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

Martin Thomson <martin.thomson@gmail.com> Mon, 10 April 2017 21:06 UTC

Return-Path: <martin.thomson@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 D1CA5129AF1 for <ietf@ietfa.amsl.com>; Mon, 10 Apr 2017 14:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 6o1gEcA8-ygI for <ietf@ietfa.amsl.com>; Mon, 10 Apr 2017 14:05:56 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 7180B129AE7 for <ietf@ietf.org>; Mon, 10 Apr 2017 14:05:53 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id h125so77240340lfe.0 for <ietf@ietf.org>; Mon, 10 Apr 2017 14:05:53 -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=uY+ZWiMTikzHKGLahLoIrIXGPDdbwXLyIc00qcaOi6Q=; b=uOVY/GNVaAq+QJ5J1C3ItfPcHrqoMnIa4f5yR4XJLxUn7Pvo+cVWp3HCi70hlUJceS iX2pXvhtduymvXnOQhQP0sFJjMgiQvTv0B67jUB9C7BFmWtzNgsKEbQ+iHD5fmau5XU/ PqKn74Vy4kK6xDSmz+E0L4RzOulRmdIGBh8d4jiZIjO4cHNZcXYIWiPy1/+YlYRN639D LxaQkrA/0BUNg2W/rjX19Ku1iv8InvDskIbhiwV1a+wKXhx4AyHPtja2/Ffcg3j0FhSj NGJl4mx7Zfp+ZjiTU/mYIGsib4qAVizGyLhYCprHjy5C8BAjOL3a42oRfxrqSaTe7ncJ wv7g==
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=uY+ZWiMTikzHKGLahLoIrIXGPDdbwXLyIc00qcaOi6Q=; b=CvYqClbPr+9of2KMNLOk83aWeN23JqUhWtiSjL4oAW2FZBYiE+lq6otERIFOwr55sc 16huuaoz6LyrGkA7Chv/eiriEN6Oh7tqynTdxqG/j0o75b/4jLmDHB2iZ2Yz7nPz/bkB S0UJK175Ft9fdugV037gJGsGs0sr2k0vACTX1Qc0hVEdEQVwpBK5cvBGEkg9o2v4kXHI g0dh+GAJq52Cq03msAkYNUmEJbzjZQseQNd063gJM8zOtH+faaGaCr/0MZdb3XYTlmva vT2vXKLEsp63xX9XLwaoXT8HAzCsM1lStYIWBGVyRtQG0AO2wYHEOR/xC3yqalH10gIE VT7Q==
X-Gm-Message-State: AFeK/H3AqQM0j/4b+7S5GduUwoBwd/SDArfPMeRSP6LylMhFkAEpsCyKbKG98kokPVyejB/aZBt/T1H42Kwriw==
X-Received: by 10.25.76.193 with SMTP id z184mr15733327lfa.43.1491858351243; Mon, 10 Apr 2017 14:05:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.83.5 with HTTP; Mon, 10 Apr 2017 14:05:49 -0700 (PDT)
Received: by 10.46.83.5 with HTTP; Mon, 10 Apr 2017 14:05:49 -0700 (PDT)
In-Reply-To: <CABkgnnXv4RkwGKW42O_0=6FgQHgFjOGVxoHvxUdY=vhAJPWi7A@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>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 11 Apr 2017 07:05:49 +1000
Message-ID: <CABkgnnWrufep_hQTVqbZ6cn9kDZRkc_B4ExWOV_5d3bK_H_-zw@mail.gmail.com>
Subject: Re: Review of draft-mm-wg-effect-encrypt-09
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: ietf@ietf.org
Content-Type: multipart/alternative; boundary=001a114b060c14c8e2054cd6572d
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/6dBVElerIA38Ql992_45_g1ZQG8>
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: Mon, 10 Apr 2017 21:06:02 -0000

I most certainly reviewed 09. I haven't reviewed the diff. I doubt that it
would change my opinion on the macro - level problems.

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

>
> 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.
>
>
> 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?
>
> 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.  I'm
also
> inclined to suggest that this is the wrong question to ask in the first
place.
>
> 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.
>
> 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?
>
>
> 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.
>
> 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.
>
> 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.
>
>
> 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.
>
>
> 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.
> 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.
>
> 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>;.
>
> 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?

Thank you,
Kathleen

>
> 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.
>
>
> Section 2 (top section)
>
> I like that the attacks on SMTP by network operators is highlighted here.
>
> 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.  This implicitly makes a value-judgment
about
> relative morality/acceptability/value of certain practices.  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.
>
> 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.
>
> 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.
>
> 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).
>
> 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".
>
> 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.
>
> The degree to which these models are privacy-invasive is not even
acknowledged.
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> This text references a non-existent Appendix.
>
> 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.
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> 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.
>
> 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).
>
> Section 4.1.3.2
>
> "HTTP/2", not "HTTP2".
>
> 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.
>
> The discussion of caching here warrants a new section.
>
> Section 5.1
>
> s/effect/affect
>
> 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.
>
> 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.
>
> Section 5.5
>
> See my comment about about endpoint-based methods.
>
> 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.
>
> That said, this doesn't pay any attention to another feature in HTTP/2:
> connection coalescing.
>
> Section 6.2
>
> ALPN will be encrypted in TLS 1.3.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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).
>
> Section 7.4
>
> s/GPSR/GPRS/ ?
>
> 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.
>
> 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.
>



--

Best regards,
Kathleen