draft-ietf-uta-smtp-require-tls-03.txt | draft-ietf-uta-smtp-require-tls-04.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 June 22, 2018 | Intended status: Standards Track September 26, 2018 | |||
Expires: December 24, 2018 | Expires: March 30, 2019 | |||
SMTP Require TLS Option | SMTP Require TLS Option | |||
draft-ietf-uta-smtp-require-tls-03 | draft-ietf-uta-smtp-require-tls-04 | |||
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 December 24, 2018. | This Internet-Draft will expire on March 30, 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 29 ¶ | skipping to change at page 2, line 29 ¶ | |||
4.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 5 | 4.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 5 | |||
4.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 5 | 4.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 5 | |||
4.2.1. Sending with TLS Required . . . . . . . . . . . . . . 5 | 4.2.1. Sending with TLS Required . . . . . . . . . . . . . . 5 | |||
4.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 6 | 4.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 6 | |||
4.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 7 | 4.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 7 | |||
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 . . . . . . . . . . . . . . . . . . . . . 9 | |||
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 . . . . . . . . . . . . . . . . . . . . . . 10 | |||
10. Revision History . . . . . . . . . . . . . . . . . . . . . . 11 | 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10.1. Changes since -02 Draft . . . . . . . . . . . . . . . . 11 | 10.1. Changes since -03 Draft . . . . . . . . . . . . . . . . 11 | |||
10.2. Changes since -01 Draft . . . . . . . . . . . . . . . . 11 | 10.2. Changes since -02 Draft . . . . . . . . . . . . . . . . 11 | |||
10.3. Changes since -00 Draft . . . . . . . . . . . . . . . . 11 | 10.3. Changes since -01 Draft . . . . . . . . . . . . . . . . 11 | |||
10.4. Changes since fenton-03 Draft . . . . . . . . . . . . . 11 | 10.4. Changes since -00 Draft . . . . . . . . . . . . . . . . 11 | |||
10.5. Changes Since -02 Draft . . . . . . . . . . . . . . . . 12 | 10.5. Changes since fenton-03 Draft . . . . . . . . . . . . . 12 | |||
10.6. Changes Since -01 Draft . . . . . . . . . . . . . . . . 12 | 10.6. Changes Since -02 Draft . . . . . . . . . . . . . . . . 12 | |||
10.7. Changes Since -00 Draft . . . . . . . . . . . . . . . . 12 | 10.7. Changes Since -01 Draft . . . . . . . . . . . . . . . . 12 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 10.8. Changes Since -00 Draft . . . . . . . . . . . . . . . . 12 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 | ||||
11.2. Informative References . . . . . . . . . . . . . . . . . 14 | 11.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
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 | |||
negotiate TLS even if the SMTP server's certificate is invalid. | negotiate TLS even if the SMTP server's certificate is invalid. | |||
Policy mechanisms such as DANE [RFC7672] and MTA-STS | Policy mechanisms such as DANE [RFC7672] and MTA-STS [RFC8461] may | |||
[I-D.ietf-uta-mta-sts] may impose requirements for the use of TLS for | impose requirements for the use of TLS for email destined for some | |||
email destined for some domains. However, such policies do not allow | domains. However, such policies do not allow the sender to specify | |||
the sender to specify which messages are more sensitive and require | which messages are more sensitive and require transport-level | |||
transport-level encryption, and which ones are less sensitive and | encryption, and which ones are less sensitive and ought to be relayed | |||
ought to be relayed even if TLS cannot be negotiated successfully. | even if TLS cannot be negotiated successfully. | |||
The default opportunistic nature of SMTP TLS enables several "on the | The default opportunistic nature of SMTP TLS enables several "on the | |||
wire" attacks on SMTP security between MTAs. These include passive | wire" attacks on SMTP security between MTAs. These include passive | |||
eavesdropping on connections for which TLS is not used, interference | eavesdropping on connections for which TLS is not used, interference | |||
in the SMTP protocol to prevent TLS from being negotiated (presumably | in the SMTP protocol to prevent TLS from being negotiated (presumably | |||
accompanied by eavesdropping), and insertion of a man-in-the-middle | accompanied by eavesdropping), and insertion of a man-in-the-middle | |||
attacker exploiting the lack of server authentication by the client. | attacker exploiting the lack of server authentication by the client. | |||
Attacks are described in more detail in the Security Considerations | Attacks are described in more detail in the Security Considerations | |||
section of this document. | section of this document. | |||
skipping to change at page 4, line 14 ¶ | skipping to change at page 4, line 14 ¶ | |||
2. The REQUIRETLS Service Extension | 2. The REQUIRETLS Service Extension | |||
1. The textual name of the extension is "Require TLS". | 1. The textual name of the extension is "Require TLS". | |||
2. The EHLO keyword value associated with this extension is | 2. The EHLO keyword value associated with this extension is | |||
"REQUIRETLS". | "REQUIRETLS". | |||
3. One MAIL FROM option is defined by this extension. | 3. One MAIL FROM option is defined by this extension. | |||
4. Two new SMTP status codes are defined by this extension to convey | 4. One new SMTP status code is defined by this extension to convey | |||
error conditions resulting from failure of the client to | an error condition resulting from failure of the client to send | |||
negotiate a TLS connection with the required security and as a | to a server not also supporting the REQUIRETLS extension. | |||
result of an attempt to send to a server not also supporting the | ||||
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 The certificate presented by the SMTP server MUST either verify | o The certificate presented by the SMTP server MUST either verify | |||
skipping to change at page 4, line 43 ¶ | skipping to change at page 4, line 41 ¶ | |||
client. | client. | |||
o Following the negotiation of STARTTLS, the SMTP server MUST | o Following the negotiation of STARTTLS, the SMTP server MUST | |||
advertise in the subsequent EHLO response that it supports | advertise in the subsequent EHLO response that it supports | |||
REQUIRETLS. | REQUIRETLS. | |||
3. The RequireTLS Header Field | 3. The RequireTLS Header Field | |||
One new message header field, RequireTLS, is defined by this | One new message header field, 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 (including MTA-STS [RFC8461] and DANE [RFC7672]) be ignored. | |||
The RequireTLS header field has a single REQUIRED parameter: | The RequireTLS header field has a single REQUIRED parameter: | |||
o NO - The SMTP client SHOULD attempt to send the message regardless | o NO - The SMTP client SHOULD attempt to send the message regardless | |||
of its ability to negotiate STARTTLS with the SMTP server, | of its ability to negotiate STARTTLS with the SMTP server, | |||
ignoring policy-based mechanisms, if any, asserted by the | ignoring policy-based mechanisms (including MTA-STS and DANE), if | |||
recipient domain. Nevertheless, the client SHOULD negotiate | any, asserted by the recipient domain. Nevertheless, the client | |||
STARTTLS with the server if available. | SHOULD negotiate STARTTLS with the server if available. | |||
More than one instance of the RequireTLS header field MUST NOT appear | More than one instance of the RequireTLS header field MUST NOT appear | |||
in a given message. | in a given message. | |||
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 | |||
skipping to change at page 5, line 44 ¶ | skipping to change at page 5, line 41 ¶ | |||
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. | described in [RFC5321] Section 5.1. | |||
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. | 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 as specified in | and authenticate the server's certificate as specified in | |||
[RFC6125] or [RFC6698] as applicable. | [RFC6125] or [RFC7672] as applicable. | |||
4. Ensure that the response to the subsequent EHLO following | 4. Ensure that the response to the subsequent EHLO following | |||
establishment of the TLS protection advertises the REQUIRETLS | establishment of the TLS protection advertises the REQUIRETLS | |||
capability. | capability. | |||
5. The SMTP client SHOULD also require that meaningfully secure | 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, the client MUST NOT transmit the message | there are no more MX hosts, the client MUST NOT transmit the message | |||
to the domain. | to the domain. | |||
skipping to change at page 8, line 41 ¶ | skipping to change at page 8, line 37 ¶ | |||
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 | |||
following keyword to the SMTP Service Extensions Registry | following keyword to the SMTP Service Extensions Registry | |||
[MailParams]: | [MailParams]: | |||
Textual name: RequireTLS | Textual name: RequireTLS | |||
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 REQUIRETLS | the use of TLS and tagging with | |||
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: 530 | |||
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 | |||
skipping to change at page 11, line 16 ¶ | skipping to change at page 11, line 9 ¶ | |||
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 -02 Draft | 10.1. Changes since -03 Draft | |||
Working Group Last Call changes, including: | ||||
o Correct reference for SMTP DANE | ||||
o Clarify that RequireTLS: NO applies to both MTA-STS and DANE | ||||
policies | ||||
o Correct newly-defined status codes | ||||
o Update MTA-STS references to RFC | ||||
10.2. 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.2. Changes since -01 Draft | 10.3. 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.3. Changes since -00 Draft | 10.4. 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.4. Changes since fenton-03 Draft | 10.5. 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.5. Changes Since -02 Draft | 10.6. 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.6. Changes Since -01 Draft | 10.7. 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.7. Changes Since -00 Draft | 10.8. 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 13, line 41 ¶ | skipping to change at page 13, line 50 ¶ | |||
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 | |||
Verification of Domain-Based Application Service Identity | Verification of Domain-Based Application Service Identity | |||
within Internet Public Key Infrastructure Using X.509 | within Internet Public Key Infrastructure Using X.509 | |||
(PKIX) Certificates in the Context of Transport Layer | (PKIX) Certificates in the Context of Transport Layer | |||
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March | Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March | |||
2011, <https://www.rfc-editor.org/info/rfc6125>. | 2011, <https://www.rfc-editor.org/info/rfc6125>. | |||
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication | ||||
of Named Entities (DANE) Transport Layer Security (TLS) | ||||
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August | ||||
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: | [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: | |||
Use of Transport Layer Security (TLS) for Email Submission | Use of Transport Layer Security (TLS) for Email Submission | |||
and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, | and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, | |||
<https://www.rfc-editor.org/info/rfc8314>. | <https://www.rfc-editor.org/info/rfc8314>. | |||
[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] | ||||
Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., | ||||
and J. Jones, "SMTP MTA Strict Transport Security (MTA- | ||||
STS)", draft-ietf-uta-mta-sts-21 (work in progress), June | ||||
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>. | |||
[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, | |||
skipping to change at page 14, line 48 ¶ | skipping to change at page 14, line 42 ¶ | |||
Mail Extensions (S/MIME) Version 3.2 Message | Mail Extensions (S/MIME) Version 3.2 Message | |||
Specification", RFC 5751, DOI 10.17487/RFC5751, January | Specification", RFC 5751, DOI 10.17487/RFC5751, January | |||
2010, <https://www.rfc-editor.org/info/rfc5751>. | 2010, <https://www.rfc-editor.org/info/rfc5751>. | |||
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via | [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via | |||
Opportunistic DNS-Based Authentication of Named Entities | Opportunistic DNS-Based Authentication of Named Entities | |||
(DANE) Transport Layer Security (TLS)", RFC 7672, | (DANE) Transport Layer Security (TLS)", RFC 7672, | |||
DOI 10.17487/RFC7672, October 2015, | DOI 10.17487/RFC7672, October 2015, | |||
<https://www.rfc-editor.org/info/rfc7672>. | <https://www.rfc-editor.org/info/rfc7672>. | |||
[RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., | ||||
and J. Jones, "SMTP MTA Strict Transport Security (MTA- | ||||
STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, | ||||
<https://www.rfc-editor.org/info/rfc8461>. | ||||
Author's Address | Author's Address | |||
Jim Fenton | Jim Fenton | |||
Altmode Networks | Altmode Networks | |||
Los Altos, California 94024 | Los Altos, California 94024 | |||
USA | USA | |||
Email: fenton@bluepopcorn.net | Email: fenton@bluepopcorn.net | |||
End of changes. 23 change blocks. | ||||
60 lines changed or deleted | 66 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/ |