Inline Roni > -----Original Message----- > From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Paul Wouters > Sent: יום א 12 נובמבר 2017 15:02 > To: Stephane Bortzmeyer > Cc: ietf@xxxxxxxx > Subject: Re: Last Call: <draft-mm-wg-effect-encrypt-13.txt> (Effect of > Pervasive Encryption on Operators) to Informational RFC > > > > 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. [Roni Even] I will argue this statement. My experience is that the user care about the encryption of his content. As for privacy - do you see users stop using social media? Do they install applications that ask for access to you contact, photos, location or like most users they just approve them. > > 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?