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:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: 19 February 2016 14:16 To: Ilari Liusvaara <ilariliusva...@welho.com> Cc: Karthikeyan Bhargavan <karthik.bharga...@gmail.com>; tls@ietf.org Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer On Fri, Feb 19, 2016 at 3:58 AM, Ilari Liusvaara <ilariliusva...@welho.com<mailto:ilariliusva...@welho.com>> wrote: 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]. This is the intent. I think we would be well-served to state this. 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). 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 TLS@ietf.org<mailto:TLS@ietf.org> 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>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
