Draft: draft-ietf-tls-sni-encryption

Commentary: This addresses comments from Roman , Éric ,  ,  and Alexey . Also make sure that fixes addressing  's comment will be in the final text . 
 I think this properly addresses the comments , but you may want to check with  for section 3.6 and Alexey for section 4 . 
 LGTM -- thanks , Christian ! 
 Please use RFC 8314 instead of RFC 2595 as a reference for IMAP over TLS . 
 Done in PR 
 COMMENT : Section 1 : s / servers rely on the Service Name Information ( SNI ) TLS extension / servers rely on the Server Name Indication ( SNI ) TLS extension [ RFC 6066]/ Section 2.1 : Why is parental controls in quotes ? Section 2.2 : s / Encrypting the SNI now will complete this push / Encrypting the SNI completes this push/ ( for timelessness ) Section 2.3 : In the first paragraph I would suggest trying to use the present tense more so that this still makes sense far in the future . s / At the moment / At the time of this writing/ 
 Done in PR 
   has entered the following ballot position for draft - ietf - tls - sni - encryption-05 : Yes When responding , please keep the subject line intact and reply to all email addresses included in the To and CC lines . ( Feel free to cut this introductory paragraph , however . ) Please refer to for more information about IESG DISCUSS and COMMENT positions . The document , along with other ballot positions , can be found here : COMMENT : Thanks to everyone who worked on this . It seems that it will be a useful tool for evaluating potential solutions . : Nit : " follows : " : This final sentence appears to be missing some kind of citation before the comma . : It 's a bit unclear why this is described as part of the injection of a third party into the scenario . As far as I understand , the described attack exists today , in the absence of any SNI encrypting schemes . If there 's a new twist introduced by a multi - party security context , the current text does n't seem to explain what it is . : Nit : " ... including , for example , SMTP ... " Nit : " XMPP ... " Nit : " ... benefit from SNI ... " Nit : " HTTP - only ... " : Nit : " " : I think you 're missing a comma between the two Martins . 
 Done in PR 
 COMMENT : Thank you for the work put into this document . It is well - written and easy to follow . Please find below a couple of comments and nits . Reading " In practice , it may well be that no solution can meet every requirement , and that practical solutions will have to make some compromises . " in the abstract brought a smile on my face Same for " employees of the UK National Cyber Security Centre " at the end Regards , -éric = = COMMENTS = = -- Section 2.1 -- C.1 ) I would suggest to use the words " network operators " rather than ISP as enterprise or parents for home networks are also relying on clear - text SNI to enforce some policies . -- Section 2.2 -- C.2 ) The word " abuses " seems a little strong in the first paragraph , I prefer the wording used in 2.1 " unanticipated usage " . But , this is only one comment . -- Section 3.6 -- C.3 ) It is rather a question for my own curiosity ... " The fronting service could be pressured by adversaries . " is an obvious attack but even if SNI is protected , the fronting service can still apply any policy to a protected service as it has the knowledge of protected services by design . Hence , I wonder why this case is mentioned here . -- Security section -- Like  , I find the content of this section unusual . = = NITS = = -- Section 2.1 -- Probably worth expanding " MITM " at first use . --Section 3.3 -- Probably worth expanding " DOS " at first use . 
   commented : Actually , " DoS " ( with the small " o " ) is in the RFC Editor 's list of abbreviations that do not need to be expanded . That , of course , does n't mean that it should n't be expanded . But it should be spelled with the small " o " , in any case . 
 Done in PR
Historically, adversaries have been able to monitor the use of web
services through three primary channels: looking at DNS requests,
looking at IP addresses in packet headers, and looking at the data
stream between user and services.  These channels are getting
progressively closed.  A growing fraction of Internet communication
is encrypted, mostly using Transport Layer Security (TLS) RFC5246.
Progressive deployment of solutions like DNS in TLS RFC7858 and DNS
over HTTPS RFC8484 mitigates the disclosure of DNS information.  More
and more services are colocated on multiplexed servers, loosening the
relation between IP address and web service.  However, multiplexed
servers rely on the Service Name Information (SNI) TLS extension to
direct 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 and privacy is to prevent that.
Historically, adversaries have been able to monitor the use of web
services through three primary channels: looking at DNS requests,
looking at IP addresses in packet headers, and looking at the data
stream between user and services.  These channels are getting
progressively closed.  A growing fraction of Internet communication
is encrypted, mostly using Transport Layer Security (TLS) RFC5246.
Progressive deployment of solutions like DNS in TLS RFC7858 and DNS
over HTTPS RFC8484 mitigates the disclosure of DNS information.  More
and more services are colocated on multiplexed servers, loosening the
relation between IP address and web service.  For example, in virtual
hosting solutions, multiple services can be hosted as co-tenants on
the same server, and the IP address and port do not uniquely identify
a service.  In cloud or Content Delivery Networks (CDNs) solutions, a
given platform hosts the services or servers servers of a lot of
organization, and looking up to what netblock an IP address belongs
reveals little.  However, multiplexed servers rely on the Service
Name Information (SNI) TLS extension RFC6066 to direct 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 and privacy is to prevent that.
The clear-text transmission of the SNI was not flagged as a problem
in the security consideration sections of RFC3546, RFC4366, or
RFC6066.  These specifications did not anticipate the alternative
uses and abuses described in snileak.  One reason may be that, when
these 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 identified by their IP
addresses.  However, content distribution networks (CDN) commonly
serve a large number of services through a comparatively small number
of addresses.
The clear-text transmission of the SNI was not flagged as a problem
in the security consideration sections of RFC3546, RFC4366, or
RFC6066.  These specifications did not anticipate the alternative
usage described in snileak.  One reason may be that, when these RFCs
were written, the SNI information was available through a variety of
other means, such as tracking IP addresses, DNS names, or server
certificates.
Many deployments still allocate different IP addresses to different
services, so that different services can be identified by their IP
addresses.  However, CDNs commonly serve a large number of services
through a comparatively small number of addresses.
The decoupling of IP addresses and server names, deployment of DNS
privacy, and protection of server certificate transmissions all
contribute to user privacy in the face of an RFC3552-style adversary.
Encrypting the SNI now will complete this push for privacy and make
it harder to censor or otherwise provide differential treatment to
specific internet services.
Deploying SNI encryption will help thwart most of the "unanticipated"
SNI usages described in snileak, including censorship and pervasive
surveillance.  It will also thwart functions that are sometimes
described as legitimate.  Most of these functions can, however, be
realized by other means.  For example, some DNS service providers
offer customers the provision to "opt in" filtering services for
parental control and phishing protection.  Per-stream QoS could be
provided by a combination of packet marking and end-to-end
agreements.  As SNI encryption becomes common, we can expect more
deployment of such "end-to-end" solutions.
At the moment, enterprises have the option of installing a firewall
performing SNI filtering to prevent connections to certain websites.
With SNI encryption this becomes ineffective.  Obviously, managers
could block usage of SNI encryption in enterprise computers, but this
wide-scale blocking would diminish the privacy protection of traffic
leaving the enterprise, which may not be desirable.  Enterprise
managers could rely instead on filtering software and management
software deployed on the enterprise's computers.
Over the past years, there have been multiple proposals to add an SNI
encryption option in TLS.  Many of these proposals appeared
promising, though were rejected after security reviews identified
plausible attacks.  In this section, we collect a list of these known
attacks.
The decoupling of IP addresses and server names, deployment of DNS
privacy, and protection of server certificate transmissions all
contribute to user privacy in the face of an RFC3552-style adversary.
Encrypting the SNI completes this push for privacy and make it harder
to censor or otherwise provide differential treatment to specific
internet services.
Deploying SNI encryption helps thwart most of the unanticipated SNI
usages including censorship and pervasive surveillance, but it also
will break or reduce the efficacy of the operational practices and
techniques implemented in middle-boxes as described in snileak.  Most
of these functions can, however, be realized by other means.  For
example, some DNS service providers offer customers the provision to
"opt in" filtering services for parental control and phishing
protection.  Per-stream QoS could be provided by a combination of
packet marking and end-to-end agreements.  As SNI encryption becomes
common, we can expect more deployment of such "end-to-end" solutions.
At the time of this writing, enterprises have the option of
installing a firewall performing SNI filtering to prevent connections
to certain websites.  With SNI encryption this becomes ineffective.
Obviously, managers could block usage of SNI encryption in enterprise
computers, but this wide-scale blocking would diminish the privacy
protection of traffic leaving the enterprise, which may not be
desirable.  Enterprise managers could rely instead on filtering
software and management software deployed on the enterprise's
computers.
Over the past years, there have been multiple proposals to add an SNI
encryption option in TLS.  A review of the TLS mailing list archives
shows that many of these proposals appeared promising but were
rejected after security reviews identified plausible attacks.  In
this section, we collect a list of these known attacks.
It may be argued that this is not an important DOS avenue, as regular
TLS connection attempts also require the server to perform a number
of cryptographic operations.  However, in many cases, the SNI
decryption will have to be performed by a front-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.
It may be argued that this is not an important Denial of Service
Attacks (DoS) avenue, as regular TLS connection attempts also require
the server to perform a number of cryptographic operations.  However,
in many cases, the SNI decryption will have to be performed by a
front-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.
The SNI encryption requirement does not stop with HTTP over TLS.
Multiple other applications currently use TLS, including, for
example, SMTP RFC5246, DNS RFC7858, IMAP RFC2595, and XMPP RFC7590.
These applications, too, will benefit from SNI encryption.  HTTP-only
methods like those described in httpfrontingtunnels would not apply
there.  In fact, even for the HTTPS case, the HTTPS tunneling service
described in httpfrontingtunnels is compatible with HTTP 1.0 and HTTP
HTTP/2 RFC7540.  This points to the need for an application-agnostic
solution, which would be implemented fully in the TLS layer.
The SNI encryption requirement does not stop with HTTP over TLS.
Multiple other applications currently use TLS, including, for
example, SMTP RFC5246, DNS RFC7858, IMAP RFC8314, and XMPP RFC7590.
These applications, too, will benefit from SNI encryption.  HTTP-only
methods like those described in httpfrontingtunnels would not apply
there.  In fact, even for the HTTPS case, the HTTPS tunneling service
described in httpfrontingtunnels is compatible with HTTP 1.0 and HTTP
HTTP/2 RFC7540.  This points to the need for an application-agnostic
solution, which would be implemented fully in the TLS layer.
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",
accessing the hidden service.  This solution works well in practice
when the fronting server and the hidden server are "co-tenants" of
the same multiplexed server.
In the absence of TLS-level SNI encryption, many sites rely on an
"HTTP Co-Tenancy" solution, often refered to as Domain Fronting
domfront.  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",
accessing the hidden service.  This solution works well in practice
when the fronting server and the hidden server are "co-tenants" of
the same multiplexed server.
The discovery issue is common to most SNI encryption solutions.  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 RFC8484.
The trust issue, however, requires specific developments.
The discovery issue is common to most SNI encryption solutions.  The
browser issue was solved in domfront by implementing domain fronting
as a pluggable transport for the Tor browser.  The multi-protocol
issue can be mitigated by using implementation of other applications
over HTTP, such as for example DNS over HTTPS RFC8484.  The trust
issue, however, requires specific developments.
In practice, this attack is well mitigated when the hidden service is
accessed through a specialized application.  The name of the fronting
server can then be programmed in the code of the application.  But
the attack is much harder to mitigate when the hidden service has to
be accessed through general purpose web browsers.  The browsers will
need a mechanism to obtain the fronting server indication in a secure
way.
There are several proposed solutions to this problem, such as
creating a special form of certificate to codify the relation between
fronting and hidden server, or obtaining the relation between hidden
and fronting service through the DNS, possibly using DNSSEC to avoid
spoofing.
We can observe that content distribution networks (CDNs) have a
similar requirement.  They need to convince the client that
"www.example.com" can be accessed through the seemingly unrelated
"cdn-node-xyz.example.net".  Most CDNs have deployed DNS-based
solutions to this problem.  However, the CDN often holds the
authoritative certificate of the origin.  There is simultaneously
verification of a relationship between the origin and the CDN,
through the certificate, and a risk that the CDN can spoof the
content from the origin.
In practice, this attack is well mitigated when the hidden service is
accessed through a specialized application.  The name of the fronting
server can then be programmed in the code of the application.  But
the attack is harder to mitigate when the hidden service has to be
accessed through general purpose web browsers.
There are several proposed solutions to this problem, such as
creating a special form of certificate to codify the relation between
fronting and hidden server, or obtaining the relation between hidden
and fronting service through the DNS, possibly using DNSSEC to avoid
spoofing.  The experiment described in domfront solved the issue by
integrating with the Lantern Internet circumvention circumvention
tool.
We can observe that CDNs have a similar requirement.  They need to
convince the client that "www.example.com" can be accessed through
the seemingly unrelated "cdn-node-xyz.example.net".  Most CDNs have
deployed DNS-based solutions to this problem.  However, the CDN often
holds the authoritative certificate of the origin.  There is
simultaneously verification of a relationship between the origin and
the CDN, through the certificate, and a risk that the CDN can spoof
the content from the origin.