Re: [saag] AD sponsoring Effect of Ubiquitous Encryption
Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 22 January 2017 20:42 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D02B120726 for <saag@ietfa.amsl.com>; Sun, 22 Jan 2017 12:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.5
X-Spam-Level:
X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGrBn3swN3vY for <saag@ietfa.amsl.com>; Sun, 22 Jan 2017 12:42:19 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A81127ABE for <saag@ietf.org>; Sun, 22 Jan 2017 12:42:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8A154BE2E; Sun, 22 Jan 2017 20:42:15 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WeMdrv9rX66; Sun, 22 Jan 2017 20:42:13 +0000 (GMT)
Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 41F67BDF9; Sun, 22 Jan 2017 20:42:12 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485117732; bh=2DCYu6qpe1h8vRgm1sZ0K2TCnPaq6HcDyYOeJnjGMM4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=RpG5oK8enj7TOLOORUMOb4it9Bqt0xhOQJcn6XUO+jVX+Xe2NocmQwHL4WYOvmDV2 fHHLNZBa+W/IC6OJnM701ObxFddEu9z+ZMur2ronrmLz7zufDgjuleMAjSfAwG9fDX PKcXQKeRY5xaFOTSOsDZjLDgDDzwkEsgy4/Fkb3c=
To: "saag@ietf.org" <saag@ietf.org>
References: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <307973f8-ffab-8657-ad7a-8bc8557b2555@cs.tcd.ie>
Date: Sun, 22 Jan 2017 20:42:11 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <40c377e3-9a37-0d18-adde-b11c6b8785d2@cs.tcd.ie>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000000070409060600080205"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/JAv8F5vCG87PWb5qNKWY3_NeNbc>
Cc: Al Morton <acmorton@att.com>
Subject: Re: [saag] AD sponsoring Effect of Ubiquitous Encryption
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Jan 2017 20:42:22 -0000
Hi again, First, thanks to Paul Hoffman for being willing to be the document shepherd for this. And to the authors for what will be a fine RFC when it's done. Second, I've done my AD review of this and there are a set of things that need fixing before we'll be ready for IETF last call. At minimum there are still a few placeholder sections of text (2.3,2.3.1,3.2,2), but I also have many comments that cumulatively raise to the level where we should address a bunch of those before IETF LC, even though many (but not all) of my comments are relatively nitty. I think that almost all of those should be pretty easy to resolve, so we should still be able to get this done before IETF98 I hope. My AD review is below. Cheers, S. general: I wonder if we're dealing with all possible effects or only with those relevant to network management, security ad privacy? For example, more encryption does prevent some advertising insertion, but whether or not that is in scope here is unclear to me. Should it be? - title: I wonder would "Effects of Much More Common Encryption" be a better title? Ubiquitous is never actually going to happen, nor is it required for many of the effects to be seen. (And there is defo. >1 effect to be seen.) Or, you could keep the title, but explain in the text that you really mean "much more common." - abstract: "solve these problems" is a tad one-sided in that it doesn't recognise the valid reasons for more confidentiality. I think it's important that the abstract recognise that we're here documenting one set of consequences of what is a valid set of trade-offs and not describing a set of problems caused for no good reason. I think that it's important to set the right tone early for this one - if we don't then some readers who want better privacy may be more likely to be dismissive, which'd be a shame. - abstract: "will impact" is maybe no longer the correct tense - we've seen some of these impacts already I think, so maybe "are impacting" or just "impact" is better? - abstract: "more drastic" seems unfounded - what do you really want to say there? - intro: I'm not sure "primarily a passive attack" is right. Maybe easiest to just delete that clause as I don't think it's needed here. You could add a reference to RFC7624 for those who'd like more detail. - intro, 2nd para: I'm not sure what you mean referring to "many attackers"? That sentence doesn't seem to make sense as-is. - intro: the UTA document references need to be updated - intro: the 30% figure is probably out of date, please check again (or add a date as done with the others). - intro: "for corporate users" would be better removed - we care as much about non-corporate users after all - intro: "TLS over HTTP" is backwards, as is "TLS over XMPP" - intro: "Although this does provide..." - that sentence isn't right, passive is not the opposite of e2e, I think you want s/passive wiretapping/transport layer attacks/ - intro: You mention OTR, but the cooler kids these days use signal/telegram (though I don't for platform reasons;-). Might be worth checking out what to say about those, or just say "e.g. OTR" instead of making it seem like OTR is the only way to do IM e2e. - intro, 2nd last para: that one is very good - intro, last para: you don't mention enterprise networks here, worth a mention? - section 2, 2nd para: I think you could do with a forward reference or example to the "opterational practices that require cleartext" or maybe better is to s/require/previously depended on/ - 2: "TLS over SMTP" - backwards again - 2: "The EFF reported..." that needs a reference - 2: I'm not at all sure encryption "prevents" load balancing, in fact I'm pretty sure it does not prevent that - 2: "on the decline now that they are exposed through the media" - I think it'd be better to remove that sentence - it doesn't add much and there are more details better described later I'm sure. - 2.1: this sections seems mixed between middleboxes and mobile, probably as a result of iterative editing. Not sure how best to fix. - 2.1, last para: Is that really a middlebox function? I thought most of the examples given were cases of end systems (web servers) impinging on privacy and not middleboxes (and the naughty web servers are not affected by encryption so aren't really in scope) - 2.1.3: I don't think DPI aims to improve "features and efficiency" - 2.1.3: "must be known" is overstated - again I think we want to always phrase it as "has previously been assumed to be required" or similar - 2.1.4: I think compression could (and maybe should) be separated out - one of the things CRIME has shown us is that we had more to learn about how to combine compression and encryption. I also think most compression is not done/undone at middleboxes, nor does it relate to monitoring so compression doesn't seem to fit well in 2.1. (Transcoding however might fit in some middlebox section, but is not compression.) - 2.1.5: s/law agencies/law enforcement agencies/ is the usual term, and LEAs are not the only entities that insist on this kind of thing - considering censorship. - 2.1.5: "sites promoting anorexia" seems like an odd example, but I think in any case it'd be better to generalise the examples a bit - 2.1.5: DNS queries do not "reveal" URLs. And the described mechanism seems quite odd. - 2.1.5: The 3rd last para about "TLS proxies" and "future versions of HTTP and TCP" is not clear to me. Is that really needed? - 2.1.5: Parental controls might deserve it's own subsection - it differs in that the endopints are involved, which I think means that the effects of e.g. TLS on the changes required to the service are different from cases where an external party (govt/SP/whoever) imposes the filtering. - 2.1.6.3: I think you need a reference to RFC2804 here. The IETF does not to LI in standards, for the (good) reasons stated therin. So this may be a case where the effects of crypto do enhance existing IETF policy but also counter existing policies of other entities. But we should not ignore the former (IETF) policy - we ought not claim here that one or the other are better, but just ack the tussle. - 2.1.6.4: MTAs do trypically have cleartext access, so what kind of spam/malware filtering do you mean there? How does that relate to the mail architecture? (There's an RFC for that that ought be ref'd.) If section 5 does cover this well, then I'd say removing this section would be good as it add nothing much that I can see. - 2.2: Do we have evidence that the decrease of measurement accuracy has actually lead to a decrease in repair efficiency? I'm not convinced - it doesn't seem like a crazy proposition, but nor does it seem like a tautology. (What metric for efficiency of repair is there that could be mapped to visibility of different protocol layers?) - 2.2, 2nd para: This is repetitive. Making the point once is enough. - 2.3 and 2.3.1: What is the intent here? These sections seem to be content free. Looks like a placeholder that never got filled in? (Not unreasonable as it's hard to see real downsides to encryption of inter-DC traffic.) These need to be fixed or deleted. Probably deleted is better. (Certainly easier.) That needs fixing before IETF LC. 3.1.1, 1st para: I'm not clear how session monitoring of cleartext is needed for SLA evaluation. Maybe an example of some specific thing needed would helpa but I'm not seeing an input to SLA evaluation here. (I do see how logs can be useful there.) 3.1.1 (and elsewhere): s/mobile clients/clients/ - while some of thie text relates to the marnew w/s, it ought only specify mobile clients where those are specifically relevant, an in this case, and others, they're not. 3.1.2: "cyber-security" and "cyber-attack" please avoid thosse ill-defined marketing terms unless you really need and can justify them 3.1.1: Is "malware explosion" a generally known term? I think detection is sufficient and searing for "malware explosion" doesn't turn up what I think you mean. (I'm guessing you mean unzipping etc.) 3.1.2, last para: I'm not clear how this para fits here or in this document in general. Not sure if that's just me or if some better linkage is needed, or even if the text would be better moved or deleted. 3.2.1: I'm not sure I agree with this, at least as stated. Wouldn't passive monitoring of ciphertext be just as effective for the SLA metrics mentioned in almost all cases? 3.2.2: "[Need descriptions for..." The rest of that para seems like placeholder text that needs fixing before IETF LC. 3.2.2: I think it'd be worth saying somewhere here that STARTTLS ought have zero effect on anti-SPAM etc. for SMTP traffic but is only an issue in corner-cases for e.g. hosters who want to scan outbound port 25 traffic in case their cusomters have suffered breaches and start sending spam. (At least that's my understanding.) PGP or S/MIME do of course. 3.2.2: What header encryption efforts are meant here? I'm not familiar with anything doing exactly that. Or maybe it's just a phrasing issue? Or perhaps this text is a bit old and OBE? (I mean that initial hopes that we initiate work to to encrypt e.g. Subject seem to be currently moribund.) 3.2.2: I'm not sure the bullet list here is a good idea. E.g. it omits DKIM related things and SPF related things. Maybe check with some anti-spam folks if keeping this list? 3.3: I wondered if this section would be better reorganised into a structure based on where the keys are located. Not sure but that might be a clearer way to distinguish the various kinds of encrypted storage. (Feel free to ignore this suggestion if it doesn't resonate.) 3.3.1: I found this sub-section confusing and not useful. Would suggest simplifying it a lot. The term "burst data" isn't that clear. - section 4: Is "for Enterprise Users" right here? - 4: "harder to break" is not relevant here - at least in terms of algorithms, which is what that'd be interpreted as far as to mean. If you mean that non FS mechanisms (e.g. RSA key transport) provide more opportunity for decryption at places other than the endpoint at which the applications calls for decryption, but that we increasingly do want to see more use of FS mechanisns, and that that's a tension, then maybe say that. - 4.1: Not sure "static" is quire right - I think what you mean is replicated TLS server RSA private keys. - 4.1.1: "Enterprise users are subject to the policies of their organization." That is jurisdiction-dependent - at least in some countries (e.g. Ireland) the enterprise cannot breach employment laws that can touch on employee privacy. Such jurisdictional issues can work both ways of course, either re-inforcing privacy or calling for privacy to be eroded even more than the enterprise would wish. Suggest adding "... and the jurisdictions in which the enterprise operates" to cover both;-) - 4.1.1: "These functions are critical to security and fraud monitoring." I don't accept that this is true of all the numbered elements in the list. Supposed countermeasures for IP leakage for example are often ineffective (though vendors who sell such things will doubtless disagree;-). I'd say toning that down a bit would be right, e.g. s/are criticial/ are often consided important/. - 4.1.2: Mention of PDM reminds me that that has had a pretty thorough discussion related to the secdir review and issues relevant to this draft. Incorporating a description of that history would maybe be useful so that we have less pain when we re-do that in future for other protocols. - 4.1.3: I don't accept "impossible" is correct. If we wanted to say that, we'd need evidence, e.g. via a set of references. "More onerous" would be fine if that's all we need to say. A number of other similar changes are needed for the text in 4.1.3.x as well, e.g.: - 4.1.3.1: "requires" is overstated, and what evidence is there for "frequently used"? I don't accept either assertion without evidence. - 4.1.3.x: there are more of the above that need fixing - 4.2, 2nd para: A lot of this is duplicative of earlier text. - 4.2: "unique and efficient vantage point" that's sales language and doesn't belong here. - 5.1: "TLS over SMTP" again a couple of times - 5.2: Is I-D.teague.. the right reference here? I'd have thought there was an ipfix RFC already that'd be good here. - 5.6: "has quickly reacted to" is sales language and doesn't belong. - 5.6: What is "[not BCP84]" as a reference? And I'm not sure why RFC2504 is a good reference here either. Are we talking about BCP38 but someone forgot to update text written from memory or something? :-) - 5.6: SAVI was only chartered for enterprise networks iirc. - 5.7: THe [SACM] reference is odd and has no entry in section 12. - 6.1: Are those "notable exceptions" still relevant? I'd say maybe not. - 6.1: Is the Alt-SVC description correct? I'm not sure. I suggest you ask an HTTP person maybe. That could also do with some references. - 6.1: "... to be blocked" makes some assumptions about what's ok/right that are not needed, "being requested" would be better. - section 7: "efforts to prevent it" - which it? And I don't think prevent is what you mean, unless you're moving into the "what the spooks want" territory and away from "what network managers need" which'd seem out of scope. I think that needs rephrasing. - section 7: "National surveillance programs" is not the right phrase. Maybe just "Law enforcement agencies..." - 7: please drop the various uses of "cyber" again;-) - 7: David Cameron seems to no longer act in that role. - 7: "avoid the fears of terrorism" is wrong - fears will exiat and be propogated by various actors regardless. And understanding technology won't help there. I think the fear you mean is that technolgoy will be abused by bad actors. - 7: The text seems to assume that all governments are equally ok and that they all like one another equally. I dont believe that is the case, so there are additional categories of bad actor that are missing here. I also find the frequency of the occurrence of "terror" to be higher than needed. (That is a scare-word best omitted when not needed.) - 7: I think a reference to the workshop held in Wash. DC last year (maybe June?) on whether or not magic solutions for LEAs can exist here may be useful. Some IETFers attended, and it covered these issues in a lot more depth than could be fitted here but I don't have the reference to hand. (Spoiler: there is no magic;-) - 7, last para; I'd recommend deleting this. When and if PIR methods are usable they will create as many issues as the solve, from the perspective of this document. - section 11: Is this useful? If not, it ought be deleted. If so, then it should be a section of its own on mobile networks and not an appendix. (I'll comment assuming that keeping the text is better, but I'm not sure it is, given the amount of context it may need.) - 11.1: What is an ACK stream? A reference or description is needed. "Prevents" needs justification (possibly via reference) - 11.1: eNodeB needs a reference, KPI/KQI need expansion, CEM needs describing or a reference. What is a "sector"? And (in this context) what is "a server"? APN needs a reference. - 11.1: "trusted parties" is unclear - you need to say what is trusted by whom for what actions for this to be useful. - 11.1: DRM/QOE need expansion and a reference to justify the claim wrt *maximising* QOE. - 11.1: "Trusted proxy" - see above wrt term trusted. But in this case, the term is misleading and ought not be used as there seems to be no way in which the entity who needs to trust the proxy can know that that proxy exists. Please drop that term entirely. (Call it a TLS-MitM attacker if you must, as that is what it is and that is how such things were referred to earlier in this document.) There are two occurrences of that misldeading marketing term to remove. - 11.1: RAN needs expansion and "RAN-aware pacing" needs explanation and/or reference. - 11.2: What is meant here by "Transport header"? TCP mostly doesn't have this issue, so I assume this is looking forward to QUIC. I'd argue that if so, this text should be deleted as we now have a WG for QUIC which is specifically chartered to address these issues. If this is not about QUIC, then please elaborate. - 11.2: ANDSF needs a reference - 11.2: SON and MLB need references - 11.2: UPCON needs a reference, off-peak acceleration and outbound roamers need explanation and/or reference - 11.2: DSCP needs a reference - 11.3: RCS, QCI, LTE need rererences - 11.3: eMBMS needs a reference, see above wrt "trusted" - 11.3: Asserting that TLS is not necessary for DRM'd content is arguable and not blatently true, as asserted here. - 11.4: see above wrt "trusted." - 11.4: QAM, CS-Voice need references - 11.4: PGW, GGSN need references - 11.4; "GW" needs explanation and/or a reference - 11.4: "Decreasing Client-Server control loop requires deploying CDNs/Cloud functions that terminate encryption closer to the edge." I don't accept that "requires" is clearly true. Please justify e.g. via reference. Or maybe re-phrase so that the statement is clearly true but doesn't have gigantic implications for who is allowed to deploy what. (Or maybe I'm confused by what is meant here?) - 11.4: s/de-encryt/decrypt/ - 11.4: MEC needs a reference, see above wrt "trusted proxy" - 12.1: I agree with the shepherd that all the references here can be informative and you don't need 2119. - 12.2: URLs like that used for CAIDA aren't great for RFCs - better to find a better reference where that's easy (which it is in that case). I'm less sure about how best to deal with the Intercept and EFF, but if you search in scholar.google.com you may find other references for that content that are easier to use. (The issue here being reference stability.) - 12.2: [homomophic] needs a better reference if it stays, e.g. Gentry's PhD or something. - 12.2: various references need to be updated. I-D nits will help you there - 12.2: I'm sure you'll agree that [TOR] isn't right as-is:-)
- [saag] AD sponsoring Effect of Ubiquitous Encrypt… Stephen Farrell
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Stephen Farrell
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Kathleen Moriarty
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Stephen Farrell
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Kathleen Moriarty
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Julien ÉLIE
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Eliot Lear
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Kathleen Moriarty
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Kathleen Moriarty
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Viktor Dukhovni
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Kathleen Moriarty
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Salz, Rich
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Viktor Dukhovni
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Julien ÉLIE
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Kathleen Moriarty
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Kathleen Moriarty
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Kathleen Moriarty
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Viktor Dukhovni
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Viktor Dukhovni
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… kathleen.moriarty.ietf
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Margaret Cullen
- Re: [saag] AD sponsoring Effect of Ubiquitous Enc… Kathleen Moriarty