It's because of the rules in RFC8446. If the server doesn't utter an extension in HelloRetryRequest, the client is not allowed to change the corresponding ClientHello extension. We found an implementation which actually enforces this. https://github.com/tlswg/draft-ietf-tls-esni/issues/358
David On Tue, Aug 17, 2021 at 4:03 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > Hiya, > > (I'm just getting around to playing with draft-13 ECH and > HRR and have a question...) > > In 6.2 talking about GREASEd ECH, the draft says: > > If sending a second ClientHello in response to a > HelloRetryRequest, the client copies the entire > "encrypted_client_hello" extension from the first > ClientHello. The identical value will reveal to an > observer that the value of "encrypted_client_hello" was > fake, but this only occurs if there is a > HelloRetryRequest. > > I don't object to that, but can't recall why we wanted > the same value re-tx'd. (My code just naturally generated > a new GREASE ECH value and it all worked fine, so being > the lazy person I am, I'm wondering if doing nothing is > a good option:-) > > Ta, > S. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
