draft-ietf-uta-mta-sts-05.txt   draft-ietf-uta-mta-sts-06.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 4, 2017 B. Ramakrishnan Expires: December 01, 2017 B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
A. Brotman A. Brotman
Comcast, Inc Comcast, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
May 3, 2017 May 31, 2017
SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts-05 draft-ietf-uta-mta-sts-06
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 November 4, 2017. This Internet-Draft will expire on November 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 10, line 16 skipping to change at page 10, line 16
the case of temporary message delivery failures (as discussed in the case of temporary message delivery failures (as discussed in
[RFC5321] section 4.5.4.1). [RFC5321] section 4.5.4.1).
6. Operational Considerations 6. Operational Considerations
6.1. Policy Updates 6.1. Policy Updates
Updating the policy requires that the owner make changes in two Updating the policy requires that the owner make changes in two
places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and
at the corresponding HTTPS endpoint. As a result, recipients should at the corresponding HTTPS endpoint. As a result, recipients should
thus expect a policy will continue to be used by senders until both expect a policy will continue to be used by senders until both the
the HTTPS and TXT endpoints are updated and the TXT record's TTL has HTTPS and TXT endpoints are updated and the TXT record's TTL has
passed. passed.
In other words, a sender who is unable to successfully deliver a In other words, a sender who is unable to successfully deliver a
message while applying a cache of the recipient's now-outdated policy message while applying a cache of the recipient's now-outdated policy
may be unable to discover that a new policy exists until the DNS TTL may be unable to discover that a new policy exists until the DNS TTL
has passed. Recipients should therefore ensure that old policies has passed. Recipients should therefore ensure that old policies
continue to work for message delivery during this period of time, or continue to work for message delivery during this period of time, or
risk message delays. risk message delays.
Recipients should also prefer to update the HTTPS policy body before
updating the TXT record; this ordering avoids the risk that senders,
seeing a new TXT record, mistakenly cache the old policy from HTTPS.
7. IANA Considerations 7. IANA Considerations
A new .well-known URI will be registered in the Well-Known URIs A new .well-known URI will be registered in the Well-Known URIs
registry as described below: registry as described below:
URI Suffix: mta-sts.json Change Controller: IETF URI Suffix: mta-sts.json Change Controller: IETF
8. Security Considerations 8. Security Considerations
SMTP MTA Strict Transport Security attempts to protect against an SMTP MTA Strict Transport Security attempts to protect against an
skipping to change at page 14, line 26 skipping to change at page 14, line 30
// Attempt to open an SMTP connection with STARTTLS with the MX. // Attempt to open an SMTP connection with STARTTLS with the MX.
} }
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 CN and DNS-ID SANs.
for san in getDnsIdSansAndCnFromCert(connection) { for san in getDnsIdSansAndCnFromCert(connection) {
for mx in policy.mx { for mx in policy.mx {
// Return if the server certificate from "connection" matches the "mx" host. // Return if the server certificate from "connection" matches the "mx" host.
if san[0] == '*' { if san[0] == '*' {
// Invalid wildcard! // Invalid wildcard!
if san[1] != '.' return false if san[1] != '.' continue
san = san[1:] san = san[1:]
} }
if san[0] == '.' && HasSuffix(mx, san) { if san[0] == '.' && HasSuffix(mx, san) {
return true return true
} }
if mx[0] == '.' && HasSuffix(san, mx) { if mx[0] == '.' && HasSuffix(san, mx) {
return true return true
} }
if mx == san { if mx == san {
return true return true
 End of changes. 7 change blocks. 
7 lines changed or deleted 11 lines changed or added

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