Deprecation of TLS 1.1 for Email Submission and Accesscyberstorm.mu88 Avenue De Plevitz Roches BrunesRose Hill71259Mauritius+230 59762817logan@cyberstorm.muTrinity College DublinDublin2Ireland+353-1-896-2354stephen.farrell@cs.tcd.ie
Internet
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
.
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
() 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
. Introduction
. Conventions Used in This Document
. Updates to RFC 8314
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
Introduction defines the minimum
recommended version of TLS as version 1.1. Due to the deprecation of
TLS 1.1 in , this recommendation is no longer valid. Therefore,
this document updates so that
the minimum version for TLS is TLS 1.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
when, and only when, they appear in all capitals, as shown here.
Updates to RFC 8314OLD:
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 , 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 or later. Earlier TLS and
SSL versions MAY also be supported, so long as the MUA requires at
least TLS 1.1 when accessing accounts that are
configured to impose minimum confidentiality requirements.
NEW:
MUAs MUST implement TLS 1.2 or later, e.g., TLS 1.3 . Earlier TLS and
SSL versions MAY also be supported, so long as the MUA requires at
least TLS 1.2 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.)
IANA ConsiderationsThis document has no IANA actions.Security ConsiderationsThe purpose of this document is to document updated recommendations
for using TLS with email services. Those recommendations are based on
.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and AccessThis specification outlines current recommendations for the use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFCs 1939, 2595, 3501, 5068, 6186, and 6409.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Deprecating TLS 1.0 and TLS 1.1Dell EMCTrinity College DublinInformative ReferencesThe Transport Layer Security (TLS) Protocol Version 1.1This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.AcknowledgementsThe authors would like to thank and for their
feedback.Authors' Addressescyberstorm.mu88 Avenue De Plevitz Roches BrunesRose Hill71259Mauritius+230 59762817logan@cyberstorm.muTrinity College DublinDublin2Ireland+353-1-896-2354stephen.farrell@cs.tcd.ie