Network Working Group                                         C. Huitema
Internet-Draft                                      Private Octopus Inc.
Intended status: Standards Track Informational                               E. Rescorla
Expires: September 2, November 21, 2018                                    RTFM, Inc.
                                                           March 1,
                                                            May 20, 2018

           Issues and Requirements for SNI Encryption in TLS Through Tunneling
                    draft-ietf-tls-sni-encryption-02
                    draft-ietf-tls-sni-encryption-03

Abstract

   This draft describes the general problem of encryption of the Server
   Name Identification (SNI) parameter.  The proposed solutions hide a
   Hidden Service behind a Fronting Service, only disclosing the SNI of
   the Fronting Service to external observers.  The draft starts by
   listing lists known
   attacks against SNI encryption, discusses the current "co-tenancy
   fronting" solution, and then presents two potential requirements for future TLS layer solutions that might mitigate these attacks.
   The first solution is based on TLS in TLS "quasi tunneling", and the
   second solution is based on "combined tickets".  These solutions only
   require minimal extensions to the TLS protocol.
   solutions.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 2, November 21, 2018.

Copyright Notice

   Copyright (c) 2018 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
   2.  History of the TLS SNI extension  . . . . . . . . . . . . . .   3
     2.1.  Unanticipated usage of SNI information  . . . . . . . . .   3
     1.1.  Key Words
     2.2.  SNI encryption timeliness . . . . . . . . . . . . . . . .   4
     2.3.  End-to-end alternatives . . . . . . . . . . . . . . . . .   4
   2.
   3.  Security and Privacy Requirements for SNI Encryption  . . . .   4
     2.1.   5
     3.1.  Mitigate Replay Attacks . . . . . . . . . . . . . . . . .   4
     2.2.   5
     3.2.  Avoid Widely Shared Secrets . . . . . . . . . . . . . . .   4
     2.3.   5
     3.3.  Prevent SNI-based Denial of Service Attacks . . . . . . .   5
     2.4.   6
     3.4.  Do not stick out  . . . . . . . . . . . . . . . . . . . .   5
     2.5.   6
     3.5.  Forward Secrecy . . . . . . . . . . . . . . . . . . . . .   5
     2.6.   6
     3.6.  Proper Security Context . . . . . . . . . . . . . . . . .   5
     2.7.   6
     3.7.  Fronting Server Spoofing  . . . . . . . . . . . . . . . .   6
     2.8.   7
     3.8.  Supporting multiple protocols . . . . . . . . . . . . . .   6
       2.8.1.   7
       3.8.1.  Hiding the Application Layer Protocol Negotiation . .   7
       2.8.2.   8
       3.8.2.  Support other transports than HTTP  . . . . . . . . .   7
     2.9.   8
     3.9.  Fail to fronting  . . . . . . . . . . . . . . . . . . . .   7
   3.   8
   4.  HTTP Co-Tenancy Fronting  . . . . . . . . . . . . . . . . . .   8
     3.1.   9
     4.1.  HTTPS Tunnels . . . . . . . . . . . . . . . . . . . . . .   9
     3.2.  10
     4.2.  Delegation Token  . . . . . . . . . . . . . . . . . . . .   9
   4.  SNI Encapsulation Specification . . . . . . Control  . . . . . . . . .  10
     4.1.  Tunneling TLS in TLS  . . . . . . . . . . . . . . . . . .  10
     4.2.  Tunneling design issues . .
   5.  Security Considerations . . . . . . . . . . . . . . .  12
       4.2.1.  Fronting Server logic . . . .  11
   6.  IANA Considerations . . . . . . . . . . . .  13
       4.2.2.  Early data . . . . . . . . .  11
   7.  Acknowledgements  . . . . . . . . . . . .  13
       4.2.3.  Client requirements . . . . . . . . . .  11
   8.  References  . . . . . . .  14
   5.  SNI encryption with combined tickets . . . . . . . . . . . .  14
     5.1.  Session resumption with combined tickets . . . . . .  11
     8.1.  Normative References  . .  14
     5.2.  New Combined Session Ticket . . . . . . . . . . . . . . .  16
     5.3.  First session .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . .  17
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
     6.1.  Replay attacks  13

1.  Introduction

   Historically, adversaries have been able to monitor the use of web
   services through three channels: looking at DNS requests, looking at
   IP addresses in packet headers, and looking at the data stream
   between user and side channels  . . . . . . . . . . . .  18
     6.2.  Sticking out  . . . . . . . . . . . . . . . . . . . . . .  19
     6.3.  Forward Secrecy . . . . . . . . . . . . . . . . . . . . .  19
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  20
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   Historically, adversaries have been able to monitor the use of web
   services through three channels: looking at DNS requests, looking at
   IP addresses in packet headers, and looking at the data stream
   between user and services.  These services.  These channels are getting progressively
   closed.  A growing fraction of Internet communication is encrypted,
   mostly using Transport Layer Security (TLS) [RFC5246].  Progressive
   deployment of solutions like DNS in TLS [RFC7858] mitigates the
   disclosure of DNS information.  More and more services are colocated
   on multiplexed servers, loosening the relation between IP address and
   web service.  However, multiplexed servers rely on the Service Name
   Information (SNI) to direct TLS connections to the appropriate
   service implementation.  This protocol element is transmitted in
   clear text.  As the other methods of monitoring get blocked,
   monitoring focuses on the clear text SNI.  The purpose of SNI
   encryption is to prevent that.

   In the past, there have been multiple attempts at defining SNI
   encryption.  These attempts have generally floundered, because the
   simple designs fail to mitigate several of the attacks listed in
   Section 2. 3.  In the absence of a TLS level solution, the most popular
   approach to SNI privacy is HTTP level fronting, which we discuss in
   Section 3. 4.

2.  History of the TLS SNI extension

   The current draft proposes two designs for SNI Encryption extension was standardized in TLS.
   Both designs hide 2003 in [RFC3546] to facilitate
   management of "colocation servers", in which a "Hidden Service" behind multiple services
   shared the same IP address.  A typical example would be mutiple web
   sites served by the same web server.  The SNI extension carries the
   name of a "Fronting Service".  To
   an external observer, specific server, enabling the TLS connections will appear connection to be directed
   towards
   established with the Fronting Service. desired server context.  The cleartext SNI parameter will
   document the Fronting Service.  A second current SNI parameter will
   extension specification can be
   transmitted found in an encrypted form to [RFC6066].

   The SNI specification allowed for different types of server names,
   but only the Fronting Service, "hostname" variant was standardized and will
   allow deployed.  In
   that service to redirect variant, the connection towards SNI extension carries the Hidden
   Service. domain name of the target
   server.  The first design relies on tunneling TLS SNI extension is carried in TLS, as explained clear text in
   Section 4.  It does not require the TLS extensions,
   "Client Hello" message.

2.1.  Unanticipated usage of SNI information

   The SNI was defined to facilitate management of servers, but relies on
   conventions in the implementation
   developer of middleboxes soon found out that they could take
   advantage of TLS 1.3 [I-D.ietf-tls-tls13] by
   the Client and the Fronting Server.

   The second design, presented information.  Many examples of such usage are
   reviewed in Section 5 removes the requirement for
   tunneling, on simply relies on Combined Tickets.  It uses the
   extension process for session tickets already defined [I-D.mm-wg-effect-encrypt].  They include:

   o  Censorship of specific sites by "national firewalls",

   o  Content filtering by ISP blocking specific web sites in
   [I-D.ietf-tls-tls13].

   This draft is presented order to
      implement "parental controls", or to prevent access to fraudulent
      web sites, such as is used for phishing,

   o  ISP assigning different QOS profiles to trigger discussions.  It is expected
   that target services,

   o  Enterprise firewalls blocking web sites not deemed appropriate for
      work,

   o  Enterprise firewalls exempting specific web sites from MITM
      inspection, such as healthcare or financial sites for which
      inspection would intrude with the draft progresses, only one privacy of the two proposed solutions
   will be retained.

1.1.  Key Words employees.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Security and Privacy Requirements for SNI Encryption

   Over is probably also included in the past years, there have been multiple proposals to add an SNI
   encryption option in TLS.  Many of these proposals appeared
   promising, but were rejected after security reviews pointed plausible
   attacks.  In this section, we collect a list general collection of these known attacks.

2.1.  Mitigate Replay Attacks

   The simplest
   metadata by pervasive surveillance actors.

2.2.  SNI encryption designs replace in the initial TLS
   exchange timeliness

   The clear-text transmission of the clear text SNI with an encrypted value, using was not flagged as a key
   known to problem
   in the multiplexed server.  Regardless security consideration sections of [RFC3546], [RFC4366], or
   [RFC6066].  These specifications did not anticipate the encryption used, abuses
   described in Section 2.1.  One reason may be that, when these designs RFCs
   were written, the SNI information was available through a variety of
   other means.

   Many deployments still allocate different IP addresses to different
   services, so that different services can be broken identified by their IP
   addresses.  However, content distribution networks (CDN) commonly
   serve a simple replay attack, which works as
   follow:

   1- The user starts large number of services through a TLS connection to the multiplexed server,
   including an encrypted SNI value.

   2- small number of addresses.

   The adversary observes the exchange and copies the encrypted SNI
   parameter.

   3- The adversary starts its own connection to carries the domain name of the multiplexed server,
   including in its connection parameters which is also sent as
   part of the DNS queries.  Most of the encrypted SNI copied from usage described in
   Section 2.1 could also be implemented by monitoring DNS traffic or
   controlling DNS usage.  But this is changing with the observed exchange.

   4- advent of DNS
   resolvers providing services like DNS over TLS [RFC7858] or DNS over
   HTTPS [I-D.ietf-doh-dns-over-https].

   The multiplexed server establishes the connection to common name component of the protected
   service, thus revealing server certificate generally exposes
   the identity of same name as the service.

   One of SNI.  In TLS versions 1.0 [RFC2246], 1.1
   [RFC4346], and 1.2 [RFC5246], 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 server send their certificate in
   clear text, ensuring that
   service.

2.2.  Avoid Widely Shared Secrets

   It is easy to think of simple schemes there would be limited benefits in which hiding
   the SNI is encrypted
   or hashed using a shared secret.  This symmetric key must be known by SNI.  But the multiplexed server, and by every users transmission of the server certificate is protected services.
   Such schemes are thus very fragile, since the compromise
   in TLS 1.3 [I-D.ietf-tls-tls13].

   The decoupling of a single
   user would compromise IP addresses and server names, the entire set deployment of users
   DNS privacy, and protected services.

2.3.  Prevent SNI-based Denial the protection of Service Attacks server certificates transmissions
   all contribute to user privacy.  Encrypting the SNI may create extra load now will complete
   this push for the multiplexed server.
   Adversaries may mount denial of service attacks by generating random
   encrypted SNI values privacy and forcing the multiplexed server make it much harder to spend
   resources censor specific
   internet services.

2.3.  End-to-end alternatives

   Deploying SNI encryption will help thwarting most the "unanticipated"
   SNI usages described in useless decryption attempts. Section 2.1, including censorship and
   pervasive surveillance.  It may be argued will also thwart functions that this is not an important DOS avenue, are
   sometimes described as regular
   TLS connection attempts also require the server to perform a number legitimate.  Most of cryptographic operations.  However, in many cases, these functions can
   however be realized by other means.  For example, some DNS service
   providers offer customers the SNI
   decryption will have provision to "opt in" filtering
   services for parental control and phishing protection.  Per stream
   QoS can be performed provided by a front combination of packet marking and end component with
   limited resources, while the TLS operations are performed by the
   component dedicated to their respective services.  SNI based DOS
   attacks could target the front end component.

2.4.  Do not stick out

   In some designs, handshakes using SNI encryption
   agreements.  Enterprises can be easily
   differentiated from "regular" handshakes.  For example, some designs
   require specific extensions in the Client Hello packets, or specific
   values deploy monitoring software to control
   usage of the clear text enterprises computers.  As SNI parameter.  If adversaries encryption becomes
   common, we can easily
   detect the use expect more deployment of such "end to end" solutions.

3.  Security and Privacy Requirements for SNI encryption, they could block it, or they could
   flag Encryption

   Over the users of past years, there have been multiple proposals to add an SNI
   encryption for special treatment. option in TLS.  Many of these proposals appeared
   promising, but were rejected after security reviews pointed plausible
   attacks.  In the future, it might be possible to assume that this section, we collect a large fraction list of TLS handshakes use these known attacks.

3.1.  Mitigate Replay Attacks

   The simplest SNI encryption.  If that was encryption designs replace in the case, initial TLS
   exchange the
   detection of clear text SNI encryption would be with an encrypted value, using a lesser concern.  However, we
   have key
   known to assume that in the near future, only a small fraction multiplexed server.  Regardless of TLS
   connections will use SNI encryption.

2.5.  Forward Secrecy

   The general concerns about forward secrecy apply to SNI the encryption
   just as well as to regular TLS sessions.  For example, some proposed used,
   these designs rely on can be broken by a public key of the multiplexed server simple replay attack, which works as
   follow:

   1- The user starts a TLS connection to define the multiplexed server,
   including an encrypted SNI encryption key.  If value.

   2- The adversary observes the corresponding private key was
   compromised, exchange and copies the adversaries would be able encrypted SNI
   parameter.

   3- The adversary starts its own connection to process archival
   records of past connections, and retrieve the protected SNI used multiplexed server,
   including in
   these connections.  These designs failed to maintain forward secrecy
   of its connection parameters the encrypted SNI encryption.

2.6.  Proper Security Context

   We can design solutions in which copied from
   the observed exchange.

   4- The multiplexed server or a fronting
   service act as a relay establishes the connection to reach the protected service.  Some
   service, thus revealing the identity of those
   solutions involve just one TLS handshake between the client and service.

   One of the
   multiplexed server, or between goals of SNI encryption is to prevent adversaries from
   knowing which Hidden Service the client and the fronting service.

   The master secret is verified by verifying a certificate provided by
   either of these entities, but not using.  Successful replay
   attacks breaks that goal by the protected allowing adversaries to discover that
   service.

   These solutions expose the client

3.2.  Avoid Widely Shared Secrets

   It is easy to think of simple schemes in which the SNI is encrypted
   or hashed using a Man-In-The-Middle attack shared secret.  This symmetric key must be known by
   the multiplexed server or server, and by every users of the fronting service.  Even if protected services.
   Such schemes are thus very fragile, since the
   client has some reasonable trust in these services, compromise of a single
   user would compromise the possibility entire set of MITM attack is troubling.

   The multiplexed server or users and protected services.

3.3.  Prevent SNI-based Denial of Service Attacks

   Encrypting the fronting services could be pressured SNI may create extra load for the multiplexed server.
   Adversaries may mount denial of service attacks by
   adversaries.  By design, they could be forced to deny access to the
   protected service, or to divulge which client accessed it.  But if
   MITM is possible, the adversaries would also be able to pressure them
   into intercepting or spoofing the communications between client and
   protected service.

2.7.  Fronting Server Spoofing

   Adversaries could mount an attack by spoofing the Fronting Service.
   A spoofed Fronting Service could act as a "honeypot" for users of
   hidden services.  At a minimum, the fake server could record the IP
   addresses of these users.  If the SNI encryption solution places too
   much trust on the fronting server, the fake server could also serve
   fake content of its own choosing, including various forms of malware.

   There are two main channels by which adversaries can conduct this
   attack.  Adversaries can simply try to mislead users into believing
   that the honeypot is a valid Fronting Server, especially if that
   information is carried by word of mouth or in unprotected DNS
   records.  Adversaries can also attempt to hijack the traffic to the
   regular Fronting Server, using for example spoofed DNS responses or
   spoofed IP level routing, combined with a spoofed certificate.

2.8.  Supporting multiple protocols

   The SNI encryption requirement do not stop with HTTP over TLS.
   Multiple other applications currently use TLS, including for example
   SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590].  These applications
   too will benefit of SNI encryption.  HTTP only methods like those
   described in Section 3.1 would not apply there.  In fact, even for
   the HTTPS case, the HTTPS tunneling service described in Section 3.1
   is compatible with HTTP 1.0 and HTTP 1.1, but interacts awkwardly
   with the multiple streams feature of HTTP 2.0 [RFC7540].  This points
   to the need of an application agnostic solution, that would be
   implemented fully in the TLS layer.

2.8.1.  Hiding the Application Layer Protocol Negotiation

   The Application Layer Protocol Negotiation (ALPN) parameters of TLS
   allow implementations to negotiate the application layer protocol
   used on a given connection.  TLS provides the ALPN values in clear
   text during the initial handshake.  While exposing the ALPN does not
   create the same privacy issues as exposing the SNI, there is still a
   risk.  For example, some networks may attempt to block applications
   that they do not understand, or that they wish users would not use.

   In a sense, ALPN filtering could be very similar to the filtering of
   specific port numbers exposed in some network.  This filtering by
   ports has given rise to evasion tactics in which various protocols
   are tunneled over HTTP in order to use open ports 80 or 443.
   Filtering by ALPN would probably beget the same responses, in which
   the applications just move over HTTP, and only the HTTP ALPN values
   are used.  Applications would not need to do that if the ALPN was
   hidden in the same way as the SNI.

   It is thus desirable that SNI Encryption mechanisms be also able hide
   the ALPN.

2.8.2.  Support other transports than HTTP

   The TLS handshake is also used over other transports such as UDP with
   both DTLS [I-D.ietf-tls-dtls13] and QUIC [I-D.ietf-quic-tls].  The
   requirement to encrypt the SNI apply just as well for these
   transports as for TLS over TCP.

   This points to a requirement for SNI Encryption mechanisms to also be
   applicable to non-TCP transports such as DTLS or QUIC.

2.9.  Fail to fronting

   It is easy to imagine designs in which the client sends some client
   hello extension that points to a secret shared by client and hidden
   server.  If that secret is incorporated into the handshake secret,
   the exchange will only succeeds if the connection truly ends at the
   hidden server.  The exchange will fail if the extension is stripped
   by an MITM, and the exchange will also fail if an adversary replays
   the extension in a Client Hello.

   The problem with that approach is clear.  Adversaries that replay the
   extension can test whether the client truly wanted to access the
   fronting server, or was simply using that fronting server as an
   access gateway to something else.  The adversaries will not know what
   hidden service the client was trying to reach, but they can guess.

   They can also start directly interrogate the user, or other
   unpleasant alternatives.

   When designing SNI encryption schemes, we have to take into account
   attacks that strip parameters from the Client Hello, or replay
   attacks.  In both cases, the desired behavior is to fall back to a
   connection with the fronting server, so there is no visble difference
   between a regular connection to that server and an atempt to reach
   the hidden server.

3.  HTTP Co-Tenancy Fronting

   In the absence of TLS level SNI encryption, many sites rely on an
   "HTTP Co-Tenancy" solution.  The TLS connection is established with
   the fronting server, and HTTP requests are then sent over that
   connection to the hidden service.  For example, the TLS SNI could be
   set to "fronting.example.com", the fronting server, and HTTP requests
   sent over that connection could be directed to "hidden.example.com/
   some-content", accessing the hidden service.  This solution works
   well in practice when the fronting server and the hidden server are
   'co-tenant" of the same multiplexed server.

   The HTTP fronting solution can be deployed without modification to
   the TLS protocol, and does not require using and specific version of
   TLS.  There are however a few issues regarding discovery, client
   implementations, trust, and applicability:

   o  The client has to discover that the hidden service can be accessed
      through the fronting server.

   o  The client browser's has to be directed to access the hidden
      service through the fronting service.

   o  Since the TLS connection is established with the fronting service,
      the client has no proof that the content does in fact come from
      the hidden service.  The solution does thus not mitigate the
      context sharing issues described in Section 2.6.

   o  Since this is an HTTP level solution, it would not protected non
      HTTP protocols such as DNS over TLS [RFC7858] or IMAP over TLS
      [RFC2595].

   The discovery issue is common to pretty much every SNI encryption
   solution, and is also discussed in Section 4.2.3 and Section 5.3.
   The browser issue may be solved by developing a browser extension
   that support HTTP Fronting, and manages the list of fronting services
   associated with the hidden services that the client uses.  The multi-
   protocol issue can be mitigated by using implementation of other
   applications over HTTP, such as for example DNS over HTTPS
   [I-D.hoffman-dns-over-https].  The trust issue, however, requires
   specific developments.

3.1.  HTTPS Tunnels

   The HTTP Fronting solution places a lot of trust in the Fronting
   Server.  This required trust can be reduced by tunnelling HTTPS in
   HTTPS, which effectively treats the Fronting Server as an HTTP Proxy.
   In this solution, the client establishes a TLS connection to the
   Fronting Server, and then issues an HTTP Connect request to the
   Hidden Server.  This will establish an end-to-end HTTPS over TLS
   connection between the client and the Hidden Server, mitigating the
   issues described in Section 2.6.

   The HTTPS in HTTPS solution requires double encryption of every
   packet.  It also requires that the fronting server decrypts and relay
   messages to the hidden server.  Both of these requirements make the
   implementation onerous.

3.2.  Delegation Token

   Clients would see their privacy compromised if they contacted the
   wrong fronting server to access the hidden service, since this wrong
   server could disclose their access to adversaries.  This can possibly
   be mitigated by recording the relation between fronting server and
   hidden server in a Delegation Token.

   The delegation token would be a form of certificate, signed by the
   hidden service.  It would have the following components:

   o  The DNS name of the fronting service

   o  TTL (i.e. expiration date)

   o  An indication of the type of access that would be used, such as
      direct fronting in which the hidden content is directly served by
      the fronting server, or HTTPS in HTTPS, or one of the TLS level
      solutions discussed in Section 4 and Section 5

   o  Triple authentication, to make the barrier to setting up a
      honeypot extremely high

      1.  Cert chain for hidden server certificate (e.g.,
          hidden.example.com) up to CA.

      2.  Certificate transparency proof of the hidden service
          certificate (hidden.example.com) from a popular log, with a
          requirement that the browser checks the proof before
          connecting.

      3.  A TLSA record for hidden service domain name
          (hidden.example.com), with full DNSSEC chain (also mandatory
          to check)

   o  Possibly, a list of valid addresses of the fronting service.

   o  Some extension mechanism for other bits

   If N multiple domains on a CDN are acceptable fronts, then we may
   want some way to indicate this without publishing and maintaining N
   separate tokens.

   Delegation tokens could be published by the fronting server, in
   response for example to a specific query by a client.  The client
   would then examine whether one of the Delegation Tokens matches the
   hidden service that it wants to access.

   QUESTION: Do we need a revocation mechanism?  What if a fronting
   service obtains a delegation token, and then becomes untrustable for
   some other reason?  Or is it sufficient to just use short TTL?

4.  SNI Encapsulation Specification

   We propose to provide SNI Privacy by using a form of TLS
   encapsulation.  The big advantage of this design compared to previous
   attempts is that it requires effectively no changes to TLS 1.3.  It
   only requires a way to signal to the Fronting Server server that the
   encrypted application data is actually a ClientHello which is
   intended for the hidden service.  Once the tunneled session is
   established, encrypted packets will be forwarded to the Hidden
   Service without requiring encryption or decryption by the Fronting
   Service.

4.1.  Tunneling TLS in TLS

   The proposed design is to encapsulate a second Client Hello in the
   early data of a TLS connection to the Fronting Service.  To the
   outside, it just appears that the client is resuming a session with
   the fronting service.

       Client                  Fronting Service         Hidden Service
       ClientHello
       + early_data
       + key_share*
       + psk_key_exchange_modes
       + pre_shared_key
       + SNI = fronting
       (
        //Application data
        ClientHello#2
         + KeyShare
         + signature_algorithms*
         + psk_key_exchange_modes*
         + pre_shared_key*
         + SNI = hidden
       )
                         -------->
                              ClientHello#2
                              + KeyShare
                              + signature_algorithms*
                              + psk_key_exchange_modes*
                              + pre_shared_key*
                              + SNI = hidden  ---->

       <Application Data*>
       <end_of_early_data>    -------------------->
                                                           ServerHello
                                                     +  pre_shared_key
                                                          + key_share*
                                                 {EncryptedExtensions}
                                                 {CertificateRequest*}
                                                        {Certificate*}
                                                  {CertificateVerify*}
                                                            {Finished}
                              <--------------------
       {Certificate*}
       {CertificateVerify*}
       {Finished}             ---------------------

       [Application Data]     <-------------------> [Application Data]

       Key to brackets:

       *  optional messages, not present in all scenarios
       () encrypted with Client->Fronting 0-RTT key
       <> encrypted with Client->Hidden 0-RTT key
       {} encrypted with Client->Hidden 1-RTT handshake
       [] encrypted with Client->Hidden 1-RTT key

   The way this works is that the Fronting Server decrypts the _data_ in
   the client's first flight, which is actually ClientHello#2 from the
   client, containing the true SNI and then passes it on to the Hidden
   server.  However, the Hidden Server responds with its own ServerHello
   which the Fronting Server just passes unchanged, because it's
   actually the response to ClientHello#2 rather than to ClientHello#1.
   As long as ClientHello#1 and ClientHello#2 are similar (e.g.,
   differing only in the client's actual share (though of course it must
   be in the same group)), SNI, and maybe EarlyDataIndication), then an
   attacker should not be able to distinguish these cases -- although
   there may be possible attacks through timing analysis, or by
   observing traffic between the Fronting Server and Hidden Server if
   they are not colocated.

4.2.  Tunneling design issues

   The big advantage of this design is that it requires effectively no
   changes to TLS.  It only requires a way to signal to the Fronting
   Server that the encrypted application data is actually a ClientHello
   which is intended for the hidden service.

   The major disadvantage of this overall design strategy (however it's
   signaled) is that it's somewhat harder to implement in the co-
   tenanted cases than the simple schemes that carry the "real SNI" in
   an encrypted parameter of the Client Hello.  That means that it's
   somewhat less likely that servers will implement it "by default" and
   more likely that they will have to take explicit effort to allow
   Encrypted SNI.  Conversely, however, these schemes (aside from a
   server with a single wildcard or multi-SAN cert) involve more changes
   to TLS to deal with issues like "what is the server cert that is
   digested into the keys", and that requires more analysis, so there is
   an advantage to deferring that.  If we have EncryptedExtensions in
   the client's first flight it would be possible to define a "Real SNI"
   extension later if/when we had clearer analysis for that case.

   Notes on several obvious technical issues:

   1.  How does the Fronting Server distinguish this case from where the
       initial flight is actual application data?  See Section 4.2.1 for
       some thoughts on this.

   2.  Can we make this work with 0-RTT data from the client to the
       Hidden server?  The answer is probably yes, as discussed in
       Section 4.2.2.

   3.  What happens if the Fronting Server doesn't gateway, e.g.,
       because it has forgotten the ServerConfiguration?  In that case,
       the client gets a handshake with the Fronting Server, which it
       will have to determine via trial decryption.  At this point the
       Fronting Server supplies a ServerConfiguration and the client can
       reconnect as above.

   4.  What happens if the client does 0-RTT inside 0-RTT (as in #2
       above) and the Hidden server doesn't recognize the
       ServerConfiguration in ClientHello#2?  In this case, the client
       gets a 0-RTT rejection and it needs to do trial decryption to
       know whether the rejection was from the Fronting Server or the
       Hidden server.

   5.  What happens if the Fronting Server is under a DOS attack, and
       chooses to refuse all 0-RTT data?

   The client part of that logic, including the handling of question #3
   above, is discussed in Section 4.2.3.

4.2.1.  Fronting Server logic

   The big advantage of this design is that it requires effectively no
   changes to TLS.  It only requires a way to signal to the Fronting
   Server that the encrypted application data is actually a ClientHello
   which is intended for the hidden service.  The two most obvious
   designs are:

   o  Have an EncryptedExtension which indicates that the inner data is
      tunnelled.

   o  Have a "tunnelled" TLS content type.

   EncryptedExtensions would be the most natural, but they were removed
   from the ClientHello during the TLS standardization.  In Section 4.1
   we assume that the second ClientHello is just transmitted as 0-RTT
   data, and that the servers use some form of pattern matching to
   differentiate between this second ClientHello and other application
   messages.

4.2.2.  Early data

   In the proposed design, the second ClientHello is sent to the
   Fronting Server as early data, encrypted with Client->Fronting 0-RTT
   key.  If the Client follows the second ClientHello with 0-RTT data,
   that data could in theory be sent in two ways:

   1.  The client could use double encryption.  The data is first
       encrypted with the Client->Hidden 0-RTT key, then wrapped and generating random
   encrypted with the Client->Fronting 0-RTT key.  The Fronting
       server would decrypt, unwrap and relay.

   2.  The client could just encrypt the data with the Client->Hidden
       0-RTT key, SNI values and ask forcing the multiplexed server to blindly relay it.

   Each of these ways has its issues.  The double encryption scenario
   would require two end of early data messages, one double encrypted
   and relayed by the Fronting Server to the Hidden Server, and another
   sent from Client to Fronting Server, to delimit the end of the double
   encrypted stream, and also to ensure spend
   resources in useless decryption attempts.

   It may be argued that the stream of messages this is not distinguishable from simply sending 0-RTT data to the Fronting
   server.  The blind relaying is simpler, and is the scenario described
   in the diagram of Section 4.1.  In that scenario, an important DOS avenue, as regular
   TLS connection attempts also require the Fronting server
   switches to relaying mode immediately after unwrapping and forwarding
   the second ClientHello. perform a number
   of cryptographic operations.  However, in many cases, the blind relaying requires the
   ClientHello SNI
   decryption will have to be isolated to performed by a single record.

4.2.3.  Client requirements

   In order to use front end component with
   limited resources, while the tunneling service, TLS operations are performed by the client needs
   component dedicated to identify their respective services.  SNI based DOS
   attacks could target the front end component.

3.4.  Do not stick out

   In some designs, handshakes using SNI encryption can be easily
   differentiated from "regular" handshakes.  For example, some designs
   require specific extensions in the Fronting Service willing to tunnel to Client Hello packets, or specific
   values of the Hidden Service.  We clear text SNI parameter.  If adversaries can
   assume that the client will learn easily
   detect the identity use of suitable Fronting
   Services from SNI encryption, they could block it, or they could
   flag the Hidden Service itself. users of SNI encryption for special treatment.

   In order to tunnel the second ClientHello as 0-RTT data, the client
   needs future, it might be possible to have assume that a shared secret with the Fronting Service.  To avoid
   the trap large fraction
   of "well known shared secrets" described in Section 2.2,
   this should be a pair wise secret.  The most practical solution is to TLS handshakes use a session resumption ticket.  This requires SNI encryption.  If that prior to the
   tunneling attempt, was the client establishes regular connections with case, the fronting service and obtains one or several session resumption
   tickets.

5.
   detection of SNI encryption with combined tickets

   EDITOR'S NOTE: This section is an alternative design would be a lesser concern.  However, we
   have to Section 4.
   As assume that in the draft progresses, near future, only one a small fraction of the alternatives will be
   selected, and the text corresponding to the other alternative TLS
   connections will be
   deleted.

   We propose to provide use SNI Privacy by relying solely on "combined
   tickets". encryption.

3.5.  Forward Secrecy

   The big advantage of this design compared general concerns about forward secrecy apply to previous
   attempts is that it requires only minimal changes SNI encryption
   just as well as to implementations
   of regular TLS 1.3.  These changes are confined to the handling sessions.  For example, some proposed
   designs rely on a public key of the
   combined ticket by Fronting and Hidden service, and multiplexed server to define the signaling
   of the Fronting
   SNI to the client by encryption key.  If the Hidden service.

5.1.  Session resumption with combined tickets

   In this example, corresponding private key was
   compromised, the client obtains a combined session resumption
   ticket during a previous connection adversaries would be able to the hidden service, process archival
   records of past connections, and has
   learned retrieve the protected SNI used in
   these connections.  These designs failed to maintain forward secrecy
   of SNI encryption.

3.6.  Proper Security Context

   We can design solutions in which the multiplexed server or a fronting service.  The session resumption will
   happen
   service act as follows:

      Client                    Fronting Service         Hidden Service
      ClientHello
      + early_data
      + key_share*
      + psk_key_exchange_modes
      + pre_shared_key
      + SNI = fronting
                        -------->
                             // Decode the ticket
                             // Forwards a relay to hidden
                             ClientHello  ------->

      (Application Data*)  ---------------------->
                                                          ServerHello
                                                    +  pre_shared_key
                                                         + key_share*
                                                {EncryptedExtensions}
                                                        + early_data*
                                                           {Finished}
                           <---------------------- [Application Data]
      (EndOfEarlyData)
      {Finished}           ---------------------->

      [Application Data]   <---------------------> [Application Data]

      +  Indicates noteworthy extensions sent in reach the
         previously noted message.
      *  Indicates optional or situation-dependent
         messages/extensions that are not always sent.
      () encrypted with Client->Hidden 0-RTT key
      {} encrypted with Client->Hidden 1-RTT protected service.  Some of those
   solutions involve just one TLS handshake
      [] encrypted with Client->Hidden 1-RTT key

   The Fronting server that receives the Client Hello will find the
   combined ticket in between the pre_shared_key extensions, just as it would in
   a regular session resumption attempt.  When parsing client and the ticket,
   multiplexed server, or between the
   Fronting server will discover that client and the session really fronting service.

   The master secret is meant to be
   resumed with verified by verifying a certificate provided by
   either of these entities, but not by the Hidden server.  It will arrange for all protected service.

   These solutions expose the
   connection data to be forwarded client to the Hidden server, including
   forwarding a copy of Man-In-The-Middle attack by
   the initial Client Hello.

   The Hidden multiplexed server will receive the Client Hello.  It will obtain the
   identity of the Fronting service from or by the SNI parameter.  It will
   then parse fronting service.  Even if the session resumption ticket, and proceed with
   client has some reasonable trust in these services, the
   resumption possibility
   of MITM attack is troubling.

   The multiplexed server or the session.

   In this fronting services could be pressured by
   adversaries.  By design, they could be forced to deny access to the Client Hello message is relayed unchanged from
   Fronting server
   protected service, or to hidden server.  This ensures that code changes are
   confined divulge which client accessed it.  But if
   MITM is possible, the adversaries would also be able to pressure them
   into intercepting or spoofing the interpretation of communications between client and
   protected service.

3.7.  Fronting Server Spoofing

   Adversaries could mount an attack by spoofing the message parameters.  The
   construction Fronting Service.
   A spoofed Fronting Service could act as a "honeypot" for users of handshake contexts is left unchanged.

5.2.  New Combined Session Ticket

   In normal TLS 1.3 operations,
   hidden services.  At a minimum, the fake server can send New Session Ticket
   messages at any time after could record the receiving IP
   addresses of these users.  If the Client Finished message.
   The ticket structure is defined in TLS 1.3 as:

                     struct {
                         uint32 ticket_lifetime;
                         uint32 ticket_age_add;
                         opaque ticket_nonce<1..255>;
                         opaque ticket<1..2^16-1>;
                         Extension extensions<0..2^16-2>;
                     } NewSessionTicket;

   When SNI encryption is enabled, tickets will carry a "Fronting SNI"
   extension, and the ticket value itself will be negotiated between
   Fronting Service and Hidden Service, as in:

    Client                    Fronting Service         Hidden Service

                                          <=======   <Ticket Request>
                          Combined Ticket =======>
                                                  [New Session Ticket
                         <------------------------    + SNI Extension]

      <==> sent solution places too
   much trust on connection between Hidden and Fronting service
      <>   encrypted with Fronting<->Hidden key
      [] encrypted with Client->Hidden 1-RTT key

   In theory, the actual format of fronting server, the ticket fake server could be set also serve
   fake content of its own choosing, including various forms of malware.

   There are two main channels by mutual
   agreement between Fronting Service and Hidden Service.  In practice,
   it is probably better which adversaries can conduct this
   attack.  Adversaries can simply try to provide guidance, as mislead users into believing
   that the ticket must meet
   three requirements:

   o  The honeypot is a valid Fronting Server must understand enough Server, especially if that
   information is carried by word of the combined ticket mouth or in unprotected DNS
   records.  Adversaries can also attempt to relay hijack the connection towards traffic to the Hidden Server;

   o
   regular Fronting Server, using for example spoofed DNS responses or
   spoofed IP level routing, combined with a spoofed certificate.

3.8.  Supporting multiple protocols

   The Hidden Server must understand enough SNI encryption requirement do not stop with HTTP over TLS.
   Multiple other applications currently use TLS, including for example
   SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590].  These applications
   too will benefit of SNI encryption.  HTTP only methods like those
   described in Section 4.1 would not apply there.  In fact, even for
   the combined ticket to
      resume HTTPS case, the session HTTPS tunneling service described in Section 4.1
   is compatible with HTTP 1.0 and HTTP 1.1, but interacts awkwardly
   with the client;

   o  Third parties must not be able multiple streams feature of HTTP 2.0 [RFC7540].  This points
   to deduce the name need of an application agnostic solution, that would be
   implemented fully in the Hidden
      Service from TLS layer.

3.8.1.  Hiding the value Application Layer Protocol Negotiation

   The Application Layer Protocol Negotiation (ALPN) parameters of TLS
   allow implementations to negotiate the ticket.

   There are three plausible designs, a stateful design, a shared key
   design, and application layer protocol
   used on a
   In the stateful design, the ticket are just random numbers that given connection.  TLS provides the
   Fronting server associates with ALPN values in clear
   text during the Hidden server, and initial handshake.  While exposing the Hidden
   server associates with ALPN does not
   create the session context.  The shared key design
   would work same privacy issues as follow:

   o  the hidden server and exposing the fronting server share SNI, there is still a symmetric key
      K_sni.

   o  the "clear text" ticket includes
   risk.  For example, some networks may attempt to block applications
   that they do not understand, or that they wish users would not use.

   In a nonce, the ordinary ticket used
      for session resumption by the hidden service, and the id of the
      Hidden service for the Fronting Service.

   o  the ticket will sense, ALPN filtering could be encrypted with AEAD, using the nonce as an IV.

   o  When very similar to the client reconnects filtering of
   specific port numbers exposed in some network.  This filtering by
   ports has given rise to evasion tactics in which various protocols
   are tunneled over HTTP in order to use open ports 80 or 443.
   Filtering by ALPN would probably beget the fronting server, it decrypts same responses, in which
   the
      ticket using K_sni and if it succeeds, then it applications just forwards move over HTTP, and only the
      Client Hello HTTP ALPN values
   are used.  Applications would not need to do that if the ALPN was
   hidden server indicated in id-hidden-service
      (which of course has to know to ignore SNI).  Otherwise, it
      terminates the connection itself with its own SNI.

   The hidden server can just refresh the ticket any time it pleases, same way as
   usual.

   This design allows the Hidden Service to hide behind many Fronting
   Services, each using a different key.  The Client Hello received by
   the Hidden Server carries the SNI.

   It is thus desirable that SNI of the Fronting Service, which the
   Hidden Server can use to select the appropriate K_sni.

   In the public key design, the Hidden Server encrypts the tickets with
   a public key of Encryption mechanisms be also able hide
   the Fronting Server. ALPN.

3.8.2.  Support other transports than HTTP

   The ticket itself would be
   similar to what TLS handshake is also used in the shared key design.  The compute cost
   for a single decryption may be higher, but the Fronting Server would
   not need to blindly try multiple decryption keys associated over other transports such as UDP with
   multiple Hidden Servers.
   both DTLS [I-D.ietf-tls-dtls13] and QUIC [I-D.ietf-quic-tls].  The Hidden Server would not be able
   requirement to
   decrypt encrypt the ession Tickets, which means that it would have SNI apply just as well for these
   transports as for TLS over TCP.

   This points to rely on
   some kind of stateful storage.

5.3.  First session

   The previous sections present how sessions can a requirement for SNI Encryption mechanisms to also be resumed with the
   combined ticket.  Clients have that have never contacted the Hidden
   Server will need
   applicable to non-TCP transports such as DTLS or QUIC.

3.9.  Fail to obtain a first ticket during a first session.
   The most plausible option fronting

   It is easy to have imagine designs in which the client directly connect sends some client
   hello extension that points to a secret shared by client and hidden
   server.  If that secret is incorporated into the Hidden Service, handshake secret,
   the exchange will only succeeds if the connection truly ends at the
   hidden server.  The exchange will fail if the extension is stripped
   by an MITM, and then ask for the exchange will also fail if an adversary replays
   the extension in a combined ticket. Client Hello.

   The obvious
   issue problem with that approach is clear.  Adversaries that replay the SNI will not be encrypted for this first
   connection, which exposes
   extension can test whether the client truly wanted to surveillance and censorship. access the
   fronting server, or was simply using that fronting server as an
   access gateway to something else.  The adversaries will not know what
   hidden service the client may was trying to reach, but they can guess.

   They can also learn about start directly interrogate the relation between Fronting Service
   and Hidden Service through an out of band channel, such as DNS
   service, user, or word of mouth.  However, it other
   unpleasant alternatives.

   When designing SNI encryption schemes, we have to take into account
   attacks that strip parameters from the Client Hello, or replay
   attacks.  In both cases, the desired behavior is difficult to establish fall back to a
   combined ticket completely out of band, since
   connection with the ticket must be
   associated fronting server, so there is no visble difference
   between a regular connection to two shared secrets, one understood by that server and an attempt to reach
   the hidden server.

4.  HTTP Co-Tenancy Fronting
   service and

   In the other shared absence of TLS level SNI encryption, many sites rely on an
   "HTTP Co-Tenancy" solution.  The TLS connection is established with
   the Hidden service to ensure
   protection against replay attacks.

   An alternative may be fronting server, and HTTP requests are then sent over that
   connection to use the TLS-in-TLS service described in
   Section 4.1 for hidden service.  For example, the first contact.  There will TLS SNI could be some overhead due
   set to tunnelling, but as we discussed in Section 4.2.3 "fronting.example.com", the tunneling
   solution allows for safe first contact.  Yet another way would fronting server, and HTTP requests
   sent over that connection could be directed to
   use the HTTPS in HTTPS tunneling described in Section 3.1.

6.  Security Considerations

   The encapsulation protocol proposed in this draft mitigates "hidden.example.com/
   some-content", accessing the known
   attacks listed hidden service.  This solution works
   well in Section 2.  For example, practice when the encapsulation design
   uses pairwise security contexts, fronting server and is not dependent on the widely
   shared secrets described in Section 2.2.  The design also does not
   rely on additional public key operations by the multiplexed hidden server or
   by are
   'co-tenant" of the same multiplexed server.

   The HTTP fronting server, solution can be deployed without modification to
   the TLS protocol, and thus does not open the attack surface for
   denial require using any specific version of service discussed in Section 2.3.  The session keys
   TLS.  There are
   negotiated end however a few issues regarding discovery, client
   implementations, trust, and applicability:

   o  The client has to end between discover that the hidden service can be accessed
      through the fronting server.

   o  The client and browser's has to be directed to access the protected hidden
      service through the fronting service.

   o  Since the TLS connection is established with the fronting service,
   as required
      the client has no proof that the content does in Section 2.6.

   The combined ticket solution also mitigates fact come from
      the known attacks. hidden service.  The
   design also uses pairwise security contexts, and is solution does thus not dependent on mitigate the widely shared secrets
      context sharing issues described in Section 2.2.  The design also
   does 3.6.

   o  Since this is an HTTP level solution, it would not rely on additional public key operations by the multiplexed
   server protected non
      HTTP protocols such as DNS over TLS [RFC7858] or IMAP over TLS
      [RFC2595].

   The discovery issue is common to pretty much every SNI encryption
   solution.  The browser issue may be solved by the fronting server, developing a browser
   extension that support HTTP Fronting, and thus does not open manages the attack
   surface for denial list of service discussed in Section 2.3.  The session
   keys are negotiated end to end between
   fronting services associated with the client and hidden services that the protected
   service, client
   uses.  The multi-protocol issue can be mitigated by using
   implementation of other applications over HTTP, such as required in Section 2.6.

   However, for example
   DNS over HTTPS [I-D.hoffman-dns-over-https].  The trust issue,
   however, requires specific developments.

4.1.  HTTPS Tunnels

   The HTTP Fronting solution places a lot of trust in some cases, proper mitigation depends on careful
   implementation.

6.1.  Replay attacks and side channels

   Both solutions mitigate the replay attacks described Fronting
   Server.  This required trust can be reduced by tunnelling HTTPS in Section 2.1
   because adversaries cannot decrypt the replies intended for
   HTTPS, which effectively treats the
   client.  However, Fronting Server as an HTTP Proxy.
   In this solution, the client establishes a TLS connection from to the fronting service
   Fronting Server, and then issues an HTTP Connect request to the
   hidden service can be observed through side channels.

   To give
   Hidden Server.  This will establish an obvious example, suppose that end-to-end HTTPS over TLS
   connection between the fronting service merely
   relays client and the data by establishing a TCP connection to Hidden Server, mitigating the hidden
   service.  An adversary capable
   issues described in Section 3.6.

   The HTTPS in HTTPS solution requires double encryption of observing all network traffic at every
   packet.  It also requires that the fronting server can associate the arrival of an encrypted message decrypts and relay
   messages to the fronting service and hidden server.  Both of these requirements make the TCP handshake between
   implementation onerous.

4.2.  Delegation Control

   Clients would see their privacy compromised if they contacted the
   wrong fronting server and to access the hidden service, and deduce which hidden service the
   user accessed.

   The mitigation of since this attack relies on proper implementation of the wrong
   server could disclose their access to adversaries.  This requires a
   controlled way to indicate which fronting ferver is acceptable by the
   hidden service.

   This may require cooperation problem is both similar and different from the multiplexed
   server.

6.2.  Sticking out

   The TLS encapsulation protocol mostly fulfills the requirements to
   "not stick out" expressed "fronting server
   spoofing" attack described in Section 2.4.  The initial messages will 3.7.  Here, the spoofing would
   be sent performed by distributing fake advice, such as 0-RTT data, and will be encrypted using the 0-RTT key
   negotiated with the "to reach example
   hidden.example.com, use fake.example.com as a fronting service.  Adversaries cannot tell
   whether the client server", when
   "fake.example.com" is using TLS encapsulation or some other 0-RTT
   service.  However, under the control of an adversary.

   In practice, this attack is only true if well mitigated when the fronting hidden service
   regularly uses 0-RTT data. is
   accessed through a specialized application.  The combined token solution almost perfectly fulfills name of the
   requirements to "not stick out" expressed fronting
   server can then be programmed in Section 2.4, as the
   observable flow code of message is almost exactly the same as a regular
   TLS connection.  However, adversaries could observe the values of application.  But
   the
   PSK Identifier that contains attack is much harder to mitigate when the combined ticket. hidden service has to
   be accessed through general purpose web browsers.  The proposed
   ticket structure is designed browsers will
   need a mechanism to thwart analysis of obtain the ticket, but if
   implementations fronting server indication in a secure
   way.

   There are not careful the size of the combined ticket can
   be used several proposed solutions to this problem, such as
   creating a side channel allowing adversaries special form of certificate to distinguish between
   different Hidden Services located behind codify the same Fronting Service.

6.3.  Forward Secrecy

   In relation between
   fronting and hidden server, or obtaining the TLS encapsulation protocol, relation between hidden
   and fronting service through the encapsulated Client Hello is
   encrypted DNS, possibly using DNSSEC to avoid
   spoofing.

   We can observe that content distribution network have a similar
   requirement.  They need to convince the session resumption key.  If this key is revealed,
   the Client Hello data will also client that "www.example.com"
   can be revealed.  The mitigation there is
   to not use accessed through the same session resumption key multiple time.

   The most common implementations of TLS tickets seemingly unrelated "cdn-node-
   xyz.example.net".  Most CDN have the server using
   Session Ticket Encryption Keys (STEKs) deployed DNS-based solutions to create this
   problem.

5.  Security Considerations

   Replacing clear text SNI transmission by an encrypted copy variant will
   improve the privacy and reliability of TLS connections, but the session parameters which
   design of proper SNI encryption solutions is then stored by the client.  When the
   client resumes, it supplies this encrypted copy, difficult.  This
   document does not present the server decrypts
   it, design of a solution, but provide
   guidelines for evaluating proposed solutions.

   This document lists a number of attacks against SNI encryption in
   Section 3, and has the parameters it needs also in Section 4.2, and presents a list of
   requirements to resume. mitigate these attacks.  The server need current HTTP based
   solutions described in Section 4 only
   remember the STEK.  If a STEK is disclosed to an adversary, then all meet some of the data encrypted by sessions protected by the STEK these
   requirements.  In practice, it may well be
   decrypted by an adversary.

   To mitigate this attack, server implementations of that no solution can meet
   every requirement, and that practical solutions will have to make
   some compromises.

   In particular, the combined
   ticket protocol SHOULD use stateful tickets instead of STEK protected
   TLS tickets.  If they do rely on STEK protected tickets, they MUST
   ensure requirement to not stick out presented in
   Section 3.4 may have to be lifted, especially if for proposed
   solutions that the K_sni keys used to encrypt these tickets are rotated
   frequently.

7. could quickly reach large scale deployments.

6.  IANA Considerations

   Do we need to register an extension point?  Or is it just OK to use
   early data?

8.

   This draft does not require any IANA action.

7.  Acknowledgements

   A large part of this draft originates in discussion of SNI encryption
   on the TLS WG mailing list, including comments after the tunneling
   approach was first proposed in a message to that list:
   <https://mailarchive.ietf.org/arch/msg/tls/
   tXvdcqnogZgqmdfCugrV8M90Ftw>.

   During the discussion of SNI Encryption in Yokohama, Deb Cooley
   argued that rather than messing with TLS to allow SNI encryption, we
   should just tunnel TLS in TLS.  A number of people objected to this
   on the grounds of the performance cost for the Fronting Server
   because it has to encrypt and decrypt everything.

   After the meeting, Martin Thomson suggested a modification to the
   tunnelling proposal that removes this cost.  The key observation is
   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.

   The combined ticket approach was first proposed by Cedric Fournet and
   Antoine Delignaut-Lavaud.

   The delegation token design comes from many people, including Ben
   Schwartz, Brian Sniffen and Rich Salz.

   Thanks to Daniel Kahn Gillmor for a pretty detailed review of the
   initial draft.

9.

8.  References

9.1.

8.1.  Normative References

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
              March 2018.

8.2.  Informative References

   [I-D.hoffman-dns-over-https]
              Hoffman, P. and P. McManus, "DNS Queries over HTTPS",
              draft-hoffman-dns-over-https-01 (work in progress), June
              2017.

   [I-D.ietf-doh-dns-over-https]
              Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DOH)", draft-ietf-doh-dns-over-https-08 (work in
              progress), May 2018.

   [I-D.ietf-quic-tls]
              Thomson, M. and S. Turner, "Using Transport Layer Security
              (TLS) to Secure QUIC", draft-ietf-quic-tls-09 draft-ietf-quic-tls-11 (work in
              progress), January April 2018.

   [I-D.ietf-tls-dtls13]
              Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", draft-ietf-tls-dtls13-22 draft-ietf-tls-dtls13-26 (work in progress),
              November 2017.

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-24 March
              2018.

   [I-D.mm-wg-effect-encrypt]
              Moriarty, K. and A. Morton, "Effects of Pervasive
              Encryption on Operators", draft-mm-wg-effect-encrypt-25
              (work in progress),
              February March 2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14,

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2119, 2246, DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

9.2.  Informative References

   [I-D.hoffman-dns-over-https]
              Hoffman, P. and P. McManus, "DNS Queries over HTTPS",
              draft-hoffman-dns-over-https-01 (work in progress), June
              2017. 10.17487/RFC2246, January 1999,
              <https://www.rfc-editor.org/info/rfc2246>.

   [RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP",
              RFC 2595, DOI 10.17487/RFC2595, June 1999,
              <https://www.rfc-editor.org/info/rfc2595>.

   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003,
              <https://www.rfc-editor.org/info/rfc3546>.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346,
              DOI 10.17487/RFC4346, April 2006,
              <https://www.rfc-editor.org/info/rfc4346>.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
              <https://www.rfc-editor.org/info/rfc4366>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,
              <https://www.rfc-editor.org/info/rfc6066>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <https://www.rfc-editor.org/info/rfc7540>.

   [RFC7590]  Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
              Security (TLS) in the Extensible Messaging and Presence
              Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
              2015, <https://www.rfc-editor.org/info/rfc7590>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

Authors' Addresses

   Christian Huitema
   Private Octopus Inc.
   Friday Harbor  WA  98250
   U.S.A

   Email: huitema@huitema.net
   Eric Rescorla
   RTFM, Inc.
   U.S.A

   Email: ekr@rtfm.com