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