On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > After the discussion on PR #615, I took another pass at this with some > help from the research community. Please see: > > https://github.com/tlswg/tls13-spec/pull/672 > > > Key changes in this PR: > > 1. I have merged the HMAC into the PreSharedKey message, where it is > now called "PSK Binder" to make very clear what the purpose of the > HMAC it is (this suggestion due to Karthik Bhargavan) This also makes > implementation somewhat easier and avoids creating another extension. > > 2. It is now possible to have >1 PSK, each with its own binder. > > 3. The binder is now computed over the ClientHello prefix rather than > filling the MAC with zeroes. > > 4. I've taken a suggestion from David Benjamin to move the negotiation > of the PSK key exchange parameters out of the PSK itself and into a > separate message. This cleans things up and also lets us drop the > currently non-useful auth_mode parameter.
Eeh... From the text, it seems to currently require the kex modes extension if PSK extension is present. Which seems worse than useless if the meaning is to get rid of the kex mode parameter from PSK extension (since you will have the value anyway, but need to dig it from another extension... Blech). > This text is still a bit rough but I think shows the right direction. I would talk about PSKs established by NST, not resumption PSKs. Also, didn't notice what prevents pathology like this (I presume this is not allowed): (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256) ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] ---> [0-RTT data, encrypted using AES-128-GCM-SHA256] <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256] <-- EncryptedExtensions[EarlyDataIndication] Note the record protection algorithm mismatch. Also, to straightforwardly prove that collision resistance of HKDF and HMAC (as used) follows from collision resistance of the underlying hash function, yon need to take the output to be at least the hash output size. As otherwise it is not guaranteed that any collision in HKDF or HMAC can be reduced into collision of the underlying hash. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
