draft-ietf-uta-smtp-require-tls-07.txt | draft-ietf-uta-smtp-require-tls-08.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 January 22, 2019 | Intended status: Standards Track April 22, 2019 | |||
Expires: July 26, 2019 | Expires: October 24, 2019 | |||
SMTP Require TLS Option | SMTP Require TLS Option | |||
draft-ietf-uta-smtp-require-tls-07 | draft-ietf-uta-smtp-require-tls-08 | |||
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, TLS-Required. If the REQUIRETLS option or TLS-Required | |||
message header field is used when sending a message, it asserts a | message header field is used when sending a message, it asserts a | |||
request on the part of the message sender to override the default | request on the part of the message sender to override the default | |||
negotiation of TLS, either by requiring that TLS be negotiated when | negotiation of TLS, either by requiring that TLS be negotiated when | |||
the message is relayed, or by requesting that recipient-side policy | the message is relayed, or by requesting that recipient-side policy | |||
mechanisms such as MTA-STS and DANE be ignored when relaying a | mechanisms such as MTA-STS and DANE be ignored when relaying a | |||
message for which security is unimportant. | message for which security is unimportant. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
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 July 26, 2019. | This Internet-Draft will expire on October 24, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . 4 | |||
2. The REQUIRETLS Service Extension . . . . . . . . . . . . . . 4 | 2. The REQUIRETLS Service Extension . . . . . . . . . . . . . . 4 | |||
3. The RequireTLS Header Field . . . . . . . . . . . . . . . . . 5 | 3. The TLS-Required Header Field . . . . . . . . . . . . . . . . 5 | |||
4. REQUIRETLS Semantics . . . . . . . . . . . . . . . . . . . . 6 | 4. REQUIRETLS Semantics . . . . . . . . . . . . . . . . . . . . 6 | |||
4.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 6 | 4.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 6 | |||
4.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 6 | 4.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 6 | |||
4.2.1. Sending with TLS Required . . . . . . . . . . . . . . 6 | 4.2.1. Sending with TLS Required . . . . . . . . . . . . . . 6 | |||
4.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 7 | 4.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 7 | |||
4.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 8 | 4.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 8 | |||
4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 8 | 4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 8 | |||
5. Non-delivery message handling . . . . . . . . . . . . . . . . 8 | 5. Non-delivery message handling . . . . . . . . . . . . . . . . 8 | |||
6. Mailing list considerations . . . . . . . . . . . . . . . . . 9 | 6. Reorigination considerations . . . . . . . . . . . . . . . . 9 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 11 | 8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 11 | |||
8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 11 | 8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 11 | |||
8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 11 | 8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 12 | |||
8.4. Policy Conflicts . . . . . . . . . . . . . . . . . . . . 12 | ||||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | |||
10. Revision History . . . . . . . . . . . . . . . . . . . . . . 12 | 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 12 | |||
10.1. Changes since -06 Draft . . . . . . . . . . . . . . . . 12 | 10.1. Changes since -07 Draft . . . . . . . . . . . . . . . . 12 | |||
10.2. Changes since -05 Draft . . . . . . . . . . . . . . . . 12 | 10.2. Changes since -06 Draft . . . . . . . . . . . . . . . . 13 | |||
10.3. Changes since -04 Draft . . . . . . . . . . . . . . . . 12 | 10.3. Changes since -05 Draft . . . . . . . . . . . . . . . . 13 | |||
10.4. Changes since -03 Draft . . . . . . . . . . . . . . . . 13 | 10.4. Changes since -04 Draft . . . . . . . . . . . . . . . . 13 | |||
10.5. Changes since -02 Draft . . . . . . . . . . . . . . . . 13 | 10.5. Changes since -03 Draft . . . . . . . . . . . . . . . . 14 | |||
10.6. Changes since -01 Draft . . . . . . . . . . . . . . . . 13 | 10.6. Changes since -02 Draft . . . . . . . . . . . . . . . . 14 | |||
10.7. Changes since -00 Draft . . . . . . . . . . . . . . . . 13 | 10.7. Changes since -01 Draft . . . . . . . . . . . . . . . . 14 | |||
10.8. Changes since fenton-03 Draft . . . . . . . . . . . . . 13 | 10.8. Changes since -00 Draft . . . . . . . . . . . . . . . . 14 | |||
10.9. Changes Since -02 Draft . . . . . . . . . . . . . . . . 14 | 10.9. Changes since fenton-03 Draft . . . . . . . . . . . . . 14 | |||
10.10. Changes Since -01 Draft . . . . . . . . . . . . . . . . 14 | 10.10. Changes Since -02 Draft . . . . . . . . . . . . . . . . 15 | |||
10.11. Changes Since -00 Draft . . . . . . . . . . . . . . . . 14 | 10.11. Changes Since -01 Draft . . . . . . . . . . . . . . . . 15 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 10.12. Changes Since -00 Draft . . . . . . . . . . . . . . . . 15 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 16 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17 | 11.2. Informative References . . . . . . . . . . . . . . . . . 17 | |||
A.1. REQUIRETLS SMTP Option . . . . . . . . . . . . . . . . . 17 | Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 | |||
A.2. RequireTLS Header Field . . . . . . . . . . . . . . . . . 18 | A.1. REQUIRETLS SMTP Option . . . . . . . . . . . . . . . . . 18 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 | A.2. TLS-Required Header Field . . . . . . . . . . . . . . . . 19 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 | ||||
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 3, line 41 ¶ | skipping to change at page 3, line 43 ¶ | |||
REQUIRETLS consists of two mechanisms: an SMTP service extension and | REQUIRETLS consists of two mechanisms: an SMTP service extension and | |||
a message header field. The service extension is used to specify | a message header field. The service extension is used to specify | |||
that a given message sent during a particular session MUST be sent | that a given message sent during a particular session MUST be sent | |||
over a TLS-protected session with specified security characteristics. | over a TLS-protected session with specified security characteristics. | |||
It also requires that the SMTP server advertise that it supports | It also requires that the SMTP server advertise that it supports | |||
REQUIRETLS, in effect promising that it will honor the requirement to | REQUIRETLS, in effect promising that it will honor the requirement to | |||
enforce TLS transmission and REQUIRETLS support for onward | enforce TLS transmission and REQUIRETLS support for onward | |||
transmission of those messages. | transmission of those messages. | |||
The RequireTLS message header field is used to convey a request to | The TLS-Required message header field is used to convey a request to | |||
ignore recipient-side policy mechanisms such as MTA-STS and DANE, | ignore recipient-side policy mechanisms such as MTA-STS and DANE, | |||
thereby prioritizing delivery over ability to negotiate TLS. Unlike | thereby prioritizing delivery over ability to negotiate TLS. Unlike | |||
the service extension, the RequireTLS header field allows the message | the service extension, the TLS-Required header field allows the | |||
to transit through one or more MTAs that do not support REQUIRETLS. | message 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) | The formal syntax uses the Augmented Backus-Naur Form (ABNF) | |||
skipping to change at page 5, line 23 ¶ | skipping to change at page 5, line 27 ¶ | |||
successfully in a trust chain leading to a certificate trusted by | successfully in a trust chain leading to a certificate trusted by | |||
the SMTP client or it MUST verify successfully using DANE as | the SMTP client or it MUST verify successfully using DANE as | |||
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 TLS-Required Header Field | |||
One new message header field [RFC5322], RequireTLS, is defined by | One new message header field [RFC5322], TLS-Required, is defined by | |||
this specification. It is used for messages for which the originator | this specification. It is used for messages for which the originator | |||
requests that recipient TLS policy (including MTA-STS [RFC8461] and | requests that recipient TLS policy (including MTA-STS [RFC8461] and | |||
DANE [RFC7672]) be ignored. This might be done, for example, to | DANE [RFC7672]) be ignored. This might be done, for example, to | |||
report a misconfigured mail server, such as an expired TLS | report a misconfigured mail server, such as an expired TLS | |||
certificate. | certificate. | |||
The RequireTLS header field has a single REQUIRED parameter: | The TLS-Required 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 TLS-Required header field MUST NOT | |||
in a given message. | appear in a given message. | |||
The ABNF syntax for the RequireTLS header field is as follows: | The ABNF syntax for the TLS-Required header field is as follows: | |||
requiretls-field = "RequireTLS:" [FWS] "No" CRLF | requiretls-field = "TLS-Required:" [FWS] "No" CRLF | |||
; where requiretls-field in an instance of an | ; where requiretls-field in an instance of an | |||
; optional-field defined in RFC 5322 Section | ; optional-field defined in RFC 5322 Section | |||
; 3.6.8. | ; 3.6.8. | |||
FWS = <as defined in RFC 5322> | FWS = <as defined in RFC 5322> | |||
CRLF = <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 for which the return-path is not empty | the receipt of a message, an SMTP server MUST tag that message as | |||
(indicating a bounce message), an SMTP server MUST tag that message | needing REQUIRETLS handling. | |||
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 TLS-Required 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 TLS-Required header | |||
field. If the REQUIRETLS MAIL FROM parameter is specified, the | field. If the REQUIRETLS MAIL FROM parameter is specified, the TLS- | |||
RequireTLS header field MUST be ignored but MAY be included in onward | Required 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 | |||
skipping to change at page 7, line 39 ¶ | skipping to change at page 7, line 43 ¶ | |||
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. | |||
4.2.2. Sending with TLS Optional | 4.2.2. Sending with TLS Optional | |||
Messages tagged RequireTLS: NO are handled as follows. When sending | Messages tagged TLS-Required: No are handled as follows. When | |||
such a message, the sending (client) MTA MUST: | sending such a message, the sending (client) MTA MUST: | |||
o Look up the SMTP server to which the message is to be sent as | o 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. | |||
o Open an SMTP session with the peer SMTP server using the EHLO | o Open an SMTP session with the peer SMTP server using the EHLO | |||
verb. Attempt to negotiate STARTTLS if possible, and follow any | verb. Attempt to negotiate STARTTLS if possible, and follow any | |||
policy published by the recipient domain, but do not fail if this | policy published by the recipient domain, but do not fail if this | |||
is unsuccessful. | is unsuccessful. | |||
Some SMTP servers may be configured to require STARTTLS connections | Some SMTP servers may be configured to require STARTTLS connections | |||
as a matter of policy and not accept messages in the absence of | as a matter of policy and not accept messages in the absence of | |||
STARTTLS. A non-delivery notification MUST be returned to the sender | STARTTLS. A non-delivery notification MUST be returned to the sender | |||
if message relay fails due to an inability to negotiate STARTTLS when | if message relay fails due to an inability to negotiate STARTTLS when | |||
required by the server. | required by the server. | |||
Since messages tagged with RequireTLS: NO will sometimes be sent to | Since messages tagged with TLS-Required: No will sometimes be sent to | |||
SMTP servers not supporting REQUIRETLS, that option will not be | SMTP servers not supporting REQUIRETLS, that option will not be | |||
uniformly observed by all SMTP relay hops. | uniformly observed by all SMTP relay hops. | |||
4.3. REQUIRETLS Submission | 4.3. REQUIRETLS Submission | |||
An MUA or other agent making the initial introduction of a message | An MUA or other agent making the initial introduction of a message | |||
has authority to decide whether to require TLS. When TLS is to be | has authority to decide whether to require TLS. When TLS is to be | |||
required, it MUST do so by negotiating STARTTLS and REQUIRETLS and | required, it MUST do so by negotiating STARTTLS and REQUIRETLS and | |||
include the REQUIRETLS option on the MAIL FROM command, as is done | include the REQUIRETLS option on the MAIL FROM command, as is done | |||
for message relay. | for message relay. | |||
When TLS is not to be required, the sender MUST include the | When TLS is not to be required, the sender MUST include the TLS- | |||
RequireTLS header field in the message. SMTP servers implementing | Required header field in the message. SMTP servers implementing this | |||
this specification MUST interpret this header field as described in | specification MUST interpret this header field as described in | |||
Section 4.1. | Section 4.1. | |||
In either case, the decision whether to specify REQUIRETLS MAY be | In either case, the decision whether to specify REQUIRETLS MAY be | |||
done based on a user interface selection or based on a ruleset or | done based on a user interface selection or based on a ruleset or | |||
other policy. The manner in which the decision to require TLS is | other policy. The manner in which the decision to require TLS is | |||
made is implementation-dependent and is beyond the scope of this | made is implementation-dependent and is beyond the scope of this | |||
specification. | specification. | |||
4.4. Delivery of REQUIRETLS messages | 4.4. Delivery of REQUIRETLS messages | |||
skipping to change at page 9, line 7 ¶ | skipping to change at page 9, line 10 ¶ | |||
unless redacted as described below. | unless redacted as described below. | |||
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. The SMTP | |||
transformed to RET=HDRS on relay. The SMTP client for a REQUIRETLS | client for a REQUIRETLS bounce message uses an empty MAIL FROM | |||
bounce message uses an empty MAIL FROM return-path as required by | return-path as required by [RFC5321]. When the MAIL FROM return-path | |||
[RFC5321]. When the MAIL FROM return-path is empty, the REQUIRETLS | is empty, the REQUIRETLS parameter SHOULD NOT cause a bounce message | |||
parameter SHOULD NOT cause a bounce message to be discarded even if | to be discarded even if the next-hop relay does not advertise | |||
the next-hop relay does not advertise REQUIRETLS. | 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. | |||
6. Mailing list considerations | 6. Reorigination considerations | |||
Mailing lists, upon receipt of a message, originate new messages to | In a number of situations, a mediator [RFC5598] originates a new | |||
list addresses. This is distinct from an aliasing operation that | message as a result of an incoming message. These situations | |||
redirects the original message, in some cases to multiple recipients. | include, but are not limited to, mailing lists (including | |||
The requirement to preserve the REQUIRETLS tag therefore does not | administrative traffic such as message approval requests), Sieve | |||
necessarily extend to mailing lists, although the inclusion of the | [RFC5228], "vacation" responders, and other filters to which incoming | |||
RequireTLS header field MAY cause messages sent to mailing lists to | messages may be piped. These newly originated messages may | |||
inherit this characteristic. REQUIRETLS users SHOULD be made aware | essentially be copies of the incoming message, such as with a | |||
of this limitation so that they use caution when sending to mailing | forwarding service or a mailing list expander. In other cases, such | |||
lists and do not assume that REQUIRETLS applies to messages from the | as with a vacation message or a delivery notification, they will be | |||
list operator to list members. | different but might contain parts of the original message or other | |||
information for which the original message sender wants to influence | ||||
the requirement to use TLS transmission. | ||||
Mailing list operators MAY apply REQUIRETLS requirements in incoming | Mediators that reoriginate messages should apply REQUIRETLS | |||
messages to the resulting messages they originate. If this is done, | requirements in incoming messages (both requiring TLS transmission | |||
they SHOULD also apply these requirements to administrative traffic, | and requesting that TLS not be required) to the reoriginated messages | |||
such as messages to moderators requesting approval of messages. | to the extent feasible. A limitation to this might be that for a | |||
message requiring TLS, redistribution to multiple addresses while | ||||
retaining the TLS requirement could result in the message not being | ||||
delivered to some of the intended recipients. | ||||
User-side mediators (such as use of Sieve rules on a user agent) | ||||
typically do not have access to the SMTP details, and therefore may | ||||
not be aware of the REQUIRETLS requirement on a delivered message. | ||||
Recipients that expect sensitive traffic should avoid the use of | ||||
user-side mediators. Alternatively, if operationally feasible (such | ||||
as when forwarding to a specific, known address), they should apply | ||||
REQUIRETLS to all reoriginated messages that do not contain the "TLS- | ||||
Required: No" header field. | ||||
7. IANA Considerations | 7. IANA Considerations | |||
If published as an RFC, this draft requests the addition of the | If published as an RFC, this draft requests the addition of the | |||
following keyword to the SMTP Service Extensions Registry | following keyword to the SMTP Service Extensions Registry | |||
[MailParams]: | [MailParams]: | |||
Textual name: RequireTLS | Textual name: Require TLS | |||
EHLO keyword value: REQUIRETLS | EHLO keyword value: REQUIRETLS | |||
Syntax and parameters: (no parameters) | Syntax and parameters: (no parameters) | |||
Additional SMTP verbs: none | Additional SMTP verbs: none | |||
MAIL and RCPT parameters: REQUIRETLS parameter on MAIL | MAIL and RCPT parameters: REQUIRETLS parameter on MAIL | |||
Behavior: Use of the REQUIRETLS parameter on the | Behavior: Use of the REQUIRETLS parameter on the | |||
MAIL verb causes that message to require | MAIL verb causes that message to require | |||
the use of TLS and tagging with | the use of TLS and tagging with | |||
REQUIRETLS for all onward relay. | REQUIRETLS for all onward relay. | |||
Command length increment: 11 characters | Command length increment: 11 characters | |||
If published as an RFC, this draft requests the addition of an entry | If published as an RFC, this draft requests the addition of an entry | |||
to the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes | to the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes | |||
Registry [SMTPStatusCodes]: | Registry [SMTPStatusCodes]: | |||
Code: 5.7.YYY | Code: 5.7.YYY | |||
Sample Text: REQUIRETLS support required | Sample Text: REQUIRETLS support required | |||
Associated basic status code: 530 | Associated basic status code: 550 | |||
Description: This indicates that the message was not | Description: This indicates that the message was not | |||
able to be forwarded because it was | able to be forwarded because it was | |||
received with a REQUIRETLS requirement | received with a REQUIRETLS requirement | |||
and none of the SMTP servers to which | and none of the SMTP servers to which | |||
the message should be forwarded provide | the message should be forwarded provide | |||
this support. | this support. | |||
Reference: (this document) | Reference: (this document) | |||
Submitter: J. Fenton | Submitter: J. Fenton | |||
Change controller: IESG | Change controller: IESG | |||
If published as an RFC, this draft requests the addition of an entry | If published as an RFC, this draft requests the addition of an entry | |||
to the Permanent Message Header Field Names Registry | to the Permanent Message Header Field Names Registry | |||
[PermMessageHeaderFields]: | [PermMessageHeaderFields]: | |||
Header field name: RequireTLS | Header field name: TLS-Required | |||
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 give the originator of a message | The purpose of REQUIRETLS is to give the originator of a message | |||
control over the security of email they send, either by conveying an | control over the security of email they send, either by conveying an | |||
expectation that it will be transmitted in an encrypted form "over | expectation that it will be transmitted in an encrypted form "over | |||
the wire" or explicitly that transport encryption is not required if | the wire" or explicitly that transport encryption is not required if | |||
it cannot be successfully negotiated. | it cannot be successfully negotiated. | |||
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 TLS-Required 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 | |||
and server. This assumes, of course, the cryptographic integrity of | and server. This assumes, of course, the cryptographic integrity of | |||
the TLS connection being used. | the TLS connection being used. | |||
skipping to change at page 12, line 12 ¶ | skipping to change at page 12, line 21 ¶ | |||
they handle, and are not part of the threat model for transport-layer | they handle, and are not part of the threat model for transport-layer | |||
security, they are also not part of the threat model for REQUIRETLS. | security, they are also not part of the threat model for REQUIRETLS. | |||
It should be reemphasized that since SMTP TLS is a transport-layer | It should be reemphasized that since SMTP TLS is a transport-layer | |||
security protocol, messages sent using REQUIRETLS are not encrypted | security protocol, messages sent using REQUIRETLS are not encrypted | |||
end-to-end and are visible to MTAs that are part of the message | end-to-end and are visible to MTAs that are part of the message | |||
delivery path. Messages containing sensitive information that MTAs | delivery path. Messages containing sensitive information that MTAs | |||
should not have access to MUST be sent using end-to-end content | should not have access to MUST be sent using end-to-end content | |||
encryption such as OpenPGP [RFC4880] or S/MIME [RFC5751]. | encryption such as OpenPGP [RFC4880] or S/MIME [RFC5751]. | |||
8.4. Policy Conflicts | ||||
In some cases, the use of the TLS-Required header field may conflict | ||||
with a recipient domain policy expressed through the DANE [RFC7672] | ||||
or MTA-STS [RFC8461] protocols. Although these protocols encourage | ||||
the use of TLS transport by advertising availability of TLS, the use | ||||
of "TLS-Required: No" header field represents an explicit decision on | ||||
the part of the sender not to require the use of TLS, such as to | ||||
overcome a configuration error. The recipient domain has the | ||||
ultimate ability to require TLS by not accepting messages when | ||||
STARTTLS has not been negotiated; otherwise, "TLS-Required: No" is | ||||
effectively directing the client MTA to behave as if it does not | ||||
support DANE nor MTA-STS. | ||||
9. Acknowledgements | 9. Acknowledgements | |||
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, Barry Leiba, 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 -06 Draft | 10.1. Changes since -07 Draft | |||
Changes in response to IESG review and IETF Last Call comments: | ||||
o Change associated status code for 5.7.YYY from 530 to 550. | ||||
o Correct textual name of extension in IANA Considerations for | ||||
consistency with the rest of the document. | ||||
o Remove special handling of bounce messages in Section 4.1. | ||||
o Change name of header field from RequireTLS to TLS-Required and | ||||
make capitalization of parameter consistent. | ||||
o Remove mention of transforming RET=FULL to RET=HDRS on relay in | ||||
Section 5. | ||||
o Replace Section 6 dealing with mailing lists with a more general | ||||
section on reorigination by mediators. | ||||
o Add security considerations section on policy conflicts. | ||||
10.2. Changes since -06 Draft | ||||
Various changes in response to AD review: | Various changes in response to AD review: | |||
o Reference RFC 7525 for TLS negotiation recommendations. | o Reference RFC 7525 for TLS negotiation recommendations. | |||
o Make reference to requested 5.7.YYY error code consistent. | o Make reference to requested 5.7.YYY error code consistent. | |||
o Clarify applicability to LMTP and submission. | o Clarify applicability to LMTP and submission. | |||
o Provide ABNF for syntax of SMTP option and header field and | o Provide ABNF for syntax of SMTP option and header field and | |||
examples in Appendix A. | examples in Appendix A. | |||
o Correct use of normative language in Section 5. | o Correct use of normative language in Section 5. | |||
o Clarify case where REQUIRETLS option is used on bounce messages. | o Clarify case where REQUIRETLS option is used on bounce messages. | |||
o Improve Security Requirements wording to be incusive of both SMTP | o Improve Security Requirements wording to be incusive of both SMTP | |||
option and header field. | option and header field. | |||
10.2. Changes since -05 Draft | 10.3. Changes since -05 Draft | |||
Corrected IANA Permanent Message Header Fields Registry request. | Corrected IANA Permanent Message Header Fields Registry request. | |||
10.3. Changes since -04 Draft | 10.4. 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.4. Changes since -03 Draft | 10.5. 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.5. Changes since -02 Draft | 10.6. 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 [RFC3461], 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.6. Changes since -01 Draft | 10.7. 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.7. Changes since -00 Draft | 10.8. 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.8. Changes since fenton-03 Draft | 10.9. 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.9. Changes Since -02 Draft | 10.10. 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.10. Changes Since -01 Draft | 10.11. 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.11. Changes Since -00 Draft | 10.12. 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 17, line 18 ¶ | skipping to change at page 18, line 18 ¶ | |||
[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>. | |||
[RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email | ||||
Filtering Language", RFC 5228, DOI 10.17487/RFC5228, | ||||
January 2008, <https://www.rfc-editor.org/info/rfc5228>. | ||||
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, | ||||
DOI 10.17487/RFC5598, July 2009, | ||||
<https://www.rfc-editor.org/info/rfc5598>. | ||||
[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>. | |||
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", | [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", | |||
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, | STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, | |||
<https://www.rfc-editor.org/info/rfc6409>. | <https://www.rfc-editor.org/info/rfc6409>. | |||
Appendix A. Examples | Appendix A. Examples | |||
This section is informative. | This section is informative. | |||
A.1. REQUIRETLS SMTP Option | A.1. REQUIRETLS SMTP Option | |||
The RequireTLS SMTP option is used to express the intent of the | The TLS-Required SMTP option is used to express the intent of the | |||
sender that the associated message be relayed using TLS. In the | sender that the associated message be relayed using TLS. In the | |||
following example, lines beginning with C: are transmitted from the | following example, lines beginning with C: are transmitted from the | |||
SMTP client to the server, and lines beginning with S: are | SMTP client to the server, and lines beginning with S: are | |||
transmitted in the opposite direction. | transmitted in the opposite direction. | |||
S: 220 mail.example.net ESMTP | S: 220 mail.example.net ESMTP | |||
C: EHLO mail.example.org | C: EHLO mail.example.org | |||
S: 250-mail.example.net Hello example.org [192.0.2.1] | S: 250-mail.example.net Hello example.org [192.0.2.1] | |||
S: 250-SIZE 52428800 | S: 250-SIZE 52428800 | |||
S: 250-8BITMIME | S: 250-8BITMIME | |||
skipping to change at page 18, line 39 ¶ | skipping to change at page 19, line 39 ¶ | |||
C: RCPT TO:<editor@example.net> | C: RCPT TO:<editor@example.net> | |||
S: 250 Accepted | S: 250 Accepted | |||
C: DATA | C: DATA | |||
S: 354 Enter message, ending with "." on a line by itself | S: 354 Enter message, ending with "." on a line by itself | |||
(message follows) | (message follows) | |||
C: . | C: . | |||
S: 250 OK | S: 250 OK | |||
C: QUIT | C: QUIT | |||
A.2. RequireTLS Header Field | A.2. TLS-Required Header Field | |||
The RequireTLS header field is used when the sender of the message | The TLS-Required header field is used when the sender of the message | |||
wants to override the default policy of the recipient domain to | wants to override the default policy of the recipient domain to | |||
require TLS. It might be used, for example, to allow problems with | require TLS. It might be used, for example, to allow problems with | |||
the recipient domain's TLS certificate to be reported: | the recipient domain's TLS certificate to be reported: | |||
From: Roger Reporter <roger@example.org> | From: Roger Reporter <roger@example.org> | |||
To: Andy Admin <admin@example.com> | To: Andy Admin <admin@example.com> | |||
Subject: Certificate problem? | Subject: Certificate problem? | |||
RequireTLS: NO | TLS-Required: No | |||
Date: Fri, 18 Jan 2019 10:26:55 -0800 | Date: Fri, 18 Jan 2019 10:26:55 -0800 | |||
Message-ID: <5c421a6f79c0e_d153ff8286d45c468473@mail.example.org> | Message-ID: <5c421a6f79c0e_d153ff8286d45c468473@mail.example.org> | |||
Andy, there seems to be a problem with the TLS certificate | Andy, there seems to be a problem with the TLS certificate | |||
on your mail server. Are you aware of this? | on your mail server. Are you aware of this? | |||
Roger | Roger | |||
Author's Address | Author's Address | |||
End of changes. 51 change blocks. | ||||
95 lines changed or deleted | 156 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/ |