draft-ietf-tls-wkech.txt

TLS                                                           S. Farrell
Internet-Draft                                    Trinity College Dublin
Intended status: Experimental                                    R. Salz
Expires: 5 October 2025                              Akamai Technologies
                                                             B. Schwartz
                                                    Meta Platforms, Inc.
                                                            3 April 2025


           A well-known URI for publishing service parameters
                        draft-ietf-tls-wkech-07

Abstract

   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.

Note

   This note is to be removed before publishing as an RFC.

   The source for this draft is in https://github.com/sftcd/wkesni/
   Issues and PRs are welcome there too.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 5 October 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Farrell, et al.          Expires 5 October 2025                 [Page 1]

Internet-Draft           Well-Known URI for SVCB              April 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Example uses of the well-known URI for ECH  . . . . . . . . .   4
     3.1.  Shared-mode deplpoyment.  . . . . . . . . . . . . . . . .   4
     3.2.  Split-mode deployment.  . . . . . . . . . . . . . . . . .   5
   4.  The origin-svcb well-known URI  . . . . . . . . . . . . . . .   7
   5.  The JSON structure for origin service binding info  . . . . .   7
   6.  Zone Factory behaviour  . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Well-known endpoint registration  . . . . . . . . . . . .  13
     9.2.  JSON Service Binding Info . . . . . . . . . . . . . . . .  14
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     10.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  16
   Appendix B.  Examples . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   Encrypted ClientHello (ECH) [I-D.ietf-tls-esni] for TLS1.3 [RFC8446]
   defines a confidentiality mechanism for server names and other
   ClientHello content in TLS.  The Service Bindings (SVCB) in DNS RFC
   [RFC9460] defines how to handle information needed to make
   connections to services by using a new DNS record set (RRset).  The
   [I-D.ietf-tls-svcb-ech] document defines an entry in that RRset for
   Encrypted Client Hello (ECH) configuration information.











Farrell, et al.          Expires 5 October 2025                 [Page 2]

Internet-Draft           Well-Known URI for SVCB              April 2025


   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 a mechanism like the one defined
   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).  This mechanism is extensible to
   deliver other kinds of information about the origin, that can be of
   use in these circumstances.  This document uses the ECH data to
   provide a concrete example.

   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 [RFC8615] 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 it's own value to publish for the ZF to read.  ECH
   split-mode is defined in [I-D.ietf-tls-esni] and an example is
   provided below (Section 3).

2.  Terminology

   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 [RFC2119] [RFC8174] 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:  the web server that has an ECH private value.





Farrell, et al.          Expires 5 October 2025                 [Page 3]

Internet-Draft           Well-Known URI for SVCB              April 2025


      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.

3.  Example uses of the well-known URI for ECH

   Some example deployments are described here.

3.1.  Shared-mode deplpoyment.

                       +--------------------+
                       |                    |
    TLS                |   2001:DB8::1111   | Client-
   Client <----------->|                    | 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
                       |                    |
                       +--------------------+



Farrell, et al.          Expires 5 October 2025                 [Page 4]

Internet-Draft           Well-Known URI for SVCB              April 2025


          Figure 1: Shared-Mode Topology with Zone Factory and 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
   Figure 3) 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.

3.2.  Split-mode deployment.

   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.














Farrell, et al.          Expires 5 October 2025                 [Page 5]

Internet-Draft           Well-Known URI for SVCB              April 2025


                       +--------------------+
                       |        REAL        |
                       | backend.example.com|
                       |                    |
                       +--------------------+
         (1) backend       ^^           ^^   (2) backend publishes
             reads CFS'    ||    VPN    ||       backend's
             .well-known   VV           VV       .well-known
                       +--------------------+
                       |                    |
        TLS            |   2001:DB8::1111   |
        Client <---->  |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
                       |                    |
                       +--------------------+

          Figure 2: Split-Mode Topology with Zone Factory and DNS

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

   1.  The client-facing server (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.




Farrell, et al.          Expires 5 October 2025                 [Page 6]

Internet-Draft           Well-Known URI for SVCB              April 2025


   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.

4.  The origin-svcb well-known URI

   If the backend wants to convey information to the Zone Factory, it
   publishes the JSON content defined in Section 5 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 Section 6), 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.

5.  The JSON structure for origin service binding info












Farrell, et al.          Expires 5 October 2025                 [Page 7]

Internet-Draft           Well-Known URI for SVCB              April 2025


       {
           "regeninterval": 3600,
           "endpoints": [{
               "priority": 1,
               "target": "cdn.example",
               "params": {
                   "ech": "AD7+DQA65wAgAC..AA=="
               }
           }, {
               "priority": 1,
               "params": {
                   "port": 8413,
                   "ech": "AD7+DQA65wAgAC..AA=="
               }
           }]
       }

               Figure 3: Sample JSON for ECH without aliases

        {
           "regeninterval": 108000,
           "endpoints": [{
               "alias": "cdn1.example.com",
           }]
         }

                    Figure 4: Sample JSON with aliasing

   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.














Farrell, et al.          Expires 5 October 2025                 [Page 8]

Internet-Draft           Well-Known URI for SVCB              April 2025


   More precise expiration times are common (e.g., the "notAfter" field
   in certificate lifetime validity, discussed in Section 4.1.2.5 of
   [RFC5280]), 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 means that all HTTPS records that the ZF
      has published for the origin should be deleted.

   *  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
          (Section 9), 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 [RFC9460]).

   This format is designed to allow full use of the capabilities of
   HTTPS records [RFC9460] 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









Farrell, et al.          Expires 5 October 2025                 [Page 9]

Internet-Draft           Well-Known URI for SVCB              April 2025


      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 [RFC5234]).  These are the characters used in
      preferred name syntax [RFC1034] and underscore labels.

   priority:  The value is a positive integer corresponding to the
      SvcPriority.  If omitted, the ZF MAY infer numerically increasing
      SvcPriority from the order of the endpoints array.

   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
         [ISOMORPHIC-DECODE].  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 (Section 6) 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.





Farrell, et al.          Expires 5 October 2025                [Page 10]

Internet-Draft           Well-Known URI for SVCB              April 2025


   *  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.

   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
   [RFC9460].

6.  Zone Factory behaviour

   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.



Farrell, et al.          Expires 5 October 2025                [Page 11]

Internet-Draft           Well-Known URI for SVCB              April 2025


   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.

7.  Security Considerations

   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.

   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 [RFC8555]
   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 bootsrap 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.




Farrell, et al.          Expires 5 October 2025                [Page 12]

Internet-Draft           Well-Known URI for SVCB              April 2025


   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.

   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.

8.  Acknowledgements

   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.

9.  IANA Considerations

   IANA is requested to take two actions: registering a new well-known
   URI in the registry at https://www.iana.org/assignments/well-known-
   uris/well-known-uris.xhtml#well-known-uris-1 and creating a new
   registry for defining items in the JSON object found at that
   endpoint.

9.1.  Well-known endpoint registration

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














Farrell, et al.          Expires 5 October 2025                [Page 13]

Internet-Draft           Well-Known URI for SVCB              April 2025


            +---------------------+---------------------------+
            | 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       |                           |
            +---------------------+---------------------------+

                    Table 1: Additional Well-Known entry

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

9.2.  JSON Service Binding Info

   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.












Farrell, et al.          Expires 5 October 2025                [Page 14]

Internet-Draft           Well-Known URI for SVCB              April 2025


                  +---------------+------------+-------+
                  | Name          | Reference  | Notes |
                  +---------------+------------+-------+
                  | endpoints     | {This RFC} |       |
                  +---------------+------------+-------+
                  | regeninterval | {This RFC} |       |
                  +---------------+------------+-------+

                     Table 2: Initial values for the
                                 registry

10.  References

10.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.





Farrell, et al.          Expires 5 October 2025                [Page 15]

Internet-Draft           Well-Known URI for SVCB              April 2025


   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/info/rfc9460>.

   [I-D.ietf-tls-esni]
              Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
              Encrypted Client Hello", Work in Progress, Internet-Draft,
              draft-ietf-tls-esni-24, 20 March 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              esni-24>.

   [I-D.ietf-tls-svcb-ech]
              Schwartz, B. M., Bishop, M., and E. Nygren, "Bootstrapping
              TLS Encrypted ClientHello with DNS Service Bindings", Work
              in Progress, Internet-Draft, draft-ietf-tls-svcb-ech-07,
              12 February 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-tls-svcb-ech-07>.

10.2.  Informative References

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/info/rfc8555>.

   [ISOMORPHIC-DECODE]
              WHATWG, "WHATWG definition of Isomorphic Decode",
              <https://infra.spec.whatwg.org/#isomorphic-decode>.

Appendix A.  Change Log

   This section is to be removed before publishing as an 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.





Farrell, et al.          Expires 5 October 2025                [Page 16]

Internet-Draft           Well-Known URI for SVCB              April 2025


   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.

Appendix B.  Examples

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

Authors' Addresses

   Stephen Farrell
   Trinity College Dublin
   Dublin
   2
   Ireland
   Phone: +353-1-896-2354
   Email: stephen.farrell@cs.tcd.ie


   Rich Salz
   Akamai Technologies
   Email: rsalz@akamai.com


   Benjamin Schwartz
   Meta Platforms, Inc.
   Email: ietf@bemasc.net

















Farrell, et al.          Expires 5 October 2025                [Page 17]