Internet DRAFT - draft-ietf-tls-svcb-ech

draft-ietf-tls-svcb-ech







TLS Working Group                                            B. Schwartz
Internet-Draft                                                    Google
Intended status: Standards Track                               M. Bishop
Expires: 29 March 2024                                         E. Nygren
                                                     Akamai Technologies
                                                       26 September 2023


   Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
                       draft-ietf-tls-svcb-ech-00

Abstract

   To use TLS Encrypted ClientHello (ECH) the client needs to learn the
   ECH configuration for a server before it attempts a connection to the
   server.  This specification provides a mechanism for conveying the
   ECH configuration information via DNS, using a SVCB or HTTPS record.

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



Schwartz, et al.          Expires 29 March 2024                 [Page 1]

Internet-Draft                 ECH in SVCB                September 2023


Table of Contents

   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  SvcParam for ECH configuration  . . . . . . . . . . . . . . .   2
   3.  Server behavior . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Client behavior . . . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Disabling fallback  . . . . . . . . . . . . . . . . . . .   3
     4.2.  ClientHello construction  . . . . . . . . . . . . . . . .   3
     4.3.  Performance optimizations . . . . . . . . . . . . . . . .   3
   5.  Interaction with HTTP Alt-Svc . . . . . . . . . . . . . . . .   4
     5.1.  Security Considerations . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Overview

   The Service Bindings framework [SVCB] allows server operators to
   publish a detailed description of their service in the Domain Name
   System [RFC1034] using SVCB or HTTPS records.  Each SVCB record
   describes a single "alternative endpoint", and contains a collection
   of "SvcParams" that can be extended with new kinds of information
   that may be of interest to a client.  Clients can use the SvcParams
   to improve the privacy, security, and performance of their connection
   to this endpoint.

   This specification defines a new SvcParam to enable the use of TLS
   Encrypted ClientHello [ECH] in TLS-based protocols.  This SvcParam
   can be used in SVCB, HTTPS or any future SVCB-compatible DNS records,
   and is intended to serve as the primary bootstrap mechanism for ECH.

2.  SvcParam for ECH configuration

   The "ech" SvcParamKey is defined for conveying the ECH configuration
   of an alternative endpoint.  It is applicable to all TLS-based
   protocols (including DTLS [RFC9147] and QUIC version 1 [RFC9001])
   unless otherwise specified.

   In wire format, the value of the parameter is an ECHConfigList
   (Section 4 of [ECH]), including the redundant length prefix.  In
   presentation format, the value is the ECHConfigList in Base 64
   Encoding (Section 4 of [RFC4648]).  Base 64 is used here to simplify
   integration with TLS server software.  To enable simpler parsing,
   this SvcParam MUST NOT contain escape sequences.





Schwartz, et al.          Expires 29 March 2024                 [Page 2]

Internet-Draft                 ECH in SVCB                September 2023


3.  Server behavior

   When publishing a record containing an "ech" parameter, the publisher
   MUST ensure that all IP addresses of TargetName correspond to servers
   that have access to the corresponding private key or are
   authoritative for the public name.  (See Section 7.2.2 of [ECH] for
   more details about the public name.)  Otherwise, connections will
   fail entirely.

4.  Client behavior

   This section describes client behavior in using ECH configurations
   provided in SVCB or HTTPS records.

4.1.  Disabling fallback

   The SVCB-optional client behavior specified in (Section 3 of [SVCB])
   permits clients to fall back to a direct connection if all SVCB
   options fail.  This behavior is not suitable for ECH, because
   fallback would negate the privacy benefits of ECH.  Accordingly, ECH-
   capable SVCB-optional clients MUST switch to SVCB-reliant connection
   establishment if SVCB resolution succeeded (as defined in Section 3
   of [SVCB]) and all alternative endpoints have an "ech" SvcParam.

4.2.  ClientHello construction

   When ECH is in use, the TLS ClientHello is divided into an
   unencrypted "outer" and an encrypted "inner" ClientHello.  The outer
   ClientHello is an implementation detail of ECH, and its contents are
   controlled by the ECHConfig in accordance with [ECH].  The inner
   ClientHello is used for establishing a connection to the service, so
   its contents may be influenced by other SVCB parameters.  For
   example, the requirements related to ALPN protocol identifiers in
   Section 7.1.2 of [SVCB] apply only to the inner ClientHello.
   Similarly, it is the inner ClientHello whose Server Name Indication
   identifies the desired service.

4.3.  Performance optimizations

   Prior to retrieving the SVCB records, the client does not know
   whether they contain an "ech" parameter.  As a latency optimization,
   clients MAY prefetch DNS records that will only be used if this
   parameter is not present (i.e. only in SVCB-optional mode).

   The "ech" SvcParam alters the contents of the TLS ClientHello if it
   is present.  Therefore, clients that support ECH MUST NOT issue any
   TLS ClientHello until after SVCB resolution has completed.  (See
   Section 5.1 of [SVCB]).



Schwartz, et al.          Expires 29 March 2024                 [Page 3]

Internet-Draft                 ECH in SVCB                September 2023


5.  Interaction with HTTP Alt-Svc

   HTTP clients that implement both HTTP Alt-Svc [RFC7838] and the HTTPS
   record type [SVCB] can use them together, provided that they only
   perform connection attempts that are "consistent" with both sets of
   parameters (Section 9.3 of [SVCB]).  At the time of writing, there is
   no defined parameter related to ECH for Alt-Svc.  Accordingly, a
   connection attempt that uses ECH is considered "consistent" with an
   Alt-Svc Field Value that does not mention ECH.

   Origins that publish an "ech" SvcParam in their HTTPS record SHOULD
   also publish an HTTPS record with the "ech" SvcParam for every alt-
   authority offered in its Alt-Svc Field Values.  Otherwise, clients
   might reveal the name of the server in an unencrypted ClientHello to
   an alt-authority.

   If all HTTPS records for an alt-authority contain "ech" SvcParams,
   the client MUST adopt SVCB-reliant behavior (as in Section 4.1) for
   that RRSet.  This precludes the use of certain connections that Alt-
   Svc would otherwise allow, as discussed in Section 9.3 of [SVCB].

5.1.  Security Considerations

   A SVCB RRSet containing some RRs with "ech" and some without is
   vulnerable to a downgrade attack: a network intermediary can block
   connections to the endpoints that support ECH, causing the client to
   fall back to a non-ECH endpoint.  This configuration is NOT
   RECOMMENDED.  Zone owners who do use such a mixed configuration
   SHOULD mark the RRs with "ech" as more preferred (i.e. lower
   SvcPriority value) than those without, in order to maximize the
   likelihood that ECH will be used in the absence of an active
   adversary.

   Use of ECH yields an anonymity set of cardinality equal to the number
   of ECH-enabled server domains supported by a given client-facing
   server.  Thus, even with an encrypted ClientHello, an attacker who
   can enumerate the set of ECH-enabled domains supported by a client-
   facing server can guess the correct SNI with probability at least 1/
   K, where K is the size of this ECH-enabled server anonymity set.
   This probability may be increased via traffic analysis or other
   mechanisms.

6.  IANA Considerations

   IANA is instructed to modify the Service Binding (SVCB) Parameter
   Keys Registry entry for "ech" as follows:





Schwartz, et al.          Expires 29 March 2024                 [Page 4]

Internet-Draft                 ECH in SVCB                September 2023


      +========+======+====================+===========+============+
      | Number | Name | Meaning            | Format    | Change     |
      |        |      |                    | Reference | Controller |
      +========+======+====================+===========+============+
      | 5      | ech  | TLS Encrypted      | (This     | IETF       |
      |        |      | ClientHello Config | document) |            |
      +--------+------+--------------------+-----------+------------+

                                  Table 1

7.  References

7.1.  Normative References

   [ECH]      Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
              Encrypted Client Hello", Work in Progress, Internet-Draft,
              draft-ietf-tls-esni-16, 6 April 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              esni-16>.

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

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

   [SVCB]     Schwartz, B. M., Bishop, M., and E. Nygren, "Service
              binding and parameter specification via the DNS (DNS SVCB
              and HTTPS RRs)", Work in Progress, Internet-Draft, draft-
              ietf-dnsop-svcb-https-12, 11 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
              svcb-https-12>.

7.2.  Informative References

   [RFC7838]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
              April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.

   [RFC9001]  Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
              QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9001>.







Schwartz, et al.          Expires 29 March 2024                 [Page 5]

Internet-Draft                 ECH in SVCB                September 2023


   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
              <https://www.rfc-editor.org/rfc/rfc9147>.

Authors' Addresses

   Ben Schwartz
   Google
   Email: ietf@bemasc.net


   Mike Bishop
   Akamai Technologies
   Email: mbishop@evequefou.be


   Erik Nygren
   Akamai Technologies
   Email: erik+ietf@nygren.org































Schwartz, et al.          Expires 29 March 2024                 [Page 6]