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 <h...@ee.technion.ac.il> wrote: > > 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 <e...@rtfm.com> wrote: > > On Thu, Feb 18, 2016 at 7:32 AM, Wan-Teh Chang <w...@google.com> wrote: > On Wed, Feb 17, 2016 at 7:49 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > > TL;DR. > > I propose that we should not change keys between the handshake > > 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? > > Yes, precisely. > > -Ekr > > _______________________________________________ > 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
