| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | Internet Engineering Task Force (IETF) J. Fenton |
| 6 | Request for Comments: 8689 Altmode Networks |
| 7 | Category: Standards Track November 2019 |
| 8 | ISSN: 2070-1721 |
| 9 | |
| 10 | |
| 11 | SMTP Require TLS Option |
| 12 | |
| 13 | Abstract |
| 14 | |
| 15 | The SMTP STARTTLS option, used in negotiating transport-level |
| 16 | encryption of SMTP connections, is not as useful from a security |
| 17 | standpoint as it might be because of its opportunistic nature; |
| 18 | message delivery is, by default, prioritized over security. This |
| 19 | document describes an SMTP service extension, REQUIRETLS, and a |
| 20 | message header field, TLS-Required. If the REQUIRETLS option or TLS- |
| 21 | Required message header field is used when sending a message, it |
| 22 | asserts a request on the part of the message sender to override the |
| 23 | default negotiation of TLS, either by requiring that TLS be |
| 24 | negotiated when the message is relayed or by requesting that |
| 25 | recipient-side policy mechanisms such as MTA-STS and DNS-Based |
| 26 | Authentication of Named Entities (DANE) be ignored when relaying a |
| 27 | message for which security is unimportant. |
| 28 | |
| 29 | Status of This Memo |
| 30 | |
| 31 | This is an Internet Standards Track document. |
| 32 | |
| 33 | This document is a product of the Internet Engineering Task Force |
| 34 | (IETF). It represents the consensus of the IETF community. It has |
| 35 | received public review and has been approved for publication by the |
| 36 | Internet Engineering Steering Group (IESG). Further information on |
| 37 | Internet Standards is available in Section 2 of RFC 7841. |
| 38 | |
| 39 | Information about the current status of this document, any errata, |
| 40 | and how to provide feedback on it may be obtained at |
| 41 | https://www.rfc-editor.org/info/rfc8689. |
| 42 | |
| 43 | Copyright Notice |
| 44 | |
| 45 | Copyright (c) 2019 IETF Trust and the persons identified as the |
| 46 | document authors. All rights reserved. |
| 47 | |
| 48 | This document is subject to BCP 78 and the IETF Trust's Legal |
| 49 | Provisions Relating to IETF Documents |
| 50 | (https://trustee.ietf.org/license-info) in effect on the date of |
| 51 | publication of this document. Please review these documents |
| 52 | carefully, as they describe your rights and restrictions with respect |
| 53 | to this document. Code Components extracted from this document must |
| 54 | include Simplified BSD License text as described in Section 4.e of |
| 55 | the Trust Legal Provisions and are provided without warranty as |
| 56 | described in the Simplified BSD License. |
| 57 | |
| 58 | Table of Contents |
| 59 | |
| 60 | 1. Introduction |
| 61 | 1.1. Requirements Language |
| 62 | 2. The REQUIRETLS Service Extension |
| 63 | 3. The TLS-Required Header Field |
| 64 | 4. REQUIRETLS Semantics |
| 65 | 4.1. REQUIRETLS Receipt Requirements |
| 66 | 4.2. REQUIRETLS Sender Requirements |
| 67 | 4.2.1. Sending with TLS Required |
| 68 | 4.2.2. Sending with TLS Optional |
| 69 | 4.3. REQUIRETLS Submission |
| 70 | 4.4. Delivery of REQUIRETLS messages |
| 71 | 5. Non-delivery Message Handling |
| 72 | 6. Reorigination Considerations |
| 73 | 7. IANA Considerations |
| 74 | 8. Security Considerations |
| 75 | 8.1. Passive Attacks |
| 76 | 8.2. Active Attacks |
| 77 | 8.3. Bad-Actor MTAs |
| 78 | 8.4. Policy Conflicts |
| 79 | 9. References |
| 80 | 9.1. Normative References |
| 81 | 9.2. Informative References |
| 82 | Appendix A. Examples |
| 83 | A.1. REQUIRETLS SMTP Option |
| 84 | A.2. TLS-Required Header Field |
| 85 | Acknowledgements |
| 86 | Author's Address |
| 87 | |
| 88 | 1. Introduction |
| 89 | |
| 90 | The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a |
| 91 | means by which an SMTP server and client can establish a Transport |
| 92 | Layer Security (TLS) protected session for the transmission of email |
| 93 | messages. By default, TLS is used only upon mutual agreement |
| 94 | (successful negotiation) of STARTTLS between the client and server; |
| 95 | if this is not possible, the message is sent without transport |
| 96 | encryption. Furthermore, it is common practice for the client to |
| 97 | negotiate TLS even if the SMTP server's certificate is invalid. |
| 98 | |
| 99 | Policy mechanisms such as DANE [RFC7672] and MTA-STS [RFC8461] may |
| 100 | impose requirements for the use of TLS for email destined for some |
| 101 | domains. However, such policies do not allow the sender to specify |
| 102 | which messages are more sensitive and require transport-level |
| 103 | encryption and which ones are less sensitive and ought to be relayed |
| 104 | even if TLS cannot be negotiated successfully. |
| 105 | |
| 106 | The default opportunistic nature of SMTP TLS enables several on-the- |
| 107 | wire attacks on SMTP security between MTAs. These include passive |
| 108 | eavesdropping on connections for which TLS is not used, interference |
| 109 | in the SMTP protocol to prevent TLS from being negotiated (presumably |
| 110 | accompanied by eavesdropping), and insertion of a man-in-the-middle |
| 111 | attacker exploiting the lack of server authentication by the client. |
| 112 | Attacks are described in more detail in the Security Considerations |
| 113 | section of this document. |
| 114 | |
| 115 | REQUIRETLS consists of two mechanisms: an SMTP service extension and |
| 116 | a message header field. The service extension is used to specify |
| 117 | that a given message sent during a particular session MUST be sent |
| 118 | over a TLS-protected session with specified security characteristics. |
| 119 | It also requires that the SMTP server advertise that it supports |
| 120 | REQUIRETLS, in effect promising that it will honor the requirement to |
| 121 | enforce TLS transmission and REQUIRETLS support for onward |
| 122 | transmission of those messages. |
| 123 | |
| 124 | The TLS-Required message header field is used to convey a request to |
| 125 | ignore recipient-side policy mechanisms such as MTA-STS and DANE, |
| 126 | thereby prioritizing delivery over ability to negotiate TLS. Unlike |
| 127 | the service extension, the TLS-Required header field allows the |
| 128 | message to transit through one or more MTAs that do not support |
| 129 | REQUIRETLS. |
| 130 | |
| 131 | 1.1. Requirements Language |
| 132 | |
| 133 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| 134 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and |
| 135 | "OPTIONAL" in this document are to be interpreted as described in |
| 136 | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all |
| 137 | capitals, as shown here. |
| 138 | |
| 139 | The formal syntax uses the Augmented Backus-Naur Form (ABNF) |
| 140 | [RFC5234], including the core rules defined in Appendix B of that |
| 141 | document. |
| 142 | |
| 143 | 2. The REQUIRETLS Service Extension |
| 144 | |
| 145 | The REQUIRETLS SMTP service extension has the following |
| 146 | characteristics: |
| 147 | |
| 148 | 1. The textual name of the extension is "Require TLS". |
| 149 | |
| 150 | 2. The EHLO keyword value associated with this extension is |
| 151 | "REQUIRETLS". |
| 152 | |
| 153 | 3. No additional SMTP verbs are defined by this extension. |
| 154 | |
| 155 | 4. One optional parameter ("REQUIRETLS") is added to the MAIL FROM |
| 156 | command by this extension. No value is associated with this |
| 157 | parameter. |
| 158 | |
| 159 | 5. The maximum length of a MAIL FROM command line is increased by 11 |
| 160 | octets by the possible addition of a space and the REQUIRETLS |
| 161 | keyword. |
| 162 | |
| 163 | 6. One new SMTP status code is defined by this extension to convey |
| 164 | an error condition resulting from failure of the client to send |
| 165 | data to a server that does not also support the REQUIRETLS |
| 166 | extension. |
| 167 | |
| 168 | 7. The REQUIRETLS extension is valid for message relay [RFC5321], |
| 169 | submission [RFC6409], and the Local Mail Transfer Protocol (LMTP) |
| 170 | [RFC2033]. |
| 171 | |
| 172 | 8. The ABNF syntax for the MAIL FROM parameter is as follows: |
| 173 | |
| 174 | requiretls-param = "REQUIRETLS" |
| 175 | ; where requiretls-param is an instance of an |
| 176 | ; esmtp-param used in Mail-parameters in |
| 177 | ; RFC 5321, Section 4.1.2. There is no esmtp-value |
| 178 | ; associated with requiretls-param. |
| 179 | |
| 180 | In order to specify REQUIRETLS treatment for a given message, the |
| 181 | REQUIRETLS option is specified in the MAIL FROM command when that |
| 182 | message is transmitted. This option MUST only be specified in the |
| 183 | context of an SMTP session meeting the security requirements of |
| 184 | REQUIRETLS: |
| 185 | |
| 186 | * The session itself MUST employ TLS transmission. |
| 187 | |
| 188 | * If the SMTP server to which the message is being transmitted is |
| 189 | identified through an MX record lookup, its name MUST be validated |
| 190 | via a DNSSEC signature on the recipient domain's MX record, or the |
| 191 | MX hostname MUST be validated by an MTA-STS policy as described in |
| 192 | Section 4.1 of [RFC8461]. DNSSEC is defined in [RFC4033], |
| 193 | [RFC4034], and [RFC4035]. |
| 194 | |
| 195 | * The certificate presented by the SMTP server either MUST be |
| 196 | verified successfully by a trust chain leading to a certificate |
| 197 | trusted by the SMTP client, or it MUST be verified successfully |
| 198 | using DANE, as specified in [RFC7672]. For trust chains, the |
| 199 | choice of trusted (root) certificates is at the discretion of the |
| 200 | SMTP client. |
| 201 | |
| 202 | * Following the negotiation of STARTTLS, the SMTP server MUST |
| 203 | advertise in the subsequent EHLO response that it supports |
| 204 | REQUIRETLS. |
| 205 | |
| 206 | 3. The TLS-Required Header Field |
| 207 | |
| 208 | One new message header field [RFC5322], TLS-Required, is defined by |
| 209 | this specification. It is used for messages for which the originator |
| 210 | requests that the recipient TLS policy (including MTA-STS [RFC8461] |
| 211 | and DANE [RFC7672]) be ignored. This might be done, for example, to |
| 212 | report a misconfigured mail server, such as an expired TLS |
| 213 | certificate. |
| 214 | |
| 215 | The TLS-Required header field has a single REQUIRED parameter: |
| 216 | |
| 217 | * No - The SMTP client SHOULD attempt to send the message regardless |
| 218 | of its ability to negotiate STARTTLS with the SMTP server, |
| 219 | ignoring policy-based mechanisms (including MTA-STS and DANE), if |
| 220 | any, asserted by the recipient domain. Nevertheless, the client |
| 221 | SHOULD negotiate STARTTLS with the server if available. |
| 222 | |
| 223 | More than one instance of the TLS-Required header field MUST NOT |
| 224 | appear in a given message. |
| 225 | |
| 226 | The ABNF syntax for the TLS-Required header field is as follows: |
| 227 | |
| 228 | requiretls-field = "TLS-Required:" [FWS] "No" CRLF |
| 229 | ; where requiretls-field in an instance of an |
| 230 | ; optional-field defined in RFC 5322, Section 3.6.8. |
| 231 | FWS = <as defined in RFC 5322> |
| 232 | CRLF = <as defined in RFC 5234> |
| 233 | |
| 234 | 4. REQUIRETLS Semantics |
| 235 | |
| 236 | 4.1. REQUIRETLS Receipt Requirements |
| 237 | |
| 238 | Upon receipt of the REQUIRETLS option on a MAIL FROM command during |
| 239 | the receipt of a message, an SMTP server MUST tag that message as |
| 240 | needing REQUIRETLS handling. |
| 241 | |
| 242 | Upon receipt of a message not specifying the REQUIRETLS option on its |
| 243 | MAIL FROM command but containing the TLS-Required header field in its |
| 244 | message header, an SMTP server implementing this specification MUST |
| 245 | tag that message with the option specified in the TLS-Required header |
| 246 | field. If the REQUIRETLS MAIL FROM parameter is specified, the TLS- |
| 247 | Required header field MUST be ignored but MAY be included in the |
| 248 | onward relay of the message. |
| 249 | |
| 250 | The manner in which the above tagging takes place is implementation |
| 251 | dependent. If the message is being locally aliased and redistributed |
| 252 | to multiple addresses, all instances of the message MUST be tagged in |
| 253 | the same manner. |
| 254 | |
| 255 | 4.2. REQUIRETLS Sender Requirements |
| 256 | |
| 257 | 4.2.1. Sending with TLS Required |
| 258 | |
| 259 | When sending a message tagged as requiring TLS for which the MAIL |
| 260 | FROM return-path is not empty (an empty MAIL FROM return-path |
| 261 | indicating a bounce message), the sending (client) MTA MUST: |
| 262 | |
| 263 | 1. Look up the SMTP server to which the message is to be sent, as |
| 264 | described in [RFC5321], Section 5.1. |
| 265 | |
| 266 | 2. If the server lookup is accomplished via the recipient domain's |
| 267 | MX record (the usual case) and is not accompanied by a valid |
| 268 | DNSSEC signature, the client MUST also validate the SMTP server |
| 269 | name using MTA-STS, as described in [RFC8461], Section 4.1. |
| 270 | |
| 271 | 3. Open an SMTP session with the peer SMTP server using the EHLO |
| 272 | verb. |
| 273 | |
| 274 | 4. Establish a TLS-protected SMTP session with its peer SMTP server |
| 275 | and authenticate the server's certificate as specified in |
| 276 | [RFC6125] or [RFC7672], as applicable. The hostname from the MX |
| 277 | record lookup (or the domain name in the absence of an MX record |
| 278 | where an A record is used directly) MUST match the DNS-ID or CN- |
| 279 | ID of the certificate presented by the server. |
| 280 | |
| 281 | 5. Ensure that the response to the subsequent EHLO following |
| 282 | establishment of the TLS protection advertises the REQUIRETLS |
| 283 | capability. |
| 284 | |
| 285 | The SMTP client SHOULD follow the recommendations in [RFC7525] or its |
| 286 | successor with respect to negotiation of the TLS session. |
| 287 | |
| 288 | If any of the above steps fail, the client MUST issue a QUIT to the |
| 289 | server and repeat steps 2-5 with each host on the recipient domain's |
| 290 | list of MX hosts in an attempt to find a mail path that meets the |
| 291 | sender's requirements. The client MAY send other, unprotected |
| 292 | messages to that server if it has any such messages prior to issuing |
| 293 | the QUIT. If there are no more MX hosts, the client MUST NOT |
| 294 | transmit the message to the domain. |
| 295 | |
| 296 | Following such a failure, the SMTP client MUST send a non-delivery |
| 297 | notification to the reverse-path of the failed message, as described |
| 298 | in Section 3.6 of [RFC5321]. The following status codes [RFC5248] |
| 299 | SHOULD be used: |
| 300 | |
| 301 | * REQUIRETLS not supported by server: 5.7.30 REQUIRETLS support |
| 302 | required |
| 303 | |
| 304 | * Unable to establish TLS-protected SMTP session: 5.7.10 Encryption |
| 305 | needed |
| 306 | |
| 307 | Refer to Section 5 for further requirements regarding non-delivery |
| 308 | messages. |
| 309 | |
| 310 | If all REQUIRETLS requirements have been met, transmit the message, |
| 311 | issuing the REQUIRETLS option on the MAIL FROM command with the |
| 312 | required option(s), if any. |
| 313 | |
| 314 | 4.2.2. Sending with TLS Optional |
| 315 | |
| 316 | Messages tagged "TLS-Required: No" are handled as follows. When |
| 317 | sending such a message, the sending (client) MTA MUST: |
| 318 | |
| 319 | * Look up the SMTP server to which the message is to be sent, as |
| 320 | described in [RFC5321], Section 5.1. |
| 321 | |
| 322 | * Open an SMTP session with the peer SMTP server using the EHLO |
| 323 | verb. Attempt to negotiate STARTTLS if possible, and follow any |
| 324 | policy published by the recipient domain, but do not fail if this |
| 325 | is unsuccessful. |
| 326 | |
| 327 | Some SMTP servers may be configured to require STARTTLS connections |
| 328 | as a matter of policy and not accept messages in the absence of |
| 329 | STARTTLS. A non-delivery notification MUST be returned to the sender |
| 330 | if message relay fails due to an inability to negotiate STARTTLS when |
| 331 | required by the server. |
| 332 | |
| 333 | Since messages tagged with "TLS-Required: No" will sometimes be sent |
| 334 | to SMTP servers not supporting REQUIRETLS, that option will not be |
| 335 | uniformly observed by all SMTP relay hops. |
| 336 | |
| 337 | 4.3. REQUIRETLS Submission |
| 338 | |
| 339 | A Mail User Agent (MUA) or other agent making the initial |
| 340 | introduction of a message has the option to decide whether to require |
| 341 | TLS. If TLS is to be required, it MUST do so by negotiating STARTTLS |
| 342 | and REQUIRETLS and including the REQUIRETLS option on the MAIL FROM |
| 343 | command, as is done for message relay. |
| 344 | |
| 345 | When TLS is not to be required, the sender MUST include the TLS- |
| 346 | Required header field in the message. SMTP servers implementing this |
| 347 | specification MUST interpret this header field as described in |
| 348 | Section 4.1. |
| 349 | |
| 350 | In either case, the decision whether to specify REQUIRETLS MAY be |
| 351 | done based on a user interface selection or based on a ruleset or |
| 352 | other policy. The manner in which the decision to require TLS is |
| 353 | made is implementation dependent and is beyond the scope of this |
| 354 | specification. |
| 355 | |
| 356 | 4.4. Delivery of REQUIRETLS messages |
| 357 | |
| 358 | Messages are usually retrieved by end users using protocols other |
| 359 | than SMTP such as IMAP [RFC3501], POP [RFC1939], or Web mail systems. |
| 360 | Mail delivery agents supporting the REQUIRETLS SMTP option SHOULD |
| 361 | observe the guidelines in [RFC8314]. |
| 362 | |
| 363 | 5. Non-delivery Message Handling |
| 364 | |
| 365 | Non-delivery ("bounce") messages usually contain important metadata |
| 366 | about the message to which they refer, including the original message |
| 367 | header. They therefore MUST be protected in the same manner as the |
| 368 | original message. All non-delivery messages resulting from messages |
| 369 | with the REQUIRETLS SMTP option, whether resulting from a REQUIRETLS |
| 370 | error or some other issue, MUST also specify the REQUIRETLS SMTP |
| 371 | option unless redacted as described below. |
| 372 | |
| 373 | The path from the origination of an error bounce message back to the |
| 374 | MAIL FROM address may not share the same REQUIRETLS support as the |
| 375 | forward path. Therefore, users requiring TLS are advised to make |
| 376 | sure that they are capable of receiving mail using REQUIRETLS as |
| 377 | well. Otherwise, such non-delivery messages will be lost. |
| 378 | |
| 379 | If a REQUIRETLS message is bounced, the server MUST behave as if |
| 380 | RET=HDRS was present, as described in [RFC3461]. If both RET=FULL |
| 381 | and REQUIRETLS are present, the RET=FULL MUST be disregarded. The |
| 382 | SMTP client for a REQUIRETLS bounce message uses an empty MAIL FROM |
| 383 | return-path, as required by [RFC5321]. When the MAIL FROM return- |
| 384 | path is empty, the REQUIRETLS parameter SHOULD NOT cause a bounce |
| 385 | message to be discarded even if the next-hop relay does not advertise |
| 386 | REQUIRETLS. |
| 387 | |
| 388 | Senders of messages requiring TLS are advised to consider the |
| 389 | possibility that bounce messages will be lost as a result of |
| 390 | REQUIRETLS return path failure and that some information could be |
| 391 | leaked if a bounce message is not able to be transmitted with |
| 392 | REQUIRETLS. |
| 393 | |
| 394 | 6. Reorigination Considerations |
| 395 | |
| 396 | In a number of situations, a mediator [RFC5598] originates a new |
| 397 | message as a result of an incoming message. These situations include |
| 398 | but are not limited to mailing lists (including administrative |
| 399 | traffic such as message approval requests), Sieve [RFC5228], |
| 400 | "vacation" responders, and other filters to which incoming messages |
| 401 | may be piped. These newly originated messages may essentially be |
| 402 | copies of the incoming message, such as with a forwarding service or |
| 403 | a mailing list expander. In other cases, such as with a vacation |
| 404 | message or a delivery notification, they will be different but might |
| 405 | contain parts of the original message or other information for which |
| 406 | the original message sender wants to influence the requirement to use |
| 407 | TLS transmission. |
| 408 | |
| 409 | Mediators that reoriginate messages should apply REQUIRETLS |
| 410 | requirements in incoming messages (both requiring TLS transmission |
| 411 | and requesting that TLS not be required) to the reoriginated messages |
| 412 | to the extent feasible. A limitation to this might be that for a |
| 413 | message requiring TLS, redistribution to multiple addresses while |
| 414 | retaining the TLS requirement could result in the message not being |
| 415 | delivered to some of the intended recipients. |
| 416 | |
| 417 | User-side mediators (such as use of Sieve rules on a user agent) |
| 418 | typically do not have access to the SMTP details and therefore may |
| 419 | not be aware of the REQUIRETLS requirement on a delivered message. |
| 420 | Recipients that expect sensitive traffic should avoid the use of |
| 421 | user-side mediators. Alternatively, if operationally feasible (such |
| 422 | as when forwarding to a specific, known address), they should apply |
| 423 | REQUIRETLS to all reoriginated messages that do not contain the "TLS- |
| 424 | Required: No" header field. |
| 425 | |
| 426 | 7. IANA Considerations |
| 427 | |
| 428 | Per this document, IANA has added the following keyword to the "SMTP |
| 429 | Service Extensions" subregistry of the "Mail Parameters" registry |
| 430 | [MailParams]: |
| 431 | |
| 432 | EHLO Keyword: REQUIRETLS |
| 433 | Description: Require TLS |
| 434 | Syntax and parameters: (no parameters) |
| 435 | Additional SMTP verbs: none |
| 436 | MAIL and RCPT parameters: REQUIRETLS parameter on MAIL |
| 437 | Behavior: Use of the REQUIRETLS parameter on |
| 438 | the MAIL verb causes that message to |
| 439 | require the use of TLS and tagging |
| 440 | with REQUIRETLS for all onward |
| 441 | relay. |
| 442 | Command length increment: 11 characters |
| 443 | |
| 444 | Per this document, IANA has added an entry to the "Enumerated Status |
| 445 | Codes" subregistry of the "Simple Mail Transfer Protocol (SMTP) |
| 446 | Enhanced Status Codes Registry" [SMTPStatusCodes]: |
| 447 | |
| 448 | Code: X.7.30 |
| 449 | Sample Text: REQUIRETLS support required |
| 450 | Associated basic status code: 550 |
| 451 | Description: This indicates that the message was |
| 452 | not able to be forwarded because it |
| 453 | was received with a REQUIRETLS |
| 454 | requirement and none of the SMTP |
| 455 | servers to which the message should |
| 456 | be forwarded provide this support. |
| 457 | Reference: RFC 8689 |
| 458 | Submitter: J. Fenton |
| 459 | Change Controller: IESG |
| 460 | |
| 461 | Per this document, IANA has added an entry to the "Permanent Message |
| 462 | Header Field Names" subregistry of the "Message Headers" registry |
| 463 | [MessageHeaders] as follows: |
| 464 | |
| 465 | Header field name: TLS-Required |
| 466 | Applicable protocol: mail |
| 467 | Status: standard |
| 468 | Author/change controller: IETF |
| 469 | Specification document: RFC 8689 |
| 470 | |
| 471 | 8. Security Considerations |
| 472 | |
| 473 | The purpose of REQUIRETLS is to give the originator of a message |
| 474 | control over the security of email they send, either by conveying an |
| 475 | expectation that it will be transmitted in an encrypted form over the |
| 476 | wire or explicitly indicating that transport encryption is not |
| 477 | required if it cannot be successfully negotiated. |
| 478 | |
| 479 | The following considerations apply to the REQUIRETLS service |
| 480 | extension but not the TLS-Required header field, since messages |
| 481 | specifying the header field are less concerned with transport |
| 482 | security. |
| 483 | |
| 484 | 8.1. Passive Attacks |
| 485 | |
| 486 | REQUIRETLS is generally effective against passive attackers who are |
| 487 | merely trying to eavesdrop on an SMTP exchange between an SMTP client |
| 488 | and server. This assumes, of course, the cryptographic integrity of |
| 489 | the TLS connection being used. |
| 490 | |
| 491 | 8.2. Active Attacks |
| 492 | |
| 493 | Active attacks against TLS-encrypted SMTP connections can take many |
| 494 | forms. One such attack is to interfere in the negotiation by |
| 495 | changing the STARTTLS command to something illegal such as XXXXXXXX. |
| 496 | This causes TLS negotiation to fail and messages to be sent in the |
| 497 | clear, where they can be intercepted. REQUIRETLS detects the failure |
| 498 | of STARTTLS and declines to send the message rather than send it |
| 499 | insecurely. |
| 500 | |
| 501 | A second form of attack is a man-in-the-middle attack where the |
| 502 | attacker terminates the TLS connection rather than the intended SMTP |
| 503 | server. This is possible when, as is commonly the case, the SMTP |
| 504 | client either does not verify the server's certificate or establishes |
| 505 | the connection even when the verification fails. REQUIRETLS requires |
| 506 | successful certificate validation before sending the message. |
| 507 | |
| 508 | Another active attack involves the spoofing of DNS MX records of the |
| 509 | recipient domain. An attacker with this capability could potentially |
| 510 | cause the message to be redirected to a mail server under the |
| 511 | attacker's own control, which would presumably have a valid |
| 512 | certificate. REQUIRETLS requires that the recipient domain's MX |
| 513 | record lookup be validated either using DNSSEC or via a published |
| 514 | MTA-STS policy that specifies the acceptable SMTP server hostname(s) |
| 515 | for the recipient domain. |
| 516 | |
| 517 | 8.3. Bad-Actor MTAs |
| 518 | |
| 519 | A bad-actor MTA along the message transmission path could |
| 520 | misrepresent its support of REQUIRETLS and/or actively strip |
| 521 | REQUIRETLS tags from messages it handles. However, since |
| 522 | intermediate MTAs are already trusted with the cleartext of messages |
| 523 | they handle, and are not part of the threat model for transport-layer |
| 524 | security, they are also not part of the threat model for REQUIRETLS. |
| 525 | |
| 526 | It should be reemphasized that since SMTP TLS is a transport-layer |
| 527 | security protocol, messages sent using REQUIRETLS are not encrypted |
| 528 | end-to-end and are visible to MTAs that are part of the message |
| 529 | delivery path. Messages containing sensitive information that MTAs |
| 530 | should not have access to MUST be sent using end-to-end content |
| 531 | encryption such as OpenPGP [RFC4880] or S/MIME [RFC8551]. |
| 532 | |
| 533 | 8.4. Policy Conflicts |
| 534 | |
| 535 | In some cases, the use of the TLS-Required header field may conflict |
| 536 | with a recipient domain policy expressed through the DANE [RFC7672] |
| 537 | or MTA-STS [RFC8461] protocols. Although these protocols encourage |
| 538 | the use of TLS transport by advertising the availability of TLS, the |
| 539 | use of the "TLS-Required: No" header field represents an explicit |
| 540 | decision on the part of the sender not to require the use of TLS, |
| 541 | such as to overcome a configuration error. The recipient domain has |
| 542 | the ultimate ability to require TLS by not accepting messages when |
| 543 | STARTTLS has not been negotiated; otherwise, "TLS-Required: No" is |
| 544 | effectively directing the client MTA to behave as if it does not |
| 545 | support DANE or MTA-STS. |
| 546 | |
| 547 | 9. References |
| 548 | |
| 549 | 9.1. Normative References |
| 550 | |
| 551 | [MailParams] |
| 552 | IANA, "Mail Parameters", |
| 553 | <http://www.iana.org/assignments/mail-parameters>. |
| 554 | |
| 555 | [MessageHeaders] |
| 556 | IANA, "Permanent Message Header Field Names", |
| 557 | <https://www.iana.org/assignments/message-headers>. |
| 558 | |
| 559 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| 560 | Requirement Levels", BCP 14, RFC 2119, |
| 561 | DOI 10.17487/RFC2119, March 1997, |
| 562 | <https://www.rfc-editor.org/info/rfc2119>. |
| 563 | |
| 564 | [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over |
| 565 | Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, |
| 566 | February 2002, <https://www.rfc-editor.org/info/rfc3207>. |
| 567 | |
| 568 | [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service |
| 569 | Extension for Delivery Status Notifications (DSNs)", |
| 570 | RFC 3461, DOI 10.17487/RFC3461, January 2003, |
| 571 | <https://www.rfc-editor.org/info/rfc3461>. |
| 572 | |
| 573 | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
| 574 | Rose, "DNS Security Introduction and Requirements", |
| 575 | RFC 4033, DOI 10.17487/RFC4033, March 2005, |
| 576 | <https://www.rfc-editor.org/info/rfc4033>. |
| 577 | |
| 578 | [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
| 579 | Rose, "Resource Records for the DNS Security Extensions", |
| 580 | RFC 4034, DOI 10.17487/RFC4034, March 2005, |
| 581 | <https://www.rfc-editor.org/info/rfc4034>. |
| 582 | |
| 583 | [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. |
| 584 | Rose, "Protocol Modifications for the DNS Security |
| 585 | Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, |
| 586 | <https://www.rfc-editor.org/info/rfc4035>. |
| 587 | |
| 588 | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| 589 | Specifications: ABNF", STD 68, RFC 5234, |
| 590 | DOI 10.17487/RFC5234, January 2008, |
| 591 | <https://www.rfc-editor.org/info/rfc5234>. |
| 592 | |
| 593 | [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced |
| 594 | Mail System Status Codes", BCP 138, RFC 5248, |
| 595 | DOI 10.17487/RFC5248, June 2008, |
| 596 | <https://www.rfc-editor.org/info/rfc5248>. |
| 597 | |
| 598 | [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, |
| 599 | DOI 10.17487/RFC5321, October 2008, |
| 600 | <https://www.rfc-editor.org/info/rfc5321>. |
| 601 | |
| 602 | [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, |
| 603 | DOI 10.17487/RFC5322, October 2008, |
| 604 | <https://www.rfc-editor.org/info/rfc5322>. |
| 605 | |
| 606 | [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and |
| 607 | Verification of Domain-Based Application Service Identity |
| 608 | within Internet Public Key Infrastructure Using X.509 |
| 609 | (PKIX) Certificates in the Context of Transport Layer |
| 610 | Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March |
| 611 | 2011, <https://www.rfc-editor.org/info/rfc6125>. |
| 612 | |
| 613 | [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, |
| 614 | "Recommendations for Secure Use of Transport Layer |
| 615 | Security (TLS) and Datagram Transport Layer Security |
| 616 | (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May |
| 617 | 2015, <https://www.rfc-editor.org/info/rfc7525>. |
| 618 | |
| 619 | [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via |
| 620 | Opportunistic DNS-Based Authentication of Named Entities |
| 621 | (DANE) Transport Layer Security (TLS)", RFC 7672, |
| 622 | DOI 10.17487/RFC7672, October 2015, |
| 623 | <https://www.rfc-editor.org/info/rfc7672>. |
| 624 | |
| 625 | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC |
| 626 | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, |
| 627 | May 2017, <https://www.rfc-editor.org/info/rfc8174>. |
| 628 | |
| 629 | [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: |
| 630 | Use of Transport Layer Security (TLS) for Email Submission |
| 631 | and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, |
| 632 | <https://www.rfc-editor.org/info/rfc8314>. |
| 633 | |
| 634 | [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., |
| 635 | and J. Jones, "SMTP MTA Strict Transport Security (MTA- |
| 636 | STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, |
| 637 | <https://www.rfc-editor.org/info/rfc8461>. |
| 638 | |
| 639 | [SMTPStatusCodes] |
| 640 | IANA, "Simple Mail Transfer Protocol (SMTP) Enhanced |
| 641 | Status Codes Registry", <https://www.iana.org/assignments/ |
| 642 | smtp-enhanced-status-codes>. |
| 643 | |
| 644 | 9.2. Informative References |
| 645 | |
| 646 | [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", |
| 647 | STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, |
| 648 | <https://www.rfc-editor.org/info/rfc1939>. |
| 649 | |
| 650 | [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, |
| 651 | DOI 10.17487/RFC2033, October 1996, |
| 652 | <https://www.rfc-editor.org/info/rfc2033>. |
| 653 | |
| 654 | [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION |
| 655 | 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, |
| 656 | <https://www.rfc-editor.org/info/rfc3501>. |
| 657 | |
| 658 | [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. |
| 659 | Thayer, "OpenPGP Message Format", RFC 4880, |
| 660 | DOI 10.17487/RFC4880, November 2007, |
| 661 | <https://www.rfc-editor.org/info/rfc4880>. |
| 662 | |
| 663 | [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email |
| 664 | Filtering Language", RFC 5228, DOI 10.17487/RFC5228, |
| 665 | January 2008, <https://www.rfc-editor.org/info/rfc5228>. |
| 666 | |
| 667 | [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, |
| 668 | DOI 10.17487/RFC5598, July 2009, |
| 669 | <https://www.rfc-editor.org/info/rfc5598>. |
| 670 | |
| 671 | [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", |
| 672 | STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, |
| 673 | <https://www.rfc-editor.org/info/rfc6409>. |
| 674 | |
| 675 | [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ |
| 676 | Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 |
| 677 | Message Specification", RFC 8551, DOI 10.17487/RFC8551, |
| 678 | April 2019, <https://www.rfc-editor.org/info/rfc8551>. |
| 679 | |
| 680 | Appendix A. Examples |
| 681 | |
| 682 | This section is informative. |
| 683 | |
| 684 | A.1. REQUIRETLS SMTP Option |
| 685 | |
| 686 | The TLS-Required SMTP option is used to express the intention of the |
| 687 | sender to have the associated message relayed using TLS. In the |
| 688 | following example, lines beginning with "C:" are transmitted from the |
| 689 | SMTP client to the server, and lines beginning with "S:" are |
| 690 | transmitted in the opposite direction. |
| 691 | |
| 692 | S: 220 mail.example.net ESMTP |
| 693 | C: EHLO mail.example.org |
| 694 | S: 250-mail.example.net Hello example.org [192.0.2.1] |
| 695 | S: 250-SIZE 52428800 |
| 696 | S: 250-8BITMIME |
| 697 | S: 250-PIPELINING |
| 698 | S: 250-STARTTLS |
| 699 | S: 250 HELP |
| 700 | C: STARTTLS |
| 701 | S: TLS go ahead |
| 702 | |
| 703 | (at this point TLS negotiation takes place. The remainder of this |
| 704 | session occurs within TLS.) |
| 705 | |
| 706 | S: 220 mail.example.net ESMTP |
| 707 | C: EHLO mail.example.org |
| 708 | S: 250-mail.example.net Hello example.org [192.0.2.1] |
| 709 | S: 250-SIZE 52428800 |
| 710 | S: 250-8BITMIME |
| 711 | S: 250-PIPELINING |
| 712 | S: 250-REQUIRETLS |
| 713 | S: 250 HELP |
| 714 | C: MAIL FROM:<roger@example.org> REQUIRETLS |
| 715 | S: 250 OK |
| 716 | C: RCPT TO:<editor@example.net> |
| 717 | S: 250 Accepted |
| 718 | C: DATA |
| 719 | S: 354 Enter message, ending with "." on a line by itself |
| 720 | |
| 721 | (message follows) |
| 722 | |
| 723 | C: . |
| 724 | S: 250 OK |
| 725 | C: QUIT |
| 726 | |
| 727 | A.2. TLS-Required Header Field |
| 728 | |
| 729 | The TLS-Required header field is used when the sender requests that |
| 730 | the mail system not heed a default policy of the recipient domain |
| 731 | requiring TLS. It might be used, for example, to allow problems with |
| 732 | the recipient domain's TLS certificate to be reported: |
| 733 | |
| 734 | From: Roger Reporter <roger@example.org> |
| 735 | To: Andy Admin <admin@example.com> |
| 736 | Subject: Certificate problem? |
| 737 | TLS-Required: No |
| 738 | Date: Fri, 18 Jan 2019 10:26:55 -0800 |
| 739 | Message-ID: <5c421a6f79c0e_d153ff8286d45c468473@mail.example.org> |
| 740 | |
| 741 | Andy, there seems to be a problem with the TLS certificate |
| 742 | on your mail server. Are you aware of this? |
| 743 | |
| 744 | Roger |
| 745 | |
| 746 | Acknowledgements |
| 747 | |
| 748 | The author would like to acknowledge many helpful suggestions on the |
| 749 | ietf-smtp and uta mailing lists, in particular those of Viktor |
| 750 | Dukhovni, Tony Finch, Jeremy Harris, Arvel Hathcock, John Klensin, |
| 751 | Barry Leiba, John Levine, Chris Newman, Rolf Sonneveld, and Per |
| 752 | Thorsheim. |
| 753 | |
| 754 | Author's Address |
| 755 | |
| 756 | Jim Fenton |
| 757 | Altmode Networks |
| 758 | Los Altos, California 94024 |
| 759 | United States of America |
| 760 | |
| 761 | Email: fenton@bluepopcorn.net |