draft-ietf-uta-smtp-require-tls-06.txt | draft-ietf-uta-smtp-require-tls-07.txt | |||
---|---|---|---|---|
Internet Engineering Task Force J. Fenton | Internet Engineering Task Force J. Fenton | |||
Internet-Draft Altmode Networks | Internet-Draft Altmode Networks | |||
Intended status: Standards Track December 4, 2018 | Intended status: Standards Track January 22, 2019 | |||
Expires: June 7, 2019 | Expires: July 26, 2019 | |||
SMTP Require TLS Option | SMTP Require TLS Option | |||
draft-ietf-uta-smtp-require-tls-06 | draft-ietf-uta-smtp-require-tls-07 | |||
Abstract | Abstract | |||
The SMTP STARTTLS option, used in negotiating transport-level | The SMTP STARTTLS option, used in negotiating transport-level | |||
encryption of SMTP connections, is not as useful from a security | encryption of SMTP connections, is not as useful from a security | |||
standpoint as it might be because of its opportunistic nature; | standpoint as it might be because of its opportunistic nature; | |||
message delivery is, by default, prioritized over security. This | message delivery is, by default, prioritized over security. This | |||
document describes an SMTP service extension, REQUIRETLS, and message | document describes an SMTP service extension, REQUIRETLS, and message | |||
header field, RequireTLS. If the REQUIRETLS option or RequireTLS | header field, RequireTLS. If the REQUIRETLS option or RequireTLS | |||
message header field is used when sending a message, it asserts a | message header field is used when sending a message, it asserts a | |||
skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on June 7, 2019. | This Internet-Draft will expire on July 26, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
2. The REQUIRETLS Service Extension . . . . . . . . . . . . . . 4 | 2. The REQUIRETLS Service Extension . . . . . . . . . . . . . . 4 | |||
3. The RequireTLS Header Field . . . . . . . . . . . . . . . . . 4 | 3. The RequireTLS Header Field . . . . . . . . . . . . . . . . . 5 | |||
4. REQUIRETLS Semantics . . . . . . . . . . . . . . . . . . . . 5 | 4. REQUIRETLS Semantics . . . . . . . . . . . . . . . . . . . . 6 | |||
4.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 5 | 4.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 6 | |||
4.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 5 | 4.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 6 | |||
4.2.1. Sending with TLS Required . . . . . . . . . . . . . . 5 | 4.2.1. Sending with TLS Required . . . . . . . . . . . . . . 6 | |||
4.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 6 | 4.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 7 | |||
4.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 7 | 4.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 8 | |||
4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 7 | 4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 8 | |||
5. Non-delivery message handling . . . . . . . . . . . . . . . . 7 | 5. Non-delivery message handling . . . . . . . . . . . . . . . . 8 | |||
6. Mailing list considerations . . . . . . . . . . . . . . . . . 8 | 6. Mailing list considerations . . . . . . . . . . . . . . . . . 9 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 10 | 8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 11 | |||
8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 10 | 8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 11 | |||
8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 10 | 8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 11 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | |||
10. Revision History . . . . . . . . . . . . . . . . . . . . . . 11 | 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 12 | |||
10.1. Changes since -05 Draft . . . . . . . . . . . . . . . . 11 | 10.1. Changes since -06 Draft . . . . . . . . . . . . . . . . 12 | |||
10.2. Changes since -04 Draft . . . . . . . . . . . . . . . . 11 | 10.2. Changes since -05 Draft . . . . . . . . . . . . . . . . 12 | |||
10.3. Changes since -03 Draft . . . . . . . . . . . . . . . . 11 | 10.3. Changes since -04 Draft . . . . . . . . . . . . . . . . 12 | |||
10.4. Changes since -02 Draft . . . . . . . . . . . . . . . . 11 | 10.4. Changes since -03 Draft . . . . . . . . . . . . . . . . 13 | |||
10.5. Changes since -01 Draft . . . . . . . . . . . . . . . . 12 | 10.5. Changes since -02 Draft . . . . . . . . . . . . . . . . 13 | |||
10.6. Changes since -00 Draft . . . . . . . . . . . . . . . . 12 | 10.6. Changes since -01 Draft . . . . . . . . . . . . . . . . 13 | |||
10.7. Changes since fenton-03 Draft . . . . . . . . . . . . . 12 | 10.7. Changes since -00 Draft . . . . . . . . . . . . . . . . 13 | |||
10.8. Changes Since -02 Draft . . . . . . . . . . . . . . . . 12 | 10.8. Changes since fenton-03 Draft . . . . . . . . . . . . . 13 | |||
10.9. Changes Since -01 Draft . . . . . . . . . . . . . . . . 12 | 10.9. Changes Since -02 Draft . . . . . . . . . . . . . . . . 14 | |||
10.10. Changes Since -00 Draft . . . . . . . . . . . . . . . . 13 | 10.10. Changes Since -01 Draft . . . . . . . . . . . . . . . . 14 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 10.11. Changes Since -00 Draft . . . . . . . . . . . . . . . . 14 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 15 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 | 11.2. Informative References . . . . . . . . . . . . . . . . . 16 | |||
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17 | ||||
A.1. REQUIRETLS SMTP Option . . . . . . . . . . . . . . . . . 17 | ||||
A.2. RequireTLS Header Field . . . . . . . . . . . . . . . . . 18 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 | ||||
1. Introduction | 1. Introduction | |||
The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a | The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a | |||
means by which an SMTP server and client can establish a Transport | means by which an SMTP server and client can establish a Transport | |||
Layer Security (TLS) protected session for the transmission of email | Layer Security (TLS) protected session for the transmission of email | |||
messages. By default, TLS is used only upon mutual agreement | messages. By default, TLS is used only upon mutual agreement | |||
(successful negotiation) of STARTTLS between the client and server; | (successful negotiation) of STARTTLS between the client and server; | |||
if this is not possible, the message is sent without transport | if this is not possible, the message is sent without transport | |||
encryption. Furthermore, it is common practice for the client to | encryption. Furthermore, it is common practice for the client to | |||
skipping to change at page 4, line 7 ¶ | skipping to change at page 4, line 7 ¶ | |||
to transit through one or more MTAs that do not support REQUIRETLS. | to transit through one or more MTAs that do not support REQUIRETLS. | |||
1.1. Requirements Language | 1.1. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
The formal syntax uses the Augmented Backus-Naur Form (ABNF) | ||||
[RFC5234] including the core rules defined in Appendix B of that | ||||
document. | ||||
2. The REQUIRETLS Service Extension | 2. The REQUIRETLS Service Extension | |||
1. The textual name of the extension is "Require TLS". | 1. The textual name of the extension is "Require TLS". | |||
2. The EHLO keyword value associated with this extension is | 2. The EHLO keyword value associated with this extension is | |||
"REQUIRETLS". | "REQUIRETLS". | |||
3. One MAIL FROM option is defined by this extension. | 3. No additional SMTP verbs are defined by this extension. | |||
4. One new SMTP status code is defined by this extension to convey | 4. One optional parameter ("REQUIRETLS") is added to the MAIL FROM | |||
command by this extension. No value is associated with this | ||||
parameter. | ||||
5. The maximum length of a MAIL FROM command line is increased by 11 | ||||
octets by the possible addition of a space and the REQUIRETLS | ||||
keyword. | ||||
6. One new SMTP status code is defined by this extension to convey | ||||
an error condition resulting from failure of the client to send | an error condition resulting from failure of the client to send | |||
to a server not also supporting the REQUIRETLS extension. | to a server not also supporting the REQUIRETLS extension. | |||
7. The REQUIRETLS extension is valid for message relay [RFC5321], | ||||
submission [RFC6409], and the Local Mail Transfer Protocol (LMTP) | ||||
[RFC2033] | ||||
8. The ABNF syntax for the MAIL FROM parameter is as follows: | ||||
requiretls-param = "REQUIRETLS" | ||||
; where requiretls-param is an instance of an | ||||
; esmtp-param used in Mail-parameters in | ||||
; RFC 5321 Section 4.1.2. There is no esmtp-value | ||||
; associated with requiretls-param. | ||||
In order to specify REQUIRETLS treatment for a given message, the | In order to specify REQUIRETLS treatment for a given message, the | |||
REQUIRETLS option is specified on the MAIL FROM command when that | REQUIRETLS option is specified on the MAIL FROM command when that | |||
message is transmitted. This option MUST only be specified in the | message is transmitted. This option MUST only be specified in the | |||
context of an SMTP session meeting the security requirements that | context of an SMTP session meeting the security requirements of | |||
have been specified: | REQUIRETLS: | |||
o The session itself MUST employ TLS transmission. | o The session itself MUST employ TLS transmission. | |||
o If the SMTP server to which the message is being transmitted is | o If the SMTP server to which the message is being transmitted is | |||
identified through an MX record lookup, its name MUST be validated | identified through an MX record lookup, its name MUST be validated | |||
via a DNSSEC signature on the recipient domain's MX record, or the | via a DNSSEC signature on the recipient domain's MX record, or the | |||
MX hostname MUST be validated by an MTA-STS policy as described in | MX hostname MUST be validated by an MTA-STS policy as described in | |||
Section 4.1 of RFC 8461 [RFC8461]. DNSSEC is defined in RFC 4033 | Section 4.1 of RFC 8461 [RFC8461]. DNSSEC is defined in RFC 4033 | |||
[RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035]. | [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035]. | |||
skipping to change at page 4, line 48 ¶ | skipping to change at page 5, line 25 ¶ | |||
specified in RFC 7672 [RFC7672]. For trust chains, the choice of | specified in RFC 7672 [RFC7672]. For trust chains, the choice of | |||
trusted (root) certificates is at the discretion of the SMTP | trusted (root) certificates is at the discretion of the SMTP | |||
client. | client. | |||
o Following the negotiation of STARTTLS, the SMTP server MUST | o Following the negotiation of STARTTLS, the SMTP server MUST | |||
advertise in the subsequent EHLO response that it supports | advertise in the subsequent EHLO response that it supports | |||
REQUIRETLS. | REQUIRETLS. | |||
3. The RequireTLS Header Field | 3. The RequireTLS Header Field | |||
One new message header field, RequireTLS, is defined by this | One new message header field [RFC5322], RequireTLS, is defined by | |||
specification. It is used for messages requesting that recipient TLS | this specification. It is used for messages for which the originator | |||
policy (including MTA-STS [RFC8461] and DANE [RFC7672]) be ignored. | requests that recipient TLS policy (including MTA-STS [RFC8461] and | |||
DANE [RFC7672]) be ignored. This might be done, for example, to | ||||
report a misconfigured mail server, such as an expired TLS | ||||
certificate. | ||||
The RequireTLS header field has a single REQUIRED parameter: | The RequireTLS header field has a single REQUIRED parameter: | |||
o NO - The SMTP client SHOULD attempt to send the message regardless | o NO - The SMTP client SHOULD attempt to send the message regardless | |||
of its ability to negotiate STARTTLS with the SMTP server, | of its ability to negotiate STARTTLS with the SMTP server, | |||
ignoring policy-based mechanisms (including MTA-STS and DANE), if | ignoring policy-based mechanisms (including MTA-STS and DANE), if | |||
any, asserted by the recipient domain. Nevertheless, the client | any, asserted by the recipient domain. Nevertheless, the client | |||
SHOULD negotiate STARTTLS with the server if available. | SHOULD negotiate STARTTLS with the server if available. | |||
More than one instance of the RequireTLS header field MUST NOT appear | More than one instance of the RequireTLS header field MUST NOT appear | |||
in a given message. | in a given message. | |||
The ABNF syntax for the RequireTLS header field is as follows: | ||||
requiretls-field = "RequireTLS:" [FWS] "No" CRLF | ||||
; where requiretls-field in an instance of an | ||||
; optional-field defined in RFC 5322 Section | ||||
; 3.6.8. | ||||
FWS = <as defined in RFC 5322> | ||||
CRLF = <as defined in RFC 5322> | ||||
4. REQUIRETLS Semantics | 4. REQUIRETLS Semantics | |||
4.1. REQUIRETLS Receipt Requirements | 4.1. REQUIRETLS Receipt Requirements | |||
Upon receipt of the REQUIRETLS option on a MAIL FROM command during | Upon receipt of the REQUIRETLS option on a MAIL FROM command during | |||
the receipt of a message, an SMTP server MUST tag that message as | the receipt of a message for which the return-path is not empty | |||
needing REQUIRETLS handling. | (indicating a bounce message), an SMTP server MUST tag that message | |||
as needing REQUIRETLS handling. | ||||
Upon receipt of a message not specifying the REQUIRETLS option on its | Upon receipt of a message not specifying the REQUIRETLS option on its | |||
MAIL FROM command but containing the RequireTLS header field in its | MAIL FROM command but containing the RequireTLS header field in its | |||
message header, an SMTP server implementing this specification MUST | message header, an SMTP server implementing this specification MUST | |||
tag that message with the option specified in the RequireTLS header | tag that message with the option specified in the RequireTLS header | |||
field. If the REQUIRETLS MAIL FROM parameter is specified, the | field. If the REQUIRETLS MAIL FROM parameter is specified, the | |||
RequireTLS header field MUST be ignored but MAY be included in onward | RequireTLS header field MUST be ignored but MAY be included in onward | |||
relay of the message. | relay of the message. | |||
The manner in which the above tagging takes place is implementation- | The manner in which the above tagging takes place is implementation- | |||
dependent. If the message is being locally aliased and redistributed | dependent. If the message is being locally aliased and redistributed | |||
to multiple addresses, all instances of the message MUST be tagged in | to multiple addresses, all instances of the message MUST be tagged in | |||
the same manner. | the same manner. | |||
4.2. REQUIRETLS Sender Requirements | 4.2. REQUIRETLS Sender Requirements | |||
4.2.1. Sending with TLS Required | 4.2.1. Sending with TLS Required | |||
When sending a message tagged as requiring TLS, the sending (client) | When sending a message tagged as requiring TLS for which the MAIL | |||
MTA MUST: | FROM return-path is not empty (an empty MAIL FROM return-path | |||
indicating a bounce message), the sending (client) MTA MUST: | ||||
1. Look up the SMTP server to which the message is to be sent as | 1. Look up the SMTP server to which the message is to be sent as | |||
described in [RFC5321] Section 5.1. | described in [RFC5321] Section 5.1. | |||
2. If the server lookup is accomplished via the recipient domain's | 2. If the server lookup is accomplished via the recipient domain's | |||
MX record (the usual case) and is not accompanied by a valid | MX record (the usual case) and is not accompanied by a valid | |||
DNSSEC signature, the client MUST also validate the SMTP server | DNSSEC signature, the client MUST also validate the SMTP server | |||
name using MTA-STS as described in Section 4.1 of RFC 8461 | name using MTA-STS as described in RFC 8461 [RFC8461] | |||
[RFC8461]. | Section 4.1. | |||
3. Open an SMTP session with the peer SMTP server using the EHLO | 3. Open an SMTP session with the peer SMTP server using the EHLO | |||
verb. | verb. | |||
4. Establish a TLS-protected SMTP session with its peer SMTP server | 4. Establish a TLS-protected SMTP session with its peer SMTP server | |||
and authenticate the server's certificate as specified in | and authenticate the server's certificate as specified in | |||
[RFC6125] or [RFC7672] as applicable. | [RFC6125] or [RFC7672] as applicable. | |||
5. Ensure that the response to the subsequent EHLO following | 5. Ensure that the response to the subsequent EHLO following | |||
establishment of the TLS protection advertises the REQUIRETLS | establishment of the TLS protection advertises the REQUIRETLS | |||
capability. | capability. | |||
6. The SMTP client SHOULD also require that meaningfully secure | The SMTP client SHOULD follow the recommendations in [RFC7525] or its | |||
cipher algorithms and key lengths be negotiated with the server. | successor with respect to negotiation of the TLS session. | |||
The choices of key lengths and algorithms change over time, so a | ||||
specific requirement is not presented here. | ||||
If any of the above steps fail, the client MUST issue a QUIT to the | If any of the above steps fail, the client MUST issue a QUIT to the | |||
server and repeat steps 2-5 with each host on the recipient domain's | server and repeat steps 2-5 with each host on the recipient domain's | |||
list of MX hosts in an attempt to find a mail path that meets the | list of MX hosts in an attempt to find a mail path that meets the | |||
sender's requirements. The client MAY send other, unprotected, | sender's requirements. The client MAY send other, unprotected, | |||
messages to that server if it has any prior to issuing the QUIT. If | messages to that server if it has any prior to issuing the QUIT. If | |||
there are no more MX hosts, the client MUST NOT transmit the message | there are no more MX hosts, the client MUST NOT transmit the message | |||
to the domain. | to the domain. | |||
Following such a failure, the SMTP client MUST send a non-delivery | Following such a failure, the SMTP client MUST send a non-delivery | |||
notification to the reverse-path of the failed message as described | notification to the reverse-path of the failed message as described | |||
in section 3.6 of [RFC5321]. The following status codes [RFC5248] | in section 3.6 of [RFC5321]. The following status codes [RFC5248] | |||
SHOULD be used: | SHOULD be used: | |||
o REQUIRETLS not supported by server: 5.7.x REQUIRETLS needed | o REQUIRETLS not supported by server: 5.7.YYY REQUIRETLS needed | |||
o Unable to establish TLS-protected SMTP session: 5.7.10 Encryption | o Unable to establish TLS-protected SMTP session: 5.7.10 Encryption | |||
needed | needed | |||
Refer to Section 5 for further requirements regarding non-delivery | Refer to Section 5 for further requirements regarding non-delivery | |||
messages. | messages. | |||
If all REQUIRETLS requirements have been met, transmit the message, | If all REQUIRETLS requirements have been met, transmit the message, | |||
issuing the REQUIRETLS option on the MAIL FROM command with the | issuing the REQUIRETLS option on the MAIL FROM command with the | |||
required option(s), if any. | required option(s), if any. | |||
skipping to change at page 8, line 17 ¶ | skipping to change at page 9, line 9 ¶ | |||
The path from the origination of an error bounce message back to the | The path from the origination of an error bounce message back to the | |||
MAIL FROM address may not share the same REQUIRETLS support as the | MAIL FROM address may not share the same REQUIRETLS support as the | |||
forward path. Therefore, users requiring TLS are advised to make | forward path. Therefore, users requiring TLS are advised to make | |||
sure that they are capable of receiving mail using REQUIRETLS as | sure that they are capable of receiving mail using REQUIRETLS as | |||
well. Otherwise, such non-delivery messages will be lost. | well. Otherwise, such non-delivery messages will be lost. | |||
If a REQUIRETLS message is bounced, the server MUST behave as if | If a REQUIRETLS message is bounced, the server MUST behave as if | |||
RET=HDRS was present as described in [RFC3461]. If both RET=FULL and | RET=HDRS was present as described in [RFC3461]. If both RET=FULL and | |||
REQUIRETLS are present, the RET=FULL MUST be disregarded and MAY be | REQUIRETLS are present, the RET=FULL MUST be disregarded and MAY be | |||
transformed to RET=HDRS on relay. The SMTP client for a REQUIRETLS | transformed to RET=HDRS on relay. The SMTP client for a REQUIRETLS | |||
bounce message MUST use an empty MAIL FROM return-path as required by | bounce message uses an empty MAIL FROM return-path as required by | |||
[RFC5321]. When the MAIL FROM return-path is empty, the REQUIRETLS | [RFC5321]. When the MAIL FROM return-path is empty, the REQUIRETLS | |||
parameter SHOULD NOT cause a bounce message to be discarded even if | parameter SHOULD NOT cause a bounce message to be discarded even if | |||
the next-hop relay does not advertise REQUIRETLS. | the next-hop relay does not advertise REQUIRETLS. | |||
Senders of messages requiring TLS are advised to consider the | Senders of messages requiring TLS are advised to consider the | |||
possibility that bounce messages will be lost as a result of | possibility that bounce messages will be lost as a result of | |||
REQUIRETLS return path failure, and that some information could be | REQUIRETLS return path failure, and that some information could be | |||
leaked if a bounce message is not able to be transmitted with | leaked if a bounce message is not able to be transmitted with | |||
REQUIRETLS. | REQUIRETLS. | |||
skipping to change at page 9, line 47 ¶ | skipping to change at page 10, line 47 ¶ | |||
Header field name: RequireTLS | Header field name: RequireTLS | |||
Applicable protocol: mail | Applicable protocol: mail | |||
Status: standard | Status: standard | |||
Author/change controller: IETF | Author/change controller: IETF | |||
Specification document: (this document) | Specification document: (this document) | |||
This section is to be updated for publication by the RFC Editor. | This section is to be updated for publication by the RFC Editor. | |||
8. Security Considerations | 8. Security Considerations | |||
The purpose of REQUIRETLS is to improve communications security for | The purpose of REQUIRETLS is to give the originator of a message | |||
email by giving the originator of a message an expectation that it | control over the security of email they send, either by conveying an | |||
will be transmitted in an encrypted form "over the wire". When used, | expectation that it will be transmitted in an encrypted form "over | |||
REQUIRETLS changes the traditional behavior of email transmission, | the wire" or explicitly that transport encryption is not required if | |||
which favors delivery over the ability to send email messages using | it cannot be successfully negotiated. | |||
transport-layer security, to one in which requested security takes | ||||
precedence over delivery and domain-level policy. | ||||
The following considerations apply to the REQUIRETLS service | The following considerations apply to the REQUIRETLS service | |||
extension but not the RequireTLS header field, since messages | extension but not the RequireTLS header field, since messages | |||
specifying the header field are less concerned with transport | specifying the header field are less concerned with transport | |||
security. | security. | |||
8.1. Passive attacks | 8.1. Passive attacks | |||
REQUIRETLS is generally effective against passive attackers who are | REQUIRETLS is generally effective against passive attackers who are | |||
merely trying to eavesdrop on an SMTP exchange between an SMTP client | merely trying to eavesdrop on an SMTP exchange between an SMTP client | |||
skipping to change at page 11, line 25 ¶ | skipping to change at page 12, line 23 ¶ | |||
The author would like to acknowledge many helpful suggestions on the | The author would like to acknowledge many helpful suggestions on the | |||
ietf-smtp and uta mailing lists, in particular those of Viktor | ietf-smtp and uta mailing lists, in particular those of Viktor | |||
Dukhovni, Chris Newman, Tony Finch, Jeremy Harris, Arvel Hathcock, | Dukhovni, Chris Newman, Tony Finch, Jeremy Harris, Arvel Hathcock, | |||
John Klensin, John Levine, Rolf Sonneveld, and Per Thorsheim. | John Klensin, John Levine, Rolf Sonneveld, and Per Thorsheim. | |||
10. Revision History | 10. Revision History | |||
To be removed by RFC Editor upon publication as an RFC. | To be removed by RFC Editor upon publication as an RFC. | |||
10.1. Changes since -05 Draft | 10.1. Changes since -06 Draft | |||
Various changes in response to AD review: | ||||
o Reference RFC 7525 for TLS negotiation recommendations. | ||||
o Make reference to requested 5.7.YYY error code consistent. | ||||
o Clarify applicability to LMTP and submission. | ||||
o Provide ABNF for syntax of SMTP option and header field and | ||||
examples in Appendix A. | ||||
o Correct use of normative language in Section 5. | ||||
o Clarify case where REQUIRETLS option is used on bounce messages. | ||||
o Improve Security Requirements wording to be incusive of both SMTP | ||||
option and header field. | ||||
10.2. Changes since -05 Draft | ||||
Corrected IANA Permanent Message Header Fields Registry request. | Corrected IANA Permanent Message Header Fields Registry request. | |||
10.2. Changes since -04 Draft | 10.3. Changes since -04 Draft | |||
Require validation of SMTP server hostname via DNSSEC or MTA-STS | Require validation of SMTP server hostname via DNSSEC or MTA-STS | |||
policy when TLS is required. | policy when TLS is required. | |||
10.3. Changes since -03 Draft | 10.4. Changes since -03 Draft | |||
Working Group Last Call changes, including: | Working Group Last Call changes, including: | |||
o Correct reference for SMTP DANE | o Correct reference for SMTP DANE | |||
o Clarify that RequireTLS: NO applies to both MTA-STS and DANE | o Clarify that RequireTLS: NO applies to both MTA-STS and DANE | |||
policies | policies | |||
o Correct newly-defined status codes | o Correct newly-defined status codes | |||
o Update MTA-STS references to RFC | o Update MTA-STS references to RFC | |||
10.4. Changes since -02 Draft | 10.5. Changes since -02 Draft | |||
o More complete documentation for IANA registration requests. | o More complete documentation for IANA registration requests. | |||
o Changed bounce handling to use RET parameters of RFC 3461, along | o Changed bounce handling to use RET parameters of RFC 3461, along | |||
with slightly more liberal transmission of bounces even if | with slightly more liberal transmission of bounces even if | |||
REQUIRETLS can't be negotiated. | REQUIRETLS can't be negotiated. | |||
10.5. Changes since -01 Draft | 10.6. Changes since -01 Draft | |||
o Converted DEEP references to RFC 8314. | o Converted DEEP references to RFC 8314. | |||
o Removed REQUIRETLS options: CHAIN, DANE, and DNSSEC. | o Removed REQUIRETLS options: CHAIN, DANE, and DNSSEC. | |||
o Editorial corrections, notably making the header field name | o Editorial corrections, notably making the header field name | |||
consistent (RequireTLS rather than Require-TLS). | consistent (RequireTLS rather than Require-TLS). | |||
10.6. Changes since -00 Draft | 10.7. Changes since -00 Draft | |||
o Created new header field, Require-TLS, for use by "NO" option. | o Created new header field, Require-TLS, for use by "NO" option. | |||
o Removed "NO" option from SMTP service extension. | o Removed "NO" option from SMTP service extension. | |||
o Recommend DEEP requirements for delivery of messages requiring | o Recommend DEEP requirements for delivery of messages requiring | |||
TLS. | TLS. | |||
o Assorted copy edits | o Assorted copy edits | |||
10.7. Changes since fenton-03 Draft | 10.8. Changes since fenton-03 Draft | |||
o Wording improvements from Rolf Sonneveld review 22 July 2017 | o Wording improvements from Rolf Sonneveld review 22 July 2017 | |||
o A few copy edits | o A few copy edits | |||
o Conversion from individual to UTA WG draft | o Conversion from individual to UTA WG draft | |||
10.8. Changes Since -02 Draft | 10.9. Changes Since -02 Draft | |||
o Incorporation of "MAY TLS" functionality as REQUIRETLS=NO per | o Incorporation of "MAY TLS" functionality as REQUIRETLS=NO per | |||
suggestion on UTA WG mailing list. | suggestion on UTA WG mailing list. | |||
o Additional guidance on bounce messages | o Additional guidance on bounce messages | |||
10.9. Changes Since -01 Draft | 10.10. Changes Since -01 Draft | |||
o Specified retries when multiple MX hosts exist for a given domain. | o Specified retries when multiple MX hosts exist for a given domain. | |||
o Clarified generation of non-delivery messages | o Clarified generation of non-delivery messages | |||
o Specified requirements for application of REQUIRETLS to mail | o Specified requirements for application of REQUIRETLS to mail | |||
forwarders and mailing lists. | forwarders and mailing lists. | |||
o Clarified DNSSEC requirements to include MX lookup only. | o Clarified DNSSEC requirements to include MX lookup only. | |||
o Corrected terminology regarding message retrieval vs. delivery. | o Corrected terminology regarding message retrieval vs. delivery. | |||
o Changed category to standards track. | o Changed category to standards track. | |||
10.10. Changes Since -00 Draft | 10.11. Changes Since -00 Draft | |||
o Conversion of REQUIRETLS from an SMTP verb to a MAIL FROM | o Conversion of REQUIRETLS from an SMTP verb to a MAIL FROM | |||
parameter to better associate REQUIRETLS requirements with | parameter to better associate REQUIRETLS requirements with | |||
transmission of individual messages. | transmission of individual messages. | |||
o Addition of an option to require DNSSEC lookup of the remote mail | o Addition of an option to require DNSSEC lookup of the remote mail | |||
server, since this affects the common name of the certificate that | server, since this affects the common name of the certificate that | |||
is presented. | is presented. | |||
o Clarified the wording to more clearly state that TLS sessions must | o Clarified the wording to more clearly state that TLS sessions must | |||
skipping to change at page 14, line 25 ¶ | skipping to change at page 15, line 40 ¶ | |||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "Resource Records for the DNS Security Extensions", | Rose, "Resource Records for the DNS Security Extensions", | |||
RFC 4034, DOI 10.17487/RFC4034, March 2005, | RFC 4034, DOI 10.17487/RFC4034, March 2005, | |||
<https://www.rfc-editor.org/info/rfc4034>. | <https://www.rfc-editor.org/info/rfc4034>. | |||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "Protocol Modifications for the DNS Security | Rose, "Protocol Modifications for the DNS Security | |||
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, | Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, | |||
<https://www.rfc-editor.org/info/rfc4035>. | <https://www.rfc-editor.org/info/rfc4035>. | |||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | ||||
Specifications: ABNF", STD 68, RFC 5234, | ||||
DOI 10.17487/RFC5234, January 2008, | ||||
<https://www.rfc-editor.org/info/rfc5234>. | ||||
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced | [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced | |||
Mail System Status Codes", BCP 138, RFC 5248, | Mail System Status Codes", BCP 138, RFC 5248, | |||
DOI 10.17487/RFC5248, June 2008, | DOI 10.17487/RFC5248, June 2008, | |||
<https://www.rfc-editor.org/info/rfc5248>. | <https://www.rfc-editor.org/info/rfc5248>. | |||
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | |||
DOI 10.17487/RFC5321, October 2008, | DOI 10.17487/RFC5321, October 2008, | |||
<https://www.rfc-editor.org/info/rfc5321>. | <https://www.rfc-editor.org/info/rfc5321>. | |||
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, | ||||
DOI 10.17487/RFC5322, October 2008, | ||||
<https://www.rfc-editor.org/info/rfc5322>. | ||||
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | |||
Verification of Domain-Based Application Service Identity | Verification of Domain-Based Application Service Identity | |||
within Internet Public Key Infrastructure Using X.509 | within Internet Public Key Infrastructure Using X.509 | |||
(PKIX) Certificates in the Context of Transport Layer | (PKIX) Certificates in the Context of Transport Layer | |||
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March | Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March | |||
2011, <https://www.rfc-editor.org/info/rfc6125>. | 2011, <https://www.rfc-editor.org/info/rfc6125>. | |||
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, | ||||
"Recommendations for Secure Use of Transport Layer | ||||
Security (TLS) and Datagram Transport Layer Security | ||||
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | ||||
2015, <https://www.rfc-editor.org/info/rfc7525>. | ||||
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via | ||||
Opportunistic DNS-Based Authentication of Named Entities | ||||
(DANE) Transport Layer Security (TLS)", RFC 7672, | ||||
DOI 10.17487/RFC7672, October 2015, | ||||
<https://www.rfc-editor.org/info/rfc7672>. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: | [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: | |||
Use of Transport Layer Security (TLS) for Email Submission | Use of Transport Layer Security (TLS) for Email Submission | |||
and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, | and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, | |||
<https://www.rfc-editor.org/info/rfc8314>. | <https://www.rfc-editor.org/info/rfc8314>. | |||
[RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., | [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., | |||
skipping to change at page 15, line 22 ¶ | skipping to change at page 17, line 5 ¶ | |||
Transfer Protocol (SMTP) Enhanced Status Codes Registry", | Transfer Protocol (SMTP) Enhanced Status Codes Registry", | |||
2008, <http://www.iana.org/assignments/ | 2008, <http://www.iana.org/assignments/ | |||
smtp-enhanced-status-codes>. | smtp-enhanced-status-codes>. | |||
11.2. Informative References | 11.2. Informative References | |||
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | |||
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, | STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, | |||
<https://www.rfc-editor.org/info/rfc1939>. | <https://www.rfc-editor.org/info/rfc1939>. | |||
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, | ||||
DOI 10.17487/RFC2033, October 1996, | ||||
<https://www.rfc-editor.org/info/rfc2033>. | ||||
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | |||
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, | 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, | |||
<https://www.rfc-editor.org/info/rfc3501>. | <https://www.rfc-editor.org/info/rfc3501>. | |||
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. | [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. | |||
Thayer, "OpenPGP Message Format", RFC 4880, | Thayer, "OpenPGP Message Format", RFC 4880, | |||
DOI 10.17487/RFC4880, November 2007, | DOI 10.17487/RFC4880, November 2007, | |||
<https://www.rfc-editor.org/info/rfc4880>. | <https://www.rfc-editor.org/info/rfc4880>. | |||
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet | [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet | |||
Mail Extensions (S/MIME) Version 3.2 Message | Mail Extensions (S/MIME) Version 3.2 Message | |||
Specification", RFC 5751, DOI 10.17487/RFC5751, January | Specification", RFC 5751, DOI 10.17487/RFC5751, January | |||
2010, <https://www.rfc-editor.org/info/rfc5751>. | 2010, <https://www.rfc-editor.org/info/rfc5751>. | |||
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via | [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", | |||
Opportunistic DNS-Based Authentication of Named Entities | STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, | |||
(DANE) Transport Layer Security (TLS)", RFC 7672, | <https://www.rfc-editor.org/info/rfc6409>. | |||
DOI 10.17487/RFC7672, October 2015, | ||||
<https://www.rfc-editor.org/info/rfc7672>. | Appendix A. Examples | |||
This section is informative. | ||||
A.1. REQUIRETLS SMTP Option | ||||
The RequireTLS SMTP option is used to express the intent of the | ||||
sender that the associated message be relayed using TLS. In the | ||||
following example, lines beginning with C: are transmitted from the | ||||
SMTP client to the server, and lines beginning with S: are | ||||
transmitted in the opposite direction. | ||||
S: 220 mail.example.net ESMTP | ||||
C: EHLO mail.example.org | ||||
S: 250-mail.example.net Hello example.org [192.0.2.1] | ||||
S: 250-SIZE 52428800 | ||||
S: 250-8BITMIME | ||||
S: 250-PIPELINING | ||||
S: 250-STARTTLS | ||||
S: 250 HELP | ||||
C: STARTTLS | ||||
S: TLS go ahead | ||||
(at this point TLS negotiation takes place. The remainder of this | ||||
session occurs within TLS.) | ||||
S: 220 mail.example.net ESMTP | ||||
C: EHLO mail.example.org | ||||
S: 250-mail.example.net Hello example.org [192.0.2.1] | ||||
S: 250-SIZE 52428800 | ||||
S: 250-8BITMIME | ||||
S: 250-PIPELINING | ||||
S: 250-REQUIRETLS | ||||
S: 250 HELP | ||||
C: MAIL FROM:<roger@example.org> REQUIRETLS | ||||
S: 250 OK | ||||
C: RCPT TO:<editor@example.net> | ||||
S: 250 Accepted | ||||
C: DATA | ||||
S: 354 Enter message, ending with "." on a line by itself | ||||
(message follows) | ||||
C: . | ||||
S: 250 OK | ||||
C: QUIT | ||||
A.2. RequireTLS Header Field | ||||
The RequireTLS header field is used when the sender of the message | ||||
wants to override the default policy of the recipient domain to | ||||
require TLS. It might be used, for example, to allow problems with | ||||
the recipient domain's TLS certificate to be reported: | ||||
From: Roger Reporter <roger@example.org> | ||||
To: Andy Admin <admin@example.com> | ||||
Subject: Certificate problem? | ||||
RequireTLS: NO | ||||
Date: Fri, 18 Jan 2019 10:26:55 -0800 | ||||
Message-ID: <5c421a6f79c0e_d153ff8286d45c468473@mail.example.org> | ||||
Andy, there seems to be a problem with the TLS certificate | ||||
on your mail server. Are you aware of this? | ||||
Roger | ||||
Author's Address | Author's Address | |||
Jim Fenton | Jim Fenton | |||
Altmode Networks | Altmode Networks | |||
Los Altos, California 94024 | Los Altos, California 94024 | |||
USA | USA | |||
Email: fenton@bluepopcorn.net | Email: fenton@bluepopcorn.net | |||
End of changes. 34 change blocks. | ||||
77 lines changed or deleted | 223 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |