Hi Deborah, On Wed, Feb 7, 2018 at 4:35 PM, Deborah Brungard <db3...@att.com> wrote: > Deborah Brungard 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: > ---------------------------------------------------------------------- > > Thanks for handling my other comments, the abstract and intro for setting > context are much improved. I found some sections still though need some > neutrality/tweaking, others have already provided detailed comments. > > For me, section 8 as the "way forward" is especially weak and confusing. As > the > last section of a very detailed, lengthy document, a more concise, > stronger summary is needed on the purpose of the document.
Great point, I moved some of the examples into section 1.2 and one is overlapping, so that has been deleted. I also noticed your prior request to include a sentence on operators support of encryption (which we've heard from many operators) was removed from the introductory text when other text replacements were provided. I think it makes sense to add it back into section 8 as that will also help the tone of the document so readers understand there is wide support for encryption and this document seeks to find ways to increase adoption of strong session encryption. How about the following for Section 8: As stated in RFC7258, "an appropriate balance (between network management and PM mitigations) will emerge over time as real instances of this tension are considered." This document is intended as a first step for engineers and other innovators to work toward solving network and security management problems with protocol designers and application developers in new ways rather than preventing the use of encryption. Numerous operators made it clear in their response to this document that they fully support strong encryption and providing privacy for end users, this is a common goal. By having the discussions on network and security management practices with application developers and protocol designers, each side of the debate can understand each others goals and work toward alternate solutions. A goal of this document is to increase adoption of strong session encryption as a result of work spurred on by documenting the current practices of operators resulting in new work items tackling only the IETF supported use cases faced by operators. > > "Changes to improve encryption or to deploy OS methods have little > impact on the detection of malicious actors; they already have access > to strong encryption." I moved this text as a second paragraph to the introduction in section 5 and now reads as follows: Changes to improve encryption or to deploy OS methods have little impact on the detection of malicious actors. Malicious actors have had access to strong encryption for quite some time. Incident responders, in many cases, have developed techniques to locate malicious traffic within encrypted sessions. The following section will note some examples where detection and mitigation of such traffic has been successful. > > And the last two sentences cast a foreboding outlook: > "..but make passive monitoring broadly cost > prohibitive. This is meant to restrict monitoring to sessions where > there is reason to have suspicion." I see what you are saying and I have trimmed section 8 to the single paragraph listed above, edits are welcome. Thank you for your review and assistance to improve the document. > > The End for this 40-page story? > > -- Best regards, Kathleen _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
