--- 1/draft-ietf-uta-mta-sts-13.txt 2018-01-16 02:13:08.652280739 -0800 +++ 2/draft-ietf-uta-mta-sts-14.txt 2018-01-16 02:13:08.752283119 -0800 @@ -1,24 +1,24 @@ Using TLS in Applications D. Margolis Internet-Draft M. Risher Intended status: Standards Track Google, Inc -Expires: June 7, 2018 B. Ramakrishnan +Expires: July 20, 2018 B. Ramakrishnan Yahoo!, Inc A. Brotman Comcast, Inc J. Jones Microsoft, Inc - December 4, 2017 + January 16, 2018 SMTP MTA Strict Transport Security (MTA-STS) - draft-ietf-uta-mta-sts-13 + draft-ietf-uta-mta-sts-14 Abstract SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections, and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. Status of This Memo @@ -29,25 +29,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -352,22 +352,21 @@ 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 root CA that is trusted by the sending MTA, and be non-expired. It is expected that sending MTAs use a set of trusted CAs similar to those in widely deployed Web browsers and operating systems. The certificate is valid for the "mta-sts" host with respect to the rules described in [RFC6125], with the following application-specific considerations: - o Matching is performed only against the DNS-ID and CN-ID - identifiers. + o Matching is performed only against the DNS-ID identifiers. o DNS domain names in server certificates MAY contain the wildcard character '*' as the complete left-most label within the identifier. The certificate MAY be checked for revocation via the Online Certificate Status Protocol (OCSP) [RFC6960], certificate revocation lists (CRLs), or some other mechanism. Policies fetched via HTTPS are only valid if the HTTP response code @@ -431,37 +430,37 @@ described in "MX Certificate Validation". This section does not dictate the behavior of sending MTAs when policies fail to validate; see Section 5, "Policy Application" for a description of sending MTA behavior when policy validation fails. 4.1. MX Certificate Validation 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 - certificate MUST have a CN-ID ([RFC6125]) or subject alternative name - (SAN, [RFC5280]) with a DNS-ID matching the "mx" pattern. The MX's - certificate MAY also be checked for revocation via OCSP [RFC6960], - CRLs [RFC6818], or some other mechanism. + certificate MUST have a subject alternative name (SAN, [RFC5280]) + with a DNS-ID matching the "mx" pattern. The MX's certificate MAY + also be checked for revocation via OCSP [RFC6960], CRLs [RFC6818], or + some other mechanism. Because the "mx" patterns are not hostnames, however, matching is not identical to other common cases of X.509 certificate authentication (as described, for example, in [RFC6125]). Consider the example policy given above, with an "mx" pattern containing ".example.com". In this case, if the MX server's X.509 certificate contains a SAN matching "*.example.com", we are required to implement "wildcard-to- wildcard" matching. To simplify this case, we impose the following constraints on 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- - IDs, but must be the entire first label of the identifier (that is, + and [RFC6125] section 6.4.3: wildcards are valid in DNS-IDs, but must + be the entire first label of the identifier (that is, "*.example.com", not "mail*.example.com"). Senders who are comparing a "suffix" MX pattern with a wildcard identifier should thus strip the wildcard and ensure that the two sides match label-by-label, until all labels of the shorter side (if unequal length) are consumed. 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 SAN of "*.example.com" match an "mx" of "example.com". @@ -859,21 +858,21 @@ Markus Laber 1&1 Mail & Media Development & Technology GmbH markus.laber (at) 1und1 (dot de) 12. References 12.1. Normative References [I-D.ietf-uta-smtp-tlsrpt] Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J., 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 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, . @@ -1023,22 +1022,22 @@ if pat[0] == '.' { parts = SplitN(host, '.', 2) // Split on the first '.'. if len(parts) > 1 && parts[1] == pat[1:] { return true } } return false } func certMatches(connection, policy) { - // Assume a handy function to return CN and DNS-ID SANs. - for san in getDnsIdSansAndCnFromCert(connection) { + // Assume a handy function to return DNS-ID SANs. + for san in getDnsIdSansFromCert(connection) { for mx in policy.mx { // Return if the server certificate from "connection" matches the // "mx" host. if san[0] == '*' { // Invalid wildcard! if san[1] != '.' continue san = san[1:] } if isWildcardMatch(san, mx) || isWildcardMatch(mx, san) { return true