diff options
Diffstat (limited to 'doc/rfc/rfc8997.txt')
| -rw-r--r-- | doc/rfc/rfc8997.txt | 253 |
1 files changed, 253 insertions, 0 deletions
diff --git a/doc/rfc/rfc8997.txt b/doc/rfc/rfc8997.txt new file mode 100644 index 0000000..234f5a6 --- /dev/null +++ b/doc/rfc/rfc8997.txt @@ -0,0 +1,253 @@ + + + + +Internet Engineering Task Force (IETF) L. Velvindron +Request for Comments: 8997 cyberstorm.mu +Updates: 8314 S. Farrell +Category: Standards Track Trinity College Dublin +ISSN: 2070-1721 March 2021 + + + Deprecation of TLS 1.1 for Email Submission and Access + +Abstract + + This specification updates the current recommendation for the use of + the Transport Layer Security (TLS) protocol to provide + confidentiality of email between a Mail User Agent (MUA) and a Mail + Submission Server or Mail Access Server. This document updates RFC + 8314. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8997. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Conventions Used in This Document + 3. Updates to RFC 8314 + 4. IANA Considerations + 5. Security Considerations + 6. References + 6.1. Normative References + 6.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + [RFC8314] defines the minimum recommended version of TLS as version + 1.1. Due to the deprecation of TLS 1.1 in [RFC8996], this + recommendation is no longer valid. Therefore, this document updates + [RFC8314] so that the minimum version for TLS is TLS 1.2. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Updates to RFC 8314 + + OLD: + + | 4.1. Deprecation of Services Using Cleartext and TLS Versions + | Less Than 1.1 + + NEW: + + | 4.1. Deprecation of Services Using Cleartext and TLS Versions + | Less Than 1.2 + + OLD: + + | As soon as practicable, MSPs currently supporting Secure Sockets + | Layer (SSL) 2.x, SSL 3.0, or TLS 1.0 SHOULD transition their users + | to TLS 1.1 or later and discontinue support for those earlier + | versions of SSL and TLS. + + NEW: + + | As soon as practicable, MSPs currently supporting Secure Sockets + | Layer (SSL) 2.x, SSL 3.0, TLS 1.0, or TLS 1.1 SHOULD transition + | their users to TLS 1.2 or later and discontinue support for those + | earlier versions of SSL and TLS. + + In Section 4.1 of [RFC8314], the text should be revised from: + + OLD: + + | One way is for the server to refuse a ClientHello message from any + | client sending a ClientHello.version field corresponding to any + | version of SSL or TLS 1.0. + + NEW: + + | One way is for the server to refuse a ClientHello message from any + | client sending a ClientHello.version field corresponding to any + | version of SSL or TLS earlier than TLS 1.2. + + OLD: + + | It is RECOMMENDED that new users be required to use TLS version + | 1.1 or greater from the start. However, an MSP may find it + | necessary to make exceptions to accommodate some legacy systems + | that support only earlier versions of TLS or only cleartext. + + NEW: + + | It is RECOMMENDED that new users be required to use TLS version + | 1.2 or greater from the start. However, an MSP may find it + | necessary to make exceptions to accommodate some legacy systems + | that support only earlier versions of TLS or only cleartext. + + OLD: + + | If, however, an MUA provides such an indication, it MUST NOT + | indicate confidentiality for any connection that does not at least + | use TLS 1.1 with certificate verification and also meet the + | minimum confidentiality requirements associated with that account. + + NEW: + + | If, however, an MUA provides such an indication, it MUST NOT + | indicate confidentiality for any connection that does not at least + | use TLS 1.2 with certificate verification and also meet the + | minimum confidentiality requirements associated with that account. + + OLD + + | MUAs MUST implement TLS 1.2 [RFC5246] or later. Earlier TLS and + | SSL versions MAY also be supported, so long as the MUA requires at + | least TLS 1.1 [RFC4346] when accessing accounts that are + | configured to impose minimum confidentiality requirements. + + NEW: + + | MUAs MUST implement TLS 1.2 [RFC5246] or later, e.g., TLS 1.3 + | [RFC8446]. Earlier TLS and SSL versions MAY also be supported, so + | long as the MUA requires at least TLS 1.2 [RFC5246] when accessing + | accounts that are configured to impose minimum confidentiality + | requirements. + + OLD: + + | The default minimum expected level of confidentiality for all new + | accounts MUST require successful validation of the server's + | certificate and SHOULD require negotiation of TLS version 1.1 or + | greater. (Future revisions to this specification may raise these + | requirements or impose additional requirements to address newly + | discovered weaknesses in protocols or cryptographic algorithms.) + + NEW: + + | The default minimum expected level of confidentiality for all new + | accounts MUST require successful validation of the server's + | certificate and SHOULD require negotiation of TLS version 1.2 or + | greater. (Future revisions to this specification may raise these + | requirements or impose additional requirements to address newly + | discovered weaknesses in protocols or cryptographic algorithms.) + +4. IANA Considerations + + This document has no IANA actions. + +5. Security Considerations + + The purpose of this document is to document updated recommendations + for using TLS with email services. Those recommendations are based + on [RFC8996]. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + <https://www.rfc-editor.org/info/rfc5246>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS + 1.1", RFC 8996, DOI 10.17487/RFC8996, March 2021, + <https://www.rfc-editor.org/info/rfc8996>. + +6.2. Informative References + + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, + DOI 10.17487/RFC4346, April 2006, + <https://www.rfc-editor.org/info/rfc4346>. + +Acknowledgements + + The authors would like to thank Vittorio Bertola and Viktor Dukhovni + for their feedback. + +Authors' Addresses + + Loganaden Velvindron + cyberstorm.mu + 88 Avenue De Plevitz Roches Brunes + 71259 + Rose Hill + Mauritius + + Phone: +230 59762817 + Email: logan@cyberstorm.mu + + + Stephen Farrell + Trinity College Dublin + Dublin + 2 + Ireland + + Phone: +353-1-896-2354 + Email: stephen.farrell@cs.tcd.ie |