idnits 2.17.1 draft-ietf-dane-smtp-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 355 has weird spacing: '...ocument this ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 25, 2013) is 4109 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 4409 (Obsoleted by RFC 6409) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS-Based Authentication of Named T. Finch 3 Entities (DANE) University of Cambridge 4 Internet-Draft January 25, 2013 5 Intended status: Standards Track 6 Expires: July 29, 2013 8 Secure SMTP with TLS, DNSSEC and TLSA records. 9 draft-ietf-dane-smtp-00 11 Abstract 13 SMTP has a STARTTLS extension, but (especially in the case of inter- 14 domain mail transfer) it only provides very limited security because 15 it does not specify how to authenticate the server's certificate. 16 This memo specifies how TLSA records in the DNS can be used for 17 proper SMTP server authentication. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 29, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Questions for reviewers . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Inter-domain SMTP with TLSA . . . . . . . . . . . . . . . . . 4 57 3.1. MX lookup checks . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. SMTP server checks . . . . . . . . . . . . . . . . . . . . 5 59 4. Intra-domain SMTP with TLSA . . . . . . . . . . . . . . . . . 6 60 5. The Transmitted: header field . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 6.1. "with" protocol types . . . . . . . . . . . . . . . . . . 8 63 6.2. Permanent message header field registration . . . . . . . 8 64 6.3. "dane" MTA-name-type . . . . . . . . . . . . . . . . . . . 8 65 7. Security considerations . . . . . . . . . . . . . . . . . . . 9 66 7.1. Fallback to insecure SMTP . . . . . . . . . . . . . . . . 9 67 7.2. A mail domain trusts its SMTP servers . . . . . . . . . . 9 68 7.3. Temporary failures and denial of service . . . . . . . . . 9 69 7.4. Certificate subject name matching . . . . . . . . . . . . 10 70 7.5. Deliberate omissions . . . . . . . . . . . . . . . . . . . 10 71 8. Internationalization Considerations . . . . . . . . . . . . . 10 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 13 77 Appendix B. Rationale - choice of certificate identity . . . . . 13 78 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 14 79 C.1. Changes in version -00 . . . . . . . . . . . . . . . . . . 14 80 C.2. Changes in version fanf-04 . . . . . . . . . . . . . . . . 14 81 C.3. Changes in version fanf-03 . . . . . . . . . . . . . . . . 14 82 C.4. Changes in version fanf-02 . . . . . . . . . . . . . . . . 15 83 C.5. Changes in version fanf-01 . . . . . . . . . . . . . . . . 15 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 The specification for SMTP over TLS [RFC3207] does not describe how 89 to authenticate a server: which identity relating to the connection 90 ought to be authenticated by the server's certificate. In practice, 91 most certificates presented by publicly-referenced SMTP servers 92 either cannot be validated with respect to a well-known certification 93 authority, or do not verify any identity expected by the client. 95 As a result, inter-domain SMTP clients cannot require working server 96 authentication if they want to successfully send mail using TLS. 97 Therefore TLS currently provides only a limited amount of additional 98 security for inter-domain SMTP. Its encryption protects against on- 99 path passive eavesdropping; but it does not protect against an active 100 attack, since the client has no way to detect when an attacker is 101 spoofing the server. 103 This memo describes how to fix this using DNSSEC [RFC4033] and TLSA 104 records [RFC6698] with owner names of the form "_25._tcp.hostname". 106 We use DNSSEC to secure the association between a mail domain and its 107 SMTP server host names, and between the host names and their 108 certificates. Connections to servers are authenticated by their TLS 109 certificates. 111 As well as its normal function of providing an association between a 112 domain name and a certificate, we are also using the existance of a 113 TLSA record to signal to the client that it can expect the server to 114 offer TLS with a valid certificate. 116 The security situation is better for intra-domain SMTP, because in 117 this case the client and server can be configured with prior 118 knowledge of how to authenticate each other. This specification can 119 also be used for authenticating servers in intra-domain SMTP. 121 This memo does not cover message submission [RFC4409] [RFC5068] 122 [RFC6186], nor does it cover LMTP [RFC2033], since they use the DNS 123 in a different way than MTA-to-MTA SMTP. 125 The protocol described in this memo adds new security checks that can 126 cause email delivery to be delayed when a security failure is 127 detected. We specify that clients treat a problems as a "temporary 128 failure", causing the message to be queued for a later delivery 129 attempt, in the hope that the attack (or configuration error) will 130 have been dealt with. 132 1.1. Questions for reviewers 134 Is the Transmitted: header useful enough to include in this spec? 135 Should it be dropped, or perhaps moved to another document? 137 Is the "dane" MTA-name-type for use in delivery status notifications 138 a good idea? Is it likely to cause interoperability problems? 140 Is the description of DNSSEC validation over-done? Can it be trimmed 141 down so it relies more on the core DNSSEC specs? 143 2. Terminology 145 ADMD: An ADministrative Management Domain, as described in the 146 Internet Mail Architecture [RFC5598]. 148 Inter-domain SMTP: SMTP between different ADMDs across the public 149 Internet, where a client MTA sends mail to a publicly-referenced 150 SMTP server MTA. 152 Intra-domain SMTP: SMTP between MTAs within an ADMD. 154 Mail domain: The part of an email address after the "@"; also the 155 owner name of a (possibly implicit) MX record. 157 MX resolution: The algorithm for resolving a mail domain into a set 158 of SMTP server hosts, described in [RFC5321] section 5. 160 Publicly-referenced SMTP server: An SMTP server which runs on port 161 25 of an Internet host located using MX resolution. (This term is 162 from [RFC3207].) 164 SMTP server host name: The target of a (possibly implicit) MX 165 record. 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 memo are to be interpreted as described in [RFC2119]. 171 3. Inter-domain SMTP with TLSA 173 In the following we describe some additions to the usual MX 174 resolution algorithm described in [RFC5321] section 5. If there is 175 any conflict between this memo and the other specifications cited in 176 this section, that is an error in this memo. 178 3.1. MX lookup checks 180 The client SHALL look up the MX RRset for the mail domain. There are 181 three succesful results that yield a list of SMTP server host names: 183 o A list of one or more MX records; 185 o An implicit MX record, in lieu of an empty list of MX records; 187 o A CNAME or DNAME pointing to a successful result. 189 If the lookup is not successful, the client SHALL proceed as 190 described in [RFC5321] section 5. 192 If any of the responses is "bogus" according to DNSSEC validation 193 ([RFC4033] section 5) the client MUST treat this as a temporary 194 error. 196 For this protocol to take effect, all of these DNS RRsets MUST be 197 "secure" according to DNSSSEC validation. In the case of an implicit 198 MX record, there MUST be a secure denial of existence of an MX RRset 199 for the mail domain. In the case of a (chain of) CNAME or DNAME RRs, 200 the whole chain MUST be secure as well as the ultimate target. 202 If they are not all secure, this protocol has not been fully 203 deployed. The client SHOULD fall back to insecure delivery (which 204 might be over unauthenticated TLS). 206 (If the client is using a non-validating security-aware stub resolver 207 (see [RFC4033] section 7), it can rely on its recursive name server 208 to perform these checks and set the AD bit according to the result - 209 see [RFC4035] section 3.2.3.) 211 The client now has an authentic list of SMTP server host names and 212 priority values. It processes this list as described in [RFC5321] 213 section 5 (sorting the host names etc.) without regard to the 214 presence or absence of DNSSEC or TLSA records. 216 3.2. SMTP server checks 218 This sub-section applies to each SMTP server host name individually. 220 When connecting to a server, the client SHALL look up the server's 221 TLSA RRset as described in [RFC6698] section 3. That is, the TLSA 222 RRset owner name SHALL be "_25._tcp.hostname" where "hostname" is the 223 SMTP server host name. The response can be one of the following (as 224 listed in [RFC6698] section 4.1): 226 o A secure answer containing one or more TLSA records, in which case 227 the client SHALL proceed as descrbed below. 229 o A bogus answer or other failure, which the client MUST treat as a 230 temporary error. 232 o If there is no TLSA record or its DNSSEC validation state is 233 insecure or indeterminate, this protocol has not been fully 234 deployed. The client SHOULD deliver to this server insecurely 235 (which might be over unauthenticated TLS, as described in the 236 introduction). 238 The client now has one or more TLSA records for the server it is 239 connecting to. 241 The client MUST ensure that the server offers the STARTTLS service 242 extension [RFC3207] in its response to the client's EHLO command 243 ([RFC5321] section 4.1.1.1). 245 The client SHALL then issue the STARTTLS command which MUST be 246 successful. It then proceeds with TLS negotiation [RFC5246]. If the 247 client uses the Server Name Indication TLS extension ([RFC6066] 248 section 3) it MUST use the SMTP server host name as the value for the 249 ServerName field. 251 The client SHALL validate the server's certificate as described in 252 [RFC6698] section 2.1. (This might or might not include PKIX 253 certificate validation [RFC5280].) 255 The client SHALL verify that the server host name matches the 256 identity asserted by the server's certificate as described in 257 [RFC6125] section 6. Following that specification, the client's list 258 of reference identifiers SHOULD include the SMTP server host name 259 with type DNS-ID, and MAY include a second copy of the host name with 260 type CN-ID. 262 If any of these checks fail, the client MUST disconnect from the 263 server and treat this as a temporary failure. 265 If all the checks pass, the client can then proceed to deliver mail 266 securely. 268 4. Intra-domain SMTP with TLSA 270 Mail transmission within an ADMD can be based on MX records (such as 271 when delivering incoming mail to its destination host) or on 272 statically configured host names (such as when routing outgoing mail 273 via a border relay). 275 When routing internal mail using MX records, Section 3 applies the 276 same as for inter-domain SMTP. 278 When routing mail using host names, the MX lookup step is skipped and 279 only Section 3.2 applies. 281 5. The Transmitted: header field 283 The client MAY wish to insert a Transmitted: header field at the 284 start of the message header just before transmitting the message. 285 This records the result of the checks specified in the previous 286 section. (See Section 7 for some comments on its utility or lack 287 thereof.) It is a client-side counterpart to the Received: header 288 field ([RFC5321] section 4.4) and has very similar syntax. It SHOULD 289 be treated as a trace field. 291 The syntax of the Transmitted: header field is described using ABNF 292 [RFC5234]. Non-terminal syntax rules not defined in this memo are 293 defined in [RFC5321], or [RFC5322], or [RFC5234]. 295 Transmitted-line = "Transmitted:" FWS To-domain By-domain 296 Opt-info [CFWS] ";" date-time CRLF 298 To-domain = "TO" FWS Extended-Domain 300 A SHALL include: 302 o A clause describing the SMTP server. The 303 part of a SHALL be the same as the SMTP server host 304 name. 306 o A clause identifying the SMTP client that added the 307 header. (If the client also acts as a server this is the same 308 clause it would include in any Received: header fields 309 it adds.) This clause helps with recovery if the original order 310 of a message header's fields has been lost. 312 o Various clauses, which MUST include a clause. 313 The part of this clause is used to indicate whether the 314 client successfully authenticated the server, using one of the 315 types specified in Section 6.1. 317 o And a to further help with disordering in case a 318 message is transmitted by the same client more than once. 320 6. IANA Considerations 322 6.1. "with" protocol types 324 The "with" protocol type registry includes a number of keywords that 325 indicate the use of SMTP with or without TLS and/or AUTH [RFC3848]. 326 When these types appear in a Transmitted: header field "with" clause 327 they indicate that the client did not authenticate the server as 328 described in Section 3. 330 o The new keyword "ESMTPT" indicates the use of ESMTP [RFC5321] with 331 STARTTLS [RFC3207] when the client successfully authenticated the 332 server. 334 o The new keyword "ESMTPTA" indicates the use of ESMTP [RFC5321] 335 with STARTTLS [RFC3207] and AUTH [RFC4954] when the client 336 successfully authenticated the server. 338 These new keywords are not for use in Received: header fields since 339 the server cannot tell whether or not the client authenticated it. 341 There are no keywords corresponding to a client trying and failing to 342 authenticate the server, since in this case no message transmission 343 occurs. 345 6.2. Permanent message header field registration 347 Header field name: Transmitted: 349 Applicable protocol: mail 351 Status: standard 353 Change controller: IETF 355 Specification document this memo 357 6.3. "dane" MTA-name-type 359 Delivery status notifications [RFC3464] can include a Remote-MTA 360 field recording an SMTP server host name. When this has been 361 authenticated according to Section 3 the reporting MTA MAY use an 362 MTA-type-name of "dane". 364 a. MTA-type-name: "dane" 366 b. Syntax: same as the "dns" MTA-type-name [RFC3461] 367 c. Translation into US-ASCII: none needed 369 7. Security considerations 371 7.1. Fallback to insecure SMTP 373 This memo provides only conditional security. It allows a server to 374 publish in the DNS the details of how it can be authenticated. 375 Clients that implement this protocol can use it to provide a strong 376 guarantee that they are sending mail to the correct place. If either 377 of these is missing, mail delivery will be insecure. 379 There is no secure way for a server to tell if a client has 380 authenticated it using this protocol. This is a general limitation 381 of TLS. The Transmitted: header field records this information for 382 tracing and debugging and measuring deployment, not for security 383 purposes. 385 We do not specify that clients check that all of a mail domain's SMTP 386 server host names are consistent in whether they have or do not have 387 TLSA records. This is so that partial or incremental deployment does 388 not break mail delivery. Different levels of deployment are likely 389 if a domain has a third-party backup MX, for example. 391 The MX sorting rules are unchanged; in particular they have not been 392 altered in order to prioritize secure servers over insecure servers. 393 If a site wants to be secure it needs to deploy this protocol 394 completely; a partial deployment is not secure and we make no special 395 effort to support it. 397 7.2. A mail domain trusts its SMTP servers 399 By signing their zone with DNSSEC, a mail domain owner implicitly 400 instructs SMTP clients to check their SMTP server TLSA records. This 401 implies another point in the trust relationship between mail domain 402 owner and smtp server operator. Most of the setup requirements for 403 this protocol fall on the SMTP server operator: installing a TLS 404 certificate with the correct name, and publishing a TLSA record under 405 that name. If these are not correct then mail delivery from TLSA- 406 aware clients might be delayed. 408 7.3. Temporary failures and denial of service 410 Many provisioning failures in SMTP cause "permanent" failures, that 411 is the immediate and final rejection of the message. This includes 412 missing DNS records, an SMTP server that is not configured to accept 413 mail for the recipient domain, and so forth. 415 In this protocol, provisioning an incorrect TLS certificate triggers 416 a temporary error. This is because we want to minimise the damage 417 that occurs when an on-path attacker intercepts the TCP connection 418 between an SMTP client and server. An attacker can cause delays, but 419 is not able to trigger immediate delivery failures. 421 7.4. Certificate subject name matching 423 Section 4 of the TLSA specification [RFC6698] leaves the details of 424 checking names in certificates to higher level application protocols, 425 though it suggests the use of [RFC6125]. 427 Name checking might appear to be unnecessary, since DNSSEC provides a 428 secure binding between the server name and the TLSA record, which in 429 turn authenticates the certificate. However this latter step can be 430 indirect, via a chain of certificates. A usage=0 TLSA record only 431 authenticates the CA that issued the certificate, and third parties 432 can obtain certificates from the same CA. 434 So this specification says that SMTP clients check that the server's 435 certificate matches the server host name, to ensure that the 436 certificate was issued by the CA to the server that the client is 437 connecting to. The client always performs this check regardless of 438 the TLSA usage, because the implementation is simpler and so that 439 this specification is less likely to need updating when new TLSA 440 usages are added. 442 7.5. Deliberate omissions 444 We do not specify that clients check the DNSSEC state of the SMTP 445 server address records. This is not necessary since the certificate 446 checks ensure that the client has connected to the correct server. 447 (The address records will normally have the same security state as 448 the TLSA records, but they can differ if there are CNAME or DNAME 449 indirections.) 451 This memo does not specify any changes to SMTP client authentication. 452 Inter-domain SMTP client authentication remains extremely weak. 453 Intra-domain SMTP can be configured as strong as necessary (using 454 SMTP AUTH or TLS client certificates, for instance) but that is out 455 of scope for this memo. 457 8. Internationalization Considerations 459 If any of the DNS queries are for an internationalized domain name, 460 then they need to use the A-label form [RFC5890]. 462 9. Acknowledgements 464 Thanks to Mark Andrews for arguing that authenticating the SMTP 465 server host name is the right thing, and that we ought to rely on 466 DNSSEC to secure the MX lookup. Thanks to James Cloos, Ned Freed, 467 Olafur Gudmundsson, Paul Hoffman, Phil Pennock, Hector Santos, Jonas 468 Schneider, and Alessandro Vesely for helpful suggestions. 470 10. References 472 10.1. Normative References 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, March 1997. 477 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 478 Transport Layer Security", RFC 3207, February 2002. 480 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 481 Extension for Delivery Status Notifications (DSNs)", 482 RFC 3461, January 2003. 484 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 485 for Delivery Status Notifications", RFC 3464, 486 January 2003. 488 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types 489 Registration", RFC 3848, July 2004. 491 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 492 Rose, "DNS Security Introduction and Requirements", 493 RFC 4033, March 2005. 495 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 496 Rose, "Protocol Modifications for the DNS Security 497 Extensions", RFC 4035, March 2005. 499 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 500 for Authentication", RFC 4954, July 2007. 502 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 503 Specifications: ABNF", STD 68, RFC 5234, January 2008. 505 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 506 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 508 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 509 Housley, R., and W. Polk, "Internet X.509 Public Key 510 Infrastructure Certificate and Certificate Revocation List 511 (CRL) Profile", RFC 5280, May 2008. 513 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 514 October 2008. 516 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 517 October 2008. 519 [RFC5890] Klensin, J., "Internationalized Domain Names for 520 Applications (IDNA): Definitions and Document Framework", 521 RFC 5890, August 2010. 523 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 524 Extension Definitions", RFC 6066, January 2011. 526 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 527 Verification of Domain-Based Application Service Identity 528 within Internet Public Key Infrastructure Using X.509 529 (PKIX) Certificates in the Context of Transport Layer 530 Security (TLS)", RFC 6125, March 2011. 532 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 533 of Named Entities (DANE) Transport Layer Security (TLS) 534 Protocol: TLSA", RFC 6698, August 2012. 536 10.2. Informative References 538 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 539 October 1996. 541 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 542 RFC 4409, April 2006. 544 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 545 Finch, "Email Submission Operations: Access and 546 Accountability Requirements", BCP 134, RFC 5068, 547 November 2007. 549 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 550 July 2009. 552 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 553 Submission/Access Services", RFC 6186, March 2011. 555 Appendix A. Example 557 In the following, most of the DNS resource data is elided for 558 simplicity. 560 ; mail domain 561 example.com. MX 1 mx.example.net. 562 example.com. RRSIG MX ... 564 ; SMTP server host name 565 mx.example.net. A 192.0.2.1 566 mx.example.net. AAAA 2001:db8:212:8::e:1 568 ; TLSA resource record 569 _25._tcp.mx.example.net. TLSA ... 570 _25._tcp.mx.example.net. RRSIG TLSA ... 572 Mail for addresses at example.com is delivered by SMTP to 573 mx.example.net. Connections to mx.example.net port 25 that use 574 STARTTLS will get a server certificate that authenticates the name 575 mx.example.net. 577 Appendix B. Rationale - choice of certificate identity 579 There are a number of reasons for the certificate to authenticate the 580 SMTP server host name rather than the mail domain. 582 SMTP allows a client to transfer mail to recipients at multiple 583 domains in the same connection. If the certificate identifies the 584 host name then it does not need to list all the possible mail 585 domains. 587 It is not in general feasible for the server to select a mail domain 588 certificate based on the recipient domains when the connection is 589 established (using Server Name Indication, [RFC6066] section 3), 590 because an SMTP client might not know all of the recipients when it 591 establishes the connection. 593 Outgoing SMTP relays and message submission servers handle mail for 594 any domain, so in those cases the only sensible option is for the 595 certificate to contain the host name. It is more consistent for 596 incoming MX server certificates to match. 598 It is common for SMTP servers to act in multiple roles, as outgoing 599 relays or as incoming MX servers, depending on the client identity. 600 It is simpler if the server can present the same certificate 601 regardless of the role in which it is to act. 603 Sometimes the server does not know its role until the client has 604 authenticated, which usually occurs after TLS has been established. 606 This protocol does not provide an option for directly authenticating 607 the mail domain because that would add complexity without providing 608 any benefit, and security protocols are best kept simple. As 609 described above, there are real-world cases where authenticating the 610 mail domain cannot be made to work, so there are complicated criteria 611 for when mail domain TLSA records might be used and when they cannot. 612 This is all avoided by authenticating the SMTP server host name. 614 Finally, this protocol only affects the logic in the SMTP client and 615 requires no additional SMTP server functionality, such as support for 616 the TLS Server Name Indication extension. 618 Appendix C. Change log 620 C.1. Changes in version -00 622 Change doc name from draft-fanf-dane-smtp to draft-ietf-dane-smtp. 624 Update DANE citation to published RFC. 626 Be clearer about the PKIX certificate validation vs. certificate 627 subject name matching. 629 Minor clarifications suggested by Phill Hallam-Baker and James Cloos. 631 C.2. Changes in version fanf-04 633 Add some questions for reviewers 635 Add a note about stub resolvers and the AD bit. 637 Internationalization considerations. 639 C.3. Changes in version fanf-03 641 Clarify how to use SNI with this protocol. 643 Clarify lack of changes to MX sorting rules. 645 Mention DNAME as well as CNAME. 647 An example. 649 C.4. Changes in version fanf-02 651 Clarify the wording that describes how a client determines that this 652 protocol is in effect. 654 Divide the security considerations into sub-sections, and add a 655 subsection on denial of service. 657 Clarify intro, mentioning TLSA owner name format. 659 Extend the scope to cover MTA-to-MTA mail within an ADMD as well as 660 between ADMDs. 662 C.5. Changes in version fanf-01 664 More about why not to authenticate mail domains in the rationale. 666 Change DNS-ID requirement from MUST to SHOULD to follow RFC 6125. 668 Acknowledgments section. 670 Transmitted: header trace field. Not sure if this is a good idea; 671 feedback wanted. 673 "dane" MTA-name-type for use in DSNs. Even less sure if this is a 674 good idea. 676 Author's Address 678 Tony Finch 679 University of Cambridge Computing Service 680 New Museums Site 681 Pembroke Street 682 Cambridge CB2 3QH 683 ENGLAND 685 Phone: +44 797 040 1426 686 Email: dot@dotat.at 687 URI: http://dotat.at/