Hi all, Nick noticed a fun (almost?) conflict between DTLS 1.3 PSK binders and DTLS 1.2 HelloVerifyRequest:
A DTLS 1.2+1.3 client, in possession of a DTLS 1.3 PSK, will send a ClientHello with a PSK binder. The server, however, may have since rolled back DTLS 1.3 support and then might negotiate DTLS 1.2 and then respond with a HelloVerifyRequest (not HelloRetryRequest). The client would then resend the ClientHello with a new legacy_cookie value, as it's expected to. Now, a natural implementation would then recompute the PSK binder. It doesn't strictly need to, because HelloVerifyRequest is forbidden in DTLS 1.3, so the client is already not going to accept a 1.3 ServerHello. But it is simpler to recompute it, so you don't need to stash the old value (or include logic to serialize a special cookie-less ClientHello). The question is whether this is allowed by spec and in practice, or will a DTLS 1.2 server bind the *whole extension list* into its cookie. RFC 6347, Section 4.2.1 says the following: When responding to a HelloVerifyRequest, the client MUST use the same parameter values (version, random, session_id, cipher_suites, compression_method) as it did in the original ClientHello. It's unclear whether that list is a set of examples or the complete list of parameters. After all, quite a lot of ClientHello parameters are in the extensions list. On the other hand, given that DTLS 1.2 doesn't have a key share in here, it's a little unclear to me what benefit there is in binding anything other than the random value into this cookie. (Unless the server takes any extensions into account when deciding whether to send a cookie?) Are there any DTLS 1.2 implementations that bind the whole ClientHello? At a glance, it looks like OpenSSL does not bind any part of the ClientHello, and BoringSSL and NSS never generate DTLS 1.2 cookies in the first place. My inclination is to say that refreshing the PSK value is fine. The spec doesn't say you have to keep the extension list fixed, and this'll only be a problem if you have an extension-binding DTLS 1.2 server, deploy DTLS 1.3, mint some tickets, and then roll back DTLS 1.3. And then single-use tickets (if you implement them) will eventually repair it anyway. Thoughts? David
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
