draft-ietf-tls-sni-encryption-08.txt   draft-ietf-tls-sni-encryption-09.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: April 9, 2020 RTFM, Inc. Expires: April 30, 2020 RTFM, Inc.
October 7, 2019 October 28, 2019
Issues and Requirements for SNI Encryption in TLS Issues and Requirements for SNI Encryption in TLS
draft-ietf-tls-sni-encryption-08 draft-ietf-tls-sni-encryption-09
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 April 9, 2020. This Internet-Draft will expire on April 30, 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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
example, in virtual hosting solutions, multiple services can be example, in virtual hosting solutions, multiple services can be
hosted as co-tenants on the same server, and the IP address and port 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 do not uniquely identify a service. In cloud or Content Delivery
Networks (CDNs) solutions, a given platform hosts the services or Networks (CDNs) solutions, a given platform hosts the services or
servers servers of a lot of organization, and looking up to what servers servers of a lot of organization, and looking up to what
netblock an IP address belongs reveals little. However, multiplexed netblock an IP address belongs reveals little. However, multiplexed
servers rely on the Service Name Information (SNI) TLS extension servers rely on the Service Name Information (SNI) TLS extension
[RFC6066] to direct connections to the appropriate service [RFC6066] to direct connections to the appropriate service
implementation. This protocol element is transmitted in clear text. implementation. This protocol element is transmitted in clear text.
As the other methods of monitoring get blocked, monitoring focuses on As the other methods of monitoring get blocked, monitoring focuses on
the clear text SNI. The purpose of SNI encryption and privacy is to the clear text SNI. The purpose of SNI encryption is to prevent that
prevent that. and aid privacy.
Replacing clear text SNI transmission by an encrypted variant will Replacing clear text SNI transmission by an encrypted variant will
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.
skipping to change at page 5, line 18 skipping to change at page 5, line 18
certificate, or in its absence the common name component, expose the certificate, or in its absence the common name component, expose the
same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 [RFC4346], same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 [RFC4346],
and 1.2 [RFC5246], servers send certificates in clear text, ensuring and 1.2 [RFC5246], servers send certificates in clear text, ensuring
that there would be limited benefits in hiding the SNI. However, in that there would be limited benefits in hiding the SNI. However, in
TLS 1.3 [RFC8446], server certificates are encrypted in transit. TLS 1.3 [RFC8446], server certificates are encrypted in transit.
Note that encryption alone is insufficient to protect server Note that encryption alone is insufficient to protect server
certificates; see Section 3.1 for details. certificates; see Section 3.1 for details.
The decoupling of IP addresses and server names, deployment of DNS The decoupling of IP addresses and server names, deployment of DNS
privacy, and protection of server certificate transmissions all privacy, and protection of server certificate transmissions all
contribute to user privacy in the face of an [RFC3552]-style contribute to user privacy in the face of an [RFC7258]-style
adversary. Encrypting the SNI completes this push for privacy and adversary. Encrypting the SNI complements this push for privacy and
make it harder to censor or otherwise provide differential treatment make it harder to censor or otherwise provide differential treatment
to specific internet services. to specific internet services.
2.3. End-to-end alternatives 2.3. End-to-end alternatives
Deploying SNI encryption helps thwart most of the unanticipated SNI Deploying SNI encryption helps thwart most of the unanticipated SNI
usages including censorship and pervasive surveillance, but it also usages including censorship and pervasive surveillance, but it also
will break or reduce the efficacy of the operational practices and will break or reduce the efficacy of the operational practices and
techniques implemented in middle-boxes as described in Section 2.1. techniques implemented in middle-boxes as described in Section 2.1.
Most of these functions can, however, be realized by other means. Most of these functions can, however, be realized by other means.
skipping to change at page 12, line 21 skipping to change at page 12, line 21
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:
<https://mailarchive.ietf.org/arch/msg/tls/ <https://mailarchive.ietf.org/arch/msg/tls/
tXvdcqnogZgqmdfCugrV8M90Ftw>. tXvdcqnogZgqmdfCugrV8M90Ftw>.
Thanks to Daniel Kahn Gillmor for a pretty detailed review of the Thanks to Daniel Kahn Gillmor for a pretty detailed review of the
initial draft. Thanks to Bernard Aboba, Mike Bishop, Stephen initial draft. Thanks to Bernard Aboba, Mike Bishop, Alissa Cooper,
Farrell, Barry Leiba, Martin Rex, Meral Shirazipour, Martin Thomson Roman Danyliw, Stephen Farrell, Warren Kumari, Mirja Kuelewind Barry
and employees of the UK National Cyber Security Centre for their Leiba, Martin Rex, Adam Roach, Meral Shirazipour, Martin Thomson,
reviews. Eric Vyncke, and employees of the UK National Cyber Security Centre
for their reviews. Thanks to Chris Wood, Ben Kaduk and Sean Turner
for helping publish this document.
8. Informative References 8. Informative References
[domfront] [domfront]
Fifield, D., Lan, C., Hynes, R., Wegmann, P., and V. Fifield, D., Lan, C., Hynes, R., Wegmann, P., and V.
Paxson, "Blocking-resistant communication through domain Paxson, "Blocking-resistant communication through domain
fronting", DOI 10.1515/popets-2015-0009, 2015, fronting", DOI 10.1515/popets-2015-0009, 2015,
<https://www.bamsoftware.com/papers/fronting/>. <https://www.bamsoftware.com/papers/fronting/>.
[I-D.ietf-httpbis-http2-secondary-certs] [I-D.ietf-httpbis-http2-secondary-certs]
skipping to change at page 12, line 46 skipping to change at page 12, line 48
Certificate Authentication in HTTP/2", draft-ietf-httpbis- Certificate Authentication in HTTP/2", draft-ietf-httpbis-
http2-secondary-certs-04 (work in progress), April 2019. http2-secondary-certs-04 (work in progress), April 2019.
[I-D.ietf-quic-tls] [I-D.ietf-quic-tls]
Thomson, M. and S. Turner, "Using TLS to Secure QUIC", Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
draft-ietf-quic-tls-23 (work in progress), September 2019. draft-ietf-quic-tls-23 (work in progress), September 2019.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-32 (work in progress), July 1.3", draft-ietf-tls-dtls13-33 (work in progress), October
2019. 2019.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246, January 1999, RFC 2246, DOI 10.17487/RFC2246, January 1999,
<https://www.rfc-editor.org/info/rfc2246>. <https://www.rfc-editor.org/info/rfc2246>.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003,
<https://www.rfc-editor.org/info/rfc3546>. <https://www.rfc-editor.org/info/rfc3546>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, (TLS) Protocol Version 1.1", RFC 4346,
DOI 10.17487/RFC4346, April 2006, DOI 10.17487/RFC4346, April 2006,
<https://www.rfc-editor.org/info/rfc4346>. <https://www.rfc-editor.org/info/rfc4346>.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
<https://www.rfc-editor.org/info/rfc4366>. <https://www.rfc-editor.org/info/rfc4366>.
 End of changes. 8 change blocks. 
18 lines changed or deleted 15 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/