Open Bug 1725938 (ech) Opened 3 years ago Updated 11 days ago

[meta] ECH

Categories

(NSS :: Libraries, enhancement, P3)

enhancement

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: djackson, Assigned: djackson)

References

(Depends on 10 open bugs, Blocks 1 open bug)

Details

(Keywords: meta, Whiteboard: [nss-fx][nss-meta])

Attachments

(7 files, 1 obsolete file)

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
Depends on: 1712879
Severity: -- → N/A
Priority: -- → P1
Summary: ECH -13 updates → [meta] TLS 1.3 ECH draft -13 updates
Whiteboard: nss-fx → [nss-fx][nss-meta]

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.

Depends on: 1677181
Depends on: 1728281

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

Attachment #9241357 - Attachment is obsolete: true
Attachment #9239654 - Attachment description: WIP: Bug 1725938 - Update generation of ECH Xtn AAD → WIP: Bug 1725938 - Update generation of the Associated Data for ECH-13
Attachment #9239654 - Attachment description: WIP: Bug 1725938 - Update generation of the Associated Data for ECH-13 → Bug 1725938 - Update generation of the Associated Data for ECH-13
Attachment #9241361 - Attachment description: WIP: Bug 1725938 - Remove ECH_inner extension, use new enum format. → Bug 1725938 - Remove ECH_inner extension, use new enum format.
Attachment #9236489 - Attachment description: WIP: Bug 1725938 - Stricter ClientHelloInner Decompression → Bug 1725938 - Stricter ClientHelloInner Decompression
Attachment #9241356 - Attachment description: WIP: Bug 1725938 - Update the version number for ECH-13 and adjust the ECHConfig size → Bug 1725938 - Update the version number for ECH-13 and adjust the ECHConfig size. r=mt
Attachment #9241361 - Attachment description: Bug 1725938 - Remove ECH_inner extension, use new enum format. → Bug 1725938 - Remove ECH_inner extension, use new enum format. r=mt
Attachment #9236489 - Attachment description: Bug 1725938 - Stricter ClientHelloInner Decompression → Bug 1725938 - Stricter ClientHelloInner Decompression. r=mt.
Attachment #9239654 - Attachment description: Bug 1725938 - Update generation of the Associated Data for ECH-13 → Bug 1725938 - Update generation of the Associated Data for ECH-13 r=mt

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

Depends on: 1742568
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Depends on: 1748469
Depends on: 1749869
Status: REOPENED → ASSIGNED
Depends on: 1751877
Depends on: 1755904
Depends on: 1756127
Depends on: 1756485
Depends on: 1759525
Depends on: 1760809
Depends on: 1763120
Summary: [meta] TLS 1.3 ECH draft -13 updates → [meta] ECH
Depends on: 1765590
Depends on: 1767974
Depends on: 1773965
Depends on: 1774001
Depends on: 1771479
Depends on: 1779370
Depends on: 1779361
Depends on: 1779357
Depends on: 1779234
Depends on: 1771100
Depends on: 1780807
Depends on: 1781224
Depends on: 1788924
No longer depends on: 1788924
Depends on: 1789381
No longer depends on: 1789381
Depends on: 1789410
Depends on: 1790357
Depends on: 1790801
Depends on: 1804460
Depends on: 1816952
No longer depends on: 1816952
Depends on: 1817185
Depends on: 1822876
Depends on: 1822877
Depends on: 1500289
Duplicate of this bug: 1590863
Depends on: 1824578
See Also: 1590863
Priority: P1 → P3
Depends on: 1828861
Depends on: 1847589
Depends on: 1847804
Alias: ech
Depends on: 1850248
Depends on: 1535235

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.

Depends on: 1856928

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?

Depends on: 1869753
Depends on: 1876732
Depends on: 1841029
Depends on: 1891470
Depends on: 1891483

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

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: