draft-ietf-uta-mta-sts-13.txt   draft-ietf-uta-mta-sts-14.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: June 7, 2018 B. Ramakrishnan Expires: July 20, 2018 B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
A. Brotman A. Brotman
Comcast, Inc Comcast, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
December 4, 2017 January 16, 2018
SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts-13 draft-ietf-uta-mta-sts-14
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 https://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 June 7, 2018. This Internet-Draft will expire on July 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 (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
skipping to change at page 8, line 30 skipping to change at page 8, line 30
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.
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 and CN-ID o Matching is performed only against the DNS-ID identifiers.
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.
The certificate MAY be checked for revocation via the Online The certificate MAY be checked for revocation via the Online
Certificate Status Protocol (OCSP) [RFC6960], certificate revocation Certificate Status Protocol (OCSP) [RFC6960], certificate revocation
lists (CRLs), or some other mechanism. lists (CRLs), or some other mechanism.
Policies fetched via HTTPS are only valid if the HTTP response code Policies fetched via HTTPS are only valid if the HTTP response code
skipping to change at page 10, line 13 skipping to change at page 10, line 13
described in "MX Certificate Validation". described in "MX Certificate Validation".
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 CN-ID ([RFC6125]) or subject alternative name certificate MUST have a subject alternative name (SAN, [RFC5280])
(SAN, [RFC5280]) with a DNS-ID matching the "mx" pattern. The MX's with a DNS-ID matching the "mx" pattern. The MX's certificate MAY
certificate MAY also be checked for revocation via OCSP [RFC6960], also be checked for revocation via OCSP [RFC6960], CRLs [RFC6818], or
CRLs [RFC6818], or some other mechanism. 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
wildcard certificates, identical to those in [RFC7672] section 3.2.3 wildcard certificates, identical to those in [RFC7672] section 3.2.3
and [RFC6125] section 6.4.3: wildcards are valid in DNS-IDs or CN- and [RFC6125] section 6.4.3: wildcards are valid in DNS-IDs, but must
IDs, but must be the entire first label of the identifier (that is, be the entire first label of the identifier (that is,
"*.example.com", not "mail*.example.com"). Senders who are comparing "*.example.com", not "mail*.example.com"). Senders who are comparing
a "suffix" MX pattern with a wildcard identifier should thus strip a "suffix" MX pattern with a wildcard identifier should thus strip
the wildcard and ensure that the two sides match label-by-label, the wildcard and ensure that the two sides match label-by-label,
until all labels of the shorter side (if unequal length) are until all labels of the shorter side (if unequal length) are
consumed. consumed.
Note that a wildcard must match a label; an "mx" pattern of Note that a wildcard must match a label; an "mx" pattern of
".example.com" thus does not match a SAN of "example.com", nor does a ".example.com" thus does not match a SAN of "example.com", nor does a
SAN of "*.example.com" match an "mx" of "example.com". SAN of "*.example.com" match an "mx" of "example.com".
skipping to change at page 19, line 14 skipping to change at page 19, line 14
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-11 (work in progress), November 2017. tlsrpt-13 (work in progress), December 2017.
[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, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <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>.
skipping to change at page 22, line 36 skipping to change at page 22, line 36
if pat[0] == '.' { if pat[0] == '.' {
parts = SplitN(host, '.', 2) // Split on the first '.'. parts = SplitN(host, '.', 2) // Split on the first '.'.
if len(parts) > 1 && parts[1] == pat[1:] { if len(parts) > 1 && parts[1] == pat[1:] {
return true return true
} }
} }
return false return false
} }
func certMatches(connection, policy) { func certMatches(connection, policy) {
// Assume a handy function to return CN and DNS-ID SANs. // Assume a handy function to return DNS-ID SANs.
for san in getDnsIdSansAndCnFromCert(connection) { for san in getDnsIdSansFromCert(connection) {
for mx in policy.mx { for mx in policy.mx {
// Return if the server certificate from "connection" matches the // Return if the server certificate from "connection" matches the
// "mx" host. // "mx" host.
if san[0] == '*' { if san[0] == '*' {
// Invalid wildcard! // Invalid wildcard!
if san[1] != '.' continue if san[1] != '.' continue
san = san[1:] san = san[1:]
} }
if isWildcardMatch(san, mx) || isWildcardMatch(mx, san) { if isWildcardMatch(san, mx) || isWildcardMatch(mx, san) {
return true return true
 End of changes. 10 change blocks. 
16 lines changed or deleted 15 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/