Subject: Re: Comments on draft-mm-wg-effect-encrypt-11

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 1 May 2017 07:38:21 -0400

Hi Mark,

Thank you for your comments.  This draft is in the process of a major revision and will have another IETF last call.  I think most of your pikers have been considered, but we'll make sure prior to posting an update.

Best regards,
Kathleen 

Sent from my iPhone

> On Apr 30, 2017, at 11:45 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Sorry for the late review; on the plus side, I'm coming to it with fresh eyes.
> 
> Overall, this document reads as if it was originally written to highlight the downsides of increased use of encryption, and then rewritten to be more neutral in tone. Unfortunately, some of the original intent posited there still seeps through.
> 
> In doing so, it often fails to convey that there are any options other than "this has to be done by the network." I know that this has been cast as a survey of potential impacts, and therefore doesn't necessary need to enumerate alternatives, but the way that it's written could easily lead a reader to think that there aren't alternatives. It also is odd that alternatives are not enumerated when they're often well-known, and the really interesting issues are in the tradeoffs between doing something in the network (i.e., as a third party) vs. by one of the endpoints (a first party to communication) or their delegates.
> 
> For example, Section 2.2 talks about the importance of passive monitoring for traffic surveys, but fails to discuss alternative means of gathering data (e.g., anonymised data from content providers; telemetry from client implementations) that are superior in some ways, limited in others. It would be a useful contribution to characterise the tradeoffs here, so this is an opportunity lost.
> 
> Section 2.3.2.1 points out that "Web proxies are widely used", but fails to note that the vast bulk of caching is done by endpoints -- browsers, CDNs and reverse proxies, thereby sidestepping the issues of encryption (although they have their own unique challenges). Discussing why this form of caching has become prevalent might help inform network operators as to why getting the economics and trust relationships of intermediation right is important.
> 
> Section 2.3.2.2 motivates DPI as "Input for Differential Treatment", but fails to note the developing efforts to coordinate client and server behaviour to adapt to network conditions, without the need for stripping encryption.
> 
> Section 2.4 talks about need for compression proxies, but fails to note the deployment of them in overlay networks (e.g., by Google Chrome, UCBrowser, Opera Mini, etc.). There is a minefield of issues surrounding them, of course, but it's useful context.
> 
> Section 2.5.2 does note that endpoint-based alternatives might be possible, but fizzles out after that. Exploring why they haven't developed would be a substantial contribution.
> 
> A few additional points:
> 
> * The Introduction says "it is important to catalog existing standard functions around network management, security and troubleshooting that have depending upon the availability of open information to function." Using the word "standard" here is misleading; some of the described functions are not envisioned or enshrined by Internet Standards.
> 
> * The Introduction says "The IETF reiterates its view that pervasive monitoring is an attack..."  It's odd to have an Informational document "reiterate" a BCP.
> 
> * Much of the Introduction motivates this document as being about "network management, security and troubleshooting." Then, later, it inserts things like "monitoring services", policy enforcement, and parental controls. These are qualitatively very different things. Being able to monitor and run the network to provide a service is not the same as being able to impose your will upon the users of that service. Elevating the latter to the status of the former is not something we should even unintentionally imply, even if it is common practice.
> 
> * Section 1.1 asserts that "Increased use of encryption (either opportunistic or authenticated) will impact operations for security and network management, causing a shift in how these functions are performed." This is an assertion about the future that's quite strong. I could see it saying that they *have* impacted, and then giving examples, or that they *might* impact them in the future, but asserting that it *will* impact them seems like an assertion that doesn't have IETF consensus.
> 
> * Section 2.6.5 talks about injecting HTTP headers into a connection and fails to note the significant privacy issues brought about by this practice. Using encryption to defeat this is, to many in the IETF community, a feature, not a bug.
> 
> 
> Hope this helps,
> 
> --
> Mark Nottingham   https://www.mnot.net/
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 1 May 2017 20:26:20 +0200

Hi Mark,

> Overall, this document reads as if it was originally written to highlight the downsides of increased use of encryption, and then rewritten to be more neutral in tone. Unfortunately, some of the ori…
What I'm becoming concerned about is us not talking about what we're
talking about.  If encryption presents challenges in some deployments,
certainly one should say so.  One should also say what workarounds are
available, and maybe even what challenges or complexities those
workarounds themselves introduce.

> Section 2.3.2.2 motivates DPI as "Input for Differential Treatment", but fails to note the developing efforts to coordinate client and server behaviour to adapt to network conditions, without the n…

There are two key issues to DPI is intended to tackle:

  * The ability to identify a class of traffic at all, perhaps without
    so much as the benefit of fixed TCP/UDP port assignments, as is
    often the case with media streams; and
  * Trust between the end devices and the network administration, where
    the administrator wants to know that a traffic class is used solely
    for authorized purposes (e.g., nobody's prioritizing Age of Empires
    by attempting to mimic an IP-based phone).

When encryption is present, the DPI fails.  To remedy this there are
essentially four approaches:

 1. Trust one of the endpoints, if possible, to report that the
    communication is authentic and authorized;
 2. Require that set-up of communications (such as a media streams)
    occur through a trusted 3rd party that reports 5-tuple information
    (including call completion);
 3. Make do with what information can be gleaned outside the payload
    (e.g., packet timing, sequencing, etc - so-called meta-information);
 4. Give up.

I'm sure smarter people than me have come up with options 5, 6, etc, but
you get the idea.

The trust relationships have to be in place for options 1 or 2 to work,
and for the mobile operator use case that might be quite tricky.  
Option 2 presents a state management issue, and may or may not incur a
latency penalty during setup.  Both 1 and 2 have attendant complexity of
additional communication paths, but as they say, there ain't no such
thing as a free lunch, and that really is or should be the point of the
draft. 

It may not be feasible to go into even this much detail in each case,
and we shouldn't require that, so long as the problem statement is well
supported.

> Section 2.3.2.1 points out that "Web proxies are widely used", but fails to note that the vast bulk of caching is done by endpoints -- browsers, CDNs and reverse proxies, thereby sidestepping the i…

I like the idea of examining the economic relationships between, say,
the end user's service provider and the end user, versus the end user
service provider and the content provider, etc., and where value might
be had with regard to those who have business relationships and those
who don't.  Note the case where the user is an employee is different
than when the user is a service provider customer, the former of which
is discussed in Section 4.

One caution: this document risks turning into a tome if the discussion
goes too long.  Better to be succinct and reference where one can.

Eliot

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 May 2017 12:04:13 +0900

> For example, Section 2.2 talks about the importance of passive
> monitoring for traffic surveys, but fails to discuss alternative means

possibly our friends from zürich have some ideas here

randy

---

From: Brian Trammell (IETF) <[email-masked]>
Date: Tue, 2 May 2017 11:39:44 +0200

you rang? :)

I'll refrain from wider comment on the current revision of the document; I think the authors continue to receive good feedback on its scope and structure, and I'll have a look during next last call.

Section 2.2 seems to be lumping together three things which aren't necessarily related: longitudinal studies of Internet traffic for operational and academic purposes, traffic matrix generation (a specific operational measurement purpose which has received a good deal of academic attention), and application classification / aggregation by application-layer semantics. The first two of these do use similar inputs (e.g. IPFIX data aggregated to the per-layer-4-flow level at the finest), but require application-layer data only if they additionally classify or aggregate traffic at the application layer.

For example, a simple traffic matrix might use IP packet and octet counts aggregated by prefix, and requires only IP-layer data to generate. A matrix focused on isolating transport-layer performance problems would need to estimate TCP parameters for each flow or group of flows, using TCP headers (typically TCP flags, sequence and acknowledgment numbers, as well as timestamps if available) in addition to IP headers to generate loss, retransmission, and RTT statistics. A more detailed matrix still could classify traffic as belonging to a specific application through application-layer header and payload inspection.

It's true that each layer you encrypt reduces the utility of passive measurement to determine certain things. For example, a study trying to estimate the amount of streaming video over a given link can do this much more easily and with higher fidelity by inspecting HTTP headers than it can by applying heuristics to the time-series of interpacket times and packet sizes. It's true that the inferences made in a measurement will have to get more clever as the amount of observable data decreases, and those inferences may be so weak as to make a particular measurement useless. But it's not true that these studies always need application-layer headers or payload, or even transport layer headers for the simplest matrices.

One note on the text here: "CAIDA" isn't one data set, they run many projects, many of which are active (e.g. Archipelago, which does various topology measurements); the best-known passive facility, the CAIDA darkspace telescope, surveys background radiation, and mainly catches backscatter. The application-layer semantics of which are either necessarily in cleartext (because there exists no cryptographic context to encrypt a backscatter reply to garbage) or irrelevant, so increasing encryption shouldn't cause a problem there.

Cheers,

Brian

> On 02 May 2017, at 05:04, Randy Bush <[email-masked]> wrote:
>

---

From: Brian Trammell (IETF) <[email-masked]>
Date: Tue, 2 May 2017 12:32:13 +0200

hi Mark,

...hm, apparently I *will* comment on the structure of the current document, inline below...

> On 01 May 2017, at 05:45, Mark Nottingham <[email-masked]> wrote:
> 

I think the statement of alternatives is a different document, though; it's one that needs to be written, yes, but the division of problem space and solution space is IMO useful here. I see this as the analogous to the split between RFC 7624 and draft-iab-privsec-confidentiality-mitigations. It was quite useful in having the former as a complete statement of what we think the problem is (in more detail that 7258's declaration) before recommending solutions. And, indeed, it's entirely possible that an IETF consensus statement on the solutions available for a given problem is "we have decided that this is not actually a problem we should design for", as in RFC 2804.

Cheers,

Brian

---

From: Benoit Claise <[email-masked]>
Date: Wed, 3 May 2017 18:26:48 +0200

Dear all,
> I think the statement of alternatives is a different document, though; it's one that needs to be written, yes, but the division of problem space and solution space is IMO useful here.
I would agree.
The operators are used to manage their network in a certain way.
The change for more encrypted traffic will force a change of those 
operational practices.
This document should serve as for a starting point to have this debate 
at the IETF, based on the documentation of those operational practices.
> I see this as the analogous to the split between RFC 7624 and draft-iab-privsec-confidentiality-mitigations. It was quite useful in having the former as a complete statement of what we think the problem is (in more detail that 7258's declaration) before recommending solutions. And, indeed, it's entirely possible that an IETF consensus statement on the solutions available for a given problem is "we have decided that this is not actually a problem we should design for", as in RFC 2804.
And again agree. Not all problems in this document are valid IETF 
problems. It doesn't mean that we should not document them.

Regards, Benoit

---

From: Christian Huitema <[email-masked]>
Date: Wed, 3 May 2017 09:42:38 -0700

> at the IETF, based on the documentation of those operational practices. 

My problem is that it is easy to get consensus on some practices, such
as "gathering statistics for traffic engineering", and much less so on
other practices, such as "opening the HTTP headers and adding
supercookies." The current document does not differentiate at all. It it
was published as is, the naive reader could just deduce that "the IETF
endorses adding supercookies to HTTP headers" -- to take just one
example. I understand that documenting alternatives for each of these
practices in the analysis document is impractical, but we need to find a
way to "document the controversy" -- when it exists of course.

-- Christian Huitema

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 3 May 2017 13:28:56 -0400

> way to "document the controversy" -- when it exists of course.

There's an explicit statement that says the IETF does not endorse the
documented practices.  It's not the practices, but the overall
document that we should have consensus on - that it is important to
document these practices so we have a starting point for discussion.
As Brian suggested, the follow on documents could do just that for
individual practices.  It's good to understand what is happening in
reality so we can help solve problems.

For the supercookie example, it is meant to be read with the preceding
text, which essentially does say what you are requesting - this is
something we don't want to happen - without a conversation, we won't
reach balance.  I'll clear up the text for that in the next version if
we haven't already.

-- 

Best regards,
Kathleen

---

From: Pete Resnick <[email-masked]>
Date: Wed, 3 May 2017 12:45:57 -0500

On 3 May 2017, at 11:42, Christian Huitema wrote:

> supercookies."

I have no idea what "getting consensus on some practices" means. It is 
certainly easy to get IETF consensus that both practices *exist*. They 
do; of that there is no question. If the IETF were being asked to come 
to consensus that both practices *were good*, yes, that would be 
difficult. Luckily, that's not what's being asked.

> The current document does not differentiate at all. It it
> example.

I cannot come up with any way to read the mention of super cookies in 
section 8 as an endorsement at all.

If you're referring to the discussion of header insertion in 2.6.5, the 
only thing that could be vaguely construed as endorsing would be the 
phrase in inverted commas (which I take to be indicating irony) 
'header-enrichment'. If the suggestion is that the irony will be missed 
and someone might read that as endorsing, then saying "so-called 
'header-enrichment'" might make it crystal clear.

Either way, lack of overt disapproval is not endorsement.

This argument is not an argument about consensus. The intent of the 
document (AFAICT) is to catalog the practices, not to register 
endorsement or disapproval of them. If the text of the document fails to 
do the former, or mistakenly does do the latter, then that should be 
fixed. But arguing lack of consensus is just a red herring.

pr

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 May 2017 09:57:37 +1000

On 4 May 2017, at 3:45 am, Pete Resnick <[email-masked]> wrote:

> I cannot come up with any way to read the mention of super cookies in section 8 as an endorsement at all.
> 
> If you're referring to the discussion of header insertion in 2.6.5, the only thing that could be vaguely construed as endorsing would be the phrase in inverted commas (which I take to be indicating irony) 'header-enrichment'. If the suggestion is that the irony will be missed and someone might read that as endorsing, then saying "so-called 'header-enrichment'" might make it crystal clear.
> 

I don't know, Pete. In my experience, people often misread intent in specs, even when we think it's very clearly spelled out, because we are blinded by how close we are to it. On the other side, developers routinely cherry-pick a statement in isolation to prove their point, rather than taking in the whole. This happens all of the time in HTTP, despite our best efforts to educate.

Relying on irony to convey intent in specifications is spectacularly poor practice; we should know better than this by now.

So I don't think it does any harm to over-communicate; if we're going to talk about a controversial practice like header "enrichment", it seems reasonable to me that we should put the appropriate context with it, rather than relying on the reader having a full understanding not only of the whole document, but the context within which it was written.

Even more so when the person misreading (or misusing) it might be a legislator or regulator who has comparatively little technical depth, but great impact.

Cheers,

---

From: Pete Resnick <[email-masked]>
Date: Wed, 3 May 2017 21:47:48 -0500

On 3 May 2017, at 18:57, Mark Nottingham wrote:

> ...I don't think it does any harm to over-communicate; if we're going 
> to talk about a controversial practice like header "enrichment", it 
> seems reasonable to me that we should put the appropriate context with 
> it, rather than relying on the reader having a full understanding not 
> only of the whole document, but the context within which it was 
> written.

As I said earlier, I think it's perfectly appropriate to make sure that 
we're not endorsing any of these practices in this document, so I have 
no problem "over-communicating", for example in 2.6.5. And so long as 
"appropriate context" doesn't mean "we must explain in excruciating 
detail the wrongness of each and every wrong thing about these 
practices", I'm fine giving a little context. I just worry from some of 
the comments that some folks don't want to make mention of any practice 
without both an explicit rejection of the practice (beyond the context 
setting at the beginning of the document that it is not the purpose of 
the document to endorse, but instead simply catalog, these practices) 
and a statement of alternatives to each of the practices. I think that's 
unreasonable to ask of this sort of document. So long as it says up 
front that it is not endorsing any practice, and there is nothing in the 
description of any particular practice that could be mistaken for an 
endorsement, that's enough.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 May 2017 12:38:05 +0900

> The operators are used to manage their network in a certain way.

the ways operators manage their networks is highly varied.

but, in reality, what packet data do i need beyond the basic four-tuple
and congestion markings?

> The change for more encrypted traffic will force a change of those

not necessarily.  of course it will seriously impact those operators
doing dpi, http header insertion, etc.  many of us consider this a
feature of encryption not a bug.

> at the IETF> practices.

it is.  and it should not go forward until we have had this debate.  and
we clearly have significant differences today.

> based on the documentation of those operational practices.

the set of operational practices is manifold.

Kathleen Moriarty wrote:
> documented practices.

standard wiggle 14.3.  please specifically call them out as negatively
affecting privacy and dis-recommended.

> It's not the practices, but the overall document that we should have
> consensus on - that it is important to document these practices so we
> have a starting point for discussion.

as christian alluded, the practices are not a closed set.

> section 8 as an endorsement at all.

or as an anti-endorsement.  so you would lay out the road map with no
marking of the evil paths.

> Either way, lack of overt disapproval is not endorsement.

in the real world of "buy our X device which implements rfc 666's
description of how to murder users" it is endorsement.

randy

---

From: Petr Špaček <[email-masked]>
Date: Thu, 4 May 2017 08:12:34 +0200

On 4.5.2017 04:47, Pete Resnick wrote:
>> only of the whole document, but the context within which it was written.
> 

I agree with Pete here. Little more context, or just repeated notice
"this practice is evil and listed here for completeness"
would be enough for this document.

Redundancy in natural languages helps to get the point across.
Let's add some redundancy!

Petr Špaček  @  CZ.NIC

---

From: Eliot Lear <[email-masked]>
Date: Thu, 4 May 2017 09:06:57 +0200

Just a comment on this:

> Even more so when the person misreading (or misusing) it might be a legislator or regulator who has comparatively little technical depth, but great impact.

That is *not* the concern that you should be focused on.

First, find me a legislator who has actually read an RFC, and I'll buy
you one of those fancy drinks you like.  Even most regulators do not
read RFCs, but when they do they are generally focused on normative
product requirements.  This document has no such requirements to grasp.

Nor should a press quote even be a serious concern, given how little
press 7258 and the IAB statement generated.

The only serious concern one might have is whether someone would look at
the document and decide that there is a problem statement for work that
would subvert security to take place, either within the IETF or
elsewhere.  Within the IETF we have a rough consensus process that
anyone can use.  It doesn't guarantee a result, but it is the best we
have, and I couldn't imagine someone *not* being called out for taking
something out of context, especially on this topic.

That leaves other organizations. some of whose members might even
intentionally misconstrue this work as justification to start new (bad)
work.  That's a real risk and it has happened before.  Repeatedly.  My
observation is that when this has happened in the past, the long term
consequences to the industry have been minimal, first because because we
have happily been able to stop some of the dumber ideas, and also
because our documents had good technical grounding while others did
not.  Furthermore, if we don't publish in order to avoid being
misconstrued, it means we cannot have an honest discussion amongst
ourselves, nor can we document any consequences of our decisions, and
that opens this organization up to far more serious (and deserved)
criticism by regulators, antagonists, academics, the press, and, well, us.

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 May 2017 17:14:00 +1000

> On 4 May 2017, at 12:47 pm, Pete Resnick <[email-masked]> wrote:
> 
> As I said earlier, I think it's perfectly appropriate to make sure that we're not endorsing any of these practices in this document, so I have no problem "over-communicating", for example in 2.6.5. And so long as "appropriate context" doesn't mean "we must explain in excruciating detail the wrongness of each and every wrong thing about these practices", I'm fine giving a little context. I just worry from some of the comments that some folks don't want to make mention of any practice without both an explicit rejection of the practice (beyond the context setting at the beginning of the document that it is not the purpose of the document to endorse, but instead simply catalog, these practices) and a statement of alternatives to each of the practices. I think that's unreasonable to ask of this sort of document. So long as it says up front that it is not endorsing any practice, and there is nothing in the description of any particular practice that could be mistaken for an endorsement, that's enough.

I'm not advocating going deep into the weeds. OTOH I chafe at the idea of a catalogue that has the theme "useful things that your network can do" that has things like header enrichment thrown in with *no* context -- which is the current state in -11.

Looking forward to the next revision.

Cheers,

---

From: Adam Roach <[email-masked]>
Date: Fri, 5 May 2017 15:28:47 -0400

On 5/4/17 03:06, Eliot Lear wrote:
> Furthermore, if we don't publish in order to avoid being misconstrued...

I have not yet heard anyone publicly say this document should not be 
published, and I find it a bit disingenuous to construe requests for 
improvement in such a way. <https://yourlogicalfallacyis.com/strawman>

/a

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 May 2017 21:45:09 +0200

Ho

> improvement in such a way. <https://yourlogicalfallacyis.com/strawman>

What is disingenuous is reviewing a document to death, requiring
consensus on people's expressed concerns, and then claiming, “oh no,
we're not stopping publication”.

Eliot

---

From: Randy Bush <[email-masked]>
Date: Sat, 06 May 2017 08:45:19 +0900

> consensus on people's expressed concerns

aside from the hyperbole, i think this is what we're supposed to be
doing

> then claiming, “oh no, we're not stopping publication”.

puhleeze.

there seems to be some useful disagreemet here; and it would help if we
focused on it and tried to work it through until we can get consensus.

< stating what might be obvious >

as i read it, a fair number of folk (i among them) think that a number
of practices described neutrally in the document should be flagged as
negative.

the reason this is an important distinction is that if and when we get
downstream to writing documents more in the solution space, the
behaviors marked as negtive do not need to be spported.  e.g. some see
encryption preventing http header insertion as a feature, not a bug.

and it is ok to have this discussion.

randy