DANE V. Dukhovni
Internet-Draft Two Sigma
Intended status: Standards Track W. Hardaker
-Expires: November 26, 2014 Parsons
- May 25, 2014
+Expires: February 18, 2015 Parsons
+ August 17, 2014
SMTP security via opportunistic DANE TLS
- draft-ietf-dane-smtp-with-dane-10
+ 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 November 26, 2014.
+ This Internet-Draft will expire on February 18, 2015.
Copyright Notice
-Dukhovni & Hardaker Expires November 26, 2014 [Page 1]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 1]
\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
the Trust Legal Provisions and are provided without warranty as
1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 6
1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 6
1.3.2. Insecure server name without DNSSEC . . . . . . . . . 7
- 1.3.3. Sender policy does not scale . . . . . . . . . . . . 7
+ 1.3.3. Sender policy does not scale . . . . . . . . . . . . 8
1.3.4. Too many certification authorities . . . . . . . . . 8
- 2. Identifying applicable TLSA records . . . . . . . . . . . . . 8
- 2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 8
- 2.1.1. DNS errors, bogus and indeterminate responses . . . . 8
+ 2. Identifying applicable TLSA records . . . . . . . . . . . . . 9
+ 2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 9
+ 2.1.1. DNS errors, bogus and indeterminate responses . . . . 9
2.1.2. DNS error handling . . . . . . . . . . . . . . . . . 11
- 2.1.3. Stub resolver considerations . . . . . . . . . . . . 11
- 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 12
- 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 13
+ 2.1.3. Stub resolver considerations . . . . . . . . . . . . 12
+ 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 13
+ 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 14
2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 15
2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 17
3. DANE authentication . . . . . . . . . . . . . . . . . . . . . 19
3.1. TLSA certificate usages . . . . . . . . . . . . . . . . . 19
- 3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 20
- 3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 21
- 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 22
- 3.2. Certificate matching . . . . . . . . . . . . . . . . . . 23
- 3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 23
- 3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 23
- 3.2.3. Reference identifier matching . . . . . . . . . . . . 24
- 4. Server key management . . . . . . . . . . . . . . . . . . . . 25
+ 3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 21
+ 3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 22
+ 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 23
+ 3.2. Certificate matching . . . . . . . . . . . . . . . . . . 24
+ 3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 24
+ 3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 24
+ 3.2.3. Reference identifier matching . . . . . . . . . . . . 25
+ 4. Server key management . . . . . . . . . . . . . . . . . . . . 26
5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26
6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 27
- 7. Note on DANE for Message User Agents . . . . . . . . . . . . 28
- 8. Interoperability considerations . . . . . . . . . . . . . . . 29
- 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 29
- 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 29
- 9. Operational Considerations . . . . . . . . . . . . . . . . . 30
- 9.1. Client Operational Considerations . . . . . . . . . . . . 30
+ 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 . . . . . . . . . . . . . . . . . . . 31
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
- 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
- 13.1. Normative References . . . . . . . . . . . . . . . . . . 32
- 13.2. Informative References . . . . . . . . . . . . . . . . . 33
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
+ 13.1. Normative References . . . . . . . . . . . . . . . . . . 31
+ 13.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
-Dukhovni & Hardaker Expires November 26, 2014 [Page 2]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 2]
\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1. Introduction
This specification uses the presence of DANE TLSA records to securely
signal TLS support and to publish the means by which SMTP clients can
successfully authenticate legitimate SMTP servers. This becomes
- "opportunistic DANE TLS" and is resistant to downgrade and MITM
- attacks. It enables an incremental transition of the email backbone
- to authenticated TLS delivery, with increased global protection as
- adoption increases.
+ "opportunistic DANE TLS" and is resistant to downgrade and man-in-
+ the-middle (MITM) attacks. It enables an incremental transition of
+ the email backbone to authenticated TLS delivery, with increased
+ global protection as adoption increases.
With opportunistic DANE TLS, traffic from SMTP clients to domains
that publish "usable" DANE TLSA records in accordance with this memo
-Dukhovni & Hardaker Expires November 26, 2014 [Page 3]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 3]
\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
secure, bogus, insecure, indeterminate: DNSSEC validation results,
Security-Aware Stub Resolver:
Capabilities of the stub resolver in use as defined in [RFC4033];
note that this specification requires the use of a Security-Aware
- Stub Resolver; Security-Oblivious stub-resolvers MUST NOT be used.
-
- opportunistic DANE TLS: Best-effort use of TLS, resistant to
- downgrade attacks for destinations with DNSSEC-validated TLSA
- records. When opportunistic DANE TLS is determined to be
- unavailable, clients should fall back to opportunistic TLS below.
- Opportunistic DANE TLS requires support for DNSSEC, DANE and
- STARTTLS on the client side and STARTTLS plus a DNSSEC published
- TLSA record on the server side.
+ Stub Resolver.
(pre-DANE) opportunistic TLS: Best-effort use of TLS that is
generally vulnerable to DNS forgery and STARTTLS downgrade
record indirection generally precludes authentication even when
TLS is available.
+ opportunistic DANE TLS: Best-effort use of TLS, resistant to
+ downgrade attacks for destinations with DNSSEC-validated TLSA
+ records. When opportunistic DANE TLS is determined to be
+ unavailable, clients should fall back to opportunistic TLS.
+ Opportunistic DANE TLS requires support for DNSSEC, DANE and
+ STARTTLS on the client side and STARTTLS plus a DNSSEC published
+ TLSA record on the server side.
+
reference identifier: (Special case of [RFC6125] definition). One
of the domain names associated by the SMTP client with the
destination SMTP server for performing name checks on the server
delayed delivery: Email delivery is a multi-hop store & forward
process. When an MTA is unable forward a message that may become
- deliverable later, the message is queued and delivery is retried
+ deliverable later the message is queued and delivery is retried
periodically. Some MTAs may be configured with a fallback next-
hop destination that handles messages that the MTA would otherwise
- queue and retry. In these cases, messages that would otherwise
- have to be delayed, may be sent to the fallback next-hop
- destination instead. The fallback destination may itself be
+ queue and retry. When a fallback next-hop is configured, messages
+ that would otherwise have to be delayed may be sent to the
+ fallback next-hop destination instead. The fallback destination
-Dukhovni & Hardaker Expires November 26, 2014 [Page 4]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 4]
\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
- subject to opportunistic or mandatory DANE TLS as though it were
- the original message destination.
+ may itself be subject to opportunistic or mandatory DANE TLS as
+ though it were the original message destination.
original next hop destination: The logical destination for mail
delivery. By default this is the domain portion of the recipient
-Dukhovni & Hardaker Expires November 26, 2014 [Page 5]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 5]
\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1.3. SMTP channel security
1.3.1. STARTTLS downgrade attack
The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop
- protocol in a multi-hop store & forward email delivery process. SMTP
- envelope recipient addresses are not transport addresses and are
- security-agnostic. Unlike the Hypertext Transfer Protocol (HTTP) and
- its corresponding secured version, HTTPS, where the use of TLS is
- signaled via the URI scheme, email recipient addresses do not
- directly signal transport security policy. Indeed, no such signaling
- could work well with SMTP since TLS encryption of SMTP protects email
- traffic on a hop-by-hop basis while email addresses could only
- express end-to-end policy.
+ protocol in a multi-hop store & forward email delivery process. An
+ SMTP envelope recipient address does not correspond to a specific
+ transport-layer endpoint address, rather at each relay hop the
+ transport-layer endpoint is the next-hop relay, while the envelope
+ recipient address typically remains the same. Unlike the Hypertext
+ Transfer Protocol (HTTP) and its corresponding secured version,
+ HTTPS, where the use of TLS is signaled via the URI scheme, email
+ recipient addresses do not directly signal transport security policy.
+ Indeed, no such signaling could work well with SMTP since TLS
+ encryption of SMTP protects email traffic on a hop-by-hop basis while
+ email addresses could only express end-to-end policy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 6]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
With no mechanism available to signal transport security policy, SMTP
relays employ a best-effort "opportunistic" security model for TLS.
security feature, such as the use of PKIX, can prevent this. The
attacker can simply disable TLS.
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 6]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
1.3.2. Insecure server name without DNSSEC
With SMTP, DNS Mail Exchange (MX) records abstract the next-hop
that the server's certificate binds the public key to a name that
matches one of the client's reference identifiers. A natural choice
of reference identifier is the server's domain name. However, with
- SMTP, server names are obtained indirectly via MX records. Without
- DNSSEC, the MX lookup is vulnerable to MITM and DNS cache poisoning
- attacks. Active attackers can forge DNS replies with fake MX records
- and can redirect email to servers with names of their choice.
- Therefore, secure verification of SMTP TLS certificates matching the
- server name is not possible without DNSSEC.
+ SMTP, server names are not directly encoded in the recipient address,
+ instead they are obtained indirectly via MX records. Without DNSSEC,
+ the MX lookup is vulnerable to MITM and DNS cache poisoning attacks.
+ Active attackers can forge DNS replies with fake MX records and can
+ redirect email to servers with names of their choice. Therefore,
+ secure verification of SMTP TLS certificates matching the server name
+ is not possible without DNSSEC.
One might try to harden TLS for SMTP against DNS attacks by using the
envelope recipient domain as a reference identifier and requiring
large-scale deployment of authenticated TLS for SMTP requires that
the DNS be secure.
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 7]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
Since SMTP security depends critically on DNSSEC, it is important to
point out that consequently SMTP with DANE is the most conservative
possible trust model. It trusts only what must be trusted and no
more. Adding any other trusted actors to the mix can only reduce
SMTP security. A sender may choose to further harden DNSSEC for
- selected high-value receiving domains, by configuring explicit trust
+ selected high-value receiving domains by configuring explicit trust
anchors for those domains instead of relying on the chain of trust
- from the root domain. Detailed discussion of DNSSEC security
- practices is out of scope for this document.
+ from the root domain. However, detailed discussion of DNSSEC
+ security practices is out of scope for this document.
1.3.3. Sender policy does not scale
-
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 7]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
Sending systems are in some cases explicitly configured to use TLS
for mail sent to selected peer domains. This requires sending MTAs
to be configured with appropriate subject names or certificate
trust anchor). MTAs are not interactive applications where a human
operator can make a decision (wisely or otherwise) to selectively
disable TLS security policy when certificate chain verification
- fails. With no user to "click OK", the MTAs list of public CA trust
+ fails. With no user to "click OK", the MTA's list of public CA trust
anchors would need to be comprehensive in order to avoid bouncing
mail addressed to sites that employ unknown Certification
Authorities.
- On the other hand, each trusted CA can issue certificates for any
- domain. If even one of the configured CAs is compromised or operated
- by an adversary, it can subvert TLS security for all destinations.
- Any set of CAs is simultaneously both overly inclusive and not
- inclusive enough.
-2. Identifying applicable TLSA records
-2.1. DNS considerations
-2.1.1. DNS errors, bogus and indeterminate responses
+Dukhovni & Hardaker Expires February 18, 2015 [Page 8]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+ On the other hand, each trusted CA can issue certificates for any
+ domain. If even one of the configured CAs is compromised or operated
+ by an adversary, it can subvert TLS security for all destinations.
+ Any set of CAs is simultaneously both overly inclusive and not
+ inclusive enough.
+2. Identifying applicable TLSA records
-Dukhovni & Hardaker Expires November 26, 2014 [Page 8]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+2.1. DNS considerations
+2.1.1. DNS errors, bogus and indeterminate responses
An SMTP client that implements opportunistic DANE TLS per this
specification depends critically on the integrity of DNSSEC lookups,
- as discussed in Section 1.3. This section lists the DNS resolver
+ as discussed in Section 1.3.2. This section lists the DNS resolver
requirements needed to avoid downgrade attacks when using
opportunistic DANE TLS.
There is no trust anchor that would indicate that a specific
portion of the tree is secure.
+ To avoid further confusion, the adjective "anchorless" will be used
+ below to refer to domains or RRsets that are "indeterminate" in the
+ [RFC4033] sense, and the term "indeterminate" will be used
+ exclusively in the sense of [RFC4035].
+
SMTP clients following this specification SHOULD NOT distinguish
- between "insecure" and "indeterminate" in the [RFC4033] sense. Both
- "insecure" and RFC4033 "indeterminate" are 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, when we say "insecure", we include also DNS results
- for domains that lie in a portion of the DNS tree for which there is
- no applicable trust anchor. With the DNS root zone signed, we expect
- that validating resolvers used by Internet-facing MTAs will be
- configured with trust anchor data for the root zone. Therefore,
- RFC4033-style "indeterminate" domains should be rare in practice.
- From here on, when we say "indeterminate", it is exclusively in the
- sense of [RFC4035].
+ between "insecure" and "anchorless" DNS responses. Both "insecure"
+ 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 include the case of
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 9]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ "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,
+ we expect that validating resolvers used by Internet-facing MTAs will
+ be configured with trust anchor data for the root zone, and that
+ therefore "anchorless" domains should be rare in practice.
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
"secure", "insecure", "bogus" or "indeterminate". It is expected
that most security-aware stub resolvers will not signal an
- "indeterminate" security status in the RFC4035-sense to the
+ "indeterminate" security status (in the sense of RFC4035) to the
application, and will signal a "bogus" or error result instead. If a
resolver does signal an RFC4035 "indeterminate" security status, this
MUST be treated by the SMTP client as though a "bogus" or error
result had been returned.
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 9]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
An MTA making use of a non-validating security-aware stub resolver
MAY use the stub resolver's ability, if available, to signal DNSSEC
validation status based on information the stub resolver has learned
- from an upstream validating recursive resolver. In accordance with
- section 4.9.3 of [RFC4035]:
+ from an upstream validating recursive resolver. Security-Oblivious
+ stub-resolvers MUST NOT be used. In accordance with section 4.9.3 of
+ [RFC4035]:
... a security-aware stub resolver MUST NOT place any reliance on
signature validation allegedly performed on its behalf, except
has not been left without an answer; it has learned that records of
the requested type do not exist.
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 10]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
Security-aware stub resolvers will, of course, also signal DNS lookup
errors in other cases, for example when processing a "ServFail"
RCODE, which will not have an associated DNSSEC status. All lookup
security, but do not stand in the way of message delivery. See
section Section 2.2 for further details.
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 10]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
2.1.2. DNS error handling
When a DNS lookup failure (error or "bogus" or "indeterminate" as
clients MUST NOT continue to connect to an SMTP server or destination
whose TLSA record lookup fails.
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 11]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
2.1.3. Stub resolver considerations
+ SMTP clients that employ opportunistic DANE TLS to secure connections
+ to SMTP servers MUST NOT use Security-Oblivious stub-resolvers.
+
A note about DNAME aliases: a query for a domain name whose ancestor
- domain is a DNAME alias returns the DNAME RR for the ancestor domain,
+ domain is a DNAME alias returns the DNAME RR for the ancestor domain
along with a CNAME that maps the query domain to the corresponding
sub-domain of the target domain of the DNAME alias [RFC6672].
Therefore, whenever we speak of CNAME aliases, we implicitly allow
for the possibility that the alias in question is the result of an
ancestor domain DNAME record. Consequently, no explicit support for
- DNAME records is needed in SMTP software, it is sufficient to process
+ DNAME records is needed in SMTP software; it is sufficient to process
the resulting CNAME aliases. DNAME records only require special
processing in the validating stub-resolver library that checks the
integrity of the combined DNAME + CNAME reply. When DNSSEC
When a stub resolver returns a response containing a CNAME alias that
does not also contain the corresponding query results for the target
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 11]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
of the alias, the SMTP client will need to repeat the query at the
target of the alias, and should do so recursively up to some
configured or implementation-dependent recursion limit. If at any
final result) MUST be considered "insecure" regardless of whether any
earlier CNAME records leading to the "insecure" record were "secure".
- Note, a security-aware non-validating stub resolver may return to the
- SMTP client an "insecure" reply received from a validating recursive
- resolver that contains a CNAME record along with additional answers
- recursively obtained starting at the target of the CNAME. In this
- all that one can say is that some record in the set of records
- returned is "insecure", but it is possible that the initial CNAME
- record and a subset of the subsequent records are "secure".
+ Note that a security-aware non-validating stub resolver may return to
+ the SMTP client an "insecure" reply received from a validating
+ recursive resolver that contains a CNAME record along with additional
+ answers recursively obtained starting at the target of the CNAME. In
+ this case, the only possible conclusion is that some record in the
+ set of records returned is "insecure", and it is in fact possible
+ that the initial CNAME record and a subset of the subsequent records
+ are "secure".
If the SMTP client needs to determine the security status of the DNS
- zone containing the initial CNAME record, it may need to issue an a
+ zone containing the initial CNAME record, it may need to issue a
separate query of type "CNAME" that returns only the initial CNAME
record. In particular in Section 2.2.2 when insecure A or AAAA
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 12]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
records are found for an SMTP server via a CNAME alias, it may be
necessary to perform an additional CNAME query to determine whether
the DNS zone in which the alias is published is signed.
context is in the sense of Section 4.1 of [RFC6698]. Specifically,
if the DNS lookup for a TLSA record returns:
-
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 12]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
A secure TLSA RRset with at least one usable record: A connection to
the MTA MUST be made using authenticated and encrypted TLS, using
the techniques discussed in the rest of this document. Failure to
establish an authenticated TLS connection MUST result in falling
back to the next SMTP server or delayed delivery.
- A Secure non-empty TLSA RRset where all the records are unusable: A
+ A secure non-empty TLSA RRset where all the records are unusable: A
connection to the MTA MUST be made via TLS, but authentication is
not required. Failure to establish an encrypted TLS connection
MUST result in falling back to the next SMTP server or delayed
An SMTP client MAY be configured to require DANE verified delivery
for some destinations. We will call such a configuration "mandatory
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 13]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
DANE TLS". With mandatory DANE TLS, delivery proceeds only when
"secure" TLSA records are used to establish an encrypted and
authenticated TLS channel with the SMTP server.
than a DNS domain, DANE TLS does not apply. Delivery proceeds using
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 the MTA chooses to connect to the network
- address DANE TLSA does not apply for such a connection.
+ lieu of an MX hostname, if an MTA chooses to connect to the network
+ 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
servers and the associated TLSA records for a given next-hop
resolution and have MX records. The TLSA records and the associated
base domain are derived separately for each MX hostname that is used
to attempt message delivery. DANE TLS can authenticate message
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 13]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
delivery to the intended next-hop domain only when the MX records are
obtained securely via a DNSSEC validated lookup.
results in a CNAME alias, the MTA replaces the initial name with the
resulting name and performs a new lookup with the new name. MTAs
typically support recursion in CNAME expansion, so this replacement
- is performed repeatedly until the ultimate non-CNAME domain is found.
+ is performed repeatedly (up to the MTA's recursion limit) until the
+ ultimate non-CNAME domain is found.
If the MX RRset (or any CNAME leading to it) is "insecure" (see
Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
pre-DANE opportunistic TLS. That said, the protocol in this memo is
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 14]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
an "opportunistic security" protocol, meaning that it strives to
communicate with each peer as securely as possible, while maintaining
broad interoperability. Therefore, the SMTP client MAY proceed to
a given destination, delivery MUST be delayed when the MX RRset is
not "secure".
-
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 14]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
Otherwise, assuming no DNS errors (Section 2.1.1), the MX RRset is
"secure", and the SMTP client MUST treat each MX hostname as a
separate non-MX destination for opportunistic DANE TLS as described
resolution. This frequently involves configuration set by the MTA
administrator to handle some or all mail.
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 15]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
o A next-hop destination domain subject to MX resolution that has no
MX records. In this case the domain's name is implicitly also its
sole SMTP server name.
If no address records are found, the destination is unreachable. If
address records are found, but the DNSSEC validation status of the
first query response is "insecure" (see Section 2.1.3), the SMTP
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 15]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
client SHOULD NOT proceed to search for any associated TLSA records.
With the problem domains, TLSA queries will lead to DNS lookup errors
and cause messages to be consistently delayed and ultimately returned
If the A and/or AAAA lookup of the "initial name" yields a CNAME, we
replace it with the resulting name as if it were the initial name and
perform a lookup again using the new name. This replacement is
- performed recursively.
+ performed recursively (up to the MTA's recursion limit).
We consider the following cases for handling a DNS response for an A
or AAAA DNS lookup:
neither a list of addresses nor a CNAME (or CNAME expansion is not
supported) the destination is unreachable.
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 16]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
Non-CNAME: The answer is not a CNAME alias. If the address RRset
is "secure", TLSA lookups are performed as described in
Section 2.2.3 with the initial name as the candidate TLSA base
candidate TLSA base domains are tried: the fully CNAME-expanded
initial name and, failing that, then the initial name itself.
-
-
-
-
-
-
-
-
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 16]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
In summary, if it is possible to securely obtain the full, CNAME-
expanded, DNSSEC-validated address records for the input domain, then
that name is the preferred TLSA base domain. Otherwise, the
_25._tcp.mx.example.com. IN TLSA ?
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 17]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
The query response may be a CNAME, or the actual TLSA RRset. If the
response is a CNAME, the SMTP client (through the use of its
security-aware stub resolver) restarts the TLSA query at the target
domain, following CNAMEs as appropriate and keeping track of whether
the entire chain is "secure". If any "insecure" records are
encountered, or the TLSA records don't exist, the next candidate TLSA
- base is tried instead.
+ base domain is tried instead.
If the ultimate response is a "secure" TLSA RRset, then the candidate
TLSA base domain will be the actual TLSA base domain and the TLSA
TLSA record publishers may leverage CNAMEs to reference a single
authoritative TLSA RRset specifying a common Certification Authority
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 17]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
or a common end entity certificate to be used with multiple TLS
services. Such CNAME expansion does not change the SMTP client's
notion of the TLSA base domain; thus, when _25._tcp.mx.example.com is
reference identifier used together with the next-hop domain in peer
certificate name checks.
- Note, shared end entity certificate associations expose the
+ Note that shared end entity certificate associations expose the
publishing domain to substitution attacks, where an MITM attacker can
reroute traffic to a different server that shares the same end entity
- certificate. Such shared end entity records SHOULD be avoided unless
- the servers in question are functionally equivalent (an active
- attacker gains nothing by diverting client traffic from one such
- server to another).
+ certificate. Such shared end entity TLSA records SHOULD be avoided
+ unless the servers in question are functionally equivalent or employ
+ mutually incompatible protocols (an active attacker gains nothing by
+ diverting client traffic from one such server to another).
- For example, given the DNSSEC validated records below:
+ A better example, employing a shared trust anchor rather than shared
+ end-entity certificates, is illustrated by the DNSSEC validated
+ records below:
example.com. IN MX 0 mx1.example.com.
example.com. IN MX 0 mx2.example.com.
- _25._tcp.mx1.example.com. IN CNAME tlsa211._dane.example.com.
- _25._tcp.mx2.example.com. IN CNAME tlsa211._dane.example.com.
- tlsa211._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c149a...
+ _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
+ _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
+ tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c149a...
The SMTP servers mx1.example.com and mx2.example.com will be expected
to have certificates issued under a common trust anchor, but each MX
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 18]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
hostname's TLSA base domain remains unchanged despite the above CNAME
records. Correspondingly, each SMTP server will be associated with a
pair of reference identifiers consisting of its hostname plus the
arise during CNAME expansion that are neither the original, nor the
final name, are never candidate TLSA base domains, even if "secure".
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 18]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
3. DANE authentication
This section describes which TLSA records are applicable to SMTP
The DANE TLSA specification [RFC6698] defines multiple TLSA RR types
via combinations of 3 numeric parameters. The numeric values of
- these parameters were later given symbolic names in
- [I-D.ietf-dane-registry-acronyms]. The rest of the TLSA record is
- the "certificate association data field", which specifies the full or
- digest value of a certificate or public key. The parameters are:
+ these parameters were later given symbolic names in [RFC7218]. The
+ rest of the TLSA record is the "certificate association data field",
+ which specifies the full or digest value of a certificate or public
+ key. The parameters are:
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 19]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698]
- specifies 4 values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-
- EE(3). There is an additional private-use value: PrivCert(255).
- All other values are reserved for use by future specifications.
+ specifies four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and
+ DANE-EE(3). There is an additional private-use value:
+ PrivCert(255). All other values are reserved for use by future
+ specifications.
- The selector field: Section 2.1.2 of [RFC6698] specifies 2 values:
- Cert(0), SPKI(1). There is an additional private-use value:
+ The selector field: Section 2.1.2 of [RFC6698] specifies two values:
+ Cert(0) and SPKI(1). There is an additional private-use value:
PrivSel(255). All other values are reserved for use by future
specifications.
- The matching type field: Section 2.1.3 of [RFC6698] specifies 3
- values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional
- private-use value: PrivMatch(255). All other values are reserved
- for use by future specifications.
+ The matching type field: Section 2.1.3 of [RFC6698] specifies three
+ values: Full(0), SHA2-256(1) and SHA2-512(2). There is an
+ additional private-use value: PrivMatch(255). All other values
+ are reserved for use by future specifications.
We may think of TLSA Certificate Usage values 0 through 3 as a
combination of two one-bit flags. The low bit chooses between trust
The selector field specifies whether the TLSA RR matches the whole
certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1). The
- subjectPublicKeyInfo is an ASN.1 DER encoding of the certificate's
- algorithm id, any parameters and the public key data.
+ subjectPublicKeyInfo is an ASN.1 DER ([X.690]) encoding of the
+ certificate's algorithm id, any parameters and the public key data.
The matching type field specifies how the TLSA RR Certificate
Association Data field is to be compared with the certificate or
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 19]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
public key. A value of Full(0) means an exact match: the full DER
encoding of the certificate or public key is given in the TLSA RR. A
value of SHA2-256(1) means that the association data matches the
on coordinated changes to DNS and SMTP server settings, the best
choice of records to publish will depend on site-specific practices.
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 20]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
The certificate usage element of a TLSA record plays a critical role
in determining how the corresponding certificate association data
field is used to authenticate server's certificate chain. The next
MUST be considered authenticated even if none of the names in the
certificate match the client's reference identity for the server.
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 20]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
Similarly, the expiration date of the server certificate MUST be
ignored, the validity period of the TLSA record key binding is
determined by the validity interval of the TLSA record DNSSEC
it is simpler still to publish the same MX hostname for all the
hosted domains.
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 21]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
For domains where it is practical to make coordinated changes in DNS
TLSA records during SMTP server key rotation, it is often best to
publish end-entity DANE-EE(3) certificate associations. DANE-EE(3)
example.com. IN MX 0 mx1.example.com.
example.com. IN MX 0 mx2.example.com.
- _25._tcp.mx1.example.com. IN CNAME tlsa211._dane.example.com.
- _25._tcp.mx2.example.com. IN CNAME tlsa211._dane.example.com.
- tlsa211._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c14....
-
-
-
-
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 21]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
+ _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
+ _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
+ tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14....
With usage DANE-TA(2) the server certificates will need to have names
that match one of the client's reference identifiers (see [RFC6125]).
client, authentication is likely to fail unless the TA certificate is
included in the TLS server certificate message.
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 22]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
TLSA records with selector Full(0) are discouraged. While these
potentially obviate the need to transmit the TA certificate in the
TLS server certificate message, client implementations may not be
DNSSEC for secure MX records and DANE for STARTTLS support signaling,
perform server identity verification or prevent STARTTLS downgrade
attacks. The use of PKIX CAs offers no added security since an
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 22]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
attacker capable of compromising DNSSEC is free to replace any PKIX-
TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient
non-PKIX certificate usage.
PKIX certificate usages cannot aid SMTP TLS security, they can only
impede SMTP TLS interoperability.
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 23]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0)
or PKIX-EE(1) is undefined. SMTP clients should generally treat such
TLSA records as unusable.
3.2.1. DANE-EE(3) name checks
The SMTP client MUST NOT perform certificate name checks with
- certificate usage DANE-EE(3), see Section 3.1.1 above.
+ certificate usage DANE-EE(3); see Section 3.1.1 above.
3.2.2. DANE-TA(2) name checks
the MX lookup MUST be included as as a second reference
identifier. The CNAME-expanded original next-hop domain MUST be
included as a third reference identifier if different from the
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 23]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
original next-hop domain. When the client MTA is employing DANE
TLS security despite "insecure" MX redirection the MX hostname is
the only reference identifier.
look for the email domain name in server certificates. For example,
with "secure" DNS records as below:
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 24]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
exchange.example.org. IN CNAME mail.example.org.
mail.example.org. IN CNAME example.com.
example.com. IN MX 10 mx10.example.com.
3.2.3. Reference identifier matching
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 24]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
When name checks are applicable (certificate usage DANE-TA(2)), if
the server certificate contains a Subject Alternative Name extension
([RFC5280]), with at least one DNS-ID ([RFC6125]) then only the DNS-
remaining labels matching verbatim. For example, the DNS-ID
"*.example.com" matches the reference identifier "mx1.example.com".
SMTP clients MAY, subject to local policy allow wildcards to match
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 25]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
multiple reference identifier labels, but servers cannot expect broad
support for such a policy. Therefore any wildcards in server
certificates SHOULD match exactly one label in either the TLSA base
the previous trust anchor have expired, its associated RRs can be
removed from the TLSA RRset.
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 25]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
In the DANE-TA(2) key management model server operators do not
generally need to update DNS TLSA records after initially creating a
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
+
+
+
+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
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 26]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
- 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.
+ 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
-
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 27]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
An MTA implementing this protocol may require a stronger security
assurance when sending email to selected destinations. The sending
organization may need to send sensitive email and/or may have
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
is left to future documents that focus specifically on SMTP security
between MUAs and MSAs.
-
-
-
-
-
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 28]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
8. Interoperability considerations
8.1. SNI support
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
- 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
- a mutually supported non-anonymous cipher suite or by correctly
- handling client connections that negotiate anonymous cipher suites.
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 29]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 28]
\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+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
+ a mutually supported non-anonymous cipher suite or by correctly
+ handling client connections that negotiate anonymous cipher suites.
+
Note that while SMTP server operators are under no obligation to
enable anonymous cipher suites, no security is gained by sending
certificates to clients that will ignore them. Indeed support for
least one TLSA record when usable TLSA records are found for that
server.
-9.2. Publisher Operational Considerations
- SMTP servers that publish certificate usage DANE-TA(2) associations
- MUST include the TA certificate in their TLS server certificate
- 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.
-Dukhovni & Hardaker Expires November 26, 2014 [Page 30]
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 29]
\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+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
+ MUST include the TA certificate in their TLS server certificate
+ chain, even when that TA certificate is a self-signed root
+ certificate.
+ 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
This protocol leverages DANE TLSA records to implement MITM resistant
- opportunistic channel security for SMTP. For destination domains
- that sign their MX records and publish signed TLSA records for their
- MX hostnames, this protocol allows sending MTAs to securely discover
- both the availability of TLS and how to authenticate the destination.
+ opportunistic security ([I-D.dukhovni-opportunistic-security]) for
+ SMTP. For destination domains that sign their MX records and publish
+ signed TLSA records for their MX hostnames, this protocol allows
+ sending MTAs to securely discover both the availability of TLS and
+ how to authenticate the destination.
This protocol does not aim to secure all SMTP traffic, as that is not
practical until DNSSEC and DANE adoption are universal. The
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.
The authors would like to extend great thanks to Tony Finch, who
started the original version of a DANE SMTP document. His work is
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 31]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
greatly appreciated and has been incorporated into this document.
The authors would like to additionally thank Phil Pennock for his
comments and advice on this document.
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.
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 32]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012.
+ [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
+ Conversations about DNS-Based Authentication of Named
+ Entities (DANE)", RFC 7218, April 2014.
+
+ [X.690] International Telecommunications Union, "Recommendation
+ ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information
+ technology - ASN.1 encoding rules: Specification of Basic
+ Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)", July 2002.
+
13.2. Informative References
- [I-D.ietf-dane-registry-acronyms]
- Gudmundsson, O., "Adding acronyms to simplify DANE
- conversations", draft-ietf-dane-registry-acronyms-01 (work
- in progress), October 2013.
+ [I-D.dukhovni-opportunistic-security]
+
+
+
+
+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., "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.
+ 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.
Email: ietf-dane@dukhovni.org
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 33]
-\f
-Internet-Draft SMTP security via opportunistic DANE TLS May 2014
-
-
Wes Hardaker
Parsons
P.O. Box 382
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dukhovni & Hardaker Expires November 26, 2014 [Page 34]
+Dukhovni & Hardaker Expires February 18, 2015 [Page 33]
projects / exim.git / blobdiff