We plan to implement Encrypted Client Hello in NSS and Firefox, replacing the current ESNI support. This work is being tracked in bug 1654332. Included is GREASE ECH, which sends a randomized ECH extension in non-ECH TLS 1.3 handshakes (see RFC 8701). The latter is intended to prevent ossification and to reduce the extent to which real ECH handshakes stand out from regular TLS traffic.
Notable changes between ESNI and ECH include:
1) Rather than encrypting only SNI extension contents, ECH encrypts a complete Client Hello (CH) containing the secret SNI value and possibly other extensions. This encrypted CH is sent as an extension in an unencrypted (outer) CH.
2) ECH now leverages Hybrid Public Key Encryption (see draft-irtf-cfrg-hpke-05) for deriving shared encryption keys from server and ephemeral client key pairs. The HPKE implementation is being developed in parallel under bug 1631890.
Server operators advertise their ECH (HPKE) public key via a special HTTPSSVC DNS record (see bug 1634793). Decryption failures and configuration mismatches are detected and resolved when the server responds to the unencrypted “outer” CH, triggering retry steps on the client. Otherwise, the decrypted inner CH is used as a basis for the TLS handshake. Further details can be found in the linked drafts.
We are partnering with the Necko team and Cloudflare for this implementation and will conduct an interoperability study for ECH handshakes in Nightly. We also may conduct a breakage study focusing only on GREASE ECH.
*Link to standards*:
*Estimated target release*:
None; prerelease-only currently.
Chromium work ongoing in https://bugs.chromium.org/p/chromium/issues/detail?id=1091403
*Preference behind which this will be implemented*:
ECH will be implemented behind network.security.ech.enabled, replacing network.security.esni.enabled. A separate pref may be added to independently control GREASE ECH.