draft-ietf-uta-mta-sts-20.txt   draft-ietf-uta-mta-sts-21.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: December 8, 2018 B. Ramakrishnan Expires: December 18, 2018 B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
A. Brotman A. Brotman
Comcast, Inc Comcast, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
June 6, 2018 June 16, 2018
SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts-20 draft-ietf-uta-mta-sts-21
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
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 December 8, 2018. This Internet-Draft will expire on December 18, 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
(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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 10 3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 10
4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 10 4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 10
4.1. MX Host Validation . . . . . . . . . . . . . . . . . . . 11 4.1. MX Host Validation . . . . . . . . . . . . . . . . . . . 11
4.2. Recipient MTA Certificate Validation . . . . . . . . . . 11 4.2. Recipient MTA Certificate Validation . . . . . . . . . . 11
5. Policy Application . . . . . . . . . . . . . . . . . . . . . 11 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 11
5.1. Policy Application Control Flow . . . . . . . . . . . . . 12 5.1. Policy Application Control Flow . . . . . . . . . . . . . 12
6. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 12 6. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 12
7. Interoperability Considerations . . . . . . . . . . . . . . . 13 7. Interoperability Considerations . . . . . . . . . . . . . . . 13
7.1. SNI Support . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. SNI Support . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Minimum TLS Version Support . . . . . . . . . . . . . . . 13 7.2. Minimum TLS Version Support . . . . . . . . . . . . . . . 13
8. Operational Considerations . . . . . . . . . . . . . . . . . 13 8. Operational Considerations . . . . . . . . . . . . . . . . . 14
8.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 14 8.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 14
8.2. Policy Delegation . . . . . . . . . . . . . . . . . . . . 14 8.2. Policy Delegation . . . . . . . . . . . . . . . . . . . . 14
8.3. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 15 8.3. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 15
8.4. Preserving MX Candidate Traversal . . . . . . . . . . . . 15 8.4. Preserving MX Candidate Traversal . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 16 9.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 16
9.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 16 9.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 16
9.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 16 9.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 17 10.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 17
10.2. Preventing Policy Discovery . . . . . . . . . . . . . . 18 10.2. Preventing Policy Discovery . . . . . . . . . . . . . . 18
10.3. Denial of Service . . . . . . . . . . . . . . . . . . . 18 10.3. Denial of Service . . . . . . . . . . . . . . . . . . . 18
10.4. Weak Policy Constraints . . . . . . . . . . . . . . . . 19 10.4. Weak Policy Constraints . . . . . . . . . . . . . . . . 19
10.5. Compromise of the Web PKI System . . . . . . . . . . . . 19 10.5. Compromise of the Web PKI System . . . . . . . . . . . . 19
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 22
skipping to change at page 5, line 17 skipping to change at page 5, line 17
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. updated by comparing to the "id" of a previously seen policy.
There is no implied ordering of "id" fields between revisions. There is no implied ordering of "id" fields between revisions.
An example TXT record is as below: An example TXT record is as below:
"_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"" _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
The formal definition of the "_mta-sts" TXT record, defined using The formal definition of the "_mta-sts" TXT record, defined using
ABNF ([RFC7405]), is as follows: ABNF ([RFC7405]), is as follows:
sts-text-record = sts-version 1*(sts-field-delim sts-field) sts-text-record = sts-version 1*(sts-field-delim sts-field)
[sts-field-delim] [sts-field-delim]
sts-field = sts-id / ; Note that sts-id record sts-field = sts-id / ; Note that sts-id record
sts-extension ; is required. sts-extension ; is required.
skipping to change at page 5, line 40 skipping to change at page 5, line 40
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 "=", ";", and control chars ; chars excluding "=", ";", SP, and CTLs
The TXT record MUST begin with sts-version field, and the order of The TXT record MUST begin with sts-version field, and the order of
other fields is not significant. If multiple TXT records for "_mta- other fields is not significant. If multiple TXT records for "_mta-
sts" are returned by the resolver, records which do not begin with sts" are returned by the resolver, records which do not begin with
"v=STSv1;" are discarded. If the number of resulting records is not "v=STSv1;" are discarded. If the number of resulting records is not
one, senders MUST assume the recipient domain does not have an one, or if the resulting record is syntactically invalid, senders
available MTA-STS policy and skip the remaining steps of policy MUST assume the recipient domain does not have an available MTA-STS
discovery. (Note that absence of a usable TXT record is not by policy and skip the remaining steps of policy discovery. (Note that
itself sufficient to remove a sender's previously cached policy for absence of a usable TXT record is not by itself sufficient to remove
the Policy Domain, as discussed in Section 5.1, "Policy Application a sender's previously cached policy for the Policy Domain, as
Control Flow".) If the resulting TXT record contains multiple discussed in Section 5.1, "Policy Application Control Flow".) If the
strings, then the record MUST be treated as if those strings are resulting TXT record contains multiple strings, then the record MUST
concatenated together without adding spaces. 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 Policy Host. The Policy Host DNS name is constructed by the Policy Host. The Policy Host DNS name is constructed by
prepending "mta-sts" to the Policy Domain. prepending "mta-sts" to the Policy Domain.
Thus for a Policy Domain of "example.com" the full URL is Thus for a Policy Domain of "example.com" the full URL is
skipping to change at page 7, line 31 skipping to change at page 7, line 32
[RFC7405], is as follows: [RFC7405], is as follows:
sts-policy-record = sts-policy-field *WSP sts-policy-record = sts-policy-field *WSP
*(sts-policy-term sts-policy-field *WSP) *(sts-policy-term sts-policy-field *WSP)
[sts-policy-term] [sts-policy-term]
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 sts-policy-term) / sts-policy-term /
; required at least once, except when ; required at least once, except when
; mode is "none" ; mode is "none"
sts-policy-extension ; other fields sts-policy-extension ; other fields
sts-policy-field-delim = ":" *WSP sts-policy-field-delim = ":" *WSP
sts-policy-version = sts-policy-version-field sts-policy-field-delim sts-policy-version = sts-policy-version-field sts-policy-field-delim
sts-policy-version-value sts-policy-version-value
skipping to change at page 7, line 50 skipping to change at page 8, line 4
sts-policy-version-value sts-policy-version-value
sts-policy-version-field = %s"version" sts-policy-version-field = %s"version"
sts-policy-version-value = %s"STSv1" sts-policy-version-value = %s"STSv1"
sts-policy-mode = sts-policy-mode-field sts-policy-field-delim sts-policy-mode = sts-policy-mode-field sts-policy-field-delim
sts-policy-mode-value sts-policy-mode-value
sts-policy-mode-field = %s"mode" sts-policy-mode-field = %s"mode"
sts-policy-mode-value = %s"testing" / %s"enforce" / %s"none" sts-policy-mode-value = %s"testing" / %s"enforce" / %s"none"
sts-policy-mx = sts-policy-mx-field sts-policy-field-delim sts-policy-mx = sts-policy-mx-field sts-policy-field-delim
sts-policy-mx-value sts-policy-mx-value
sts-policy-mx-field = %s"mx" sts-policy-mx-field = %s"mx"
sts-policy-mx-value = ["*."] *(sts-policy-mx-label ".") sts-policy-mx-value = ["."] Domain
sts-policy-mx-toplabel
sts-policy-mx-label = sts-policy-alphanum | sts-policy-mx-label = sts-policy-alphanum /
sts-policy-alphanum *(sts-policy-alphanum | "-") sts-policy-alphanum *(sts-policy-alphanum / "-")
sts-policy-alphanum sts-policy-alphanum
sts-policy-mx-toplabel = ALPHA | ALPHA *(sts-policy-alphanum | "-") sts-policy-mx-toplabel = ALPHA / ALPHA *(sts-policy-alphanum / "-")
sts-policy-alphanum sts-policy-alphanum
sts-policy-max-age = sts-policy-max-age-field sts-policy-field-delim sts-policy-max-age = sts-policy-max-age-field sts-policy-field-delim
sts-policy-max-age-value sts-policy-max-age-value
sts-policy-max-age-field = %s"max_age" sts-policy-max-age-field = %s"max_age"
sts-policy-max-age-value = 1*10(DIGIT) sts-policy-max-age-value = 1*10(DIGIT)
sts-policy-extension = sts-policy-ext-name ; additional sts-policy-extension = sts-policy-ext-name ; additional
sts-policy-field-delim ; extension sts-policy-field-delim ; extension
sts-policy-ext-value ; fields sts-policy-ext-value ; fields
sts-policy-ext-name = (sts-policy-alphanum) sts-policy-ext-name = (sts-policy-alphanum)
*31(sta-policy-alphanum / "_" / "-" / ".") *31(sta-policy-alphanum / "_" / "-" / ".")
sts-policy-term = LF / CR / CRLF sts-policy-term = LF / CRLF
sts-policy-ext-value = sts-policy-vchar sts-policy-ext-value = sts-policy-vchar
[*(%x20 / sts-policy-vchar) [*(%x20 / sts-policy-vchar)
sts-policy-vchar] sts-policy-vchar]
; chars, including UTF-8 [@!RFC3629], ; chars, including UTF-8 [@!RFC3629],
; excluding CTLs and no ; excluding CTLs and no
; leading/trailing spaces ; leading/trailing spaces
sts-policy-alphanum = ALPHA | DIGIT sts-policy-alphanum = ALPHA / DIGIT
sts-policy-vchar = %x21-7E / UTF8-2 / UTF8-3 / UTF8-4 sts-policy-vchar = %x21-7E / UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <Defined in Section 4 of [@!RFC3629]> UTF8-2 = <Defined in Section 4 of [@!RFC3629]>
UTF8-3 = <Defined in Section 4 of [@!RFC3629]> UTF8-3 = <Defined in Section 4 of [@!RFC3629]>
UTF8-4 = <Defined in Section 4 of [@!RFC3629]> UTF8-4 = <Defined in Section 4 of [@!RFC3629]>
Domain = <see RFC 5321 4.1.2>
Parsers MUST accept TXT records and policy files which are Parsers MUST accept TXT records and policy files which are
syntactically valid (i.e., valid key/value pairs separated by semi- syntactically valid (i.e., valid key/value pairs separated by semi-
colons for TXT records), possibly containing additional key/value colons for TXT records), possibly containing additional key/value
pairs not specified in this document, in which case unknown fields pairs not specified in this document, in which case unknown fields
SHALL be ignored. If any non-repeated field--i.e., all fields SHALL be ignored. If any non-repeated field--i.e., all fields
excepting "mx"--is duplicated, all entries except for the first SHALL excepting "mx"--is duplicated, all entries except for the first SHALL
be ignored. If any field is not specified, the policy SHALL be be ignored.
treated as invalid.
3.3. HTTPS Policy Fetching 3.3. HTTPS Policy Fetching
Policy bodies are, as described above, retrieved by sending MTAs via Policy bodies are, as described above, retrieved by sending MTAs via
HTTPS [RFC2818]. During the TLS handshake initiated to fetch a new HTTPS [RFC2818]. During the TLS handshake initiated to fetch a new
or updated policy from the Policy Host, the Policy Host HTTPS server or updated policy from the Policy Host, the Policy Host HTTPS server
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"
DNS-ID ([RFC6125]) (e.g., "mta-sts.example.com") as described below, DNS-ID ([RFC6125]) (e.g., "mta-sts.example.com") as described below,
chain to a root CA that is trusted by the sending MTA, and be non- 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 expired. It is expected that sending MTAs use a set of trusted CAs
skipping to change at page 10, line 35 skipping to change at page 10, line 35
problems with policy refresh, MTAs SHOULD alert administrators problems with policy refresh, MTAs SHOULD alert administrators
(through the use of logs or similar) when such attempts fail, unless (through the use of logs or similar) when such 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 administratively configured When sending mail via a "smart host"--an administratively configured
intermediate SMTP relay, which is different from the message intermediate SMTP relay, which is different from the message
recipient's server as determined from DNS --compliant senders MUST 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. This specification does not
provide a means of associating policies with addresses that employ
Address Literals [RFC5321].
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
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 MTA-STS policy, a sending MTA honoring MTA-STS MUST and non-expired MTA-STS policy, a sending MTA honoring MTA-STS MUST
 End of changes. 21 change blocks. 
29 lines changed or deleted 32 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/