[OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Thu, 08 February 2018 05:04 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 741FE1241F3; Wed, 7 Feb 2018 21:04:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: draft-mm-wg-effect-encrypt@ietf.org, opsawg@ietf.org, warren@kumari.net, Paul Hoffman <paul.hoffman@vpnc.org>, paul.hoffman@vpnc.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151806627444.17073.14252972331367641645.idtracker@ietfa.amsl.com>
Date: Wed, 07 Feb 2018 21:04:34 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/UF-W2lrfy2sQNN8VMNFy1mxVeOg>
Subject: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Feb 2018 05:04:34 -0000
Eric Rescorla has entered the following ballot position for draft-mm-wg-effect-encrypt-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have completely re-reviewed the latest version. First, I want to thank you for toning down some of the material that I was concerned about. Unfortunately, the fundamental concern that motivated my DISCUSS remains: I do not believe that this document matches the consensus of the IETF community. Specifically, this document takes at face value a large number of claims about the necessity/value of certain practices that either are controversial within the IETF or that there is, I believe, rough consensus to be actively bad, and that in many cases, encryption is specifically designed to prevent. I have noted a number of these below, but I do not believe that this is an exhaustive list (going through my previous DISCUSS, I see that I noted a number of these but that still appear to be unaddressed.) DISCUSS session encryption that deployed more easily instead of no encryption. I think I understand what you are saying here, but the term "breakable" seems very unfortunate, especially in the context of this document. The only such shift I am aware of that has received acceptance in IETF is one from always requiring fully authenticated encryption to allowing unauthenticated encryption, which you document in the next paragraph. I recognize that there are other perspectives (e.g., those in draft-rhrd) but those are pretty far from IETF consenus. Accordingly, I think you should remove this sentence. motivation outside of privacy and pervasive monitoring that are driving end-to-end encryption for these content providers. This section seems kind of confusing, at least as applied to HTTP. There are three kinds of cache in HTTP: - Reverse proxy caches (the kind CDNs run) - Explicit forward proxy caches - "Transparent" intercepting caches The first of these move to HTTPS just fine and that's typically how CDNs do it. Explicit forward proxy caches are largely going away, but part of the point of this kind of end-to-end encryption is to hide data from those caches. Transparent intercepting caches that the user didn't opt into are a bad thing, so having them go away is a positive. document existing practices, the development of IETF protocols follows the guiding principles of [RFC1984] and [RFC2804]. This is pretty opaque in this context. It should explicitly state that the IETF's position is that we do not engineer for these use cases, not just to cite the RFCs. based billing, or for other reasons, possibly considered inappropriate by some. See RFC7754 [RFC7754] for a survey of Internet filtering techniques and motivations. This section is I don't think this accurately represents the RFC, which makes clear that the IAB consensus is that filtering is bad: " From a technical perspective, there are no perfect or even good solutions -- there is only least bad. On that front, we posit that a hybrid approach that combines endpoint-based filtering with network filtering may prove least damaging. An endpoint may choose to participate in a filtering regime in exchange for the network providing broader unfiltered access." detect or prevent attacks as well as to guarantee service level expectations. In some cases, alternate options are available when encryption is in use, but techniques like that of data leakage These certainly are use cases, but you really need to acknowledge that it's also a form of user surveillance. Some DLP tools intercept traffic at the Internet gateway or proxy services with the ability to man-in-the-middle (MiTM) encrypted session traffic (HTTP/TLS). These tools may use key words important to the enterprise including business sensitive information such as trade secrets, financial data, personally identifiable information (PII), or personal health information (PHI). Various techniques are used to intercept HTTP/TLS sessions for DLP and other purposes, and are described in "Summarizing Known Attacks on TLS and DTLS" [RFC7457]. As far as I know, the MITM techniques used by middleboxes are not described in 7457. You also need to cover the fact that these MITM are a threat to user security because they are often so badly implemented. S 5.4. It's pretty odd to talk about phishing without acknowledging that by far the largest anti-phishing platform (Safe Browsing) operates in the client, not be network interception. The transport header encryption prevents trusted transit proxies. It may be that the benefits of such proxies could be achieved by end to You don't define a "trusted transit proxy" so I don't know what this means, and whether they provide any benefit, but this certainly sounds euphemistic. Generally, "trusted" is not an adjective we associate with network proxies operated by third parties. In the best case scenario, engineers and other innovators would work to solve the problems at hand in new ways rather than prevent the use of encryption. As stated in [RFC7258], "an appropriate balance (between network management and PM mitigations) will emerge over time as real instances of this tension are considered." Much of the context of this debate is about whether operators not being able to do the things in this document is a problem, and this seems to presume the answer. This optimization at network edges measurably improves real-time transmission over long delay Internet paths or networks with large Do you have a citation for this claim? Web proxies are sometimes used to filter traffic, allowing only access to well-known sites found to be legitimate and free of malware on last check by a proxy service company. This type of restriction is usually not noticeable in a corporate setting as the typical corporate user does not access sites that are not well-known to these tools, but may be noticeable to those in research who are unable to access colleague's individual sites or new web sites that have not yet been screened. In situations where new sites are required for access, they can typically be added after notification by the user or proxy log alerts and review. Home mail account access may be blocked in corporate settings to prevent another vector for malware to enter as well as for intellectual property to leak out of the network. This method remains functional with increased use of encryption and may be more effective at preventing malware from entering the network. Web proxy solutions monitor and potentially restrict access based on the destination URL or the DNS name. A complete URL may be used in cases where access restrictions vary for content on a particular site or for the sites hosted on a particular server. If you are filtering on URL and there is HTTPS involved, then you are a MITM, and this is potentially noticeable to end-users. We encounter this regularly when MITM proxies make mistakes in getting into our trust anchor store. Re: 0-rating. user. This feature is impacted if encryption hides the details of the content domain from the network. Well, maybe. Facebook's zero rating, for instance, is IP-based. https://info.internet.org/en/blog/2015/09/24/enhancing-security-and-privacy-of-free-basics/ S 2.2.2. The presentation here seems biased given that it does not acknowledge that one of the reasons that ISPs do traffic class discrimination is to prioritize favored rather than disfavored traffic, regardless of user preferences. I don't believe that the IETF has taken a position for net neutrality, but I'm also pretty sure we don't have consensus against it. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Pervasive Monitoring (PM) attacks on the privacy of Internet users is of serious concern to both the user and the operator communities. are of serious concern Traditional network management, planning, security operations, and performance optimization have been developed in an Internet where a large majority of data traffic flows without encryption. While you have a plural/singular mismatch here. Authentication with IPsec [RFC7619] and there are a number of infrastructure use cases such as server to server encryption, where this mode is deployed. While OS is helpful in reducing pervassive Nit, no comma before "where" recommendations from these documents were were built upon for TLS 1.3 to provide a more inherently secure end-to-end protocol. "were were" to-user content encryption schemes, such as S/MIME and PGP for email and encryption (e.g. Off-the-Record (OTR)) for XMPP are used by those interested to protect their data as it crosses intermediary Not, "e.g.," been impacted by increases in encrypted traffic. Only methods keeping with the goal of balancing network management and PM mitigation in [RFC7258] should be considered in solution work resulting from this document. I don't understand what the normative content of this was. upgrades before user experience declines. For example, findings of loss and jitter in VoIP traffic can be a predictor of future customer dissatisfaction (supported by metadata from the RTP/RTCP protocol ) [RFC3550], or increases in DNS response time can generally make interactive web browsing appear sluggish. But to detect such problems, the application or service stream must first be distinguished from others. This is a little hard to read, but generally this information is not encrypted for SRTP/SRTCP. When using increased encryption, operators lose a source of data that may be used to debug user issues. Because of this, application server operators using increased encryption might be called upon more frequently to assist with debugging and troubleshooting, and thus may want to consider what tools can be put in the hands of their clients or network operators. This is phrased as hypothetical, but is there any actual data to support this? We have a lot of experience now with encrypted voice and video as well as Web. Do those providers report any increased level of requests. the new flow and would not be able to route it back to the original POP. I'm having a little trouble understanding this paragraph. Why is this about mobile operators? It seems like it's an issue for anyone who has a service that might have mobile clients. effective at providing data offload when there is a network element close to the receiver that has access to see all the content. This section is also confusing in that it fails to distinguish between proxies of this type that the user opts into from transparent proxies that just do this service without the user's consent. Part of the purpose of encryption is to preclude that. created from the intercepting device to the client's destination, this is an opt-in strategy for the client. Changes to TLSv1.3 do not impact this more invasive method of interception, where this has the I don't understand the cite to TLS 1.3 here. None of this is presently affected by 1.3. endpoints as a service reduces providers' ability to offer parental control. This section makes it seem like there are no other methods that allow for parental control, but that's not true. There are parental control mechanisms which rely on MITM proxies or application interfacing. HTTP headers and content are encrypted, this prevents mobile carriers from intercepting the traffic and performing an HTTP redirect. As a result, some mobile carriers block customer's encrypted requests, Yes, stopping traffic redirection is actually one of the major design purposes of HTTPS. to the customer and additional overhead to the mobile network service provider. This section is basically a commercial for this practice. It needs to acknowledge that it's actually much closer to IETF consensus that it's a bad practice. headers to accomplish the, sometimes considered controversial, functions above. Again, this is precisely the form of attack that HTTPS is intended to prevent. perform SSL/TLS decryption are impacted by the increased use of encryption that prevents interception. I don't really understand what this text means. What is "use of encryption that prevents interception" in the context of tools which already do decryption? [DarkMail]. Of course, SPAM filtering will not be possible on encrypted content. This is not strictly correct, as you can still header filter, etc. over the Internet. Options for monitoring will vary with each encryption approach described below. In most cases, solution have been identified to provide encryption while ensuring management Nit: "solutions have" allow for multiple end user sessions to share the same TCP connection. This rasises several points of interest with an increased use of encryption. TCP session multiplexing should still Typos: rasises be possible when TLS or TCPcrypt is in use since the TCP header information is exposed leaving the 5-tuple accessible. The use TCP session multiplexing of an IP layer encyption, e.g. IPsec, that only I'm not sure if this is correct. What precisely do you mean by "TCP session multiplexing"? A cite would be helpful here. center. HTTP pipelining requires both the client and server to participate; visibilty of packets once encrypted will hide the use of HTTP pipelining for any monitoring that takes place outside of the Typo: visibility traffic cannot be intercepted, encouraging alternate options such as performing these functions at the edge. I'm not seeing the relevance of this. Who is proposing solutions in which encrypted traffic cannot be intercepted at the outgoing network edge. owing to concealment of critical headers and payloads. Many forms of enterprise performance management may be similarly affected. Again, this is sort of transparent caching is an anti-pattern, so this document ought to acknowledge that, parts of the address assignment/management protocols, critical for SAVI mechanisms, can result in a dysfunction of the SAVI mechanisms. Does anyone actually deploy SAVI? If not, encryption isn't having much of an impact. network filters look out for seeing a Server Name Indication extension, they may not find one. The SNI Encryption in TLS Through Tunneling [I-D.ietf-tls-sni-encryption] draft has been adopted by the This doesn't really follow. I mean they "may not" but overwhelmingly they will
- [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-e… Eric Rescorla
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Eliot Lear
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Benoit Claise
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Randy Bush
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Mirja Kuehlewind (IETF)
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Melinda Shore
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Eliot Lear
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Joel M. Halpern
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Carlos Pignataro (cpignata)
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Randy Bush
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Kathleen Moriarty
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Kathleen Moriarty
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Eric Rescorla
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Spencer Dawkins at IETF
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Benoit Claise
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Spencer Dawkins at IETF
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Warren Kumari
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Spencer Dawkins at IETF
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Warren Kumari
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Eric Rescorla
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Eric Rescorla
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Kathleen Moriarty
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Eric Rescorla
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Warren Kumari
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Eric Rescorla
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Kathleen Moriarty
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Warren Kumari
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Warren Kumari
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Eric Rescorla
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Warren Kumari
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Eric Rescorla
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Kathleen Moriarty
- Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-… Eric Rescorla