1725938 - (ech) [meta] ECH

Status: ASSIGNED

(NSS :: Libraries, enhancement, P3)

Description

[Dennis Jackson]

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

Comment 1

[Dennis Jackson]

Attachment: Bug 1725938 - Stricter ClientHelloInner Decompression. r=mt.

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.

Comment 2

[Dennis Jackson]

Attachment: Bug 1725938 - Update generation of the Associated Data for ECH-13 r=mt

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.

Comment 3

[Dennis Jackson]

Attachment: Bug 1725938 - Update the version number for ECH-13 and adjust the ECHConfig size. r=mt

TODO: Regenerate the disabled tests.

Comment 4

[Dennis Jackson]

Attachment: WIP: Bug 1725938 - Remove ECH_inner extension, use new enum format.

Depends on D125697

Comment 5

[Dennis Jackson]

Attachment: Bug 1725938 - Remove ECH_inner extension, use new enum format. r=mt

Depends on D125697

Comment 6

[Dennis Jackson]

Attachment: Bug 1725938 - Tidy up error handling r=mt

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

Depends on D130696

Comment 7

[Dennis Jackson]

Attachment: Bug 1725938 - Update tests for ECH-13. r=mt

• 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

Comment 8

[Dennis Jackson]

Attachment: WIP: Bug 1725938: Add a script for testing ECH Interoperability

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

Depends on D130699

Comment 9

[Dennis Jackson]

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

Comment 11

[celexi]

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.

Comment 12

[[:estemal]]

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?

Comment 13

[BB_C]

(In reply to celexi from comment #11)

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

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.

Seconded.

1. The claim that DoH is required to get a DNS HTTPS record response is wrong and trivially disprovable:

   % dig '@8.8.8.8' +noall +answer -t HTTPS  cloudflare.com
   cloudflare.com.         300     IN      HTTPS   1 . alpn="h3,h2" ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5
   

   (same response with 1.1.1.1 or 9.9.9.9 or ...)

2. For unaware users with no encrypted system-wide DNS, using a custom DoH resolver will require bootstrapping, which will both leak the resolver domain request, and rely on the unencrypted response. So a security argument for the DoH requirement would also be 100% bogus.

3. For the aware users, this requirement locks them out of their system DNS setup, which may for example rely on quic quick resolvers (not a typo, I meant resolvers using the quic protocol directly without HTTP/3).

If the DoH requirement stays for faux security, there should be at least a non-default option to remove that requirement.

Comment 14

[Frank]

Hello, recently Cloudflare enabled ECH in all free plans. Unfortunately it was later blocked by the Russian DPI.

What's interesting, is that connection are being established after ~1 minute without ECH, whereas in the IETF documentation it clearly states:

Unless ECH is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to using unencrypted ClientHellos, as this allows a network attacker to disclose the contents of this ClientHello, including the SNI. It MAY attempt to use another server from the DNS results, if one is provided.

Is this on purpose? Thanks.

Comment 15

[Frank]

Behaviour is that the DPI "freezes" the connection, all subsequent packets are dropped after prohibited connection is detected, instead of tearing it down or sending TLS alert, or anything more appropriate.