Issues and Requirements for Server Name Identification (SNI) Encryption in TLS
RFC 8744
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. These
Show full document text