draft-ietf-tls-sni-encryption-07.txt   draft-ietf-tls-sni-encryption-08.txt 
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft Private Octopus Inc. Internet-Draft Private Octopus Inc.
Intended status: Informational E. Rescorla Intended status: Informational E. Rescorla
Expires: March 26, 2020 RTFM, Inc. Expires: April 9, 2020 RTFM, Inc.
September 23, 2019 October 7, 2019
Issues and Requirements for SNI Encryption in TLS Issues and Requirements for SNI Encryption in TLS
draft-ietf-tls-sni-encryption-07 draft-ietf-tls-sni-encryption-08
Abstract Abstract
This draft describes the general problem of encrypting the Server This draft describes the general problem of encrypting the Server
Name Identification (SNI) TLS parameter. The proposed solutions hide Name Identification (SNI) TLS parameter. The proposed solutions hide
a Hidden Service behind a fronting service, only disclosing the SNI a Hidden Service behind a fronting service, only disclosing the SNI
of the fronting service to external observers. The draft lists known of the fronting service to external observers. The draft lists known
attacks against SNI encryption, discusses the current "co-tenancy attacks against SNI encryption, discusses the current "co-tenancy
fronting" solution, and presents requirements for future TLS layer fronting" solution, and presents requirements for future TLS layer
solutions. solutions.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 26, 2020. This Internet-Draft will expire on April 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. History of the TLS SNI extension . . . . . . . . . . . . . . 3 2. History of the TLS SNI extension . . . . . . . . . . . . . . 3
2.1. Unanticipated usage of SNI information . . . . . . . . . 3 2.1. Unanticipated usage of SNI information . . . . . . . . . 4
2.2. SNI encryption timeliness . . . . . . . . . . . . . . . . 4 2.2. SNI encryption timeliness . . . . . . . . . . . . . . . . 4
2.3. End-to-end alternatives . . . . . . . . . . . . . . . . . 5 2.3. End-to-end alternatives . . . . . . . . . . . . . . . . . 5
3. Security and Privacy Requirements for SNI Encryption . . . . 5 3. Security and Privacy Requirements for SNI Encryption . . . . 5
3.1. Mitigate Replay Attacks . . . . . . . . . . . . . . . . . 6 3.1. Mitigate Replay Attacks . . . . . . . . . . . . . . . . . 6
3.2. Avoid Widely Shared Secrets . . . . . . . . . . . . . . . 6 3.2. Avoid Widely Shared Secrets . . . . . . . . . . . . . . . 6
3.3. Prevent SNI-based Denial of Service Attacks . . . . . . . 6 3.3. Prevent SNI-based Denial of Service Attacks . . . . . . . 6
3.4. Do not stick out . . . . . . . . . . . . . . . . . . . . 7 3.4. Do not stick out . . . . . . . . . . . . . . . . . . . . 7
3.5. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 7 3.5. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 7
3.6. Multi-Party Security Contexts . . . . . . . . . . . . . . 7 3.6. Multi-Party Security Contexts . . . . . . . . . . . . . . 7
3.7. Supporting multiple protocols . . . . . . . . . . . . . . 8 3.7. Supporting multiple protocols . . . . . . . . . . . . . . 8
skipping to change at page 3, line 27 skipping to change at page 3, line 27
improve the privacy and reliability of TLS connections, but the improve the privacy and reliability of TLS connections, but the
design of proper SNI encryption solutions is difficult. In the past, design of proper SNI encryption solutions is difficult. In the past,
there have been multiple attempts at defining SNI encryption. These there have been multiple attempts at defining SNI encryption. These
attempts have generally floundered, because the simple designs fail attempts have generally floundered, because the simple designs fail
to mitigate several of the attacks listed in Section 3. In the to mitigate several of the attacks listed in Section 3. In the
absence of a TLS-level solution, the most popular approach to SNI absence of a TLS-level solution, the most popular approach to SNI
privacy for web services is HTTP-level fronting, which we discuss in privacy for web services is HTTP-level fronting, which we discuss in
Section 4. Section 4.
This document does not present the design of a solution, but provides This document does not present the design of a solution, but provides
guidelines for evaluating proposed solutions. The need for related guidelines for evaluating proposed solutions. (The review of HTTP-
work on the encryption of the Application Layer Protocol Negotiation level solutions in Section 4 is not an endorsement of these
(ALPN) parameters of TLS is discussed in Section 3.7.1. solutions.) The need for related work on the encryption of the
Application Layer Protocol Negotiation (ALPN) parameters of TLS is
discussed in Section 3.7.1.
2. History of the TLS SNI extension 2. History of the TLS SNI extension
The SNI extension was specified in 2003 in [RFC3546] to facilitate The SNI extension was specified in 2003 in [RFC3546] to facilitate
management of "colocation servers", in which multiple services shared management of "colocation servers", in which multiple services shared
the same IP address. A typical example would be multiple web sites the same IP address. A typical example would be multiple web sites
served by the same web server. The SNI extension carries the name of served by the same web server. The SNI extension carries the name of
a specific server, enabling the TLS connection to be established with a specific server, enabling the TLS connection to be established with
the desired server context. The current SNI extension specification the desired server context. The current SNI extension specification
can be found in [RFC6066]. can be found in [RFC6066].
skipping to change at page 4, line 26 skipping to change at page 4, line 31
o Firewalls within enterprise networks blocking web sites not deemed o Firewalls within enterprise networks blocking web sites not deemed
appropriate for work, or appropriate for work, or
o Firewalls within enterprise networks exempting specific web sites o Firewalls within enterprise networks exempting specific web sites
from Man-In-The-Middle (MITM) inspection, such as healthcare or from Man-In-The-Middle (MITM) inspection, such as healthcare or
financial sites for which inspection would intrude on the privacy financial sites for which inspection would intrude on the privacy
of employees. of employees.
The SNI is probably also included in the general collection of The SNI is probably also included in the general collection of
metadata by pervasive surveillance actors, for example to identify metadata by pervasive surveillance actors [RFC7258], for example to
services used by surveillance targets. identify services used by surveillance targets.
2.2. SNI encryption timeliness 2.2. SNI encryption timeliness
The clear-text transmission of the SNI was not flagged as a problem The clear-text transmission of the SNI was not flagged as a problem
in the security consideration sections of [RFC3546], [RFC4366], or in the security consideration sections of [RFC3546], [RFC4366], or
[RFC6066]. These specifications did not anticipate the alternative [RFC6066]. These specifications did not anticipate the alternative
usage described in Section 2.1. One reason may be that, when these usage described in Section 2.1. One reason may be that, when these
RFCs were written, the SNI information was available through a RFCs were written, the SNI information was available through a
variety of other means, such as tracking IP addresses, DNS names, or variety of other means, such as tracking IP addresses, DNS names, or
server certificates. server certificates.
skipping to change at page 11, line 39 skipping to change at page 11, line 39
The ORIGIN frame defined for HTTP/2 [RFC8336] can be used to flag The ORIGIN frame defined for HTTP/2 [RFC8336] can be used to flag
content provided by the hidden server. Secondary certificate content provided by the hidden server. Secondary certificate
authentication [I-D.ietf-httpbis-http2-secondary-certs] can be used authentication [I-D.ietf-httpbis-http2-secondary-certs] can be used
to manage authentication of hidden server content, or to perform to manage authentication of hidden server content, or to perform
client authentication before accessing hidden content. client authentication before accessing hidden content.
5. Security Considerations 5. Security Considerations
This document lists a number of attacks against SNI encryption in This document lists a number of attacks against SNI encryption in
Section 3, and also in Section 4.2, and presents a list of Section 3 and also in Section 4.2, and presents a list of
requirements to mitigate these attacks. Current HTTP-based solutions requirements to mitigate these attacks. Current HTTP-based solutions
described in Section 4 only meet some of these requirements. In described in Section 4 only meet some of these requirements. In
practice, it may well be that no solution can meet every requirement, practice, it may well be that no solution can meet every requirement,
and that practical solutions will have to make some compromises. and that practical solutions will have to make some compromises.
In particular, the requirement to not stick out presented in In particular, the requirement to not stick out presented in
Section 3.4 may have to be lifted, especially for proposed solutions Section 3.4 may have to be lifted, especially for proposed solutions
that could quickly reach large scale deployments. that could quickly reach large scale deployments.
Replacing clear text SNI transmission by an encrypted variant will Replacing clear text SNI transmission by an encrypted variant will
also thwart MITM interferences that are sometimes described as break or reduce the efficacy of the operational practices and
legitimate. As explained in Section 2.3, alternative solutions will techniques implemented in middle-boxes as described in Section 2.1.
have to be developed.
As explained in Section 2.3, alternative solutions will have to be
developed.
6. IANA Considerations 6. IANA Considerations
This draft does not require any IANA action. This draft does not require any IANA action.
7. Acknowledgements 7. Acknowledgements
A large part of this draft originates in discussion of SNI encryption A large part of this draft originates in discussion of SNI encryption
on the TLS WG mailing list, including comments after the tunneling on the TLS WG mailing list, including comments after the tunneling
approach was first proposed in a message to that list: approach was first proposed in a message to that list:
skipping to change at page 13, line 35 skipping to change at page 13, line 35
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer [RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
Security (TLS) in the Extensible Messaging and Presence Security (TLS) in the Extensible Messaging and Presence
Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
2015, <https://www.rfc-editor.org/info/rfc7590>. 2015, <https://www.rfc-editor.org/info/rfc7590>.
 End of changes. 9 change blocks. 
14 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/