idnits 2.17.1 draft-fanf-dane-smtp-02.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 321 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 (May 31, 2012) is 4349 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 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-23) exists of draft-ietf-dane-protocol-21 -- Obsolete informational reference (is this intentional?): RFC 4409 (Obsoleted by RFC 6409) Summary: 1 error (**), 0 flaws (~~), 4 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 May 31, 2012 5 Intended status: Standards Track 6 Expires: December 2, 2012 8 Secure SMTP with TLS, DNSSEC and TLSA records. 9 draft-fanf-dane-smtp-02 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 December 2, 2012. 36 Copyright Notice 38 Copyright (c) 2012 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Inter-domain SMTP with TLSA . . . . . . . . . . . . . . . . . 4 56 3.1. MX lookup checks . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. SMTP server checks . . . . . . . . . . . . . . . . . . . . 5 58 4. Intra-domain SMTP with TLSA . . . . . . . . . . . . . . . . . 6 59 5. The Transmitted: header field . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 6.1. "with" protocol types . . . . . . . . . . . . . . . . . . 7 62 6.2. Permanent message header field registration . . . . . . . 8 63 6.3. "dane" MTA-name-type . . . . . . . . . . . . . . . . . . . 8 64 7. Security considerations . . . . . . . . . . . . . . . . . . . 8 65 7.1. Fallback to insecure SMTP . . . . . . . . . . . . . . . . 8 66 7.2. A mail domain trusts its SMTP servers . . . . . . . . . . 9 67 7.3. Temporary failures and denial of service . . . . . . . . . 9 68 7.4. Deliberate omissions . . . . . . . . . . . . . . . . . . . 9 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Appendix A. Rationale - choice of certificate identity . . . . . 11 74 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 12 75 B.1. Changes in version -02 . . . . . . . . . . . . . . . . . . 12 76 B.2. Changes in version -01 . . . . . . . . . . . . . . . . . . 12 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The specification for SMTP over TLS [RFC3207] does not describe how 82 to authenticate a server: which identity relating to the connection 83 ought to be authenticated by the server's certificate. In practice, 84 most certificates presented by publicly-referenced SMTP servers 85 either cannot be validated with respect to a well-known certification 86 authority, or do not verify any identity expected by the client. 88 As a result, inter-domain SMTP clients cannot require working server 89 authentication if they want to successfully send mail using TLS. 90 Therefore TLS currently provides only a limited amount of additional 91 security for inter-domain SMTP. Its encryption protects against on- 92 path passive eavesdropping; but it does not protect against an active 93 attack, since the client has no way to detect when an attacker is 94 spoofing the server. 96 This memo describes how to fix this using DNSSEC [RFC4033] and TLSA 97 records [I-D.ietf-dane-protocol] with owner names of the form 98 "_25._tcp.hostname". 100 We use DNSSEC to secure the association between a mail domain and its 101 SMTP server host names, and between the host names and their 102 certificates. Connections to servers are authenticated by their TLS 103 certificates. 105 As well as its normal function of providing an association between a 106 domain name and a certificate, we are also using the existance of a 107 TLSA record to signal to the client that it can expect the server to 108 offer TLS with a valid certificate. 110 The security situation is better for intra-domain SMTP, because in 111 this case the client and server can be configured with prior 112 knowledge of how to authenticate each other. This specification can 113 also be used for authenticating servers in intra-domain SMTP. 115 This memo does not cover message submission [RFC4409] [RFC5068] 116 [RFC6186], nor does it cover LMTP [RFC2033], since they use the DNS 117 in a different way than MTA-to-MTA SMTP. 119 The protocol described in this memo adds new security checks that can 120 cause email delivery to be delayed when a security failure is 121 detected. We specify that clients treat a problems as a "temporary 122 failure", causing the message to be queued for a later delivery 123 attempt, in the hope that the attack (or configuration error) will 124 have been dealt with. 126 2. Terminology 128 ADMD: An ADministrative Management Domain, as described in the 129 Internet Mail Architecture [RFC5598]. 131 Inter-domain SMTP: SMTP between different ADMDs across the public 132 Internet, where a client MTA sends mail to a publicly-referenced 133 SMTP server MTA. 135 Intra-domain SMTP: SMTP between MTAs within an ADMD. 137 Mail domain: The part of an email address after the "@"; also the 138 owner name of a (possibly implicit) MX record. 140 MX resolution: The algorithm for resolving a mail domain into a set 141 of SMTP server hosts, described in [RFC5321] section 5. 143 Publicly-referenced SMTP server: An SMTP server which runs on port 144 25 of an Internet host located using MX resolution. (This term is 145 from [RFC3207].) 147 SMTP server host name: The target of a (possibly implicit) MX 148 record. 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 memo are to be interpreted as described in [RFC2119]. 154 3. Inter-domain SMTP with TLSA 156 In the following we describe some additions to the usual MX 157 resolution algorithm described in [RFC5321] section 5. If there is 158 any conflict between this memo and the other specifications cited in 159 this section, that is an error in this memo. 161 3.1. MX lookup checks 163 The client SHALL look up the MX RRset for the mail domain. There are 164 three succesful results that yield a list of SMTP server host names: 166 o A list of one or more MX records; 168 o An implicit MX record, in lieu of an empty list of MX records; 170 o A CNAME to a successful result. 172 If the lookup is not successful, the client SHALL proceed as 173 described in [RFC5321] section 5. 175 If any of the responses is "bogus" according to DNSSEC validation 176 ([RFC4033] section 5) the client MUST treat this as a temporary 177 error. 179 For this protocol to take effect, all of these DNS RRsets MUST be 180 "secure" according to DNSSSEC validation. In the case of an implicit 181 MX record, there MUST be a secure denial of existence of an MX RRset 182 for the mail domain. In the case of a (chain of) CNAME RRs, all the 183 CNAMEs MUST be secure as well as their ultimate target. 185 If they are not all secure, this protocol has not been fully 186 deployed. The client SHOULD fall back to insecure delivery (which 187 might be over unauthenticated TLS). 189 The client now has an authentic list of SMTP server host names and 190 priority values. It processes this list as described in [RFC5321] 191 section 5. 193 3.2. SMTP server checks 195 This sub-section applies to each SMTP server host name individually. 197 When connecting to a server, the client SHALL look up its TLSA RRset 198 as described in [I-D.ietf-dane-protocol] section 3. That is, the 199 TLSA RRset owner name SHALL be "_25._tcp.hostname" where "hostname" 200 is the SMTP server host name. The response can be one of the 201 following (as listed in [I-D.ietf-dane-protocol] section 4.1): 203 o A secure answer containing one or more TLSA records, in which case 204 the client SHALL proceed as descrbed below. 206 o A bogus answer, which the client MUST treat as a temporary error. 208 o In the other cases this protocol has not been fully deployed, so 209 client SHOULD deliver to this server insecurely (which might be 210 over unauthenticated TLS). 212 The client now has one or more TLSA records for the server it is 213 connecting to. 215 The client MUST ensure that the server offers the STARTTLS service 216 extension [RFC3207] in its response to the client's EHLO command 217 ([RFC5321] section 4.1.1.1). 219 The client SHALL then issue the STARTTLS command which MUST be 220 successful. It then proceeds with TLS negotiation. 222 The client SHALL validate the server's certificate as described in 223 [I-D.ietf-dane-protocol] section 2.1. 225 The client SHALL verify the server's identity as described in 226 [RFC6125] section 6. Its list of reference identifiers SHOULD 227 include the SMTP server host name with type DNS-ID, and MAY include a 228 second copy of the host name with type CN-ID. 230 If any of these checks fail, the client MUST disconnect from the 231 server and treat this as a temporary failure. 233 The client can now proceed to deliver mail securely. 235 4. Intra-domain SMTP with TLSA 237 Mail transmission within an ADMD can be based on MX records (such as 238 when delivering incoming mail to its destination host) or on 239 statically configured host names (such as when routing outgoing mail 240 via a border relay). 242 When routing internal mail using MX records, Section 3 applies the 243 same as for inter-domain SMTP. 245 When routing mail using host names, the MX lookup step is skipped and 246 only Section 3.2 applies. 248 5. The Transmitted: header field 250 The client MAY wish to insert a Transmitted: header field at the 251 start of the message header just before transmitting the message. 252 This records the result of the checks specified in the previous 253 section. (See Section 7 for some comments on its utility or lack 254 thereof.) It is a client-side counterpart to the Received: header 255 field ([RFC5321] section 4.4) and has very similar syntax. It SHOULD 256 be treated as a trace field. 258 The syntax of the Transmitted: header field is described using ABNF 259 [RFC5234]. Non-terminal syntax rules not defined in this memo are 260 defined in [RFC5321], or [RFC5322], or [RFC5234]. 262 Transmitted-line = "Transmitted:" FWS To-domain By-domain 263 Opt-info [CFWS] ";" date-time CRLF 265 To-domain = "TO" FWS Extended-Domain 266 A SHALL include: 268 o A clause describing the SMTP server. The 269 part of a SHALL be the same as the SMTP server host 270 name. 272 o A clause identifying the SMTP client that added the 273 header. (If the client also acts as a server this is the same 274 clause it would include in any Received: header fields 275 it adds.) This clause helps with recovery if the original order 276 of a message header's fields has been lost. 278 o Various clauses, which MUST include a clause. 279 The part of this clause is used to indicate whether the 280 client successfully authenticated the server, using one of the 281 types specified in Section 6.1. 283 o And a to further help with disordering in case a 284 message is transmitted by the same client more than once. 286 6. IANA Considerations 288 6.1. "with" protocol types 290 The "with" protocol type registry includes a number of keywords that 291 indicate the use of SMTP with or without TLS and/or AUTH [RFC3848]. 292 When these types appear in a Transmitted: header field "with" clause 293 they indicate that the client did not authenticate the server as 294 described in Section 3. 296 o The new keyword "ESMTPT" indicates the use of ESMTP [RFC5321] with 297 STARTTLS [RFC3207] when the client successfully authenticated the 298 server. 300 o The new keyword "ESMTPTA" indicates the use of ESMTP [RFC5321] 301 with STARTTLS [RFC3207] and AUTH [RFC4954] when the client 302 successfully authenticated the server. 304 These new keywords are not for use in Received: header fields since 305 the server cannot tell whether or not the client authenticated it. 307 There are no keywords corresponding to a client trying and failing to 308 authenticate the server, since in this case no message transmission 309 occurs. 311 6.2. Permanent message header field registration 313 Header field name: Transmitted: 315 Applicable protocol: mail 317 Status: standard 319 Change controller: IETF 321 Specification document this memo 323 6.3. "dane" MTA-name-type 325 Delivery status notifications [RFC3464] can include a Remote-MTA 326 field recording an SMTP server host name. When this has been 327 authenticated according to Section 3 the reporting MTA MAY use an 328 MTA-type-name of "dane". 330 a. MTA-type-name: "dane" 332 b. Syntax: same as the "dns" MTA-type-name [RFC3461] 334 c. Translation into US-ASCII: none needed 336 7. Security considerations 338 7.1. Fallback to insecure SMTP 340 This memo provides only conditional security. It allows a server to 341 publish in the DNS the details of how it can be authenticated. 342 Clients that implement this protocol can use it to provide a strong 343 guarantee that they are sending mail to the correct place. If either 344 of these is missing, mail delivery will be insecure. 346 There is no secure way for a server to tell if a client has 347 authenticated it using this protocol. This is a general limitation 348 of TLS. The Transmitted: header field records this information for 349 tracing and debugging and measuring deployment, not for security 350 purposes. 352 We do not specify that clients check that all of a mail domain's SMTP 353 server host names consistently have or do not have TLSA records. 354 This is so that partial or incremental deployment does not break mail 355 delivery. Different levels of deployment are likely if a domain has 356 a third-party backup MX, for example. 358 7.2. A mail domain trusts its SMTP servers 360 By signing their zone with DNSSEC, a mail domain owner implicitly 361 instructs SMTP clients to check their SMTP server TLSA records. This 362 implies another point in the trust relationship between mail domain 363 owner and smtp server operator. Most of the setup requirements for 364 this protocol fall on the SMTP server operator: installing a TLS 365 certificate with the correct name, and publishing a TLSA record under 366 that name. If these are not correct then mail delivery from TLSA- 367 aware clients might be delayed. 369 7.3. Temporary failures and denial of service 371 Many provisioning failures in SMTP cause "permanent" failures, that 372 is the immediate and final rejection of the message. This includes 373 missing DNS records, an SMTP server that is not configured to accept 374 mail for the recipient domain, and so forth. 376 In this protocol, provisioning an incorrect TLS certificate triggers 377 a temporary error. This is because we want to minimise the damage 378 that occurs when an on-path attacker intercepts the TCP connection 379 between an SMTP client and server. An attacker can cause delays, but 380 is not able to trigger immediate delivery failures. 382 7.4. Deliberate omissions 384 We do not specify that clients check the DNSSEC state of the SMTP 385 server address records. This is not necessary since the certificate 386 checks ensure that the client has connected to the correct server. 387 (The address records will normally have the same security state as 388 the TLSA records, but they can differ if there are CNAME or DNAME 389 indirections.) 391 This memo does not specify any changes to SMTP client authentication. 392 Inter-domain SMTP client authentication remains extremely weak. 393 Intra-domain SMTP can be configured as strong as necessary (using 394 SMTP AUTH or TLS client certificates, for instance) but that is out 395 of scope for this memo. 397 8. Acknowledgements 399 Thanks to Mark Andrews for arguing that authenticating the SMTP 400 server host name is the right thing, and that we should rely on 401 DNSSEC to secure the MX lookup. Thanks to Ned Freed, Paul Hoffman, 402 Phil Pennock, Hector Santos, and Alessandro Vesely for helpful 403 suggestions. 405 9. References 407 9.1. Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 413 Transport Layer Security", RFC 3207, February 2002. 415 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 416 Extension for Delivery Status Notifications (DSNs)", 417 RFC 3461, January 2003. 419 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 420 for Delivery Status Notifications", RFC 3464, 421 January 2003. 423 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types 424 Registration", RFC 3848, July 2004. 426 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 427 Rose, "DNS Security Introduction and Requirements", 428 RFC 4033, March 2005. 430 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 431 for Authentication", RFC 4954, July 2007. 433 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 434 Specifications: ABNF", STD 68, RFC 5234, January 2008. 436 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 437 October 2008. 439 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 440 October 2008. 442 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 443 Verification of Domain-Based Application Service Identity 444 within Internet Public Key Infrastructure Using X.509 445 (PKIX) Certificates in the Context of Transport Layer 446 Security (TLS)", RFC 6125, March 2011. 448 [I-D.ietf-dane-protocol] 449 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 450 of Named Entities (DANE) Transport Layer Security (TLS) 451 Protocol: TLSA", draft-ietf-dane-protocol-21 (work in 452 progress), May 2012. 454 9.2. Informative References 456 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 457 October 1996. 459 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 460 RFC 4409, April 2006. 462 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 463 Finch, "Email Submission Operations: Access and 464 Accountability Requirements", BCP 134, RFC 5068, 465 November 2007. 467 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 468 July 2009. 470 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 471 Extension Definitions", RFC 6066, January 2011. 473 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 474 Submission/Access Services", RFC 6186, March 2011. 476 Appendix A. Rationale - choice of certificate identity 478 There are a number of reasons for the certificate to authenticate the 479 SMTP server host name rather than the mail domain. 481 SMTP allows a client to transfer mail to recipients at multiple 482 domains in the same connection. If the certificate identifies the 483 host name then it does not need to list all the possible mail 484 domains. 486 It is not in general feasible for the server to select a mail domain 487 certificate based on the recipient domains when the connection is 488 established (using Server Name Indication, [RFC6066] section 3), 489 because an SMTP client might not know all of the recipients when it 490 establishes the connection. 492 Outgoing SMTP relays and message submission servers handle mail for 493 any domain, so in those cases the only sensible option is for the 494 certificate to contain the host name. It is more consistent for 495 incoming MX server certificates to match. 497 It is common for SMTP servers to act in multiple roles, as outgoing 498 relays or as incoming MX servers, depending on the client identity. 499 It is simpler if the server can present the same certificate 500 regardless of the role in which it is to act. 502 Sometimes the server does not know its role until the client has 503 authenticated, which usually occurs after TLS has been established. 505 This protocol does not provide an option for directly authenticating 506 the mail domain because that would add complexity without providing 507 any benefit, and security protocols are best kept simple. As 508 described above, there are real-world cases where authenticating the 509 mail domain cannot be made to work, so there are complicated criteria 510 for when mail domain TLSA records might be used and when they cannot. 511 This is all avoided by authenticating the SMTP server host name. 513 Finally, this protocol only affects the logic in the SMTP client and 514 requires no additional SMTP server functionality, such as support for 515 the TLS Server Name Indication extension. 517 Appendix B. Change log 519 B.1. Changes in version -02 521 Clarify the wording that describes how a client determines that this 522 protocol is in effect. 524 Divide the security considerations into sub-sections, and add a 525 subsection on denial of service. 527 Clarify intro, mentioning TLSA owner name format. 529 Extend the scope to cover MTA-to-MTA mail within an ADMD as well as 530 between ADMDs. 532 B.2. Changes in version -01 534 More about why not to authenticate mail domains in the rationale. 536 Change DNS-ID requirement from MUST to SHOULD to follow RFC 6125. 538 Acknowledgments section. 540 Transmitted: header trace field. Not sure if this is a good idea; 541 feedback wanted. 543 "dane" MTA-name-type for use in DSNs. Even less sure if this is a 544 good idea. 546 Author's Address 548 Tony Finch 549 University of Cambridge Computing Service 550 New Museums Site 551 Pembroke Street 552 Cambridge CB2 3QH 553 ENGLAND 555 Phone: +44 797 040 1426 556 Email: dot@dotat.at 557 URI: http://dotat.at/