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