On Fri, Feb 19, 2016 at 07:14:44AM -0700, Eric Rescorla wrote: > On Fri, Feb 19, 2016 at 2:12 AM, Karthikeyan Bhargavan < > karthik.bharga...@gmail.com> 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.
To be clear, RMS needs to include some data in "flight 3", so the most straightforward is to take the hash to be ClientHello1...ClientFinished. EMS needs to be secret and nonce versus ES and SS (otherwise you can get Triple-Handshake-style attacks). And one can compute such values immediately after ServerHello in main modes. However, given that some more "exotic" modes might have attacks all the way into ClientFinished, it would be good idea to take the EMS hash to ClientFinished too. Taking EMS to ClientFinished would prevent server from computing authenticators immediately after getting into application data, but usually those kinds of authenticators are used client-first so it won't matter much. And authentication TBS need to be nonce versus ES and SS. TBS failing to be nonce with SS is what led to Cremers attack. Also, where things can also get scary is server authentication. Whereas with client auth, the TBS should become nonce versus SS via Server- Finished, there is nothing corresponding for server authentication (this is not problem in GDHE-CERT w/o Config because SS=ES, and TBS is nonce versus ES). There are some subtle caveats tho: In practicular, the HKDF salt needs to be constant-length or one can obtain trivial collisions in HKDF. So one can't feed raw SS as salt (but must extract it first). > 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. There's question about if to use ES+SS or just SS. One of those might make proofs of some kind easier, dunno. > > > > 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. I don't find it prohibitively hard (or even hard) to analyze unless you get thigns like configurations or future modes involved. (And I think one would get similar problems before the simplication too). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
