If NSS client offered ECH but it is correctly rejected in a server's HRR ECH extension, NSS client offers 'real' ECH in CH2 and only after receiving SH and completing the handshake (with successful verification) does it send an 'ech_required' alert in tls13_FinishHandshake(), following draft-ietf-tls-esni-14, Section 6.1.6 which might only refer to handling ECH extension within the EncryptedExtensions message.

However, to my knowledge it is not specified if the client should send CH2 or alert immediately and if it should send CH2, if it is supposed to offer 'real' ECH again even though it was formally rejected by the server.

In the BoringSSL test (bogo) "TLS-ECH-Client-Reject-RandomHRRExtension" an immediate 'ech_required' alert is expected after receiving HRR with valid ECH 'rejection' extension (test is disabled currently).

Depends on D151692

The severity field is not set for this bug.
:beurdouche, could you have a look please?

For more information, please visit auto_nag documentation.

https://hg.mozilla.org/projects/nss/rev/d88b18cd99b07029901c52364f0ac1aeba195668