I concur with most of Stephane’s comments. And I find the use of the term “pervasive encryption” very problematic. Pervasive means: “(especially of an unwelcome influence or physical effect) spreading widely throughout an area or a group of people.” More encryption is never unwelcome to the enduser. If this document listed these practises, along with valid methods for operators to switch to, i could be convinced the document is useful. But as Stephane pointed out, a lot of these problems are desired features. That the operator has less networking debugging tools is an unavoidable side effect, but should not be used as an argument against more encryption. But in its current form, it seems this document would be prime candidate for operator misbehaviour justification “sanctioned” by the IETF. Note that I _do_ believe in the authors’ good intention of just documenting the new problems operators face. But the IETF will have taken these issues into consideration already before it published the RFCs. This documents feels (unintentionally) that we need to go back to be drawing board to reconsider these operator issues. Paul > On Nov 12, 2017, at 19:55, 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". > > 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?