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 = FWS = 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]