Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

[Douglas Stebila <[e-mail]>]

> On Jul 11, 2016, at 19:24, Andrei Popov <[e-mail]> wrote:
> 
> As currently defined, post-handshake client auth allows the same client to present different identities, but not to repudiate a previously presented identity. So in your example, from the TLS perspective, the client is both Alice and Bob, and therefore I think the same EKM value makes sense.

Even if that's how it's defined, we cannot be sure that applications which use EKM will realize that.  We should not underestimate how much applications may abuse TLS or misunderstand TLS's security properties.

> On Jul 11, 2016, at 21:13, Martin Thomson <[e-mail]> wrote:
> 
> 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.

Agreed, this does create the possibility that the endpoints will export different values at different times due to unsynchronized context switches.  

However, we should compare this failure mode (which might cause two "partnered" parties to not get the same exporter key) with the failure mode if we use the same EKM for the whole session (which might cause more parties than we expect to get the same exporter key).  Fail-closed versus fail-open.

Douglas


> On 12 July 2016 at 05:39, Douglas Stebila <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls