Internet DRAFT - draft-crocker-strint-workshop-messaging

draft-crocker-strint-workshop-messaging







Network Working Group                                         D. Crocker
Internet-Draft                               Brandenburg InternetWorking
Intended status: Informational                                P. Resnick
Expires: July 20, 2014                       Qualcomm Technologies, Inc.
                                                        January 16, 2014


    STRINT Workshop Position Paper: Levels of Opportunistic Privacy
            Protection for Messaging-Oriented Architectures
               draft-crocker-strint-workshop-messaging-00

Abstract

   Given a concern for pervasive monitoring, messaging information
   needing protection includes primary payload, descriptive meta-data,
   and traffic-related analysis.  Complete protection against pervasive
   monitoring (PM), for traffic through complex handling sequences, has
   not yet been achieved reliably in real-world operation.
   Consequently, it is reasonable to consider a range of mechanisms, for
   protecting differing amounts of information and against monitoring of
   different kinds.  Although channel-based encryption can be helpful,
   it is not sufficient.  This paper considers pursuing different levels
   of end-to-end protection, referencing examples of component
   mechanisms that already have encouraging field experience.

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).  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 July 20, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Crocker & Resnick         Expires July 20, 2014                 [Page 1]

Internet-Draft   STRINT: Opportunistic Messaging Privacy    January 2014


   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.

1.  Background

   Concern for pervasive monitoring motivates the deployment of strong
   mechanisms that will protect against intrusive disclosure of
   information.  Information needing protection can be primary payload,
   descriptive meta-data, or traffic-related analysis.  Most Internet
   services operate according to a relatively simple, two-party client/
   server model, with the server holding primary data and performing
   primary actions, and the user having a direct relationship with the
   service being provided.  For these arrangements, concerns over
   privacy violations tend to focus on wiretapping of the data transfer
   mechanism and on server compromise.

   In contrast messaging architectures, such as for email [MAILARCH],
   can be highly distributed, with any number of application-level
   store-and-forward intermediaries.  This can produce complex sequences
   through many independent administrative authorities, possibly unknown
   to either the user or the recipient.  Because multi-hop store-and-
   forward messaging can involve several systems not under the
   administrative control of either end of the messaging transaction,
   compromise of any of the intermediate systems can expose messages to
   monitoring past the first, or before the last, hop.  Therefore end-
   to-end encryption is still highly desirable.  Key distribution and
   validation is one of the greatest impediments to deployment.

   Current multi-hop store-and-forward messaging on the Internet uses
   primarily two security technologies:

   1.  Channel encryption between the submitter and its submission
       server and final recipient and its receiving server,
       respectively, that encryption generally relying on CAs for
       authentication; and

   2.  End-to-end content encryption that relies on pre-authenticated
       certificates available to the end-points.

   The former is used, but does not provide sufficient protection
   against certain kinds of pervasive monitoring, and the latter is



Crocker & Resnick         Expires July 20, 2014                 [Page 2]

Internet-Draft   STRINT: Opportunistic Messaging Privacy    January 2014


   rarely used because of deployment and use barriers.  More
   opportunistic mechanisms might have a higher likelihood of
   deployment, with minimal effect on services, and therefore should be
   attempted.  Further if these opportunistic mechanisms do gain
   success, they can be used for further minimization of some forms of
   abuse.

   Complete protection against pervasive monitoring (PM), for traffic
   through complex handling sequences, has not yet been achieved
   reliably in real-world operation.  Consequently, it is reasonable to
   consider a range of mechanisms, for protecting differing amounts of
   information and against monitoring of different kinds.  The premises
   are that one or more of these might prove more effective than others
   and that some protection is better than none.

   Given the scale and urgency of community need for this protection,
   mechanisms should be based on established technologies, where
   possible.  While innovation is needed, it should be kept as modest as
   possible.  So the major challenge should be system design, rather
   than component invention, where possible and practical.

   There are four types of data to be considered for protection in a
   distributed messaging architecture:

   o  Message Content

   o  Header Content

   o  Envelope meta-data

   o  Handling meta-data

   Message content is considered the primary payload; for email this is
   the body of the message.  However messaging often contains additional
   content in a header, such as the names and addresses of authors and
   recipient, content summary, such as a Subject field, date of posting,
   and so on.  Envelope meta-data is the information used by the transit
   service, including recipient and return addresses.  Handling
   information is created during transit, such as for recording
   processing tags by intermediaries.  The placement of these bits of
   information can vary, so that distinguishing among them can sometimes
   be confusing.  As an example email relay handling meta-data is placed
   into the message header.

   Almost all efforts to protect messages have focused on the primary
   message content, with two well-known capabilities being standardized.
   [OPENPGP][SMIME] However after twenty-five years of these efforts to




Crocker & Resnick         Expires July 20, 2014                 [Page 3]

Internet-Draft   STRINT: Opportunistic Messaging Privacy    January 2014


   protect messages that are in transit, nearly all such traffic is
   still sent in the clear.

   In the absence of a success scenario for end-to-end payload privacy
   protection, it is not possible to be certain which barriers are
   critical, nor how to overcome them.  In current discussions, the
   primary culprits are believed to be key administration and end user
   interface design and performance complexity.  Both are deemed to
   require too much human effort, and a common view is to essentially
   remove humans from needing to configure their services or choose to
   use them.

   Channel encryption is low-hanging fruit when it comes to messaging
   security, though it only offers minimal protections against pervasive
   monitoring in its current use.  Right now, messaging-related channel
   encryption is almost exclusively used between end clients and their
   directly-associated servers, mostly for purposes of protecting the
   login credentials from monitoring.  It does result in clear message
   contents also being protected from snooping on the channel between
   the end client and server, and it protects envelope information
   (which is not otherwise protected by end-to-end content encryption.)
   However this protection only operates for the first and last message
   hops and leaves intermediate hops unprotected.  So the addition of
   channel security at every hop is still desirable.  Authentication can
   be recorded in the envelope if it takes place, presumably in a way
   that allows the recipient to confirm that the authentication took
   place, but authentication is not necessary for a large increase in
   security.  For intermediate hops opportunistic encryption would be a
   significant improvement and would be deemed sufficient for most
   cases.  The intermediate servers can simply do key exchange in-band.

2.  Incremental End-to-End Protection

   Channel encryption can not protect against some of the PM activities
   that have been documented.  So the more challenging concern is
   protection against collaborating or compromised intermediate nodes
   and even source and destination servers.  Ideally protection
   therefore must be end-to-end, defined in terms of the author's and
   recipient's independent user agents.  The difficulty of achieving
   this is exacerbated by the degree of existing Internet messaging
   activity that has all user agent behavior on, or controlled by, end-
   system web servers, rather than by independent software that is
   solely under the control of the author or recipient.  Hence the best
   end-to-end protection that will be achievable for many users is
   between originating server and receiving server.

   This highlights the need for incremental mechanisms that provide
   increasing protection.  Greater user independence should be able to



Crocker & Resnick         Expires July 20, 2014                 [Page 4]

Internet-Draft   STRINT: Opportunistic Messaging Privacy    January 2014


   permit greater user protection.  Another benefit of this incremental
   approach is that it is likely to provide some useful protection while
   still permitting exposure information necessary to legitimate
   management.  Of course, balancing between protecting against
   problematic monitoring and facilitating legitimate monitoring
   (management) requires agreement on the trade-offs and explicit
   choices amongst them.  The discussion and agreement remain an open
   and challenging task.

   An observation about focusing on PM protection is that use of
   encryption for that purpose does not necessarily carry the usual,
   accompanying requirement for strong authentication of one or both
   principals in the interaction.  In the extreme, this might mean that
   typical man-in-the-middle scenarios are not a concern, but it also
   can mean that authentication related to an agent -- rather than to
   the user -- is sufficient.

   This well might permit opportunistic privacy protection without
   direct user involvement, possibly with unauthenticated encryption and
   no human configuration, and for authentication to take place as a
   separate piece of user interface when that is desirable.  To the
   extent that human involvement is needed for the basic setup, it might
   be limited to service administrators, rather than end users.  The
   obvious appeal of this is that there are orders of magnitude fewer
   administrators than there are users, and administrators typically
   have far more technical skill.

   Key discovery is the most significant challenge during operation of a
   protection mechanism.  A promising approach that already has some
   field experience achieves key distribution through the [DNS].  The
   core requirement, of course, is determining what domain name to
   query.  The most obvious choice in a messaging service is the domain
   name of the recipient's address.  Enhancing this to permit DNS
   queries on an entire email address would be the refinement to
   attempt.

   A DNS-based mechanism would facilitate query, but would not deal with
   key administration.  Although there is activity in this space, easy
   key generation remain an open issue for the Internet.  However note
   that by making the critical actors for this service be operators, the
   scale of this challenge is dramatically smaller than if end users
   need to be involved.

   Given a basic key-discovery ability, the question then is what to
   encrypt?  Simply encrypting a message body is appealing, but leaves
   exposed all of the message header, as well as associated handling and
   envelope information.  This is where the "levels" reference in the
   paper's title comes in.  Additional mechanisms or services can



Crocker & Resnick         Expires July 20, 2014                 [Page 5]

Internet-Draft   STRINT: Opportunistic Messaging Privacy    January 2014


   protect increasing amounts of message-related information.  However,
   a pragmatic basis for choosing different levels is likely to prove
   challenging, since users cannot be relied on to make such decision.
   Still it will be worth pursuing an activity to describe the choices.
   Essentially, they are:

   o  Content

   o  Content + Header

   o  Content + Header + Envelope

   For email, one challenge in encrypting the message header is that the
   header is modified in transit.  A plausible approach is to
   encapsulate the original message as a [MIME] attachment, so that the
   visible message header is only a form of envelope.

   In order to obscure the origin/receiver envelope information, the
   message in transit needs to use different envelope data.  Given that
   the information is essential to message transit, this will require an
   overlay relay service, designed to hide actual author/recipient
   information.  It is worth considering enhancements, to integrate it
   more seamlessly for well-motivated users.

3.  Exemplars to Demonstrate Feasibility

   Although it is easy to offer appealing design ideas, estimating their
   real-world feasibility and utility can be challenging.  This paper is
   not intended to formulate detailed solutions, but it does need to
   provide some basis for comfort with the basic approaches it suggests.
   The discussion in this section is therefore intended to provide some
   substance, to that end.

   Rather than consider whether a detail discussed in this section is
   good or bad, or whether one approach is better or worse than another,
   the reader is encouraged merely to review the examples in terms of
   existing deployment experience and the likely pragmatics of
   incremental engineering and operations that is described.  While it
   is likely that superior designs can be specified, the requirement now
   is to develop a reasonable degree of comfort that the basic
   approaches are plausible.

3.1.  Administrators vs. Users

   There is considerable field experience with the difference between
   the administrative skills of professional operators, versus end-
   users.  With respect to key administration, specific examples include
   [DNSSEC] and [DKIM].  The experience shows that key administration



Crocker & Resnick         Expires July 20, 2014                 [Page 6]

Internet-Draft   STRINT: Opportunistic Messaging Privacy    January 2014


   tends to be daunting even for professionals, but is infeasible for
   most end users.

   A related point is the greater deployment and use success that is
   likely when providing protection between servers rather than between
   end-users.  An exemplar of this approach being successful for a
   security mechanism is [DKIM] as compared against the problematic
   deployment histories of [OPENPGP] and [SMIME].  However the obvious
   concern is that the end-users must rely on the safety of their server
   operations.

3.2.  Key Discovery

   Key discovery through the DNS already has several examples, including
   [DNSSEC], [DANE] and [DKIM].  In the aggregate they demonstrate that
   this basic approach is operationally reasonable.

3.3.  Per-User Keys

   The history of per-user key administration is particularly
   disheartening.  To the extent that key discovery via domain names has
   established a strong proof of concept, it is appealing to consider
   extending it to the granularity of complete email addresses.
   Although there have been some attempts at doing this, they gained no
   large-scale traction.

   Historically, there has been a basic incompatibility between email
   address encoding and domain name encoding.  A domain name is an
   undifferentiated sequence, whereas an email address is structured
   into two, semantically-distinct parts (separated by the "@" sign.)  A
   recent, popular enhancement to DNS naming is the use of an
   underscore-based node name, such as [SRVDNS] for information that
   does not need to be treated as a hostname.  The application of this
   enhancement could produce a query name in the style of:

                          Mailbox._at.example.net

   Hence, key query would be for a domain name, where the name might be
   a hostname or might be an encoded email address.  Although this would
   be a new mechanism, it entails no enhancement to infrastructure
   services and it re-uses a well-established and reasonably inexpensive
   form of DNS-based mechanism.

3.4.  Message Encapsulation

   Protecting the message header means that it needs to be hidden during
   transit, in spite of the header's being modified in transit, for
   email.  One approach to solving this is to encapsulate the entire



Crocker & Resnick         Expires July 20, 2014                 [Page 7]

Internet-Draft   STRINT: Opportunistic Messaging Privacy    January 2014


   message as a MIME attachment; the visible header therefore would only
   contain handling information.  This model of encapsulation only
   requires adoption by author (or originating server) and recipient (or
   receiving server) and is transparent to the message-handling
   infrastructure.  Architecturally, it is identical with the way MIME
   was propagated, in the 1990s, so it's viability has been well
   demonstrated.  Also, encapsulating an entire message as an attachment
   has already been enabled through [BSMTP].

3.5.  Protecting Envelope Meta-Data

   If envelope data is to be hidden during transit, it must be
   encapsulated in a message with different envelope data, and processed
   by special, trusted relays that hide addressing and transit
   information, and ensure that none is associated with the message when
   it is finally delivered.  This is in the spirit of [TOR].

4.  Security Considerations

   Everything in this draft related to security, and especially to
   confidentiality in the service of privacy protection.

5.  IANA Considerations

   There are no IANA considerations for this draft.

   Note to RFC Editor: Please remove the entire IANA Considerations
   section, prior to publication

6.  References - Informative

   [BSMTP]    Freed, N., Newman, D., Hoy, M., and , "The Batch SMTP
              Media Type", RFC 2442, November 1998.

   [DANE]     Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

   [DKIM]     Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
              Identified Mail (DKIM) Signatures", RFC 6376, September
              2011.

   [DNSSEC]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [DNS]      Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.



Crocker & Resnick         Expires July 20, 2014                 [Page 8]

Internet-Draft   STRINT: Opportunistic Messaging Privacy    January 2014


   [MAILARCH]
              Crocker, D., "Internet Mail Architecture", RFC 5598, July
              2009.

   [MIME]     Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [OPENPGP]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

   [SMIME]    Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

   [SRVDNS]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [TLS]      Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [TOR]      "TOR Project", WEB https://www.torproject.org/, .

Authors' Addresses

   Dave Crocker
   Brandenburg InternetWorking
   675 Spruce Drive
   Sunnyvale, CA  94086
   USA

   Phone: +1.408.246.8253
   Email: dcrocker@bbiw.net


   Pete Resnick
   Qualcomm Technologies, Inc.
   5775 Morehouse Drive
   San Diego, CA  92121
   US

   Phone: +1 858 6511 4478
   Email: presnick@qti.qualcomm.com







Crocker & Resnick         Expires July 20, 2014                 [Page 9]