Traffic peeking
draft-moonesamy-traffic-peeking-00

INTERNET-DRAFT                                              S. Moonesamy
Intended Status: Informational                                          
Expires: May 28, 2014                                  November 24, 2013

                            Traffic peeking 
                   draft-moonesamy-traffic-peeking-00

Abstract

   In June 2013, a news article revealed that the National Security
   Agency obtained direct access to the systems of several service
   providers from the United States through an undisclosed surveillance
   programme called PRISM.  This document discusses about traffic
   peeking.

Status of this Memo

   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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   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
 

S. Moonesamy              Expires May 28, 2014                  [Page 1]
INTERNET DRAFT              Traffic peeking            November 24, 2013

   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.

Table of Contents

   1. Background  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Traffic peeking . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1. Encrypting traffic  . . . . . . . . . . . . . . . . . . . .  3
   3. Security Considerations . . . . . . . . . . . . . . . . . . . .  4
   4. Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  4
   6. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     6.1.  Informative References . . . . . . . . . . . . . . . . . .  4
   Appendix A: IETF Protocols without encryption  . . . . . . . . . .  5
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . .  6

 

S. Moonesamy              Expires May 28, 2014                  [Page 2]
INTERNET DRAFT              Traffic peeking            November 24, 2013

1. Background

   In June 2013, a news article [Guar1] revealed that the National
   Security Agency obtained direct access to the systems of several
   service providers from the United States through an undisclosed
   surveillance programme called PRISM [Guar2].  The surveillance
   programme intercepted traffic flowing through communication links
   used throughout the world.  According to a news article published in
   October 2013, the National Security Agency had also been wiretapping
   traffic flowing between the datacenters used by Google and Yahoo
   [Wash1].

   In 2007, Dan Shumow and Niels Ferguson discussed about the
   possibility of a backdoor in a Dual Elliptic Curve  pseudorandom
   number generator [Rump]. In September, 2013, the National Institute
   of Standards and Technology reported that concern has been expressed
   about the Dual Elliptic Curve Deterministic Random Bit Generation
   (Dual_EC_DRBG) algorithm published in one of its standards (SP 800-
   90/90A) [NIST]. 

2. Traffic peeking

   RFC 1958 [RFC1958] states that "it is highly desirable that Internet
   carriers protect the privacy and authenticity of all traffic, but
   this is not a requirement of the architecture.  "Tussle in
   Cyberspace: Defining Tomorrow's Internet" [Tussle] states that
   "peeking is irresistible".  Given that most Internet traffic is not
   encrypted, there isn't any significant barrier to hamper an entity
   with the available resources to peek on the traffic of Internet
   carriers.  As data storage is affordable the next step would be to go
   beyond traffic peeking and collect all the data.  [Tussle] argued
   that "if there is information visible in the packet, there is no way
   to keep an intermediate node from looking at it.  So the ultimate
   defense of the end to end mode is end to end encryption".

2.1. Encrypting traffic

   Encrypting traffic "might just be the first step in an escalating
   tussle between the end user and the network provider, in which the
   response of the provider is to refuse to carry encrypted data"
   [Tussle].  It helps to shape the end user's expectations as the
   latter will be aware of the restrictions.

   The end user relies on the organizations recommending the standards
   as it is not possible for the average person to evaluate whether the
   encryption mechanism used will protect the traffic from wiretapping. 
   It is to be noted that some encryption standards are incorporated by
   reference in standards used for the Internet.
 

S. Moonesamy              Expires May 28, 2014                  [Page 3]
INTERNET DRAFT              Traffic peeking            November 24, 2013

3. Security Considerations

   Entities exchanging traffic over the Internet should assume that any
   traffic which is not encrypted will be intercepted given that peeking
   is irresistible. There is a risk that encrypted traffic will not
   provide any protection if it is stored indefinitely as the ability to
   recover the traffic is preserved.

4. Conclusion

   The security dilemma exists when "many of the means by which a
   country tries to increase its security decrease the security of
   others".  It is up to designers and implementers of a protocol to see
   whether the encryption standard they use will provide a level of the
   security which they consider acceptable.

   It is in the interest of a network provider or a provider of a
   service to collaborate with the relevant government.  The end user
   will usually be at the losing end of the bargain in a tussle between
   the end user and government when Internet traffic wiretapping is a
   matter of national security.

5. IANA Considerations

   [RFC Editor: please remove this section]

6. References

6.1.  Informative References

   [RFC1958]  Carpenter, B., Ed., "Architectural Principles of the
              Internet", RFC 1958, June 1996.

   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD
              9, RFC 959, October 1985.

   [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              RFC 1725, November 1994.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.
 

S. Moonesamy              Expires May 28, 2014                  [Page 4]
INTERNET DRAFT              Traffic peeking            November 24, 2013

   [Guar1]   <http://www.theguardian.com/world/2013/jun/06/us-tech-
              giants-nsa-data>

   [Guar2]   <http://www.theguardian.com/world/interactive/2013/
              nov/01/prism-slides-nsa-document>

   [NIST]    <http://csrc.nist.gov/publications/nistbul/
              itlbul2013_09_supplemental.pdf>

   [Rump]    <http://rump2007.cr.yp.to/15-shumow.pdf>

   [Tussle]   Clark D., Wroclawski J., Sollins K., Braden R., "Tussle in
              cyberspace: Defining tomorrow's Internet", 2002.

   [Wash1]   <http://www.washingtonpost.com/world/national-security/nsa-
              infiltrates-links-to-yahoo-google-data-centers-worldwide-
              snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-
              d89d714ca4dd_story.html>

Appendix A: IETF Protocols without encryption

There are several widely deployed IETF protocols which generate plain
text (unencrypted) traffic.  The specifications of these protocols
usually have a Security Considerations section to discuss the security
issues.  The specifications mentioned below is not an exhaustive list of
IETF protocols which are vulnerable to traffic peeking.

The File Transfer Protocol (FTP) [RFC0959] is sometimes used for
transferring files.  The specification does not provide any guidance
about encrypting the traffic generated by the protocol.

The Hypertext Transfer Protocol (HTTP) [RFC2616] is widely used to
access the web.   The protocol is sometimes used to provide web access
to email.  Section 15 of RFC 2616 [RFC2616] does not provide any
guidance about encrypting the traffic generated by the protocol.

The Internet Message Access Protocol, Version 4rev1 [RFC3501] can be
used by the end user to read email messages.  Section 11 of RFC 3501
[RFC3501] states that "sent in the clear over the network unless
protection from snooping is negotiated".  There is some information
about encrypting the traffic generated by the protocol.

The Post Office Protocol, Version 3 [RFC1939] can be used by the end
user to read email messages.  Section 13 of RFC 1939[RFC1939] does not
provide any guidance about encrypting the traffic generated by the
protocol.

The Simple Mail Transfer Protocol [RFC5321] is used for sending email
 

S. Moonesamy              Expires May 28, 2014                  [Page 5]
INTERNET DRAFT              Traffic peeking            November 24, 2013

messages.  Section 7 of RFC 5321[RFC5321] states that "SMTP mail is
inherently insecure".  It is mentioned in the section that "real mail
security lies only in end-to-end methods".

Author's Addresses

   S. Moonesamy
   76, Ylang Ylang Avenue
   Quatre Bornes
   Mauritius

   Email: sm+ietf@elandsys.com

S. Moonesamy              Expires May 28, 2014                  [Page 6]