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

From: Douglas Stebila <[email-masked]>
Date: Mon, 11 Jul 2016 15:39:43 -0400

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

---

From: Andrei Popov <[email-masked]>
Date: Mon, 11 Jul 2016 23:24:30 +0000

Hi Douglas,

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.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Douglas Stebila
Sent: Monday, July 11, 2016 12:40 PM
To: [email-masked]
Subject: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

Douglas
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jul 2016 11:13:07 +1000

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.

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 11 Jul 2016 22:56:22 -0400

> 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

> > 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:
> >
> > 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.
> >
> > 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Jul 2016 20:13:24 -0700

> TLS document or RFC 5705.

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

-Ekr

>> > 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
>> > 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

---

From: Douglas Stebila <[email-masked]>
Date: Tue, 12 Jul 2016 10:00:35 -0400

> On Jul 11, 2016, at 19:24, Andrei Popov <[email-masked]> wrote:
> 

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 <[email-masked]> wrote:
> 
> Back to the question...

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

---

From: Bill Cox <[email-masked]>
Date: Tue, 12 Jul 2016 08:34:32 -0700

IIRC, in TLS 1.2 the same keys are used after resumption, and EKM values do
not change.  I think most applications currently using EKM will break if
the EKM values change after a PSK resume.

However, forcing TLS 1.3 to remember a 256-bit EKM seed will bloat tickets
by 32 bytes, and complicate the state machine.  I think this could
partially be addressed by enhancing the custom extension APIs found in
popular TLS libraries to enable custom extensions to specify state that
needs to be remembered on a resume.  That, in combination with requiring
extensions to be sent and processed in order of extension number, could
enable a lot of this complexity to be taken out of the main TLS code, and
only connections that actually need such extensions would see the increase
in ticket size.

Could something like this could work well for channel binding?

Bill

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Jul 2016 08:53:22 -0700

On Tue, Jul 12, 2016 at 8:34 AM, Bill Cox <[email-masked]> wrote:

> IIRC, in TLS 1.2 the same keys are used after resumption, and EKM values
> do not change.
>

In TLS 1.2, the EKM == MS but the exporter includes the randoms:

           PRF(SecurityParameters.master_secret, label,
               SecurityParameters.client_random +
               SecurityParameters.server_random +
               context_value_length + context_value
               )[length]

This means that if you resume, you should get different exported values.

-Ekr

I think most applications currently using EKM will break if the EKM values
> change after a PSK resume.
>

---

From: Andrei Popov <[email-masked]>
Date: Tue, 12 Jul 2016 15:56:38 +0000

Ø  IIRC, in TLS 1.2 the same keys are used after resumption, and EKM values do not change.
Is this correct? EKM mixes in client and server randoms, which are hopefully different in each resumption.

Cheers,

Andrei

From: Bill Cox [mailto:[email-masked]]
Sent: Tuesday, July 12, 2016 8:35 AM
To: Douglas Stebila <[email-masked]>
Cc: Andrei Popov <[email-masked]>; Martin Thomson <[email-masked]>; [email-masked]
Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

IIRC, in TLS 1.2 the same keys are used after resumption, and EKM values do not change.  I think most applications currently using EKM will break if the EKM values change after a PSK resume.

However, forcing TLS 1.3 to remember a 256-bit EKM seed will bloat tickets by 32 bytes, and complicate the state machine.  I think this could partially be addressed by enhancing the custom extension APIs found in popular TLS libraries to enable custom extensions to specify state that needs to be remembered on a resume.  That, in combination with requiring extensions to be sent and processed in order of extension number, could enable a lot of this complexity to be taken out of the main TLS code, and only connections that actually need such extensions would see the increase in ticket size.

Bill

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 13 Jul 2016 00:27:40 +0300

On Tue, Jul 12, 2016 at 10:00:35AM -0400, Douglas Stebila wrote:
> Agreed, this does create the possibility that the endpoints will export
> different values at different times due to unsynchronized context
> switches.  

It gets worse: KeyUpdate is explicitly designed to work even when
arbitrarily unsynchronized and run behind app's back (the application
never having to care for it).

> 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.

Also, I wouldn't expect rekeying occur very often at default. 24M
records in bulk transfer is quite a bit of data (would require quite
fast connection to do in a few hours even at full blast). And there
is no recommendation on time-based rekeying (and Chacha can run
as good as forever even on the fastest connections).

So, even if rekey changed EKM, it likely would not save you if
application misused exporters in way vulernable to this.

Worth security consideration? Certainly.

Also, why does post-handshake auth seemingly always use traffic_secret_0,
instead say whatever happens to be the newest in forward (C->S)
direction when the Finished is sent (that would be well-defined key)?

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Jul 2016 14:42:15 -0700

> direction when the Finished is sent (that would be well-defined key)?

Thinko.

Filed an issue for this.
https://github.com/tlswg/tls13-spec/issues/545

-Ekr