On Mon, Jul 11, 2016 at 9:13 PM, Martin Thomson <martin.thom...@gmail.com> wrote:
> 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. > This is unrelated to the issue s raised by Douglas , but if the exporter *key* is intended for use as a unique session identifier (or a sort of "channel binding") then calling it a "key" is misleading. For example, while a key of 128 bits is perfectly fine (e.g. for AES-128), such length is insufficient as a channel binding string (where resistance to birthday attacks seems necessary). I do not see a note on this in the TLS document or RFC 5705. Hugo > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
