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

Reply via email to