Subject: [OPSAWG] Deborah Brungard's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)

From: Deborah Brungard <[email-masked]>
Date: Wed, 07 Feb 2018 13:35:42 -0800

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.

"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."

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."

The End for this 40-page story?

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 9 Feb 2018 10:56:33 -0500

Hi Deborah,

> https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

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.

>    impact on the detection of malicious actors; they already have access

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.

>    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.

-- 

Best regards,
Kathleen

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 9 Feb 2018 20:53:31 +0000

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:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Friday, February 09, 2018 10:57 AM
To: BRUNGARD, DEBORAH A <[email-masked]>
Cc: [email-masked]; Warren Kumari <[email-masked]>; The IESG <[email-masked]>; [email-masked]; Paul Hoffman <[email-masked]>
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 <[email-masked]> wrote:
> 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=
> 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=
>
>
>
> 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.

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. 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.

>    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.

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 9 Feb 2018 17:55:07 -0500

Hi, Deborah.

Sent from my mobile device

> On Feb 9, 2018, at 3:53 PM, BRUNGARD, DEBORAH A <[email-masked]> wrote:
> 
> Hi Kathleen,
> 
> Much better😊
> 

Your edits look great and improve the text further.  We’ll get them in the next revision.

Thank you!
Kathleen