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

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Apr 2017 13:24:59 +1000

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

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.

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

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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 7 Apr 2017 13:34:10 -0400

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.

> includes things on which the IETF has published statements (see for example RFC

See the abstract and introduction and summary.

> attempt to dilute RFC 7258.

Not at all.

> 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

-- 

Best regards,
Kathleen

---

From: Eliot Lear <[email-masked]>
Date: Fri, 7 Apr 2017 21:37:25 +0200

On 4/7/17 5:24 AM, Martin Thomson wrote:
> collateral[...]

... DAMAGE.

You couldn't even say the word. 

The whole point of the document is to expand upon the implications of
what operational practices are impacted in an encrypted world.  That
doesn't mean people should stop encrypting, but it does mean that we
should understand what is breaking.  To do otherwise is to stick our
heads in the sand.  Let's not do that.  And let's not question whether a
particular function is "legitimate" which ironically applies a value
judgment, something that you yourself complained about.

Better to focus on whether the impact of encryption has indeed been well
documented.

Eliot
ps: but I agree with your point about statistics.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 7 Apr 2017 15:31:02 -0700

> Better to focus on whether the impact of encryption has indeed been well
Having read draft-mm-wg-effect-encrypt-10, I agree with Martin. This
draft is hard to read, and provides a confusing mix of business goals,
techniques, and complaints. My personal recommendation, like Martin's,
is that it would benefit from a thorough rewrite before publication.

I also agree with Martin's recommendation to leave QUIC out of this
business, since it is not standardized yet. The proper place for the
QUIC related text is in a contribution to the QUIC WG.

The draft presents a number of practices, but does not really articulate
practices and business goals. In fact, it starts from the practices,
instead of starting from the goals. My recommendation would be to start
by articulating the "business goals" such as Parental Control, Spam
Filtering, Phishing Prevention, Data Leak Prevention, Insertion of
Super-Cookies, Traffic Engineering, Traffic Prioritization, Data
Compression, Traffic Intercept, Censorship, or Load Balancing. The draft
could then explain how each of these goals are performed by a variety of
techniques, some of which are deployed on the end points, and some other
at various places in the network using a variety of techniques,
including header analysis and deep packet inspection. And then the draft
could have another section explaining how network-based techniques may
or may not be affected by the deployment of encryption.

As a bonus point, we could also note that many of the business goals are
somewhat controversial, and state the controversy.

But the current draft is too confusing for being endorsed by the IETF.

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Apr 2017 07:05:49 +1000

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" <
[email-masked]> wrote:

Hello Martin,

The abstract states:

Not at all.

Thank you,
Kathleen

> https://www.washingtonpost.com/rf/image_404h/2010-2019/
WashingtonPost/2013/10/30/Local/Images/GOOGLE-CLOUD-
EXPLOITATION1383148810.jpg).

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 10 Apr 2017 23:54:34 -0400

Hi Martin,

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

> 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"
> <[email-masked]> wrote:
>
> Hello Martin,
>

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.

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

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

>> attempt to dilute RFC 7258.

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?

>> each practice the pros, cons, and technical limitations are covered with

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

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

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

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.

>> better solutions to legitimate problems is worthwhile.

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

>>    that properly respect privacy and security?

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

>> the cases where encryption most often interferes.

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

>> the cases listed in this document, the benefit is accrued primarily to the

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.

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

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

>> for the uptick in adoption of cryptographic protection for Internet

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.

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

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

>> use specific terms like "mail host" or "web server" as appropriate to the

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

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

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

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

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?

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

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

>> * "QUIC's server-generated flow IDs" -> "QUIC's connection IDs".

Thanks for the nit corrections.

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

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.

>> complete lack of transparency (yep).

This was organized per IESG review.

>> now at scaling content to suit the device on which that content is

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.

>> that significant damage can be done to video streams by "well-intentioned"

Please suggest text.

>> adopt undesirable security practices".  Statements in that form have no

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.

>> The use of particular examples (betting, gambling, dating) shows cultural

subjective review again, but 7754 cites examples too.

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

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

>> http://conferences.sigcomm.org/hotnets/2010/papers/a6-popa.pdf) saying

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

>> Malware encrypts too (https://arxiv.org/abs/1607.01639).

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

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

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

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

>> saying things like "PGP may be a front runner" though.

This was added per EKR in IESG review.

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

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

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

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

>> fairly clear on this point).

Thanks for catching that.  We can drop this text.

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

Fixed.

>> casually list off the cuff.

Please suggest text.

>> The discussion of caching here warrants a new section.

Thanks, we'll fix this.

>> No cititation for APWG.  Not an IETF working group from what I can see.

We'll add that, thanks.

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

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

Already agree with this point.

>> attention this section devotes to it.  The clients that don't include SNI

Text was aded per EKR's review.

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

Please suggest text if this should be included.

>> ALPN will be encrypted in TLS 1.3.

Noted.  Thanks.

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

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

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

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

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

>> s/GPSR/GPRS/ ?

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

>> new information, particularly information relevant to RFC 2804.

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

>> 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 & Al

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 11 Apr 2017 08:13:43 -0400

I received a correction...

Sent from my iPhone

> On Apr 10, 2017, at 11:54 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Martin,
> 

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

Kathleen

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 12 Apr 2017 20:28:31 +0200

Hi Martin, hi Kathleen,

I would like to comment (for now) just on this one section, as my name was called out.

> Am 11.04.2017 um 05:54 schrieb Kathleen Moriarty <[email-masked]>:
> 
>>> Section 2.1
>>> 
>>> to be necessary?  

My understanding is that the stand-alone load balancer was only brought up to better explain what an integrated load balancer is, assuming that the integrated (more complex) case is the common one. 

However, to answer your question, for a stand-alone laod balancer it is assumed that you only have a small number of servers at one single location and you only need one box that does the load-balancing on these different servers. So all this box needs to know is the IP address of these servers.

>>> Is this something a network operator uses?  I see text
>>> on NFV

To my understanding all the concerns apply to integrated load balancers. Integrated only means that the load balancer shares some information with the server and based on this knowledge the load balancer can identify based on some information in the packets which server this packet should be forwarded to.

> Google QUIC (referred to as GQUIC in IETF discussions) is a more

I fully agree to remove the quic specific language. It’s definitely too early to say something in this document (and GQUIC is probably not documented well enough to rely on this). This text wasn’t provided by me but I recommended a contributor for this text who is also active in the quic wg and missed this when he send the text.

I recommend to simply remove the following sentences:

"QUIC is an example of such
   protocol in development by IETF QUIC WG right now.“

"New connection-migration-tolerant protocols, such as QUIC, are
   deliberately designed to allow such extra information available in
   plain text (QUIC's server-generated flow IDs).“

>>> Is this an oblique reference to (the much-loved) RFC 7974?

No, not at all. There are other ways middleboxes can add information. But in this case actually the server would add information because the load balancers and the server share some knowledge.

>>> Otherwise, I don't know what it means.

A server could select a certain sequence number (range), or TCP timestamp, I guess...

> the sponsoring AD's request of that work.

I think this sentence should be removed in this document and a reference to RFC 7258 should be added, instead of coming up with new terminology here that sets the bar higher that what was agreed in RFC 7258.

> Thanks for the nit corrections.

Thanks!

I will further comment later!

Mirja

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 12 Apr 2017 14:42:56 -0400

Mirja,

Sorry for the top post.

Thank you for responding on the outstanding items that were more
technical in nature (QUIC and load balancing).  We'll integrate your
suggested edits in the next revision.

Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 12 Apr 2017 23:01:41 -0400

Hi Mirja and Martin,

Responding inline with adjustments that were made to address the
technical comments and responses in this section of the review.  This
will show up in version 11.

>>    plain text (QUIC's server-generated flow IDs).“

These sentences have been removed.  Thanks for your guidance on these questions.

>> I think this sentence should be removed in this document and a reference to RFC 7258 should be added, instead of coming up with new terminology here that sets the bar higher that what was agreed i…

Thanks, Mirja.  Deborah suggested some new text for the abstract and
introduction that hits on this same point as well.  It should assist
with some of Martin's tone comments.  As for this specific suggestion,
we deleted the text as advised and added the following per your
suggestion:

       As noted in Section 2 of RFC7258, careful consideration
        in protocol design to mitigate PM is important, while ensuring
        manageability of the network.
>> I will further comment later!

Your assistance is much appreciated.

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 13 Apr 2017 01:33:23 -0400

Hello,

>> Perhaps you have additional language suggestions for context setting?

We have updated version 11 with new context setting text that
hopefully addresses your major concerns in tone setting for the rest
of the document.

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

The abstract has been updated further to ensure the context is set and
shows how the document further supports the goals of RFC7258.
Hopefully this is a helpful update for you.

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

We've added some additional statements in line with the goals of
RFC7258 balancing network management and PM mitigations.

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

This wording has been updated to avoid unintended interpretations of that text.

> we have responded to them.

We have also made an effort to update text to clear up tone questions
where specific text has been called into question.

> The abstract is value neutral right now.

The abstract has been updated, please see version 11.

> encryption protocols helps with this.

update made.
> but should be deprecated crypto.

I read the text in the draft again and changed it as follows:

      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
in the US. Only methods keeping with the goal of
      balancing network management and PM mitigation in
      RFC7258 should be considered in solution work resulting
      from this document.
> back with Stephen to see if he agrees.

We changed the text slightly in a way that should help with your concern:

      The loss of access to these fields, has in some cases,
      prompted undesirable security practices in order to gain access to the
      fields in unencrypted data flows.

> reference.  Do you have a wording suggestion?

<snip> questions and text addressed with Mirja's assistance.

>>> subtlety to be lost on many readers though.

removed.

> Thanks for catching that.  We can drop this text.
dropped.
>>> text that does this), you need to acknowledge the downsides.

By use of the word, attack, this is not a recommended method.  It's
also not in line with the goals of RFC7258, so it's just a practice
that's documented.  Not one that is endorsed (none are).

  For example,
>>> MitM

Added reference.
> in place for a long time by these users.  Essentially, it's not an argument that

The following sentence was added:
      Changes to improve encryption or to deploy OS methods have little
      impact on the detection of such activities as they already have access to
      strong encryption.

-- 

Best regards,
Kathleen

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Apr 2017 15:26:20 +1000

Hi Kathleen, (Al,)

First, I think that my comments have been misinterpreted - albeit
understandably - as meaning that I am opposed to the existence of this
document.  That's not the case, I believe that there is valuable
content here and I would like to see this published.  As observed
separately, writing RFC 3234 was difficult, but ultimately valuable.

I think that there are some structural issues and some unnecessary
making-of-statements.  The former needs some fairly major editing
work; the latter: I'd advocate for excision.  I believe that your
assertion is that the latter have been excised; I found several places
where that is clearly not the case.  I'll try to highlight those I
find, but I can't afford the time to do another full review just yet.

It would be a mistake to simply say that because someone requested
publication that this document is ready to publish.  The main cost of
taking another pass at this is the not-inconsiderable time and effort
that requires.  So far the main argument against doing that is that it
is hard, and I can't really disagree with that.  I happen to think
that the extra effort is more likely to produce a more valuable
product.

I've tried to trim this mail; it's long.  I noted quite a few issues
that you didn't address in -11 or respond to in the process, but I'm
just cutting them for the sanity of all involved.

>> Perhaps you have additional language suggestions for context setting?

I have a suggestion, below.

> which is part of our intent.

I don't think that argument is so easily dismissed.  When we create a
statement, we have to consider how it might be read from multiple
perspectives.  In this case, it's not that much of a stretch to
believe that someone might read some of the statements here as license
to try to undermine TLS (for example, based on a reading of the text
from Section 2.4).

> are "requirements" or even "needs".

Actually, I don't question the fact that people believe these to be
requirements.  But I see a lot of cases where it's less clear, for
example in Section 2.3.1 (I'm moving to -11 now):

   This [referring to traffic analysis] technique may be
   used with clear text or encrypted sessions.

Thinking about an adversarial reading of this, is that a permissive "may"?

> We thought that was very clear to your points.

The abstract could be better I think.  How about?

   Pervasive monitoring attacks on the privacy of Internet users is of
serious concern to both the user and operator community.  RFC 7258
established the need to protect user privacy when developing IETF
specifications.  This encourages reducing the information that is made
available to passive observers, which affects some security and
network management practices.  This document describes those practices
and examines the effect of increased use of encryption on those
practices.

On a second read, I think that the bulk of the problem is with 1.1,
section 1 is largely OK.  The second-to-last paragraph of Section 1.1
is critical, but I actually think that the remainder of that section
is more of a liability than an asset.  The discussion of OS is weak,
creating good citations for the statistics is hard, and the discussion
of non-web cases isn't adding much value.  You could simply take it as
read that there will be increased encryption and this document would
work well.  Even if you didn't want to assume that encryption is
increasing in volume, you could have a fine document that explored the
management impacts of encrypted sessions.

Also, it would help if there was a clearer statement regarding lack of
endorsement.  If you are going to say "lawful intercept exists" - a
true statement, almost a truism - it's prudent to also say that this
isn't an endorsement of those practices.  Explicitly.

> 1.3, TCPinc, QUIC, etc.).

Yep, and that's a valuable goal.  It would be nice to have a document
that allowed someone with a need (or requirement) to be redirected to
an architecturally sound solution.  The challenge is that these
problems don't all have simple solutions.  In its current form, I
don't see this draft as providing that service well because the
goals/use cases aren't particularly well-organized.  Also, it's
probably best to avoid developing solutions as part of this.  A simple
catalogue of needs and practices works.

> RFC 7258 so we can change that specific wording?

See above.

> summary and sprinkled throughout the document.

I don't think that the superficial change really worked.  See above
regarding "may".

> "... the different practices that might be employed to achieve that goal."

Agreed.  I am more interested in the structure of that document.  How
it breaks down the problem carefully and explores the various options.
You don't have to offer solutions here, but the treatment could be
more methodical (like in RFC 7754).

> privacy.

I understand that's true.  Though it's also a little sad, I'm speaking
from a position of privilege, so I won't make too much of an issue of
it.  What interests me here is the operational challenges that arise
from this.  The need to modify multiple applications for instance.

> the introduction?  - This document aims to...

If that is actually the aim of the document, sure.  It seemed less
clear to me what the intent was from reading it.

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

I don't think that this is exactly the question you ask, it's a
broader one that you are trying to attack.  You are laying the
groundwork for asking that question: which is, what are those
practices and why do they exist?  The question of legitimacy isn't one
that you want to tackle here (not enough space, too hard, etc...) and
designing solutions is best left to individual protocol designs.

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

It's very easy to lose track of that 40 pages in when the text that
you are reading says something else.

> and there is benefit for all parties when the trouble is cleared.

I think that you missed my point here.  The point is that the document
declares various outcomes as virtuous, rather than simply describing
the practice.

Section 2.3.2.1:

   The features and efficiency of some Internet services can be
   augmented through analysis of user flows and the applications they
   provide.

That's an statement that ascribes a virtue to a particular practice
without qualification.  The ensuing text only doubles down on that.

> That's not the point of IESG review.

See above.

> operators understand it in the mix of encryption options.

The first two paragraphs of Section 1.1 talk about OS.  In the context
of this document OS is maybe relevant for a few reasons:

1. it can be removed trivially (see the STARTTLS attack by operators)
2. it can be deployed more easily (debatable)
3. it is encryption

Of these, the last is the only thing that is relevant.  For the
reasons I cite above, I would restrict discussion of it to those
sections that talk about stripping opportunistic security (striptls,
the STARTTLS attack).

>> have further text suggestions to clarify this statistic?

Well, my first suggestion is removal.  Failing that, create citations
for the statistics.  If you can't - the Dell EMC stats, for example -
then at least describe what they mean. I don't know if 78% applies to
connections, packets, or requests (probably not requests).

> but should be deprecated crypto.

I think that you should include a section on intercept.  It happens;
encryption largely prevents it, though OS doesn't.

> back with Stephen to see if he agrees.

I would prefer that the document doesn't mention that at all.  Talk
about disabling OS as a practice that happens.

>>> I

See above.  That is, acknowledge that some methods exist for
"breaking" encryption, that those are largely limited to striptls and
its ilk, though attackers with significant resources might be able to
perform other sorts of attacks (cite the attacks on TLS doc here).

> specific additions that were requested.

I think that Mirja responded here, I'll follow-up there.

> Google QUIC (referred to as GQUIC in IETF discussions) is a more

It's existence seems assured, but not its form.  Google are tracking
the IETF work.

> shift with these changes.

Here's a structural suggestion then:

* Use Cases
** Common Use Cases - those for more than one type of network operator
(e.g., troubleshooting)
** Enterprise Use Cases - those unique to enterprise (e.g., DLP)
** Network Operator Use Cases - e.g., capacity modelling
** Hosted Service Use Cases
* Practices
** DPI
** Traffic Analysis
** Removing Encryption
** Repacketization
** TCP Termination
** ...

Description of use cases can list practices used in support of them,
or the practices can list the use cases they support, or both.

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

"This has an effect on applications in addition to network operations.
By removing the ability of an intermediary to compress content, the
responsibility for adapting to network conditions moves to the
endpoints.  Applications that are able to compress content, or reduce
bandwidth use to suit network conditions will gain better
performance."

>>> that significant damage can be done to video streams by "well-intentioned"

"Compression employed by middleboxes can have an effect on
performance.  In addition to latency costs, compression can require
additional computational resources.  Use of lossy compress degrades
the quality of content."

> text and we'll go back to the other person.

Ahh, I hate putting you in that position.  I would prefer if this be removed.

> Please suggest text.  This was updated in IESG review.

I see a reference to Section 7 here, but no text on zero rating in that section.

Zero rating is a use case in its own right.  I would make a new
section, or simply repurpose Section 2.6.2 for that (remove paragraph
1).

Section 2.6.2. Zero Rating and Preferential Treatment

   Some network operators sell tariffs that allow access to certain
content without cost to users, a practice known as 'zero rating'.

   More generally, users might be charged differently based on the
content they are viewing.  Or, packets related to the access of
certain content might be given different priority.  Identification of
content is critical to providing this differentiation, because web
content is often distributed across multiple servers.

   Use of encryption hides details about content, preventing the use
of those specifics from being used in providing preferential
treatment.

This expands the scope of the section considerably, but I think that
it's what you want to say.  I have restrained myself in not making any
statement about the virtue or otherwise of these practices.  I think
that this is a bad trend, but we don't need to say that in an RFC
(unless we create one with that purpose, that is).

> proposing text to help in that vein.

"The widespread use of encrypted HTTP means that TCP port 443 is being
used for a large variety of use cases with sometimes very different
performance requirements.  Some uses are latency-sensitive, others
need to send lots of bytes.  In some cases, mixed uses appear on the
same connection; which is possible with both WebSockets [RFC6455] and
HTTP/2 multiplexing [RFC7540].  A network operator is unable to
provide differential treatment using the information that is available
to them."

Now that I look at this, this is a more general and useful statement.
Hiding it in the bottom of a section about something else doesn't make
a lot of sense.  It's also not general enough to surface in an
introduction, so I recognize the difficulty in finding it a home.

> environments.  There were adjustments made and they've been

This short explanation is much easier to digest.  Is there any way
that might be said up front? Though even with that, I would still find
this section very difficult to read.

> with given the large number of applications running in their

If that is indeed an issue (I've heard the same asserted, it's
probably true), then it needs to be said.

>>> casually list off the cuff.

Well, to preface this, I don't think that this is the right section to
put text like this.  It's more appropriate in a section that talks
about the specific techniques (Section 4.2 is another grab bag of
practices duplicating text from other sections).

I think that it is entirely appropriate to say:

```
Encryption can be disadvantageous to the goals of the operator of a
middlebox.  Removal of encryption without the consent of endpoints is
an attack.  Attackers can and have removed attempts by endpoints to
use opportunistic security (see [SSLSTRIP --
https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf],
[STARTTLS -- Section 5.1 of DOI.10.1145/2815675.2815695]).  More
resourceful attackers might use attacks or weaknesses in deployed
protocols (see [RFC7457]) or flaws in implementations to remove or
attack uses of encryption.
```

That's a stronger statement than I think you are looking to make
though.  It doesn't invalidate the cases where endpoints are owned and
trust anchors are installed.  I would put that down in a different
section.

```One method for intermediating encrypted sessions is to install a
trust anchor on an endpoint and then use the associated keys to create
authentication credentials that will be accepted by the endpoint.  In
this way, a middlebox can terminate a session in a way that the
endpoint will accept as legitimate, thereby impersonating the intended
peer.

This technique rarely works for mutually authenticated communications,
because the middlebox is usually unable to exert control over both
intended endpoints in a way that would allow it to impersonate both
peers to each other.  It also causes the modified endpoint to become
entirely reliant on the methods the middlebox uses for correctly
authenticating the intended peer.

For example, a web client typically implements authentication checks
that exceed those listed in RFC 5280 [cite]. This might include key
pinning [RFC7469], OCSP stapling
[https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-ocsp-stapling/],
and other checks. A middlebox that impersonates a web server that does
not perform the same checks could be vulnerable to the attacks that
these additional checks are intended to protect against.
Impersonation of a web server also hides the true status of the
connection from the web client.
```

>>> Section 6.1
...
> Please suggest text if this should be included.

Here's a rewrite...

```
A TLS client that initiates a connection to a server can provide a
server_name extension (server name indication, or SNI) [RFC6066] which
indicates the name of the server to which it is attempting to connect.
SNI allows servers to select between multiple certificates when
handling a TLS handshake.  This enables the use of multiple domain
names at the same IP address, also known as virtual hosting.

Although SNI is an optional extension, it is today supported by all
modern browsers, web servers and developer libraries.  Akamai [Nygren]
report that many of their customers see client TLS SNI usage over 99%.
HTTP/2 [RFC7540] mandates the use of SNI.

When present, the server_name extension that is included in the TLS
handshake is not encrypted.  This allows a passive observer to
identify the domain name to which a connection SNI is being made.
Other information about the application, such as the URL of an HTTP
request or the type of content being requested, is not visible, only
the domain name of the server.

Relying on SNI to identify a host has several limitations.  It is not
present in a small number of cases where clients do not support the
feature, or where protocols that don't mandate or rely on its use.  In
addition, HTTP/2 connection coalescing (see Section 9.1.1 of
[RFC7540]) can mean that a connection originally established for one
name is used for requests to other names.
```

I've dropped Alt-Svc mentions (they aren't relevant in this context -
even with HTTP OS, SNI is still shown in the clear).  I tried to keep
the text about the type of content

>>> ALPN will be encrypted in TLS 1.3.

Hmm, I should have been clearer, the server's choice of application
protocol will be encrypted.  The client's set of options will not be.

> the problem with the text you are citing, so could you suggest

```
Information about the content of encrypted communications is often
available through traffic analysis.  For instance, the size and timing
of packets can reveal considerable information about the contents of
data [NETFLIX][CLINIC].

Applications can implement traffic analysis strategies, usually by
padding content to obscure its true length.  This can be achieved in a
limited fashion in block ciphers in TLS, and various features of other
protocols can be exploited to add padding.  Explicit support for
padding is included in HTTP/2, TLS 1.3, and some other protocols.

Use of multiplexed protocols can confound traffic analysis by
combining data from multiple discrete events.  However, multiplexed
protocols depend on flow control, which can be exploited to reveal
information (see [HEIST]).
```

Citations for the above (sorry, rough):

  NETFLIX=DOI.10.1145/3029806.3029821
  CLINIC:
    title: "I Know Why You Went to the Clinic: Risks and Realization
of HTTPS Traffic Analysis"
    author:
      - ins: B. Miller
      - ins: L. Huang
      - ins: A. D. Joseph
      - ins: J. D. Tygar
    date: 2014-03-03
    target: "https://arxiv.org/abs/1403.0297"
  HEIST: https://www.blackhat.com/docs/us-16/materials/us-16-VanGoethem-HEIST-HTTP-Encrypted-Information-Can-Be-Stolen-Through-TCP-Windows-wp.pdf

> discuss.  It was the mobile operator view.

It's valuable information, sure, but hard to use.  I can see why the
IESG thought that it needed to be in the body, as there are quite a
few new use cases.

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

The bit about surveillance programs and lawful intercept really need
to be in the relevant sections of the body (that was the "new
information" I referred to).  I agree that it would be good to promote
the first statement to the introductory material.

> in place for a long time by these users.  Essentially, it's not an argument that

Yeah, as before, when it comes to discussion of lawful intercept, I
would prefer to have that in the body of the document.  Preferably
without mentioning why it happens, because that avoids the emotive
topics.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 19 Apr 2017 12:52:09 -0400

Hello Martin,

Thanks for your review and clarification.

> separately, writing RFC 3234 was difficult, but ultimately valuable.

Thanks, this is very helpful.
> find, but I can't afford the time to do another full review just yet.

That's good that you haven't had time for a full review yet as we are
working on a revision. Alissa . Cooper has been providing extensive
input on the latter.  We are waiting on some comments from her and I
will be taking a couple of days off, so there may be a slight delay in
posting the next version.

As for structural issues, it is tough with this document as there are
many opinions on what the layout should be, having said that, we are
looking at that as well.  We'll likely figure out what to do with
section 7 as a first step.

> that the extra effort is more likely to produce a more valuable

We are working on it already.

>> which is part of our intent.

We've worked on the context setting more since this last message with
input from the IESG reviews.  I'll just put a bit of the text here and
the rest will be in version 12.  We can let you know when the updated
version gets posted.

1.  Introduction

   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.
   Pervasive Monitoring (PM) is of serious concern to users, operators,
   and application providers.  RFC7258 discussed the critical need to
   protect users' privacy when developing IETF specifications and also
   recognized that making networks unmanageable to mitigate PM is not an
   acceptable outcome, but rather an appropriate balance would emerge
   over time.

...

Seeing the rest in the next version and getting your comments would be helpful.

>    used with clear text or encrypted sessions.

Good then I'll update that to, more of a statement that this occurs:

This technique is sometimes used with clear text or encrypted sessions.

> and examines the effect of increased use of encryption on those

We've updated the abstract in IESG review and have the text as follows
in the running version.  The full scope of RFC7258 is important for
this draft as it discuses finding a balance with network management
and the importance of user privacy.  The following is similar to your
proposed text, but includes that as well.  We want to make sure the
document is helpful to operators and keeps the conversation open for
each side of the discussion - so it happens.

Abstract

   Pervasive Monitoring (PM) attacks on the privacy of Internet users is
   of serious concern to both the user and operator community.  RFC7258
   discussed the critical need to protect users' privacy when developing
   IETF specifications and also recognized making networks unmanageable
   to mitigate PM is not an acceptable outcome, an appropriate balance
   is needed.  This document discusses current security and network
   management practices that may be impacted by the shift to increased
   use of encryption to help guide protocol development in support of
   manageable, secure networks.

> management impacts of encrypted sessions.

In reviewing this text again, I see we jumped right into TLS and DTLS
with no discussion of OS used in IPsec.  I'll think about this a bit
more.  IPsec has had OS in place for a while and we have a few
documents published showing implementation work: RFC4322 - Linux
FreeS/WAN project and RFC7619 -specifying IPsec without
authentication.  The latter was implemented by RedHat.  RedHat put it
in the OS and had intended to have it enabled by default, that hasn't
happened yet.  There are many uses for OS between servers or Linux
systems, where you can't authenticate the other party in advance.  I
actually posted a review to the DHCPv6 mailing list yesterday pointing
to these RFCs to consider including int heir work to make it easier to
implement end-to-end encryption for DHCP for the coffee shop use case.
Storage uses IPsec and I'm sure there are other use cases where OS
is/will be very helpful. We'll play with the text a bit to make this
clear.

> isn't an endorsement of those practices.  Explicitly.

OK, some of this text got cut, but we'll look through it again.  We've
also gotten comments to not have text throughout that restates such
things as the context setting is enough.  I think considering this
with the full updates is needed and we'll look at that.

> catalogue of needs and practices works.

Agreed.
> I don't think that the superficial change really worked.  See above

Yes, we are working on this and if you find any problems in a later
version, that would be helpful.  We are trying to catch all of them.

> clear to me what the intent was from reading it.

OK, hopefully much of what you are looking to see will be in one of
the next versions.  We may need to do a couple as we work through the
rest of the comments.

> designing solutions is best left to individual protocol designs.

Agreed and yes, this might be input to include in conversations on
individual protocol design.  At that point interested parties should
dig deeper and determine what make sense and what is possible
considering the balance that is desired for that protocol.

> you are reading says something else.

Fair enough.

> 2. it can be deployed more easily (debatable)
I think the IPsec uses of this may change the argument (meaning the
deployment ease improves for that), think DHCP or connections between
servers.  In the RedHat case, their plan was to implement tunnel mode
IPsec and have it enabled by default for use between other systems on
the same operating system.

> sections that talk about stripping opportunistic security (striptls,
I'm going to think about your points more, but just an initial thought...
For follow on work, wouldn't individual protocol designs consider OS
in the balance between management and privacy?  I would think the
conversation would be part of the discussion and wouldn't go as far as
saying (for the purpose of this thread, not the draft) that management
would tip a balance to OS

> connections, packets, or requests (probably not requests).

For Dell EMC, it was firewall logs.  This would be URL accessed (many
for single pages) I suspect.  We'll think more about this and possible
removal.

> encryption largely prevents it, though OS doesn't.

OK, we'll consider doing that.  I think some of this text has been
removed in the current version and I don't want to see a head in sand
approach, so maybe a section on interception is the best way forward.

> about disabling OS as a practice that happens.

We'll think about this more in an intercept section.  There are steps
to this, TLS 1.2 to TLS 1.3, use of OS in TLS and IPsec, known attacks
possible in TLS 1.2, things you can do if you own the server and keys
for TLS, as well as ACME work - setup easier, but not quite as secure
since we are accepting tradeoffs to increase the use of encryption.

> perform other sorts of attacks (cite the attacks on TLS doc here).

Noted, thanks.
> I think that Mirja responded here, I'll follow-up there.

Great and her suggestions have been taken into account in the working
copy of the draft.
> It's existence seems assured, but not its form.  Google are tracking

This was removed, per Mirja.

> or the practices can list the use cases they support, or both.

Thanks, we'll consider this structure.
> bandwidth use to suit network conditions will gain better

Thanks for the text to add.

> additional computational resources.  Use of lossy compress degrades

Thanks for the suggested text.

> Ahh, I hate putting you in that position.  I would prefer if this be removed.

It was edited again in the meantime.  One instance seems to be removed
(there were 2) and we have:

      In response to increased encryption of these fields, some network
      service providers may be inspired to undertake undesirable security
      practices in order to gain access to the fields in unencrypted data flows.
> (unless we create one with that purpose, that is).

Thanks, this is helpful. Al will need to take a look at this as well
and then we can integrate it.

> introduction, so I recognize the difficulty in finding it a home.

Thanks for the text, we'll figure out what to do with it then.
Structure isn't easy in this draft.

> this section very difficult to read.

OK, We'll think about this more.
> probably true), then it needs to be said.

I'm pretty sure we've inserted more text on logging, but will make
sure with a sweep of the full draft to make sure it was put in
appropriately.  This might not be perfect in -12.

> attack uses of encryption.

We'll think about this more as section 4 is part of the enterprise
text with the disclaimer at the start of the section that provides the
caveat that users have signed away their privacy rights (essentially).

> trust anchors are installed.  I would put that down in a different

This goes to our current division of sections for text and what's okay
in an enterprise is by no means okay anywhere else.

> connection from the web client.

Thanks for the text, it's helpful and we'll also consider placement.
I'm not sure of the extent of structural changes for the document, but
this is text that we'd have to consider where it makes the most sense.
> name is used for requests to other names.

Thanks for the text.  This is good, but we also have to include the
point that this is a change for operators and an impact as they were
using more information than just the server/hostname in the past and
we need to make that change clear in
the text for operator impact.

> the text about the type of content

OK, thank you.

> protocol will be encrypted.  The client's set of options will not be.

Thanks that's helpful.

> information (see [HEIST]).

Thanks is good text to have as part of the changes and problem statement.

>   HEIST: https://www.blackhat.com/docs/us-16/materials/us-16-VanGoethem-HEIST-HTTP-Encrypted-Information-Can-Be-Stolen-Through-TCP-Windows-wp.pdf

Thanks.

> IESG thought that it needed to be in the body, as there are quite a

We'll be working on this soon, maybe in -13, maybe -12, not sure yet.
> the first statement to the introductory material.

Noted, thanks.

> without mentioning why it happens, because that avoids the emotive

OK, l think about this more.  Thanks for your review and proposed text.

-- 

Best regards,
Kathleen