DANE V. Dukhovni
Internet-Draft Two Sigma
Intended status: Standards Track W. Hardaker
-Expires: February 3, 2015 Parsons
- August 2, 2014
+Expires: February 18, 2015 Parsons
+ August 17, 2014
SMTP security via opportunistic DANE TLS
- draft-ietf-dane-smtp-with-dane-11
+ draft-ietf-dane-smtp-with-dane-12
Abstract
time. It is inappropriate to use Internet-Drafts as reference
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
-Dukhovni & Hardaker Expires February 3, 2015 [Page 1]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 1]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
3.2.3. Reference identifier matching . . . . . . . . . . . . 25
4. Server key management . . . . . . . . . . . . . . . . . . . . 26
5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26
- 6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 28
- 7. Note on DANE for Message User Agents . . . . . . . . . . . . 29
- 8. Interoperability considerations . . . . . . . . . . . . . . . 29
- 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 29
- 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 30
- 9. Operational Considerations . . . . . . . . . . . . . . . . . 30
- 9.1. Client Operational Considerations . . . . . . . . . . . . 30
- 9.2. Publisher Operational Considerations . . . . . . . . . . 31
- 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
- 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32
- 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
- 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
- 13.1. Normative References . . . . . . . . . . . . . . . . . . 33
- 13.2. Informative References . . . . . . . . . . . . . . . . . 34
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
-
-
-
-Dukhovni & Hardaker Expires February 3, 2015 [Page 2]
+ 6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 27
+ 7. Note on DANE for Message User Agents . . . . . . . . . . . . 27
+ 8. Interoperability considerations . . . . . . . . . . . . . . . 28
+ 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 28
+ 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 28
+ 9. Operational Considerations . . . . . . . . . . . . . . . . . 29
+ 9.1. Client Operational Considerations . . . . . . . . . . . . 29
+ 9.2. Publisher Operational Considerations . . . . . . . . . . 30
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
+ 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
+ 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
+ 13.1. Normative References . . . . . . . . . . . . . . . . . . 31
+ 13.2. Informative References . . . . . . . . . . . . . . . . . 32
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 2]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 3]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 3]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 4]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 4]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 5]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 5]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 6]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 6]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 7]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 7]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 8]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 8]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
and "anchorless" RRsets MUST be handled identically: in either case
unvalidated data for the query domain is all that is and can be
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
-Dukhovni & Hardaker Expires February 3, 2015 [Page 9]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 9]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 10]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 10]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 11]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 11]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 12]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 12]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 13]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 13]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
any relevant security policy configured by the MTA administrator.
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
- 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.
In the subsections that follow we explain how to locate the SMTP
-Dukhovni & Hardaker Expires February 3, 2015 [Page 14]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 14]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 15]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 15]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 16]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 16]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 17]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 17]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 18]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 18]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 19]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 19]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 20]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 20]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 21]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 21]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 22]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 22]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 23]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 23]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 24]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 24]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-Dukhovni & Hardaker Expires February 3, 2015 [Page 25]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 25]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
CNAME record that references the centrally operated DANE-TA(2) RRset.
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
- compromised key expires, at which point it can return to using CNAME
- record. If the central trust anchor is compromised, all servers need
- to be issued new keys by a new TA, and a shared DANE-TA(2) TLSA RRset
- needs to be published containing just the new TA. SMTP servers
- cannot expect broad SMTP client CRL or OCSP support.
+ compromised key expires, at which point it can return to using a
+ CNAME record. If the central trust anchor is compromised, all
+ servers need to be issued new keys by a new TA, and an updated DANE-
+ TA(2) TLSA RRset needs to be published containing just the new TA.
+
+ 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
- specify a protocol by which the SMTP client and TLSA record publisher
- can agree on the strongest shared algorithm. Such a protocol would
- allow the client and server to avoid exposure to any deprecated
-Dukhovni & Hardaker Expires February 3, 2015 [Page 26]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 26]
\f
Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+ While [RFC6698] specifies multiple digest algorithms, it does not
+ specify a protocol by which the SMTP client and TLSA record publisher
+ can agree on the strongest shared algorithm. Such a protocol would
+ allow the client and server to avoid exposure to any deprecated
weaker algorithms that are published for compatibility with less
- capable clients, but should be ignored when possible. We specify
- such a protocol below.
-
- Suppose that a DANE TLS client authenticating a TLS server considers
- digest algorithm "BetterAlg" stronger than digest algorithm
- "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.
-
-
-
-
-
-
-
-
-
-
-
-Dukhovni & Hardaker Expires February 3, 2015 [Page 27]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-
-
- 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.
+ capable clients, but should be ignored when possible. Such a
+ protocol is specified in [I-D.ietf-dane-ops]. SMTP clients and
+ servers that implement this specification MUST comply with the
+ requirements outlined under "Digest Algorithm Agility" in
+ [I-D.ietf-dane-ops].
6. Mandatory TLS Security
MX hostnames, a sending MTA can be configured to use the receiving
domains's DANE TLSA records to authenticate the corresponding SMTP
server. Authentication via DANE TLSA records is easier to manage, as
-
-
-
-Dukhovni & Hardaker Expires February 3, 2015 [Page 28]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-
-
changes in the receiver's expected certificate properties are made on
the receiver end and don't require manually communicated
configuration changes. With mandatory DANE TLS, when no usable TLSA
replaced by corresponding DNS Service (SRV) records
[I-D.ietf-dane-srv].
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 27]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
However, until MUAs begin to adopt the dynamic configuration
mechanisms of [RFC6186] they are adequately served by more
traditional static TLS security policies. Specification of DANE TLS
Each SMTP server MUST present a certificate chain (see [RFC5246]
Section 7.4.2) that matches at least one of the TLSA records. The
server MAY rely on SNI to determine which certificate chain to
-
-
-
-Dukhovni & Hardaker Expires February 3, 2015 [Page 29]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-
-
present to the client. Clients that don't send SNI information may
not see the expected certificate chain.
offer to negotiate a typical set of non-anonymous cipher suites
required for interoperability with such servers. An SMTP client
employing pre-DANE opportunistic TLS MAY in addition include one or
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 28]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
more anonymous TLS cipher suites in its TLS HELLO. SMTP servers,
that need to interoperate with opportunistic TLS clients SHOULD be
prepared to interoperate with such clients by either always selecting
failure to deliver time-sensitive email. The sending MTA
administrator may have to choose between letting email queue until
the error is resolved and disabling opportunistic or mandatory DANE
-
-
-
-Dukhovni & Hardaker Expires February 3, 2015 [Page 30]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-
-
TLS for one or more destinations. The choice to disable DANE TLS
security should not be made lightly. Every reasonable effort should
be made to determine that problems with mail delivery are the result
least one TLSA record when usable TLSA records are found for that
server.
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 29]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
9.2. Publisher Operational Considerations
SMTP servers that publish certificate usage DANE-TA(2) associations
chain, even when that TA certificate is a self-signed root
certificate.
- TLSA Publishers MUST follow the digest agility guidelines in
- Section 5 and MUST make sure that all objects published in digest
- form for a particular usage and selector are published with the same
- set of digest algorithms.
+ TLSA Publishers MUST follow the guidelines in the "TLSA Publisher
+ Requirements" section of [I-D.ietf-dane-ops].
- TLSA Publishers should follow the TLSA publication size guidance
- found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines".
+ TLSA Publishers SHOULD follow the TLSA publication size guidance
+ found in [I-D.ietf-dane-ops] under "DANE DNS Record Size Guidelines".
10. Security Considerations
sending MTAs to securely discover both the availability of TLS and
how to authenticate the destination.
-
-
-
-
-
-
-
-Dukhovni & Hardaker Expires February 3, 2015 [Page 31]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-
-
This protocol does not aim to secure all SMTP traffic, as that is not
practical until DNSSEC and DANE adoption are universal. The
incremental deployment provided by following this specification is a
specification that indicate when it is appropriate to initiate a non-
authenticated connection or cleartext connection to a SMTP server.
Specifically, in order to prevent downgrade attacks on this protocol,
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 30]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
implementation must not initiate a connection when this specification
indicates a particular SMTP server must be considered unreachable.
Postfix, and whose advice and feedback were essential to the
development of the Postfix DANE implementation.
-
-
-
-Dukhovni & Hardaker Expires February 3, 2015 [Page 32]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-
-
13. References
13.1. Normative References
[I-D.ietf-dane-ops]
- Dukhovni, V. and W. Hardaker, "DANE TLSA implementation
- and operational guidance", draft-ietf-dane-ops-00 (work in
- progress), October 2013.
+ Dukhovni, V. and W. Hardaker, "Updates to and Operational
+ Guidance for the DANE Protocol", draft-ietf-dane-ops-06
+ (work in progress), August 2014.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 31]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011.
-
-
-
-
-
-
-
-Dukhovni & Hardaker Expires February 3, 2015 [Page 33]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS August 2014
-
-
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
13.2. Informative References
[I-D.dukhovni-opportunistic-security]
- Dukhovni, V., "Opportunistic Security: some protection
- most of the time", draft-dukhovni-opportunistic-
- security-01 (work in progress), July 2014.
-
- [I-D.ietf-dane-srv]
- Finch, T., "Using DNS-Based Authentication of Named
- Entities (DANE) TLSA records with SRV and MX records.",
- draft-ietf-dane-srv-02 (work in progress), February 2013.
- [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
- 2009.
- [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
- STD 72, RFC 6409, November 2011.
-Authors' Addresses
+Dukhovni & Hardaker Expires February 18, 2015 [Page 32]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+ Dukhovni, V., "Opportunistic Security: Some Protection
+ Most of the Time", draft-dukhovni-opportunistic-
+ security-03 (work in progress), August 2014.
+ [I-D.ietf-dane-srv]
+ Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
+ Based Authentication of Named Entities (DANE) TLSA Records
+ with SRV Records", draft-ietf-dane-srv-07 (work in
+ progress), July 2014.
+ [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
+ 2009.
-Dukhovni & Hardaker Expires February 3, 2015 [Page 34]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+ [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
+ STD 72, RFC 6409, November 2011.
+Authors' Addresses
Viktor Dukhovni
Two Sigma
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dukhovni & Hardaker Expires February 3, 2015 [Page 35]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 33]
git://git.exim.org / users / heiko / exim.git / blobdiff