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". 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). The document also completely ignores network neutrality, not to mention the end-to-end principle. 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. > 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). > 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/> > 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: > 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. 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. > 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. > 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". > 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. > 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. > 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. > 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. > 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. > 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. 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. > 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. 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. > monitor incoming mail to remove SPAM Why is spam uppercased?