draft-huitema-tls-sni-encryption-01.txt   draft-huitema-tls-sni-encryption-02.txt 
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft Private Octopus Inc. Internet-Draft Private Octopus Inc.
Intended status: Standards Track E. Rescorla Intended status: Standards Track E. Rescorla
Expires: January 3, 2018 RTFM, Inc. Expires: January 4, 2018 RTFM, Inc.
July 2, 2017 July 3, 2017
SNI Encryption in TLS Through Tunneling SNI Encryption in TLS Through Tunneling
draft-huitema-tls-sni-encryption-01 draft-huitema-tls-sni-encryption-02
Abstract Abstract
This draft describes the general problem of encryption of the Server This draft describes the general problem of encryption of the Server
Name Identification (SNI) parameter. The proposed solutions hide a Name Identification (SNI) parameter. The proposed solutions hide a
Hidden Service behind a Fronting Service, only disclosing the SNI of Hidden Service behind a Fronting Service, only disclosing the SNI of
the Fronting Service to external observers. The draft starts by the Fronting Service to external observers. The draft starts by
listing known attacks against SNI encryption, discusses the current listing known attacks against SNI encryption, discusses the current
"co-tenancy fronting" solution, and then presents two potential TLS "co-tenancy fronting" solution, and then presents two potential TLS
layer solutions that might mitigate these attacks. layer solutions that might mitigate these attacks.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 3, 2018. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 2, line 18 skipping to change at page 2, line 18
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
1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security and Privacy Requirements for SNI Encryption . . . . 4 2. Security and Privacy Requirements for SNI Encryption . . . . 4
2.1. Mitigate Replay Attacks . . . . . . . . . . . . . . . . . 4 2.1. Mitigate Replay Attacks . . . . . . . . . . . . . . . . . 4
2.2. Avoid Widely Shared Secrets . . . . . . . . . . . . . . . 4 2.2. Avoid Widely Shared Secrets . . . . . . . . . . . . . . . 4
2.3. Prevent SNI-based Denial of Service Attacks . . . . . . . 4 2.3. Prevent SNI-based Denial of Service Attacks . . . . . . . 5
2.4. Do not stick out . . . . . . . . . . . . . . . . . . . . 5 2.4. Do not stick out . . . . . . . . . . . . . . . . . . . . 5
2.5. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 5 2.5. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 5
2.6. Proper Security Context . . . . . . . . . . . . . . . . . 6 2.6. Proper Security Context . . . . . . . . . . . . . . . . . 6
2.7. Fronting Server Spoofing . . . . . . . . . . . . . . . . 6 2.7. Fronting Server Spoofing . . . . . . . . . . . . . . . . 6
3. HTTP Co-Tenancy Fronting . . . . . . . . . . . . . . . . . . 7 3. HTTP Co-Tenancy Fronting . . . . . . . . . . . . . . . . . . 7
3.1. HTTPS Tunnels . . . . . . . . . . . . . . . . . . . . . . 7 3.1. HTTPS Tunnels . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Delegation Token . . . . . . . . . . . . . . . . . . . . 8 3.2. Delegation Token . . . . . . . . . . . . . . . . . . . . 8
4. SNI Encapsulation Specification . . . . . . . . . . . . . . . 9 4. SNI Encapsulation Specification . . . . . . . . . . . . . . . 9
4.1. Tunneling TLS in TLS . . . . . . . . . . . . . . . . . . 9 4.1. Tunneling TLS in TLS . . . . . . . . . . . . . . . . . . 9
4.2. Tunneling design issues . . . . . . . . . . . . . . . . . 12 4.2. Tunneling design issues . . . . . . . . . . . . . . . . . 12
4.2.1. Gateway logic . . . . . . . . . . . . . . . . . . . . 13 4.2.1. Gateway logic . . . . . . . . . . . . . . . . . . . . 13
4.2.2. Early data . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. Early data . . . . . . . . . . . . . . . . . . . . . 13
4.2.3. Client requirements . . . . . . . . . . . . . . . . . 14 4.2.3. Client requirements . . . . . . . . . . . . . . . . . 14
5. SNI encryption with combined tickets . . . . . . . . . . . . 14 5. SNI encryption with combined tickets . . . . . . . . . . . . 14
5.1. Session resumption with combined tickets . . . . . . . . 14 5.1. Session resumption with combined tickets . . . . . . . . 14
5.2. New Combined Session Ticket . . . . . . . . . . . . . . . 16 5.2. New Combined Session Ticket . . . . . . . . . . . . . . . 16
5.3. First session . . . . . . . . . . . . . . . . . . . . . . 18 5.3. First session . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Replay attacks and side channels . . . . . . . . . . . . 19 6.1. Replay attacks and side channels . . . . . . . . . . . . 19
6.2. Sticking out . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Sticking out . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 20 6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Historically, adversaries have been able to monitor the use of web Historically, adversaries have been able to monitor the use of web
services through three channels: looking at DNS requests, looking at services through three channels: looking at DNS requests, looking at
IP addresses in packet headers, and looking at the data stream IP addresses in packet headers, and looking at the data stream
between user and services. These channels are getting progressively between user and services. These channels are getting progressively
closed. A growing fraction of Internet communication is encrypted, closed. A growing fraction of Internet communication is encrypted,
mostly using Transport Layer Security (TLS) [RFC5246]. Progressive mostly using Transport Layer Security (TLS) [RFC5246]. Progressive
skipping to change at page 4, line 33 skipping to change at page 4, line 33
2- The adversary observes the exchange and copies the encrypted SNI 2- The adversary observes the exchange and copies the encrypted SNI
parameter. parameter.
3- The adversary starts its own connection to the multiplexed server, 3- The adversary starts its own connection to the multiplexed server,
including in its connection parameters the encrypted SNI copied from including in its connection parameters the encrypted SNI copied from
the observed exchange. the observed exchange.
4- The multiplexed server establishes the connection to the protected 4- The multiplexed server establishes the connection to the protected
service, thus revealing the identity of the service. service, thus revealing the identity of the service.
One of the goals of SNI encryption is to prevent adversaries from
knowing which Hidden Service the client is using. Successful replay
attacks breaks that goal by allowing adversaries to discover that
service.
SNI encryption designs MUST mitigate this attack. SNI encryption designs MUST mitigate this attack.
2.2. Avoid Widely Shared Secrets 2.2. Avoid Widely Shared Secrets
It is easy to think of simple schemes in which the SNI is encrypted It is easy to think of simple schemes in which the SNI is encrypted
or hashed using a shared secret. This symmetric key must be known by or hashed using a shared secret. This symmetric key must be known by
the multiplexed server, and by every users of the protected services. the multiplexed server, and by every users of the protected services.
Such schemes are thus very fragile, since the compromise of a single Such schemes are thus very fragile, since the compromise of a single
user would compromise the entire set of users and protected services. user would compromise the entire set of users and protected services.
skipping to change at page 8, line 5 skipping to change at page 8, line 12
[I-D.hoffman-dns-over-https]. The trust issue, however, requires [I-D.hoffman-dns-over-https]. The trust issue, however, requires
specific developments such as HTTP tunnels or Delegation Tokens. specific developments such as HTTP tunnels or Delegation Tokens.
3.1. HTTPS Tunnels 3.1. HTTPS Tunnels
The HTTP Fronting solution places a lot of trust in the Fronting The HTTP Fronting solution places a lot of trust in the Fronting
Server. This required trust can be reduced by tunnelling HTTPS in Server. This required trust can be reduced by tunnelling HTTPS in
HTTPS, which effectively treats the Fronting Server as an HTTP Proxy. HTTPS, which effectively treats the Fronting Server as an HTTP Proxy.
In this solution, the client establishes a TLS connection to the In this solution, the client establishes a TLS connection to the
Fronting Server, and then issues an HTTP Connect request to the Fronting Server, and then issues an HTTP Connect request to the
Hidden Server. This will effectively establish an end-to-end HTTPS Hidden Server. This will establish an end-to-end HTTPS over TLS
over TLS connection between the client and the Hidden Server, connection between the client and the Hidden Server, mitigating the
mitigating the issues described in Section 2.6. issues described in Section 2.6.
The HTTPS in HTTPS solution requires double encryption of every The HTTPS in HTTPS solution requires double encryption of every
packet. It also requires that the fronting server decrypts and relay packet. It also requires that the fronting server decrypts and relay
messages to the hidden server. Both of these requirements make the messages to the hidden server. Both of these requirements make the
implementation onerous. implementation onerous.
3.2. Delegation Token 3.2. Delegation Token
Clients would see their privacy compromised if they contacted the Clients would see their privacy compromised if they contacted the
wrong fronting server to access the hidden service, since this wrong wrong fronting server to access the hidden service, since this wrong
skipping to change at page 21, line 20 skipping to change at page 21, line 35
After the meeting, Martin Thomson suggested a modification to the After the meeting, Martin Thomson suggested a modification to the
tunnelling proposal that removes this cost. The key observation is tunnelling proposal that removes this cost. The key observation is
that if we think of the 0-RTT flight as a separate message attached that if we think of the 0-RTT flight as a separate message attached
to the handshake, then we can tunnel a second first flight in it. to the handshake, then we can tunnel a second first flight in it.
The combined ticket approach was first proposed by Cedric Fournet and The combined ticket approach was first proposed by Cedric Fournet and
Antoine Delignaut-Lavaud. Antoine Delignaut-Lavaud.
The delegation token design comes from many people, including Ben The delegation token design comes from many people, including Ben
Schwartz and Rich Salz. Schwartz, Brian Sniffen and Rich Salz.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-20 (work in progress), Version 1.3", draft-ietf-tls-tls13-20 (work in progress),
April 2017. April 2017.
 End of changes. 11 change blocks. 
14 lines changed or deleted 19 lines changed or added

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