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

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

OPSAWG mailing list

Reply via email to