Not taking any position on the question, which I think is a fine thing to ask, but...
I'd just like to point out that the example is flawed in the sense that the system permits both users to share state. When Alice logs out, that needs to include any state that might have been accumulated to Alice. This necessarily includes any sessions, including that TLS connection. If we imagine that this is a browser, then you also need to flush caches and remove cookies before the system is usable by another user. There might be operating system level things as well. Machines in internet cafes often create temporary accounts, or even rebuild the entire machine between users for this reason. Back to the question... One challenge with this is that exporters are often used to compare things. For instance, one side signs an exported value, the other validates the signature by independently exporting the same value. Getting different values for a particular exporter will cause some classes of things to fail in subtle ways. On 12 July 2016 at 05:39, Douglas Stebila <dsteb...@gmail.com> wrote: > Some of the discussions I've had with people about post-handshake client > authentication have raised the question of whether application traffic > secrets should be updated automatically upon post-handshake client > authentication: the thinking being that every change in context should be > accompanied by a change in keying material. I used to think that was a good > idea for TLS 1.3, although it was recently argued to me that if we view the > application traffic secrets as being "internal" to the TLS protocol, then the > change in client authentication status doesn't change the confidential or > integrity properties of the record layer, it just serves as a "marker" to the > application that certain portions of the application data were associated > with certain authentication contexts. I was convinced that this can be > safely accomplished without a change in application traffic secret key > material. > > But I'm not sure that the same applies to *exporter* keys. Should exported > keying material change as the authentication context changes? > > Consider a long-lived TLS connection, where different users come and go. For > example, a web browser on a public terminal may have established a long-lived > TLS connection to a particular website, and send subsequent requests to the > same website over the same TLS connection. Now imagine two users use the > terminal one after another: > > 1: initial handshake on a public terminal > 2: [time passes] > 3: Alice starts browsing > 4: Alice does post-handshake client authentication > 5: Alice purchases something > 6: Alice hits "logout" at the application layer > 7: [time passes] > 8: Bob starts using the terminal > 9: Bob does post-handshake client authentication > 10: Bob purchases something > 11: Bob hits "logout" at the application layer > > TLS 1.3 will tell the application about events 4 and 9. Events 6 and 11 > happen at the application layer rather than the TLS layer (since I don't > think TLS 1.3 has a client-de-authentication option). But putting this all > together, the application will learn all the correct authentication contexts: > 1-3 is anonymous, 4-5 is Alice, 6-8 is anonymous, 9-10 is Bob, 11-onwards is > anonymous. > > Now imagine that we use keying material exporters in on lines 5 and 10: > > 1: initial handshake on a public terminal > 2: [time passes] > 3: Alice starts browsing > 4: Alice does post-handshake client authentication > *5: Alice presses the "export keying material" button > 6: Alice hits "logout" at the application layer > 7: [time passes] > 8: Bob starts using the terminal > 9: Bob does post-handshake client authentication > *10: Bob presses the "export keying material" button > 11: Bob hits "logout" at the application layer > > Since the exporter master secret is not updated when client authentication > changes, Alice and Bob will export the same keying material at steps 5 and > 10. If the intended goal of this exported key is for Alice to obtain > confidentiality in some other use, this will not be achieved, since Bob will > obtain the same exported key. > > Now, a proviso is that RFC 5705 allows for the application to mix a "context > value" into the export, which could mitigate this, but that is optional. > > So it seems to me like in at least some scenarios, exported keying material > should be associated with authentication context. It is less clear to me if > the same holds true for KeyUpdates. > > Douglas > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
