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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
