Issues and Requirements for Server Name Identification (SNI) Encryption in TLS
RFC 8744

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08
• 09



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