draft-ietf-tls-wkech.xml

<?xml version="1.0" encoding="US-ASCII"?>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="exp" docName="draft-ietf-tls-wkech-07"
  ipr="trust200902" submissionType="IETF" xmlns:xi="http://www.w3.org/2001/XInclude">
  <front>
    <title abbrev="Well-Known URI for SVCB">A well-known URI for publishing service parameters</title>

    <author fullname="Stephen Farrell" initials="S." surname="Farrell">
      <organization>Trinity College Dublin</organization>
      <address>
        <postal>
          <street/>
          <city>Dublin</city>
          <region/>
          <code>2</code>
          <country>Ireland</country>
        </postal>
        <phone>+353-1-896-2354</phone>
        <email>stephen.farrell@cs.tcd.ie</email>
      </address>
    </author>

    <author initials="R." surname="Salz" fullname="Rich Salz">
      <organization>Akamai Technologies</organization>
      <address>
	<email>rsalz@akamai.com</email>
      </address>
    </author>

    <author initials="B." surname="Schwartz" fullname="Benjamin Schwartz">
      <organization>Meta Platforms, Inc.</organization>
      <address>
	<email>ietf@bemasc.net</email>
      </address>
    </author>

    <date year="2025"/>
    <area>Security Area</area>
    <workgroup>TLS</workgroup>
    <keyword>TLS</keyword>
    <keyword>ECH</keyword>

    <abstract>
        <t>
            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.
        </t>
      </abstract>
      <note removeInRFC="true">
	<t>The source for this draft is in
	  <eref target="https://github.com/sftcd/wkesni/"/>
	  Issues and PRs are welcome there too.</t>
      </note>
    </front>

  <middle>
    <section title="Introduction">

        <t>
	    Encrypted ClientHello (ECH) <xref target="I-D.ietf-tls-esni"/>
	    for TLS1.3 <xref target="RFC8446"/>
	    defines a confidentiality mechanism for server names and other
	    ClientHello content in TLS.
	    The <xref target="RFC9460">Service Bindings (SVCB) in DNS RFC</xref>
	    defines how to handle information needed to make connections
	    to services by using a new DNS record set (RRset).
	    The <xref target="I-D.ietf-tls-svcb-ech"/> document defines
        an entry in that RRset for Encrypted Client Hello (ECH) configuration
        information.
	</t>
	<t>
	    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.
        </t>

        <t>
	    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.
        </t>

        <t>
            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 <xref target="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.
        </t>

        <t>
            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
	    <xref target="I-D.ietf-tls-esni"/> and an example is provided
	    <xref target="examples">below</xref>.
        </t>

      </section>

      <section title="Terminology">
        <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>

    <t>We define or re-use the following terms:
    <dl>
      <dt>Zone factory (ZF):</dt>
      <dd>an entity that has write-access to the DNS</dd>
      <dt>Client-Facing Server:</dt>
      <dd>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.</dd>
      <dt>Backend:</dt>
      <dd>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.</dd>
      <dt>Shared-mode:</dt>
      <dd>this is where client-facing and backend servers are the same web server.</dd>
      <dt>Split-mode:</dt>
      <dd>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</dd>
      <dt>regeninterval:</dt>
      <dd>the number of seconds after which the value retrieved
	after acessing a well-known URI may be changed.</dd>
    </dl>
    </t>

      </section>

    <section title="Example uses of the well-known URI for ECH" anchor="examples">

        <t>Some example deployments are described here.</t>

        <section title="Shared-mode deplpoyment.">


<figure title="Shared-Mode Topology with Zone Factory and DNS" anchor="shared-mode"><artwork><![CDATA[
                    +--------------------+
                    |                    |
 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
                    |                    |
                    +--------------------+
]]></artwork></figure>

      <t>
	  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 <xref target="sample-json"/>) at the well-known URI,
	  https://backend.example.com/.well-known/origin-svcb.
      </t>
      <t>
	  These steps may then occur:
           <ol>
            <li>
                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.
            </li>
            <li>
                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.
            </li>
            <li>
                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.
            </li>
        </ol>
            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.
        </t>

        </section>

        <section title="Split-mode deployment.">
        <t>
            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.
        </t>

<figure title="Split-Mode Topology with Zone Factory and DNS" anchor="split-mode"><artwork><![CDATA[

                    +--------------------+
                    |        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
                    |                    |
                    +--------------------+
]]></artwork></figure>

<t>
    In this topology, the overall process is as in the previous section,
    but with the following differences:
    <ol>
        <li>
            The client-facing server (CFS) is a load-balancer and
            only does ECH decryption. The load-balancer is
            called cfs.lb.example.
        </li>
        <li>
            Traffic between the CFS and backend is protected using
            some kind of VPN.
        </li>
        <li>
            The A/AAAA values for backend.example.com and
            cfs.lb.example are the same.
        </li>
        <li>
            backend.example.com content is hosted on some machine(s)
            accessible via the CFS and then via the VPN.
        </li>
        <li>
            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
        </li>
        <li>
            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.
        </li>
        <li>
            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.
        </li>
    </ol>
</t>

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

	 </section>
    </section>

    <section title="The origin-svcb well-known URI">

         <t>
            If the backend wants to convey information to the Zone
            Factory, it publishes the JSON content
            defined in <xref target="jsonstr"/> at:
            https://backend.example.com/.well-known/origin-svcb
        </t>

        <t>The well-known URI defined here MUST be an https URL and therefore the ZF
        can verify the correct backend is being accessed.</t>

    <t>If no new ECHConfig value verifies (as per <xref target="zfbehave"/>), then the
            zone factory MUST NOT modify the zone. </t>

            <t>
                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.
            </t>

    </section>


<section anchor="jsonstr" title="The JSON structure for origin service binding info">

<figure anchor="sample-json" title="Sample JSON for ECH without aliases" >
<artwork><![CDATA[
    {
        "regeninterval": 3600,
        "endpoints": [{
            "priority": 1,
            "target": "cdn.example",
            "params": {
                "ech": "AD7+DQA65wAgAC..AA=="
            }
        }, {
            "priority": 1,
            "params": {
                "port": 8413,
                "ech": "AD7+DQA65wAgAC..AA=="
            }
        }]
    }
  ]]></artwork>
</figure>

<figure anchor="sample-json-alias" title="Sample JSON with aliasing" >
    <artwork><![CDATA[
     {
        "regeninterval": 108000,
        "endpoints": [{
            "alias": "cdn1.example.com",
        }]
      }
    ]]></artwork>
</figure>

    <t>
        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.
    </t>
    <t>
	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.
    </t>
    <t>
	More precise expiration times are common (e.g., the "notAfter" field
	in certificate lifetime validity, discussed in Section 4.1.2.5 of
	<xref target="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.
    </t>
    <t>
        The "endpoints" key is an array of objects.
    <ul>
      <li>
	  An empty endpoints array means that all HTTPS records that the
	  ZF has published for the origin should be deleted.
	</li>
      <li>
	  An endpoints array with one element can be one of
	  three things:
	<ol>
	  <li>
	    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.
	  </li>
	  <li>
	      A ServiceMode entry, containing at least one key from the JSON
	      HTTP Origin Info registry (see <xref target="iana">IANA
	      Considerations</xref>, below).
	  </li>
	  <li>
	    An AliasMode entry that points to another DNS name that must
	    be resolved.
	  </li>
	  </ol>
      </li>
      <li>
	    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 <xref target="RFC9460">, Section 2.4.2</xref>).
      </li>
    </ul>
    </t>

    <t>
	This format is designed to allow full use of the capabilities of
        HTTPS records <xref target="RFC9460"/> in natural JSON
        while minimizing the risk of invalid configurations.
    </t>

  <t>The following keys are defined for ServiceMode entries:
    <dl>
      <dt>target:</dt>
      <dd>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 
      <xref target="RFC5234">ABNF</xref>).
      These are the characters used in preferred name syntax <xref target="RFC1034"/> and
      underscore labels.
      </dd>
      <dt>priority:</dt>
      <dd>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.</dd>
      <dt>params:</dt>
      <dd>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 "{}".
	<ul>
	  <li>
	      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
	      <xref target="ISOMORPHIC-DECODE"/>.  In almost all cases, this
	      is equivalent to the ordinary string representation of the
	      presentation value.
	  </li>
	  <li>
	      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.
	  </li>
	</ul>
      </dd>
    </dl>
  </t>

  <t>The following key is defined for AliasMode entries.
    <dl>
      <dt>alias:</dt>
      <dd>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).
      </dd>
    </dl>
  </t>

  <t>These definitions, taken with the <xref target="zfbehave">ZF behaviour</xref>
      specified below, provide the following important properties:
    <ul>
	<li>
        Origins can express any useful configuration that is representable by
        HTTPS records, including multiple endpoints representing different
        ports, providers, etc.
    </li>
    <li>
        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.
    </li>
</ul>
</t>

    <t>
        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 <xref target="RFC9460">section 1.3</xref>.
    </t>

</section>

<section anchor="zfbehave" title="Zone Factory behaviour">

    <t>
	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.
    </t>

    <t>
	A ZF MAY apply additional processing according to its own policy, such as
	adjusting TTL values and correcting common misconfigurations.
    </t>

    <t>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.
    </t>

    <t>
        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.
    </t>

    <t>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.</t>

   <t>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.</t>

    <t>A ZF SHOULD publish all the endpoints
        that are presented in the JSON file that pass
        the checks above.</t>

    <t>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.
    </t>

</section>


    <section title="Security Considerations">

        <t>
            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.
        </t>

        <t>
            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.
        </t>

        <t>
            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.
        </t>

        <t>
            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.
        </t>

        <t>
	    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
            <xref target="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.
        </t>

        <t>
            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:
	  <ul>
                <li>
                    The bootstrap connection would not be able to use ECH,
                    so it would reveal all the information that ECH seeks
                    to protect.
                </li>
                <li>
                    The origin could serve the user with a uniquely
                    identifying configuration, potentially resulting in an
                    unexpected tracking vector.
                </li>
            </ul>
        </t>

        <t>
            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.
        </t>

    </section>

    <section title="Acknowledgements">
        <t>Thanks to Niall O'Reilly, Martin Thomson and David Black for reviews.</t>
        <t>Stephen Farrell's work on this specification was supported in part by
            the Open Technology Fund.</t>
    </section>

    <section anchor = "iana" title="IANA Considerations">
      <t>IANA is requested to take two actions: registering a new well-known
      URI in the registry at
      <eref target="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.</t>

      <section title="Well-known endpoint registration">
	<t>IANA is requested to add the following entry to the Well-Known URIs table:</t>
	  <table>
	    <name>Additional Well-Known entry</name>
	  <thead><tr><td>Column</td><td>Value</td></tr></thead>
	  <tbody>
	    <tr><td>URI Suffix</td><td>origin-svcb</td></tr>
	    <tr><td>Change Controller</td><td>IETF</td></tr>
	    <tr><td>Reference</td><td>{This RFC}</td></tr>
	    <tr><td>Status</td><td>permanent</td></tr>
	    <tr><td>Related Information</td><td>Must be fetched via HTTPS</td></tr>
	    <tr><td>Date Registered</td><td>{When registered}</td></tr>
	    <tr><td>Date Modified</td><td></td></tr>
	  </tbody>
	</table>
	<t>Items in curly braces should be replaced with their actual values.</t>
      </section>

      <section title="JSON Service Binding Info">

        <t>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:
	<dl>
	  <dt>Name:</dt><dd>the name of the top-level field being added</dd>
	  <dt>Reference:</dt><dd>the document that defines the semantics of the field</dd>
	  <dt>Notes:</dt><dd>any short additional information the registrant wishes to add</dd>
	</dl>
        </t>
	<t>
	    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.
        </t>
	<table>
	  <name>Initial values for the registry</name>
	  <thead><tr><td>Name</td><td>Reference</td><td>Notes</td></tr></thead>
	  <tbody>
	    <tr><td>endpoints</td><td>{This RFC}</td><td></td></tr>
	    <tr><td>regeninterval</td><td>{This RFC}</td><td></td></tr>
	  </tbody>
	</table>

      </section>

    </section>
  </middle>

  <back>
    <references title="Normative References">
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8615.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-esni.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-svcb-ech.xml"/>
    </references>

    <references title="Informative References">
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"/>
      <reference anchor="ISOMORPHIC-DECODE"
                   target="https://infra.spec.whatwg.org/#isomorphic-decode">
          <front>
            <title>WHATWG definition of Isomorphic Decode</title>
            <author fullname="WHATWG">
              <organization />
            </author>
            <date />
          </front>
        </reference>
    </references>

    <section title="Change Log" removeInRFC="true">
      <t>The -00 WG draft replaces draft-farrell-tls-wkesni-03.</t>

      <t>
        Version 01 changed from a special-purpose design, carrying only
        ECHConfigs and port numbers, to a more general approach based on
        Service Bindings.
      </t>

      <t>
        Version 02 is just a keep-alive
      </t>

      <t>
        Version 03 reflects some local implementation experience with -02
      </t>

      <t>
        Version 04 matches a proof-of-concept bash script implementation and
        results of IETF-117 discussion.
      </t>

      <t>
	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.
      </t>

      <t>
	  Version 06 changed the name and some of the text because
	  it is no longer ECH-specific.
      </t>

      <t>
          Version 07 clarifies that origins only speak for themselves
          and has editorial changes and clarifications.
      </t>

    </section>
    <section title="Examples">

        <t>
            TBD - add more and more detailed examples with names, JSON etc. and
            brief explanations.
        </t>

    </section>

  </back>
</rfc>