1 Internet Engineering Task Force (IETF) V. Dukhovni
2 Request for Comments: 7672 Two Sigma
3 Category: Standards Track W. Hardaker
4 ISSN: 2070-1721 Parsons
5 October 2015
6
7
8 SMTP Security via Opportunistic DNS-Based Authentication of Named
9 Entities (DANE) Transport Layer Security (TLS)
10
11 Abstract
12
13 This memo describes a downgrade-resistant protocol for SMTP transport
14 security between Message Transfer Agents (MTAs), based on the DNS-
15 Based Authentication of Named Entities (DANE) TLSA DNS record.
16 Adoption of this protocol enables an incremental transition of the
17 Internet email backbone to one using encrypted and authenticated
18 Transport Layer Security (TLS).
19
20 Status of This Memo
21
22 This is an Internet Standards Track document.
23
24 This document is a product of the Internet Engineering Task Force
25 (IETF). It represents the consensus of the IETF community. It has
26 received public review and has been approved for publication by the
27 Internet Engineering Steering Group (IESG). Further information on
28 Internet Standards is available in Section 2 of RFC 5741.
29
30 Information about the current status of this document, any errata,
31 and how to provide feedback on it may be obtained at
32 http://www.rfc-editor.org/info/rfc7672.
33
34 Copyright Notice
35
36 Copyright (c) 2015 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
38
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
48
49
50
51
52 Dukhovni & Hardaker Standards Track [Page 1]
53 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
54
55
56 Table of Contents
57
58 1. Introduction ....................................................3
59 1.1. Terminology ................................................4
60 1.2. Background .................................................6
61 1.3. SMTP Channel Security ......................................6
62 1.3.1. STARTTLS Downgrade Attack ...........................7
63 1.3.2. Insecure Server Name without DNSSEC .................7
64 1.3.3. Sender Policy Does Not Scale ........................8
65 1.3.4. Too Many Certification Authorities ..................9
66 2. Identifying Applicable TLSA Records .............................9
67 2.1. DNS Considerations .........................................9
68 2.1.1. DNS Errors, "Bogus" Responses, and
69 "Indeterminate" Responses ...........................9
70 2.1.2. DNS Error Handling .................................11
71 2.1.3. Stub Resolver Considerations .......................12
72 2.2. TLS Discovery .............................................13
73 2.2.1. MX Resolution ......................................14
74 2.2.2. Non-MX Destinations ................................16
75 2.2.3. TLSA Record Lookup .................................18
76 3. DANE Authentication ............................................20
77 3.1. TLSA Certificate Usages ...................................20
78 3.1.1. Certificate Usage DANE-EE(3) .......................21
79 3.1.2. Certificate Usage DANE-TA(2) .......................22
80 3.1.3. Certificate Usages PKIX-TA(0) and PKIX-EE(1) .......23
81 3.2. Certificate Matching ......................................24
82 3.2.1. DANE-EE(3) Name Checks .............................24
83 3.2.2. DANE-TA(2) Name Checks .............................24
84 3.2.3. Reference Identifier Matching ......................25
85 4. Server Key Management ..........................................26
86 5. Digest Algorithm Agility .......................................27
87 6. Mandatory TLS Security .........................................27
88 7. Note on DANE for Message User Agents ...........................28
89 8. Interoperability Considerations ................................28
90 8.1. SNI Support ...............................................28
91 8.2. Anonymous TLS Cipher Suites ...............................29
92 9. Operational Considerations .....................................29
93 9.1. Client Operational Considerations .........................29
94 9.2. Publisher Operational Considerations ......................30
95 10. Security Considerations .......................................30
96 11. References ....................................................31
97 11.1. Normative References .....................................31
98 11.2. Informative References ...................................33
99 Acknowledgements ..................................................34
100 Authors' Addresses ................................................34
101
102
103
104
105
106
107 Dukhovni & Hardaker Standards Track [Page 2]
108 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
109
110
111 1. Introduction
112
113 This memo specifies a new connection security model for Message
114 Transfer Agents (MTAs). This model is motivated by key features of
115 inter-domain SMTP delivery, principally, the fact that the
116 destination server is selected indirectly via DNS Mail Exchange (MX)
117 records and that neither email addresses nor MX hostnames signal a
118 requirement for either secure or cleartext transport. Therefore,
119 aside from a few manually configured exceptions, SMTP transport
120 security is, by necessity, opportunistic (for a definition of
121 "Opportunistic Security", see [RFC7435]).
122
123 This specification uses the presence of DANE TLSA records to securely
124 signal TLS support and to publish the means by which SMTP clients can
125 successfully authenticate legitimate SMTP servers. This becomes
126 "opportunistic DANE TLS" and is resistant to downgrade and
127 man-in-the-middle (MITM) attacks. It enables an incremental
128 transition of the email backbone to authenticated TLS delivery, with
129 increased global protection as adoption increases.
130
131 With opportunistic DANE TLS, traffic from SMTP clients to domains
132 that publish "usable" DANE TLSA records in accordance with this memo
133 is authenticated and encrypted. Traffic from legacy clients or to
134 domains that do not publish TLSA records will continue to be sent in
135 the same manner as before, via manually configured security,
136 (pre-DANE) opportunistic TLS, or just cleartext SMTP.
137
138 Problems with the existing use of TLS in MTA-to-MTA SMTP that
139 motivate this specification are described in Section 1.3. The
140 specification itself follows, in Sections 2 and 3, which describe,
141 respectively, how to locate and use DANE TLSA records with SMTP. In
142 Section 6, we discuss the application of DANE TLS to destinations for
143 which channel integrity and confidentiality are mandatory. In
144 Section 7, we briefly comment on the potential applicability of this
145 specification to Message User Agents.
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162 Dukhovni & Hardaker Standards Track [Page 3]
163 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
164
165
166 1.1. Terminology
167
168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
170 "OPTIONAL" in this document are to be interpreted as described in
171 [RFC2119].
172
173 The following terms or concepts are used throughout this document:
174
175 Man-in-the-middle (MITM) attack: Active modification of network
176 traffic by an adversary able to thereby compromise the
177 confidentiality or integrity of the data.
178
179 Downgrade attack: (From [RFC4949].) A type of MITM attack in which
180 the attacker can cause two parties, at the time they negotiate a
181 security association, to agree on a lower level of protection than
182 the highest level that could have been supported by both of them.
183
184 Downgrade-resistant: A protocol is "downgrade-resistant" if it
185 employs effective countermeasures against downgrade attacks.
186
187 "Secure", "bogus", "insecure", "indeterminate": DNSSEC validation
188 results, as defined in Section 4.3 of [RFC4035].
189
190 Validating security-aware stub resolver and non-validating
191 security-aware stub resolver:
192 Capabilities of the stub resolver in use, as defined in [RFC4033];
193 note that this specification requires the use of a security-aware
194 stub resolver.
195
196 (Pre-DANE) opportunistic TLS: Best-effort use of TLS that is
197 generally vulnerable to DNS forgery and STARTTLS downgrade
198 attacks. When a TLS-encrypted communication channel is not
199 available, message transmission takes place in the clear. MX
200 record indirection generally precludes authentication even when
201 TLS is available.
202
203 Opportunistic DANE TLS: Best-effort use of TLS that is resistant to
204 downgrade attacks for destinations with DNSSEC-validated TLSA
205 records. When opportunistic DANE TLS is determined to be
206 unavailable, clients should fall back to pre-DANE opportunistic
207 TLS. Opportunistic DANE TLS requires support for DNSSEC, DANE,
208 and STARTTLS on the client side, and STARTTLS plus a DNSSEC
209 published TLSA record on the server side.
210
211
212
213
214
215
216
217 Dukhovni & Hardaker Standards Track [Page 4]
218 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
219
220
221 Reference identifier: (Special case of [RFC6125] definition.) One
222 of the domain names associated by the SMTP client with the
223 destination SMTP server for performing name checks on the server
224 certificate. When name checks are applicable, at least one of the
225 reference identifiers MUST match an [RFC6125] DNS-ID (or, if none
226 are present, the [RFC6125] CN-ID) of the server certificate (see
227 Section 3.2.3).
228
229 MX hostname: The RRDATA of an MX record consists of a 16 bit
230 preference followed by a Mail Exchange domain name (see [RFC1035],
231 Section 3.3.9). We will use the term "MX hostname" to refer to
232 the latter, that is, the DNS domain name found after the
233 preference value in an MX record. Thus, an "MX hostname" is
234 specifically a reference to a DNS domain name rather than any host
235 that bears that name.
236
237 Delayed delivery: Email delivery is a multi-hop store-and-forward
238 process. When an MTA is unable to forward a message that may
239 become deliverable later, the message is queued and delivery is
240 retried periodically. Some MTAs may be configured with a fallback
241 next-hop destination that handles messages that the MTA would
242 otherwise queue and retry. When a fallback next-hop destination
243 is configured, messages that would otherwise have to be delayed
244 may be sent to the fallback next-hop destination instead. The
245 fallback destination may itself be subject to opportunistic or
246 mandatory DANE TLS (Section 6) as though it were the original
247 message destination.
248
249 Original next-hop destination: The logical destination for mail
250 delivery. By default, this is the domain portion of the recipient
251 address, but MTAs may be configured to forward mail for some or
252 all recipients via designated relays. The original next-hop
253 destination is, respectively, either the recipient domain or the
254 associated configured relay.
255
256 MTA: Message Transfer Agent ([RFC5598], Section 4.3.2).
257
258 MSA: Message Submission Agent ([RFC5598], Section 4.3.1).
259
260 MUA: Message User Agent ([RFC5598], Section 4.2.1).
261
262 RR: A DNS resource record as defined in [RFC1034], Section 3.6.
263
264 RRset: An RRset ([RFC2181], Section 5) is a group of DNS resource
265 records that share the same label, class, and type.
266
267
268
269
270
271
272 Dukhovni & Hardaker Standards Track [Page 5]
273 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
274
275
276 1.2. Background
277
278 The Domain Name System Security Extensions (DNSSEC) add data origin
279 authentication, data integrity, and data nonexistence proofs to the
280 Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034],
281 and [RFC4035].
282
283 As described in the introduction of [RFC6698], TLS authentication via
284 the existing public Certification Authority (CA) PKI suffers from an
285 overabundance of trusted parties capable of issuing certificates for
286 any domain of their choice. DANE leverages the DNSSEC infrastructure
287 to publish public keys and certificates for use with the Transport
288 Layer Security (TLS) [RFC5246] protocol via the "TLSA" DNS record
289 type. With DNSSEC, each domain can only vouch for the keys of its
290 delegated sub-domains.
291
292 The TLS protocol enables secure TCP communication. In the context of
293 this memo, channel security is assumed to be provided by TLS. Used
294 without authentication, TLS provides only privacy protection against
295 eavesdropping attacks. Otherwise, TLS also provides data origin
296 authentication to guard against MITM attacks.
297
298 1.3. SMTP Channel Security
299
300 With HTTPS, TLS employs X.509 certificates [RFC5280] issued by one of
301 the many CAs bundled with popular web browsers to allow users to
302 authenticate their "secure" websites. Before we specify a new DANE
303 TLS security model for SMTP, we will explain why a new security model
304 is needed. In the process, we will explain why the familiar HTTPS
305 security model is inadequate to protect inter-domain SMTP traffic.
306
307 The subsections below outline four key problems with applying
308 traditional Web PKI [RFC7435] to SMTP; these problems are addressed
309 by this specification. Since an SMTP channel security policy is not
310 explicitly specified in either the recipient address or the MX
311 record, a new signaling mechanism is required to indicate when
312 channel security is possible and should be used. The publication of
313 TLSA records allows server operators to securely signal to SMTP
314 clients that TLS is available and should be used. DANE TLSA makes it
315 possible to simultaneously discover which destination domains support
316 secure delivery via TLS and how to verify the authenticity of the
317 associated SMTP services, providing a path forward to ubiquitous SMTP
318 channel security.
319
320
321
322
323
324
325
326
327 Dukhovni & Hardaker Standards Track [Page 6]
328 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
329
330
331 1.3.1. STARTTLS Downgrade Attack
332
333 SMTP [RFC5321] is a single-hop protocol in a multi-hop store-and-
334 forward email delivery process. An SMTP envelope recipient address
335 does not correspond to a specific transport-layer endpoint address;
336 rather, at each relay hop, the transport-layer endpoint is the
337 next-hop relay, while the envelope recipient address typically
338 remains the same. Unlike HTTP and its corresponding secured version,
339 HTTPS, where the use of TLS is signaled via the URI scheme, email
340 recipient addresses do not directly signal transport security policy.
341 Indeed, no such signaling could work well with SMTP, since TLS
342 encryption of SMTP protects email traffic on a hop-by-hop basis while
343 email addresses could only express end-to-end policy.
344
345 With no mechanism available to signal transport security policy, SMTP
346 relays employ a best-effort "opportunistic" security model for TLS.
347 A single SMTP server TCP listening endpoint can serve both TLS and
348 non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS
349 command [RFC3207]. The server signals TLS support to the client over
350 a cleartext SMTP connection, and, if the client also supports TLS, it
351 may negotiate a TLS-encrypted channel to use for email transmission.
352 The server's indication of TLS support can be easily suppressed by an
353 MITM attacker. Thus, pre-DANE SMTP TLS security can be subverted by
354 simply downgrading a connection to cleartext. No TLS security
355 feature can prevent this. The attacker can simply disable TLS.
356
357 1.3.2. Insecure Server Name without DNSSEC
358
359 With SMTP, DNS MX records abstract the next-hop transport endpoint
360 and allow administrators to specify a set of target servers to which
361 SMTP traffic should be directed for a given domain.
362
363 A TLS client is vulnerable to MITM attacks unless it verifies that
364 the server's certificate binds the public key to a name that matches
365 one of the client's reference identifiers. A natural choice of
366 reference identifier is the server's domain name. However, with
367 SMTP, server names are not directly encoded in the recipient address;
368 instead, they are obtained indirectly via MX records. Without
369 DNSSEC, the MX lookup is vulnerable to MITM and DNS cache poisoning
370 attacks. Active attackers can forge DNS replies with fake MX records
371 and can redirect email to servers with names of their choice.
372 Therefore, secure verification of SMTP TLS certificates matching the
373 server name is not possible without DNSSEC.
374
375
376
377
378
379
380
381
382 Dukhovni & Hardaker Standards Track [Page 7]
383 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
384
385
386 One might try to harden TLS for SMTP against DNS attacks by using the
387 envelope recipient domain as a reference identifier and by requiring
388 each SMTP server to possess a trusted certificate for the envelope
389 recipient domain rather than the MX hostname. Unfortunately, this is
390 impractical, as email for many domains is handled by third parties
391 that are not in a position to obtain certificates for all the domains
392 they serve. Deployment of the Server Name Indication (SNI) extension
393 to TLS (see Section 3 of [RFC6066]) is no panacea, since SNI key
394 management is operationally challenging except when the email service
395 provider is also the domain's registrar and its certificate issuer;
396 this is rarely the case for email.
397
398 Since the recipient domain name cannot be used as the SMTP server
399 reference identifier, and neither can the MX hostname without DNSSEC,
400 large-scale deployment of authenticated TLS for SMTP requires that
401 the DNS be secure.
402
403 Since SMTP security depends critically on DNSSEC, it is important to
404 point out that SMTP with DANE is consequently the most conservative
405 possible trust model. It trusts only what must be trusted and no
406 more. Adding any other trusted actors to the mix can only reduce
407 SMTP security. A sender may choose to further harden DNSSEC for
408 selected high-value receiving domains by configuring explicit trust
409 anchors for those domains instead of relying on the chain of trust
410 from the root domain. However, detailed discussion of DNSSEC
411 security practices is out of scope for this document.
412
413 1.3.3. Sender Policy Does Not Scale
414
415 Sending systems are in some cases explicitly configured to use TLS
416 for mail sent to selected peer domains, but this requires configuring
417 sending MTAs with appropriate subject names or certificate content
418 digests from their peer domains. Due to the resulting administrative
419 burden, such statically configured SMTP secure channels are used
420 rarely (generally only between domains that make bilateral
421 arrangements with their business partners). Internet email, on the
422 other hand, requires regularly contacting new domains for which
423 security configurations cannot be established in advance.
424
425 The abstraction of the SMTP transport endpoint via DNS MX records,
426 often across organizational boundaries, limits the use of public CA
427 PKI with SMTP to a small set of sender-configured peer domains. With
428 little opportunity to use TLS authentication, sending MTAs are rarely
429 configured with a comprehensive list of trusted CAs. SMTP services
430 that support STARTTLS often deploy X.509 certificates that are
431 self-signed or issued by a private CA.
432
433
434
435
436
437 Dukhovni & Hardaker Standards Track [Page 8]
438 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
439
440
441 1.3.4. Too Many Certification Authorities
442
443 Even if it were generally possible to determine a secure server name,
444 the SMTP client would still need to verify that the server's
445 certificate chain is issued by a trusted CA (a trust anchor). MTAs
446 are not interactive applications where a human operator can make a
447 decision (wisely or otherwise) to selectively disable TLS security
448 policy when certificate chain verification fails. With no user to
449 "click OK", the MTA's list of public CA trust anchors would need to
450 be comprehensive in order to avoid bouncing mail addressed to sites
451 that employ unknown CAs.
452
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.
458
459 2. Identifying Applicable TLSA Records
460
461 2.1. DNS Considerations
462
463 2.1.1. DNS Errors, "Bogus" Responses, and "Indeterminate" Responses
464
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.
470
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:
477
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.
483
484 Note that the "indeterminate" security status has a conflicting
485 definition in Section 5 of [RFC4033]:
486
487 There is no trust anchor that would indicate that a specific
488 portion of the tree is secure.
489
490
491
492 Dukhovni & Hardaker Standards Track [Page 9]
493 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
494
495
496 In this document, the term "indeterminate" will be used exclusively
497 in the [RFC4035] sense. Therefore, obtaining "indeterminate" lookup
498 results is a (transient) failure condition, namely, the inability to
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
499 locate the relevant DNS records. DNS records that would be
500 classified "indeterminate" in the sense of [RFC4035] are simply
501 classified as "insecure".
502
503 We do not need to distinguish between zones that lack a suitable
504 ancestor trust anchor, and delegations (ultimately) from a trust
505 anchor that designate a child zone as being "insecure". All
506 "insecure" RRsets MUST be handled identically: in either case,
507 non-validated data for the query domain is all that is and can be
508 available, and authentication using the data is impossible. As the
509 DNS root zone has been signed, we expect that validating resolvers
510 used by Internet-facing MTAs will be configured with trust anchor
511 data for the root zone and that therefore domains with no ancestor
512 trust anchor will not be possible in most deployments.
513
514 As noted in Section 4.3 of [RFC4035], a security-aware DNS resolver
515 MUST be able to determine whether a given non-error DNS response is
516 "secure", "insecure", "bogus", or "indeterminate". It is expected
517 that most security-aware stub resolvers will not signal an
518 "indeterminate" security status (in the sense of [RFC4035]) to the
519 application and will instead signal a "bogus" or error result. If a
520 resolver does signal an [RFC4035] "indeterminate" security status,
521 this MUST be treated by the SMTP client as though a "bogus" or error
522 result had been returned.
523
524 An MTA using a non-validating security-aware stub resolver MAY use
525 the stub resolver's ability, if available, to signal DNSSEC
526 validation status based on information the stub resolver has learned
527 from an upstream validating recursive resolver. Security-oblivious
528 stub resolvers [RFC4033] MUST NOT be used. In accordance with
529 Section 4.9.3 of [RFC4035]:
530
531 ... a security-aware stub resolver MUST NOT place any reliance on
532 signature validation allegedly performed on its behalf, except
533 when the security-aware stub resolver obtained the data in
534 question from a trusted security-aware recursive name server via a
535 secure channel.
536
537 To avoid much repetition in the text below, we will pause to explain
538 the handling of "bogus" or "indeterminate" DNSSEC query responses.
539 These are not necessarily the result of a malicious actor; they can,
540 for example, occur when network packets are corrupted or lost in
541 transit. Therefore, "bogus" or "indeterminate" replies are equated
542 in this memo with lookup failure.
543
544
545
546
547 Dukhovni & Hardaker Standards Track [Page 10]
548 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
549
550
551 There is an important non-failure condition we need to highlight in
552 addition to the obvious case of the DNS client obtaining a non-empty
553 "secure" or "insecure" RRset of the requested type. Namely, it is
554 not an error when either "secure" or "insecure" nonexistence is
555 determined for the requested data. When a DNSSEC response with a
556 validation status that is either "secure" or "insecure" reports
557 either no records of the requested type or nonexistence of the query
558 domain, the response is not a DNS error condition. The DNS client
559 has not been left without an answer; it has learned that records of
560 the requested type do not exist.
561
562 Security-aware stub resolvers will, of course, also signal DNS lookup
563 errors in other cases, for example, when processing a "SERVFAIL"
564 [RFC2136] response code (RCODE) [RFC1035], which will not have an
565 associated DNSSEC status. All lookup errors are treated the same way
566 by this specification, regardless of whether they are from a "bogus"
567 or "indeterminate" DNSSEC status or from a more generic DNS error:
568 the information that was requested cannot be obtained by the
569 security-aware resolver at this time. Thus, a lookup error is either
570 a failure to obtain the relevant RRset if it exists or a failure to
571 determine that no such RRset exists when it does not.
572
573 In contrast to a "bogus" response or an "indeterminate" response, an
574 "insecure" DNSSEC response is not an error; rather, as explained
575 above, it indicates that the target DNS zone is either delegated as
576 an "insecure" child of a "secure" parent zone or not a descendant of
577 any of the configured DNSSEC trust anchors in use by the SMTP client.
578 "Insecure" results will leave the SMTP client with degraded channel
579 security but do not stand in the way of message delivery. See
580 Section 2.2 for further details.
581
582 2.1.2. DNS Error Handling
583
584 When a DNS lookup failure (an error, "bogus", or "indeterminate", as
585 defined above) prevents an SMTP client from determining which SMTP
586 server or servers it should connect to, message delivery MUST be
587 delayed. This naturally includes, for example, the case when a
588 "bogus" or "indeterminate" response is encountered during MX
589 resolution. When multiple MX hostnames are obtained from a
590 successful MX lookup but a later DNS lookup failure prevents network
591 address resolution for a given MX hostname, delivery may proceed via
592 any remaining MX hosts.
593
594 When a particular SMTP server is securely identified as the delivery
595 destination, a set of DNS lookups (Section 2.2) MUST be performed to
596 locate any related TLSA records. If any DNS queries used to locate
597 TLSA records fail (due to "bogus" or "indeterminate" records,
598 timeouts, malformed replies, SERVFAIL responses, etc.), then the SMTP
599
600
601
602 Dukhovni & Hardaker Standards Track [Page 11]
603 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
604
605
606 client MUST treat that server as unreachable and MUST NOT deliver the
607 message via that server. If no servers are reachable, delivery is
608 delayed.
609
610 In the text that follows, we will only describe what happens when all
611 relevant DNS queries succeed. If any DNS failure occurs, the SMTP
612 client MUST behave as described in this section, by "skipping" the
613 SMTP server or destination that is problematic. Queries for
614 candidate TLSA records are explicitly part of "all relevant DNS
615 queries", and SMTP clients MUST NOT continue to connect to an SMTP
616 server or destination whose TLSA record lookup fails.
617
618 2.1.3. Stub Resolver Considerations
619
620 A note about DNAME aliases: a query for a domain name whose ancestor
621 domain is a DNAME alias returns the DNAME RR for the ancestor domain
622 along with a CNAME that maps the query domain to the corresponding
623 sub-domain of the target domain of the DNAME alias [RFC6672].
624 Therefore, whenever we speak of CNAME aliases, we implicitly allow
625 for the possibility that the alias in question is the result of an
626 ancestor domain DNAME record. Consequently, no explicit support for
627 DNAME records is needed in SMTP software; it is sufficient to process
628 the resulting CNAME aliases. DNAME records only require special
629 processing in the validating stub resolver library that checks the
630 integrity of the combined DNAME + CNAME reply. When DNSSEC
631 validation is handled by a local caching resolver rather than the MTA
632 itself, even that part of the DNAME support logic is outside the MTA.
633
634 When a stub resolver returns a response containing a CNAME alias that
635 does not also contain the corresponding query results for the target
636 of the alias, the SMTP client will need to repeat the query at the
637 target of the alias and should do so recursively up to some
638 configured or implementation-dependent recursion limit. If at any
639 stage of CNAME expansion an error is detected, the lookup of the
640 original requested records MUST be considered to have failed.
641
642 Whether a chain of CNAME records was returned in a single stub
643 resolver response or via explicit recursion by the SMTP client, if at
644 any stage of recursive expansion an "insecure" CNAME record is
645 encountered, then it and all subsequent results (in particular, the
646 final result) MUST be considered "insecure", regardless of whether or
647 not any earlier CNAME records leading to the "insecure" record were
648 "secure".
649
650 Note that a security-aware non-validating stub resolver may return to
651 the SMTP client an "insecure" reply received from a validating
652 recursive resolver that contains a CNAME record along with additional
653 answers recursively obtained starting at the target of the CNAME. In
654
655
656
657 Dukhovni & Hardaker Standards Track [Page 12]
658 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
659
660
661 this case, the only possible conclusion is that some record in the
662 set of records returned is "insecure", and it is, in fact, possible
663 that the initial CNAME record and a subset of the subsequent records
664 are "secure".
665
666 If the SMTP client needs to determine the security status of the DNS
667 zone containing the initial CNAME record, it will need to issue a
668 separate query of type "CNAME" that returns only the initial CNAME
669 record. Specifically, as discussed in Section 2.2.2, when "insecure"
670 A or AAAA records are found for an SMTP server via a CNAME alias, the
671 SMTP client will need to perform an additional CNAME query in order
672 to determine whether or not the DNS zone in which the alias is
673 published is DNSSEC signed.
674
675 2.2. TLS Discovery
676
677 As noted previously (in Section 1.3.1), opportunistic TLS with SMTP
678 servers that advertise TLS support via STARTTLS is subject to an MITM
679 downgrade attack. Also, some SMTP servers that are not, in fact, TLS
680 capable erroneously advertise STARTTLS by default, and clients need
681 to be prepared to retry cleartext delivery after STARTTLS fails. In
682 contrast, DNSSEC-validated TLSA records MUST NOT be published for
683 servers that do not support TLS. Clients can safely interpret their
684 presence as a commitment by the server operator to implement TLS and
685 STARTTLS.
686
687 This memo defines four actions to be taken after the search for a
688 TLSA record returns "secure" usable results, "secure" unusable
689 results, "insecure" or no results, or an error signal. The term
690 "usable" in this context is in the sense of Section 4.1 of [RFC6698].
691 Specifically, if the DNS lookup for a TLSA record returns:
692
693 A "secure" TLSA RRset with at least one usable record: Any
694 connection to the MTA MUST employ TLS encryption and MUST
695 authenticate the SMTP server using the techniques discussed in the
696 rest of this document. Failure to establish an authenticated TLS
697 connection MUST result in falling back to the next SMTP server or
698 delayed delivery.
699
700 A "secure" non-empty TLSA RRset where all the records are unusable:
701 Any connection to the MTA MUST be made via TLS, but authentication
702 is not required. Failure to establish an encrypted TLS connection
703 MUST result in falling back to the next SMTP server or delayed
704 delivery.
705
706
707
708
709
710
711
712 Dukhovni & Hardaker Standards Track [Page 13]
713 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
714
715
716 An "insecure" TLSA RRset or DNSSEC-authenticated denial of existence
717 of the TLSA records:
718 A connection to the MTA SHOULD be made using (pre-DANE)
719 opportunistic TLS; this includes using cleartext delivery when the
720 remote SMTP server does not appear to support TLS. The MTA MAY
721 retry in cleartext when delivery via TLS fails during the
722 handshake or even during data transfer.
723
724 Any lookup error: Lookup errors, including "bogus" and
725 "indeterminate" as explained in Section 2.1.1, MUST result in
726 falling back to the next SMTP server or delayed delivery.
727
728 An SMTP client MAY be configured to mandate DANE-verified delivery
729 for some destinations. With mandatory DANE TLS (Section 6), delivery
730 proceeds only when "secure" TLSA records are used to establish an
731 encrypted and authenticated TLS channel with the SMTP server.
732
733 When the original next-hop destination is an address literal rather
734 than a DNS domain, DANE TLS does not apply. Delivery proceeds using
735 any relevant security policy configured by the MTA administrator.
736 Similarly, when an MX RRset incorrectly lists a network address in
737 lieu of an MX hostname, if an MTA chooses to connect to the network
738 address in the nonconformant MX record, DANE TLSA does not apply for
739 such a connection.
740
741 In the subsections that follow, we explain how to locate the SMTP
742 servers and the associated TLSA records for a given next-hop
743 destination domain. We also explain which name or names are to be
744 used in identity checks of the SMTP server certificate.
745
746 2.2.1. MX Resolution
747
748 In this section, we consider next-hop domains that are subject to MX
749 resolution and have MX records. The TLSA records and the associated
750 base domain are derived separately for each MX hostname that is used
751 to attempt message delivery. DANE TLS can authenticate message
752 delivery to the intended next-hop domain only when the MX records are
753 obtained securely via a DNSSEC-validated lookup.
754
755 MX records MUST be sorted by preference; an MX hostname with a worse
756 (numerically higher) MX preference that has TLSA records MUST NOT
757 preempt an MX hostname with a better (numerically lower) preference
758 that has no TLSA records. In other words, prevention of delivery
759 loops by obeying MX preferences MUST take precedence over channel
760 security considerations. Even with two equal-preference MX records,
761 an MTA is not obligated to choose the MX hostname that offers more
762
763
764
765
766
767 Dukhovni & Hardaker Standards Track [Page 14]
768 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
769
770
771 security. Domains that want secure inbound mail delivery need to
772 ensure that all their SMTP servers and MX records are configured
773 accordingly.
774
775 In the language of [RFC5321], Section 5.1, the original next-hop
776 domain is the "initial name". If the MX lookup of the initial name
777 results in a CNAME alias, the MTA replaces the initial name with the
778 resulting name and performs a new lookup with the new name. MTAs
779 typically support recursion in CNAME expansion, so this replacement
780 is performed repeatedly (up to the MTA's recursion limit) until the
781 ultimate non-CNAME domain is found.
782
783 If the MX RRset (or any CNAME leading to it) is "insecure" (see
784 Section 2.1.1) and DANE TLS for the given destination is mandatory
785 (Section 6), delivery MUST be delayed. If the MX RRset is "insecure"
786 and DANE TLS is not mandatory, the SMTP client is free to use
787 pre-DANE opportunistic TLS (possibly even cleartext).
788
789 Since the protocol in this memo is an Opportunistic Security protocol
790 [RFC7435], the SMTP client MAY elect to use DANE TLS (as described in
791 Section 2.2.2 below), even with MX hosts obtained via an "insecure"
792 MX RRset. For example, when a hosting provider has a signed DNS zone
793 and publishes TLSA records for its SMTP servers, hosted domains that
794 are not signed may still benefit from the provider's TLSA records.
795 Deliveries via the provider's SMTP servers will not be subject to
796 active attacks when sending SMTP clients elect to use the provider's
797 TLSA records (active attacks that tamper with the "insecure" MX RRset
798 are of course still possible in this case).
799
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.
809
810 In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset
811 is not "insecure", then it is "secure", and the SMTP client MUST
812 treat each MX hostname as described in Section 2.2.2. When, for a
813 given MX hostname, no TLSA records are found or only "insecure" TLSA
814 records are found, DANE TLSA is not applicable with the SMTP server
815 in question, and delivery proceeds to that host as with pre-DANE
816 opportunistic TLS. To avoid downgrade attacks, any errors during
817 TLSA lookups MUST, as explained in Section 2.1.2, cause the SMTP
818 server in question to be treated as unreachable.
819
820
821
822 Dukhovni & Hardaker Standards Track [Page 15]
823 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
824
825
826 2.2.2. Non-MX Destinations
827
828 This section describes the algorithm used to locate the TLSA records
829 and associated TLSA base domain for an input domain that is not
830 subject to MX resolution, that represents a hostname from a "secure"
831 MX RRset, or that lacks MX records. Such domains include:
832
833 o Any host that is configured by the sending MTA administrator as
834 the next-hop relay for some or all domains and that is not subject
835 to MX resolution.
836
837 o A domain that has MX records. When a domain has MX records, we
838 treat each MX host listed in those MX records as though it were a
839 non-MX destination -- that is, in the same way as we would treat
840 an administrator-configured relay that handles mail for that
841 domain. (Unlike administrator-specified relays, MTAs are not
842 required to support CNAME expansion of next-hop names found via MX
843 lookups.)
844
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
847 its sole SMTP server name.
848
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. These nameservers SHOULD provide
853 "insecure" negative replies that indicate the nonexistence of the
854 TLSA records, but instead they fail by not responding at all or by
855 responding with a DNS RCODE [RFC1035] other than NXDOMAIN, e.g.,
856 SERVFAIL or NOTIMP [RFC2136].
857
858 To avoid problems delivering mail to domains whose SMTP servers are
859 served by these problematic nameservers, the SMTP client MUST perform
860 any A and/or AAAA queries for the destination before attempting to
861 locate the associated TLSA records. This lookup is needed in any
862 case to determine (1) whether or not the destination domain is
863 reachable and (2) the DNSSEC validation status of the chain of CNAME
864 queries required to reach the ultimate address records.
865
866 If no address records are found, the destination is unreachable. If
867 address records are found but the DNSSEC validation status of the
868 first query response is "insecure" (see Section 2.1.3), the SMTP
869 client SHOULD NOT proceed to search for any associated TLSA records.
870 In the case of these problematic domains, TLSA queries would lead to
871 DNS lookup errors and would cause messages to be consistently delayed
872 and ultimately returned to the sender. We don't expect to find any
873
874
875
876
877 Dukhovni & Hardaker Standards Track [Page 16]
878 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
879
880
881 "secure" TLSA records associated with a TLSA base domain that lies in
882 an unsigned DNS zone. Therefore, skipping TLSA lookups in this case
883 will also reduce latency, with no detrimental impact on security.
884
885 If the A and/or AAAA lookup of the initial name yields a CNAME, we
886 replace it with the resulting name as if it were the initial name and
887 perform a lookup again using the new name. This replacement is
888 performed recursively (up to the MTA's recursion limit).
889
890 We consider the following cases for handling a DNS response for an
891 A or AAAA DNS lookup:
892
893 Not found: When the DNS queries for A and/or AAAA records yield
894 neither a list of addresses nor a CNAME (or CNAME expansion is not
895 supported), the destination is unreachable.
896
897 Non-CNAME: The answer is not a CNAME alias. If the address RRset is
898 "secure", TLSA lookups are performed as described in Section 2.2.3
899 with the initial name as the candidate TLSA base domain. If no
900 "secure" TLSA records are found, DANE TLS is not applicable and
901 mail delivery proceeds with pre-DANE opportunistic TLS (which,
902 being best-effort, degrades to cleartext delivery when STARTTLS is
903 not available or the TLS handshake fails).
904
905 Insecure CNAME: The input domain is a CNAME alias, but the ultimate
906 network address RRset is "insecure" (see Section 2.1.1). If the
907 initial CNAME response is also "insecure", DANE TLS does not
908 apply. Otherwise, this case is treated just like the non-CNAME
909 case above, where a search is performed for a TLSA record with the
910 original input domain as the candidate TLSA base domain.
911
912 Secure CNAME: The input domain is a CNAME alias, and the ultimate
913 network address RRset is "secure" (see Section 2.1.1). Two
914 candidate TLSA base domains are tried: the fully CNAME-expanded
915 initial name and, failing that, the initial name itself.
916
917 In summary, if it is possible to securely obtain the full,
918 CNAME-expanded, DNSSEC-validated address records for the input
919 domain, then that name is the preferred TLSA base domain. Otherwise,
920 the unexpanded input domain is the candidate TLSA base domain. When
921 no "secure" TLSA records are found at either the CNAME-expanded or
922 unexpanded domain, then DANE TLS does not apply for mail delivery via
923 the input domain in question. And, as always, errors, "bogus"
924 results, or "indeterminate" results for any query in the process MUST
925 result in delaying or abandoning delivery.
926
927
928
929
930
931
932 Dukhovni & Hardaker Standards Track [Page 17]
933 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
934
935
936 2.2.3. TLSA Record Lookup
937
938 When the SMTP server's hostname is not a CNAME or DNAME alias, the
939 list of associated candidate TLSA base domains (see below) consists
940 of just the server hostname.
941
942 When the hostname is an alias with a "secure" (at every stage) full
943 expansion, the list of candidate TLSA base domains (see below) is a
944 pair of domains: the fully expanded server hostname first, and the
945 unexpanded server hostname second.
946
947 Each candidate TLSA base domain (alias-expanded or original) is in
948 turn prefixed with service labels of the form "_<port>._tcp". The
949 resulting domain name is used to issue a DNSSEC query with the query
950 type set to TLSA ([RFC6698], Section 7.1).
951
952 The first of these candidate domains to yield a "secure" TLSA RRset
953 becomes the actual TLSA base domain.
954
955 For SMTP, the destination TCP port is typically 25, but this may be
956 different with custom routes specified by the MTA administrator, in
957 which case the SMTP client MUST use the appropriate number in the
958 "_<port>" prefix in place of "_25". If, for example, the candidate
959 base domain is "mx.example.com" and the SMTP connection is to port
960 25, the TLSA RRset is obtained via a DNSSEC query of the form:
961
962 _25._tcp.mx.example.com. IN TLSA ?
963
964 The query response may be a CNAME or the actual TLSA RRset. If the
965 response is a CNAME, the SMTP client (through the use of its
966 security-aware stub resolver) restarts the TLSA query at the target
967 domain, following CNAMEs as appropriate, and keeps track of whether
968 or not the entire chain is "secure". If any "insecure" records are
969 encountered or the TLSA records don't exist, the next candidate TLSA
970 base domain is tried instead.
971
972 If the ultimate response is a "secure" TLSA RRset, then the candidate
973 TLSA base domain will be the actual TLSA base domain, and the TLSA
974 RRset will constitute the TLSA records for the destination. If none
975 of the candidate TLSA base domains yield "secure" TLSA records, then
976 the SMTP client is free to use pre-DANE opportunistic TLS (possibly
977 even cleartext).
978
979 TLSA record publishers may leverage CNAMEs to reference a single
980 authoritative TLSA RRset specifying a common CA or a common
981 end-entity certificate to be used with multiple TLS services. Such
982 CNAME expansion does not change the SMTP client's notion of the TLSA
983 base domain; thus, when _25._tcp.mx.example.com is a CNAME, the base
984
985
986
987 Dukhovni & Hardaker Standards Track [Page 18]
988 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
989
990
991 domain remains mx.example.com, and this is still the reference
992 identifier used together with the next-hop domain in peer certificate
993 name checks.
994
995 Note that shared end-entity certificate associations expose the
996 publishing domain to substitution attacks, where an MITM attacker can
997 reroute traffic to a different server that shares the same end-entity
998 certificate. Such shared end-entity TLSA records SHOULD be avoided
999 unless the servers in question are functionally equivalent or employ
1000 mutually incompatible protocols (an active attacker gains nothing by
1001 diverting client traffic from one such server to another).
1002
1003 A better example, employing a shared trust anchor rather than shared
1004 end-entity certificates, is illustrated by the DNSSEC-validated
1005 records below:
1006
1007 example.com. IN MX 0 mx1.example.com.
1008 example.com. IN MX 0 mx2.example.com.
1009 _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
1010 _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
1011 tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c149a...
1012
1013 The SMTP servers mx1.example.com and mx2.example.com will be expected
1014 to have certificates issued under a common trust anchor, but each MX
1015 hostname's TLSA base domain remains unchanged despite the above CNAME
1016 records. Correspondingly, each SMTP server will be associated with a
1017 pair of reference identifiers consisting of its hostname plus the
1018 next-hop domain "example.com".
1019
1020 If, during TLSA resolution (including possible CNAME indirection), at
1021 least one "secure" TLSA record is found (even if not usable because
1022 it is unsupported by the implementation or support is
1023 administratively disabled), then the corresponding host has signaled
1024 its commitment to implement TLS. The SMTP client MUST NOT deliver
1025 mail via the corresponding host unless a TLS session is negotiated
1026 via STARTTLS. This is required to avoid MITM STARTTLS downgrade
1027 attacks.
1028
1029 As noted previously (in Section 2.2.2), when no "secure" TLSA records
1030 are found at the fully CNAME-expanded name, the original unexpanded
1031 name MUST be tried instead. This supports customers of hosting
1032 providers where the provider's zone cannot be validated with DNSSEC
1033 but the customer has shared appropriate key material with the hosting
1034 provider to enable TLS via SNI. Intermediate names that arise during
1035 CNAME expansion that are neither the original name nor the final name
1036 are never candidate TLSA base domains, even if "secure".
1037
1038
1039
1040
1041
1042 Dukhovni & Hardaker Standards Track [Page 19]
1043 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1044
1045
1046 3. DANE Authentication
1047
1048 This section describes which TLSA records are applicable to SMTP
1049 opportunistic DANE TLS and how to apply such records to authenticate
1050 the SMTP server. With opportunistic DANE TLS, both the TLS support
1051 implied by the presence of DANE TLSA records and the verification
1052 parameters necessary to authenticate the TLS peer are obtained
1053 together. In contrast to protocols where channel security policy is
1054 set exclusively by the client, authentication via this protocol is
1055 expected to be less prone to connection failure caused by
1056 incompatible configuration of the client and server.
1057
1058 3.1. TLSA Certificate Usages
1059
1060 The DANE TLSA specification [RFC6698] defines multiple TLSA RR types
1061 via combinations of three numeric parameters. The numeric values of
1062 these parameters were later given symbolic names in [RFC7218]. The
1063 rest of the TLSA record is the "certificate association data field",
1064 which specifies the full or digest value of a certificate or
1065 public key.
1066
1067 Since opportunistic DANE TLS will be used by non-interactive MTAs,
1068 with no user to "click OK" when authentication fails, reliability of
1069 peer authentication is paramount. Server operators are advised to
1070 publish TLSA records that are least likely to fail authentication due
1071 to interoperability or operational problems. Because DANE TLS relies
1072 on coordinated changes to DNS and SMTP server settings, the best
1073 choice of records to publish will depend on site-specific practices.
1074
1075 The certificate usage element of a TLSA record plays a critical role
1076 in determining how the corresponding certificate association data
1077 field is used to authenticate a server's certificate chain.
1078 Sections 3.1.1 and 3.1.2 explain the process for certificate usages
1079 DANE-EE(3) and DANE-TA(2), respectively. Section 3.1.3 briefly
1080 explains why certificate usages PKIX-TA(0) and PKIX-EE(1) are not
1081 applicable with opportunistic DANE TLS.
1082
1083 In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1) SHA2-256(1)",
1084 with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records as a second
1085 choice, depending on site needs. See Sections 3.1.1 and 3.1.2 for
1086 more details. Other combinations of TLSA parameters either (1) are
1087 explicitly unsupported or (2) offer little to recommend them over
1088 these two.
1089
1090
1091
1092
1093
1094
1095
1096
1097 Dukhovni & Hardaker Standards Track [Page 20]
1098 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1099
1100
1101 3.1.1. Certificate Usage DANE-EE(3)
1102
1103 Authentication via certificate usage DANE-EE(3) TLSA records involves
1104 simply checking that the server's leaf certificate matches the TLSA
1105 record. In particular, the binding of the server public key to its
1106 name is based entirely on the TLSA record association. The server
1107 MUST be considered authenticated even if none of the names in the
1108 certificate match the client's reference identity for the server.
1109
1110 The expiration date of the server certificate MUST be ignored: the
1111 validity period of the TLSA record key binding is determined by the
1112 validity interval of the TLSA record DNSSEC signature.
1113
1114 With DANE-EE(3), servers need not employ SNI (they may ignore the
1115 client's SNI message) even when the server is known under independent
1116 names that would otherwise require separate certificates. It is
1117 instead sufficient for the TLSA RRsets for all the domains in
1118 question to match the server's default certificate. Of course, with
1119 SMTP servers it is simpler still to publish the same MX hostname for
1120 all the hosted domains.
1121
1122 For domains where it is practical to make coordinated changes in DNS
1123 TLSA records during SMTP server key rotation, it is often best to
1124 publish end-entity DANE-EE(3) certificate associations. DANE-EE(3)
1125 certificates don't suddenly stop working when leaf or intermediate
1126 certificates expire, nor do they fail when the server operator
1127 neglects to configure all the required issuer certificates in the
1128 server certificate chain.
1129
1130 TLSA records published for SMTP servers SHOULD, in most cases, be
1131 "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE
1132 implementations are required to support SHA2-256, this record type
1133 works for all clients and need not change across certificate renewals
1134 with the same key.
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152 Dukhovni & Hardaker Standards Track [Page 21]
1153 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1154
1155
1156 3.1.2. Certificate Usage DANE-TA(2)
1157
1158 Some domains may prefer to avoid the operational complexity of
1159 publishing unique TLSA RRs for each TLS service. If the domain
1160 employs a common issuing CA to create certificates for multiple TLS
1161 services, it may be simpler to publish the issuing authority as a
1162 trust anchor (TA) for the certificate chains of all relevant
1163 services. The TLSA query domain (TLSA base domain with port and
1164 protocol prefix labels) for each service issued by the same TA may
1165 then be set to a CNAME alias that points to a common TLSA RRset that
1166 matches the TA. For example:
1167
1168 example.com. IN MX 0 mx1.example.com.
1169 example.com. IN MX 0 mx2.example.com.
1170 _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
1171 _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
1172 tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14....
1173
1174 With usage DANE-TA(2), the server certificates will need to have
1175 names that match one of the client's reference identifiers (see
1176 [RFC6125]). The server MAY employ SNI to select the appropriate
1177 certificate to present to the client.
1178
1179 SMTP servers that rely on certificate usage DANE-TA(2) TLSA records
1180 for TLS authentication MUST include the TA certificate as part of the
1181 certificate chain presented in the TLS handshake server certificate
1182 message even when it is a self-signed root certificate. Many SMTP
1183 servers are not configured with a comprehensive list of trust
1184 anchors, nor are they expected to be at any point in the future.
1185 Some MTAs will ignore all locally trusted certificates when
1186 processing usage DANE-TA(2) TLSA records. Thus, even when the TA
1187 happens to be a public CA known to the SMTP client, authentication is
1188 likely to fail unless the TA certificate is included in the TLS
1189 server certificate message.
1190
1191 With some SMTP server software, it is not possible to configure the
1192 server to include self-signed (root) CA certificates in the server
1193 certificate chain. Such servers either MUST publish DANE-TA(2)
1194 records for an intermediate certificate or MUST instead use
1195 DANE-EE(3) TLSA records.
1196
1197 TLSA records with a matching type of Full(0) are discouraged. While
1198 these potentially obviate the need to transmit the TA certificate in
1199 the TLS server certificate message, client implementations may not be
1200 able to augment the server certificate chain with the data obtained
1201 from DNS, especially when the TLSA record supplies a bare key
1202 (selector SPKI(1)). Since the server will need to transmit the TA
1203 certificate in any case, server operators SHOULD publish TLSA records
1204
1205
1206
1207 Dukhovni & Hardaker Standards Track [Page 22]
1208 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1209
1210
1211 with a matching type other than Full(0) and avoid potential
1212 interoperability issues with large TLSA records containing full
1213 certificates or keys.
1214
1215 TLSA Publishers employing DANE-TA(2) records SHOULD publish records
1216 with a selector of Cert(0). Such TLSA records are associated with
1217 the whole trust anchor certificate, not just with the trust anchor
1218 public key. In particular, the SMTP client SHOULD then apply any
1219 relevant constraints from the trust anchor certificate, such as, for
1220 example, path length constraints.
1221
1222 While a selector of SPKI(1) may also be employed, the resulting TLSA
1223 record will not specify the full trust anchor certificate content,
1224 and elements of the trust anchor certificate other than the public
1225 key become mutable. This may, for example, allow a subsidiary CA to
1226 issue a chain that violates the trust anchor's path length or name
1227 constraints.
1228
1229 3.1.3. Certificate Usages PKIX-TA(0) and PKIX-EE(1)
1230
1231 Note that this section applies to MTA-to-MTA SMTP, which is normally
1232 on port 25 -- that is, to servers that are the SMTP servers for one
1233 or more destination domains. Other uses of SMTP, such as in
1234 MUA-to-MSA submission on ports 587 or 465, are out of scope for this
1235 document. Where those other uses also employ TLS opportunistically
1236 and/or depend on DNSSEC as a result of DNS-based discovery of service
1237 location, the relevant specifications should, as appropriate, arrive
1238 at similar conclusions.
1239
1240 As noted in Sections 1.3.1 and 1.3.2, sending MTAs cannot, without
1241 relying on DNSSEC for "secure" MX records and DANE for STARTTLS
1242 support signaling, perform server identity verification or prevent
1243 STARTTLS downgrade attacks. The use of PKIX CAs offers no added
1244 security, since an attacker capable of compromising DNSSEC is free to
1245 replace any PKIX-TA(0) or PKIX-EE(1) TLSA records with records
1246 bearing any convenient non-PKIX certificate usage. Finally, as
1247 explained in Section 1.3.4, there is no list of trusted CAs agreed
1248 upon by all MTAs and no user to "click OK" when a server's CA is not
1249 trusted by a client.
1250
1251 Therefore, TLSA records for the port 25 SMTP service used by client
1252 MTAs SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) or
1253 PKIX-EE(1). SMTP client MTAs cannot be expected to be configured
1254 with a suitably complete set of trusted public CAs. Lacking a
1255 complete set of public CAs, MTA clients would not be able to verify
1256 the certificates of SMTP servers whose issuing root CAs are not
1257 trusted by the client.
1258
1259
1260
1261
1262 Dukhovni & Hardaker Standards Track [Page 23]
1263 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1264
1265
1266 Opportunistic DANE TLS needs to interoperate without bilateral
1267 coordination of security settings between client and server systems.
1268 Therefore, parameter choices that are fragile in the absence of
1269 bilateral coordination are unsupported. Nothing is lost; since the
1270 PKIX certificate usages cannot aid SMTP TLS security, they can only
1271 impede SMTP TLS interoperability.
1272
1273 SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0)
1274 or PKIX-EE(1) is undefined. As with any other unsupported
1275 certificate usage, SMTP clients MAY treat such records as "unusable".
1276
1277 3.2. Certificate Matching
1278
1279 When at least one usable "secure" TLSA record is found, the SMTP
1280 client MUST use TLSA records to authenticate the SMTP server.
1281 Messages MUST NOT be delivered via the SMTP server if authentication
1282 fails; otherwise, the SMTP client is vulnerable to MITM attacks.
1283
1284 3.2.1. DANE-EE(3) Name Checks
1285
1286 The SMTP client MUST NOT perform certificate name checks with
1287 certificate usage DANE-EE(3) (Section 3.1.1).
1288
DNS records that would be classified "indeterminate" in the sense of [RFC4035] are simply classified as "insecure".
DNS records that would be classified "indeterminate" in the sense of [RFC40353] are simply classified as "insecure".
1289 3.2.2. DANE-TA(2) Name Checks
1290
1291 To match a server via a TLSA record with certificate usage
1292 DANE-TA(2), the client MUST perform name checks to ensure that it has
1293 reached the correct server. In all DANE-TA(2) cases, the SMTP client
1294 MUST employ the TLSA base domain as the primary reference identifier
1295 for matching the server certificate.
1296
1297 TLSA records for MX hostnames: If the TLSA base domain was obtained
1298 indirectly via a "secure" MX lookup (including any CNAME-expanded
1299 name of an MX hostname), then the original next-hop domain used in
1300 the MX lookup MUST be included as a second reference identifier.
1301 The CNAME-expanded original next-hop domain MUST be included as a
1302 third reference identifier if different from the original next-hop
1303 domain. When the client MTA is employing DANE TLS security
1304 despite "insecure" MX redirection, the MX hostname is the only
1305 reference identifier.
1306
1307 TLSA records for non-MX hostnames: If MX records were not used
1308 (e.g., if none exist) and the TLSA base domain is the
1309 CNAME-expanded original next-hop domain, then the original
1310 next-hop domain MUST be included as a second reference identifier.
1311
1312
1313
1314
1315
1316
1317 Dukhovni & Hardaker Standards Track [Page 24]
1318 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1319
1320
1321 Accepting certificates with the original next-hop domain in addition
1322 to the MX hostname allows a domain with multiple MX hostnames to
1323 field a single certificate bearing a single domain name (i.e., the
1324 email domain) across all the SMTP servers. This also aids
1325 interoperability with pre-DANE SMTP clients that are configured to
1326 look for the email domain name in server certificates -- for example,
1327 with "secure" DNS records as shown below:
1328
1329 exchange.example.org. IN CNAME mail.example.org.
1330 mail.example.org. IN CNAME example.com.
1331 example.com. IN MX 10 mx10.example.com.
1332 example.com. IN MX 15 mx15.example.com.
1333 example.com. IN MX 20 mx20.example.com.
1334 ;
1335 mx10.example.com. IN A 192.0.2.10
1336 _25._tcp.mx10.example.com. IN TLSA 2 0 1 ...
1337 ;
1338 mx15.example.com. IN CNAME mxbackup.example.com.
1339 mxbackup.example.com. IN A 192.0.2.15
1340 ; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
1341 _25._tcp.mx15.example.com. IN TLSA 2 0 1 ...
1342 ;
1343 mx20.example.com. IN CNAME mxbackup.example.net.
1344 mxbackup.example.net. IN A 198.51.100.20
1345 _25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...
1346
1347 Certificate name checks for delivery of mail to exchange.example.org
1348 via any of the associated SMTP servers MUST accept at least the names
1349 "exchange.example.org" and "example.com", which are, respectively,
1350 the original and fully expanded next-hop domain. When the SMTP
1351 server is mx10.example.com, name checks MUST accept the TLSA base
1352 domain "mx10.example.com". If, despite the fact that MX hostnames
1353 are required to not be aliases, the MTA supports delivery via
1354 "mx15.example.com" or "mx20.example.com", then name checks MUST
1355 accept the respective TLSA base domains "mx15.example.com" and
1356 "mxbackup.example.net".
1357
1358 3.2.3. Reference Identifier Matching
1359
1360 When name checks are applicable (certificate usage DANE-TA(2)), if
1361 the server certificate contains a Subject Alternative Name extension
1362 [RFC5280] with at least one DNS-ID [RFC6125], then only the DNS-IDs
1363 are matched against the client's reference identifiers. The CN-ID
1364 [RFC6125] is only considered when no DNS-IDs are present. The server
1365 certificate is considered matched when one of its presented
1366 identifiers [RFC5280] matches any of the client's reference
1367 identifiers.
1368
1369
1370
1371
1372 Dukhovni & Hardaker Standards Track [Page 25]
1373 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1374
1375
1376 Wildcards are valid in either DNS-IDs or the CN-ID when applicable.
1377 The wildcard character must be the entire first label of the DNS-ID
1378 or CN-ID. Thus, "*.example.com" is valid, while "smtp*.example.com"
1379 and "*smtp.example.com" are not. SMTP clients MUST support wildcards
1380 that match the first label of the reference identifier, with the
1381 remaining labels matching verbatim. For example, the DNS-ID
1382 "*.example.com" matches the reference identifier "mx1.example.com".
1383 SMTP clients MAY, subject to local policy, allow wildcards to match
1384 multiple reference identifier labels, but servers cannot expect broad
1385 support for such a policy. Therefore, any wildcards in server
1386 certificates SHOULD match exactly one label in either the TLSA base
1387 domain or the next-hop domain.
1388
1389 4. Server Key Management
1390
1391 Two TLSA records MUST be published before employing a new EE or TA
1392 public key or certificate: one matching the currently deployed key
1393 and the other matching the new key scheduled to replace it. Once
1394 sufficient time has elapsed for all DNS caches to expire the previous
1395 TLSA RRset and related signature RRsets, servers may be configured to
1396 use the new EE private key and associated public key certificate or
1397 may employ certificates signed by the new trust anchor.
1398
1399 Once the new public key or certificate is in use, the TLSA RR that
1400 matches the retired key can be removed from DNS, leaving only RRs
1401 that match keys or certificates in active use.
1402
1403 As described in Section 3.1.2, when server certificates are validated
1404 via a DANE-TA(2) trust anchor and CNAME records are employed to store
1405 the TA association data at a single location, the responsibility of
1406 updating the TLSA RRset shifts to the operator of the trust anchor.
1407 Before a new trust anchor is used to sign any new server
1408 certificates, its certificate (digest) is added to the relevant TLSA
1409 RRset. After enough time elapses for the original TLSA RRset to age
1410 out of DNS caches, the new trust anchor can start issuing new server
1411 certificates. Once all certificates issued under the previous trust
1412 anchor have expired, its associated RRs can be removed from the TLSA
1413 RRset.
1414
1415 In the DANE-TA(2) key management model, server operators do not
1416 generally need to update DNS TLSA records after initially creating a
1417 CNAME record that references the centrally operated DANE-TA(2) RRset.
1418 If a particular server's key is compromised, its TLSA CNAME SHOULD be
1419 replaced with a DANE-EE(3) association until the certificate for the
1420 compromised key expires, at which point it can return to using a
1421 CNAME record. If the central trust anchor is compromised, all
1422
1423
1424
1425
1426
1427 Dukhovni & Hardaker Standards Track [Page 26]
1428 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1429
1430
1431 servers need to be issued new keys by a new TA, and an updated
1432 DANE-TA(2) TLSA RRset needs to be published containing just the
1433 new TA.
1434
1435 SMTP servers cannot expect broad Certificate Revocation List (CRL) or
1436 Online Certificate Status Protocol (OCSP) support from SMTP clients.
1437 As outlined above, with DANE, compromised server or trust anchor keys
1438 can be "revoked" by removing them from the DNS without the need for
1439 client-side support for OCSP or CRLs.
1440
1441 5. Digest Algorithm Agility
1442
1443 While [RFC6698] specifies multiple digest algorithms, it does not
1444 specify a protocol by which the SMTP client and TLSA record publisher
1445 can agree on the strongest shared algorithm. Such a protocol would
1446 allow the client and server to avoid exposure to deprecated weaker
1447 algorithms that are published for compatibility with less capable
1448 clients. When stronger algorithms are an option, deprecated
1449 algorithms SHOULD be avoided. Such a protocol is specified in
1450 [RFC7671]. SMTP clients and servers that implement this
1451 specification MUST comply with the requirements outlined in Section 9
1452 of [RFC7671].
1453
1454 6. Mandatory TLS Security
1455
1456 An MTA implementing this protocol may require a stronger security
1457 assurance when sending email to selected destinations. The sending
1458 organization may need to send sensitive email and/or may have
1459 regulatory obligations to protect its content. This protocol is not
1460 in conflict with such a requirement and, in fact, can often simplify
1461 authenticated delivery to such destinations.
1462
1463 Specifically, with domains that publish DANE TLSA records for their
1464 MX hostnames, a sending MTA can be configured to use the receiving
1465 domain's DANE TLSA records to authenticate the corresponding SMTP
1466 server. Authentication via DANE TLSA records is easier to manage, as
1467 changes in the receiver's expected certificate properties are made on
1468 the receiver end and don't require manually communicated
1469 configuration changes. With mandatory DANE TLS, when no usable TLSA
1470 records are found, message delivery is delayed. Thus, mail is only
1471 sent when an authenticated TLS channel is established to the remote
1472 SMTP server.
1473
1474 Administrators of mail servers that employ mandatory DANE TLS need to
1475 carefully monitor their mail logs and queues. If a partner domain
1476 unwittingly misconfigures its TLSA records, disables DNSSEC, or
1477 misconfigures SMTP server certificate chains, mail will be delayed
1478 and may bounce if the issue is not resolved in a timely manner.
1479
1480
1481
1482 Dukhovni & Hardaker Standards Track [Page 27]
1483 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1484
1485
1486 7. Note on DANE for Message User Agents
1487
1488 We note that SMTP is also used between Message User Agents (MUAs) and
1489 Message Submission Agents (MSAs) [RFC6409]. In [RFC6186], a protocol
1490 is specified that enables an MUA to dynamically locate the MSA based
1491 on the user's email address. SMTP connection security considerations
1492 for MUAs implementing [RFC6186] are largely analogous to connection
1493 security requirements for MTAs, and this specification could be
1494 applied largely verbatim with DNS MX records replaced by
1495 corresponding DNS Service (SRV) records [RFC7673].
1496
1497 However, until MUAs begin to adopt the dynamic configuration
1498 mechanisms of [RFC6186], they are adequately served by more
1499 traditional static TLS security policies. Specification of DANE TLS
1500 for MUA-to-MSA SMTP is left to future documents that focus
1501 specifically on SMTP security between MUAs and MSAs.
1502
1503 8. Interoperability Considerations
1504
1505 8.1. SNI Support
1506
1507 To ensure that the server sends the right certificate chain, the SMTP
1508 client MUST send the TLS SNI extension containing the TLSA base
1509 domain. This precludes the use of the Secure Socket Layer (SSL)
1510 HELLO that is SSL 2.0 compatible by the SMTP client.
1511
1512 Each SMTP server MUST present a certificate chain (see [RFC5246],
1513 Section 7.4.2) that matches at least one of the TLSA records. The
1514 server MAY rely on SNI to determine which certificate chain to
1515 present to the client. Clients that don't send SNI information may
1516 not see the expected certificate chain.
1517
1518 If the server's TLSA records match the server's default certificate
1519 chain, the server need not support SNI. In either case, the server
1520 need not include the SNI extension in its TLS HELLO, as simply
1521 returning a matching certificate chain is sufficient. Servers
1522 MUST NOT enforce the use of SNI by clients, as the client may be
1523 using unauthenticated opportunistic TLS and may not expect any
1524 particular certificate from the server. If the client sends no SNI
1525 extension or sends an SNI extension for an unsupported domain, the
1526 server MUST simply send some fallback certificate chain of its
1527 choice. The reason for not enforcing strict matching of the
1528 requested SNI hostname is that DANE TLS clients are typically willing
1529 to accept multiple server names but can only send one name in the SNI
1530 extension. The server's fallback certificate may match a different
1531 name acceptable to the client, e.g., the original next-hop domain.
1532
1533
1534
1535
1536
1537 Dukhovni & Hardaker Standards Track [Page 28]
1538 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1539
1540
1541 8.2. Anonymous TLS Cipher Suites
1542
1543 Since many SMTP servers either do not support or do not enable any
1544 anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD
1545 offer to negotiate a typical set of non-anonymous cipher suites
1546 required for interoperability with such servers. An SMTP client
1547 employing pre-DANE opportunistic TLS MAY also include one or more
1548 anonymous TLS cipher suites in its TLS HELLO. SMTP servers that need
1549 to interoperate with opportunistic TLS clients SHOULD be prepared to
1550 interoperate with such clients by either always selecting a mutually
1551 supported non-anonymous cipher suite or correctly handling client
1552 connections that negotiate anonymous cipher suites.
1553
1554 Note that while SMTP server operators are under no obligation to
1555 enable anonymous cipher suites, no security is gained by sending
1556 certificates to clients that will ignore them. Indeed, support for
1557 anonymous cipher suites in the server makes audit trails more
1558 informative. Log entries that record connections that employed an
1559 anonymous cipher suite record the fact that the clients did not care
1560 to authenticate the server.
1561
1562 9. Operational Considerations
1563
1564 9.1. Client Operational Considerations
1565
1566 An operational error on the sending or receiving side that cannot be
1567 corrected in a timely manner may, at times, lead to consistent
1568 failure to deliver time-sensitive email. The sending MTA
1569 administrator may have to choose between allowing email to queue
1570 until the error is resolved and disabling opportunistic or mandatory
1571 DANE TLS (Section 6) for one or more destinations. The choice to
1572 disable DANE TLS security should not be made lightly. Every
1573 reasonable effort should be made to determine that problems with mail
1574 delivery are the result of an operational error and not an attack. A
1575 fallback strategy may be to configure explicit out-of-band TLS
1576 security settings if supported by the sending MTA.
1577
1578 SMTP clients may deploy opportunistic DANE TLS incrementally by
1579 enabling it only for selected sites or may occasionally need to
1580 disable opportunistic DANE TLS for peers that fail to interoperate
1581 due to misconfiguration or software defects on either end. Some
1582 implementations MAY support DANE TLS in an "audit only" mode in which
1583 failure to achieve the requisite security level is logged as a
1584 warning and delivery proceeds at a reduced security level. Unless
1585 local policy specifies "audit only" or specifies that opportunistic
1586 DANE TLS is not to be used for a particular destination, an SMTP
1587
1588
1589
1590
1591
1592 Dukhovni & Hardaker Standards Track [Page 29]
1593 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1594
1595
1596 client MUST NOT deliver mail via a server whose certificate chain
1597 fails to match at least one TLSA record when usable TLSA records are
1598 found for that server.
1599
1600 9.2. Publisher Operational Considerations
1601
1602 Some MTAs enable STARTTLS selectively. For example, they might only
1603 support STARTTLS with clients that have previously demonstrated
1604 "proper MTA behavior", e.g., by retrying the delivery of deferred
1605 messages (greylisting). If such an MTA publishes DANE TLSA records,
1606 sending MTAs that implement this specification will not attempt the
1607 initial cleartext SMTP transaction needed to establish the "proper
1608 MTA behavior", because they cannot establish the required channel
1609 security. Server operators MUST NOT implement selective STARTTLS if
1610 they also want to support DANE TLSA.
1611
1612 TLSA Publishers MUST follow the guidelines in Section 8 of [RFC7671].
1613
1614 TLSA Publishers SHOULD follow the TLSA publication size guidance
1615 found in Section 10.1 of [RFC7671].
1616
1617 TLSA Publishers SHOULD follow the TLSA record TTL and signature
1618 lifetime recommendations found in Section 13 of [RFC7671].
1619
1620 10. Security Considerations
1621
1622 This protocol leverages DANE TLSA records to implement MITM-resistant
1623 Opportunistic Security [RFC7435] for SMTP. For destination domains
1624 that sign their MX records and publish signed TLSA records for their
1625 MX hostnames, this protocol allows sending MTAs to securely discover
1626 both the availability of TLS and how to authenticate the destination.
1627
1628 This protocol does not aim to secure all SMTP traffic, as that is not
1629 practical until DNSSEC and DANE adoption are universal. The
1630 incremental deployment provided by following this specification is a
1631 best possible path for securing SMTP. This protocol coexists and
1632 interoperates with the existing insecure Internet email backbone.
1633
1634 The protocol does not preclude existing non-opportunistic SMTP TLS
1635 security arrangements, which can continue to be used as before via
1636 manual configuration with negotiated out-of-band key and TLS
1637 configuration exchanges.
1638
1639 Opportunistic SMTP TLS depends critically on DNSSEC for downgrade
1640 resistance and secure resolution of the destination name. If DNSSEC
1641 is compromised, it is not possible to fall back on the public CA PKI
1642 to prevent MITM attacks. A successful breach of DNSSEC enables the
1643 attacker to publish TLSA usage 3 certificate associations and thereby
1644
1645
1646
1647 Dukhovni & Hardaker Standards Track [Page 30]
1648 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1649
1650
1651 bypass any security benefit the legitimate domain owner might hope to
1652 gain by publishing usage 0 or usage 1 TLSA RRs. Given the lack of
1653 public CA PKI support in existing MTA deployments, avoiding
1654 certificate usages 0 and 1 simplifies implementation and deployment
1655 with no adverse security consequences.
1656
1657 Implementations must strictly follow Sections 2.1.2, 2.1.3, 2.2,
1658 2.2.1, 2.2.2, 2.2.3, 3.2, and 9.1 of this specification; these
1659 sections indicate when it is appropriate to initiate a
1660 non-authenticated connection or cleartext connection to an SMTP
1661 server. Specifically, in order to prevent downgrade attacks on this
1662 protocol, implementations must not initiate a connection when this
1663 specification indicates that a particular SMTP server must be
1664 considered unreachable.
1665
1666 11. References
1667
1668 11.1. Normative References
1669
1670 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1671 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
1672 <http://www.rfc-editor.org/info/rfc1034>.
1673
1674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1675 Requirement Levels", BCP 14, RFC 2119,
1676 DOI 10.17487/RFC2119, March 1997,
1677 <http://www.rfc-editor.org/info/rfc2119>.
1678
1679 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
1680 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
1681 February 2002, <http://www.rfc-editor.org/info/rfc3207>.
1682
1683 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1684 Rose, "DNS Security Introduction and Requirements",
1685 RFC 4033, DOI 10.17487/RFC4033, March 2005,
1686 <http://www.rfc-editor.org/info/rfc4033>.
1687
1688 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1689 Rose, "Resource Records for the DNS Security Extensions",
1690 RFC 4034, DOI 10.17487/RFC4034, March 2005,
1691 <http://www.rfc-editor.org/info/rfc4034>.
1692
1693 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1694 Rose, "Protocol Modifications for the DNS Security
1695 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
1696 <http://www.rfc-editor.org/info/rfc4035>.
1697
1698
1699
1700
1701
1702 Dukhovni & Hardaker Standards Track [Page 31]
1703 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1704
1705
1706 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1707 (TLS) Protocol Version 1.2", RFC 5246,
1708 DOI 10.17487/RFC5246, August 2008,
1709 <http://www.rfc-editor.org/info/rfc5246>.
1710
1711 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1712 Housley, R., and W. Polk, "Internet X.509 Public Key
1713 Infrastructure Certificate and Certificate Revocation List
1714 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1715 <http://www.rfc-editor.org/info/rfc5280>.
1716
1717 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1718 DOI 10.17487/RFC5321, October 2008,
1719 <http://www.rfc-editor.org/info/rfc5321>.
1720
1721 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
1722 DOI 10.17487/RFC5598, July 2009,
1723 <http://www.rfc-editor.org/info/rfc5598>.
1724
1725 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
1726 Extensions: Extension Definitions", RFC 6066,
1727 DOI 10.17487/RFC6066, January 2011,
1728 <http://www.rfc-editor.org/info/rfc6066>.
1729
1730 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1731 Verification of Domain-Based Application Service Identity
1732 within Internet Public Key Infrastructure Using X.509
1733 (PKIX) Certificates in the Context of Transport Layer
1734 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125,
1735 March 2011, <http://www.rfc-editor.org/info/rfc6125>.
1736
1737 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
1738 Submission/Access Services", RFC 6186,
1739 DOI 10.17487/RFC6186, March 2011,
1740 <http://www.rfc-editor.org/info/rfc6186>.
1741
1742 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
1743 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
1744 <http://www.rfc-editor.org/info/rfc6672>.
1745
1746 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
1747 of Named Entities (DANE) Transport Layer Security (TLS)
1748 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698,
1749 August 2012, <http://www.rfc-editor.org/info/rfc6698>.
1750
1751
1752
1753
1754
1755
1756
1757 Dukhovni & Hardaker Standards Track [Page 32]
1758 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1759
1760
1761 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
1762 Conversations about DNS-Based Authentication of Named
1763 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218,
1764 April 2014, <http://www.rfc-editor.org/info/rfc7218>.
1765
1766 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
1767 Authentication of Named Entities (DANE) Protocol: Updates
1768 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
1769 October 2015, <http://www.rfc-editor.org/info/rfc7671>.
1770
1771 11.2. Informative References
1772
1773 [RFC1035] Mockapetris, P., "Domain names - implementation and
1774 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
1775 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
1776
1777 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
1778 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
1779 RFC 2136, DOI 10.17487/RFC2136, April 1997,
1780 <http://www.rfc-editor.org/info/rfc2136>.
1781
1782 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1783 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
1784 <http://www.rfc-editor.org/info/rfc2181>.
1785
1786 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
1787 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
1788 <http://www.rfc-editor.org/info/rfc4949>.
1789
1790 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
1791 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
1792 <http://www.rfc-editor.org/info/rfc6409>.
1793
1794 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
1795 Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
1796 December 2014, <http://www.rfc-editor.org/info/rfc7435>.
1797
1798 [RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using
1799 DNS-Based Authentication of Named Entities (DANE) TLSA
1800 Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673,
1801 October 2015, <http://www.rfc-editor.org/info/rfc7673>.
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812 Dukhovni & Hardaker Standards Track [Page 33]
1813 RFC 7672 SMTP Security via Opportunistic DANE TLS October 2015
1814
1815
1816 Acknowledgements
1817
1818 The authors would like to extend great thanks to Tony Finch, who
1819 started the original version of a DANE SMTP document. His work is
1820 greatly appreciated and has been incorporated into this document.
1821 The authors would like to additionally thank Phil Pennock for his
1822 comments and advice on this document.
1823
1824 Acknowledgements from Viktor: Thanks to Paul Hoffman, who motivated
1825 me to begin work on this memo and provided feedback on early draft
1826 versions of this document. Thanks to Patrick Koetter, Perry Metzger,
1827 and Nico Williams for valuable review comments. Thanks also to
1828 Wietse Venema, who created Postfix, and whose advice and feedback
1829 were essential to the development of the Postfix DANE implementation.
1830
1831 Authors' Addresses
1832
1833 Viktor Dukhovni
1834 Two Sigma
1835
1836 Email: ietf-dane@dukhovni.org
1837
1838
1839 Wes Hardaker
1840 Parsons
1841 P.O. Box 382
1842 Davis, CA 95617
1843 United States
1844
1845 Email: ietf@hardakers.net
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867 Dukhovni & Hardaker Standards Track [Page 34]
1868
3.2.2. DANE-TA(2) Name Checks
To match a server via a TLSA record with certificate usage
DANE-TA(2), the client MUST perform name checks to ensure that it has
reached the correct server. In all DANE-TA(2) cases, the SMTP client
MUST employ the TLSA base domain as the primary reference identifier
for matching the server certificate.
TLSA records for MX hostnames: If the TLSA base domain was obtained
indirectly via a "secure" MX lookup (including any CNAME-expanded
name of an MX hostname), then the original next-hop domain used in
the MX lookup MUST be included as a second reference identifier.
The CNAME-expanded original next-hop domain MUST be included as a
third reference identifier if different from the 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.
3.2.2. DANE-TA(2) Name Checks
To match a server via a TLSA record with certificate usage
DANE-TA(2), the client MUST perform name checks to ensure that it has
reached the correct server. In all DANE-TA(2) cases, the SMTP client
MUST employ the TLSA base domain as the primary reference identifier
for matching the server certificate.
TLSA records for MX hostnames: If the TLSA base domain was obtained
indirectly via a "secure" MX lookup (including any CNAME-expanded
name of an MX hostname), then the original next-hop domain used in
the MX lookup MUST be included as a second reference identifier.
The CNAME-expanded original next-hop domain MUST be included as a
third reference identifier if different from the original next-hop
domain. When the client MTA is employing DANE TLS security
despite "insecure" MX redirection, the MX hostnameTLSA base domain is the only
reference identifier.