Issues and Requirements for Server Name Identification (SNI) Encryption in TLS
draft-ietf-tls-sni-encryption-09

** Section 1.  Per “More and more services are colocated on multiplexed servers, loosening the relation between IP address and web service”, completely agree.  IMO, unpacking “multiplexed servers” is worthwhile to explain the subsequent text because it motivates the loss of visibility due to encryption with network only monitoring.  “Multiplex’ happens at two levels:

-- co-tenants (e.g., virtual hosting) – multiple services on the same server (i.e., an IP/port doesn’t uniquely identify the service)

-- cloud/cdn  – a given platform hosts the services/servers of a lot of organization (i.e., looking up to what netblock an IP belongs reveals little)

** Section 2.1.  Per “The SNI was defined to facilitate management of servers, though the developers of middleboxes soon found out that they could take advantage of the information.  Many examples of such usage are reviewed in [RFC8404].”, 

-- Can’t middleboxes also help facilitate the management of servers?  This text seems to take a particular view on middleboxes which doesn't seem appropriate.

-- RFC8404 describes a number of middlebox practices, but only Section 6.2 explicitly discusses SNI, and of the examples list here, only one comes from RFC8404.

** Section 2.1. The “monitoring and identification of specific sites” isn’t symmetric to the other examples – it is rather generic.  The other examples, identify a what/who (e.g., ISP, firewall) + action (e.g., block, filter).  Also, to implement most of the other example, “monitoring and identification of specific sites” needs to be done.

** Section 2.1.  Why is parental controls in quotes?  In RFC8404, it is not.  The quotes could be read as a judgement on the practice.

** Section 2.1.  Per “The SNI is probably also included in the general collection of metadata by pervasive surveillance actors”, I recommend against speculation and instead simply stating that SNI would be interesting meta-data for a RFC7258 attacker.

** Section 2.2.  Per “One reason may be that, when these RFCs were written, the SNI information was available through a variety of other means”, what would those “other means” be?

** Section 2.3.  Per “Deploying SNI encryption will help thwarting most of the ‘unanticipated’ SNI usages described in Section 2.1, including censorship and pervasive surveillance.”:

-- Why the quotes around "unanticipated" SNI usage?

-- One person’s censorship is another person’s threat mitigation, policy enforcement for a network they own, or parental controls (per the list in Section 2.1) – recommend being more precise on the order of “Deploying SNI encryption will {break | reduce the efficacy of } the operational practices and techniques used in middleboxes described in Section 2.1”.

** Section 2.3.  Per “It will also thwart functions that are sometimes described as legitimate”, what functions are those?  I’d recommend eliminating this sentence as it reads like a value judgement on existing practices (which doesn’t seem germane for discussing requirements).

** Section 3.  Per “Over the past years, there have been multiple proposals to add an SNI encryption option in TLS.”, can these past proposals be cited so future readers can learn from them.

** Section 3.4. The existence of designs were alluded to but not cited.  Be specific with citation.

** Section 3.7.1. The rational for including this discussion about ALPN isn’t clear as it doesn’t suggest new requirements for SNI encryption.

** Section 4.  I got hung-up on the description of Section 4 describing a “solution”.  Is Section 4 (and the related subsections) describing an operational practice or a notional reference architecture?  The text reads one part “people are doing” and another part “people could do”.

** Section 4.  Per “In the absence of TLS-level SNI encryption, many sites rely on an "HTTP Co-Tenancy" solution”, this seems like a strong of a statement about utilization of this architecture explicitly to hide the hidden.example.com SNI.  Can you provide a citation for a sense penetration.

** Section 4.  Per the bullet “since this is an HTTP-level solution”, I recommend citing that it fails on the requirement identified in Section 3.7 (instead of enumerating a list of protocols)

** Section 4.  The opening of this section noted that “many sites” rely on the architecture described in this section. Later, it is noted that “a browser extension that support[s] HTTP Fronting” is a necessary architecture component.  Can a few citations be made to the popular extensions.

** Section 4.2.  Per "to reach example   hidden.example.com, use fake.example.com as a fronting server", shouldn’t this read: “to reach hidden.example.com, use fake.example.com as a fronting server"?

** Editorial Nits
-- Section 2.  Typo.  s/mutiple/multiple.

-- Section 2.1. Typo.  s/fradulent/fraudulent/

-- Section 3.1.  “Hidden Service” is capitalized in a few places like it is a proper noun?  Is it meant to be?  If so, define or cite it.

-- Section 3.6. s/the the/

-- Section 4.1. s/tunnelling/tunneling/

-- Section 4.2. s/ferver/server/

-- Section 7.  s/Martin Rex Martin Thomson/Martin Rex, Martin Thomson/

Firstly, thank you for writing this -- I think that it is useful and important...

I have some comments -- mostly nits and questions.

1: "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."
I don't think the purpose of privacy is to prevent that -- perhaps "The purpose of SNI encryption is to prevent that." or "to prevent that and aid privacy."? 

2: "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."
Does encrypting the SNI really "complete" this in the "we can all declare success and go home" sense?

3: Also, I think I'm missing something -- RFC3552 is "Security Considerations Guidelines" --- I don't think it actually describes *an* adversary, rather it describes a number of different  attacks / adversaries (including things like DDoS). I think this needs words (e.g MITM / active attacker / something) (yes, I know that people sometimes use this term, and that EKR is an author...)

4: "The downside is the the client will not verify the identity of the fronting service with risks discussed in , but solutions will"
a: "the the" b: this seems to be missing a word / reference.

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 Warren, 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.

Thank you for this document.

One small thing:

Please use RFC 8314 instead of RFC 2595 as a reference for IMAP over TLS.

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/

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 [RFC5246], 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
   hidden.example.com, use fake.example.com 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.

Thanks for clearly writing down attacks and requirements in this document.

One small technical comment on this sentence:
Sec 2.3: "Per-stream
   QoS can be provided by a combination of packet marking and end-to-end
   agreements."
If this sentence is meant to mean use of DSCP, I don't think this is true, as DSCP is usually not available end-to-end but most often gets changed or bleached somewhere on the path.

And two editorial comments:

Sec 2.1: "The SNI was defined to facilitate management of servers, though the
   developers of middleboxes soon found out that they could take
   advantage of the information."
"soon found out" does sound a bit story-telling like to me. I recommend a more objective phrasing like:
"The SNI was defined to facilitate management of servers, though other usages by middleboxes also take
   advantage of the information."
or something similar...

Also sec 2.1: "The SNI is probably also included in the general collection of
   metadata by pervasive surveillance actors."
This sentence is phrased a bit speculatively and at the same kind seems inherently true as a "pervasive surveillance actor" usually just collect all available data/traffic... I guess the more interesting question would be if and how this information is used. Anyway I recommend some rephrasing like:
"The SNI could also be utilised by the general collection of
   metadata by pervasive surveillance actors."