draft-ietf-uta-mta-sts-14.txt   draft-ietf-uta-mta-sts-15.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 Google, Inc Intended status: Standards Track Google, Inc
Expires: July 20, 2018 B. Ramakrishnan Expires: October 6, 2018 B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
A. Brotman A. Brotman
Comcast, Inc Comcast, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
January 16, 2018 April 4, 2018
SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts-14 draft-ietf-uta-mta-sts-15
Abstract Abstract
SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a
mechanism enabling mail service providers to declare their ability to mechanism enabling mail service providers to declare their ability to
receive Transport Layer Security (TLS) secure SMTP connections, and receive Transport Layer Security (TLS) secure SMTP connections, and
to specify whether sending SMTP servers should refuse to deliver to to specify whether sending SMTP servers should refuse to deliver to
MX hosts that do not offer TLS with a trusted server certificate. 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 https://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 July 20, 2018. This Internet-Draft will expire on October 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 3 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 3
3. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . 4 3. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . 4
3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 4 3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 4
3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 5 3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 5
3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 8 3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 8
3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 9 3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 9
4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 9 4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 9
4.1. MX Certificate Validation . . . . . . . . . . . . . . . . 10 4.1. MX Certificate Validation . . . . . . . . . . . . . . . . 10
5. Policy Application . . . . . . . . . . . . . . . . . . . . . 10 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 11
5.1. Policy Application Control Flow . . . . . . . . . . . . . 11 5.1. Policy Application Control Flow . . . . . . . . . . . . . 11
6. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 11 6. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 12
7. Interoperability Considerations . . . . . . . . . . . . . . . 12 7. Interoperability Considerations . . . . . . . . . . . . . . . 12
7.1. SNI Support . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. SNI Support . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Minimum TLS Version Support . . . . . . . . . . . . . . . 12 7.2. Minimum TLS Version Support . . . . . . . . . . . . . . . 13
8. Operational Considerations . . . . . . . . . . . . . . . . . 13 8. Operational Considerations . . . . . . . . . . . . . . . . . 13
8.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 13 8.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 13
8.2. Policy Delegation . . . . . . . . . . . . . . . . . . . . 13 8.2. Policy Delegation . . . . . . . . . . . . . . . . . . . . 13
8.3. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 14 8.3. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 14 9.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 15
9.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 15 9.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 15
9.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 15 9.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 16 10.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 16
10.2. Preventing Policy Discovery . . . . . . . . . . . . . . 16 10.2. Preventing Policy Discovery . . . . . . . . . . . . . . 16
10.3. Denial of Service . . . . . . . . . . . . . . . . . . . 17 10.3. Denial of Service . . . . . . . . . . . . . . . . . . . 17
10.4. Weak Policy Constraints . . . . . . . . . . . . . . . . 18 10.4. Weak Policy Constraints . . . . . . . . . . . . . . . . 18
10.5. Compromise of the Web PKI System . . . . . . . . . . . . 18 10.5. Compromise of the Web PKI System . . . . . . . . . . . . 18
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. MTA-STS example record & policy . . . . . . . . . . 21 Appendix A. MTA-STS example record & policy . . . . . . . . . . 21
Appendix B. Message delivery pseudocode . . . . . . . . . . . . 21 Appendix B. Message delivery pseudocode . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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 negotiate the use of a TLS channel for encrypted mail hosts to negotiate the use of a TLS channel for encrypted mail
transmission. transmission.
While this opportunistic encryption protocol by itself provides a While this opportunistic encryption protocol by itself provides a
high barrier against passive man-in-the-middle traffic interception, high barrier against passive man-in-the-middle traffic interception,
skipping to change at page 3, line 31 skipping to change at page 3, line 31
o whether MTAs sending mail to this domain can expect PKIX- o whether MTAs sending mail to this domain can expect PKIX-
authenticated TLS support authenticated TLS support
o what a conforming client should do with messages when TLS cannot o what a conforming client should do with messages when TLS cannot
be successfully negotiated be successfully negotiated
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119]. These
words may also appear in this document in lowercase, absent their
normative meanings.
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 MTA-STS Policy: A commitment by the Policy Domain to support PKIX o MTA-STS Policy: A commitment by the Policy Domain to support PKIX
authenticated TLS for the specified MX hosts. [RFC5280] authenticated TLS for the specified MX hosts.
o Policy Domain: The domain for which an MTA-STS Policy is defined. o Policy Domain: The domain for which an MTA-STS Policy is defined.
This is the next-hop domain; when sending mail to This is the next-hop domain; when sending mail to
"alice@example.com" this would ordinarily be "example.com", but "alice@example.com" this would ordinarily be "example.com", but
this may be overridden by explicit routing rules (as described in this may be overridden by explicit routing rules (as described in
Section 3.4, "Policy Selection for Smart Hosts and Subdomains"). Section 3.4, "Policy Selection for Smart Hosts and Subdomains").
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
skipping to change at page 5, line 27 skipping to change at page 5, line 29
sts-version = %s"v=STSv1" sts-version = %s"v=STSv1"
sts-id = %s"id=" 1*32(ALPHA / DIGIT) ; id=... sts-id = %s"id=" 1*32(ALPHA / DIGIT) ; id=...
sts-extension = sts-ext-name "=" sts-ext-value ; name=value sts-extension = sts-ext-name "=" sts-ext-value ; name=value
sts-ext-name = (ALPHA / DIGIT) sts-ext-name = (ALPHA / DIGIT)
*31(ALPHA / DIGIT / "_" / "-" / ".") *31(ALPHA / DIGIT / "_" / "-" / ".")
sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; chars excluding "=", ";", SP, and control chars ; chars excluding "=", ";", and control chars
If multiple TXT records for "_mta-sts" are returned by the resolver, The TXT record MUST begin with sts-version field, and the order of
records which do not begin with "v=STSv1;" are discarded. If the other fields is not significant. If multiple TXT records for "_mta-
number of resulting records is not one, senders MUST assume the sts" are returned by the resolver, records which do not begin with
recipient domain does not implement MTA-STS and skip the remaining "v=STSv1;" are discarded. If the number of resulting records is not
steps of policy discovery. If the resulting TXT record contains one, senders MUST assume the recipient domain does not implement MTA-
multiple strings, then the record MUST be treated as if those strings STS and skip the remaining steps of policy discovery. If the
are concatenated together without adding spaces. resulting TXT record contains multiple strings, then the record MUST
be treated as if those strings are concatenated together without
adding spaces.
3.2. MTA-STS Policies 3.2. MTA-STS Policies
The policy itself is a set of key/value pairs (similar to [RFC5322] The policy itself is a set of key/value pairs (similar to [RFC5322]
header fields) served via the HTTPS GET method from the fixed header fields) served via the HTTPS GET method from the fixed
[RFC5785] "well-known" path of ".well-known/mta-sts.txt" served by [RFC5785] "well-known" path of ".well-known/mta-sts.txt" served by
the "mta-sts" host at the Policy Domain. Thus for "example.com" the the "mta-sts" host at the Policy Domain. Thus for "example.com" the
path is "https://mta-sts.example.com/.well-known/mta-sts.txt". path is "https://mta-sts.example.com/.well-known/mta-sts.txt".
The [RFC7231] "Content-Type" media type for this resource MUST be When fetching a policy, senders SHOULD validate that the media type
"text/plain". When fetching a policy, senders SHOULD validate that is "text/plain" to guard against cases where webservers allow
the media type is "text/plain" to guard against cases where untrusted users to host non-text content (typically, HTML or images)
webservers allow untrusted users to host non-text content (typically, at a user-defined path. All parameters other charset=utf-8 or
HTML or images) at a user-defined path. Additional "Content-Type" charset=us-ascii are ignored. Additional "Content-Type" parameters
parameters are ignored. are also ignored.
This resource contains the following newline-separated key/value This resource contains the following CRLF-separated key/value pairs:
pairs:
o "version": (plain-text). Currently only "STSv1" is supported. o "version": (plain-text). Currently only "STSv1" is supported.
o "mode": (plain-text). One of "enforce", "testing", or "none", o "mode": (plain-text). One of "enforce", "testing", or "none",
indicating the expected behavior of a sending MTA in the case of a indicating the expected behavior of a sending MTA in the case of a
policy validation failure. policy validation failure. See Section 5, "Policy Application."
for more details about the three modes.
o "max_age": Max lifetime of the policy (plain-text non-negative o "max_age": Max lifetime of the policy (plain-text non-negative
integer seconds, maximum value of 31557600). Well-behaved clients integer seconds, maximum value of 31557600). Well-behaved clients
SHOULD cache a policy for up to this value from last policy fetch 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 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 is expected that this value typically be in the range of weeks or
greater. greater.
o "mx": MX identity patterns (list of plain-text strings). One or o "mx": MX identity patterns (list of plain-text strings). One or
more patterns matching a Common Name ([RFC6125]) or Subject more patterns matching a Common Name or Subject Alternative Name
Alternative Name ([RFC5280]) DNS-ID present in the X.509 ([RFC5280]) DNS-ID ([RFC6125]) present in the X.509 certificate
certificate presented by any MX receiving mail for this domain. presented by any MX receiving mail for this domain. For example:
For example: "mx: mail.example.com mx: .example.net" indicates
that mail for this domain might be handled by any MX with a mx: mail.example.com <CRLF>
certificate valid for a host at "mail.example.com" or mx: .example.net
"example.net". Valid patterns can be either fully specified names
("example.com") or suffixes (".example.net") matching the right- indicates that mail for this domain might be handled by any MX with a
hand parts of a server's identity; the latter case are certificate valid for a host at "mail.example.com" or "example.net".
distinguished by a leading period. If there are more than one MX Valid patterns can be either fully specified names ("example.com") or
specified by the policy, they MUST be on separate lines within the suffixes (".example.net") matching the right-hand parts of a server's
policy file. In the case of Internationalized Domain Names identity; the latter case are distinguished by a leading period. If
([RFC5891]), the MX MUST specify the Punycode-encoded A-label there are more than one MX specified by the policy, they MUST be on
[RFC3492] and not the Unicode-encoded U-label. The full semantics separate lines within the policy file. In the case of
of certificate validation are described in Section 4.1, "MX Internationalized Domain Names ([RFC5891]), the MX MUST specify the
Certificate Validation." Punycode-encoded A-label [RFC3492] and not the Unicode-encoded
U-label. The full semantics of certificate validation are described
in Section 4.1, "MX Certificate Validation."
An example policy is as below: An example policy is as below:
version: STSv1 version: STSv1
mode: enforce mode: enforce
mx: mail.example.com mx: mail.example.com
mx: .example.net mx: .example.net
mx: backupmx.example.com mx: backupmx.example.com
max_age: 123456 max_age: 123456
The formal definition of the policy resource, defined using The formal definition of the policy resource, defined using
[RFC7405], is as follows: [RFC7405], is as follows:
sts-policy-record = *WSP sts-policy-field *WSP sts-policy-record = sts-policy-field *WSP
*(CRLF *WSP sts-policy-field *WSP) *(CRLF sts-policy-field *WSP)
[CRLF] [CRLF]
sts-policy-field = sts-policy-version / ; required once sts-policy-field = sts-policy-version / ; required once
sts-policy-mode / ; required once sts-policy-mode / ; required once
sts-policy-max-age / ; required once sts-policy-max-age / ; required once
0*(sts-policy-mx *WSP CRLF) / 0*(sts-policy-mx *WSP CRLF) /
; required at least once, except when ; required at least once, except when
; mode is "none" ; mode is "none"
skipping to change at page 8, line 24 skipping to change at page 8, line 29
is duplicated, all entries except for the first SHALL be ignored. If is duplicated, all entries except for the first SHALL be ignored. If
any field is not specified, the policy SHALL be treated as invalid. any field is not specified, the policy SHALL be treated as invalid.
3.3. HTTPS Policy Fetching 3.3. HTTPS Policy Fetching
When fetching a new policy or updating a policy, the HTTPS endpoint When fetching a new policy or updating a policy, the HTTPS endpoint
MUST present a X.509 certificate which is valid for the "mta-sts" MUST present a X.509 certificate which is valid for the "mta-sts"
host (e.g. "mta-sts.example.com") as described below, chain to a host (e.g. "mta-sts.example.com") as described below, chain to a
root CA that is trusted by the sending MTA, and be non-expired. It 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 is expected that sending MTAs use a set of trusted CAs similar to
those in widely deployed Web browsers and operating systems. those in widely deployed Web browsers and operating systems. See
[RFC5280] for more details about certificate verification.
The certificate is valid for the "mta-sts" host with respect to the The certificate is valid for the "mta-sts" host with respect to the
rules described in [RFC6125], with the following application-specific rules described in [RFC6125], with the following application-specific
considerations: considerations:
o Matching is performed only against the DNS-ID identifiers. o Matching is performed only against the DNS-ID identifiers.
o DNS domain names in server certificates MAY contain the wildcard o DNS domain names in server certificates MAY contain the wildcard
character '*' as the complete left-most label within the character '*' as the complete left-most label within the
identifier. identifier.
skipping to change at page 9, line 19 skipping to change at page 9, line 26
If a valid TXT record is found but no policy can be fetched via HTTPS If a valid TXT record is found but no policy can be fetched via HTTPS
(for any reason), and there is no valid (non-expired) previously- (for any reason), and there is no valid (non-expired) previously-
cached policy, senders MUST continue with delivery as though the cached policy, senders MUST continue with delivery as though the
domain has not implemented MTA-STS. domain has not implemented MTA-STS.
Conversely, if no "live" policy can be discovered via DNS or fetched Conversely, if no "live" policy can be discovered via DNS or fetched
via HTTPS, but a valid (non-expired) policy exists in the sender's via HTTPS, but a valid (non-expired) policy exists in the sender's
cache, the sender MUST apply that cached policy. cache, the sender MUST apply that cached policy.
Finally, to mitigate the risk of persistent interference with policy Finally, to mitigate the risk of persistent interference with policy
refresh, as discussed in-depth in Section 10, MTAs SHOULD refresh, as discussed in-depth in Section 10, MTAs SHOULD proactively
proactivecly refresh cached policies before they expire; a suggested refresh cached policies before they expire; a suggested refresh
refresh frequency is once per day. To enable administrators to frequency is once per day. To enable administrators to discover
discover problems with policy refresh, MTAs SHOULD alert problems with policy refresh, MTAs SHOULD alert administrators
administrators (through the use of logs or similar) when such (through the use of logs or similar) when such attempts fail, unless
attempts fail, unless the cached policy mode is "none". the cached policy mode is "none".
3.4. Policy Selection for Smart Hosts and Subdomains 3.4. Policy Selection for Smart Hosts and Subdomains
When sending mail via a "smart host"--an intermediate SMTP relay When sending mail via a "smart host"--an administratively configured
rather than the message recipient's server--compliant senders MUST intermediate SMTP relay, which is different from the message
recipient's server as determined from DNS --compliant senders MUST
treat the smart host domain as the policy domain for the purposes of treat the smart host domain as the policy domain for the purposes of
policy discovery and application. policy discovery and application.
When sending mail to a mailbox at a subdomain, compliant senders MUST When sending mail to a mailbox at a subdomain, compliant senders MUST
NOT attempt to fetch a policy from the parent zone. Thus for mail NOT attempt to fetch a policy from the parent zone. Thus for mail
sent to "user@mail.example.com", the policy can be fetched only from sent to "user@mail.example.com", the policy can be fetched only from
"mail.example.com", not "example.com". "mail.example.com", not "example.com".
4. Policy Validation 4. Policy Validation
skipping to change at page 10, line 14 skipping to change at page 10, line 21
This section does not dictate the behavior of sending MTAs when This section does not dictate the behavior of sending MTAs when
policies fail to validate; see Section 5, "Policy Application" for a policies fail to validate; see Section 5, "Policy Application" for a
description of sending MTA behavior when policy validation fails. description of sending MTA behavior when policy validation fails.
4.1. MX Certificate Validation 4.1. MX Certificate Validation
The certificate presented by the receiving MX MUST chain to a root CA The certificate presented by the receiving MX MUST chain to a root CA
that is trusted by the sending MTA and be non-expired. The that is trusted by the sending MTA and be non-expired. The
certificate MUST have a subject alternative name (SAN, [RFC5280]) certificate MUST have a subject alternative name (SAN, [RFC5280])
with a DNS-ID matching the "mx" pattern. The MX's certificate MAY with a DNS-ID ([RFC6125]) matching the "mx" pattern. The MX's
also be checked for revocation via OCSP [RFC6960], CRLs [RFC6818], or certificate MAY also be checked for revocation via OCSP [RFC6960],
some other mechanism. CRLs [RFC6818], or some other mechanism.
Because the "mx" patterns are not hostnames, however, matching is not Because the "mx" patterns are not hostnames, however, matching is not
identical to other common cases of X.509 certificate authentication identical to other common cases of X.509 certificate authentication
(as described, for example, in [RFC6125]). Consider the example (as described, for example, in [RFC6125]). Consider the example
policy given above, with an "mx" pattern containing ".example.com". policy given above, with an "mx" pattern containing ".example.com".
In this case, if the MX server's X.509 certificate contains a SAN In this case, if the MX server's X.509 certificate contains a SAN
matching "*.example.com", we are required to implement "wildcard-to- matching "*.example.com", we are required to implement "wildcard-to-
wildcard" matching. wildcard" matching.
To simplify this case, we impose the following constraints on To simplify this case, we impose the following constraints on
skipping to change at page 12, line 26 skipping to change at page 12, line 37
7.1. SNI Support 7.1. SNI Support
To ensure that the server sends the right certificate chain, the SMTP To ensure that the server sends the right certificate chain, the SMTP
client MUST have support for the TLS SNI extension [RFC6066]. When client MUST have support for the TLS SNI extension [RFC6066]. When
connecting to a HTTP server to retrieve the MTA-STS policy, the SNI connecting to a HTTP server to retrieve the MTA-STS policy, the SNI
extension MUST contain the name of the policy host (e.g. "mta- extension MUST contain the name of the policy host (e.g. "mta-
sts.example.com"). When connecting to an SMTP server, the SNI sts.example.com"). When connecting to an SMTP server, the SNI
extension MUST contain the MX hostname. extension MUST contain the MX hostname.
HTTP servers used to deliver MTA-STS policies MUST have support for HTTP servers used to deliver MTA-STS policies MAY rely on SNI to
the TLS SNI extension and MAY rely on SNI to determine which determine which certificate chain to present to the client. HTTP
certificate chain to present to the client. In either case, HTTP
servers MUST respond with a certificate chain that matches the policy servers MUST respond with a certificate chain that matches the policy
hostname or abort the TLS handshake if unable to do so. hostname or abort the TLS handshake if unable to do so. Clients that
do not send SNI information may not see the expected certificate
chain.
SMTP servers MUST have support for the TLS SNI extension and MAY rely SMTP servers MAY rely on SNI to determine which certificate chain to
on SNI to determine which certificate chain to present to the client. present to the client. However servers that have one identity and a
If the client sends no SNI extension or sends an SNI extension for an single matching certificate do not require SNI support. Servers MUST
unsupported server name, the server MUST simply send a fallback NOT enforce the use of SNI by clients, as the client may be using
certificate chain of its choice. The reason for not enforcing strict unauthenticated opportunistic TLS and may not expect any particular
matching of the requested SNI hostname is that MTA-STS TLS clients certificate from the server. If the client sends no SNI extension or
may be typically willing to accept multiple server names but can only sends an SNI extension for an unsupported server name, the server
send one name in the SNI extension. The server's fallback MUST simply send a fallback certificate chain of its choice. The
certificate may match a different name that is acceptable to the reason for not enforcing strict matching of the requested SNI
client, e.g., the original next-hop domain. hostname is that MTA-STS TLS clients may be typically willing to
accept multiple server names but can only send one name in the SNI
extension. The server's fallback certificate may match a different
name that is acceptable to the client, e.g., the original next-hop
domain.
7.2. Minimum TLS Version Support 7.2. Minimum TLS Version Support
MTAs supporting MTA-STS MUST have support for TLS version 1.2 MTAs supporting MTA-STS MUST have support for TLS version 1.2
[RFC5246] or higher. The general TLS usage guidance in [RFC7525] [RFC5246] or higher. The general TLS usage guidance in [RFC7525]
SHOULD be followed. SHOULD be followed.
8. Operational Considerations 8. Operational Considerations
8.1. Policy Updates 8.1. Policy Updates
skipping to change at page 19, line 14 skipping to change at page 19, line 28
Markus Laber 1&1 Mail & Media Development & Technology GmbH Markus Laber 1&1 Mail & Media Development & Technology GmbH
markus.laber (at) 1und1 (dot de) markus.laber (at) 1und1 (dot de)
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-uta-smtp-tlsrpt] [I-D.ietf-uta-smtp-tlsrpt]
Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J., Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J.,
and M. Risher, "SMTP TLS Reporting", draft-ietf-uta-smtp- and M. Risher, "SMTP TLS Reporting", draft-ietf-uta-smtp-
tlsrpt-13 (work in progress), December 2017. tlsrpt-17 (work in progress), March 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Requirement Levels", BCP 14, RFC 2119, Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
DOI 10.17487/RFC2119, March 1997, February 2002, <https://www.rfc-editor.org/info/rfc3207>.
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
<https://www.rfc-editor.org/info/rfc3492>. <https://www.rfc-editor.org/info/rfc3492>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5321>. editor.org/info/rfc5321>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5785>. editor.org/info/rfc5785>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6066>. editor.org/info/rfc6066>.
[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, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
12.2. Informative References 12.2. Informative References
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, Requirement Levels", BCP 14, RFC 2119,
February 2002, <https://www.rfc-editor.org/info/rfc3207>. DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[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 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5322>. editor.org/info/rfc5322>.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5891>. editor.org/info/rfc5891>.
[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January
2013, <https://www.rfc-editor.org/info/rfc6818>. 2013, <https://www.rfc-editor.org/info/rfc6818>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>. <https://www.rfc-editor.org/info/rfc7234>.
[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.17487/RFC7672, October 2015, DOI 10.17487/RFC7672, October 2015, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7672>. editor.org/info/rfc7672>.
Appendix A. MTA-STS example record & policy Appendix A. MTA-STS example record & policy
The owner of "example.com" wishes to begin using MTA-STS with a The owner of "example.com" wishes to begin using MTA-STS with a
policy that will solicit reports from senders without affecting how policy that will solicit reports from senders without affecting how
the messages are processed, in order to verify the identity of MXs the messages are processed, in order to verify the identity of MXs
that handle mail for "example.com", confirm that TLS is correctly that handle mail for "example.com", confirm that TLS is correctly
used, and ensure that certificates presented by the recipient MX used, and ensure that certificates presented by the recipient MX
validate. validate.
 End of changes. 40 change blocks. 
105 lines changed or deleted 112 lines changed or added

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