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

[Ballot comment]
I appreciate all the work that the authors have put into this document, and I think it makes a number of good points. However, at the end of the day, I don't think publishing an IETF RFC devoted to listing all the problems that encryption creates -- even with a bunch of disclaimers -- is consistent with the direction the IETF is otherwise taking towards universal encryption.

[Ballot comment]
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.

[Ballot comment]
Thank you for this important OPS/SEC document, which has improved lately.

I do NOT read this document as: encryption makes live harder for operators, so we should not do encryption.
I read this document as: encryption makes live harder for operators and we should find different ways to manage networks, if possible.
The point is not to do a value judgment on the "management" function (ex: HTTP header insertion)Thanks for this improved doc.
For me, the key document aspects are:

  The goal is to help inform future protocol development to
  ensure that operational impact is part of the conversation.  Perhaps,
  new methods could be developed to accomplish some of the goals of
  current practices despite changes in the extent to which cleartext
  will be available to network operators (including methods for network
  endpoints where applicable).

  ...

  This document
  lists a collection of functions currently employed by network
  operators that may be impacted by the shift to increased use of
  encryption.  This draft does not attempt to specify responses or
  solutions to these impacts, but rather documents the current state.

[Ballot comment]
Many thanks for all the effort that has gone in to addressing all the comments from the last IESG review and from the community. I find this version to be much improved from the last time the IESG reviewed it.

However, I do not feel that I can support the publication of the document. While the tone has improved in many places and the introduction does a better job of contextualizing the document, the document still contains text in several sections that states service providers' claims about their practices as facts rather than stating them as claims or presenting the practices in a neutral way. This was a point raised in my previous DISCUSS (I've included my previous DISCUSS ballot text below in full for reference). In the previous review round Warren had invited recommendations for places where the tone or choice of words could be made more neutral or balanced, and I provided many detailed suggestions, but a number of those were not adopted. I also realize that the introduction contains much of the disclaimer text we previously hashed out to try to address this, but it doesn't contain all of it. So this is still a major issue for the document, IMO.

The document also still extemporizes about future possible impacts, making it hard to come away with a neutral view of their treatment, as I noted in my previous DISCUSS ballot.

I support the DISCUSS position held by Ekr. But given the above I don't think it will be fruitful for me to continue to engage on the details of this document, so I'm abstaining.

I've included below some of the areas that I still find problematic, as well as some nits.

Problematic areas:

= Section 2.1.2 =

(1)
"Network operators are often the first ones called upon to investigate
  application problems"

I still contend that without data to back this up, this claim should not be made, especially for the enterprise context.

(2)
"Vendors must be aware that in order for operators to better
  troubleshoot and manage networks with increasing amounts of encrypted
  traffic, built-in diagnostics and serviceability must be enhanced to
  provide detailed logging and debugging capabilities that, when
  possible, can reveal cleartext network parameters."

If I try to paraphrase this it sounds like "vendors should build in capabilities to decrypt encrypted traffic." Was that the intent?

= Section 2.2.4 =

I agree with Christian Huitema's unresolved comments on this section. In the thread regarding his comments Kathleen said "we don't want to make general statements that aren't necessarily true" -- IMO that is what the middle three paragraphs in this section are doing. At a minimum, I think the characterizations about the effects of performance-enhancing proxies needs to be qualified by saying "some operators find that ..." rather than stating their effects as fact.

= Section 2.2.7 =

"There is work in progress to specify protocols that permit Service
  Function Chaining (SFC)."

I don't think it makes sense to have this forward-looking statement when Section 1 states that "This document describes practices currently used by network operators to manage, operate, and secure their networks." I think it makes sense to focus this section on how existing SFC deployments have stopped functioning because of increased use of encrypted traffic, but it seems unfair to claim that some future, yet-to-deployed functionality will be broken.

= Section 2.3.2 =

"As a
  result, some mobile carriers block customer's encrypted requests,
  which is a far less optimal customer experience because the blocking
  reason must be conveyed by some other means."

This could easily be read to imply that sending requests in cleartext is optimal.

Overall, the use of the words "usual," "optimal," and "often" in this section imply a level of generality that is unwarranted I think.

= Section 5.6 =

The implications for SAVI seem speculative unless you can point to SAVI deployments that have been impacted by increased use of encryption.

Nits:

= Abstract =

s/Pervasive Monitoring (PM) attacks on the privacy of Internet users is
  of serious concern/Pervasive Monitoring (PM) attacks on the privacy of Internet users are of serious concern/

= Section 2.1.2 =

(1)
"Further, the performance of some services can be more efficiently
  managed and repaired when information on user transactions is
  available to the service provider.  It may be possible to continue
  such monitoring activities without clear text access to the
  application layers of interest ..."

It's not clear what "such monitoring" refers to, since the previous sentence is about performance management and service repair.

(2)
Is "User/Service Key Quality Indicators" a term of art? It seems weird to be capitalized.

= Section 2.2.3 =

This section seems like it was left in the document by mistake.

= Section 2.3 =

"As previously stated, the intent of this document is to
  document existing practices, the development of IETF protocols
  follows the guiding principles of [RFC1984] and [RFC2804]."

Is that comma supposed to be a period? I'm not following the grammar here.

= Section 2.3.1 =

s/However, the lack of ability to efficiently manage
  endpoints as a service reduces providers' ability to offer parental
  control./However, the lack of ability to efficiently manage
  endpoints as a service reduces network service providers' ability to offer parental
  control./

= Section 4.1.2 =

It seems like a single reference to RFC 8250 would suffice.

= Section 7.4 =

What is a trusted transit proxy?

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

Previous DISCUSS ballot text:

I have cleared my original DISCUSS point from my earlier review -- I get what the text is saying now, although I still think the "lose the option" language implies some entitlement to the option in the first place, which seems inappropriate.

But given the reviews from Martin Thomson and Christian Huitema, it's not clear to me that this document represents the consensus view of the IETF community. Kathleen's response to Martin reinforces the point that we were discussing in the first ballot cycle, which is that this document is written for and represents operators, not the broader array of Internet interests. Yet the suggestion to state that fact up front in the document was not adopted.

Having had some more time to review this document than I had in the previous ballot cycle, I also am finding myself in agreement with significant portions of the reviews from Martin and Christian. Reading their reviews helped crystallize a lot of the difficulty I had in parsing this document the first time around.

I understand the rationale that led to this document being written and I think there is a version of this document that could be written that would achieve the original goals while giving the subject matter a readable, neutral treatment. Such a version would be a useful contribution. But I don't think this document achieves that. In particular, there are four things that I think it would need to do to achieve that:

1. State the analysis in a neutral way. As I had mentioned in one of the email threads for the previous ballot cycle, I believe this document could be written in a neutral way -- e.g., “Service providers currently do X. It is implemented using Y mechanism. Encryption at Z layer breaks current implementations.” -- but it is not. Instead it characterizes many of the practices described as "optimizations" or "features" or "enrichment" and states service providers' claims about what these practices accomplish (e.g., "maximize QOE") as facts rather than stating them as the reasons given by service providers for why they engage in the practices. This is why in the previous round I suggested the disclaimer at the top of the document to say that the document is giving a view from service providers; that apparently didn't go anywhere, so the other option is to describe each technique neutrally, or explain with each technique that the characterization of the benefits is from the view of the operator. Martin's comments about being clear about who is benefitting point this out as well.

2. Limit the discussion to techniques presently being affected and those effects. There is a bunch of extemporizing about future possible impacts (e.g., in Sec. 2.7, 4.1.2, 4.1.3.1, 5.7, 7, 8). It's very hard to characterize future implications, who will bear the "cost" for what, whether increases in user complaints to various parties are "worth it," etc., in a way that is perceived as neutral by all affected parties. Better not to make predictions if the goal is to give a neutral treatment of network functions being impacted today.

3. Acknowledge the controversy. Many of the practices described in this document are controversial, and have been for a long time. There is nothing wrong with that. I agree with Christian that it would be better to state an understanding of that head-on rather than leave it to the reader to decide whether any particular characterization of something described implies an endorsement of it. This has been done before, even in potentially controversial documents that this document references, e.g. RFC 3135.

4. Structure the document in a way that is consistent and logical with minimal repetition. It seems like there are multiple ways that this could be done. Organizing based on use case (per Christian) and then discussing techniques used within each use case is one way; organizing based on technique while mentioning the goals for which each technique is employed is another. At present the document is jumble of these.

[Ballot discuss]
I have completely re-reviewed the latest version. First, I want to
thank you for toning down some of the material that I was concerned
about.

Unfortunately, the fundamental concern that motivated my DISCUSS
remains: I do not believe that this document matches the consensus
of the IETF community.

Specifically, this document takes at face value a large number of
claims about the necessity/value of certain practices that either are
controversial within the IETF or that there is, I believe, rough
consensus to be actively bad, and that in many cases, encryption is
specifically designed to prevent. I have noted a number of these
below, but I do not believe that this is an exhaustive list (going
through my previous DISCUSS, I see that I noted a number of these but
that still appear to be unaddressed.)


DISCUSS
  session encryption that deployed more easily instead of no
  encryption.
 
I think I understand what you are saying here, but the term
"breakable" seems very unfortunate, especially in the context of this
document. The only such shift I am aware of that has received
acceptance in IETF is one from always requiring fully authenticated
encryption to allowing unauthenticated encryption, which you document
in the next paragraph. I recognize that there are other perspectives
(e.g., those in draft-rhrd) but those are pretty far from IETF
consenus. Accordingly, I think you should remove this sentence.


  motivation outside of privacy and pervasive monitoring that are
  driving end-to-end encryption for these content providers.
 
This section seems kind of confusing, at least as applied to
HTTP. There are three kinds of cache in HTTP:

- Reverse proxy caches (the kind CDNs run)
- Explicit forward proxy caches
- "Transparent" intercepting caches

The first of these move to HTTPS just fine and that's typically how
CDNs do it.  Explicit forward proxy caches are largely going away, but
part of the point of this kind of end-to-end encryption is to hide
data from those caches.  Transparent intercepting caches that the user
didn't opt into are a bad thing, so having them go away is a positive.

  document existing practices, the development of IETF protocols
  follows the guiding principles of [RFC1984] and [RFC2804].
 
This is pretty opaque in this context. It should explicitly state that
the IETF's position is that we do not engineer for these use cases,
not just to cite the RFCs.


  based billing, or for other reasons, possibly considered
  inappropriate by some.  See RFC7754 [RFC7754] for a survey of
  Internet filtering techniques and motivations.  This section is

I don't think this accurately represents the RFC, which makes clear
that the IAB consensus is that filtering is bad:

" From a technical perspective, there are no perfect or even good
solutions -- there is only least bad.  On that front, we posit that a
hybrid approach that combines endpoint-based filtering with network
filtering may prove least damaging.  An endpoint may choose to
participate in a filtering regime in exchange for the network
providing broader unfiltered access."


  detect or prevent attacks as well as to guarantee service level
  expectations.  In some cases, alternate options are available when
  encryption is in use, but techniques like that of data leakage
 
These certainly are use cases, but you really need to acknowledge that
it's also a form of user surveillance.


  Some DLP tools intercept traffic at the Internet gateway or proxy
  services with the ability to man-in-the-middle (MiTM) encrypted
  session traffic (HTTP/TLS).  These tools may use key words important
  to the enterprise including business sensitive information such as
  trade secrets, financial data, personally identifiable information
  (PII), or personal health information (PHI).  Various techniques are
  used to intercept HTTP/TLS sessions for DLP and other purposes, and
  are described in "Summarizing Known Attacks on TLS and DTLS"
  [RFC7457].

As far as I know, the MITM techniques used by middleboxes are not
described in 7457.

You also need to cover the fact that these MITM are a threat to user
security because they are often so badly implemented.


S 5.4.
It's pretty odd to talk about phishing without acknowledging that by
far the largest anti-phishing platform (Safe Browsing) operates in the
client, not be network interception.


    The transport header encryption prevents trusted transit proxies.  It
  may be that the benefits of such proxies could be achieved by end to
 
You don't define a "trusted transit proxy" so I don't know what this
means, and whether they provide any benefit, but this certainly sounds
euphemistic. Generally, "trusted" is not an adjective we associate
with network proxies operated by third parties.


  In the best case scenario, engineers and other innovators would work
  to solve the problems at hand in new ways rather than prevent the use
  of encryption.  As stated in [RFC7258], "an appropriate balance
  (between network management and PM mitigations) will emerge over time
  as real instances of this tension are considered."

Much of the context of this debate is about whether operators not
being able to do the things in this document is a problem, and this
seems to presume the answer.


  This optimization at network edges measurably improves real-time
  transmission over long delay Internet paths or networks with large
 
Do you have a citation for this claim?


  Web proxies are sometimes used to filter traffic, allowing only
  access to well-known sites found to be legitimate and free of malware
  on last check by a proxy service company.  This type of restriction
  is usually not noticeable in a corporate setting as the typical
  corporate user does not access sites that are not well-known to these
  tools, but may be noticeable to those in research who are unable to
  access colleague's individual sites or new web sites that have not
  yet been screened.  In situations where new sites are required for
  access, they can typically be added after notification by the user or
  proxy log alerts and review.  Home mail account access may be blocked
  in corporate settings to prevent another vector for malware to enter
  as well as for intellectual property to leak out of the network.
  This method remains functional with increased use of encryption and
  may be more effective at preventing malware from entering the
  network.  Web proxy solutions monitor and potentially restrict access
  based on the destination URL or the DNS name.  A complete URL may be
  used in cases where access restrictions vary for content on a
  particular site or for the sites hosted on a particular server.

If you are filtering on URL and there is HTTPS involved, then you are
a MITM, and this is potentially noticeable to end-users. We encounter
this regularly when MITM proxies make mistakes in getting into our
trust anchor store.


Re: 0-rating.
  user.  This feature is impacted if encryption hides the details of
  the content domain from the network.
 
Well, maybe. Facebook's zero rating, for instance, is IP-based.
https://info.internet.org/en/blog/2015/09/24/enhancing-security-and-privacy-of-free-basics/

S 2.2.2.
The presentation here seems biased given that it does not acknowledge
that one of the reasons that ISPs do traffic class discrimination is
to prioritize favored rather than disfavored traffic, regardless of
user preferences. I don't believe that the IETF has taken a position
for net neutrality, but I'm also pretty sure we don't have consensus
against it.

[Ballot comment]
  Pervasive Monitoring (PM) attacks on the privacy of Internet users is
  of serious concern to both the user and the operator communities.
are of serious concern



  Traditional network management, planning, security operations, and
  performance optimization have been developed in an Internet where a
  large majority of data traffic flows without encryption.  While
you have a plural/singular mismatch here.


  Authentication with IPsec [RFC7619] and there are a number of
  infrastructure use cases such as server to server encryption, where
  this mode is deployed.  While OS is helpful in reducing pervassive
Nit, no comma before "where"



  recommendations from these documents were were built upon for TLS 1.3
  to provide a more inherently secure end-to-end protocol.
"were were"



  to-user content encryption schemes, such as S/MIME and PGP for email
  and encryption (e.g.  Off-the-Record (OTR)) for XMPP are used by
  those interested to protect their data as it crosses intermediary
Not, "e.g.,"



  been impacted by increases in encrypted traffic.  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.
I don't understand what the normative content of this was.




  upgrades before user experience declines.  For example, findings of
  loss and jitter in VoIP traffic can be a predictor of future customer
  dissatisfaction (supported by metadata from the RTP/RTCP protocol )
  [RFC3550], or increases in DNS response time can generally make
  interactive web browsing appear sluggish.  But to detect such
  problems, the application or service stream must first be
  distinguished from others.

This is a little hard to read, but generally this information is not
encrypted for SRTP/SRTCP.


  When using increased encryption, operators lose a source of data that
  may be used to debug user issues.  Because of this, application
  server operators using increased encryption might be called upon more
  frequently to assist with debugging and troubleshooting, and thus may
  want to consider what tools can be put in the hands of their clients
  or network operators.
 
This is phrased as hypothetical, but is there any actual data to
support this? We have a lot of experience now with encrypted voice and
video as well as Web. Do those providers report any increased level of requests.



  the new flow and would not be able to route it back to the original
  POP.
 
I'm having a little trouble understanding this paragraph. Why is this
about mobile operators? It seems like it's an issue for anyone who has
a service that might have mobile clients.






  effective at providing data offload when there is a network element
  close to the receiver that has access to see all the content.
This section is also confusing in that it fails to distinguish between proxies of this
type that the user opts into from transparent proxies that just do this service
without the user's consent. Part of the purpose of encryption is to preclude that.





  created from the intercepting device to the client's destination,
  this is an opt-in strategy for the client.  Changes to TLSv1.3 do not
  impact this more invasive method of interception, where this has the
I don't understand the cite to TLS 1.3 here. None of this is presently affected by 1.3.



  endpoints as a service reduces providers' ability to offer parental
  control.
This section makes it seem like there are no other methods that allow for parental control, but that's not true. There are parental control mechanisms which rely on MITM proxies or application interfacing.



  HTTP headers and content are encrypted, this prevents mobile carriers
  from intercepting the traffic and performing an HTTP redirect.  As a
  result, some mobile carriers block customer's encrypted requests,
Yes, stopping traffic redirection is actually one of the major design purposes of HTTPS.



  to the customer and additional overhead to the mobile network service
  provider.
This section is basically a commercial for this practice. It needs to acknowledge that it's actually much closer to IETF consensus that it's a bad practice.





  headers to accomplish the, sometimes considered controversial,
  functions above.
Again, this is precisely the form of attack that HTTPS is intended to prevent.



  perform SSL/TLS decryption are impacted by the increased use of
  encryption that prevents interception.
I don't really understand what this text means. What is "use of encryption that prevents interception" in the context of tools which already do decryption?



  [DarkMail].  Of course, SPAM filtering will not be possible on
  encrypted content.
This is not strictly correct, as you can still header filter, etc.



  over the Internet.  Options for monitoring will vary with each
  encryption approach described below.  In most cases, solution have
  been identified to provide encryption while ensuring management
Nit: "solutions have"



  allow for multiple end user sessions to share the same TCP
  connection.  This rasises several points of interest with an
  increased use of encryption.  TCP session multiplexing should still
Typos: rasises



  be possible when TLS or TCPcrypt is in use since the TCP header
  information is exposed leaving the 5-tuple accessible.  The use TCP
  session multiplexing of an IP layer encyption, e.g.  IPsec, that only
I'm not sure if this is correct. What precisely do you mean by "TCP
session multiplexing"? A cite would be helpful here.



  center.  HTTP pipelining requires both the client and server to
  participate; visibilty of packets once encrypted will hide the use of
  HTTP pipelining for any monitoring that takes place outside of the
Typo: visibility





  traffic cannot be intercepted, encouraging alternate options such as
  performing these functions at the edge.
I'm not seeing the relevance of this. Who is proposing solutions in which encrypted traffic cannot be intercepted at the outgoing network edge.






  owing to concealment of critical headers and payloads.  Many forms of
  enterprise performance management may be similarly affected.
Again, this is sort of transparent caching is an anti-pattern, so this document ought to acknowledge that,



  parts of the address assignment/management protocols, critical for
  SAVI mechanisms, can result in a dysfunction of the SAVI mechanisms.
Does anyone actually deploy SAVI? If not, encryption isn't having much of an impact.



  network filters look out for seeing a Server Name Indication
  extension, they may not find one.  The SNI Encryption in TLS Through
  Tunneling [I-D.ietf-tls-sni-encryption] draft has been adopted by the
This doesn't really follow. I mean they "may not" but overwhelmingly they will

[Ballot comment]
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?

[Ballot comment]
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.)

[Ballot comment]
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

[Ballot comment]
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.

=== 1. Summary ===

This Informational document is a fairly extensive collection of security and network management functions that will likely be impacted by the increased use of encryption. Note that this document is a list of issues; there is no attempt to ameliorate the problems in the list. It is meant to help those who are attempting to create solutions to the problem by giving a taxonomy of problems and a list of useful references, as well as to point out where there is significant disagreement in the technical community about particular tradeoffs.

Paul Hoffman is the document shepherd; Warren Kumari is the responsible AD.

=== 2. Review and Consensus ===

This is an AD-sponsored document. It was discussed in SAAG, both on the mailing list and in at least one face-to-face meeting (IETF 97). The list discussion was not heavy, but there was clearly enough inputs to the authors to see a reasonable amount of improvement between the recent drafts. There was a "pre-IETF-last-call" discussion on SAAG that proposed changes, and the authors made those. There were two IETF-wide last calls, and a set of IESG balloting, all of which generated many more updates, particularly to highlight points where there is disagreement.

=== 3. Intellectual Property ===

Both authors have disclaimed any knowledge of IPR issues with this document.

=== 4. Other Points ===

Documents of this type (taxonomies and reference lists that can be used by others who are crafting solutions to problems) have been useful in earlier IETF work, and this document is likely to be a significant help to the security community. Many places in this document describe disagreements in the security community, and that too might be valuable for future protocol developers.

=== 1. Summary ===

This Informational document is a fairly extensive collection of security and network management functions that will likely be impacted by the increased use of encryption. Note that this document is a list of issues; there is no attempt to ameliorate the problems in the list. It is meant to help those who are attempting to create solutions to the problem by giving a taxonomy of problems and a list of useful references, as well as to point out where there is significant disagreement in the technical community about particular tradeoffs.

Paul Hoffman is the document shepherd; Warren Kumari is the responsible AD.

=== 2. Review and Consensus ===

This is an AD-sponsored document. It was discussed in SAAG, both on the mailing list and in at least one face-to-face meeting (IETF 97). The list discussion was not heavy, but there was clearly enough inputs to the authors to see a reasonable amount of improvement between the recent drafts. There was a "pre-IETF-last-call" discussion on SAAG that proposed changes, and the authors made those. There were two IETF-wide last calls, and a set of IESG balloting, both of which generated many more updates, particularly to highlight points where there is disagreement.

=== 3. Intellectual Property ===

Both authors have disclaimed any knowledge of IPR issues with this document.

=== 4. Other Points ===

Documents of this type (taxonomies and reference lists that can be used by others who are crafting solutions to problems) have been useful in earlier IETF work, and this document is likely to be a significant help to the security community. Many places in this document describe disagreements in the security community, and that too might be valuable for future protocol developers.

=== 1. Summary ===

This Informational document is a fairly extensive collection of security and network management functions that will likely be impacted by the increased use of encryption. Note that this document is a list of issues; there is no attempt to ameliorate the problems in the list. It is meant to help those who are attempting to create solutions to the problem by giving a taxonomy of problems and a list of useful references, as well as to point out where there is significant disagreement in the technical community about particular tradeoffs.

Paul Hoffman is the document shepherd; Warren Kumari is the responsible AD.

=== 2. Review and Consensus ===

This is an AD-sponsored document. It was discussed in SAAG, both on the mailing list and in at least one face-to-face meeting (IETF 97). The list discussion was not heavy, but there was clearly enough inputs to the authors to see a reasonable amount of improvement between the recent drafts. There was a "pre-IETF-last-call" discussion on SAAG that proposed changes, and the authors made those. The IETF-wide last call started 2017-02-13, and the first set of IESG balloting, generated many more updates, particularly to highlight points where there is disagreement.

=== 3. Intellectual Property ===

Both authors have disclaimed any knowledge of IPR issues with this document.

=== 4. Other Points ===

Documents of this type (taxonomies and reference lists that can be used by others who are crafting solutions to problems) have been useful in earlier IETF work, and this document is likely to be a significant help to the security community. Many places in this document describe disagreements in the security community, and that too might be valuable for future protocol developers.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-mm-wg-effect-encrypt-13, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-12-04):

From: The IESG
To: IETF-Announce
CC: warren@kumari.net, Paul Hoffman , draft-mm-wg-effect-encrypt@ietf.org, paul.hoffman@vpnc.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Effect of Pervasive Encryption on Operators) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'Effect of Pervasive Encryption on Operators'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-12-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Pervasive Monitoring (PM) attacks on the privacy of Internet users is
  of serious concern to both the user and the operator communities.
  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ballot/


No IPR declarations have been submitted directly on this I-D.

[Ballot discuss]
- There are unresolved and substantive Last Call comments which the document does not address.

For example, I have a hard time reading "Not at all" as effectively addressing concerns that the document implicitly weakens the critically important principles that RFC 7258 lays down. While feedback to improve this specific situation has been solicited from Martin, it has been scantly more than a day since that request has been made. I don't think we're in a position to move the document forward with the current slate of unresolved Last Call comments.

- The IETF as a whole does not have consensus on the document.

For a document with such wide-reaching remit -- spanning network layers 3 through 7 -- the IETF-wide discussion has garnered an unclear mix of support and objection, and at fairly low volume (once we discount personnel directly involved in the progression of the document). If I count correctly, we have support for a document that fills this niche from Badri and Elliot, the most tepid statement of support I've seen in quite a while from Stuart (which itself concedes that the document diverges in tone and content from prior IETF statements on related topics), and rather strong statements of opposition from Martin and Christian. The objections by both Martin and Christian are substantive and structural; and many of the primary concerns they express appear to remain unresolved.

I understand the temptation to dismiss many of the objecting comments about structure and tone as editorial in nature; but this document lands squarely in the middle of a policy area in which the IETF (and the IAB in particular) has written extensively and carefully, in at least RFCs 1984, 2804, 7258, and 7754, among probably others that escape my notice at the moment; and this also includes IAB statements on the topic, such as . Due to this factor, I believe that obtaining IETF consensus on tone rather than merely technical content is warranted in this case.

____
Addendum: Some of the documents that "escape[d] my notice" above include RFCs 1958 and 3724 (and in particular sections 4.1.1 and 4.1.2 of the latter document).

[Ballot comment]
I share many of the concerns raised by Martin and Christian myself, in particular those that pertain to implicit endorsement of behaviors that other documents explicitly deprecate. I understand that the goal here is to be neutral in the way the document presents these topics (and I don't believe the current form achieves even that), but I believe that's the wrong goal.

To be clear, I don't want to pretend that these techniques don't exist in the wild, but I think the current formulation (and section 2 in particular) casts certain third-party entities as "victims of encryption"; when, in fact, most of these behaviors have been proscribed by IETF protocols and architecture documents for years. This is especially salient in light of the fact that such proscription has typically been precisely for the reason that these behaviors presume that traffic behavior can never evolve (e.g. that there will never be an increase in the use of encryption), and that behavior is now finally evolving.

The RFCs I cite in my discuss actually do stake out specific policy positions that pertain to overall Internet architecture; and, while I don't expect this document to necessarily reiterate all of them, it should at least be consistent with them.  In the context of the clear statements made by these policy documents, much of the text of the current document reads as an attempt to pussyfoot around sensibilities of entities who may not agree with established and published IETF consensus; but that should not be the goal (even if much of the target audience of this document includes such entities). We have published statements that many of the behaviors described in this document are *not* neutral, and attempting to *treat* them in a neutral fashion is explicitly going against that consensus. To be clear: yes, I am suggesting that description, in this document, of behaviors that are discouraged by the documents I cite above should be accompanied by clearer disclaimers that they are, and have historically been, considered by the IETF to be fundamentally detrimental.

I read some of the comments so far on this draft as wanting to revise the direction the IETF takes on these topics. That's a far broader conversation than pertains to this document; if we want to discuss that, I think we need to halt processing this document entirely and engage the IAB in a conversation around whether the aforementioned policy documents got it wrong.

_____

Some nuts and bolts of lesser consequence:

I think I've seen some messages about the potentially adversarial relationships that can arise in three- (or more) party communications, which is highly relevant; however, the document doesn't appear to have any treatment of this issue. In particular, I believe that the increased use of encryption may arise *because* of the behaviors being described, rather than despite them.

I agree with Ben's comment that the document suffers from explaining what is being done rather than why it is being done in some places. Ostensibly, a major part of the document's purpose is to foster discussion about how network operators can continue to manage their network in the face of encryption; but it will be difficult to discuss alternative approaches to meet their goals if those goals are not explained.

Section 2.3.2.1 mentions CDNs in a way that I find very confusing. Typically, CDNs are operated by or in cooperation with the entities providing authoritative content. Those entities are ostensibly both (a) the parties impacted by encryption, and (b) the parties choosing whether to use encryption. Clearly this can't be what you meant, since that reduces to a "doctor, it hurts when I do this" situation. I think a better description of the CDN scenario in this section is called for, if it is retained.

Section 2.4 describes "undesirable security practices" in generic terms. At least for browsers (the cited application), it's not clear to me precisely what kind of practices are being alluded to. Please add an example of one such practice.

In section 2.5.1, the statement mentioning "were contributed" has no context. I suspect an earlier document spoke of some process by which use cases were gathered from interested parties?

I think the scenario described in section 2.5.3 does not match the scope of this document (encryption). The problem being described is introduced by authentication of servers, not by encryption of content. I suggest either removing the scenario, or expanding the scope of the document to include problems introduced by authentication.

Section 2.6.1's assertions of a problem arising from encryption seem circular. It can be summarized as: the problem that arises from traffic being encrypted is that some traffic is not encrypted. This should be removed or clarified. This same tautology appears in section 3.1.

In section 2.6.5, the reference to non-CPNI data is using a really obscure and technically precise term, and really calls for a definition inline.

Section 2.7 discusses a number of problems that could arise from IP-level encryption, but which don't arise with the encryption that is commonly used on the Internet today. For example, analysis of TCP options, congestion window, etc. are not precluded by the use of TLS (as TCP information is sent in the clear); and the use of SRTP does not preclude analysis of VoIP traffic, as SRTP sends all the information used by DPI boxes in plaintext. As this document seems to be focusing on the practical effects of today's encryption deployment rather than the theoretical impacts of future widespread IPSEC deployment, these should probably be removed or heavily qualified. (n.b. -- I am not intimately familiar with the current level of IPSEC deployment in the Internet at large for typical large-scale consumer applications, and may be operating from an outdated view of its likely impact)

I'm not sure the mention of websockets in Section 2.7 is helpful: using HTTP for the types of operations cited has been a widely-used part of web browser behavior since the introduction of XMLHttpRequest over a decade ago. I think this would be improved if mention of Websockets were dropped entirely, and the paragraph were merely cast as the increase in use of port 443 for things other than simple web page retrieval.

Section 3.1.2 is very confusing -- it's muddy about which encryption here is desired by SPs, which encryption is posing novel challenges for them, and how they interact with each other. I think what's being described is a scenario in which an HTTPS connection is being terminated on a front end that can authenticate as the expected domain, decrypt the content, and then turn around and re-encrypt it. It's really not clear how this is impacted by the increased deployment of encryption, since the scenario only arises when encryption is required by the SP.

I'm not the expert here, but I think I've heard that there's some thinking around how to close the "SNI Hole," so it's probably relevant and useful to mention that this technique's days may be numbered as well.

Section 6.3 should probably mention the issues discussed in RFC 6562, including in particular the guidance in section 5 of that document. This issue may be true to some degree for video codecs as well, where the volume of encrypted data can be used to infer the amount of motion in a frame.

[Ballot discuss]
- There are unresolved and substantive Last Call comments which the document does not address.

For example, I have a hard time reading "Not at all" as effectively addressing concerns that the document implicitly weakens the critically important principles that RFC 7258 lays down. While feedback to improve this specific situation has been solicited from Martin, it has been scantly more than a day since that request has been made. I don't think we're in a position to move the document forward with the current slate of unresolved Last Call comments.

- The IETF as a whole does not have consensus on the document.

For a document with such wide-reaching remit -- spanning network layers 3 through 7 -- the IETF-wide discussion has garnered an unclear mix of support and objection, and at fairly low volume (once we discount personnel directly involved in the progression of the document). If I count correctly, we have support for a document that fills this niche from Badri and Elliot, the most tepid statement of support I've seen in quite a while from Stuart (which itself concedes that the document diverges in tone and content from prior IETF statements on related topics), and rather strong statements of opposition from Martin and Christian. The objections by both Martin and Christian are substantive and structural; and many of the primary concerns they express appear to remain unresolved.

I understand the temptation to dismiss many of the objecting comments about structure and tone as editorial in nature; but this document lands squarely in the middle of a policy area in which the IETF (and the IAB in particular) has written extensively and carefully, in at least RFCs 1984, 2804, 7258, and 7754, among probably others that escape my notice at the moment; and this also includes IAB statements on the topic, such as . Due to this factor, I believe that obtaining IETF consensus on tone rather than merely technical content is warranted in this case.

____
Addendum: Some of the documents that "escape[d] my notice" above include RFCs 1958 and 3274 (and in particular sections 4.1.1 and 4.1.2 of the latter document).

[Ballot comment]
Thank you for this OPS/SEC document. This is an important document.

I do NOT read this document as: encryption makes live harder for operators, so we should not do encryption.
I read this document as: encryption makes live harder for operators and we should find different ways to manage networks, if possible.

The point is not to do a value judgment on the "management" function (ex: HTTP header insertion)

Some sentences might be expressed in a different tone, to respect the different susceptibilities (But in the end, the draft mentions facts).
Ex:

  The loss of access to these fields may
  prompt undesirable security practices in order to gain access to the
  fields in unencrypted data flows.

Ex: Effect of Pervasive Encryption => Effect of Pervasive Encryption on Operators

Ex: It will take time to devise alternate approaches to achieve similar goals.
    => Well, not all goals described here are valid.

The draft could be reorganized to make easier to read (as Christian Huitema mentioned), but that's a huge change at this point.

Finally, I'm surprised not to see a section on Flow Monitoring with IPFIX/NetFlow.

[Ballot discuss]
- There are unresolved and substantive Last Call comments which the document does not address.

For example, I have a hard time reading "Not at all" as effectively addressing concerns that the document implicitly weakens the critically important principles that RFC 7258 lays down. While feedback to improve this specific situation has been solicited from Martin, it has been scantly more than a day since that request has been made. I don't think we're in a position to move the document forward with the current slate of unresolved Last Call comments.

- The IETF as a whole does not have consensus on the document.

For a document with such wide-reaching remit -- spanning network layers 3 through 7 -- the IETF-wide discussion has garnered an unclear mix of support and objection, and at fairly low volume (once we discount personnel directly involved in the progression of the document). If I count correctly, we have support for a document that fills this niche from Badri and Elliot, the most tepid statement of support I've seen in quite a while from Stuart (which itself concedes that the document diverges in tone and content from prior IETF statements on related topics), and rather strong statements of opposition from Martin and Christian. The objections by both Martin and Christian are substantive and structural; and many of the primary concerns they express appear to remain unresolved.

I understand the temptation to dismiss many of the objecting comments about structure and tone as editorial in nature; but this document lands squarely in the middle of a policy area in which the IETF (and the IAB in particular) has written extensively and carefully, in at least RFCs 1984, 2804, 7258, and 7754, among probably others that escape my notice at the moment; and this also includes IAB statements on the topic, such as . Due to this factor, I believe that obtaining IETF consensus on tone rather than merely technical content is warranted in this case.

[Ballot comment]
I share many of the concerns raised by Martin and Christian myself, in particular those that pertain to implicit endorsement of behaviors that other documents explicitly deprecate. I understand that the goal here is to be neutral in the way the document presents these topics (and I don't believe the current form achieves even that), but I believe that's the wrong goal.

To be clear, I don't want to pretend that these techniques don't exist in the wild, but I think the current formulation (and section 2 in particular) casts certain third-party entities as "victims of encryption"; when, in fact, most of these behaviors have been proscribed by IETF protocols and architecture documents for years. This is especially salient in light of the fact that such proscription has typically been precisely for the reason that these behaviors presume that traffic behavior can never evolve (e.g. that there will never be an increase in the use of encryption), and that behavior is now finally evolving.

The RFCs I cite in my discuss actually do stake out specific policy positions that pertain to overall Internet architecture; and, while I don't expect this document to necessarily reiterate all of them, it should at least be consistent with them.  In the context of the clear statements made by these policy documents, much of the text of the current document reads as an attempt to pussyfoot around sensibilities of entities who may not agree with established and published IETF consensus; but that should not be the goal (even if much of the target audience of this document includes such entities). We have published statements that many of the behaviors described in this document are *not* neutral, and attempting to *treat* them in a neutral fashion is explicitly going against that consensus. To be clear: yes, I am suggesting that description, in this document, of behaviors that are discouraged by the documents I cite above should be accompanied by clearer disclaimers that they are, and have historically been, considered by the IETF to be fundamentally detrimental.

I read some of the comments so far on this draft as wanting to revise the direction the IETF takes on these topics. That's a far broader conversation than pertains to this document; if we want to discuss that, I think we need to halt processing this document entirely and engage the IAB in a conversation around whether the aforementioned policy documents got it wrong.

_____

Some nuts and bolts of lesser consequence:

I think I've seen some messages about the potentially adversarial relationships that can arise in three- (or more) party communications, which is highly relevant; however, the document doesn't appear to have any treatment of this issue. In particular, I believe that the increased use of encryption may arise *because*of the behaviors being described, rather than despite them.

I agree with Ben's comment that the document suffers from explaining what is being done rather than why it is being done in some places. Ostensibly, a major part of the document's purpose is to foster discussion about how network operators can continue to manage their network in the face of encryption; but it will be difficult to discuss alternative approaches to meet their goals if those goals are not explained.

Section 2.3.2.1 mentions CDNs in a way that I find very confusing. Typically, CDNs are operated by or in cooperation with the entities providing authoritative content. Those entities are ostensibly both (a) the parties impacted by encryption, and (b) the parties choosing whether to use encryption. Clearly this can't be what you meant, since that reduces to a "doctor, it hurts when I do this" situation. I think a better description of the CDN scenario in this section is called for, if it is retained.

Section 2.4 describes "undesirable security practices" in generic terms. At least for browsers (the cited application), it's not clear to me precisely what kind of practices are being alluded to. Please add an example of one such practice.

In section 2.5.1, the statement mentioning "were contributed" has no context. I suspect an earlier document spoke of some process by which use cases were gathered from interested parties?

I think the scenario described in section 2.5.3 does not match the scope of this document (encryption). The problem being described is introduced by authentication of servers, not by encryption of content. I suggest either removing the scenario, or expanding the scope of the document to include problems introduced by authentication.

Section 2.6.1's assertions of a problem arising from encryption seem circular. It can be summarized as: the problem that arises from traffic being encrypted is that some traffic is not encrypted. This should be removed or clarified. This same tautology appears in section 3.1.

In section 2.6.5, the reference to non-CPNI data is using a really obscure and technically precise term, and really calls for a definition inline.

Section 2.7 discusses a number of problems that could arise from IP-level encryption, but which don't arise with the encryption that is commonly used on the Internet today. For example, analysis of TCP options, congestion window, etc. are not precluded by the use of TLS (as TCP information is sent in the clear); and the use of SRTP does not preclude analysis of VoIP traffic, as SRTP sends all the information used by DPI boxes in plaintext. As this document seems to be focusing on the practical effects of today's encryption deployment rather than the theoretical impacts of future widespread IPSEC deployment, these should probably be removed or heavily qualified. (n.b. -- I am not intimately familiar with the current level of IPSEC deployment in the Internet at large for typical large-scale consumer applications, and may be operating from an outdated view of its likely impact)

I'm not sure the mention of websockets in Section 2.7 is helpful: using HTTP for the types of operations cited has been a widely-used part of web browser behavior since the introduction of XMLHttpRequest over a decade ago. I think this would be improved if mention of Websockets were dropped entirely, and the paragraph were merely cast as the increase in use of port 443 for things other than simple web page retrieval.

Section 3.1.2 is very confusing -- it's muddy about which encryption here is desired by SPs, which encryption is posing novel challenges for them, and how they interact with each other. I think what's being described is a scenario in which an HTTPS connection is being terminated on a front end that can authenticate as the expected domain, decrypt the content, and then turn around and re-encrypt it. It's really not clear how this is impacted by the increased deployment of encryption, since the scenario only arises when encryption is required by the SP.

I'm not the expert here, but I think I've heard that there's some thinking around how to close the "SNI Hole," so it's probably relevant and useful to mention that this technique's days may be numbered as well.

Section 6.3 should probably mention the issues discussed in RFC 6562, including in particular the guidance in section 5 of that document. This issue may be true to some degree for video codecs as well, where the volume of encrypted data can be used to infer the amount of motion in a frame.

[Ballot comment]
I support all points of Alissa's discuss on version 10 if this is to be published as an IETF consensus document. (Does it need to be a consensus document to add value?)

I think it would also be helpful to clarify the provider end-goals for each practice. That's clear in some cases, but not in all.  It would also help to distinguish between situations where said goal can no longer be accomplished in the face of encryption, vs situations where the goal can be achieved by other means.  Again, this is clear in some cases, but not all.

[Ballot comment]
I support all points of Alissa's discuss if this is to be published as an IETF consensus document. (Does it need to be a consensus document to add value?)

I think it would also be helpful to clarify the provider end-goals for each practice. That's clear in some cases, but not in all.  It would also help to distinguish between situations where said goal can no longer be accomplished in the face of encryption, vs situations where the goal can be achieved by other means.  Again, this is clear in some cases, but not all.

[Ballot comment]
I believe that the discussions have made the document substantially better, especially regarding its purpose.

I think that it is very useful that we know how ubiquitous encryption impacts operators - not so that we stop pushing for this, but rather so that we can understand what information operators actually *need* to operate their networks -- if we make this information unavailable, operators may hinder or thwart deployment of new protocols / technologies.
Having an adversarial relationship with operators doesn't end well for any of us, but collaboration might...

[Ballot comment]
While I support the draft's intention to document current network management tools to help the community going forward with protocol development, considering the recent list discussion, I think a much stronger statement/better tone is needed to assure the reader that operators are not against RFC7258. Privacy concerns are critical to both users and operators. It's not encryption that is evil.

Operators themselves are very aware that their methods used in a pre-encrypted era may be used by "bad actors" and so the methods themselves are becoming more complex to manage in today's bad-actor world.

And the use of encryption is not blindly recommended by IETF with disregard for network operations. RFC7258, RFC7435, and other documents discussed network management issues and use of encryption. And there's been an IAB workshop on managing radio networks in an encrypted world.

Suggest:
In the abstract, the first sentence "Increased use of encryption impacts operations" sets a negative tone "operators vs. IETF and privacy advocates". It infers IETF disregarded operational impacts in recommending encryption. I think it would be good to "set the stage" differently, adding more on RFC7258 and why encryption is needed in today's world, e.g.:
"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."

As Warren mentioned, the document "sells" the many capabilities possible when not using encryption and in some items even argues (2.3.1) that encryption is not a "panacea". This tone is unnecessarily negative - are the draft's motives to help us understand operational concerns or to argue that encryption is no better as there are always corner cases? It would be more fair if it also mentioned the well-known security tradeoffs when not using encryption.

I think the document would be better perceived if it scoped itself to management issues vs. business motivations e.g. 2.3.2.1 on caching. Statements saying encryption is used for "intentional control" by the user, and not privacy motivated, are not within the scope of IETF. And, it infers any/all encryption is evil.

This is an important document, let's get it right. I think in its current state, it will confuse the industry. I don't think we need to rush to publish this document.

[Ballot discuss]
I have cleared my original DISCUSS point from my earlier review -- I get what the text is saying now, although I still think the "lose the option" language implies some entitlement to the option in the first place, which seems inappropriate.

But given the reviews from Martin Thomson and Christian Huitema, it's not clear to me that this document represents the consensus view of the IETF community. Kathleen's response to Martin reinforces the point that we were discussing in the first ballot cycle, which is that this document is written for and represents operators, not the broader array of Internet interests. Yet the suggestion to state that fact up front in the document was not adopted.

Having had some more time to review this document than I had in the previous ballot cycle, I also am finding myself in agreement with significant portions of the reviews from Martin and Christian. Reading their reviews helped crystallize a lot of the difficulty I had in parsing this document the first time around.

I understand the rationale that led to this document being written and I think there is a version of this document that could be written that would achieve the original goals while giving the subject matter a readable, neutral treatment. Such a version would be a useful contribution. But I don't think this document achieves that. In particular, there are four things that I think it would need to do to achieve that:

1. State the analysis in a neutral way. As I had mentioned in one of the email threads for the previous ballot cycle, I believe this document could be written in a neutral way -- e.g., “Service providers currently do X. It is implemented using Y mechanism. Encryption at Z layer breaks current implementations.” -- but it is not. Instead it characterizes many of the practices described as "optimizations" or "features" or "enrichment" and states service providers' claims about what these practices accomplish (e.g., "maximize QOE") as facts rather than stating them as the reasons given by service providers for why they engage in the practices. This is why in the previous round I suggested the disclaimer at the top of the document to say that the document is giving a view from service providers; that apparently didn't go anywhere, so the other option is to describe each technique neutrally, or explain with each technique that the characterization of the benefits is from the view of the operator. Martin's comments about being clear about who is benefitting point this out as well.

2. Limit the discussion to techniques presently being affected and those effects. There is a bunch of extemporizing about future possible impacts (e.g., in Sec. 2.7, 4.1.2, 4.1.3.1, 5.7, 7, 8). It's very hard to characterize future implications, who will bear the "cost" for what, whether increases in user complaints to various parties are "worth it," etc., in a way that is perceived as neutral by all affected parties. Better not to make predictions if the goal is to give a neutral treatment of network functions being impacted today.

3. Acknowledge the controversy. Many of the practices described in this document are controversial, and have been for a long time. There is nothing wrong with that. I agree with Christian that it would be better to state an understanding of that head-on rather than leave it to the reader to decide whether any particular characterization of something described implies an endorsement of it. This has been done before, even in potentially controversial documents that this document references, e.g. RFC 3135.

4. Structure the document in a way that is consistent and logical with minimal repetition. It seems like there are multiple ways that this could be done. Organizing based on use case (per Christian) and then discussing techniques used within each use case is one way; organizing based on technique while mentioning the goals for which each technique is employed is another. At present the document is jumble of these.

[Ballot comment]
First,  thank you very much for handling my previous comments.

Second, having reread the new version of the document, I am quite concerned that the
focused efforts to deny negative impact from pervasive encryption is close to biasing
the document.    I am aware that there are different aspects of tussle here - ranging from
the standard trade-offs between network management and privacy/efficiency/etc.
to  whether the application layer is the only one that can look at user-data or whether there
are reasons why a network operator needs to for manageability or to profit (just as the
applications do) to absolutism on the technical purity of pervasive encryption being the
only true way and all concerns of collateral damage are to be ignored.  There are trade-offs
here - as in everything engineering - and IMHO, we need to be approaching this document
as a good way of describing one part of the equation.  If VoIP calls don't work with acceptable
QoE because the flows aren't identifiable and given the needed QoS treatment, then having the
call be private isn't particularly useful.  If operators block encrypted protocols because they
can't handle the costs of the call volume to troubleshoot, then no one has won.  This is a really
useful and excellent list of issues and concerns - and anyone who isn't terrified by the list of
items that amount to "hope applications provide better logs because that's all we'll have  for
troubleshooting" should take a few more minutes to think it over and explain, if they are in
the applications space, how they will approach solving these problems.

a) "Reduces the benefits IP/DSCP-based transit network delivery
      optimizations; since the multiple applications are multiplexed
      within the same 5-tuple transport connection; a reasonable
      assumption is that the DSCP markings would be withheld from the
      outer IP header to further obscure which packets belong to each
      application flow."
    This doesn't mention the trust issue between the network and the application
    around DSCP markings.  Even if the application does mark each application
    flow as to its type, without either a cost to the application or a way for the
    network to verify, everything could simply be marked to be Expedited Forwarding.
    Beyond that is the issue that different networks use different DSCP values for
    different purposes; how does the network tell the application which values to use?

[Ballot comment]
I think that version -10 is much improved over -08, and that this is a useful contribution.
My earlier comments have been discussed, I'm updating this with some places where I think that people may be misunderstanding the intent / places where the tone could be misinterpreted.

One example where a reader could get the impressions that the IETF
might be condoning weakening encryption is:
"This had an immediate  impact to help protect the privacy of users
data, but created a
  problem for some network operators.  They could no longer gain access
  to session streams resulting in actions by several to regain their
  operational practices that previously depended on cleartext data
  sessions.

The EFF reported [EFF2014] several network service providers taking
  steps to prevent the use of SMTP over TLS by breaking STARTTLS
  (section 3.2 of [RFC7525]), essentially preventing the negotiation
  process resulting in fallback to the use of clear text."

This is a value neutral statement, but (I'm sure) would be viewed as
evil by many IETF participants. I understand that the document is
trying to explain what operators *do*, not what they should do, but
noting that this occurs without also noting that it has bad security
implications could feel like it is implicitly condoning
it. Yes, this is subjective -- but I wanted to mention it as an
example.


Another (even more subjective one) is: "In other cases, the ability to
monitor and troubleshoot could be eliminated." -- troubleshooting is a
very necessary function; the "could" doesn't help here -- it could be
read that the IETF is intentionally doing something to limit
troubleshooting ability, not that this is an (unfortunate)
side-effect.

I personally think that:
"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."

could be removed, and would help the document -- the previous and next
sentences cover this.
I'm just trying to highlight where someone who is approaching this
from another angle may read things...

[Ballot discuss]
I do not believe that this document represents IETF Consensus, largely
for the reasons indicated by Martin Thomson and Christian Huitema on
the IETF list recently. Specifically, this document, while perhaps not
saying anything actually false, essentially only presents the
perspective of operators and service providers. In many cases, those
interests are adverse to those of users -- and in many cases
encryption is used specifically to prevent operators from providing
the "services" and "enhancements" contemplated by this document.  For
these reasons, I don't believe that the uncritical treamtent of these
activities presented in this document should be published as an
RFC that claims to have IETF Consensus.

I have made specific comments below that indicate some of the more
serious issues, but the problems here are systematic and require
more than simple edits.

S 1.
  draft includes a collection of
  current security and network management functions

The functions presented here in many cases go far beyond security
and management. For instance, header enrichment is neither,
except by stretching the definition of "management" to breaking.


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

I'm not sure why you are mentioning CALEA here. As far as I can tell,
the CALEA requirements only apply to carriers who have access to the
keying material.

  The loss of access to these fields may
  prompt undesirable security practices in order to gain access to the
  fields in unencrypted data flows.

As Martin Thomson indicates, this feels like a threat.


S 2.1.
As Martin and Christian indicate, this QUIC material is entirely
speculative and extremely controversial and you should remove it.



  Additionally, a system that is able to encode the identity of the
  pool server in plain text information available in each incoming
  packet is able to provide stateless load balancing.

This doesn't have to be in plaintext because the pool load balancer
has a relationship with the servers. We already have designs for this
for QIC.


  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.  (In
  case of TCP, such information can be encoded by having server-
  generated sequence numbers, mss values, lengths of the packet sent,
  etc.)

How does this help the load balancer direct traffic.

S 2.2.
  Internet traffic surveys are useful in many well-intentioned

"Well-intentioned" is pretty tendentious here.


  pursuits, such as CAIDA data [CAIDA] and SP network design and
  optimization.

I'd be interested in hearing which CAIDA studies are impacted by
content encryption. Do you have citations?


S 2.3.2.1.
There are two kinds of caching potentially in play:

- Explicit caches
- Intercepting caches

At this point, what ISPs primarily run is intercepting caches, and
there's a lot of evidence that they contribute to bustage and
ossification, as well as being a primary tool for ISPs to use to mess
with people's traffic in ways that users clearly don't want
(ad/tracking injection, etc.).  So, I don't think an IETF consensus
document should suggest that we are sad to be breaking them.


S 2.3.2.2.
The presentation here seems biased given that it does not acknowledge
that one of the primary reasons that ISPs do traffic class
discrimination is to prioritize favored rather than disfavored
traffic, regardless of user preferences. I don't believe that the IETF
has taken a position for net neutrality, but I'm also pretty sure we
don't have consensus against it.


S 2.5.3.

Currently, the mobile network service provider redirects the customer
  using HTTP redirect to a page which educates the customer on the
  reason for the blockage and provide steps to proceed.  Once the HTTP
  header and content are encrypted, the Mobile carrier loses the option
  to intercept the traffic and perform an HTTP redirect.  With current
  solution options, this leaves only the option to block the customer’s
  request and cause a bad customer experience until the blocking reason
  can be conveyed by some other means.

This is pretty tendentious. It's not at all clear to me that the customer
thinks that having their traffic intercepted is a better experience.


S 2.6.2.
Zero-rating is absolutely possible in the face of encryption. Facebook
Free Basics supports this.

https://info.internet.org/en/blog/2015/09/24/enhancing-security-and-privacy-of-free-basics/


S 2.6.5.
Header insertion is also used for tracking and advertising.

S 2.7.
This should be clearer about the impact of encryption at various
layers. Most of the things you want to do here will work fine with
HTTPS.

S 2.8.
  When utilizing increased encryption, application server operators
  should expect to be called upon more frequently to diagnose problems

Why would this be true? As far as I can tell, pretty much only if they
are screwing with the traffic in ways that the user would prefer they
not.


S 3.3.1.
  The general monitoring needs for data replication are described in
  this subsection.

It's not at all obvious these are needs.

S 4.1.1.
A lot of these monitoring applications could also be characterized
as the employer conducting surveillance on its employees.


S 4.2.
As far as I know, the MITM techniques used by middleboxes are
not described in 7457.

You also need to cover the fact that these MITM are a threat to
user security because they are often so badly implemented.


  Restrictions on traffic to approved sites: Web proxies are sometimes
  used to filter traffic, allowing only access to well-known sites
  found to be legitimate and free of malware on last check by a proxy
  service company.  This type of restriction is usually not noticeable
  in a corporate setting, but may be to those in research who are
  unable to access colleague’s individual sites or new web sites that
  have not yet been screened.

I'm not sure why this would be not noticeable in a corporate setting.
I, for one, notice it on airplanes.

S 5.3.
It's pretty odd to talk about phishing without acknowledging that by
far the largest anti-phishing platform (Safe Browsing) operates
in the client, not be network interception.


S 7.1
This entire section is pretty confusing. Issues include:

- There is real debate about whether performance-enhancing proxies
  really work (see Mathis's comments at IETF).

- Content replication needs a lot more than just being able to see
  ACKs.

- "trusted" proxies? Trusted by who?

This whole architectural structure of having invisible proxies messing
with the transport stream is a total violation of the E2E argument,
so I don't see how one could think that describing it as if it were
positive can have IETF consensus.

I also notice that this section and the sectoin below describe things
that a lot of users don't want as "features"


S 7.3.
      Content/Application based Prioritization of Over-the-Top (OTT)
      services - each application-type or service has different
      delay/loss/throughput expectations, and each type of stream will
      be unknown to an edge device if encrypted; this impedes dynamic-
      QoS adaptation.

I think there's a lot of debate about whether we *want* networks to
try to accommodate new traffic classes. This has lead to a lot of problems
under the heading of "ossification"

        While CDNs that de-encrypt flows or split-connection proxy
      (similar to split-tcp) could be deployed closer to the edges to
      reduce control loop RTT, with transport header encryption, such
      CDNs perform optimization functions only for partner client
      flows; thus content from Small-Medium Businesses (SMBs) would not
      get such CDN benefits.

Huh? Lots of SMBs use this kind of CDN. That's how e.g., Cloudflare
works. Heck the IETF uses it.


S 8.
  In the best case scenario, engineers and other innovators would work
  to solve the problems at hand in new ways rather than prevent the use
  of encryption.  It will take time to devise alternate approaches to
  achieve similar goals.

Much of the context of this debate is about whether operators not
being able to do the things in this document is a problem.

  It is well known that national surveillance programs monitor traffic
  for terrorism [JNSLP]

I concur with Martin's objection to the use of the loaded word
"terrorism" here. Given RFC 2804 and the IETF's clear position on
protocol design, this discussion of balance between surveillance
and user security seems completely outside the IETF consensus.

  Open questions: As the use of encryption increases, does passive
  monitoring become limited to metadata analysis?  What metadata should
  be left in protocols as they evolve to also protect users privacy?

Huh? Coming as this does in the context of surveillance, 2804 is
clear. It might be the case that there are good reasons to avoid
encrypting metadata for the purposes of network monitoring by carriers,
but I think the IETF consensus is clearly not to do so to enable
surveillance.

[Ballot comment]
DISCUSS
I do not believe that this document represents IETF Consensus, largely
for the reasons indicated by Martin Thomson and Christian Huitema on
the IETF list recently. Specifically, this document, while perhaps not
saying anything actually false, essentially only presents the
perspective of operators and service providers. In many cases, those
interests are adverse to those of users -- and in many cases
encryption is used specifically to prevent operators from providing
the "services" and "enhancements" contemplated by this document.  For
these reasons, I don't believe that the uncritical treamtent of these
activities presented in this document should be published as an
RFC that claims to have IETF Consensus.

I have made specific comments below that indicate some of the more
serious issues, but the problems here are systematic and require
more than simple edits.

S 1.
  draft includes a collection of
  current security and network management functions

The functions presented here in many cases go far beyond security
and management. For instance, header enrichment is neither,
except by stretching the definition of "management" to breaking.


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

I'm not sure why you are mentioning CALEA here. As far as I can tell,
the CALEA requirements only apply to carriers who have access to the
keying material.

  The loss of access to these fields may
  prompt undesirable security practices in order to gain access to the
  fields in unencrypted data flows.

As Martin Thomson indicates, this feels like a threat.


S 2.1.
As Martin and Christian indicate, this QUIC material is entirely
speculative and extremely controversial and you should remove it.



  Additionally, a system that is able to encode the identity of the
  pool server in plain text information available in each incoming
  packet is able to provide stateless load balancing.

This doesn't have to be in plaintext because the pool load balancer
has a relationship with the servers. We already have designs for this
for QIC.


  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.  (In
  case of TCP, such information can be encoded by having server-
  generated sequence numbers, mss values, lengths of the packet sent,
  etc.)

How does this help the load balancer direct traffic.

S 2.2.
  Internet traffic surveys are useful in many well-intentioned

"Well-intentioned" is pretty tendentious here.


  pursuits, such as CAIDA data [CAIDA] and SP network design and
  optimization.

I'd be interested in hearing which CAIDA studies are impacted by
content encryption. Do you have citations?


S 2.3.2.1.
There are two kinds of caching potentially in play:

- Explicit caches
- Intercepting caches

At this point, what ISPs primarily run is intercepting caches, and
there's a lot of evidence that they contribute to bustage and
ossification, as well as being a primary tool for ISPs to use to mess
with people's traffic in ways that users clearly don't want
(ad/tracking injection, etc.).  So, I don't think an IETF consensus
document should suggest that we are sad to be breaking them.


S 2.3.2.2.
The presentation here seems biased given that it does not acknowledge
that one of the primary reasons that ISPs do traffic class
discrimination is to prioritize favored rather than disfavored
traffic, regardless of user preferences. I don't believe that the IETF
has taken a position for net neutrality, but I'm also pretty sure we
don't have consensus against it.


S 2.5.3.

Currently, the mobile network service provider redirects the customer
  using HTTP redirect to a page which educates the customer on the
  reason for the blockage and provide steps to proceed.  Once the HTTP
  header and content are encrypted, the Mobile carrier loses the option
  to intercept the traffic and perform an HTTP redirect.  With current
  solution options, this leaves only the option to block the customer’s
  request and cause a bad customer experience until the blocking reason
  can be conveyed by some other means.

This is pretty tendentious. It's not at all clear to me that the customer
thinks that having their traffic intercepted is a better experience.


S 2.6.2.
Zero-rating is absolutely possible in the face of encryption. Facebook
Free Basics supports this.

https://info.internet.org/en/blog/2015/09/24/enhancing-security-and-privacy-of-free-basics/


S 2.6.5.
Header insertion is also used for tracking and advertising.

S 2.7.
This should be clearer about the impact of encryption at various
layers. Most of the things you want to do here will work fine with
HTTPS.

S 2.8.
  When utilizing increased encryption, application server operators
  should expect to be called upon more frequently to diagnose problems

Why would this be true? As far as I can tell, pretty much only if they
are screwing with the traffic in ways that the user would prefer they
not.


S 3.3.1.
  The general monitoring needs for data replication are described in
  this subsection.

It's not at all obvious these are needs.

S 4.1.1.
A lot of these monitoring applications could also be characterized
as the employer conducting surveillance on its employees.


S 4.2.
As far as I know, the MITM techniques used by middleboxes are
not described in 7457.

You also need to cover the fact that these MITM are a threat to
user security because they are often so badly implemented.


  Restrictions on traffic to approved sites: Web proxies are sometimes
  used to filter traffic, allowing only access to well-known sites
  found to be legitimate and free of malware on last check by a proxy
  service company.  This type of restriction is usually not noticeable
  in a corporate setting, but may be to those in research who are
  unable to access colleague’s individual sites or new web sites that
  have not yet been screened.

I'm not sure why this would be not noticeable in a corporate setting.
I, for one, notice it on airplanes.

S 5.3.
It's pretty odd to talk about phishing without acknowledging that by
far the largest anti-phishing platform (Safe Browsing) operates
in the client, not be network interception.


S 7.1
This entire section is pretty confusing. Issues include:

- There is real debate about whether performance-enhancing proxies
  really work (see Mathis's comments at IETF).

- Content replication needs a lot more than just being able to see
  ACKs.

- "trusted" proxies? Trusted by who?

This whole architectural structure of having invisible proxies messing
with the transport stream is a total violation of the E2E argument,
so I don't see how one could think that describing it as if it were
positive can have IETF consensus.

I also notice that this section and the sectoin below describe things
that a lot of users don't want as "features"


S 7.3.
      Content/Application based Prioritization of Over-the-Top (OTT)
      services - each application-type or service has different
      delay/loss/throughput expectations, and each type of stream will
      be unknown to an edge device if encrypted; this impedes dynamic-
      QoS adaptation.

I think there's a lot of debate about whether we *want* networks to
try to accommodate new traffic classes. This has lead to a lot of problems
under the heading of "ossification"

        While CDNs that de-encrypt flows or split-connection proxy
      (similar to split-tcp) could be deployed closer to the edges to
      reduce control loop RTT, with transport header encryption, such
      CDNs perform optimization functions only for partner client
      flows; thus content from Small-Medium Businesses (SMBs) would not
      get such CDN benefits.

Huh? Lots of SMBs use this kind of CDN. That's how e.g., Cloudflare
works. Heck the IETF uses it.


S 8.
  In the best case scenario, engineers and other innovators would work
  to solve the problems at hand in new ways rather than prevent the use
  of encryption.  It will take time to devise alternate approaches to
  achieve similar goals.

Much of the context of this debate is about whether operators not
being able to do the things in this document is a problem.

  It is well known that national surveillance programs monitor traffic
  for terrorism [JNSLP]

I concur with Martin's objection to the use of the loaded word
"terrorism" here. Given RFC 2804 and the IETF's clear position on
protocol design, this discussion of balance between surveillance
and user security seems completely outside the IETF consensus.

  Open questions: As the use of encryption increases, does passive
  monitoring become limited to metadata analysis?  What metadata should
  be left in protocols as they evolve to also protect users privacy?

Huh? Coming as this does in the context of surveillance, 2804 is
clear. It might be the case that there are good reasons to avoid
encrypting metadata for the purposes of network monitoring by carriers,
but I think the IETF consensus is clearly not to do so to enable
surveillance.

[Ballot comment]
I think that version -09 is much improved over -08, and that this is a useful contribution.

Comment:
I realize that this might not be possible (I think it was in an email), but it would be nice if there were a reference for "The Mozilla (Foundation) maintains statistics on TLS usage and as of March 2017, 54% of HTTP base page loads are encrypted."

Nits:
Section 7 still says things like "This Appendix considers...", and the Acknowledgements section still refers to the appendix.

[Ballot comment]
* 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.

[Ballot comment]
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

[Ballot comment]
I agree with Ekr's comment concerning the sometimes adversarial relationship between the SP and the user, and the use of the word "need" in several places.

-1: Can you elaborate on : "Once OS is used, it allows for an upgrade to authenticated encryption."? I suspect you refer to the 7435 mention that OS may offer an evolution path to authenticated, encrypted communication. But as written, It sounds like it is trying to say OS offers an upgrade option for a particular session.

- 2.1.1: I'm not sure I follow the part about encryption that conceals the 5-tuple from a load balancer. The scenarios that spring to mind fall into the "why would anyone do that" category, but I assume that's due to my own lack of imagination.  A concrete example might help.

-2.1.2, paragraph 2: How is filtering on higher-layer data related to traffic analysis?

-2.1.4: This section seems to treat DPI as an end in itself. It's a tool to be used to accomplish certain goals, but if those goals went away, I don't think people would be too worried about the loss of DPI.

- 3.1.1: Again, I'm confused by the part about encryption that conceals the 5-tuple in the context of filtering. Is previously untunneled traffic becoming tunneled without the cooperation of hosted service provider or application provider?

- 3.1.2:I'm confused by this case. In the ASP case, I would assume the same authority would control at least one application endpoint as controls the network, and therefore should be able to get whatever information they need from that endpoint. Is there some assumption that this is not the case? If so, it would be worth mentioning.

[Ballot comment]
1) In Sec 2.1.1, it says "(including addresses and ports for source and destination, and one
  additional field such as the DSCP or other priority marking)."
  The DSCP field isn't included both because its value can chance based on ECN and because
  there can be packets in the same flow with different DSCP values (AF11 vs. AF12 vs. AF13).
  The 5 fields usually included are: IP src/dest, Protocol field, src/dest ports.
    This is correct in Section 3.1.1

2) Sec 3.1.2 refers to "Secure overlay networks (for example, VXLAN)" which is startling because
    VXLAN has no security mechanisms in it; it's just an additional header that can encapsulate
    Ethernet traffic.  It's like claiming MPLS is secure because it is layer 2.5.    There is some work
    starting in NVO3 about security extensions to go with the chosen encap (Geneve as a VXLAN
    replacement) and GUE (a WG draft in intarea) has some security extensions proposed.
    I think this paragraph needs some rework.  An overlay network can be used to provide isolation
    but this isolation just isn't secure - even more than VLANs don't add real protection for Ethernet
    traffic (but switches restrict what traffic is duplicated on the network based on VLAN membership
    on the links).

[Ballot discuss]

= Section 2.1.6.2 =

"Once the
  content is encrypted, the Mobile carrier loses the option to redirect
  the traffic leaving the option to block the customer's request and
  cause a bad customer experience untill the blocking reason can be
  conveyed by some other means."

If all that is encrypted is the application payload, why does the mobile carrier lose the option of being able to do this based on the 5-tuple? This seems to me to be a false statement, or it is assuming some conditions which need to be made more clear.

[Ballot comment]
Updated COMMENT with some more comments:

COMMENT:

= General =

I agree with Ekr's general comment.
 
= Section 2.1 =

"Encryption that conceals or replaces the original IP header" -- Section 1 doesn't give any particular indication that these kinds of techniques are on the rise; are there stats you could include, similar to the web ones that are included?

= Section 2.1.2 =

I find the co-mingling of traffic analysis for DDoS mitigation and endpoint fingerprinting in this section to be confusing. Are you saying that payload encryption is making both of these harder? If so, is the fact that attackers are having trouble more trouble doing endpoint fingerprinting seen as beneficial, or detrimental?

= Section 2.1.3 =

"Passive monitoring makes inferences about observed traffic using the
  maximal information available, and is subject to inaccuracies
  stemming from incomplete sampling (of packets in a stream) or loss
  due to monitoring system overload.  When encryption conceals more
  layers in each packet, reliance on pattern inferences and other
  heuristics grows, and accuracy suffers.  For example, the traffic
  patterns between server and browser are dependent on browser supplier
  and version, even when the sessions use the same server application
  (e.g., web e-mail access)."

I'm trying to see if I understand what this is saying. Is the idea that at present, in order to measure traffic volumes, traffic is sampled in a particular way based on which browser version is used? So if the entity doing the monitoring cannot determine the browser version of the traffic it is observing, the current model it uses to sample traffic and calculate a measurement becomes non-representative of the traffic it is trying to measure?

= Section 2.1.5 =

"or worse, they will adopt undesirable security practices in order to gain access to the unencrypted data flows" -- Isn't this a possibility for all of the use cases in Section 2.1, that the loss of the monitoring functionality may induce this behavior? If not, it would be helpful to further explain why this only applies to compression in mobile networks.

= Section 2.1.6 =

This section seems to cast the rationales behind filtering much more narrowly than they are in reality. In particular, lots of filtering happens for reasons other than law enforcement requests (as you then go on to describe in sub-sections). I would suggest citing RFC 7754 and generalizing this text.

= Section 2.1.6.1 =

(1)
How is the use case in this section different from the mention in 2.1.6 of "the user's pre-defined profile (e.g. for age sensitive content)"?

(2)
"In these cases, more granular (application layer) metadata may be used to
  analyze and block traffic, which will not work on encrypted content."

I don't think it's appropriate to say that this technique "will not work" given the purpose of this document. There is already some evidence that network management that some folks probably thought was impossible given encrypted traffic actually is still possible (e.g., https://arxiv.org/abs/1607.01639). The same may be true for parental controls, we just may not know how to do it yet. I think it's fine to say that access to cleartext application-layer metadata is no longer possible, or something along those lines.

= Section 2.1.7.3 =

In Section 2 the text says:

"The use of
  encryption prevents middle boxes from performing functions that range
  from some methods of load balancing to monitoring for attacks or
  enabling "lawful intercept", such that described in [ETSI101331] and
  [CALEA] in the US."

This section says that lawful intercept is "impacted by encryption, typically by allowing a less granular means of implementation." So, is the claim that LI is prevented by encryption, or that it requires a change of implementation? These seem to be saying different things.

= Section 2.1.7.4 =

s/Real Time Session Protocol/Real Time Streaming Protocol/

= Section 2.1.7.5 =

I would build on Ekr's comment here to say that even calling this technique header "enrichment" makes the text sound biased. Something like header "insertion" would be more neutral.

= Section 2.2 =

(1)
I think this section would benefit from some commentary about how the fact that the "management" and "repair" of application traffic in the middle of the network might become more difficult could also be seen as an overall benefit, since lots of application providers and users see worse performance or user experience when the network tries to "manage" or "repair" their traffic. Some applications have been motivated to adopt encryption in order to avoid this to begin with.

(2)
"With the growing use of WebSockets ..." -- strictly speaking, this isn't related to encryption, because encryption is not mandatory to use with websockets. So I don't think it belongs in the document.

= Section 3.2.2 =

"STARTTLS ought have zero effect on anti-SPAM efforts for SMTP
  traffic.  Anti-SPAM services could easily be performed on an SMTP
  gateway, eliminating the need for TLS decryption services."
 
This text caught my eye because it seems to be in contrast to the descriptions provided in Section 2 (and the purpose of the draft as stated in Section 1), which seem to be driving more of a "the current way this is done is X, and X would not be possible in the same way anymore" message. Personally I would much prefer if the whole document were more in the vein of this text in 3.2.2., but given the framing in Section 1 it seems like re-framing the text here would be more appropriate.

= Section 7 =

"National surveillance programs have a clear need for monitoring
  terrorism [JNSLP] as do Internet security practitioners monitoring
  for criminal activities."

To me these claims seem a bit out of place for an IETF RFC, and in general I agree with Ekr that it's probably better not to opine about the needs of various actors.

= Section 11 =

(1)
Wherever this section lands, I think it needs a clear disclaimer up front that the problems are being described from the perspective of the mobile network provider.

(2)
Is the term "trusted proxy" defined in one of the references? If not, it seems like it needs a definition.

[Ballot discuss]
I have only made it through Section 2.1.6 of this document, but I'm not sure if I'll have time to read the rest before the telechat, so I'm putting in what I have now for my ballot. My apologies for this.

= Section 2.1.6.2 =

"Once the
  content is encrypted, the Mobile carrier loses the option to redirect
  the traffic leaving the option to block the customer's request and
  cause a bad customer experience untill the blocking reason can be
  conveyed by some other means."

If all that is encrypted is the application payload, why does the mobile carrier lose the option of being able to do this based on the 5-tuple? This seems to me to be a false statement, or it is assuming some conditions which need to be made more clear.

[Ballot comment]
= Section 2.1 =

"Encryption that conceals or replaces the original IP header" -- Section 1 doesn't give any particular indication that these kinds of techniques are on the rise; are there stats you could include, similar to the web ones that are included?

= Section 2.1.2 =

I find the co-mingling of traffic analysis for DDoS mitigation and endpoint fingerprinting in this section to be confusing. Are you saying that payload encryption is making both of these harder? If so, is the fact that attackers are having trouble more trouble doing endpoint fingerprinting seen as beneficial, or detrimental?

= Section 2.1.3 =

"Passive monitoring makes inferences about observed traffic using the
  maximal information available, and is subject to inaccuracies
  stemming from incomplete sampling (of packets in a stream) or loss
  due to monitoring system overload.  When encryption conceals more
  layers in each packet, reliance on pattern inferences and other
  heuristics grows, and accuracy suffers.  For example, the traffic
  patterns between server and browser are dependent on browser supplier
  and version, even when the sessions use the same server application
  (e.g., web e-mail access)."

I'm trying to see if I understand what this is saying. Is the idea that at present, in order to measure traffic volumes, traffic is sampled in a particular way based on which browser version is used? So if the entity doing the monitoring cannot determine the browser version of the traffic it is observing, the current model it uses to sample traffic and calculate a measurement becomes non-representative of the traffic it is trying to measure?

= Section 2.1.5 =

"or worse, they will adopt undesirable security practices in order to gain access to the unencrypted data flows" -- Isn't this a possibility for all of the use cases in Section 2.1, that the loss of the monitoring functionality may induce this behavior? If not, it would be helpful to further explain why this only applies to compression in mobile networks.

= Section 2.1.6 =

This section seems to cast the rationales behind filtering much more narrowly than they are in reality. In particular, lots of filtering happens for reasons other than law enforcement requests (as you then go on to describe in sub-sections). I would suggest citing RFC 7754 and generalizing this text.

= Section 2.1.6.1 =

(1)
How is the use case in this section different from the mention in 2.1.6 of "the user's pre-defined profile (e.g. for age sensitive content)"?

(2)
"In these cases, more granular (application layer) metadata may be used to
  analyze and block traffic, which will not work on encrypted content."

I don't think it's appropriate to say that this technique "will not work" given the purpose of this document. There is already some evidence that network management that some folks probably thought was impossible given encrypted traffic actually is still possible (e.g., https://arxiv.org/abs/1607.01639). The same may be true for parental controls, we just may not know how to do it yet. I think it's fine to say that access to cleartext application-layer metadata is no longer possible, or something along those lines.

[Ballot discuss]
Why is section 11 in the appendix only? I would see this as an important part of the document because it seems to me that mobile operators are the ones most impacted by encryption.

[Ballot comment]
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.

[Ballot comment]
We have a few small nits queued up - the two from idnits
Badri Subramanyan's name will be added to the ACKs

and

Section 2.1.6.2 needs a small typo correction

2.  Further contenty may not
s/contenty/content/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-mm-wg-effect-encrypt-07.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

=== 1. Summary ===

This Informational document is a fairly extensive collection of security and network management functions that will likely be impacted by the increased use of encryption. Note that this document is a list of issues; there is no attempt to ameleroate the problems in the list. It is meant to help those who are attempting to create solutions to the problem by giving a taxonomy of problems and a list of useful references.

Paul Hoffman is the document shepherd; Stephen Farrell is the responsible AD.

=== 2. Review and Consensus ===

This is an AD-sponsored document. It was discussed in SAAG, both on the mailing list and in at least one face-to-face meeting (IETF 97). The list discussion was not heavy, but there was clearly enough inputs to the authors to see a reasonable amount of improvement between the recent drafts. There was a "pre-IETF-last-call" discussion on SAAG that proposed changes, and the authors made those. The IETF-wide last call started 2017-02-13 may generate more suggestions for additions and clarifications.

=== 3. Intellectual Property ===

Both authors have disclaimed any knowledge of IPR issues with this document.

=== 4. Other Points ===

Documents of this type (taxonomies and reference lists that can be used by others who are crafting solutions to problems) have been useful in earlier work, and this document is likely to be a significant help to the security community.

Minor stuff:

There is a cross-reference to [SACM] with no matching target.

idnits points out that "HTTP/2 implementations MUST support..." should not have the capitalized MUST because RFC 2119 is not referenced; it could be easily changed to "...are required...".

There is inconsistent capitalization in the references to non-RFCs; this trivial matter can be dealt with after IETF Last Call or by the RFC Editor (or can be ignored altogether, really).

=== 1. Summary ===

This Informational document is a fairly extensive collection of security and network management functions that will likely be impacted by the increased use of encryption. Note that this document is a list of issues; there is no attempt to ameleroate the problems in the list. It is meant to help those who are attempting to create solutions to the problem by giving a taxonomy of problems and a list of useful references.

Paul Hoffman is the document shepherd; Stephen Farrell is the responsible AD.

=== 2. Review and Consensus ===

This is an AD-sponsored document. It was discussed in SAAG, both on the mailing list and in at least one face-to-face meeting (IETF 97). The list discussion was not heavy, but there was clearly enough intputs to the authors to see a reasonable amount of improvement between the recent drafts. It is likely that an IETF-wide last call will generate more suggestions for additions and clarifications.

=== 3. Intellectual Property ===

Both authors have disclaimed any knowledge of IPR issues with this document.

=== 4. Other Points ===

Documents of this type (taxonomies and reference lists that can be used by others who are crafting solutions to problems) have been useful in earlier work, and this document is likely to be a significant help to the security community.

Minor stuff:

There is a cross-reference to [SACM] with no matching target.

The reference to RFC 2119 seems gratuitous and could be eliminated without reducing the value of the document. I also don't see a reason for RFC 4949 to be "normative"; it feels like all references for this document should be "informative".

There is inconsistent capitalization in the references to non-RFCs; this trivial matter can be dealt with after IETF Last Call or by the RFC Editor (or can be ignored altogether, really).

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: "Paul Hoffman" , paul.hoffman@vpnc.org, draft-mm-wg-effect-encrypt@ietf.org, stephen.farrell@cs.tcd.ie
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Effect of Pervasive Encryption) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Effect of Pervasive Encryption'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-03-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ballot/

No IPR declarations have been submitted directly on this I-D.

I-D nits notes that there is one use of a 2119 MUST (which can be
lowercased I guess) and the reference to [SACM] in 5.7 has no
matching entry in section 12, but we can fix those later.

This is an AD-sponsored last call. The relevant AD (Stephen
Farrell) will be escaping the IESG in March, so there may not be
time to get this document approved by the IESG before then,
e.g., if there is substantive discussion during/after IETF LC.
Warren Kumari, (one of the incoming ADs) has agreed to pick
this up should that be necessary. But better to get it over the
line if we do turn out to have IETF consensus for it now.

=== 1. Summary ===

This Informational document is a fairly extensive collection of security and network management functions that will likely be impacted by the increased use of encryption. Note that this document is a list of issues; there is no attempt to ameleroate the problems in the list. It is meant to help those who are attempting to create solutions to the problem by giving a taxonomy of problems and a list of useful references.

Paul Hoffman is the document shepherd; Stephen Farrell is the responsible AD.

=== 2. Review and Consensus ===

This is an AD-sponsored document. It was discussed in SAAG, both on the mailing list and in at least one face-to-face meeting (IETF 97). The list discussion was not heavy, but there was clearly enough intputs to the authors to see a reasonable amount of improvement between the recent drafts. It is likely that an IETF-wide last call will generate more suggestions for additions and clarifications.

=== 3. Intellectual Property ===

Both authors have disclaimed any knowledge of IPR issues with this document.

=== 4. Other Points ===

Documents of this type (taxonomies and reference lists that can be used by others who are crafting solutions to problems) have been useful in earlier work, and this document is likely to be a significant help to the security community.

Minor stuff:

idnits found one easy-to-fix error (a cross-reference to [SACM] with no matching target).

The reference to RFC 2119 seems gratuitous and could be eliminated without reducing the value of the document. I also don't see a reason for RFC 4949 to be "normative"; it feels like all references for this document should be "informative".

There is inconsistent capitalization in the references to non-RFCs; this trivial matter can be dealt with after IETF Last Call or by the RFC Editor (or can be ignored altogether, really).