<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC5479   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5479.xml">
<!ENTITY RFC1543   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1543.xml">
<!ENTITY RFC2104   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml">
<!ENTITY RFC6973   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.xml">
<!ENTITY I-D.sheffer-tls-bcp PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.sheffer-tls-bcp.xml">
<!ENTITY I-D.ietf-avtcore-rtp-security-options PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-security-options.xml">
<!ENTITY I-D.ietf-avt-srtp-not-mandatory PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-srtp-not-mandatory.xml">
<!ENTITY I-D.tschofenig-secure-the-web PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-secure-the-web.xml">
<!ENTITY I-D.ietf-websec-session-continue-prob PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-websec-session-continue-prob.xml">
]>

<?rfc inline="yes"?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?> 
<?rfc symrefs="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>


<rfc category='info' ipr='trust200902' docName='draft-tschofenig-perpass-surveillance-01.txt'>

  <front>
    <title abbrev="Tackling Pervasive Surveillance">Tackling Pervasive Surveillance or How to improve Security of the Internet?</title>

    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization></organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <code></code>
          <country></country>
        </postal>
        <phone></phone>
        <email>Hannes.Tschofenig@gmx.net</email>
       <!-- <uri>http://www.tschofenig.priv.at</uri> -->
      </address>
    </author>
 
	
    <date year='2013'/>
    <area>Security</area>
    <workgroup>PERPASS</workgroup>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>Security</keyword>
    <keyword>Surveillance</keyword>

    <abstract>
      
      <t>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 even though the ambition to offer end-to-end security on the Internet dates back even to the 70ies. The approach to get access to meta-data as well as to communication content has taken forms that are largely indistinguishable from ordinary attacks.</t>    
      
      <t>This document explains the attacks in context of the larger Internet eco-system.</t>
  </abstract>
  </front>
  <middle>
    
  
 
    <section title='Introduction'>
    
	<t>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 design decisions.</t>
      
      <t>To fully understand the role of the IETF in this context it is useful to look at the types of attacks that are occurring. It quickly becomes clear that the development of many countermeasures is entirely within scope of the IETF. But the deployment and use is outside out scope, and requires interactions with the larger Internet eco-system.</t>
        
  </section>
	  
    
    <section title="Attack Surface">
      
      <t>The attack surface is categorized into four areas, as shown in <xref target="attack-figure"/>. In subsequent sections more details are provided and examples are listed.</t>
      <t>
        <figure title="Attack Surface." anchor="attack-figure">
          <artwork>
            <![CDATA[
+-----------------+ +---------------+ +----------------+ +------------+
|                 | |               | |                | |            |
| Aging or Broken | | Weak          | | Implementation | | Insecure   |
| Cryptographic   | | Protocol or   | | Bugs and other | | Deployment |
| Primitives      | | Architectural | | Vulnerabilities| | Practices  |
|                 | | Foundation    | |                | |            |
+-----------------+ +---------------+ +----------------+ +------------+
]]>
          </artwork>
        </figure>
      </t> 
      
      
      <section title="Cryptographic Primitives">
        <t>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/private 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 key space with the same amount of financial budget spent. (Note: How much of the key space an adversary has to search depends on a number of factors. Due to the birthday paradoxon it has to search on average 1/2 of the key space. It can actually be much lower when lower entrophy secrets are used, such as passwords.) Researchers have also made improvements in analyzing 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.</t>
        
        <t>The IETF has played a minor role in the work on cryptographic primitives. Instead, it has 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 <xref target="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.</t>
        
        <t>While there have been problems with weaknesses in cryptographic primitives (e.g., RC4 <xref target="RC4-Attack-FMS"/>, <xref target="RC4-Attack"/>, <xref target="RC4-Attack-AlF"/>) those have not been a substantial issue from a standardization point of view thanks to 'crypto-agility'. (Note that RC4 is not a NIST standard.) Crypto-agility is the ability of a protocol to adapt to evolving cryptographic algorithms and security requirements. This includes provisions that allow security protocols to adopt different cryptographic algorithms without substantial disruption to deployed implementations. This does not mean the implementation is unchanged and, of course, the need for backwards compatibility creates downgrade attacks.</t>
        
        <t>Rumors about backdoors in specific elliptic curves, and random number generators have created some uncertainty about what algorithms are 'safe' to use. The crypto-community is still debating about the validity of these claims and investigating about how long weaknesses in standards should have been known to experts.</t>
        <!-- 
        <t>Problematic are, however, suspected backdoors in specific elliptic curves <xref target="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.</t>
        --> 
        
      </section>
     
      <section title="Protocols and Architecture">
      
        <t>Internet protocols and communication architectures belong to the core expertise of the IETF. While security experts have been around in the early days of the IETF the security community grew over time after security considerations sections became a mandatory part of IETF specifications <xref target="RFC1543"/>. The overall understanding of security is still increasing thanks to education efforts, reviews from the security area directorate, and the push back from the IESG when questionable documents arrive.</t>
        
        <t>Still, there are a number of challenges. For example, cryptographic attacks like BEAST <xref target="BEAST"/>, CRIME <xref target="CRIME"/>, and Lucky Thirteen <xref target="CBC-Attack"/> targeted the Transport Layer Security (TLS) protocol when specific algorithms are used with specific application layer protocols (such as HTTP). 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. 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. 
          
          
          Section 8 of <xref target="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 ensuring that the protocol development of an entire communication architecture provides good security and privacy properties after many 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. Furthermore, often the attention is paid on protecting the payload of the content only and meta-data is exposed to service providers and other parties, particularly with server-centric communication architectures.</t>
        
        <t>In many cases, the implications of certain design decisions are subtle. Two examples are: <list style="hanging">
          <t hangText="Cookies:">For example, the excitement of Web companies to use HTTP cookies <xref target="I-D.tschofenig-secure-the-web"/>, <xref target="I-D.ietf-websec-session-continue-prob"/> as a replacement for cryptographic authentication was hard to anticipate. 
          </t>
          <t hangText="VoIP Media Security:">The large number of key exchange mechanisms standardized for VoIP (see <xref target="RFC5479"/>, <xref target="I-D.ietf-avt-srtp-not-mandatory"/>, <xref target="I-D.ietf-avtcore-rtp-security-options"/>) might have provided ways to fulfill needs of different deployment scenarios but certainly confused the industry and didn't increase interoperability. New VoIP security authentication protocols are still proposed today.</t>
        </list>
        </t>
        <t>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 certification 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. There have been claims that the same architectural vulnerability has been exploited  by the National Security Agency (NSA) in man-in-the-middle attacks <xref target="MitM"/>.</t>
        
        <t>Improving security and privacy for different communication protocols has been subject of discussion on the IETF perpass list <xref target="perpass"/>. Note that some discussions go beyond suggesting actions for the IETF; they belong to the discussion in <xref target="implementations"/> and <xref target="deployment"/>. As another example of ongoing work is a document on best current practices for Transport Layer Security <xref target="I-D.sheffer-tls-bcp"/>, which gathers experience from recent security attacks and recommends state-of-the-art ciphersuites. </t>
     
      </section>
      
     <section anchor="implementations" title="Implementations">
       
       <t>Once standardization work is completed the specifications have to be implemented. Often those who develop the specifications are not necessary the same parties who 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. Note: This description is rather simplified version of the typical IETF protocol development. In many cases, the development process is not linear since protocols are implemented while they are specified and implementation results are fed back into the standardization effort. Still, for many successful protocols implementations the number of those involved in implementations far exceeds the number of standardization participants.</t>
       
       <t>Implementations may show a number of security weaknesses, such as lack of security features, quality of the implementations (e.g., implementations with insufficient penetration testing), weak pseudo-random number generators <xref target="Dual_EC_DBRG"/>, <xref target="Entrophy"/>, etc. Since the source code of many implementations is not available to the public, backdoors may be built-in, as it was rumored with  <xref target="Anti-Tor-Malware"/>.
       </t>
      
       <t>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 <xref target="OWASP"/>. Sometimes vendors make design decisions for their product implementations that lead to security vulnerabilities, for example when devices are shipped with default-passwords or with enabled debugging interfaces <xref target="Wired"/>. </t>
     </section>
      
     <section anchor="deployment" title="Deployment">
       <t>Finally, implementations of various protocols are put together and complete systems are deployed. Those who deploy have to make decisions that go beyond pure protocol aspects; for example, they 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 <xref target="WhatsApp"/>), etc. Depending on the jurisdiction within which a service is provided, those who deploy systems may assume certain for data retention, and support for lawful intercept.
       </t>
    </section>
    
    <!-- 
    <section title='Recommendations'>
      <t><list style="hanging">
        <t hangText="Cryptographic Primitives:">There are three possible directions the IETF could take, namely (a) continue with the current practice by trusting others to do the right thing, (b) play a more active role in the selection and development of cryptographic primitives, and (c) reach out to other organizations that may have expertise. Item (b) might be most promising but requires a fair amount of additional work and interest from the research community to engage in a dialog. The IRTF Crypto Forum Research Group (CFRG) may also serve as a suitable venue. </t>
        
      </list></t> 
    </section>
    --> 

    </section>
    
    
    <section title='Security Considerations' anchor='Security'>
  <t>This entire document focuses on security.</t> 
    </section>

    <section title='IANA Considerations' anchor='IANA'>
	 <t>This document does not require actions by IANA.</t>
    </section>

    <section title='Acknowledgments'>
	     <t>I would like to thank the IAB for encouraging me to turn my IAB-internal presentation into a document. I would also like to thank Stephen Kent, Rene Struik, and Linus Nordberg for their detailed reviews.</t>
    </section>

  </middle>

  <back>

    <references title='Normative References'>


      
      <reference anchor="RC4-Attack-FMS"><front><title>Weaknesses in the Key Scheduling Algorithm of RC4</title><author initials="S." surname="Fluhrer" fullname="Scott Fluhrer"/><author initials="I." surname="Mantin" fullname="Itsik Mantin"/><author initials="A." surname="Shamir" fullname="Adi Shamir"/><date year="2001"/></front><seriesInfo name="Selected Areas in Cryptography" value=""/></reference>
      <reference anchor="RC4-Attack"><front><title>Full Plaintext Recovery Attack on Broadcast RC4</title><author initials="T." surname="ISOBE" fullname="Takanori ISOBE"/><author initials="T." surname="OHIGASHI" fullname="Toshihiro OHIGASHI"/><author initials="Y." surname="WATANABE" fullname="Yuhei WATANABE"/><author initials="M." surname="MORII" fullname="Masakatu MORII"/><date year="2013"/></front><seriesInfo name="International Workshop on Fast Software Encryption" value=""/></reference>
      <reference anchor="RC4-Attack-AlF" target="https://www.usenix.org/conference/usenixsecurity13/security-rc4-tls"><front><title>On the Security of RC4 in TLS</title><author initials="N." surname="AlFardan" fullname="Nadhem AlFardan"/><author initials="D.J." surname="Bernstein" fullname="Daniel J. Bernstein"/><author initials="K.G." surname="Paterson" fullname="Kenneth G. Paterson"/><author initials="B." surname="Poettering" fullname="Bertram Poettering"/><author initials="J.C.N." surname="Schuldt" fullname="Jacob C. N. Schuldt"/><date year="2013"/></front><seriesInfo name="Usenix Security Symposium" value="2013"/></reference>
      
      <reference anchor="CBC-Attack"><front><title>Lucky Thirteen: Breaking the TLS and DTLS Record Protocols</title><author initials="N.J." surname="AlFardan" fullname="Nadhem J. AlFardan"/><author initials="K." surname="Paterson" fullname="K. Paterson"/><date year="2013"/></front><seriesInfo name="IEEE Symposium on Security and Privacy" value=""/></reference>
      <reference anchor="BEAST" target="https://packetstormsecurity.com/files/105499/Browser-Exploit-Against-SSL-TLS.html"><front><title>Browser Exploit Against SSL/TLS</title><author initials="J." surname="Rizzo" fullname="Juliano Rizzo"/><author initials="T." surname="Duong" fullname="Thai Duong"/><date year="2011"/></front></reference>
      <reference anchor="CRIME"><front><title>The CRIME Attack</title><author initials="J." surname="Rizzo" fullname="Juliano Rizzo"/><author initials="T." surname="Duong" fullname="Thai Duong"/><date year="2012"/></front><seriesInfo name="EKOparty Security Conference" value="2012"/></reference>
      
      <reference anchor="Dual_EC_DBRG">
        <front>
          <title>Stop using NSA-influenced code in our products, RSA tells customers</title>
          
          <author>
            <organization>Ars Technica</organization>
          </author>
          
          <date month="Sep" year="2013" />
        </front>
        
        <seriesInfo name=""
          value="URL: http://arstechnica.com/security/2013/09/stop-using-nsa-influence-code-in-our-product-rsa-tells-customers/" />
        
        <format target="http://arstechnica.com/security/2013/09/stop-using-nsa-influence-code-in-our-product-rsa-tells-customers/"
          type="HTML" />
      </reference>
      
      <reference anchor="Anti-Tor-Malware">
        <front>
          <title>Anti-Tor malware reported back to the NSA</title>
          
          <author>
            <organization>Boing Boing</organization>
          </author>
          
          <date month="Aug" year="2013" />
        </front>
        
        <seriesInfo name=""
          value="URL: http://boingboing.net/2013/08/05/anti-tor-malware-reported-back.html" />
        
        <format target="http://boingboing.net/2013/08/05/anti-tor-malware-reported-back.html"
          type="HTML" />
      </reference>
      
      <!-- 
      <reference anchor="ECC">
        <front>
          <title>Should we trust the NIST-recommended ECC parameters?</title>
          
          <author>
            <organization>Cryptography Stack Exchange</organization>
          </author>
          
          <date month="Sep" year="2013" />
        </front>
        
        <seriesInfo name=""
          value="URL: https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters" />
        
        <format target="https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters"
          type="HTML" />
      </reference>
      --> 
      <reference anchor="perpass">
        <front>
          <title>PERPASS Mailing List</title>
          
          <author>
            <organization>IETF</organization>
          </author>
          
          <date month="Oct" year="2013" />
        </front>
        
        <seriesInfo name=""
          value="URL: https://www.ietf.org/mail-archive/web/perpass/current/maillist.html" />
        
        <format target="https://www.ietf.org/mail-archive/web/perpass/current/maillist.html"
          type="HTML" />
      </reference>
      
      <reference anchor="Entrophy">
        <front>
          <title>New research: There's no need to panic over factorable keys–just mind your Ps and Qs</title>
          
          <author>
            <organization>Nadia Heninger</organization>
          </author>
          
          <date month="Oct" year="2013" />
        </front>
        
        <seriesInfo name=""
          value="URL: https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/" />
        
        <format target="https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/"
          type="HTML" />
      </reference>
      
      <reference anchor="WhatsApp">
        <front>
          <title>WhatsApp is broken, really broken</title>
          
          <author>
            <organization>fileperms Blog</organization>
          </author>
          
          <date month="Sep" year="2012" />
        </front>
        
        <seriesInfo name=""
          value="URL: http://fileperms.org/whatsapp-is-broken-really-broken/" />
        
        <format target="http://fileperms.org/whatsapp-is-broken-really-broken/"
          type="HTML" />
      </reference>
      
      <reference anchor="OWASP">
        <front>
          <title>Open Web Application Security Project (OWASP): Top Ten Project</title>
          
          <author>
            <organization>OWASP</organization>
          </author>
          
          <date month="Oct" year="2013" />
        </front>
        
        <seriesInfo name=""
          value="URL: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project" />
        
        <format target="https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project"
          type="HTML" />
      </reference>
      
      
      <reference anchor="Wired">
        <front>
          <title>NSA Laughs at PCs, Prefers Hacking Routers and Switches</title>
          
          <author>
            <organization>Wired</organization>
          </author>
          
          <date month="Apr" year="2013" />
        </front>
        
        <seriesInfo name=""
          value="URL: http://www.wired.com/threatlevel/2013/09/nsa-router-hacking/" />
        
        <format target="http://www.wired.com/threatlevel/2013/09/nsa-router-hacking/"
          type="HTML" />
      </reference>
      
      
      <reference anchor="MitM">
        <front>
          <title>NSA impersonated Google in MitM attacks</title>
          
          <author>
            <organization>Zeljka Zorz</organization>
          </author>
          
          <date month="Apr" year="2013" />
        </front>
        
        <seriesInfo name=""
          value="URL: https://www.net-security.org/secworld.php?id=15579" />
        
        <format target="https://www.net-security.org/secworld.php?id=15579"
          type="HTML" />
      </reference>
      
      &I-D.ietf-avtcore-rtp-security-options;
      &RFC5479; 
      &I-D.ietf-avt-srtp-not-mandatory;
      &I-D.sheffer-tls-bcp; 
      &RFC6973; 
      &RFC2104;
      &RFC1543;
      &I-D.ietf-websec-session-continue-prob; 
      &I-D.tschofenig-secure-the-web; 
    </references>
    
    <!-- 
    <references title='Informative References'>
    </references>
    --> 
    
  </back>

</rfc>
