Trinity College Dublin

Dublin 2 Ireland +353-1-896-2354 stephen.farrell@cs.tcd.ie

Akamai Technologies

rsalz@akamai.com

Meta Platforms, Inc.

ietf@bemasc.net

Security Area TLS TLS ECH We define a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about its Service Bindings. The data can include Encrypted ClientHello (ECH) configurations, allowing the origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. The source for this draft is in Issues and PRs are welcome there too.

Encrypted ClientHello (ECH) for TLS1.3 defines a confidentiality mechanism for server names and other ClientHello content in TLS. The Service Bindings (SVCB) in DNS RFC defines how to handle information needed to make connections to services by using a new DNS record set (RRset). The document defines an entry in that RRset for Encrypted Client Hello (ECH) configuration information. Many applications will require publication of SVCB data, such as a list of ECHConfig values, in the DNS. Each ECHConfig value contains the public component of a key pair that will typically be periodically (re-)generated by a web server. Many web infrastructures will have an API that can be used to dynamically update the DNS RRset to contain the current list of ECHConfig data, known as an ECHConfigList. Some deployments, however, will not, and those deployments could benefit from the mechanism defined here. Note that this protocol is not intended for universal deployment, but rather for cases where the web server doesn't have write access to the relevant zone file (or equivalent). This document uses the ECH data to provide a concrete motivating example. The mechanism defined here is extensible so can be used to deliver other kinds of information about the origin, intended to be published in HTTPS RRs. We use the term "zone factory" (ZF) for the entity that does have write access to the zone file. We assume the ZF can also make HTTPS requests to the web server with the ECH keys. We define a well-known URI on the web server that allows the ZF to poll for changes to ECHConfigList values. For example, if a web server generates new ECHConfigList values hourly and publishes those at the well-known URI, the ZF can poll that URI. When the ZF sees new values, it can check if those work, and if they do, then update the zone file and re-publish the zone. If ECH is being operated in split-mode then the web server (backend) can similarly poll the ECH client-facing server at the well-known URI and then create its own value to publish for the ZF to read. ECH split-mode is defined in and an example is provided below.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. We define or re-use the following terms:

Zone factory (ZF):

an entity that has write-access to the DNS

Client-Facing Server (CFS):

the web server that has an ECH private value. This processes the outer ClientHello and attempts ECH decryption. The name of client-facing server will typically be the public_name value used in an ECHConfig.

Backend:

the web server that will process the inner ClientHello. Note that even if client-facing server and backend are on the same web server, they almost certainly have different DNS names.

Shared-mode:

this is where client-facing and backend servers are the same web server.

Split-mode:

this refers to the case where the client-facing server only does ECH decryption but the TLS session is between the client and backend, which will typically be on a different host to client-facing server

regeninterval:

the number of seconds after which the value retrieved after acessing a well-known URI may be changed.

Some example deployments are described here.

| | facing | cfs.example.com | server | backend.example.com| +--------------------+ ^ ^ (1) ZF reads | | (2) ZF checks .well-known V V ECHConfig +--------------------+ | | | zf.example.net | Zone Factory (ZF) | | +--------------------+ | | (3) ZF publishes new HTTPS RR V +--------------------+ | | | ns.example.net | Authoritative DNS | | +--------------------+ ]]>

The shared-mode ECH server generates new ECHConfigList values every "regeninterval" seconds via some regular, automated process (e.g., a cronjob). ECHConfigList values are "current" for an hour, and remain usable for three hours from the time of generation. The automated process updates the ECHConfigList values in a JSON resource (see ) at the well-known URI, https://backend.example.com/.well-known/origin-svcb. These steps may then occur:

1. On the ZF, another regularly executed job uses an HTTP client to retrieve this JSON resource from backend.example.com. The data MUST be fetched via HTTPS and the certificate validity MUST be verified.
2. If there is no change to the JSON content, then the ZF is done processing for this backend. If there is a change to the JSON content, the ZF attempts to connect to backend.example.com using these ECH values and confirms that they are working.
3. The ZF observes that the JSON resource has a regeninterval of 3600 seconds, and chooses a DNS TTL of 1800. It updates the DNS zone file for backend.example.com and re-publishes the zone containing the new ECHConfigList values instead of the old.

When "regeninterval" seconds have passed, the ZF attempts to refresh its cached copy of the JSON resource. If the resource has changed, it repeats this process.

In this section, we describe one possible way in which ECH split-mode could be deployed and make use of this .well-known scheme. There are of course various other deployment options that might be more effective.

|backend.example.com | | cfs.lb.example | +--------------------+ ^ ^ (3) ZF reads | | (4) ZF checks .well-known V V ECHConfig +--------------------+ | | | zf.example.net | Zone Factory (ZF) | | +--------------------+ | | (5) ZF publishes new HTTPS RR V +--------------------+ | | | ns.example.net | Authoritative DNS | | +--------------------+ ]]>

In this topology, the overall process is as in the previous section, but with the following differences:

1. The CFS is a load-balancer and only does ECH decryption. The load-balancer is called cfs.lb.example.
2. Traffic between the CFS and backend is protected using some kind of VPN.
3. The A/AAAA values for backend.example.com and cfs.lb.example are the same.
4. backend.example.com content is hosted on some machine(s) accessible via the CFS and then via the VPN.
5. backend.example.com wants to acquire the ECH config information from the CFS by querying the CFS' .well-known URL, in this case https://cfs.lb.example/.well-known/origin-svcb
6. backend.example.com then publishes its chosen JSON (presumably including the relevant ECH config information) at https://backend.example.com/.well-known/origin-svcb That resource is hosted on the "real" backend.example.com machine.
7. The ZF attempts to connect to https://backend.example.com using the generated HTTPS record(s), including the relevant ECH values, and confirms that all is working before updating the zone.

Note that in this example the ZF does not necessarily know that ECH split-mode is in use.

If the backend wants to convey information to the Zone Factory, it publishes the JSON content defined in at: https://backend.example.com/.well-known/origin-svcb The well-known URI defined here MUST be an https URL and therefore the ZF can verify the correct backend is being accessed. If no new ECHConfig value verifies (as per ), then the zone factory MUST NOT modify the zone. With this scheme, web origins can only "speak for themselves" so that if the backend is e.g. at port 8443 rather then the default 443, then the ZF MUST access https://backend.example.com:8443/.well-known/origin-scvb when considering modifications to the HTTPS/SVCB records for _8443._https.example.com. As a consequence, a ZF will need to be configured to periodically refresh the JSON resource for each origin separately; that is, a ZF cannot "discover" from port 443 that some other service, for which the ZF is expected to update the DNS, is also present on another port on the same host.

The JSON file at the well-known URI MUST contain an object with two keys: "regeninterval", whose value is a number, and "endpoints" whose value is an array of objects. All other keys MUST be ignored. The "regeninterval" must be a positive integer and specifies the number of seconds between key generation actions at the origin, i.e. a replacement ECHConfigList may be generated this often. This is used by the ZF to generate DNS TTL values and to determine when to next poll the origin for updates. More precise expiration times are common (e.g., the "notAfter" field in certificate lifetime validity, discussed in Section 4.1.2.5 of ), but are too stringent for this use-case. The ZF cannot afford to fail open (by removing the HTTPS records) or fail closed (by removing the IP addresses), but it can safely "stretch" the lifetime of the HTTPS records because of ECH's "retry_configs" behavior. Since we have to accept this stretching, it makes sense to avoid an explicit expiration time and instead speak about the intended update frequency. This also make it clear the origin must tolerate some amount of version skew, and gives operational flexibility to avoid unreasonable update frequencies. The "endpoints" key is an array of objects.

• An empty endpoints array MUST be treated as an error.
• An endpoints array with one element can be one of three things:
  1. An empty object, which the ZF should take to be an HTTPS record with inferred SvcPriority, a TargetName equal to ".", and no ECH support. This can can be useful as a simple way to make use of the HTTPS RR type's HSTS behavior.
  2. A ServiceMode entry, containing at least one key from the JSON HTTP Origin Info registry (see IANA Considerations, below).
  3. An AliasMode entry that points to another DNS name that must be resolved.
• If the endpoints array has more than one element, every item SHOULD be a ServiceMode entry, due to restrictions on the use of multiple AliasMode records (see , Section 2.4.2).

This format is designed to allow full use of the capabilities of HTTPS records in natural JSON while minimizing the risk of invalid configurations. The following keys are defined for ServiceMode entries:

target:

The value is a string containing a fully qualified domain name corresponding to the HTTPS record's TargetName with the final "." removed. The default value is the empty string (""), corresponding to a TargetName of ".". To avoid complex conversion logic, the characters in this value MUST be limited to lower ASCII letters, digits, "-", "_", and "." (ALPHA / DIGIT / "-" / "_" / "." in ABNF). These are the characters used in preferred name syntax and underscore labels.

priority:

The value is a positive integer corresponding to the SvcPriority. If omitted, the ZF SHOULD use the SvcPriority from the previous element of the endpoints array (or the value one for the first element).

params:

A JSON Dictionary representing the SVCB SvcParams. Each key in the dictionary is a string containing a registered SvcParamKey name (e.g., "ipv6hint") or a SvcParamKey in generic form (e.g., "key65528"). The default value is "{}".

• For single-valued SvcParams (e.g., "ech"), the value is a JSON String. A JSON String is a sequence of Unicode codepoints, while a SvcParam's presentation value is a sequence of octets, so each value octet is stored as a single Unicode codepoint . In almost all cases, this is equivalent to the ordinary string representation of the presentation value.
• For list-valued SvcParams (e.g., "alpn"), the value is a JSON Array of Strings. Each String represents an octet sequence, as in the single-value case.

The following key is defined for AliasMode entries.

alias:

The value MUST be a DNS name that could be used as the TargetName of an HTTPS resource record. This indicates that the backend is hosted on the same endpoints as this target, and is equivalent to an HTTPS AliasMode record. The ZF might implement this directive by publishing an AliasMode record, publishing a CNAME record, copying HTTPS records from the target zone, or fetching https://cfs.example.com/.well-known/origin-svcb (if it exists).

These definitions, taken with the ZF behaviour specified below, provide the following important properties:

• Origins can express any useful configuration that is representable by HTTPS records, including multiple endpoints representing different ports, providers, etc.
• Origins that simply alias to a single target can indicate this without copying the ECHConfig and other parameters, avoiding the maintenance burden of staying synchronized with the target's key rotations and configuration updates.

If the origin makes use of intermediaries, it is the origin's responsibility to ensure that the origin-svcb JSON document correctly accounts for their current configuration. Note that there are multiple, and possibly confusing, port numbers involved here. The port that is part of the web origin in the .well-known URL is part of the QNAME that will be used by clients in accessing the origin's HTTPS/SVCB resource records. The "port" field in the RR value, and in the JSON structure, is the value to be used in specifying an "alternative endpoint" as defined in section 1.3.

If the ZF is unable to convert the JSON into a DNS zone fragment (e.g., due to an unrecognized SvcParamKey), or if the resulting zone fails validation checks, the ZF MUST NOT update the DNS. Such failures will not be directly visible to the client-facing server, so ZF implementations will need to provide some form of reporting so that the situation can be resolved. Note that this can lead to inconsistent behavior for a single origin served by multiple ZFs. A ZF MAY apply additional processing according to its own policy, such as adjusting TTL values and correcting common misconfigurations. A ZF SHOULD check that ECH with the presented endpoints succeeds with the backend before publication. In order to make such checks, the ZF SHOULD attempt to access the well-known URI defined here while attempting ECH. A bespoke TLS client is likely needed for this check, that does not require the ECHConfigList value to have already been published in the DNS. The TLS client also needs to allow checking for the success or failure of ECH. If more than one ECHConfig is present in an ECHConfigList, then the ZF SHOULD explode the ECHConfigList value presented into "singleton" values with one public key in each, and then test each of those separately. If ipv4hints or ipv6hints are present, and if those are not the same values as are published in A/AAAA RRs for the backend, then the ZF SHOULD check that webPKI based authentication of the backend works at all of the relevant addresses. A ZF SHOULD publish all the endpoints that are presented in the JSON file that pass the checks above. A ZF SHOULD set a DNS TTL less than regeninterval, i.e. short enough so that any cached DNS resource records are likely to have expired before the JSON object's content is likely to have changed. The ZF MUST attempt to refresh the JSON object and regenerate the zone before this time. This aims to ensure that ECHConfig values are not used longer than intended by backend.

This document defines a way to publish SVCB/HTTPS RR values. If the wrong values were published in the DNS, then TLS clients using ECH might suffer a privacy leak, or degraded service due to overuse of ECH retry_configs. Similarly, a ZF that also has write access to A/AAAA RRs for a backend, SHOULD NOT publish HTTPS RRs that contain ipv4hints or ipv6hints that are in conflict with the correct A/AAAA values unless those have been verified (via webPKI) as belonging to the same backend. When considering the content of SVCB/HTTPS RRs, the general argument for the security of this scheme is that this scheme has the backend server authenticate the JSON structure that is mapped directly to the SVCB/HTTPS RR, to eventually be used by TLS clients when interacting with the backend server, via the client-facing server. If a ZF is also authoritative for the CAA RR for a CFS, then, as part of verifying the origin of the .well-known JSON, that ZF is in a position to evaluate whether the CA that issues the CFS TLS server certificate was authorized to do so at the time of issuance. A check of this kind can reduce exposure to attacks by an untrustworthy CA. ECH split-mode security also requires that the backend server acquire SvcParamKey values from the client-facing server via some authenticated means. If the backend server acquires the JSON data from the well-known URL and it is properly authenticated via HTTPS from the client-facing server's public_name then that satisfies this requirement. The system described here depends on the webPKI for authentication of entities and results in publication of new SVCB/HTTPS RRs. The webPKI itself, however, often depends on the DNS to demonstrate control over a DNS name, e.g. when using the ACME protocol with the HTTP-01 challenge type. A temporary breach of a backend server that allows the attacker to contol the JSON content described here could be used to bootstrap more long-lasting control over the backend's DNS name if the attacker were to request new certificates during the time when the attacker's chosen values were published in the DNS, and if the ACME server doing the validation solely depended on content from the backend's HTTPS RR, e.g. preferring ipv6hints over the AAAA for the backend. It would seem prudent for ACME servers to be cautious if using ipv4hints and ipv6hints, e.g. flagging divergence between those values and A/AAAA RRs. Although the .well-known URL defined here may well be publicly accessible, general HTTP clients SHOULD NOT attempt to use this resource in lieu of HTTPS records queries through their preferred DNS server for the following reasons:

• The bootstrap connection would not be able to use ECH, so it would reveal all the information that ECH seeks to protect.
• The origin could serve the user with a uniquely identifying configuration, potentially resulting in an unexpected tracking vector.

Operators should be careful to avoid directory enumeration or traversal attacks if the .well-known/ URLs are served directly from a filesystem. For example, a misconfiguration of this kind could expose the ECH private keys. As described, in mutlti-CDN and simlar scenarios, a ZF might only test ECH success against one of the CDNs unless the ZF can make use of the ipv4hints and/or ipv6hint values, or the ZF has out of band information about the different addresses at which backend.example.com can be accessed. This document doesn't specify how origins are added to the list used by a ZF, nor how those are deleted, nor does it specify how a CFS might signal to a ZF that it wishes all HTTPS RRs to be deleted. To reduce the frequency of DNS zone updates, ZF implementations MAY defer any DNS updates until they detect a a change to the JSON value. Changes can be detected using HTTP cache headers, comparison of normalized JSON or internal data structures to a cached copy, or comparison of the generated DNS records (including TTLs) with those currently published in the zone. If DNS records are retrieved for this purpose using a DNS query, it MUST use an authenticated secure transport directly to the authoritative server, in order to ensure integrity of the returned TTL value. For clarity: a localhost connection between the ZF implementation and the authoritative server process that does not use the system stub resolver is considered sufficently secure for this protocol, should that be an acceptable local policy. Using this protocol, a ZF SHOULD only publish RRs for origins that are actively taking part in this protocol. If an origin used to use this protocol, but since stopped, this protocol. If an origin used to use this protocol, but since stopped, and if a ZF was still polling for that origin's .well-known and the origin hadn't deleted the origin-svcb JSON, then undesired publication of RRs could occur. Implementations SHOULD take steps to try ensure such accidental publication does not happen.

Thanks to Niall O'Reilly, Martin Thomson and David Black for reviews. Stephen Farrell's work on this specification was supported in part by the Open Technology Fund.

IANA is requested to take two actions: registering a new well-known URI in the registry at and creating a new registry for defining items in the JSON object found at that endpoint.

IANA is requested to add the following entry to the Well-Known URIs table: Additional Well-Known entry

Column	Value
URI Suffix	origin-svcb
Change Controller	IETF
Reference	{This RFC}
Status	permanent
Related Information	Must be fetched via HTTPS
Date Registered	{When registered}
Date Modified

Items in curly braces should be replaced with their actual values.

If approved, this specification requests the creation of an IANA registry named "JSON Service Binding Info" with a Standards Action registration policy. The request is to put the table in a new file "json-svcb.xml" in the existing "dns-svcb" registry group. The table has three columns:

Name:

the name of the top-level field being added

Reference:

the document that defines the semantics of the field

Notes:

any short additional information the registrant wishes to add

The table should be populated with the following two entries, where Items in curly braces should be replaced with their actual values, and the "Notes" column is empty. Initial values for the registry

Name	Reference	Notes
endpoints	{This RFC}
regeninterval	{This RFC}

The -00 WG draft replaces draft-farrell-tls-wkesni-03. Version 01 changed from a special-purpose design, carrying only ECHConfigs and port numbers, to a more general approach based on Service Bindings. Version 02 is just a keep-alive Version 03 reflects some local implementation experience with -02 Version 04 matches a proof-of-concept bash script implementation and results of IETF-117 discussion. Version 05 updated the IANA and Security considerations and fixed conformance to HTTPS SVCB spec. It also addressed early artart and dnsop reviews, and some list discussion/github issues. Version 06 changed the name and some of the text because it is no longer ECH-specific. Version 07 clarifies that origins only speak for themselves and has editorial changes and clarifications. Version 08 resolves a number of issues identified in discussion between authors and arising from implementation and (a very tiny) deployment.

TBD - add more and more detailed examples with names, JSON etc. and brief explanations.