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 <mnot(_at_)mnot(_dot_)net>
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/