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

[Kathleen Moriarty <[e-mail]>]

I received a correction...

Sent from my iPhone

> On Apr 10, 2017, at 11:54 PM, Kathleen Moriarty <[e-mail]> wrote:
> 
> 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
> <[e-mail]> 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"
>> <[e-mail]> 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
>> <[e-mail]> 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).

Stephen was the co-author.  I should have checked that, but it was late when I hit send.

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