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. This text is still a bit rough but I think shows the right direction. As usual, comments welcome, but I think the key question we need to resolve is whether we really need multiple PSKs. It's clearly simpler not to support them but it seems like we need to worry about the case where we are resuming a session created with a PSK. I've come to the conclusion that if we want to have multiple concurrent PSKs at all, then this is the right structure, rather than having one PSK and using HRR to fix it. ISTM that the other major alternatives are to say: 1. You can't resume sessions created with a PSK. 2. Tickets created in sessions created with a PSK have a hard lifetime value and it's a failure if the server forgets during the lifetime (this seems like it's going to interact badly with clock skew). Note that if we decide that we only want one PSK, I'll just revise the PreSharedKey section to have one, not a list [0]. Thanks, -Ekr [0] In fairness, it's also worth noting that if we decide to only have one, it's possible in the future to replace the PreSharedKey extension with a MultiplePreSharedKey extension.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
