idnits 2.17.1 draft-ietf-dane-smtp-with-dane-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 9, 2014) is 3728 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5280' is defined on line 1277, but no explicit reference was found in the text == Unused Reference: 'RFC6409' is defined on line 1297, but no explicit reference was found in the text == Unused Reference: 'RFC6672' is defined on line 1300, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dane-smtp' is defined on line 1314, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dane-srv' is defined on line 1319, but no explicit reference was found in the text == Unused Reference: 'RFC6394' is defined on line 1327, but no explicit reference was found in the text == Unused Reference: 'RFC6895' is defined on line 1331, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-dane-ops-00 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-04) exists of draft-ietf-dane-registry-acronyms-01 == Outdated reference: A later version (-14) exists of draft-ietf-dane-srv-02 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DANE V. Dukhovni 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track W. Hardaker 5 Expires: August 13, 2014 Parsons 6 February 9, 2014 8 SMTP security via opportunistic DANE TLS 9 draft-ietf-dane-smtp-with-dane-05 11 Abstract 13 This memo describes a downgrade-resistant protocol for SMTP transport 14 security between Mail Transfer Agents (MTAs) based on the DNS-Based 15 Authentication of Named Entities (DANE) TLSA DNS record. Adoption of 16 this protocol enables an incremental transition of the Internet email 17 backbone to one using encrypted and authenticated Transport Layer 18 Security (TLS). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 13, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 5 58 1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 5 59 1.3.2. Insecure server name without DNSSEC . . . . . . . . . 6 60 1.3.3. Sender policy does not scale . . . . . . . . . . . . 7 61 1.3.4. Too many certificate authorities . . . . . . . . . . 7 62 2. Hardening (pre-DANE) Opportunistic TLS . . . . . . . . . . . 8 63 2.1. DNS errors, bogus and indeterminate responses . . . . . . 8 64 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 11 65 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 13 66 2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 14 67 2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 16 68 2.3. DANE authentication . . . . . . . . . . . . . . . . . . . 17 69 2.3.1. TLSA certificate usages . . . . . . . . . . . . . . . 18 70 2.3.2. Certificate matching . . . . . . . . . . . . . . . . 20 71 2.3.3. Digest algorithm agility . . . . . . . . . . . . . . 23 72 3. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 25 73 4. Operational Considerations . . . . . . . . . . . . . . . . . 25 74 4.1. Client Operational Considerations . . . . . . . . . . . . 25 75 4.2. Publisher Operational Considerations . . . . . . . . . . 25 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 77 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 81 8.2. Informative References . . . . . . . . . . . . . . . . . 28 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 84 1. Introduction 86 This memo specifies a new connection security model for Message 87 Transfer Agents (MTAs). This model is motivated by key features of 88 inter-domain SMTP delivery, in particular the fact that the 89 destination server is selected indirectly via DNS Mail Exchange (MX) 90 records and that with MTA to MTA SMTP the use of TLS is generally 91 opportunistic. 93 We note that the SMTP protocol is also used between Message User 94 Agents (MUAs) and Message Submission Agents (MSAs). In [RFC6186] a 95 protocol is specified that enables an MUA to dynamically locate the 96 MSA based on the user's email address. SMTP connection security 97 requirements for MUAs implementing [RFC6186] are largely analogous to 98 connection security requirements for MTAs, and this specification 99 could be applied largely verbatim with DNS MX records replaced by 100 corresponding DNS Service (SRV) records. 102 However, until MUAs begin to adopt the dynamic configuration 103 mechanisms of [RFC6186] they are adequately served by more 104 traditional static TLS security policies. This document will not 105 discuss the MUA use case further, leaving specification of DANE TLS 106 for MUAs to future documents that focus specifically on SMTP security 107 between MUAs and MSAs. The rest of this memo will focus on securing 108 MTA to MTA SMTP connections. 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in 115 [RFC2119]. 117 The following terms or concepts are used through the document: 119 secure, bogus, insecure, indeterminate: DNSSEC validation results, 120 as defined in Section 4.3 of [RFC4035]. 122 Validating Security-Aware Stub Resolver and Non-Validating 123 Security-Aware Stub Resolver: 124 Capabilities of the stub resolver in use as defined in [RFC4033]; 125 note that this specification requires the use of a Security-Aware 126 Stub Resolver; Security-Oblivious stub-resolvers MUST NOT be used. 128 opportunistic DANE TLS: Best-effort use of TLS, resistant to 129 downgrade attacks for destinations with DNSSEC-validated TLSA 130 records. When opportunistic DANE TLS is determined to be 131 unavailable, clients should fall back to opportunistic TLS below. 132 Opportunistic DANE TLS requires support for DNSSEC, DANE and 133 STARTTLS on the client side and STARTTLS plus a DNSSEC published 134 TLSA record on the server side. 136 (pre-DANE) opportunistic TLS: Best-effort use of TLS that is 137 generally vulnerable to DNS forgery and STARTTLS downgrade 138 attacks. When a TLS-encrypted communication channel is not 139 available, message transmission takes place in the clear. MX 140 record indirection generally precludes authentication even when 141 TLS is available. 143 MX hostname: The RRDATA of an MX record consists of a 16 bit 144 preference followed by a Mail Exchange domain name (see [RFC1035], 145 Section 3.3.9). We will use the term "MX hostname" to refer to 146 the latter, that is, the DNS domain name found after the 147 preference value in an MX record. Thus an "MX hostname" is 148 specifically a reference to a DNS domain name, rather than any 149 host that bears that name. 151 SMTP server: An SMTP server whose name appears in an MX record for a 152 particular domain. Used to refer specifically to the host and 153 SMTP service itself, not its DNS name. 155 delayed delivery: Email delivery is a multi-hop store & forward 156 process. When an MTA is unable forward a message that may become 157 deliverable later, the message is queued and delivery is retried 158 periodically. Some MTAs may be configured with a fallback next- 159 hop destination that handles messages that the MTA would otherwise 160 queue and retry. In these cases, messages that would otherwise 161 have to be delayed, may be sent to the fallback next-hop 162 destination instead. The fallback destination may itself be 163 subject to opportunistic or mandatory DANE TLS as though it were 164 the original message destination. 166 original next hop destination: The logical destination for mail 167 delivery. By default this is the domain portion of the recipient 168 address, but MTAs may be configured to forward mail for some or 169 all recipients via designated relays. The original next hop 170 destination is, respectively, either the recipient domain or the 171 associated configured relay. 173 MTA: Message Transfer Agent ([RFC5598], Section 4.3.2). 175 MSA: Message Submission Agent ([RFC5598], Section 4.3.1). 177 MUA: Message User Agent ([RFC5598], Section 4.2.1). 179 RR: A DNS Resource Record 181 RRset: A set of DNS Resource Records for a particular class, domain 182 and record type. 184 1.2. Background 186 The Domain Name System Security Extensions (DNSSEC) adds data origin 187 authentication, data integrity and data non-existence proofs to the 188 Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034] 189 and [RFC4035]. 191 As described in the introduction of [RFC6698], TLS authentication via 192 the existing public Certificate Authority (CA) PKI suffers from an 193 over-abundance of trusted certificate authorities capable of issuing 194 certificates for any domain of their choice. DANE leverages the 195 DNSSEC infrastructure to publish trusted public keys and certificates 196 for use with the Transport Layer Security (TLS) [RFC5246] protocol 197 via a new "TLSA" DNS record type. With DNSSEC each domain can only 198 vouch for the keys of its directly delegated sub-domains. 200 The TLS protocol enables secure TCP communication. In the context of 201 this memo, channel security is assumed to be provided by TLS. Used 202 without authentication, TLS provides only privacy protection against 203 eavesdropping attacks. With authentication, TLS also provides data 204 integrity protection to guard against man-in-the-middle (MITM) 205 attacks. 207 1.3. SMTP channel security 209 With HTTPS, Transport Layer Security (TLS) employs X.509 certificates 210 issued by one of the many Certificate Authorities (CAs) bundled with 211 popular web browsers to allow users to authenticate their "secure" 212 websites. Before we specify a new DANE TLS security model for SMTP, 213 we will explain why a new security model is needed. In the process, 214 we will explain why the familiar HTTPS security model is is 215 inadequate to protect inter-domain SMTP traffic. 217 The subsections below outline four key problems with applying 218 traditional PKI to SMTP that are addressed by this specification. 219 Since SMTP channel security policy is not explicitly specified in 220 either the recipient address or the MX record, a new signaling 221 mechanism is required to indicate when channel security is possible 222 and should be used. The publication of TLSA records allows server 223 operators to securely signal to SMTP clients that TLS is available 224 and should be used. DANE TLSA makes it possible to simultaneously 225 discover which destination domains support secure delivery via TLS 226 and how to verify the authenticity of the associated SMTP services 227 providing a path forward to ubiquitous SMTP channel security. 229 1.3.1. STARTTLS downgrade attack 231 The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop 232 protocol in a multi-hop store & forward email delivery process. SMTP 233 envelope recipient addresses are not transport addresses and are 234 security-agnostic. Unlike the Hypertext Transfer Protocol (HTTP) and 235 its corresponding secured version, HTTPS, there is no URI scheme for 236 email addresses to designate whether communication with the SMTP 237 server should be conducted via a cleartext or a TLS-encrypted 238 channel. Indeed no such URI scheme could work well with SMTP since 239 TLS encryption of SMTP protects email traffic on a hop-by-hop basis 240 while email addresses could only express end-to-end policy. 242 With no mechanism available to signal transport security policy, SMTP 243 relays employ a best-effort "opportunistic" security model for TLS. 244 A single SMTP server TCP listening endpoint can serve both TLS and 245 non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS 246 command ([RFC3207]). The server signals TLS support to the client 247 over a cleartext SMTP connection, and if the client also supports 248 TLS, it may negotiate a TLS encrypted channel to use for email 249 transmission. The server's indication of TLS support can be easily 250 suppressed by a man in the middle attacker. Thus pre-DANE SMTP TLS 251 security can be subverted by simply downgrading a connection to 252 cleartext. No TLS security feature, such as the use of PKIX, can 253 prevent this. The attacker can simply bypass TLS. 255 1.3.2. Insecure server name without DNSSEC 257 With SMTP, DNS Mail Exchange (MX) records abstract the next-hop 258 transport endpoint and allow administrators to specify a set of 259 target servers to which SMTP traffic should be directed for a given 260 domain. 262 A PKIX TLS client is vulnerable to man in the middle (MITM) attacks 263 unless it verifies that the server's certificate binds its public key 264 to its name. However, with SMTP server names are obtained indirectly 265 via MX records. Without DNSSEC, the MX lookup is vulnerable MITM and 266 DNS cache poisoning attacks. Active attackers can forge DNS replies 267 with fake MX records, and can redirect email to servers with names of 268 their choice. Therefore, secure verification of SMTP TLS 269 certificates is not possible without DNSSEC. 271 One might try to harden the use of TLS with SMTP against DNS attacks 272 by requiring each SMTP server to possess a trusted certificate for 273 the envelope recipient domain rather than the MX hostname. 274 Unfortunately, this is impractical, as email for many domains is 275 handled by third parties that are not in a position to obtain 276 certificates for all the domains they serve. Deployment of the 277 Server Name Indication (SNI) extension to TLS (see [RFC6066] 278 Section 3) is no panacea, since SNI key management is operationally 279 challenging except when the email service provider is also the 280 domain's registrar and its certificate issuer; this is rarely the 281 case for email. 283 Since the recipient domain name cannot be used as the SMTP server 284 authentication identity, and neither can the MX hostname without 285 DNSSEC, large-scale deployment of authenticated TLS for SMTP requires 286 that the DNS be secure. 288 Since SMTP security depends critically on DNSSEC, it is important to 289 point out that consequently SMTP with DANE is the most conservative 290 possible trust model. It trusts only what must be trusted and no 291 more. Adding any other trusted actors to the mix can only reduce 292 SMTP security. A sender may choose to harden DNSSEC for selected 293 high value receiving domains, by configuring explicit trust anchors 294 for those domains instead of relying on the chain of trust from the 295 root domain. In such a case there is not an "additional" trusted 296 authority, rather the root trust anchor is replaced with a more 297 specific trust anchor for each of the domains in question. Detailed 298 discussion of DNSSEC security practices is out of scope for this 299 document. 301 1.3.3. Sender policy does not scale 303 Sending systems are in some cases explicitly configured to use TLS 304 for mail sent to specifically selected peer domains. This requires 305 MTAs to be configured with appropriate subject names or certificate 306 content digests to expect in the presented host certificates. 307 Because of the heavy administrative burden, such statically 308 configured SMTP secure channels are used rarely (generally only 309 between domains that make bilateral arrangements with their business 310 partners). Internet email, on the other hand, requires regularly 311 contacting new domains for which security configurations cannot be 312 established in advance. 314 The abstraction of the SMTP transport endpoint via DNS MX records, 315 often across organization boundaries, limits the use of public CA PKI 316 with SMTP to a small set of sender-configured peer domains. With 317 little opportunity to use TLS authentication, sending MTAs are rarely 318 configured with a comprehensive list of trusted CAs. SMTP services 319 that support STARTTLS often use X.509 certificates that are self- 320 signed or issued by a private CA. 322 1.3.4. Too many certificate authorities 324 Even if it were generally possible to determine a secure server name, 325 the SMTP client would still need to verify that the server's 326 certificate chain is issued by a trusted certificate authority (a 327 trust anchor). MTAs are not interactive applications where a human 328 operator can make a decision (wisely or otherwise) to selectively 329 disable TLS security policy when certificate chain verification 330 fails. With no user to "click OK", the MTAs list of public CA trust 331 anchors would need to be comprehensive in order to avoid bouncing 332 mail sites to sites employing an unknown certificate authority. 334 On the other hand, each trusted CA can issue certificates for any 335 domain. If even one of the configured CAs is compromised or operated 336 by an adversary, it can subvert TLS security for all destinations. 337 Any set of CAs is simultaneously both overly inclusive and not 338 inclusive enough. 340 2. Hardening (pre-DANE) Opportunistic TLS 342 Neither email addresses nor MX hostnames (or submission SRV records) 343 signal a requirement for either secure or cleartext transport. 344 Therefore, SMTP transport security is of necessity generally 345 opportunistic (barring manually configured exceptions). 347 This specification uses the presence of DANE TLSA records to securely 348 signal TLS support and to publish the means by which SMTP clients can 349 successfully authenticate legitimate SMTP servers. This becomes 350 "opportunistic DANE TLS" and is resistant to downgrade and MITM 351 attacks, and enables an incremental transition of the email backbone 352 to authenticated TLS delivery, with increased global protection as 353 adoption increases. 355 With opportunistic DANE TLS, traffic from SMTP clients to domains 356 that publish "usable" DANE TLSA records in accordance with this memo 357 is authenticated and encrypted. Traffic from non-compliant clients 358 or to domains that do not publish TLSA records will continue to be 359 sent in the same manner as before, via manually configured security, 360 (pre-DANE) opportunistic TLS or just cleartext SMTP. 362 2.1. DNS errors, bogus and indeterminate responses 364 An SMTP client that implements opportunistic DANE TLS per this 365 specification depends critically on the integrity of DNSSEC lookups, 366 as discussed in Section 1.3. This section lists the DNS resolver 367 requirements needed to avoid downgrade attacks when using 368 opportunistic DANE TLS. 370 A DNS lookup may signal an error or return a definitive answer. A 371 security-aware resolver must be used for this specification. 372 Security-aware resolvers will indicate the security status of a DNS 373 RRset with one of four possible values defined in Section 4.3 of 374 [RFC4035]: "secure", "insecure", "bogus" and "indeterminate". In 375 [RFC4035] the meaning of the "indeterminate" security status is: 377 An RRset for which the resolver is not able to determine whether 378 the RRset should be signed, as the resolver is not able to obtain 379 the necessary DNSSEC RRs. This can occur when the security-aware 380 resolver is not able to contact security-aware name servers for 381 the relevant zones. 383 Note, the "indeterminate" security status has a conflicting 384 definition in section 5 of [RFC4033]. 386 There is no trust anchor that would indicate that a specific 387 portion of the tree is secure. 389 SMTP clients following this specification SHOULD NOT distinguish 390 between "insecure" and "indeterminate" in the [RFC4033] sense. Both 391 "insecure" and RFC4033 "indeterminate" are handled identically: in 392 either case unvalidated data for the query domain is all that is and 393 can be available, and authentication using the data is impossible. 394 In what follows, when we say "insecure", we include also DNS results 395 for domains that lie in a portion of the DNS tree for which there is 396 no applicable trust anchor. With the DNS root zone signed, we expect 397 that validating resolvers used by Internet-facing MTAs will be 398 configured with trust anchor data for the root zone. Therefore, 399 RFC4033-style "indeterminate" domains should be rare in practice. 400 From here on, when we say "indeterminate", it is exclusively in the 401 sense of [RFC4035]. 403 As noted in section 4.3 of [RFC4035], a security-aware DNS resolver 404 MUST be able to determine whether a given non-error DNS response is 405 "secure", "insecure", "bogus" or "indeterminate". It is expected 406 that most security-aware stub resolvers will not signal an 407 "indeterminate" security status the RFC4035-sense to the application, 408 and will signal a "bogus" or error result instead. If a resolver 409 does signal an RFC4035 "indeterminate" security status, this MUST be 410 treated by the SMTP client as though a "bogus" or error result had 411 been returned. 413 An MTA making use of a non-validating security-aware stub resolver 414 MAY use the stub resolver's ability, if available, to signal DNSSEC 415 validation status based on information the stub resolver has learned 416 from an upstream validating recursive resolver. In accordance with 417 section 4.9.3 of [RFC4035]: 419 ... a security-aware stub resolver MUST NOT place any reliance on 420 signature validation allegedly performed on its behalf, except 421 when the security-aware stub resolver obtained the data in question 422 from a trusted security-aware recursive name server via a secure 423 channel. 425 To avoid much repetition in the text below, we will pause to explain 426 the handling of "bogus" or "indeterminate" DNSSEC query responses. 427 These are not necessarily the result of a malicious actor; they can, 428 for example, occur when network packets are corrupted or lost in 429 transit. Therefore, "bogus" or "indeterminate" replies are equated 430 in this memo with lookup failure. 432 There is an important non-failure condition we need to highlight in 433 addition to the obvious case of the DNS client obtaining a non-empty 434 "secure" or "insecure" RRset of the requested type. Namely, it is 435 not an error when either "secure" or "insecure" non-existence is 436 determined for the requested data. When a DNSSEC response with a 437 validation status that is either "secure" or "insecure" reports 438 either no records of the requested type or non-existence of the query 439 domain, the response is not a DNS error condition. The DNS client 440 has not been left without an answer; it has learned that records of 441 the requested type do not exist. 443 Security-aware stub resolvers will, of course, also signal DNS lookup 444 errors in other cases, for example when processing a "ServFail" 445 RCODE, which will not have an associated DNSSEC status. All lookup 446 errors are treated the same way by this specification, regardless of 447 whether they are from a "bogus" or "indeterminate" DNSSEC status or 448 from a more generic DNS error: the information that was requested can 449 not be obtained by the security-aware resolver at this time. A 450 lookup error is thus a failure to obtain the relevant RRset if it 451 exists, or to determine that no such RRset exists when it does not. 453 In contrast to a "bogus" or an "indeterminate" response, an 454 "insecure" DNSSEC response is not an error, rather it indicates that 455 the target DNS zone is either securely opted out of DNSSEC validation 456 or is not connected with the DNSSEC trust anchors being used. 457 Insecure results will leave the SMTP client with degraded channel 458 security, but do not stand in the way of message delivery. See 459 section Section 2.2 for further details. 461 When a stub resolver receives a response containing a CNAME alias, it 462 will generally restart the query at the target of the alias, and 463 should do so recursively up to some configured or implementation- 464 dependent recursion limit. If at any stage of recursive CNAME 465 expansion a query fails, the stub resolver's lookup of the original 466 requested records will result in a failure status being returned. If 467 at any stage of recursive expansion the response is "insecure", then 468 it and all subsequent results (in particular, the final result) MUST 469 be considered "insecure" regardless of whether the other responses 470 received were deemed "secure". If at any stage of recursive 471 expansion the validation status is "bogus" or "indeterminate" or 472 associated with another DNS lookup error, the resolution of the 473 requested records MUST be considered to have failed. 475 When a DNS lookup failure (error or "bogus" or "indeterminate" as 476 defined above) prevents an SMTP client from determining which SMTP 477 server or servers it should connect to, message delivery MUST be 478 delayed. This naturally includes, for example, the case when a 479 "bogus" or "indeterminate" response is encountered during MX 480 resolution. When multiple MX hostnames are obtained from a 481 successful MX lookup, but a later DNS lookup failure prevents network 482 address resolution for a given MX hostname, delivery may proceed via 483 any remaining MX hosts. 485 When a particular SMTP server is selected as the delivery 486 destination, a set of DNS lookups must be performed to discover any 487 related TLSA records. If any DNS queries used to locate TLSA records 488 fail (be it due to "bogus" or "indeterminate" records, timeouts, 489 malformed replies, ServFails, etc.), then the SMTP client MUST treat 490 that server as unreachable and MUST NOT deliver the message via that 491 server. If no servers are reachable, delivery is delayed. 493 In what follows, we will only describe what happens when all relevant 494 DNS queries succeed. If any DNS failure occurs, the SMTP client MUST 495 behave as described in this section, by skipping the problem SMTP 496 server, or the problem destination. Queries for candidate TLSA 497 records are explicitly part of "all relevant DNS queries" and SMTP 498 clients MUST NOT continue to connect to an SMTP server or destination 499 whose TLSA record lookup fails. 501 2.2. TLS discovery 503 As noted previously (in Section 1.3.1), opportunistic TLS with SMTP 504 servers that advertise TLS support via STARTTLS is subject to an MITM 505 downgrade attack. Also some SMTP servers that are not, in fact, TLS 506 capable erroneously advertise STARTTLS by default and clients need to 507 be prepared to retry cleartext delivery after STARTTLS fails. In 508 contrast, DNSSEC validated TLSA records MUST NOT be published for 509 servers that do not support TLS. Clients can safely interpret their 510 presence as a commitment by the server operator to implement TLS and 511 STARTTLS. 513 This memo defines four actions to be taken after the search for a 514 TLSA record returns secure usable results, secure unusable results, 515 insecure or no results or an error signal. The term "usable" in this 516 context is in the sense of Section 4.1 of [RFC6698]. Specifically, 517 if the DNS lookup for a TLSA record returns: 519 A secure TLSA RRset with at least one usable record: A connection to 520 the MTA MUST be made using authenticated and encrypted TLS, using 521 the techniques discussed in the rest of this document. Failure to 522 establish an authenticated TLS connection MUST result in falling 523 back to the next SMTP server or delayed delivery. 525 A Secure non-empty TLSA RRset where all the records are unusable: A 526 connection to the MTA MUST be made via TLS, but authentication is 527 not required. Failure to establish an encrypted TLS connection 528 MUST result in falling back to the next SMTP server or delayed 529 delivery. 531 An insecure TLSA RRset or DNSSEC validated proof-of-non-existent TLSA 532 records: 533 A connection to the MTA SHOULD be made using (pre-DANE) 534 opportunistic TLS, this includes using cleartext delivery when the 535 remote SMTP server does not appear to support TLS. The MTA may 536 optionally retry in cleartext when a TLS handshake fails. 538 Any lookup error: Lookup errors, including "bogus" and 539 "indeterminate", as explained in Section 2.1 MUST result in 540 falling back to the next SMTP server or delayed delivery. 542 An SMTP client MAY be configured to require DANE verified delivery 543 for some destinations. We will call such a configuration "mandatory 544 DANE TLS". With mandatory DANE TLS, delivery proceeds only when 545 "secure" TLSA records are used to establish an encrypted and 546 authenticated TLS channel with the SMTP server. 548 An operational error on the sending or receiving side that cannot be 549 corrected in a timely manner may, at times, lead to consistent 550 failure to deliver time-sensitive email. The sending MTA 551 administrator may have to choose between letting email queue until 552 the error is resolved and disabling opportunistic or mandatory DANE 553 TLS for one or more destinations. The choice to disable DANE TLS 554 security should not be made lightly. Every reasonable effort should 555 be made to determine that problems with mail delivery are the result 556 of an operational error, and not an attack. A fallback strategy may 557 be to configure explicit out-of-band TLS security settings if 558 supported by the sending MTA. 560 A note about DNAME aliases: a query for a domain name whose ancestor 561 domain is a DNAME alias returns the DNAME RR for the ancestor domain, 562 along with a CNAME that maps the query domain to the corresponding 563 sub-domain of the target domain of the DNAME alias. Therefore, 564 whenever we speak of CNAME aliases, we implicitly allow for the 565 possibility that the alias in question is the result of an ancestor 566 domain DNAME record. Consequently, no explicit support for DNAME 567 records is needed in SMTP software, it is sufficient to process the 568 resulting CNAME aliases. DNAME records only require special 569 processing in the validating stub-resolver library that checks the 570 integrity of the combined DNAME + CNAME reply. When DNSSEC 571 validation is handled by a local caching resolver, rather than the 572 MTA itself, even that part of the DNAME support logic is outside the 573 MTA. 575 When the original next-hop destination is an address literal, rather 576 than a DNS domain, DANE TLS does not apply. Delivery proceeds using 577 any relevant security policy configured by the MTA administrator. 578 Similarly, when an MX RRset incorrectly lists an network address in 579 lieu of an MX hostname, if the MTA chooses to connect to the network 580 address DANE TLSA does not apply for such a connection. 582 In the subsections that follow we explain how to locate the SMTP 583 servers and the associated TLSA records for a given next-hop 584 destination domain. We also explain which name or names are to be 585 used in identity checks of the SMTP server certificate. 587 2.2.1. MX resolution 589 In this section we consider next-hop domains that are subject to MX 590 resolution and have MX records. The TLSA records and the associated 591 base domain are derived separately for each MX hostname that is used 592 to attempt message delivery. Clearly, if DANE TLS security is to 593 apply to message delivery via any of the SMTP servers, the MX records 594 must be obtained securely via a DNSSEC validated MX lookup. 596 MX records MUST be sorted by preference; an MX hostname with a worse 597 (numerically higher) MX preference that has TLSA records MUST NOT 598 preempt an MX hostname with a better (numerically lower) preference 599 that has no TLSA records. In other words, prevention of delivery 600 loops by obeying MX preferences MUST take precedence over channel 601 security considerations. Even with two equal preference MX records, 602 an MTA is not obligated to choose the MX hostname that offers more 603 security. Domains that want secure inbound mail delivery need to 604 ensure that all their SMTP servers and MX records are configured 605 accordingly. 607 In the language of [RFC5321] Section 5.1, the original next-hop 608 domain is the "initial name". If the MX lookup of the initial name 609 results in a CNAME alias, the MTA replaces the initial name with the 610 resulting name and performs a new lookup with the new name. MTAs 611 typically support recursion in CNAME expansion, so this replacement 612 is performed repeatedly until the ultimate non-CNAME domain is found. 614 If the MX RRset (or any CNAME leading to it) is "insecure" (see 615 Section 2.1), DANE TLS does not apply, and delivery proceeds via pre- 616 DANE opportunistic TLS. Otherwise (assuming no DNS errors or "bogus" 617 /"indeterminate" responses), the MX RRset is "secure", and the SMTP 618 client MUST treat each MX hostname as a separate non-MX destination 619 for opportunistic DANE TLS as described in Section 2.2.2. When, for 620 a given MX hostname, no TLSA records are found, or only "insecure" 621 TLSA records are found, DANE TLSA is not applicable with the SMTP 622 server in question and delivery proceeds to that host as with pre- 623 DANE opportunistic TLS. To avoid downgrade attacks, any errors 624 during TLSA lookups MUST, as explained in Section 2.1, cause the SMTP 625 server in question to be treated as unreachable. 627 2.2.2. Non-MX destinations 629 This section describes the algorithm used to locate the TLSA records 630 and associated TLSA base domain for an input domain not subject to MX 631 resolution. Such domains include: 633 o Each MX hostname used in a message delivery attempt for an 634 original next-hop destination domain subject to MX resolution. 635 Note, MTAs are not obligated to support CNAME expansion of MX 636 hostnames. 638 o Any administrator configured relay hostname, not subject to MX 639 resolution. This frequently involves configuration set by the MTA 640 administrator to handle some or all mail. 642 o A next-hop destination domain subject to MX resolution that has no 643 MX records. In this case the domain's name is implicitly also the 644 hostname of its sole SMTP server. 646 Note that DNS queries with type TLSA are mishandled by load balancing 647 nameservers that serve the MX hostnames of some large email 648 providers. The DNS zones served by these nameservers are not signed 649 and contain no TLSA records, but queries for TLSA records fail, 650 rather than returning the non-existence of the requested TLSA 651 records. 653 To avoid problems delivering mail to domains whose SMTP servers are 654 served by the problem nameservers the SMTP client MUST perform any A 655 and/or AAAA queries for the destination before attempting to locate 656 the associated TLSA records. This lookup is needed in any case to 657 determine whether the destination domain is reachable and the DNSSEC 658 validation status of each stage of the chain of CNAME queries 659 required to reach the final result. 661 If no address records are found, the destination is unreachable. If 662 address records are found, but the DNSSEC validation status of the 663 first query response is "insecure" (there may be additional queries 664 if the initial response is a CNAME alias), the SMTP client SHOULD NOT 665 proceed to search for any associated TLSA records. With the problem 666 domains, TLSA queries will lead to DNS lookup errors and cause 667 messages to be consistently delayed and ultimately returned to the 668 sender. We don't expect to find any "secure" TLSA records associated 669 with a TLSA base domain that lies in an unsigned DNS zone. 670 Therefore, skipping TLSA lookups in this case will also reduce 671 latency with no detrimental impact on security. 673 If the A and/or AAAA lookup of the "initial name" yields a CNAME, we 674 replace it with the resulting name as if it were the initial name and 675 perform a lookup again using the new name. This replacement is 676 performed recursively. 678 We consider the following cases for handling a DNS response for an A 679 or AAAA DNS lookup: 681 Not found: When the DNS queries for A and/or AAAA records yield 682 neither a list of addresses nor a CNAME (or CNAME expansion is not 683 supported) the destination is unreachable. 685 Non-CNAME: The answer is not a CNAME alias. If the address RRset 686 is "secure", TLSA lookups are performed as described in 687 Section 2.2.3 with the initial name as the candidate TLSA base 688 domain. If no "secure" TLSA records are found, DANE TLS is not 689 applicable and mail delivery proceeds with pre-DANE opportunistic 690 TLS (which, being best-effort, degrades to cleartext delivery when 691 STARTTLS is not available or the TLS handshake fails). 693 Insecure CNAME: The input domain is a CNAME alias, but the ultimate 694 network address RRset is "insecure" (see Section 2.1). If the 695 initial CNAME response is also "insecure", DANE TLS does not 696 apply. Otherwise, this case is treated just like the non-CNAME 697 case above, where a search is performed for a TLSA record with the 698 original input domain as the candidate TLSA base domain. 700 Secure CNAME: The input domain is a CNAME alias, and the ultimate 701 network address RRset is "secure" (see Section 2.1). Two 702 candidate TLSA base domains are tried: the fully CNAME-expanded 703 initial name and, failing that, then the initial name itself. 705 In summary, if it is possible to securely obtain the full, CNAME- 706 expanded, DNSSEC-validated address records for the input domain, then 707 that name is the preferred TLSA base domain. Otherwise, the 708 unexpanded input-MX domain is the candidate TLSA base domain. When 709 no "secure" TLSA records are found at either the CNAME-expanded or 710 unexpanded domain, then DANE TLS does not apply for mail delivery via 711 the input domain in question. And, as always, errors, bogus or 712 indeterminate results for any query in the process MUST result in 713 delaying or abandoning delivery. 715 2.2.3. TLSA record lookup 717 Each candidate TLSA base domain (the original or fully CNAME-expanded 718 name of a non-MX destination or a particular MX hostname of an MX 719 destination) is in turn prefixed with service labels of the form 720 "_._tcp". The resulting domain name is used to issue a DNSSEC 721 query with the query type set to TLSA ([RFC6698] Section 7.1). 723 For SMTP, the destination TCP port is typically 25, but this may be 724 different with custom routes specified by the MTA administrator. The 725 SMTP client MUST use the appropriate number in the "_" prefix 726 in place of "_25". If, for example, the candidate base domain is 727 "mail.example.com", and the SMTP connection is to port 25, the TLSA 728 RRset is obtained via a DNSSEC query of the form: 730 _25._tcp.mail.example.com. IN TLSA ? 732 The query response may be a CNAME, or the actual TLSA RRset. If the 733 response is a CNAME, the SMTP client (through the use of its 734 security-aware stub resolver) restarts the TLSA query at the target 735 domain, following CNAMEs as appropriate and keeping track of whether 736 the entire chain is "secure". If any "insecure" records are 737 encountered, or the TLSA records don't exist, the next candidate TLSA 738 base is tried instead. 740 If the ultimate response is a "secure" TLSA RRset, then the candidate 741 TLSA base domain will be the actual TLSA base domain and the TLSA 742 RRset will constitute the TLSA records for the destination. If none 743 of the candidate TLSA base domains yield "secure" TLSA records then 744 delivery should proceed via pre-DANE opportunistic TLS. 746 TLSA record publishers may leverage CNAMEs to reference a single 747 authoritative TLSA RRset specifying a common certificate authority or 748 a common end entity certificate to be used with multiple TLS 749 services. Such CNAME expansion does not change the SMTP client's 750 notion of the TLSA base domain; thus, when _25._tcp.mail.example.com 751 is a CNAME, the base domain remains mail.example.com and is still the 752 name used in peer certificate name checks. 754 Note, shared end entity certificate associations expose the 755 publishing domain to substitution attacks, where an MITM attacker can 756 reroute traffic to a different server that shares the same end entity 757 certificate. Such shared end entity records should be avoided unless 758 the servers in question are interchangeable. 760 For example, given the DNSSEC validated records below: 762 example.com. IN MX 0 mail.example.com. 763 example.com. IN MX 0 mail2.example.com. 764 _25._tcp.mail.example.com. IN CNAME tlsa211._dane.example.com. 765 _25._tcp.mail2.example.com. IN CNAME tlsa211._dane.example.com. 766 tlsa211._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c14.... 768 The SMTP servers mail.example.com and mail2.example.com will be 769 expected to have certificates issued under a common trust anchor, but 770 each MX hostname's TLSA base domain remains unchanged despite the 771 above CNAME records. Each SMTP server's certificate subject name (or 772 one of the subject alternative names) is expected to match either the 773 corresponding MX hostname or else "example.com". 775 If, during TLSA resolution (including possible CNAME indirection), at 776 least one "secure" TLSA record is found (even if not usable because 777 it is unsupported by the implementation or support is 778 administratively disabled), then the corresponding host has signaled 779 its commitment to implement TLS. The SMTP client SHOULD NOT deliver 780 mail via the corresponding host unless a TLS session is negotiated 781 via STARTTLS. This is required to avoid MITM STARTTLS downgrade 782 attacks. 784 As noted previously (in Section Section 2.2.2), when no "secure" TLSA 785 records are found at the fully CNAME-expanded name, the original 786 unexpanded name MUST be tried instead. This supports customers of 787 hosting providers where the provider's zone cannot be validated with 788 DNSSEC, but the customer has shared appropriate key material with the 789 hosting provider to enable TLS via SNI. Intermediate names that 790 arise during CNAME expansion that are neither the original, nor the 791 final name, are never candidate TLSA base domains, even if "secure". 793 2.3. DANE authentication 795 This section describes which TLSA records are applicable to SMTP 796 opportunistic DANE TLS and how to apply such records to authenticate 797 the SMTP server. With opportunistic DANE TLS, both the TLS support 798 implied by the presence of DANE TLSA records and the verification 799 parameters necessary to authenticate the TLS peer are obtained 800 together, therefore authentication via this protocol is expected to 801 be less prone to connection failure caused by incompatible 802 configuration of the client and server. 804 2.3.1. TLSA certificate usages 806 The DANE TLSA specification [RFC6698] defines multiple TLSA RR types 807 via combinations of 3 numeric parameters. The numeric values of 808 these parameters were later given symbolic names in 809 [I-D.ietf-dane-registry-acronyms]. The rest of the TLSA record is 810 the "certificate association data field", which specifies the full or 811 digest value of a certificate or public key. The parameters are: 813 The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698] 814 specifies 4 values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE- 815 EE(3). There is an additional private-use value: PrivCert(255). 816 All other values are reserved for use by future specifications. 818 The selector field: Section 2.1.2 of [RFC6698] specifies 2 values: 819 Cert(0), SPKI(1). There is an additional private-use value: 820 PrivSel(255). All other values are reserved for use by future 821 specifications. 823 The matching type field: Section 2.1.3 of [RFC6698] specifies 3 824 values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional 825 private-use value: PrivMatch(255). All other values are reserved 826 for use by future specifications. 828 We may think of TLSA Certificate Usage values 0 through 3 as a 829 combination of two one-bit flags. The low bit chooses between trust 830 anchor (TA) and end entity (EE) certificates. The high bit chooses 831 between public PKI issued and domain-issued certificates. 833 The selector field specifies whether the TLSA RR matches the whole 834 certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1). The 835 subjectPublicKeyInfo is an ASN.1 DER encoding of the certificate's 836 algorithm id, any parameters and the public key data. 838 The matching type field specifies how the TLSA RR Certificate 839 Association Data field is to be compared with the certificate or 840 public key. A value of Full(0) means an exact match: the full DER 841 encoding of the certificate or public key is given in the TLSA RR. A 842 value of SHA2-256(1) means that the association data matches the 843 SHA2-256 digest of the certificate or public key, and likewise 844 SHA2-512(2) means a SHA2-512 digest is used. 846 The certificate usage element of a TLSA record plays a critical role 847 in determining how the corresponding certificate association data 848 field is used to authenticate server's certificate chain. The next 849 two subsections explain the process for certificate usages DANE-EE(3) 850 and DANE-TA(2). The third subsection briefly explains why 851 certificate usages PKIX-TA(0) and PKIX-EE(1) are not applicable with 852 opportunistic DANE TLS. 854 2.3.1.1. Certificate usage DANE-EE(3) 856 Since opportunistic DANE TLS will be used by non-interactive MTAs, 857 with no user to "press OK" when authentication fails, reliability of 858 peer authentication is paramount. 860 Authentication via certificate usage DANE-EE(3) TLSA records involves 861 simply checking that the server's leaf certificate matches the TLSA 862 record. Other than extracting the relevant certificate elements for 863 comparison, no other use is made of the certificate content. 864 Authentication via certificate usage DANE-EE(3) TLSA records involves 865 no certificate authority signature checks. It also involves no 866 server name checks, and thus does not impose any new requirements on 867 the names contained in the server certificate (SNI is not required 868 when the TLSA record matches the server's default certificate). 870 Two TLSA records MUST be published before updating a server's public 871 key, one matching the currently deployed key and the other matching 872 the new key scheduled to replace it. Once sufficient time has 873 elapsed for all DNS caches to expire the previous TLSA RRset and 874 related signature RRsets, the server may be reconfigured to use the 875 new private key and associated public key certificate. Once the 876 server is using the new key, the TLSA RR that matches the retired key 877 can be removed from DNS, leaving only the RR that matches the new 878 key. 880 TLSA records published for SMTP servers SHOULD, in most cases, be 881 "DANE-EE(3) DANE(SPKI) SHA2-256(1)" records. Since all DANE 882 implementations are required to support SHA2-256, this record works 883 for all clients and need not change across certificate renewals with 884 the same key. 886 2.3.1.2. Certificate usage DANE-TA(2) 888 Some domains may prefer to avoid the operational complexity of 889 publishing unique TLSA RRs for each TLS service. If the domain 890 employs a common issuing Certificate Authority to create certificates 891 for multiple TLS services, it may be simpler to publish the issuing 892 authority as a trust anchor (TA) for the certificate chains of all 893 relevant services. The TLSA query domain (TLSA base domain with port 894 and protocol prefix labels) for each service issued by the same TA 895 may then be set to a CNAME alias that points to a common TLSA RRset 896 that matches the TA. 898 SMTP servers that rely on certificate usage DANE-TA(2) TLSA records 899 for TLS authentication MUST include the TA certificate as part of the 900 certificate chain presented in the TLS handshake server certificate 901 message even when it is a self-signed root certificate. At this 902 time, many SMTP servers are not configured with a comprehensive list 903 of trust anchors, nor are they expected to at any point in the 904 future. Some MTAs will ignore all locally trusted certificates when 905 processing usage DANE-TA(2) TLSA records. Thus even when the TA 906 happens to be a public Certificate Authority known to the SMTP 907 client, authentication is likely to fail unless the TA is included in 908 the TLS server certificate message. 910 TLSA Publishers should publish either "DANE-TA(2) SPKI(1) Full(0)" or 911 "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA parameters. As with leaf 912 certificate rollover discussed in Section 2.3.1.1, two such TLSA RRs 913 need to be published to facilitate TA certificate rollover. 915 2.3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) 917 SMTP servers SHOULD NOT publish TLSA RRs with certificate usage 918 "PKIX-TA(0)" or "PKIX-EE(1)". SMTP clients cannot be expected to be 919 configured with a suitably complete set of trusted public CAs. Even 920 with a full set of public CAs, SMTP clients cannot (without relying 921 on DNSSEC for secure MX records and DANE for STARTTLS support 922 signalling) perform [RFC6125] server identity verification or prevent 923 STARTTLS downgrade attacks. The use of trusted public CAs offers no 924 added security since an attacker capable of compromising DNSSEC is 925 free to replace any PKIX-TA(0) or PKIX-EE(1) TLSA records with 926 records bearing any convenient non-PKIX certificate usage. 928 SMTP client treatment of TLSA RRs with certificate usages "PKIX- 929 TA(0)" or "PKIX-EE(1)" is undefined. For example, clients MAY (will 930 likely) treat such TLSA records as unusable. 932 2.3.2. Certificate matching 934 When at least one usable "secure" TLSA record is found, the SMTP 935 client SHOULD use TLSA records to authenticate the SMTP server. 936 Messages SHOULD NOT be delivered via the SMTP server if 937 authentication fails, otherwise the SMTP client is vulnerable to MITM 938 attacks. 940 To match a server via a TLSA record with certificate usage DANE- 941 TA(2), the client MUST perform name checks to ensure that it has 942 reached the correct server. In all cases the SMTP client MUST accept 943 the TLSA base domain as a valid DNS name in the server certificate. 945 TLSA records for MX hostnames: If the TLSA base domain was obtained 946 indirectly via an MX lookup (including any CNAME-expanded name of 947 an MX hostname), then the original next-hop domain used in the MX 948 lookup MUST be accepted in the peer certificate. The CNAME- 949 expanded original next-hop domain MUST also be accepted if 950 different from the initial query name. 952 TLSA records for Non-MX hostnames: If MX records were not used 953 (e.g., if none exist) and the TLSA base domain is the CNAME- 954 expanded original next-hop domain, then the original next-hop 955 domain MUST also be accepted. 957 Accepting certificates with the original next-hop domain in addition 958 to the MX hostname allows a domain with multiple MX hostnames to 959 field a single certificate bearing a single domain name (i.e., the 960 email domain) across all the SMTP servers. This also aids inter- 961 operability with pre-DANE SMTP clients that are configured to look 962 for the email domain name in server certificates. For example, with 963 "secure" DNS records as below: 965 exchange.example.org. IN CNAME mail.example.org. 966 mail.example.org. IN CNAME example.com. 967 example.com. IN MX 10 mx10.example.com. 968 example.com. IN MX 15 mx15.example.com. 969 example.com. IN MX 20 mx20.example.com. 970 ; 971 mx10.example.com. IN A 192.0.2.10 972 _25._tcp.mx10.example.com. IN TLSA 2 0 1 ... 973 ; 974 mx15.example.com. IN CNAME mxbackup.example.com. 975 mxbackup.example.com. IN A 192.0.2.15 976 ; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN) 977 _25._tcp.mx15.example.com. IN TLSA 2 0 1 ... 978 ; 979 mx20.example.com. IN CNAME mxbackup.example.net. 980 mxbackup.example.net. IN A 198.51.100.20 981 _25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ... 983 Certificate name checks for delivery of mail to exchange.example.org 984 via any of the associated SMTP servers MUST accept at least the names 985 "exchange.example.org" and "example.com", which are respectively the 986 original and fully expanded next-hop domain. When the SMTP server is 987 mx10.example.com, name checks MUST accept the TLSA base domain 988 "mx10.example.com". If, despite the fact that MX hostnames are 989 required to not be aliases, the MTA supports delivery via 990 "mx15.example.com" or "mx20.example.com" then name checks MUST accept 991 the respective TLSA base domains "mx15.example.com" and 992 "mxbackup.example.net". 994 The SMTP client MUST NOT perform certificate usage name checks with 995 certificate usage DANE-EE(3), since with usage DANE-EE(3) the server 996 is authenticated directly by matching the TLSA RRset to its 997 certificate or public key without resorting to any issuing authority. 998 The certificate content is ignored except to match the certificate or 999 public key (ASN.1 DER encoding or its digest) with the TLSA RRset. 1001 To ensure that the server sends the right certificate chain, the SMTP 1002 client MUST send the TLS SNI extension containing the TLSA base 1003 domain. This precludes the use of the backward compatible SSL 2.0 1004 compatible SSL HELLO by the SMTP client. The minimum SSL/TLS client 1005 HELLO version for SMTP clients performing DANE authentication is SSL 1006 3.0, but a client that offers SSL 3.0 MUST also offer at least TLS 1007 1.0 and MUST include the SNI extension. Servers that don't make use 1008 of SNI MAY negotiate SSL 3.0 if offered by the client. 1010 Each SMTP server MUST present a certificate chain (see [RFC5246] 1011 Section 7.4.2) that matches at least one of the TLSA records. The 1012 server MAY rely on SNI to determine which certificate chain to 1013 present to the client. Clients that don't send SNI information may 1014 not see the expected certificate chain. 1016 If the server's TLSA RRset includes records with a matching type 1017 indicating a digest record (i.e., a value other than Full(0)), a TLSA 1018 record with a SHA2-256(1) matching type SHOULD be provided along with 1019 any other digest published, since some SMTP clients may support only 1020 SHA2-256(1). 1022 If the server's TLSA records match the server's default certificate 1023 chain, the server need not support SNI. In either case, the server 1024 need not include the SNI extension in its TLS HELLO as simply 1025 returning a matching certificate chain is sufficient. Servers MUST 1026 NOT enforce the use of SNI by clients, as the client may be using 1027 unauthenticated opportunistic TLS and may not expect any particular 1028 certificate from the server. If the client sends no SNI extension, 1029 or sends an SNI extension for an unsupported domain, the server MUST 1030 simply send its default certificate chain. The reason for not 1031 enforcing strict matching of the requested SNI hostname is that DANE 1032 TLS clients are typically willing to accept multiple server names, 1033 but can only send one name in the SNI extension. The server's 1034 default certificate may match a different name acceptable to the 1035 client, e.g., the original next-hop domain. 1037 An SMTP client employing pre-DANE opportunistic TLS MAY include some 1038 anonymous TLS cipher suites in its TLS HELLO in addition to at least 1039 one non-anonymous cipher suite (since servers often do support any of 1040 the anonymous ones). Therefore, an SMTP server MUST either select 1041 some suitable non-anonymous cipher suite offered by the client, or if 1042 it selects an anonymous cipher suite, it MUST NOT fail to complete 1043 the handshake merely because an anonymous cipher suite was chosen. 1045 Note that while SMTP server operators are under no obligation to 1046 enable anonymous cipher suites, no security is gained by sending 1047 certificates to clients that will ignore them. Indeed support for 1048 anonymous cipher suites in the server makes audit trails more 1049 informative. Log entries that record connections that employed an 1050 anonymous cipher suite record the fact that the clients did not care 1051 to authenticate the server. 1053 2.3.3. Digest algorithm agility 1055 While [RFC6698] specifies multiple digest algorithms, it does not 1056 specify a protocol by which the SMTP client and TLSA record publisher 1057 can agree on the strongest shared algorithm. Such a protocol would 1058 allow the client and server to avoid exposure to any deprecated 1059 weaker algorithms that are published for compatibilty with less 1060 capable clients, but should be ignored when possible. We specify 1061 such a protocol below. 1063 Suppose that a DANE TLS client authenticating a TLS server considers 1064 digest algorithm BETTER stronger than digest algorithm WORSE. 1065 Suppose further that a server's TLSA RRset contains some records with 1066 BETTER as the digest algorithm. Finally, suppose that for every raw 1067 public key or certificate object that is included in the server's 1068 TLSA RRset in digest form, whenever that object appears with 1069 algorithm WORSE with some usage and selector it also appears with 1070 algorithm BETTER with the same usage and selector. In that case our 1071 client can safely ignore TLSA records with the weaker algorithm 1072 WORSE, because it suffices to check the records with the stronger 1073 algorithm BETTER. 1075 Server operators MUST ensure that for any given usage and selector, 1076 each object (certificate or public key), for which a digest 1077 association exists in the TLSA RRset, is published with the SAME SET 1078 of digest algorithms as all other objects that published with that 1079 usage and selector. In other words, for each usage and selector, the 1080 records with non-zero matching types will correspond to on a cross- 1081 product of a set of underlying objects and a fixed set of digest 1082 algorithms that apply uniformly to all the objects. 1084 To achieve digest algorithm agility, all published TLSA RRsets for 1085 use with opportunistic DANE TLS for SMTP MUST conform to the above 1086 requirements. Then, for each combination of usage and selector, SMTP 1087 clients can simply ignore all digest records except those that employ 1088 the strongest digest algorithm. The ordering of digest algorithms by 1089 strength is not specified in advance, it is entirely up to the SMTP 1090 client. SMTP client implementations SHOULD make the digest algorithm 1091 preference order configurable. Only the future will tell which 1092 algorithms might be weakened by new attacks and when. 1094 Note, TLSA records with a matching type of Full(0), that publish the 1095 full value of a certificate or public key object, play no role in 1096 digest algorithm agility. They neither trump the processing of 1097 records that employ digests, nor are they ignored in the presence of 1098 any records with a digest (i.e. non-zero) matching type. 1100 SMTP clients SHOULD use digest algorithm agility when processing the 1101 DANE TLSA records of an SMTP server. Algorithm agility is to be 1102 applied after first discarding any unusable or malformed records 1103 (unsupported digest algorithm, or incorrect digest length). Thus, 1104 for each usage and selector, the client SHOULD process only any 1105 usable records with a matching type of Full(0) and the usable records 1106 whose digest algorithm is believed to be the strongest among usable 1107 records with the given usage and selector. 1109 The main impact of this requirement is on key rotation, when the TLSA 1110 RRset is pre-populated with digests of new certificates or public 1111 keys, before these replace or augment their predecessors. Were the 1112 newly introduced RRs to include previously unused digest algorithms, 1113 clients that employ this protocol could potentially ignore all the 1114 digests corresponding to the current keys or certificates, causing 1115 connectivity issues until the new keys or certificates are deployed. 1116 Similarly, publishing new records with fewer digests could cause 1117 problems for clients using cached TLSA RRsets that list both the old 1118 and new objects once the new keys are deployed. 1120 To avoid problems, server operators SHOULD apply the following 1121 strategy: 1123 o When changing the set of objects published via the TLSA RRset 1124 (e.g. during key rotation), DO NOT change the set of digest 1125 algorithms used; change just the list of objects. 1127 o When changing the set of digest algorithms, change only the set of 1128 algorithms, and generate a new RRset in which all the current 1129 objects are re-published with the new set of digest algorithms. 1131 After either of these two changes are made, the new TLSA RRset should 1132 be left in place long enough that the older TLSA RRset can be flushed 1133 from caches before making another change. 1135 3. Mandatory TLS Security 1137 An MTA implementing this protocol may require a stronger security 1138 assurance when sending email to selected destinations. The sending 1139 organization may need to send sensitive email and/or may have 1140 regulatory obligations to protect its content. This protocol is not 1141 in conflict with such a requirement, and in fact can often simplify 1142 authenticated delivery to such destinations. 1144 Specifically, with domains that publish DANE TLSA records for their 1145 MX hostnames, a sending MTA can be configured to use the receiving 1146 domains's DANE TLSA records to authenticate the corresponding SMTP 1147 server. Authentication via DANE TLSA records is easier to manage, as 1148 changes in the receiver's expected certificate properties are made on 1149 the receiver end and don't require manually communicated 1150 configuration changes. With mandatory DANE TLS, when no usable TLSA 1151 records are found, message delivery is delayed. Thus, mail is only 1152 sent when an authenticated TLS channel is established to the remote 1153 SMTP server. 1155 Administrators of mail servers that employ mandatory DANE TLS, need 1156 to carefully monitor their mail logs and queues. If a partner domain 1157 unwittingly misconfigures their TLSA records, disables DNSSEC, or 1158 misconfigures SMTP server certificate chains, mail will be delayed. 1160 4. Operational Considerations 1162 4.1. Client Operational Considerations 1164 SMTP clients may deploy opportunistic DANE TLS incrementally by 1165 enabling it only for selected sites, or may occasionally need to 1166 disable opportunistic DANE TLS for peers that fail to interoperate 1167 due to misconfiguration or software defects on either end. Unless 1168 local policy specifies that opportunistic DANE TLS is not to be used 1169 for a particular destination, client MUST NOT deliver mail via a 1170 server whose certificate chain fails to match at least one TLSA 1171 record when usable TLSA records are available. 1173 4.2. Publisher Operational Considerations 1175 SMTP servers that publish certificate usage DANE-TA(2) associations 1176 MUST include the TA certificate in their TLS server certificate 1177 chain, even when that TA certificate is a self-signed root 1178 certificate. 1180 TLSA Publishers must follow the digest agility guidelines in 1181 Section 2.3.3 and must make sure that all objects published in digest 1182 form for a particular usage and selector are published with the same 1183 set of digest algorithms. 1185 TLSA Publishers should follow the TLSA publication size guidance 1186 found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines". 1188 5. Security Considerations 1190 This protocol leverages DANE TLSA records to implement MITM resistant 1191 opportunistic channel security for SMTP. For destination domains 1192 that sign their MX records and publish signed TLSA records for their 1193 MX hostnames, this protocol allows sending MTAs to securely discover 1194 both the availability of TLS and how to authenticate the destination. 1196 This protocol does not aim to secure all SMTP traffic, as that is not 1197 practical until DNSSEC and DANE adoption are universal. The 1198 incremental deployment provided by following this specification is a 1199 best possible path for securing SMTP. This protocol coexists and 1200 interoperates with the existing insecure Internet email backbone. 1202 The protocol does not preclude existing non-opportunistic SMTP TLS 1203 security arrangements, which can continue to be used as before via 1204 manual configuration with negotiated out-of-band key and TLS 1205 configuration exchanges. 1207 Opportunistic SMTP TLS depends critically on DNSSEC for downgrade 1208 resistance and secure resolution of the destination name. If DNSSEC 1209 is compromised, it is not possible to fall back on the public CA PKI 1210 to prevent MITM attacks. A successful breach of DNSSEC enables the 1211 attacker to publish TLSA usage 3 certificate associations, and 1212 thereby bypass any security benefit the legitimate domain owner might 1213 hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of 1214 public CA PKI support in existing MTA deployments, avoiding 1215 certificate usages 0 and 1 simplifies implementation and deployment 1216 with no adverse security consequences. 1218 Implementations must strictly follow the portions of this 1219 specification that indicate when it is appropriate to initiate a non- 1220 authenticated connection or cleartext connection to a SMTP server. 1221 Specifically, in order to prevent downgrade attacks on this protocol, 1222 implementation must not initiate a connection when this specification 1223 indicates a particular SMTP server must be considered unreachable. 1225 6. IANA considerations 1227 This specification requires no support from IANA. 1229 7. Acknowledgements 1231 The authors would like to extend great thanks to Tony Finch, who 1232 started the original version of a DANE SMTP document. His work is 1233 greatly appreciated and has been incorporated into this document. 1234 The authors would like to additionally thank Phil Pennock for his 1235 comments and advice on this document. 1237 Acknowledgments from Viktor: Thanks to Paul Hoffman who motivated me 1238 to begin work on this memo and provided feedback on early drafts. 1239 Thanks to Patrick Koetter, Perry Metzger and Nico Williams for 1240 valuable review comments. Thanks also to Wietse Venema who created 1241 Postfix, and whose advice and feedback were essential to the 1242 development of the Postfix DANE implementation. 1244 8. References 1246 8.1. Normative References 1248 [I-D.ietf-dane-ops] 1249 Dukhovni, V. and W. Hardaker, "DANE TLSA implementation 1250 and operational guidance", draft-ietf-dane-ops-00 (work in 1251 progress), October 2013. 1253 [RFC1035] Mockapetris, P., "Domain names - implementation and 1254 specification", STD 13, RFC 1035, November 1987. 1256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1257 Requirement Levels", BCP 14, RFC 2119, March 1997. 1259 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1260 Transport Layer Security", RFC 3207, February 2002. 1262 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1263 Rose, "DNS Security Introduction and Requirements", RFC 1264 4033, March 2005. 1266 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1267 Rose, "Resource Records for the DNS Security Extensions", 1268 RFC 4034, March 2005. 1270 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1271 Rose, "Protocol Modifications for the DNS Security 1272 Extensions", RFC 4035, March 2005. 1274 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1275 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1277 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1278 Housley, R., and W. Polk, "Internet X.509 Public Key 1279 Infrastructure Certificate and Certificate Revocation List 1280 (CRL) Profile", RFC 5280, May 2008. 1282 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1283 October 2008. 1285 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1286 Extension Definitions", RFC 6066, January 2011. 1288 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1289 Verification of Domain-Based Application Service Identity 1290 within Internet Public Key Infrastructure Using X.509 1291 (PKIX) Certificates in the Context of Transport Layer 1292 Security (TLS)", RFC 6125, March 2011. 1294 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 1295 Submission/Access Services", RFC 6186, March 2011. 1297 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1298 STD 72, RFC 6409, November 2011. 1300 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1301 DNS", RFC 6672, June 2012. 1303 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1304 of Named Entities (DANE) Transport Layer Security (TLS) 1305 Protocol: TLSA", RFC 6698, August 2012. 1307 8.2. Informative References 1309 [I-D.ietf-dane-registry-acronyms] 1310 Gudmundsson, O., "Adding acronyms to simplify DANE 1311 conversations", draft-ietf-dane-registry-acronyms-01 (work 1312 in progress), October 2013. 1314 [I-D.ietf-dane-smtp] 1315 Finch, T., "Secure SMTP using DNS-Based Authentication of 1316 Named Entities (DANE) TLSA records.", draft-ietf-dane- 1317 smtp-01 (work in progress), February 2013. 1319 [I-D.ietf-dane-srv] 1320 Finch, T., "Using DNS-Based Authentication of Named 1321 Entities (DANE) TLSA records with SRV and MX records.", 1322 draft-ietf-dane-srv-02 (work in progress), February 2013. 1324 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 1325 2009. 1327 [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based 1328 Authentication of Named Entities (DANE)", RFC 6394, 1329 October 2011. 1331 [RFC6895] Eastlake, D., "Domain Name System (DNS) IANA 1332 Considerations", BCP 42, RFC 6895, April 2013. 1334 Authors' Addresses 1336 Viktor Dukhovni 1337 Unaffiliated 1339 Email: ietf-dane@dukhovni.org 1341 Wes Hardaker 1342 Parsons 1343 P.O. Box 382 1344 Davis, CA 95617 1345 US 1347 Email: ietf@hardakers.net