draft-ietf-uta-smtp-require-tls-01.txt | draft-ietf-uta-smtp-require-tls-02.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 16, 2018 | Intended status: Standards Track April 6, 2018 | |||
Expires: July 20, 2018 | Expires: October 8, 2018 | |||
SMTP Require TLS Option | SMTP Require TLS Option | |||
draft-ietf-uta-smtp-require-tls-01 | draft-ietf-uta-smtp-require-tls-02 | |||
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, Require-TLS. If the REQUIRETLS option or Require-TLS | 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 | |||
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 20, 2018. | This Internet-Draft will expire on October 8, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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 | |||
skipping to change at page 2, line 17 ¶ | skipping to change at page 2, line 17 ¶ | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
2. The REQUIRETLS Service Extension . . . . . . . . . . . . . . 3 | 2. The REQUIRETLS Service Extension . . . . . . . . . . . . . . 3 | |||
3. The Require-TLS Header Field . . . . . . . . . . . . . . . . 5 | 3. The RequireTLS Header Field . . . . . . . . . . . . . . . . . 4 | |||
4. REQUIRETLS Semantics . . . . . . . . . . . . . . . . . . . . 5 | 4. REQUIRETLS Semantics . . . . . . . . . . . . . . . . . . . . 5 | |||
4.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 5 | 4.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 5 | |||
4.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 6 | 4.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 5 | |||
4.2.1. Sending with TLS Required . . . . . . . . . . . . . . 6 | 4.2.1. Sending with TLS Required . . . . . . . . . . . . . . 5 | |||
4.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 7 | 4.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 6 | |||
4.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 7 | 4.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 7 | |||
4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 8 | 4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 7 | |||
5. Non-delivery message handling . . . . . . . . . . . . . . . . 8 | 5. Non-delivery message handling . . . . . . . . . . . . . . . . 7 | |||
6. Mailing list considerations . . . . . . . . . . . . . . . . . 8 | 6. Mailing list considerations . . . . . . . . . . . . . . . . . 8 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 10 | 8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 9 | |||
8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 10 | 8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 9 | |||
8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 10 | 8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 10 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
10. Revision History . . . . . . . . . . . . . . . . . . . . . . 11 | 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 10 | |||
10.1. Changes since -00 Draft . . . . . . . . . . . . . . . . 11 | 10.1. Changes since -01 Draft . . . . . . . . . . . . . . . . 10 | |||
10.2. Changes since fenton-03 Draft . . . . . . . . . . . . . 11 | 10.2. Changes since -00 Draft . . . . . . . . . . . . . . . . 10 | |||
10.3. Changes Since -02 Draft . . . . . . . . . . . . . . . . 11 | 10.3. Changes since fenton-03 Draft . . . . . . . . . . . . . 11 | |||
10.4. Changes Since -01 Draft . . . . . . . . . . . . . . . . 12 | 10.4. Changes Since -02 Draft . . . . . . . . . . . . . . . . 11 | |||
10.5. Changes Since -00 Draft . . . . . . . . . . . . . . . . 12 | 10.5. Changes Since -01 Draft . . . . . . . . . . . . . . . . 11 | |||
10.6. Changes Since -00 Draft . . . . . . . . . . . . . . . . 11 | ||||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 14 | 11.2. Informative References . . . . . . . . . . . . . . . . . 13 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
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 32 ¶ | skipping to change at page 3, line 33 ¶ | |||
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 Require-TLS message header field is used to convey a request to | The RequireTLS 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 Require-TLS header field allows the | the service extension, the RequireTLS header field allows the message | |||
message to transit through one or more MTAs that do not support | to transit through one or more MTAs that do not support REQUIRETLS. | |||
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. | |||
2. The REQUIRETLS Service Extension | 2. The REQUIRETLS Service Extension | |||
skipping to change at page 4, line 24 ¶ | skipping to change at page 4, line 24 ¶ | |||
REQUIRETLS extension. | REQUIRETLS extension. | |||
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 that | |||
have been specified: | have been specified: | |||
o The session itself MUST employ TLS transmission. | o The session itself MUST employ TLS transmission. | |||
o Any server authentication requirements included as an option to | o The certificate presented by the SMTP server MUST either verify | |||
the REQUIRETLS option (see below) MUST have been satisfied in | successfully in a trust chain leading to a certificate trusted by | |||
establishing the current session. | the SMTP client or it MUST verify succesfully using DANE as | |||
specified in RFC 7672 [RFC7672]. For trust chains, the choice of | ||||
trusted (root) certificates is at the discretion of the SMTP | ||||
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. | |||
An optional parameter to the REQUIRETLS MAIL FROM option specifies | 3. The RequireTLS Header Field | |||
the requirements for server authentication that MUST be used for any | ||||
onward transmission of the following message. The parameter takes | ||||
the form of either a single value or comma-separated list, separated | ||||
from the REQUIRETLS option by a single "=" (equals-sign) character. | ||||
If present, the parameter MUST take one or more of the following | ||||
values: | ||||
o CHAIN - The certificate presented by the SMTP server MUST verify | ||||
successfully in a trust chain leading to a certificate trusted by | ||||
the SMTP client. The choice of trusted (root) certificates by the | ||||
client is at their own discretion. | ||||
o DANE - The certificate presented by the SMTP server MUST verify | ||||
succesfully using DANE as specified in RFC 7672 [RFC7672]. | ||||
o DNSSEC - The server MUST confirm that any MX record or CNAME | ||||
lookup used to locate the SMTP server must be DNSSEC [RFC4035] | ||||
signed and valid. | ||||
The CHAIN and DANE parameters are additive; if both are specified, | ||||
either method of certificate validation is acceptable. If neither | ||||
CHAIN nor DANE is specified, the certificate presented by the SMTP | ||||
server is not required to be verified. | ||||
3. The Require-TLS Header Field | ||||
One new message header field, Require-TLS, is defined by this | One new message header field, RequireTLS, is defined by this | |||
specification. It is used for messages requesting that recipient TLS | specification. It is used for messages requesting that recipient TLS | |||
policy (MTA-STS [I-D.ietf-uta-mta-sts] or DANE [RFC7672]) be ignored. | policy (MTA-STS [I-D.ietf-uta-mta-sts] or DANE [RFC7672]) be ignored. | |||
The Require-TLS 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, if any, asserted by the | ignoring policy-based mechanisms, if any, asserted by the | |||
recipient domain. Nevertheless, the client MAY negotiate STARTTLS | recipient domain. Nevertheless, the client SHOULD negotiate | |||
with the server if available. | STARTTLS with the server if available. | |||
More than one instance of the Require-TLS header field MUST NOT | More than one instance of the RequireTLS header field MUST NOT appear | |||
appear in a given message. | in a given message. | |||
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, an SMTP server MUST tag that message as | |||
needing REQUIRETLS handling with the option(s) specified in the | needing REQUIRETLS handling. | |||
REQUIRETLS parameter. | ||||
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 Require-TLS 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 Require-TLS 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 | |||
Require-TLS header field MUST be ignored but MAY be included in | RequireTLS header field MUST be ignored but MAY be included in onward | |||
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, the sending (client) | |||
MTA MUST: | 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. If the DNSSEC option is | described in [RFC5321] Section 5.1. | |||
included in the message tag, the MX record lookups in this | ||||
process MUST use DNSSEC verification and the response(s) MUST be | ||||
DNSSEC-signed in order to ensure the integrity of the resource | ||||
identifier [RFC6125] used to authenticate the SMTP server. | ||||
2. Open an SMTP session with the peer SMTP server using the EHLO | 2. Open an SMTP session with the peer SMTP server using the EHLO | |||
verb. The server MUST advertise the REQUIRETLS capability. | verb. | |||
3. Establish a TLS-protected SMTP session with its peer SMTP server | 3. Establish a TLS-protected SMTP session with its peer SMTP server | |||
and authenticate the server's certificate with the specified | and authenticate the server's certificate as specified in | |||
authentication method as specified in [RFC6125] or [RFC6698] as | [RFC6125] or [RFC6698] as applicable. | |||
applicable. | ||||
4. The SMTP client SHOULD also require that meaningfully secure | 4. Ensure that the response to the subsequent EHLO following | |||
establishment of the TLS protection advertises the REQUIRETLS | ||||
capability. | ||||
5. The SMTP client SHOULD also require that meaningfully secure | ||||
cipher algorithms and key lengths be negotiated with the server. | cipher algorithms and key lengths be negotiated with the server. | |||
The choices of key lengths and algorithms change over time, so a | The choices of key lengths and algorithms change over time, so a | |||
specific requirement is not presented here. | 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-4 with each host on the recipient domain's | server and repeat steps 2-4 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 or if the MX record lookup is not DNSSEC- | there are no more MX hosts, the client MUST NOT transmit the message | |||
protected and DNSSEC verification is required, the client MUST NOT | to the domain. | |||
transmit the message 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 DNSSEC lookup failure: 5.x.x DNSSEC lookup required | ||||
o REQUIRETLS not supported by server: 5.7.x REQUIRETLS needed | o REQUIRETLS not supported by server: 5.7.x 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 | |||
skipping to change at page 7, line 27 ¶ | skipping to change at page 6, line 45 ¶ | |||
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. This MUST be expected, and a non-delivery notification | STARTTLS. A non-delivery notification MUST be returned to the sender | |||
returned to the sender. | if message relay fails due to an inability to negotiate STARTTLS when | |||
required by the server. | ||||
Since messages tagged with RequireTLS: NO will sometimes be sent to | Since messages tagged with RequireTLS: 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, and if so, using what | has authority to decide whether to require TLS. When TLS is to be | |||
authentication method(s). When TLS is to be required, it MUST do so | required, it MUST do so by negotiating STARTTLS and REQUIRETLS and | |||
by negotiating STARTTLS and REQUIRETLS and include the REQUIRETLS | include the REQUIRETLS option on the MAIL FROM command, as is done | |||
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 Require- | When TLS is not to be required, the sender MUST include the | |||
TLS header field in the message. SMTP servers implementing this | RequireTLS header field in the message. SMTP servers implementing | |||
specification will interpret this header field as described in | this specification MUST interpret this header field as described in | |||
Section 4.1. | Section 4.1. | |||
In either case, the decision whether to specify REQUIRETLS, and with | In either case, the decision whether to specify REQUIRETLS MAY be | |||
what option(s), MAY be done based on a user interface selection or | done based on a user interface selection or based on a ruleset or | |||
based on a ruleset or other policy. The manner in which the decision | other policy. The manner in which the decision to require TLS is | |||
to require TLS is made is implementation-dependent and is beyond the | made is implementation-dependent and is beyond the scope of this | |||
scope of this specification. | specification. | |||
4.4. Delivery of REQUIRETLS messages | 4.4. Delivery of REQUIRETLS messages | |||
Messages are usually retrieved by end users using protocols other | Messages are usually retrieved by end users using protocols other | |||
than SMTP such as IMAP [RFC3501], POP [RFC1939], or web mail systems. | than SMTP such as IMAP [RFC3501], POP [RFC1939], or web mail systems. | |||
Mail delivery agents supporting REQUIRETLS SHOULD observe the | Mail delivery agents supporting the REQUIRETLS SMTP option SHOULD | |||
guidelines in [I-D.ietf-uta-email-deep]. | observe the guidelines in [RFC8314]. | |||
5. Non-delivery message handling | 5. Non-delivery message handling | |||
Non-delivery ("bounce") messages usually contain important metadata | Non-delivery ("bounce") messages usually contain important metadata | |||
about the message to which they refer, including the original message | about the message to which they refer, including the original message | |||
header. They therefore MUST be protected in the same manner as the | header. They therefore MUST be protected in the same manner as the | |||
original message. All non-delivery messages, whether resulting from | original message. All non-delivery messages resulting from messages | |||
a REQUIRETLS error or some other, MUST employ REQUIRETLS using the | with the REQUIRETLS SMTP option, whether resulting from a REQUIRETLS | |||
same authentication method(s) as the message that caused the error to | error or some other, MUST also specify the REQUIRETLS SMTP option | |||
occur. | 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 at the | sure that they are capable of receiving mail using REQUIRETLS as | |||
same authentication method(s) as messages they send. Otherwise, such | well. Otherwise, such non-delivery messages will be lost. | |||
non-delivery messages will be lost. | ||||
If unable to send a bounce message due to a REQUIRETLS failure (the | If unable to send a bounce message due to a REQUIRETLS failure (the | |||
return path not supporting the TLS requirements in the original | return path not supporting the TLS requirements in the original | |||
message), the MTA sending the bounce message MAY send a redacted non- | message), the MTA sending the bounce message MAY send a redacted non- | |||
delivery message to the postmaster of the domain identified in the | delivery message to the postmaster of the domain identified in the | |||
envelope-From address identifying the message only by Message-ID and | envelope-From address identifying the message only by Message-ID and | |||
indicating the type of failure. The original From, Return-path, To, | indicating the type of failure. The original From, Return-path, To, | |||
Sender, Cc, and related header fields MUST NOT be included in this | Sender, Cc, and related header fields MUST NOT be included in this | |||
message. | message. | |||
Senders of messages requiring TLS are advised to consider the | Senders of messages requiring TLS are advised to consider the | |||
increased likelihood that bounce messages will be lost as a result of | increased likelihood that bounce messages will be lost as a result of | |||
REQUIRETLS return path failure. | REQUIRETLS return path failure. | |||
6. Mailing list considerations | 6. Mailing list considerations | |||
Mailing lists, upon receipt of a message, originate new messages to | Mailing lists, upon receipt of a message, originate new messages to | |||
list addresses, as distinct from an aliasing operation that redirects | list addresses. This is distinct from an aliasing operation that | |||
the original message, in some cases to multiple recipients. The | redirects the original message, in some cases to multiple recipients. | |||
requirement to preserve the REQUIRETLS tag and options therefore does | The requirement to preserve the REQUIRETLS tag therefore does not | |||
not necessarily extend to mailing lists, although the inclusion of | necessarily extend to mailing lists, although the inclusion of the | |||
the Require-TLS header field MAY cause messages sent to mailing lists | RequireTLS header field MAY cause messages sent to mailing lists to | |||
to inherit this characteristic. REQUIRETLS users SHOULD be made | inherit this characteristic. REQUIRETLS users SHOULD be made aware | |||
aware of this limitation so that they use caution when sending to | of this limitation so that they use caution when sending to mailing | |||
mailing lists and do not assume that REQUIRETLS applies to messages | lists and do not assume that REQUIRETLS applies to messages from the | |||
from the list operator to list members. | list operator to list members. | |||
Mailing list operators MAY apply REQUIRETLS requirements in incoming | Mailing list operators MAY apply REQUIRETLS requirements in incoming | |||
messages to the resulting messages they originate. If this is done, | messages to the resulting messages they originate. If this is done, | |||
they SHOULD also apply these requirements to administrative traffic, | they SHOULD also apply these requirements to administrative traffic, | |||
such as messages to moderators requesting approval of messages. | such as messages to moderators requesting approval of messages. | |||
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 | |||
keyword REQUIRETLS to the SMTP Service Extensions Registry | keyword REQUIRETLS to the SMTP Service Extensions Registry | |||
[MailParams]. | [MailParams]. | |||
If published as an RFC, this draft also requests the creation of a | ||||
registry, REQUIRETLS Security Requirements, to be initially populated | ||||
with the CHAIN, DANE, DNSSEC, and NO keywords. | ||||
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] in the 5.7.YYY range to indicate lack of | Registry [SMTPStatusCodes] in the 5.7.YYY range to indicate lack of | |||
REQUIRETLS support by an SMTP server to which a message is being | REQUIRETLS support by an SMTP server to which a message is being | |||
routed. | routed. | |||
If published as an RFC, this draft requests the addition of the | If published as an RFC, this draft requests the addition of the | |||
header field name Require-TLS to the Permanent Message Header Field | header field name RequireTLS to the Permanent Message Header Field | |||
Names Registry [PermMessageHeaderFields]. | Names Registry [PermMessageHeaderFields]. | |||
This section is to be removed during conversion into an RFC by the | This section is to be removed during conversion into an RFC by the | |||
RFC Editor. | RFC Editor. | |||
8. Security Considerations | 8. Security Considerations | |||
The purpose of REQUIRETLS is to improve communications security for | The purpose of REQUIRETLS is to improve communications security for | |||
email by giving the originator of a message an expectation that it | email by giving the originator of a message an expectation that it | |||
will be transmitted in an encrypted form "over the wire". When used, | will be transmitted in an encrypted form "over the wire". When used, | |||
skipping to change at page 10, line 26 ¶ | skipping to change at page 9, line 41 ¶ | |||
changing the STARTTLS command to something illegal such as XXXXXXXX. | changing the STARTTLS command to something illegal such as XXXXXXXX. | |||
This causes TLS negotiation to fail and messages to be sent in the | This causes TLS negotiation to fail and messages to be sent in the | |||
clear, where they can be intercepted. REQUIRETLS detects the failure | clear, where they can be intercepted. REQUIRETLS detects the failure | |||
of STARTTLS and declines to send the message rather than send it | of STARTTLS and declines to send the message rather than send it | |||
insecurely. | insecurely. | |||
A second form of attack is a man-in-the-middle attack where the | A second form of attack is a man-in-the-middle attack where the | |||
attacker terminates the TLS connection rather than the intended SMTP | attacker terminates the TLS connection rather than the intended SMTP | |||
server. This is possible when, as is commonly the case, the SMTP | server. This is possible when, as is commonly the case, the SMTP | |||
client either does not verify the server's certificate or establishes | client either does not verify the server's certificate or establishes | |||
the connection even when the verification fails. The REQUIRETLS | the connection even when the verification fails. REQUIRETLS requires | |||
CHAIN and DANE options allow the message sender to specify that | successful certificate validation before sending the message. | |||
successful certificate validation, using either or both of two | ||||
different methods, is required before sending the message. | ||||
Another active attack involves the spoofing of DNS MX records of the | Another active attack involves the spoofing of DNS MX records of the | |||
recipient domain. An attacker having this capability could cause the | recipient domain. An attacker having this capability could cause the | |||
message to be redirected to a mail server under the attacker's own | message to be redirected to a mail server under the attacker's own | |||
control, which would presumably have a valid certificate. The | control, which would presumably have a valid certificate. REQUIRETLS | |||
REQUIRETLS DNSSEC option allows the message sender to require that | does not address this attack. | |||
valid DNSSEC [RFC4033] signatures be obtained when locating the | ||||
recipient's mail server, in order to address that attack. | ||||
In addition to support of the DNSSEC option, domains receiving email | ||||
SHOULD deploy DNSSEC and SMTP clients SHOULD deploy DNSSEC | ||||
verification. | ||||
8.3. Bad Actor MTAs | 8.3. Bad Actor MTAs | |||
A bad-actor MTA along the message transmission path could | A bad-actor MTA along the message transmission path could | |||
misrepresent its support of REQUIRETLS and/or actively strip | misrepresent its support of REQUIRETLS and/or actively strip | |||
REQUIRETLS tags from messages it handles. However, since | REQUIRETLS tags from messages it handles. However, since | |||
intermediate MTAs are already trusted with the cleartext of messages | intermediate MTAs are already trusted with the cleartext of messages | |||
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. | |||
skipping to change at page 11, line 23 ¶ | skipping to change at page 10, line 32 ¶ | |||
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, Tony Finch, Jeremy Harris, Arvel Hathcock, John Klensin, | Dukhovni, Tony Finch, Jeremy Harris, Arvel Hathcock, John Klensin, | |||
John Levine, Rolf Sonneveld, and Per Thorsheim. | 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 -00 Draft | 10.1. Changes since -01 Draft | |||
o Converted DEEP references to RFC 8314. | ||||
o Removed REQUIRETLS options: CHAIN, DANE, and DNSSEC. | ||||
o Editorial corrections, notably making the header field name | ||||
consistent (RequireTLS rather than Require-TLS). | ||||
10.2. 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.2. Changes since fenton-03 Draft | 10.3. 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.3. Changes Since -02 Draft | 10.4. 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.4. Changes Since -01 Draft | 10.5. 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.5. Changes Since -00 Draft | 10.6. 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 12, line 42 ¶ | skipping to change at page 12, line 9 ¶ | |||
o Introduced need for minimum encryption standards (key lengths and | o Introduced need for minimum encryption standards (key lengths and | |||
algorithms) | algorithms) | |||
o Substantially rewritten Security Considerations section | o Substantially rewritten Security Considerations section | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[I-D.ietf-uta-email-deep] | ||||
Moore, K. and C. Newman, "Cleartext Considered Obsolete: | ||||
Use of TLS for Email Submission and Access", draft-ietf- | ||||
uta-email-deep-12 (work in progress), December 2017. | ||||
[MailParams] | [MailParams] | |||
Internet Assigned Numbers Authority (IANA), "IANA Mail | Internet Assigned Numbers Authority (IANA), "IANA Mail | |||
Parameters", 2007, | Parameters", 2007, | |||
<http://www.iana.org/assignments/mail-parameters>. | <http://www.iana.org/assignments/mail-parameters>. | |||
[PermMessageHeaderFields] | [PermMessageHeaderFields] | |||
Internet Assigned Numbers Authority (IANA), "Permanent | Internet Assigned Numbers Authority (IANA), "Permanent | |||
Message Header Field Names Registry", 2004, | Message Header Field Names Registry", 2004, | |||
<https://www.iana.org/assignments/message-headers/ | <https://www.iana.org/assignments/message-headers/ | |||
message-headers.xhtml#perm-headers>. | message-headers.xhtml#perm-headers>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over | [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over | |||
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, | Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, | |||
February 2002, <https://www.rfc-editor.org/info/rfc3207>. | February 2002, <https://www.rfc-editor.org/info/rfc3207>. | |||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | ||||
Rose, "Protocol Modifications for the DNS Security | ||||
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, | ||||
<https://www.rfc-editor.org/info/rfc4035>. | ||||
[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>. | |||
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | |||
skipping to change at page 14, line 5 ¶ | skipping to change at page 13, line 5 ¶ | |||
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication | [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication | |||
of Named Entities (DANE) Transport Layer Security (TLS) | of Named Entities (DANE) Transport Layer Security (TLS) | |||
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August | Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August | |||
2012, <https://www.rfc-editor.org/info/rfc6698>. | 2012, <https://www.rfc-editor.org/info/rfc6698>. | |||
[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: | ||||
Use of Transport Layer Security (TLS) for Email Submission | ||||
and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, | ||||
<https://www.rfc-editor.org/info/rfc8314>. | ||||
[SMTPStatusCodes] | [SMTPStatusCodes] | |||
Internet Assigned Numbers Authority (IANA), "Simple Mail | Internet Assigned Numbers Authority (IANA), "Simple Mail | |||
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 | |||
[I-D.ietf-uta-mta-sts] | [I-D.ietf-uta-mta-sts] | |||
Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., | Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., | |||
and J. Jones, "SMTP MTA Strict Transport Security (MTA- | and J. Jones, "SMTP MTA Strict Transport Security (MTA- | |||
STS)", draft-ietf-uta-mta-sts-14 (work in progress), | STS)", draft-ietf-uta-mta-sts-15 (work in progress), April | |||
January 2018. | 2018. | |||
[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>. | |||
[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>. | |||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | ||||
Rose, "DNS Security Introduction and Requirements", | ||||
RFC 4033, DOI 10.17487/RFC4033, March 2005, | ||||
<https://www.rfc-editor.org/info/rfc4033>. | ||||
[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>. | |||
End of changes. 51 change blocks. | ||||
154 lines changed or deleted | 114 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |