Deployable Enhanced Email Privacy (DEEP)
draft-newman-email-deep-00

Network Working Group                                          C. Newman
Internet-Draft                                                    Oracle
Intended status: Standards Track                        November 3, 2013
Expires: May 7, 2014

                Deployable Enhanced Email Privacy (DEEP)
                     draft-newman-email-deep-00.txt

Abstract

   This specification defines a set of requirements and facilities
   designed to improve email privacy.  The focus of this proposal is to
   increase use of already deployed technology that can protect email
   privacy and provide a mechansim to record use of that technology.

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 May 7, 2014.

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

Newman                     Expires May 7, 2014                  [Page 1]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  Security Latches . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Introduction to Security Latches . . . . . . . . . . . . .  4
     3.2.  Initial Set of Security Latches  . . . . . . . . . . . . .  5
     3.3.  Security Latch Failures  . . . . . . . . . . . . . . . . .  6
   4.  Recording TLS Cipher Suite in Received Header  . . . . . . . .  6
   5.  DEEP Compliance  . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  DEEP Compliance For Both Servers and Clients . . . . . . .  7
     5.2.  DEEP Compliance for Servers  . . . . . . . . . . . . . . .  8
     5.3.  DEEP Compliance for Mail Clients . . . . . . . . . . . . .  9
     5.4.  DEEP Compliance for Mail User Agents . . . . . . . . . . . 10
     5.5.  DEEP Compliance for SMTP Relay Clients . . . . . . . . . . 10
     5.6.  DEEP Compliance for Anti-Virus/Anti-Spam Software and
           Services . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.7.  DEEP Compliance for an SMTP relay proxy  . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Design Considerations . . . . . . . . . . . . . . . . 13
   Appendix B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15

Newman                     Expires May 7, 2014                  [Page 2]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

1.  Introduction

   Email software on the Internet that provides mail access and transfer
   via Internet Message Access Protocol (IMAP) [RFC3501] and Simple Mail
   Transfer Protocol (SMTP) [RFC5321] usually have Transport Layer
   Security (TLS) [RFC5246] support but often do not use it in a way
   that maximizes the end-user privacy it can provide.  This
   specification proposes three changes to email software and
   deployments intended to improve this situation.  First, a security
   latch mechanism is provided to automatically enable and use improved
   TLS (or other security) capabilities without user or administrator
   intervention.  Second, a mechanism is provided to record additional
   information about the security and privacy provided during email
   transit through extensions to the Received header [RFC5321].  Third,
   a set of requirements and recommendations are provided to determine
   if email software is DEEP compliant.

   It's helpful to understand the constraints on deployed Internet mail
   service to evaluate if a mechanism is deployable.  At the time this
   is written, Internet email is a widely deployed commodity service and
   a critical component of online commerce.  As a result, the email
   infrastructure is resistent to change.  Email software for desktop
   operating systems is rarely upgraded.  Email software for smaller
   devices is exploring available IMAP extensions that can improve
   battery life, but otherwise appears to have limited investment.
   Email service providers generally operate on tight budgets and will
   not deploy any email-related technology that could increase support
   calls from customers.  Some service providers run email server
   software that is years out of date.

   This situation creates constraints on deployable email technology.
   First, it can't change anything fundamental about the nature of email
   software and service.  Second, it has to be useful even if deployed
   in only a subset of the email system.  Third, it can't significantly
   increase the cost of service administration.  DEEP is designed to
   improve end-user privacy within these constraints.

   DEEP is targeted at improving hop-to-hop privacy rather than end-to-
   end security.  As a result, it provides no protection from insider
   attacks.  Most email passes through two administrative domains
   [RFC5598]: one used for submission and a second one used by the
   recipient to access mail.  DEEP does not protect email from analysis
   and interception by the service providers involved in mail transfer.

   This is an early draft and is subject to change.  Implementation of
   this proposal is not recommended at this time.

Newman                     Expires May 7, 2014                  [Page 3]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This specification expresses syntax using the Augmented Backus-Naur
   Form (ABNF) as described in [RFC5234], including the core rules in
   Appendix B and rules from [RFC5322].

3.  Security Latches

3.1.  Introduction to Security Latches

   Once an improved email security or privacy mechanism is made
   available, it is desirable to continue using it for future email
   transfer.  Although TLS is widely deployed in email software, use of
   TLS is often not required.  Mail user agents (MUAs) [RFC5598] will at
   best make a determination if TLS is available when an account is
   first configured and may require use of TLS with that account if and
   only if it was initially available.  If the service provider makes
   TLS available after initial client configuration, many MUAs will not
   notice the change.  Mail transfer agents sometimes use TLS on an
   opportunistic basis but this use is optional in most deployments and
   will silently stop if either peer stops offering the capability.

   A security latch is identified by a short alphanumeric token and
   indicates that a security facility was available and used for a mail
   transfer between a client and a server.  The client stores the
   security latches associated with the server's host identifier (prior
   to DNS lookup) in persistent or semi-persistent storage.  The
   security facilities indicated by the stored security latches will be
   required for subsequent connections from that client to that server.

   Protocol clients for IMAP [RFC3501], Message Submission [RFC6409] and
   SMTP transfer [RFC5321] are expected to store tuples including the
   name used for the first DNS lookup related to the connection, the
   mail service being performed (message access, message submission or
   message rely) and the security latch.  SMTP rely clients MAY expire
   these stored tuples to control the size of security latch storage,
   but MUST retain them for a period of at least two months.

   An identifier for a security latch has the following formal syntax:

     security-latch-id  =  ALPHA *31(ALPHA / DIGIT / "-")

   Security latches are intended to represent a one-way improvement to

Newman                     Expires May 7, 2014                  [Page 4]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

   privacy or security.  As a result, it's generally inappropriate to
   associate a security latch with a specific cryptographic algorithm.
   However, if weaknesses have been discovered in a deployed
   cryptographic algorithm it can be appropriate to define a security
   latch to indicate it is not necessary to use that algorithm with that
   peer in the future.  Two examples of the latter are included in the
   initial set of security latches.

3.2.  Initial Set of Security Latches

   This section describes an initial set of security latches.  The IANA
   Considerations section Section 6 defines a registry so that more
   latches can be defined in the future.

   tls10  This security latch indicates that TLS version 1.0 [RFC2246]
      or later was negotiated successfully including negotiation of a
      strong encryption layer with a symmetric key of at least 128 bits.
      This latch does not indicate that the server certificate was
      valid.

   tls11  This security latch indicates that TLS version 1.1 [RFC4346]
      or later was negotiated successfully including negotiation of a
      strong encryption layer with a symmetric key of at least 128 bits.
      This latch does not indicate that the server certificate was
      valid.

   tls12  This security latch indicates that TLS version 1.2 [RFC5246]
      or later was negotiated successfully including negotiation of a
      strong encryption layer with a symmetric key of at least 128 bits.
      This latch does not indicate that the server certificate was
      valid.

   tls-cert  This security latch indicates that TLS was successfully
      negotiated and the server certificate was successfully verified by
      the client using the algorithm described in
      [I-D.melnikov-email-tls-certs].  For SMTP transfer [RFC5321] the
      name used for the MX lookup for mail routing is used with the
      algorithm in [RFC6125]

   tls-dane-tlsa  This security latch indicates the TLS server
      certificate was verified using the procedures described in "The
      DNS-Based Authentication of Named Entities (DANE) Transport Layer
      Security (TLS) Protocol: TLSA" [RFC6698].

   tls-nomd5  This security latch indicates that a TLS cipher suite was
      negotiated that did not use the MD5 cryptographic hash algorithm
      [RFC1321].

Newman                     Expires May 7, 2014                  [Page 5]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

   tls-norc4  This security latch indicates that a TLS cipher suite was
      negotiated that did not use the RC4 cipher.

   tls-pfs  This security latch indicates that a TLS cipher suite was
      negotiated that included the "perfect forward secrecy" property.

3.3.  Security Latch Failures

   When a security latch has been set for connections from a client to a
   server and the property identified by that latch is no longer
   available, this results in a connection failure.  For an MUA, the
   end-user should be encouraged to contact their service provider.  An
   MUA might suggest deleting the account and re-creating it as a
   cumbersome mechanism to reset the security latches.  MUAs are
   discouraged from offering a lightweight option to reset or ignore
   security latches as this defeats much of the benefit they provide to
   end users.  A mail transfer agent (MTA) is encouraged to treat
   security latches as a temporary failure so the messages sit in a
   queue for the retry period and an administrator can intervene.
   Providing a way for an administrator to reset security latches in an
   MTA is likely necessary, particularly for the case of an expired
   server certificate.  MTAs are encouraged to provide a way to reset a
   subset of security latches that does not eliminate all privacy; for
   example by clearing all latches except one of the versioned tls
   latches.

   When MTA transport fails due to a security latch, the MTA MUST use
   the SMTP enhanced status code X.7.TBD.  The SMTP notary response
   [RFC3464] for a security latch failure MUST include an additional
   "SMTP-Security-Latch" recipient-specific header field that includes a
   space-delimited list including one or more security latch that
   failed.  The ABNF for this new field follows:

     CFWS                 =  <defined in RFC 5322>

     FWS                  =  <defined in RFC 5322>

     smtp-security-latch  =  "SMTP-Security-Latch:" CFWS
                             security-latch-id *(FWS security-latch-id)

4.  Recording TLS Cipher Suite in Received Header

   The ESMTPS transmission type [RFC3848] provides trace information
   that can indicate TLS was used when transferring mail over the
   Internet.  If this is combined with a success delivery status
   notification (DSN) that requests header return [RFC3461] that

Newman                     Expires May 7, 2014                  [Page 6]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

   provides a way to determine if TLS usage was recorded for all
   transfers for which trace information is available.  However, TLS
   usage by itself is not a guarantee of privacy or security.  The TLS
   cipher suite provides additional important information about the
   level of privacy or security made available for that hop.  This
   defines a new SMTP "tls" Received header additional-registered-clause
   that is used to record the TLS cipher suite that was negotiated for
   the connection.  The value included in this additional clause SHOULD
   be the registered cipher suite name (e.g.,
   TLS_DHE_RSA_WITH_AES_128_CBC_SHA) included in the TLS cipher suite
   registry.  In the event the implementation does not know the name of
   the cipher suite (a situation that should be remedied promptly), a
   four-digit hexadecimal cipher suite identifier MAY be used.  The ABNF
   for the field follows:

     tls-cipher-clause  =  CFWS "tls" FWS tls-cipher

     tls-cipher         =  tls-cipher-suite-name / tls-cipher-suite-hex

     tls-cipher-name    =  ALPHA *(ALPHA / DIGIT / "_")
                           ; as registered in IANA cipher suite registry

     tls-cipher-hex     =  "0x" 4HEXDIG

5.  DEEP Compliance

   This section describes what is required for various entities in a
   mail system to be DEEP compliant.  An Internet service provider is
   considered DEEP compliant if all components in their mail system are
   DEEP compliant.

5.1.  DEEP Compliance For Both Servers and Clients

   In order to be DEEP compliant, software has to meet the following
   requirements.  These requirements apply to MUAs, MTAs, SMTP proxies
   and IMAP servers.

   o  MUST implement TLS 1.2 or later [RFC5246] for any connections made
      or received via IMAP, SMTP or Message Submission.

   o  MUST implement the TLS 1.2 mandatory-to-implement cipher suite
      TLS_RSA_WITH_AES_128_CBC_SHA for any connections made or received
      via IMAP, SMTP or Message Submission.

   o  MUST implement the TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite
      for any connections made or received via IMAP, SMTP or Message
      Submission.

Newman                     Expires May 7, 2014                  [Page 7]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

   o  MUST implement the IMAP4rev1 mandatory-to-implement cipher suite
      TLS_RSA_WITH_RC4_128_MD5 for any connections made or received via
      IMAP.

5.2.  DEEP Compliance for Servers

   This section applies to server software that accepts TCP connections
   for IMAP, SMTP or Message Submission.  In order to be DEEP compliant
   these servers have to meet the following requirements.

   o  MUST prefer the TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite over
      the TLS_RSA_WITH_AES_128_CBC_SHA.

   o  MUST prefer the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite over the
      TLS_RSA_WITH_RC4_128_MD5 cipher suite.

   o  SHOULD prefer cipher suites that offer the "perfect forward
      secrecy" property over cipher suites that do not.

   o  MUST prefer cipher suites that do not use MD5 over cipher suites
      that use MD5.

   o  SHOULD prefer cipher suites that do not use RC4 over cipher suites
      that do use RC4.

   o  SMTP receivers and message submission servers MUST advertise
      STARTTLS [RFC3207] in response to the EHLO command if TLS has not
      yet been negotiated, and successful TLS negotiation is possible.

   o  IMAP servers MUST advertise STARTTLS in response to the CAPABILITY
      command (and in the server greeting CAPABILITY if provided) if TLS
      has not yet been negotiated, and successful TLS negotiation is
      possible.

   o  Servers MUST NOT advertise STARTTLS if it is unlikely to succeed
      based on server configuration (e.g., there is no server
      certificate installed).

   o  SMTP receivers and message submission servers MUST add a received
      header to the message [RFC5321] including the tls clause described
      in Section 4.

   o  SMTP and IMAP servers MUST be able to include the TLS cipher
      information in any connection logging or auditing facility they
      provide.

Newman                     Expires May 7, 2014                  [Page 8]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

5.3.  DEEP Compliance for Mail Clients

   This section applies to client software that connects to TCP sockets
   on servers for IMAP, SMTP relay or Message Submission.  In order to
   be DEEP compliant these clients have to meet the following
   requirements.

   o  MUST look for STARTTLS in the protocol's capability listing
      (including the EHLO response for SMTP) and attempt to negotiate
      TLS before sending a password if STARTTLS is advertised.

   o  MUST be able to negotiate and use a strong TLS encryption layer
      regardless of the server certificate's validity.  In particular,
      the client MUST be able to use TLS session encryption even if the
      server certificate is expired, self-signed or both.

   o  MUST be able to save the "tls10" security latch if the client is
      able to establish strong encryption with the server.

   o  MUST be able to validate server certificates as described for the
      "tls-cert" security latch and save that latch.

   o  If the TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite is
      successfully negotiated, the client MUST save the "tls-norc4",
      "tls-nomd5" and "tls-pfs" security latches.

   o  If the TLS 1.2 mandatory-to-implement cipher suite
      TLS_RSA_WITH_AES_128_CBC_SHA is successfully negotiated, the
      client MUST save the "tls-norc4" and "tls-nomd5" security latches.

   o  Clients MAY support TLSA [RFC6698].  If a client supports both
      TLSA and DEEP, it MUST save the "tls-dane-tlsa" security latch if
      TLSA is successfully negotiated.

   o  If the "tls-nomd5" security latch is set, the client MUST NOT
      offer to use any cipher suite using the MD5 algorithm in the TLS
      negotiation.

   o  If the "tls-norc4" security latch is set, the client MUST NOT
      offer to use any cipher suite using the RC4 algorithm in the TLS
      negotiation.

   o  If the "tls-pfs" security latch is set, the client MUST NOT offer
      to use any cipher suite lacking the "perfect forward secrecy"
      property in the TLS negotiation.

   o  Clients SHOULD implement the "tls11" and "tls12" security latches
      (the TLS library has to provide an API that communicates the TLS

Newman                     Expires May 7, 2014                  [Page 9]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

      protocol version used to the application for this to be possible).
      If the MUA implements the "tls11" and "tls12" security latches,
      the MUA MUST disable the ability to negotiate TLS 1.0 and TLS 1.1
      if a higher TLS version is latched.

5.4.  DEEP Compliance for Mail User Agents

   A MUA is considered DEEP compliant if it implements all of the
   following requirements and includes a public list of any
   recommendations below that it does not implement.

   o  MUAs MUST store the security latches mentioned in the previous
      section in persistent storage.  It is sufficient to store security
      latches for the servers associated with a mail account with the
      account configuration.

   o  MUAs SHOULD be able to request success delivery status
      notifications via mail submission with the "RET=HDRS" ESMTP
      parameter and the "NOTIFY=SUCCESS,DELAY,FAILURE" ESMTP parameter
      [RFC3461].

5.5.  DEEP Compliance for SMTP Relay Clients

   These requirements apply to SMTP relay clients as found on submission
   servers and MTAs.

   o  MUST implement a persistent (e.g., database) or semi-persistent
      (e.g., replicated RAM cache) storage mechanism for security
      latches associated with a recipient MTA's domain name.  Examples
      of a compliant implementation include storage in an embedded
      database (e.g., SQLlite or Oracle Berkeley DB) or support for
      storage and access to security latches via an appropriate protocol
      for that purpose (e.g., MySQL Client/Server Protocol, memcached
      protocol, etc).

   o  MUST implement the tls10, tls-nomd5, tls-norc4, tls-pfs security
      latches and set them as appropriate for each envelope recipient
      right-hand-side.

5.6.  DEEP Compliance for Anti-Virus/Anti-Spam Software and Services

   There are multiple ways to connect an Anti-Virus and/or Anti-Spam
   (AVAS) service to a mail server.  Some mechanisms, such as the de-
   facto milter protocol do not impact DEEP.  However, some services use
   an SMTP relay proxy that intercepts mail at the application layer to
   perform a scan and proxy to the real MTA.  Deploying AVAS services in
   this way can cause many problems [RFC2979] including direct
   interference with DEEP.  An AVAS product or service is considered

Newman                     Expires May 7, 2014                 [Page 10]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

   DEEP compliant if all IMAP and SMTP-related software it includes is
   DEEP compliant.

5.7.  DEEP Compliance for an SMTP relay proxy

   An SMTP relay proxy generally has no queue and will have a client
   connection open at the same time as a connection to a real MTA,
   passing data through if it meets the proxy's goals.  An SMTP proxy
   MUST comply with the SMTP relay server requirements (for its server
   component) and the SMTP relay client requirements (for its client
   components).  In particular, the SMTP proxy MUST add a received
   header with the tls clause described in Section 4.  If an SMTP proxy
   connects to an explicitly configured list of servers, then the
   requirement to store security latches on a per-host basis is waived
   and the proxy is compliant if it persistently stores security latches
   that apply to all back-ends.

6.  IANA Considerations

   TBD:

   o  Create expert review, publication required registry for security
      latches.  Initialize registry with latches from Section 3.2.

   o  Add new "tls" Additional-registered-clauses for received to SMTP
      extensions registry to indicate TLS cipher suite selected.

   o  Add new SMTP enhanced status code [RFC5248] to indicate failure of
      a security latch.  Can be temporary (e.g., expired server
      certificate) or permanent, but generally prefer temporary.

   o  Add new DSN [RFC3464] SMTP-Security-Latch per-recipient field to
      indicate the security latch(es) that caused a delivery failure.

7.  Security Considerations

   This entire document is about security considerations.  TBD: add more
   text here.  In general, this is targeted to improve mail privacy and
   to mitigate threats external to the email system such as network-
   level snooping or interception; this is not intended to mitigate
   active attackers who have compromised service provider systems.

8.  References

Newman                     Expires May 7, 2014                 [Page 11]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

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

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, January 2003.

   [RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
              for Delivery Status Notifications", RFC 3464,
              January 2003.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

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

   [RFC5248]  Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
              Mail System Status Codes", BCP 138, RFC 5248, June 2008.

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

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, March 2011.

   [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              STD 72, RFC 6409, November 2011.

   [I-D.melnikov-email-tls-certs]
              Melnikov, A., "Updated TLS Server Identity Check Procedure
              for Email Related Protocols",
              draft-melnikov-email-tls-certs-01 (work in progress),
              October 2013.

Newman                     Expires May 7, 2014                 [Page 12]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

8.2.  Informative References

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2979]  Freed, N., "Behavior of and Requirements for Internet
              Firewalls", RFC 2979, October 2000.

   [RFC3848]  Newman, C., "ESMTP and LMTP Transmission Types
              Registration", RFC 3848, July 2004.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

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

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

Appendix A.  Design Considerations

   This was written independently from draft-moore-email-tls-00.txt.
   This author believes it would be desirable to merge these two
   proposals.  The arguments against STARTTLS in the other draft are
   largely resolved by the use of security latches.  However, I agree
   with the end-goal of having all mail protocols except SMTP-relay
   always use a TLS-only port.  This document presently doesn't mention
   TLS-only ports, although MUA software that switches (and latches) to
   a TLS-only port if STARTTLS is present in the capabilities would
   comply with this document.  At a minimum it makes sense to encourage
   that behavior and require implementation of TLS-only ports.

   There are many open issues with this document.  Here is an attempt to
   enumerate some of them:

   o  A suggestion has been made to add a DNSSEC latch.  I like the
      idea, but may need help writing the text and references correctly.

   o  There is concern that the tls-nomd5 and tls-norc4 latches could
      result in worse security choices.  If, for example, a
      vulnerability were found in AES resulting in that cipher being
      disabled but the existing weaknesses in RC4 remained relatively

Newman                     Expires May 7, 2014                 [Page 13]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

      minor in the TLS context, then the tls-norc4 latch would cause
      problems rather than make security better.  I feel the idea
      remains interesting enough to merit debate, but there is a good
      chance these two latches will be removed.

   o  Having security latches result in a relatively serious failure as
      described in Section 3.3 risks violating an important goal of not
      introducing something that could generate support calls.  However,
      a lesser failure reduces the resistance to man-in-the-middle
      attacks that security latches can provide.  In general, I'd prefer
      to balance those two goals whenever possible.  However, security
      that doesn't deploy is useless so man-in-the-middle defenses have
      to go if they are likely to prevent deployment.  Getting defenses
      from passive eavesdropping deployed is definitely feasible and
      much more important.  Feedback from potential implementers and
      service providers will be helpful to determine the right path here
      and is welcome.

   o  I'm presently concerned about certificate expiration causing
      support calls that would deter deployment of this proposal due to
      the tls-cert security latch.  Some of the requirements in
      draft-moore-email-tls-00.txt related to certificate management may
      help with this.  A requirement for server software to generate an
      alarm, admin email and/or log message as certificate expiration
      approaches may also be helpful there.

   o  This does not presently discuss pinning certificates.  In general,
      I consider pinning certificates with an expiration date to be a
      serious deployment problem due to support calls generated when the
      certificates expire and difficulty of upgrading pinned
      certificates with a reasonable user interface at the MUA.

   o  I'm concerned by the required support for DNS-ID and SRV-ID in
      draft-melnikov-email-tls-certs-01; and feel it may be premature to
      require that (particularly SRV-ID) if we want something
      deployable.

   o  I believe the security latch in this is complementary with
      draft-ietf-dane-smtp-with-dane-02 but haven't thought about the
      issues in depth.  I welcome feedback on this point.

   o  TLS_DHE_RSA_WITH_AES_128_CBC_SHA was chosen because it's perhaps
      the most widely implemented cipher suite with perfect-forward-
      secrecy.  However, that choice is subject to change based on
      feedback from the security community about the preferred PFS
      cipher suite to start using.

Newman                     Expires May 7, 2014                 [Page 14]
Internet-Draft  Deployable Enhanced Email Privacy (DEEP)   November 2013

   o  This does not presently cover POP.  Adding POP would make this
      document slightly more complex so it was simpler to omit for the
      first version.  The author would not object to adding POP.

   o  This does not presently include a mechanism to determine what
      security latches were set during message transit.  However, by
      defining a standard syntax and registry for security latches it is
      possible to add such a mechanism in a future proposal.  Message
      Tracking Query Protocol could be used to provide such a mechanism.

Appendix B.  Acknowledgements

   Many thanks to Ned Freed for refinement of the initial concepts in
   this document.  Thanks to Dan Newman and Alexey Melnikov for review
   feedback.  Thanks to Paul Hoffman and Keith Moore for interesting
   feedback in initial conversations about this idea.

Author's Address

   Chris Newman
   Oracle
   440 E. Huntington Dr., Suite 400
   Arcadia, CA  91006
   US

   Email: chris.newman@oracle.com

Newman                     Expires May 7, 2014                 [Page 15]