Dear Stephane, Thank you for your review and comments. Let's see if we can work through your questions, discuss updates and perspectives to see where we get. I appreciate your engagement in advance. Inline On Sun, Nov 12, 2017 at 6:55 AM, Stephane Bortzmeyer <bortzmeyer@xxxxxx> wrote: > On Mon, Nov 06, 2017 at 06:06:50AM -0800, > The IESG <iesg-secretary@xxxxxxxx> wrote > a message of 37 lines which said: > >> The IESG has received a request from an individual submitter to >> consider the following document: - 'Effect of Pervasive Encryption >> on Operators' <draft-mm-wg-effect-encrypt-13.txt> as Informational >> RFC > > I'm quite concerned by this document. Basically, it seems to me it > deviates a lot from a simple description of current practices, and > goes into promoting them. The overall effect seems to me very > dangerous. One can easily read this document as "encryption is a pain > for the operators, we should not promote it too agressively". We worked hard on the framing in the introduction, so I'd like to see if your concerns are captured there in this discussion or if wording tweaks to make sure the statements are read as explanations of what is in use as opposed to endorsements as they are not. This is meant as a starting point for discussion to find balance between network management and prevention of pervasive monitoring, which is called for in RFC7258. We as a community have to work through these discussions to determine where the balance lies. This type of conversation and ones that would follow based on this and other work is helpful toward that goal. > > My opinion is that its publication as it is would inflict real harm to > the efforts of IETF to promote privacy (which implies, among other > things, a lot of encryption). I think wording tweaks may help, so let's see where we get as this is an important conversation to have. As one of the SecADs, I am constantly reviewing drafts and identifying security and privacy issues with new and evolving protocols. Acknowledging what practices are in place is very important to determine next steps and to work toward a common goal of privacy. Note that many of the techniques are aimed at network management and not with the intent of exploiting end user privacy. Operators are also concerned with end user privacy and in many cases, the end point application is actually the biggest risk to that user's privacy. Many of the use cases described are working towards use of a 5-tuple or 2-tuple or limited data that has been exposed at the transport layer. Yes, identifiers and flow information can be be used to expose information on end users. It is also clear that at least several of the described use cases could be solved with improved logging and debugging at the application. This is a known gap that if we worked together to address could help with a shift towards increased deployment of e2e encryption. > > The document also completely ignores network neutrality, not to > mention the end-to-end principle. > Perhaps a text change to highlight this better might help. The E2E principle is referenced with 3 RFCs in the second paragraph of the Introduction. When this was added, I had suggested that it might be a stronger statement to separate out the e2e references into a separate subsequent sentence since the documents don't quite fit with the preceding references. The IESG (in their review) did not think that was necessary, so we have the current text. I think it might be helpful to pull this out separately as you missed it's presence and others will likely too. It's also important to note, that like this document, the three on the e2e are informational and thus do not represent IETF consensus. So, they probably don't fit with the sentence they were in anyway since they are BCPs or policy documents (2804). RFC1958 is informational, but does offer guidance that is not immutable, so I think it's fine to leave where it is, but could see how that might be debatable. E2E is a guiding principle, the existing documents encourage it's use, document use cases, but explicitly do not make recommendations. Here's a proposal, edit suggestions are welcome, of course: OLD: The document does not endorse the use of the practices described herein. Nor does it aim to provide a comprehensive treatment of the effects of current practices, some of which have been considered controversial from a technical or business perspective or contradictory to previous IETF statements (e.g., [RFC 1958], [RFC 1984], [RFC 2804], [RFC 2775], [RFC 3724], [RFC 7754]). NEW: The document does not endorse the use of the practices described herein. Nor does it aim to provide a comprehensive treatment of the effects of current practices, some of which have been considered controversial from a technical or business perspective or contradictory to previous IETF statements (e.g., [RFC 1958], [RFC 1984], [RFC 2804]). The following informational documents consider the end to end (e2e) architectural principle, a guiding principle for the development of Internet protocols [RFC 2775], [RFC 3724], [RFC 7754]). > More precisely: > >> This document discusses practices currently used by network >> operators to manage, operate, and secure their networks > > Actually, it does not "discuss": it describes them, using only the > arguments of the operators that use these practices, rarely > questioning them. Good catch, thanks. How about: s/discuss/documents/ > >> the impact of pervasive encryption > > Note that we are far from "pervasive encryption". For instance, the > DNS traffic is almost entirely in clear (RFC 7858). This discussion has continued in the larger thread, so I'll follow along there to see if the end result is to change to a new term or if this term has agreement. If you have proposals for alternate terms, please do add them to that discussion. Thank you. > >> For example, the traffic patterns between server and browser are >> dependent on browser supplier and version > > That's a good example of why HTTP sessions must be encrypted: the > User-Agent: field is very revealing, among other infos sent by the > browser, as exemplified by the Panopticlick > <https://panopticlick.eff.org/> > Sure, that's not being argued. If you think a text change would help to make it clear that this is just being documented, please suggest text. The statement above reads as documentation of use to me, not an argument in either direction, but if you read it in another way, a clarification might be helpful. We're happy to consider proposals and discuss on list. >> Network operators use packet captures and protocol-dissecting >> analyzers when responding to customer problems, > > Not all network operators are so benevolent. I doubt that many 30 $ or > 25 € / month ISP use tcpdump when the customer has a > problem :-) Seriously, this sentence is very dangerous because of: I think the rest of your thought was omitted, but I believe this was discussed further in the thread. I will wait to see if text adjustments are needed. As far as I recall of the list discussion, "some" being added didn't seem to help as that is already implied with the existing sentence. Other text modification suggestions are welcome to help resolve a concern, if one exists still. > >> The ability to identify the problem application's traffic is >> important and deep packet inspection (DPI) is often used for this >> purpose > > This really looks like an attempt to "sell" DPI by explaining that it > may benefit the users. Actually, I would like to see my ISP going into > such efforts to help me but I doubt it will be the case. I believe I responded to this point later in the thread, so I won't respond here too. I suggest this gets snipped in a response. > > Note that no ISP document the practices it actually use against user > flows. This is sufficient proof that they are not done in the interest > of the users. Hmm, or this is because it's part of their secret sauce to provide enhanced performance over a competitor to meet or exceed SLAs for which contract services are based on and that allows them to continue to sell bandwidth and operate networks for which applications rely upon. > >> For example, by investigating packet loss (from TCP sequence and >> acknowledgement numbers), round-trip-time (from TCP timestamp >> options or application-layer transactions, e.g., DNS or HTTP >> response time), TCP receive-window size, packet corruption, >> inefficient fragmentation, or application-layer problems, the >> operator can narrow the problem > > Almost all of these investigations can be performed even if TLS or SSH > is used. Again, it really seems an effort to make DPI acceptable. The draft acks that some of the practices rely on the use of a 2-tuple or 5-tuple. You're arguing that a 5-tuple is enough for this particular type of monitoring that is documented. Is the expanded text around this statement contradictory to that point? If so, do you have a text suggestion to clarify? I think the description of what metadata is used in the quoted text makes your point clear already, but if you are reading it otherwise, others may too. > >> Because of this, application server operators using increased >> encryption should expect to be called upon more frequently to assist >> with debugging and troubleshooting > > Hard to read this as something else than a threat "do not use > encryption or your business will suffer". Hmm, what text would you suggest? This points to a problem that we have currently in that applications are not providing adequate logging and debugging information. To be successful in expanding the use of e2e, it is necessary to address this gap. Is there a way to rephrase this text, but still convey this point so you don;t feel like it's a threat? It's meant to be a possible way forward. > >> A common, early trigger for DDoS mitigation includes observing >> uncharacteristic traffic volumes or sources; congestion; or >> degradation of a given network or service. One approach to mitigate >> such an attack involves distinguishing attacker traffic from >> legitimate user traffic. > > Are there really dDoS attacks using encryption? Hard data welcome. This text was provided by 3 contributors (in ack section) with hands on experience on DDoS attacks. I can understand why you might question why encryption would be used as it would seem unnecessary, but it could be targeting services that are encrypted to deplete resources. the important point here is the ack that a fingerprint of encrypted traffic is adequate to identifying DDoS traffic to assist with mitigation. If you are arguing the e2e principle, I'm not sure why you'd be concerned with this statement where a type of monitoring has been able to proceed in an encrypted world and serves as a good example. > >> Mobile networks especially rely on content/application based >> prioritization of Over-the-Top (OTT) services > > This is a very important point: if encryption really prevents > prioritization of some services over the others, then it means we need > more encryption, not less. If encryption can help preserve network > neutrality, this is a good reason to use it even more. This is a technical summary, nit a policy one. So if we were to dive into net neutrality, we'd have to understand how they were prioritizing services. Is this based on paid SLAs with large customers, which would mean that it doesn't enter the net neutrality space. Is it to prefer their services over competitors? For this case, it is a problem. If it is to prefer services that do not have a tolerance for latency, like weighting phone calls over email, is this just normal traffic management to ensure things like emergency calls are given a preference? I'd have to go back and look at the surrounding text. If you have a text proposal here, please let us know. We're interested to document uses of monitoring, not to make policy statements or recommendations as this is intended to be an informational document. If there are references to other statements that already provide such guidance, I think it would be better to include a link rather than trying to work toward consensus on any such statement in this draft. This one clearly states the practices documented are not endorsed and I think that should address your concern. Having said that, if you do have a wording suggestion, please provide it. > >> Due to the characteristics of the mobile link, performance-enhancing >> TCP proxies may perform local retransmission at the mobile edge. In >> TCP, duplicated ACKs are detected and potentially concealed when the >> proxy retransmits a segment > > Again, TLS or SSH do not prevent this sort of hacks. Similar to the above statement, is there text around this that states more than the 5-tuple is needed? I would think the documentation of what is used makes that clear already. A 2-tuple would prevent this type of monitoring, which is also a possibility and good to document so application developers are aware of this usage and might discuss it further with operators when considering a move to encrypted protection that moves this from having the 5-tuple exposed to only having the 2-tuple exposed. the prevalence and importance could be discussed at that time, it's just important to have an understanding of use for the purpose of this document. > >> In addition to caching, various applications exist to provide data >> compression in order to conserve the life of the user's mobile data >> plan and optimize delivery over the mobile link > > I know that some mobile operators (see, in french, > <https://www.hteumeuleu.fr/la-compression-dimages-par-les-operateurs/>) > apply a LOSSY compression without the user consent or even > knowledge. Again, if end-to-end encryption prevents this, this is a > very good reason to deploy encryption. Interesting. Could you propose text written neutrally that documents this application of compression? I don't speak French. This document does not endorse the documented practices. We had some statements sprinkled throughout the document, but through reviews, it was deciding framing text in the introduction was sufficient. > >> These regulations include Lawful Intercept, adherence to Codes of >> Practice on content filtering, and application of court order >> filters. Such regulations assume network access to provide content >> filtering and accounting, as discussed below. > > It seems to me that RFC 1984 already replies to this reasoning. The full text of that section is as follows: Mobile Networks and many ISPs operate under the regulations of their licensing government authority. These regulations include Lawful Intercept, adherence to Codes of Practice on content filtering, and application of court order filters. Such regulations assume network access to provide content filtering and accounting, as discussed below. RFC1984 is already mentioned in the introduction in the same paragraph that explicitly states the documented practices are not endorsed. I see why you might be concerned and we've tried to avoid repeating these points throughout the document, but I'll propose text to see if it is agreed upon (or a tweaked version): NEW: Mobile Networks and many ISPs operate under the regulations of their licensing government authority. These regulations include Lawful Intercept, adherence to Codes of Practice on content filtering, and application of court order filters. Such regulations assume network access to provide content filtering and accounting, as discussed below. 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]. It feels unnecessary and duplicative to me, but understanding if others find this or a variant of this text useful would be helpful. > >> This type of granular filtering could occur at the endpoint. >> However, the lack of ability to efficiently manage endpoints as a >> service reduces providers' ability to offer parental control. > > I would be specially unhappy if IETF were to publish a RFC with such a > sentence without follow-up comments. Filtering MUST be done at the > endpoint, otherwise it is not a service, it is censorship. I think that point is subjective and debatable. While important, it would be a rat hole. In the interest of being productive, do you have a text suggestion that keeps us out of that discussion and just documents use of monitoring without endorsement? Considering the introductory text that already exists? TIA. > > If we assume that the subscriber wants parental control, then we must > conclude that he/she will have no problem sending the traffic to a > filtering proxy. No need to break encryption for that. Hmm, I think we are reading the text differently as I read it as describing this use usage that you seem to be okay with (this document merely documents it, does not endorse it). This still breaks e2e, but in a way that is permitted by the end user who decides to trust this service. We were trying not to split hairs on methods used to view traffic - it is already sent in the clear, some type of interception is performed (enterprise use cases where the server is already managed by that entity), or proxy services that serve as an endpoint for the encrypted session. Do you have text tweaks to suggest if you look at this again and find a place where it is not written as intended? I don't seen an issue with the quoted text, but that could just be me. TIA. > >> Some mobile carriers use HTTP header insertion (see section 3.2.1 of >> [RFC7230]) to provide information about their customers to third >> parties or to their own internal systems [Enrich]. > > Again, this technique, which has very serious privacy consequences > (see the mentioned reference [Enrich] with for example Vodafone which > added the phone number and the IMEI in HTTP headers) MUST NOT be done > and, if encryption stops it, great. Omitting this text would be ignoring the practice. Isn't it better to document all uses of monitoring to understand motivations and to open discussions between protocol developers and operators? This may result in wide-scale use of encryption to protect this data, but it could also highlight to developers the need to communicate with end users and find alternate methods to offer information to users. I think MNOT may have commented on this same section, so perhaps he has suggestions. If not, text suggestions are welcome. > > Editorial issues: > >> Currently, some mobile network service providers redirect the >> customer using HTTP redirect to a page that explains to those >> customers the reason for the blockage and the steps to proceed > > A mention of RFC 6108 would be cool here. That's a good addition. I only skimmed, but it states a requirement on port 80, so this relies on a clear text stream, is that right? Do you have text to propose for this addition? > >> monitor incoming mail to remove SPAM > > Why is spam uppercased? Thanks for catching that. > -- Best regards, Kathleen