draft-ietf-uta-rfc7525bis-02.txt   draft-ietf-uta-rfc7525bis-03.txt 
UTA Working Group Y. Sheffer UTA Working Group Y. Sheffer
Internet-Draft Intuit Internet-Draft Intuit
Obsoletes: 7525 (if approved) R. Holz Obsoletes: 7525 (if approved) R. Holz
Updates: 5288, 6066 (if approved) University of Twente Updates: 5288, 6066 (if approved) University of Twente
Intended status: Best Current Practice P. Saint-Andre Intended status: Best Current Practice P. Saint-Andre
Expires: 1 March 2022 Mozilla Expires: 28 April 2022 Mozilla
T. Fossati T. Fossati
arm arm
28 August 2021 25 October 2021
Recommendations for Secure Use of Transport Layer Security (TLS) and Recommendations for Secure Use of Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS) Datagram Transport Layer Security (DTLS)
draft-ietf-uta-rfc7525bis-02 draft-ietf-uta-rfc7525bis-03
Abstract Abstract
Transport Layer Security (TLS) and Datagram Transport Layer Security Transport Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) are widely used to protect data exchanged over application (DTLS) are widely used to protect data exchanged over application
protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the
last few years, several serious attacks on TLS have emerged, last few years, several serious attacks on TLS have emerged,
including attacks on its most commonly used cipher suites and their including attacks on its most commonly used cipher suites and their
modes of operation. This document provides recommendations for modes of operation. This document provides recommendations for
improving the security of deployed services that use TLS and DTLS. improving the security of deployed services that use TLS and DTLS.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 1 March 2022. This Internet-Draft will expire on 28 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 32 skipping to change at page 2, line 32
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Recommendations . . . . . . . . . . . . . . . . . . . 5 3. General Recommendations . . . . . . . . . . . . . . . . . . . 5
3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 5 3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 5
3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 5 3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 5
3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 6 3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 6
3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 7 3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 7
3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 8 3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 8
3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9 3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9
3.6. Post-Handshake Authentication . . . . . . . . . . . . . . 10 3.6. Post-Handshake Authentication . . . . . . . . . . . . . . 9
3.7. Server Name Indication . . . . . . . . . . . . . . . . . 10 3.7. Server Name Indication . . . . . . . . . . . . . . . . . 10
3.8. Application-Layer Protocol Negotiation . . . . . . . . . 10 3.8. Application-Layer Protocol Negotiation . . . . . . . . . 10
3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 . . . . . . 11 3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 . . . . . . 11
4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 11 4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 11
4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 12 4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 11
4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 13 4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 13
4.2.1. Implementation Details . . . . . . . . . . . . . . . 14 4.2.1. Implementation Details . . . . . . . . . . . . . . . 13
4.3. Cipher Suites for TLS 1.3 . . . . . . . . . . . . . . . . 14 4.3. Cipher Suites for TLS 1.3 . . . . . . . . . . . . . . . . 14
4.4. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 15 4.4. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 14
4.5. Public Key Length . . . . . . . . . . . . . . . . . . . . 15 4.5. Public Key Length . . . . . . . . . . . . . . . . . . . . 15
4.6. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 16 4.6. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 16
5. Applicability Statement . . . . . . . . . . . . . . . . . . . 16 5. Applicability Statement . . . . . . . . . . . . . . . . . . . 16
5.1. Security Services . . . . . . . . . . . . . . . . . . . . 17 5.1. Security Services . . . . . . . . . . . . . . . . . . . . 17
5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 18 5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6.1. Host Name Validation . . . . . . . . . . . . . . . . . . 18 6.1. Host Name Validation . . . . . . . . . . . . . . . . . . 18
6.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2.1. Nonce Reuse in TLS 1.2 . . . . . . . . . . . . . . . 19 6.2.1. Nonce Reuse in TLS 1.2 . . . . . . . . . . . . . . . 19
6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 20 6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 20
6.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 21 6.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 21
6.5. Certificate Revocation . . . . . . . . . . . . . . . . . 22 6.5. Certificate Revocation . . . . . . . . . . . . . . . . . 22
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Differences from RFC 7525 . . . . . . . . . . . . . 32 Appendix A. Differences from RFC 7525 . . . . . . . . . . . . . 32
Appendix B. Document History . . . . . . . . . . . . . . . . . . 33 Appendix B. Document History . . . . . . . . . . . . . . . . . . 33
B.1. draft-ietf-uta-rfc7525bis-02 . . . . . . . . . . . . . . 33 B.1. draft-ietf-uta-rfc7525bis-03 . . . . . . . . . . . . . . 33
B.2. draft-ietf-uta-rfc7525bis-01 . . . . . . . . . . . . . . 33 B.2. draft-ietf-uta-rfc7525bis-02 . . . . . . . . . . . . . . 33
B.3. draft-ietf-uta-rfc7525bis-00 . . . . . . . . . . . . . . 34 B.3. draft-ietf-uta-rfc7525bis-01 . . . . . . . . . . . . . . 33
B.4. draft-sheffer-uta-rfc7525bis-00 . . . . . . . . . . . . . 34 B.4. draft-ietf-uta-rfc7525bis-00 . . . . . . . . . . . . . . 34
B.5. draft-sheffer-uta-bcp195bis-00 . . . . . . . . . . . . . 34 B.5. draft-sheffer-uta-rfc7525bis-00 . . . . . . . . . . . . . 34
B.6. draft-sheffer-uta-bcp195bis-00 . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Transport Layer Security (TLS) [RFC5246] and Datagram Transport Transport Layer Security (TLS) [RFC5246] and Datagram Transport
Security Layer (DTLS) [RFC6347] are widely used to protect data Security Layer (DTLS) [RFC6347] are widely used to protect data
exchanged over application protocols such as HTTP, SMTP, IMAP, POP, exchanged over application protocols such as HTTP, SMTP, IMAP, POP,
SIP, and XMPP. Over the years leading to 2015, several serious SIP, and XMPP. Over the years leading to 2015, several serious
attacks on TLS have emerged, including attacks on its most commonly attacks on TLS have emerged, including attacks on its most commonly
used cipher suites and their modes of operation. For instance, both used cipher suites and their modes of operation. For instance, both
skipping to change at page 9, line 39 skipping to change at page 9, line 39
server is able to track the client, in some cases indefinitely. See server is able to track the client, in some cases indefinitely. See
[Sy2018] for more details. [Sy2018] for more details.
3.5. TLS Renegotiation 3.5. TLS Renegotiation
Where handshake renegotiation is implemented, both clients and Where handshake renegotiation is implemented, both clients and
servers MUST implement the renegotiation_info extension, as defined servers MUST implement the renegotiation_info extension, as defined
in [RFC5746]. Note: this recommendation applies to TLS 1.2 only, in [RFC5746]. Note: this recommendation applies to TLS 1.2 only,
because renegotiation has been removed from TLS 1.3. because renegotiation has been removed from TLS 1.3.
The most secure option for countering the Triple Handshake attack is A related attack resulting from TLS session parameters not properly
to refuse any change of certificates during renegotiation. In authenticated is Triple Handshake [triple-handshake]. To address
addition, TLS clients SHOULD apply the same validation policy for all this attack, TLS 1.2 implementations SHOULD support the
certificates received over a connection. The [triple-handshake] extended_master_secret extension defined in [RFC7627].
document suggests several other possible countermeasures, such as
binding the master secret to the full handshake (see [SESSION-HASH])
and binding the abbreviated session resumption handshake to the
original full handshake. Although the latter two techniques are
still under development and thus do not qualify as current practices,
those who implement and deploy TLS are advised to watch for further
development of appropriate countermeasures.
3.6. Post-Handshake Authentication 3.6. Post-Handshake Authentication
Renegotiation in TLS 1.2 was replaced in TLS 1.3 by separate post- Renegotiation in TLS 1.2 was replaced in TLS 1.3 by separate post-
handshake authentication and key update mechanisms. In the context handshake authentication and key update mechanisms. In the context
of protocols that multiplex requests over a single connection (such of protocols that multiplex requests over a single connection (such
as HTTP/2), post-handshake authentication has the same problems as as HTTP/2), post-handshake authentication has the same problems as
TLS 1.2 renegotiation. Multiplexed protocols SHOULD follow the TLS 1.2 renegotiation. Multiplexed protocols SHOULD follow the
advice provided for HTTP/2 in [RFC8740]. advice provided for HTTP/2 in [RFC8740].
skipping to change at page 10, line 33 skipping to change at page 10, line 24
Rationale: SNI supports deployment of multiple TLS-protected virtual Rationale: SNI supports deployment of multiple TLS-protected virtual
servers on a single address, and therefore enables fine-grained servers on a single address, and therefore enables fine-grained
security for these virtual servers, by allowing each one to have its security for these virtual servers, by allowing each one to have its
own certificate. However, SNI also leaks the target domain for a own certificate. However, SNI also leaks the target domain for a
given connection; this information leak will be plugged by use of TLS given connection; this information leak will be plugged by use of TLS
Encrypted Client Hello. Encrypted Client Hello.
In order to prevent the attacks described in [ALPACA], a server that In order to prevent the attacks described in [ALPACA], a server that
does not recognize the presented server name SHOULD NOT continue the does not recognize the presented server name SHOULD NOT continue the
handshake and instead fail with a fatal-level handshake and instead fail with a fatal-level unrecognized_name(112)
"unrecognized_name(112)" alert. Note that this recommendation alert. Note that this recommendation updates Section 3 of [RFC6066]:
updates Section 3 of [RFC6066]: "If the server understood the "If the server understood the ClientHello extension but does not
ClientHello extension but does not recognize the server name, the recognize the server name, the server SHOULD take one of two actions:
server SHOULD take one of two actions: either abort the handshake by either abort the handshake by sending a fatal-level
sending a fatal-level "unrecognized_name(112)" alert or continue the unrecognized_name(112) alert or continue the handshake." It is also
handshake." It is also RECOMMENDED that clients abort the handshake RECOMMENDED that clients abort the handshake if the server
if the server acknowledges the SNI hostname with a different hostname acknowledges the SNI hostname with a different hostname than the one
than the one sent by the client. sent by the client.
3.8. Application-Layer Protocol Negotiation 3.8. Application-Layer Protocol Negotiation
TLS implementations (both client- and server-side) MUST support the TLS implementations (both client- and server-side) MUST support the
Application-Layer Protocol Negotiation (ALPN) extension [RFC7301]. Application-Layer Protocol Negotiation (ALPN) extension [RFC7301].
In order to prevent "cross-protocol" attacks resulting from failure In order to prevent "cross-protocol" attacks resulting from failure
to ensure that a message intended for use in one protocol cannot be to ensure that a message intended for use in one protocol cannot be
mistaken for a message for use in another protocol, servers should mistaken for a message for use in another protocol, servers should
strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]: strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]:
"In the event that the server supports no protocols that the client "In the event that the server supports no protocols that the client
advertises, then the server SHALL respond with a fatal advertises, then the server SHALL respond with a fatal
"no_application_protocol" alert." It is also RECOMMENDED that no_application_protocol alert." It is also RECOMMENDED that clients
clients abort the handshake if the server acknowledges the ALPN abort the handshake if the server acknowledges the ALPN extension,
extension, but does not select a protocol from the client list. but does not select a protocol from the client list. Failure to do
Failure to do so can result in attacks such those described in so can result in attacks such those described in [ALPACA].
[ALPACA].
Protocol developers are strongly encouraged to register an ALPN Protocol developers are strongly encouraged to register an ALPN
identifier for their protocols. This applies to new protocols, as identifier for their protocols. This applies to new protocols, as
well as well-established protocols such as SMTP. well as well-established protocols such as SMTP.
3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3 3.9. Zero Round Trip Time (0-RTT) Data in TLS 1.3
The 0-RTT early data feature is new in TLS 1.3. It provides improved The 0-RTT early data feature is new in TLS 1.3. It provides improved
latency when TLS connections are resumed, at the potential cost of latency when TLS connections are resumed, at the potential cost of
security. As a result, it requires special attention from security. As a result, it requires special attention from
skipping to change at page 15, line 8 skipping to change at page 14, line 43
4.3. Cipher Suites for TLS 1.3 4.3. Cipher Suites for TLS 1.3
This document does not specify any cipher suites for TLS 1.3. This document does not specify any cipher suites for TLS 1.3.
Readers are referred to Sec. 9.1 of [RFC8446] for cipher suite Readers are referred to Sec. 9.1 of [RFC8446] for cipher suite
recommendations. recommendations.
4.4. Limits on Key Usage 4.4. Limits on Key Usage
All ciphers have an upper limit on the amount of traffic that can be All ciphers have an upper limit on the amount of traffic that can be
securely encrypted with any given key. In the case of AEAD cipher securely protected with any given key. In the case of AEAD cipher
suites, the limit is typically determined by the cipher's integrity suites, two separate limits are maintained for each key:
guarantees. When the amount of traffic for a particular connection
has reached the limit, an implementation SHOULD perform a new
handshake (or in TLS 1.3, a Key Update) to rotate the session key.
For all AES-GCM cipher suites recommended for TLS 1.2 in this 1. Confidentiality limit (CL), i.e., the number of records that can
document, the limit for one connection is 2^24.5 full-size records be encrypted.
(about 24 million). This is the same number as for TLS 1.3 with the
equivalent cipher suites.
// TODO: refer to {{I-D.irtf-cfrg-aead-limits}} once it has added the 2. Integrity limit (IL), i.e., the number of records that are
// derivation for TLS 1.2, which is different from TLS 1.3. allowed to fail authentication.
// Different derivation, same numbers.
The latter only applies to DTLS since TLS connections are torn down
on the first decryption failure.
When a sender is approaching CL, the implementation SHOULD initiate a
new handshake (or in TLS 1.3, a Key Update) to rotate the session
key.
When a receiver has reached IL, the implementation SHOULD close the
connection.
For all TLS 1.3 cipher suites, readers are referred to Section 5.5 of For all TLS 1.3 cipher suites, readers are referred to Section 5.5 of
[RFC8446]. [RFC8446] for the values of CL and IL. For all DTLS 1.3 cipher
suites, readers are referred to Section 4.5.3 of
[I-D.ietf-tls-dtls13].
For all AES-GCM cipher suites recommended for TLS 1.2 and DTLS 1.2 in
this document, CL can be derived by plugging the corresponding
parameters into the inequalities in Section 6.1 of
[I-D.irtf-cfrg-aead-limits] that apply to random, partially implicit
nonces, i.e., the nonce construction used in TLS 1.2. Although the
obtained figures are slightly higher than those for TLS 1.3, it is
RECOMMENDED that the same limit of 2^24.5 records is used for both
versions.
For all AES-GCM cipher suites recommended for DTLS 1.2, IL (obtained
from the same inequalities referenced above) is 2^28.
4.5. Public Key Length 4.5. Public Key Length
When using the cipher suites recommended in this document, two public When using the cipher suites recommended in this document, two public
keys are normally used in the TLS handshake: one for the Diffie- keys are normally used in the TLS handshake: one for the Diffie-
Hellman key agreement and one for server authentication. Where a Hellman key agreement and one for server authentication. Where a
client certificate is used, a third public key is added. client certificate is used, a third public key is added.
With a key exchange based on modular exponential (MODP) Diffie- With a key exchange based on modular exponential (MODP) Diffie-
Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048 Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048
skipping to change at page 20, line 6 skipping to change at page 20, line 6
attacks such as [Joux2006]. (See [CVE] records: CVE-2016-0270, CVE- attacks such as [Joux2006]. (See [CVE] records: CVE-2016-0270, CVE-
2016-10213, CVE-2016-10212, CVE-2017-5933.) 2016-10213, CVE-2016-10212, CVE-2017-5933.)
While this problem has been fixed in TLS 1.3, which enforces a While this problem has been fixed in TLS 1.3, which enforces a
deterministic method to generate nonces from record sequence numbers deterministic method to generate nonces from record sequence numbers
and shared secrets for all of its AEAD cipher suites (including AES- and shared secrets for all of its AEAD cipher suites (including AES-
GCM), TLS 1.2 implementations could still choose their own GCM), TLS 1.2 implementations could still choose their own
(potentially insecure) nonce generation methods. (potentially insecure) nonce generation methods.
It is therefore RECOMMENDED that TLS 1.2 implementations use the It is therefore RECOMMENDED that TLS 1.2 implementations use the
64-bit sequence number to populate the "nonce_explicit" part of the 64-bit sequence number to populate the nonce_explicit part of the GCM
GCM nonce, as described in the first two paragraphs of Section 5.3 of nonce, as described in the first two paragraphs of Section 5.3 of
[RFC8446]. Note that this recommendation updates Section 3 of [RFC8446]. Note that this recommendation updates Section 3 of
[RFC5288]: "The nonce_explicit MAY be the 64-bit sequence number." [RFC5288]: "The nonce_explicit MAY be the 64-bit sequence number."
We note that at the time of writing there are no cipher suites We note that at the time of writing there are no cipher suites
defined for nonce reuse resistant algorithms such as AES-GCM-SIV defined for nonce reuse resistant algorithms such as AES-GCM-SIV
[RFC8452]. [RFC8452].
6.3. Forward Secrecy 6.3. Forward Secrecy
Forward secrecy (also called "perfect forward secrecy" or "PFS" and Forward secrecy (also called "perfect forward secrecy" or "PFS" and
skipping to change at page 24, line 8 skipping to change at page 24, line 8
and Orit Levin as the working group chairs and Pete Resnick as the and Orit Levin as the working group chairs and Pete Resnick as the
sponsoring Area Director. sponsoring Area Director.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-httpbis-semantics] [I-D.ietf-httpbis-semantics]
Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf- Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-18, 18 August 2021, httpbis-semantics-19, 12 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-httpbis- <https://www.ietf.org/archive/id/draft-ietf-httpbis-
semantics-18.txt>. semantics-19.txt>.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021, dtls13-43, 30 April 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls- <https://www.ietf.org/archive/id/draft-ietf-tls-
dtls13-43.txt>. dtls13-43.txt>.
[I-D.ietf-tls-oldversions-deprecate] [I-D.ietf-tls-oldversions-deprecate]
skipping to change at page 25, line 49 skipping to change at page 26, line 5
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
DOI 10.17487/RFC7465, February 2015, DOI 10.17487/RFC7465, February 2015,
<https://www.rfc-editor.org/info/rfc7465>. <https://www.rfc-editor.org/info/rfc7465>.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade Suite Value (SCSV) for Preventing Protocol Downgrade
Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
<https://www.rfc-editor.org/info/rfc7507>. <https://www.rfc-editor.org/info/rfc7507>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015,
<https://www.rfc-editor.org/info/rfc7627>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740, [RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,
DOI 10.17487/RFC8740, February 2020, DOI 10.17487/RFC8740, February 2020,
skipping to change at page 31, line 18 skipping to change at page 31, line 29
<https://www.rfc-editor.org/info/rfc8452>. <https://www.rfc-editor.org/info/rfc8452>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>. 2018, <https://www.rfc-editor.org/info/rfc8470>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>. <https://www.rfc-editor.org/info/rfc9001>.
[SESSION-HASH]
Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015,
<https://www.rfc-editor.org/info/rfc7627>.
[Smith2013] [Smith2013]
Smith, B., "Proposal to Change the Default TLS Smith, B., "Proposal to Change the Default TLS
Ciphersuites Offered by Browsers.", 2013, Ciphersuites Offered by Browsers.", 2013,
<https://briansmith.org/browser-ciphersuites-01.html>. <https://briansmith.org/browser-ciphersuites-01.html>.
[Soghoian2011] [Soghoian2011]
Soghoian, C. and S. Stamm, "Certified Lies: Detecting and Soghoian, C. and S. Stamm, "Certified Lies: Detecting and
Defeating Government Interception Attacks Against SSL", Defeating Government Interception Attacks Against SSL",
SSRN Electronic Journal, DOI 10.2139/ssrn.1591033, 2010, SSRN Electronic Journal, DOI 10.2139/ssrn.1591033, 2010,
<https://doi.org/10.2139/ssrn.1591033>. <https://doi.org/10.2139/ssrn.1591033>.
skipping to change at page 32, line 33 skipping to change at page 32, line 33
- Added TLS 1.3 at a SHOULD level. - Added TLS 1.3 at a SHOULD level.
- Similar changes to DTLS, pending publication of DTLS 1.3. - Similar changes to DTLS, pending publication of DTLS 1.3.
- Specific guidance for multiplexed protocols. - Specific guidance for multiplexed protocols.
- MUST-level implementation requirement for ALPN, and more - MUST-level implementation requirement for ALPN, and more
specific SHOULD-level guidance for ALPN and SNI. specific SHOULD-level guidance for ALPN and SNI.
- Limits on key usage.
- New attacks since [RFC7457]: ALPACA, Raccoon, Logjam, "Nonce- - New attacks since [RFC7457]: ALPACA, Raccoon, Logjam, "Nonce-
Disrespecting Adversaries" Disrespecting Adversaries".
* Differences specific to TLS 1.2: * Differences specific to TLS 1.2:
- Fallback SCSV as a MUST for TLS 1.2. - Fallback SCSV as a MUST for TLS 1.2.
- SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2. - SHOULD-level guidance on AES-GCM nonce generation.
- SHOULD NOT use static DH keys or reuse ephemeral DH keys across - SHOULD NOT use static DH keys or reuse ephemeral DH keys across
multiple connections. multiple connections.
- 2048-bit DH now a MUST, ECDH minimal curve size is 224, vs. 192 - 2048-bit DH now a MUST, ECDH minimal curve size is 224, vs. 192
previously. previously.
- Support for extended_master_secret is a SHOULD. Also removed
other, more complicated, related mitigations.
* Differences specific to TLS 1.3: * Differences specific to TLS 1.3:
- New TLS 1.3 capabilities: 0-RTT. - New TLS 1.3 capabilities: 0-RTT.
- Removed capabilities: renegotiation, compression. - Removed capabilities: renegotiation, compression.
- Added mention of TLS Encrypted Client Hello, but no - Added mention of TLS Encrypted Client Hello, but no
recommendation to use until it is finalized. recommendation to use until it is finalized.
- SHOULD-level requirement for forward secrecy in TLS 1.3 session - SHOULD-level requirement for forward secrecy in TLS 1.3 session
resumption. resumption.
- Generic SHOULD-level guidance to avoid 0-RTT unless it is - Generic SHOULD-level guidance to avoid 0-RTT unless it is
documented for the particular protocol. documented for the particular protocol.
Appendix B. Document History Appendix B. Document History
// Note to RFC Editor: please remove before publication. // Note to RFC Editor: please remove before publication.
B.1. draft-ietf-uta-rfc7525bis-02 B.1. draft-ietf-uta-rfc7525bis-03
* Cipher integrity and confidentiality limits.
* Require extended_master_secret.
B.2. draft-ietf-uta-rfc7525bis-02
* Adjusted text about ALPN support in application protocols * Adjusted text about ALPN support in application protocols
* Incorporated text from draft-ietf-tls-md5-sha1-deprecate * Incorporated text from draft-ietf-tls-md5-sha1-deprecate
B.2. draft-ietf-uta-rfc7525bis-01 B.3. draft-ietf-uta-rfc7525bis-01
* Many more changes, including: * Many more changes, including:
- SHOULD-level requirement for forward secrecy in TLS 1.3 session - SHOULD-level requirement for forward secrecy in TLS 1.3 session
resumption. resumption.
- Removed TLS 1.2 capabilities: renegotiation, compression. - Removed TLS 1.2 capabilities: renegotiation, compression.
- Specific guidance for multiplexed protocols. - Specific guidance for multiplexed protocols.
skipping to change at page 34, line 5 skipping to change at page 34, line 13
documented for the particular protocol. documented for the particular protocol.
- SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2. - SHOULD-level guidance on AES-GCM nonce generation in TLS 1.2.
- SHOULD NOT use static DH keys or reuse ephemeral DH keys across - SHOULD NOT use static DH keys or reuse ephemeral DH keys across
multiple connections. multiple connections.
- 2048-bit DH now a MUST, ECDH minimal curve size is 224, up from - 2048-bit DH now a MUST, ECDH minimal curve size is 224, up from
192. 192.
B.3. draft-ietf-uta-rfc7525bis-00 B.4. draft-ietf-uta-rfc7525bis-00
* Renamed: WG document. * Renamed: WG document.
* Started populating list of changes from RFC 7525. * Started populating list of changes from RFC 7525.
* General rewording of abstract and intro for revised version. * General rewording of abstract and intro for revised version.
* Protocol versions, fallback. * Protocol versions, fallback.
* Reference to ECHO. * Reference to ECHO.
B.4. draft-sheffer-uta-rfc7525bis-00 B.5. draft-sheffer-uta-rfc7525bis-00
* Renamed, since the BCP number does not change. * Renamed, since the BCP number does not change.
* Added an empty "Differences from RFC 7525" section. * Added an empty "Differences from RFC 7525" section.
B.5. draft-sheffer-uta-bcp195bis-00 B.6. draft-sheffer-uta-bcp195bis-00
* Initial release, the RFC 7525 text as-is, with some minor * Initial release, the RFC 7525 text as-is, with some minor
editorial changes to the references. editorial changes to the references.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Intuit Intuit
Email: yaronf.ietf@gmail.com Email: yaronf.ietf@gmail.com
 End of changes. 30 change blocks. 
69 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/