Thanks, Roman. I have submitted draft-08 with the changes.
On 10/7/2019 12:07 PM, Roman Danyliw wrote: > > Hi Christian! > > > > Thanks for all of the iteration and updates. Given what’s proposed in > github (https://github.com/tlswg/sniencryption/pull/46/files), > consider my comments resolved. Minor comments inline … > > > > *From:*Christian Huitema [mailto:huit...@huitema.net] > *Sent:* Thursday, September 26, 2019 6:53 PM > *To:* Roman Danyliw <r...@cert.org>; The IESG <i...@ietf.org> > *Cc:* draft-ietf-tls-sni-encrypt...@ietf.org; tls-cha...@ietf.org; > tls@ietf.org > *Subject:* Re: [TLS] Roman Danyliw's No Objection on > draft-ietf-tls-sni-encryption-05: (with COMMENT) > > > > > > On 9/26/2019 11:38 AM, Roman Danyliw wrote: > > Hi Christian! > > > > Thanks for all of the updates. I have a remaining items are described > inline. > > > > To bring up a new item, there was new text introduced in -06 of Section 5 > to which I strongly object. Specifically: > > > > "Replacing clear text SNI transmission by an encrypted variant will > > also thwart MITM interferences that are sometimes described as > > legitimate. As explained in Section 2.3, alternative solutions will > > have to be developed.” > > > > I read this paragraph as addressing the operational practices outlined in > Section 2.1. I think it is inappropriate to refer to some of these > operational practices as being "sometimes described as legitimate". > > Anything performed by MITM is by definition controversial. But I get > your point. How about > > "Replacing clear text SNI transmission by an encrypted variant will break or > reduce the > efficacy of the operational practices and techniques implemented in > middle-boxes as > described in Section 2.1. As explained in Section 2.3, alternative solutions > will > have to be developed." > > [Roman] Looks good to me. Thanks. > > > > -----Original Message----- > > From: Christian Huitema [mailto:huit...@huitema.net] > > Sent: Wednesday, September 25, 2019 3:47 PM > > To: Roman Danyliw <r...@cert.org> <mailto:r...@cert.org>; The IESG > <i...@ietf.org> <mailto:i...@ietf.org> > > Cc: draft-ietf-tls-sni-encrypt...@ietf.org > <mailto:draft-ietf-tls-sni-encrypt...@ietf.org>; tls-cha...@ietf.org > <mailto:tls-cha...@ietf.org>; tls@ietf.org <mailto:tls@ietf.org> > > Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni- > > encryption-05: (with COMMENT) > > > > Hello Roman, > > > > A lot of the fixes that you suggested are incorporated in the > draft-07 that was > > just released. I think the last version addresses your concerns, but > you may > > of course want to verify. > > > > On 9/25/2019 7:27 AM, Roman Danyliw wrote: > > Hi Christian! > > > > Thanks for the detailed responses and the helpful background. > Below are a > > number of proposed text block replacements to clarify my intent > (instead of > > more questions). > > > > Roman > > > > -----Original Message----- > > From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of > Christian > > Huitema > > Sent: Wednesday, September 18, 2019 10:14 PM > > To: Roman Danyliw <r...@cert.org> <mailto:r...@cert.org>; The > IESG <i...@ietf.org> <mailto:i...@ietf.org> > > Cc: draft-ietf-tls-sni-encrypt...@ietf.org > <mailto:draft-ietf-tls-sni-encrypt...@ietf.org>; tls-cha...@ietf.org > <mailto:tls-cha...@ietf.org>; > > tls@ietf.org <mailto:tls@ietf.org> > > Subject: Re: [TLS] Roman Danyliw's No Objection on > > draft-ietf-tls-sni- > > encryption-05: (with COMMENT) > > > > 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. > > Thanks. > > > > Changes incorporated in first paragraph of section 1. > > > > The text -07 works for me. Thanks for adding this extra bit. > > > > > > ** 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? > > I'm not sure I understand the original of the requirement that > the client > > and server being in the same management domain. > > > > RFC3546's definition of SNI opens with: > > [TLS] does not provide a mechanism for a client to tell a > server the > > name of the server it is contacting. It may be desirable for > clients > > to provide this information to facilitate secure connections to > > servers that host multiple 'virtual' servers at a single > underlying > > network address. > > > > It seems to me that if we are trying to channel original intent, > then only the > > virtual server use case applies. I'd propose: > > > > OLD > > 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]. > > > > NEW > > The SNI was defined to facilitate secure connections to servers > that host > > multiple 'virtual' servers at a single underlying network address > [RFC3546]. > > However, addition management and security practices emerged making use > > of this information. Examples of such usage are reviewed in > [RFC8404]. > > > > This language would let you distinguish all of the middle box > behaviors > > done by operators and enterprises from a possible [RFC7258] attacker. > > > > As I noted in my reply to Ben, I don't follow the current language for > anticipated/unanticipated. > > > > https://mailarchive.ietf.org/arch/msg/tls/54cEpjUcIZqNW_y7Eb344XLQp0Y > > > > -- 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. > > > > The -07 text works for me. Thanks. > > > > ** 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. > > I still think this needs to be cleaned up in some way. IMO, I'd > drop it. > > > > Was rewritten in new section 2.1 as "Filtering or censorship of > specific > > services for a variety of reasons." > > > > I'm still struggling with the specificity here and the overlap. Dropping > the censorship and it reads "filtering of specific services for a variety of > reasons". That's exactly what bullet 2 (content filtering by operators) and > bullet 3 (enterprise firewalls for NSFW) > > > > What's unique about this bullet -- is it who is doing this > filter/censorship? where it is happening? What tech is being used? > > For example, arbitrary filtering of web sites competing with other > services preferred by the network provider. Some filtering and > censorship is more controversial than others. But I don't think that > listing every controversial usage would be appropriate. I would rather > keep the somewhat vague phrasing than try to have a debate about which > practice is controversial and which is not. > > [Roman] Understood. Point made. The text is neutral enough for me > now, and I won’t push further (for editorial clarity). Thanks. > > > > ... > > ** 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. > > IMO, explicitly linking it to the draft would help. > > > > OLD: > > 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. > > > > NEW: > > The SNI could be included in the general collection of metadata by > > pervasive monitoring attacker [RFC7258], for example to identify > > services used by surveillance targets. > > > > I missed the reference to 7258. Will add it in the next version. > > > > Recommend adding the RFC7258 reference. As I noted above, the semantics > of "probably" vs. "could". "probably" suggests a confidence to me. > > Yes, there is some confidence, based on the Snowden revelation of > systems like Quantum Insert, comments like "recording the whole > haystack", or the Korean regulation explicitly targeting the SNI > field. It is more probable than not that SNI data is being recorded, > and I think that "probably" is just fine. > > [Roman] I can live with just the RFC7258 reference. Thanks for adding it. > > > > > > > > > > ** 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. > > I understand. I didn't read it that way. My recommendation > isn't to > > describe the "other means" (as it is described below), but to be > clear on the > > obvious, what is the SNI information. > > > > OLD: > > One reason may be that, when these RFCs were written, the SNI > > information was available through a variety of other means. > > > > NEW: > > One reason may be that when the RFCs were written, the name of the > > server the being contacted by the client (i.e., the SNI) was evident > through > > other means. > > > > The new text in -07 reads more clearly to me. Thanks for this change. > > > > ** 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... > > Thanks. > > > > -- 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. > > > > Thanks for this. > > > > Works for me. However, I'd drop "Most of these functions can, > however, > > be realized by other means" because this opens the debate on how > exactly, > > etc. > > > > I still recommend dropping the "other means" text because that opens > debate. > > > > ** 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). > > > > Now that censorship got added to the list in Section 2.1, you likely want > to: > > > > s/including censorship and pervasive surveillance/including pervasive > surveillance/ > > > > Otherwise, LGTM. Thanks. > > OK. > > > > ... > > ... > > > > "This document does not present the design of a solution, but provides > > guidelines for evaluating proposed solutions." However, the current > text in > > Section 4 is explicitly states it is providing a solution. The > sub-section of > > Section 4.x assume the solution in Section 4.0 and describe the > follow-on > > work. Section 2 - 3 do lay out the means for evaluation nicely. > Perhaps, > > something on the order of: > > > > OLD: > > This document does not present the design of a solution, but > provides > > guidelines for evaluating proposed solutions. > > > > NEW: > > This provides guidelines on evaluating solution and proposes an > > architecture to mitigate the threats created by an unencrypted SNI > using > > existing approaches. > > > > > > I added the reference to a paper by Fified et al. that describes the > "domain > > fronting" solution and some of its deployments. > > > > Note that the intent is not to recommend the domain fronting solution. > That solution, and the HTTPS tunnel solution, are examined as example > of proposed solutions that meet some of the requirement but not all. > But I understand that you perceived the text as some kind of endorsement. > > [Roman] Right, but I also think the citation helps that you’re > describing an existing practice. The new language in added in > https://github.com/tlswg/sniencryption/pull/46/files works for me. > Thanks. > > ... > > > > > > Draft 07 added text describing actual deployments. > > > > The use of the [domfront] citation works for me and addresses my > concerns. Two nits: > > > > ** I'd recommend using the URL to the paper from conference site itself: > https://petsymposium.org/2015/papers/03_Fifield.pdf > > OK. > > > > > > ** I'd also recommend adding a sentence to the last paragraph of Section > 1, "This document does not present the design ...", to foreshadow that you'll > discuss an alternative approach even if encrypted SNI isn't realized yet. > > OK, will try make clear that this is not an endorsement or a proposal. > > [Roman] I think you have it covered in the new language in > https://github.com/tlswg/sniencryption/pull/46/files. > > Regards, > > Roman > > -- Christian Huitema > > > > > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
