draft-ietf-uta-mta-sts-12.txt   draft-ietf-uta-mta-sts-13.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Intended status: Standards Track Google, Inc Intended status: Standards Track Google, Inc
Expires: June 7, 2018 B. Ramakrishnan Expires: June 7, 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 December 4, 2017
SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts-12 draft-ietf-uta-mta-sts-13
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 4, line 7 skipping to change at page 4, line 7
The DANE TLSA record [RFC7672] is similar, in that DANE is also The DANE TLSA record [RFC7672] is similar, in that DANE is also
designed to upgrade unauthenticated encryption or plaintext designed to upgrade unauthenticated encryption or plaintext
transmission into authenticated, downgrade-resistant encrypted transmission into authenticated, downgrade-resistant encrypted
transmission. DANE requires DNSSEC [RFC4033] for authentication; the transmission. DANE requires DNSSEC [RFC4033] for authentication; the
mechanism described here instead relies on certificate authorities mechanism described here instead relies on certificate authorities
(CAs) and does not require DNSSEC, at a cost of risking malicious (CAs) and does not require DNSSEC, at a cost of risking malicious
downgrades. For a thorough discussion of this trade-off, see downgrades. For a thorough discussion of this trade-off, see
Section 10, "Security Considerations". Section 10, "Security Considerations".
In addition, MTA-STS provides an optional report-only mode, enabling In addition, MTA-STS provides an optional testing-only mode, enabling
soft deployments to detect policy failures; partial deployments can soft deployments to detect policy failures; partial deployments can
be achieved in DANE by deploying TLSA records only for some of a be achieved in DANE by deploying TLSA records only for some of a
domain's MXs, but such a mechanism is not possible for the per-domain domain's MXs, but such a mechanism is not possible for the per-domain
policies used by MTA-STS. policies used by MTA-STS.
The primary motivation of MTA-STS is to provide a mechanism for The primary motivation of MTA-STS is to provide a mechanism for
domains to ensure transport security even when deploying DNSSEC is domains to ensure transport security even when deploying DNSSEC is
undesirable or impractical. However, MTA-STS is designed not to undesirable or impractical. However, MTA-STS is designed not to
interfere with DANE deployments when the two overlap; in particular, interfere with DANE deployments when the two overlap; in particular,
senders who implement MTA-STS validation MUST NOT allow a "valid" or senders who implement MTA-STS validation MUST NOT allow a "valid" or
"report-only" MTA-STS validation to override a failing DANE "testing"-only MTA-STS validation to override a failing DANE
validation. validation.
3. Policy Discovery 3. Policy Discovery
MTA-STS policies are distributed via HTTPS from a "well-known" MTA-STS policies are distributed via HTTPS from a "well-known"
[RFC5785] path served within the Policy Domain, and their presence [RFC5785] path served within the Policy Domain, and their presence
and current version are indicated by a TXT record at the Policy and current version are indicated by a TXT record at the Policy
Domain. These TXT records additionally contain a policy "id" field, Domain. These TXT records additionally contain a policy "id" field,
allowing sending MTAs to check the currency of a cached policy allowing sending MTAs to check the currency of a cached policy
without performing an HTTPS request. without performing an HTTPS request.
skipping to change at page 11, line 5 skipping to change at page 11, line 5
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
the result of a policy validation failure one of two ways, depending the result of a policy validation failure one of two ways, depending
on the value of the policy "mode" field: on the value of the policy "mode" field:
1. "enforce": In this mode, sending MTAs MUST NOT deliver the 1. "enforce": In this mode, sending MTAs MUST NOT deliver the
message to hosts which fail MX matching or certificate message to hosts which fail MX matching or certificate
validation. validation.
2. "report": In this mode, sending MTAs which also implement the 2. "testing": In this mode, sending MTAs which also implement the
TLSRPT specification [I-D.ietf-uta-smtp-tlsrpt] merely send a TLSRPT specification [I-D.ietf-uta-smtp-tlsrpt] merely send a
report indicating policy application failures (so long as TLSRPT report indicating policy application failures (so long as TLSRPT
is also implemented by the recipient domain). is also implemented by the recipient domain).
3. "none": In this mode, sending MTAs should treat the policy domain 3. "none": In this mode, sending MTAs should treat the policy domain
as though it does not have any active policy; see Section 8.3, as though it does not have any active policy; see Section 8.3,
"Removing MTA-STS", for use of this mode value. "Removing MTA-STS", for use of this mode value.
When a message fails to deliver due to an "enforce" policy, a When a message fails to deliver due to an "enforce" policy, a
compliant MTA MUST NOT permanently fail to deliver messages before compliant MTA MUST NOT permanently fail to deliver messages before
skipping to change at page 21, line 39 skipping to change at page 21, line 39
validate. validate.
MTA-STS policy indicator TXT RR: MTA-STS policy indicator TXT RR:
_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;" _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
MTA-STS Policy file served as the response body at "https://mta- MTA-STS Policy file served as the response body at "https://mta-
sts.example.com/.well-known/mta-sts.txt": sts.example.com/.well-known/mta-sts.txt":
version: STSv1 version: STSv1
mode: report mode: testing
mx: mx1.example.com mx: mx1.example.com
mx: mx2.example.com mx: mx2.example.com
mx: mx.backup-example.com mx: mx.backup-example.com
max_age: 12345678 max_age: 12345678
Appendix B. Message delivery pseudocode Appendix B. Message delivery pseudocode
Below is pseudocode demonstrating the logic of a compliant sending Below is pseudocode demonstrating the logic of a compliant sending
MTA. MTA.
 End of changes. 5 change blocks. 
5 lines changed or deleted 5 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/