Hello, Thanks for your comments on the draft. We will respond to all comments, but it may take time as it's a busy week and this message seemed like one that I could respond to more quickly than the prior. On Sun, Nov 12, 2017 at 8:02 AM, Paul Wouters <paul@xxxxxxxxx> wrote: > > > 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. Could you propose an alternate title? We used the term ubiquitous previously, and it was changed in a prior IETF list discussion to the current title. > > 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. The purpose was to document the effects of increased encryption, not to solve any of the problems. As the document states, there are cases where the feature/function may just be eliminated with no way to perform the desired feature (desired by some operators). If you don't look at the impacts as a first step, they will be an impediment to the adoption of E2E protocols and the evolution that is happening with TLS 1.3 and QUIC for example. By opening up the conversation, and having both sides look at the problems, we are more likely to achieve E2E in deployment scenarios. Continuing an arms race is not effective - rather stepping back to document impacts is a first step toward removing obstacles to deployment for E2E. I thought this point was fairly clear in the introduction, so if it is not and you have wording suggestions, please provide them. > > But in its current form, it seems this document would be prime candidate for operator misbehaviour justification “sanctioned” by the IETF. The introduction makes it quite clear that it is not the case and states the documented effects are not IETF sanctioned. > > 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. Operators have responded very positively to this draft that has let them open up the conversation, so I don't think the problems have been looked at by the developers of protocols like TLS 1.3 and QUIC. Operators were unaware of the changes. Now it's time to have the discussions and see how we can work together so that deployment of e2e encryption happens. Just because we release protocols does not ensure their adoption. > > This documents feels (unintentionally) that we need to go back to be drawing board to reconsider these operator issues. Not necessarily. The framing tries to make the intentions clear. Can you take a look at the introduction and let us know where that is not clear? Best regards, Kathleen > > 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? > -- Best regards, Kathleen