idnits 2.17.1 draft-ietf-dane-smtp-with-dane-00.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 seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When at least one usable "secure" TLSA record is found, the SMTP client SHOULD use TLSA records to authenticate the next-hop host, mail SHOULD not be delivered via this next-hop host if authentication fails, otherwise the SMTP client is vulnerable to TLS man in the middle attacks. -- The document date (October 08, 2013) is 3850 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3546' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'RFC4346' is defined on line 749, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-dukhovni-dane-ops-00 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3546 (Obsoleted by RFC 4366) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: Experimental W. Hardaker 5 Expires: April 11, 2014 Parsons 6 October 08, 2013 8 SMTP security via opportunistic DANE TLS 9 draft-ietf-dane-smtp-with-dane-00 11 Abstract 13 This memo describes a protocol for opportunistic TLS security based 14 on the DANE TLSA DNS record. The protocol is downgrade resistant 15 when the SMTP client supports DANE TLSA and the server domain 16 publishes TLSA records for its MX hosts. This enables an incremental 17 transition of the Internet email backbone (MTA to MTA SMTP traffic) 18 to TLS encrypted and authenticated delivery. 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 April 11, 2014. 37 Copyright Notice 39 Copyright (c) 2013 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. Background . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.2. SMTP Channel Security . . . . . . . . . . . . . . . . . . 3 57 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Hardening Opportunistic TLS . . . . . . . . . . . . . . . . . 5 59 2.1. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1.1. MX resolution . . . . . . . . . . . . . . . . . . . . 6 61 2.1.2. TLSA record lookup . . . . . . . . . . . . . . . . . 7 62 2.2. DANE authentication . . . . . . . . . . . . . . . . . . . 8 63 2.2.1. TLSA certificate usages . . . . . . . . . . . . . . . 8 64 2.2.2. Certificate matching . . . . . . . . . . . . . . . . 11 65 3. Opportunistic TLS for Submission . . . . . . . . . . . . . . 13 66 4. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 14 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 7. Normative References . . . . . . . . . . . . . . . . . . . . 16 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 72 1. Introduction 74 Lacking verified DNS and "Server Name Indication" (SNI), there has 75 historically been no scalable way for SMTP server operators to 76 provide certificates which match a trustable identifier. It's only 77 with the deployment of DNSSEC and DANE that authenticated TLS for 78 SMTP to MX becomes possible between parties that have not already 79 established an identity convention out-of-band. 81 1.1. Background 83 The Domain Name System Security Extensions (DNSSEC) add data origin 84 authentication and data integrity to the Domain Name System. DNSSEC 85 is defined in [RFC4033], [RFC4034] and [RFC4035]. 87 As described in the introduction of [RFC6698], TLS authentication via 88 the existing public Certificate Authority (CA) Public Key 89 Infrastructure (PKI) suffers from an over-abundance of trusted 90 certificate authorities capable of issuing certificates for any 91 domain of their choice. DNS-Based Authentication of Named Entities 92 (DANE) leverages the DNSSEC infrastructure to publish trusted keys 93 and certificates for use with TLS via a new TLSA record type. With 94 DANE, the public CA PKI can be augmented or replaced by DNSSEC 95 validated TLSA records. 97 The Transport Layer Security (TLS [RFC5246]) protocol enables secure 98 TCP communication. In the context of this memo, channel security is 99 assumed to be provided by TLS. Used without authentication, TLS 100 protects only against eavesdropping. With authentication, TLS also 101 protects against man-in-the-middle (MITM) attacks. 103 1.2. SMTP Channel Security 105 The Simple Mail Transport Protocol (SMTP) ([RFC5321]) is multi-hop 106 store & forward, while TLS security is hop-by-hop. The number of 107 hops from the sender's Mail User Agent to the recipient mailbox is 108 rarely less than 2 and is often higher. Some hops may be TLS 109 protected, some may not. The same SMTP TCP endpoint can serve both 110 TLS and non-TLS clients, with TLS negotiated via the SMTP STARTTLS 111 command ([RFC3207]). DNS MX records abstract the next hop transport 112 end-point. SMTP addresses are not transport addresses and are 113 security agnostic. Unlike HTTP, there is no URI scheme for email 114 addresses to designate whether the SMTP server should be contacted 115 with or without security. 117 A Mail Transport Agent (MTA) may need to forward a message to a 118 particular email recipient . To deliver the 119 message, the MTA needs to retrieve the MX hosts of example.com from 120 DNS, and then deliver the message to one of them. Absent DNSSEC, the 121 MX lookup is vulnerable to man-in-the-middle and cache poisoning 122 attacks. As a result, secure verification of MX host certificates is 123 not possible without DNSSEC, as an active attacker can forge DNS 124 replies with fake MX records, and can direct traffic to a server of 125 their choice. A man-in-the-middle can also suppress the MX host's 126 STARTTLS EHLO response, convincing the client that communication over 127 TLS is unavailable. 129 One might try to harden STARTTLS with SMTP against DNS attacks by 130 requiring each MX host to posess an X.509 certificate for the 131 recipient domain that is obtained from the message envelope and is 132 not subject to DNS reply forgery. Unfortunately, this is 133 impractical, as email for many domains is handled by third parties, 134 which are not in a position to obtain certificates for all the 135 domains they serve. Deployment of SNI (see [RFC6066] Section 3.1) is 136 no panacea, since the key management is operationally challenging at 137 large scale unless the email service provider is also the domain's 138 registrar and its certificate issuer; this is rarely the case for 139 email. 141 Since the recipient domain name cannot be used as the SMTP server 142 authentication identity, nor can the MX hostname without DNSSEC, 143 large scale deployment of authenticated TLS for SMTP requires secure 144 DNS. At this time, DNSSEC is not yet widely deployed and MTA to MTA 145 traffic between Internet connected organizations rarely uses TLS at 146 all, or simply uses TLS opportunistically without authentication and 147 protects against only passive eavesdropping attacks. 149 The only exceptions are cases in which the sending MTA is statically 150 configured to use TLS for mail sent to specific selected peer domains 151 and is configured with appropriate names (or content digests) to 152 expect in the presented MX host certificates of those domains. Such 153 statically configured SMTP secure channels are also used rarely, and 154 only between domains that make bilateral arrangements with their 155 business partners. Internet email, on the other hand, requires 156 contacting many new domains for which security configurations can not 157 be established in advance. 159 Note, the above does not apply to mail submission [RFC6409], where a 160 mail user agent is pre-configured to send all email to a fixed Mail 161 Submission Agent (MSA). Submission servers usually offer TLS and the 162 Mail User Agent (MUA) can be statically configured to require TLS 163 with its chosen MSA. The situation changes when submission servers 164 are configured dynamically via SRV records (see [RFC6186] Section 6, 165 although this is not yet widely deployed). Applications to 166 submission via SRV records will be discussed later in this memo. 168 With little opportunity to use TLS authentication, MX hosts that 169 support STARTTLS often use self-signed or private-CA issued X.509 170 certificates. Sending systems are rarely configured with a 171 comprehensive list of trusted CAs and do not check CRLs or implement 172 OCSP. In essence, they don't and can't reply on the existing public 173 CA PKI. This is not simply a result of complacency on the part SMTP 174 server administrators and MTA developers. Nor is it just a result of 175 the relative maturity of the SMTP infrastructure when TLS was 176 introduced. Rather, the abstraction of the SMTP transport endpoint 177 via DNS MX records, often across organization boundaries, limits the 178 use of public CA PKI with SMTP to a small set of sender-configured 179 peer domains. 181 This does not mean, however, that the Internet email backbone cannot 182 benefit from TLS. The fact that transport security is not explicitly 183 specified in either the recipient address or the MX record means that 184 new protocols can furnish out-of-band information to SMTP, making it 185 possible to simultaneously discover both which peer domains support 186 secure delivery via TLS and how to verify the authenticity of the 187 associated MX hosts. The first such mechanism that can work an 188 Internet scale is DANE TLSA, but use of DANE TLSA with MTA to MTA 189 SMTP must be cognizant of the lack of any realistic role for the 190 existing public CA PKI. 192 1.3. Terminology 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in [RFC2119]. 198 2. Hardening Opportunistic TLS 200 This section describes opportunistic SMTP over TLS security, where 201 traffic from DANE TLSA aware SMTP clients to domains that implement 202 DANE TLSA records in accordance with this memo is secure. Traffic to 203 other domains continues to be sent in the same manner as before 204 (either manually configured for security or unencrypted and 205 unauthenticated). It is hoped that, over time, more domains will 206 implement DNSSEC and publish DANE TLSA records for their MX hosts. 207 This will enable an incremental transition of the email backbone to 208 authenticated TLS delivery. 210 Since email addresses and MX hostnames (or submission SRV records) 211 neither signal nor deny support for TLS by the receiving domain, it 212 is possible to use DANE TLSA records to securely signal TLS support 213 and simultaneously to provide the means by which SMTP clients can 214 successfully authenticate legitimate SMTP servers. 216 2.1. TLS discovery 218 As noted previously (Section 1.2), opportunistic TLS with SMTP 219 servers that advertise TLS support via STARTTLS is subject to a man 220 in the middle downgrade attack. Some SMTP servers erroneously 221 advertise STARTTLS in default configurations that are not in fact TLS 222 capable, and clients need to be prepared to retry plaintext delivery 223 after STARTTLS fails. A downgrade resistant mechanism for a server 224 to advertise TLS support based on DANE TLSA records is specified 225 below. DNSSEC validated TLSA records are unlikely to be accidentally 226 published for servers that do not in fact support TLS, and thus 227 clients can safely interpret their presence as a commitment by the 228 server operator to implement STARTTLS. 230 SMTP is a store & forward protocol. An MTA that is not the final 231 destination for a message recipient forwards the message one hop 232 closer to the recipient's mailbox. To do so, it must determine the 233 appropriate next-hop destination. 235 Typically, the next-hop destination defaults to the domain part of 236 the recipient address, which is then subject to MX resolution. The 237 next-hop destination may also be configured by the MTA administrator 238 to be a next-hop destination host (explicitly exempt from MX 239 resolution), or a next-hop destination domain (subject to MX 240 resolution) which takes the place of the domain part of the recipient 241 address. In the language of [RFC5321] Section 5.1, we'll refer to 242 this next-hop destination host or domain as "the initial name". 244 2.1.1. MX resolution 246 If the initial name is a next-hop domain subject to MX resolution, a 247 DNSSEC validated "MX" lookup is performed, to obtain the list of 248 associated MX hosts. If no MX records are found, or if the initial 249 name is a next-hop host not subject to MX resolution, it is resolved 250 to one or more network addresses, by performing DNSSEC validated "A" 251 and/or "AAAA" lookups. 253 Following [RFC5321] Section 5.1, if the "A", "AAAA" or "MX" lookup of 254 the initial name yields a CNAME, we replace it with the resulting 255 name as if it were the initial name and try the same lookup again 256 with the new name. MTAs typically support limited recursion in CNAME 257 expansion so this replacement is performed recursively. If 258 initially, or at any stage of recursion, the response is "bogus", MX 259 resolution fails with a temporary error. Mail delivery SHOULD either 260 be deferred or attempted via any alternative delivery channel 261 configured by the MTA administrator (which may also employ 262 opportunistic DANE TLS). 264 With a next-hop destination domain subject to MX resolution which has 265 MX records, if at least one lookup in the (possibly empty) chain of 266 CNAMEs leading to the MX RRset is "insecure", opportunistic DANE TLS 267 is not applicable, and mail delivery may proceed with pre-DANE 268 opportunistic TLS (subject to its various MITM attacks). 270 With a next-hop destination host not subject to MX resolution or a 271 domain with no MX records, if at least one lookup in the (possibly 272 empty) chain of CNAMEs leading to the A or AAAA RRset is "insecure", 273 the TLSA base domain is the initial next-hop name, and opportunistic 274 DANE TLS is applicable only when a "secure" TLSA RRset is found at 275 that base domain. 277 Otherwise, if at each and every stage of CNAME expansion the DNS 278 response is "secure", and either the initial name is a next-hop host 279 name not subject to MX resolution or no MX records are found, the 280 resulting final name becomes the next-hop destination and is the base 281 domain for TLSA record lookup. In summary, the TLSA base domain is 282 the fully CNAME expanded name that is "secure" or else is the initial 283 name. 285 Finally, if at each and every stage the DNS response is "secure", and 286 and one or more MX records are found, the MX records MUST be sorted 287 by preference. A better (numerically lower) MX preference for a host 288 that does not support TLS MUST NOT be preempted by a worse 289 (numerically higher) MX preference for a host that does support TLS. 290 In other words, avoiding delivery loops trumps any preference for 291 channel security. In each delivery attempt via a candidate MX host, 292 the MX host MUST be treated as though it were the initial next-hop 293 destination host (which is, of course, not subject to further MX 294 resolution). The associated TLSA base domain is equal to the CNAME 295 resolved MX exchange name if CNAME expansion of MX exchange names is 296 supported and all CNAMEs encountered are "secure". Otherwise, the 297 unexpanded name of the MX exchange is the TLSA base domain. 299 CNAMEs are not legal in the exchange field of MX records, thus MTAs 300 MAY skip over MX records in which the MX exchange is a CNAME. There 301 is some additional risk, in this case, that the MTA may fail to 302 notice that it is one of the MX hosts for the destination and that it 303 must skip MX records with equal or worse (numerically higher 304 precedence). If an MTA does allow CNAMEs to be used in MX records it 305 SHOULD process them recursively as described above to determine 306 whether opportunistic DANE TLS is applicable and if so the associated 307 TLSA RRset base domain. 309 2.1.2. TLSA record lookup 311 When all the DNSSEC lookups, "CNAME", "MX", "A" or "AAAA", used to 312 obtain a given TLSA base domain (one for each candidate MX host if 313 multiple DNSSEC validated MX hosts were found) are "secure", and the 314 SMTP client is configured for opportunistic DANE TLS, it SHOULD 315 locate the TLSA RRset corresponding to this base domain. If, for 316 example, the base domain is "mail.example.com", the TLSA RRset is 317 obtained via a DNSSEC query of the form: 319 _25._tcp.mail.example.com. IN TLSA ? 321 Typically, the destination TCP port is 25, but this may be different 322 with custom routes specified by the MTA administrator or when an MUA 323 connects to a submission server on port 587. The SMTP client MUST 324 use the appropriate "_" prefix in place of "_25" when the port 325 number is not equal to 25. The query response may be a CNAME (or a 326 DNAME + CNAME combination), or the TLSA RRset. DNAME processing with 327 DNSSEC can be done using standard DNAME resolution techniques and 328 will not be discussed in detail here. The SMTP client MUST check the 329 security status of the response. 331 If the response is "bogus", delivery via the host in question SHOULD 332 NOT proceed, otherwise the SMTP client is vulnerable to man in the 333 middle STARTTLS downgrade attacks. If the response is "insecure", 334 opportunistic DANE TLS is not applicable for the host in question, 335 and the SMTP client SHOULD proceed with ordinary opportunistic TLS. 337 If the response is "secure" and the record is a CNAME or DNAME, the 338 SMTP client restarts the TLSA query at the target domain, following 339 CNAMEs as appropriate (such CNAME expansion does not change the SMTP 340 client's notion of the TLSA base domain). 342 If, after possible CNAME indirection, the response is "secure" and at 343 least one TLSA record is found (even if not usable because it is 344 unsupported by the implementation or administratively disabled) the 345 next-hop host has committed to TLS support. The SMTP client SHOULD 346 NOT deliver mail via such a next-hop host unless a TLS session is 347 negotiated via STARTTLS. This avoids man in the middle STARTTLS 348 downgrade attacks. 350 When no TLSA records are found at a CNAME-expanded initial name 351 (insecure response or no records), the unexpanded initial name MUST 352 be tried instead. This supports clients of hosting providers where 353 the provider zone is not DNSSEC validated, but the client has shared 354 appropriate key material with the hosting provider to enable TLS via 355 SNI. 357 When usable TLSA records are available, a client SHOULD NOT deliver 358 mail via a server that fails to match at least one TLSA record. This 359 is not a "must" because clients may incrementally deploy 360 opportunistic DANE TLS only for selected peer domains. At times, 361 clients may need to disable opportunistic DANE TLS for peers that 362 fail to interoperate due to misconfiguration or software defects on 363 either end. For opportunistic DANE TLS to be robust (resistant to 364 failures), servers MUST live up to the promises stated by the 365 existence of the TLSA record, but it is not always possible to compel 366 clients to use a security policy chosen by the server. Given a 367 robust security protocol, clients will hopefully, over time, 368 willingly choose to adopt it. 370 SMTP clients employing opportunistic DANE TLS and TLSA record 371 publishers for SMTP servers need to follow the guidance outlined in 372 [I-D.dukhovni-dane-ops]'s "Certificate Name Check Conventions", 373 "Service Provider and TLSA Publisher Synchronization" and "TLSA Base 374 Domain and CNAMEs" sections. 376 2.2. DANE authentication 378 2.2.1. TLSA certificate usages 380 As noted in the introduction, the existing public CA PKI is not 381 viable for the Internet email backbone. TLSA records for MX hosts or 382 submission servers that are to be found via SRV records SHOULD NOT 383 include certificate usage "0" or "1", as in both cases SMTP clients 384 cannot be expected to perform [RFC5280] PKIX validation or [RFC6125] 385 identity verification. Clients MAY treat such TLSA records as 386 unusable. 388 SMTP clients may also to the extent possible map these usages to the 389 corresponding non-PKIX certificate usages (0 to 2 and 1 to 3). 390 Servers publishing these certificate usages hoping to be protected by 391 both the public CA PKI and by DNSSEC will typically be protected by 392 neither. 394 TLSA Publishers should follow the TLSA publication size guidance 395 found in [I-D.dukhovni-dane-ops] about "DANE DNS Record Size 396 Guidelines". 398 2.2.1.1. Certificate usage 3 400 Since opportunistic DANE TLS will be used by non-interactive MTAs, 401 with no user to "press OK" when authentication fails, reliability of 402 peer authentication is paramount. TLSA records published for SMTP 403 servers SHOULD be "3 1 1" records to support opportunistic SMTP over 404 TLS with DANE. This record specifies the SHA-256 digest of the 405 server's public key. 407 Authentication via certificate usage "3" TLSA records involves no 408 certificate authority signature checks. It also involves no server 409 name checks, and thus does not impose any new requirements on the 410 names contained in the server certificate (SNI is not required when 411 the TLSA record matches the public key of the server's default 412 certificate). It uses the SHA-256 digest which all clients are 413 obligated to support, and works across certificate renewals with the 414 same key. 416 Two TLSA records will need to be published before updating a server's 417 public key, one matching the currently deployed key and the other 418 matching the new key scheduled to replace it. Once sufficient time 419 has elapsed for all DNS caches to time out the previous TLSA RRset, 420 which contains only the old key, the server may be reconfigured to 421 use the new private key and associated public key certificate. The 422 amount of time a server should wait before using a new key that is 423 referenced by new TLSA records should be at least twice the TTL of 424 the previously published TLSA records. Once the server is using a 425 new key, the obsolete TLSA RR can be removed from DNS, leaving only 426 the RR that matches the new key. 428 2.2.1.2. Certificate usage 2 430 Some domains may prefer to reduce the operational complexity of 431 publishing unique TLSA RRs for each TLS service. If the domain 432 employs a common issuing certificate authority to create certificates 433 for multiple TLS services, it may be simpler to publish the issuing 434 authority's public key as a trust-anchor for the certificate chains 435 of all relevant services. The TLSA RRs for each service issued by 436 the same TA may then be CNAMEs to a common TLSA RRset that matches 437 the TA. In this case, the certificate chain presented in the TLS 438 handshake of each service SHOULD include the TA certificate, as SMTP 439 clients cannot generally be expected to have domain-issued trust- 440 anchor certificates in their trusted certificate store. TLSA 441 Publishers should publish either "2 1 1" or "2 0 1" TLSA parameters, 442 which specify the SHA-256 digest of the trust-anchor public key or 443 certificate respectively. As with regular certificate rollover 444 discussed in Section 2.2.1.1, two such TLSA RRs need to be published 445 to facilitate TA certificate rollover. 447 The usability of "2 1 1" or "2 0 1" TLSA RRs with SMTP is not 448 assured. If server operators employing these RRs universally ensure 449 that the corresponding TA certificate is included in the SMTP 450 server's TLS handshake trust chain, clients can safely enable support 451 for these RRs. If sufficiently many server administrators are 452 negligent in deploying these RRs, SMTP clients will be hesitant to 453 support them, since mail delivery will not work to many destination 454 domains if they do. Server operators are encouraged to implement 455 these RRs, if they are operationally a better fit for their 456 organization, provided they do so with care. It is critical to never 457 forget to include trust-anchor certificates in server trust chains. 458 SMTP client implementations SHOULD support these TLSA RRs, unless 459 server operators fail publish certificate chains that include the 460 required TA certificate. 462 2.2.1.3. Certificate usage 1 464 SMTP servers SHOULD NOT publish TLSA RRs with certificate usage "1". 465 Clients MAY treat such TLSA records as unusable. Alternatively, SMTP 466 clients that implement this specification MAY ignore the PKIX 467 validation requirement when they encounter certificate usage "1", and 468 authenticate the server per the content of the TLSA record alone. 469 That is, SMTP clients may treat certificate usage "1" as certificate 470 usage "3". 472 2.2.1.4. Certificate usage 0 474 SMTP servers SHOULD NOT publish TLSA RRs with certificate usage "0". 475 Clients MAY treat such TLSA records as unusable. Alternatively, 476 since PKIX validation is not possible with opportunistic DANE TLS, 477 SMTP clients MAY treat certificate usage "0" RRs as though they were 478 certificate usage "2" RRs. But, with certificate usage "0" the 479 usability of the TLSA record depends more strongly on its matching 480 type. 482 If the matching type is "0" (the server should also avoid this 483 matching type and should publish usage "3" or "2" public key or 484 certificate digests), the TLSA record contains the full certificate 485 or full public key of the trusted certificate authority. In this 486 case the client has all the information it needs to match the server 487 trust-chain to the TLSA record. The client SHOULD ignore the PKIX 488 validation requirement, and verify the server's trust chain via its 489 DANE TLSA records only (name checks still apply as with usage "2"). 491 If the matching type is not "0", the TLSA record contains only a 492 digest of the trust certificate authority certificate or public key. 493 The server operator publishing usage 0 TLSA records may expect that 494 clients already have the issuing authority certificate on hand, and 495 may omit it from the server's certificate chain. As a result, the 496 client may not be able to match the server trust chain against the 497 TLSA record if it, in fact, does not have a copy of the certificate 498 authority certificate or public key. 500 SMTP clients that implement this specification SHOULD treat TLSA 501 records with certificate usage "0" and a digest matching type as 502 unusable, but MAY be explicitly configured to support them when it is 503 believed that clients posses a sufficiently complete set of trusted 504 public CA certificates. This is most plausible with an MUA which 505 only needs enough CA certificates to authenticate its preferred 506 submission service. 508 2.2.2. Certificate matching 510 When at least one usable "secure" TLSA record is found, the SMTP 511 client SHOULD use TLSA records to authenticate the next-hop host, 512 mail SHOULD not be delivered via this next-hop host if authentication 513 fails, otherwise the SMTP client is vulnerable to TLS man in the 514 middle attacks. 516 To match a server via a TLSA record with certificate usage "2", the 517 client MUST perform name checks to ensure that it has reached the 518 correct server. The SMTP client MUST accept the TLSA base domain as 519 a valid DNS name in the server certificate. Clients should also 520 accept securely looked up TLSA base domain obtained indirectly via an 521 MX lookup, or a CNAME resolved expansion. 523 Accepting certificates with the next-hop domain in addition to the 524 next-hop MX host allows a domain with multiple MX hosts to field a 525 single certificate bearing the email domain name across all the MX 526 hosts, this is also compatible with pre-DANE SMTP clients that are 527 configured to look for the email domain name in server certificates. 529 The client MUST NOT perform certificate usage name checks with 530 certificate usage "3", since with usage "3" the server is 531 authenticated directly by matching the TLSA RRset to its certificate 532 or public key without resort to any issuing authority. The 533 certificate content is ignored except in so far as it is used to 534 match the certificate or public key digest with the TLSA RRset. 536 To ensure that the server sends the right certificate chain, the SMTP 537 client MUST send the TLS SNI extension containing the TLSA base 538 domain. Since DANE-aware clients are obligated to send SNI 539 information, which requires at least TLS 1.0, SMTP servers for which 540 DANE TLSA records are published MUST support TLS 1.0 or later with 541 any client authorized to use the service. 543 Each SMTP server MUST present a certificate trust chain (see 544 [RFC2246] Section 7.4.2) that matches at least one of the TLSA 545 records. The server MAY rely on SNI to determine which certificate 546 chain to present to the client. Clients that don't send SNI 547 information may not see the expected certificate chain. 549 If the server's TLSA RRset includes records with a matching type 550 indication a digest record (i.e., a value other than "0"), the 551 SHA-256 digest of any object SHOULD be provided along with any other 552 digest published, since clients may support only SHA-256. Unless 553 SHA-256 proves vulnerable to a "second preimage" attack, it should be 554 the only digest algorithm used in TLSA records. 556 If the server's TLSA records match the server's default certificate 557 chain, the server need not support SNI. The server need not include 558 the extension in its TLS HELLO, simply returning a matching 559 certificate chain is sufficient. Servers MUST NOT enforce the use of 560 SNI by clients, if the client sends no SNI extension, or sends an SNI 561 extension for an unsupported domain the server MUST simply use its 562 default certificate chain. The client may be using unauthenticated 563 opportunistic TLS and may not expect any particular certificate from 564 the server. 566 The client may even offer to use anonymous TLS ciphersuites and 567 servers SHOULD support these, no security is gained by forcing the 568 use of a certificate the client will ignore. Indeed support for 569 anonymous ciphersuites in the server makes audit trails more useful 570 if the chosen ciphersuite is logged, as this will in many cases 571 record which clients did not care to authenticate the server. (The 572 Postfix SMTP server supports anonymous TLS ciphersuites by default, 573 and the Postfix SMTP client offers these at its highest preference 574 when server authentication is not applicable). 576 With opportunistic DANE TLS, both the TLS support implied by the 577 presence of DANE TLSA records and the verification parameters 578 necessary to authenticate the TLS peer are obtained together, 579 therefore authentication via this protocol is expected to be less 580 prone to connection failure caused by incompatible configuration of 581 the client and server. 583 3. Opportunistic TLS for Submission 585 Prior to [RFC6409], the SMTP submission protocol was a poster child 586 for PKIX TLS. The MUA typically connects to one or more submission 587 servers explicitly configured by the user. There is no indirection 588 via insecure MX records, and unlike web browsers, there is no need to 589 authenticate a large set of TLS servers. Once TLS is enabled for the 590 desired submission server or servers, provided the server certificate 591 is correctly maintained, the MUA is able to reliably use TLS to 592 authenticate the submission server. 594 [RFC6186] aims to simplify the configuration of the MUA submission 595 service by dynamically deriving the submission service from the 596 user's email address. This is done via SRV records, but at the cost 597 of introducing the same TLS security problems faced by MTA to MTA 598 SMTP. Prompting the user when the SRV record domain is different 599 from the email domain is not a robust solution. 601 The protocol defined in this memo can also be used to 602 opportunistically secure the submission service association. If the 603 email domain is DNSSEC signed, the SRV records are "secure" and the 604 SRV host publishes secure TLSA records for submission, then the MUA 605 can safely auto-configure to authenticate the submission server via 606 DANE. When DANE TLSA records are not available, the client SHOULD 607 fall back to legacy behavior. 609 Specifically, MUAs that dynamically determine the submission server 610 via SRV records SHOULD support DNSSEC and DANE TLSA records. They 611 SHOULD use TLSA records to authenticate the server. The processing 612 of usage 2 and 3 TLSA associations by an MUA is the same as by an MTA 613 with SRV records replaced by corresponding MX records. 615 Just as with port 25, SMTP submission servers SHOULD NOT publish 616 usage 0 or 1 TLSA associations, and MUAs that support DANE TLSA are 617 not expected to trust a full list of public CAs. Server certificate 618 subjectAltNames should include at least the server name. When the 619 server administrator is also authorized to obtain certificates for 620 the email domain, the server certificate should also include the 621 email domain name. MUAs that are not able to support DNSSEC may then 622 be able to authenticate the server domain. If it is practical to 623 field additional certificates for hosted domains, SNI may be used by 624 the server to select the appropriate domain's certificate. 626 4. Mandatory TLS Security 628 An MTA implementing this protocol may require a stronger security 629 assurance when sending email to selected destinations to which the 630 sending organization sends sensitive email and may have regulatory 631 obligations to protect its content. This protocol is not in conflict 632 with such a requirement, and in fact it can often simplify 633 authenticated delivery to such destinations. 635 Specifically, with domains that publish DANE TLSA records for their 636 MX hosts a sending MTA can be configured to use the receiving 637 domains's DANE TLSA records to authenticate the corresponding MX 638 hosts, thereby obviating the complex manual provisioning process. In 639 anticipation of, or in response to, a failure to obtain the expected 640 TLSA records, the sending system's administrator may choose from a 641 selection of fallback options, if supported by the sending MTA: 643 o Defer mail if no usable TLSA records are found. This is useful 644 when the destination is known to publish TLSA records, and lack of 645 TLSA records is most likely a transient misconfiguration. 647 o Authenticate the peer via a manually configured certificate 648 digest. This may be obtained, for example, after a problem is 649 detected and confirmed to be valid by some out-of-band mechanism. 651 o Authenticate the peer via the existing public CA PKI, if the peer 652 server has usable CA issued certificates. In many cases the 653 sending MTA will need custom certificate name matching rules to 654 match the destination's gateways. And the sending server must 655 explicitly configure policy for the destination to always require 656 TLS to prevent MITM attacks. 658 o Send via unauthenticated mandatory TLS. This is useful if the 659 requirement is merely to always encrypt transmissions to protect 660 against only eavesdropping, and the possibility of MITM attacks is 661 less of a concern than timely email delivery. 663 It should be noted that barring administrator intervention, email 664 SHOULD be deferred when DNSSEC lookups fail, (as distinct from 665 "secure" non-existence of TLSA records, or secure evidence that the 666 domain is no longer signed). In addition to configuring fallback 667 strategies when TLSA records are unexpectedly absent, administrators 668 may, in hopefully rare cases, need to disable DNSSEC lookups for a 669 destination to work around a DNSSEC outage. 671 5. Acknowledgements 673 The authors would like to extend great thanks to Tony Finch, who 674 started the original version of a DANE SMTP document. His work is 675 greatly appreciated and has been incorporated into this document. 676 The authors would like to additionally thank Phil Pennock for his 677 comments and advice on this document. 679 Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded 680 me into participating in DANE working group discussions. Thanks to 681 Paul Hoffman who motivated me to produce this memo and provided 682 feedback on early drafts. Thanks also to Wietse Venema who created 683 Postfix, and patiently guided the Postfix DANE implementation to 684 production quality. 686 6. Security Considerations 688 This protocol leverages DANE TLSA records to implement MITM resistant 689 opportunistic channel security for SMTP. For destination domains 690 that sign their MX records and publish signed TLSA records for their 691 MX hosts, this protocol allows sending MTAs (and perhaps dynamically 692 configured MUAs) to securely discover both the availability of TLS 693 and how to authenticate the destination. 695 This protocol does not aim to secure all SMTP traffic, as that is not 696 practical until DNSSEC and DANE adoption are universal. The 697 incremental deployment provided by following this specification is a 698 best possible path for securing SMTP. This protocol coexists and 699 interoperates with the existing insecure Internet email backbone. 701 The protocol does not preclude existing non-opportunistic SMTP TLS 702 security arrangements, which can continue to be used as before via 703 manual configuration and negotiated out-of-band key and TLS 704 configuration exchanges. 706 Opportunistic SMTP TLS depends critically on DNSSEC for downgrade 707 resistance and secure resolution of the destination name. If DNSSEC 708 is compromised, it is not possible to fall back on the public CA PKI 709 to prevent MITM attacks. A successful breach of DNSSEC enables the 710 attacker to publish TLSA usage 3 certificate associations, and 711 thereby bypass any security benefit the legitimate domain owner might 712 hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of 713 public CA PKI support in existing MTA deployments, deprecating 714 certificate usages 0 and 1 in this specifications improves 715 interoperability without degrading security. 717 7. Normative References 719 [I-D.dukhovni-dane-ops] 720 Dukhovni, V., "DANE TLSA implementation and operational 721 guidance", draft-dukhovni-dane-ops-00 (work in progress), 722 May 2013. 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", BCP 14, RFC 2119, March 1997. 727 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 728 RFC 2246, January 1999. 730 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 731 Transport Layer Security", RFC 3207, February 2002. 733 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 734 and T. Wright, "Transport Layer Security (TLS) 735 Extensions", RFC 3546, June 2003. 737 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 738 Rose, "DNS Security Introduction and Requirements", RFC 739 4033, March 2005. 741 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 742 Rose, "Resource Records for the DNS Security Extensions", 743 RFC 4034, March 2005. 745 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 746 Rose, "Protocol Modifications for the DNS Security 747 Extensions", RFC 4035, March 2005. 749 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 750 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 752 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 753 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 755 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 756 Housley, R., and W. Polk, "Internet X.509 Public Key 757 Infrastructure Certificate and Certificate Revocation List 758 (CRL) Profile", RFC 5280, May 2008. 760 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 761 October 2008. 763 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 764 Extension Definitions", RFC 6066, January 2011. 766 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 767 Verification of Domain-Based Application Service Identity 768 within Internet Public Key Infrastructure Using X.509 769 (PKIX) Certificates in the Context of Transport Layer 770 Security (TLS)", RFC 6125, March 2011. 772 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 773 Submission/Access Services", RFC 6186, March 2011. 775 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 776 STD 72, RFC 6409, November 2011. 778 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 779 of Named Entities (DANE) Transport Layer Security (TLS) 780 Protocol: TLSA", RFC 6698, August 2012. 782 Authors' Addresses 784 Viktor Dukhovni 785 Unaffiliated 787 Email: ietf-dane@dukhovni.org 789 Wes Hardaker 790 Parsons 791 P.O. Box 382 792 Davis, CA 95617 793 US 795 Email: ietf@hardakers.net