Re: [TLS] HelloRetryRequest question (was Re: TLS 1.3 Problem?)

[Michael D'Errico <[e-mail]>]

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