(cannot comment, not enough rep)

Regarding your last point, it is impossible to compute a hash of the HRR and to store that inside inside a cookie, as changing the cookie would change the HRR and the client would compute a different HRR hash than the one stored inside the cookie. Leaving the client and server with different transcripts...

Like you, I don't understand how that construction makes it possible for the HRR to be stateless. I don't even understand what's the added security of keeping the ClientHello1 and HelloRetryRequest inside the transcript-hash instead of "simply" starting anew with ClientHello2.

The RFC is explicit that the transcript-hash shouldn't be reset but there is no explanation why

From section 2.1

Note: The handshake transcript incorporates the initial ClientHello/HelloRetryRequest exchange; it is not reset with the new ClientHello.

I guess we have to implement that silly construction and get none of its advertised benefits...

Regarding your last point, it is impossible to compute a hash of the HRR and to store that inside a cookie, as changing the cookie would change the HRR and the client would compute a different HRR hash than the one stored inside the cookie. Leaving the client and server with different transcripts...

Like you, I don't understand how that construction makes it possible for the HRR to be stateless. I don't even understand what the added security of keeping the ClientHello1 and HelloRetryRequest inside the transcript-hash instead of "simply" starting anew with ClientHello2.

The RFC is explicit that the transcript-hash shouldn't be reset but there is no explanation why

From section 2.1

Note: The handshake transcript incorporates the initial ClientHello/HelloRetryRequest exchange; it is not reset with the new ClientHello.

I guess we have to implement that silly construction and get none of its advertised benefits...

(cannot comment, not enough rep)

Regarding your last point, it is impossible to compute a hash of the HRR and to store that inside inside a cookie, as changing the cookie would change the HRR and the client would compute a different HRR hash than the one stored inside the cookie.

Like you, I don't understand how that construction makes it possible for the HRR to be stateless. I don't even understand what's the added security of keeping the ClientHello1 and HelloRetryRequest inside the transcript-hash instead of "simply" starting anew with ClientHello2.

The RFC is explicit that the transcript-hash shouldn't be reset but there is no explanation why

From section 2.1

Note: The handshake transcript incorporates the initial ClientHello/HelloRetryRequest exchange; it is not reset with the new ClientHello.

I guess we have to implement that silly construction and get none of its advertised benefits...

(cannot comment, not enough rep)

Regarding your last point, it is impossible to compute a hash of the HRR and to store that inside inside a cookie, as changing the cookie would change the HRR and the client would compute a different HRR hash than the one stored inside the cookie. Leaving the client and server with different transcripts...

Like you, I don't understand how that construction makes it possible for the HRR to be stateless. I don't even understand what's the added security of keeping the ClientHello1 and HelloRetryRequest inside the transcript-hash instead of "simply" starting anew with ClientHello2.

The RFC is explicit that the transcript-hash shouldn't be reset but there is no explanation why

From section 2.1

Note: The handshake transcript incorporates the initial ClientHello/HelloRetryRequest exchange; it is not reset with the new ClientHello.

I guess we have to implement that silly construction and get none of its advertised benefits...