Unbreak utf8clean testcase.
[exim.git] / doc / doc-txt / draft-ietf-dane-smtp-with-dane.txt
CommitLineData
22e6f294
JH
1
2
3
4
5DANE V. Dukhovni
6Internet-Draft Two Sigma
7Intended status: Standards Track W. Hardaker
a46255cd
JH
8Expires: February 3, 2015 Parsons
9 August 2, 2014
22e6f294
JH
10
11
12 SMTP security via opportunistic DANE TLS
a46255cd 13 draft-ietf-dane-smtp-with-dane-11
22e6f294
JH
14
15Abstract
16
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).
23
24Status of This Memo
25
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
28
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/.
33
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."
38
a46255cd 39 This Internet-Draft will expire on February 3, 2015.
22e6f294
JH
40
41Copyright Notice
42
43 Copyright (c) 2014 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
45
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
53
54
55
a46255cd 56Dukhovni & Hardaker Expires February 3, 2015 [Page 1]
22e6f294 57\f
a46255cd 58Internet-Draft SMTP security via opportunistic DANE TLS August 2014
22e6f294
JH
59
60
61 the Trust Legal Provisions and are provided without warranty as
62 described in the Simplified BSD License.
63
64Table of Contents
65
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
a46255cd 72 1.3.3. Sender policy does not scale . . . . . . . . . . . . 8
22e6f294 73 1.3.4. Too many certification authorities . . . . . . . . . 8
a46255cd
JH
74 2. Identifying applicable TLSA records . . . . . . . . . . . . . 9
75 2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 9
76 2.1.1. DNS errors, bogus and indeterminate responses . . . . 9
22e6f294 77 2.1.2. DNS error handling . . . . . . . . . . . . . . . . . 11
a46255cd
JH
78 2.1.3. Stub resolver considerations . . . . . . . . . . . . 12
79 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 13
80 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 14
22e6f294
JH
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
a46255cd
JH
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
22e6f294 93 5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26
a46255cd
JH
94 6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 28
95 7. Note on DANE for Message User Agents . . . . . . . . . . . . 29
22e6f294
JH
96 8. Interoperability considerations . . . . . . . . . . . . . . . 29
97 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 29
a46255cd 98 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 30
22e6f294
JH
99 9. Operational Considerations . . . . . . . . . . . . . . . . . 30
100 9.1. Client Operational Considerations . . . . . . . . . . . . 30
a46255cd 101 9.2. Publisher Operational Considerations . . . . . . . . . . 31
22e6f294 102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
a46255cd
JH
103 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32
104 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
105 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
106 13.1. Normative References . . . . . . . . . . . . . . . . . . 33
107 13.2. Informative References . . . . . . . . . . . . . . . . . 34
108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
22e6f294
JH
109
110
111
a46255cd 112Dukhovni & Hardaker Expires February 3, 2015 [Page 2]
22e6f294 113\f
a46255cd 114Internet-Draft SMTP security via opportunistic DANE TLS August 2014
22e6f294
JH
115
116
1171. Introduction
118
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.
127
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
a46255cd
JH
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.
22e6f294
JH
135
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.
142
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.
151
1521.1. Terminology
153
154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
156 "OPTIONAL" in this document are to be interpreted as described in
157 [RFC2119].
158
159 The following terms or concepts are used through the document:
160
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.
164
165
166
167
a46255cd 168Dukhovni & Hardaker Expires February 3, 2015 [Page 3]
22e6f294 169\f
a46255cd 170Internet-Draft SMTP security via opportunistic DANE TLS August 2014
22e6f294
JH
171
172
173 secure, bogus, insecure, indeterminate: DNSSEC validation results,
174 as defined in Section 4.3 of [RFC4035].
175
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
a46255cd 180 Stub Resolver.
22e6f294
JH
181
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.
188
a46255cd
JH
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.
196
22e6f294
JH
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).
204
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.
212
213 delayed delivery: Email delivery is a multi-hop store & forward
214 process. When an MTA is unable forward a message that may become
a46255cd 215 deliverable later the message is queued and delivery is retried
22e6f294
JH
216 periodically. Some MTAs may be configured with a fallback next-
217 hop destination that handles messages that the MTA would otherwise
a46255cd
JH
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
22e6f294
JH
221
222
223
a46255cd 224Dukhovni & Hardaker Expires February 3, 2015 [Page 4]
22e6f294 225\f
a46255cd 226Internet-Draft SMTP security via opportunistic DANE TLS August 2014
22e6f294
JH
227
228
a46255cd
JH
229 may itself be subject to opportunistic or mandatory DANE TLS as
230 though it were the original message destination.
22e6f294
JH
231
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.
238
239 MTA: Message Transfer Agent ([RFC5598], Section 4.3.2).
240
241 MSA: Message Submission Agent ([RFC5598], Section 4.3.1).
242
243 MUA: Message User Agent ([RFC5598], Section 4.2.1).
244
245 RR: A DNS Resource Record
246
247 RRset: A set of DNS Resource Records for a particular class, domain
248 and record type.
249
2501.2. Background
251
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].
256
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.
265
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.
271
272
273
274
275
276
277
278
279
a46255cd 280Dukhovni & Hardaker Expires February 3, 2015 [Page 5]
22e6f294 281\f
a46255cd 282Internet-Draft SMTP security via opportunistic DANE TLS August 2014
22e6f294
JH
283
284
2851.3. SMTP channel security
286
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.
294
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.
306
3071.3.1. STARTTLS downgrade attack
308
309 The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop
a46255cd
JH
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.
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336Dukhovni & Hardaker Expires February 3, 2015 [Page 6]
337\f
338Internet-Draft SMTP security via opportunistic DANE TLS August 2014
339
22e6f294
JH
340
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.
353
22e6f294
JH
3541.3.2. Insecure server name without DNSSEC
355
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.
360
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
a46255cd
JH
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.
22e6f294
JH
372
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.
384
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.
389
a46255cd
JH
390
391
392Dukhovni & Hardaker Expires February 3, 2015 [Page 7]
393\f
394Internet-Draft SMTP security via opportunistic DANE TLS August 2014
395
396
22e6f294
JH
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
a46255cd 402 selected high-value receiving domains by configuring explicit trust
22e6f294 403 anchors for those domains instead of relying on the chain of trust
a46255cd
JH
404 from the root domain. However, detailed discussion of DNSSEC
405 security practices is out of scope for this document.
22e6f294
JH
406
4071.3.3. Sender policy does not scale
408
22e6f294
JH
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.
419
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.
427
4281.3.4. Too many certification authorities
429
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
a46255cd 436 fails. With no user to "click OK", the MTA's list of public CA trust
22e6f294
JH
437 anchors would need to be comprehensive in order to avoid bouncing
438 mail addressed to sites that employ unknown Certification
439 Authorities.
440
22e6f294 441
22e6f294 442
22e6f294 443
22e6f294
JH
444
445
446
447
a46255cd
JH
448Dukhovni & Hardaker Expires February 3, 2015 [Page 8]
449\f
450Internet-Draft SMTP security via opportunistic DANE TLS August 2014
22e6f294
JH
451
452
a46255cd
JH
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.
22e6f294 458
a46255cd 4592. Identifying applicable TLSA records
22e6f294 460
a46255cd 4612.1. DNS considerations
22e6f294 462
a46255cd 4632.1.1. DNS errors, bogus and indeterminate responses
22e6f294
JH
464
465 An SMTP client that implements opportunistic DANE TLS per this
466 specification depends critically on the integrity of DNSSEC lookups,
a46255cd 467 as discussed in Section 1.3.2. This section lists the DNS resolver
22e6f294
JH
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, 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
a46255cd
JH
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].
494
22e6f294 495 SMTP clients following this specification SHOULD NOT distinguish
a46255cd
JH
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 includes the case of
501
502
503
504Dukhovni & Hardaker Expires February 3, 2015 [Page 9]
505\f
506Internet-Draft SMTP security via opportunistic DANE TLS August 2014
507
508
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.
22e6f294
JH
514
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
a46255cd 519 "indeterminate" security status (in the sense of RFC4035) to the
22e6f294
JH
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.
524
22e6f294
JH
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
a46255cd
JH
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]:
22e6f294
JH
531
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.
537
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.
544
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.
555
a46255cd
JH
556
557
558
559
560Dukhovni & Hardaker Expires February 3, 2015 [Page 10]
561\f
562Internet-Draft SMTP security via opportunistic DANE TLS August 2014
563
564
22e6f294
JH
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.
574
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.
582
22e6f294
JH
5832.1.2. DNS error handling
584
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.
594
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.
603
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.
611
a46255cd
JH
612
613
614
615
616Dukhovni & Hardaker Expires February 3, 2015 [Page 11]
617\f
618Internet-Draft SMTP security via opportunistic DANE TLS August 2014
619
620
22e6f294
JH
6212.1.3. Stub resolver considerations
622
a46255cd
JH
623 SMTP clients that employ opportunistic DANE TLS to secure connections
624 to SMTP servers MUST NOT use Security-Oblivious stub-resolvers.
625
22e6f294 626 A note about DNAME aliases: a query for a domain name whose ancestor
a46255cd 627 domain is a DNAME alias returns the DNAME RR for the ancestor domain
22e6f294
JH
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
a46255cd 633 DNAME records is needed in SMTP software; it is sufficient to process
22e6f294
JH
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.
640
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
22e6f294
JH
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.
648
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".
655
a46255cd
JH
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".
22e6f294
JH
664
665 If the SMTP client needs to determine the security status of the DNS
a46255cd 666 zone containing the initial CNAME record, it may need to issue a
22e6f294
JH
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
a46255cd
JH
669
670
671
672Dukhovni & Hardaker Expires February 3, 2015 [Page 12]
673\f
674Internet-Draft SMTP security via opportunistic DANE TLS August 2014
675
676
22e6f294
JH
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.
680
6812.2. TLS discovery
682
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
691 STARTTLS.
692
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:
698
22e6f294
JH
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.
704
a46255cd 705 A secure non-empty TLSA RRset where all the records are unusable: A
22e6f294
JH
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.
710
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.
718
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.
722
723 An SMTP client MAY be configured to require DANE verified delivery
724 for some destinations. We will call such a configuration "mandatory
a46255cd
JH
725
726
727
728Dukhovni & Hardaker Expires February 3, 2015 [Page 13]
729\f
730Internet-Draft SMTP security via opportunistic DANE TLS August 2014
731
732
22e6f294
JH
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.
736
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
a46255cd
JH
741 lieu of an MX hostname, if an MTA chooses to connect to the network
742 address in the non-conformat MX record, DANE TLSA does not apply for
743 such a connection.
22e6f294
JH
744
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.
749
7502.2.1. MX resolution
751
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
22e6f294
JH
756 delivery to the intended next-hop domain only when the MX records are
757 obtained securely via a DNSSEC validated lookup.
758
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.
769
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
a46255cd
JH
775 is performed repeatedly (up to the MTA's recursion limit) until the
776 ultimate non-CNAME domain is found.
22e6f294
JH
777
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
a46255cd
JH
781
782
783
784Dukhovni & Hardaker Expires February 3, 2015 [Page 14]
785\f
786Internet-Draft SMTP security via opportunistic DANE TLS August 2014
787
788
22e6f294
JH
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.
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. When DANE TLS is mandatory (Section 6) for
809 a given destination, delivery MUST be delayed when the MX RRset is
810 not "secure".
811
22e6f294
JH
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.
822
8232.2.2. Non-MX destinations
824
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:
828
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.
833
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.
837
a46255cd
JH
838
839
840Dukhovni & Hardaker Expires February 3, 2015 [Page 15]
841\f
842Internet-Draft SMTP security via opportunistic DANE TLS August 2014
843
844
22e6f294
JH
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.
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, but queries for TLSA records fail,
853 rather than returning the non-existence of the requested TLSA
854 records.
855
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.
863
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
22e6f294
JH
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.
874
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
a46255cd 878 performed recursively (up to the MTA's recursion limit).
22e6f294
JH
879
880 We consider the following cases for handling a DNS response for an A
881 or AAAA DNS lookup:
882
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.
886
a46255cd
JH
887
888
889
890
891
892
893
894
895
896Dukhovni & Hardaker Expires February 3, 2015 [Page 16]
897\f
898Internet-Draft SMTP security via opportunistic DANE TLS August 2014
899
900
22e6f294
JH
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).
908
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.
915
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.
920
22e6f294
JH
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.
930
9312.2.3. TLSA record lookup
932
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).
938
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:
945
946 _25._tcp.mx.example.com. IN TLSA ?
947
a46255cd
JH
948
949
950
951
952Dukhovni & Hardaker Expires February 3, 2015 [Page 17]
953\f
954Internet-Draft SMTP security via opportunistic DANE TLS August 2014
955
956
22e6f294
JH
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
a46255cd 963 base domain is tried instead.
22e6f294
JH
964
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.
975
976 TLSA record publishers may leverage CNAMEs to reference a single
977 authoritative TLSA RRset specifying a common Certification Authority
22e6f294
JH
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.
984
a46255cd 985 Note that shared end entity certificate associations expose the
22e6f294
JH
986 publishing domain to substitution attacks, where an MITM attacker can
987 reroute traffic to a different server that shares the same end entity
a46255cd
JH
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).
22e6f294 992
a46255cd
JH
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:
22e6f294
JH
996
997 example.com. IN MX 0 mx1.example.com.
998 example.com. IN MX 0 mx2.example.com.
a46255cd
JH
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...
22e6f294
JH
1002
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
a46255cd
JH
1005
1006
1007
1008Dukhovni & Hardaker Expires February 3, 2015 [Page 18]
1009\f
1010Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1011
1012
22e6f294
JH
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".
1017
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.
1026
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".
1035
22e6f294
JH
10363. DANE authentication
1037
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.
1047
10483.1. TLSA certificate usages
1049
1050 The DANE TLSA specification [RFC6698] defines multiple TLSA RR types
1051 via combinations of 3 numeric parameters. The numeric values of
a46255cd
JH
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:
1056
1057
1058
1059
1060
1061
1062
1063
1064Dukhovni & Hardaker Expires February 3, 2015 [Page 19]
1065\f
1066Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1067
22e6f294
JH
1068
1069 The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698]
a46255cd
JH
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.
22e6f294 1074
a46255cd
JH
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:
22e6f294
JH
1077 PrivSel(255). All other values are reserved for use by future
1078 specifications.
1079
a46255cd
JH
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.
22e6f294
JH
1084
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.
1089
1090 The selector field specifies whether the TLSA RR matches the whole
1091 certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1). The
a46255cd
JH
1092 subjectPublicKeyInfo is an ASN.1 DER ([X.690]) encoding of the
1093 certificate's algorithm id, any parameters and the public key data.
22e6f294
JH
1094
1095 The matching type field specifies how the TLSA RR Certificate
1096 Association Data field is to be compared with the certificate or
22e6f294
JH
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.
1102
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.
1110
a46255cd
JH
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120Dukhovni & Hardaker Expires February 3, 2015 [Page 20]
1121\f
1122Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1123
1124
22e6f294
JH
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.
1132
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.
1138
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.
1149
11503.1.1. Certificate usage DANE-EE(3)
1151
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.
1158
22e6f294
JH
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.
1163
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.
1171
a46255cd
JH
1172
1173
1174
1175
1176Dukhovni & Hardaker Expires February 3, 2015 [Page 21]
1177\f
1178Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1179
1180
22e6f294
JH
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.
1188
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.
1194
11953.1.2. Certificate usage DANE-TA(2)
1196
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:
1206
1207 example.com. IN MX 0 mx1.example.com.
1208 example.com. IN MX 0 mx2.example.com.
a46255cd
JH
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....
22e6f294
JH
1212
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.
1217
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.
1229
a46255cd
JH
1230
1231
1232Dukhovni & Hardaker Expires February 3, 2015 [Page 22]
1233\f
1234Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1235
1236
22e6f294
JH
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.
1247
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.
1254
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.
1261
12623.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1)
1263
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
22e6f294
JH
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.
1271
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.
1278
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.
1285
a46255cd
JH
1286
1287
1288Dukhovni & Hardaker Expires February 3, 2015 [Page 23]
1289\f
1290Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1291
1292
22e6f294
JH
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.
1296
12973.2. Certificate matching
1298
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.
1303
13043.2.1. DANE-EE(3) name checks
1305
1306 The SMTP client MUST NOT perform certificate name checks with
a46255cd 1307 certificate usage DANE-EE(3); see Section 3.1.1 above.
22e6f294
JH
1308
13093.2.2. DANE-TA(2) name checks
1310
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.
1316
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
22e6f294
JH
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.
1326
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.
1331
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:
1339
a46255cd
JH
1340
1341
1342
1343
1344Dukhovni & Hardaker Expires February 3, 2015 [Page 24]
1345\f
1346Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1347
1348
22e6f294
JH
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 192.0.2.10
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 192.0.2.15
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 198.51.100.20
1365 _25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...
1366
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".
1377
13783.2.3. Reference identifier matching
1379
22e6f294
JH
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.
1388
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
a46255cd
JH
1397
1398
1399
1400Dukhovni & Hardaker Expires February 3, 2015 [Page 25]
1401\f
1402Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1403
1404
22e6f294
JH
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.
1409
14104. Server key management
1411
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.
1419
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.
1423
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.
1435
22e6f294
JH
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 CNAME
1442 record. If the central trust anchor is compromised, all servers need
1443 to be issued new keys by a new TA, and a shared DANE-TA(2) TLSA RRset
1444 needs to be published containing just the new TA. SMTP servers
1445 cannot expect broad SMTP client CRL or OCSP support.
1446
14475. Digest algorithm agility
1448
1449 While [RFC6698] specifies multiple digest algorithms, it does not
1450 specify a protocol by which the SMTP client and TLSA record publisher
1451 can agree on the strongest shared algorithm. Such a protocol would
1452 allow the client and server to avoid exposure to any deprecated
a46255cd
JH
1453
1454
1455
1456Dukhovni & Hardaker Expires February 3, 2015 [Page 26]
1457\f
1458Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1459
1460
22e6f294
JH
1461 weaker algorithms that are published for compatibility with less
1462 capable clients, but should be ignored when possible. We specify
1463 such a protocol below.
1464
1465 Suppose that a DANE TLS client authenticating a TLS server considers
1466 digest algorithm "BetterAlg" stronger than digest algorithm
1467 "WorseAlg". Suppose further that a server's TLSA RRset contains some
1468 records with "BetterAlg" as the digest algorithm. Finally, suppose
1469 that for every raw public key or certificate object that is included
1470 in the server's TLSA RRset in digest form, whenever that object
1471 appears with algorithm "WorseAlg" with some usage and selector it
1472 also appears with algorithm "BetterAlg" with the same usage and
1473 selector. In that case our client can safely ignore TLSA records
1474 with the weaker algorithm "WorseAlg", because it suffices to check
1475 the records with the stronger algorithm "BetterAlg".
1476
1477 Server operators MUST ensure that for any given usage and selector,
1478 each object (certificate or public key), for which a digest
1479 association exists in the TLSA RRset, is published with the SAME SET
1480 of digest algorithms as all other objects that published with that
1481 usage and selector. In other words, for each usage and selector, the
1482 records with non-zero matching types will correspond to on a cross-
1483 product of a set of underlying objects and a fixed set of digest
1484 algorithms that apply uniformly to all the objects.
1485
1486 To achieve digest algorithm agility, all published TLSA RRsets for
1487 use with opportunistic DANE TLS for SMTP MUST conform to the above
1488 requirements. Then, for each combination of usage and selector, SMTP
1489 clients can simply ignore all digest records except those that employ
1490 the strongest digest algorithm. The ordering of digest algorithms by
1491 strength is not specified in advance, it is entirely up to the SMTP
22e6f294
JH
1492 client. SMTP client implementations SHOULD make the digest algorithm
1493 preference order configurable. Only the future will tell which
1494 algorithms might be weakened by new attacks and when.
1495
1496 Note, TLSA records with a matching type of Full(0), that publish the
1497 full value of a certificate or public key object, play no role in
1498 digest algorithm agility. They neither trump the processing of
1499 records that employ digests, nor are they ignored in the presence of
1500 any records with a digest (i.e. non-zero) matching type.
1501
a46255cd
JH
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512Dukhovni & Hardaker Expires February 3, 2015 [Page 27]
1513\f
1514Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1515
1516
22e6f294
JH
1517 SMTP clients SHOULD use digest algorithm agility when processing the
1518 DANE TLSA records of an SMTP server. Algorithm agility is to be
1519 applied after first discarding any unusable or malformed records
1520 (unsupported digest algorithm, or incorrect digest length). Thus,
1521 for each usage and selector, the client SHOULD process only any
1522 usable records with a matching type of Full(0) and the usable records
1523 whose digest algorithm is believed to be the strongest among usable
1524 records with the given usage and selector.
1525
1526 The main impact of this requirement is on key rotation, when the TLSA
1527 RRset is pre-populated with digests of new certificates or public
1528 keys, before these replace or augment their predecessors. Were the
1529 newly introduced RRs to include previously unused digest algorithms,
1530 clients that employ this protocol could potentially ignore all the
1531 digests corresponding to the current keys or certificates, causing
1532 connectivity issues until the new keys or certificates are deployed.
1533 Similarly, publishing new records with fewer digests could cause
1534 problems for clients using cached TLSA RRsets that list both the old
1535 and new objects once the new keys are deployed.
1536
1537 To avoid problems, server operators SHOULD apply the following
1538 strategy:
1539
1540 o When changing the set of objects published via the TLSA RRset
1541 (e.g. during key rotation), DO NOT change the set of digest
1542 algorithms used; change just the list of objects.
1543
1544 o When changing the set of digest algorithms, change only the set of
1545 algorithms, and generate a new RRset in which all the current
1546 objects are re-published with the new set of digest algorithms.
1547
1548 After either of these two changes are made, the new TLSA RRset should
1549 be left in place long enough that the older TLSA RRset can be flushed
1550 from caches before making another change.
1551
15526. Mandatory TLS Security
1553
22e6f294
JH
1554 An MTA implementing this protocol may require a stronger security
1555 assurance when sending email to selected destinations. The sending
1556 organization may need to send sensitive email and/or may have
1557 regulatory obligations to protect its content. This protocol is not
1558 in conflict with such a requirement, and in fact can often simplify
1559 authenticated delivery to such destinations.
1560
1561 Specifically, with domains that publish DANE TLSA records for their
1562 MX hostnames, a sending MTA can be configured to use the receiving
1563 domains's DANE TLSA records to authenticate the corresponding SMTP
1564 server. Authentication via DANE TLSA records is easier to manage, as
a46255cd
JH
1565
1566
1567
1568Dukhovni & Hardaker Expires February 3, 2015 [Page 28]
1569\f
1570Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1571
1572
22e6f294
JH
1573 changes in the receiver's expected certificate properties are made on
1574 the receiver end and don't require manually communicated
1575 configuration changes. With mandatory DANE TLS, when no usable TLSA
1576 records are found, message delivery is delayed. Thus, mail is only
1577 sent when an authenticated TLS channel is established to the remote
1578 SMTP server.
1579
1580 Administrators of mail servers that employ mandatory DANE TLS, need
1581 to carefully monitor their mail logs and queues. If a partner domain
1582 unwittingly misconfigures their TLSA records, disables DNSSEC, or
1583 misconfigures SMTP server certificate chains, mail will be delayed
1584 and may bounce if the issue is not resolved in a timely manner.
1585
15867. Note on DANE for Message User Agents
1587
1588 We note that the SMTP protocol is also used between Message User
1589 Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In
1590 [RFC6186] a protocol is specified that enables an MUA to dynamically
1591 locate the MSA based on the user's email address. SMTP connection
1592 security considerations for MUAs implementing [RFC6186] are largely
1593 analogous to connection security requirements for MTAs, and this
1594 specification could be applied largely verbatim with DNS MX records
1595 replaced by corresponding DNS Service (SRV) records
1596 [I-D.ietf-dane-srv].
1597
1598 However, until MUAs begin to adopt the dynamic configuration
1599 mechanisms of [RFC6186] they are adequately served by more
1600 traditional static TLS security policies. Specification of DANE TLS
1601 for Message User Agent (MUA) to Message Submission Agent (MSA) SMTP
1602 is left to future documents that focus specifically on SMTP security
1603 between MUAs and MSAs.
1604
22e6f294
JH
16058. Interoperability considerations
1606
16078.1. SNI support
1608
1609 To ensure that the server sends the right certificate chain, the SMTP
1610 client MUST send the TLS SNI extension containing the TLSA base
1611 domain. This precludes the use of the backward compatible SSL 2.0
1612 compatible SSL HELLO by the SMTP client. The minimum SSL/TLS client
1613 HELLO version for SMTP clients performing DANE authentication is SSL
1614 3.0, but a client that offers SSL 3.0 MUST also offer at least TLS
1615 1.0 and MUST include the SNI extension. Servers that don't make use
1616 of SNI MAY negotiate SSL 3.0 if offered by the client.
1617
1618 Each SMTP server MUST present a certificate chain (see [RFC5246]
1619 Section 7.4.2) that matches at least one of the TLSA records. The
1620 server MAY rely on SNI to determine which certificate chain to
a46255cd
JH
1621
1622
1623
1624Dukhovni & Hardaker Expires February 3, 2015 [Page 29]
1625\f
1626Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1627
1628
22e6f294
JH
1629 present to the client. Clients that don't send SNI information may
1630 not see the expected certificate chain.
1631
1632 If the server's TLSA records match the server's default certificate
1633 chain, the server need not support SNI. In either case, the server
1634 need not include the SNI extension in its TLS HELLO as simply
1635 returning a matching certificate chain is sufficient. Servers MUST
1636 NOT enforce the use of SNI by clients, as the client may be using
1637 unauthenticated opportunistic TLS and may not expect any particular
1638 certificate from the server. If the client sends no SNI extension,
1639 or sends an SNI extension for an unsupported domain, the server MUST
1640 simply send some fallback certificate chain of its choice. The
1641 reason for not enforcing strict matching of the requested SNI
1642 hostname is that DANE TLS clients are typically willing to accept
1643 multiple server names, but can only send one name in the SNI
1644 extension. The server's fallback certificate may match a different
1645 name acceptable to the client, e.g., the original next-hop domain.
1646
16478.2. Anonymous TLS cipher suites
1648
1649 Since many SMTP servers either do not support or do not enable any
1650 anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD
1651 offer to negotiate a typical set of non-anonymous cipher suites
1652 required for interoperability with such servers. An SMTP client
1653 employing pre-DANE opportunistic TLS MAY in addition include one or
1654 more anonymous TLS cipher suites in its TLS HELLO. SMTP servers,
1655 that need to interoperate with opportunistic TLS clients SHOULD be
1656 prepared to interoperate with such clients by either always selecting
1657 a mutually supported non-anonymous cipher suite or by correctly
1658 handling client connections that negotiate anonymous cipher suites.
1659
22e6f294
JH
1660 Note that while SMTP server operators are under no obligation to
1661 enable anonymous cipher suites, no security is gained by sending
1662 certificates to clients that will ignore them. Indeed support for
1663 anonymous cipher suites in the server makes audit trails more
1664 informative. Log entries that record connections that employed an
1665 anonymous cipher suite record the fact that the clients did not care
1666 to authenticate the server.
1667
16689. Operational Considerations
1669
16709.1. Client Operational Considerations
1671
1672 An operational error on the sending or receiving side that cannot be
1673 corrected in a timely manner may, at times, lead to consistent
1674 failure to deliver time-sensitive email. The sending MTA
1675 administrator may have to choose between letting email queue until
1676 the error is resolved and disabling opportunistic or mandatory DANE
a46255cd
JH
1677
1678
1679
1680Dukhovni & Hardaker Expires February 3, 2015 [Page 30]
1681\f
1682Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1683
1684
22e6f294
JH
1685 TLS for one or more destinations. The choice to disable DANE TLS
1686 security should not be made lightly. Every reasonable effort should
1687 be made to determine that problems with mail delivery are the result
1688 of an operational error, and not an attack. A fallback strategy may
1689 be to configure explicit out-of-band TLS security settings if
1690 supported by the sending MTA.
1691
1692 SMTP clients may deploy opportunistic DANE TLS incrementally by
1693 enabling it only for selected sites, or may occasionally need to
1694 disable opportunistic DANE TLS for peers that fail to interoperate
1695 due to misconfiguration or software defects on either end. Some
1696 implementations MAY support DANE TLS in an "audit only" mode in which
1697 failure to achieve the requisite security level is logged as a
1698 warning and delivery proceeds at a reduced security level. Unless
1699 local policy specifies "audit only" or that opportunistic DANE TLS is
1700 not to be used for a particular destination, an SMTP client MUST NOT
1701 deliver mail via a server whose certificate chain fails to match at
1702 least one TLSA record when usable TLSA records are found for that
1703 server.
1704
17059.2. Publisher Operational Considerations
1706
1707 SMTP servers that publish certificate usage DANE-TA(2) associations
1708 MUST include the TA certificate in their TLS server certificate
1709 chain, even when that TA certificate is a self-signed root
1710 certificate.
1711
a46255cd
JH
1712 TLSA Publishers MUST follow the digest agility guidelines in
1713 Section 5 and MUST make sure that all objects published in digest
22e6f294
JH
1714 form for a particular usage and selector are published with the same
1715 set of digest algorithms.
1716
22e6f294
JH
1717 TLSA Publishers should follow the TLSA publication size guidance
1718 found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines".
1719
172010. Security Considerations
1721
1722 This protocol leverages DANE TLSA records to implement MITM resistant
a46255cd
JH
1723 opportunistic security ([I-D.dukhovni-opportunistic-security]) for
1724 SMTP. For destination domains that sign their MX records and publish
1725 signed TLSA records for their MX hostnames, this protocol allows
1726 sending MTAs to securely discover both the availability of TLS and
1727 how to authenticate the destination.
1728
1729
1730
1731
1732
1733
1734
1735
1736Dukhovni & Hardaker Expires February 3, 2015 [Page 31]
1737\f
1738Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1739
22e6f294
JH
1740
1741 This protocol does not aim to secure all SMTP traffic, as that is not
1742 practical until DNSSEC and DANE adoption are universal. The
1743 incremental deployment provided by following this specification is a
1744 best possible path for securing SMTP. This protocol coexists and
1745 interoperates with the existing insecure Internet email backbone.
1746
1747 The protocol does not preclude existing non-opportunistic SMTP TLS
1748 security arrangements, which can continue to be used as before via
1749 manual configuration with negotiated out-of-band key and TLS
1750 configuration exchanges.
1751
1752 Opportunistic SMTP TLS depends critically on DNSSEC for downgrade
1753 resistance and secure resolution of the destination name. If DNSSEC
1754 is compromised, it is not possible to fall back on the public CA PKI
1755 to prevent MITM attacks. A successful breach of DNSSEC enables the
1756 attacker to publish TLSA usage 3 certificate associations, and
1757 thereby bypass any security benefit the legitimate domain owner might
1758 hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of
1759 public CA PKI support in existing MTA deployments, avoiding
1760 certificate usages 0 and 1 simplifies implementation and deployment
1761 with no adverse security consequences.
1762
1763 Implementations must strictly follow the portions of this
1764 specification that indicate when it is appropriate to initiate a non-
1765 authenticated connection or cleartext connection to a SMTP server.
1766 Specifically, in order to prevent downgrade attacks on this protocol,
1767 implementation must not initiate a connection when this specification
1768 indicates a particular SMTP server must be considered unreachable.
1769
177011. IANA considerations
1771
1772 This specification requires no support from IANA.
1773
177412. Acknowledgements
1775
1776 The authors would like to extend great thanks to Tony Finch, who
1777 started the original version of a DANE SMTP document. His work is
22e6f294
JH
1778 greatly appreciated and has been incorporated into this document.
1779 The authors would like to additionally thank Phil Pennock for his
1780 comments and advice on this document.
1781
1782 Acknowledgments from Viktor: Thanks to Paul Hoffman who motivated me
1783 to begin work on this memo and provided feedback on early drafts.
1784 Thanks to Patrick Koetter, Perry Metzger and Nico Williams for
1785 valuable review comments. Thanks also to Wietse Venema who created
1786 Postfix, and whose advice and feedback were essential to the
1787 development of the Postfix DANE implementation.
1788
a46255cd
JH
1789
1790
1791
1792Dukhovni & Hardaker Expires February 3, 2015 [Page 32]
1793\f
1794Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1795
1796
22e6f294
JH
179713. References
1798
179913.1. Normative References
1800
1801 [I-D.ietf-dane-ops]
1802 Dukhovni, V. and W. Hardaker, "DANE TLSA implementation
1803 and operational guidance", draft-ietf-dane-ops-00 (work in
1804 progress), October 2013.
1805
1806 [RFC1035] Mockapetris, P., "Domain names - implementation and
1807 specification", STD 13, RFC 1035, November 1987.
1808
1809 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1810 Requirement Levels", BCP 14, RFC 2119, March 1997.
1811
1812 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
1813 Transport Layer Security", RFC 3207, February 2002.
1814
1815 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1816 Rose, "DNS Security Introduction and Requirements", RFC
1817 4033, March 2005.
1818
1819 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1820 Rose, "Resource Records for the DNS Security Extensions",
1821 RFC 4034, March 2005.
1822
1823 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1824 Rose, "Protocol Modifications for the DNS Security
1825 Extensions", RFC 4035, March 2005.
1826
1827 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1828 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
1829
1830 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1831 Housley, R., and W. Polk, "Internet X.509 Public Key
1832 Infrastructure Certificate and Certificate Revocation List
1833 (CRL) Profile", RFC 5280, May 2008.
1834
22e6f294
JH
1835 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1836 October 2008.
1837
1838 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
1839 Extension Definitions", RFC 6066, January 2011.
1840
a46255cd
JH
1841
1842
1843
1844
1845
1846
1847
1848Dukhovni & Hardaker Expires February 3, 2015 [Page 33]
1849\f
1850Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1851
1852
22e6f294
JH
1853 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1854 Verification of Domain-Based Application Service Identity
1855 within Internet Public Key Infrastructure Using X.509
1856 (PKIX) Certificates in the Context of Transport Layer
1857 Security (TLS)", RFC 6125, March 2011.
1858
1859 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
1860 Submission/Access Services", RFC 6186, March 2011.
1861
1862 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
1863 DNS", RFC 6672, June 2012.
1864
1865 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
1866 of Named Entities (DANE) Transport Layer Security (TLS)
1867 Protocol: TLSA", RFC 6698, August 2012.
1868
a46255cd
JH
1869 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
1870 Conversations about DNS-Based Authentication of Named
1871 Entities (DANE)", RFC 7218, April 2014.
1872
1873 [X.690] International Telecommunications Union, "Recommendation
1874 ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information
1875 technology - ASN.1 encoding rules: Specification of Basic
1876 Encoding Rules (BER), Canonical Encoding Rules (CER) and
1877 Distinguished Encoding Rules (DER)", July 2002.
1878
22e6f294
JH
187913.2. Informative References
1880
a46255cd
JH
1881 [I-D.dukhovni-opportunistic-security]
1882 Dukhovni, V., "Opportunistic Security: some protection
1883 most of the time", draft-dukhovni-opportunistic-
1884 security-01 (work in progress), July 2014.
22e6f294
JH
1885
1886 [I-D.ietf-dane-srv]
1887 Finch, T., "Using DNS-Based Authentication of Named
1888 Entities (DANE) TLSA records with SRV and MX records.",
1889 draft-ietf-dane-srv-02 (work in progress), February 2013.
1890
1891 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
1892 2009.
1893
1894 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
1895 STD 72, RFC 6409, November 2011.
1896
1897Authors' Addresses
1898
22e6f294 1899
22e6f294
JH
1900
1901
1902
1903
a46255cd 1904Dukhovni & Hardaker Expires February 3, 2015 [Page 34]
22e6f294 1905\f
a46255cd
JH
1906Internet-Draft SMTP security via opportunistic DANE TLS August 2014
1907
1908
1909 Viktor Dukhovni
1910 Two Sigma
1911
1912 Email: ietf-dane@dukhovni.org
22e6f294
JH
1913
1914
1915 Wes Hardaker
1916 Parsons
1917 P.O. Box 382
1918 Davis, CA 95617
1919 US
1920
1921 Email: ietf@hardakers.net
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
a46255cd 1960Dukhovni & Hardaker Expires February 3, 2015 [Page 35]