Re: Review of draft-mm-wg-effect-encrypt-09

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 11 April 2017 03:55 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D7A127866 for <ietf@ietfa.amsl.com>; Mon, 10 Apr 2017 20:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nINWrUlUbLEL for <ietf@ietfa.amsl.com>; Mon, 10 Apr 2017 20:55:17 -0700 (PDT)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C41126B71 for <ietf@ietf.org>; Mon, 10 Apr 2017 20:55:16 -0700 (PDT)
Received: by mail-pf0-x22a.google.com with SMTP id s16so42534078pfs.0 for <ietf@ietf.org>; Mon, 10 Apr 2017 20:55:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=18pQSezVamMJm2HY616mxLLqLkBY3nqcgpjE43B+82I=; b=VDjP4sjR7o7SxfSB/pPFZZopjvzxSOMGmpyp2gl02JbwZ09bb9UI1HzKSChHvTsmi/ qXWXTeLMpsKqhvL+MVudePpi7MH5nnfnBXl7TluBd1CTZxPv6Z1d7aV1IP1WQZuvevaG AyLvtJpFtIa1bqHAY5HYeCByU3fcfwxlQrFo8hqEhc8iItY1w9kAfHu4IMR7FCTC98K/ dax2x7Dlt19kLyluiOo3yp+OQ7t4d4E3qAMXdoWyZyapGkV4Nuck7oVXh0AsbrnyKaw1 v461k2YD0mlOPoRPY/cd57zfQPovc0SaWJP8SWTAnxmdKRk9N3mBDDcGxXtlDyyo320x Exkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=18pQSezVamMJm2HY616mxLLqLkBY3nqcgpjE43B+82I=; b=jJIvawx3HEc8DadXBbIymX+COS4ByONgk1FEd65/295NGFS+aXy0XnZp5/PV+dd0I9 MgGEOIumErHs1tWZa/pm+keO1qZOJ8L1Pw9ra4z56zRqfETdX2fEA0NKV9voMMJnTmtB 1PQFupZQA0UpwOX8Ua6s1Gri2e4WiowMwg1o9o0bRy3dKXwvkAMZJTKZwrrbZ9sNfcd7 oYahdMK6iLliUrNDeGVaNBQXQxY0yynNTbdhaTqepubSbIXc0146lvbzUWMeKrYzMr3T vo3wPejkFw/xBRJI/VTcOew5ZpeVcZtGDKFKwsMJBNv377Xs0reCS6gm0XS3hTcomzBm +IRg==
X-Gm-Message-State: AFeK/H2rvzFwNn7QcqNilDEj3o3WShNiHyrytZ+iwW0I9XgB1iWrBjzZU0WYbGEHmQt7/r1yFnhk9gT8sR3mAg==
X-Received: by 10.84.142.133 with SMTP id 5mr73095592plx.129.1491882915136; Mon, 10 Apr 2017 20:55:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.128.131 with HTTP; Mon, 10 Apr 2017 20:54:34 -0700 (PDT)
In-Reply-To: <CABkgnnWrufep_hQTVqbZ6cn9kDZRkc_B4ExWOV_5d3bK_H_-zw@mail.gmail.com>
References: <CABkgnnU-rFL6sPTx=Y2rh6vzf9NSiLmMTQPMFNgrV+-Fq29+dA@mail.gmail.com> <CAHbuEH7CeZ-3D8bqDzhUTTGSkLJ2k69cw3vAM8xid1_=UvGiyQ@mail.gmail.com> <CABkgnnXv4RkwGKW42O_0=6FgQHgFjOGVxoHvxUdY=vhAJPWi7A@mail.gmail.com> <CABkgnnWrufep_hQTVqbZ6cn9kDZRkc_B4ExWOV_5d3bK_H_-zw@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Mon, 10 Apr 2017 23:54:34 -0400
Message-ID: <CAHbuEH6KGgqa7F59PcWO+U3i1e-YtaMOtPZQfXo4uE2x5jf2+Q@mail.gmail.com>
Subject: Re: Review of draft-mm-wg-effect-encrypt-09
To: Martin Thomson <martin.thomson@gmail.com>
Cc: IETF <ietf@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/nLs-goMaT2rf3ts3_0Q8jFk43kE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Apr 2017 03:55:23 -0000

Hi Martin,

We went through your comments one more time to make sure any
technical/substantive comments are addressed.  Please see the
discussion inline.


On Mon, Apr 10, 2017 at 5:05 PM, Martin Thomson
<martin.thomson@gmail.com>; wrote:
> I most certainly reviewed 09. I haven't reviewed the diff. I doubt that it
> would change my opinion on the macro - level problems.

My mistake, I thought the acronym you corrected was in version 9.

>
> On 8 Apr. 2017 3:34 am, "Kathleen Moriarty"
> <kathleen.moriarty.ietf@gmail.com>; wrote:
>
> Hello Martin,
>
> Thanks for your review.  It seems that you have read version 8 or
> earlier and not the current version, 9, from some of your suggestions
> that have been corrected already.  Your review also reads to me that
> additional context setting may help, but please note that some context
> setting was improved in version 9.  We re-arranged some of the
> sections per IESG review recommendations in the latest version as
> well.
>
> Perhaps you have additional language suggestions for context setting?
>
> The abstract states:
>
>    Increased use of encryption impacts operations for security and
>    network management causing a shift in how these functions are
>    performed.  In some cases, new methods to both monitor and protect
>    data will evolve.  In other cases, the ability to monitor and
>    troubleshoot could be eliminated.  This draft includes a collection
>    of current security and network management functions that may be
>    impacted by the shift to increased use of encryption.  This draft
>    does not attempt to solve these problems, but rather document the
>    current state to assist in the development of alternate options to
>    achieve the intended purpose of the documented practices.
>
> which is repeated again in the introduction, but slightly reworded.
> The introduction also includes statements on the existing publications
> related to encryption and I read them as not having any bias, but
> rather supporting the existing documents that also had consensus.
>
> A couple of comments and one question inline.
>
> On Thu, Apr 6, 2017 at 11:24 PM, Martin Thomson
> <martin.thomson@gmail.com>; wrote:
>> Draft: draft-mm-wg-effect-encrypt-09
>> Date: 2017-04-07
>>
>> Overall
>>
>> This document is unfocused and unclear in its intent.  It is filled with
>> unsubstantiated claims, misleading statements, bias, and implied
>> recommendations
>> for bad practices.  I would oppose its publication in the current form.
>> Furthermore, I don't believe that small scale or editorial changes would
>> be
>> sufficient to correct these problems.
>>
>>
>> Aside from weakening its utility and/or arguments, the lack of focus will
>> allow
>> this document to be abused in various ways.  For instance, it might imply
>> IETF
>> endorsement of the practices described in the document.  Given that the
>> IETF has
>> published positions that in some cases reject these practices, this
>> document
>> needs to be very precise with its claims.  In its current form, it is not
>> nearly
>> careful enough.

This paragraph is all speculation about an unfortunate future.
We could speculate that the operator, security and app communities
come together to work out solutions after reading this doc,
which is part of our intent.

>>
>> If this document is going to be published as an RFC, then it needs to be
>> very
>> clear about its intent and its position - or lack thereof - toward these
>> practices.  It might be possible to say that these practices were employed
>> in
>> networks in the past and that encryption is reducing the viability of
>> those
>> practices.  A value-neutral statement like that might be acceptable as
>> long as
>> it were framed carefully.

The document conveys that message everywhere. The words contributed were
changed in many places to remove any implication that the current practices
are "requirements" or even "needs".

The abstract and introduction contain value neutral statements like
what you are suggesting already.  We actually say the practices may be
eliminated, going further than your request as that may be the case.

The only change I could see in the abstract would be the following:

   Increased use of encryption impacts operations for security and
   network management causing a shift in how these functions are
   performed.  In some cases, new methods to both monitor and protect
   data will evolve.  In other cases, the ability to monitor and
   troubleshoot could be eliminated.  This draft includes a collection
   of current security and network management functions that may be
   impacted by the shift to increased use of encryption and encryption
that is designed prevent interception.  This draft
   does not attempt to solve these problems, but rather document the
   current state to assist in the development of alternate options to
   achieve the intended purpose of the documented practices when possible.

Do you have additional suggestions?  Or is the phrasing read
differently than we intended by stating functions may be eliminated?
We thought that was very clear to your points.

>>
>> What is problematic is the implicit argument that is presented.  This
>> document
>> could easily be construed as the IETF legitimizing these practices.  This
>> includes things on which the IETF has published statements (see for
>> example RFC
>> 2804).
>
> See the abstract and introduction and summary.
>
>>
>> This steps firmly into to sticky mess that is the politics of encryption
>> policy.
>> If the IETF is going to make a political statement with this document,
>> then that
>> statement needs to be a lot better than this.

The intent of this document is to help operators as these changes
continue.  It is to make sure we are not ignoring the impact of the
changes the IETF has with our decision (which are supported in this
document).  This document is intended to assist operators.  By
explaining the functions being performed, some have already been
provided alternate methods to achieve their goals.  We have also
received quite a bit of positive feedback from operators - that this
document helped them come back to the discussion and to approach a
world with more encryption or sessions that can't be intercepted (TLS
1.3, TCPinc, QUIC, etc.).

>>
>> Furthermore, any statement needs to be consistent with previous
>> statements,
>> where in this case that primarily means RFC 7258.  Right now it reads as
>> an
>> attempt to dilute RFC 7258.
>
> Not at all.

It does not read that way to many people who strongly support RFC
7258, including Stephen who was our sponsoring AD (and was for 7258).
Can you give specific sections where it sounds like we are weakening
RFC 7258 so we can change that specific wording?

>
>>
>> If this document were more clearly formulated as an even-handed treatment
>> of
>> what happens today - without judgment - then it could be useful.  Here the
>> model
>> of RFC 7754 is a good one.  It describes the different facets of a use
>> case,
>> then the different practices that might be employed to achieve that goal.
>> For
>> each practice the pros, cons, and technical limitations are covered with
>> an eye
>> to all involved parties.
>>

Version 8 to 9 had some edits to remove statements with used terms
like 'need'.  We may have missed a couple, we'll check the ones you
pointed out.  There are also numerous statements that are explicitly
in support of RFC7258.  These are in the abstract, introduction,
summary and sprinkled throughout the document.

Apparently, RFC 7754 goes further than our scope. We are not describing:
"... the different practices that might be employed to achieve that goal."

>>
>> The Real Purpose of this Document
>>
>> I think that this is the real question that this document wants to ask is:
>>
>>    In a world where we are forced to defend against pervasive monitoring
>> by
>>    motivated and malicious actors, can we find a role for less pervasive
>>    monitoring by well-intentioned entities?

The document aims to help operators by giving them a chance to discuss
the impact.  It opens the
door to conversation so they can find new ways to achieve the same
goals (better performance for customers for instance or monitoring
services that have been requested - web content, DLP), which may mean
endpoint solutions are needed or filtering limited to hostnames for
now until other mechanisms are developed (likely at the application
layer).

For enterprises, application and host level solutions are
fine as many organizations have employees sign away their rights to
privacy.  I would never check FaceBook from work for instance or
access any site of a personal nature.  This is why we broke out the
sections by the type of network or SP, their options are different
with and without encryption.

QUESTION: Would it help to add some text like the first paragraph into
the introduction?  - This document aims to...

>>
>> There is an interesting discussion to be had here, but I'm convinced after
>> my
>> review that this document is the wrong vehicle for that discussion.

RFCs are the vehicles the IETF has found most useful in talking to the world.

>>  I'm
>> also
>> inclined to suggest that this is the wrong question to ask in the first
>> place.

We can't ignore the problems resulting from the changes, we the IETF
make, to improve privacy and security.  While we agree it is a positive
thing to improve these functions, we (the IETF) should also help with
the wake we
leave in our path.  Otherwise, we can't expect people to play along
with the protocol specifications the IETF publishes.

It's much more than an "interesting discussion" to many operators.
Some are required by law to use these practices to protect privacy.

There are many questions to ask, some of which have already been
answered. For example, RFC 7258 asked 'How can we deal with
pervasive monitoring' and answered it through the same IETF
consensus process this document has already gone through.

>>
>> To the extent that we have the tools necessary to protect against
>> pervasive
>> monitoring, we have to accept that more-legitimate uses of monitoring are
>> collateral.  Mostly, that's just a function of the limitations of the
>> imperfect
>> tools we have.
>>
>> The value in this document is in the rather comprehensive collection of
>> use
>> cases.  Sure, some we might not attribute much weight to, like
>> wiretapping.
>> Others are frankly frightening and not just in the Orwellian sense.
>>
>> The problems that are implied by the current practices of network
>> operators is a
>> large vein of unexplored work for the community.  Spending effort on
>> finding
>> better solutions to legitimate problems is worthwhile.

Right, so we started by documenting them *before* the collateral damage appears.

>>
>> In other words, the right question might be:
>>
>>    For each of these practices that we see today, are the use cases that
>>    motivate them legitimate and how might be implement alternative
>> techniques
>>    that properly respect privacy and security?
>>

Yes, this is the point of the document and it's stated in several places.

>>
>> Two- and Three- Party Interactions
>>
>> A great many sections of the document are unclear about the relationships
>> between different actors.  It seems like many of the activities describe,
>> which
>> are presented here as being beneficial, are performed by a third party
>> without
>> the consent or involvement of the two communicating peers.  After all,
>> those are
>> the cases where encryption most often interferes.
>>

As the draft says, some of the methods will be eliminated.

>> The assertion that some benefit is accrued to communicating peers as a
>> result of
>> these actions is the constant subject of the text.  I observe that in most
>> of
>> the cases listed in this document, the benefit is accrued primarily to the
>> third
>> party.

Operators by their nature have different privacy concerns than their end
users. Operators by their nature want to accrue benefits. This document
doesn't change the balance; instead, it tells them how to deal with privacy
that has already been applied.  While we agree with your statement and think
it's important to build privacy and privacy options into IETF protocols,
operators often don't care, despite the many RFCs we have published
telling them that they should care. We still need to engage them so we can
have this discussion.

The "third party" is likely the only one receiving a trouble call,
and there is benefit for all parties when the trouble is cleared.

>>
>> Clarity around the arguments that the document makes with respect to
>> benefits to
>> each of the involved parties is sorely lacking.
>>
>> In addition to this, where benefits truly do accrue to communicating
>> peers,
>> technical options that don't rely on privacy-invasive techniques are
>> routinely
>> dismissed in an offhand fashion.  In this way, any moral imprimatur
>> attributed
>> to the use case is used to justify the privacy-invasive method.
>>

Without specific comments, the above are all subjective statements and
we have responded to them.

>>
>> Document Structure
>>
>> This document is very hard to read (and review).  Probably my biggest
>> complaint
>> is that the sections are haphazardly organized.  They contain a mixture of
>> use
>> cases (what does SP X want to do) and techniques (how do they do these
>> things).
>> Material is duplicated between sections.  Sections cover 10 different use
>> cases
>> while talking about techniques, then other sections talk about different
>> techniques whiles talking about a scenario.  This leads to a lot of
>> repetition.
>>
>> There are three axes that this document contemplates:
>>
>>  - the techniques that are currently used in networks
>>  - the use cases that motivate these techniques
>>  - the deployment scenarios in which these use cases manifest
>>
>> It would appear that the document attemps to start from the deployment
>> scenarios.  However, this causes use cases and techniques to be mixed.
>> Judicious use of cross-referencing might have made this arrangement
>> tractable,
>> but there are virtually no cross references.
>>

The above is stylistic in nature.  We've already made changes to the
format to address specific comments in IESG review. A complete
re-write is not appropriate at this point in the draft lifecycle.
That's not the point of IESG review.

>>
>> Section 1
>>
>> I find the introduction of this document difficult to parse.  I think that
>> what
>> it wants to say is pretty straightforward, but it manages this in quite an
>> obtuse way.  Here's what I think that it is trying to say:
>>
>> 1. The IETF (and the larger community) has reacted to revelations of
>> pervasive
>>    monitoring by increasing the use of encryption.
>> 2. That has been somewhat successful.
>> 3. More encryption has an impact on some practices that network operators
>> have
>>    become accustomed to employing.
>>
>> Expressed in this way, you can see how you could make a value-neutral
>> statement.
>>
>> On the first, you can definitely make an argument based on the documents
>> that
>> the IETF have published.  However, it is a mistake here in assuming that
>> the
>> IETF - or the revelations of global-scale surveillance - is directly
>> responsible
>> for the uptick in adoption of cryptographic protection for Internet
>> traffic.

The abstract is value neutral right now.

The increase or changes are not just about PM.  We are making
TLS 1.3 so that it cannot be intercepted (I agree with this move of
course as we should make our protocols strong and adhere to
established IETF principles)?  Or the efforts of TCPInc and
QUIC?  We do directly affect the use of encryption and the types of
encryption that are deployed.  We work with the vendor communities in
publishing deprecation drafts as well.  All of these efforts got
additional energy from the PM work and that's a good thing.  Events
trigger increases in security and it's fine to acknowledge that.  The
introduction states:

   In response to pervasive monitoring revelations and the IETF
   consensus that Pervasive Monitoring is an Attack [RFC7258], efforts
   are underway to increase encryption of Internet traffic.  Session
   encryption helps to prevent both passive and active attacks on
   transport protocols;

We could change it to say:

   In response to pervasive monitoring revelations and the IETF
   consensus that Pervasive Monitoring is an Attack [RFC7258], efforts
   are underway to improve and increase encryption of Internet traffic.  Session
   encryption helps to prevent both passive and active attacks on
   transport protocols;

The second sentence mentions passive and active attacks here as that
hits on the prevention of active attacks - improving session
encryption protocols helps with this.

>> This is something that the community as a whole has been working towards
>> for
>> many years; these trends predate the actions this draft focuses on.  This
>> is
>> particularly true for the hosted provider cases in Section 3, where
>> business
>> motivations for protection are far stronger than any concerns over
>> government
>> surveillance.  Yeah, that's a subjective view, but I'm just reviewing, I
>> don't
>> have to write a statement that will be labelled as having IETF consensus.

Section 3 already makes this point very clear (full text for the intro
to that section):

3.  Encryption in Hosting SP Environments

   Hosted environments have had varied requirements in the past for
   encryption, with many businesses choosing to use these services
   primarily for data and applications that are not business or privacy
   sensitive.  A shift prior to the revelations on surveillance/passive
   monitoring began where businesses were asking for hosted environments
   to provide higher levels of security so that additional applications
   and service could be hosted externally.  Businesses understanding the
   threats of monitoring in hosted environments only increased that
   pressure to provide more secure access and session encryption to
   protect the management of hosted environments as well as for the data
   and applications.

>>
>> The immediate focus on opportunistic security is highly misleading,
>> especially
>> in the web case.  The amount of opportunistically secured web traffic is
>> miniscule by global standards.  Since Firefox is the only browser to
>> support OS
>> for the web, so adjust the following by market share:
>> <https://mzl.la/2oc46ch>;.

You'll need to cite text that is leading you to this conclusion as I
don't read it as being specific to OS, rather that OS is explained so
operators understand it in the mix of encryption options.

>>
>> I understand that mail is more often opportunistically secured, and you
>> will
>> hear the virtues of OS sung from the rooftops, but all evidence suggests
>> that
>> this is just a transitory state.  Instant messaging is closer to the web
>> case,
>> with the trend toward strong protections that include authentication.  Of
>> course, I don't believe that mail or instant messaging represent any
>> significant
>> traffic volume, so you need to be very careful about the nature of the
>> claims
>> that are being made.  It has to be that the volume of mail has to be a
>> rounding
>> error when it comes to capacity planning for networks.
>>
>> On the second point, when making claims about prevalence of encryption, I
>> would
>> advise caution when citing statistics.  Here's the graph for the Mozilla
>> figures
>> that I think are being cited <https://mzl.la/2obZjrb>;. Here's a different
>> graph
>> with a different number <https://mzl.la/2oc263J>;.  This highlights the
>> point
>> that statistics need to be carefully cited, because bare claims are
>> difficult to
>> assess.  Methodology matters when it comes to these sorts of claims - are
>> we
>> talking proportions of packets, requests, flows, or something else?
>> Furthermore, the citations in the document are made more difficult to
>> assess by
>> being measured at very different times (where the two I cite here were
>> made at
>> roughly the same point in time).
>
> For the Mozilla statistics, Richard Barnes had reviewed the text after
> providing the statistic as he wanted to make sure it was stated
> clearly raising the same concerns you do about statistics.  Do you
> have further text suggestions to clarify this statistic?
>

>
>>
>> The statistics do support the notion that there is a significant amount of
>> encryption in use, but it would appear that the claim is that the amount
>> of
>> encryption is *increasing*.  This is not an extraordinary claim, but no
>> evidence
>> is offered in support of the claim.  It isn't a certain thing either.
>> From the
>> statistics that I have access to, there was a definite uptick in October
>> of
>> 2015, but the rate appears to be stable since then.
>>
>> It appears that the remainder of the document is intended to address the
>> third
>> of my points in some detail.  That's a good structure in theory, but see
>> above.
>>
>> I don't think that the "service provider" taxonomy works for this
>> document.
>> Based solely on the structure of the document, the only service provider
>> that
>> this document concerns itself with is the one who forwards the packets.
>> That
>> application service providers are involved as one of the endpoints is
>> relevant
>> in some cases, but not all.  For that reason, I prefer "network operator"
>> and to
>> use specific terms like "mail host" or "web server" as appropriate to the
>> context.
>>

Those are subjective comments, so we'll put those aside.

>>
>> Section 2 (top section)
>>
>> I like that the attacks on SMTP by network operators is highlighted here.

We tried to have balance and had other attacks by operators in
previous versions, but only articles that are not stable references
for them and were asked to remove them in AD review.

>>
>> There's an implicit argument here that runs counter to established IETF
>> consensus.
>>
>>    Some methods used by service providers are impacted by the use of
>> encryption
>>    where middle boxes were in use to perform functions that range from
>> load
>>    balancing techniques to monitoring for attacks or enabling "lawful
>>    intercept", such that described in [ETSI101331] and [CALEA] in the US.
>>
>> This fails to remain neutral.

The functions are impacted, so how would you suggest we word this
text?  It doesn't endorse the functions, just says they are impacted.
We are open to suggested text.  Similar to how we describe 'attacks'
by operators to break encryption or use RSA private keys.  We do have
text in both directions on this and your review is complimentary of
the ones that fit your dialog, but are also not value neutral.  Mind
you, I am constantly reviewing RFCs and making sure TLS best practices
are considered and questioning the use of deprecated crypto or not-yet
but should be deprecated crypto.

>> This implicitly makes a value-judgment
>> about
>> relative morality/acceptability/value of certain practices.

We have statements in both directions in the document as you point out
above with one of them.

>>  What is
>> particularly insidious about this particular form is that it invites
>> interpretation that is subjectively coloured.  For instance, as a non-EU
>> and
>> non-US citizen, I might consider the use of the particular lawful
>> intercept
>> techniques offensive; thus I might interpret this as a spectrum between
>> inoffensive to offensive.  An employee of the US government might view
>> this
>> somewhat differently and interpret this as a scale between low-value to
>> high-value.  I'm guessing here, but this is really just to highlight my
>> point
>> about care.
>>
>> A more serious concern is this statement:
>>
>>    The loss of access to these fields may prompt undesirable security
>> practices
>>    in order to gain access to the fields in unencrypted data flows.
>>

But this is true and we've seen operators do things like prevent
STARTTLS.  This isn't a good thing and we need to ack that this has
happened.  We need to help operators figure out how they help users in
new ways and understand that some of the functions they perform
currently (TLS 1.2) won't work in the future.

This text got re-worded during AD review, I believe.  The intent is to
say that this is not good - the practices are called out as
undesirable.  How would you suggest it be re-phrased and we can check
back with Stephen to see if he agrees.

>> I've read this argument before (see
>> https://queue.acm.org/detail.cfm?id=2508864
>> for the long form), and it might even have an element of truth to it.
>> However,
>> it's not a statement that I personally attribute any real credibility to,
>> and
>> nor do I think that it needs to be credited with any amount of
>> seriousness.  I
>> certainly disagree with the IETF making any such statement.  It says that
>> we are
>> collectively willing to bow in response to (anticipated) threats of
>> violence.

Prior to AD review, there was a reference in the text to the practices
being bad and stating that regulators and the media helped to correct
this behavior.  The problem here may be the evolution of the
text and lack of reference now since we couldn't find a stable
reference.  Do you have a wording suggestion?

>>
>> Section 2.1
>>
>> This is one of the few sections that talk about what it means to operate a
>> service as opposed to operate a network.
>>
>> Overall, this section doesn't work particularly well.  The distinction
>> between
>> integrated and standalone load balancing is an interesting division, but
>> it
>> doesn't leverage this distinction well.  What causes a standalone
>> load-balancer
>> to be necessary?  Is this something a network operator uses?  I see text
>> on NFV
>> later, but it's far removed from the original text and it seems
>> aspirational
>> rather than concrete.  On the other hand, many of the concerns in this
>> document
>> simply don't apply to an integrated load balancer.
>>
>> The amount of text on QUIC here is surprising.  Given how much of QUIC is
>> changing right now, we shouldn't publish a document that attempts to make
>> claims
>> about what QUIC is or how it is operated.  This attempts to dive into the
>> details of QUIC connection migration in a way that presumes much about the
>> outcome of issues that the QUIC working group is still struggling with.
>>
>> I would strongly recommend removing QUIC-specific language from this
>> section and
>> the document as a whole.  We have an operational document in the QUIC
>> working
>> group that would be a good venue to discuss some of these concerns.

While we read this as  more of a substantive remark, the text on
load balancers and QUIC were added per Mirja's IESG review.  We would
need to check with her about making any changes here.  They were
specific additions that were requested.

Further, it is only IETF QUIC that is in active development.
Google QUIC (referred to as GQUIC in IETF discussions) is a more
stable experiment now.

>>
>> Is this an oblique reference to (the much-loved) RFC 7974?
>>
>>    Current protocols, such as TCP, allow the development of stateless
>> integrated
>>    load balancers by availing such load balancers of additional plain text
>>    information in client-to-server packets.
>>
>> Otherwise, I don't know what it means.
>>
>> BTW, I like this parenthetical:
>>
>>    (That said, care must be exercised to make sure that the information
>> encoded
>>    by the endpoints is not sufficient to identify unique flows and
>> facilitate
>>    Persistent Surveillance attack vector.)
>>
>> I'm going to take this to the QUIC working group, because QUIC certainly
>> doesn't
>> meet that bar right now.  It fully facilitates Persistent Surveillance in
>> its
>> current form (proper noun?  I haven't really seen that term before, even
>> though
>> it draws a neat parallel with Pervasive Surveillance).
>>

OK, let us know what you hear back.  These changes were in response to
the sponsoring AD's request of that work.

>> Editorial:
>> * "pop" is a term of art that needs explanation.
>> * "QUIC?s", "network?s" - avoid smart quotes, and - more generally - the
>>   possessive form for the inanimate.
>> * "QUIC's server-generated flow IDs" -> "QUIC's connection IDs".

Thanks for the nit corrections.

>>
>> Section 2.2
>>
>> I think that this sums the situation up reasonably well.  It fails the
>> value-neutral test in a few ways though.  As I understand the situation,
>> surveying operates at many levels.  For accurate planning, models of
>> endpoint
>> behaviour are used to determine things like whether loss or congestion is
>> affecting throughput.  Really good models require knowledge of what users
>> are
>> attempting to do and the applications they are using (as mentioned, things
>> like
>> browser version matter in these models).  For instance, it isn't enough to
>> understand that the user is trying to receive 720p video, you also have to
>> know
>> that a 4k stream for the same content is available.

Sure, that's why we broke the draft down by operator type.  Some
functions are shifting and the responsibilities for operators will
shift with these changes.

>>
>> The degree to which these models are privacy-invasive is not even
>> acknowledged.

Suggest text please.  The abstract and intro were meant to set the
context for the document.  Some of the functions will be eliminated -
and that's fine, it is what it is, but operators need to adapt and
deal with the change.  We should help them so we all get to a better
place with improved privacy for users and increased security.  By not
helping them, we do not get closer to solving these problems.

Try to consider the operators perspective here. They are used to knowing
what SI has been exposed by knowing video format
or browser type that has been in the clear for years.  Understanding
the practices
helps make it possible for apps/ops/security/transport to come together to
reach better solutions.

>>
>> Nit: Did you realize that "well-intentioned" is a euphemism?  I'd expect
>> that
>> subtlety to be lost on many readers though.
>>
>> Section 2.3.1
>>
>> I find this sad, even if I can recognize the truth of it:
>>
>>    A monitoring system could easily identify a specific browser,
>>    and by correlating other information, identify a specific user.
>>
>> As a browser vendor, we don't consider this to be a feature, it's a bug.
>>
>> Section 2.3.2.1
>>
>> This is a strange section under which to put caching.  Caching is a use
>> case
>> akin to compression.  I don't see it as belonging to the class of things
>> that
>> rely on DPI.  You just intermediate the cleartext HTTP in the way that RFC
>> 7230
>> recognizes.  Note that RFC 7230 explicitly does not endorse the practice
>> of
>> transparent proxying for a range of reasons, not the least of which is the
>> complete lack of transparency (yep).


This was organized per IESG review.

>>
>> Section 2.3.2.2
>>
>> Again, it's strange to see differential treatment under DPI.  I was fairly
>> sure
>> that fingerprinting was used here as well.
>>
>> Section 2.4
>>
>> This section doesn't even attempt to recognize that applications are much
>> better
>> now at scaling content to suit the device on which that content is
>> intended to
>> be consumed.  It should.

The reason for that is that there has been a useful dialog between application
designers and network providers over time, beginning with app designers
saying "what do you mean the network has errors and delay? this works
fine in my lab...".  The contributors viewed that as well understood
and far back
in time, so not necessary to mention.

If you think there should be text to this point, please suggest some.

>>
>> This section should not represent compression as an unmitigated good.  I'm
>> told
>> that significant damage can be done to video streams by "well-intentioned"
>> compression middleboxes.

Please suggest text.

>>
>> Yet again I see a call back to the implicit threat of violence in "they
>> will
>> adopt undesirable security practices".  Statements in that form have no
>> place in
>> IETF RFCs.

This was edited text per review and agreed upon (I think in the AD
review).  Suggest alternate
text and we'll go back to the other person.

>>
>> Section 2.5
>>
>> This mentions RFC 7754 then blithely ignores its primary conclusion.
>> Generally,
>> The treatment in RFC 7754 of this subject is more even-handed.
>>
>> The use of particular examples (betting, gambling, dating) shows cultural
>> bias.

subjective review again, but 7754 cites examples too.

>>
>> Jargon warning: "core network", "the mobile network" ("the"?)
>>
>> Section 2.5.2
>>
>>    This type of granular filtering could occur at the endpoint, however
>> the
>>    ability to efficiently provide this as a service without new efficient
>>    management solutions for end point solutions impacts providers.
>>
>> The initial premise here (up to the first comma) is the conclusion of RFC
>> 7754.
>> I disagree with the conclusion, and I suspect so does RFC 7754.  In
>> scenarios
>> where this matters, endpoints are routinely managed centrally.  The range
>> of
>> options for this sort of management are plentiful and diverse.

Sure, but there is an impact and it's okay to ack that and assist with
these alternate options.  If you have text to suggest, please do so.

>>
>> Section 2.5.3
>>
>> This describes a captive portal, which in the case where the service
>> provider
>> has a relationship with their customers, seems like a poor solution.  See
>> the
>> CAPPORT working group for ways in which people are actually working on a
>> solution to this problem.
>>
>> Section 2.6
>>
>> The capitalization of section headings is inconsistent here (and
>> throughout).
>>
>> Section 2.6.1
>>
>> Isn't this a duplicate of Section 2.1?
>>
>> Section 2.6.2
>>
>> I can't parse this statement:
>>
>>    Approved access to a network is a prerequisite to requests for Internet
>>    traffic - hence network access, including any authentication and
>>    authorization, is not impacted by encryption.
>>
>> And then we get into zero rating, which is a hot-button topic.  No
>> acknowledgment given to the sensitivities on the subject, or even a
>> superficial
>> exploration of the technical options that are available.

Please suggest text.  This was updated in IESG review.

>>
>> This text references a non-existent Appendix.


Fixed. It's section 7 now.

>>
>> Section 2.6.5
>>
>> This paragraph is strange.  It starts by describing what appears to be use
>> cases
>> (are those scare quotes?).  It finishes by implying that these are attacks
>> on
>> privacy (which they are).
>>
>> What is "Non-Customer Proprietary Network Information"?  I hope that this
>> isn't
>> an attempt to somehow privilege the information so that it seems less than
>> privacy-invasive.
>>
>> Section 2.7
>>
>> This is one of the areas that is most legitimately affected by increased
>> adoption of encryption.  I have no doubt that having detailed information
>> about
>> the application and its use makes the process of troubleshooting easier.
>>
>> This is the first mention in the document of network-based optimization.
>> Was
>> the section describing that cut from an earlier draft?
>>
>> The use of websockets as a primary example is an odd one.  It's just not
>> that
>> common.  For reference, we see >20% failure rates on encrypted websockets
>> and
>>>50% failures in the clear; no one in their right mind would rely on
>>> websockets.
>> If the point is that HTTP is carrying more traffic (see
>> http://conferences.sigcomm.org/hotnets/2010/papers/a6-popa.pdf) saying
>> just that
>> would be more effective.

"in their right mind" . That isn't helpful.  Operators submitted text
to explain what they are doing and how it's impacted.  How about
proposing text to help in that vein.

>>
>> Section 3
>>
>> It would help if "hosted environments" was defined before diving in.
>>
>> Section 3.1
>>
>> The paragraph on DLP is ironically amusing.  Encryption exists to prevent
>> private information leakage, but the assertion here is that encryption is
>> hampering DLP attempts.
>>
>> It's true that protection of intellectual property is an important
>> business
>> goal, but this handling suggests an architecture that I'm fairly sure is
>> counter
>> to established wisdom (see "SSL added and removed here :-)":
>>
>> https://www.washingtonpost.com/rf/image_404h/2010-2019/WashingtonPost/2013/10/30/Local/Images/GOOGLE-CLOUD-EXPLOITATION1383148810.jpg).
>> Worse, this casually dismisses a model that is actually more likely to
>> work.
>> Malware encrypts too (https://arxiv.org/abs/1607.01639).

The section talks about the end points being the better place for this already.

>>
>> Section 3.1.1
>>
>> Who is the customer here?
>>
>> Why does the hosting provider need to monitor access?  They have the
>> ability to
>> limit accesses, but this is suggesting that what happens within the
>> envelope of
>> what they permit is important for them to know.  I'd be surprised if you
>> could
>> show that this is true.  Hosting providers - in my experience - value
>> their
>> ongoing business and would not jeapardize it by snooping on their
>> customers.
>> It's different if the customer opts in to a security service, but that
>> demonstrates a cooperative situation, where the rest of this document is
>> largely
>> concerned with adversarial uses of encryption.

This is describing the cooperative scenario.  The service is hosted,
so maybe the definition of hosted would have helped you.

>>
>> Section 3.1.2
>>
>> This is another example where the organization of the document could
>> be improved.
>>
>> Again with the "SSL added and removed here :-)" recommendation.  PCI don't
>> permit that for good reason.

I don't read the following text in this section as a recommendation or
endorsement.  Is there a tweak you think that should be made as I'm
not seeing the problem your describing. This is just describing what
they do and stating that it will be impacted and then the truth that
the functions may no longer be possible - not stating that it is good
or bad, just the fact that it won't be possible.

   The use of tools that
   perform SSL/TLS decryption are impacted by the increased use of
   encryption that prevents interception.  Alternate methods to acheive
   the goals of these functions may be necessary and in some cases, the
   functions may no longer persist in a pervasively encrypted Internet.

>>
>> Section 3.2.1
>>
>> I don't believe that monitoring of these types of application require
>> cleartext
>> access.  There are two parties involved: the provider of the application
>> and the
>> user of it.  The provider has most of the power here and can theoretically
>> design the system to allow whatever level of access they require.  To the
>> extent
>> that the user needs protection from the application provider, that is a
>> matter
>> of negotiation between them.
>>
>> I don't see how the adversarial three-party situation presented in the
>> rest of
>> the document applies in this situation.

Sure, there is a shift in how many functions will be performed
happening and this is documenting that shift.  Much moves to the
application.  We are helping to document the changes.

>>
>> Section 3.2.2
>>
>> No real mention of the effect of encryption here, or is this just saying
>> that
>> there is no issue here?
>>
>> I don't see the point of the PGP/Dark Mail paragraph.  I'd be leery of the
>> IETF
>> saying things like "PGP may be a front runner" though.
>>

This was added per EKR in IESG review.

>> Section 3.3
>>
>> There's certainly a lot of detail here, but I had a really hard time
>> extracting
>> value from this section.  I can't see how data storage is fundamentally
>> different to the general case of an application provider.

They figured out how to increase encryption and manage their hosted
environments.  There were adjustments made and they've been
successful.

>>
>> Section 4.1.1
>>
>> I appreciate the recognition that endpoint-based techniques work.  The
>> implication that this isn't the obvious solution, much less so.

This isn't a technical comment, but we'll revisit the text to see if a
wording change can help.

>>
>> Section 4.1.2
>>
>> I'm confused about the purpose of this section.  This seems to be talking
>> about
>> the sort of network-based methodologies an application provider might
>> employ to
>> ensure that their application is working as intended.  Why would the
>> application
>> provider not have access to detailed logging and usage metrics?

The problem cited to us is that logging is sorely lacking.  This needs
to be pointed out and fixed as it is too much for the operator to deal
with given the large number of applications running in their
environments.

>>
>> As an aside, I skimmed through ietf-ippm-6man-pdm-option, since it is
>> cited no
>> fewer than three times in the same paragraph.  It makes some fairly bold
>> claims
>> about its effect on privacy that I don't believe will hold up to analysis.
>>
>> Section 4.1.3.1
>>
>> This section correctly identifies the issue as one of shortcomings in
>> logging,
>> not increased use of encryption.

Right, a key point in this document - other methods will have to be
used and an obvious one is logging.  However, logging needs to improve
for that to be possible.

>>
>> I would have stopped there, but the section persists and ultimately
>> references
>> RFC 7974, which is widely recognized as a monstrously bad idea (the IESG
>> note is
>> fairly clear on this point).

Thanks for catching that.  We can drop this text.

>>
>> Section 4.1.3.2
>>
>> "HTTP/2", not "HTTP2".

Fixed.

>>
>> I don't see how this section belongs in this document.  The 1:1
>> correlation
>> between actions and flows in HTTP was a mistake of the 1980s that we've
>> spent a
>> lot of time on correcting (sometimes unsuccessfully, see pipelining).
>>
>> Section 4.1.3.3
>>
>> It's not a "service call" it's just a request.
>>
>> Section 4.2
>>
>> If the inclusion of a reference to RFC 7457 is to support a claim that TLS
>> is
>> attacked, that's sailing far too close to an endorsement of attacks than I
>> am
>> comfortable with.  However, I don't believe that any of the listed attacks
>> remain viable in modern applications.  What is most often the case is that
>> a
>> trust anchor is installed on enterprise users' machines and new
>> certificates are
>> minted as needed.  In other words, the host that is accessing the HTTPS
>> site is
>> owned by the enterprise and modified so that it can comply with its
>> policies.
>>
>> When you recommend attack like this (to be clear, I would oppose
>> publication of
>> text that does this), you need to acknowledge the downsides.  For example,
>> MitM
>> devices routinely break connections, they hide the true security status of
>> communications from endpoints and users, they frequently implement weaker
>> versions of protocols, they often don't include the same degree of rigor
>> in
>> things like certificate validation, and probably many more things that I
>> can't
>> casually list off the cuff.

Please suggest text.

>>
>> The discussion of caching here warrants a new section.
>>
>> Section 5.1
>>
>> s/effect/affect
>>

Thanks, we'll fix this.

>> No complaint here, just an advertisement for technical solutions that
>> aren't
>> affected by increases in encryption.  Good, though I'm not sure if the
>> section
>> meets the document's criteria for inclusion.
>>
>> Section 5.3
>>
>> No cititation for APWG.  Not an IETF working group from what I can see.

We'll add that, thanks.

>>
>> There's a presumption here that administrators need to perform these
>> tasks.  Why
>> can't endpoints do this?  It would certainly be a whole lot less invasive
>> that
>> way.  Take a look at how browsers implement checks for "bad" sites (which
>> include phishing sites).  These methods have some fairly significant
>> privacy
>> safeguards without compromising on performance.

A lot will move to the endpoints, but things like logging need to
improve and we need to get application developers to do a better job
so that there is no reason for someone to want to try to intercept
traffic for troubleshooting.  Operators see this as an insurmountable
problem.  We need to help.

>>
>> Section 5.5
>>
>> See my comment about about endpoint-based methods.

Already agree with this point.

>>
>> Section 5.6
>>
>> I believe that the spoofed source address problem is not relevant to this
>> document.  It's a fairly well understood problem.  That said, if we could
>> wave a
>> magic wand and get BCP 38 deployed, that might be nice.
>>
>> Section 6.1
>>
>> As this says, it's fairly well understood that - for HTTP - SNI is used.
>> The
>> point that it is optional is interesting, but doesn't deserve the amount
>> of
>> attention this section devotes to it.  The clients that don't include SNI
>> are in
>> a diminishing minority.

Text was aded per EKR's review.

>>
>> That said, this doesn't pay any attention to another feature in HTTP/2:
>> connection coalescing.

Please suggest text if this should be included.

>>
>> Section 6.2
>>
>> ALPN will be encrypted in TLS 1.3.

Noted.  Thanks.

>>
>> Section 6.3
>>
>> This reads as a invitation to perform traffic analysis (a statement that I
>> oppose).  Note that we have added padding to most recent protocols (HTTP/2
>> and
>> TLS 1.3 in particular) to give endpoints the ability to resist this sort
>> of
>> attack.
>>
>> Note that block ciphers can add ~240 octets of discretionary padding per
>> record.
>> That can be pretty effective if you are careful.

I believe this text was added through the IESG review.  I don't see
the problem with the text you are citing, so could you suggest
alternate text?

>>
>> Section 7
>>
>> This section is duplicative of much of the rest of the document.  I
>> realize that
>> editing is hard, but see my earlier comments about structure.

This text was the appendix, but moved to section 7 per IESG review and
discuss.  It was the mobile operator view.

>>
>> It's obvious that this section is about QUIC.  That shows in several ways.
>> It's
>> nice how it doesn't say so out loud, but it leaks through in several
>> confusing
>> ways.  See below.
>>
>> Section 7.1
>>
>> This section is purportedly about encrypted ACKs, which won't happen until
>> we
>> get to QUIC.  But the points regarding proxies (b, c, d) are not prevented
>> by
>> encrypted ACKs, they are prevented by encryption more generally.  Point e
>> is
>> defeated by integrity protection of ACKs, not confidentiality protection.
>>
>> I hope that the IETF never publishes draft-dolson-plus-middlebox-benefits;
>> it
>> makes claims about the benefits of specific solutions for different use
>> cases
>> with the goal of justifying those solutions.  At the same time, it fails
>> to
>> recognize the existence of alternative, often superior, solutions for
>> those use
>> cases.  In other words, it has many of the same issues as this document.

I think this is an early document and expect it will get some
revision.  This was added into our document per Mirja's IESG review.
They are documenting middle boxes that use 5-tuples.  That point isn't
clear until the summary.  I provided some light feedback, but could
provide more to help them improve the document.  I think it's fine to
document these things and then figure out how we can do better with
IETF agreed upon protocol design intentions (end-to-end and assisting
to improve user's privacy as well as the security of sessions.

>>
>> FWIW, also be OK if draft-thomson-http-bc never went anywhere as well; I
>> don't
>> know how to close the gap between the privacy assurances I wish it had and
>> the
>> privacy weaknesses it has.
>>
>> The phrase "trusted proxies" is a dangerously misleading phrase.  The
>> concept of
>> trust is - particularly in this context - frequently abused.

That's why the quotes were there, but this has been re-phrased in 10 -
see the SecDir review.

>>
>> Sections 7.2 and 7.3
>>
>> I'd be interested in learning about the justification for these features
>> (again,
>> go back to my comment about to whom the benefit accrues, and I'd advise
>> caution
>> not to make the trickle-down economics mistake of using second-order
>> effects).
>> Personally, I'm not that sad that they are going to be negatively
>> affected.
>>
>> Section 7.2, Point d seems to be saying something about a multiplexed
>> protocol,
>> not one that has an encrypted transport header (see above regarding QUIC).
>>
>> All these points equally apply to HTTPS, which suggest that encrypted
>> transport
>> headers is not the issue (unless by transport we mean HTTP).

Again, section 7 was changed in IESG review and added into the body of
the document per Mirja's discuss since the mobile operator is
important to include.

>>
>> Section 7.4
>>
>> s/GPSR/GPRS/ ?

Fixed.  I thought this was fixed in 9, hence me thinking you read the
wrong version.

>>
>> Section 8
>>
>> I generally agree with the first statement here, but after having read the
>> document, I could take away some very different views on what the
>> "problems at
>> hand" actually are.  I suspect that different people will have very
>> different
>> takeaways.
>>
>> The conclusion section of a document is not the right place to start
>> introducing
>> new information, particularly information relevant to RFC 2804.

Should we move this to the introduction perhaps to help with context setting?

>>
>> Not sure where this is going:
>>
>>    Terrorists and criminals have been using encryption for many years.
>>
>> Because it's disconnected from the remainder of the paragraph.  If you are
>> going
>> to invoke the T-word, you had better have a strong argument to make.  On
>> the
>> final sentence of that paragraph, the subject ("This") is unclear.
>>

Sure, the point was that their use of encryption is not a
justification argue any of the improvements to crypto for the general
population.  Incident handlers know full well that encryption has been
in place for a long time by these users.  Essentially, it's not an argument that
hold muster.

>
>
>
> --
>
> Best regards,
> Kathleen
>
>



-- 

Best regards,
Kathleen & Al