draft-ietf-uta-mta-sts-19.txt   draft-ietf-uta-mta-sts-20.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 24, 2018 B. Ramakrishnan Expires: December 8, 2018 B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
A. Brotman A. Brotman
Comcast, Inc Comcast, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
May 23, 2018 June 6, 2018
SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts-19 draft-ietf-uta-mta-sts-20
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 https://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 24, 2018. This Internet-Draft will expire on December 8, 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
(https://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
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 2, line 31 skipping to change at page 2, line 31
4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 10 4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 10
4.1. MX Host Validation . . . . . . . . . . . . . . . . . . . 11 4.1. MX Host Validation . . . . . . . . . . . . . . . . . . . 11
4.2. Recipient MTA Certificate Validation . . . . . . . . . . 11 4.2. Recipient MTA Certificate Validation . . . . . . . . . . 11
5. Policy Application . . . . . . . . . . . . . . . . . . . . . 11 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 11
5.1. Policy Application Control Flow . . . . . . . . . . . . . 12 5.1. Policy Application Control Flow . . . . . . . . . . . . . 12
6. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 12 6. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 12
7. Interoperability Considerations . . . . . . . . . . . . . . . 13 7. Interoperability Considerations . . . . . . . . . . . . . . . 13
7.1. SNI Support . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. SNI Support . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Minimum TLS Version Support . . . . . . . . . . . . . . . 13 7.2. Minimum TLS Version Support . . . . . . . . . . . . . . . 13
8. Operational Considerations . . . . . . . . . . . . . . . . . 13 8. Operational Considerations . . . . . . . . . . . . . . . . . 13
8.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 13 8.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 14
8.2. Policy Delegation . . . . . . . . . . . . . . . . . . . . 14 8.2. Policy Delegation . . . . . . . . . . . . . . . . . . . . 14
8.3. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 15 8.3. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 15
8.4. Preserving MX Candidate Traversal . . . . . . . . . . . . 15 8.4. Preserving MX Candidate Traversal . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 16 9.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 16
9.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 16 9.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 16
9.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 16 9.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 17 10.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 17
10.2. Preventing Policy Discovery . . . . . . . . . . . . . . 18 10.2. Preventing Policy Discovery . . . . . . . . . . . . . . 18
10.3. Denial of Service . . . . . . . . . . . . . . . . . . . 18 10.3. Denial of Service . . . . . . . . . . . . . . . . . . . 18
10.4. Weak Policy Constraints . . . . . . . . . . . . . . . . 19 10.4. Weak Policy Constraints . . . . . . . . . . . . . . . . 19
10.5. Compromise of the Web PKI System . . . . . . . . . . . . 19 10.5. Compromise of the Web PKI System . . . . . . . . . . . . 19
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. MTA-STS example record & policy . . . . . . . . . . 23 Appendix A. MTA-STS example record & policy . . . . . . . . . . 23
Appendix B. Message delivery pseudocode . . . . . . . . . . . . 23 Appendix B. Message delivery pseudocode . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
hosts to negotiate the use of a TLS channel for encrypted mail hosts to negotiate the use of a TLS channel for encrypted mail
transmission. transmission.
While this opportunistic encryption protocol by itself provides a While this opportunistic encryption protocol by itself provides a
high barrier against passive man-in-the-middle traffic interception, high barrier against passive man-in-the-middle traffic interception,
any attacker who can delete parts of the SMTP session (such as the any attacker who can delete parts of the SMTP session (such as the
skipping to change at page 4, line 5 skipping to change at page 4, line 5
"alice@example.com" this would ordinarily be "example.com", but "alice@example.com" this would ordinarily be "example.com", but
this may be overridden by explicit routing rules (as described in this may be overridden by explicit routing rules (as described in
Section 3.4, "Policy Selection for Smart Hosts and Subdomains"). Section 3.4, "Policy Selection for Smart Hosts and Subdomains").
o Policy Host: The HTTPS host which serves the MTA-STS Policy for a o Policy Host: The HTTPS host which serves the MTA-STS Policy for a
Policy Domain. Rules for constructing the hostname are described Policy Domain. Rules for constructing the hostname are described
in Section 3.2, "MTA-STS Policies". in Section 3.2, "MTA-STS Policies".
o Sender: The SMTP Mail Transfer Agent sending an email message. o Sender: The SMTP Mail Transfer Agent sending an email message.
o ABNF: Augmented Backus-Naur Form, a syntax for formally specifying
syntax, defined in [RFC5234] and [RFC7405].
2. Related Technologies 2. Related Technologies
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".
skipping to change at page 5, line 16 skipping to change at page 5, line 20
updates. This string MUST uniquely identify a given instance of a updates. This string MUST uniquely identify a given instance of a
policy, such that senders can determine when the policy has been policy, such that senders can determine when the policy has been
updated by comparing to the "id" of a previously seen policy. updated by comparing to the "id" of a previously seen policy.
There is no implied ordering of "id" fields between revisions. There is no implied ordering of "id" fields between revisions.
An example TXT record is as below: An example TXT record is as below:
"_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"" "_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;""
The formal definition of the "_mta-sts" TXT record, defined using The formal definition of the "_mta-sts" TXT record, defined using
[RFC7405], is as follows: ABNF ([RFC7405]), is as follows:
sts-text-record = sts-version 1*(field-delim sts-field) [field-delim] sts-text-record = sts-version 1*(sts-field-delim sts-field)
[sts-field-delim]
sts-field = sts-id / ; Note that sts-id record sts-field = sts-id / ; Note that sts-id record
sts-extension ; is required. sts-extension ; is required.
field-delim = *WSP ";" *WSP sts-field-delim = *WSP ";" *WSP
sts-version = %s"v=STSv1" sts-version = %s"v=STSv1"
sts-id = %s"id=" 1*32(ALPHA / DIGIT) ; id=... sts-id = %s"id=" 1*32(ALPHA / DIGIT) ; id=...
sts-extension = sts-ext-name "=" sts-ext-value ; name=value sts-extension = sts-ext-name "=" sts-ext-value ; name=value
sts-ext-name = (ALPHA / DIGIT) sts-ext-name = (ALPHA / DIGIT)
*31(ALPHA / DIGIT / "_" / "-" / ".") *31(ALPHA / DIGIT / "_" / "-" / ".")
skipping to change at page 6, line 13 skipping to change at page 6, line 15
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 ful URL is Thus for a Policy Domain of "example.com" the full URL is
"https://mta-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 7, line 21 skipping to change at page 7, line 24
mode: enforce mode: enforce
mx: mail.example.com mx: mail.example.com
mx: *.example.net mx: *.example.net
mx: backupmx.example.com mx: backupmx.example.com
max_age: 604800 max_age: 604800
The formal definition of the policy resource, defined using The formal definition of the policy resource, defined using
[RFC7405], is as follows: [RFC7405], is as follows:
sts-policy-record = sts-policy-field *WSP sts-policy-record = sts-policy-field *WSP
*(CRLF sts-policy-field *WSP) *(sts-policy-term sts-policy-field *WSP)
[CRLF] [sts-policy-term]
sts-policy-field = sts-policy-version / ; required once sts-policy-field = sts-policy-version / ; required once
sts-policy-mode / ; required once sts-policy-mode / ; required once
sts-policy-max-age / ; required once sts-policy-max-age / ; required once
0*(sts-policy-mx *WSP CRLF) / 0*(sts-policy-mx *WSP sts-policy-term) /
; required at least once, except when ; required at least once, except when
; mode is "none" ; mode is "none"
sts-policy-extension ; other fields sts-policy-extension ; other fields
field-delim = ":" *WSP sts-policy-field-delim = ":" *WSP
sts-policy-version = sts-policy-version-field field-delim sts-policy-version = sts-policy-version-field sts-policy-field-delim
sts-policy-version-value sts-policy-version-value
sts-policy-version-field = %s"version" sts-policy-version-field = %s"version"
sts-policy-version-value = %s"STSv1" sts-policy-version-value = %s"STSv1"
sts-policy-mode = sts-policy-mode-field field-delim sts-policy-mode = sts-policy-mode-field sts-policy-field-delim
sts-policy-mode-value sts-policy-mode-value
sts-policy-mode-field = %s"mode" sts-policy-mode-field = %s"mode"
sts-policy-mode-value = %s"testing" / %s"enforce" / %s"none" sts-policy-mode-value = %s"testing" / %s"enforce" / %s"none"
sts-policy-mx = sts-policy-mx-field sts-policy-field-delim
sts-policy-mx = sts-policy-mx-field field-delim
sts-policy-mx-value sts-policy-mx-value
sts-policy-mx-field = %s"mx" sts-policy-mx-field = %s"mx"
sts-policy-mx-value = ["*."] *(sts-policy-mx-label ".") sts-policy-mx-value = ["*."] *(sts-policy-mx-label ".")
sts-policy-mx-toplabel sts-policy-mx-toplabel
sts-policy-mx-label = sts-policy-alphanum | sts-policy-mx-label = sts-policy-alphanum |
sts-policy-alphanum *(sts-policy-alphanum | "-") sts-policy-alphanum *(sts-policy-alphanum | "-")
sts-policy-alphanum sts-policy-alphanum
sts-policy-mx-toplabel = ALPHA | ALPHA *(sts-policy-alphanum | "-") sts-policy-mx-toplabel = ALPHA | ALPHA *(sts-policy-alphanum | "-")
sts-policy-alphanum sts-policy-alphanum
sts-policy-max-age = sts-policy-max-age-field field-delim sts-policy-max-age = sts-policy-max-age-field sts-policy-field-delim
sts-policy-max-age-value sts-policy-max-age-value
sts-policy-max-age-field = %s"max_age" sts-policy-max-age-field = %s"max_age"
sts-policy-max-age-value = 1*10(DIGIT) sts-policy-max-age-value = 1*10(DIGIT)
sts-policy-extension = sts-policy-ext-name ; additional sts-policy-extension = sts-policy-ext-name ; additional
field-delim ; extension sts-policy-field-delim ; extension
sts-policy-ext-value ; fields sts-policy-ext-value ; fields
sts-policy-ext-name = (sts-policy-alphanum) sts-policy-ext-name = (sts-policy-alphanum)
*31(sta-policy-alphanum / "_" / "-" / ".") *31(sta-policy-alphanum / "_" / "-" / ".")
sts-policy-term = CRLF / LF sts-policy-term = LF / CR / CRLF
sts-policy-ext-value = sts-policy-vchar sts-policy-ext-value = sts-policy-vchar
[*(%x20 / sts-policy-vchar) [*(%x20 / sts-policy-vchar)
sts-policy-vchar] sts-policy-vchar]
; chars, including UTF-8 [@?RFC3629], ; chars, including UTF-8 [@!RFC3629],
; excluding CTLs and no ; excluding CTLs and no
; leading/trailing spaces ; leading/trailing spaces
sts-policy-alphanum = ALPHA | DIGIT sts-policy-alphanum = ALPHA | DIGIT
sts-policy-vchar = %x21-7E / UTF8-2 / UTF8-3 / UTF8-4 sts-policy-vchar = %x21-7E / UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <Defined in Section 4 of [@!RFC3629]>
UTF8-3 = <Defined in Section 4 of [@!RFC3629]>
UTF8-4 = <Defined in Section 4 of [@!RFC3629]>
Parsers MUST accept TXT records and policy files which are Parsers MUST accept TXT records and policy files which are
syntactically valid (i.e., valid key/value pairs separated by semi- syntactically valid (i.e., valid key/value pairs separated by semi-
colons for TXT records) and but containing additional key/value pairs colons for TXT records), possibly containing additional key/value
not specified in this document, in which case unknown fields SHALL be pairs not specified in this document, in which case unknown fields
ignored. If any non-repeated field--i.e., all fields excepting "mx" SHALL be ignored. If any non-repeated field--i.e., all fields
--is duplicated, all entries except for the first SHALL be ignored. excepting "mx"--is duplicated, all entries except for the first SHALL
If any field is not specified, the policy SHALL be treated as be ignored. If any field is not specified, the policy SHALL be
invalid. treated as invalid.
3.3. HTTPS Policy Fetching 3.3. HTTPS Policy Fetching
Policy bodies are, as described above, retrieved by sending MTAs via Policy bodies are, as described above, retrieved by sending MTAs via
HTTPS [RFC2818]. During the TLS handshake initiated to fetch a new HTTPS [RFC2818]. During the TLS handshake initiated to fetch a new
or updated policy from the Policy Host, the Policy Host HTTPS server or updated policy from the Policy Host, the Policy Host HTTPS server
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"
DNS-ID ([RFC6125]) (e.g., "mta-sts.example.com") as described below, DNS-ID ([RFC6125]) (e.g., "mta-sts.example.com") as described below,
chain to a root CA that is trusted by the sending MTA, and be non- 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 expired. It is expected that sending MTAs use a set of trusted CAs
skipping to change at page 9, line 38 skipping to change at page 9, line 46
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
is 200 (OK). HTTP 3xx redirects MUST NOT be followed, and HTTP is 200 (OK). HTTP 3xx redirects MUST NOT be followed, and HTTP
caching (as specified in [RFC7234]) MUST NOT be used. caching (as specified in [RFC7234]) MUST NOT be used.
Senders may wish to rate-limit the frequency of attempts to fetch the Senders may wish to rate-limit the frequency of attempts to fetch the
HTTPS endpoint even if a valid TXT record for the recipient domain HTTPS endpoint even if a valid TXT record for the recipient domain
exists. In the case that the HTTPS GET fails, we implementions exists. In the case that the HTTPS GET fails, implementers SHOULD
SHOULD limit further attempts to a period of five minutes or longer limit further attempts to a period of five minutes or longer per
per version ID, to avoid overwhelming resource-constrained recipients version ID, to avoid overwhelming resource-constrained recipients
with cascading failures. with cascading failures.
Senders MAY impose a timeout on the HTTPS GET and/or a limit on the Senders MAY impose a timeout on the HTTPS GET and/or a limit on the
maximum size of the response body to avoid long delays or resource maximum size of the response body to avoid long delays or resource
exhaustion during attempted policy updates. A suggested timeout is exhaustion during attempted policy updates. A suggested timeout is
one minute, and a suggested maximum policy size 64 kilobytes; policy one minute, and a suggested maximum policy size 64 kilobytes; policy
hosts SHOULD respond to requests with a complete policy body within hosts SHOULD respond to requests with a complete policy body within
that timeout and size limit. that timeout and size limit.
If a valid TXT record is found but no policy can be fetched via HTTPS If a valid TXT record is found but no policy can be fetched via HTTPS
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-21 (work in progress), May 2018. tlsrpt-22 (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, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2119>. 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, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2818>. 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>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
editor.org/info/rfc5234>.
[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, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5246>. 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, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5321>. 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, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5785>. 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, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6066>. 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 34
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, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5322>. 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, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5891>. 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, DOI 10.17487/RFC7672, October 2015, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7672>. 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. 37 change blocks. 
54 lines changed or deleted 67 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/