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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-tls-sni-encryption-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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