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

[Eric Rescorla <[e-mail]>]

On Mon, Jul 11, 2016 at 7:56 PM, Hugo Krawczyk <[e-mail]>
wrote:

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

I filed the following issue so we would remember this:
https://github.com/tlswg/tls13-spec/issues/540

-Ekr


> Hugo
>
>
>>
>> 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
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>