[TLS] AD review of draft-ietf-tls-sni-encryption-04

[Benjamin Kaduk <[e-mail]>]

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