Hi, Deborah. Sent from my mobile device
> On Feb 9, 2018, at 3:53 PM, BRUNGARD, DEBORAH A <db3...@att.com> wrote: > > Hi Kathleen, > > Much better😊 > > And as we discussed, not all these procedures are used by *all* operators, > already there are other tools available/in development. I've slightly tweaked > the following to hopefully clarify: > > 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." 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. Operators recognize not all the practices > documented need to be supported going forward, either because of the risk to > end user privacy or alternate technologies and tools have already emerged. > This document is intended to support network engineers and other innovators > to work toward solving network and security management problems with protocol > designers and application developers in new ways that facilitate adoption of > strong encryption rather than preventing the use of encryption. 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 assist the IETF to understand some of the current practices so > as to identify new work items for IETF-related use cases which can help > facilitate the adoption of strong session encryption and support network and > security management. > Your edits look great and improve the text further. We’ll get them in the next revision. Thank you! Kathleen > Thanks! > Deborah > > > -----Original Message----- > From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of Kathleen Moriarty > Sent: Friday, February 09, 2018 10:57 AM > To: BRUNGARD, DEBORAH A <db3...@att.com> > Cc: opsawg@ietf.org; Warren Kumari <war...@kumari.net>; The IESG > <i...@ietf.org>; draft-mm-wg-effect-encr...@ietf.org; Paul Hoffman > <paul.hoff...@vpnc.org> > Subject: Re: Deborah Brungard's No Objection on > draft-mm-wg-effect-encrypt-17: (with COMMENT) > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg >> _statement_discuss-2Dcriteria.html&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r >> =6UhGpW9lwi9dM7jYlxXD8w&m=8M35KpcqzI3VzEU66Ux0nzlEfwm0h78rAN_pYnkJJIo& >> s=awEF1_D-eBDtsSZwy-LHDfmZyWBpfrQFnAJ4Zfv8QAk&e= >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf. >> org_doc_draft-2Dmm-2Dwg-2Deffect-2Dencrypt_&d=DwIBaQ&c=LFYZ-o9_HUMeMTS >> QicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=8M35KpcqzI3VzEU66Ux0nzlEfwm0h78rAN_ >> pYnkJJIo&s=H8IAnJEU4LeLp6IG2fx3fVephVrA9aSGrRtIRPghj2M&e= >> >> >> >> ---------------------------------------------------------------------- >> 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