An ECH key file can be valid for the wrong boundary

Summary

RFC 9934 can establish that a private key in a PEM file matches at least one public ECH configuration. It does not establish who approved that bundle for a particular DNS owner, client-facing server population, retry set, anonymity set or lifecycle window.
The missing control is not another copy of the key. It is a privacy-preserving policy-deployment receipt that joins the decoded configuration to the authorized DNS record, server cohort, ordinary and retry roles, overlap period, rollback decision and accountable approver without exposing private keys or a directory of protected names.

The green result is narrower than it looks

A file validator has an attractive answer to give. The delimiters are recognizable. The private key is valid PKCS #8. The ECHConfigList decodes. A public configuration in the list corresponds to the private key. Nothing is malformed. The result can be expressed as a green light.

That result matters. Before RFC 9934, different TLS libraries and servers could use different conventions for moving ECH key material from a key manager into a service. A common PEM form reduces needless conversion and makes interchange less dependent on one implementation. The standard says that an ECH PEM file contains zero or one private key and one encoded ECHConfigList. When the private key is present, the list must contain a matching ECHConfig. It also gives the public list a dedicated ECHCONFIG label and requires that the private component never be published in DNS.

But the green light answers a relationship question inside the file. It says that this private component can correspond to one public component. It does not say that the person who assembled the file had authority to choose the service boundary. It does not identify the DNS owner that should publish the list, the pool of servers that should receive the key, the names meant to share it, the subset that should appear in retry configurations, or the moment at which the old key can be retired.

This distinction is easy to miss because the artifact contains cryptography. A cryptographic match feels stronger than an ordinary configuration check, and within its stated scope it is. Yet stronger evidence about a small proposition does not become evidence about every decision around it. A signed receipt for a parcel does not decide which building was entitled to receive it. A matching key pair does not decide the privacy perimeter in which it should operate.

The operational question is therefore not “Is the file valid?” alone. It is “Valid for which approved deployment state?”

One file can contain several choices

RFC 9934 deliberately permits more than a single public configuration. An ECHConfigList can contain several ECHConfig values in decreasing order of preference. Those values can differ in extensions or public_name. A TLS server can also be configured with several filenames. The RFC notes that only a subset of those files may be selected for the retry_configs sent when ECH is rejected.

Each of those features is useful. Preference supports transition. Multiple values can accommodate protocol evolution. Several files can separate operational roles. A retry set can help clients recover from an advertised key that a server no longer accepts.

They also show why syntax is not policy. A file can be internally valid while the preference order is not the one that change control approved. Two valid files can be loaded into different nodes even though the deployment plan called for one common set. A valid configuration intended only for overlap can remain in the ordinary advertised set. Another intended for ordinary use can be omitted from the retry set. A list can contain a public_name that parses correctly but belongs to a different client-facing boundary from the one the service owner meant to operate.

The rule that trailing content should be ignored reinforces the point. The format does not make prose appended after the ECHConfigList into an authoritative deployment instruction. An operator cannot safely solve the governance gap by adding “for these servers until Friday” beneath the PEM object and assuming every parser, automation system and reviewer will treat that text as binding. The standardized object ends before the surrounding decision does.

The same limit applies to a raw file hash. RFC 7468 warns that textual encodings are not canonical. Whitespace, label treatment and encoding choices can yield different textual forms of the same decoded object. Conversely, an identical byte hash says nothing about whether the file was placed in the approved location or loaded by the approved process. Evidence should bind a specified canonical representation of the decoded list and then join that identity to the external deployment decision.

The privacy boundary is made by sharing, not by the label

RFC 9849 defines the fields that make the consequences visible. The public_name is the DNS name of the client-facing server, described as the entity trusted to update the ECH configuration. The one-byte config_id helps a server select candidate keys, but it is not a global identity. Values need not be unique across client-facing servers and may be reused after an old configuration leaves the known set.

Neither field is a certificate of institutional authority. A syntactically valid public_name tells a client what identity to authenticate in an ECH rejection path. It does not prove that a particular team was entitled to move a customer, domain group or server pool behind that name. A config_id helps an implementation find a key; it cannot carry the history of approval, scope and retirement in one byte.

More importantly, the client-facing configuration helps determine the anonymity set. RFC 9849 explains that separate ECHConfig values can make server names distinguishable, while sharing one configuration across more names can enlarge the set. This is not a cosmetic property. ECH is intended to protect the inner server name, yet the surrounding public information and the choice of configuration can still divide traffic into observable groups.

A file that passes its match check can therefore implement a privacy boundary that is narrower than intended. The private key is not wrong. The public key is not wrong. The mistake can live in the decision to allocate different configurations to names that were meant to be indistinguishable, or to combine names whose owners never approved a shared operational boundary.

There is no universal rule that the largest possible set is always correct. Sharing increases a privacy set, but it also expands the blast radius of key custody and operational change. Separate tenants may require different control, incident response or contractual boundaries. The accountable choice is not “always merge” or “always separate.” It is to make the chosen boundary explicit, authorized and testable.

DNS turns the file into a public promise

The file does not reach a client by itself. RFC 9848 defines the ech parameter in SVCB and HTTPS DNS records as the primary bootstrap path. The public ECHConfigList published there must correspond to the servers a client can reach.

The deployment requirement is concrete: when a record contains ech, every address selected by its TargetName must lead to a server that has the matching private key or is authoritative for the public name. If that join fails, connections can fail. A successful check on one machine does not prove coverage across the address cohort produced by the DNS decision.

RFC 9460 adds another layer. SVCB record sets are unordered, while SvcPriority expresses preference among ServiceMode records. AliasMode can move resolution to another name. Mandatory keys determine whether a client considers a record compatible. Address hints, alternative endpoints and incomplete responses can influence which candidate is attempted.

The privacy decision therefore spans at least two objects: the decoded ECHConfigList loaded by the client-facing servers and the DNS RRSet that advertises it. In many deployments it spans more: an alias chain, several priorities, multiple providers, Alt-Svc authorities and an evolving address pool.

RFC 9848 warns against a mixed set in which some records carry ECH and others do not. An intermediary may block the ECH-capable endpoints and induce use of a non-ECH alternative. It also requires ECH-capable clients to abandon ordinary optional fallback in specified circumstances, because fallback would erase the privacy benefit. Those rules are protocol defenses, but the operator still chooses the record set to which they apply.

A valid PEM file cannot report that another provider's pool lacks the key. It cannot prove that the DNS publication is the version approved by the domain owner. It cannot show that an Alt-Svc authority received a consistent ECH configuration. That evidence belongs to the deployment transaction.

Rotation is an interval, not a switch

Key replacement is often described as if a new file atomically displaced an old one. ECH does not live in that tidy instant. RFC 9849 says a server's known set should include the configurations currently published and previous values that clients may still use because DNS answers can be cached up to their TTL or longer.

This creates a period in which several states are legitimate at once. DNS may advertise the new configuration while servers retain the old private key for cached clients. Some nodes may have loaded the new file; others may still be converging. Retry configurations must carry up-to-date keys. A client that receives a retry configuration and is then rejected again has evidence of likely inconsistency, not merely bad luck.

Frequent rotation limits the exposure of a compromised key, but RFC 9849 notes that rotating too quickly can reduce the anonymity set accumulated around a configuration. Slow retirement supports cached clients, but it prolongs key custody and widens the compromise window. These are policy trade-offs expressed through time.

The file carries no activation timestamp, DNS publication proof, expected overlap, endpoint completion threshold or destruction receipt. Operators may keep all of those in a deployment system, and many mature systems do. The important point is that the file's validity cannot substitute for them.

A defensible rotation record needs to distinguish “old but intentionally accepted” from “old because one node was missed.” It needs to show when publication changed, what TTL and cache allowance governed overlap, when the endpoint cohort reached the required coverage, what retry set was active and who authorized retirement. Without that sequence, a later reviewer sees two valid files and cannot recover why either one was serving at a given moment.

What the file proves—and what it cannot

The scope can be stated without diminishing the standard.

The file can prove, when correctly parsed and validated, that its encoded structures meet the format and that a present private key matches at least one configuration. It can provide a portable unit to move compatible material between key management and TLS software. It can help prevent a simple class of mismatched-key errors.

The file cannot alone prove that:

the chosen public_name represents the approved client-facing authority;
the DNS owner authorized this ECHConfigList for this RRSet;
every address reachable through the selected TargetName has the needed key;
the preference order and ordinary-versus-retry subset match policy;
all names intended to share an anonymity set use the same approved configuration;
names that must remain separate were not combined;
the old configuration remains only for a justified cache-overlap window;
mixed ECH and non-ECH alternatives have been reviewed;
an exception has an owner, expiry, rollback target and correction path.

These are not cryptographic defects. They are facts of authorization, distribution and time. Trying to force them into the private-key file would also be dangerous: the file is highly sensitive, while some deployment evidence must be inspectable by people or systems that should never receive the key.

A policy-deployment receipt without a privacy dossier

The appropriate companion is a receipt that identifies the decision without copying its secrets.

Start with a canonical digest of the decoded ECHConfigList and a result showing whether the private key matches. Do not store the private key or a reversible representation of it. Record the intended public_name, configuration identifiers and the approved role of each list member: ordinary, retry, overlap or retired.

Bind that object to a canonical digest of the relevant DNS RRSet, together with its owner, RR type, mode, TargetName, SvcPriority and the presence of mandatory parameters. For a multi-provider path, preserve the chosen alias and provider boundary. Record a coarse digest of the expected endpoint cohort and a coverage result, not a publicly readable inventory of addresses.

Time needs its own fields: approval, key generation, server activation, DNS publication, overlap start, earliest safe retirement, actual retirement and destruction confirmation. The calculation should cite the governing TTL and any explicit allowance for clients that cache longer. A test should confirm that ordinary and retry sets match the approved state and that repeated retry is not occurring above the chosen threshold.

The anonymity-set decision must be reviewable without publishing every protected name. A receipt can carry the policy version, a bucketed count or range, tenant-separation class and a statement of which change threshold requires renewed approval. Independent testing can use controlled names rather than a customer directory.

Finally, record who approved the change, which authority they exercised, the exception and expiry if any, the rollback target, evaluator version and correction state. A receipt that cannot be corrected will turn an early mistake into false institutional memory.

This design follows a simple boundary: evidence about the decision should be accessible to the reviewer; the private key and the protected population should not be. ECH should not gain an audit system that recreates the browsing and hosting map it exists to conceal.

Evidence limits

The RFCs establish protocol behavior, not a story about one operator. They do not show that a named service loaded the wrong file, split an anonymity set, leaked a key or suffered a downgrade. No adoption rate, failure rate, anonymity-set measurement or legal conclusion follows from them.

Nor is the proposed receipt an IETF requirement. It is an editorial control derived from the gap between a portable object and the larger institutional decision. A deployment that already preserves equivalent evidence in a key manager, DNS change system and server inventory may not need a new store. It still needs to show that the evidence can be joined.

The practical conclusion is narrow. Validate the file. Protect it like a server private key. Then resist the temptation to describe that validation as proof of the privacy boundary. The boundary is made where the file meets DNS authority, endpoint coverage, name sharing and time.

A Valid ECH Key File Does Not Prove the Right Privacy Boundary

Why it matters

Summary

The green result is narrower than it looks

One file can contain several choices

The privacy boundary is made by sharing, not by the label

DNS turns the file into a public promise

Rotation is an interval, not a switch

What the file proves—and what it cannot

A policy-deployment receipt without a privacy dossier

Evidence limits

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing