Hi Ben, Thanks for checking back through the responses. inline
On Tue, Feb 13, 2018 at 2:35 PM, Ben Campbell <b...@nostrum.com> wrote: > Hi Kathleen, > > Thanks for your response. Comments inline; I deleted sections that do not > seem to need further discussion. > > Thanks! > > Ben. > >> On Feb 9, 2018, at 1:18 PM, Kathleen Moriarty >> <kathleen.moriarty.i...@gmail.com> wrote: >> >> Hi Ben, >> >> Thanks again for the comments, responses and proposals are inline. >> >> On Wed, Feb 7, 2018 at 12:40 AM, Ben Campbell <b...@nostrum.com> wrote: >>> Ben Campbell has entered the following ballot position for >>> draft-mm-wg-effect-encrypt-17: 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-mm-wg-effect-encrypt/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> This is a considerably better document than the previous versions I have >>> reviewed. Thanks for all that work. But of course, I still have some >>> comments >>> :-) >>> >>> Substantive Comments: >>> >>> -2.2.2, 2nd paragraph: "... for example, many >>> forms of communications (from isochronous/real-time to bulk/elastic >>> file transfer) will take place over HTTP port 80 or port 443, so only >>> the messages and higher-layer data will make application >>> differentiation possible." >>> >>> I'm confused about the use of port 443 in that sentence; presumably traffic >>> to >>> 443 will be encrypted and not allow differentiation using higher-layer data. >> >> TLS 1.2 does leave data exposed for differentiation, SNI for example. >> TLS 1.3 leaves some, but there will be options to encrypt SNI at some >> point in the future. The response to ALPN will be returned in >> encrypted extensions in TLS 1.3. These are just the examples that >> come readily to mind and are included in the document. >> >> Do you think additional text is needed in this section around the port >> 443 example or is this covered enough later in the document? > > No, I think that's fine. I was not thinking about information revealed by TLS > itself. Thanks for confirming. > >> >> >>> >>> -2.2.4: This section lacks a discussion of the impact of encryption. >> >> Good point. I added one sentence at the edn of the second to last >> paragraph and modified the last paragraph as follows. Let me know if >> this looks good or you would like to see changes. >> >> If impacted by encryption, performance enhancing proxies could make >> use of routing >> overlay protocols to accomplish the same task, but this results in >> additional overhead. >> >> An application-type-aware network edge (middlebox) can further >> control pacing, limit >> simultaneous HD videos, or prioritize active videos against new videos, >> etc. >> Services at this more granular level are limited with the use of >> encryption. > > WFM. > >> >>> >>> -2.2.5, last paragraph: I understand that techniques that require endpoint >>> cooperation might be out of scope, but the tone of this paragraph makes it >>> sound like requiring endpoint cooperation is a negative. Is that the intent? >> >> Good catch, no that was not the intent and is in conflict with the >> following sentence. How about the following modification: >> >> Alternate approaches are in the early phase of being explored to >> allow caching of >> encrypted content. These solutions require cooperation from >> content owners and >> fall outside the scope of what is covered in this document. >> Content delegation >> allows for replication with possible benefits, but any form of >> delegation has the >> potential to affect the expectation of client-server confidentiality. > > WFM. > > […] > >>> >>> -2.3.1: I think it might be worth mentioning that an "intercepting >>> certificate" >>> requires endpoints to be configured to trust that certificate. (I assume we >>> are >>> not talking about the more unsavory practice of certificates that >>> misrepresent >>> their subjects. >> >> OK, I read this as being covered, but added the following as it must >> not be clear enough to others if you raised this point (thanks for >> doing so): >> >> Content filtering via a proxy can also utilize an intercepting >> certificate where >> the client's session is terminated at the proxy enabling for >> cleartext inspection >> of the traffic. A new session is created from the intercepting >> device to the >> client's destination, this is an opt-in strategy for the client, >> where the endpoint >> is configured to trust the intercepting certificate. Changes to >> TLSv1.3 do not >> impact this more invasive method of interception, where this has >> the potential >> to expose every HTTPS session to an active man in the middle (MitM). > > WFM. > >> >>> >>> -2.3.4 I concur with Adam that this section should explicitly mention >>> "cross-site user tracking" as one of the common motivations for header >>> insertion/enrichment. I think it should also include a mention of RFC 8165. >> >> Adam's request has already been addressed by adding that text. How >> abotu the following paragrpah to address the addition of an 8165 >> reference and for it to make sense in context of the document: >> >> Guidance from the Internet Architecture Board has been provided in RFC8165 >> on Design Considerations for Metadata Insertion. The guidance asserts >> that >> designs that share metadata only by explicit actions at the host >> are preferable >> to designs in which middleboxes insert metadata. Alternate notification >> methods that follow this and other guidance would be helpful to >> mobile carriers. > > Looks good. Thanks! > > >> >>> >>> -5.2: This section doesn't seem to include discussion of the impact of >>> encryption. >> >> I added the following to address your comment, thank you. >> >> The impact of encryption can be understood from their documented use >> cases I-D.ietf-dots-use-cases. > > Okay. > >> >>> Editorial and nits: >>> > > […] > >>> >>> -2.2.5, first paragraph: " Encryption of packet contents at a given >>> protocol layer usually makes DPI processing of that layer and higher >>> layers impossible. " >>> >>> This sentence seems misplaced; the section is not about DPI. >> >> Hmm, I read this as DPI being used in these functions, hence the >> impact of encryption. I'm wondering if reading the first sentence >> again helps: >> >> The features and efficiency of some Internet services can be augmented >> through analysis of user flows and the applications they provide. >> >> Or if I am missing something. If so, please let me know! >> > > No, I apparently lost state between the first sentence and the sentence I > commented on :-) Happens to all of us :-) > > […] > > >>> >>> -3.1.2: This section is about Hosting SPs, but the last two paragraphs seem >>> to >>> be about ASPs. While I realize those may sometimes be the same organization, >>> they are architecturally distinct. >> >> I changed the section heading for 3 to include application service >> providers as the document doesn't have another place for that content. >> I agree with the distinction you are making, let me know if this is an >> okay fix. >> > > ThaWFM. > >>> >>> -3.2.2: "STARTTLS ought have zero effect..." >>> "Ought to have zero effect" or "has little effect"? (If the former, it's >>> safe >>> to say "should" since this draft does not use RFC 2119 keywords.) >> >> This wording came from Stephen in his original AD review, so we stuck with >> it. >> Ought to has been pretty common practice in RFCs, but I guess we used >> to see this more at the beginning of my term as an AD. I'll add the >> to and if anyone else wants it changed, it's not a big deal. > > I did not mean to complain about “ought to” per se, but I was wondering why > the text used a subjunctive from for what seemed like a statement of fact. > Was the point to talk about the way things should be, or the way things are > (or maybe are expected)? I'm happy to change and will do so :-) . I'll use should to capture what was intended. > >> >>> >>> -12: Are there really no normative references? The definition of a >>> "normative >>> reference" is any reference needed to fully implement or _understand_ the >>> document. This is true for both informational and standards-track >>> documents. Do >>> you think a reader can fully understand this document if they ignore every >>> reference? (I'm willing to accept that the answer might be "yes" given the >>> nature of this draft--but that situation is rare in practice.) >> >> We'll think about this a bit more, thanks. >>> >>> > > To be clear, I’m perfectly happy if you decide that there really are no > normative references; I just wanted to make sure it was thought about. OK, Al and I need to chat about this one still. Thank you, again! Kathleen > -- Best regards, Kathleen _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
