> 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. > 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. > 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) > 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. 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 :-) > > 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. > > > On Thu, Feb 18, 2016 at 4:05 PM, Eric Rescorla <[email protected] > <mailto:[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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/tls > <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
