]> 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 this origin's Service Bindings, i.e. its "HTTPS" DNS records. These instructions can include Encrypted ClientHello (ECH) configurations, allowing the origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys.

Encrypted ClientHello (ECH) for TLS1.3 defines a confidentiality mechanism for server names and other ClientHello content in TLS. For many applications, that requires publication of ECHConflgList data structures in the DNS. An ECHConfigList structure contains a list of ECHConfig values. 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 RR values containing ECHConfigList values. Some deployments however, will not, so web deployments could benefit from a mechanism to use in such cases. We define such a mechanism here. Note that this 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). That zone file will eventually include an HTTPS or SVCB RR containing the ECHConfigList. This mechanism is extensible to deliver other kinds of information about the origin, that can be of use in these circumstances, but is mainly intended to provide the functionality necessary for ongoing management of ECH keys. We use the term "zone factory" for the entity that does have write access to the zone file. We assume the zone factory (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 (back-end) can similarly poll the ECH front-end at the well-known URI and then create it's own value to publish for the ZF to read. [[The source for this draft is in https://github.com/sftcd/wkesni/ Issues and PRs are welcome there too.]]

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-accsss to the DNS Front-end (FE): the web server that has an ECH private value. This processes the outer ClientHello and attempts ECH decryption. The name of FE will typically be the public_name value used in an ECHconfig. Back-end (BE): the web server that will process the inner ClientHello. Note that even if FE and BE are on the same web server, they almost certainly have different DNS names. Shared-mode: this is where FE and BE are the same web server. Split-mode: this refers to the case where FE only does ECH decryption but the TLS session is between the client and BE, which will typically be on a different host to FE regeninterval: the number of seconds after which the value retrieved after acessing a well-known URI may be changed.

An example deployment could be as follows: Shared-mode ECH web 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 3 hours from the time of generation The cronjob updates the ECHConfigList values in a JSON resource at at https://BE/.well-known/origin-svcb, as shown in . On the ZF, another regularaly executed job uses an HTTP client to retrieve this JSON resource. It also attempts to connect to BE using these ECH values and confirms that they are working. The ZF observes that the JSON resource has a regeninterval of 3600 seconds, and chooses a DNS TTL of 1800. It updates the zone file for BE and re-publishes the zone containing only the new ECHConfigList values. 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.

If BE wants to convey information to the Zone Factory, it publishes the JSON content defined in at: https://BE/.well-known/origin-svcb The well-known URI defined here MUST be an https URL and therefore the ZF verifies the correct BE is being accessed. If no new ECH value resulting "works," then the zone factory SHOULD NOT modify the zone. Note that a consequence of the URL above is that back-ends that wish to use different ECH settings are very likely to have to use different "DocRoot" settings.

[[The JSON structure is a work in progress.]]

The JSON file at the well-known URI MUST contain an object with an "endpoints" key that contains an array of objects that each map to a desired HTTPS/SVCB resource record that the back-end would like to see published. The "endpoints" array its value is an array whose elements each represent HTTPS records in ServiceMode or AliasMode as described below. Each element MAY contain one or more keys from the JSON HTTP Origin Info registry (see IANA Considerations). The initial registry entries are: regeninterval: the number of seconds between key generation actions at the origin, i.e. a replacement ECHConfigList may be generated this often. priority: The value is a positive integer corresponding to the SvcPriority. If omitted, the zone factory SHOULD infer numerically increasing SvcPriority from the order of the endpoints array. target: The value is a string containing a fully qualified domain name, corresponding to the HTTPS record's TargetName. The default value is ".". alias: The value MUST be a DNS name that could be used as the TargetName of an HTTPS resource record. This indicates that the back-end 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://FE/.well-known/origin-svcb" (if it exists). In this case, the regeninterval indicates that BE does not plan to change the content at the URL for at least that number of seconds. If an alias entry is present then any ech and port entries (if also present) MUST be ignored. ech: The value is a string containing an ECHConfigList encoded in Base64 , corresponding to the value of the "ech" SvcParamKey. port: The value is a non-negative integer, corresponding to the value of the "port" SvcParamKey. alpn: The value is a string corresponding to the value of the "alpn" SvcParamKey. Typically this is likely to be set per back-end. ipv4hints: The value is a string corresponding to the value of the "ipv4hints" SvcParamKey. Typically this is likely to be set per front-end. ipv6hints: The value is a string corresponding to the value of the "ipv6hints" SvcParamKey. Typically this is likely to be set per front-end. An empty endpoint object corresponds to an HTTPS record with inferred SvcPriority, TargetName=".", and no ECH support. An empty record of this kind can be useful as a simple way to make use of the HTTPS RR type's HSTS behavior. [[TODO: What does the zone factory do if it encounters an unrecognized field?]] This arrangement provides the following important properties: Origins can indicate that different ECHConfigs are used on different ports. Origins can indicate that multiple CDNs are in use, each with its own ECHConfig. Origins that simply alias to a single target can indicate this without copying the ECHConfig and other parameters, which can interfere with key rotation and other maintenance. "port" and "target" are generally sufficient to uniquely identify a ServiceMode record, so zone factories can use the endpoint list to add ECH to pre-existing ServiceMode records that may have other SvcParams.

ZF SHOULD check that the presented endpoints work and provide access to BE before publication. A bespoke TLS client may be needed for this check, that does not require the ECHConfigList value to have already been published in the DNS. In order to make such checks, the ZF SHOULD attempt to access the well-known URI defined here. A careful ZF implementation could explode the ECHConfigList value presented into "singleton" values with one public key in each, and then test each of those separately. ZF SHOULD publish all the endpoints that are presented in the JSON file that pass the checks above. ZF SHOULD set a DNS TTL 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 BE.

This document defines another way to publish ECHConfigList values. If the wrong keys were read from here and published in the DNS, then clients using ECH would do the wrong thing, likely resulting in denial of service, or a privacy leak, or worse, when TLS clients attempt to use ECH with a back-end web site. So: Don't do that:-) Although this configuration resource MAY 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.

Thanks to Niall O'Reilly for a quick review of -00. Stephen Farrell's work on this specification was supported in part by the Open Technology Fund.

[[TBD: IANA registration of a .well-known. Also TBD - how to handle I18N for $FRONTEND and $BACKEND within such a URL.]] If approved, this specification requests the creation of an IANA registry named "JSON HTTP Origin Info" with a Standards Action registration policy, containing a field named "Name" whose value is a UTF-8 string.

&I-D.ietf-tls-esni; &I-D.ietf-tls-svcb-ech;

[[RFC editor: please remove this before publication.]] 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.