idnits 2.17.1 draft-moonesamy-traffic-peeking-03.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 is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 25, 2014) is 3625 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Jervis' is defined on line 299, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1725 (ref. 'RFC1939') (Obsoleted by RFC 1939) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Moonesamy 3 Intended Status: Informational 4 Expires: November 26, 2014 May 25, 2014 6 Traffic peeking 7 draft-moonesamy-traffic-peeking-03 9 Abstract 11 In June 2013, a news article revealed that the National Security 12 Agency obtained direct access to the systems of several service 13 providers from the United States through an undisclosed surveillance 14 programme called PRISM. This document discusses about the practice 15 of traffic peeking. 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), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright and License Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Traffic peeking . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. IETF Protocols without encryption . . . . . . . . . . . . . 4 59 3.2. Encrypting traffic . . . . . . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7.1. Informative References . . . . . . . . . . . . . . . . . . 6 65 Appendix A: Electronic Surveillance . . . . . . . . . . . . . . . 9 66 Appendix B: Implementation of the Dual Elliptic Curve DRBG . . . . 10 67 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Acknowledgements 71 The author would like to thank Iain Ross Learmonth for his review and 72 contributions to this document. 74 2. Background 76 In June 2013, a news article [Guar1] revealed that the (United 77 States) National Security Agency obtained direct access to the 78 systems of several service providers from the United States through 79 an undisclosed surveillance programme called PRISM [Guar2][Europa]. 80 The surveillance programme intercepted traffic flowing through 81 communication links used throughout the world. According to a news 82 article published in October 2013, the National Security Agency had 83 also been wiretapping traffic flowing through private networks 84 between the datacenters used by Google and Yahoo [Wash1]. According 85 to a news article [Guar3] millions of Yahoo webcam images were 86 intercepted by GCHQ. Between 3% and 11% of the Yahoo webcam imagery 87 harvested contained "undesirable nudity". 89 In 2007, Dan Shumow and Niels Ferguson discussed about the 90 possibility of a backdoor in a Dual Elliptic Curve pseudorandom 91 number generator [Rump] (see Appendix B for more information). In 92 September 2013, the (United States) National Institute of Standards 93 and Technology reported that concern has been expressed about the 94 Dual Elliptic Curve Deterministic Random Bit Generation 95 (Dual_EC_DRBG) algorithm published in one of its standards (SP 800- 96 90/90A) [NIST]. ISO/IEC JTC 1/SC 27 recommended [JTC] that users of 97 the ISO/IEC 18031:2011 standard [ISO8031] take note of the concerns 98 relating to the default application specific parameters that are 99 provided in Annex D of that international standard. According to a 100 news article [Reuters] published in December 2013 RSA received U.S. 101 $10 million in a deal that set the Dual Elliptic Curve Deterministic 102 Random Bit Generation as the preferred, or default, method for number 103 generation in the BSafe software [RSA]. 105 3. Traffic peeking 107 RFC 1958 [RFC1958] states that "it is highly desirable that Internet 108 carriers protect the privacy and authenticity of all traffic, but 109 this is not a requirement of the architecture". "Tussle in 110 Cyberspace: Defining Tomorrow's Internet" [Tussle] states that 111 "peeking is irresistible". Given that most Internet traffic is not 112 encrypted, there isn't any significant barrier to hamper an entity 113 with even modest resources, let alone the resources of a nation's 114 government, to peek on the traffic of Internet carriers. As data 115 storage is becoming rapidly more affordable the next step would be to 116 go beyond traffic peeking and archive all the data. [Tussle] argued 117 that "if there is information visible in the packet, there is no way 118 to keep an intermediate node from looking at it. So the ultimate 119 defense of the end to end mode is end to end encryption". 121 3.1. IETF Protocols without encryption 123 There are several widely deployed IETF protocols which generate plain 124 text (unencrypted) traffic. The specifications of these protocols 125 usually have a Security Considerations section to discuss the 126 security issues. The list of specifications mentioned below lists a 127 selection of IETF protocols vulnerable to traffic peeking but is 128 definitely not an exhaustive list. 130 The File Transfer Protocol (FTP) [RFC0959] is sometimes used for 131 transferring files. The specification does not provide any guidance 132 about encrypting the traffic generated by the protocol. 134 The Hypertext Transfer Protocol (HTTP) [RFC2616] is widely used to 135 access the web. The protocol is sometimes used to provide web 136 access to email. Section 15 of RFC 2616 [RFC2616] does not provide 137 any guidance about encrypting the traffic generated by the protocol. 139 The Internet Message Access Protocol, Version 4rev1 [RFC3501] is 140 widely used to read email messages. Section 11 of RFC 3501 [RFC3501] 141 states that "protocol transactions, including electronic mail data, 142 are sent in the clear over the network unless protection from 143 snooping is negotiated". Details about negotiating encryption are 144 provided; there isn't any recommendation about when encryption 145 should be used. It could be argued that for accessing email, users 146 have an expectation of the privacy of their messages and so 147 encryption should be used unless it is technically or legally 148 infeasible to do so. RFC 3501 does not reflect this. 150 Similarly, the Post Office Protocol, Version 3 [RFC1939] is used to 151 read email messages. Section 13 of RFC 1939[RFC1939] does not 152 provide any guidance about encrypting the traffic generated by the 153 protocol but does acknowledge that "use of the PASS command sends 154 passwords in the clear over the network" and "use of the RETR and TOP 155 commands sends mail in the clear over the network". 157 The Simple Mail Transfer Protocol [RFC5321] is used for sending email 158 messages. Section 7 of RFC 5321[RFC5321] states that "SMTP mail is 159 inherently insecure". It is mentioned in the section that "real mail 160 security lies only in end-to-end methods". 162 3.2. Encrypting traffic 164 Encrypting traffic "might just be the first step in an escalating 165 tussle between the end user and the network provider, in which the 166 response of the provider is to refuse to carry encrypted data" 167 [Tussle][Torrent]. In this case, protocols preferring encryption 168 still have an advantage over those that don't as they can present the 169 user with a warning that it will be necessary to fallback to an 170 unencrypted communication. This allows the user to adjust their 171 expectations of how private a communication will be. 173 The end user relies on the organizations recommending the standards 174 and software vendors as it is not possible for the average person to 175 evaluate whether the encryption mechanism used will protect the 176 traffic from peeking [Apple][Etisal][Mums][Ossl]. It is to be noted 177 that some encryption standards are incorporated by reference in 178 standards used for the Internet [IAB]. There is a brief discussion 179 about electronic surveillance in Appendix A. 181 4. Security Considerations 183 Entities exchanging traffic over the Internet should assume that any 184 traffic which is not encrypted can be intercepted given that peeking 185 is irresistible. There is a risk that encrypted traffic will not 186 provide any protection if it is stored indefinitely as the ability to 187 recover the traffic is preserved [Netcraft]. 189 5. Conclusion 191 The security dilemma exists when "many of the means by which a 192 country tries to increase its security decrease the security of 193 others"[Jervis]. It is up to designers and implementers of a 194 protocol to see whether the encryption standard they use will provide 195 a level of the security which they consider acceptable. Even where 196 it is not possible to use encryption to prevent peeking, 197 recommendations can still be provided to implementers to ensure that 198 there is awareness of the security methods, or lack of, being used to 199 protect the traffic generated by the protocol. 201 It is in the interest of a network provider or a provider of a 202 service to collaborate with the relevant government. The end user 203 will usually be at the losing end of the bargain in a tussle between 204 the end user and government when it is claimed that traffic peeking 205 is a matter of national interest. 207 6. IANA Considerations 209 [RFC Editor: please remove this section] 211 7. References 212 7.1. Informative References 214 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 215 Internet", RFC 1958, June 1996. 217 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 218 9, RFC 959, October 1985. 220 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 221 RFC 1725, November 1994. 223 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 224 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 225 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 227 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 228 2000. 230 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 231 4rev1", RFC 3501, March 2003. 233 [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture 234 for Lawful Intercept in IP Networks", RFC 3924, October 235 2004. 237 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 238 October 2008. 240 [Athens] Prevelakis V. and Spinellis D. "The Athens Affair. IEEE 241 Spectrum 44", July 2007. 243 [Apple] Apple Inc., "About the security content of iOS 7.0.6", 244 February 2014, 246 [Dual] Checkoway S., Fredrikson M., Niederhagen R., Green M., 247 Lange T., Bernstein D. J., Maskiewicz J. and Shacham H., 248 "On the Practical Exploitability of Dual EC in TLS 249 Implementations". 5 , and Hovav Shacham 250 [Etisal] "Etisalat's BlackBerry patch designed for surveillance", 251 July 2009, 254 [ETSI] European Telecommunications Standards Institute, Lawful 255 Interception (LI); Requirements of Law Enforcement 256 Agencies", TS 01 331 V1.3.1, October 2009. 258 [Europa] European Commission, "PRISM scandal: The data protection 259 rights of EU citizens are non-negotiable", June 2013, 260 263 [Fbnz] Facebook, Australia & New Zealand, "Comments on 264 Telecommunications (Interception Capability and Security) 265 Bill", July 2012, 266 268 [Guar1] The Guardian, "NSA Prism program taps in to user data of 269 Apple, Google and others", June 2013, 270 273 [Guar2] The Guardian, "NSA Prism program slides", November 2013, 274 277 [Guar3] The Guardian, "Optic Nerve: millions of Yahoo webcam 278 images intercepted by GCHQ", February 2014, 279 282 [Hunz] Huawei Technologies (New Zealand) Company Limited, 283 "Submission from Huawei Technologies New Zealand Limited 284 on the Telecommunications (Interception Capability and 285 Security)", June 2013, 286 288 [IAB] IAB, "NIST Cryptographic Standards and Development 289 Process", April 2014, 292 [ISO8031] ISO, "ISO/IEC 18031:2011 Information technology -- 293 Security techniques -- Random bit generation", November 294 2011 296 [Java] RSA, The Security Division of EMC, "RSA BSAFE Share for 297 JavaTM Platform", January 2013, 298 299 [Jervis] Jervis R., "Cooperation Under the Security Dilemma", World 300 Politics, Vol. 30, No. 2, January 1978 302 [JTC] ISO, "A Cautionary Note on the Use of ISO/IEC 18031:2011", 303 305 [Mcaf] McAfee, "Patches resolve RSA BSafe Dual Elliptic Curve 306 DRBG algorithm vulnerability - Security Bulletins ID: 307 SB10067", March 2014, 308 310 [Msnz] Microsoft New Zealand Limited, "Comments on 311 Telecommunications (Interception Capability and Security) 312 Bill", June 2013, 313 315 [Mums] Mumsnet, "Mumsnet and Heartbleed as it happened", April 316 2014, 319 [Netcraft] Netcraft, "SSL: Intercepted today, decrypted tomorrow", 320 September 2013, 321 324 [NIST] National Institute of Standards and Technology, "NIST 325 opens draft Special Publication 800-90A, Recommendation 326 for Random Number Generation using Deterministic Random 327 Bit Generators, for review and comment", September 2013, 328 331 [Ossl] OpenSSL Project, "OpenSSL Security Advisory - TLS 332 heartbeat read overrun", April 2014, 333 335 [Reuters] Reuters, "Secret contract tied NSA and security industry 336 pioneer", December 2013, 337 340 [RSA] RSA, The Security Division of EMC, "RSA response to media 341 claims regarding NSA relationship", December 2013, 342 344 [Rump] Shumow D., Ferguson N., "On the possibility of a Back Door 345 in the NIST SP800-90 Dual Ec Prng", August 2007, 346 348 [Torrent] TorrentFreak, "https://torrentfreak.com/uk-internet- 349 filter-blocks-vpns-australia-to-follow-soon-130905/", 350 September 2013, 353 [Tussle] Clark D., Wroclawski J., Sollins K., Braden R., "Tussle in 354 cyberspace: Defining tomorrow's Internet", 2002. 356 [USGov1] United States Government Printing Office, "47 U.S.C. 1008 357 - Payment of costs of telecommunications carriers to 358 comply with capability requirements" 360 [Wash1] The Washington Post, "NSA infiltrates links to Yahoo, 361 Google data centers worldwide, Snowden documents say", 362 October 2013, 363 369 Appendix A: Electronic Surveillance 371 Electronic surveillance is sometimes referred to as "wiretapping". A 372 well-known electronic surveillance case is the Athens affair [Athens] 373 which targeted the conversations of specific, highly placed 374 government and military officials. The scope of that activity is to 375 a large extent unknown. The following is a brief discussion of the 376 topic in IETF RFCs, standards and legislation. 378 The IETF decided not to consider requirements for wiretapping as part 379 of the process for creating and maintaining IETF standards [RFC2804]. 380 It was the belief of the IETF that "in the case of traffic that is 381 today going across the Internet without being protected by the end 382 systems (by encryption or other means), the use of existing network 383 features, if deployed intelligently, provides extensive opportunities 384 for wiretapping". It was noted that "the end systems take adequate 385 measures to protect their communications". 387 It was the belief of the IETF that "mechanisms designed to facilitate 388 or enable wiretapping, or methods of using other facilities for such 389 purposes, should be openly described". RFC 3924 [RFC3924] describes 390 the Cisco Architecture for Lawful Intercept in IP Networks. 392 The European Telecommunications Standards Institute, Technical 393 Committee Lawful Interception (TC LI) [ETSI], publishes standards 394 about lawful interception. The standards specify the network or 395 service protocols necessary to provide handover of lawfully 396 intercepted data and traffic, as well as the physical or logical 397 point at which the interception has to take place (the handover 398 interface) both for packet data and circuit-switched communications. 400 In Europe, the Council Resolution of 17 January 1995 on the lawful 401 interception of telecommunications (96/C 329/01) enables its member 402 states "to conduct the lawful interception of telecommunications", 403 subject to national law and interpreted in accordance with applicable 404 national policies. Most countries have a legal framework which 405 "generally obliges all providers of public electronic communications 406 networks and services to cooperate". This includes the obligation to 407 install interception equipment, usually without compensation. 409 In the United States, the Communications Assistance for Law 410 Enforcement Act requires telecommunications carriers (including 411 broadband Internet access providers and providers of VoIP services) 412 "to ensure that equipment, facilities, or services that allow a 413 customer or subscriber to "originate, terminate, or direct 414 communications," enable law enforcement officials to conduct 415 electronic surveillance pursuant to court order or other lawful 416 authorization". The legislation provides for the payment of costs of 417 telecommunications carriers to comply with capability requirements 418 [USGov1]. 420 Article 3 of the Budapest Convention on Cybercrime about illegal 421 interception requires the countries ratifying the treaty "to adopt 422 such legislative and other measures as may be necessary to establish 423 as criminal offences under its domestic law, when committed 424 intentionally". 426 The New Zealand Parliament updated its legislation about Interception 427 Capability and Security last year. Several entities provided 428 comments about the legislation where it was proposed 429 [Fbnz][Hunz][Msnz]. It is to be noted that the entities operate in 430 several jurisdictions. 432 Appendix B: Implementation of the Dual Elliptic Curve DRBG 434 The Dual EC DRBG was implemented in OpenSSL, an open source general 435 purpose cryptography library, in 2011 at the request of a paying 436 customer. The implementer was "well aware at the time of the dubious 437 reputation of the algorithm". It was mentioned that cryptography in 438 the United States Federal government is heavily constrained by 439 standards [NIST] and vendors selling products to that government 440 don't have much of a choice. RSA BSafe Dual Elliptic Curve DRBG 441 implementation was used in McAfee Software [Mcaf] and Share for Java 442 [Java]. "Depending on the design choices in the implementations, an 443 attacker can recover TLS session keys within seconds on a single CPU 444 or may require a cluster of more than 100,000 CPUs for the same task 445 if a different library is used" [Dual]. 447 Author's Addresses 449 S. Moonesamy 450 76, Ylang Ylang Avenue 451 Quatre Bornes 452 Mauritius 454 Email: sm+ietf@elandsys.com