On 9/30/20 17:34, Benjamin Kaduk wrote:
The HRR is presumed to be a deterministic function of the initial ClientHello, and as I discussed in my earlier message, the server can reconstruct the initial ClientHello from the second ClientHello and verify it against the hash in the cookie.
I don't believe you can reliably always reconstruct the initial ClientHello1 from ClientHello2. Maybe current TLS 1.3 clients are sending simple enough ClientHello messages so this is possible today, but what about next week, next year, etc.? RFC 8446 lists on pages 27-28 all of the ways the client is supposed to (or allowed to) change the ClientHello that gets returned after a HelloRetryRequest: - If a "key_share" extension was supplied in the HelloRetryRequest, replacing the list of shares with a list containing a single KeyShareEntry from the indicated group. - Removing the "early_data" extension (Section 4.2.10) if one was present. Early data is not permitted after a HelloRetryRequest. - Including a "cookie" extension if one was provided in the HelloRetryRequest. - Updating the "pre_shared_key" extension if present by recomputing the "obfuscated_ticket_age" and binder values and (optionally) removing any PSKs which are incompatible with the server's indicated cipher suite. - Optionally adding, removing, or changing the length of the "padding" extension [RFC7685]. - Other modifications that may be allowed by an extension defined in the future and present in the HelloRetryRequest. The only way stateless HRR could work (I think) is if you sent the entire ClientHello1 and HelloRetryRequest-minus-cookie encoded in the cookie somehow, encrypted, integrity-protected. But a hash of ClientHello1 by itself just won't do. Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
