Draft: draft-ietf-tls-sni-encryption

Commentary: can you please have a look ? 
 Ping 
 Looks good . I just spotted a small typo ...
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 lists known
attacks against SNI encryption, discusses the current "co-tenancy
fronting" solution, and presents requirements for future TLS layer
solutions.
This draft describes the general problem of encrypting the Server
Name Identification (SNI) TLS 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 lists known
attacks against SNI encryption, discusses the current "co-tenancy
fronting" solution, and presents requirements for future TLS layer
solutions.
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 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
snisecreq.  In the absence of a TLS level solution, the most popular
approach to SNI privacy is HTTP level fronting, which we discuss in
httpfronting.
The SNI extension was standardized in 2003 in RFC3546 to facilitate
management of "colocation servers", in which a 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 specific server, enabling the TLS connection to be
established with the desired server context.  The current SNI
extension specification can be found in RFC6066.
The SNI specification allowed for different types of server names,
but only the "hostname" variant was standardized and deployed.  In
that variant, the SNI extension carries the domain name of the target
server.  The SNI extension is carried in clear text in the TLS
"Client Hello" message.
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.
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
snisecreq.  In the absence of a TLS-level solution, the most popular
approach to SNI privacy for web services is HTTP-level fronting,
which we discuss in httpfronting.
The SNI extension was specified in 2003 in RFC3546 to facilitate
management of "colocation servers", in which 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 specific server, enabling the TLS connection to be established with
the desired server context.  The current SNI extension specification
can be found in RFC6066.
The SNI specification allowed for different types of server names,
though only the "hostname" variant was specified and deployed.  In
that variant, the SNI extension carries the domain name of the target
server.  The SNI extension is carried in clear text in the TLS
"ClientHello" message.
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 small number of addresses.
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 subjectAltName extension of type dNSName of the server
certificate, or in its absence the common name component, expose the
same name as the SNI.  In TLS versions 1.0 RFC2246, 1.1 RFC4346, and
ensuring that there would be limited benefits in hiding the SNI.  But
the transmission of the server certificate is protected in TLS 1.3
RFC8446.
The decoupling of IP addresses and server names, the deployment of
DNS privacy, and the protection of server certificates transmissions
all contribute to user privacy.  Encrypting the SNI now will complete
this push for privacy and make it harder to censor specific internet
services.
The subjectAltName extension of type dNSName of the server
certificate, or in its absence the common name component, expose the
same name as the SNI.  In TLS versions 1.0 RFC2246, 1.1 RFC4346, and
there would be limited benefits in hiding the SNI.  However, in TLS
encryption alone is insufficient to protect server certificates; see
replayattack for details.
The decoupling of IP addresses and server names, deployment of DNS
privacy, and protection of server certificates 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 thwarting 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 can 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.  Enterprises
managers could rely instead on filtering software and management
software deployed on enterprises computers.
Over 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 of these known attacks.
Deploying SNI encryption will help thwarting 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 can 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.
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 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.
We can design solutions in which a fronting service act as a relay to
reach the protected service.  Some of those solutions involve just
one TLS handshake between the client and the fronting service.  The
master secret is verified by verifying a certificate provided by the
fronting service, but not by the protected service.  These solutions
expose the client to a Man-In-The-Middle attack by the fronting
service.  Even if the client has some reasonable trust in this
services, the possibility of MITM attack is troubling.
We can design solutions in which a fronting service act as a relay to
reach the protected service.  Some of those solutions involve just
one TLS handshake between the client and the fronting service.  The
master secret is verified by verifying a certificate provided by the
fronting service, but not by the protected service.  These solutions
expose the client to a Man-In-The-Middle attack by the fronting
service.  Even if the client has some reasonable trust in this
service, the possibility of MITM attack is troubling.
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.
Adversaries could also 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.
The SNI encryption requirement does 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 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 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.
The SNI encryption requirement does 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 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 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.
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-tenant" of the
same multiplexed server.
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-tenant" of the
same multiplexed server.
The discovery issue is common to pretty much every SNI encryption
solution.  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 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.
This problem is both similar and different from the "fronting server
spoofing" attack described in frontingspoofing.  Here, the spoofing
would be performed by distributing fake advice, such as "to reach
example hidden.example.com, use fake.example.com as a fronting
server", when "fake.example.com" is under the control of an
adversary.
This problem is both similar and different from the "fronting server
spoofing" attack described in nocontextsharing.  Here, the spoofing
would be performed by distributing fake advice, such as "to reach
example hidden.example.com, use fake.example.com as a fronting
server", when "fake.example.com" is under the control of an
adversary.
We can observe that content distribution network 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 CDN have deployed DNS-based solutions to this
problem.
We can observe that content distribution network 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.
Replacing clear text SNI transmission by an encrypted variant will
improve the privacy and reliability of TLS connections, but the
design of proper SNI encryption solutions is difficult.  This
document does not present the design of a solution, but provide
guidelines for evaluating proposed solutions.
Replacing clear text SNI transmission by an encrypted variant will
improve the privacy and reliability of TLS connections, but the
design of proper SNI encryption solutions is difficult.  This
document does not present the design of a solution, but provides
guidelines for evaluating proposed solutions.