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: hugok...@gmail.com [mailto:hugok...@gmail.com] On Behalf Of Hugo Krawczyk Sent: 19 February 2016 19:57 To: Cedric Fournet <four...@microsoft.com> Cc: Eric Rescorla <e...@rtfm.com>; Ilari Liusvaara <ilariliusva...@welho.com>; Karthikeyan Bhargavan <karthik.bharga...@gmail.com>; tls@ietf.org; Markulf Kohlweiss <mark...@microsoft.com>; Antoine Delignat-Lavaud <an...@microsoft.com>; Santiago Zanella-Beguelin <santi...@microsoft.com> Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer On Fri, Feb 19, 2016 at 12:58 PM, Cedric Fournet <four...@microsoft.com<mailto:four...@microsoft.com>> 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 -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<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. [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<mailto:tls-boun...@ietf.org>] On Behalf Of Eric Rescorla Sent: 19 February 2016 14:16 To: Ilari Liusvaara <ilariliusva...@welho.com<mailto:ilariliusva...@welho.com>> Cc: Karthikeyan Bhargavan <karthik.bharga...@gmail.com<mailto:karthik.bharga...@gmail.com>>; tls@ietf.org<mailto: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
