| PERPASS | H. Tschofenig |
| Internet-Draft | October 21, 2013 |
| Intended status: Informational | |
| Expires: April 24, 2014 |
Tackling Pervasive Surveillance or How to improve Security of the Internet?
draft-tschofenig-perpass-surveillance-00.txt
Surveillance is the observation or monitoring of an individual's communications or activities. Surveillance is one of several privacy/security threats engineers try to take into account in their designs. The reports about pervasive monitoring of Internet traffic have, however, surprised many since the scale was not envisaged during the design of many Internet protocols. The approach to get access to meta-data as well as to communication content has taken forms that are largely indistinguishable from ordinary attacks.
This document explains the attacks in context of the larger Internet eco-system.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Securing the Internet is a rather complicated task since the threat landscape has changed significantly over the last 20 years. For many of the recognized security weaknesses solutions have been developed and standardized. Unfortunately, the existence of specifications by itself is not enough: security protocols need to be implemented and deployed. Since many of the tougher security challenges suffer from a collective action problem it typically takes many years until widespread deployment has been reached (typically requiring sufficient energy and enough pain). The recently observed pervasive monitoring activities represent a new challenge to the Internet community and require us to review and revisit some earlier made design decisions.
To fully understand the role of the IETF in this context it is useful to look at the types of attacks that are occuring. It quickly becomes clear that the responsiblities for developing countermeasures resides not only with the IETF but with the larger Internet eco-system.
The attack surface is categorized into four areas, as shown in Figure 1. In subsequent sections more details are provided and examples are listed.
+-----------------+ +---------------+ +----------------+ +------------+
| | | | | | | |
| Aging or Broken | | Weak | | Implementation | | Insecure |
| Cryptographic | | Protocol or | | Bugs and other | | Deployment |
| Primitives | | Architectural | | Vulnerabilities| | Practices |
| | | Foundation | | | | |
+-----------------+ +---------------+ +----------------+ +------------+
Figure 1: Attack Surface.
Internet security relies on sound cryptographic primitives, such as hash functions, random number generators, integrity and encryption algorithms, etc. The basic design philosophy is that the strength of keyed algorithms relies on the length of the secret key. It is well-known that these cryptographic primitives "age" as processing power of computing hardware increases. This means that over time it is faster to search through the entire key space with the same amount of financial budget spent. Researchers have also made improvements in analysing the building blocks of these algorithms and new attack techniques (such as side channel attacks). This has lead to a continued development of new cryptographic primitives.
The IETF has played a minor role in the work on cryptographic primitives. Instead, it has rather been a consumer of these building blocks and has therefore relied on others to select specifications and to provide guidance. As an exception one could see the publication of HMAC [RFC2104]. In fact, the crypto-community world-wide is rather small and for a variety of reasons the National Institute of Standards and Technology (NIST) has spearheaded many of these developments. The IETF security community has relied on NIST to provide guidance largely because no other groups have come forward to offer advice.
While there have been problems with weaknesses in cryptographic primitives (e.g., RC4 [RC4-Attack-FMS], [RC4-Attack], [RC4-Attack-AlF]) those have not been a a substantial issue from a standardization point of view thanks to 'crypto-aglity'. Crypto-agility is the ability of a protocol to adapt to evolving cryptographic algorithms and security requirements. This may include the provision of a modular mechanism to allow cryptographic algorithms to be updated without substantial disruption to deployed implementations.
Problematic are, however, potential backdoors in elliptic curve cryptography as well [ECC]. While the ability of many IETF protocols to negotiate cryptographic protocols allows to deal with weak cryptographic algorithm there is still some degree of uncertainty about what algorithms are 'safe' to use.
Internet protocols and communication architectures belong to the core expertise of the IETF. The IETF security community has grown over time after security considerations sections became a mandatory part of IETF specifications [RFC1543] and the overall understanding of security is increasing thanks to education efforts, the security area directorate, and the push back from the IESG when questionable documents arrive.
Still, there are a number of challenges. For example, cryptographic attacks like BEAST [BEAST], CRIME [CRIME], and Lucky Thirteen [CBC-Attack] targeted the Transport Layer Security (TLS) protocol. More difficult to deal with are security and privacy challenges with entire protocols architectures, as the design of email, instant messaging, voice over IP (VoIP), DNS, DHCP, etc. demonstrate. Section 8 of [RFC6973] provides an interesting summary of the design tradeoffs that had been made in the real-time communication architecture as used by VoIP and instant messaging. The difficulty is often not in crafting a security solution at the level of a single specification but rather to ensure that the protocol development of an entire communication architecture provides good security and privacy properties after 10+ years of standardization when various different industry trends (such as cloud computing, and the JavaScript-based Web), and the interests of participating parties re-shape the original design goals. In many cases, the implications of certain design decisions are subtle. For example, the excitement of Web companies to use HTTP cookies [I-D.tschofenig-secure-the-web] as a replacement for cryptographic authentication was hard to anticipate. The large number of key exchange mechanisms standardized for VoIP (see [RFC5479], [I-D.ietf-avt-srtp-not-mandatory], [I-D.ietf-avtcore-rtp-security-options]) might have provided different ways to fulfill needs of different deployments but on the other hand confused the industry .
Often, insecure versions of a protocol are standardized and completed first before the secure version is developed. For example, consider security for HTTP, SIP, XMPP, eMail, etc. While this may not have a consequence on paper it certainly impacts follow-up implementations and deployments.
Another example for an architectural weakness can be found with the public key infrastructure (PKI) when the limitations of the PKI became apparent in 2011: DigiNotar, a Dutch certificate authority, had a security breach and in the same year a Comodo affiliate was compromised. Both cases lead to fraudulent issue of certificates allowing man-in-the-middle attacks on TLS secured data Web interactions. The same structural vulnerability has been exploided by the NSA in man-in-the-middle attacks [MitM].
Improving security and privacy for different communication protocols has been subject of discussion on the IETF perpass list [perpass]. Note that some discussions go beyond suggesting actions for the IETF but rather belong the discussion in Section 2.3 and Section 2.4. As another example of ongoing work is a document on best current practices for Transport Layer Security [I-D.sheffer-tls-bcp], which gathers experience from recent security attacks and recommends state-of-the-art ciphersuites.
Once standardization work is completed the specifications have to get implemented. Often those who develop the specifications are not necessary the same parties that implement the software. The specifications therefore have to offer enough context and be readable to avoid security problems via misinterpretation. Also, those who implement and those who deploy are also not necessarily the same set of people. For example, some developers write open source libraries useful for a wide range of communities, as it is the case with OpenSSL or GnuTLS.
Implementations may show a number of security weaknesses, such as lack of security features, quality of the implementations (e.g., implementations with insufficent penetration testing), weak pseudo-random number generators [Dual_EC_DBRG], [Entrophy], etc. Since the source code of many implementations is not available to the public backdoors may be built-in [Anti-Tor-Malware].
Many implementations of Web applications, however, suffer from basic vulnerabilities (such as injection or cross-site scripting attacks), as the top-10 charts of the Open Web Application Security Project (OWASP) reveal [OWASP]. Sometimes vendors make design decision for their product implementations that lead to security vulnerabilities, for example when devices are shipped with default-passwords or with enabled debugging interfaces [Wired].
Finally, the implementations of various protocols are put together and complete systems are deployed. Those who deploy have to make various decisions that go beyond pure protocol aspects but also have to consider various configuration options. These deployment decisions have an important impact on the provided privacy and security properties. Examples include, backend server protocols secured only with "physical security" (i.e., without cryptographic security protection), email services without TLS protection, custom security designs (see, for example, WhatsApp [WhatsApp]), etc. With the juridiction the service is provided in certain responsiblities for data retention, and lawful intercept arise.
This entire document focused on the discussion of new functionality for securing Diameter AVPs selectively between non-neighboring nodes.
This document does not require actions by IANA.
We would like to thank the IAB for encouraging me to turn my slide deck into a document.
| [1] | Fluhrer, S., Mantin, I. and A. Shamir, "Weaknesses in the Key Scheduling Algorithm of RC4", Selected Areas in Cryptography , 2001. |
| [2] | ISOBE, T., OHIGASHI, T., WATANABE, Y. and M. MORII, "Full Plaintext Recovery Attack on Broadcast RC4", International Workshop on Fast Software Encryption , 2013. |
| [3] | AlFardan, N., Bernstein, D.J., Paterson, K.G., Poettering, B. and J.C.N. Schuldt, "On the Security of RC4 in TLS", Usenix Security Symposium 2013, 2013. |
| [4] | AlFardan, N.J. and K. Paterson, "Lucky Thirteen: Breaking the TLS and DTLS Record Protocols", IEEE Symposium on Security and Privacy , 2013. |
| [5] | Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS", 2011. |
| [6] | Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty Security Conference 2012, 2012. |
| [7] | Ars Technica, "Stop using NSA-influenced code in our products, RSA tells customers", URL: http://arstechnica.com/security/2013/09/stop-using-nsa-influence-code-in-our-product-rsa-tells-customers/, Sep 2013. |
| [8] | Boing Boing, "Anti-Tor malware reported back to the NSA", URL: http://boingboing.net/2013/08/05/anti-tor-malware-reported-back.html, Aug 2013. |
| [9] | Cryptography Stack Exchange, "Should we trust the NIST-recommended ECC parameters?", URL: http://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters, Sep 2013. |
| [10] | Nadia Heninger, "PERPASS Mailing List", URL: http://www.ietf.org/mail-archive/web/perpass/current/maillist.html, Oct 2013. |
| [11] | IETF, "New research: There’s no need to panic over factorable keys–just mind your Ps and Qs", URL: https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/, Oct 2013. |
| [12] | fileperms Blog, "WhatsApp is broken, really broken", URL: http://fileperms.org/whatsapp-is-broken-really-broken/, Sep 2012. |
| [13] | OWASP, "Open Web Application Security Project (OWASP): Top Ten Project", URL: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project, Oct 2013. |
| [14] | Wired, "NSA Laughs at PCs, Prefers Hacking Routers and Switches", URL: http://www.wired.com/threatlevel/2013/09/nsa-router-hacking/, Apr 2013. |
| [15] | Zeljka Zorz, "NSA impersonated Google in MitM attacks", URL: https://www.net-security.org/secworld.php?id=15579, Apr 2013. |
| [16] | Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", Internet-Draft draft-ietf-avtcore-rtp-security-options-04, July 2013. |
| [17] | Wing, D., Fries, S., Tschofenig, H. and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009. |
| [18] | Perkins, C. and M. Westerlund, "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution", Internet-Draft draft-ietf-avt-srtp-not-mandatory-13, May 2013. |
| [19] | Sheffer, Y. and R. Holz, "Recommendations for Secure Use of TLS and DTLS", Internet-Draft draft-sheffer-tls-bcp-01, September 2013. |
| [20] | Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M. and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013. |
| [21] | Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. |
| [22] | Postel, J., "Instructions to RFC Authors", RFC 1543, October 1993. |
| [23] | Tschofenig, H., Turner, S. and M. Hanson, "An Inquiry into the Nature and the Causes of Web Insecurity", Internet-Draft draft-tschofenig-secure-the-web-04, October 2012. |