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.

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