idnits 2.17.00 (12 Aug 2021) /tmp/idnits57845/draft-tschofenig-perpass-surveillance-01.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 7 instances of too long lines in the document, the longest one being 2 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 (November 04, 2013) is 3113 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-avtcore-rtp-security-options has been published as RFC 7201 == Outdated reference: draft-ietf-avt-srtp-not-mandatory has been published as RFC 7202 == Outdated reference: A later version (-02) exists of draft-sheffer-tls-bcp-01 ** Obsolete normative reference: RFC 1543 (ref. '21') (Obsoleted by RFC 2223) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PERPASS H. Tschofenig 3 Internet-Draft 4 Intended status: Informational November 04, 2013 5 Expires: May 08, 2014 7 Tackling Pervasive Surveillance or How to improve Security of the 8 Internet? 9 draft-tschofenig-perpass-surveillance-01.txt 11 Abstract 13 Surveillance is the observation or monitoring of an individual's 14 communications or activities. Surveillance is one of several privacy 15 /security threats engineers try to take into account in their 16 designs. The reports about pervasive monitoring of Internet traffic 17 have, however, surprised many since the scale was not envisaged 18 during the design of many Internet protocols even though the ambition 19 to offer end-to-end security on the Internet dates back even to the 20 70ies. The approach to get access to meta-data as well as to 21 communication content has taken forms that are largely 22 indistinguishable from ordinary attacks. 24 This document explains the attacks in context of the larger Internet 25 eco-system. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 08, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Attack Surface . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Cryptographic Primitives . . . . . . . . . . . . . . . . 3 64 2.2. Protocols and Architecture . . . . . . . . . . . . . . . 4 65 2.3. Implementations . . . . . . . . . . . . . . . . . . . . . 5 66 2.4. Deployment . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 70 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Securing the Internet is a rather complicated task since the threat 76 landscape has changed significantly over the last 20 years. For many 77 of the recognized security weaknesses solutions have been developed 78 and standardized. Unfortunately, the existence of specifications by 79 itself is not enough: security protocols need to be implemented and 80 deployed. Since many of the tougher security challenges suffer from 81 a collective action problem it typically takes many years until 82 widespread deployment has been reached (typically requiring 83 sufficient energy and enough pain). The recently observed pervasive 84 monitoring activities represent a new challenge to the Internet 85 community and require us to review and revisit some earlier design 86 decisions. 88 To fully understand the role of the IETF in this context it is useful 89 to look at the types of attacks that are occurring. It quickly 90 becomes clear that the development of many countermeasures is 91 entirely within scope of the IETF. But the deployment and use is 92 outside out scope, and requires interactions with the larger Internet 93 eco-system. 95 2. Attack Surface 97 The attack surface is categorized into four areas, as shown in Figure 98 1. In subsequent sections more details are provided and examples are 99 listed. 101 +-----------------+ +---------------+ +----------------+ +------------+ 102 | | | | | | | | 103 | Aging or Broken | | Weak | | Implementation | | Insecure | 104 | Cryptographic | | Protocol or | | Bugs and other | | Deployment | 105 | Primitives | | Architectural | | Vulnerabilities| | Practices | 106 | | | Foundation | | | | | 107 +-----------------+ +---------------+ +----------------+ +------------+ 109 Figure 1: Attack Surface. 111 2.1. Cryptographic Primitives 113 Internet security relies on sound cryptographic primitives, such as 114 hash functions, random number generators, integrity and encryption 115 algorithms, etc. The basic design philosophy is that the strength of 116 keyed algorithms relies on the length of the secret/private key. It 117 is well-known that these cryptographic primitives "age" as processing 118 power of computing hardware increases. This means that over time it 119 is faster to search through the key space with the same amount of 120 financial budget spent. (Note: How much of the key space an 121 adversary has to search depends on a number of factors. Due to the 122 birthday paradoxon it has to search on average 1/2 of the key space. 123 It can actually be much lower when lower entrophy secrets are used, 124 such as passwords.) Researchers have also made improvements in 125 analyzing the building blocks of these algorithms and new attack 126 techniques (such as side channel attacks). This has lead to a 127 continued development of new cryptographic primitives. 129 The IETF has played a minor role in the work on cryptographic 130 primitives. Instead, it has been a consumer of these building blocks 131 and has therefore relied on others to select specifications and to 132 provide guidance. As an exception one could see the publication of 133 HMAC [20]. In fact, the crypto-community world-wide is rather small 134 and for a variety of reasons the National Institute of Standards and 135 Technology (NIST) has spearheaded many of these developments. The 136 IETF security community has relied on NIST to provide guidance 137 largely because no other groups have come forward to offer advice. 139 While there have been problems with weaknesses in cryptographic 140 primitives (e.g., RC4 [1], [2], [3]) those have not been a 141 substantial issue from a standardization point of view thanks to 142 'crypto-agility'. (Note that RC4 is not a NIST standard.) Crypto- 143 agility is the ability of a protocol to adapt to evolving 144 cryptographic algorithms and security requirements. This includes 145 provisions that allow security protocols to adopt different 146 cryptographic algorithms without substantial disruption to deployed 147 implementations. This does not mean the implementation is unchanged 148 and, of course, the need for backwards compatibility creates 149 downgrade attacks. 151 Rumors about backdoors in specific elliptic curves, and random number 152 generators have created some uncertainty about what algorithms are 153 'safe' to use. The crypto-community is still debating about the 154 validity of these claims and investigating about how long weaknesses 155 in standards should have been known to experts. 157 2.2. Protocols and Architecture 159 Internet protocols and communication architectures belong to the core 160 expertise of the IETF. While security experts have been around in 161 the early days of the IETF the security community grew over time 162 after security considerations sections became a mandatory part of 163 IETF specifications [21]. The overall understanding of security is 164 still increasing thanks to education efforts, reviews from the 165 security area directorate, and the push back from the IESG when 166 questionable documents arrive. 168 Still, there are a number of challenges. For example, cryptographic 169 attacks like BEAST [5], CRIME [6], and Lucky Thirteen [4] targeted 170 the Transport Layer Security (TLS) protocol when specific algorithms 171 are used with specific application layer protocols (such as HTTP). 172 More difficult to deal with are security and privacy challenges with 173 entire protocols architectures, as the design of email, instant 174 messaging, voice over IP (VoIP), DNS, DHCP, etc. demonstrate. Often, 175 insecure versions of a protocol are standardized and completed first 176 before the secure version is developed. For example, consider 177 security for HTTP, SIP, XMPP, eMail, etc. While this may not have a 178 consequence on paper it certainly impacts follow-up implementations 179 and deployments. Section 8 of [19] provides an interesting summary 180 of the design tradeoffs that had been made in the real-time 181 communication architecture as used by VoIP and instant messaging. 182 The difficulty is often not in crafting a security solution at the 183 level of a single specification, but rather ensuring that the 184 protocol development of an entire communication architecture provides 185 good security and privacy properties after many years of 186 standardization when various different industry trends (such as cloud 187 computing, and the JavaScript-based Web), and the interests of 188 participating parties re-shape the original design goals. 189 Furthermore, often the attention is paid on protecting the payload of 190 the content only and meta-data is exposed to service providers and 191 other parties, particularly with server-centric communication 192 architectures. 194 In many cases, the implications of certain design decisions are 195 subtle. Two examples are: 197 Cookies: For example, the excitement of Web companies to use HTTP 198 cookies [23], [22] as a replacement for cryptographic 199 authentication was hard to anticipate. 201 VoIP Media Security: The large number of key exchange mechanisms 202 standardized for VoIP (see [16], [17], [15]) might have provided 203 ways to fulfill needs of different deployment scenarios but 204 certainly confused the industry and didn't increase 205 interoperability. New VoIP security authentication protocols are 206 still proposed today. 208 Another example for an architectural weakness can be found with the 209 public key infrastructure (PKI) when the limitations of the PKI 210 became apparent in 2011: DigiNotar, a Dutch certification authority, 211 had a security breach and in the same year a Comodo affiliate was 212 compromised. Both cases lead to fraudulent issue of certificates 213 allowing man-in-the-middle attacks on TLS secured data Web 214 interactions. There have been claims that the same architectural 215 vulnerability has been exploited by the National Security Agency 216 (NSA) in man-in-the-middle attacks [14]. 218 Improving security and privacy for different communication protocols 219 has been subject of discussion on the IETF perpass list [9]. Note 220 that some discussions go beyond suggesting actions for the IETF; they 221 belong to the discussion in Section 2.3 and Section 2.4. As another 222 example of ongoing work is a document on best current practices for 223 Transport Layer Security [18], which gathers experience from recent 224 security attacks and recommends state-of-the-art ciphersuites. 226 2.3. Implementations 228 Once standardization work is completed the specifications have to be 229 implemented. Often those who develop the specifications are not 230 necessary the same parties who implement the software. The 231 specifications therefore have to offer enough context and be readable 232 to avoid security problems via misinterpretation. Also, those who 233 implement and those who deploy are also not necessarily the same set 234 of people. For example, some developers write open source libraries 235 useful for a wide range of communities, as it is the case with 236 OpenSSL or GnuTLS. Note: This description is rather simplified 237 version of the typical IETF protocol development. In many cases, the 238 development process is not linear since protocols are implemented 239 while they are specified and implementation results are fed back into 240 the standardization effort. Still, for many successful protocols 241 implementations the number of those involved in implementations far 242 exceeds the number of standardization participants. 244 Implementations may show a number of security weaknesses, such as 245 lack of security features, quality of the implementations (e.g., 246 implementations with insufficient penetration testing), weak pseudo- 247 random number generators [7], [10], etc. Since the source code of 248 many implementations is not available to the public, backdoors may be 249 built-in, as it was rumored with [8]. 251 Many implementations of Web applications, however, suffer from basic 252 vulnerabilities (such as injection or cross-site scripting attacks), 253 as the top-10 charts of the Open Web Application Security Project 254 (OWASP) reveal [12]. Sometimes vendors make design decisions for 255 their product implementations that lead to security vulnerabilities, 256 for example when devices are shipped with default-passwords or with 257 enabled debugging interfaces [13]. 259 2.4. Deployment 261 Finally, implementations of various protocols are put together and 262 complete systems are deployed. Those who deploy have to make 263 decisions that go beyond pure protocol aspects; for example, they 264 have to consider various configuration options. These deployment 265 decisions have an important impact on the provided privacy and 266 security properties. Examples include, backend server protocols 267 secured only with "physical security" (i.e., without cryptographic 268 security protection), email services without TLS protection, custom 269 security designs (see, for example, WhatsApp [11]), etc. Depending 270 on the jurisdiction within which a service is provided, those who 271 deploy systems may assume certain for data retention, and support for 272 lawful intercept. 274 3. Security Considerations 276 This entire document focuses on security. 278 4. IANA Considerations 280 This document does not require actions by IANA. 282 5. Acknowledgments 284 I would like to thank the IAB for encouraging me to turn my IAB- 285 internal presentation into a document. I would also like to thank 286 Stephen Kent, Rene Struik, and Linus Nordberg for their detailed 287 reviews. 289 6. Normative References 291 [1] Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the 292 Key Scheduling Algorithm of RC4", Selected Areas in 293 Cryptography , 2001. 295 [2] ISOBE, T., OHIGASHI, T., WATANABE, Y., and M. MORII, "Full 296 Plaintext Recovery Attack on Broadcast RC4", International 297 Workshop on Fast Software Encryption , 2013. 299 [3] AlFardan, N., Bernstein, D., Paterson, K., Poettering, B., 300 and J. Schuldt, "On the Security of RC4 in TLS", Usenix 301 Security Symposium 2013, 2013, . 304 [4] AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking 305 the TLS and DTLS Record Protocols", IEEE Symposium on 306 Security and Privacy , 2013. 308 [5] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS", 309 2011, . 312 [6] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty 313 Security Conference 2012, 2012. 315 [7] Ars Technica, "Stop using NSA-influenced code in our 316 products, RSA tells customers", URL: http:// 317 arstechnica.com/security/2013/09/stop-using-nsa-influence- 318 code-in-our-product-rsa-tells-customers/, Sep 2013. 320 [8] Boing Boing, "Anti-Tor malware reported back to the NSA", 321 URL: http://boingboing.net/2013/08/05/anti-tor-malware- 322 reported-back.html, Aug 2013. 324 [9] IETF, "PERPASS Mailing List", URL: https://www.ietf.org/ 325 mail-archive/web/perpass/current/maillist.html, Oct 2013. 327 [10] Nadia Heninger, "New research: There's no need to panic 328 over factorable keys-just mind your Ps and Qs", URL: https 329 ://freedom-to-tinker.com/blog/nadiah/new-research-theres- 330 no-need-panic-over-factorable-keys-just-mind-your-ps-and- 331 qs/, Oct 2013. 333 [11] fileperms Blog, "WhatsApp is broken, really broken", URL: 334 http://fileperms.org/whatsapp-is-broken-really-broken/, 335 Sep 2012. 337 [12] OWASP, "Open Web Application Security Project (OWASP): Top 338 Ten Project", URL: https://www.owasp.org/index.php/ 339 Category:OWASP_Top_Ten_Project, Oct 2013. 341 [13] Wired, "NSA Laughs at PCs, Prefers Hacking Routers and 342 Switches", URL: http://www.wired.com/threatlevel/2013/09/ 343 nsa-router-hacking/, Apr 2013. 345 [14] Zeljka Zorz, "NSA impersonated Google in MitM attacks", 346 URL: https://www.net-security.org/secworld.php?id=15579, 347 Apr 2013. 349 [15] Westerlund, M. and C. Perkins, "Options for Securing RTP 350 Sessions", draft-ietf-avtcore-rtp-security-options-08 351 (work in progress), October 2013. 353 [16] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 354 "Requirements and Analysis of Media Security Management 355 Protocols", RFC 5479, April 2009. 357 [17] Perkins, C. and M. Westerlund, "Securing the RTP Protocol 358 Framework: Why RTP Does Not Mandate a Single Media 359 Security Solution", draft-ietf-avt-srtp-not-mandatory-14 360 (work in progress), October 2013. 362 [18] Sheffer, Y. and R. Holz, "Recommendations for Secure Use 363 of TLS and DTLS", draft-sheffer-tls-bcp-01 (work in 364 progress), September 2013. 366 [19] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 367 Morris, J., Hansen, M., and R. Smith, "Privacy 368 Considerations for Internet Protocols", RFC 6973, July 369 2013. 371 [20] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 372 Hashing for Message Authentication", RFC 2104, February 373 1997. 375 [21] Postel, J., "Instructions to RFC Authors", RFC 1543, 376 October 1993. 378 [22] Williams, N., "Hypertext Transport Protocol (HTTP) Session 379 Continuation: Problem Statement", draft-ietf-websec- 380 session-continue-prob-00 (work in progress), July 2013. 382 [23] Tschofenig, H., Turner, S., and M. Hanson, "An Inquiry 383 into the Nature and the Causes of Web Insecurity", draft- 384 tschofenig-secure-the-web-04 (work in progress), October 385 2012. 387 Author's Address 389 Hannes Tschofenig 391 Email: Hannes.Tschofenig@gmx.net