On Fri, Feb 19, 2016 at 2:12 AM, Karthikeyan Bhargavan < [email protected]> wrote:
> > Note that this is (almost) exactly the original KDF scheme of OPTLS as I > presented in Dallas > > > Indeed, Ekr’s proposed scheme looks much like you original diagram. > I would like to clarify that this isn't *my* scheme, though I think it's a good one. It came out of a long discussion with the people listed in my original message and probably is most closely derived from something Karthik drew. Sorry if I gave an impression to the contrary! In any case, I'm glad to see that it's close to Hugo's original diagram, since that's a good indication that we're on the right track! Anyway, from here you can see that the last HKDF in your scheme (with 0 > salt) > is not needed. You can derive the RMS, EMS keys directly from the second > HKDF > (as siblings of 1-RTT Traffic Keys). Am I missing something? > > > The purpose of the third HKDF is to bind the handshake context (the full > transcript) into > the resumption and exporter keys. It adds no new key material. > Yes, that was my understanding as well. I see that Ilari suggested that this might not be necessary (presumably as a consequence of having the full shares included in the stage 2 transcript rather than just the nonces as in TLS 1.2. The imperative here is to avoid creating an attack like triple handshake or the Cremers et al. attack on the PSK-resumption. In any case, having the EMS and RMS keys derived at the end also helps enforce the logic that you should never be exporting/resuming until you have actually completed the handshake. What I do miss in this scheme is the derivation of the Finished keys. I hope > you do not intend to use the application key for this! > > > Indeed those are missing in the picture, but I believe Ekr means to derive > separate > finished keys alongside the 1-RTT Traffic keys (right after the > ServerHello) > Affirmative. Error in my diagram. I also want to stress, for the record, that this simplification has nothing > to > do with using the application keys for handshake protection. > > > I agree, this key schedule simplification seems orthogonal. > Yes, but... In the current 1-RTT mode, there is a derivation stage that does not appear on this diagram, one that includes the transcript up to the server CertificateVerify and is used to derive the application traffic keys. So, if part of the intent of this diagram is to reduce the number of points at which we derive, we will need to derive the application traffic keys at stage 2 even if they are separate from the handshake traffic keys. I believe this something you proposed, but I just want to clarify that this diagram would entail a change in the timing of key derivation, even if not the number of keys. > For what it’s worth, I am building a symbolic model of this new key > schedule and will > report my analysis results at TRON. It’s not a cryptographic proof, but it > should shake > out early logical bugs in the design, if any. > > Best, > Karthik > > > That "optimization" > is orthogonal to this KDF simplification and hopefully will be reverted > (*). > > (*) You may say I'm a dreamer, But I may not be the only one :-) > > Nothing to be reverted yet, it's just a proposal. If it's a bad idea (and being prohibitively hard to analyze is one reason it might be) then we shouldn't adopt it. Hugo > > PS: I have a disagreement with you in terms of the protocol now being > "signature based". Yes there are signatures in the protocol but not all > modes > use them and they are not always needed. In my eyes the logic of the > protocol > is best seen as DH-based with authentication occurring through the server > Finished MAC (with a key derived from SS which can take the values of g^xs, > g^xy or PSK). That is common to *all* modes, including 0-RTT and PSK which > do > not build on signatures. This is how the protocol was built originally and > that structure remains in spite of the added signatures. > > Sorry about the misleading terminology. I just meant that it presently has signatures. I'll try to be more precise in future. -Ekr On Thu, Feb 18, 2016 at 4:05 PM, Eric Rescorla <[email protected]> wrote: > >> Hi folks, >> >> TL;DR. >> Let's simplify the key schedule. >> >> >> DETAILS >> This is the second in a series of proposed simplifications to TLS 1.3 >> based on implementation experience and analysis once the protocol >> starts to harden. The following suggestion comes out of conversations >> with Richard Barnes, Karthik Bhargavan, Antoine Delignat-Lavaud, >> Cedric Fournet, Markus Kohlweiss, Martin Thomson, Santiago Zanella and >> others. >> >> The current key schedule is elegant but it is actually more than we >> need in that it allows SS to be known either before or after ES. If we >> assume (as is always true in the current TLS 1.3 modes) that SS is >> known before or at the same time as ES, then we can design a simpler >> scheme which looks more like a ladder. Something like: >> >> 0 >> | >> SS -> HKDF [ClientHello + Context] >> | \ >> | \ >> v v >> X1 0-RTT Traffic Keys * >> | >> | >> v >> ES -> HKDF [ClientHello, ServerHello] >> | \ >> | \ >> v v >> X2 1-RTT Traffic Keys * >> | >> | >> v >> 0 -> HKDF [ClientHello...ClientFinished] >> | >> | >> v >> RMS, EMS >> >> As should be apparent, this key schedule is well-suited to the >> simplified key change schedule in my previous message. >> >> Note 1: It might be attractive to not even bother with the first stage >> if you aren't doing 0-RTT. It's not necessary then. However, this is >> just an optimization. Also, if you don't want to extract an RMS or an >> EMS you can skip the last stage (this is compatible). >> >> Note 2: The IKM for the final HKDF is 0, but in principle we could use >> it to add some sort of new keying material, for instance g^xs if we >> were using static DH certificates (see below). >> >> >> In line with Hugo's message earlier today, the major argument against >> this design is that it is more oriented towards a signature-based >> system, which TLS 1.3 is today, than towards a DH certificate-based >> system. To elaborate on this a bit, in a DH certificate-based system, >> the server authenticates by proving knowledge of g^xs (and hence >> s). In the current TLS 1.3 design you can do this trivially by >> replacing the signature in the server CertificateVerify with a MAC >> over the transcript (using g^xs as the key) [again, analysis needed.] >> This is straightforward and doesn't require rearchitecting the >> protocol really at all. However, this (as with the current >> signature-based mode) does not provide confidentiality of the >> connection if y is later revealed. >> >> As Hugo has noted several times, if you mix both g^xy and g^xs into >> the traffic keys, then you are protected if either y or s is leaked, >> which gives you somewhat stronger security properties with a DH >> cetificate The current key schedule accommodates that by allowing for >> SS to come before *or* after ES, but the simplified schedule does not >> quite so easily. >> >> With that said, TLS 1.3 doesn’t support *any* pure static DH design >> now and will do so even less well if we remove the key change as >> discussed above. There are at least three ways forward to incorporate >> them in future: >> >> - Just do as I suggest above. >> - Define a new DH cipher suite that adds an additional key change. >> This would allow us only to have the key change complexity in >> that mode. >> - Replace the 0 in the above schedule with g^xs and then define that >> the key for KeyUpdate is actually coming out of the final HKDF. >> >> Any of those seem like they wouldn’t be too hard to do, if and when >> we start having a lot of demand for DH certificates. >> >> Please discuss. >> >> -Ekr >> >> * Note that as I indicated in my previous message, it is possible to >> generate multiple sets of keys at the same stage, if that is necessary >> to handle the analysis concerns. >> >> >> >> >> >> >> >> _______________________________________________ >> TLS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> >> > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
