draft-ietf-uta-smtp-require-tls-05.txt | draft-ietf-uta-smtp-require-tls-06.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 November 20, 2018 | Intended status: Standards Track December 4, 2018 | |||
Expires: May 24, 2019 | Expires: June 7, 2019 | |||
SMTP Require TLS Option | SMTP Require TLS Option | |||
draft-ietf-uta-smtp-require-tls-05 | draft-ietf-uta-smtp-require-tls-06 | |||
Abstract | Abstract | |||
The SMTP STARTTLS option, used in negotiating transport-level | The SMTP STARTTLS option, used in negotiating transport-level | |||
encryption of SMTP connections, is not as useful from a security | encryption of SMTP connections, is not as useful from a security | |||
standpoint as it might be because of its opportunistic nature; | standpoint as it might be because of its opportunistic nature; | |||
message delivery is, by default, prioritized over security. This | message delivery is, by default, prioritized over security. This | |||
document describes an SMTP service extension, REQUIRETLS, and message | document describes an SMTP service extension, REQUIRETLS, and message | |||
header field, RequireTLS. If the REQUIRETLS option or RequireTLS | header field, RequireTLS. If the REQUIRETLS option or RequireTLS | |||
message header field is used when sending a message, it asserts a | message header field is used when sending a message, it asserts a | |||
skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on May 24, 2019. | This Internet-Draft will expire on June 7, 2019. | |||
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 34 ¶ | skipping to change at page 2, line 34 ¶ | |||
4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 7 | 4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 7 | |||
5. Non-delivery message handling . . . . . . . . . . . . . . . . 7 | 5. Non-delivery message handling . . . . . . . . . . . . . . . . 7 | |||
6. Mailing list considerations . . . . . . . . . . . . . . . . . 8 | 6. Mailing list considerations . . . . . . . . . . . . . . . . . 8 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 10 | 8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 10 | |||
8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 10 | 8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 10 | |||
8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 10 | 8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 10 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10. Revision History . . . . . . . . . . . . . . . . . . . . . . 11 | 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10.1. Changes since -04 Draft . . . . . . . . . . . . . . . . 11 | 10.1. Changes since -05 Draft . . . . . . . . . . . . . . . . 11 | |||
10.2. Changes since -03 Draft . . . . . . . . . . . . . . . . 11 | 10.2. Changes since -04 Draft . . . . . . . . . . . . . . . . 11 | |||
10.3. Changes since -02 Draft . . . . . . . . . . . . . . . . 11 | 10.3. Changes since -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 . . . . . . . . . . . . . . . . 12 | |||
10.6. Changes since fenton-03 Draft . . . . . . . . . . . . . 12 | 10.6. Changes since -00 Draft . . . . . . . . . . . . . . . . 12 | |||
10.7. Changes Since -02 Draft . . . . . . . . . . . . . . . . 12 | 10.7. Changes since fenton-03 Draft . . . . . . . . . . . . . 12 | |||
10.8. Changes Since -01 Draft . . . . . . . . . . . . . . . . 12 | 10.8. Changes Since -02 Draft . . . . . . . . . . . . . . . . 12 | |||
10.9. Changes Since -00 Draft . . . . . . . . . . . . . . . . 13 | 10.9. Changes Since -01 Draft . . . . . . . . . . . . . . . . 12 | |||
10.10. Changes Since -00 Draft . . . . . . . . . . . . . . . . 13 | ||||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 15 | 11.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
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 | |||
skipping to change at page 4, line 37 ¶ | skipping to change at page 4, line 37 ¶ | |||
o If the SMTP server to which the message is being transmitted is | o If the SMTP server to which the message is being transmitted is | |||
identified through an MX record lookup, its name MUST be validated | identified through an MX record lookup, its name MUST be validated | |||
via a DNSSEC signature on the recipient domain's MX record, or the | via a DNSSEC signature on the recipient domain's MX record, or the | |||
MX hostname MUST be validated by an MTA-STS policy as described in | MX hostname MUST be validated by an MTA-STS policy as described in | |||
Section 4.1 of RFC 8461 [RFC8461]. DNSSEC is defined in RFC 4033 | Section 4.1 of RFC 8461 [RFC8461]. DNSSEC is defined in RFC 4033 | |||
[RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035]. | [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035]. | |||
o The certificate presented by the SMTP server MUST either verify | o The certificate presented by the SMTP server MUST either verify | |||
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 succesfully 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 RequireTLS Header Field | |||
skipping to change at page 9, line 39 ¶ | skipping to change at page 9, line 39 ¶ | |||
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: RequireTLS | |||
Applicable protocol: mail | Applicable protocol: mail | |||
Status: provisional | Status: standard | |||
Author/change controller: IETF UTA Working Group | Author/change controller: IETF | |||
Specification document: (this document) | Specification document: (this document) | |||
This section is to be updated for publication by the RFC Editor. | This section is to be updated for publication by the RFC Editor. | |||
8. Security Considerations | 8. Security Considerations | |||
The purpose of REQUIRETLS is to improve communications security for | The purpose of REQUIRETLS is to 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, | |||
REQUIRETLS changes the traditional behavior of email transmission, | REQUIRETLS changes the traditional behavior of email transmission, | |||
skipping to change at page 11, line 25 ¶ | skipping to change at page 11, line 25 ¶ | |||
The author would like to acknowledge many helpful suggestions on the | The author would like to acknowledge many helpful suggestions on the | |||
ietf-smtp and uta mailing lists, in particular those of Viktor | ietf-smtp and uta mailing lists, in particular those of Viktor | |||
Dukhovni, Chris Newman, Tony Finch, Jeremy Harris, Arvel Hathcock, | Dukhovni, Chris Newman, Tony Finch, Jeremy Harris, Arvel Hathcock, | |||
John Klensin, John Levine, Rolf Sonneveld, and Per Thorsheim. | John Klensin, John Levine, Rolf Sonneveld, and Per Thorsheim. | |||
10. Revision History | 10. Revision History | |||
To be removed by RFC Editor upon publication as an RFC. | To be removed by RFC Editor upon publication as an RFC. | |||
10.1. Changes since -04 Draft | 10.1. Changes since -05 Draft | |||
Corrected IANA Permanent Message Header Fields Registry request. | ||||
10.2. 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.2. Changes since -03 Draft | 10.3. 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.3. Changes since -02 Draft | 10.4. Changes since -02 Draft | |||
o More complete documentation for IANA registration requests. | o More complete documentation for IANA registration requests. | |||
o Changed bounce handling to use RET parameters of RFC 3461, along | o Changed bounce handling to use RET parameters of RFC 3461, along | |||
with slightly more liberal transmission of bounces even if | with slightly more liberal transmission of bounces even if | |||
REQUIRETLS can't be negotiated. | REQUIRETLS can't be negotiated. | |||
10.4. Changes since -01 Draft | 10.5. 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.5. Changes since -00 Draft | 10.6. 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.6. Changes since fenton-03 Draft | 10.7. 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.7. Changes Since -02 Draft | 10.8. 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.8. Changes Since -01 Draft | 10.9. 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.9. Changes Since -00 Draft | 10.10. 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 | |||
End of changes. 15 change blocks. | ||||
25 lines changed or deleted | 30 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/ |