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. -2.2.4: This section lacks a discussion of the impact of encryption. -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? -2.3, section title: The title is only partially evocative of the section content. I suggest adding "content filtering". -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. -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. -5.2: This section doesn't seem to include discussion of the impact of encryption. Editorial and nits: -IDNits finds a number of unused references, and a few other reference issues. Please check. - Abstract: 2nd sentence is hard to parse, and ends with a comma splice. - 1, 2nd paragraph: " The following informational documents consider the end to end (e2e) architectural principle, a guiding principle for the development of Internet protocols [RFC2775] [RFC3724] [RFC7754]." Is the comma correct? It currently reads along the lines of "The documents consider the e2e principle, and we think that it is a guiding principle...", but I think you might mean "The documents consider the e2e to be a guiding principle..." -1, 3rd paragraph: "... (including methods for network endpoints where applicable)..." Should that say "methods that rely on network endpoints"? -2.1.1: Please expand "CAIDA" -2.1.1: Paragraph starting with " When using increased encryption, operators lose a source of data that may be used to debug user issues." I don't think the operators are the ones using the encreased encryption in that sentence. Perhaps "When endpoints use increased encryption..." or even (When increased encryption is used..." -2.1.3, 2nd paragraph: "The ability to examine layers and payloads above transport provides a new range of filtering opportunities at each layer in the clear. " Should "new range" be "increased range"? -2.1.3, third paragraph: The last sentence seems out of place. Is the point of the paragraph to point out that the use of these monitoring techniques for DoS mitigation can't be distinguished from the use of them for privacy violation? -2.2.1: Please expand "QUIC" and add a citation. -2.2.3, last sentence: Sentence fragment. -2.2.4, first sentence: Comma splice. -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. -- same paragraph: I don't understand the point(s) of the last two sentences. -2.2.5, third paragraph: "The Enhanced Multimedia Broadcast/ Multicast Services (3GPP eMBMS) - trusted edge proxies facilitate delivering same stream to different users, using either unicast or multicast depending on channel conditions to the user. " I can't parse that sentence. -2.3.3: Please make the "SHOULD" lower case. Since this document does not use RFC 2119/8174 keywords, a capitalized SHOULD should not appear outside of a literal quote. -3: "Businesses understanding the threats of monitoring in hosted environments only increased that pressure to provide more secure access and session encryption" Why "only"? That seems to suggest one would expect some different result. -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. -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.) -3.2.2, last paragraph: Should "SPAM filtering" be "content-based SPAM filtering"? -4.2: What does it mean for tools to "use" keywords? Does this mean "search for" or "monitor for" keywords? -5.4: This seems to say that "Detection and Mitigations" involves thousands of hosts, etc. I think the point is that the botnets themselves may involve thousands of hosts..." -7 and subsections: It looks like the editing of this section is not finished; several sections indicate they are to be deleted. -7.4: Please describe what you mean by "transit proxies". I can't parse item 4. The entire section could use proofreading for missing articles. -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.) _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
