Internet DRAFT - draft-wchuang-msmd
draft-wchuang-msmd
Application Area Working Group W. Chuang
Internet-Draft N. Lidzborkski
Expires: April 18, 2014 E. Bursztein
Google, Inc.
October 15, 2013
MSMD: Mandatory Secure Mail Delivery
draft-wchuang-msmd-00
Abstract
Opportunistic SMTP TLS does not enforce electronic mail delivery
using TLS leading to potential loss of privacy and security. We
propose an optional mail header extension "mandatory-secure-mail-
delivery:" and SMTP EHLO response extension "MSMD" that indicates
mail must be delivered privately using TLS and with integrity using
DKIM, and thereby provide a security guarantee to the user. When
mail is sent with the header indicating privacy and integrity and if
the receiving party does not support this, the mail is instead
bounced. To protect the mail after delivery, the destination SMTP
server must advertise its capabilities as part of the EHLO response,
and the sender can choose whether the destination is able to honor
the privacy requirements specified on the mail header.
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 April 18, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Chuang, et al. Expires April 18, 2014 [Page 1]
Internet-Draft MSMD October 2013
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.
This document may not be modified, and derivative works of it may not
be created, and it may not be published except as an Internet-Draft.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Mandatory Private Delivery Specification . . . . . . . . . . 5
2.1. MSMD Mail Header . . . . . . . . . . . . . . . . . . . . 5
2.2. MSMD SMTP Extension . . . . . . . . . . . . . . . . . . . 6
2.3. Domain Keys Identified Mail . . . . . . . . . . . . . . . 6
2.4. Deployment Concerns . . . . . . . . . . . . . . . . . . . 6
2.5. Delivery Failure Notification . . . . . . . . . . . . . . 7
2.6. Mail User Agent Support . . . . . . . . . . . . . . . . . 7
2.6.1. IMAP Extension . . . . . . . . . . . . . . . . . . . 8
2.6.2. POP3 Extension . . . . . . . . . . . . . . . . . . . 8
2.7. Compatibility . . . . . . . . . . . . . . . . . . . . . . 8
3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Optional Requirements and Capabilities . . . . . . . . . . . 11
4.1. Mail Header Requirements . . . . . . . . . . . . . . . . 11
4.2. SMTP MSMD Capabilities . . . . . . . . . . . . . . . . . 12
4.3. Example with Requirements and Capabilities . . . . . . . 12
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Opportunistic SMTP TLS [RFC3207] does not enforce electronic mail
delivery using TLS. This means that even if a user wishing to send
mail has a provider that supports SMTP TLS, the provider does not
necessarily deliver mail over TLS depending on whether the peer
supports TLS or if the TLS negotiation fails. Unfortunately our
observation is that most mail providers do not support SMTP TLS.
These deployment problems are made worse because users typically do
not have control over delivery and do not know whether their message
will be delivered securely. Also users have an assumption that their
Chuang, et al. Expires April 18, 2014 [Page 2]
Internet-Draft MSMD October 2013
mail content will be delivered without modifications though in fact
with traditional SMTP [RFC5321] there is no assurance of this. This
combination diminishes trust amongst electronic mail users.
We believe that finding a solution will become more important as
recent news indicates that eavesdroppers will increasingly targeting
electronic mail delivery as a likely point of attack (if not
already). This is motivated by the observation that web client side
security has steadily improved due to increasingly effective and
deployed encryption [1] while most mail delivery remains unencrypted.
Moreover SMTP TLS is more susceptible to active attack such as Man-
in-the-Middle (MitM) than web client security. Attacks such as
certificate forgery or TLS downgrade have been mitigated with
certificate pinning [2] and HSTS [RFC6797]. No such mechanism exists
today with SMTP TLS.
The main alternative is to use encrypted mail such as PGP/MIME and S/
MIME which keep the mail body private during delivery. However they
do nothing to guarantee private mail delivery, and traditional SMTP
transmits the sender and the recipient in the clear. Thus even PGP/
MIME [RFC3156] or S/MIME [RFC5751] encrypted mail is susceptible to
meta-data surveillance.
We propose optional mail extensions that indicates that mail delivery
must be delivered privately using TLS, and must be signed with DKIM
to indicate authenticity and integrity. The user or their provider
can choose to set a new mail header "mandatory-secure-mail-delivery:"
that indicates private mail distribution as described in Section 2.1.
When mail is sent with this header, the SMTP client (sending SMTP
server) checks if the receiving side supports encrypted and signed
private delivery. If not, the mail is bounced. The bounce message
must be returned to sender securely as well, otherwise the message
must be dropped. A courtesy message may be sent to the recipient
depending on the sender's settings. Another concern is maintaining
the security of the mail at the destination and beyond. The SMTP
server (destination SMTP server) must advertise it supports and
enforces this protocol as part of the EHLO response using the
extension "MSMD" which the sender will verify as described in
Section 2.2. Mail providers that honor this protocol should ensure
that derivative mails created such as when forwarding and replying
maintain the requested private mail delivery property by copying the
security header to the new message. This is not mandatory in the
base protocol because honoring it would impose restrictions for all
Mail User Agent interfaces that would be a substantial barrier to
entry. In the following sections, we show how we can elevate the
"should" to "must" for securing derivative mails. Thus with the base
protocol at minimum a sender can be certain that a sent mail will be
delivered privately and unaltered.
Chuang, et al. Expires April 18, 2014 [Page 3]
Internet-Draft MSMD October 2013
The protocol can impose additional security requirement options via
arguments on the message-header as described in Section 4.1 that the
SMTP client can verify. As part of this verification process, the
SMTP server can also advertise domain security capability options as
part of the EHLO response as described in Section 4.2. They can help
insure the recipient's mail provider is just as capable of verifying
the security requirements as the sender's provider. Options enable
the protocol to flexibly extend the definition of security to meet
different needs, and to evolve as the security standing of the
ecosystem improves.
Options are particularly useful if the sender wishes to mandate
enforcement of the protocol for the entire conversation meaning
through all derived forwarded and replied mails. We propose a Secure
Conversation and Access (SCA) option that mandates for all mail
messages so marked, all derived mail must also be so marked. Any
mail agent in the domain must honor and propagate the additional SCA
protocol in addition to the base protocol. This imposes a powerful
and stringent requirement over all MUA such as IMAP or POP3 to
support the protocol as described in Section 2.6, or not be able to
access these messages. SCA also requires that these clients must
access these messages privately over an encrypted channel. Thus a
sender can be sure that a sent mail and its derivatives will be sent
and accessed securely.
Via options we can also specify TLS settings to improve security. Of
the threats to TLS, perhaps the most difficult to protect against is
MitM since the adversary impersonates the endpoint. To defend
against this, we bundle various TLS settings into tiers corresponding
to the capabilities of ecosystem that improves the ability to reject
MitM peers.
This example illustrates the message declaration, and that of the
recipient i.e. the base protocol. It also illustrates the
verification by the sender. We use the convention "C:" for client
and "S:" for server.
Some mail message has a private delivery request, which specifies the
mail header:
mandatory-secure-mail-delivery:
The SMTP exchange protocol appears as follows:
S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.server.org SMTP service ready
C: EHLO mail.client.com
S: 250-mail.server.org welcomes you
S: 250-STARTTLS
Chuang, et al. Expires April 18, 2014 [Page 4]
Internet-Draft MSMD October 2013
S: 250-MSMD
S: 250 DSN
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation using default TLS requirements>
C & S: <negotiate a TLS session>
C: EHLO mail.client.com
S: 250-mail.server.org welcomes you
S: 250-MSMD
S: 250 DSN
C: <Perform MSMD Requirements Check: On failure close the connection>
C: DATA
C: <Send mail with DKIM signature>
Note: 1) TLS requirements are passed to the TLS setup 2) after the
second EHLO, that there is a MSMD Requirements Check. The latter
verifies that the TLS connection has started, and that the MSMD
SMTP extension was presented on the second EHLO.
Figure 1: Basic MSMD Protocol Example
2. Mandatory Private Delivery Specification
2.1. MSMD Mail Header
We propose a new optional mail header: [RFC5322] "mandatory-secure-
mail-delivery:" (MSMD) in accordance with [RFC3864]. The MSMD header
indicates that this message must be privately distributed using
encryption. It may have associated with it parameters that impose
additional requirements on the delivery security and destination
security. The parameters will be discussed further in Section 4.1.
Requirements may only be applied if the user's mail provider can
support those requirements.
Mail messages derived from a mail message with the MSMD message
header should copy this header along with any options, and those
derived messages must honor the security protocol. Examples of
deriving the message are replying and forwarding the mail message.
If the Secure Conversation and Access option is specified, the
derived message must copy the message header. The user is free to
download the content, or distribute the contents via GUI means such
as cut or copy and paste without the header. The distinction is
meant to protect mail content against accidental exposure via
unencrypted mail delivery, but not stymie legitimate every day use of
mail content. Derived mail may add additional security requirements
to the MSMD message header but must not remove any requirements.
Chuang, et al. Expires April 18, 2014 [Page 5]
Internet-Draft MSMD October 2013
2.2. MSMD SMTP Extension
When delivering the mail message, the SMTP client must verify that
the destination will honor maintaining the MSMD protocol once the
message is delivered. To support this, the SMTP server advertises
that it supports the protocol via a MSMD SMTP extension [RFC5321].
This means that during the EHLO response, there will be a "MSMD"
keyword, and that it may be followed by parameters describing
additional capabilities of the server. The capabilities are
described in Section 4.2. The SMTP client verifies that the SMTP
server has both MSMD and STARTTLS extensions, then establishes the
TLS connection. As the connection at this point is encrypted and
private, it redoes the EHLO, gathering any capabilities specified by
the server. Then it does the MSMD requirements check using the
securely communicated capabilities values. In the basic
configuration meaning without any additional requirements or
capabilities, SMTP client just verifies the connection is in TLS, and
re-verifies that there is a MSMD SMTP extension. Success allows mail
delivery to continue, while failure causes a notification to be sent
as described Section 2.5 and the TLS and SMTP connection is closed
and reset. Any other Mail Transfer Agent must support this protocol
in a similar fashion or be prevent from transferring mails marked by
the MSMD header.
2.3. Domain Keys Identified Mail
All MSMD market mails must be sent with DKIM [RFC6376] signatures to
provide assurance for the integrity and authenticity of the mail
message. Similarly MSMD SMTP Servers must verify received DKIM
messages. In the MSMD context, how DKIM handles failed signature
verification is up to the mail provider. MSMD mandates that at least
the message body and "mandatory-secure-mail-delivery:" header be
signed leaving the rest as implementation dependent.
2.4. Deployment Concerns
Though much of this proposal is concerned with security of SMTP mail
delivery, the base protocol recommends that all other means of
accessing the protected mail via Mail User Agents should be similarly
protected. This means all mail fetch mechanism should similarly
honor the encrypted delivery requirement and should propagate the
MSMD header to derived mails.
If the Secure Conversation and Access option is given, the
restrictions on MUA become mandatory. Also to prevent eavesdropping
during fetch, SCA places a further requirement to encrypt access. If
the MUA cannot insure propagating the MSMD protocol or provide
private access, that they must be prevented from accessing user data
Chuang, et al. Expires April 18, 2014 [Page 6]
Internet-Draft MSMD October 2013
marked with the MSMD security header. Upon access failure these
clients should use whatever error reporting mechanism built into the
protocol to provide a notification indicating the cause and an
alternative means of accessing the mail securely.
Mailing list forwarders supporting the MSMD protocol must also check
if each list recipient honors the protocol in the same way as a
single recipient. Failure to meet the security requirements results
in the message not being delivered and may result in notification of
delivery failure. These forwarders must also insure that DKIM
verification will succeed either by maintaining the exact same MSMD
header and message body, or by re-generating the DKIM signature.
2.5. Delivery Failure Notification
For message delivery failure due to insufficient security, the sender
will be notified via a non-delivery notification message [RFC3461].
For diagnostics, these security bounce messages should include at
least a description of the failure including which step of the SMTP
handshake that failed, any missing requested options, and identifying
information such as destination and subject. Security bounce
messages must be delivered with the same security guarantees as the
originating message. This means that the MSMD header is copied to
the bounce message, and honored as with the original, and a DKIM
signature placed on the message. To prevent an endless notification
loop, delivery failure of these security bounce messages due to MSMD
protocol failure causes the message to be silently dropped.
Upon security failure on delivery, the SMTP client may still sent a
courtesy message to the recipient depending on the header options, to
let them know that mail is missing due to security failure at
delivery time. The courtesy message is optional in case the sender
insists on keeping private all meta-data that might be leaked by
courtesy messages. It differs from security bounce messages in that
the security header is not propagated, and the information passed is
more restricted. The courtesy message should just provide enough to
identify the message and cause but no more i.e. identifying
information such as from: and subject: but not the body or any
additional user identifying header information.
2.6. Mail User Agent Support
Assuming that the Secure Conversation Mail option applies to the mail
message, Mail User Agents such as IMAP or POP3 Clients must honor the
MSMD security protocol, and clients must be able to prove to the
servers they are capable of honoring the protocol. Such MUA servers
must be able to display the MSMD extension, and the MUA clients must
be able present to the server its ability to honor the MSMD protocol.
Chuang, et al. Expires April 18, 2014 [Page 7]
Internet-Draft MSMD October 2013
If MUA clients does not display support for MSMD, then MSMD MUA
servers must prevent access to MSMD marked and protected mail.
2.6.1. IMAP Extension
In the case of IMAP [RFC3501], it provides a CAPABILITY command to
describe the server extensions. We propose a new MSMD capability to
IMAP where "MSMD" appears in the CAPABILITY response, and a new
"MSMD" command that announces to the server that the client supports
the MSMD protocol.
2.6.2. POP3 Extension
Like IMAP, POP3 [RFC1939], it provides a CAPA [RFC2449] command to
describe the server extensions. We propose a new MSMD capability
where "MSMD" appears in the CAPA response, and a new "MSMD" command
so that the client can indicate to the server it supports the MSMD
protocol.
2.7. Compatibility
Specification of the MSMD security header is on a per message basis.
This allows the sender to fallback to clear-text delivery for
backwards compatibility for recipients that don't support the
protocol and don't need the security it mandates. In the expected
case, when the sender starts composing the mail, they can check the
GUI to see if the recipient can support MSMD, and if not then elect
to send mail insecurely or not at all. That said, we expect that
over time as the ecosystem will upgrade its security capability
meaning that MSMD support becomes the norm. Once that happens, it is
easy to imagine that a mail provider would make MSMD mandatory.
The Secure Conversation and Access option also provides a significant
increase in privacy by mandating restricted access after delivery.
This poses a policy issue, as the recipient has mandatory restriction
placed on mail in their inbox that they may not want. Thus we
imagine that this option be used only in conversations where privacy
is required such as by business need, and where all parties would not
object to the restrictions. With other conversations the sender
could use the base MSMD protocol or even clear text delivery. Also
these restrictions are caused by infrastructure limitations that
should improve over time. Once MSMD and SCA support becomes
universal then this restriction become moot.
3. TLS
TLS can be configured to significantly degrade eavesdropping and
MitM. They are organized into tiers corresponding to ability of the
Chuang, et al. Expires April 18, 2014 [Page 8]
Internet-Draft MSMD October 2013
ecosystem to support the features, and are meant to evolve and be
upgraded to draw upon improved techniques for stopping these threats.
The following list are the current TLS parameters that MSMD controls.
TLS Version Describes the TLS version. Currently this is restricted
TLS only and version "1.0" (SSL version 3,1) or greater must be
supported.
CipherSuite Describes the TLS cipher as a selector based on the
values from IANA registry for TLS [RFC5246]. Anonymous Diffie-
Hellman key exchange and RC4 cipher shall not be allowed.
Public Key Size Describes the SMTP client/server minimum TLS
certificate CA certificate public key size. MSMD requires that
key sizes of 1024, 2048, 4096 be supported for RSA, DSA and
Diffie-Hellman based algorithms, and 250 for Elliptic-Curve
Cryptography if supported. It is recommended that larger sizes be
supported as well.
Public Key Type Describes the SMTP server TLS [RFC5246] public key
type. MSMD requires that RSA be supported, and others are
optional.
Symmetric Key Size Describes the SMTP server TLS [RFC5246] symmetric
cipher key size. Both 128 and 256 bits must be supported.
Check Server Certificate This specifies the mechanism by which the
SMTP TLS server certificate are verified. Ability to use PKI
verification of X.509 certificate [RFC5280] using "CA"
(Certificate Authority) must be supported, though actual
verification is recommended. We recommend that certificate naming
standardize [RFC6125] to setting the DNS-ID from the MX record
host name. We also recommend using improved PKI such as
Certificate Transparency [RFC6962].
To reiterate, the baseline TLS constraints for all MSMD
implementation with or without specifying the "tls" requirement
option is the following:
o TLS version >= "1.0"
o MSMD Public key exchange must support RSA.
o Public key exchange shall not use anonymous Diffie-Hellman.
o Cipher shall not use RC4.
o RSA/DSA/DH Public Key Size >= 1024 or ECC Public Key Size >= 250
Chuang, et al. Expires April 18, 2014 [Page 9]
Internet-Draft MSMD October 2013
o Symmetric Key Size >= 128
o Support for CA PKI verification of X.509 certificate.
If the "tls" requirement option is specified, then it must specify
one of two tiers. The tiers corresponding to what can be deployed
today (circa 2013) with reasonable support from ecosystem.
o Tier 1- Baseline strong TLS. Assumes TLS baseline.
* TLS version >= "1.2"
* Public key exchange must use ephemeral Diffie-Hellman for
perfect forward secrecy.
* RSA/DSA/DH Public Key Size >= 2048 or ECC Public Key Size >=
250
o Tier 2- Resist MitM- Assumes capabilities of tier 1.
* Check Server Certificate- should check for: path, expiry, and
trusted CA root. Self-signed certificates shall not not
verify.
* DNSSEC- DNS name look up must look up and verify security
extensions. In other words the "ds" DNSSEC requirement option
is implicitly set, though it is recommended the "ds"
requirement should still be explicitly appended for
readability.
* Require that certificate naming standardize [RFC6125] to
setting the DNS-ID from the MX record host name.
We anticipate more tiers being defined particularly to improve PKI.
Certificate naming of identifiers for SMTP servers has been recently
rigorously defined in [RFC6125]. MSMD recommends (and at Tier 2
requires) the use of this naming scheme for the certificate
identifiers. The certificate DNS-ID identifier contents should be
the SMTP MX host name, and if there are more than one host name than
multiple DNS-ID names may be specified. The certificate common
identifier CN-ID may also be set but with restrictions as noted in
[RFC6125]. There are also restrictions for identifier wild-cards
'*'. An example of the naming scheme is in Figure 2.
MX Record for gmail.com:
gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com.
Chuang, et al. Expires April 18, 2014 [Page 10]
Internet-Draft MSMD October 2013
SMTP X.509 Certificate recommended identifier bindings:
DNS-ID: gmail-smtp-in.l.google.com
DNS-ID: alt1.gmail-smtp-in.l.google.com.
Figure 2: Certificate Naming for SMTP
4. Optional Requirements and Capabilities
To allow for different security requirements and to allow for future
extension, this protocol supports options. The MSMD message header
may take additional arguments that act as requirements during the
MSMD requirements check. The requirements specify expressions that
have values bound to it during the TLS setup and the expression must
evaluate to true. Requirements may be interpreted by other mail
components outside of mail delivery e.g. SCA. The MSMD SMTP EHLO
extension provides the means to display additional capabilities that
the server can provide, and can bind values used for the requirements
check. To summarize, options serve the following purposes:
o Constraints on TLS
o Constraints on recipient- Ensure the recipient mail provider can
maintain security when the message is forwarded or replied-to from
that provider.
o Settings describing the treatment of the message outside of the
mail delivery
4.1. Mail Header Requirements
To simplify the treatment of MSMD requirements, they are all treated
as expressions with the following rules for the evaluation.
Requirement names are variables that may be bound to values from SMTP
extension capabilities or bound to a default value as specified.
Three value types are currently allowed: boolean, integer or string.
They initially are bound to respectively False, 0, or "". All may
also be set to "undef" meaning not assigned which is treated as
False. Expressions support basic comparisons i.e. "==", "!=", "<",
">", "<=", and ">=". They also support composition with "AND", and
"OR" and precedence group "()", as well as negation "NOT". Operator
order of precedence follows the Python language. Requirement names
and operators are case insensitive. One syntactic sugar is allowed:
1. If multiple requirements are presented in a sequence separated
only by white-space, they are treated as composed with "AND".
The following list describes requirements that may be placed with
"mandatory-secure-mail-delivery:" header. Each requirement has a
Chuang, et al. Expires April 18, 2014 [Page 11]
Internet-Draft MSMD October 2013
short name and a longer description name. The short name should be
used in the mail header to save transmission resources.
sca Secure Conversation and Access- as described in Section 2.4.
(type: boolean)
ds DNSSEC- Use DNSSEC for name service look-up. Look-up must verify
the signatures of DNS records. (type: boolean)
m Message- After MSMD security check failure, forward to the
destination a courtesy notice as specified in Section 2.5. (type:
boolean)
v Version- The version value for MSMD. This starts at 0. (type:
int)
tls TLS Tier- As describes in Section 3 one can specify bundles or
tiers of TLS settings. The allowed tiers are 1, and 2. (type:
int)
4.2. SMTP MSMD Capabilities
As part of the EHLO response, additional optional capabilities are
advertised. The capabilities names are variables bound effectively
as key-value pairs. These results become available in the MSMD
requirements check evaluation. Unadorned names are bound to "true",
however if the name is followed by "=" and a value, then the name is
bound to that value. Capabilities are also case insensitive.
sca Secure Conversation and Access- SMTP Server supports SCA.
ds DNSSEC- SMTP Server uses DNSSEC for name service look-up.
m Message- MSMD security check failure sends a courtesy notice.
v Version- The version number for MSMD.
tls TLS Tier- The version number for TLS tiers
4.3. Example with Requirements and Capabilities
The following illustrates how the options would be used. A company
want mail delivery to their customers that mitigates eavesdropping
and MitM attacks. To do so, this company would like to specify the
use of perfect forward secrecy, DNSSEC, and X.509 CA PKI certificates
verification during mail delivery. Currently the latter two
requirements are not yet deployed for many mail providers, but will
likely be available in the near future. So today this company just
Chuang, et al. Expires April 18, 2014 [Page 12]
Internet-Draft MSMD October 2013
uses MSMD with baseline TLS encryption settings for mail delivery as
described in the earlier example in Figure 1. Later when supported,
the company specifies those three properties for new mail messages
using the MSMD requirement option "tls>=2". This is illustrated in
the following example in Figure 3
The mail message requests perfect forward secrecy, DNSSEC, and
X.509 certificate verification by setting the header to:
mandatory-secure-mail-delivery: tls>=2 ds
S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.server.org SMTP service ready
C: EHLO mail.client.com
S: 250-mail.server.org welcomes you
S: 250-STARTTLS
S: 250-MSMD sca m tls=2 ds
S: 250 DSN
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session w/ECDHE-RSA-AES128-SHA>
C: EHLO mail.client.com
S: 250-mail.server.org welcomes you
S: 250-MSMD sca m tls=2 ds
S: 250 DSN
C: <Perform MSMD Requirements Check: On failure close the connection>
C: DATA
C: <Send mail with DKIM signature>
During the MSMD Requirements check the requirements expands as follows:
tls>=2 AND ds
2>=2 AND true
This evaluates true and passes, as does the baseline MSMD
requirements check. The passing MSMD requirements check indicates
the recipient provider can maintain at least the same security as
requested for this message.
Figure 3: MSMD Options Example
5. Recommendations
Some recommendations that assist the effectiveness of this protocol:
o During composition of the mail message that the user be able to
control setting of MSMD header and SCA option though not
necessarily the other options.
Chuang, et al. Expires April 18, 2014 [Page 13]
Internet-Draft MSMD October 2013
o GUI should assist the user in predicting whether delivery will
succeed when the MSMD feature is selected using provider modeling
and other means.
6. Security Considerations
The ability of the protocol to maintain security of mail content
depends on the effectiveness of peer mail systems implementation of
this protocol. Since enforcement is voluntary and easily subverted
by bad implementations, we propose a blacklist list of mail providers
that advertise support but are known to have flawed implementations.
This list would be maintained and adjudicated by a yet to be decided
third party. Implementations should obtain the blacklist, and
prevent delivery of MSMD messages to these mail providers.
7. Acknowledgements
The authors wish to acknowledge the very useful comments and
suggestions from: Brandon Long, Adam Langley, Danesh Irani, Ian
Fette, and Robert Chien.
8. References
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension
Mechanism", RFC 2449, November 1998.
[RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, October
2000.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC
3461, January 2003.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
Chuang, et al. Expires April 18, 2014 [Page 14]
Internet-Draft MSMD October 2013
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[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.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
September 2011.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, June 2013.
Authors' Addresses
Weihaw Chuang
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: weihaw@google.com
Chuang, et al. Expires April 18, 2014 [Page 15]
Internet-Draft MSMD October 2013
Nicolas Lidzborkski
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: nlidz@google.com
Elie Bursztein
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: elieb@google.com
Chuang, et al. Expires April 18, 2014 [Page 16]
