We plan to implement Encrypted Client Hello in NSS and Firefox, replacing t=
he current ESNI support. This work is being tracked in bug 1654332. Include=
d 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 a=
nd to reduce the extent to which real ECH handshakes stand out from regular=
Notable changes between ESNI and ECH include:
1) Rather than encrypting only SNI extension contents, ECH encrypts a compl=
ete Client Hello (CH) containing the secret SNI value and possibly other ex=
tensions. This encrypted CH is sent as an extension in an unencrypted (oute=
2) ECH now leverages Hybrid Public Key Encryption (see draft-irtf-cfrg-hpke=
-05) for deriving shared encryption keys from server and ephemeral client k=
ey pairs. The HPKE implementation is being developed in parallel under bug =
Server operators advertise their ECH (HPKE) public key via a special HTTPSS=
VC DNS record (see bug 1634793). Decryption failures and configuration mism=
atches are detected and resolved when the server responds to the unencrypte=
d =E2=80=9Couter=E2=80=9D CH, triggering retry steps on the client. Otherwi=
se, the decrypted inner CH is used as a basis for the TLS handshake. Furthe=
r details can be found in the linked drafts.
We are partnering with the Necko team and Cloudflare for this implementatio=
n 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*:=20
https://tools.ietf.org/html/draft-ietf-tls-esni-07 and https://tools.ietf.o=
*Estimated target release*:=20
None; prerelease-only currently.
Chromium work ongoing in https://bugs.chromium.org/p/chromium/issues/detail=
*Preference behind which this will be implemented*:=20
ECH will be implemented behind network.security.ech.enabled, replacing netw=
ork.security.esni.enabled. A separate pref may be added to independently co=
ntrol GREASE ECH.