draft-ietf-uta-mta-sts-18.txt   draft-ietf-uta-mta-sts-19.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: November 21, 2018 B. Ramakrishnan Expires: November 24, 2018 B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
A. Brotman A. Brotman
Comcast, Inc Comcast, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
May 20, 2018 May 23, 2018
SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts-18 draft-ietf-uta-mta-sts-19
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 http://datatracker.ietf.org/drafts/current/. Drafts is at https://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 November 21, 2018. This Internet-Draft will expire on November 24, 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 (https://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
skipping to change at page 5, line 43 skipping to change at page 5, line 43
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 "=", ";", and control chars
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, senders MUST assume the recipient domain does not have an
available MTA-STS policy and skip the remaining steps of policy available MTA-STS policy and skip the remaining steps of policy
discovery. (Note that lack of an available policy does not signal discovery. (Note that absence of a usable TXT record is not by
opting out of MTA-STS altogether if the sender has a previously itself sufficient to remove a sender's previously cached policy for
cached policy for the recipient domain, as discussed in Section 5.1, the Policy Domain, as discussed in Section 5.1, "Policy Application
"Policy Application Control Flow".) If the resulting TXT record Control Flow".) If the resulting TXT record contains multiple
contains multiple strings, then the record MUST be treated as if strings, then the record MUST be treated as if those strings are
those strings are concatenated together without adding spaces. 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 path is "https://mta- Thus for a Policy Domain of "example.com" the ful URL is
sts.example.com/.well-known/mta-sts.txt". "https://mta-sts.example.com/.well-known/mta-sts.txt".
When fetching a policy, senders SHOULD validate that the media type When fetching a policy, senders SHOULD validate that the media type
is "text/plain" to guard against cases where webservers allow is "text/plain" to guard against cases where webservers allow
untrusted users to host non-text content (typically, HTML or images) untrusted users to host non-text content (typically, HTML or images)
at a user-defined path. All parameters other than charset=utf-8 or at a user-defined path. All parameters other than charset=utf-8 or
charset=us-ascii are ignored. Additional "Content-Type" parameters charset=us-ascii are ignored. Additional "Content-Type" parameters
are also ignored. are also ignored.
This resource contains the following CRLF-separated key/value pairs: This resource contains the following CRLF-separated key/value pairs:
skipping to change at page 11, line 17 skipping to change at page 11, line 17
A receiving candidate MX host is valid according to an applied MTA- A receiving candidate MX host is valid according to an applied MTA-
STS policy if the MX record name matches one or more of the "mx" STS policy if the MX record name matches one or more of the "mx"
fields in the applied policy. Matching is identical to the rules fields in the applied policy. Matching is identical to the rules
given in [RFC6125], with restriction that the wildcard character "*" given in [RFC6125], with restriction that the wildcard character "*"
may only be used to match the entire left-most label in the presented may only be used to match the entire left-most label in the presented
identifier. Thus the mx pattern "*.example.com" matches identifier. Thus the mx pattern "*.example.com" matches
"mail.example.com" but not "example.com" or "foo.bar.example.com". "mail.example.com" but not "example.com" or "foo.bar.example.com".
4.2. Recipient MTA Certificate Validation 4.2. Recipient MTA Certificate Validation
The certificate presented by the receiving MTA MUST chain to a root The certificate presented by the receiving MTA MUST not be expired,
CA that is trusted by the sending MTA and be non-expired. The and MUST chain to a root CA that is trusted by the sending MTA. The
certificate MUST have a subject alternative name (SAN, [RFC5280]) certificate MUST have a subject alternative name (SAN, [RFC5280])
with a DNS-ID ([RFC6125]) matching the host name, per the rules given with a DNS-ID ([RFC6125]) matching the host name, per the rules given
in [RFC6125]. The MX's certificate MAY also be checked for in [RFC6125]. The MX's certificate MAY also be checked for
revocation via OCSP [RFC6960], CRLs [RFC6818], or some other revocation via OCSP [RFC6960], CRLs [RFC6818], or some other
mechanism. mechanism.
5. Policy Application 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,
non-expired MTA-STS policy, a sending MTA honoring MTA-STS applies non-expired MTA-STS policy, a sending MTA honoring MTA-STS applies
skipping to change at page 15, line 7 skipping to change at page 15, line 7
_mta-sts.user.example. IN CNAME _mta-sts.provider.example. _mta-sts.user.example. IN CNAME _mta-sts.provider.example.
Policy: Policy:
> GET /.well-known/mta-sts.txt Host: mta-sts.user.example > GET /.well-known/mta-sts.txt Host: mta-sts.user.example
< HTTP/1.1 200 OK # Response proxies content from < HTTP/1.1 200 OK # Response proxies content from
# https://mta-sts.provider.example # https://mta-sts.provider.example
Note that in all such cases, the policy endpoint ("https://mta- Note that in all such cases, the policy endpoint ("https://mta-
sts.user.example/.well-known/mta-sts.txt" in this example) must still sts.user.example/.well-known/mta-sts.txt" in this example) must still
present a certificate valid for the Policy Domain ("user.example"), present a certificate valid for the Policy Host ("mta-
and not for that of the provider ("provider.example"). sts.user.example"), and not for that host at the provider's domain
("mta-sts.provider.example").
Note that while sending MTAs MUST NOT use HTTP caching when fetching Note that while sending MTAs MUST NOT use HTTP caching when fetching
policies via HTTPS, such caching may nonetheless be useful to a policies via HTTPS, such caching may nonetheless be useful to a
reverse proxy configured as described in this section. An HTTPS reverse proxy configured as described in this section. An HTTPS
policy endpoint expecting to be proxied for multiple hosted domains-- policy endpoint expecting to be proxied for multiple hosted domains--
as with a large mail hosting provider or similar--may wish to as with a large mail hosting provider or similar--may wish to
indicate an HTTP Cache-Control "max-age" response directive (as indicate an HTTP Cache-Control "max-age" response directive (as
specified in [RFC7234]) of 60 seconds as a reasonable value to save specified in [RFC7234]) of 60 seconds as a reasonable value to save
reverse proxies an unnecessarily high-rate of proxied policy reverse proxies an unnecessarily high-rate of proxied policy
fetching. fetching.
skipping to change at page 20, line 45 skipping to change at page 20, line 45
Klaus Umbach 1&1 Mail & Media Development & Technology GmbH Klaus Umbach 1&1 Mail & Media Development & Technology GmbH
klaus.umbach@1und1.de klaus.umbach@1und1.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-20 (work in progress), May 2018. tlsrpt-21 (work in progress), May 2018.
[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/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, <https://www.rfc- DOI 10.17487/RFC2818, May 2000,
editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[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, <https://www.rfc-editor.org/info/rfc3207>. February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[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, <https://www.rfc- DOI 10.17487/RFC5246, August 2008,
editor.org/info/rfc5246>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC5321, October 2008,
editor.org/info/rfc5321>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC5785, April 2010,
editor.org/info/rfc5785>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC6066, January 2011,
editor.org/info/rfc6066>. <https://www.rfc-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>.
[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,
skipping to change at page 22, line 23 skipping to change at page 22, line 23
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[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, <https://www.rfc- DOI 10.17487/RFC5322, October 2008,
editor.org/info/rfc5322>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC5891, August 2010,
editor.org/info/rfc5891>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC7672, October 2015,
editor.org/info/rfc7672>. <https://www.rfc-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. 20 change blocks. 
37 lines changed or deleted 38 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/