Draft: draft-ietf-tls-sni-encryption

Commentary: Update the outdated references ( Issue ) . Address MT 's comments ( Issue ) . 
 Some comments on draft - ietf - tls - sni - encryption-03 : Section 2.3 “ End - to - end alternatives ” “ Enterprises can deploy monitoring software to control usage of the enterprises [ sic ] computers . ” At the moment enterprises have the option of installing a firewall performing SNI filtering to black - list connections to certain websites . With SNI encryption this becomes ineffective . This draft should describe the privacy impact of enterprises adopting the proposed mitigation strategy of deploying monitoring software . Similarly , the privacy impact of introducing “ opt in ” filtering of DNS and packet marking to determine  should be addressed . The privacy gains of encrypting SNI need to be weighed against the privacy losses of adopting these mitigations and at the moment this draft does not do that . Section 3.6 “ Proper security context ” This section currently describes one class of solutions where there is a single TLS handshake between the client and the multiplexed server or fronting service , but there is another class , where the TLS handshake is between the client and the protected service . The text in this section should be expanded to encompass both classes ( or it could be written as two separate sections if clearer ) . The text should also draw out that the client and the protected service are placing a great deal of trust in the fronting service , which becomes a very powerful part of the network and hence a very attractive target for attackers or malicious operators . As a suggestion , consider the following alternative text for section 3.6 : We can design solutions in which the multiplexed server or 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 multiplexed server ( or fronting service ) . Others involve just one TLS handshake between the client and the protected service . In the first case , the master secret is verified by verifying a certificate provided by the multiplexed server ( or fronting service ) , but not by the protected service . In the second case , the master secret is verified by verifying a certificate provided by the protected service . In the first case , the client is exposed to a Man - In - The - Middle attack by the multiplexed server ( or fronting service ) . The client does not verify the identity of the protected service , and thus data exchanged between the client and the protected service can be learned by the attacker . In the second case , the client does not verify the identity of the multiplexed server ( or fronting service ) , thus it is possible for an attacker to perform a Man - In - The - Middle attack between the client and the multiplexed server ( or fronting service ) . Thus it would be possible for the attacker to learn the identity of the protected service . These designs require that the client has some reasonable trust in these fronting services . If the fronting service is acting maliciously , it may re - direct the client 's TLS connection to another service other than the intended protected service . The service receiving the client 's TLS connection may not have any way of verifying that the client intended to reach that particular service if it is not able to decrypt the client 's SNI ; thus the protected service also has to have reasonable trust in the fronting service . If the fronting service is not strongly authenticated , it can be spoofed by an adversary or be subject to MITM attack . The multiplexed server or the fronting services could be pressured 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 . These approaches therefore concentrate trust in the multiplexed servers and fronting services , making them attractive targets for adversaries , or for operators of these services to install monitoring , redirection and censorship mechanisms . It is desirable for the identity of these multiplexed servers and fronting services to be strongly authenticated and verifiable by both the client and the protected service . --    in PR 
 All , I ran I - D nits before hitting the appropriate buttons to place this draft in WGLC . I figured we could address the following before we send the draft to  : = = Outdated reference : draft - ietf - tls - tls13 has been published as RFC 8446 = = Outdated reference : A later version ( -14 ) exists of draft - ietf - doh - dns - over - https-08 = = Outdated reference : A later version ( -15 ) exists of draft - ietf - quic - tls-11 = = Outdated reference : A later version ( -28 ) exists of draft - ietf - tls - dtls13 - 26 = = Outdated reference : draft - mm - wg - effect - encrypt has been published as RFC 8404 To answer the other 5 I - D nits questions " Obsolete informational reference ( is this intentional ? ) ” - the answer is yes . sptAll , I ran I - D nits before hitting the appropriate buttons to place this draft in WGLC . I figured we could address the following before we send the draft to  : = = Outdated reference : draft - ietf - tls - tls13 has been published as RFC 8446 = = Outdated reference : A later version ( -14 ) exists of draft - ietf - doh - dns - over - https-08 = = Outdated reference : A later version ( -15 ) exists of draft - ietf - quic - tls-11 = = Outdated reference : A later version ( -28 ) exists of draft - ietf - tls - dtls13 - 26 = = Outdated reference : draft - mm - wg - effect - encrypt has been published as RFC 8404 To answer the other 5 I - D nits questions " Obsolete informational reference ( is this intentional ? ) ” - the answer is yes . spt 
 Addressed in PR 
 What is most interesting about the TLS proxy case is that it sets the bar higher for this feature than we typically have it . If the TLS proxy is able to install a trust anchor , it can see all communications . However , this says that we do n't want it to learn the SNI . So it can see everything , except this one thing . I know that this is somewhat a policy decision , it 's a weird design goal .
In practice, it may well be that no solution can meet every
requirement, and that practical solutions will have to make some
compromises.
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 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.
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.
The SNI carries the domain name of the server, which is also sent as
part of the DNS queries.  Most of the SNI usage described in snileak
could also be implemented by monitoring DNS traffic or controlling
DNS usage.  But this is changing with the advent of DNS resolvers
providing services like DNS over TLS RFC7858 or DNS over HTTPS I-
D.ietf-doh-dns-over-https.
The common name component of the server certificate generally exposes
the same name as the SNI.  In TLS versions 1.0 RFC2246, 1.1 RFC4346,
and 1.2 RFC5246, the server send their certificate in clear text,
ensuring that there would be limited benefits in hiding the SNI.  But
the transmission of the server certificate is protected in TLS 1.3 I-
D.ietf-tls-tls13.
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 much harder to censor specific
internet services.
Deploying SNI encryption will help thwarting most 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.  Enterprises can deploy monitoring software to control
usage of the enterprises computers.  As SNI encryption becomes
common, we can expect more deployment of such "end to end" solutions.
The SNI carries the domain name of the server, which is also sent as
part of the DNS queries.  Most of the SNI usage described in snileak
could also be implemented by monitoring DNS traffic or controlling
DNS usage.  But this is changing with the advent of DNS resolvers
providing services like DNS over TLS RFC7858 or DNS over HTTPS
RFC8484.
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
1.2 RFC5246, the server send their certificate in clear text,
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.
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.
We can design solutions in which the multiplexed server or 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
multiplexed server, or between the client and the fronting service.
The master secret is verified by verifying a certificate provided by
either of these entities, but not by the protected service.
These solutions expose the client to a Man-In-The-Middle attack by
the multiplexed server or by the fronting service.  Even if the
client has some reasonable trust in these services, the possibility
of MITM attack is troubling.
The multiplexed server or the fronting services could be pressured 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.
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.
There are other classes of solutions in which the master secret is
verified by verifying a certificate provided by the protected
service.  These solutions offer more protection against a Man-In-The-
Middle attack by the fronting service.
The fronting service could be pressured by adversaries.  By design,
it 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 the fronting service into
intercepting or spoofing the communications between client and
protected service.
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 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.
It is thus desirable that SNI Encryption mechanisms be also able hide
the ALPN.
In addition to hiding the SNI, it is thus desirable to also hide the
ALPN.  Of course, this implies engineering trade-offs.  Using the
same technique for hiding the ALPN and encrypting the SNI may result
in excess complexity.  It might be preferable to encrypt these
independently.
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 attempt to reach
the hidden 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/
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.
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 I-D.hoffman-dns-over-https.  The trust issue, however,
requires specific developments.
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 ORIGIN frame defined for HTTP/2 RFC8336 can be used to flag
content provided by the hidden server.  Secondary certificate
authentication I-D.ietf-httpbis-http2-secondary-certs can be used to
manage authentication of hidden server content, or to perform client
authentication before accessing hidden content.
In particular, the requirement to not stick out presented in
snireqdontstickout may have to be lifted, especially if for proposed
solutions that could quickly reach large scale deployments.
In particular, the requirement to not stick out presented in
snireqdontstickout may have to be lifted, especially for proposed
solutions that could quickly reach large scale deployments.
Thanks to Daniel Kahn Gillmor for a pretty detailed review of the
initial draft.
Thanks to Daniel Kahn Gillmor for a pretty detailed review of the
initial draft.  Thanks to Stephen Farrell, Mark Orchezowski, Martin
Rex and Martin Thomson for their reviews.