Summary

  • RFC 9934 defines a portable PEM file with zero or one PKCS #8 private key followed by one ECHConfigList; when the secret is present, one listed public configuration must match it.
  • That match is local evidence. ECH also depends on the server's active key set, the public DNS value, client cache age, acceptance or retry in a live handshake and the privacy properties of the surrounding deployment.

The rotation review had three green marks. A key generator had emitted a new private key. A file validator had found the matching public key inside an ECHConfigList. The authoritative zone had an HTTPS record carrying an ech value. Then a sampled client offered an older configuration and the server returned retry configurations.

Nothing in that sequence required a broken cryptographic primitive. The file, DNS and client cache were reporting different generations of a state that operators had compressed into one label: “ECH enabled.”

RFC 9934 solves a real interoperability problem. ECH servers may use different TLS libraries, while their key managers still need a common way to deliver the public configurations and associated secret material. The RFC therefore borrows the textual-envelope discipline of RFC 7468 and gives ECH its own small file contract.

The cardinality matters. An ECH PEM file contains zero or one private key and one encoded ECHConfigList. If a private key is present, it comes first, uses the PRIVATE KEY label and carries a PKCS #8 PrivateKey. The public block follows, uses the ECHCONFIG delimiter and contains the base64 representation of the same ECHConfigList value that can be placed in an HTTPS resource record. If the file contains a private key, at least one ECHConfig in that list must match it. Content after the list should be ignored.

Those rules answer a precise question: can two implementations exchange a file whose intended blocks and relationship are unambiguous? They do not answer which process read it, whether a reload occurred, which of several configured files became active, or which list a deployment chose for retry_configs.

The zero-private-key case is especially useful for keeping the evidence honest. RFC 9934 permits a file that carries only the public list. It also says the private key from a secret-bearing file must never be published in DNS. Public distribution and secret installation are deliberately different actions. A pipeline that treats the public export and the server import as one undifferentiated artifact either risks leaking the secret or loses the ability to prove which public projection corresponds to which protected key.

Multiple values add another layer. An ECHConfigList may include several configurations with different extensions or public_name values, ordered by decreasing preference. A server can be configured with multiple filenames and can use only a subset of their lists for retry. The in-file matching rule requires one suitable public member for a present private key. It does not certify that every advertised member has a usable secret in the active process.

RFC 9849 makes the temporal problem explicit. A client-facing server should retain currently published configurations and previous values that clients may still hold for a DNS TTL or longer. If it can decrypt the encrypted inner ClientHello, ECH may be accepted and the inner handshake proceeds. If it cannot, it processes the outer ClientHello, rejects ECH and can return up-to-date retry configurations. The client, not the file validator, determines whether acceptance occurred; a rejected connection is not usable for application data.

Rotation therefore has at least six clocks: key generation, secret-bearing file installation, server load, authoritative DNS publication, recursive cache expiry and client retry state. “Replace key at midnight” is not a control until the owner can state the safe order, overlap and rollback rule for all six. Removing an old private key at the same instant that an authoritative record changes may strand clients legitimately holding the old list. Keeping every key indefinitely widens custody and trial-decryption cost.

The monitoring record should preserve joins rather than a final boolean. Store the generated key's non-secret identifier; the exact file hash; parser, cardinality and match results; filesystem access evidence; deployment and reload acknowledgements; the server's active known-config hashes; the authoritative HTTPS/SVCB RRSet; observations from selected recursive paths with TTL age; the client's chosen config_id; ECH offer, acceptance or rejection; retry-config hash; certificate validation; Finished result; and the later application observation. Never copy the private key into the audit trail.

RFC 9848 prevents a second inflation of meaning. An ech parameter in DNS is not a universal privacy receipt. A mixed RRSet with ECH and non-ECH endpoints can be downgraded by selective blocking. Plaintext DNS, a distinctive IP address, traffic analysis and a small anonymity set can still reveal or narrow the destination. RFC 9460 standardises the service-binding surface; it does not observe the server's secret or the client's handshake.

Heng Lu's Running-Code Primacy gives each witness the right size. The file parser can attest to bytes and an in-file match. The server can attest to its loaded key set. DNS authorities and resolvers can attest to their respective views. A client transcript can attest to offer and acceptance. An application probe can attest to a later result. None is diminished by refusing to speak for the others.

The Minimum Initial Specification principle explains why RFC 9934 should remain small. A common format enables independent libraries and operators to interoperate. It need not impose one universal key manager, TTL, reload mechanism or privacy policy. Those later decisions belong to the people operating the local system — but so does the duty to make their consequences observable.

The executive closeout question is not “does the file validate?” It is: which public configuration was exposed to which client population, which protected key was live when they used it, what did the handshake decide, and which observer can prove the privacy claim being made?

Sources