Changes between ECH Draft 10 and Draft 13.

• During ClientHelloInner Decompression, duplicate extensions must be rejected.
• ClientHello padding is moved from the record layer to a dedicated field.
• HRR now has an explicit confirmation value (which should be checked and GREASEd)
• Changes to ClientHelloOuterAAD Generation
• Requirements for dummy PSKs and early_data in ClientHelloOuters
• ECHConfig format changes
• Codepoint changes

Decompression is now a linear scan, ensuring the same CHO extension
is never considered for inclusion more than once. The added tests
check that duplicate or out of order references are now rejected.

This change simplifies the AAD generation for the ECH Xtn's payload in Client Hellos.
The AAD is now composed of the entire ClientHelloOuter, with the ECH Xtn payload replaced
with zeroes.

TODO: Regenerate the disabled tests.

Depends on D125697

Depends on D125697

Small commit to tidy up the error handling when receiving ECH extensions.

Depends on D130696

• Add a new test helper function for creating an ECH Config/
• Update ECH Config tests to dynamically generate their configs.
• Regenerate tests using fixed ClientHello configs for ECH-13.
• Add test for recursive ECH Outer Extensions.
• Add test for ECH Inner Extension with payload (should be empty).
• Add test to ensure AAD covers both before and after ECH extension.

Depends on D130697

The included python3 script uses drill and tstclnt to test NSS against other ECH
server implementations.

Depends on D130699

https://hg.mozilla.org/projects/nss/rev/9e1a409b15d30475b8c8e04e242c63c493e0681e
https://hg.mozilla.org/projects/nss/rev/e31c41c04527750434f9f9180b4eb53d50243eea
https://hg.mozilla.org/projects/nss/rev/6fbfdbf1fe9d989f9d083cf7e0634a2c905dc067
https://hg.mozilla.org/projects/nss/rev/6da26e8be8c5aba0a503106a159b8d860151b3e5
https://hg.mozilla.org/projects/nss/rev/dbfeabc22622b027459e3cfd256a3cf7e8ce0fc8
https://hg.mozilla.org/projects/nss/rev/ea27fc06556ad8203425bce244b90ff003b75af5

I came across the intent to implement post, but I saw this:

ECH support also requires a DoH server to be configured in Firefox (either from the default list or a custom self-hosted server). This is because >ECH depends on a special type of DNS record and is only effective if these DNS records are fetched over an encrypted connection. ECH respects >all existing DoH opt outs (canary, pref, enterprise policy) and ECH will not be used to encrypt any ClientHellos if DoH is disabled or opted out.

but the spec does not require it

10.2. Unauthenticated and Plaintext DNS

In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource
Records are signed via a server private key, ECH records have no
authenticity or provenance information. This means that any attacker
which can inject DNS responses or poison DNS caches, which is a
common scenario in client access networks, can supply clients with
fake ECH records (so that the client encrypts data to them) or strip
the ECH record from the response. However, in the face of an
attacker that controls DNS, no encryption scheme can work because the
attacker can replace the IP address, thus blocking client
connections, or substitute a unique IP address which is 1:1 with the
DNS name that was looked up (modulo DNS wildcards). Thus, allowing
the ECH records in the clear does not make the situation
significantly worse.

Rescorla, et al. Expires 8 October 2023 [Page 30]
Internet-Draft TLS Encrypted Client Hello April 2023

Clearly, DNSSEC (if the client validates and hard fails) is a defense
against this form of attack, but DoH/DPRIVE are also defenses against
DNS attacks by attackers on the local network, which is a common case
where ClientHello and SNI encryption are desired. Moreover, as noted
in the introduction, SNI encryption is less useful without encryption
of DNS queries in transit via DoH or DPRIVE mechanisms.

Requiring it will mean that users using local network DNS without DOH/tls will have their requests sent in clear for no reason as you'd be assuming if their locally configured dns server is not forwarding via doh/tls wrongly if it happens to be.

While bug1804460 is closed, there are still no devtools info about ECH as of firefox 119, the patch is marked as "Changes Planned". Is there a plan to add it?