Update DANE draft docs
[exim.git] / doc / doc-txt / draft-ietf-dane-smtp-with-dane-12.txt
5DANE V. Dukhovni
6Internet-Draft Two Sigma
7Intended status: Standards Track W. Hardaker
8Expires: February 18, 2015 Parsons
9 August 17, 2014
12 SMTP security via opportunistic DANE TLS
13 draft-ietf-dane-smtp-with-dane-12
17 This memo describes a downgrade-resistant protocol for SMTP transport
18 security between Mail Transfer Agents (MTAs) based on the DNS-Based
19 Authentication of Named Entities (DANE) TLSA DNS record. Adoption of
20 this protocol enables an incremental transition of the Internet email
21 backbone to one using encrypted and authenticated Transport Layer
22 Security (TLS).
24Status of This Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on February 18, 2015.
41Copyright Notice
43 Copyright (c) 2014 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
56Dukhovni & Hardaker Expires February 18, 2015 [Page 1]
58Internet-Draft SMTP security via opportunistic DANE TLS August 2014
61 the Trust Legal Provisions and are provided without warranty as
62 described in the Simplified BSD License.
64Table of Contents
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
68 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5
69 1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 6
70 1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 6
71 1.3.2. Insecure server name without DNSSEC . . . . . . . . . 7
72 1.3.3. Sender policy does not scale . . . . . . . . . . . . 8
73 1.3.4. Too many certification authorities . . . . . . . . . 8
74 2. Identifying applicable TLSA records . . . . . . . . . . . . . 9
75 2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 9
76 2.1.1. DNS errors, bogus and indeterminate responses . . . . 9
77 2.1.2. DNS error handling . . . . . . . . . . . . . . . . . 11
78 2.1.3. Stub resolver considerations . . . . . . . . . . . . 12
79 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 13
80 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 14
81 2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 15
82 2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 17
83 3. DANE authentication . . . . . . . . . . . . . . . . . . . . . 19
84 3.1. TLSA certificate usages . . . . . . . . . . . . . . . . . 19
85 3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 21
86 3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 22
87 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 23
88 3.2. Certificate matching . . . . . . . . . . . . . . . . . . 24
89 3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 24
90 3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 24
91 3.2.3. Reference identifier matching . . . . . . . . . . . . 25
92 4. Server key management . . . . . . . . . . . . . . . . . . . . 26
93 5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26
94 6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 27
95 7. Note on DANE for Message User Agents . . . . . . . . . . . . 27
96 8. Interoperability considerations . . . . . . . . . . . . . . . 28
97 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 28
98 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 28
99 9. Operational Considerations . . . . . . . . . . . . . . . . . 29
100 9.1. Client Operational Considerations . . . . . . . . . . . . 29
101 9.2. Publisher Operational Considerations . . . . . . . . . . 30
102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
103 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
104 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
105 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
106 13.1. Normative References . . . . . . . . . . . . . . . . . . 31
107 13.2. Informative References . . . . . . . . . . . . . . . . . 32
108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
112Dukhovni & Hardaker Expires February 18, 2015 [Page 2]
114Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1171. Introduction
119 This memo specifies a new connection security model for Message
120 Transfer Agents (MTAs). This model is motivated by key features of
121 inter-domain SMTP delivery, in particular the fact that the
122 destination server is selected indirectly via DNS Mail Exchange (MX)
123 records and that neither email addresses nor MX hostnames signal a
124 requirement for either secure or cleartext transport. Therefore,
125 aside from a few manually configured exceptions, SMTP transport
126 security is of necessity opportunistic.
128 This specification uses the presence of DANE TLSA records to securely
129 signal TLS support and to publish the means by which SMTP clients can
130 successfully authenticate legitimate SMTP servers. This becomes
131 "opportunistic DANE TLS" and is resistant to downgrade and man-in-
132 the-middle (MITM) attacks. It enables an incremental transition of
133 the email backbone to authenticated TLS delivery, with increased
134 global protection as adoption increases.
136 With opportunistic DANE TLS, traffic from SMTP clients to domains
137 that publish "usable" DANE TLSA records in accordance with this memo
138 is authenticated and encrypted. Traffic from legacy clients or to
139 domains that do not publish TLSA records will continue to be sent in
140 the same manner as before, via manually configured security, (pre-
141 DANE) opportunistic TLS or just cleartext SMTP.
143 Problems with existing use of TLS in MTA to MTA SMTP that motivate
144 this specification are described in Section 1.3. The specification
145 itself follows in Section 2 and Section 3 which describe respectively
146 how to locate and use DANE TLSA records with SMTP. In Section 6, we
147 discuss application of DANE TLS to destinations for which channel
148 integrity and confidentiality are mandatory. In Section 7 we briefly
149 comment on potential applicability of this specification to Message
150 User Agents.
1521.1. Terminology
154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
156 "OPTIONAL" in this document are to be interpreted as described in
157 [RFC2119].
159 The following terms or concepts are used through the document:
161 Man-in-the-middle or MITM attack: Active modification of network
162 traffic by an adversary able to thereby compromise the
163 confidentiality or integrity of the data.
168Dukhovni & Hardaker Expires February 18, 2015 [Page 3]
170Internet-Draft SMTP security via opportunistic DANE TLS August 2014
173 secure, bogus, insecure, indeterminate: DNSSEC validation results,
174 as defined in Section 4.3 of [RFC4035].
176 Validating Security-Aware Stub Resolver and Non-Validating
177 Security-Aware Stub Resolver:
178 Capabilities of the stub resolver in use as defined in [RFC4033];
179 note that this specification requires the use of a Security-Aware
180 Stub Resolver.
182 (pre-DANE) opportunistic TLS: Best-effort use of TLS that is
183 generally vulnerable to DNS forgery and STARTTLS downgrade
184 attacks. When a TLS-encrypted communication channel is not
185 available, message transmission takes place in the clear. MX
186 record indirection generally precludes authentication even when
187 TLS is available.
189 opportunistic DANE TLS: Best-effort use of TLS, resistant to
190 downgrade attacks for destinations with DNSSEC-validated TLSA
191 records. When opportunistic DANE TLS is determined to be
192 unavailable, clients should fall back to opportunistic TLS.
193 Opportunistic DANE TLS requires support for DNSSEC, DANE and
194 STARTTLS on the client side and STARTTLS plus a DNSSEC published
195 TLSA record on the server side.
197 reference identifier: (Special case of [RFC6125] definition). One
198 of the domain names associated by the SMTP client with the
199 destination SMTP server for performing name checks on the server
200 certificate. When name checks are applicable, at least one of the
201 reference identifiers MUST match an [RFC6125] DNS-ID (or if none
202 are present the [RFC6125] CN-ID) of the server certificate (see
203 Section 3.2.3).
205 MX hostname: The RRDATA of an MX record consists of a 16 bit
206 preference followed by a Mail Exchange domain name (see [RFC1035],
207 Section 3.3.9). We will use the term "MX hostname" to refer to
208 the latter, that is, the DNS domain name found after the
209 preference value in an MX record. Thus an "MX hostname" is
210 specifically a reference to a DNS domain name, rather than any
211 host that bears that name.
213 delayed delivery: Email delivery is a multi-hop store & forward
214 process. When an MTA is unable forward a message that may become
215 deliverable later the message is queued and delivery is retried
216 periodically. Some MTAs may be configured with a fallback next-
217 hop destination that handles messages that the MTA would otherwise
218 queue and retry. When a fallback next-hop is configured, messages
219 that would otherwise have to be delayed may be sent to the
220 fallback next-hop destination instead. The fallback destination
224Dukhovni & Hardaker Expires February 18, 2015 [Page 4]
226Internet-Draft SMTP security via opportunistic DANE TLS August 2014
229 may itself be subject to opportunistic or mandatory DANE TLS as
230 though it were the original message destination.
232 original next hop destination: The logical destination for mail
233 delivery. By default this is the domain portion of the recipient
234 address, but MTAs may be configured to forward mail for some or
235 all recipients via designated relays. The original next hop
236 destination is, respectively, either the recipient domain or the
237 associated configured relay.
239 MTA: Message Transfer Agent ([RFC5598], Section 4.3.2).
241 MSA: Message Submission Agent ([RFC5598], Section 4.3.1).
243 MUA: Message User Agent ([RFC5598], Section 4.2.1).
245 RR: A DNS Resource Record
247 RRset: A set of DNS Resource Records for a particular class, domain
248 and record type.
2501.2. Background
252 The Domain Name System Security Extensions (DNSSEC) add data origin
253 authentication, data integrity and data non-existence proofs to the
254 Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034]
255 and [RFC4035].
257 As described in the introduction of [RFC6698], TLS authentication via
258 the existing public Certification Authority (CA) PKI suffers from an
259 over-abundance of trusted parties capable of issuing certificates for
260 any domain of their choice. DANE leverages the DNSSEC infrastructure
261 to publish trusted public keys and certificates for use with the
262 Transport Layer Security (TLS) [RFC5246] protocol via a new "TLSA"
263 DNS record type. With DNSSEC each domain can only vouch for the keys
264 of its directly delegated sub-domains.
266 The TLS protocol enables secure TCP communication. In the context of
267 this memo, channel security is assumed to be provided by TLS. Used
268 without authentication, TLS provides only privacy protection against
269 eavesdropping attacks. With authentication, TLS also provides data
270 integrity protection to guard against MITM attacks.
280Dukhovni & Hardaker Expires February 18, 2015 [Page 5]
282Internet-Draft SMTP security via opportunistic DANE TLS August 2014
2851.3. SMTP channel security
287 With HTTPS, Transport Layer Security (TLS) employs X.509 certificates
288 [RFC5280] issued by one of the many Certificate Authorities (CAs)
289 bundled with popular web browsers to allow users to authenticate
290 their "secure" websites. Before we specify a new DANE TLS security
291 model for SMTP, we will explain why a new security model is needed.
292 In the process, we will explain why the familiar HTTPS security model
293 is inadequate to protect inter-domain SMTP traffic.
295 The subsections below outline four key problems with applying
296 traditional PKI to SMTP that are addressed by this specification.
297 Since SMTP channel security policy is not explicitly specified in
298 either the recipient address or the MX record, a new signaling
299 mechanism is required to indicate when channel security is possible
300 and should be used. The publication of TLSA records allows server
301 operators to securely signal to SMTP clients that TLS is available
302 and should be used. DANE TLSA makes it possible to simultaneously
303 discover which destination domains support secure delivery via TLS
304 and how to verify the authenticity of the associated SMTP services,
305 providing a path forward to ubiquitous SMTP channel security.
3071.3.1. STARTTLS downgrade attack
309 The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop
310 protocol in a multi-hop store & forward email delivery process. An
311 SMTP envelope recipient address does not correspond to a specific
312 transport-layer endpoint address, rather at each relay hop the
313 transport-layer endpoint is the next-hop relay, while the envelope
314 recipient address typically remains the same. Unlike the Hypertext
315 Transfer Protocol (HTTP) and its corresponding secured version,
316 HTTPS, where the use of TLS is signaled via the URI scheme, email
317 recipient addresses do not directly signal transport security policy.
318 Indeed, no such signaling could work well with SMTP since TLS
319 encryption of SMTP protects email traffic on a hop-by-hop basis while
320 email addresses could only express end-to-end policy.
336Dukhovni & Hardaker Expires February 18, 2015 [Page 6]
338Internet-Draft SMTP security via opportunistic DANE TLS August 2014
341 With no mechanism available to signal transport security policy, SMTP
342 relays employ a best-effort "opportunistic" security model for TLS.
343 A single SMTP server TCP listening endpoint can serve both TLS and
344 non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS
345 command ([RFC3207]). The server signals TLS support to the client
346 over a cleartext SMTP connection, and, if the client also supports
347 TLS, it may negotiate a TLS encrypted channel to use for email
348 transmission. The server's indication of TLS support can be easily
349 suppressed by an MITM attacker. Thus pre-DANE SMTP TLS security can
350 be subverted by simply downgrading a connection to cleartext. No TLS
351 security feature, such as the use of PKIX, can prevent this. The
352 attacker can simply disable TLS.
3541.3.2. Insecure server name without DNSSEC
356 With SMTP, DNS Mail Exchange (MX) records abstract the next-hop
357 transport endpoint and allow administrators to specify a set of
358 target servers to which SMTP traffic should be directed for a given
359 domain.
361 A PKIX TLS client is vulnerable to MITM attacks unless it verifies
362 that the server's certificate binds the public key to a name that
363 matches one of the client's reference identifiers. A natural choice
364 of reference identifier is the server's domain name. However, with
365 SMTP, server names are not directly encoded in the recipient address,
366 instead they are obtained indirectly via MX records. Without DNSSEC,
367 the MX lookup is vulnerable to MITM and DNS cache poisoning attacks.
368 Active attackers can forge DNS replies with fake MX records and can
369 redirect email to servers with names of their choice. Therefore,
370 secure verification of SMTP TLS certificates matching the server name
371 is not possible without DNSSEC.
373 One might try to harden TLS for SMTP against DNS attacks by using the
374 envelope recipient domain as a reference identifier and requiring
375 each SMTP server to possess a trusted certificate for the envelope
376 recipient domain rather than the MX hostname. Unfortunately, this is
377 impractical as email for many domains is handled by third parties
378 that are not in a position to obtain certificates for all the domains
379 they serve. Deployment of the Server Name Indication (SNI) extension
380 to TLS (see [RFC6066] Section 3) is no panacea, since SNI key
381 management is operationally challenging except when the email service
382 provider is also the domain's registrar and its certificate issuer;
383 this is rarely the case for email.
385 Since the recipient domain name cannot be used as the SMTP server
386 reference identifier, and neither can the MX hostname without DNSSEC,
387 large-scale deployment of authenticated TLS for SMTP requires that
388 the DNS be secure.
392Dukhovni & Hardaker Expires February 18, 2015 [Page 7]
394Internet-Draft SMTP security via opportunistic DANE TLS August 2014
397 Since SMTP security depends critically on DNSSEC, it is important to
398 point out that consequently SMTP with DANE is the most conservative
399 possible trust model. It trusts only what must be trusted and no
400 more. Adding any other trusted actors to the mix can only reduce
401 SMTP security. A sender may choose to further harden DNSSEC for
402 selected high-value receiving domains by configuring explicit trust
403 anchors for those domains instead of relying on the chain of trust
404 from the root domain. However, detailed discussion of DNSSEC
405 security practices is out of scope for this document.
4071.3.3. Sender policy does not scale
409 Sending systems are in some cases explicitly configured to use TLS
410 for mail sent to selected peer domains. This requires sending MTAs
411 to be configured with appropriate subject names or certificate
412 content digests to expect in the presented server certificates.
413 Because of the heavy administrative burden, such statically
414 configured SMTP secure channels are used rarely (generally only
415 between domains that make bilateral arrangements with their business
416 partners). Internet email, on the other hand, requires regularly
417 contacting new domains for which security configurations cannot be
418 established in advance.
420 The abstraction of the SMTP transport endpoint via DNS MX records,
421 often across organization boundaries, limits the use of public CA PKI
422 with SMTP to a small set of sender-configured peer domains. With
423 little opportunity to use TLS authentication, sending MTAs are rarely
424 configured with a comprehensive list of trusted CAs. SMTP services
425 that support STARTTLS often deploy X.509 certificates that are self-
426 signed or issued by a private CA.
4281.3.4. Too many certification authorities
430 Even if it were generally possible to determine a secure server name,
431 the SMTP client would still need to verify that the server's
432 certificate chain is issued by a trusted Certification Authority (a
433 trust anchor). MTAs are not interactive applications where a human
434 operator can make a decision (wisely or otherwise) to selectively
435 disable TLS security policy when certificate chain verification
436 fails. With no user to "click OK", the MTA's list of public CA trust
437 anchors would need to be comprehensive in order to avoid bouncing
438 mail addressed to sites that employ unknown Certification
439 Authorities.
448Dukhovni & Hardaker Expires February 18, 2015 [Page 8]
450Internet-Draft SMTP security via opportunistic DANE TLS August 2014
453 On the other hand, each trusted CA can issue certificates for any
454 domain. If even one of the configured CAs is compromised or operated
455 by an adversary, it can subvert TLS security for all destinations.
456 Any set of CAs is simultaneously both overly inclusive and not
457 inclusive enough.
4592. Identifying applicable TLSA records
4612.1. DNS considerations
4632.1.1. DNS errors, bogus and indeterminate responses
465 An SMTP client that implements opportunistic DANE TLS per this
466 specification depends critically on the integrity of DNSSEC lookups,
467 as discussed in Section 1.3.2. This section lists the DNS resolver
468 requirements needed to avoid downgrade attacks when using
469 opportunistic DANE TLS.
471 A DNS lookup may signal an error or return a definitive answer. A
472 security-aware resolver must be used for this specification.
473 Security-aware resolvers will indicate the security status of a DNS
474 RRset with one of four possible values defined in Section 4.3 of
475 [RFC4035]: "secure", "insecure", "bogus" and "indeterminate". In
476 [RFC4035] the meaning of the "indeterminate" security status is:
478 An RRset for which the resolver is not able to determine whether
479 the RRset should be signed, as the resolver is not able to obtain
480 the necessary DNSSEC RRs. This can occur when the security-aware
481 resolver is not able to contact security-aware name servers for
482 the relevant zones.
484 Note, the "indeterminate" security status has a conflicting
485 definition in section 5 of [RFC4033].
487 There is no trust anchor that would indicate that a specific
488 portion of the tree is secure.
490 To avoid further confusion, the adjective "anchorless" will be used
491 below to refer to domains or RRsets that are "indeterminate" in the
492 [RFC4033] sense, and the term "indeterminate" will be used
493 exclusively in the sense of [RFC4035].
495 SMTP clients following this specification SHOULD NOT distinguish
496 between "insecure" and "anchorless" DNS responses. Both "insecure"
497 and "anchorless" RRsets MUST be handled identically: in either case
498 unvalidated data for the query domain is all that is and can be
499 available, and authentication using the data is impossible. In what
500 follows, the term "insecure" will also include the case of
504Dukhovni & Hardaker Expires February 18, 2015 [Page 9]
506Internet-Draft SMTP security via opportunistic DANE TLS August 2014
509 "anchorless" domains that lie in a portion of the DNS tree for which
510 there is no applicable trust anchor. With the DNS root zone signed,
511 we expect that validating resolvers used by Internet-facing MTAs will
512 be configured with trust anchor data for the root zone, and that
513 therefore "anchorless" domains should be rare in practice.
515 As noted in section 4.3 of [RFC4035], a security-aware DNS resolver
516 MUST be able to determine whether a given non-error DNS response is
517 "secure", "insecure", "bogus" or "indeterminate". It is expected
518 that most security-aware stub resolvers will not signal an
519 "indeterminate" security status (in the sense of RFC4035) to the
520 application, and will signal a "bogus" or error result instead. If a
521 resolver does signal an RFC4035 "indeterminate" security status, this
522 MUST be treated by the SMTP client as though a "bogus" or error
523 result had been returned.
525 An MTA making use of a non-validating security-aware stub resolver
526 MAY use the stub resolver's ability, if available, to signal DNSSEC
527 validation status based on information the stub resolver has learned
528 from an upstream validating recursive resolver. Security-Oblivious
529 stub-resolvers MUST NOT be used. In accordance with section 4.9.3 of
530 [RFC4035]:
532 ... a security-aware stub resolver MUST NOT place any reliance on
533 signature validation allegedly performed on its behalf, except
534 when the security-aware stub resolver obtained the data in question
535 from a trusted security-aware recursive name server via a secure
536 channel.
538 To avoid much repetition in the text below, we will pause to explain
539 the handling of "bogus" or "indeterminate" DNSSEC query responses.
540 These are not necessarily the result of a malicious actor; they can,
541 for example, occur when network packets are corrupted or lost in
542 transit. Therefore, "bogus" or "indeterminate" replies are equated
543 in this memo with lookup failure.
545 There is an important non-failure condition we need to highlight in
546 addition to the obvious case of the DNS client obtaining a non-empty
547 "secure" or "insecure" RRset of the requested type. Namely, it is
548 not an error when either "secure" or "insecure" non-existence is
549 determined for the requested data. When a DNSSEC response with a
550 validation status that is either "secure" or "insecure" reports
551 either no records of the requested type or non-existence of the query
552 domain, the response is not a DNS error condition. The DNS client
553 has not been left without an answer; it has learned that records of
554 the requested type do not exist.
560Dukhovni & Hardaker Expires February 18, 2015 [Page 10]
562Internet-Draft SMTP security via opportunistic DANE TLS August 2014
565 Security-aware stub resolvers will, of course, also signal DNS lookup
566 errors in other cases, for example when processing a "ServFail"
567 RCODE, which will not have an associated DNSSEC status. All lookup
568 errors are treated the same way by this specification, regardless of
569 whether they are from a "bogus" or "indeterminate" DNSSEC status or
570 from a more generic DNS error: the information that was requested
571 cannot be obtained by the security-aware resolver at this time. A
572 lookup error is thus a failure to obtain the relevant RRset if it
573 exists, or to determine that no such RRset exists when it does not.
575 In contrast to a "bogus" or an "indeterminate" response, an
576 "insecure" DNSSEC response is not an error, rather it indicates that
577 the target DNS zone is either securely opted out of DNSSEC validation
578 or is not connected with the DNSSEC trust anchors being used.
579 Insecure results will leave the SMTP client with degraded channel
580 security, but do not stand in the way of message delivery. See
581 section Section 2.2 for further details.
5832.1.2. DNS error handling
585 When a DNS lookup failure (error or "bogus" or "indeterminate" as
586 defined above) prevents an SMTP client from determining which SMTP
587 server or servers it should connect to, message delivery MUST be
588 delayed. This naturally includes, for example, the case when a
589 "bogus" or "indeterminate" response is encountered during MX
590 resolution. When multiple MX hostnames are obtained from a
591 successful MX lookup, but a later DNS lookup failure prevents network
592 address resolution for a given MX hostname, delivery may proceed via
593 any remaining MX hosts.
595 When a particular SMTP server is securely identified as the delivery
596 destination, a set of DNS lookups (Section 2.2) MUST be performed to
597 locate any related TLSA records. If any DNS queries used to locate
598 TLSA records fail (be it due to "bogus" or "indeterminate" records,
599 timeouts, malformed replies, ServFails, etc.), then the SMTP client
600 MUST treat that server as unreachable and MUST NOT deliver the
601 message via that server. If no servers are reachable, delivery is
602 delayed.
604 In what follows, we will only describe what happens when all relevant
605 DNS queries succeed. If any DNS failure occurs, the SMTP client MUST
606 behave as described in this section, by skipping the problem SMTP
607 server, or the problem destination. Queries for candidate TLSA
608 records are explicitly part of "all relevant DNS queries" and SMTP
609 clients MUST NOT continue to connect to an SMTP server or destination
610 whose TLSA record lookup fails.
616Dukhovni & Hardaker Expires February 18, 2015 [Page 11]
618Internet-Draft SMTP security via opportunistic DANE TLS August 2014
6212.1.3. Stub resolver considerations
623 SMTP clients that employ opportunistic DANE TLS to secure connections
624 to SMTP servers MUST NOT use Security-Oblivious stub-resolvers.
626 A note about DNAME aliases: a query for a domain name whose ancestor
627 domain is a DNAME alias returns the DNAME RR for the ancestor domain
628 along with a CNAME that maps the query domain to the corresponding
629 sub-domain of the target domain of the DNAME alias [RFC6672].
630 Therefore, whenever we speak of CNAME aliases, we implicitly allow
631 for the possibility that the alias in question is the result of an
632 ancestor domain DNAME record. Consequently, no explicit support for
633 DNAME records is needed in SMTP software; it is sufficient to process
634 the resulting CNAME aliases. DNAME records only require special
635 processing in the validating stub-resolver library that checks the
636 integrity of the combined DNAME + CNAME reply. When DNSSEC
637 validation is handled by a local caching resolver, rather than the
638 MTA itself, even that part of the DNAME support logic is outside the
639 MTA.
641 When a stub resolver returns a response containing a CNAME alias that
642 does not also contain the corresponding query results for the target
643 of the alias, the SMTP client will need to repeat the query at the
644 target of the alias, and should do so recursively up to some
645 configured or implementation-dependent recursion limit. If at any
646 stage of CNAME expansion an error is detected, the lookup of the
647 original requested records MUST be considered to have failed.
649 Whether a chain of CNAME records was returned in a single stub
650 resolver response or via explicit recursion by the SMTP client, if at
651 any stage of recursive expansion an "insecure" CNAME record is
652 encountered, then it and all subsequent results (in particular, the
653 final result) MUST be considered "insecure" regardless of whether any
654 earlier CNAME records leading to the "insecure" record were "secure".
656 Note that a security-aware non-validating stub resolver may return to
657 the SMTP client an "insecure" reply received from a validating
658 recursive resolver that contains a CNAME record along with additional
659 answers recursively obtained starting at the target of the CNAME. In
660 this case, the only possible conclusion is that some record in the
661 set of records returned is "insecure", and it is in fact possible
662 that the initial CNAME record and a subset of the subsequent records
663 are "secure".
665 If the SMTP client needs to determine the security status of the DNS
666 zone containing the initial CNAME record, it may need to issue a
667 separate query of type "CNAME" that returns only the initial CNAME
668 record. In particular in Section 2.2.2 when insecure A or AAAA
672Dukhovni & Hardaker Expires February 18, 2015 [Page 12]
674Internet-Draft SMTP security via opportunistic DANE TLS August 2014
677 records are found for an SMTP server via a CNAME alias, it may be
678 necessary to perform an additional CNAME query to determine whether
679 the DNS zone in which the alias is published is signed.
6812.2. TLS discovery
683 As noted previously (in Section 1.3.1), opportunistic TLS with SMTP
684 servers that advertise TLS support via STARTTLS is subject to an MITM
685 downgrade attack. Also some SMTP servers that are not, in fact, TLS
686 capable erroneously advertise STARTTLS by default and clients need to
687 be prepared to retry cleartext delivery after STARTTLS fails. In
688 contrast, DNSSEC validated TLSA records MUST NOT be published for
689 servers that do not support TLS. Clients can safely interpret their
690 presence as a commitment by the server operator to implement TLS and
693 This memo defines four actions to be taken after the search for a
694 TLSA record returns secure usable results, secure unusable results,
695 insecure or no results or an error signal. The term "usable" in this
696 context is in the sense of Section 4.1 of [RFC6698]. Specifically,
697 if the DNS lookup for a TLSA record returns:
699 A secure TLSA RRset with at least one usable record: A connection to
700 the MTA MUST be made using authenticated and encrypted TLS, using
701 the techniques discussed in the rest of this document. Failure to
702 establish an authenticated TLS connection MUST result in falling
703 back to the next SMTP server or delayed delivery.
705 A secure non-empty TLSA RRset where all the records are unusable: A
706 connection to the MTA MUST be made via TLS, but authentication is
707 not required. Failure to establish an encrypted TLS connection
708 MUST result in falling back to the next SMTP server or delayed
709 delivery.
711 An insecure TLSA RRset or DNSSEC validated proof-of-non-existent TLSA
712 records:
713 A connection to the MTA SHOULD be made using (pre-DANE)
714 opportunistic TLS, this includes using cleartext delivery when the
715 remote SMTP server does not appear to support TLS. The MTA MAY
716 retry in cleartext when delivery via TLS fails either during the
717 handshake or even during data transfer.
719 Any lookup error: Lookup errors, including "bogus" and
720 "indeterminate", as explained in Section 2.1.1 MUST result in
721 falling back to the next SMTP server or delayed delivery.
723 An SMTP client MAY be configured to require DANE verified delivery
724 for some destinations. We will call such a configuration "mandatory
728Dukhovni & Hardaker Expires February 18, 2015 [Page 13]
730Internet-Draft SMTP security via opportunistic DANE TLS August 2014
733 DANE TLS". With mandatory DANE TLS, delivery proceeds only when
734 "secure" TLSA records are used to establish an encrypted and
735 authenticated TLS channel with the SMTP server.
737 When the original next-hop destination is an address literal, rather
738 than a DNS domain, DANE TLS does not apply. Delivery proceeds using
739 any relevant security policy configured by the MTA administrator.
740 Similarly, when an MX RRset incorrectly lists a network address in
741 lieu of an MX hostname, if an MTA chooses to connect to the network
742 address in the non-conformant MX record, DANE TLSA does not apply for
743 such a connection.
745 In the subsections that follow we explain how to locate the SMTP
746 servers and the associated TLSA records for a given next-hop
747 destination domain. We also explain which name or names are to be
748 used in identity checks of the SMTP server certificate.
7502.2.1. MX resolution
752 In this section we consider next-hop domains that are subject to MX
753 resolution and have MX records. The TLSA records and the associated
754 base domain are derived separately for each MX hostname that is used
755 to attempt message delivery. DANE TLS can authenticate message
756 delivery to the intended next-hop domain only when the MX records are
757 obtained securely via a DNSSEC validated lookup.
759 MX records MUST be sorted by preference; an MX hostname with a worse
760 (numerically higher) MX preference that has TLSA records MUST NOT
761 preempt an MX hostname with a better (numerically lower) preference
762 that has no TLSA records. In other words, prevention of delivery
763 loops by obeying MX preferences MUST take precedence over channel
764 security considerations. Even with two equal-preference MX records,
765 an MTA is not obligated to choose the MX hostname that offers more
766 security. Domains that want secure inbound mail delivery need to
767 ensure that all their SMTP servers and MX records are configured
768 accordingly.
770 In the language of [RFC5321] Section 5.1, the original next-hop
771 domain is the "initial name". If the MX lookup of the initial name
772 results in a CNAME alias, the MTA replaces the initial name with the
773 resulting name and performs a new lookup with the new name. MTAs
774 typically support recursion in CNAME expansion, so this replacement
775 is performed repeatedly (up to the MTA's recursion limit) until the
776 ultimate non-CNAME domain is found.
778 If the MX RRset (or any CNAME leading to it) is "insecure" (see
779 Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
780 pre-DANE opportunistic TLS. That said, the protocol in this memo is
784Dukhovni & Hardaker Expires February 18, 2015 [Page 14]
786Internet-Draft SMTP security via opportunistic DANE TLS August 2014
789 an "opportunistic security" protocol, meaning that it strives to
790 communicate with each peer as securely as possible, while maintaining
791 broad interoperability. Therefore, the SMTP client MAY proceed to
792 use DANE TLS (as described in Section 2.2.2 below) even with MX hosts
793 obtained via an "insecure" MX RRset. For example, when a hosting
794 provider has a signed DNS zone and publishes TLSA records for its
795 SMTP servers, hosted domains that are not signed may still benefit
796 from the provider's TLSA records. Deliveries via the provider's SMTP
797 servers will not be subject to active attacks when sending SMTP
798 clients elect to make use of the provider's TLSA records.
800 When the MX records are not (DNSSEC) signed, an active attacker can
801 redirect SMTP clients to MX hosts of his choice. Such redirection is
802 tamper-evident when SMTP servers found via "insecure" MX records are
803 recorded as the next-hop relay in the MTA delivery logs in their
804 original (rather than CNAME expanded) form. Sending MTAs SHOULD log
805 unexpanded MX hostnames when these result from insecure MX lookups.
806 Any successful authentication via an insecurely determined MX host
807 MUST NOT be misrepresented in the mail logs as secure delivery to the
808 intended next-hop domain. When DANE TLS is mandatory (Section 6) for
809 a given destination, delivery MUST be delayed when the MX RRset is
810 not "secure".
812 Otherwise, assuming no DNS errors (Section 2.1.1), the MX RRset is
813 "secure", and the SMTP client MUST treat each MX hostname as a
814 separate non-MX destination for opportunistic DANE TLS as described
815 in Section 2.2.2. When, for a given MX hostname, no TLSA records are
816 found, or only "insecure" TLSA records are found, DANE TLSA is not
817 applicable with the SMTP server in question and delivery proceeds to
818 that host as with pre-DANE opportunistic TLS. To avoid downgrade
819 attacks, any errors during TLSA lookups MUST, as explained in
820 Section 2.1.1, cause the SMTP server in question to be treated as
821 unreachable.
8232.2.2. Non-MX destinations
825 This section describes the algorithm used to locate the TLSA records
826 and associated TLSA base domain for an input domain not subject to MX
827 resolution. Such domains include:
829 o Each MX hostname used in a message delivery attempt for an
830 original next-hop destination domain subject to MX resolution.
831 Note, MTAs are not obligated to support CNAME expansion of MX
832 hostnames.
834 o Any administrator configured relay hostname, not subject to MX
835 resolution. This frequently involves configuration set by the MTA
836 administrator to handle some or all mail.
840Dukhovni & Hardaker Expires February 18, 2015 [Page 15]
842Internet-Draft SMTP security via opportunistic DANE TLS August 2014
845 o A next-hop destination domain subject to MX resolution that has no
846 MX records. In this case the domain's name is implicitly also its
847 sole SMTP server name.
849 Note that DNS queries with type TLSA are mishandled by load balancing
850 nameservers that serve the MX hostnames of some large email
851 providers. The DNS zones served by these nameservers are not signed
852 and contain no TLSA records, but queries for TLSA records fail,
853 rather than returning the non-existence of the requested TLSA
854 records.
856 To avoid problems delivering mail to domains whose SMTP servers are
857 served by the problem nameservers the SMTP client MUST perform any A
858 and/or AAAA queries for the destination before attempting to locate
859 the associated TLSA records. This lookup is needed in any case to
860 determine whether the destination domain is reachable and the DNSSEC
861 validation status of the chain of CNAME queries required to reach the
862 ultimate address records.
864 If no address records are found, the destination is unreachable. If
865 address records are found, but the DNSSEC validation status of the
866 first query response is "insecure" (see Section 2.1.3), the SMTP
867 client SHOULD NOT proceed to search for any associated TLSA records.
868 With the problem domains, TLSA queries will lead to DNS lookup errors
869 and cause messages to be consistently delayed and ultimately returned
870 to the sender. We don't expect to find any "secure" TLSA records
871 associated with a TLSA base domain that lies in an unsigned DNS zone.
872 Therefore, skipping TLSA lookups in this case will also reduce
873 latency with no detrimental impact on security.
875 If the A and/or AAAA lookup of the "initial name" yields a CNAME, we
876 replace it with the resulting name as if it were the initial name and
877 perform a lookup again using the new name. This replacement is
878 performed recursively (up to the MTA's recursion limit).
880 We consider the following cases for handling a DNS response for an A
881 or AAAA DNS lookup:
883 Not found: When the DNS queries for A and/or AAAA records yield
884 neither a list of addresses nor a CNAME (or CNAME expansion is not
885 supported) the destination is unreachable.
896Dukhovni & Hardaker Expires February 18, 2015 [Page 16]
898Internet-Draft SMTP security via opportunistic DANE TLS August 2014
901 Non-CNAME: The answer is not a CNAME alias. If the address RRset
902 is "secure", TLSA lookups are performed as described in
903 Section 2.2.3 with the initial name as the candidate TLSA base
904 domain. If no "secure" TLSA records are found, DANE TLS is not
905 applicable and mail delivery proceeds with pre-DANE opportunistic
906 TLS (which, being best-effort, degrades to cleartext delivery when
907 STARTTLS is not available or the TLS handshake fails).
909 Insecure CNAME: The input domain is a CNAME alias, but the ultimate
910 network address RRset is "insecure" (see Section 2.1.1). If the
911 initial CNAME response is also "insecure", DANE TLS does not
912 apply. Otherwise, this case is treated just like the non-CNAME
913 case above, where a search is performed for a TLSA record with the
914 original input domain as the candidate TLSA base domain.
916 Secure CNAME: The input domain is a CNAME alias, and the ultimate
917 network address RRset is "secure" (see Section 2.1.1). Two
918 candidate TLSA base domains are tried: the fully CNAME-expanded
919 initial name and, failing that, then the initial name itself.
921 In summary, if it is possible to securely obtain the full, CNAME-
922 expanded, DNSSEC-validated address records for the input domain, then
923 that name is the preferred TLSA base domain. Otherwise, the
924 unexpanded input-MX domain is the candidate TLSA base domain. When
925 no "secure" TLSA records are found at either the CNAME-expanded or
926 unexpanded domain, then DANE TLS does not apply for mail delivery via
927 the input domain in question. And, as always, errors, bogus or
928 indeterminate results for any query in the process MUST result in
929 delaying or abandoning delivery.
9312.2.3. TLSA record lookup
933 Each candidate TLSA base domain (the original or fully CNAME-expanded
934 name of a non-MX destination or a particular MX hostname of an MX
935 destination) is in turn prefixed with service labels of the form
936 "_<port>._tcp". The resulting domain name is used to issue a DNSSEC
937 query with the query type set to TLSA ([RFC6698] Section 7.1).
939 For SMTP, the destination TCP port is typically 25, but this may be
940 different with custom routes specified by the MTA administrator in
941 which case the SMTP client MUST use the appropriate number in the
942 "_<port>" prefix in place of "_25". If, for example, the candidate
943 base domain is "mx.example.com", and the SMTP connection is to port
944 25, the TLSA RRset is obtained via a DNSSEC query of the form:
946 _25._tcp.mx.example.com. IN TLSA ?
952Dukhovni & Hardaker Expires February 18, 2015 [Page 17]
954Internet-Draft SMTP security via opportunistic DANE TLS August 2014
957 The query response may be a CNAME, or the actual TLSA RRset. If the
958 response is a CNAME, the SMTP client (through the use of its
959 security-aware stub resolver) restarts the TLSA query at the target
960 domain, following CNAMEs as appropriate and keeping track of whether
961 the entire chain is "secure". If any "insecure" records are
962 encountered, or the TLSA records don't exist, the next candidate TLSA
963 base domain is tried instead.
965 If the ultimate response is a "secure" TLSA RRset, then the candidate
966 TLSA base domain will be the actual TLSA base domain and the TLSA
967 RRset will constitute the TLSA records for the destination. If none
968 of the candidate TLSA base domains yield "secure" TLSA records then
969 delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients
970 MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades
971 or even to skip SMTP servers that fail authentication, but MUST NOT
972 misrepresent authentication success as either a secure connection to
973 the SMTP server or as a secure delivery to the intended next-hop
974 domain.
976 TLSA record publishers may leverage CNAMEs to reference a single
977 authoritative TLSA RRset specifying a common Certification Authority
978 or a common end entity certificate to be used with multiple TLS
979 services. Such CNAME expansion does not change the SMTP client's
980 notion of the TLSA base domain; thus, when _25._tcp.mx.example.com is
981 a CNAME, the base domain remains mx.example.com and this is still the
982 reference identifier used together with the next-hop domain in peer
983 certificate name checks.
985 Note that shared end entity certificate associations expose the
986 publishing domain to substitution attacks, where an MITM attacker can
987 reroute traffic to a different server that shares the same end entity
988 certificate. Such shared end entity TLSA records SHOULD be avoided
989 unless the servers in question are functionally equivalent or employ
990 mutually incompatible protocols (an active attacker gains nothing by
991 diverting client traffic from one such server to another).
993 A better example, employing a shared trust anchor rather than shared
994 end-entity certificates, is illustrated by the DNSSEC validated
995 records below:
997 example.com. IN MX 0 mx1.example.com.
998 example.com. IN MX 0 mx2.example.com.
999 _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
1000 _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
1001 tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c149a...
1003 The SMTP servers mx1.example.com and mx2.example.com will be expected
1004 to have certificates issued under a common trust anchor, but each MX
1008Dukhovni & Hardaker Expires February 18, 2015 [Page 18]
1010Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1013 hostname's TLSA base domain remains unchanged despite the above CNAME
1014 records. Correspondingly, each SMTP server will be associated with a
1015 pair of reference identifiers consisting of its hostname plus the
1016 next-hop domain "example.com".
1018 If, during TLSA resolution (including possible CNAME indirection), at
1019 least one "secure" TLSA record is found (even if not usable because
1020 it is unsupported by the implementation or support is
1021 administratively disabled), then the corresponding host has signaled
1022 its commitment to implement TLS. The SMTP client MUST NOT deliver
1023 mail via the corresponding host unless a TLS session is negotiated
1024 via STARTTLS. This is required to avoid MITM STARTTLS downgrade
1025 attacks.
1027 As noted previously (in Section Section 2.2.2), when no "secure" TLSA
1028 records are found at the fully CNAME-expanded name, the original
1029 unexpanded name MUST be tried instead. This supports customers of
1030 hosting providers where the provider's zone cannot be validated with
1031 DNSSEC, but the customer has shared appropriate key material with the
1032 hosting provider to enable TLS via SNI. Intermediate names that
1033 arise during CNAME expansion that are neither the original, nor the
1034 final name, are never candidate TLSA base domains, even if "secure".
10363. DANE authentication
1038 This section describes which TLSA records are applicable to SMTP
1039 opportunistic DANE TLS and how to apply such records to authenticate
1040 the SMTP server. With opportunistic DANE TLS, both the TLS support
1041 implied by the presence of DANE TLSA records and the verification
1042 parameters necessary to authenticate the TLS peer are obtained
1043 together. In contrast to protocols where channel security policy is
1044 set exclusively by the client, authentication via this protocol is
1045 expected to be less prone to connection failure caused by
1046 incompatible configuration of the client and server.
10483.1. TLSA certificate usages
1050 The DANE TLSA specification [RFC6698] defines multiple TLSA RR types
1051 via combinations of 3 numeric parameters. The numeric values of
1052 these parameters were later given symbolic names in [RFC7218]. The
1053 rest of the TLSA record is the "certificate association data field",
1054 which specifies the full or digest value of a certificate or public
1055 key. The parameters are:
1064Dukhovni & Hardaker Expires February 18, 2015 [Page 19]
1066Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1069 The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698]
1070 specifies four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and
1071 DANE-EE(3). There is an additional private-use value:
1072 PrivCert(255). All other values are reserved for use by future
1073 specifications.
1075 The selector field: Section 2.1.2 of [RFC6698] specifies two values:
1076 Cert(0) and SPKI(1). There is an additional private-use value:
1077 PrivSel(255). All other values are reserved for use by future
1078 specifications.
1080 The matching type field: Section 2.1.3 of [RFC6698] specifies three
1081 values: Full(0), SHA2-256(1) and SHA2-512(2). There is an
1082 additional private-use value: PrivMatch(255). All other values
1083 are reserved for use by future specifications.
1085 We may think of TLSA Certificate Usage values 0 through 3 as a
1086 combination of two one-bit flags. The low bit chooses between trust
1087 anchor (TA) and end entity (EE) certificates. The high bit chooses
1088 between public PKI issued and domain-issued certificates.
1090 The selector field specifies whether the TLSA RR matches the whole
1091 certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1). The
1092 subjectPublicKeyInfo is an ASN.1 DER ([X.690]) encoding of the
1093 certificate's algorithm id, any parameters and the public key data.
1095 The matching type field specifies how the TLSA RR Certificate
1096 Association Data field is to be compared with the certificate or
1097 public key. A value of Full(0) means an exact match: the full DER
1098 encoding of the certificate or public key is given in the TLSA RR. A
1099 value of SHA2-256(1) means that the association data matches the
1100 SHA2-256 digest of the certificate or public key, and likewise
1101 SHA2-512(2) means a SHA2-512 digest is used.
1103 Since opportunistic DANE TLS will be used by non-interactive MTAs,
1104 with no user to "press OK" when authentication fails, reliability of
1105 peer authentication is paramount. Server operators are advised to
1106 publish TLSA records that are least likely to fail authentication due
1107 to interoperability or operational problems. Because DANE TLS relies
1108 on coordinated changes to DNS and SMTP server settings, the best
1109 choice of records to publish will depend on site-specific practices.
1120Dukhovni & Hardaker Expires February 18, 2015 [Page 20]
1122Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1125 The certificate usage element of a TLSA record plays a critical role
1126 in determining how the corresponding certificate association data
1127 field is used to authenticate server's certificate chain. The next
1128 two subsections explain the process for certificate usages DANE-EE(3)
1129 and DANE-TA(2). The third subsection briefly explains why
1130 certificate usages PKIX-TA(0) and PKIX-EE(1) are not applicable with
1131 opportunistic DANE TLS.
1133 In summary, we recommend the use of either "DANE-EE(3) SPKI(1)
1134 SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
1135 depending on site needs. Other combinations of TLSA parameters are
1136 either explicitly unsupported, or offer little to recommend them over
1137 these two.
1139 The mandatory to support digest algorithm in [RFC6698] is
1140 SHA2-256(1). When the server's TLSA RRset includes records with a
1141 matching type indicating a digest record (i.e., a value other than
1142 Full(0)), a TLSA record with a SHA2-256(1) matching type SHOULD be
1143 provided along with any other digest published, since some SMTP
1144 clients may support only SHA2-256(1). If at some point the SHA2-256
1145 digest algorithm is tarnished by new cryptanalytic attacks,
1146 publishers will need to include an appropriate stronger digest in
1147 their TLSA records, initially along with, and ultimately in place of,
1148 SHA2-256.
11503.1.1. Certificate usage DANE-EE(3)
1152 Authentication via certificate usage DANE-EE(3) TLSA records involves
1153 simply checking that the server's leaf certificate matches the TLSA
1154 record. In particular the binding of the server public key to its
1155 name is based entirely on the TLSA record association. The server
1156 MUST be considered authenticated even if none of the names in the
1157 certificate match the client's reference identity for the server.
1159 Similarly, the expiration date of the server certificate MUST be
1160 ignored, the validity period of the TLSA record key binding is
1161 determined by the validity interval of the TLSA record DNSSEC
1162 signature.
1164 With DANE-EE(3) servers need not employ SNI (may ignore the client's
1165 SNI message) even when the server is known under independent names
1166 that would otherwise require separate certificates. It is instead
1167 sufficient for the TLSA RRsets for all the domains in question to
1168 match the server's default certificate. Of course with SMTP servers
1169 it is simpler still to publish the same MX hostname for all the
1170 hosted domains.
1176Dukhovni & Hardaker Expires February 18, 2015 [Page 21]
1178Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1181 For domains where it is practical to make coordinated changes in DNS
1182 TLSA records during SMTP server key rotation, it is often best to
1183 publish end-entity DANE-EE(3) certificate associations. DANE-EE(3)
1184 certificates don't suddenly stop working when leaf or intermediate
1185 certificates expire, and don't fail when the server operator neglects
1186 to configure all the required issuer certificates in the server
1187 certificate chain.
1189 TLSA records published for SMTP servers SHOULD, in most cases, be
1190 "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE
1191 implementations are required to support SHA2-256, this record type
1192 works for all clients and need not change across certificate renewals
1193 with the same key.
11953.1.2. Certificate usage DANE-TA(2)
1197 Some domains may prefer to avoid the operational complexity of
1198 publishing unique TLSA RRs for each TLS service. If the domain
1199 employs a common issuing Certification Authority to create
1200 certificates for multiple TLS services, it may be simpler to publish
1201 the issuing authority as a trust anchor (TA) for the certificate
1202 chains of all relevant services. The TLSA query domain (TLSA base
1203 domain with port and protocol prefix labels) for each service issued
1204 by the same TA may then be set to a CNAME alias that points to a
1205 common TLSA RRset that matches the TA. For example:
1207 example.com. IN MX 0 mx1.example.com.
1208 example.com. IN MX 0 mx2.example.com.
1209 _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
1210 _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
1211 tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14....
1213 With usage DANE-TA(2) the server certificates will need to have names
1214 that match one of the client's reference identifiers (see [RFC6125]).
1215 The server MAY employ SNI to select the appropriate certificate to
1216 present to the client.
1218 SMTP servers that rely on certificate usage DANE-TA(2) TLSA records
1219 for TLS authentication MUST include the TA certificate as part of the
1220 certificate chain presented in the TLS handshake server certificate
1221 message even when it is a self-signed root certificate. At this
1222 time, many SMTP servers are not configured with a comprehensive list
1223 of trust anchors, nor are they expected to at any point in the
1224 future. Some MTAs will ignore all locally trusted certificates when
1225 processing usage DANE-TA(2) TLSA records. Thus even when the TA
1226 happens to be a public Certification Authority known to the SMTP
1227 client, authentication is likely to fail unless the TA certificate is
1228 included in the TLS server certificate message.
1232Dukhovni & Hardaker Expires February 18, 2015 [Page 22]
1234Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1237 TLSA records with selector Full(0) are discouraged. While these
1238 potentially obviate the need to transmit the TA certificate in the
1239 TLS server certificate message, client implementations may not be
1240 able to augment the server certificate chain with the data obtained
1241 from DNS, especially when the TLSA record supplies a bare key
1242 (selector SPKI(1)). Since the server will need to transmit the TA
1243 certificate in any case, server operators SHOULD publish TLSA records
1244 with a selector other than Full(0) and avoid potential
1245 interoperability issues with large TLSA records containing full
1246 certificates or keys.
1248 TLSA Publishers employing DANE-TA(2) records SHOULD publish records
1249 with a selector of Cert(0). Such TLSA records are associated with
1250 the whole trust anchor certificate, not just with the trust anchor
1251 public key. In particular, the SMTP client SHOULD then apply any
1252 relevant constraints from the trust anchor certificate, such as, for
1253 example, path length constraints.
1255 While a selector of SPKI(1) may also be employed, the resulting TLSA
1256 record will not specify the full trust anchor certificate content,
1257 and elements of the trust anchor certificate other than the public
1258 key become mutable. This may, for example, allow a subsidiary CA to
1259 issue a chain that violates the trust anchor's path length or name
1260 constraints.
12623.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1)
1264 As noted in the introduction, SMTP clients cannot, without relying on
1265 DNSSEC for secure MX records and DANE for STARTTLS support signaling,
1266 perform server identity verification or prevent STARTTLS downgrade
1267 attacks. The use of PKIX CAs offers no added security since an
1268 attacker capable of compromising DNSSEC is free to replace any PKIX-
1269 TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient
1270 non-PKIX certificate usage.
1272 SMTP servers SHOULD NOT publish TLSA RRs with certificate usage PKIX-
1273 TA(0) or PKIX-EE(1). SMTP clients cannot be expected to be
1274 configured with a suitably complete set of trusted public CAs.
1275 Lacking a complete set of public CAs, clients would not be able to
1276 verify the certificates of SMTP servers whose issuing root CAs are
1277 not trusted by the client.
1279 Opportunistic DANE TLS needs to interoperate without bilateral
1280 coordination of security settings between client and server systems.
1281 Therefore, parameter choices that are fragile in the absence of
1282 bilateral coordination are unsupported. Nothing is lost since the
1283 PKIX certificate usages cannot aid SMTP TLS security, they can only
1284 impede SMTP TLS interoperability.
1288Dukhovni & Hardaker Expires February 18, 2015 [Page 23]
1290Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1293 SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0)
1294 or PKIX-EE(1) is undefined. SMTP clients should generally treat such
1295 TLSA records as unusable.
12973.2. Certificate matching
1299 When at least one usable "secure" TLSA record is found, the SMTP
1300 client MUST use TLSA records to authenticate the SMTP server.
1301 Messages MUST NOT be delivered via the SMTP server if authentication
1302 fails, otherwise the SMTP client is vulnerable to MITM attacks.
13043.2.1. DANE-EE(3) name checks
1306 The SMTP client MUST NOT perform certificate name checks with
1307 certificate usage DANE-EE(3); see Section 3.1.1 above.
13093.2.2. DANE-TA(2) name checks
1311 To match a server via a TLSA record with certificate usage DANE-
1312 TA(2), the client MUST perform name checks to ensure that it has
1313 reached the correct server. In all DANE-TA(2) cases the SMTP client
1314 MUST include the TLSA base domain as one of the valid reference
1315 identifiers for matching the server certificate.
1317 TLSA records for MX hostnames: If the TLSA base domain was obtained
1318 indirectly via a "secure" MX lookup (including any CNAME-expanded
1319 name of an MX hostname), then the original next-hop domain used in
1320 the MX lookup MUST be included as as a second reference
1321 identifier. The CNAME-expanded original next-hop domain MUST be
1322 included as a third reference identifier if different from the
1323 original next-hop domain. When the client MTA is employing DANE
1324 TLS security despite "insecure" MX redirection the MX hostname is
1325 the only reference identifier.
1327 TLSA records for Non-MX hostnames: If MX records were not used
1328 (e.g., if none exist) and the TLSA base domain is the CNAME-
1329 expanded original next-hop domain, then the original next-hop
1330 domain MUST be included as a second reference identifier.
1332 Accepting certificates with the original next-hop domain in addition
1333 to the MX hostname allows a domain with multiple MX hostnames to
1334 field a single certificate bearing a single domain name (i.e., the
1335 email domain) across all the SMTP servers. This also aids
1336 interoperability with pre-DANE SMTP clients that are configured to
1337 look for the email domain name in server certificates. For example,
1338 with "secure" DNS records as below:
1344Dukhovni & Hardaker Expires February 18, 2015 [Page 24]
1346Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1349 exchange.example.org. IN CNAME mail.example.org.
1350 mail.example.org. IN CNAME example.com.
1351 example.com. IN MX 10 mx10.example.com.
1352 example.com. IN MX 15 mx15.example.com.
1353 example.com. IN MX 20 mx20.example.com.
1354 ;
1355 mx10.example.com. IN A
1356 _25._tcp.mx10.example.com. IN TLSA 2 0 1 ...
1357 ;
1358 mx15.example.com. IN CNAME mxbackup.example.com.
1359 mxbackup.example.com. IN A
1360 ; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
1361 _25._tcp.mx15.example.com. IN TLSA 2 0 1 ...
1362 ;
1363 mx20.example.com. IN CNAME mxbackup.example.net.
1364 mxbackup.example.net. IN A
1365 _25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...
1367 Certificate name checks for delivery of mail to exchange.example.org
1368 via any of the associated SMTP servers MUST accept at least the names
1369 "exchange.example.org" and "example.com", which are respectively the
1370 original and fully expanded next-hop domain. When the SMTP server is
1371 mx10.example.com, name checks MUST accept the TLSA base domain
1372 "mx10.example.com". If, despite the fact that MX hostnames are
1373 required to not be aliases, the MTA supports delivery via
1374 "mx15.example.com" or "mx20.example.com" then name checks MUST accept
1375 the respective TLSA base domains "mx15.example.com" and
1376 "mxbackup.example.net".
13783.2.3. Reference identifier matching
1380 When name checks are applicable (certificate usage DANE-TA(2)), if
1381 the server certificate contains a Subject Alternative Name extension
1382 ([RFC5280]), with at least one DNS-ID ([RFC6125]) then only the DNS-
1383 IDs are matched against the client's reference identifiers. The CN-
1384 ID ([RFC6125]) is only considered when no DNS-IDs are present. The
1385 server certificate is considered matched when one of its presented
1386 identifiers ([RFC5280]) matches any of the client's reference
1387 identifiers.
1389 Wildcards are valid in either DNS-IDs or the CN-ID when applicable.
1390 The wildcard character must be entire first label of the DNS-ID or
1391 CN-ID. Thus, "*.example.com" is valid, while "smtp*.example.com" and
1392 "*smtp.example.com" are not. SMTP clients MUST support wildcards
1393 that match the first label of the reference identifier, with the
1394 remaining labels matching verbatim. For example, the DNS-ID
1395 "*.example.com" matches the reference identifier "mx1.example.com".
1396 SMTP clients MAY, subject to local policy allow wildcards to match
1400Dukhovni & Hardaker Expires February 18, 2015 [Page 25]
1402Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1405 multiple reference identifier labels, but servers cannot expect broad
1406 support for such a policy. Therefore any wildcards in server
1407 certificates SHOULD match exactly one label in either the TLSA base
1408 domain or the next-hop domain.
14104. Server key management
1412 Two TLSA records MUST be published before employing a new EE or TA
1413 public key or certificate, one matching the currently deployed key
1414 and the other matching the new key scheduled to replace it. Once
1415 sufficient time has elapsed for all DNS caches to expire the previous
1416 TLSA RRset and related signature RRsets, servers may be configured to
1417 use the new EE private key and associated public key certificate or
1418 may employ certificates signed by the new trust anchor.
1420 Once the new public key or certificate is in use, the TLSA RR that
1421 matches the retired key can be removed from DNS, leaving only RRs
1422 that match keys or certificates in active use.
1424 As described in Section 3.1.2, when server certificates are validated
1425 via a DANE-TA(2) trust anchor, and CNAME records are employed to
1426 store the TA association data at a single location, the
1427 responsibility of updating the TLSA RRset shifts to the operator of
1428 the trust anchor. Before a new trust anchor is used to sign any new
1429 server certificates, its certificate (digest) is added to the
1430 relevant TLSA RRset. After enough time elapses for the original TLSA
1431 RRset to age out of DNS caches, the new trust anchor can start
1432 issuing new server certificates. Once all certificates issued under
1433 the previous trust anchor have expired, its associated RRs can be
1434 removed from the TLSA RRset.
1436 In the DANE-TA(2) key management model server operators do not
1437 generally need to update DNS TLSA records after initially creating a
1438 CNAME record that references the centrally operated DANE-TA(2) RRset.
1439 If a particular server's key is compromised, its TLSA CNAME SHOULD be
1440 replaced with a DANE-EE(3) association until the certificate for the
1441 compromised key expires, at which point it can return to using a
1442 CNAME record. If the central trust anchor is compromised, all
1443 servers need to be issued new keys by a new TA, and an updated DANE-
1444 TA(2) TLSA RRset needs to be published containing just the new TA.
1446 SMTP servers cannot expect broad CRL or OCSP support from SMTP
1447 clients. As outlined above, with DANE, compromised server or trust
1448 anchor keys can be "revoked" by removing them from the DNS without
1449 the need for client-side support for OCSP or CRLs.
14515. Digest algorithm agility
1456Dukhovni & Hardaker Expires February 18, 2015 [Page 26]
1458Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1461 While [RFC6698] specifies multiple digest algorithms, it does not
1462 specify a protocol by which the SMTP client and TLSA record publisher
1463 can agree on the strongest shared algorithm. Such a protocol would
1464 allow the client and server to avoid exposure to any deprecated
1465 weaker algorithms that are published for compatibility with less
1466 capable clients, but should be ignored when possible. Such a
1467 protocol is specified in [I-D.ietf-dane-ops]. SMTP clients and
1468 servers that implement this specification MUST comply with the
1469 requirements outlined under "Digest Algorithm Agility" in
1470 [I-D.ietf-dane-ops].
14726. Mandatory TLS Security
1474 An MTA implementing this protocol may require a stronger security
1475 assurance when sending email to selected destinations. The sending
1476 organization may need to send sensitive email and/or may have
1477 regulatory obligations to protect its content. This protocol is not
1478 in conflict with such a requirement, and in fact can often simplify
1479 authenticated delivery to such destinations.
1481 Specifically, with domains that publish DANE TLSA records for their
1482 MX hostnames, a sending MTA can be configured to use the receiving
1483 domains's DANE TLSA records to authenticate the corresponding SMTP
1484 server. Authentication via DANE TLSA records is easier to manage, as
1485 changes in the receiver's expected certificate properties are made on
1486 the receiver end and don't require manually communicated
1487 configuration changes. With mandatory DANE TLS, when no usable TLSA
1488 records are found, message delivery is delayed. Thus, mail is only
1489 sent when an authenticated TLS channel is established to the remote
1490 SMTP server.
1492 Administrators of mail servers that employ mandatory DANE TLS, need
1493 to carefully monitor their mail logs and queues. If a partner domain
1494 unwittingly misconfigures their TLSA records, disables DNSSEC, or
1495 misconfigures SMTP server certificate chains, mail will be delayed
1496 and may bounce if the issue is not resolved in a timely manner.
14987. Note on DANE for Message User Agents
1500 We note that the SMTP protocol is also used between Message User
1501 Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In
1502 [RFC6186] a protocol is specified that enables an MUA to dynamically
1503 locate the MSA based on the user's email address. SMTP connection
1504 security considerations for MUAs implementing [RFC6186] are largely
1505 analogous to connection security requirements for MTAs, and this
1506 specification could be applied largely verbatim with DNS MX records
1507 replaced by corresponding DNS Service (SRV) records
1508 [I-D.ietf-dane-srv].
1512Dukhovni & Hardaker Expires February 18, 2015 [Page 27]
1514Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1517 However, until MUAs begin to adopt the dynamic configuration
1518 mechanisms of [RFC6186] they are adequately served by more
1519 traditional static TLS security policies. Specification of DANE TLS
1520 for Message User Agent (MUA) to Message Submission Agent (MSA) SMTP
1521 is left to future documents that focus specifically on SMTP security
1522 between MUAs and MSAs.
15248. Interoperability considerations
15268.1. SNI support
1528 To ensure that the server sends the right certificate chain, the SMTP
1529 client MUST send the TLS SNI extension containing the TLSA base
1530 domain. This precludes the use of the backward compatible SSL 2.0
1531 compatible SSL HELLO by the SMTP client. The minimum SSL/TLS client
1532 HELLO version for SMTP clients performing DANE authentication is SSL
1533 3.0, but a client that offers SSL 3.0 MUST also offer at least TLS
1534 1.0 and MUST include the SNI extension. Servers that don't make use
1535 of SNI MAY negotiate SSL 3.0 if offered by the client.
1537 Each SMTP server MUST present a certificate chain (see [RFC5246]
1538 Section 7.4.2) that matches at least one of the TLSA records. The
1539 server MAY rely on SNI to determine which certificate chain to
1540 present to the client. Clients that don't send SNI information may
1541 not see the expected certificate chain.
1543 If the server's TLSA records match the server's default certificate
1544 chain, the server need not support SNI. In either case, the server
1545 need not include the SNI extension in its TLS HELLO as simply
1546 returning a matching certificate chain is sufficient. Servers MUST
1547 NOT enforce the use of SNI by clients, as the client may be using
1548 unauthenticated opportunistic TLS and may not expect any particular
1549 certificate from the server. If the client sends no SNI extension,
1550 or sends an SNI extension for an unsupported domain, the server MUST
1551 simply send some fallback certificate chain of its choice. The
1552 reason for not enforcing strict matching of the requested SNI
1553 hostname is that DANE TLS clients are typically willing to accept
1554 multiple server names, but can only send one name in the SNI
1555 extension. The server's fallback certificate may match a different
1556 name acceptable to the client, e.g., the original next-hop domain.
15588.2. Anonymous TLS cipher suites
1560 Since many SMTP servers either do not support or do not enable any
1561 anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD
1562 offer to negotiate a typical set of non-anonymous cipher suites
1563 required for interoperability with such servers. An SMTP client
1564 employing pre-DANE opportunistic TLS MAY in addition include one or
1568Dukhovni & Hardaker Expires February 18, 2015 [Page 28]
1570Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1573 more anonymous TLS cipher suites in its TLS HELLO. SMTP servers,
1574 that need to interoperate with opportunistic TLS clients SHOULD be
1575 prepared to interoperate with such clients by either always selecting
1576 a mutually supported non-anonymous cipher suite or by correctly
1577 handling client connections that negotiate anonymous cipher suites.
1579 Note that while SMTP server operators are under no obligation to
1580 enable anonymous cipher suites, no security is gained by sending
1581 certificates to clients that will ignore them. Indeed support for
1582 anonymous cipher suites in the server makes audit trails more
1583 informative. Log entries that record connections that employed an
1584 anonymous cipher suite record the fact that the clients did not care
1585 to authenticate the server.
15879. Operational Considerations
15899.1. Client Operational Considerations
1591 An operational error on the sending or receiving side that cannot be
1592 corrected in a timely manner may, at times, lead to consistent
1593 failure to deliver time-sensitive email. The sending MTA
1594 administrator may have to choose between letting email queue until
1595 the error is resolved and disabling opportunistic or mandatory DANE
1596 TLS for one or more destinations. The choice to disable DANE TLS
1597 security should not be made lightly. Every reasonable effort should
1598 be made to determine that problems with mail delivery are the result
1599 of an operational error, and not an attack. A fallback strategy may
1600 be to configure explicit out-of-band TLS security settings if
1601 supported by the sending MTA.
1603 SMTP clients may deploy opportunistic DANE TLS incrementally by
1604 enabling it only for selected sites, or may occasionally need to
1605 disable opportunistic DANE TLS for peers that fail to interoperate
1606 due to misconfiguration or software defects on either end. Some
1607 implementations MAY support DANE TLS in an "audit only" mode in which
1608 failure to achieve the requisite security level is logged as a
1609 warning and delivery proceeds at a reduced security level. Unless
1610 local policy specifies "audit only" or that opportunistic DANE TLS is
1611 not to be used for a particular destination, an SMTP client MUST NOT
1612 deliver mail via a server whose certificate chain fails to match at
1613 least one TLSA record when usable TLSA records are found for that
1614 server.
1624Dukhovni & Hardaker Expires February 18, 2015 [Page 29]
1626Internet-Draft SMTP security via opportunistic DANE TLS August 2014
16299.2. Publisher Operational Considerations
1631 SMTP servers that publish certificate usage DANE-TA(2) associations
1632 MUST include the TA certificate in their TLS server certificate
1633 chain, even when that TA certificate is a self-signed root
1634 certificate.
1636 TLSA Publishers MUST follow the guidelines in the "TLSA Publisher
1637 Requirements" section of [I-D.ietf-dane-ops].
1639 TLSA Publishers SHOULD follow the TLSA publication size guidance
1640 found in [I-D.ietf-dane-ops] under "DANE DNS Record Size Guidelines".
164210. Security Considerations
1644 This protocol leverages DANE TLSA records to implement MITM resistant
1645 opportunistic security ([I-D.dukhovni-opportunistic-security]) for
1646 SMTP. For destination domains that sign their MX records and publish
1647 signed TLSA records for their MX hostnames, this protocol allows
1648 sending MTAs to securely discover both the availability of TLS and
1649 how to authenticate the destination.
1651 This protocol does not aim to secure all SMTP traffic, as that is not
1652 practical until DNSSEC and DANE adoption are universal. The
1653 incremental deployment provided by following this specification is a
1654 best possible path for securing SMTP. This protocol coexists and
1655 interoperates with the existing insecure Internet email backbone.
1657 The protocol does not preclude existing non-opportunistic SMTP TLS
1658 security arrangements, which can continue to be used as before via
1659 manual configuration with negotiated out-of-band key and TLS
1660 configuration exchanges.
1662 Opportunistic SMTP TLS depends critically on DNSSEC for downgrade
1663 resistance and secure resolution of the destination name. If DNSSEC
1664 is compromised, it is not possible to fall back on the public CA PKI
1665 to prevent MITM attacks. A successful breach of DNSSEC enables the
1666 attacker to publish TLSA usage 3 certificate associations, and
1667 thereby bypass any security benefit the legitimate domain owner might
1668 hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of
1669 public CA PKI support in existing MTA deployments, avoiding
1670 certificate usages 0 and 1 simplifies implementation and deployment
1671 with no adverse security consequences.
1673 Implementations must strictly follow the portions of this
1674 specification that indicate when it is appropriate to initiate a non-
1675 authenticated connection or cleartext connection to a SMTP server.
1676 Specifically, in order to prevent downgrade attacks on this protocol,
1680Dukhovni & Hardaker Expires February 18, 2015 [Page 30]
1682Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1685 implementation must not initiate a connection when this specification
1686 indicates a particular SMTP server must be considered unreachable.
168811. IANA considerations
1690 This specification requires no support from IANA.
169212. Acknowledgements
1694 The authors would like to extend great thanks to Tony Finch, who
1695 started the original version of a DANE SMTP document. His work is
1696 greatly appreciated and has been incorporated into this document.
1697 The authors would like to additionally thank Phil Pennock for his
1698 comments and advice on this document.
1700 Acknowledgments from Viktor: Thanks to Paul Hoffman who motivated me
1701 to begin work on this memo and provided feedback on early drafts.
1702 Thanks to Patrick Koetter, Perry Metzger and Nico Williams for
1703 valuable review comments. Thanks also to Wietse Venema who created
1704 Postfix, and whose advice and feedback were essential to the
1705 development of the Postfix DANE implementation.
170713. References
170913.1. Normative References
1711 [I-D.ietf-dane-ops]
1712 Dukhovni, V. and W. Hardaker, "Updates to and Operational
1713 Guidance for the DANE Protocol", draft-ietf-dane-ops-06
1714 (work in progress), August 2014.
1716 [RFC1035] Mockapetris, P., "Domain names - implementation and
1717 specification", STD 13, RFC 1035, November 1987.
1719 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1720 Requirement Levels", BCP 14, RFC 2119, March 1997.
1722 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
1723 Transport Layer Security", RFC 3207, February 2002.
1725 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1726 Rose, "DNS Security Introduction and Requirements", RFC
1727 4033, March 2005.
1729 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1730 Rose, "Resource Records for the DNS Security Extensions",
1731 RFC 4034, March 2005.
1736Dukhovni & Hardaker Expires February 18, 2015 [Page 31]
1738Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1741 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1742 Rose, "Protocol Modifications for the DNS Security
1743 Extensions", RFC 4035, March 2005.
1745 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1746 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
1748 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1749 Housley, R., and W. Polk, "Internet X.509 Public Key
1750 Infrastructure Certificate and Certificate Revocation List
1751 (CRL) Profile", RFC 5280, May 2008.
1753 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1754 October 2008.
1756 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
1757 Extension Definitions", RFC 6066, January 2011.
1759 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1760 Verification of Domain-Based Application Service Identity
1761 within Internet Public Key Infrastructure Using X.509
1762 (PKIX) Certificates in the Context of Transport Layer
1763 Security (TLS)", RFC 6125, March 2011.
1765 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
1766 Submission/Access Services", RFC 6186, March 2011.
1768 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
1769 DNS", RFC 6672, June 2012.
1771 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
1772 of Named Entities (DANE) Transport Layer Security (TLS)
1773 Protocol: TLSA", RFC 6698, August 2012.
1775 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
1776 Conversations about DNS-Based Authentication of Named
1777 Entities (DANE)", RFC 7218, April 2014.
1779 [X.690] International Telecommunications Union, "Recommendation
1780 ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information
1781 technology - ASN.1 encoding rules: Specification of Basic
1782 Encoding Rules (BER), Canonical Encoding Rules (CER) and
1783 Distinguished Encoding Rules (DER)", July 2002.
178513.2. Informative References
1787 [I-D.dukhovni-opportunistic-security]
1792Dukhovni & Hardaker Expires February 18, 2015 [Page 32]
1794Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1797 Dukhovni, V., "Opportunistic Security: Some Protection
1798 Most of the Time", draft-dukhovni-opportunistic-
1799 security-03 (work in progress), August 2014.
1801 [I-D.ietf-dane-srv]
1802 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
1803 Based Authentication of Named Entities (DANE) TLSA Records
1804 with SRV Records", draft-ietf-dane-srv-07 (work in
1805 progress), July 2014.
1807 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
1808 2009.
1810 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
1811 STD 72, RFC 6409, November 2011.
1813Authors' Addresses
1815 Viktor Dukhovni
1816 Two Sigma
1818 Email: ietf-dane@dukhovni.org
1821 Wes Hardaker
1822 Parsons
1823 P.O. Box 382
1824 Davis, CA 95617
1825 US
1827 Email: ietf@hardakers.net
1848Dukhovni & Hardaker Expires February 18, 2015 [Page 33]