draft-ietf-uta-mta-sts-07.txt   draft-ietf-uta-mta-sts-08.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: January 2, 2018 B. Ramakrishnan Expires: February 16, 2018 B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
A. Brotman A. Brotman
Comcast, Inc Comcast, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
June 29, 2017 August 15, 2017
SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts-07 draft-ietf-uta-mta-sts-08
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 January 2, 2018 . This Internet-Draft will expire on February 16, 2018.
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 2, line 19 skipping to change at page 2, line 19
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 3 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 3
3. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . 4 3. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . 4
3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 4 3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 4
3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 5 3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 5
3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 6 3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 7
3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 7 3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 9
4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 8 4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 9
4.1. MX Certificate Validation . . . . . . . . . . . . . . . . 8 4.1. MX Certificate Validation . . . . . . . . . . . . . . . . 9
5. Policy Application . . . . . . . . . . . . . . . . . . . . . 9 5. Policy Application . . . . . . . . . . . . . . . . . . . . . 10
5.1. Policy Application Control Flow . . . . . . . . . . . . . 9 5.1. Policy Application Control Flow . . . . . . . . . . . . . 10
6. Operational Considerations . . . . . . . . . . . . . . . . . 10 6. Operational Considerations . . . . . . . . . . . . . . . . . 11
6.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 10 6.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 10 7.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 11
7.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 10 7.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 12
7.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 11 7.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 12 8.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 13
8.2. Preventing Policy Discovery . . . . . . . . . . . . . . . 12 8.2. Preventing Policy Discovery . . . . . . . . . . . . . . . 13
8.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 12 8.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 14
8.4. Weak Policy Constraints . . . . . . . . . . . . . . . . . 13 8.4. Weak Policy Constraints . . . . . . . . . . . . . . . . . 14
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Appendix 1: MTA-STS example record & policy . . . . . . . . . 14 10. Appendix 1: MTA-STS example record & policy . . . . . . . . . 15
11. Appendix 2: Message delivery pseudocode . . . . . . . . . . . 14 11. Appendix 2: Message delivery pseudocode . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 18
12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 48 skipping to change at page 4, line 48
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
[RFC5234], is as follows: [RFC7405], is as follows:
sts-text-record = sts-version *WSP field-delim *WSP sts-id
[field-delim [sts-extensions]]
field-delim = %x3B ; ";" sts-text-record = sts-version field-delim sts-id
*(field-delim sts-extension) [field-delim]
sts-version = %x76 *WSP "=" *WSP %x53 %x54 ; "v=STSv1" field-delim = *WSP ";" *WSP
%x53 %x76 %x31
sts-id = %x69 %x64 *WSP "=" sts-version = %s"v=STSv1"
*WSP 1*32(ALPHA / DIGIT) ; "id="
sts-extensions = sts-extension *(field-delim sts-extension) sts-id = %s"id=" 1*32(ALPHA / DIGIT) ; id=...
[field-delim] ; extension fields
sts-extension = sts-ext-name *WSP "=" *WSP sts-ext-value sts-extension = sts-ext-name "=" sts-ext-value ; name=value
sts-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / ".") sts-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / ".")
sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) ; chars excluding sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) ; chars excluding
; "=", ";", SP, and ; "=", ";", SP, and
; control chars ; control chars
If multiple TXT records for "_mta-sts" are returned by the resolver, If multiple TXT records for "_mta-sts" are returned by the resolver,
records which do not begin with "v=STSv1;" are discarded. If the records which do not begin with "v=STSv1;" are discarded. If the
number of resulting records is not one, senders MUST assume the number of resulting records is not one, senders MUST assume the
recipient domain does not implement MTA-STS and skip the remaining recipient domain does not implement MTA-STS and skip the remaining
steps of policy discovery. steps of policy discovery.
3.2. MTA-STS Policies 3.2. MTA-STS Policies
The policy itself is a JSON [RFC7159] object served via the HTTPS GET The policy itself is a set of key/value pairs served via the HTTPS
method from the fixed [RFC5785] "well-known" path of ".well-known/ GET method from the fixed [RFC5785] "well-known" path of ".well-
mta-sts.json" served by the "mta-sts" host at the Policy Domain. known/mta-sts.txt" served by the "mta-sts" host at the Policy Domain;
Thus for "example.com" the path is "https://mta-sts.example.com the [RFC2616] "Content-Type" header MUST be "text/plain". Thus for
/.well-known/mta-sts.json". "example.com" the path is "https://mta-sts.example.com/.well-known/
mta-sts.txt".
This JSON object contains the following key/value pairs: This resource contains the following line-separated key/value pairs:
o "version": (plain-text, required). Currently only "STSv1" is o "version": (plain-text, required). Currently only "STSv1" is
supported. supported.
o "mode": (plain-text, required). Either "enforce" or "report", o "mode": (plain-text, required). Either "enforce" or "report",
indicating the expected behavior of a sending MTA in the case of a indicating the expected behavior of a sending MTA in the case of a
policy validation failure. policy validation failure.
o "max_age": Max lifetime of the policy (plain-text non-negative o "max_age": Max lifetime of the policy (plain-text non-negative
integer seconds, required). Well-behaved clients SHOULD cache a integer seconds, required). Well-behaved clients SHOULD cache a
policy for up to this value from last policy fetch time. To policy for up to this value from last policy fetch time. To
mitigate the risks of attacks at policy refresh time, it is mitigate the risks of attacks at policy refresh time, it is
expected that this value typically be in the range of weeks or expected that this value typically be in the range of weeks or
greater. greater.
o "mx": MX identity patterns (list of plain-text strings, required). o "mx": MX identity patterns (list of plain-text strings, required).
One or more patterns matching a Common Name ([RFC6125]) or Subject One or more patterns matching a Common Name ([RFC6125]) or Subject
Alternative Name ([RFC5280]) DNS-ID present in the X.509 Alternative Name ([RFC5280]) DNS-ID present in the X.509
certificate presented by any MX receiving mail for this domain. certificate presented by any MX receiving mail for this domain.
For example, "["mail.example.com", ".example.net"]" indicates that For example: "mx: mail.example.com mx: .example.net" indicates
mail for this domain might be handled by any MX with a certificate that mail for this domain might be handled by any MX with a
valid for a host at "mail.example.com" or "example.net". Valid certificate valid for a host at "mail.example.com" or
patterns can be either fully specified names ("example.com") or "example.net". Valid patterns can be either fully specified names
suffixes (".example.net") matching the right-hand parts of a ("example.com") or suffixes (".example.net") matching the right-
server's identity; the latter case are distinguished by a leading hand parts of a server's identity; the latter case are
period. In the case of Internationalized Domain Names distinguished by a leading period. If there are more than one MX
specified by the policy, they MUST be on separate lines within the
policy file. In the case of Internationalized Domain Names
([RFC5891]), the MX MUST specify the Punycode-encoded A-label ([RFC5891]), the MX MUST specify the Punycode-encoded A-label
[RFC3492] and not the Unicode-encoded U-label. The full semantics [RFC3492] and not the Unicode-encoded U-label. The full semantics
of certificate validation are described in Section 4.1, "MX of certificate validation are described in Section 4.1, "MX
Certificate Validation." Certificate Validation."
An example JSON policy is as below: An example policy is as below:
{ version: STSv1
"version": "STSv1", mode: enforce
"mode": "enforce", mx: mail.example.com
"mx": [".mail.example.com"], mx: .example.net
"max_age": 123456 mx: backupmx.example.com
} max_age: 123456
The formal definition of the policy resource, defined using
[RFC7405], is as follows:
sts-policy-record = sts-policy-version CRLF
sts-policy-mode CRLF
1*(sts-policy-mx CRLF)
sts-policy-max-age
field-delim = ":" *WSP
sts-policy-version = sts-policy-version-field field-delim
sts-policy-version-value
sts-policy-version-field = %s"version"
sts-policy-version-value = %s"STSv1"
sts-policy-mode = sts-policy-mode-field field-delim
sts-policy-mode-value
sts-policy-mode-field = %s"mode"
sts-policy-model-value = %s"report" / %s"enforce"
sts-policy-mx = sts-policy-mx-field field-delim
sts-policy-mx-value
sts-policy-mx-field = %s"mx"
sts-policy-mx-value = 1*(ALPHA / DIGIT / "_" / "-" / ".")
sts-policy-max-age = sts-policy-max-age-field field-delim
sts-policy-max-age-value
sts-policy-max-age-field = %s"max_age"
sts-policy-max-age-value = 1*10(DIGIT)
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 valid JSON for policy files) and colons for TXT records) and implementing a superset of this
implementing a superset of this specification, in which case unknown specification, in which case unknown fields SHALL be ignored. If any
fields SHALL be ignored. field other than "mx" is duplicated, the first entry will be honored,
the rest should be ignored. For the "mx" field, all valid entries
will be utilized when enforcing the stated policy.
3.3. HTTPS Policy Fetching 3.3. HTTPS Policy Fetching
When fetching a new policy or updating a policy, the HTTPS endpoint When fetching a new policy or updating a policy, the HTTPS endpoint
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 (as described below), chain to a root CA that is trusted by the host (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 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 use a set of trusted CAs similar to those in widely deployed Web
browsers and operating systems. browsers and operating systems.
skipping to change at page 9, line 15 skipping to change at page 10, line 25
A simple pseudocode implementation of this algorithm is presented in A simple pseudocode implementation of this algorithm is presented in
the Appendix. the Appendix.
5. Policy Application 5. Policy Application
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. "report": In this mode, sending MTAs merely send a report (as 1. "report": In this mode, sending MTAs which also implement the
described in the TLSRPT specification (TODO: add ref)) indicating TLSRPT specification (TODO: add ref) merely send a report
policy application failures. indicating policy application failures (so long as TLSRPT is also
implemented by the recipient domain).
2. "enforce": In this mode, sending MTAs MUST NOT deliver the 2. "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.
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
checking for the presence of an updated policy at the Policy Domain. checking for the presence of an updated policy at the Policy Domain.
(In all cases, MTAs SHOULD treat such failures as transient errors (In all cases, MTAs SHOULD treat such failures as transient errors
and retry delivery later.) This allows implementing domains to and retry delivery later.) This allows implementing domains to
skipping to change at page 10, line 38 skipping to change at page 11, line 49
updating the TXT record; this ordering avoids the risk that senders, updating the TXT record; this ordering avoids the risk that senders,
seeing a new TXT record, mistakenly cache the old policy from HTTPS. seeing a new TXT record, mistakenly cache the old policy from HTTPS.
7. IANA Considerations 7. IANA Considerations
7.1. Well-Known URIs Registry 7.1. Well-Known URIs Registry
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.txt Change Controller: IETF
7.2. MTA-STS TXT Record Fields 7.2. MTA-STS TXT Record Fields
IANA is requested to create a new registry titled "MTA-STS TXT Record IANA is requested to create a new registry titled "MTA-STS TXT Record
Fields". The initial entries in the registry are: Fields". The initial entries in the registry are:
+------------+--------------------+------------------------+ +------------+--------------------+------------------------+
| Field Name | Description | Reference | | Field Name | Description | Reference |
+------------+--------------------+------------------------+ +------------+--------------------+------------------------+
| v | Record version | Section 3.1 of RFC XXX | | v | Record version | Section 3.1 of RFC XXX |
skipping to change at page 14, line 23 skipping to change at page 15, line 36
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.
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 JSON served as the response body at [1] MTA-STS Policy file served as the response body at [1]
{ version: STSv1
"version": "STSv1", mode: report
"mode": "report", mx: mx1.example.com
"mx": ["mx1.example.com", "mx2.example.com"], mx: mx2.example.com
"max_age": 12345678 mx: mx.backup-example.com
} max_age: 12345678
11. Appendix 2: Message delivery pseudocode 11. Appendix 2: 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.
While this pseudocode implementation suggests synchronous policy While this pseudocode implementation suggests synchronous policy
retrieval in the delivery path, in a working implementation that may retrieval in the delivery path, in a working implementation that may
be undesirable, and we expect some implementors to instead prefer a be undesirable, and we expect some implementors to instead prefer a
background fetch that does not block delivery if no cached policy is background fetch that does not block delivery if no cached policy is
skipping to change at page 17, line 19 skipping to change at page 18, line 29
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, DOI 10 Certificate Status Protocol - OCSP", RFC 2560, DOI 10
.17487/RFC2560, June 1999, .17487/RFC2560, June 1999,
<http://www.rfc-editor.org/info/rfc2560>. <http://www.rfc-editor.org/info/rfc2560>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/
RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>.
[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, <http://www.rfc-editor.org/info/rfc3207>. February 2002, <http://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,
<http://www.rfc-editor.org/info/rfc3492>. <http://www.rfc-editor.org/info/rfc3492>.
[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", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, DOI 10.17487/RFC4033, March 2005, 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[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,
<http://www.rfc-editor.org/info/rfc5280>. <http://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,
<http://www.rfc-editor.org/info/rfc5321>. <http://www.rfc-editor.org/info/rfc5321>.
skipping to change at page 18, line 17 skipping to change at page 19, line 32
RFC5891, August 2010, RFC5891, August 2010,
<http://www.rfc-editor.org/info/rfc5891>. <http://www.rfc-editor.org/info/rfc5891>.
[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, <http://www.rfc-editor.org/info/rfc6125>. 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 7405, DOI 10.17487/RFC7405, December 2014,
2014, <http://www.rfc-editor.org/info/rfc7159>. <http://www.rfc-editor.org/info/rfc7405>.
[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, DOI 10 (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10
.17487/RFC7672, October 2015, .17487/RFC7672, October 2015,
<http://www.rfc-editor.org/info/rfc7672>. <http://www.rfc-editor.org/info/rfc7672>.
12.2. URIs 12.2. URIs
[1] https://mta-sts.example.com/.well-known/mta-sts.json: [1] https://mta-sts.example.com/.well-known/mta-sts.txt:
Authors' Addresses Authors' Addresses
Daniel Margolis Daniel Margolis
Google, Inc Google, Inc
Email: dmargolis (at) google.com Email: dmargolis (at) google.com
Mark Risher Mark Risher
Google, Inc Google, Inc
Email: risher (at) google (dot com) Email: risher (at) google (dot com)
Binu Ramakrishnan Binu Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
Email: rbinu (at) yahoo-inc (dot com) Email: rbinu (at) yahoo-inc (dot com)
Alexander Brotman Alexander Brotman
Comcast, Inc Comcast, Inc
Email: alex_brotman (at) comcast.com Email: alex_brotman (at) comcast.com
Janet Jones Janet Jones
Microsoft, Inc Microsoft, Inc
Email: janet.jones (at) microsoft (dot com) Email: janet.jones (at) microsoft (dot com)
 End of changes. 27 change blocks. 
85 lines changed or deleted 125 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/