Effects of Pervasive Encryption on Operators
draft-mm-wg-effect-encrypt-25

Thanks for all the work that has gone into this document. The framing and tone
is much improved over -10, and the reorganization of section 7 into the rest
of the document helps a lot. I do have a handful of comments. In particular,
I think the omission in section 2.3.4 is very important; however, I
wanted to clear my discuss and trust the sponsoring AD to do the right thing
here rather than re-issuing a different discuss position.

---------------------------------------------------------------------------

§2.1.2 -- I am surprised that there is so much discussion of fields that are
not generally encrypted in practice (e.g., RTP headers, TCP headers). It may
be worth distinguishing between session-layer, transport-layer and
network-layer security.

(I think I mentioned this in my initial review, and saw neither a response nor a
document change in reaction to it.)

---------------------------------------------------------------------------

§2.2.3 -- This section reads like a set of unfinished "notes to self" for the
authors' later use. Minimally, I would suggest restructuring the sentence
fragments in this section into sentences. I will also note that section 2
indicates that the following sections will discuss both (a) purpose of the
technique, and (b) fields used to achieve this purpose. This section appears
to lack the latter.

---------------------------------------------------------------------------

§2.2.5:

>   For example, network caching of popular content at a
>   location close to the requesting user can improve delivery efficiency
>   (both in terms of lower request response times and reduced use of
>   International Internet links when content is remotely located), and
>   authorized parties acting on their behalf use DPI in combination with
>   content distribution networks to determine if they can intervene
>   effectively.  Caching was first supported in [RFC1945] and continued
>   in the recent update of "Hypertext Transfer Protocol (HTTP/1.1):
>   Caching" in [RFC7234].

The transition from the general case of caching to the specific case of HTTP
proxy caching (and the subsequent change back to the general case) seems
rather abrupt. Consider splitting the HTTP proxy caching out into a separate
paragraph.

---------------------------------------------------------------------------

§2.2.5:

>   The Enhanced Multimedia Broadcast/
>   Multicast Services (3GPP eMBMS) - trusted edge proxies facilitate
>   delivering same stream to different users, using either unicast or
>   multicast depending on channel conditions to the user.

This passage also reads like outline notes rather than a finished document.

---------------------------------------------------------------------------

§2.2.5:

>   preserving end-to-end security: AMT, for instance, allows CDNs to

Please expand "AMT".

---------------------------------------------------------------------------

§2.2.7:

>    A goal is protecting end-user
>    data -- but at the same time not making the network inoperable or
>    unmanageable.

I fear this sentence falls back to the hyperbolic tone that plagued version
-10 of this document. I suggest something more along the lines of "...not
forcing changes to the way networks have historically been operated and
managed" or something similar.

---------------------------------------------------------------------------

§2.3.2:

>   The customer may need
>   call customer care to find out the reason, both an inconvenience
>   to the customer and additional overhead to the mobile network service
>   provider.

I believe this is false. Please remove this assertion or support it with a
citation.

To my knowledge, standard operating procedure for mobile networks (based on my
personal experience on two different post-paid US carriers and probably half a
dozen pre-paid non-US carriers) is that users are sent an SMS message
explaining the situation. I think the statement above overstates the
inconvenience to both users and operators, and consequently runs the risk of
causing protocol designers to evaluate the impact incorrectly.

---------------------------------------------------------------------------

§2.3.4:

>   Third parties use
>   the inserted information for analytics, customization, advertising,
>   to bill the customer, or to selectively allow or block content.

This is much improved over the previous formulation, but it leaves out a simple
factual statement that is highly relevant when designers are evaluating the
impact of encryption on this behavior. In fact, I would argue that it leaves
out the *most* notable use of these headers: cross-site user tracking. I
suggest amending the list to something like:

    Third parties use the inserted information for analytics, customization,
    advertising, cross-site tracking of users, to bill the customer, or to
    selectively allow or block content.

---------------------------------------------------------------------------

§3.3:

>   encryption approach described below.  In most cases, solution have
>   been identified to provide encryption while ensuring management

Nit: "...solutions have..."


---------------------------------------------------------------------------
§3.2.2 and §5.1:

Nit: s/SPAM/spam/g

This document is not perfect, but I found it to be generally useful. This version is much improved.

When you talk about logging, maybe mentioning "protocol trace logging" or "PDU logging" as a useful tool for troubleshooting that can be provided by both client and server endpoints?

DMARC (RFC 7489) should probably be mentioned in Section 5.1 where you mention ARF.

This is a considerably better document than the previous versions I have reviewed. Thanks for all that work. But of course, I still have some comments :-)

Substantive Comments:

-2.2.2, 2nd paragraph: "... for example, many
   forms of communications (from isochronous/real-time to bulk/elastic
   file transfer) will take place over HTTP port 80 or port 443, so only
   the messages and higher-layer data will make application
   differentiation possible."

I'm confused about the use of port 443 in that sentence; presumably traffic to 443 will be encrypted and not allow differentiation using higher-layer data.

-2.2.4: This section lacks a discussion of the impact of encryption.

-2.2.5, last paragraph: I understand that techniques that require endpoint cooperation might be out of scope, but the tone of this paragraph makes it sound like requiring endpoint cooperation is a negative. Is that the intent?

-2.3, section title: The title is only partially evocative of the section content. I suggest adding "content filtering".

-2.3.1: I think it might be worth mentioning that an "intercepting certificate" requires endpoints to be configured to trust that certificate. (I assume we are not talking about the more unsavory practice of certificates that misrepresent their subjects.

-2.3.4 I concur with Adam that this section should explicitly mention "cross-site user tracking" as one of the common motivations for header insertion/enrichment. I think it should also include a mention of RFC 8165.  

-5.2: This section doesn't seem to include discussion of the impact of encryption.

Editorial and nits:

-IDNits finds a number of unused references, and a few other reference issues. Please check.

- Abstract: 2nd sentence is hard to parse, and ends with a comma splice.

- 1, 2nd paragraph: " The following informational
   documents consider the end to end (e2e) architectural principle, a
   guiding principle for the development of Internet protocols [RFC2775]
   [RFC3724] [RFC7754]."

Is the comma correct? It currently reads along the lines of "The documents consider the e2e principle, and we think that it is a guiding principle...", but I think you might mean "The documents consider the e2e to be a guiding principle..."

-1, 3rd paragraph: "... (including methods for network
   endpoints where applicable)..."
Should that say "methods that rely on network endpoints"?

-2.1.1: Please expand "CAIDA"

-2.1.1: Paragraph starting with "
   When using increased encryption, operators lose a source of data that
   may be used to debug user issues."
I don't think the operators are the ones using the encreased encryption in that sentence. Perhaps "When endpoints use increased encryption..." or even (When increased encryption is used..."

-2.1.3, 2nd paragraph: "The ability to examine layers and payloads
   above transport provides a new range of filtering opportunities at
   each layer in the clear. "
Should "new range" be "increased range"?

-2.1.3, third paragraph: The last sentence seems out of place. Is the point of the paragraph to point out that the use of these monitoring techniques for DoS mitigation can't be distinguished from the use of them for privacy violation?

-2.2.1: Please expand "QUIC" and add a citation.

-2.2.3, last sentence: Sentence fragment.

-2.2.4, first sentence: Comma splice.

-2.2.5, first paragraph: " Encryption of packet contents at a given
   protocol layer usually makes DPI processing of that layer and higher
   layers impossible. "

This sentence seems misplaced; the section is not about DPI.

-- same paragraph: I don't understand the point(s) of the last two sentences.

-2.2.5, third paragraph: "The Enhanced Multimedia Broadcast/
   Multicast Services (3GPP eMBMS) - trusted edge proxies facilitate
   delivering same stream to different users, using either unicast or
   multicast depending on channel conditions to the user. "

I can't parse that sentence.

-2.3.3: Please make the "SHOULD" lower case. Since this document does not use RFC 2119/8174 keywords, a capitalized SHOULD should not appear outside of a literal quote.

-3: "Businesses understanding the
   threats of monitoring in hosted environments only increased that
   pressure to provide more secure access and session encryption"

Why "only"? That seems to suggest one would expect some different result.

-3.1.2: This section is about Hosting SPs, but the last two paragraphs seem to be about ASPs. While I realize those may sometimes be the same organization, they are architecturally distinct.

-3.2.2: "STARTTLS ought have zero effect..."
"Ought to have zero effect" or "has little effect"?  (If the former, it's safe to say "should" since this draft does not use RFC 2119 keywords.)

-3.2.2, last paragraph: Should "SPAM filtering" be "content-based SPAM filtering"?

-4.2: What does it mean for tools to "use" keywords? Does this mean "search for" or "monitor for" keywords?

-5.4: This seems to say that "Detection and Mitigations" involves thousands of hosts, etc. I think the point is that the botnets themselves may involve thousands of hosts..."

-7 and subsections: It looks like the editing of this section is not finished; several sections indicate they are to be deleted. 

-7.4: Please describe what you mean by "transit proxies". 

I can't parse item 4. The entire section could use proofreading for missing articles.

-12: Are there really no normative references? The definition of a "normative reference" is any reference needed to fully implement or _understand_ the document. This is true for both informational and standards-track documents. Do you think a reader can fully understand this document if they ignore every reference?  (I'm willing to accept that the answer might be "yes" given the nature of this draft--but that situation is rare in practice.)

Thanks for handling my other comments, the abstract and intro for setting
context are much improved. I found some sections still though need some
neutrality/tweaking, others have already provided detailed comments.

For me, section 8 as the "way forward" is especially weak and confusing. As the
last section of a very detailed, lengthy document, a more concise,
stronger summary is needed on the purpose of the document.

"Changes to improve encryption or to deploy OS methods have little
   impact on the detection of malicious actors; they already have access
   to strong encryption."

And the last two sentences cast a foreboding outlook:
"..but make passive monitoring broadly cost
   prohibitive.  This is meant to restrict monitoring to sessions where
   there is reason to have suspicion."

The End for this 40-page story?

I hesitate to register concern here  and I don't think the sky will fall if this is published but I the taxonomy insufficiently nuanced in a few areas of areas for me to consider this document as offering guidance. primarily

The section on load balancing devices is essentially a caricature of broad field of  devices that cover all sorts of variation from ethernet switches all the way up to ssl termination.

Likewise content filtering covers a whole range of different approaches, actors and goals. whereas here we have the higly condensed version. 

I

Really thanks a lot for all the work on this document! I changed my position from discuss to no objection with these edits now because I think there are still things that could be improved to make the document more useful. However, I also think that it is important to publish this document soonish and I don't think any additional delay would help the message significantly.

-------------------------------
Old comment for the record: 
-------------------------------

I would be a 'Yes' because I think this document is very valuable, however, I think it could be structured better to provide more value. The document is rather long and has some redundancy due to the structure: while sections 2.-4. are split based on the type of network operator, sections 5. and 6. are split based on the protocol layer. Further I think section 2 could be further extended because there are more cases to cover, also see (section 3 of) https://tools.ietf.org/html/draft-dolson-plus-middlebox-benefits-03. See for more concrete and mostly editorial comments below:

1) sec 2.1.1: "The definition of a flow will be based on a
   combination of header fields, often as many as five for 5-tuple flows
  (including addresses and ports for source and destination, and one
   additional field such as the DSCP or other priority marking)."
Usually the 5th field is the protocol number; I'm not aware of any load balancers that look at DSCP...?

2) sec 2.1.4 seems to cover two different cases: caching and differential treatment

3) sec 2.1.6. should probably be called "Content Filtering" and "Mobility Middlebox Content Filtering" should be an own subsection, as parental filtering is not specific to mobile networks.

4) I don't really understand why sec 2.1.7 "Access and Policy Enforcement" is a subsection of 2.1 "Middlebox Monitoring". Was that on purpose or an error? Actually I don't really understand the structure of section 2 at all. What's the difference between 2.1 and 2.2? I would group section 2.1.1, 2.1.2, and 2.1.3 under Traffic Monitoring and move all other subsections of 2.1 one level up...

5) sec 3 rather describes how encryption is already used and doesn't not really discuss any effects of increased use of encryption.

6) there is quite some overlap between section 2 and 4.1.3. as the problems on monitoring/troubleshoot are the same for enterprise network and other networks; the only difference is that in enterprises TLS interception may be acceptable while it's not for network operators. However, it would still be good to better align these sections.

7) section 6 only describes with information is visible but not how and if this information is used and what would happen if this information would go away.

8) section 7 should be integrated in the introduction because it sets the context for this document and it's not needed to have read the rest of the document to understand this section.

* Section 2

This text is a bit confusing. Who does the second "providers" refer to? The application service providers or the network service providers? If it is the latter the examples seem to be off. If it is the former, I am not sure this is relevant in this section.

   Following the Snowden revelations, application service providers
   responded by encrypting traffic between their data centers to prevent
   passive monitoring from taking place unbeknownst to the providers
   (Yahoo, Google, etc.).

* Section 2.1.4.

This text below is not entirely true. There are other mechanisms by which the user traffic can be separated without DPI (e.g. dedicated bearers have existed for a very long time to separate traffic). 

   "Ideally, the
   scheduler manages the queue so that each user has an acceptable
   experience as conditions vary, but the traffic type has been required
   to be known to date."

* Section 2.1.7.2

Since there is some sort of prior arrangement for this zero rating can't this be done by getting a list of IP addresses?

* Section 3.2.1.

Wouldn't server side logs and/or 5 tuple be enough to make these metrics work especially for managed applications (e.g. correlate managed application to ip address and port and then use 5 tuple on packet)?

* Section 4.1.1.

In at least some of the enterprises I have seen, the security enforcement is seen at the endpoints for the company owned devices. There are also new endpoint security solutions being enforced in BYOD environments (e.g. VMware Airwatch). This section seems to gloss over the fact.

* Section 5.6.

The SLAAC reference is wrong. Must be RFC4862 instead of RFC4682.
The SEND reference is wrong. Must be RFC3971 instead of RFC3791.

* Section 11

This section seems to be a grab bag of claims some of which seem to be dodgy. e.g. the ANDSF claim in Section 11.2. The ANDSF assists the UE (the endpoint) and provides rules to the endpoint. It is unclear how transport encryption will affect these rules.

No Objection, however I fully support the words in Alissa's DISCUSS and they should be given extensive consideration