Thanks David. Cheers, S.
On 17/08/2021 21:15, David Benjamin wrote:
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
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
