draft-ietf-uta-mta-sts-01.txt   draft-ietf-uta-mta-sts-02.txt 
Using TLS in Applications D. Margolis Using TLS in Applications D. Margolis
Internet-Draft M. Risher Internet-Draft M. Risher
Intended status: Standards Track N. Lidzborski Intended status: Standards Track Google, Inc
Expires: January 9, 2017 W. Chuang Expires: June 18, 2017 B. Ramakrishnan
B. Long
Google, Inc
B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
A. Brotman A. Brotman
Comcast, Inc Comcast, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
F. Martin December 15, 2016
LinkedIn
K. Umbach
M. Laber
1&1 Mail & Media Development & Technology GmbH
July 8, 2016
SMTP MTA Strict Transport Security SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts-01 draft-ietf-uta-mta-sts-02
Abstract Abstract
SMTP MTA-STS is a mechanism enabling mail service providers to SMTP Mail Transfer Agent Strict Transport Security (SMTP STS) is a
declare their ability to receive TLS-secured connections, to declare mechanism enabling mail service providers to declare their ability to
particular methods for certificate validation, and to request that receive TLS-secured connections and an expected validity of
sending SMTP servers report upon and/or refuse to deliver messages certificates presented by their MX hosts, and to specify whether
that cannot be delivered securely. sending SMTP servers should refuse to deliver to MX hosts that do not
offer TLS with a trusted server certificate.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2017. This Internet-Draft will expire on June 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 3
2.1. Differences from DANE . . . . . . . . . . . . . . . . . . 4 3. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Advantages of SMTP MTA-STS when compared to DANE . . 4 3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 4
2.1.2. Advantages of DANE when compared to SMTP MTA-STS . . 5 3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 5
3. Policy Semantics . . . . . . . . . . . . . . . . . . . . . . 5 3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 6
3.1. Formal Definition . . . . . . . . . . . . . . . . . . . . 6 3.4. Policy Selection for Smart Hosts . . . . . . . . . . . . 6
3.1.1. TXT Record . . . . . . . . . . . . . . . . . . . . . 6 4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. SMTP MTA-STS Policy . . . . . . . . . . . . . . . . . 6 4.1. MX Matching . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Policy Expirations . . . . . . . . . . . . . . . . . . . 7 4.2. MX Certificate Validation . . . . . . . . . . . . . . . . 7
3.2.1. Policy Updates . . . . . . . . . . . . . . . . . . . 8 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 7
3.3. Policy Discovery & Authentication . . . . . . . . . . . . 8 5.1. MX Preference . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Policy Validation . . . . . . . . . . . . . . . . . . . . 9 5.2. Policy Application Control Flow . . . . . . . . . . . . . 8
3.5. Policy Application . . . . . . . . . . . . . . . . . . . 9 6. Operational Considerations . . . . . . . . . . . . . . . . . 8
4. Failure Reporting . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Appendix 1: Validation Pseudocode . . . . . . . . . . . . . . 12 10. Appendix 1: Domain Owner STS example record . . . . . . . . . 11
9. Appendix 2: Domain Owner STS example record . . . . . . . . . 12 10.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Appendix 2: Message delivery pseudocode . . . . . . . . . . . 11
10. Appendix 3: DEEP Registration Elements . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11. Normative References . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
hosts to establish secure SMTP sessions over TLS. In its current hosts to negotiate the use of a TLS channel for secure mail
form, however, it fails to provide (a) message confidentiality -- transmission.
because opportunistic STARTTLS is subject to downgrade attacks -- and
(b) server authenticity -- because the trust relationship from email
domain to MTA server identity is not cryptographically validated.
While such _opportunistic_ encryption protocols provide a high While such _opportunistic_ encryption protocols provide a high
barrier against passive man-in-the-middle traffic interception, any barrier against passive man-in-the-middle traffic interception, any
attacker who can delete parts of the SMTP session (such as the "250 attacker who can delete parts of the SMTP session (such as the "250
STARTTLS" response) or who can redirect the entire SMTP session STARTTLS" response) or who can redirect the entire SMTP session
(perhaps by overwriting the resolved MX record of the delivery (perhaps by overwriting the resolved MX record of the delivery
domain) can perform such a downgrade or interception attack. domain) can perform downgrade or interception attacks.
This document defines a mechanism for recipient domains to publish This document defines a mechanism for recipient domains to publish
policies specifying: policies specifying:
o whether MTAs sending mail to this domain can expect TLS support o whether MTAs sending mail to this domain can expect TLS support
o how MTAs can validate the TLS server certificate presented during o expected validity of server certificates presented by the domain's
mail delivery MX hosts
o the expected identity of MXs that handle mail for this domain
o what an implementing sender should do with messages when TLS
cannot be successfully negotiated
The mechanism described is separated into four logical components:
1. policy semantics: whether senders can expect a server for the
recipient domain to support TLS encryption and how to validate
the TLS certificate presented
2. policy discovery & authentication: how to discover a domain's
published STS policy and determine the authenticity of that
policy
3. failure report format: a mechanism for informing recipient
domains about aggregate failure statistics
4. failure handling: what sending MTAs should do in the case of o what a conforming client should do with messages when TLS cannot
policy failures be successfully negotiated
1.1. Terminology 1.1. Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119]. document, are to be interpreted as described in [RFC2119].
We also define the following terms for further use in this document: We also define the following terms for further use in this document:
o STS Policy: A definition of the expected TLS availability and o STS Policy: A committment by the Policy Domain to support PKIX
behavior, as well as the desired actions for a given domain when a authenticated TLS for the specified MX hosts.
sending MTA encounters different results.
o Policy Domain: The domain against which an STS Policy is defined. o Policy Domain: The domain for which an STS Policy is defined.
(For example, when sending mail to "alice@example.com", the policy
domain is "example.com".)
o Policy Authentication: Authentication of the STS policy retrieved o Policy Authentication: Authentication of the STS policy retrieved
for a recipient domain by the sender. for a recipient domain by the sender.
2. Related Technologies 2. Related Technologies
The DANE TLSA record [RFC7672] is similar, in that DANE is also The DANE TLSA record [RFC7672] is similar, in that DANE is also
designed to upgrade opportunistic encryption into required designed to upgrade opportunistic, unauthenticated encryption into
encryption. DANE requires DNSSEC [RFC4033] for the secure delivery required, authenticated encryption. DANE requires DNSSEC [RFC4033]
of policies; the mechanism described here presents a variant for for authentication; the mechanism described here instead relies on
systems not yet supporting DNSSEC. certificate authorities (CAs) and does not require DNSSEC. For a
thorough discussion of this trade-off, see the section _Security_
2.1. Differences from DANE _Considerations_.
The primary difference between the mechanism described here and DANE
is that DANE requires the use of DNSSEC to authenticate DANE TLSA
records, whereas SMTP STS relies on the certificate authority (CA)
system to avoid interception. (For a thorough discussion of this
trade-off, see the section _Security_ _Considerations_.)
In addition, SMTP MTA-STS introduces a mechanism for failure
reporting and a report-only mode, enabling offline ("report-only")
deployments and auditing for compliance.
2.1.1. Advantages of SMTP MTA-STS when compared to DANE
SMTP MTA-STS offers the following advantages compared to DANE:
o Infrastructure: In comparison to DANE, this proposal does not
require DNSSEC be deployed on either the sending or receiving
domain. In addition, the reporting feature of SMTP MTA-STS can be
deployed to perform offline analysis of STARTTLS failures,
enabling mail providers to gain insight into the security of their
SMTP connections without the need to modify MTA codebases
directly.
o Offline or report-only usage: DANE does not provide a reporting
mechanism and does not have a concept of "report-only" for
failures; as a result, a service provider cannot receive metrics
on TLS acceptability without asking senders to enforce a given
policy; similarly, senders who cannot enforce DANE constraints at
send-time have no mechanism to provide recipients such metrics
from an offline (and potentially easier-to-deploy) logs-analysis
batch process.
2.1.2. Advantages of DANE when compared to SMTP MTA-STS
o Infrastructure: DANE may be easier for some providers to deploy. In addition, SMTP STS provides an optional report-only mode, enabling
In particular, for providers who already support DNSSEC, SMTP MTA- soft deployments to detect policy failures.
STS would additionally require they host a HTTPS webserver and
obtain a CA-signed X.509 certificate for the recipient domain.
o Security: DANE offers an advantage against policy-lookup DoS 3. Policy Discovery
attacks; that is, while a DNSSEC-signed NXDOMAIN response to a
DANE lookup authoritatively indicates the lack of a DANE record,
such an option to authenticate policy non-existence does not exist
when looking up a policy over plain DNS.
3. Policy Semantics SMTP STS policies are distributed via HTTPS from a "well-known"
[RFC5785] path served within the Policy Domain, and their presence
and current version are indicated by a TXT record at the Policy
Domain. These TXT records additionally contain a policy "id" field,
allowing sending MTAs to check the currency of a cached policy
without performing an HTTPS request.
SMTP MTA-STS policies are distributed via a "well known" HTTPS To discover if a recipient domain implements MTA-STS, a sender need
endpoint in the Policy Domain. A corresponding TXT record in the DNS only resolve a single TXT record. To see if an updated policy is
alerts sending MTAs to the presence of a policy file. available for a domain for which the sender has a previously cached
policy, the sender need only check the TXT record's version "id"
against the cached value.
(Future implementations may move to alternate methods of policy 3.1. MTA-STS TXT Records
discovery or distribution. See the section _Future_ _Work_ for more
discussion.)
*The MTA-STS TXT record MUST specify the following fields:* The MTA-STS TXT record is a TXT record with the name "_mta-sts" at
the Policy Domain. For the domain "example.com", this record would
be "_mta-sts.example.com". MTA-STS TXT records MUST be US-ASCII,
semicolon-separated key/value pairs containing the following fields:
o "v": (plain-text, required). Currently only "STSv1" is supported. o "v": (plain-text, required). Currently only "STSv1" is supported.
o "id": (plain-text, required). A short string used to track policy o "id": (plain-text, required). A short string used to track policy
updates. This string MUST uniquely identify a given instance of a updates. This string MUST uniquely identify a given instance of a
policy, such that senders can determine when the policy has been policy, such that senders can determine when the policy has been
updated by comparing to the "id" of a previously seen policy, and updated by comparing to the "id" of a previously seen policy.
must also match the "policy_id" value of the distributed policy. There is no implied ordering of "id" fields between revisions.
A lenient parser SHOULD accept a policy file implementing a superset An example TXT record is as below:
of this specification, in which case unknown values SHALL be ignored.
*Policies MUST specify the following fields in JSON* [RFC4627] "_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;""
*format:*
o "version": (plain-text, required). Currently only "STSv1" is The formal definition of the "_mta-sts" TXT record, defined using
supported. [RFC5234], is as follows:
o "mode": (plain-text, required). If "enforce", the receiving MTA sts-text-record = sts-version *WSP %x3B *WSP sts-id [%x3B]
requests that messages be delivered only if they conform to the
STS policy. If "report" the receiving MTA requests that failure
reports be delivered, as specified by the "rua" parameter.
o "mx": MX patterns (list of plain-text MX match patterns, sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1"
required). One or more comma-separated patterns matching the %x53 %x76 %x31
expected MX for this domain. For example, "["*.example.com",
"*.example.net"]" indicates that mail for this domain might be
handled by any MX whose hostname is a subdomain of "example.com"
or "example.net". The semantics for these patterns should be the
ones found in the "Checking of Wildcard Certificates" rules in
Section 6.4.3 of [RFC6125].
o "max_age": Max lifetime of the policy (plain-text integer sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT)
seconds). Well-behaved clients SHOULD cache a policy for up to
this value from last policy fetch time.
o "policy_id": A short string used to track policy updates. This If multiple TXT records for "_mta-sts" are returned by the resolver,
string MUST uniquely identify a given instance of a policy, such records which do not begin with "v=STSv1;" are discarded. If the
that senders can determine when the policy has been updated by number of resulting records is not one, senders MUST assume the
comparing to the "policy_id" of a previously seen policy. recipient domain does not implement MTA STS and skip the remaining
steps of policy discovery.
A lenient parser SHOULD accept a policy file which is valid JSON 3.2. MTA-STS Policies
implementing a superset of this specification, in which case unknown
values SHALL be ignored.
3.1. Formal Definition The policy itself is a JSON [RFC4627] object served via the HTTPS GET
method from the fixed [RFC5785] "well-known" path of ".well-known/
mta-sts.json" served by the "mta-sts" host at the Policy Domain.
Thus for "example.com" the path is "https://mta-sts.example.com
/.well-known/mta-sts.json".
3.1.1. TXT Record This JSON object contains the following key/value pairs:
The formal definition of the "_mta_sts" TXT record, defined using o "version": (plain-text, required). Currently only "STSv1" is
[RFC5234], is as follows: supported.
sts-text-record = sts-version *WSP %x3B *WSP sts-id o "mode": (plain-text, required). Either "enforce" or "report",
indicating the expected behavior of a sending MTA in the case of a
policy validation failure.
sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1" o "max_age": Max lifetime of the policy (plain-text non-negative
%x53 %x76 %x31 integer seconds, required). Well-behaved clients SHOULD cache a
policy for up to this value from last policy fetch time. To
mitigate the risks of attacks at policy refresh time, it is
expected that this value typically be in the range of weeks or
greater.
sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT) o "mx": MX patterns (list of plain-text MX match strings, required).
One or more patterns matching the expected MX for this domain.
For example, "["*.example.com", "*.example.net"]" indicates that
mail for this domain might be handled by any MX with a hostname at
"example.com" or "example.net". Valid patterns can be either
hostname literals (e.g. "mx1.example.com") or wildcard matches, so
long as the wildcard occupies the full left-most label in the
pattern. (Thus "*.example.com" is valid but "mx*.example.com" is
not.)
3.1.2. SMTP MTA-STS Policy An example JSON policy is as below:
The formal definition of the SMTP MTA-STS policy, using [RFC5234], is {
as follows: "version": "STSv1",
"mode": "enforce",
"mx": ["*.mail.example.com"],
"max_age": 123456
}
sts-record = WSP %x7B WSP ; { left curly bracket A lenient parser SHOULD accept TXT records and policy files which are
sts-element ; comma-separated syntactically valid (i.e. valid key-value pairs separated by semi-
[ ; list colons for TXT records and valid JSON for policy files) and
WSP %x2c WSP ; of implementing a superset of this specification, in which case unknown
sts-element ; sts-elements fields SHALL be ignored.
]
WSP %x7d WSP ; } right curly bracket
sts-element = sts-version / sts-mode / sts-id / sts-mx / sts-max_age 3.3. HTTPS Policy Fetching
sts-version = %x22 "version" %x22 *WSP %x3a *WSP ; "version": When fetching a new policy or updating a policy, the HTTPS endpoint
%x22 %x53 %x54 %x53 %x76 %x31 ; "STSv1" MUST present a TLS certificate which is valid for the "mta-sts" host
(as described in [RFC6125]), chain to a root CA that is trusted by
the sending MTA, and be non-expired. It is expected that sending
MTAs use a set of trusted CAs similar to those in widely deployed Web
browsers and operating systems.
sts-mode = %x22 "mode" %x22 *WSP %x3a *WSP ; "mode": HTTP 3xx redirects MUST NOT be followed.
%x22 ("report" / "enforce") %x22 ; "report"/"enforce"
sts-id = %x22 "policy_id" %x22 *WSP %x3a *WSP ; "policy_id": Senders may wish to rate-limit the frequency of attempts to fetch the
%x22 1*32(ALPHA / DIGIT) %x22 ; some chars HTTPS endpoint even if a valid TXT record for the recipient domain
exists. In the case that the HTTPS GET fails, we suggest
implementions may limit further attempts to a period of five minutes
or longer per version ID, to avoid overwhelming resource-constrained
recipients with cascading failures.
sts-mx = %x22 "mx" $x22 *WSP %x3a *WSP ; "mx": Senders MAY impose a timeout on the HTTPS GET to avoid long delays
%x5B ; [ imposed by attempted policy updates. A suggested timeout is one
domain-match ; comma-separated list minute; policy hosts SHOULD respond to requests with a complete
[WSP %x2c domain-match WSP] ; of domain-matches policy body within that timeout.
%x5B ; ]
sts-max_age = %x22 "max_age" %x22 *WSP $x3a *WSP ; "max_age": 3.4. Policy Selection for Smart Hosts
1*10DIGIT ; some digits
domain-match = %x22 1*(dtext / "*") *("." ; wildcard or label When sending mail via a "smart host"--an intermediate SMTP relay
1*dtext) %x22 ; with 0+ more labels rather than the message recipient's server--compliant senders MUST
treat the smart host domain as the policy domain for the purposes of
policy discovery and application.
dtext = ALPHA / DIGIT / %2D ; A-Z, a-z, 0-9, "-" 4. Policy Validation
A size limitation in a sts-uri, if provided, is interpreted as a When sending to an MX at a domain for which the sender has a valid
count of units followed by an OPTIONAL unit size ("k" for kilobytes, and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP STS
"m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a MUST validate:
unit, the number is presumed to be a basic byte count. Note that the
units are considered to be powers of two; a kilobyte is 2^10, a
megabyte is 2^20, etc.
3.2. Policy Expirations 1. That the recipient MX matches the "mx" pattern from the recipient
domain's policy.
In order to resist attackers inserting a fraudulent policy, SMTP MTA- 2. That the recipient MX supports STARTTLS and offers a valid PKIX
STS policies are designed to be long-lived, with an expiry typically based TLS certificate.
greater than two weeks. Policy validity is controlled by two
separate expiration times: the lifetime indicated in the policy
("max_age=") and the TTL on the DNS record itself. The policy
expiration will ordinarily be longer than that of the DNS TTL, and
senders SHOULD cache a policy (and apply it to all mail to the
recipient domain) until the policy expiration.
An important consideration for domains publishing a policy is that This section does not dictate the behavior of sending MTAs when
senders will see a policy expiration as relative to the fetch of a policies fail to validate; in particular, validation failures of
policy cached by their recursive resolver. Consequently, a sender policies which specify "report" mode MUST NOT be interpreted as
MAY treat a policy as valid for up to {expiration time} + {DNS TTL}. delivery failures, as described in the section _Policy_
Publishers SHOULD thus continue to expect senders to apply old _Application_.
policies for up to this duration.
3.2.1. Policy Updates 4.1. MX Matching
Updating the policy requires that the owner make changes in two When delivering mail for the Policy Domain to a recipient MX host,
places: the "_mta_sts" RR record in the Policy Domain's DNS zone and the sender validates the MX match against the "mx" pattern from the
at the corresponding HTTPS endpoint. In the case where the HTTPS applied policy. The semantics for these patterns are those found in
endpoint has been updated but the TXT record has not been, senders section 6.4 of [RFC6125].
will not know there is a new policy released and may thus continue to
use old, previously cached versions. Recipients should thus expect a
policy will continue to be used by senders until both the HTTPS and
TXT endpoints are updated and the TXT record's TTL has passed.
3.3. Policy Discovery & Authentication Patterns may contain a wildcard character "*" which matches any
single domain name component or component fragment, though only as
the leftmost component in a pattern. For example, "*.example.com" is
a valid pattern, but "foo.*.example.com" is not. Given the pattern
"*.example.com", "mx1.example.com" is a valid MX host, but
"1234.dhcp.example.com" is not.
Senders discover a recipient domain's STS policy, by making an 4.2. MX Certificate Validation
attempt to fetch TXT records from the recipient domain's DNS zone
with the name "_mta_sts". A valid TXT record presence in
"_mta_sts.example.com" indicates that the recipent domain supports
STS. To allow recipient domains to safely serve new policies, it is
important that senders are able to authenticate a new policy
retrieved for a recipient domain.
Web PKI is the mechanism used for policy authentication. In this The certificate presented by the receiving MX MUST be valid for the
mechanism, the sender fetches a HTTPS resource (policy) from a host MX hostname and chain to a root CA that is trusted by the sending
at "policy.mta-sts" in the Policy Domain. The policy is served from MTA. The certificate MUST have a CN or SAN matching the MX hostname
a "well known" URI: "https://policy.mta-sts.example.com/.well-known/ (as described in [RFC6125]) and be non-expired.
mta-sts/current". To consider the policy as valid, the "policy_id"
field in the policy MUST match the "id" field in the DNS TXT record
under "_mta_sts".
When fetching a new policy or updating a policy, the new policy MUST In the case of an "implicit" MX record (as specified in [RFC2821])
be fully authenticated (HTTPS certificate validation + peer where no MX RR exists for the recipient domain but there is an A RR,
verification) before use. A policy which has not ever been the MX hostname is assumed to be that of the A RR and should be
successfully authenticated MUST NOT be used to reject mail. validated as such.
3.4. Policy Validation 5. Policy Application
When sending to an MX at a domain for which the sender has a valid When sending to an MX at a domain for which the sender has a valid,
and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP MTA- non-expired STS policy, a sending MTA honoring SMTP STS applies the
STS MUST validate that the recipient MX supports STARTTLS, and offers result of a policy validation one of two ways, depending on the value
a valid PKIX based TLS certificate. The certificate presented by the of the policy "mode" field:
receiving MX MUST be valid for the MX name and chain to a root CA
that is trusted by the sending MTA. The certificate MUST have a CN
or SAN matching the MX hostname (as described in [RFC6125]) and be
non-expired.
3.5. Policy Application 1. "report": In this mode, sending MTAs merely send a report (as
described in the TLSRPT specification (TODO: add ref)) indicating
policy application failures.
When sending to an MX at a domain for which the sender has a valid 2. "enforce": In this mode, sending MTAs treat STS policy failures
non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP MTA-STS as a mail delivery error, and MUST NOT deliver the message to
MAY apply the result of a policy validation one of two ways: this host.
o "report": In this mode, sending MTAs merely send a report to the When a message fails to deliver due to an "enforce" policy, a
designated report address indicating policy application failures. compliant MTA MUST check for the presence of an updated policy at the
This can be done "offline", i.e. based on the MTA logs, and is Policy Domain before permanently failing to deliver the message.
thus a suitable low-risk option for MTAs who wish to enhance
transparency of TLS tampering without making complicated changes
to production mail-handling infrastructure.
o "enforce": In this mode, sending MTAs SHOULD treat STS policy This allows implementing domains to update long-lived policies on the
failures, in which the policy action is "reject", as a mail fly.
delivery error, and SHOULD terminate the SMTP connection, not
delivering any more mail to the recipient MTA.
In "enforce" mode, however, sending MTAs MUST first check for a new Finally, in both "enforce" and "report" modes, failures to deliver in
authenticated policy before actually treating a message failure as compliance with the applied policy result in failure reports to the
fatal. policy domain, as described in the TLSRPT specification (TODO: add
ref).
Thus the control flow for a sending MTA that does online policy 5.1. MX Preference
application consists of the following steps:
1. Check for cached non-expired policy. If none exists, fetch the When applying a policy, sending MTAs SHOULD select recipient MXs by
latest, authenticate and cache it. first eliminating any MXs at lower priority than the current host (if
in the MX candidate set), then eliminating any non-matching (as
specified by the STS Policy) MX hosts from the candidate MX set, and
then attempting delivery to matching hosts as indicated by their MX
priority, until delivery succeeds or the MX candidate set is empty.
2. Validate recipient MTA against policy. If valid, deliver mail. 5.2. Policy Application Control Flow
3. If not valid and the policy specifies reporting, generate report. An example control flow for a compliant sender consists of the
following steps:
4. If not valid and policy specifies rejection, perform the 1. Check for a cached policy whose time-since-fetch has not exceeded
following steps: its "max_age". If none exists, attempt to fetch a new policy.
(Optionally, sending MTAs may unconditionally check for a new
policy at this step.)
* Check for a new (non-cached) authenticated policy. 2. Filter candidate MXs against the current policy.
* If one exists and the new policy is different, update the 3. If no candidate MXs are valid and the policy mode is "enforce",
current policy and go to step 2. temporarily fail the message. (Otherwise, generate a failure
report but deliver as though MTA STS were not implemented.)
* If one exists and the new policy is same as the cached policy, 4. For each candidate MX, in order of MX priority, attempt to
treat the delivery as a failure. deliver the message, enforcing STARTTLS and the MX host's PKIX
certificate validation.
* If none exists and cached policy is not expired, treat the 5. Upon message retries, a message MAY be permanently failed
delivery as a failure. following first checking for the presence of a new policy (as
indicated by the "id" field in the "_mta-sts" TXT record).
Understanding the details of step 4 is critical to understanding the 6. Operational Considerations
behavior of the system as a whole.
Remember that each policy has an expiration time (which SHOULD be 6.1. Policy Updates
long, on the order of days or months) and a validation method. With
these two mechanisms and the procedure specified in step 4,
recipients who publish a policy have, in effect, a means of updating
a cached policy at arbitrary intervals, without the risks (of a man-
in-the-middle attack) they would incur if they were to shorten the
policy expiration time.
4. Failure Reporting Updating the policy requires that the owner make changes in two
places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and
at the corresponding HTTPS endpoint. In the case where the HTTPS
endpoint has been updated but the TXT record has not yet been,
senders will not know there is a new policy released and may thus
continue to use old, previously cached versions. Recipients should
thus expect a policy will continue to be used by senders until both
the HTTPS and TXT endpoints are updated and the TXT record's TTL has
passed.
Aggregate statistics on policy failures MAY be reported using the 7. IANA Considerations
"TLSRPT" reporting specification (TODO: Add Ref).
5. IANA Considerations A new .well-known URI will be registered in the Well-Known URIs
registry as described below:
There are no IANA considerations at this time. URI Suffix: mta-sts.json Change Controller: IETF
6. Security Considerations 8. Security Considerations
SMTP Strict Transport Security protects against an active attacker SMTP Strict Transport Security attempts to protect against an active
who wishes to intercept or tamper with mail between hosts who support attacker who wishes to intercept or tamper with mail between hosts
STARTTLS. There are two classes of attacks considered: who support STARTTLS. There are two classes of attacks considered:
o Foiling TLS negotiation, for example by deleting the "250 1. Foiling TLS negotiation, for example by deleting the "250
STARTTLS" response from a server or altering TLS session STARTTLS" response from a server or altering TLS session
negotiation. This would result in the SMTP session occurring over negotiation. This would result in the SMTP session occurring
plaintext, despite both parties supporting TLS. over plaintext, despite both parties supporting TLS.
o Impersonating the destination mail server, whereby the sender 2. Impersonating the destination mail server, whereby the sender
might deliver the message to an impostor, who could then monitor might deliver the message to an impostor, who could then monitor
and/or modify messages despite opportunistic TLS. This and/or modify messages despite opportunistic TLS. This
impersonation could be accomplished by spoofing the DNS MX record impersonation could be accomplished by spoofing the DNS MX record
for the recipient domain, or by redirecting client connections for the recipient domain, or by redirecting client connections
intended for the legitimate recipient server (for example, by intended for the legitimate recipient server (for example, by
altering BGP routing tables). altering BGP routing tables).
SMTP Strict Transport Security relies on certificate validation via SMTP Strict Transport Security relies on certificate validation via
PKIX based TLS identity checking [RFC6125]. Attackers who are able PKIX based TLS identity checking [RFC6125]. Attackers who are able
to obtain a valid certificate for the targeted recipient mail service to obtain a valid certificate for the targeted recipient mail service
(e.g. by compromising a certificate authority) are thus out of scope (e.g. by compromising a certificate authority) are thus able to
of this threat model. circumvent STS authentication.
Since we use DNS TXT record for policy discovery, an attacker who is Since we use DNS TXT records for policy discovery, an attacker who is
able to block DNS responses can suppress the discovery of an STS able to block DNS responses can suppress the discovery of an STS
Policy, making the Policy Domain appear not to have an STS Policy. Policy, making the Policy Domain appear not to have an STS Policy.
The caching model described in _Policy_ _Expirations_ is designed to The sender policy cache is designed to resist this attack.
resist this attack, and there is discussion in the _Future_ _Work_
section around future distribution mechanisms that are robust against
this attack.
7. Future Work We additionally consider the Denial of Service risk posed by an
attacker who can modify the DNS records for a victim domain. Absent
SMTP STS, such an attacker can cause a sending MTA to cache invalid
MX records for a long TTL. With SMTP STS, the attacker can
additionally advertise a new, long-"max_age" SMTP STS policy with
"mx" constraints that validate the malicious MX record, causing
senders to cache the policy and refuse to deliver messages once the
victim has resecured the MX records.
The authors would like to suggest multiple considerations for future This attack is mitigated in part by the ability of a victim domain to
discussion. (at any time) publish a new policy updating the cached, malicious
policy, though this does require the victim domain to both obtain a
valid CA-signed certificate and to understand and properly configure
SMTP STS.
o Certificate pinning: One potential improvement in the robustness Similarly, we consider the possibilty of domains that deliberately
of the certificate validation methods discussed would be the allow untrusted users to serve untrusted content on user-specified
deployment of public-key pinning as defined for HTTP in [RFC7469]. subdomains. In some cases (e.g. the service Tumblr.com) this takes
A policy extension supporting these semantics would enable Policy the form of providing HTTPS hosting of user-registered subdomains; in
Domains to specify certificates that MUST appear in the MX other cases (e.g. dynamic DNS providers) this takes the form of
certificate chain, thus providing resistence against compromised allowing untrusted users to register custom DNS records at the
CA or DNSSEC zone keys. provider's domain.
o Policy distribution: As with Certificate Transparency ([RFC6962]), In these cases, there is a risk that untrusted users would be able to
it may be possible to provide a verifiable log of policy serve custom content at the "mta-sts" host, including serving an
_observations_ (meaning which policies have been observed for a illegitimate SMTP STS policy. We believe this attack is rendered
given Policy Domain). This would provide insight into policy more difficult by the need for the attacker to both inject malicious
spoofing or faked policy non-existence. This may be particularly (but temporarily working) MX records and also serve the "_mta-sts"
useful for Policy Domains not using DNSSEC, since it would provide TXT record on the same domain--something not, to our knowledge,
sending MTAs an authoritative source for whether a policy is widely provided to untrusted users. This attack is additionally
expected for a given domain. mitigated by the aforementioned ability for a victim domain to update
an invalid policy at any future date.
o Receive-from restrictions: Policy publishers may wish to also Even if an attacker cannot modify a served policy, the potential
indicate to domains _receiving_ mail from the Policy Domain that exists for configurations that allow attackers on the same domain to
all such mail is expected to be sent via TLS. This may allow receive mail for that domain. For example, an easy configuration
policy publishers to receive reports indicating sending MTA option when authoring an STS Policy for "example.com" is to set the
misconfigurations. However, the security properties of a "mx" equal to "*.example.com"; recipient domains must consider in
"receiver-enforced" system differ from those of the current this case the risk that any user possessing a valid hostname and CA-
design; in particular, an active man-in-the-middle attacker may be signed certificate (for example, "dhcp-123.example.com") will, from
able to exploit misconfigured sending MTAs in a way that would not the perspective of STS Policy validation, be a valid MX host for that
be possible today with a sender-enforced model. domain.
o Cipher and TLS version restrictions: Policy publishers may also 9. Contributors
wish to restrict TLS negotiation to specific ciphers or TLS
versions.
8. Appendix 1: Validation Pseudocode Nicolas Lidzborski Google, Inc nlidz (at) google (dot com)
policy = policy_from_cache() Wei Chuang Google, Inc weihaw (at) google (dot com)
if not policy or is_expired(policy):
policy = policy_from_https_endpoint() // fetch and authenticate!
update_cache = true
if policy:
if invalid_mx_or_tls(policy): // check MX and TLS cert
if rua:
generate_report()
if p_reject():
policy = policy_from_https_endpoint() // fetch and authenticate #2!
update_cache = true
if invalid_mx_or_tls(policy):
reject_message()
update_cache = false
if update_cache:
cache(policy)
9. Appendix 2: Domain Owner STS example record Brandon Long Google, Inc blong (at) google (dot com)
9.1. Example 1 Franck Martin LinkedIn, Inc fmartin (at) linkedin (dot com)
Klaus Umbach 1&1 Mail & Media Development & Technology GmbH
klaus.umbach (at) 1und1 (dot de)
The owner of example.com wishes to begin using STS with a policy that Markus Laber 1&1 Mail & Media Development & Technology GmbH
will solicit aggregate feedback from receivers without affecting how markus.laber (at) 1und1 (dot de)
the messages are processed, in order to:
o Verify the identity of MXs that handle mail for this domain 10. Appendix 1: Domain Owner STS example record
o Confirm that its legitimate messages are sent over TLS 10.1. Example 1
o Verify the validity of the certificates The owner of "example.com" wishes to begin using STS with a policy
that will solicit reports from receivers without affecting how the
messages are processed, in order to verify the identity of MXs that
handle mail for "example.com", confirm that TLS is correctly used,
and ensure that certificates presented by the recipient MX validate.
o Determine how many messages would be affected by a strict policy STS policy indicator TXT RR:
DNS STS policy indicator TXT record: _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
_mta_sts IN TXT ( "v=STSv1; id=randomstr;" ) STS Policy JSON served as the response body at [1]
STS policy served from HTTPS endpoint of the policy (recipient) {
domain, and is authenticated using Web PKI mechanism. The policy is "version": "STSv1",
fetched using HTTP GET method. "mode": "report",
"mx": ["mx1.example.com", "mx2.example.com"],
"max_age": 123456
}
{ 11. Appendix 2: Message delivery pseudocode
"version": "STSv1",
"mode": "report",
"policy_id": "randomstr",
"mx": ["*.mail.example.com"],
"max_age": 123456
}
The policy is authenticated using Web PKI mechanism. Below is pseudocode demonstrating the logic of a complaint sending
MTA. This implements the "two-pass" approach, first attempting
delivery with a newly fetched policy (if present) before falling back
to a cached policy (if present).
10. Appendix 3: DEEP Registration Elements func isEnforce(policy) {
// Return true if the policy mode is "enforce".
}
Name: mx-mismatch func isNonExpired(policy) {
Description: This indicates that the MX resolved for the recipient domain // Return true if the policy is not expired.
did not match the MX constraint specified in the policy. }
Intended Usage: COMMON
Reference: RFC XXXX (this document once published)
Submitter: Authors of this document
Change Controller: IESG
Name: certificate-name-mismatch func tryStartTls(mx) {
Description: This indicates that the subject CNAME/SAN in the certificate // Attempt to open an SMTP connection with STARTTLS with the MX.
presented by the receiving MX did not match the MX hostname
Intended Usage: COMMON
Reference: RFC XXXX (this document once published)
Submitter: Authors of this document
Change Controller: IESG
Name: invalid-certificate }
Description: This indicates that the certificate presented by the receiving MX
did not validate according to the policy validation constraint.
(Either it was not signed by a trusted CA or did not match the
DANE TLSA record for the recipient MX.)
Intended Usage: COMMON
Reference: RFC XXXX (this document once published)
Submitter: Authors of this document
Change Controller: IESG
Name: certificate-name-constraints-not-permitted func certMatches(connection, mx) {
Description: The certificate request contains a name that is not listed as // Return if the server certificate from "connection" matches the "mx" host.
permitted in the name constraints extension of the cert issuer. }
Intended Usage: COMMON
Reference: RFC XXXX (this document once published)
Submitter: Authors of this document
Change Controller: IESG
Name: certificate-name-constraints-excluded func tryDeliverMail(connection, message) {
Description: The certificate request contains a name that is listed as // Attempt to deliver "message" via "connection".
excluded in the name constraints extension of the issuer. }
Intended Usage: COMMON
Reference: RFC XXXX (this document once published)
Submitter: Authors of this document
Change Controller: IESG
Name: expired-certificate func getMxsForPolicy(domain, policy) {
Description: This indicates that the certificate has expired. // Sort the MXs by priority, filtering out those which are invalid according
Intended Usage: COMMON // to "policy".
Reference: RFC XXXX (this document once published) }
Submitter: Authors of this document
Change Controller: IESG
Name: starttls-not-supported func tryGetNewPolicy(domain) {
Description: This indicates that the recipient MX did not support STARTTLS. // Check for an MTA STS TXT record for "domain" in DNS, and return the
Intended Usage: COMMON // indicated policy (or a local cache of the unvalidated policy).
Reference: RFC XXXX (this document once published) }
Submitter: Authors of this document
Change Controller: IESG
Name: tlsa-invalid func cachePolicy(domain, policy) {
Description: This indicates a validation error for Policy Domain specifying // Store "policy" as the cached policy for "domain".
"tlsa" validation. }
Intended Usage: COMMON
Reference: RFC XXXX (this document once published)
Submitter: Authors of this document
Change Controller: IESG
Name: dnssec-invalid func tryGetCachedPolicy(domain, policy) {
Description: This indicates a failure to validate DNS records for a Policy // Return a cached policy for "domain".
Domain specifying "tlsa" validation or "dnssec" authentication. }
Intended Usage: COMMON
Reference: RFC XXXX (this document once published)
Submitter: Authors of this document
Change Controller: IESG
Name: sender-does-not-support-validation-method func reportError(error) {
Description: This indicates the sending system can never validate using the // Report an error via TLSRPT.
requested validation mechanism. }
Intended Usage: COMMON
Reference: RFC XXXX (this document once published) func tryMxAccordingTo(message, mx, policy) {
Submitter: Authors of this document connection := connect(mx)
Change Controller: IESG if !connection {
11. Normative References return false // Can't connect to the MX so it's not an STS error.
}
status := !(tryStartTls(mx, &connection) && certMatches(connection, mx))
status = true
if !tryStartTls(mx, &connection) {
status = false
reportError(E_NO_VALID_TLS)
} else if certMatches(connection, mx) {
status = false
reportError(E_CERT_MISMATCH)
}
if status || !isEnforce(policy) {
return tryDeliverMail(connection, message)
}
return false
}
func tryWithPolicy(message, domain, policy) {
mxes := getMxesForPolicy(domain, policy)
if mxs is empty {
reportError(E_NO_VALID_MXES)
}
for mx in mxes {
if tryMxAccordingTo(message, mx, policy) {
return true
}
}
return false
}
func handleMessage(message) {
domain := ... // domain part after '@' from recipient
oldPolicy := tryGetCachedPolicy(domain)
newPolicy := tryGetNewPolicy(domain)
if newPolicy {
cachePolicy(domain, newPolicy)
oldPolicy = newPolicy
}
if oldPolicy {
return tryWithPolicy(message, oldPolicy)
}
// There is no policy or there's a new policy that did not work.
// Try to deliver the message normally (i.e. without STS).
}
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
2821, DOI 10.17487/RFC2821, April 2001,
<http://www.rfc-editor.org/info/rfc2821>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
February 2002, <http://www.rfc-editor.org/info/rfc3207>. February 2002, <http://www.rfc-editor.org/info/rfc3207>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements", RFC
RFC 4033, DOI 10.17487/RFC4033, March 2005, 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, JavaScript Object Notation (JSON)", RFC 4627, DOI 10
DOI 10.17487/RFC4627, July 2006, .17487/RFC4627, July 2006,
<http://www.rfc-editor.org/info/rfc4627>. <http://www.rfc-editor.org/info/rfc4627>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
DOI 10.17487/RFC5234, January 2008, RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10
.17487/RFC5785, April 2010,
<http://www.rfc-editor.org/info/rfc5785>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>. 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://www.rfc-editor.org/info/rfc6962>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672, (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10
DOI 10.17487/RFC7672, October 2015, .17487/RFC7672, October 2015,
<http://www.rfc-editor.org/info/rfc7672>. <http://www.rfc-editor.org/info/rfc7672>.
12.2. URIs
[1] https://mta-sts.example.com/.well-known/mta-sts.json:
Authors' Addresses Authors' Addresses
Daniel Margolis Daniel Margolis
Google, Inc Google, Inc
Email: dmargolis (at) google.com Email: dmargolis (at) google.com
Mark Risher Mark Risher
Google, Inc Google, Inc
Email: risher (at) google (dot com) Email: risher (at) google (dot com)
Nicolas Lidzborski
Google, Inc
Email: nlidz (at) google (dot com)
Wei Chuang
Google, Inc
Email: weihaw (at) google (dot com)
Brandon Long
Google, Inc
Email: blong (at) google (dot com)
Binu Ramakrishnan Binu Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
Email: rbinu (at) yahoo-inc (dot com) Email: rbinu (at) yahoo-inc (dot com)
Alexander Brotman Alexander Brotman
Comcast, Inc Comcast, Inc
Email: alexander_brotman (at) cable.comcast (dot com) Email: alexander_brotman (at) cable.comcast (dot com)
Janet Jones Janet Jones
Microsoft, Inc Microsoft, Inc
Email: janet.jones (at) microsoft (dot com) Email: janet.jones (at) microsoft (dot com)
Franck Martin
LinkedIn
Email: fmartin (at) linkedin (dot com)
Klaus Umbach
1&1 Mail & Media Development & Technology GmbH
Email: klaus.umbach (at) 1und1 (dot de)
Markus Laber
1&1 Mail & Media Development & Technology GmbH
Email: markus.laber (at) 1und1 (dot de)
 End of changes. 127 change blocks. 
496 lines changed or deleted 437 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/