idnits 2.17.1 draft-carpenter-prismatic-reflections-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 110: '...hat probably use MAY instead of SHOULD...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2013) is 3869 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-hallambaker-httpsession-01 == Outdated reference: A later version (-01) exists of draft-hallambaker-prismproof-req-00 == Outdated reference: A later version (-02) exists of draft-johnston-rtcweb-zrtp-00 == Outdated reference: A later version (-01) exists of draft-trammell-perpass-ppa-00 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 General B. Carpenter, Ed. 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational September 19, 2013 5 Expires: March 23, 2014 7 Prismatic Reflections 8 draft-carpenter-prismatic-reflections-00 10 Abstract 12 Recent public disclosure of allegedly pervasive surveillance of 13 Internet traffic has led to calls for action by the IETF. This draft 14 exists solely to collect together a number of possible actions that 15 were mentioned in a vigorous discussion on the IETF mailing list. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 23, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Suggestions Made . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 55 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 56 6. Informative References . . . . . . . . . . . . . . . . . . . . 8 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 1. Introduction 61 Recent public revelations about PRISM, the alleged pervasive 62 collection and analysis of Internet traffic, including various forms 63 of metatdata, are perhaps not surprising to those who recall ECHELON 64 and the background to [RFC1984] and [RFC2804]. However, public 65 knowledge that such activities are not only possible but allegedly 66 widespread has renewed concerns about Internet surveillance and 67 privacy. It is further alleged that some encryption systems widely 68 regarded as reasonably safe have been compromised (https:// 69 www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html). 71 A call for IETF action has been made at http://www.theguardian.com/ 72 commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying. 73 Bruce Schneier states that "we need open protocols, open 74 implementations, open systems - these will be harder for the NSA to 75 subvert" and suggests that the IETF "needs to dedicate its next 76 meeting to this task. This is an emergency, and demands an emergency 77 response." 79 It is in fact alleged that the surveillance and compromised 80 encryption are not mainly the result of defective standards, but 81 rather of manufacturers and carriers being suborned. Whether it's a 82 real emergency can be debated. Nevertheless, it seems reasonable to 83 discuss what the IETF could do better, in its specifications, to 84 improve the protection of privacy, confidentiality and integrity of 85 Internet traffic. With that in mind, the only purpose of this draft 86 is to record a number of actionable ideas that have been mentioned in 87 recent contributions to the IETF list. "Actionable" means that, in 88 the editor's view, they suggest concrete actions that the IETF could 89 take as part of its work in developing and improving Internet 90 technical specifications. There is no intention to imply that these 91 ideas are good, bad or indifferent, and certainly other ideas have 92 been and will be proposed. Important suggestions may have been 93 missed: these are simply the ones that caught the editor's eye, and 94 they do not represent the outcome of an organised discussion or any 95 kind of consensus. The contributions are presented essentially 96 unedited (but abbreviated or truncated) and without further comment. 97 Where a contribution led to discussion, that can be found in the 98 mailing list archive. 100 This draft might be revised once or twice before IETF 88, but there 101 are no plans for it beyond then. The editor is aware that prisms 102 normally refract light rather than reflect it, but in this case, we 103 are seeing reflections from a PRISM. 105 2. Suggestions Made 107 o We certainly need to apply RFC 3552. (Brian Carpenter) 108 o This list (http://www.nytimes.com/interactive/2013/09/05/us/ 109 unlocking-private-communications.html) includes a lot of IETF work 110 that probably use MAY instead of SHOULD for some key choices. 111 (Lucy Lynch) 112 o S/MIME is almost what we need to secure email. What is missing is 113 an effective key discovery scheme. We could add that and add Ben 114 Laurie's Certificate Transparency and have a pretty good start on 115 a PRISM Proof email scheme. ... 117 So that means that we have to have a key distribution 118 infrastructure such that when you register a key it becomes 119 available to anyone who might need to send you a message. We 120 would also wish to apply the Certificate Transparency approach to 121 protect the Trusted Third Parties from being coerced, infiltrated 122 or compromised. Packaging the implementation is not difficult, a 123 set of proxies for IMAP and SUBMIT enhance and decrypt the 124 messages. The client side complexity is separated from the proxy 125 using Omnibroker. ... 127 We do have several areas where we could make significant advances 128 however: 130 1) Technical improvements to TLS such as recommending sites turn 131 on PFS by default and remove weak ciphers. 133 2) Stop sending authentication cookies in the clear whether or not 134 they are sent inside an encrypted tunnel 135 ([I-D.hallambaker-httpsession]). 137 3) Fix the missing 5% that stops people using secure email. We 138 have PGP that has mindshare and S/MIME that has deployment and 139 both are too much trouble for most IETF people to use, let alone 140 the typical Internet user. We can and should fix that. (Phill 141 Hallam-Baker) 143 Also see [I-D.hallambaker-prismproof-req]. 144 o Encrypting everything on the wire raises the cost for untargeted 145 mass surveillance significantly. And that is what it is all 146 about. And best is of course if this can be end to end, though 147 hiding metadata requires either something onion like or transport 148 encryption by layers below said metadata. (Martin Milnert) 149 o I think we can do more. Some examples: 151 * we're having a discussion in http 2.0 work whether encryption 152 should be mandatory 153 * the perpass list has talked about understanding better where 154 fingerprinting is an issue with IETF protocols 156 * maybe it would be time to start having specs say that 157 implementations must refuse older, weak algorithms 159 * we could do more analysis and review to understand where the 160 weak points and development opportunities are -- too early to say 161 there are none (Jari Arkko) 162 o I just recently produced a short writeup about the efforts related 163 to this topic ongoing at the last IETF meeting on my blog: 164 http://www.tschofenig.priv.at/wp/?p=993. (Hannes Tschofenig) 165 o One way to frustrate this sort of dragnet surveillance would be to 166 reduce centralization in the Internet's architecture. Right now, 167 the way the Internet works in practice for private individuals, 168 all your traffic goes up one pipe to your ISP. It's trivial to 169 tap, since the tapping can be centralized at the ISP end. [If 170 the] IETF focused on developing protocols (and reserving the 171 necessary network numbers) to facilitate direct network peering 172 between private individuals, it could make it much more expensive 173 to mount large-scale traffic interception attacks. (Adam Novak) 174 o There is a whole bunch of stuff we can do to make transit traffic 175 less observable. In other words we can modify things so the only 176 think you know about a packet is where it is going, not what it is 177 or who it came from. ... 179 Clearly, we have a lot of specification work ongoing in different 180 areas that helps to mitigate various security vulnerabilities. 181 This ranges from recent work on XMPP end-to-end security (as in 182 [I-D.miller-3923bis]) all the way to the recent RTCWEB discussions 183 on using DTLS-SRTP as a key management protocol.(Stewart Bryant) 184 o We setup the perpass list 185 as a venue for 186 triaging specific proposals in this space. A few weeks in, we 187 have [I-D.trammell-perpass-ppa] that tries to describe a threat 188 model that matches the recent revelations, and that could be a 189 good reference when folks are developing protocols. 191 We have found volunteers to write a draft for a BCP on how to use 192 perfect forward secrecy in TLS, more common use of which (we still 193 think) would mitigate a bunch of the ways in which TLS traffic 194 could be subverted, given various forms of collusion/coercion. 195 (Stephen Farrell) 196 o If we took protection against MitM attacks seriously, we would be 197 using ZRTP for RTCWEB instead of DTLS-SRTP. See 198 [I-D.johnston-rtcweb-zrtp]. (Alan Johnston) 200 o I think we need to separate the concept of end-to-end encryption 201 from authentication when it comes to UI transparency. We design 202 UIs now where we get in the user's face about doing encryption if 203 we cannot authenticate the other side and we need to get over 204 that. In email, we insist that you authenticate the recipient's 205 certificate before we allow you to install it and to start 206 encrypting, and prefer to send things in the clear until that is 207 done. That's silly and is based on the assumption that encryption 208 isn't worth doing *until* we know it's going to be done completely 209 safely. We need to separate the trust and guarantees of safeness 210 (which require *later* out-of-band verification) from the whole 211 endeavor of getting encryption used in the first place. (Pete 212 Resnick) 213 o One thing that would be helpful is to encourage the use of Diffie- 214 Hellman everywhere. ... Using TLS with DH to secure SMTP 215 connections is valuable even if it is subject to MITM attacks, and 216 even if the NSA/FBI can hand a National Security Letter to the 217 cloud provider. (Ted Ts'o) 218 o And I think that one of the more important things we can do is to 219 rethink UIs to give casual users more information about what it 220 going on and to enable them to take intelligent action on 221 decisions that should be under their control. There are good 222 reasons why the IETF has generally stayed out of the UI area but, 223 for the security and privacy areas discussed in this thread, there 224 may be no practical way to design protocols that solve real 225 problems without starting from what information a UI needs to 226 inform the user and what actions the user should be able to take 227 and then working backwards. (John Klensin) 228 o What we should probably be thinking about here is: 230 - Mitigating single points of failure (IOW, we _cannot_ rely on 231 just the root key) 233 - Hybrid solutions (more trust sources means more work to 234 compromise) 236 - Sanity checking (if a key changes unexpectedly, we should be 237 able to notice) 239 - Multiple trust anchors (for stuff that really matters, we can't 240 rely on the root or on a third party CA) 242 - Trust anchor establishment for sensitive communications (e.g. 243 with banks) (Ted Lemon) 244 o We could be telling the public about the protocols that we 245 designed 10, 15, and even 20 years ago. Some of which even have 246 rather widespread implementation, but seem to have zero use. 247 (S/MIME is in every copy of Outlook and Thunderbird, AFAIK) 248 What would the spam situation be like if 90% of emails were 249 regularly signed back in 1999? Yes, and DKIM can sign message 250 bodies now too. We should be telling people about it. 252 Use this stuff ourselves!!!! (Michael Richardson) 253 o In other words, the IETF needs to assume that we don't know what 254 will work for end users and we need to therefore focus more on 255 processing by end systems rather than end users. (Dave Crocker) 256 o In effect, DANE exchanges one trust model for another. I happen 257 to believe that the damage risque is lower with DNSSEC + DANE than 258 the traditional "any CA can issue a certificate for any domain 259 name" setup. ... 261 Audit and open source seem to be good starting points. (Mans 262 Nilsson) 263 o There was actually a proposal a couple of weeks back in the WG to 264 encrypt all traffic on the inter-xTR stage [in the LISP protocol]. 265 (Noel Chiappa) 266 o Review all key length recommendations and make them larger and 267 strongly recommend not using any shorter than . While the 268 reports are probably true that NSA can break common algorithms, 269 making the key length longer will make it harder to do it in 270 scale. 272 Move to real end to end security where key are shared via a 273 different communication path. Perhaps like PGP. 275 Remove man in the middle attacks on common protocols like SSL/TLS. 276 This is a giant problem, some people sell products that view this 277 as a feature (including my employer). This is part of a general 278 problem of middle boxes that change content, but can be fixed if 279 we make sure they can't alter the secure content. 281 Make everything run over secure paths. Even things like the DNS 282 and ICMP. Perhaps if we can secure ICMP, it will mean that middle 283 boxes will stop dropping things like PMTU discovery packets. (Bob 284 Hinden, in private mail, included with permission). 285 o It is a shame that this opportunity was not taken to highlight the 286 need for authentication. Having a totally secure channel with 287 perfect encryption is of little value if the other end of the 288 channel is a hostile power. (Tom Petch) 290 3. Security Considerations 292 See above. Also, an observation by Hannes Tschofenig seems relavant: 294 While we are able to fill gaps in security protocols fairly quickly 295 we don't always seem to make the right choices because the interests 296 of various participants are not necessarily aligned. In general, we 297 seem to develop an insecure version and a secure version of a 298 protocol. Unfortunately, the insecure version gets widely deployed 299 and we have an incredible hard time to introduce the secure version. 301 In addition to the specification work we could think about how to 302 reach out to the broader Internet ecosystem a bit better. Since we 303 have lots of folks in the IETF I don't think it is an impossible task 304 but it might require a bit of coordination. Right now would be a 305 good time to launch some of those initiatives since most people 306 currently understand the need for security. 308 4. IANA Considerations 310 This document requests no action by IANA. 312 5. Acknowledgements 314 The ideas are credited above. 316 This document was produced using the xml2rfc tool [RFC2629]. 318 6. Informative References 320 [I-D.hallambaker-httpsession] 321 Hallam-Baker, P., "HTTP Session Management", 322 draft-hallambaker-httpsession-01 (work in progress), 323 May 2013. 325 [I-D.hallambaker-prismproof-req] 326 Hallam-Baker, P., "PRISM-Proof Security Considerations", 327 draft-hallambaker-prismproof-req-00 (work in progress), 328 September 2013. 330 [I-D.johnston-rtcweb-zrtp] 331 Johnston, A., Zimmermann, P., Callas, J., Cross, T., and 332 J. Yoakum, "Using ZRTP to Secure WebRTC", 333 draft-johnston-rtcweb-zrtp-00 (work in progress), 334 August 2013. 336 [I-D.miller-3923bis] 337 Miller, M. and P. Saint-Andre, "End-to-End Object 338 Encryption for the Extensible Messaging and Presence 339 Protocol (XMPP)", draft-miller-3923bis-02 (work in 340 progress), June 2010. 342 [I-D.trammell-perpass-ppa] 343 Trammell, B., "The Perfect Passive Adversary: A Threat 344 Model for the Evaluation of Protocols under Pervasive 345 Surveillance", draft-trammell-perpass-ppa-00 (work in 346 progress), September 2013. 348 [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG 349 Statement on Cryptographic Technology and the Internet", 350 RFC 1984, August 1996. 352 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 353 June 1999. 355 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 356 May 2000. 358 Author's Address 360 Brian Carpenter (editor) 361 Department of Computer Science 362 University of Auckland 363 PB 92019 364 Auckland, 1142 365 New Zealand 367 Email: brian.e.carpenter@gmail.com