Hi all,
I must start with an apology that this review has taken so long. My
personal life has kept me quite busy for the past few months and I didn't
have much time for anything other than the IESG telechat workload, but things
are quieting down and I am starting to clear through the "publication
requested" backlog. I don't think there's anything terribly controversial
in these review comments, so hopefully it will be easy to spin up a new rev
and kick off the IETF LC.
-Ben
Abstract
We should probably say "TLS" somewhere.
Section 1
Historically, adversaries have been able to monitor the use of web
services through three channels: looking at DNS requests, looking at
IP addresses in packet headers, and looking at the data stream
between user and services. [...]
Is this intended to be an exhaustive list, or just the main channels?
Progressive
deployment of solutions like DNS in TLS [RFC7858] mitigates the
disclosure of DNS information. [...]
We could probably mention DoH here as well, especially since we do
mention it later on in Section 2.2.
However, multiplexed servers rely on the Service Name
Information (SNI) to direct TLS connections to the appropriate
service implementation. [...]
nit: add "TLS extension" after "(SNI)"?
In the past, there have been multiple attempts at defining SNI
encryption. These attempts have generally floundered, because the
simple designs fail to mitigate several of the attacks listed in
Section 3. In the absence of a TLS level solution, the most popular
approach to SNI privacy is HTTP level fronting, which we discuss in
Section 4.
Should we mention that this (obviously) does not work for services that
do not use HTTP?
Section 2
The SNI specification allowed for different types of server names,
but only the "hostname" variant was standardized and deployed. [...]
We need to be careful about using the word "standardized"; IIUC this
stuff has only ever been at proposed standard, so "specified" may keep
us safer from the process wonks.
server. The SNI extension is carried in clear text in the TLS
"Client Hello" message.
RFC 8446 also has it in "EncryptedExtensions".
nit: we seem to spell it without a space, i.e., "ClientHello", in RFC
8446.
Section 2.1
advantage of the information. Many examples of such usage are
reviewed in [RFC8404]. They include:
o Censorship of specific sites by "national firewalls",
"national firewalls" does not appear in RFC 8404, so I don't think the
8404 reference supports this claim. (The claim seems to be true,
though, so presumably just a different reference is needed.)
o Content filtering by ISP blocking specific web sites in order to
implement "parental controls", or to prevent access to fraudulent
web sites, such as used for phishing,
parental controls and phishing are well-covered in 8404, but the string
"fraud" does not appear there.
o ISP assigning different QOS profiles to target services,
nit: "QoS", to help people searching in 8404 with case-sensitive
searches
o Enterprise firewalls blocking web sites not deemed appropriate for
work, or
8404 includes a great deal of discussion about "enterprise[s]", but a
statement from Section 2.3.1 ("Content Filtering") is interesting to note
here:
% There are numerous reasons why service providers might block content:
% to comply with requests from law enforcement or regulatory
% authorities, to effectuate parental controls, to enforce content-
% based billing, or for other reasons, possibly considered
% inappropriate by some. See RFC 7754 [RFC7754] for a survey of
% Internet filtering techniques and motivations and the IAB consensus
% on those mechanisms. This section is intended to document a
% selection of current content-blocking practices by operators and the
% effects of encryption on those practices. Content blocking may also
% happen at endpoints or at the edge of enterprise networks, but those
% scenarios are not addressed in this section.
Do we envision these "Enterprise firewalls" appearing at the edge, or
elsewhere within the enterprise networks?
o Enterprise firewalls exempting specific web sites from MITM
inspection, such as healthcare or financial sites for which
inspection would intrude with the privacy of employees.
(This seems like Section 4.2 of RFC 8404.)
Section 2.2
Many deployments still allocate different IP addresses to different
services, so that different services can be identified by their IP
addresses. However, content distribution networks (CDN) commonly
serve a large number of services through a small number of addresses.
side note: working as I do for a CDN, I am pretty confident that the
number of addresses is not always "small" on an absolute scale. Perhaps
"comparatively" is appropriate :)
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
Section 2.1 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].
Do we also want to say something about the need for re-correlation, and
the in-band nature of SNI being "more convenient" in some sense?
In TLS versions 1.0 [RFC2246], 1.1 [RFC4346],
and 1.2 [RFC5246], the server send their certificate in clear text,
nit: singular/plural mismatch for "the server" and "send".
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].
We may want to add some caveats about this protection being limited, and
that in many cases replaying a ClientHello with a fresh (known) key
share would produce the same Server Certificate in the reply, as is
(roughly) described in Section 3.1.
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 seems to presume a given model of privacy, probably one in which
the adversary is an RFC 3552-style in-network attacker. I would suggest
to make this explicit, perhaps via "contribute to user privacy in the
face of an [RFC3552]-style network attacker".
this push for privacy and make it harder to censor specific internet
services.
"censor" is highly charged language, and while we do consider
"censorship of specific sites by "national firewalls"" earlier in the
text, we also mention several other unanticipated usages of SNI, which
are now being tarred with the same brush. Perhaps "censor or otherwise
provide differential treatment to" is more appropriate?
Section 2.3
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.
hyphenation nits: "Per-stream", "end-to-end"
At the moment enterprises have the option of installing a firewall
nit: comma fater "At the moment".
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
nit: "wide-scale"
leaving the enterprise, which may not be desirable. Enterprises
managers could rely instead on filtering software and management
software deployed on enterprises computers.
nit: "the enterprise's" (?)
Section 3
Over the past years, there have been multiple proposals to add an SNI
encryption option in TLS. Many of these proposals appeared
promising, but were rejected after security reviews pointed plausible
attacks. In this section, we collect a list of these known attacks.
nit: "pointed out"
Section 3.3
nit: I think "front-end component" is most commonly hyphenated (and
"SNI-based" would be as well).
We could also reiterate that the affected front-end component would
affect multiple back-end services, if we want.
Section 3.6
It's not entirely clear what the section title is trying to convey; would
something about a "three-party security model" be appropriate?
Sectio 3.7
If the SNI encryption solution places too
much trust on the fronting server, the fake server could also serve
fake content of its own choosing, including various forms of malware.
If this is intended to be distinct from the MITM case described in the
previous section, more clarification is needed. Even if not, it may be
worth trying to consolidate the content into just a single location.
Section 3.8
nit: "application-agnostic" is hyphenated.
Section 3.8.2
Is this really about transports other than HTTP, or other than TCP (in
the section heading)?
Section 4
nit: "TLS-level" is hyphenated.
o Since the TLS connection is established with the fronting service,
the client has no proof that the content does in fact come from
the hidden service. The solution does thus not mitigate the
context sharing issues described in Section 3.6.
nit: perhaps "no cryptographic proof"?
o Since this is an HTTP level solution, it would not protect non
nit: "HTTP-level" is hyphenated, as is "non-HTTP" spanning the line
break.
The discovery issue is common to pretty much every SNI encryption
solution. The browser issue may be solved by developing a browser
nit(?): I don't know if "pretty much every" is in the RFC style.
Section 4.2
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 CDN have deployed DNS-based solutions to this
problem.
nit: "Most CDNs", plural
Section 5
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 provide
guidelines for evaluating proposed solutions.
nit: "provides".
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
