Closed Bug 1779357 Opened 2 years ago Closed 2 years ago

ECH rejection in HRR - unspecified client behavior

Categories

(NSS :: Libraries, defect, P1)

3.80

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: lschwarz, Assigned: lschwarz)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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).

Blocks: ech

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(bbeurdouche)
Severity: -- → S4
Flags: needinfo?(bbeurdouche)
Priority: -- → P1
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: