draft-ietf-uta-mta-sts-00.txt   draft-ietf-uta-mta-sts-01.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 N. Lidzborski Intended status: Standards Track N. Lidzborski
Expires: November 13, 2016 W. Chuang Expires: January 9, 2017 W. Chuang
B. Long B. Long
Google, Inc Google, Inc
B. Ramakrishnan B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
A. Brotman A. Brotman
Comcast, Inc Comcast, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
F. Martin F. Martin
LinkedIn LinkedIn
K. Umbach K. Umbach
M. Laber M. Laber
1&1 Mail & Media Development & Technology GmbH 1&1 Mail & Media Development & Technology GmbH
May 13, 2016 July 8, 2016
SMTP MTA Strict Transport Security SMTP MTA Strict Transport Security
draft-ietf-uta-mta-sts-00 draft-ietf-uta-mta-sts-01
Abstract Abstract
SMTP MTA-STS is a mechanism enabling mail service providers to SMTP MTA-STS is a mechanism enabling mail service providers to
declare their ability to receive TLS-secured connections, to declare declare their ability to receive TLS-secured connections, to declare
particular methods for certificate validation, and to request that particular methods for certificate validation, and to request that
sending SMTP servers report upon and/or refuse to deliver messages sending SMTP servers report upon and/or refuse to deliver messages
that cannot be delivered securely. that cannot be delivered securely.
Status of This Memo Status of This Memo
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 October 20, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 5, line 23 skipping to change at page 5, line 23
o Security: DANE offers an advantage against policy-lookup DoS o Security: DANE offers an advantage against policy-lookup DoS
attacks; that is, while a DNSSEC-signed NXDOMAIN response to a attacks; that is, while a DNSSEC-signed NXDOMAIN response to a
DANE lookup authoritatively indicates the lack of a DANE record, DANE lookup authoritatively indicates the lack of a DANE record,
such an option to authenticate policy non-existence does not exist such an option to authenticate policy non-existence does not exist
when looking up a policy over plain DNS. when looking up a policy over plain DNS.
3. Policy Semantics 3. Policy Semantics
SMTP MTA-STS policies are distributed via a "well known" HTTPS SMTP MTA-STS policies are distributed via a "well known" HTTPS
endpoint in the Policy Domain. endpoint in the Policy Domain. A corresponding TXT record in the DNS
alerts sending MTAs to the presence of a policy file.
(Future implementations may move to alternate methods of policy (Future implementations may move to alternate methods of policy
discovery or distribution. See the section _Future_ _Work_ for more discovery or distribution. See the section _Future_ _Work_ for more
discussion.) discussion.)
Policies MUST specify the following fields in JSON [RFC4627] format: *The MTA-STS TXT record MUST specify the following fields:*
o "version": (plain-text, required). Currently only "STS1" is o "v": (plain-text, required). Currently only "STSv1" is supported.
o "id": (plain-text, required). A short string used to track policy
updates. This string MUST uniquely identify a given instance of a
policy, such that senders can determine when the policy has been
updated by comparing to the "id" of a previously seen policy, and
must also match the "policy_id" value of the distributed policy.
A lenient parser SHOULD accept a policy file implementing a superset
of this specification, in which case unknown values SHALL be ignored.
*Policies MUST specify the following fields in JSON* [RFC4627]
*format:*
o "version": (plain-text, required). Currently only "STSv1" is
supported. supported.
o "mode": (plain-text, required). If "enforce", the receiving MTA o "mode": (plain-text, required). If "enforce", the receiving MTA
requests that messages be delivered only if they conform to the requests that messages be delivered only if they conform to the
STS policy. If "report" the receiving MTA requests that failure STS policy. If "report" the receiving MTA requests that failure
reports be delivered, as specified by the "rua" parameter. reports be delivered, as specified by the "rua" parameter.
o "mx": MX patterns (list of plain-text MX match patterns, o "mx": MX patterns (list of plain-text MX match patterns,
required). One or more comma-separated patterns matching the required). One or more comma-separated patterns matching the
expected MX for this domain. For example, "["*.example.com", expected MX for this domain. For example, "["*.example.com",
"*.example.net"]" indicates that mail for this domain might be "*.example.net"]" indicates that mail for this domain might be
handled by any MX whose hostname is a subdomain of "example.com" handled by any MX whose hostname is a subdomain of "example.com"
or "example.net." The semantics for these patterns should be the or "example.net". The semantics for these patterns should be the
ones found in the "Checking of Wildcard Certificates" rules in ones found in the "Checking of Wildcard Certificates" rules in
Section 6.4.3 of [RFC6125]. Section 6.4.3 of [RFC6125].
o "max_age": Max lifetime of the policy (plain-text integer o "max_age": Max lifetime of the policy (plain-text integer
seconds). Well-behaved clients SHOULD cache a policy for up to seconds). Well-behaved clients SHOULD cache a policy for up to
this value from last policy fetch time. this value from last policy fetch time.
o "policy_id": A short string used to track policy updates. This o "policy_id": A short string used to track policy updates. This
string MUST uniquely identify a given instance of a policy, such string MUST uniquely identify a given instance of a policy, such
that senders can determine when the policy has been updated by that senders can determine when the policy has been updated by
skipping to change at page 6, line 21 skipping to change at page 6, line 36
implementing a superset of this specification, in which case unknown implementing a superset of this specification, in which case unknown
values SHALL be ignored. values SHALL be ignored.
3.1. Formal Definition 3.1. Formal Definition
3.1.1. TXT Record 3.1.1. TXT Record
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: [RFC5234], is as follows:
sts-version = "v" *WSP "=" *WSP %x53 %x54 %x53 %x31 sts-text-record = sts-version *WSP %x3B *WSP sts-id
sts-id = "id" *WSP "=" *WSP 1*20VCHAR sts-version = "v" *WSP "=" *WSP %x53 %x54 ; "STSv1"
%x53 %x76 %x31
sts-id = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT)
3.1.2. SMTP MTA-STS Policy 3.1.2. SMTP MTA-STS Policy
The formal definition of the SMTP MTA-STS policy, using [RFC5234], is The formal definition of the SMTP MTA-STS policy, using [RFC5234], is
as follows: as follows:
sts-record = WSP %x7B WSP ; { left curly bracket sts-record = WSP %x7B WSP ; { left curly bracket
sts-element ; comma-separated sts-element ; comma-separated
[ ; list [ ; list
WSP %x2c WSP ; of WSP %x2c WSP ; of
sts-element ; sts-elements sts-element ; sts-elements
] ]
WSP %x7d WSP ; } right curly bracket WSP %x7d WSP ; } right curly bracket
= %x22 "max
sts-element = sts-version / sts-mode / sts-id / sts-mx / sts-max_age sts-element = sts-version / sts-mode / sts-id / sts-mx / sts-max_age
sts-version = %x22 "version" %x22 *WSP %x3a *WSP ; "version": sts-version = %x22 "version" %x22 *WSP %x3a *WSP ; "version":
%x22 %x53 %x54 %x53 %x31 ; "STS1" %x22 %x53 %x54 %x53 %x76 %x31 ; "STSv1"
sts-mode = %x22 "mode" %x22 *WSP %x3a *WSP ; "mode": sts-mode = %x22 "mode" %x22 *WSP %x3a *WSP ; "mode":
%x22 ("report" / "enforce") %x22 ; "report"/"enforce" %x22 ("report" / "enforce") %x22 ; "report"/"enforce"
sts-id = %x22 "policy_id" %x22 *WSP %x3a *WSP ; "policy_id": sts-id = %x22 "policy_id" %x22 *WSP %x3a *WSP ; "policy_id":
%x22 1*20VCHAR %x22 ; some chars %x22 1*32(ALPHA / DIGIT) %x22 ; some chars
sts-mx = %x22 "mx" $x22 *WSP %x3a *WSP ; "mx": sts-mx = %x22 "mx" $x22 *WSP %x3a *WSP ; "mx":
%x5B ; [ %x5B ; [
domain-match ; comma-separated list domain-match ; comma-separated list
[WSP %x2c domain-match WSP] ; of domain-matches [WSP %x2c domain-match WSP] ; of domain-matches
%x5B ; ] %x5B ; ]
sts-max_age = %x22 "max_age" %x22 $x3a *WSP ; "max_age": sts-max_age = %x22 "max_age" %x22 *WSP $x3a *WSP ; "max_age":
%x22 1*10DIGIT %x22$ ; some digits 1*10DIGIT ; some digits
domain-match = ["*."] 1*dtext *("." 1*dtext) domain-match = %x22 1*(dtext / "*") *("." ; wildcard or label
1*dtext) %x22 ; with 0+ more labels
dtext = %d30-39 / ; 0-9 dtext = ALPHA / DIGIT / %2D ; A-Z, a-z, 0-9, "-"
%d41-5A / ; a-z
%61-7A / ; A-Z
%2D ; "-"
A size limitation in a sts-uri, if provided, is interpreted as a A size limitation in a sts-uri, if provided, is interpreted as a
count of units followed by an OPTIONAL unit size ("k" for kilobytes, count of units followed by an OPTIONAL unit size ("k" for kilobytes,
"m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a "m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a
unit, the number is presumed to be a basic byte count. Note that the unit, the number is presumed to be a basic byte count. Note that the
units are considered to be powers of two; a kilobyte is 2^10, a units are considered to be powers of two; a kilobyte is 2^10, a
megabyte is 2^20, etc. megabyte is 2^20, etc.
3.2. Policy Expirations 3.2. Policy Expirations
skipping to change at page 8, line 40 skipping to change at page 8, line 38
attempt to fetch TXT records from the recipient domain's DNS zone attempt to fetch TXT records from the recipient domain's DNS zone
with the name "_mta_sts". A valid TXT record presence in with the name "_mta_sts". A valid TXT record presence in
"_mta_sts.example.com" indicates that the recipent domain supports "_mta_sts.example.com" indicates that the recipent domain supports
STS. To allow recipient domains to safely serve new policies, it is STS. To allow recipient domains to safely serve new policies, it is
important that senders are able to authenticate a new policy important that senders are able to authenticate a new policy
retrieved for a recipient domain. retrieved for a recipient domain.
Web PKI is the mechanism used for policy authentication. In this Web PKI is the mechanism used for policy authentication. In this
mechanism, the sender fetches a HTTPS resource (policy) from a host mechanism, the sender fetches a HTTPS resource (policy) from a host
at "policy.mta-sts" in the Policy Domain. The policy is served from at "policy.mta-sts" in the Policy Domain. The policy is served from
a "well known" URI: "https://policy.mta-sts.example.com/current". To a "well known" URI: "https://policy.mta-sts.example.com/.well-known/
consider the policy as valid, the "policy_id" field in the policy mta-sts/current". To consider the policy as valid, the "policy_id"
MUST match the "id" field in the DNS TXT record under "_mta_sts". field in the policy MUST match the "id" field in the DNS TXT record
under "_mta_sts".
When fetching a new policy or updating a policy, the new policy MUST When fetching a new policy or updating a policy, the new policy MUST
be fully authenticated (HTTPS certificate validation + peer be fully authenticated (HTTPS certificate validation + peer
verification) before use. A policy which has not ever been verification) before use. A policy which has not ever been
successfully authenticated MUST NOT be used to reject mail. successfully authenticated MUST NOT be used to reject mail.
3.4. Policy Validation 3.4. Policy Validation
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
and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP MTA- and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP MTA-
skipping to change at page 12, line 49 skipping to change at page 12, line 49
o Verify the validity of the certificates o Verify the validity of the certificates
o Determine how many messages would be affected by a strict policy o Determine how many messages would be affected by a strict policy
DNS STS policy indicator TXT record: DNS STS policy indicator TXT record:
_mta_sts IN TXT ( "v=STSv1; id=randomstr;" ) _mta_sts IN TXT ( "v=STSv1; id=randomstr;" )
STS policy served from HTTPS endpoint of the policy (recipient) STS policy served from HTTPS endpoint of the policy (recipient)
domain, and is authenticated using Web PKI mechanism. domain, and is authenticated using Web PKI mechanism. The policy is
fetched using HTTP GET method.
{ {
"version": "STS1", "version": "STSv1",
"mode": "report", "mode": "report",
"policy_id": "randomstr", "policy_id": "randomstr",
"mx": ["*.mail.example.com"], "mx": ["*.mail.example.com"],
"max_age": "123456" "max_age": 123456
} }
The policy is authenticated using Web PKI mechanism. The policy is authenticated using Web PKI mechanism.
10. Appendix 3: DEEP Registration Elements 10. Appendix 3: DEEP Registration Elements
Name: mx-mismatch Name: mx-mismatch
Description: This indicates that the MX resolved for the recipient domain Description: This indicates that the MX resolved for the recipient domain
did not match the MX constraint specified in the policy. did not match the MX constraint specified in the policy.
Intended Usage: COMMON Intended Usage: COMMON
skipping to change at page 15, line 7 skipping to change at page 15, line 7
Name: sender-does-not-support-validation-method Name: sender-does-not-support-validation-method
Description: This indicates the sending system can never validate using the Description: This indicates the sending system can never validate using the
requested validation mechanism. requested validation mechanism.
Intended Usage: COMMON Intended Usage: COMMON
Reference: RFC XXXX (this document once published) Reference: RFC XXXX (this document once published)
Submitter: Authors of this document Submitter: Authors of this document
Change Controller: IESG Change Controller: IESG
11. Normative References 11. Normative References
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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>.
[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",
4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, DOI 10 JavaScript Object Notation (JSON)", RFC 4627,
.17487/RFC4627, July 2006, DOI 10.17487/RFC4627, July 2006,
<http://www.rfc-editor.org/info/rfc4627>. <http://www.rfc-editor.org/info/rfc4627>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234,
RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[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>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://www.rfc-editor.org/info/rfc6962>. <http://www.rfc-editor.org/info/rfc6962>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <http://www.rfc-editor.org/info/rfc7469>. 2015, <http://www.rfc-editor.org/info/rfc7469>.
[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,
.17487/RFC7672, October 2015, DOI 10.17487/RFC7672, October 2015,
<http://www.rfc-editor.org/info/rfc7672>. <http://www.rfc-editor.org/info/rfc7672>.
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
 End of changes. 27 change blocks. 
44 lines changed or deleted 62 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/