idnits 2.17.00 (12 Aug 2021) /tmp/idnits15320/draft-tschofenig-perpass-surveillance-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 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 (October 21, 2013) is 3133 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. '22') (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 October 21, 2013 5 Expires: April 24, 2014 7 Tackling Pervasive Surveillance or How to improve Security of the 8 Internet? 9 draft-tschofenig-perpass-surveillance-00.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. The approach to get 19 access to meta-data as well as to communication content has taken 20 forms that are largely indistinguishable from ordinary attacks. 22 This document explains the attacks in context of the larger Internet 23 eco-system. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 24, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Attack Surface . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Cryptographic Primitives . . . . . . . . . . . . . . . . 3 62 2.2. Protocols and Architecture . . . . . . . . . . . . . . . 4 63 2.3. Implementations . . . . . . . . . . . . . . . . . . . . . 5 64 2.4. Deployment . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Securing the Internet is a rather complicated task since the threat 74 landscape has changed significantly over the last 20 years. For many 75 of the recognized security weaknesses solutions have been developed 76 and standardized. Unfortunately, the existence of specifications by 77 itself is not enough: security protocols need to be implemented and 78 deployed. Since many of the tougher security challenges suffer from 79 a collective action problem it typically takes many years until 80 widespread deployment has been reached (typically requiring 81 sufficient energy and enough pain). The recently observed pervasive 82 monitoring activities represent a new challenge to the Internet 83 community and require us to review and revisit some earlier made 84 design decisions. 86 To fully understand the role of the IETF in this context it is useful 87 to look at the types of attacks that are occuring. It quickly 88 becomes clear that the responsiblities for developing countermeasures 89 resides not only with the IETF but with the larger Internet eco- 90 system. 92 2. Attack Surface 94 The attack surface is categorized into four areas, as shown in Figure 95 1. In subsequent sections more details are provided and examples are 96 listed. 98 +-----------------+ +---------------+ +----------------+ +------------+ 99 | | | | | | | | 100 | Aging or Broken | | Weak | | Implementation | | Insecure | 101 | Cryptographic | | Protocol or | | Bugs and other | | Deployment | 102 | Primitives | | Architectural | | Vulnerabilities| | Practices | 103 | | | Foundation | | | | | 104 +-----------------+ +---------------+ +----------------+ +------------+ 106 Figure 1: Attack Surface. 108 2.1. Cryptographic Primitives 110 Internet security relies on sound cryptographic primitives, such as 111 hash functions, random number generators, integrity and encryption 112 algorithms, etc. The basic design philosophy is that the strength of 113 keyed algorithms relies on the length of the secret key. It is well- 114 known that these cryptographic primitives "age" as processing power 115 of computing hardware increases. This means that over time it is 116 faster to search through the entire key space with the same amount of 117 financial budget spent. Researchers have also made improvements in 118 analysing the building blocks of these algorithms and new attack 119 techniques (such as side channel attacks). This has lead to a 120 continued development of new cryptographic primitives. 122 The IETF has played a minor role in the work on cryptographic 123 primitives. Instead, it has rather been a consumer of these building 124 blocks and has therefore relied on others to select specifications 125 and to provide guidance. As an exception one could see the 126 publication of HMAC [21]. In fact, the crypto-community world-wide 127 is rather small and for a variety of reasons the National Institute 128 of Standards and Technology (NIST) has spearheaded many of these 129 developments. The IETF security community has relied on NIST to 130 provide guidance largely because no other groups have come forward to 131 offer advice. 133 While there have been problems with weaknesses in cryptographic 134 primitives (e.g., RC4 [1], [2], [3]) those have not been a a 135 substantial issue from a standardization point of view thanks to 136 'crypto-aglity'. Crypto-agility is the ability of a protocol to 137 adapt to evolving cryptographic algorithms and security requirements. 139 This may include the provision of a modular mechanism to allow 140 cryptographic algorithms to be updated without substantial disruption 141 to deployed implementations. 143 Problematic are, however, potential backdoors in elliptic curve 144 cryptography as well [9]. While the ability of many IETF protocols 145 to negotiate cryptographic protocols allows to deal with weak 146 cryptographic algorithm there is still some degree of uncertainty 147 about what algorithms are 'safe' to use. 149 2.2. Protocols and Architecture 151 Internet protocols and communication architectures belong to the core 152 expertise of the IETF and a lot of work has been done in this regard. 153 The IETF security community has been established after security 154 considerations sections became a mandatory part of IETF 155 specifications [22] and the overall understanding of security is 156 fairly large thanks to education efforts, the security area 157 directorate, and the push back from the IESG when questionalble 158 documents arrive. Still, there are a number of challenges. For 159 example, cryptographic attacks like BEAST [5], CRIME [6], and Lucky 160 Thirteen [4] targeted the Transport Layer Security (TLS) protocol. 161 More difficult to deal with are security and privacy challenges with 162 entire architectures, as the design of email, instant messaging, 163 voice over IP (VoIP), DNS, DHCP, and other protocols demonstrate. 164 Section 8 of [20] provides an interesting summary of the design 165 tradeoffs that had been made in the real-time communication 166 architecture as used by VoIP and instant messaging. The difficulty 167 is often not in crafting a security at the level of a single 168 specification but rather to ensure that the protocol development of 169 an entire communication architecture provides good security and 170 privacy properties after 10+ years of standardization when various 171 different industry trends (such as cloud computing, and the 172 JavaScript-based Web), and the interests of participating parties 173 collide. In many cases, the design decisions are subtle. For 174 example, the excitement of Web companies to use HTTP cookies [23] as 175 a replacement for cryptographic authentication was hard to 176 anticipate. The large number of key exchange mechanisms standardized 177 for VoIP might have confused the industry [17], [18], [16]. 179 Often, insecure versions of a protocol are standardized and completed 180 first before the secure version is developed. For example, consider 181 security for HTTP, SIP, XMPP, eMail, etc. While this may not have a 182 consequence on paper it certainly impacts follow-up implementations 183 and deployments. 185 Improving security and privacy for different communication protocols 186 has been subject of discussion on the IETF perpass list [10]. Note 187 that some discussions go beyond suggesting actions for the IETF but 188 rather belong the discussion in Section 2.3 and Section 2.4. As 189 another example of ongoing work is a document on best current 190 practices for Transport Layer Security [19], which gathers experience 191 from recent security attacks and recommends state-of-the-art 192 ciphersuites. The limitations of the public key infrastructure that 193 had gotten a lot of attention around 2011: DigiNotar, a Dutch 194 certificate authority, had a security breach and in the same year a 195 Comodo affiliate was compromised. Both cases lead to fraudulent 196 issue of certificates. The same structural vulnerability has been 197 exploided by the NSA in man-in-the-middle attacks [15]. 199 2.3. Implementations 201 Once standardization work is completed the specifications have to get 202 implemented. Often those who develop the specifications are not 203 necessary the same parties that implement the software. The 204 specifications therefore have to offer enough context and be readable 205 to avoid security problems via misinterpretation. Also, those who 206 implement and those who deploy are also not necessarily the same set 207 of people. For example, some developers write open source libraries 208 useful for a wide range of communities, as it is the case with 209 OpenSSL or GnuTLS. 211 Implementations may show a number of security weaknesses, such as 212 lack of security features, quality of the implementations (e.g., 213 implementations with insufficent penetration testing), weak pseudo- 214 random number generators [7], [11], etc. Since the source code of 215 many implementations is not available to the public backdoors may be 216 built-in [8]. 218 Many implementations of Web applications, however, suffer from basic 219 vulnerabilities (such as injection or cross-site scripting attacks), 220 as the top-10 charts of the Open Web Application Security Project 221 (OWASP) reveal [13]. Sometimes vendors make design decision for 222 their product implementations that lead to security vulnerabilities, 223 for example when devices are shipped with default-passwords or with 224 enabled debugging interfaces [14]. 226 2.4. Deployment 228 Finally, the implementations of various protocols are put together 229 and complete systems are deployed. Those who deploy have to make 230 various decisions that go beyond pure protocol aspects but also have 231 to consider various configuration options. These deployment 232 decisions have an important impact on the provided privacy and 233 security properties. Examples include, backend server protocols 234 secured only with "physical security" (i.e., without cryptographic 235 security protection), email services without TLS protection, custom 236 security designs (see, for example, WhatsApp [12]), etc. With the 237 juridiction the service is provided in certain responsiblities for 238 data retention, and lawful intercept arise. 240 3. Security Considerations 242 This entire document focused on the discussion of new functionality 243 for securing Diameter AVPs selectively between non-neighboring nodes. 245 4. IANA Considerations 247 This document does not require actions by IANA. 249 5. Acknowledgments 251 We would like to thank the IAB for encouraging me to turn my slide 252 deck into a document. 254 6. Normative References 256 [1] Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the 257 Key Scheduling Algorithm of RC4", Selected Areas in 258 Cryptography , 2001. 260 [2] ISOBE, T., OHIGASHI, T., WATANABE, Y., and M. MORII, "Full 261 Plaintext Recovery Attack on Broadcast RC4", International 262 Workshop on Fast Software Encryption , 2013. 264 [3] AlFardan, N., Bernstein, D., Paterson, K., Poettering, B., 265 and J. Schuldt, "On the Security of RC4 in TLS", Usenix 266 Security Symposium 2013, 2013, . 269 [4] AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking 270 the TLS and DTLS Record Protocols", IEEE Symposium on 271 Security and Privacy , 2013. 273 [5] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS", 274 2011, . 277 [6] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty 278 Security Conference 2012, 2012. 280 [7] Ars Technica, "Stop using NSA-influenced code in our 281 products, RSA tells customers", URL: http:// 282 arstechnica.com/security/2013/09/stop-using-nsa-influence- 283 code-in-our-product-rsa-tells-customers/, Sep 2013. 285 [8] Boing Boing, "Anti-Tor malware reported back to the NSA", 286 URL: http://boingboing.net/2013/08/05/anti-tor-malware- 287 reported-back.html, Aug 2013. 289 [9] Cryptography Stack Exchange, "Should we trust the NIST- 290 recommended ECC parameters?", URL: http:// 291 crypto.stackexchange.com/questions/10263/should-we-trust- 292 the-nist-recommended-ecc-parameters, Sep 2013. 294 [10] Nadia Heninger, "PERPASS Mailing List", URL: http:// 295 www.ietf.org/mail-archive/web/perpass/current/ 296 maillist.html, Oct 2013. 298 [11] IETF, "New research: There's no need to panic over 299 factorable keys-just mind your Ps and Qs", URL: https 300 ://freedom-to-tinker.com/blog/nadiah/new-research-theres- 301 no-need-panic-over-factorable-keys-just-mind-your-ps-and- 302 qs/, Oct 2013. 304 [12] fileperms Blog, "WhatsApp is broken, really broken", URL: 305 http://fileperms.org/whatsapp-is-broken-really-broken/, 306 Sep 2012. 308 [13] OWASP, "Open Web Application Security Project (OWASP): Top 309 Ten Project", URL: https://www.owasp.org/index.php/ 310 Category:OWASP_Top_Ten_Project, Oct 2013. 312 [14] Wired, "NSA Laughs at PCs, Prefers Hacking Routers and 313 Switches", URL: http://www.wired.com/threatlevel/2013/09/ 314 nsa-router-hacking/, Apr 2013. 316 [15] Zeljka Zorz, "NSA impersonated Google in MitM attacks", 317 URL: https://www.net-security.org/secworld.php?id=15579, 318 Apr 2013. 320 [16] Westerlund, M. and C. Perkins, "Options for Securing RTP 321 Sessions", draft-ietf-avtcore-rtp-security-options-08 322 (work in progress), October 2013. 324 [17] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 325 "Requirements and Analysis of Media Security Management 326 Protocols", RFC 5479, April 2009. 328 [18] Perkins, C. and M. Westerlund, "Securing the RTP Protocol 329 Framework: Why RTP Does Not Mandate a Single Media 330 Security Solution", draft-ietf-avt-srtp-not-mandatory-14 331 (work in progress), October 2013. 333 [19] Sheffer, Y. and R. Holz, "Recommendations for Secure Use 334 of TLS and DTLS", draft-sheffer-tls-bcp-01 (work in 335 progress), September 2013. 337 [20] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 338 Morris, J., Hansen, M., and R. Smith, "Privacy 339 Considerations for Internet Protocols", RFC 6973, July 340 2013. 342 [21] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 343 Hashing for Message Authentication", RFC 2104, February 344 1997. 346 [22] Postel, J., "Instructions to RFC Authors", RFC 1543, 347 October 1993. 349 [23] Tschofenig, H., Turner, S., and M. Hanson, "An Inquiry 350 into the Nature and the Causes of Web Insecurity", draft- 351 tschofenig-secure-the-web-04 (work in progress), October 352 2012. 354 Author's Address 356 Hannes Tschofenig 358 Email: Hannes.Tschofenig@gmx.net 359 URI: http://www.tschofenig.priv.at