Issues and Requirements for Server Name Identification (SNI) Encryption in TLS
RFC 8744
Document | Type | RFC - Informational (July 2020; No errata) | |
---|---|---|---|
Authors | Christian Huitema , Eric Rescorla | ||
Last updated | 2020-07-28 | ||
Replaces | draft-huitema-tls-sni-encryption | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Joseph Salowey | ||
Shepherd write-up | Show (last changed 2019-01-22) | ||
IESG | IESG state | RFC 8744 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Benjamin Kaduk | ||
Send notices to | Sean Turner <sean@sn3rd.com>, Joseph Salowey <joe@salowey.net> | ||
IANA | IANA review state | IANA OK - No Actions Needed | |
IANA action state | No IANA Actions |
Internet Engineering Task Force (IETF) C. Huitema Request for Comments: 8744 Private Octopus Inc. Category: Informational July 2020 ISSN: 2070-1721 Issues and Requirements for Server Name Identification (SNI) Encryption in TLS Abstract This document describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co- tenancy" solution, and presents requirements for future TLS-layer solutions. In practice, it may well be that no solution can meet every requirement and that practical solutions will have to make some compromises. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8744. Copyright Notice Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2. History of the TLS SNI Extension 2.1. Unanticipated Usage of SNI Information 2.2. SNI Encryption Timeliness 2.3. End-to-End Alternatives 3. Security and Privacy Requirements for SNI Encryption 3.1. Mitigate Cut-and-Paste Attacks 3.2. Avoid Widely Shared Secrets 3.3. Prevent SNI-Based Denial-of-Service Attacks 3.4. Do Not Stick Out 3.5. Maintain Forward Secrecy 3.6. Enable Multi-party Security Contexts 3.7. Support Multiple Protocols 3.7.1. Hiding the Application-Layer Protocol Negotiation 3.7.2. Supporting Other Transports than TCP 4. HTTP Co-tenancy Fronting 4.1. HTTPS Tunnels 4.2. Delegation Control 4.3. Related Work 5. Security Considerations 6. IANA Considerations 7. Informative References Acknowledgements Author's Address 1. Introduction Historically, adversaries have been able to monitor the use of web services through three primary channels: looking at DNS requests, looking at IP addresses in packet headers, and looking at the data stream between user and services. These channels are getting progressively closed. A growing fraction of Internet communication is encrypted, mostly using Transport Layer Security (TLS) [RFC8446]. Progressive deployment of solutions like DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] mitigates the disclosure of DNS information. More and more services are colocated on multiplexed servers, loosening the relation between IP address and web service. For example, in virtual hosting solutions, multiple services can be hosted as co-tenants on the same server, and the IP address and port do not uniquely identify a service. In cloud or Content Delivery Network (CDN) solutions, a given platform hosts the services or servers of a lot of organizations, and looking up what netblock an IP address belongs to reveals little. However, multiplexed servers rely on the Server Name Information (SNI) TLS extension [RFC6066] to direct connections to the appropriate service implementation. This protocol element is transmitted in cleartext. As the other methods of monitoring get blocked, monitoring focuses on the cleartext SNI. The purpose of SNI encryption is to prevent that and aid privacy. Replacing cleartext SNI transmission by an encrypted variant will improve the privacy and reliability of TLS connections, but the design of proper SNI encryption solutions is difficult. In the past, there have been multiple attempts at defining SNI encryption. TheseShow full document text