< draft-ietf-dane-smtp-with-dane-11.txt   draft-ietf-dane-smtp-with-dane-12.txt >
DANE V. Dukhovni DANE V. Dukhovni
Internet-Draft Two Sigma Internet-Draft Two Sigma
Intended status: Standards Track W. Hardaker Intended status: Standards Track W. Hardaker
Expires: February 3, 2015 Parsons Expires: February 18, 2015 Parsons
August 2, 2014 August 17, 2014
SMTP security via opportunistic DANE TLS SMTP security via opportunistic DANE TLS
draft-ietf-dane-smtp-with-dane-11 draft-ietf-dane-smtp-with-dane-12
Abstract Abstract
This memo describes a downgrade-resistant protocol for SMTP transport This memo describes a downgrade-resistant protocol for SMTP transport
security between Mail Transfer Agents (MTAs) based on the DNS-Based security between Mail Transfer Agents (MTAs) based on the DNS-Based
Authentication of Named Entities (DANE) TLSA DNS record. Adoption of Authentication of Named Entities (DANE) TLSA DNS record. Adoption of
this protocol enables an incremental transition of the Internet email this protocol enables an incremental transition of the Internet email
backbone to one using encrypted and authenticated Transport Layer backbone to one using encrypted and authenticated Transport Layer
Security (TLS). Security (TLS).
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 February 3, 2015. This Internet-Draft will expire on February 18, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 37 skipping to change at page 2, line 37
3.1. TLSA certificate usages . . . . . . . . . . . . . . . . . 19 3.1. TLSA certificate usages . . . . . . . . . . . . . . . . . 19
3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 21 3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 21
3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 22 3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 22
3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 23 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 23
3.2. Certificate matching . . . . . . . . . . . . . . . . . . 24 3.2. Certificate matching . . . . . . . . . . . . . . . . . . 24
3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 24 3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 24
3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 24 3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 24
3.2.3. Reference identifier matching . . . . . . . . . . . . 25 3.2.3. Reference identifier matching . . . . . . . . . . . . 25
4. Server key management . . . . . . . . . . . . . . . . . . . . 26 4. Server key management . . . . . . . . . . . . . . . . . . . . 26
5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26 5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26
6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 28 6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 27
7. Note on DANE for Message User Agents . . . . . . . . . . . . 29 7. Note on DANE for Message User Agents . . . . . . . . . . . . 27
8. Interoperability considerations . . . . . . . . . . . . . . . 29 8. Interoperability considerations . . . . . . . . . . . . . . . 28
8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 30 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 28
9. Operational Considerations . . . . . . . . . . . . . . . . . 30 9. Operational Considerations . . . . . . . . . . . . . . . . . 29
9.1. Client Operational Considerations . . . . . . . . . . . . 30 9.1. Client Operational Considerations . . . . . . . . . . . . 29
9.2. Publisher Operational Considerations . . . . . . . . . . 31 9.2. Publisher Operational Considerations . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . . 33 13.1. Normative References . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This memo specifies a new connection security model for Message This memo specifies a new connection security model for Message
Transfer Agents (MTAs). This model is motivated by key features of Transfer Agents (MTAs). This model is motivated by key features of
inter-domain SMTP delivery, in particular the fact that the inter-domain SMTP delivery, in particular the fact that the
destination server is selected indirectly via DNS Mail Exchange (MX) destination server is selected indirectly via DNS Mail Exchange (MX)
records and that neither email addresses nor MX hostnames signal a records and that neither email addresses nor MX hostnames signal a
requirement for either secure or cleartext transport. Therefore, requirement for either secure or cleartext transport. Therefore,
aside from a few manually configured exceptions, SMTP transport aside from a few manually configured exceptions, SMTP transport
skipping to change at page 9, line 52 skipping to change at page 9, line 52
To avoid further confusion, the adjective "anchorless" will be used To avoid further confusion, the adjective "anchorless" will be used
below to refer to domains or RRsets that are "indeterminate" in the below to refer to domains or RRsets that are "indeterminate" in the
[RFC4033] sense, and the term "indeterminate" will be used [RFC4033] sense, and the term "indeterminate" will be used
exclusively in the sense of [RFC4035]. exclusively in the sense of [RFC4035].
SMTP clients following this specification SHOULD NOT distinguish SMTP clients following this specification SHOULD NOT distinguish
between "insecure" and "anchorless" DNS responses. Both "insecure" between "insecure" and "anchorless" DNS responses. Both "insecure"
and "anchorless" RRsets MUST be handled identically: in either case and "anchorless" RRsets MUST be handled identically: in either case
unvalidated data for the query domain is all that is and can be unvalidated data for the query domain is all that is and can be
available, and authentication using the data is impossible. In what available, and authentication using the data is impossible. In what
follows, the term "insecure" will also includes the case of follows, the term "insecure" will also include the case of
"anchorless" domains that lie in a portion of the DNS tree for which "anchorless" domains that lie in a portion of the DNS tree for which
there is no applicable trust anchor. With the DNS root zone signed, there is no applicable trust anchor. With the DNS root zone signed,
we expect that validating resolvers used by Internet-facing MTAs will we expect that validating resolvers used by Internet-facing MTAs will
be configured with trust anchor data for the root zone, and that be configured with trust anchor data for the root zone, and that
therefore "anchorless" domains should be rare in practice. therefore "anchorless" domains should be rare in practice.
As noted in section 4.3 of [RFC4035], a security-aware DNS resolver As noted in section 4.3 of [RFC4035], a security-aware DNS resolver
MUST be able to determine whether a given non-error DNS response is MUST be able to determine whether a given non-error DNS response is
"secure", "insecure", "bogus" or "indeterminate". It is expected "secure", "insecure", "bogus" or "indeterminate". It is expected
that most security-aware stub resolvers will not signal an that most security-aware stub resolvers will not signal an
skipping to change at page 14, line 13 skipping to change at page 14, line 13
for some destinations. We will call such a configuration "mandatory for some destinations. We will call such a configuration "mandatory
DANE TLS". With mandatory DANE TLS, delivery proceeds only when DANE TLS". With mandatory DANE TLS, delivery proceeds only when
"secure" TLSA records are used to establish an encrypted and "secure" TLSA records are used to establish an encrypted and
authenticated TLS channel with the SMTP server. authenticated TLS channel with the SMTP server.
When the original next-hop destination is an address literal, rather When the original next-hop destination is an address literal, rather
than a DNS domain, DANE TLS does not apply. Delivery proceeds using than a DNS domain, DANE TLS does not apply. Delivery proceeds using
any relevant security policy configured by the MTA administrator. any relevant security policy configured by the MTA administrator.
Similarly, when an MX RRset incorrectly lists a network address in Similarly, when an MX RRset incorrectly lists a network address in
lieu of an MX hostname, if an MTA chooses to connect to the network lieu of an MX hostname, if an MTA chooses to connect to the network
address in the non-conformat MX record, DANE TLSA does not apply for address in the non-conformant MX record, DANE TLSA does not apply for
such a connection. such a connection.
In the subsections that follow we explain how to locate the SMTP In the subsections that follow we explain how to locate the SMTP
servers and the associated TLSA records for a given next-hop servers and the associated TLSA records for a given next-hop
destination domain. We also explain which name or names are to be destination domain. We also explain which name or names are to be
used in identity checks of the SMTP server certificate. used in identity checks of the SMTP server certificate.
2.2.1. MX resolution 2.2.1. MX resolution
In this section we consider next-hop domains that are subject to MX In this section we consider next-hop domains that are subject to MX
skipping to change at page 26, line 40 skipping to change at page 26, line 40
RRset to age out of DNS caches, the new trust anchor can start RRset to age out of DNS caches, the new trust anchor can start
issuing new server certificates. Once all certificates issued under issuing new server certificates. Once all certificates issued under
the previous trust anchor have expired, its associated RRs can be the previous trust anchor have expired, its associated RRs can be
removed from the TLSA RRset. removed from the TLSA RRset.
In the DANE-TA(2) key management model server operators do not In the DANE-TA(2) key management model server operators do not
generally need to update DNS TLSA records after initially creating a generally need to update DNS TLSA records after initially creating a
CNAME record that references the centrally operated DANE-TA(2) RRset. CNAME record that references the centrally operated DANE-TA(2) RRset.
If a particular server's key is compromised, its TLSA CNAME SHOULD be If a particular server's key is compromised, its TLSA CNAME SHOULD be
replaced with a DANE-EE(3) association until the certificate for the replaced with a DANE-EE(3) association until the certificate for the
compromised key expires, at which point it can return to using CNAME compromised key expires, at which point it can return to using a
record. If the central trust anchor is compromised, all servers need CNAME record. If the central trust anchor is compromised, all
to be issued new keys by a new TA, and a shared DANE-TA(2) TLSA RRset servers need to be issued new keys by a new TA, and an updated DANE-
needs to be published containing just the new TA. SMTP servers TA(2) TLSA RRset needs to be published containing just the new TA.
cannot expect broad SMTP client CRL or OCSP support.
5. Digest algorithm agility SMTP servers cannot expect broad CRL or OCSP support from SMTP
clients. As outlined above, with DANE, compromised server or trust
anchor keys can be "revoked" by removing them from the DNS without
the need for client-side support for OCSP or CRLs.
5. Digest algorithm agility
While [RFC6698] specifies multiple digest algorithms, it does not While [RFC6698] specifies multiple digest algorithms, it does not
specify a protocol by which the SMTP client and TLSA record publisher specify a protocol by which the SMTP client and TLSA record publisher
can agree on the strongest shared algorithm. Such a protocol would can agree on the strongest shared algorithm. Such a protocol would
allow the client and server to avoid exposure to any deprecated allow the client and server to avoid exposure to any deprecated
weaker algorithms that are published for compatibility with less weaker algorithms that are published for compatibility with less
capable clients, but should be ignored when possible. We specify capable clients, but should be ignored when possible. Such a
such a protocol below. protocol is specified in [I-D.ietf-dane-ops]. SMTP clients and
servers that implement this specification MUST comply with the
Suppose that a DANE TLS client authenticating a TLS server considers requirements outlined under "Digest Algorithm Agility" in
digest algorithm "BetterAlg" stronger than digest algorithm [I-D.ietf-dane-ops].
"WorseAlg". Suppose further that a server's TLSA RRset contains some
records with "BetterAlg" as the digest algorithm. Finally, suppose
that for every raw public key or certificate object that is included
in the server's TLSA RRset in digest form, whenever that object
appears with algorithm "WorseAlg" with some usage and selector it
also appears with algorithm "BetterAlg" with the same usage and
selector. In that case our client can safely ignore TLSA records
with the weaker algorithm "WorseAlg", because it suffices to check
the records with the stronger algorithm "BetterAlg".
Server operators MUST ensure that for any given usage and selector,
each object (certificate or public key), for which a digest
association exists in the TLSA RRset, is published with the SAME SET
of digest algorithms as all other objects that published with that
usage and selector. In other words, for each usage and selector, the
records with non-zero matching types will correspond to on a cross-
product of a set of underlying objects and a fixed set of digest
algorithms that apply uniformly to all the objects.
To achieve digest algorithm agility, all published TLSA RRsets for
use with opportunistic DANE TLS for SMTP MUST conform to the above
requirements. Then, for each combination of usage and selector, SMTP
clients can simply ignore all digest records except those that employ
the strongest digest algorithm. The ordering of digest algorithms by
strength is not specified in advance, it is entirely up to the SMTP
client. SMTP client implementations SHOULD make the digest algorithm
preference order configurable. Only the future will tell which
algorithms might be weakened by new attacks and when.
Note, TLSA records with a matching type of Full(0), that publish the
full value of a certificate or public key object, play no role in
digest algorithm agility. They neither trump the processing of
records that employ digests, nor are they ignored in the presence of
any records with a digest (i.e. non-zero) matching type.
SMTP clients SHOULD use digest algorithm agility when processing the
DANE TLSA records of an SMTP server. Algorithm agility is to be
applied after first discarding any unusable or malformed records
(unsupported digest algorithm, or incorrect digest length). Thus,
for each usage and selector, the client SHOULD process only any
usable records with a matching type of Full(0) and the usable records
whose digest algorithm is believed to be the strongest among usable
records with the given usage and selector.
The main impact of this requirement is on key rotation, when the TLSA
RRset is pre-populated with digests of new certificates or public
keys, before these replace or augment their predecessors. Were the
newly introduced RRs to include previously unused digest algorithms,
clients that employ this protocol could potentially ignore all the
digests corresponding to the current keys or certificates, causing
connectivity issues until the new keys or certificates are deployed.
Similarly, publishing new records with fewer digests could cause
problems for clients using cached TLSA RRsets that list both the old
and new objects once the new keys are deployed.
To avoid problems, server operators SHOULD apply the following
strategy:
o When changing the set of objects published via the TLSA RRset
(e.g. during key rotation), DO NOT change the set of digest
algorithms used; change just the list of objects.
o When changing the set of digest algorithms, change only the set of
algorithms, and generate a new RRset in which all the current
objects are re-published with the new set of digest algorithms.
After either of these two changes are made, the new TLSA RRset should
be left in place long enough that the older TLSA RRset can be flushed
from caches before making another change.
6. Mandatory TLS Security 6. Mandatory TLS Security
An MTA implementing this protocol may require a stronger security An MTA implementing this protocol may require a stronger security
assurance when sending email to selected destinations. The sending assurance when sending email to selected destinations. The sending
organization may need to send sensitive email and/or may have organization may need to send sensitive email and/or may have
regulatory obligations to protect its content. This protocol is not regulatory obligations to protect its content. This protocol is not
in conflict with such a requirement, and in fact can often simplify in conflict with such a requirement, and in fact can often simplify
authenticated delivery to such destinations. authenticated delivery to such destinations.
skipping to change at page 31, line 31 skipping to change at page 30, line 12
least one TLSA record when usable TLSA records are found for that least one TLSA record when usable TLSA records are found for that
server. server.
9.2. Publisher Operational Considerations 9.2. Publisher Operational Considerations
SMTP servers that publish certificate usage DANE-TA(2) associations SMTP servers that publish certificate usage DANE-TA(2) associations
MUST include the TA certificate in their TLS server certificate MUST include the TA certificate in their TLS server certificate
chain, even when that TA certificate is a self-signed root chain, even when that TA certificate is a self-signed root
certificate. certificate.
TLSA Publishers MUST follow the digest agility guidelines in TLSA Publishers MUST follow the guidelines in the "TLSA Publisher
Section 5 and MUST make sure that all objects published in digest Requirements" section of [I-D.ietf-dane-ops].
form for a particular usage and selector are published with the same
set of digest algorithms.
TLSA Publishers should follow the TLSA publication size guidance TLSA Publishers SHOULD follow the TLSA publication size guidance
found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines". found in [I-D.ietf-dane-ops] under "DANE DNS Record Size Guidelines".
10. Security Considerations 10. Security Considerations
This protocol leverages DANE TLSA records to implement MITM resistant This protocol leverages DANE TLSA records to implement MITM resistant
opportunistic security ([I-D.dukhovni-opportunistic-security]) for opportunistic security ([I-D.dukhovni-opportunistic-security]) for
SMTP. For destination domains that sign their MX records and publish SMTP. For destination domains that sign their MX records and publish
signed TLSA records for their MX hostnames, this protocol allows signed TLSA records for their MX hostnames, this protocol allows
sending MTAs to securely discover both the availability of TLS and sending MTAs to securely discover both the availability of TLS and
how to authenticate the destination. how to authenticate the destination.
skipping to change at page 33, line 10 skipping to change at page 31, line 31
Thanks to Patrick Koetter, Perry Metzger and Nico Williams for Thanks to Patrick Koetter, Perry Metzger and Nico Williams for
valuable review comments. Thanks also to Wietse Venema who created valuable review comments. Thanks also to Wietse Venema who created
Postfix, and whose advice and feedback were essential to the Postfix, and whose advice and feedback were essential to the
development of the Postfix DANE implementation. development of the Postfix DANE implementation.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-dane-ops] [I-D.ietf-dane-ops]
Dukhovni, V. and W. Hardaker, "DANE TLSA implementation Dukhovni, V. and W. Hardaker, "Updates to and Operational
and operational guidance", draft-ietf-dane-ops-00 (work in Guidance for the DANE Protocol", draft-ietf-dane-ops-06
progress), October 2013. (work in progress), August 2014.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, February 2002. Transport Layer Security", RFC 3207, February 2002.
skipping to change at page 34, line 34 skipping to change at page 33, line 4
[X.690] International Telecommunications Union, "Recommendation [X.690] International Telecommunications Union, "Recommendation
ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information
technology - ASN.1 encoding rules: Specification of Basic technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", July 2002. Distinguished Encoding Rules (DER)", July 2002.
13.2. Informative References 13.2. Informative References
[I-D.dukhovni-opportunistic-security] [I-D.dukhovni-opportunistic-security]
Dukhovni, V., "Opportunistic Security: some protection Dukhovni, V., "Opportunistic Security: Some Protection
most of the time", draft-dukhovni-opportunistic- Most of the Time", draft-dukhovni-opportunistic-
security-01 (work in progress), July 2014. security-03 (work in progress), August 2014.
[I-D.ietf-dane-srv] [I-D.ietf-dane-srv]
Finch, T., "Using DNS-Based Authentication of Named Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
Entities (DANE) TLSA records with SRV and MX records.", Based Authentication of Named Entities (DANE) TLSA Records
draft-ietf-dane-srv-02 (work in progress), February 2013. with SRV Records", draft-ietf-dane-srv-07 (work in
progress), July 2014.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
2009. 2009.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, November 2011. STD 72, RFC 6409, November 2011.
Authors' Addresses Authors' Addresses
Viktor Dukhovni Viktor Dukhovni
Two Sigma Two Sigma
Email: ietf-dane@dukhovni.org Email: ietf-dane@dukhovni.org
Wes Hardaker Wes Hardaker
Parsons Parsons
P.O. Box 382 P.O. Box 382
Davis, CA 95617 Davis, CA 95617
US US
 End of changes. 16 change blocks. 
116 lines changed or deleted 50 lines changed or added

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