Deployment considerations

This section explores ECH deployment considerations. Relevant links to additional sections will be provided, detailing potential attacks against the protocols.

Process Overview

The following is a streamlined overview of the workflow involved when a browser accesses an ECH-protected website. The blue arrows signify the client-side process, while the green ones are the server-side process.

WKECH flow

Client-side Process

To initiate a website request, the browser first queries the A/AAAA records and the ECHConfig from the configured DNS server. This server may be a recursive DNS server provided by the network operator or a central DoH server.
The designated DNS server then queries the authoritative DNS server for the required information, which is managed by the website operator.
Once retrieved, the information is relayed from the authoritative DNS server to the DNS server, potentially being cached for future requests by this or other clients.
The DNS server subsequently transmits the information to the client.
Utilizing the A/AAAA records and the ECHConfig, the browser sends an HTTP request to the web server to fetch the website.

Typically, recursive DNS servers communicate with authoritative DNS servers using traditional unencrypted UDP-based DNS (Do53). Nonetheless, the adoption of DoT and DoH protocols is on the rise. Additionally, various protocol upgrades (either opportunistic or through SVCB records) are possible.

Server-side Process

The server regularly regenerates the ECH keys at defined intervals (for example, every hour) for each configured domain.
The server publishes the corresponding public ECH keys within the WKECH directories for every domain.
The Zone Factory (ZF) requests the ECH keys for each designated domain at pre-established intervals (preferably more frequent than once per hour).
The Client-Facing Server (CFS) responds with the requested ECH keys.
The ZF subsequently pushes the generated ECHConfig to the DNS server.

Webserver configuration

On the webserver side, several considerations must be addressed:

Which component generates the ECH keys with the appropriate parameters?
Which entity handles the rotation of these keys and reloads the web server configuration?
What component creates (or services) the WKECH directory, ensuring only public keys are exposed and private keys remain secure?
How is the ZF triggered after each key rotation, ideally operating separately on a different host? (see Separation).

There are similarities between the ACME protocols (made popular by the Letsencrypt initiative) and ECH, as both generate keys on the webserver and write information to the DNS zone. ECH adds the additional WKECH, see also WKECH for possible problems related to it.

To facilitate the ECH deployment, straightforward and easy tools, covering these processes, akin to ACME clients or Apache's mod_md¹ need to be developed.

Guidance on setting up webservers with ECH, can be found in the ECH Development utilities².

Complexity of Configuring the Zone Factory

The Zone Factory must be aware of the following:

Identifying well-known sites (wkech) to monitor.
Establishing a refresh schedule for the keys (either on a fixed interval or responsive to activity).
Knowing which zone files on which servers require updates.

The ZF requires write access to the zone files and must have the capability to reload the nameserver configuration. This setup is non-trivial for a systems administrator, as misconfigurations or oversights can introduce complications.

It is imperative to secure the WKECH directory: it must contain only public keys, be immutable (including to any aliases), and limit access solely to the web server itself. For more information, please refer to the section on WKECH.

DNSSEC implementation

DNSSEC (Domain Name System Security Extensions) implementation enables clients to validate ECH-enabled domains. This not only enhances the integrity of the DNS responses but also mitigates the risk of resolvers inadvertently blocking SVCB or ECH parameters.