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. > > >> >> -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. > >> >> -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 :-) […] >> >> -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)? > >> >> -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.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
