Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)

[Christian Huitema <[e-mail]>]

Thanks for the feedback, Roman. Comments in line.

On 9/18/2019 4:40 AM, Roman Danyliw via Datatracker wrote:
> ** 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)


OK, will try to incorporate your text.

>
> ** 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.

It is pretty clear that the load balancer in front of a server farm will 
need access to the service ID, and must be able to retrieve the 
decrypted SNI. There may be other examples, such as DoS mitigation 
boxes. The "unanticipated usage" comes typically from middle-boxes that 
are not in the same management domain as either the client or the 
server. Is there an established way to designate those?

> -- 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.
A few of the examples also come in the "deep packet inspection" sections 
of 8404. But rather than going in a long discussion, I would rather 
rewrite the sentence as: Many examples of such usage are reviewed in 
[@?RFC8404], other examples came out during discussions of this draft.
>
> ** 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.
See answer to Alissa. Removing the quotes.
>
> ** 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.

Yes, Mirja made a similar comment. Proposed replacement:

The SNI is probably also included in the general collection of metadata
by pervasive surveillance actors, for example to identify services
used by surveillance targets.

>
> ** 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?

The list includes at a minimum:

Clear text exchanges amenable to deep packet inspection (DPI), server 
certificates send in clear text during TLS/SSL exchanges, DNS names of 
servers in clear text DNS queries, and server specific IP addresses in 
packet headers.

I guess I could write that all, but it makes the text a bit redundant, 
since the following paragraphs do discuss server certificates, DNS names 
and IP addresses.

>
> ** 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?
Removing the quotes. Otherwise, you will be convinced that the authors 
believe that all middle-boxes are the spawn of the devil...
> -- 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”.

OK. I will try to make the text just stick to the facts:

Deploying SNI encryption thwarts most of the unanticipated SNI usages
described in (#snileak). It reduces the efficacy of the operational 
practices and
techniques implement in middle-boxes. Most of
these functions can, however, be realized by other means.
>
> ** 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.
We are describing here a series of design proposed in the TLS working 
group over the years. The whole point of the draft is to provide the 
results of the analyses, as an easy to read kind of "threat model", 
without requiring readers to wade through years of archives. If you 
really are interested, you can indeed do just that but I would not 
encourage the approach...
>
> ** 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.
Got comments about that already, and updated the text.
>
> ** 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”.
Yes, I get that. Our point is to describe this solution as part of 
explaining why we really want a TLS level solution, not just HTTP. Not 
sure that I can change much here.
>
> ** 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.

That's really hard, because it is all cloak and dagger stuff. The one 
well known example is the encrypted messaging application "Signal", that 
was censored in Egypt during the "Arab Spring" events. They were hosted 
by Google, and apparently programmed their app to just connect to 
"https://google.com/", and then use "host: signal.org" in the HTTP 
headers, evading censorship. It is not clear at all to what amount they 
synchronized with Google when doing that. And I don't think that anybody 
ever spoke openly about this.

> ** 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)
Yes. Already fixed.
>
> ** 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.

The "Signal" deployment used a service specific app. The trick of using 
https://fronting + Host: hidden is really easy to pull in an app. To do 
that in a browser does indeed require an extension, that's pretty much a 
statement of fact.