Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
draft-ietf-tls-svcb-ech-01
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
---|---|---|---|
Authors | Benjamin M. Schwartz , Mike Bishop , Erik Nygren | ||
Last updated | 2024-03-27 (Latest revision 2023-09-26) | ||
Replaces | draft-sbn-tls-svcb-ech | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
ARTART Last Call review
(of
-06)
by Barry Leiba
Ready w/nits
DNSDIR Early review
by Ted Lemon
Almost ready
SECDIR Last Call Review due 2024-11-15
Incomplete
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | I-D Exists | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-tls-svcb-ech-01
TLS Working Group B. Schwartz Internet-Draft Meta Platforms, Inc. Intended status: Standards Track M. Bishop Expires: 28 September 2024 E. Nygren Akamai Technologies 27 March 2024 Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings draft-ietf-tls-svcb-ech-01 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 28 September 2024. Copyright Notice Copyright (c) 2024 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 28 September 2024 [Page 1] Internet-Draft ECH in SVCB March 2024 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 28 September 2024 [Page 2] Internet-Draft ECH in SVCB March 2024 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 28 September 2024 [Page 3] Internet-Draft ECH in SVCB March 2024 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 28 September 2024 [Page 4] Internet-Draft ECH in SVCB March 2024 +========+======+====================+===========+============+ | 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-18, 4 March 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-tls- esni-18>. [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 (SVCB and HTTPS Resource Records)", 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 28 September 2024 [Page 5] Internet-Draft ECH in SVCB March 2024 [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 Meta Platforms, Inc. 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 28 September 2024 [Page 6]