Draft: draft-ietf-tls-sni-encryption

Commentary: This PR incorporates the feedback during IETF last call from   ( issue ) , Meral Shirazipour ( issue ) and   ( Issue ) , with only a few deltas : 1 ) Some of the issues were already fixed in PR ,  the fronting server spoofing section . 2 ) Not applying Meral 's proposal to change " colocated " to " collocated " , as " colocated " is established industry usage 3 ) Not applying  's suggestion to replace " floundered " by " foundered " , as " floundered " is closer to intended meaning . 
 -- you may want to take a look to the proposed changes . 
 Document : draft - ietf - tls - sni - encryption  :    result : Ready with Nits This document has been reviewed as part of the transport area review team 's ongoing effort to review key IETF documents . These comments were written primarily for the transport area directors , but are copied to the document 's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information . When done at the time of IETF Last Call , the authors should consider this review as part of the last - call comments they receive . Please always CC tsv- if you reply to or forward this review . I have not identified any transport related issues . NITS Expansion of acronyms on first use : Abstract : TLS Section 1 : DNS Section 2.1 : ISP , QoS , MITM Section 2 s / mutiple / multiple/ Section 2.1 s / fradulent / fraudulent/ Section 3.6 The downside is the the client will not verify the identity of the fronting service with risks discussed in , but solutions will have to mitigate this risks . [ BA ] Several problems with this sentence : s / the the / the/ s / this risks / the risk/ s / discussed in , /discussed in [ REF - TBD],/ Section 3.7.1 This section seems somewhat out of place in a section on Security and Privacy Requirements for SNI Encryption , given that it relates to hiding of the ALPN , and the text admits a weak case for linking the two problems : 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 . You might consider moving this section to Section 4.3.1 , under Section 4.3 Related Work . Section 5 The first paragraph of this section strikes me as being potentially better suited to inclusion in Section 1 Introduction . 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 . 
 Thanks for the feedback ,  . We already fixed in the editor copy some of the issues that you described based on other feedback received during last call , but not all . Your comments about section 3.7.1 and section 5 are interesting . I like your suggestion of moving some of the text from section 5 to the introduction and believe that it will improve the document . Regarding section 3.7.1 , you suggest adding a comment on related work , and perhaps moving some of the discussion of ALPN there . I understand the rationale , but I am a bit worried about going too far there -- the current text reflects discussions and feedback on the TLS list . Also , if we did add a section on related work we would probably need to reference the deployment of encrypted DNS services , and I am a bit worried about doing that late in the production cycle . How about a compromise , such as pointing the issue in the introduction with a forward reference to section 3.7.1 ? --     abbreviations : TLS , DNS , ISP , and  are considered " well known " acronyms according to , and do not need to be spelled out . Changes for spelling our MITM are proposed in PR . 
 Fixed in Pr 
   has entered the following ballot position for draft - ietf - tls - sni - encryption-05 : No Objection 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 : Lovely document ; thanks . Just a collection of nits here : — Section 1 — These attempts have generally floundered , I think the word you want here is “ foundered ” , without the “ l ” . — Section 2.1 — which inspection would intrude with the privacy of employees . “ Intrude on ” . — Section 2.2 — and protection of server certificates transmissions “ certificate ” — Section 2.3 — Deploying SNI encryption will help thwarting most of the Will “ help thwart ” or “ help in thwarting ” ; I think the former sounds better . can however be realized by other means . Needs commas around “ , however , ” . — Section 3.1 — these designs can be broken by a simple replay attack , which works as follow : “ as follows ” attacks breaks that goal “ break ” — Section 3.2 — the multiplexed server , and by every users of the protected services . By “ every user ” or “ all users ” . — Section 3.4 — of TLS handshakes use SNI encryption . If that was the case , the “ If that were the case , ” subjunctive mood . — Section 3.5 — If the corresponding private key was compromised , “ is compromised , ” or , better , “ should be compromised , ” subjunctive again . — Section 3.6 — We can design solutions in which a fronting service act as a relay “ acts ” Middle attack by the fronting service . The downside is the the “ that the ” client will not verify the identity of the fronting service with risks discussed in , but solutions will have to mitigate this risks . You ’re missing something here , a reference after “ in ” ? And “ those risks . ” regular fronting server , using for example spoofed DNS responses Needs commas around “ , for example , ” . — Section 3.7 — Multiple other applications currently use TLS , including for example SMTP [   , DNS [ RFC7858 ] , or XMPP [ RFC7590 ] . Needs commas around “ , for example , ” . Also , “ and ” , rather than “ or ” . These applications too will benefit of SNI encryption . Needs commas around “ , too , ” . Or make it , “ These applications will also benefit ... ” HTTP only methods like those “ HTTP - only ” needs a hyphen . to the need of an application - agnostic solution , that would be implemented fully in the TLS layer . “ need for ” , and “ which would ” . — Section 3.7.1 — specific port numbers exposed in some network . Should this be “ networks ” ? Applications would not need to do that if the ALPN was hidden “ were hidden ” — Section 3.7.2 — Support other transports than TCP “ Support Transports Other than TCP ” requirement to encrypt the SNI apply just as well “ applies ” — Section 4 — when the fronting server and the hidden server are " co - tenant " of the “ co - tenants ” There are however a few issues regarding discovery Needs commas around “ , however , ” . o The client browser 's has to be directed to access The “ client ’s browser ” . cryptographic proof that the content does in fact come from Needs commas around “ , in fact , ” . The solution does thus not mitigate Needs commas around “ , thus , ” . support HTTP Fronting “ supports ” applications over HTTP , such as for example DNS over HTTPS Needs commas around “ , for example , ” . — Section 4.1 — It also requires that the fronting server decrypts and relay messages to the hidden server . “ decrypt ” , more subjunctive . — Section 4.2 — be performed by distributing fake advice , such as " to reach example , use as a fronting server " , There ’s an extra “ example ” on the first line . We can observe that content distribution network have a similar “ networks ” — Section 5 — The current HTTP based “ HTTP - based ” needs a hyphen . 
 Form the  dictionary : to flounder : " to struggle to move or obtain footing " ; to founder : " to send to the bottom , collapse " I think that " flounder " is closer to the intended meaning . 
 Fixed in PR 
 I am the assigned Gen - ART reviewer for this draft . The General Area Review Team ( Gen - ART ) reviews all IETF documents being processed by the IESG for the IETF Chair . Please treat these comments just like any other last call comments . For more information , please see the FAQ at Document : draft - ietf - tls - sni - encryption-05 Reviewer : Meral Shirazipour Review Date : 2019 - 09 - 02 IETF LC End Date : 2019 - 09 - 02 IESG Telechat date : NA Summary : This draft is ready to be published as an Informational RFC . Major issues : Minor issues : Nits / editorial comments : Some may have already been reported … -[Page 2 ] , Section 1 , " colocated"---"collocated " -[Page 3 ] , Section 2 , " mutiple"----"multiple " -[Page 3 ] , Section 2.1 , " fradulent"----"fraudulent " -[Page 4 ] , Section 2.1 , " MITM inspection " , please spell out Man - In - The - Middle attack at first use -[Page 7 ] , Section 3.6 , " is the the"----"is the " -[Page 10 ] , Section 4.2 , " ferver"----"server " Best Regards , Meral Meral Shirazipour Ericsson Research 
 Not fixing " collocated " -- collocated is correct English , but colocated is established industry usage . 
 Fixed in PR 
 Section 3.6 : The downside is the the client will not verify the identity of the fronting service with risks discussed in , but solutions will have to mitigate this risks . Overall , end - to - end TLS to the protected service is preferable . " the the " = " that the " " discussed in , " presumably was intended to include a reference to ... something . " this risks " = " these risks " Section 3.7 : 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 HTTPS case , the HTTPS tunneling service described in Section 4.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 . " benefit to " = " benefit from " " HTTP only " = " HTTP - only " " HTTP 2.0 " = " HTTP/2 " " solution , that would " = " solution which can " Section 4.2 This requires a controlled way to indicate which fronting ferver is acceptable by the hidden service . " ferver " = " server " We can observe that content distribution network have a similar requirement . They need to convince the client that " " can be accessed through the seemingly unrelated " cdn - node- " . Most CDNs have deployed DNS - based solutions to this problem . It might be worth mentioning that when a CDN deploys a " DNS - based solution to this problem , " it also holds the authoritative certificate of the origin .. There is simultaneously verification of a relationship between the origin and the CDN ( because the certificate can be verified ) and a risk that the CDN can spoof the content from the origin . Section 5 Having described in 2.3 that encrypting SNI will simultaneously thwart invasions of the TLS exchange whose purpose is to improve some forms of security , I suspect this is worth a mention in the Security Considerations as well .. Section 7 "     and " = "   ,   , and " 
 Fixed in PR 
 Generally looks fine , though the paragraph in the security considerations section should probably be tweaked a bit more . LGTM with some editorial nits . Thanks ,
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 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 multiple 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 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.
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 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.
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 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.
One of the goals of SNI encryption is to prevent adversaries from
knowing which Hidden Service the client is using.  Successful replay
attacks breaks that goal by allowing adversaries to discover that
service.
It is easy to think of simple schemes in which the SNI is encrypted
or hashed using a shared secret.  This symmetric key must be known by
the multiplexed server, and by every users of the protected services.
Such schemes are thus very fragile, since the compromise of a single
user would compromise the entire set of users and protected services.
One of the goals of SNI encryption is to prevent adversaries from
knowing which Hidden Service the client is using.  Successful replay
attacks break that goal by allowing adversaries to discover that
service.
It is easy to think of simple schemes in which the SNI is encrypted
or hashed using a shared secret.  This symmetric key must be known by
the multiplexed server, and by every user of the protected services.
Such schemes are thus very fragile, since the compromise of a single
user would compromise the entire set of users and protected services.
In the future, it might be possible to assume that a large fraction
of TLS handshakes use SNI encryption.  If that was the case, the
detection of SNI encryption would be a lesser concern.  However, we
have to assume that in the near future, only a small fraction of TLS
connections will use SNI encryption.
In the future, it might be possible to assume that a large fraction
of TLS handshakes use SNI encryption.  If that were the case, the
detection of SNI encryption would be a lesser concern.  However, we
have to assume that in the near future, only a small fraction of TLS
connections will use SNI encryption.
The general concerns about forward secrecy apply to SNI encryption
just as well as to regular TLS sessions.  For example, some proposed
designs rely on a public key of the multiplexed server to define the
SNI encryption key.  If the corresponding private key was
compromised, the adversaries would be able to process archival
records of past connections, and retrieve the protected SNI used in
these connections.  These designs failed to maintain forward secrecy
of SNI encryption.
The general concerns about forward secrecy apply to SNI encryption
just as well as to regular TLS sessions.  For example, some proposed
designs rely on a public key of the multiplexed server to define the
SNI encryption key.  If the corresponding private key should be
compromised, the adversaries would be able to process archival
records of past connections, and retrieve the protected SNI used in
these connections.  These designs failed to maintain forward secrecy
of SNI encryption.
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.
We can design solutions in which a fronting service acts 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.
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 downside is that the
client will not verify the identity of the fronting service, which
enables fronting server spoofing attacks such as the "honeypot"
attack discussed below.  Overall, end-to-end TLS to the protected
service is preferable, but it is important to also provide a way to
authenticate the fronting service.
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 MITM attack
by the fronting service.  The downside is that the client will not
verify the identity of the fronting service, which enables fronting
server spoofing attacks such as the "honeypot" attack discussed
below.  Overall, end-to-end TLS to the protected service is
preferable, but it is important to also provide a way to authenticate
the fronting service.
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.
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.
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.
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
1.1, but interacts awkwardly with the multiple streams feature of
HTTP/2 RFC7540.  This points to the need for an application-agnostic
solution, which would be implemented fully in the TLS layer.
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.
In a sense, ALPN filtering could be very similar to the filtering of
specific port numbers exposed in some networks.  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 were
hidden in the same way as the SNI.
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.
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 applies just as well for these
transports as for TLS over TCP.
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-tenants" of
the same multiplexed server.
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.
The HTTPS in HTTPS solution requires double encryption of every
packet.  It also requires that the fronting server decrypt and relay
messages to the hidden server.  Both of these requirements make the
implementation onerous.
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 requires a
controlled way to indicate which fronting ferver is acceptable by the
hidden service.
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.
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 requires a
controlled way to indicate which fronting server is acceptable by the
hidden service.
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
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 CDNs have deployed DNS-based solutions to
this problem.
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.
This document lists a number of attacks against SNI encryption in
snisecreq, and also in delegationtokens, and presents a list of
requirements to mitigate these attacks.  The current HTTP based
solutions described in httpfronting only meet some of these
requirements.  In practice, it may well be that no solution can meet
every requirement, and that practical solutions will have to make
some compromises.
This document lists a number of attacks against SNI encryption in
snisecreq, and also in delegationtokens, and presents a list of
requirements to mitigate these attacks.  Current HTTP-based solutions
described in httpfronting only meet some of these requirements.  In
practice, it may well be that no solution can meet every requirement,
and that practical solutions will have to make some compromises.
Replacing clear text SNI transmission by an encrypted variant will
also thwart MITM interferences that are sometimes described as
legitimate.  As explained in end-to-end, alternative solutions will
have to be developed.
Thanks to Daniel Kahn Gillmor for a pretty detailed review of the
initial draft.  Thanks to Stephen Farrell, Martin Rex Martin Thomson
and employees of the UK National Cyber Security Centre for their
reviews.
Thanks to Daniel Kahn Gillmor for a pretty detailed review of the
initial draft.  Thanks to Mike Bishop, Stephen Farrell, Barry Leiba,
Martin Rex, Meral Shirazipour, Martin Thomson and employees of the UK
National Cyber Security Centre for their reviews.