On Fri, Feb 19, 2016 at 12:58 PM, Cedric Fournet <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 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> > 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 > 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
