A well-known URI for publishing ECHConfigList values.
draft-ietf-tls-wkech-04

TLS                                                           S. Farrell
Internet-Draft                                    Trinity College Dublin
Intended status: Experimental                                    R. Salz
Expires: 24 April 2024                               Akamai Technologies
                                                             B. Schwartz
                                                    Meta Platforms, Inc.
                                                         22 October 2023

         A well-known URI for publishing ECHConfigList values.
                        draft-ietf-tls-wkech-04

Abstract

   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.

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 24 April 2024.

Copyright Notice

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

   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

Farrell, et al.           Expires 24 April 2024                 [Page 1]
Internet-Draft           Well-Known URI for ECH             October 2023

   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 use of the well-known URI for ECH . . . . . . . . . .   3
   4.  The origin-svcb well-known URI  . . . . . . . . . . . . . . .   4
   5.  The JSON structure for origin service binding info  . . . . .   4
   6.  Zone factory behaviour  . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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.  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
   [I-D.ietf-tls-svcb-ech] 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 [RFC8615] on the web server that allows the ZF to poll
   for changes to ECHConfigList values.  For example, if a web server

Farrell, et al.           Expires 24 April 2024                 [Page 2]
Internet-Draft           Well-Known URI for ECH             October 2023

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

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

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

   An example deployment could be as follows:

   1.  Shared-mode ECH web server generates new ECHConfigList values
       every "regeninterval" seconds via some regular, automated process
       (e.g. a cronjob)
   2.  ECHConfigList values are "current" for an hour, and remain usable
       for 3 hours from the time of generation
   3.  The cronjob updates the ECHConfigList values in a JSON resource
       at at https://BE/.well-known/origin-svcb, as shown in Figure 1.

Farrell, et al.           Expires 24 April 2024                 [Page 3]
Internet-Draft           Well-Known URI for ECH             October 2023

   4.  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.
   5.  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.
   6.  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.

4.  The origin-svcb well-known URI

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

5.  The JSON structure for origin service binding info

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

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

               Figure 1: Sample JSON for ECH without aliases

Farrell, et al.           Expires 24 April 2024                 [Page 4]
Internet-Draft           Well-Known URI for ECH             October 2023

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

                    Figure 2: Sample JSON with aliasing

   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 [RFC4648], corresponding to the value of the "ech"
      SvcParamKey.
   *  port: The value is a non-negative integer, corresponding to the
      value of the "port" SvcParamKey.

Farrell, et al.           Expires 24 April 2024                 [Page 5]
Internet-Draft           Well-Known URI for ECH             October 2023

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

6.  Zone factory behaviour

   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.

Farrell, et al.           Expires 24 April 2024                 [Page 6]
Internet-Draft           Well-Known URI for ECH             October 2023

   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.

7.  Security Considerations

   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.

8.  Acknowledgements

   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.

9.  IANA Considerations

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

10.  Normative References

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

Farrell, et al.           Expires 24 April 2024                 [Page 7]
Internet-Draft           Well-Known URI for ECH             October 2023

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

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [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-17, 9 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              esni-17>.

   [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-00,
              26 September 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-tls-svcb-ech-00>.

Appendix A.  Change Log

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

Farrell, et al.           Expires 24 April 2024                 [Page 8]
Internet-Draft           Well-Known URI for ECH             October 2023

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 24 April 2024                 [Page 9]