Subject: [TLS] Proposal: don't change keys between handshake and application layer

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Feb 2016 20:49:33 -0700

Hi folks,

TL;DR.
I propose that we should not change keys between the handshake
and application traffic keys.

DETAILS
As we try to finalize the drafts and implementations are starting to
emerge, it's worth looking for opportunities to simplify. This is the
first of several messages suggesting areas where we may have made
things too general/complicated and now that we can look at
simplifying. The following suggestion comes out of conversations with
Karthik Bhargavan, Antoine Delignat-Lavaud, Cedric Fournet, Christian
Huitema, Markus Kohlweiss, Martin Thomson, Santiago Zanella and
others.

The general idea is that there is no strong security reason to change
change keys between handshake and traffic in the same phase (e.g.,
between the 1-RTT handshake and traffic keys, so we should simplify by
not doing so.)  This is something that implementers have asked for,
especially for DTLS (so you don't need to have three contexts in one
flight) and we have resisted, nominally for security reasons but
really over concerns about analysis.

There are three basic security reasons why one might want to change
keys:

- To add additional secret information.
- To bind in additional context.
- For PFS.

None of these apply at the handshake/traffic transition: We don’t have
any more secret material at this point in TLS 1.3 (SS and ES are both
known at the time that the handshake keys must be generated.) It is
not necessary to bind in the additional context to the traffic keys
(though see below about resumption) because it is tied to the keys
via the Finished messages. We know how to do security proofs
for this (those exist for 1.2).  There’s no reason to have different
PFS for the handshake versus the application traffic.

We can simplify matters by adopting a schedule more like the following:

Key Class     Input           Handshake Context         Specific
              Secrets         /Transcript               Keys
---------------------------------------------------------------------------------
0-RTT Keys    SS              ClientHello +             client write keys
                               ServerConfiguration +    client finished keys
                               ServerCertificate +
                               CertificateRequest

1-RTT Keys    SS, ES          ClientHello,              client/server write
keys
                              ServerHello               client/server
finished keys

Final Keys    SS, ES          Complete transcript
                              through client finished   exporter master
secret
                                                        resumption master
secret
                                                        [Maybe
traffic_secret_1]

Note that it is very important that the Resumption Master Secret
include the server certificate (otherwise you get Triple Handshake)
but you shouldn'tt need that for the initial handshake traffic keys.

This is clearly simpler and also has the advantage that you do fewer
expansions with different combinations of transcript messages. It's
a very simple change to the specification and to implementations.
It also allows a somewhat simpler key schedule (see the next message
in this series).

There are two potential objections here:
- It’s a change, how do we know it’s OK?
- Doesn’t this make analysis harder?

There are intuitive reasons to believe that it is OK (this is very
similar to what TLS 1.2 does with the resumption secret being derived
as with Extended Master Secret), and there are teams actively adapting
their analysis to verify that they are OK. Obviously, it might not be
OK and we should not finalize this change until we have some analysis.
I'll let Karthik, Cedric, etc. speak to the progress on that and
perhaps we can discuss more at TRON.

There is a sense in which it makes analysis harder in that the
cryptographic (as opposed to symbolic) proofs are better adapted to
assuming that the keys being output by the handshake are never used
for any handshake purpose. However, there are techniques for making
this work with plausible assumptions about how TLS will use the keys
(mainly that only TLS will be allowed to send traffic with the TLS
internal keys and that everything else will only get access to
Exported keys) [1].

One more important note: for DHE-PSK mode, it is important to have the
traffic encrypted under both SS and ES (I.e., both PSK and DHE) but
that’s not presently true for the handshake data (which is only
encrypted under ES). So, this will also require at least some change
to the key schedule to accommodate that. However, those changes are
relatively straightforward.

Comments, please.
-Ekr

[1] Another alternative here would be to generate separate keys for
handshake and application traffic but do so at the same time, so that
there is only one derivation stage. This simplifies the specification
and implementation somewhat, but not as much as having handshake
and application traffic.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 18 Feb 2016 14:09:21 +0200

> Key Class     Input           Handshake Context         Specific

Hmm... If there was master secret that was derived from SS, ES and
hash(ClientHello1...ServerHello) and then encryption keys, exporter
keys and resumption keys were derived from that, the result would be
very simple to analyze for GDHE-CERT (without CFG), GDHE-PSK and
PSK.

GDHE-CERT with CFG and other similar schemes are harder case. In
that case, attacks can peneratrate all the way to ClientFinished.

> but you shouldn'tt need that for the initial handshake traffic keys.

Eh, if using baseline GDHE-CERT without CFG and having master secret
like previous, I don't see how (except if going by misleading statement
in EMS RFC abstract).

However, given that things can go definitely wrong if *client*
certificate isn't included and attacks all the way to ClientFinished
can happen if SS is nontrivially used, it is probably the simplest and
the most conservative to take it as Hash(ClientHello1...ClientFinished),
which also happens to include server certificate....

> internal keys and that everything else will only get access to

One thing to note is that TLS 1.3 record type/length hiding makes
encrypted handshake and application data records distinct.

-Ilari

---

From: Wan-Teh Chang <[email-masked]>
Date: Thu, 18 Feb 2016 06:32:46 -0800

> and application traffic keys.

Hi Eric,

I'm not sure if I understand your one-sentence summary, because
"change keys between the foo and bar keys" is hard to understand. Are
you proposing that we should use the same keys to encrypt handshake
messages and application data?

Wan-Teh Chang

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Feb 2016 07:54:20 -0700

> messages and application data?

Yes, precisely.

-Ekr

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 18 Feb 2016 11:45:42 -0500

I want to point out that the benefits of using the application key output
by the
handshake protocol also for handshake traffic protection are not clear cut.
I cannot comment at the level of implementation simplification that
motivates
this change but I can comment on the cryptographic implications of this
change.

Yes, TLS 1.3, can probably be proved secure even with this key merge, but
it is
a proof of a *weaker* guarantee. When the application key is not used
during
the exchange you can claim that the handshake protocol provide *generic* key
exchange security. Here "generic" means that you can use the key with
*any* application that requires a secret shared key. In contrast, using the
application key during the key exchange process itself can still guarantee
security for a *specific* application but not in general. That is, we can
now
prove security for the specific application of this key to protecting TLS
record
layer traffic (achieved via TLS message type separation). But if you want to
take that same key and use it for a variant of the protocol or in a
different
application [1] then you need to go and re-analyze [2] the protocol with
that
specific application in mind.

Given the history of weaknesses in TLS I would prefer a more conservative
design. TLS evolves and is used in places and ways not contemplated by the
designers. For example, no one contemplated originally that people will use
a
MAC value or a session key as collision-resistant identifiers for sessions
but
people did. Models and requirements need to be strengthened over time, not
weakened. The merge of handshake and application key is a weakening.

Finally, a side effect of this change is that it limits the generality of
the
protocol. Till now the protocol was ready for an immediate variant where the
server uses a Diffie-Hellman certificate. It would require a minimal
adaptation
of the current specification where the CertificateVerify message is omitted
and
an entry in the key derivation table is added. But to encrypt the DH
certificate
you'd need to derive a key from g^xy only (which is not the case for the
application key). The DH variant is not currently contemplated but one that
can
be handy in the future (it is a simpler protocol than what we have now and
can
have benefits in a "post-quantum transition").

Hugo

PS: I wrote more about this topic here
https://www.ietf.org/mail-archive/web/tls/current/msg13625.html
(it was in the context of the need to encrypt the Finished message but the
issue
I was commenting on was the same as here, namely, the re-use of the
application
key during the handshake)

[1] Given the wide availability of TLS implementations, it makes sense for
different applications to use the TLS handshake as their key-exchange
protocol.
Fortunately, there is the exporter key that is still secure in the stronger
generic sense and can be used for that purpose. Even then, I would expect
people to use the application key as the natural session key, or be tied to
TLS
in a way that requires using the same application key. And, in any case,
changes
to the record layer protocol would require a re-assessment of security in
the
combined handshake-record protocol.

[2] The analysis of a protocol that breaks the generic and modular security
principles is doable but more complex and needs to be re-assessed with
changes
to the application protocol.

On Thu, Feb 18, 2016 at 9:54 AM, Eric Rescorla <[email-masked]> wrote:

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

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Fri, 19 Feb 2016 10:04:38 +0100

I do not have a very strong opinion on whether the same traffic keys can or should be used for the handshake and application. As Hugo says, it complicates the cryptographic analysis but we do know now how to do the analysis for such key usage, thanks to years of work on TLS <= 1.2. I am told that separate application and data keys would be tricky for DTLS implementations, but it does not seem to matter too much in our TLS implementation,
where we already manage a sequence of epochs for TLS 1.2.

Regardless of whether we make this change though, I think it would be useful for the TLS 1.3 RFC to clearly limit the scope of various keys generated by the handshake. During the connection lifetime, we generate a series of record encryption keys: handshake and application keys for 0-RTT and 1-RTT, and then a sequence of keys generated during rekeying. None of these keys should be used outside their intended use cases in a single connection.  The only cross-connection secret specified in the protocol is the resumption master secret, and if applications want a key from TLS 1.3, they must only use the exporter master secret. All other keys are internal to TLS.

We are in the process of implementing and analysing TLS 1.3 both in miTLS and in ProVerif, and from our early experiments, the one thing that is annoying to implement and analyze is the sheer number of places in the handshake where we generate keys. This is awkward because we need to mix in the handshake transcript at six different places, but also because we occasionally need to keep internal HKDF extracted state longer than necessary.  These points are probably more relevant to Ekr’s other email on the key schedule, and I will make them there and at my TRON talk. Coming back to the application/handshake key separation, I think I would be equally happy with deriving separate application and data keys but at the same time, so that we can still have three sets of keys, one for 0-RTT, one for 1-RTT, and one set of Final keys for resumption and exporters at the end of the handshake. This is essentially the same as Ekr’s proposal, except that we derive separate handshake and application keys at each stage. It has the minor added benefit of using HKDF as a black-box and not storing extracted secrets. If this complicates DTLS implementations, it would be worth understanding why.

> On 18 Feb 2016, at 17:45, Hugo Krawczyk <[email-masked]> wrote:
> 
> I want to point out that the benefits of using the application key output by the
> I cannot comment at the level of implementation simplification that motivates
> this change but I can comment on the cryptographic implications of this change.
> 
> Yes, TLS 1.3, can probably be proved secure even with this key merge, but it is
> a proof of a *weaker* guarantee. When the application key is not used during 
> security for a *specific* application but not in general. That is, we can now
> prove security for the specific application of this key to protecting TLS record
> take that same key and use it for a variant of the protocol or in a different
> application [1] then you need to go and re-analyze [2] the protocol with that
> designers. For example, no one contemplated originally that people will use a
> MAC value or a session key as collision-resistant identifiers for sessions but
> Finally, a side effect of this change is that it limits the generality of the
> server uses a Diffie-Hellman certificate. It would require a minimal adaptation
> of the current specification where the CertificateVerify message is omitted and
> an entry in the key derivation table is added. But to encrypt the DH certificate
> application key). The DH variant is not currently contemplated but one that can
> be handy in the future (it is a simpler protocol than what we have now and can
> (it was in the context of the need to encrypt the Finished message but the issue 
> I was commenting on was the same as here, namely, the re-use of the application 
> different applications to use the TLS handshake as their key-exchange protocol.
> people to use the application key as the natural session key, or be tied to TLS
> in a way that requires using the same application key. And, in any case, changes
> to the record layer protocol would require a re-assessment of security in the
> principles is doable but more complex and needs to be re-assessed with changes

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 19 Feb 2016 12:58:51 +0200

On Fri, Feb 19, 2016 at 10:04:38AM +0100, Karthikeyan Bhargavan wrote:

> Regardless of whether we make this change though, I think it would be
> useful for the TLS 1.3 RFC to clearly limit the scope of various keys
> generated by the handshake. During the connection lifetime, we generate
> a series of record encryption keys: handshake and application keys for
> 0-RTT and 1-RTT, and then a sequence of keys generated during rekeying.
> None of these keys should be used outside their intended use cases in a
> single connection.  The only cross-connection secret specified in the
> protocol is the resumption master secret, and if applications want a
> key from TLS 1.3, they must only use the exporter master secret. All
> other keys are internal to TLS.

I think TLS 1.3 RFC should specify what the protocol looks like and how
it can be used from application perspective. This includes specifying
what keys can be exported (among many other things, like how
authentication can be performed).

I agree that exporting the main encryption keys or secrets those are
derived from for any purpose is a rotten idea. If you need keying or
authentication material, use TLS EXPORTER (tls-unique is deprecated)
with requirement to use EMS on prior versions[1]. 

Then one might need to export RMS. I think it should be exported as
blob that also contains other associated information (e.g ciphersuites).
And possibly also encrypted, using some MRAE algorithm.

[1] Compatiblity hack: One might consider EMS always negotiated when
TLS 1.3 is negotiated. This could prvent applications that do know
about EMS but not TLS 1.3 from breaking when upgrading to TLS 1.3.

That is, if application asks about TLS 1.3 (ServerVersion 3.4)
connection "is EMS enabled?" the answer will be always "yes"
(since the point of that check is to exclude THS attacks, and
TLS 1.3 already excludes those on baseline).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Feb 2016 07:16:18 -0700

> with requirement to use EMS on prior versions[1].

This is the intent. I think we would be well-served to state this.

> TLS 1.3 already excludes those on baseline).

Good suggestion. This in fact is what NSS currently does:
https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslinfo.c#70

-Ekr

---

From: Cedric Fournet <[email-masked]>
Date: Fri, 19 Feb 2016 17:58:28 +0000

As pointed out by Karthik, we are not strongly advocating this simplification, but we do not think it would weaken the security of TLS. Details below.

-Cédric, with the miTLS team

In the following, I only consider the record layer keys, which are used for authenticated encryption; I ignore all other derived key materials. The TLS layered design goes as follows:
- The handshake provides fresh keys to the record layer (depending on its internal state machine) and keeps running;
- The record layer uses the current keys for encrypting *all* traffic, mixing handshake messages, alerts, and application data (once enabled).

These keys are used sequentially, and only by the record-layer. They are not directly used within the handshake protocol itself, or by the TLS application.
- Since the sequence of keys is meant to protect the whole stream of TLS fragments, one needs to authenticate each point in the stream where there is a key change, to prevent any traffic truncation. As discussed in another thread, we believe this is correctly handled in draft#11, but each key change remains a source of complication [1].
- There are excellent reasons to change keys between 0-RTT and 1-RTT (stronger key materials, forward secrecy).
- Otherwise, what matters is the provenance of the key (how it was derived, what identities are associated with it) and there is no point changing keys with the same provenance.

The situation is particularly clear in 0-RTT: in draft#11, the client always derives two record-layer keys from the same materials, and uses each of these keys in turn to encrypt half of its 0-RTT flight, with a Finished message in-between that signals the key change. This key change does not degrade security, but seems unnecessary.

In 1-RTT, this is less obvious because, in draft#11, the handshake keys and application-data keys are not exactly derived from the same materials. We believe this should be fixed (see the “simplified key schedule” thread). Then the same argument applies: the key change is not terrible, but it is an unnecessary complication.

I disagree with Hugo that using the same record-layer key for handshake and application data yields a proof of a weaker guarantee. As far as I can tell, this is a technicality in the cryptographic proof of the handshake, and we still get the same security guarantees for TLS users [2]. I also like simple proofs of generic security for the handshake core, but I do not see how they can cover the other features of TLS [e.g. 3, and late handshake messages] with or without the simplification. Given the choice between a simpler protocol that it is easier to implement correctly, and simpler proofs for a core, I would rather simplify the overall protocol and do the extra proof work.

One may argue about what would happen if some of the record-layer keys were mis-used, against the TLS specification (despite its export mechanism) and conclude that we need more, not less key changes [3]. But I would not call it “a different application” and I am still tempted to simplify the key schedule for its intended usage in TLS.

[1] An attacker may, for instance, delete the last fragment encrypted before the key change. Such a deletion will be caught at the protocol layer, e.g. because the last fragment is not an “end_of_early_data” alert or a Finished message. Without the key change, any deletion would be caught immediately, as the next fragment decryption fails.

[2] we do not have a complete model for TLS 1.3 yet, but we developed a detailed model for TLS 1.2 http://eprint.iacr.org/2014/182 similarly covering record-layer key changes (for renegotiations) and the fact that those keys were used to protect the Finished messages *before* key confirmation and application-data traffic. The main difference with classic models for key exchange, where the protocol runs to completion and returns “the” application key, is that in our model the honest instances provide keys during the protocol run.

[3] as recently discussed as 0.5-RTT, the spec enables the use of 1-RTT keys before completing the handshake, with weaker guarantees on the encrypted application data. However, an extra key change would require additional signalling messages.

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: 19 February 2016 14:16
To: Ilari Liusvaara <[email-masked]>
Cc: Karthikeyan Bhargavan <[email-masked]>; [email-masked]
Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer

On Fri, Feb 19, 2016 at 3:58 AM, Ilari Liusvaara <[email-masked]<mailto:[email-masked]>> wrote:

Good suggestion. This in fact is what NSS currently does:
https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslinfo.c#70<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdxr.mozilla.org%2fmozilla-central%2fsource%2fsecurity%2fnss%2flib%2fssl%2fsslinfo.c%2370&data=01%7c01%7cFOURNET%40064d.mgd.microsoft.com%7c769519cd967541c83e5808d339375926%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=yHU8A1PxV303DF3hxMLZ1BEQRbGqPe1gjdnrjhwWHe8%3d>

-Ekr

-Ilari

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cFOURNET%40064d.mgd.microsoft.com%7c769519cd967541c83e5808d339375926%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=PPF4H7v%2fuGhlNE2r%2bgtYYhztJsCvr9ftMN%2fPrxevBxQ%3d>

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 19 Feb 2016 14:56:36 -0500

On Fri, Feb 19, 2016 at 12:58 PM, Cedric Fournet <[email-masked]>
wrote:

> As pointed out by Karthik, we are not strongly advocating this
> simplification, but we do not think it would weaken the security of TLS.
> Details below.
>

I am glad you are not strongly advocating this.
I strongly advocate not using the application keys to protect handshake
messages.
I want a well-delimited point where the output session key is as good as a
fresh, never-used secret key, and that session key be used to protect
subsequent record layer traffic.

As I said, I cannot weigh this against implementation advantages of the
freshness-violation approach; but these have to be *very* significant to be
worth the security weakening.

And yes, I think this is a security weakening.
We are talking about two levels of guarantee.
One, where the TLS key exchange protocol outputs a secret key that is good
for *any* application that requires two parties to share a secret key.
The other, where the use of the key produced by this protocol is secure
enough for a *specific* application, namely, TLS record layer (at least in
its current definition).

The second is clearly weaker. It has a more limited (secure) use scope.
For example, it means that changes to the record layer protocol could
require a re-assessment of the security of the handshake, and certainly
this is the case for a different application that somehow modifies the
record layer or makes assumptions different than the intended use of the
record layer.
With a "generically secure" handshake this reassessment of the handshake
would not be needed, you would only need to verify that your application is
secure under an (ideally) shared secret key.

I am sure we all agree that considering future changes to the record layer,
changes to applications using the handshake, etc is not a theoretical
concern.
The last thing you want to assume is that the TLS environment and the
protocol evolution is static.

I think that a conservative take on this important point is the right way
to go.

H
​ugo​

> In the following, I only consider the record layer keys, which are used
> for authenticated encryption; I ignore all other derived key materials. The
> TLS layered design goes as follows:
>
> - The handshake provides fresh keys to the record layer (depending on its
> internal state machine) and keeps running;
>
> - The record layer uses the current keys for encrypting *all* traffic,
> mixing handshake messages, alerts, and application data (once enabled).
>
>
>
> These keys are used sequentially, and only by the record-layer. They are
> not directly used within the handshake protocol itself, or by the TLS
> application.
>
> - Since the sequence of keys is meant to protect the whole stream of TLS
> fragments, one needs to authenticate each point in the stream where there
> is a key change, to prevent any traffic truncation. As discussed in another
> thread, we believe this is correctly handled in draft#11, but each key
> change remains a source of complication [1].
>
> - There are excellent reasons to change keys between 0-RTT and 1-RTT
> (stronger key materials, forward secrecy).
>
> - Otherwise, what matters is the provenance of the key (how it was
> derived, what identities are associated with it) and there is no point
> changing keys with the same provenance.
>
>
>
> The situation is particularly clear in 0-RTT: in draft#11, the client
> always derives two record-layer keys from the same materials, and uses each
> of these keys in turn to encrypt half of its 0-RTT flight, with a Finished
> message in-between that signals the key change. This key change does not
> degrade security, but seems unnecessary.
>
>
>
> In 1-RTT, this is less obvious because, in draft#11, the handshake keys
> and application-data keys are not exactly derived from the same materials.
> We believe this should be fixed (see the “simplified key schedule” thread).
> Then the same argument applies: the key change is not terrible, but it is
> an unnecessary complication.
>
>
>
> I disagree with Hugo that using the same record-layer key for handshake
> and application data yields a proof of a weaker guarantee. As far as I can
> tell, this is a technicality in the cryptographic proof of the handshake,
> and we still get the same security guarantees for TLS users [2]. I also
> like simple proofs of generic security for the handshake core, but I do not
> see how they can cover the other features of TLS [e.g. 3, and late
> handshake messages] with or without the simplification. Given the choice
> between a simpler protocol that it is easier to implement correctly, and
> simpler proofs for a core, I would rather simplify the overall protocol and
> do the extra proof work.
>
>
>
> One may argue about what would happen if some of the record-layer keys
> were mis-used, against the TLS specification (despite its export mechanism)
> and conclude that we need more, not less key changes [3]. But I would not
> call it “a different application” and I am still tempted to simplify the
> key schedule for its intended usage in TLS.
>
>
>
>
>
> [1] An attacker may, for instance, delete the last fragment encrypted
> before the key change. Such a deletion will be caught at the protocol
> layer, e.g. because the last fragment is not an “end_of_early_data” alert
> or a Finished message. Without the key change, any deletion would be caught
> immediately, as the next fragment decryption fails.
>
>
>
> [2] we do not have a complete model for TLS 1.3 yet, but we developed a
> detailed model for TLS 1.2 http://eprint.iacr.org/2014/182 similarly
> covering record-layer key changes (for renegotiations) and the fact that
> those keys were used to protect the Finished messages *before* key
> confirmation and application-data traffic. The main difference with classic
> models for key exchange, where the protocol runs to completion and returns
> “the” application key, is that in our model the honest instances provide
> keys during the protocol run.
>
>
>
> [3] as recently discussed as 0.5-RTT, the spec enables the use of 1-RTT
> keys before completing the handshake, with weaker guarantees on the
> encrypted application data. However, an extra key change would require
> additional signalling messages.
>
>
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* 19 February 2016 14:16
> *To:* Ilari Liusvaara <[email-masked]>
> *Cc:* Karthikeyan Bhargavan <[email-masked]>; [email-masked]
> *Subject:* Re: [TLS] Proposal: don't change keys between handshake and
> application layer
>
>
>
>
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdxr.mozilla.org%2fmozilla-central%2fsource%2fsecurity%2fnss%2flib%2fssl%2fsslinfo.c%2370&data=01%7c01%7cFOURNET%40064d.mgd.microsoft.com%7c769519cd967541c83e5808d339375926%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=yHU8A1PxV303DF3hxMLZ1BEQRbGqPe1gjdnrjhwWHe8%3d>
>
>
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>
>
> -Ilari
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cFOURNET%40064d.mgd.microsoft.com%7c769519cd967541c83e5808d339375926%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=PPF4H7v%2fuGhlNE2r%2bgtYYhztJsCvr9ftMN%2fPrxevBxQ%3d>
>
>
>

---

From: Cedric Fournet <[email-masked]>
Date: Sat, 20 Feb 2016 18:53:44 +0000

We have rather different views of the protocol. You see the record layer as a sample application outside TLS, whereas our model (tied to our implementation) composes the handshake and the record-layer subprotocols to get security at the TLS API. You also reason about “the output session key”, whereas the handshake successively provides all traffic keys to the record layer and then provides an "exporter secret" to the application. Accordingly, you assume the handshake encrypts its own messages, whereas TLS delegates that task to the record layer—see my previous post for the details.

Hence, I understand your general argument, and I think it applies perfectly to the "exporter secret", but not to the proposed simplification (involving two traffic keys internal to TLS, successively used by the same record-layer) and I don’t see how this simplification would cause any security weakening.

Besides, in our analysis of the handshake, we get precisely the same “fresh, never-used secret” property you are advocating, with or without the simplification, each time the handshake provides keys to the record layer. These points are well-specified and delimited. They just do not coincide with the end of the handshake. So I don’t see any fundamental difference in term of generic-security.

We are left with scenarios whereby the record layer, given both the handshake and application-data traffic keys, somehow leaks only one of the two. I don’t mind keeping the key change if someone is concerned about it.

-Cédric

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hugo Krawczyk
Sent: 19 February 2016 19:57
To: Cedric Fournet <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; Ilari Liusvaara <[email-masked]>; Karthikeyan Bhargavan <[email-masked]>; [email-masked]; Markulf Kohlweiss <[email-masked]>; Antoine Delignat-Lavaud <[email-masked]>; Santiago Zanella-Beguelin <[email-masked]>
Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer

On Fri, Feb 19, 2016 at 12:58 PM, Cedric Fournet <[email-masked]<mailto:[email-masked]>> wrote:
As pointed out by Karthik, we are not strongly advocating this simplification, but we do not think it would weaken the security of TLS. Details below.

I am glad you are not strongly advocating this.
I strongly advocate not using the application keys to protect handshake messages.
I want a well-delimited point where the output session key is as good as a fresh, never-used secret key, and that session key be used to protect subsequent record layer traffic.

As I said, I cannot weigh this against implementation advantages of the freshness-violation approach; but these have to be *very* significant to be worth the security weakening.

And yes, I think this is a security weakening.
We are talking about two levels of guarantee.
One, where the TLS key exchange protocol outputs a secret key that is good for *any* application that requires two parties to share a secret key.
The other, where the use of the key produced by this protocol is secure enough for a *specific* application, namely, TLS record layer (at least in its current definition).

The second is clearly weaker. It has a more limited (secure) use scope.
For example, it means that changes to the record layer protocol could require a re-assessment of the security of the handshake, and certainly this is the case for a different application that somehow modifies the record layer or makes assumptions different than the intended use of the record layer.
With a "generically secure" handshake this reassessment of the handshake would not be needed, you would only need to verify that your application is secure under an (ideally) shared secret key.

I am sure we all agree that considering future changes to the record layer, changes to applications using the handshake, etc is not a theoretical concern.
The last thing you want to assume is that the TLS environment and the protocol evolution is static.

I think that a conservative take on this important point is the right way to go.

H
​ugo​

[2] we do not have a complete model for TLS 1.3 yet, but we developed a detailed model for TLS 1.2 http://eprint.iacr.org/2014/182<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2feprint.iacr.org%2f2014%2f182&data=01%7c01%7cFOURNET%40064d.mgd.microsoft.com%7c06953edc7b1343ec593708d33966da80%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=aA0e6ohTu%2bU8knDx23DolVNk0xCe%2fgf51HsQE6jFTKY%3d> similarly covering record-layer key changes (for renegotiations) and the fact that those keys were used to protect the Finished messages *before* key confirmation and application-data traffic. The main difference with classic models for key exchange, where the protocol runs to completion and returns “the” application key, is that in our model the honest instances provide keys during the protocol run.

From: TLS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Rescorla
Sent: 19 February 2016 14:16
To: Ilari Liusvaara <[email-masked]<mailto:[email-masked]>>
Cc: Karthikeyan Bhargavan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer

-Ekr

-Ilari

---

From: "Paterson, Kenny" <[email-masked]>
Date: Sat, 20 Feb 2016 19:58:53 +0000

Hi

My 2c below...

On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet"
<[email-masked] on behalf of [email-masked]> wrote:
>
> 
>Besides, in our analysis of the handshake, we get precisely the same
>“fresh, never-used secret” property you are advocating, with or
> without the simplification, each time the handshake provides keys to the
>record layer. These points are well-specified and delimited. They just do
>not coincide with the end of the handshake. So I don’t see any
>fundamental difference in term of generic-security.
> 
>We are left with scenarios whereby the record layer, given both the
>handshake and application-data traffic keys, somehow leaks only
> one of the two. I don’t mind keeping the key change if someone is
>concerned about it.

Like Hugo, I am also concerned about removing the key change. Let me try
to explain why.

I would emphasise the point that while we *can* provide formal security
analyses in the situation where the application key is used during the
handshake itself, it is made significantly more complex.

In particular, it means we cannot simply combine security results arising
from separate analyses of the Handshake Protocol and of the Record
Protocol to obtain security guarantees for the composition of these two
protocols. So for example, if we chose to refine our modelling of the
Record Protocol in some way, then we would need to re-do the analysis of
TLS (Handshake + Record Protocols) as a monolithic effort. That's hard
work and error prone. This situation would not arise if the application
keys were NOT used in the handshake.

This is not merely a conjectured issue. As one example, several papers
(including [1,2]) in the "provable security" paradigm have used the ACCE
framework as a security model within which to conduct analysis of
fragments of previous versions of TLS. ACCE was specifically designed to
deal with keys that are used across the Handshake and the Record
protocols. But ACCE views the Record Protocol in a particular way -
essentially as a stateful encryption scheme that processes "atomic"
messages. This modelling does not take into full account the streaming
nature of the TLS Record Protocol - in fact, what the Record Protocol
actually guarantees is significantly different from what is implied by the
ACCE modelling of it - see [3] for details, and also the cookie cutter
attack from the Triple Handshakes paper for an example of what can go
wrong.

One implication of this is that the results of [1,2] for existing versions
of TLS really need to be reworked in a modified version of the ACCE
framework that better reflects the streaming nature of the Record
Protocol. That need for rework would have been avoided had TLS not used
application keys in the Handshake Protocol, because the compositional
guarantees would have enabled us to "plug and play" with our results.

The same pertains in TLS 1.3 going forward: keeping the strict key
separation - no use of the application keys in the Handshake - will make
future - and on-going - analyses of TLS 1.3 easier. This is
notwithstanding the fact that several research teams, including Cedric's
and [1,2] below, have managed to produce analyses that do handle the use
of the application key in the Handshake.

Regards,

Kenny 

[1] Tibor Jager, Florian Kohlar, Sven Schäge, Jörg Schwenk. On the
Security of TLS-DHE in the Standard Model. CRYPTO 2012.
[2] Hugo Krawczyk, Kenneth G. Paterson, Hoeteck Wee. On the Security of
the TLS Protocol: A Systematic Analysis. CRYPTO (1) 2013.
[3] Marc Fischlin, Felix Günther, Giorgia Azzurra Marson, Kenneth G.
Paterson: Data Is a Stream: Security of Stream-Based Channels. CRYPTO (2)
2015.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 20 Feb 2016 12:30:06 -0800

Kenny,

Would you have a problem with doing as Karthik suggests and generating
separate traffic and handshake keys but at the same time?

-Ekr

On Sat, Feb 20, 2016 at 11:58 AM, Paterson, Kenny <[email-masked]

---

From: Watson Ladd <[email-masked]>
Date: Sat, 20 Feb 2016 14:45:19 -0800

> separate traffic and handshake keys but at the same time?

This solves all the problems completely, as the traffic key is fresh.

>
> -Ekr
>
>
> On Sat, Feb 20, 2016 at 11:58 AM, Paterson, Kenny <

---

From: "Paterson, Kenny" <[email-masked]>
Date: Sat, 20 Feb 2016 23:24:05 +0000

Hi Eric,

Looks like Watson already gave a definitive reply on my behalf. Thanks
Watson, for being such an effective and proactive amanuensis.

For the avoidance of doubt: what Karthik suggests would avoid the problem
we've been discussing, so I'd be quite happy with it.

Cheers

Kenny 

On 20/02/2016 20:30, "Eric Rescorla" <[email-masked]> wrote:

>On Sat, Feb 20, 2016 at 11:58 AM, Paterson, Kenny
><[email-masked]> wrote:
>
>Hi
>
>My 2c below...
>