diff --git a/rfc9846.md b/rfc9846.md
index 13c3d331..4e03f6f0 100644
--- a/rfc9846.md
+++ b/rfc9846.md
@@ -1,18 +1,19 @@
---
title: The Transport Layer Security (TLS) Protocol Version 1.3
abbrev: TLS
-docname: draft-ietf-tls-rfc8446bis-latest
+number: 9846
+docname: draft-ietf-tls-rfc8446bis-14
submissiontype: IETF
+consensus: true
category: std
updates: 5705, 6066, 7627, 8422
obsoletes: 8446
v: 3
+lang: en
ipr: pre5378Trust200902
-area: Security
-workgroup: Transport Layer Security
-keyword: Internet-Draft
-
+area: SEC
+workgroup: tls
stand_alone: yes
pi:
rfcedstyle: yes
@@ -48,14 +49,13 @@ normative:
RFC8174:
RFC5116:
-
X690:
title: "Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)"
date: February 2021
author:
org: ITU-T
seriesinfo:
- ITU-T X.690
+ ITU-T: Recommendation X.690
target: https://www.itu.int/rec/T-REC-X.690-202102-I/en
GCM:
title: "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC"
@@ -63,9 +63,9 @@ normative:
author:
- ins: M. Dworkin
seriesinfo:
- NIST: Special Publication 800-38D
+ NIST: SP 800-38D
+ DOI: 10.6028/NIST.SP.800-38D
target: https://doi.org/10.6028/NIST.SP.800-38D
-
informative:
RFC4086:
RFC4346:
@@ -85,7 +85,7 @@ informative:
RFC7685:
RFC8305:
RFC8844:
- RFC8849:
+ RFC8449:
RFC8870:
RFC8937:
RFC9001:
@@ -106,26 +106,28 @@ informative:
date: 1995-02-09
TIMING:
title: "Remote Timing Attacks Are Practical"
+ target: https://www.usenix.org/conference/12th-usenix-security-symposium/remote-timing-attacks-are-practical
author:
-
ins: D. Boneh
-
ins: D. Brumley
- seriesinfo:
- USENIX: Security Symposium
+ refcontent: 12th USENIX Security Symposium (USENIX Security 03)
date: 2003
X501:
title: "Information Technology - Open Systems Interconnection - The Directory: Models"
date: October 2019
+ target: https://www.itu.int/rec/T-REC-X.501-201910-I/en
author:
org: ITU-T
seriesinfo:
- ISO/IEC 9594-2:2020
+ ITU-T: Recommendation X.501
+ ISO/IEC: 9594-2:2020
PSK-FINISHED:
title: "Revision 10: possible attack if client authentication is allowed during PSK"
- date: 2015
- seriesinfo: message to the TLS mailing list,
- target: https://www.ietf.org/mail-archive/web/tls/current/msg18215.html
+ date: 2015-10-31
+ refcontent: message to the TLS mailing list
+ target: https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/
author:
-
ins: C. Cremers
@@ -137,9 +139,9 @@ informative:
ins: S. Scott
CHHSV17:
title: "Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18"
- date: 10 February, 2017
- target: https://www.ietf.org/mail-archive/web/tls/current/msg22382.html
- seriesinfo: message to the TLS mailing list
+ date: 2017-02-10
+ target: https://mailarchive.ietf.org/arch/msg/tls/crdSCgiW-94z2joulYJtuA52E9E/
+ refcontent: message to the TLS mailing list
author:
-
ins: C. Cremers
@@ -158,10 +160,11 @@ informative:
ins: A. Luykx
-
ins: K. Paterson
- target: https://eprint.iacr.org/2024/051.pdf
+ target: https://eprint.iacr.org/2024/051
date: August 2017
HGFS15:
title: "Prying Open Pandora's Box: KCI Attacks against TLS"
+ target: https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek
author:
-
ins: C. Hlauschek
@@ -171,7 +174,7 @@ informative:
ins: F. Fankhauser
-
ins: C. Schanes
- seriesinfo: Proceedings of USENIX Workshop on Offensive Technologies
+ refcontent: Proceedings of USENIX Workshop on Offensive Technologies
date: 2015
FGSW16:
title: "Key Confirmation in Key Exchange: A Formal Treatment and Implications for TLS 1.3"
@@ -184,16 +187,20 @@ informative:
ins: B. Schmidt
-
ins: B. Warinschi
- seriesinfo: Proceedings of IEEE Symposium on Security and Privacy (Oakland) 2016
+ refcontent: Proceedings of IEEE Symposium on Security and Privacy (Oakland) 2016
+ seriesinfo:
+ DOI: 10.1109/SP.2016.34
target: http://ieeexplore.ieee.org/document/7546517/
date: 2016
FW15:
title: "Factoring RSA Keys With TLS Perfect Forward Secrecy"
+ target: https://www.redhat.com/en/blog/factoring-rsa-keys-tls-perfect-forward-secrecy
author:
-
ins: F. Weimer
org: Red Hat Product Security
- date: 2015-09
+ date: 2015-09-02
+ refcontent: Red Hat Blog
BDFKPPRSZZ16:
title: "Implementing and Proving the TLS 1.3 Record Layer"
author:
@@ -217,16 +224,17 @@ informative:
ins: S. Zanella-Beguelin
-
ins: J. Zinzindohoue
- seriesinfo: Proceedings of IEEE Symposium on Security and Privacy (San Jose) 2017
+ refcontent: Proceedings of IEEE Symposium on Security and Privacy (San Jose) 2017
date: 2016-12
target: https://eprint.iacr.org/2016/1178
Blei98:
title: "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1"
+ target: https://link.springer.com/chapter/10.1007/bfb0055716
author:
-
ins: D. Bleichenbacher
- seriesinfo: Proceedings of CRYPTO '98
+ refcontent: Proceedings of CRYPTO '98
date: 1998
BMMRT15:
@@ -242,8 +250,8 @@ informative:
ins: P. Rogaway
-
ins: B. Tackmann
- seriesinfo: ProvSec 2015
- date: 2015-09
+ refcontent: ProvSec 2015
+ date: September 2015
target: https://eprint.iacr.org/2015/394
BT16:
@@ -253,14 +261,14 @@ informative:
ins: M. Bellare
-
ins: B. Tackmann
- seriesinfo: Proceedings of CRYPTO 2016
+ refcontent: Proceedings of CRYPTO 2016
date: July 2016
target: https://eprint.iacr.org/2016/564
Kraw16:
title: "A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with Applications to Client Authentication in TLS 1.3"
- date: October2016
- seriesinfo: Proceedings of ACM CCS 2016
+ date: October 2016
+ refcontent: Proceedings of ACM CCS 2016
target: https://eprint.iacr.org/2016/711
author:
-
@@ -268,8 +276,8 @@ informative:
KW16:
title: "The OPTLS Protocol and TLS 1.3"
- date: 2016
- seriesinfo: Proceedings of Euro S&P 2016
+ date: March 2016
+ refcontent: Proceedings of Euro S&P 2016
target: https://eprint.iacr.org/2015/978
author:
-
@@ -279,9 +287,8 @@ informative:
DFGS15:
title: "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and Pre-shared Key Handshake Protocol"
- date: 2015
- seriesinfo: Proceedings of ACM CCS 2015
- date: October 2016,
+ date: October 2015
+ refcontent: Proceedings of ACM CCS 2015
target: https://eprint.iacr.org/2015/914
author:
-
@@ -296,7 +303,7 @@ informative:
DFGS16:
title: "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and Pre-shared Key Handshake Protocol"
date: February 2016
- seriesinfo: TRON 2016
+ refcontent: TRON 2016
target: https://eprint.iacr.org/2016/081
author:
-
@@ -310,8 +317,8 @@ informative:
FG17:
title: "Replay Attacks on Zero Round-Trip Time: The Case of the TLS 1.3 Handshake Candidates"
- date: 2017
- seriesinfo: Proceedings of Euro S&P 2017
+ date: April 2017
+ refcontent: Proceedings of Euro S&P 2017
target: https://eprint.iacr.org/2017/082
author:
-
@@ -322,15 +329,14 @@ informative:
Kraw10:
title: "Cryptographic Extraction and Key Derivation: The HKDF Scheme"
date: 2010
- seriesinfo: Proceedings of CRYPTO 2010
+ refcontent: Proceedings of CRYPTO 2010
target: https://eprint.iacr.org/2010/264
- data: August 2010
author:
-
ins: H. Krawczyk
Mac17:
title: "Security Review of TLS1.3 0-RTT"
- date: March 2017
+ date: May 2017
target: https://github.com/tlswg/tls13-spec/issues/1001
author:
-
@@ -338,34 +344,36 @@ informative:
Res17a:
title: Preliminary data on Firefox TLS 1.3 Middlebox experiment
- date: 2017
- target: https://www.ietf.org/mail-archive/web/tls/current/msg25091.html
- seriesinfo: message to the TLS mailing list
+ date: 2017-12-05
+ target: https://mailarchive.ietf.org/arch/msg/tls/RBp0X-OWNuWXugFJRV7c_hIU0dI/
+ refcontent: message to the TLS mailing list
author:
-
ins: E. Rescorla
Res17b:
title: More compatibility measurement results
- date: 22 December 2017
- target: https://www.ietf.org/mail-archive/web/tls/current/msg25179.html
- seriesinfo: message to the TLS mailing list
+ date: 2017-12-22
+ target: https://mailarchive.ietf.org/arch/msg/tls/6pGGT-wm5vSkacMFPEPvFMEnj-M/
+ refcontent: message to the TLS mailing list
author:
-
ins: E. Rescorla
Ben17a:
title: Presentation before the TLS WG at IETF 100
- date: 2017
+ date: November 2017
target: https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-tls13/
author:
-
ins: D. Benjamin
+ refcontent: IETF 100 Proceedings
Ben17b:
title: Additional TLS 1.3 results from Chrome
- date: 2017
- target: https://www.ietf.org/mail-archive/web/tls/current/msg25168.html
+ date: 2017-12-18
+ target: https://mailarchive.ietf.org/arch/msg/tls/i9blmvG2BEPf1s1OJkenHknRw9c/
+ refcontent: message to the TLS mailing list
author:
-
ins: D. Benjamin
@@ -383,22 +391,29 @@ informative:
target: https://eprint.iacr.org/2018/634
FETCH:
- title: "Fetch Standard"
- date: Living Standard
+ title: "Fetch"
+ date: false
author:
org: WHATWG
target: https://fetch.spec.whatwg.org/
+ refcontent: WHATWG Living Standard
+ ann: >
+ Commit snapshot: https://fetch.spec.whatwg.org/commit-snapshots/4775fcb48042c8411df497c0b7cf167b4240004f/
DSA-1571-1:
- title: "openssl -- predictable random number generator"
+ title: "[SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator"
author:
- org: The Debian Project
+ -
+ ins: F. Weimer
date: May 2008
target: https://www.debian.org/security/2008/dsa-1571
+ refcontent: message to the debian-security-announce mailing list
MM24:
title: "Misbinding Raw Public Keys to Identities in TLS"
- date: 2024
+ date: 2025-09-29
+ refcontent:
+ arxiv:2411.09770
target: https://arxiv.org/pdf/2411.09770
author:
-
@@ -411,16 +426,98 @@ informative:
Selfie:
title: "Selfie: reflections on TLS 1.3 with PSK"
date: 2019
- target: https://eprint.iacr.org/2019/347.pdf
+ target: https://eprint.iacr.org/2019/347
author:
-
ins: N. Drucker
-
ins: S. Gueron
+ PRE-RFC9849:
+ title: >
+ TLS Encrypted Client Hello
+ target: https://www.rfc-editor.org/info/rfc9849
+ seriesinfo:
+ RFC: PRE-RFC9849
+ DOI: 10.17487/preRFC9849
+ date: December 2025
+ author:
+ -
+ ins: E. Rescorla
+ surname: Rescorla
+ fullname: Eric Rescorla
+ -
+ ins: K. Oku
+ surname: Oku
+ fullname: Kazuho Oku
+ -
+ ins: N. Sullivan
+ surname: Sullivan
+ fullname: Nick Sullivan
+ -
+ ins: C. A. Wood
+ surname: Wood
+ fullname: Christopher A. Wood
--- abstract
+
+
+
+
+
+
+
+
+
+
+
+
This 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,
@@ -431,16 +528,8 @@ RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies
new requirements for TLS 1.2 implementations.
--- middle
-
-
# Introduction
-RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH
-The source for this draft is maintained in GitHub. Suggested changes
-should be submitted as pull requests at
-https://github.com/ekr/tls13-spec. Instructions are on that page as
-well.
-
The primary goal of TLS is to provide a secure channel between two
communicating peers; the only requirement from the underlying
transport is a reliable, in-order data stream. Specifically, the
@@ -511,29 +600,33 @@ and obsoletes {{RFC6961}} as described in {{ocsp-and-sct}}.
## Conventions and Terminology
-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.
+{::boilerplate bcp14-tagged}
The following terms are used:
-client: The endpoint initiating the TLS connection.
+client:
+: The endpoint initiating the TLS connection.
-connection: A transport-layer connection between two endpoints.
+connection:
+: A transport-layer connection between two endpoints.
-endpoint: Either the client or server of the connection.
+endpoint:
+: Either the client or server of the connection.
-handshake: An initial negotiation between client and server that establishes the parameters of their subsequent interactions within TLS.
+handshake:
+: An initial negotiation between client and server that establishes the parameters of their subsequent interactions within TLS.
-peer: An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is not the primary subject of discussion.
+peer:
+: An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is not the primary subject of discussion.
-receiver: An endpoint that is receiving records.
+receiver:
+: An endpoint that is receiving records.
-sender: An endpoint that is transmitting records.
-
-server: The endpoint that did not initiate the TLS connection.
+sender:
+: An endpoint that is transmitting records.
+server:
+: The endpoint that did not initiate the TLS connection.
## Relationship to RFC 8446
@@ -546,6 +639,20 @@ editorial improvements. In addition, it removes the use of the term
names where no term was necessary. This document makes the following
specific technical changes:
+
+
+
+
- Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by {{!RFC8996}}.
- Removes ambiguity around which hash is used with PreSharedKeys and
@@ -575,7 +682,6 @@ specific technical changes:
In addition, there have been some improvements to the
security considerations, especially around privacy.
-
## Major Differences from TLS 1.2
The following is a list of the major functional differences between
@@ -610,12 +716,12 @@ are many minor differences.
be more consistent and to remove superfluous messages such as
ChangeCipherSpec (except when needed for middlebox compatibility).
-- Elliptic curve algorithms are now in the base spec and new signature
+- Elliptic curve algorithms are now in the base specification, and new signature
algorithms, such as EdDSA, are included. TLS 1.3 removed point format
negotiation in favor of a single point format for each curve.
- Other cryptographic improvements were made, including changing the RSA padding to use
- the RSA Probabilistic Signature Scheme (RSASSA-PSS), and the removal
+ the RSA Probabilistic Signature Scheme (RSASSA-PSS) and the removal
of compression, the Digital Signature Algorithm (DSA), and
custom Ephemeral Diffie-Hellman (DHE) groups.
@@ -630,7 +736,6 @@ are many minor differences.
- References have been updated to point to the updated versions of RFCs, as
appropriate (e.g., RFC 5280 rather than RFC 3280).
-
## Updates Affecting TLS 1.2
This document defines several changes that optionally affect
@@ -681,27 +786,31 @@ TLS supports three basic key exchange modes:
{{tls-full}} below shows the basic full TLS handshake:
+
+
~~~ aasvg
- Client Server
+ Client Server
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
- v + pre_shared_key* -------->
- ServerHello ^ Key
- + key_share* | Exch
- + pre_shared_key* v
- {EncryptedExtensions} ^ Server
- {CertificateRequest*} v Params
- {Certificate*} ^
- {CertificateVerify*} | Auth
- {Finished} v
- <-------- [Application Data*]
+ v + pre_shared_key* -------->
+ ServerHello ^ Key
+ + key_share* | Exch
+ + pre_shared_key* v
+ {EncryptedExtensions} ^ Server
+ {CertificateRequest*} v Params
+ {Certificate*} ^
+ {CertificateVerify*} | Auth
+ {Finished} v
+ <-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
- v {Finished} -------->
- [Application Data] <-------> [Application Data]
+ v {Finished} -------->
+ [Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the
previously noted message.
@@ -717,6 +826,13 @@ Auth | {CertificateVerify*}
~~~
{: #tls-full title="Message Flow for Full TLS Handshake"}
+
+
The handshake can be thought of as having three phases (indicated
in the diagram above):
@@ -758,12 +874,12 @@ The server then sends two messages to establish the Server Parameters:
EncryptedExtensions:
: responses to ClientHello extensions that are not required to
determine the cryptographic parameters, other than those
- that are specific to individual certificates. \[{{encrypted-extensions}}]
+ that are specific to individual certificates. [{{encrypted-extensions}}]
CertificateRequest:
: if certificate-based client authentication is desired, the
desired parameters for that certificate. This message is
- omitted if client authentication is not desired. \[{{certificate-request}}]
+ omitted if client authentication is not desired. [{{certificate-request}}]
Finally, the client and server exchange Authentication messages. TLS
uses the same set of messages every time that certificate-based
@@ -780,19 +896,20 @@ Certificate:
public keys {{RFC7250}} or the cached information extension
{{?RFC7924}} are in use, then this message will not
contain a certificate but rather some other value corresponding to
- the server's long-term key. \[{{certificate}}]
+ the server's long-term key. [{{certificate}}]
CertificateVerify:
: A signature over the entire handshake using the private key
corresponding to the public key in the Certificate message. This
message is omitted if the endpoint is not authenticating via a
- certificate. \[{{certificate-verify}}]
+ certificate. [{{certificate-verify}}]
Finished:
: A MAC (Message Authentication Code) over the entire handshake.
- This message provides key confirmation for the shared secrets established in the handshake
+ This message provides key confirmation for the shared secrets established in
+ the handshake
binds the endpoint's identity to the exchanged keys, and in PSK mode
- also authenticates the handshake. \[{{finished}}]
+ also authenticates the handshake. [{{finished}}]
{:br }
Upon receiving the server's messages, the client responds with its Authentication
@@ -820,26 +937,26 @@ If no common cryptographic parameters can be negotiated,
the server MUST abort the handshake with an appropriate alert.
~~~ aasvg
- Client Server
-
- ClientHello
- + key_share -------->
- HelloRetryRequest
- <-------- + key_share
- ClientHello
- + key_share -------->
- ServerHello
- + key_share
- {EncryptedExtensions}
- {CertificateRequest*}
- {Certificate*}
- {CertificateVerify*}
- {Finished}
- <-------- [Application Data*]
- {Certificate*}
- {CertificateVerify*}
- {Finished} -------->
- [Application Data] <-------> [Application Data]
+ Client Server
+
+ ClientHello
+ + key_share -------->
+ HelloRetryRequest
+ <-------- + key_share
+ ClientHello
+ + key_share -------->
+ ServerHello
+ + key_share
+ {EncryptedExtensions}
+ {CertificateRequest*}
+ {Certificate*}
+ {CertificateVerify*}
+ {Finished}
+ <-------- [Application Data*]
+ {Certificate*}
+ {CertificateVerify*}
+ {Finished} -------->
+ [Application Data] <-------> [Application Data]
~~~
{: #tls-restart title="Message Flow for a Full Handshake with Mismatched Parameters"}
@@ -924,16 +1041,15 @@ When PSKs are provisioned externally, the PSK identity and the KDF hash
algorithm to
be used with the PSK MUST also be provisioned.
-Note:
-: When using an externally provisioned pre-shared secret, a critical
- consideration is using sufficient entropy during the key generation, as
- discussed in [RFC4086]. Deriving a shared secret from a password or other
- low-entropy sources is not secure. A low-entropy secret, or password, is
- subject to dictionary attacks based on the PSK binder. The specified PSK
- authentication is not a strong password-based authenticated key exchange even
- when used with Diffie-Hellman key establishment. Specifically, it does not
- prevent an attacker that can observe the handshake from performing
- a brute-force attack on the password/pre-shared key.
+Note: When using an externally provisioned pre-shared secret, a critical
+consideration is using sufficient entropy during the key generation, as
+discussed in {{RFC4086}}. Deriving a shared secret from a password or other
+low-entropy sources is not secure. A low-entropy secret, or password, is
+subject to dictionary attacks based on the PSK binder. The specified PSK
+authentication is not a strong password-based authenticated key exchange even
+when used with Diffie-Hellman key establishment. Specifically, it does not
+prevent an attacker that can observe the handshake from performing
+a brute-force attack on the password/pre-shared key.
## 0-RTT Data {#zero-rtt-data}
@@ -948,39 +1064,39 @@ handshake in the first flight. The rest of the handshake uses the same messages
as for a 1-RTT handshake with PSK resumption.
~~~ aasvg
- Client Server
-
- ClientHello
- + early_data
- + key_share*
- + psk_key_exchange_modes
- + pre_shared_key
- (Application Data*) -------->
- ServerHello
- + pre_shared_key
- + key_share*
- {EncryptedExtensions}
- + early_data*
- {Finished}
- <-------- [Application Data*]
- (EndOfEarlyData)
- {Finished} -------->
- [Application Data] <-------> [Application Data]
-
- + Indicates noteworthy extensions sent in the
- previously noted message.
-
- * Indicates optional or situation-dependent
- messages/extensions that are not always sent.
-
- () Indicates messages protected using keys
- derived from a client_early_traffic_secret.
-
- {} Indicates messages protected using keys
- derived from a [sender]_handshake_traffic_secret.
-
- [] Indicates messages protected using keys
- derived from [sender]_application_traffic_secret_N.
+ Client Server
+
+ ClientHello
+ + early_data
+ + key_share*
+ + psk_key_exchange_modes
+ + pre_shared_key
+ (Application Data*) -------->
+ ServerHello
+ + pre_shared_key
+ + key_share*
+ {EncryptedExtensions}
+ + early_data*
+ {Finished}
+ <-------- [Application Data*]
+ (EndOfEarlyData)
+ {Finished} -------->
+ [Application Data] <-------> [Application Data]
+
+ + Indicates noteworthy extensions sent in the
+ previously noted message.
+
+ * Indicates optional or situation-dependent
+ messages/extensions that are not always sent.
+
+ () Indicates messages protected using keys
+ derived from a client_early_traffic_secret.
+
+ {} Indicates messages protected using keys
+ derived from a [sender]_handshake_traffic_secret.
+
+ [] Indicates messages protected using keys
+ derived from [sender]_application_traffic_secret_N.
~~~
{: #tls-0-rtt title="Message Flow for a 0-RTT Handshake"}
@@ -995,6 +1111,7 @@ as part of the protocol. Therefore, absent out-of-band knowledge of the
server's behavior, the client should assume that this data is not forward
secret.
+
2. There are no guarantees of non-replay between connections.
Protection against replay for ordinary TLS 1.3 1-RTT data is
provided via the server's Random value, but 0-RTT data does not depend
@@ -1021,7 +1138,6 @@ be used.
In the definitions below, optional components of this syntax are denoted by
enclosing them in "\[\[ \]\]" (double brackets).
-
## Basic Block Size
The representation of all data items is explicitly specified. The basic data
@@ -1239,27 +1355,17 @@ of a connection. Handshake messages are supplied to the TLS record layer, where
they are encapsulated within one or more TLSPlaintext or TLSCiphertext structures which are
processed and transmitted as specified by the current active connection state.
-%%% Handshake Protocol
enum {
- hello_request_RESERVED(0),
client_hello(1),
server_hello(2),
- hello_verify_request_RESERVED(3),
new_session_ticket(4),
end_of_early_data(5),
- hello_retry_request_RESERVED(6),
encrypted_extensions(8),
certificate(11),
- server_key_exchange_RESERVED(12),
certificate_request(13),
- server_hello_done_RESERVED(14),
certificate_verify(15),
- client_key_exchange_RESERVED(16),
finished(20),
- certificate_url_RESERVED(21),
- certificate_status_RESERVED(22),
- supplemental_data_RESERVED(23),
key_update(24),
message_hash(254),
(255)
@@ -1399,21 +1505,22 @@ previous protocol version. In particular, it MUST NOT negotiate TLS 1.3.
Structure of this message:
-%%% Key Exchange Messages
-
- uint16 ProtocolVersion;
- opaque Random[32];
-
- uint8 CipherSuite[2]; /* Cryptographic suite selector */
-
- struct {
- ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
- Random random;
- opaque legacy_session_id<0..32>;
- CipherSuite cipher_suites<2..2^16-2>;
- opaque legacy_compression_methods<1..2^8-1>;
- Extension extensions<8..2^16-1>;
- } ClientHello;
+~~~
+ uint16 ProtocolVersion;
+ opaque Random[32];
+
+ uint8 CipherSuite[2]; /* Cryptographic suite selector */
+
+ struct {
+ ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
+ Random random;
+ opaque legacy_session_id<0..32>;
+ CipherSuite cipher_suites<2..2^16-2>;
+ opaque legacy_compression_methods<1..2^8-1>;
+ Extension extensions<8..2^16-1>;
+ } ClientHello;
+~~~
+{: gi="sourcecode"}
legacy_version:
: In previous versions of TLS, this field was used for version negotiation
@@ -1519,16 +1626,17 @@ set of handshake parameters based on the ClientHello.
Structure of this message:
-%%% Key Exchange Messages
-
- struct {
- ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
- Random random;
- opaque legacy_session_id_echo<0..32>;
- CipherSuite cipher_suite;
- uint8 legacy_compression_method = 0;
- Extension extensions<6..2^16-1>;
- } ServerHello;
+~~~
+ struct {
+ ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
+ Random random;
+ opaque legacy_session_id_echo<0..32>;
+ CipherSuite cipher_suite;
+ uint8 legacy_compression_method = 0;
+ Extension extensions<6..2^16-1>;
+ } ServerHello;
+~~~
+{: gi="sourcecode"}
legacy_version:
: In previous versions of TLS, this field was used for version negotiation
@@ -1577,7 +1685,7 @@ extensions:
which are required to establish the cryptographic context and negotiate
the protocol version. All TLS 1.3 ServerHello messages MUST contain the
"supported_versions" extension. Current ServerHello messages additionally contain
- either the "pre_shared_key" extension or the "key_share" extension, or both (when using
+ the "pre_shared_key" extension or the "key_share" extension, or both (when using
a PSK with (EC)DHE key establishment). Other extensions
(see {{extensions}}) are sent
separately in the EncryptedExtensions message.
@@ -1594,7 +1702,7 @@ Random set to the special value of the SHA-256 of
Upon receiving a message with type server_hello, implementations
MUST first examine the Random value and, if it matches
-this value, process it as described in {{hello-retry-request}}).
+this value, process it as described in {{hello-retry-request}}.
TLS 1.3 has a downgrade protection mechanism embedded in the server's
random value. TLS 1.3 servers which negotiate TLS 1.2 or below in
@@ -1701,7 +1809,6 @@ handshake with an "illegal_parameter" alert if the value changes.
A number of TLS messages contain tag-length-value encoded extensions structures.
-%%% Key Exchange Messages
struct {
ExtensionType extension_type;
@@ -1781,44 +1888,64 @@ it recognizes and which is not specified for the message in which it
appears, it MUST abort the handshake with an "illegal_parameter" alert.
+
+
| Extension | TLS 1.3 |
|:-----------------------------------------|------------:|
-| server_name [RFC6066] | CH, EE |
-| max_fragment_length [RFC6066] | CH, EE |
-| status_request [RFC6066] | CH, CR, CT |
-| supported_groups [RFC7919] | CH, EE |
-| signature_algorithms [RFC8446] | CH, CR |
-| use_srtp [RFC5764] | CH, EE |
-| heartbeat [RFC6520] | CH, EE |
-| application_layer_protocol_negotiation [RFC7301]| CH, EE |
-| signed_certificate_timestamp [RFC6962] | CH, CR, CT |
-| client_certificate_type [RFC7250] | CH, EE |
-| server_certificate_type [RFC7250] | CH, EE |
-| padding [RFC7685] | CH |
-| cached_info [RFC7924] | CH, EE |
-| compress_certificate [RFC8879] | CH, CR |
-| record_size_limit [RFC8849] | CH, EE |
-| delegated_credentials [RFC9345] | CH, CR, CT |
-| supported_ekt_ciphers [RFC8870] | CH, EE |
-| pre_shared_key [RFC8446] | CH, SH |
-| early_data [RFC8446] | CH, EE, NST |
-| psk_key_exchange_modes [RFC8446]| CH |
-| cookie [RFC8446] | CH, HRR |
-| supported_versions [RFC8446] | CH, SH, HRR |
-| certificate_authorities [RFC8446]| CH, CR |
-| oid_filters [RFC8446] | CR |
-| post_handshake_auth [RFC8446] | CH |
-| signature_algorithms_cert [RFC8446]| CH, CR |
-| key_share [RFC8446] | CH, SH, HRR |
-| transparency_info [RFC9162] | CH, CR, CT |
-| connection_id [RFC9146] | CH, SH |
-| external_id_hash [RFC8844] | CH, EE |
-| external_session_id [RFC8844] | CH, EE |
-| quic_transport_parameters [RFC9001] | CH, EE |
-| ticket_request [RFC9149] | CH, EE|
+| server_name {{RFC6066}} | CH, EE |
+| max_fragment_length {{RFC6066}} | CH, EE |
+| status_request {{RFC6066}} | CH, CR, CT |
+| supported_groups {{RFC7919}} | CH, EE |
+| signature_algorithms {{RFC8446}} | CH, CR |
+| use_srtp {{RFC5764}} | CH, EE |
+| heartbeat {{RFC6520}} | CH, EE |
+| application_layer_protocol_negotiation {{RFC7301}}| CH, EE |
+| signed_certificate_timestamp {{RFC6962}} | CH, CR, CT |
+| client_certificate_type {{RFC7250}} | CH, EE |
+| server_certificate_type {{RFC7250}} | CH, EE |
+| padding {{RFC7685}} | CH |
+| cached_info {{RFC7924}} | CH, EE |
+| compress_certificate {{RFC8879}} | CH, CR |
+| record_size_limit {{RFC8449}} | CH, EE |
+| delegated_credentials {{RFC9345}} | CH, CR, CT |
+| supported_ekt_ciphers {{RFC8870}} | CH, EE |
+| pre_shared_key {{RFC8446}} | CH, SH |
+| early_data {{RFC8446}} | CH, EE, NST |
+| psk_key_exchange_modes {{RFC8446}}| CH |
+| cookie {{RFC8446}} | CH, HRR |
+| supported_versions {{RFC8446}} | CH, SH, HRR |
+| certificate_authorities {{RFC8446}}| CH, CR |
+| oid_filters {{RFC8446}} | CR |
+| post_handshake_auth {{RFC8446}} | CH |
+| signature_algorithms_cert {{RFC8446}}| CH, CR |
+| key_share {{RFC8446}} | CH, SH, HRR |
+| transparency_info {{RFC9162}} | CH, CR, CT |
+| connection_id {{RFC9146}} | CH, SH |
+| external_id_hash {{RFC8844}} | CH, EE |
+| external_session_id {{RFC8844}} | CH, EE |
+| quic_transport_parameters {{RFC9001}} | CH, EE |
+| ticket_request {{RFC9149}} | CH, EE|
{: #extensions-list title="TLS Extensions"}
-Note: this table includes only extensions marked
+Note: This table includes only extensions marked
"Recommended" at the time of this writing.
When multiple extensions of different types are present, the
@@ -1858,7 +1985,6 @@ be taken into account when designing new extensions:
### Supported Versions
-%%% Version Extension
struct {
select (Handshake.msg_type) {
@@ -1909,7 +2035,7 @@ extension. A server which negotiates TLS 1.3 MUST respond by sending a
After checking ServerHello.random to determine if the server handshake message
is a ServerHello or HelloRetryRequest, clients MUST check for this extension
prior to processing the rest of the ServerHello. This will require clients to
-parse the ServerHello to read the extension.
+parse the ServerHello to read the extension.
If this extension is present, clients MUST ignore the
ServerHello.legacy_version value and MUST use only the
"supported_versions" extension to determine the selected version. If the
@@ -1920,7 +2046,6 @@ client or contains a version prior to TLS 1.3, the client MUST abort the handsha
### Cookie
-%%% Cookie Extension
struct {
opaque cookie<1..2^16-1>;
@@ -1978,7 +2103,6 @@ MAY omit the "signature_algorithms_cert" extension.
The "extension_data" field of these extensions contains a
SignatureSchemeList value:
-%%% Signature Algorithm Extension
enum {
/* RSASSA-PKCS1-v1_5 algorithms */
@@ -2010,15 +2134,6 @@ SignatureSchemeList value:
ecdsa_sha1(0x0203),
/* Reserved Code Points */
- obsolete_RESERVED(0x0000..0x0200),
- dsa_sha1_RESERVED(0x0202),
- obsolete_RESERVED(0x0204..0x0400),
- dsa_sha256_RESERVED(0x0402),
- obsolete_RESERVED(0x0404..0x0500),
- dsa_sha384_RESERVED(0x0502),
- obsolete_RESERVED(0x0504..0x0600),
- dsa_sha512_RESERVED(0x0602),
- obsolete_RESERVED(0x0604..0x06FF),
private_use(0xFE00..0xFFFF),
(0xFFFF)
} SignatureScheme;
@@ -2098,7 +2213,7 @@ Legacy algorithms:
The signatures on certificates that are self-signed or certificates that are
trust anchors are not validated, since they begin a certification path (see
-{{RFC5280}}, Section 3.2). A certificate that begins a certification
+{{RFC5280, Section 3.2}}). A certificate that begins a certification
path MAY use a signature algorithm that is not advertised as being supported
in the "signature_algorithms" and "signature_algorithms_cert" extensions.
@@ -2134,7 +2249,6 @@ be used by the receiving endpoint to guide certificate selection.
The body of the "certificate_authorities" extension consists of a
CertificateAuthoritiesExtension structure.
-%%% Server Parameters Messages
opaque DistinguishedName<1..2^16-1>;
@@ -2164,7 +2278,6 @@ The "oid_filters" extension allows servers to provide a list of OID/value
pairs which it would like the client's certificate to match. This
extension, if provided by the server, MUST only be sent in the CertificateRequest message.
-%%% Server Parameters Messages
struct {
opaque certificate_extension_oid<1..2^8-1>;
@@ -2220,7 +2333,6 @@ to perform post-handshake authentication ({{post-handshake-authentication}}). Se
MUST NOT send a post-handshake CertificateRequest to clients which do not
offer this extension. Servers MUST NOT send this extension.
-%%% Server Parameters Messages
struct {} PostHandshakeAuth;
@@ -2241,15 +2353,11 @@ ECDSA curves. Signature algorithms are now negotiated independently (see
The "extension_data" field of this extension contains a
"NamedGroupList" value:
-%%% Supported Groups Extension
enum {
- unallocated_RESERVED(0x0000),
/* Elliptic Curve Groups (ECDHE) */
- obsolete_RESERVED(0x0001..0x0016),
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
- obsolete_RESERVED(0x001A..0x001C),
x25519(0x001D), x448(0x001E),
/* Finite Field Groups (DHE) */
@@ -2259,7 +2367,6 @@ The "extension_data" field of this extension contains a
/* Reserved Code Points */
ffdhe_private_use(0x01FC..0x01FF),
ecdhe_private_use(0xFE00..0xFEFF),
- obsolete_RESERVED(0xFF01..0xFF02),
(0xFFFF)
} NamedGroup;
@@ -2304,7 +2411,6 @@ Clients MAY send an empty client_shares list to request
group selection from the server, at the cost of an additional round trip
(see {{hello-retry-request}}).
-%%% Key Exchange Messages
struct {
NamedGroup group;
@@ -2327,7 +2433,6 @@ key_exchange:
In the ClientHello message, the "extension_data" field of this extension
contains a "KeyShareClientHello" value:
-%%% Key Exchange Messages
struct {
KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;
@@ -2352,7 +2457,7 @@ though saving the round trip of HelloRetryRequest. Servers
that wish to respect the client's group preferences SHOULD first
select a group based on "supported_groups" and then either send a
ServerHello or a HelloRetryRequest depending on the contents of
-KeyshareClienthello.
+KeyshareClienthello.
Clients can offer as many KeyShareEntry values as the number of supported
groups it is offering, each
@@ -2369,7 +2474,6 @@ if one is violated.
In a HelloRetryRequest message, the "extension_data" field of this
extension contains a KeyShareHelloRetryRequest value:
-%%% Key Exchange Messages
struct {
NamedGroup selected_group;
} KeyShareHelloRetryRequest;
@@ -2393,7 +2497,6 @@ selected_group field of the triggering HelloRetryRequest.
In a ServerHello message, the "extension_data" field of this
extension contains a KeyShareServerHello value:
-%%% Key Exchange Messages
struct {
KeyShareEntry server_share;
} KeyShareServerHello;
@@ -2421,7 +2524,7 @@ alert.
Diffie-Hellman {{DH76}} parameters for both clients and servers are encoded in
the opaque key_exchange field of a KeyShareEntry in a KeyShare structure.
The opaque value contains the
-Diffie-Hellman public value (Y = g^X mod p) for the specified group
+Diffie-Hellman public value (Y = gX mod p) for the specified group
(see {{RFC7919}} for group definitions)
encoded as a big-endian integer and padded to the left with zeros to the size of p in
bytes.
@@ -2441,7 +2544,6 @@ opaque key_exchange field of a KeyShareEntry in a KeyShare structure.
For secp256r1, secp384r1, and secp521r1, the contents are the serialized
value of the following struct:
-%%% Key Exchange Messages
struct {
uint8 legacy_form = 4;
@@ -2469,7 +2571,7 @@ equation. For these curves, implementors do not need to verify
membership in the correct subgroup.
For X25519 and X448, the content of the public value is the K_A
-or K_B value described in Section 6 of {{RFC7748}}.
+or K_B value described in {{Section 6 of RFC7748}}.
This is 32 bytes for X25519 and 56 bytes for X448.
Note: Versions of TLS prior to 1.3 permitted point format negotiation;
@@ -2495,7 +2597,6 @@ will just be that the client's attempts at resumption fail.
The server MUST NOT send a "psk_key_exchange_modes" extension.
-%%% Key Exchange Messages
enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
@@ -2528,7 +2629,6 @@ supply both the "pre_shared_key" and "early_data" extensions.
The "extension_data" field of this extension contains an
"EarlyDataIndication" value.
-%%% Key Exchange Messages
struct {} Empty;
@@ -2553,7 +2653,7 @@ MUST be the first PSK listed in the client's "pre_shared_key" extension.
For PSKs provisioned via NewSessionTicket, a server MUST validate that
the ticket age for the selected PSK identity (computed by subtracting
-ticket_age_add from PskIdentity.obfuscated_ticket_age modulo 2^32)
+ticket_age_add from PskIdentity.obfuscated_ticket_age modulo 232)
is within a small tolerance of the
time since the ticket was issued (see {{anti-replay}}). If it is not,
the server SHOULD proceed with the handshake but reject 0-RTT, and
@@ -2647,7 +2747,6 @@ with PSK key establishment.
The "extension_data" field of this extension contains a
"PreSharedKeyExtension" value:
-%%% Key Exchange Messages
struct {
opaque identity<1..2^16-1>;
@@ -2705,7 +2804,7 @@ is defined. The server MUST ensure that it selects a compatible
PSK (if any) and cipher suite.
In TLS versions prior to TLS 1.3, the Server Name Indication (SNI) value was
-intended to be associated with the session (Section 3 of {{RFC6066}}), with the
+intended to be associated with the session ({{Section 3 of RFC6066}}), with the
server being required to enforce that the SNI value associated with the session
matches the one specified in the resumption handshake. However, in reality the
implementations were not consistent on which of two supplied SNI values they
@@ -2763,7 +2862,7 @@ tickets which have ages greater than the "ticket_lifetime" value which
was provided with the ticket. The "obfuscated_ticket_age" field of
each PskIdentity contains an obfuscated version of the ticket age
formed by taking the age in milliseconds and adding the "ticket_age_add"
-value that was included with the ticket (see {{NSTMessage}}), modulo 2^32.
+value that was included with the ticket (see {{NSTMessage}}), modulo 232.
This addition prevents passive observers from correlating connections
unless tickets or key shares are reused. Note that the "ticket_lifetime" field in
the NewSessionTicket message is in seconds but the "obfuscated_ticket_age"
@@ -2852,11 +2951,12 @@ extensions and if any are found MUST abort the handshake with an
Structure of this message:
-%%% Server Parameters Messages
-
- struct {
- Extension extensions<0..2^16-1>;
- } EncryptedExtensions;
+~~~
+ struct {
+ Extension extensions<0..2^16-1>;
+ } EncryptedExtensions;
+~~~
+{: gi="sourcecode"}
extensions:
: A list of extensions. For more information, see the table in {{extensions}}.
@@ -2870,12 +2970,13 @@ follow EncryptedExtensions.
Structure of this message:
-%%% Server Parameters Messages
-
- struct {
- opaque certificate_request_context<0..2^8-1>;
- Extension extensions<0..2^16-1>;
- } CertificateRequest;
+~~~
+ struct {
+ opaque certificate_request_context<0..2^8-1>;
+ Extension extensions<0..2^16-1>;
+ } CertificateRequest;
+~~~
+{: gi="sourcecode"}
certificate_request_context:
: An opaque string which identifies the certificate request and
@@ -2911,13 +3012,13 @@ Servers which are authenticating with a resumption PSK MUST NOT send the
CertificateRequest message in the main handshake, though they
MAY send it in post-handshake authentication (see {{post-handshake-authentication}})
provided that the client has sent the "post_handshake_auth"
-extension (see {{post_handshake_auth}}).
-In the absence of some other specification to the contrary,
+extension (see {{post_handshake_auth}}).
+ In the absence of some other specification to the contrary,
servers which are authenticating with an external PSK
-MUST NOT send the CertificateRequest message either in the main handshake
+MUST NOT send the CertificateRequest message in the main handshake
or request post-handshake authentication.
-{{RFC8773}} provides an extension to permit this,
-but has received less analysis than this specification.
+{{RFC8773}} provides an extension to permit this
+but has received less analysis than this specification.
## Authentication Messages
@@ -2930,9 +3031,9 @@ messages are always sent as the last messages in their handshake
flight. The Certificate and CertificateVerify messages are only
sent under certain circumstances, as defined below. The Finished
message is always sent as part of the Authentication Block.
-These messages are encrypted under keys derived from the
-\[sender]_handshake_traffic_secret,
-except for post-handshake authentication.
+ These messages are encrypted under keys derived from the
+\[sender\]_handshake_traffic_secret,
+except for post-handshake authentication.
The computations for the Authentication messages all uniformly
take the following inputs:
@@ -2944,20 +3045,22 @@ take the following inputs:
Based on these inputs, the messages then contain:
-Certificate
+Certificate:
: The certificate to be used for authentication, and any
supporting certificates in the chain. Note that certificate-based
client authentication is not available in PSK handshake flows
(including 0-RTT).
CertificateVerify:
-: A signature over the value Transcript-Hash(Handshake Context, Certificate)
+: A signature over the value Transcript-Hash(Handshake Context, Certificate).
Finished:
: A MAC over the value Transcript-Hash(Handshake Context, Certificate, CertificateVerify)
using a MAC key derived from the Base Key.
{:br}
+
The following table defines the Handshake Context and MAC Base Key
for each scenario:
@@ -2966,7 +3069,7 @@ for each scenario:
|------|-------------------|----------|
| Server | ClientHello ... later of EncryptedExtensions/CertificateRequest | server_handshake_traffic_secret |
| Client | ClientHello ... later of server Finished/EndOfEarlyData | client_handshake_traffic_secret |
-| Post-Handshake | ClientHello ... client Finished + CertificateRequest | [sender]_application_traffic_secret_N |
+| Post-Handshake | ClientHello ... client Finished + CertificateRequest | \[sender\]_application_traffic_secret_N |
{: #hs-ctx-and-keys title="Authentication Inputs"}
### The Transcript Hash
@@ -3004,8 +3107,8 @@ server CertificateVerify, server Finished, EndOfEarlyData, client
Certificate, client CertificateVerify, and client Finished.
In general, implementations can implement the transcript by keeping a
-running transcript hash value based on the negotiated hash. Note,
-however, that subsequent post-handshake authentications do not include
+running transcript hash value based on the negotiated hash. Note, however,
+that subsequent post-handshake authentications do not include
each other, just the messages through the end of the main handshake.
### Certificate
@@ -3026,11 +3129,9 @@ be sent regardless of whether the Certificate message is empty.
Structure of this message:
-%%% Authentication Messages
-
+~~~
enum {
X509(0),
- OpenPGP_RESERVED(1),
RawPublicKey(2),
(255)
} CertificateType;
@@ -3051,6 +3152,8 @@ Structure of this message:
opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
+~~~
+{: gi="sourcecode"}
certificate_request_context:
: If this message is in response to a CertificateRequest, the
@@ -3096,8 +3199,8 @@ version, with the exception of the end-entity certificate which MUST be first.
If the RawPublicKey certificate type was negotiated, then the
certificate_list MUST contain no more than one CertificateEntry, which
-contains an ASN1_subjectPublicKeyInfo value as defined in {{RFC7250}},
-Section 3.
+contains an ASN1_subjectPublicKeyInfo value as defined in {{RFC7250,
+Section 3}}.
The OpenPGP certificate type {{RFC6091}} MUST NOT be used with TLS 1.3.
@@ -3181,7 +3284,7 @@ to be supported by the client.
This fallback chain MUST NOT use the deprecated SHA-1 hash,
unless the client specifically advertises that it is willing to accept SHA-1.
-If the sender is the client, the client MAY use a fallback chain as above, or
+If the sender is the client, the client MAY use a fallback chain as above or
continue the handshake anonymously.
If the receiver cannot construct an acceptable chain using the provided
@@ -3190,7 +3293,7 @@ handshake with an appropriate certificate-related alert (by default,
"unsupported_certificate"; see {{error-alerts}} for more information).
If the sender has multiple certificates, it chooses one of them based on the
-above-mentioned criteria (in addition to other criteria, such as transport-layer endpoint, local configuration, and preferences).
+above-mentioned criteria (in addition to other criteria, such as transport-layer endpoint, local configuration, and preferences).
#### Receiving a Certificate Message
@@ -3237,12 +3340,13 @@ after the Certificate message and immediately prior to the Finished message.
Structure of this message:
-%%% Authentication Messages
-
- struct {
- SignatureScheme algorithm;
- opaque signature<0..2^16-1>;
- } CertificateVerify;
+~~~
+ struct {
+ SignatureScheme algorithm;
+ opaque signature<0..2^16-1>;
+ } CertificateVerify;
+~~~
+{: gi="sourcecode"}
The algorithm field specifies the signature algorithm used (see
{{signature-algorithms}} for the definition of this type). The
@@ -3266,9 +3370,9 @@ prefix (ClientHello.random). The initial 64-byte pad clears that prefix
along with the server-controlled ServerHello.random.
The context string for a server signature is
-"TLS 1.3, server CertificateVerify"
+"TLS 1.3, server CertificateVerify".
The context string for a client signature is
-"TLS 1.3, client CertificateVerify"
+"TLS 1.3, client CertificateVerify".
It is used to provide separation between signatures made in different
contexts, helping against potential cross-protocol attacks.
@@ -3337,6 +3441,7 @@ settings in which it is permitted to send data prior to
receiving the peer's Finished:
1. Clients sending 0-RTT data as described in {{early-data-indication}}.
+
2. Servers MAY send data after sending their first flight, but
because the handshake is not yet complete, they have no assurance
of either the peer's identity or its liveness (i.e.,
@@ -3350,24 +3455,39 @@ Base Key defined in {{authentication-messages}} using HKDF (see
finished_key =
HKDF-Expand-Label(BaseKey, "finished", "", Hash.length)
~~~
+{: gi="sourcecode"}
Structure of this message:
-%%% Authentication Messages
+~~~
+ struct {
+ opaque verify_data[Hash.length];
+ } Finished;
+~~~
+{: gi="sourcecode"}
- struct {
- opaque verify_data[Hash.length];
- } Finished;
+The verify_data value is computed as follows:
+
+~~~
+ verify_data =
+ HMAC(finished_key,
+ Transcript-Hash(Handshake Context,
+ Certificate*, CertificateVerify*))
+~~~
+{: gi="sourcecode"}
+
+
+* Only included if present.
HMAC {{RFC2104}} uses the Hash algorithm for the handshake.
As noted above, the HMAC input can generally be implemented by a running
@@ -3387,7 +3507,6 @@ server in response to client Certificate and CertificateVerify messages.
## End of Early Data
-%%% Updating Keys
struct {} EndOfEarlyData;
@@ -3410,7 +3529,7 @@ appropriate application traffic key.
### New Session Ticket Message {#NSTMessage}
-If the client's hello contained a suitable "psk_key_exchange_modes" extension,
+If the client's hello contained a suitable "psk_key_exchange_modes" extension
at any time after the server has received the client Finished message,
it MAY send a NewSessionTicket message. This message creates a unique
association between the ticket value and a secret PSK
@@ -3419,7 +3538,7 @@ derived from the resumption secret (see {{cryptographic-computations}}).
The client MAY use this PSK for future handshakes by including the
ticket value in the "pre_shared_key" extension in its ClientHello
({{pre-shared-key-extension}}).
-Clients which receive a NewSessionTicket message but do
+ Clients which receive a NewSessionTicket message but do
not support resumption MUST silently ignore this message.
Resumption MAY be done while the
original connection is still open. Servers MAY send multiple tickets on a
@@ -3464,7 +3583,6 @@ parallel and would benefit from the reduced overhead of a resumption
handshake, for example.
-%%% Ticket Establishment
struct {
uint32 ticket_lifetime;
@@ -3488,7 +3606,7 @@ ticket_lifetime:
ticket_age_add:
: A securely generated, random 32-bit value that is used to obscure the age of
the ticket that the client includes in the "pre_shared_key" extension.
- The client-side ticket age is added to this value modulo 2^32 to
+ The client-side ticket age is added to this value modulo 232 to
obtain the value that is transmitted by the client.
The server MUST generate a fresh value for each ticket it sends.
@@ -3527,6 +3645,7 @@ The PSK associated with the ticket is computed as:
HKDF-Expand-Label(resumption_secret,
"resumption", ticket_nonce, Hash.length)
~~~~
+{: gi="sourcecode"}
Because the ticket_nonce value is distinct for each NewSessionTicket
message, a different PSK will be derived for each ticket.
@@ -3578,7 +3697,6 @@ next generation of keys, computed as described in {{updating-traffic-keys}}.
Upon receiving a KeyUpdate, the receiver MUST update its receiving keys.
-%%% Updating Keys
enum {
update_not_requested(0), update_requested(1), (255)
@@ -3624,13 +3742,13 @@ a KeyUpdate with the old key is received before accepting any messages
encrypted with the new key. Failure to do so may allow message truncation
attacks.
-With a 128-bit key as in AES-128, rekeying 2^64 times has a high
+With a 128-bit key as in AES-128, rekeying 264 times has a high
probability of key reuse within a given connection. Note that even
if the key repeats, the IV is also independently generated, so the
chance of a joint key/IV collision is much lower.
To provide an extra margin of security, sending implementations MUST
NOT allow the epoch -- and hence the number of key updates --
-to exceed 2^48-1. In order to allow this value to be changed later
+to exceed 248-1. In order to allow this value to be changed later
-- for instance for ciphers with more than 128-bit keys --
receiving implementations MUST NOT enforce this
rule. If a sending implementation receives a KeyUpdate with
@@ -3638,7 +3756,7 @@ request_update set to "update_requested", it MUST NOT send its own
KeyUpdate if that would cause it to exceed these limits and SHOULD
instead ignore the "update_requested" flag. This may result in
an eventual need to terminate the connection when the
-limits in {{limits-on-key-usage}} are reached.
+limits described in {{limits-on-key-usage}} are reached.
# Record Protocol
@@ -3682,7 +3800,7 @@ are assigned by IANA in the TLS ContentType registry as described in
## Record Layer
The record layer fragments information blocks into TLSPlaintext
-records carrying data in chunks of 2^14 bytes or less. Message
+records carrying data in chunks of 214 bytes or less. Message
boundaries are handled differently depending on the underlying
ContentType. Any future content types MUST specify appropriate
rules.
@@ -3719,7 +3837,6 @@ useful as a traffic analysis countermeasure. Application Data fragments
MAY be split across multiple records or coalesced into a single record.
-%%% Record Layer
enum {
invalid(0),
@@ -3751,7 +3868,7 @@ legacy_record_version:
length:
: The length (in bytes) of the following TLSPlaintext.fragment. The
- length MUST NOT exceed 2^14 bytes. An endpoint that receives a record
+ length MUST NOT exceed 214 bytes. An endpoint that receives a record
that exceeds this length MUST terminate the connection with a
"record_overflow" alert.
@@ -3789,7 +3906,6 @@ operation which turns plaintext into authenticated ciphertext and
back again. Each encrypted record consists of a plaintext header followed
by an encrypted body, which itself contains a type and optional padding.
-%%% Record Layer
struct {
opaque content[TLSPlaintext.length];
@@ -3837,7 +3953,7 @@ length:
: The length (in bytes) of the following TLSCiphertext.encrypted_record, which
is the sum of the lengths of the content and the padding, plus one
for the inner content type, plus any expansion added by the AEAD algorithm.
- The length MUST NOT exceed 2^14 + 256 bytes.
+ The length MUST NOT exceed 214 + 256 bytes.
An endpoint that receives a record that exceeds this length MUST
terminate the connection with a "record_overflow" alert.
@@ -3847,8 +3963,8 @@ encrypted_record:
AEAD algorithms take as input a single key, a nonce, a plaintext, and "additional
-data" to be included in the authentication check, as described in Section 2.1
-of {{RFC5116}}. The key is either the client_write_key or the server_write_key,
+data" to be included in the authentication check, as described in {{Section 2.1
+of RFC5116}}. The key is either the client_write_key or the server_write_key,
the nonce is derived from the sequence number and the
client_write_iv or server_write_iv (see {{nonce}}), and the additional data input is the
record header. I.e.,
@@ -3879,18 +3995,18 @@ additional data, and the AEADEncrypted value. The output is either the plaintext
or an error indicating that the decryption failed. There is no separate
integrity check. Symbolically,
- plaintext of encrypted_record =
- AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted)
+ plaintext of encrypted_record =
+ AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted)
If the decryption fails, the receiver MUST terminate the connection
with a "bad_record_mac" alert.
An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion greater than
255 octets. An endpoint that receives a record from its peer with
-TLSCiphertext.length larger than 2^14 + 256 octets MUST terminate
+TLSCiphertext.length larger than 214 + 256 octets MUST terminate
the connection with a "record_overflow" alert.
This limit is derived from the maximum TLSInnerPlaintext length of
-2^14 octets + 1 octet for ContentType + the maximum AEAD expansion of 255 octets.
+214 octets + 1 octet for ContentType + the maximum AEAD expansion of 255 octets.
## Per-Record Nonce {#nonce}
@@ -3911,15 +4027,15 @@ terminate the connection.
Each AEAD algorithm will specify a range of possible lengths for the
per-record nonce, from N_MIN bytes to N_MAX bytes of input {{RFC5116}}.
The length of the TLS per-record nonce (iv_length) is set to the larger of
-8 bytes and N_MIN for the AEAD algorithm (see {{RFC5116}}, Section 4).
+8 bytes and N_MIN for the AEAD algorithm (see {{RFC5116, Section 4}}).
An AEAD algorithm where N_MAX is less than 8 bytes MUST NOT be used with TLS.
The per-record nonce for the AEAD construction is formed as follows:
- 1. The 64-bit record sequence number is encoded in network byte order
- and padded to the left with zeros to iv_length.
+1. The 64-bit record sequence number is encoded in network byte order
+ and padded to the left with zeros to iv_length.
- 2. The padded sequence number is XORed with either the static client_write_iv
- or server_write_iv (depending on the role).
+2. The padded sequence number is XORed with either the static client_write_iv
+ or server_write_iv (depending on the role).
The resulting quantity (of length iv_length) is used as the per-record nonce.
@@ -3964,7 +4080,7 @@ a non-zero octet in the cleartext, it MUST terminate the
connection with an "unexpected_message" alert.
The presence of padding does not change the overall record size limitations:
-the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 + 1 octets. If the
+the full encoded TLSInnerPlaintext MUST NOT exceed 214 + 1 octets. If the
maximum fragment length is reduced -- as for example by the record_size_limit
extension from {{?RFC8449}} -- then the reduced limit applies to the full plaintext,
including the content type and padding.
@@ -3987,14 +4103,14 @@ an analysis of these limits under the assumption that the underlying
primitive (AES or ChaCha20) has no weaknesses. Implementations MUST
either close the connection or
do a key update as described in {{key-update}} prior to reaching these limits.
-Note that it is not possible to perform a KeyUpdate for early data
-and therefore implementations MUST NOT exceed the limits
+Note that it is not possible to perform a KeyUpdate for early data;
+therefore, implementations MUST NOT exceed the limits
when sending early data. Receiving implementations SHOULD NOT enforce
-these limits, as future analyses may result in updated values.
+these limits, as future analyses may result in updated values.
-For AES-GCM, up to 2^24.5 full-size records (about 24 million)
+For AES-GCM, up to 224.5 full-size records (about 24 million)
may be encrypted on a given connection while keeping a safety
-margin of approximately 2^-57 for Authenticated Encryption (AE) security.
+margin of approximately 2-57 for Authenticated Encryption (AE) security.
For ChaCha20/Poly1305, the record sequence number would wrap before the
safety limit is reached.
@@ -4040,7 +4156,6 @@ but semantically invalid (e.g., a DHE share of p - 1, or an invalid
enum) MUST terminate the connection with an "illegal_parameter" alert.
-%%% Alert Messages
enum { warning(1), fatal(2), (255) } AlertLevel;
@@ -4048,11 +4163,8 @@ enum) MUST terminate the connection with an "illegal_parameter" alert.
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
- decryption_failed_RESERVED(21),
record_overflow(22),
- decompression_failure_RESERVED(30),
handshake_failure(40),
- no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
@@ -4063,19 +4175,15 @@ enum) MUST terminate the connection with an "illegal_parameter" alert.
access_denied(49),
decode_error(50),
decrypt_error(51),
- export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
inappropriate_fallback(86),
user_canceled(90),
- no_renegotiation_RESERVED(100),
missing_extension(109),
unsupported_extension(110),
- certificate_unobtainable_RESERVED(111),
unrecognized_name(112),
bad_certificate_status_response(113),
- bad_certificate_hash_value_RESERVED(114),
unknown_psk_identity(115),
certificate_required(116),
general_error(117),
@@ -4108,7 +4216,7 @@ user_canceled:
MUST be followed by a "close_notify". This alert generally
has AlertLevel=warning. Receiving implementations SHOULD
continue to read data from the peer until a "close_notify" is received,
- though they MAY log or otherwise record them.
+ though they MAY log or otherwise record them.
{:br }
Either party MAY initiate a close of its write side of the connection by
@@ -4129,7 +4237,7 @@ connection, though doing so would introduce the possibility of truncation.
Application protocols MAY choose to flush their send buffers and immediately
send a close_notify upon receiving a close_notify, but this allows an attacker
to influence the data that the peer receives by delaying the close_notify or
-by delaying the transport level delivery of the application's packets. These
+by delaying the transport-level delivery of the application's packets. These
issues can be addressed at the application layer, for instance by ignoring
packets received after transmitting the close_notify.
@@ -4183,8 +4291,8 @@ bad_record_mac:
record_overflow:
: A TLSCiphertext record was received that had a length more than
- 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record
- with more than 2^14 bytes (or some other negotiated limit).
+ 214 + 256 bytes, or a record decrypted to a TLSPlaintext record
+ with more than 214 bytes (or some other negotiated limit).
This alert should never be observed in communication between
proper implementations, except when messages were corrupted
in the network.
@@ -4267,6 +4375,20 @@ unsupported_extension:
in a ServerHello, HelloRetryRequest, EncryptedExtensions, or Certificate not first offered in the
corresponding ClientHello or CertificateRequest.
+
+
unrecognized_name:
: Sent by servers when no server exists identified by the name
provided by the client via the "server_name" extension
@@ -4295,8 +4417,8 @@ general_error:
no_application_protocol:
: Sent by servers when a client
- "application_layer_protocol_negotiation" extension advertises
- only protocols that the server does not support
+ "application_layer_protocol_negotiation" extension advertises only
+ protocols that the server does not support
(see {{RFC7301}}).
{:br }
@@ -4324,9 +4446,12 @@ defined below:
~~~~
HKDF-Expand-Label(Secret, Label, Context, Length) =
HKDF-Expand(Secret, HkdfLabel, Length)
+~~~~
+{: gi="sourcecode"}
- Where HkdfLabel is specified as:
+Where HkdfLabel is specified as:
+~~~~
struct {
uint16 length = Length;
opaque label<7..255> = "tls13 " + Label;
@@ -4337,6 +4462,7 @@ defined below:
HKDF-Expand-Label(Secret, Label,
Transcript-Hash(Messages), Hash.length)
~~~~
+{: gi="sourcecode"}
The Hash function used by Transcript-Hash and HKDF is the cipher suite hash
algorithm.
@@ -4370,7 +4496,7 @@ input secrets are:
- (EC)DHE shared secret ({{ecdhe-shared-secret-calculation}})
This produces the key schedule shown in the diagram below
-({{key-schedule-diagram}}. In this diagram, the following formatting conventions apply:
+({{key-schedule-diagram}}). In this diagram, the following formatting conventions apply:
- HKDF-Extract is drawn as taking the Salt argument from the top and
the IKM argument from the left, with its output to the bottom and
@@ -4381,11 +4507,11 @@ This produces the key schedule shown in the diagram below
generating the client_early_traffic_secret.
- "0" indicates a string of Hash.length bytes set to zero.
-Note: the key derivation labels use the string "master" even though
+Note: The key derivation labels use the string "master" even though
the values are referred to as "main" secrets. This mismatch is a
result of renaming the values while retaining compatibility.
-Note: this does not show all the leaf keys such as the separate
+Note: This does not show all the leaf keys such as the separate
AEAD and IV keys but rather the first set of secrets derived
from the handshake.
@@ -4490,6 +4616,7 @@ The next-generation application_traffic_secret is computed as:
HKDF-Expand-Label(application_traffic_secret_N,
"traffic upd", "", Hash.length)
~~~~
+{: gi="sourcecode"}
Once client_/server_application_traffic_secret_N+1 and its associated
traffic keys have been computed, implementations SHOULD delete
@@ -4507,22 +4634,23 @@ The traffic keying material is generated from the following input values:
The traffic keying material is generated from an input traffic secret value using:
~~~~
- [sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)
- [sender]_write_iv = HKDF-Expand-Label(Secret, "iv", "", iv_length)
+[sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)
+[sender]_write_iv = HKDF-Expand-Label(Secret, "iv", "", iv_length)
~~~~
+{: gi="sourcecode"}
-\[sender] denotes the sending side. The value of Secret for each category
+\[sender\] denotes the sending side. The value of Secret for each category
of data is shown in the table below.
| Data Type | Secret |
|:------------|--------|
| 0-RTT Application and EndOfEarlyData | client_early_traffic_secret |
-| Initial Handshake | \[sender]_handshake_traffic_secret |
-| Post-Handshake and Application Data | \[sender]_application_traffic_secret_N |
+| Initial Handshake | \[sender\]_handshake_traffic_secret |
+| Post-Handshake and Application Data | \[sender\]_application_traffic_secret_N |
{: #traffic-key-table title="Secrets for Traffic Keys"}
-Alerts are sent with the then current sending key (or as
-plaintext if no such key has been established.)
+Alerts are sent with the then-current sending key (or as
+plaintext if no such key has been established.)
All the traffic keying material is recomputed whenever the
underlying Secret changes (e.g., when changing from the handshake to
Application Data keys or upon a key update).
@@ -4543,16 +4671,16 @@ leading zeros.
### Elliptic Curve Diffie-Hellman
- For secp256r1, secp384r1 and secp521r1, ECDH calculations (including key
- generation and shared secret calculation) are performed according to
- Sections 5.6.1.2 and 5.7.1.2 of {{KEYAGREEMENT}} using the Elliptic Curve
- Cryptography Cofactor Diffie-Hellman Primitive. The shared secret Z is
- the x-coordinate of the ECDH shared secret elliptic curve point represented
- as an octet string. Note that the octet string Z as output by the
- Field-Element-to-Byte String Conversion specified in Appendix C.2 of
- {{KEYAGREEMENT}} has constant length for any given field; leading zeros
- found in this octet string MUST NOT be truncated. See {{ecdhe-param}} for
- requirements on public-key validation.
+For secp256r1, secp384r1, and secp521r1, ECDH calculations (including key
+generation and shared secret calculation) are performed according to
+Sections 5.6.1.2 and 5.7.1.2 of {{KEYAGREEMENT}} using the Elliptic Curve
+Cryptography Cofactor Diffie-Hellman Primitive. The shared secret Z is
+the x-coordinate of the ECDH shared secret elliptic curve point represented
+as an octet string. Note that the octet string Z as output by the
+Field-Element-to-Byte String Conversion specified in Appendix C.2 of
+{{KEYAGREEMENT}} has constant length for any given field; leading zeros
+found in this octet string MUST NOT be truncated. See {{ecdhe-param}} for
+requirements on public-key validation.
For X25519 and X448, the ECDH calculations are as follows:
@@ -4569,9 +4697,9 @@ For these curves, implementations SHOULD use the approach specified
in {{RFC7748}} to calculate the Diffie-Hellman shared secret.
Implementations MUST check whether the computed Diffie-Hellman
shared secret is the all-zero value and abort if so, as described in
-Section 6 of {{RFC7748}}. If implementors use an alternative
+{{Section 6 of RFC7748}}. If implementors use an alternative
implementation of these elliptic curves, they SHOULD perform the
-additional checks specified in Section 7 of {{RFC7748}}.
+additional checks specified in {{Section 7 of RFC7748}}.
## Exporters
@@ -4603,8 +4731,8 @@ specifications MUST NOT define a use of exporters that permit both an empty
context and no context with the same label. New uses of exporters SHOULD provide
a context in all exporter computations, though the value could be empty.
-Requirements for the format of exporter labels are defined in Section 4
-of {{RFC5705}}.
+Requirements for the format of exporter labels are defined in {{Section 4
+of RFC5705}}.
# 0-RTT and Anti-Replay {#anti-replay}
@@ -4635,7 +4763,7 @@ concerned with:
The first class of attack can be prevented by sharing state to guarantee that
the 0-RTT data is accepted at most once. Servers SHOULD provide that level of
replay safety by implementing one of the methods described in this section or
-by equivalent means. It is understood, however, that due to operational
+by equivalent means. It is understood, however, that due to operational
concerns not all deployments will maintain state at that level. Therefore, in
normal operation, clients will not know which, if any, of these mechanisms
servers actually implement and hence MUST only send early data which they deem
@@ -4717,8 +4845,7 @@ of the ClientHello. If the ClientHello contains multiple
PSK identities, then an attacker can create multiple ClientHellos
with different binder values for the less-preferred identity on the
assumption that the server will not verify it (as recommended
-by {{pre-shared-key-extension}}).
-I.e., if the
+by {{pre-shared-key-extension}}). I.e., if the
client sends PSKs A and B but the server prefers A, then the
attacker can change the binder for B without affecting the binder
for A. If the binder for B is part of the storage key,
@@ -4787,7 +4914,7 @@ the client's "pre_shared_key" extension. The server can determine the
expected_arrival_time of the ClientHello as:
~~~~
- expected_arrival_time = adjusted_creation_time + clients_ticket_age
+ expected_arrival_time = adjusted_creation_time + clients_ticket_age
~~~~
When a new ClientHello is received, the expected_arrival_time is then
@@ -4824,10 +4951,45 @@ streamed to the server over a longer time period.
## Mandatory-to-Implement Cipher Suites
+
+
+
In the absence of an application profile standard specifying otherwise:
-A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM]
-cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and
+A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 {{GCM}}
+cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 {{GCM}} and
TLS_CHACHA20_POLY1305_SHA256 {{RFC8439}} cipher suites (see
{{cipher-suites}}).
@@ -4849,7 +5011,7 @@ TLS-compliant application MUST implement the following TLS extensions:
* Signature Algorithms Certificate ("signature_algorithms_cert"; {{signature-algorithms}})
* Negotiated Groups ("supported_groups"; {{supported-groups}})
* Key Share ("key_share"; {{key-share}})
- * Server Name Indication ("server_name"; Section 3 of {{RFC6066}})
+ * Server Name Indication ("server_name"; {{Section 3 of RFC6066}})
All implementations MUST send and use these extensions when offering
applicable features:
@@ -4942,7 +5104,7 @@ Those middleboxes continue to be non-compliant.
# Security Considerations
-Security issues are discussed throughout this memo, especially in
+Security issues are discussed throughout this memo, especially in
{{implementation-notes}}, {{backward-compatibility}}, and {{security-analysis}}.
@@ -4950,12 +5112,10 @@ Security issues are discussed throughout this memo, especially in
This document uses several registries that were originally created in
{{RFC4346}} and updated in {{RFC8446}} and {{?RFC8447}}. The changes
-between {{RFC8446}} and {{RFC8447}} this document are described in {{bis-changes}}.
-IANA has updated these to reference this document.
-
-The registries and their allocation policies are below:
+between {{RFC8446}}, {{RFC8447}}, and this document are described in {{bis-changes}}.
+IANA has replaced references to these RFCs with references to this document. The registries and their allocation policies are below:
-- TLS Cipher Suites registry: values with the first byte in the range
+- TLS Cipher Suites registry: Values with the first byte in the range
0-254 (decimal) are assigned via Specification Required {{RFC8126}}.
Values with the first byte 255 (decimal) are reserved for Private
Use {{RFC8126}}.
@@ -4969,7 +5129,7 @@ The registries and their allocation policies are below:
Standards Action {{RFC8126}}.
- TLS Alerts registry: Future values are allocated via Standards
- Action {{RFC8126}}. IANA [is requested to/has] populated this registry
+ Action {{RFC8126}}. IANA has populated this registry
with the values from {{alert-messages-appendix}}. The
"DTLS-OK" column is marked as "Y" for all such values.
Values marked as "_RESERVED" have comments
@@ -4990,8 +5150,8 @@ registry follow:
- IANA has updated the registration policy as follows:
Values with the first byte in the range 0-254 (decimal) are assigned
- via Specification Required [RFC8126]. Values with the first byte
- 255 (decimal) are reserved for Private Use [RFC8126].
+ via Specification Required {{RFC8126}}. Values with the first byte
+ 255 (decimal) are reserved for Private Use {{RFC8126}}.
- IANA has updated this registry to include the
"key_share", "pre_shared_key", "psk_key_exchange_modes",
@@ -5010,16 +5170,31 @@ originally created in {{RFC6091}} and updated in {{RFC8447}}. IANA has
updated the entry for value 1 to have the name "OpenPGP_RESERVED",
"Recommended" value "N", and comment "Used in TLS versions prior
to 1.3." IANA has updated the entry for value 0 to have the name
-"X509", "Recommended" value "Y", and comment "Was X.509 before TLS 1.3".
+"X509", "Recommended" value "Y", and comment "Was X.509 before TLS 1.3".
This document updates an entry in the TLS Certificate Status Types
registry originally created in {{RFC6961}}. IANA has updated the entry
for value 2 to have the name "ocsp_multi_RESERVED" and comment "Used
in TLS versions prior to 1.3".
+
+
This document updates two entries in the TLS Supported Groups
registry (created under a different name by {{RFC4492}}; now maintained
-by {{RFC8422}}) and updated by {{RFC7919}} and {{RFC8447}}. The entries
+by {{RFC8422}} and updated by {{RFC7919}} and {{RFC8447}}). The entries
for values 29 and 30 (x25519 and x448) have been updated to also
refer to this document.
@@ -5046,8 +5221,8 @@ by IANA:
- TLS PskKeyExchangeMode registry: Values in the
range 0-253 (decimal) are assigned via Specification Required
- [RFC8126]. The values 254 and 255 (decimal) are
- reserved for Private Use [RFC8126]. This registry has a
+ {{RFC8126}}. The values 254 and 255 (decimal) are
+ reserved for Private Use {{RFC8126}}. This registry has a
"Recommended" column. The registry has been initially
populated with psk_ke (0) and psk_dhe_ke (1). Both are marked as
"Recommended". The
@@ -5058,14 +5233,15 @@ by IANA:
## Changes for this RFC {#bis-changes}
-IANA [shall update/has updated] all references to RFC 8446 in the IANA
+IANA has updated all references to {{RFC8446}} in the IANA
registries with references to this document.
-IANA [shall rename/has renamed] the "extended_master_secret" value
+IANA has renamed the "extended_master_secret" value
in the TLS ExtensionType Values registry to "extended_main_secret".
-IANA [shall create/has created] a value for the "general_error"
-alert in the TLS Alerts Registry with the value given in {{alert-protocol}}.
+IANA has created a value for the "general_error"
+alert in the TLS Alerts registry with the value given in {{alert-protocol}}.
+
--- back
@@ -5075,7 +5251,7 @@ This appendix provides a summary of the legal state transitions for the
client and server handshakes. State names (in all capitals, e.g.,
START) have no formal meaning but are provided for ease of
comprehension. Actions which are taken only in certain circumstances are
-indicated in []. The notation "K_{send,recv} = foo" means "set the send/recv
+indicated in \[\]. The notation "K_{send,recv} = foo" means "set the send/recv
key to the given key".
## Client
@@ -5173,90 +5349,526 @@ for constants. Values listed as
for completeness. TLS 1.3 implementations MUST NOT send them but
might receive them from older TLS implementations.
-%%## Record Layer
-
-%%## Alert Messages{#alert-messages-appendix}
-
-%%## Handshake Protocol{#handshake-protocol-appendix}
-
-%%### Key Exchange Messages
-%%#### Version Extension
-%%#### Cookie Extension
-%%#### Signature Algorithm Extension
-%%#### Supported Groups Extension
-
-Values within "obsolete_RESERVED" ranges are used in previous versions
-of TLS and MUST NOT be offered or negotiated by TLS 1.3 implementations.
-The obsolete curves have various known/theoretical weaknesses or have
-had very little usage, in some cases only due to unintentional
-server configuration issues. They are no longer considered appropriate
-for general use and should be assumed to be potentially unsafe. The set
-of curves specified here is sufficient for interoperability with all
-currently deployed and properly configured TLS implementations.
-
-%%### Server Parameters Messages
-%%### Authentication Messages
-%%### Ticket Establishment
-%%### Updating Keys
-
-
-## Cipher Suites
-
-A cipher suite defines the pair of the AEAD algorithm and hash
-algorithm to be used with HKDF.
-Cipher suite names follow the naming convention:
-
-~~~
- CipherSuite TLS_AEAD_HASH = VALUE;
-~~~
+## Record Layer
-| Component | Contents |
-|:----------|:---------|
-| TLS | The string "TLS" |
-| AEAD | The AEAD algorithm used for record protection |
-| HASH | The hash algorithm used with HKDF and Transcript-Hash |
-| VALUE | The two byte ID assigned for this cipher suite |
-{: #cs-components title="Cipher Suite Name Structure"}
-This specification defines the following cipher suites for use with TLS 1.3.
+ enum {
+ invalid(0),
+ change_cipher_spec(20),
+ alert(21),
+ handshake(22),
+ application_data(23),
+ (255)
+ } ContentType;
-| Description | Value |
-|:--------------------------------|:------------|
-| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
-| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
-| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
-| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
-| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
-{: #cs-list title="Cipher Suite List"}
+ struct {
+ ContentType type;
+ ProtocolVersion legacy_record_version;
+ uint16 length;
+ opaque fragment[TLSPlaintext.length];
+ } TLSPlaintext;
-The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, and
-AEAD_AES_128_CCM are defined in {{RFC5116}}. AEAD_CHACHA20_POLY1305 is defined
-in {{RFC8439}}. AEAD_AES_128_CCM_8 is defined in {{RFC6655}}. The corresponding
-hash algorithms are defined in {{!SHS}}.
+ struct {
+ opaque content[TLSPlaintext.length];
+ ContentType type;
+ uint8 zeros[length_of_padding];
+ } TLSInnerPlaintext;
-Although TLS 1.3 uses the same cipher suite space as previous versions
-of TLS, TLS 1.3 cipher suites are defined differently, only specifying
-the symmetric ciphers, and cannot be used for TLS 1.2. Similarly,
-cipher suites for TLS 1.2 and lower cannot be used with TLS 1.3.
+ struct {
+ ContentType opaque_type = application_data; /* 23 */
+ ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
+ uint16 length;
+ opaque encrypted_record[TLSCiphertext.length];
+ } TLSCiphertext;
-New cipher suite values are assigned by IANA as described in
-{{iana-considerations}}.
-# Implementation Notes
-The TLS protocol cannot prevent many common security mistakes. This appendix
-provides several recommendations to assist implementors.
-{{?RFC8448}} provides test vectors for TLS 1.3 handshakes.
+## Alert Messages {#alert-messages-appendix}
-## Random Number Generation and Seeding
+ enum { warning(1), fatal(2), (255) } AlertLevel;
-TLS requires a cryptographically secure pseudorandom number generator (CSPRNG).
-A performant and appropriately-secure CSPRNG is provided by most operating
-systems or can be sourced from a cryptographic library.
-It is RECOMMENDED to use an existing CSPRNG implementation in
-preference to crafting a new one. Many adequate cryptographic libraries
-are already available under favorable license terms. Should those prove
+ enum {
+ close_notify(0),
+ unexpected_message(10),
+ bad_record_mac(20),
+ decryption_failed_RESERVED(21),
+ record_overflow(22),
+ decompression_failure_RESERVED(30),
+ handshake_failure(40),
+ no_certificate_RESERVED(41),
+ bad_certificate(42),
+ unsupported_certificate(43),
+ certificate_revoked(44),
+ certificate_expired(45),
+ certificate_unknown(46),
+ illegal_parameter(47),
+ unknown_ca(48),
+ access_denied(49),
+ decode_error(50),
+ decrypt_error(51),
+ export_restriction_RESERVED(60),
+ protocol_version(70),
+ insufficient_security(71),
+ internal_error(80),
+ inappropriate_fallback(86),
+ user_canceled(90),
+ no_renegotiation_RESERVED(100),
+ missing_extension(109),
+ unsupported_extension(110),
+ certificate_unobtainable_RESERVED(111),
+ unrecognized_name(112),
+ bad_certificate_status_response(113),
+ bad_certificate_hash_value_RESERVED(114),
+ unknown_psk_identity(115),
+ certificate_required(116),
+ general_error(117),
+ no_application_protocol(120),
+ (255)
+ } AlertDescription;
+
+ struct {
+ AlertLevel level;
+ AlertDescription description;
+ } Alert;
+
+
+
+
+## Handshake Protocol {#handshake-protocol-appendix}
+
+ enum {
+ hello_request_RESERVED(0),
+ client_hello(1),
+ server_hello(2),
+ hello_verify_request_RESERVED(3),
+ new_session_ticket(4),
+ end_of_early_data(5),
+ hello_retry_request_RESERVED(6),
+ encrypted_extensions(8),
+ certificate(11),
+ server_key_exchange_RESERVED(12),
+ certificate_request(13),
+ server_hello_done_RESERVED(14),
+ certificate_verify(15),
+ client_key_exchange_RESERVED(16),
+ finished(20),
+ certificate_url_RESERVED(21),
+ certificate_status_RESERVED(22),
+ supplemental_data_RESERVED(23),
+ key_update(24),
+ message_hash(254),
+ (255)
+ } HandshakeType;
+
+ struct {
+ HandshakeType msg_type; /* handshake type */
+ uint24 length; /* remaining bytes in message */
+ select (Handshake.msg_type) {
+ case client_hello: ClientHello;
+ case server_hello: ServerHello;
+ case end_of_early_data: EndOfEarlyData;
+ case encrypted_extensions: EncryptedExtensions;
+ case certificate_request: CertificateRequest;
+ case certificate: Certificate;
+ case certificate_verify: CertificateVerify;
+ case finished: Finished;
+ case new_session_ticket: NewSessionTicket;
+ case key_update: KeyUpdate;
+ };
+ } Handshake;
+
+
+
+
+### Key Exchange Messages
+
+
+ uint16 ProtocolVersion;
+ opaque Random[32];
+
+ uint8 CipherSuite[2]; /* Cryptographic suite selector */
+
+ struct {
+ ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
+ Random random;
+ opaque legacy_session_id<0..32>;
+ CipherSuite cipher_suites<2..2^16-2>;
+ opaque legacy_compression_methods<1..2^8-1>;
+ Extension extensions<8..2^16-1>;
+ } ClientHello;
+
+ struct {
+ ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
+ Random random;
+ opaque legacy_session_id_echo<0..32>;
+ CipherSuite cipher_suite;
+ uint8 legacy_compression_method = 0;
+ Extension extensions<6..2^16-1>;
+ } ServerHello;
+
+ struct {
+ ExtensionType extension_type;
+ opaque extension_data<0..2^16-1>;
+ } Extension;
+
+ enum {
+ server_name(0), /* RFC 6066 */
+ max_fragment_length(1), /* RFC 6066 */
+ status_request(5), /* RFC 6066 */
+ supported_groups(10), /* RFC 8422, 7919 */
+ signature_algorithms(13), /* RFC 8446 */
+ use_srtp(14), /* RFC 5764 */
+ heartbeat(15), /* RFC 6520 */
+ application_layer_protocol_negotiation(16), /* RFC 7301 */
+ signed_certificate_timestamp(18), /* RFC 6962 */
+ client_certificate_type(19), /* RFC 7250 */
+ server_certificate_type(20), /* RFC 7250 */
+ padding(21), /* RFC 7685 */
+ pre_shared_key(41), /* RFC 8446 */
+ early_data(42), /* RFC 8446 */
+ supported_versions(43), /* RFC 8446 */
+ cookie(44), /* RFC 8446 */
+ psk_key_exchange_modes(45), /* RFC 8446 */
+ certificate_authorities(47), /* RFC 8446 */
+ oid_filters(48), /* RFC 8446 */
+ post_handshake_auth(49), /* RFC 8446 */
+ signature_algorithms_cert(50), /* RFC 8446 */
+ key_share(51), /* RFC 8446 */
+ (65535)
+ } ExtensionType;
+
+ struct {
+ NamedGroup group;
+ opaque key_exchange<1..2^16-1>;
+ } KeyShareEntry;
+
+ struct {
+ KeyShareEntry client_shares<0..2^16-1>;
+ } KeyShareClientHello;
+
+ struct {
+ NamedGroup selected_group;
+ } KeyShareHelloRetryRequest;
+
+ struct {
+ KeyShareEntry server_share;
+ } KeyShareServerHello;
+
+ struct {
+ uint8 legacy_form = 4;
+ opaque X[coordinate_length];
+ opaque Y[coordinate_length];
+ } UncompressedPointRepresentation;
+
+ enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
+
+ struct {
+ PskKeyExchangeMode ke_modes<1..255>;
+ } PskKeyExchangeModes;
+
+ struct {} Empty;
+
+ struct {
+ select (Handshake.msg_type) {
+ case new_session_ticket: uint32 max_early_data_size;
+ case client_hello: Empty;
+ case encrypted_extensions: Empty;
+ };
+ } EarlyDataIndication;
+
+ struct {
+ opaque identity<1..2^16-1>;
+ uint32 obfuscated_ticket_age;
+ } PskIdentity;
+
+ opaque PskBinderEntry<32..255>;
+
+ struct {
+ PskIdentity identities<7..2^16-1>;
+ PskBinderEntry binders<33..2^16-1>;
+ } OfferedPsks;
+
+ struct {
+ select (Handshake.msg_type) {
+ case client_hello: OfferedPsks;
+ case server_hello: uint16 selected_identity;
+ };
+ } PreSharedKeyExtension;
+
+
+
+#### Version Extension
+
+
+ struct {
+ select (Handshake.msg_type) {
+ case client_hello:
+ ProtocolVersion versions<2..254>;
+
+ case server_hello: /* and HelloRetryRequest */
+ ProtocolVersion selected_version;
+ };
+ } SupportedVersions;
+
+
+
+#### Cookie Extension
+
+
+ struct {
+ opaque cookie<1..2^16-1>;
+ } Cookie;
+
+
+
+#### Signature Algorithm Extension
+
+
+ enum {
+ /* RSASSA-PKCS1-v1_5 algorithms */
+ rsa_pkcs1_sha256(0x0401),
+ rsa_pkcs1_sha384(0x0501),
+ rsa_pkcs1_sha512(0x0601),
+
+ /* ECDSA algorithms */
+ ecdsa_secp256r1_sha256(0x0403),
+ ecdsa_secp384r1_sha384(0x0503),
+ ecdsa_secp521r1_sha512(0x0603),
+
+ /* RSASSA-PSS algorithms with public key OID rsaEncryption */
+ rsa_pss_rsae_sha256(0x0804),
+ rsa_pss_rsae_sha384(0x0805),
+ rsa_pss_rsae_sha512(0x0806),
+
+ /* EdDSA algorithms */
+ ed25519(0x0807),
+ ed448(0x0808),
+
+ /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */
+ rsa_pss_pss_sha256(0x0809),
+ rsa_pss_pss_sha384(0x080a),
+ rsa_pss_pss_sha512(0x080b),
+
+ /* Legacy algorithms */
+ rsa_pkcs1_sha1(0x0201),
+ ecdsa_sha1(0x0203),
+
+ /* Reserved Code Points */
+ obsolete_RESERVED(0x0000..0x0200),
+ dsa_sha1_RESERVED(0x0202),
+ obsolete_RESERVED(0x0204..0x0400),
+ dsa_sha256_RESERVED(0x0402),
+ obsolete_RESERVED(0x0404..0x0500),
+ dsa_sha384_RESERVED(0x0502),
+ obsolete_RESERVED(0x0504..0x0600),
+ dsa_sha512_RESERVED(0x0602),
+ obsolete_RESERVED(0x0604..0x06FF),
+ private_use(0xFE00..0xFFFF),
+ (0xFFFF)
+ } SignatureScheme;
+
+ struct {
+ SignatureScheme supported_signature_algorithms<2..2^16-2>;
+ } SignatureSchemeList;
+
+
+
+#### Supported Groups Extension
+
+
+ enum {
+ unallocated_RESERVED(0x0000),
+
+ /* Elliptic Curve Groups (ECDHE) */
+ obsolete_RESERVED(0x0001..0x0016),
+ secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
+ obsolete_RESERVED(0x001A..0x001C),
+ x25519(0x001D), x448(0x001E),
+
+ /* Finite Field Groups (DHE) */
+ ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
+ ffdhe6144(0x0103), ffdhe8192(0x0104),
+
+ /* Reserved Code Points */
+ ffdhe_private_use(0x01FC..0x01FF),
+ ecdhe_private_use(0xFE00..0xFEFF),
+ obsolete_RESERVED(0xFF01..0xFF02),
+ (0xFFFF)
+ } NamedGroup;
+
+ struct {
+ NamedGroup named_group_list<2..2^16-1>;
+ } NamedGroupList;
+
+
+
+
+Values within "obsolete_RESERVED" ranges are used in previous versions
+of TLS and MUST NOT be offered or negotiated by TLS 1.3 implementations.
+The obsolete curves have various known/theoretical weaknesses or have
+had very little usage, in some cases only due to unintentional
+server configuration issues. They are no longer considered appropriate
+for general use and should be assumed to be potentially unsafe. The set
+of curves specified here is sufficient for interoperability with all
+currently deployed and properly configured TLS implementations.
+
+### Server Parameters Messages
+
+
+ opaque DistinguishedName<1..2^16-1>;
+
+ struct {
+ DistinguishedName authorities<3..2^16-1>;
+ } CertificateAuthoritiesExtension;
+
+ struct {
+ opaque certificate_extension_oid<1..2^8-1>;
+ opaque certificate_extension_values<0..2^16-1>;
+ } OIDFilter;
+
+ struct {
+ OIDFilter filters<0..2^16-1>;
+ } OIDFilterExtension;
+
+ struct {} PostHandshakeAuth;
+
+ struct {
+ Extension extensions<0..2^16-1>;
+ } EncryptedExtensions;
+
+ struct {
+ opaque certificate_request_context<0..2^8-1>;
+ Extension extensions<0..2^16-1>;
+ } CertificateRequest;
+
+
+
+### Authentication Messages
+
+
+ enum {
+ X509(0),
+ OpenPGP_RESERVED(1),
+ RawPublicKey(2),
+ (255)
+ } CertificateType;
+
+ struct {
+ select (certificate_type) {
+ case RawPublicKey:
+ /* From RFC 7250 ASN.1_subjectPublicKeyInfo */
+ opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
+
+ case X509:
+ opaque cert_data<1..2^24-1>;
+ };
+ Extension extensions<0..2^16-1>;
+ } CertificateEntry;
+
+ struct {
+ opaque certificate_request_context<0..2^8-1>;
+ CertificateEntry certificate_list<0..2^24-1>;
+ } Certificate;
+
+ struct {
+ SignatureScheme algorithm;
+ opaque signature<0..2^16-1>;
+ } CertificateVerify;
+
+ struct {
+ opaque verify_data[Hash.length];
+ } Finished;
+
+
+
+### Ticket Establishment
+
+
+ struct {
+ uint32 ticket_lifetime;
+ uint32 ticket_age_add;
+ opaque ticket_nonce<0..255>;
+ opaque ticket<1..2^16-1>;
+ Extension extensions<0..2^16-1>;
+ } NewSessionTicket;
+
+
+
+### Updating Keys
+
+
+ struct {} EndOfEarlyData;
+
+ enum {
+ update_not_requested(0), update_requested(1), (255)
+ } KeyUpdateRequest;
+
+ struct {
+ KeyUpdateRequest request_update;
+ } KeyUpdate;
+
+
+
+
+
+## Cipher Suites
+
+A cipher suite defines the pair of the AEAD algorithm and hash
+algorithm to be used with HKDF.
+Cipher suite names follow the naming convention:
+
+~~~
+ CipherSuite TLS_AEAD_HASH = VALUE;
+~~~
+
+| Component | Contents |
+|:----------|:---------|
+| TLS | The string "TLS" |
+| AEAD | The AEAD algorithm used for record protection |
+| HASH | The hash algorithm used with HKDF and Transcript-Hash |
+| VALUE | The two byte ID assigned for this cipher suite |
+{: #cs-components title="Cipher Suite Name Structure"}
+
+This specification defines the following cipher suites for use with TLS 1.3.
+
+| Description | Value |
+|:--------------------------------|:------------|
+| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
+| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
+| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
+| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
+| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+{: #cs-list title="Cipher Suite List"}
+
+The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, and
+AEAD_AES_128_CCM are defined in {{RFC5116}}. AEAD_CHACHA20_POLY1305 is defined
+in {{RFC8439}}. AEAD_AES_128_CCM_8 is defined in {{RFC6655}}. The corresponding
+hash algorithms are defined in {{!SHS}}.
+
+Although TLS 1.3 uses the same cipher suite space as previous versions
+of TLS, TLS 1.3 cipher suites are defined differently, only specifying
+the symmetric ciphers, and cannot be used for TLS 1.2. Similarly,
+cipher suites for TLS 1.2 and lower cannot be used with TLS 1.3.
+
+New cipher suite values are assigned by IANA as described in
+{{iana-considerations}}.
+
+
+# Implementation Notes
+
+The TLS protocol cannot prevent many common security mistakes. This appendix
+provides several recommendations to assist implementors.
+{{?RFC8448}} provides test vectors for TLS 1.3 handshakes.
+
+## Random Number Generation and Seeding
+
+TLS requires a cryptographically secure pseudorandom number generator (CSPRNG).
+A performant and appropriately secure CSPRNG is provided by most operating
+systems or can be sourced from a cryptographic library.
+It is RECOMMENDED to use an existing CSPRNG implementation in
+preference to crafting a new one. Many adequate cryptographic libraries
+are already available under favorable license terms. Should those prove
unsatisfactory, {{RFC4086}} provides guidance on the generation of random values.
TLS uses random values (1) in public protocol fields such as the
@@ -5292,7 +5904,7 @@ certification paths containing keys or signatures weaker than 2048-bit RSA or
Note that it is common practice in some protocols to use the same
certificate in both client and server modes. This setting has not been
-extensively analyzed and it is the responsibility of the higher level
+extensively analyzed, and it is the responsibility of the higher-level
protocol to ensure there is no ambiguity in this case about the
higher-level semantics.
@@ -5322,7 +5934,7 @@ TLS protocol issues:
- Have you ensured that all support for SSL, RC4, EXPORT ciphers, and
MD5 (via the "signature_algorithms" extension) is completely removed from
all possible configurations that support TLS 1.3 or later, and that
- attempts to use these obsolete capabilities fail correctly?
+ attempts to use these obsolete capabilities fail correctly
(see {{backward-compatibility}})?
- Do you handle TLS extensions in ClientHellos correctly, including
@@ -5364,9 +5976,9 @@ Cryptographic details:
generator (see {{random-number-generation-and-seeding}}) when generating Diffie-Hellman
private values, the ECDSA "k" parameter, and other security-critical values?
It is RECOMMENDED that implementations implement "deterministic ECDSA"
- as specified in {{!RFC6979}}. Note that purely deterministic ECC signatures such as
+ as specified in {{!RFC6979}}. Note that purely deterministic Elliptic Curve Cryptography (ECC) signatures such as
deterministic ECDSA and EdDSA may be vulnerable to certain side-channel and fault
- injection attacks in easily accessible IoT devices.
+ injection attacks in easily accessible Internet of Things (IoT) devices.
- Do you zero-pad Diffie-Hellman public key values and shared
secrets to the group size (see {{ffdhe-param}} and {{finite-field-diffie-hellman}})?
@@ -5391,23 +6003,23 @@ applications SHOULD NOT offer tickets across connections that are meant to be
uncorrelated. For example, {{FETCH}} defines network partition keys to separate
cache lookups in web browsers.
-Clients and Servers SHOULD NOT reuse a key share for multiple connections. Reuse
+Clients and servers SHOULD NOT reuse a key share for multiple connections. Reuse
of a key share allows passive observers to correlate different connections. Reuse
of a client key share to the same server additionally allows the server to correlate different connections.
It is RECOMMENDED that the labels for external identities be selected so that they
do not provide additional information about the identity of the
-user. For instance, if the label includes an e-mail address, then
+user. For instance, if the label includes an email address, then
this trivially identifies the user to a passive attacker,
unlike the client's Certificate, which is encrypted. There are a number of potential
-ways to avoid this risk, including (1) using random identity labels
-(2) pre-encrypting the identity under a key known to the server or (3)
-using the Encrypted Client Hello {{?I-D.ietf-tls-esni}} extension.
+ways to avoid this risk, including (1) using random identity labels,
+(2) pre-encrypting the identity under a key known to the server, or (3)
+using the Encrypted Client Hello extension {{PRE-RFC9849}}.
If an external PSK identity is used for multiple connections, then it
will generally be possible for an external observer to track
clients and/or servers across connections. Use of the
-Encrypted Client Hello {{?I-D.ietf-tls-esni}} extension can
+Encrypted Client Hello extension {{PRE-RFC9849}} can
mitigate this risk, as can mechanisms external to TLS that
rotate or encrypt the PSK identity.
@@ -5430,7 +6042,7 @@ out-of-band validation of the server's public key, trust on first
use, or a mechanism such as channel bindings (though the
channel bindings described in {{RFC5929}} are not defined for
TLS 1.3). If no such mechanism is used, then the connection has no protection
-against active man-in-the-middle attack; applications MUST NOT use TLS
+against an active man-in-the-middle attack; applications MUST NOT use TLS
in such a way absent explicit configuration or a specific application
profile.
@@ -5440,7 +6052,7 @@ profile.
To align with the names used this document, the following terms from
{{RFC5246}} are renamed:
-* The master secret, computed in Section 8.1 of {{RFC5246}}, is renamed to
+* The master secret, computed in {{Section 8.1 of RFC5246}}, is renamed to
the main secret. It is referred to as main_secret in formulas and
structures, instead of master_secret. However, the label parameter to the PRF
function is left unchanged for compatibility.
@@ -5450,13 +6062,13 @@ To align with the names used this document, the following terms from
pre_master_secret.
* The PreMasterSecret and EncryptedPreMasterSecret structures, defined in
- Section 7.4.7.1 of {{RFC5246}}, are renamed to PreliminarySecret and
+ {{Section 7.4.7.1 of RFC5246}}, are renamed to PreliminarySecret and
EncryptedPreliminarySecret, respectively.
Correspondingly, the extension defined in {{RFC7627}} is renamed to the
"Extended Main Secret" extension. The extension code point is renamed to
-"extended_main_secret". The label parameter to the PRF function in Section 4 of
-{{RFC7627}} is left unchanged for compatibility.
+"extended_main_secret". The label parameter to the PRF function in {{Section 4 of
+RFC7627}} is left unchanged for compatibility.
# Backward Compatibility
@@ -5629,7 +6241,7 @@ Implementations SHOULD NOT accept any records with a version less than 0x0300
(but may inadvertently do so if the record version number is ignored completely).
Implementations MUST NOT use the Truncated HMAC extension, defined in
-Section 7 of [RFC6066], as it is not applicable to AEAD algorithms and has
+{{Section 7 of RFC6066}}, as it is not applicable to AEAD algorithms and has
been shown to be insecure in some scenarios.
@@ -5651,10 +6263,10 @@ mutually authenticated (client and server) functionality. At the completion
of the handshake, each side outputs its view of the following values:
- A set of "session keys" (the various secrets derived from the main secret)
- from which can be derived a set of working keys. Note that when early data
+ from which a set of working keys can be derived. Note that when early data
is in use, secrets are also derived from the early secret. These enjoy
somewhat weaker properties than those derived from the main secret,
- as detailed below.
+ as detailed below.
- A set of cryptographic parameters (algorithms, etc.).
- The identities of the communicating parties.
@@ -5699,7 +6311,7 @@ Forward secret with respect to long-term keys:
(see {{?DOW92=DOI.10.1007/BF00124891}}), as long as the session key
itself (and all material that could be used to recreate the session
key) has been erased. In particular, private keys corresponding to key
- shares, shared secrets, and keys derived in the TLS Key Schedule
+ shares, shared secrets, and keys derived in the TLS key schedule
other than `binder_key`, `resumption_secret`, and PSKs derived from
the `resumption_secret` also need to be erased. The forward secrecy
property is not satisfied when PSK is used in the "psk_ke"
@@ -5711,7 +6323,7 @@ Forward secret with respect to long-term keys:
Key Compromise Impersonation (KCI) resistance:
: In a mutually authenticated connection with certificates, compromising the long-term
- secret of one actor should not break that actor’s authentication of their peer in
+ secret of one actor should not break that actor's authentication of their peer in
the given connection (see {{HGFS15}}). For example, if a client's signature key is
compromised, it should not be possible to impersonate arbitrary servers to that client
in subsequent handshakes.
@@ -5763,7 +6375,7 @@ compromised, any handshake with (EC)DHE gives protection against
active attackers. Using the terms in {{RFC7624}}, forward secrecy
without rerunning (EC)DHE does not stop an attacker from doing static
key exfiltration. After key exfiltration of
-application_traffic_secret_N, an attacker can e.g., passively
+application_traffic_secret_N, an attacker can, e.g., passively
eavesdrop on all future data sent on the connection including data
encrypted with application_traffic_secret_N+1,
application_traffic_secret_N+2, etc. Frequently rerunning (EC)DHE
@@ -5865,9 +6477,9 @@ If the client needs to determine if the server considers the
connection to be unilaterally or mutually authenticated, this has to
be provisioned by the application layer. See {{CHHSV17}} for details.
In addition, the analysis of post-handshake authentication from
-[Kraw16] shows that the client identified by the certificate sent in
-the post-handshake phase possesses the traffic key. This party is
-therefore the client that participated in the original handshake or
+{{Kraw16}} shows that the client identified by the certificate sent in
+the post-handshake phase possesses the traffic key. This party is therefore
+the client that participated in the original handshake or
one to whom the original client delegated the traffic key (assuming
that the traffic key has not been compromised).
@@ -5919,6 +6531,15 @@ Assuming that is true, and the keys are used for no more data than
indicated in {{limits-on-key-usage}}, then the record layer should provide the following
guarantees:
+
+
Confidentiality:
: An attacker should not be able to determine the plaintext contents
of a given record.
@@ -5949,7 +6570,7 @@ plaintext with a strong key. AEAD encryption {{RFC5116}} provides confidentialit
and integrity for the data. Non-replayability is provided by using
a separate nonce for each record, with the nonce being derived from
the record sequence number ({{nonce}}), with the sequence
-number being maintained independently at both sides; thus records which
+number being maintained independently at both sides; thus, records which
are delivered out of order result in AEAD deprotection failures.
In order to prevent mass cryptanalysis when the same plaintext is
repeatedly encrypted by different users under the same key
@@ -6092,7 +6713,7 @@ willingness to retry transactions and therefore only allows a limited amount
of duplication, with each copy appearing as a new connection at
the server.
-If implemented correctly, the mechanisms described in
+If implemented correctly, the mechanisms described in
{{single-use-tickets}} and {{client-hello-recording}} prevent a
replayed ClientHello and its associated 0-RTT data from being accepted
multiple times by any cluster with consistent state; for servers
@@ -6175,19 +6796,18 @@ non-member can reroute handshakes between honest group members to
connect them in unintended ways {{Selfie}}. {{RFC9257}} provides
recommendations for external PSK usage, including the use of external
PSK importers as defined in {{RFC9258}}, that prevent such malicious
-rerouting of messages
+rerouting of messages.
-## Misbinding when using Self-Signed Certificates or Raw Public Keys
+## Misbinding When Using Self-Signed Certificates or Raw Public Keys
When TLS 1.3 is used with self-signed certificates without useful
identities (as in DTLS-SRTP {{?RFC5763}}) or raw public keys
{{RFC7250}} for peer authentication, it may be vulnerable to
misbinding attacks {{MM24}}. This risk can be mitigated by using
-the "external_id_hash" extension {{?RFC8844}} or, if only
+the "external_id_hash" extension {{RFC8844}} or, if only
the server is being authenticated, by the server verifying
that the "server_name" extension matches its expected identity.
-
## Attacks on Static RSA
Although TLS 1.3 does not use RSA key transport and so is not
@@ -6203,53 +6823,11 @@ relies on clients refusing to accept signatures using keys
in certificates that do not have the digitalSignature bit set,
and many clients do not enforce this restriction.
-# Change Log
-
-[[RFC EDITOR: Please remove in final RFC.]]
-Since -06
-- Updated text about differences from RFC 8446.
-- Clarify which parts of IANA considerations are new to this document.
-- Upgrade the requirement to initiate key update before exceeding
- key usage limits to MUST.
-- Add some text around use of the same cert for client and server.
-
-Since -05
-
-- Port in text on key update limits from RFC 9147 (Issue 1257)
-- Clarify that you need to ignore NST if you don't do resumption
- (Issue 1280)
-- Discuss the privacy implications of external key reuse (Issue 1287)
-- Advice on key deletion (PR 1282)
-- Clarify what unsolicited extensions means (PR 1275)
-- close_notify should be warning (PR 1290)
-- Reference RFC 8773 (PR 1296)
-- Add some more information about application bindings and cite
- RFC 9525 (PR 1297)
-
-Since -04
-
-* Update the extension table (Issue 1241)
-* Clarify user_canceled (Issue 1208)
-* Clarify 0-RTT cache side channels (Issue 1225)
-* Require that message reinjection be done with the current hash.
- Potentially a clarification and potentially a wire format
- change depending on previous interpretation (Issue 1227)
-
-Changelog not updated between -00 and -03
-
-Since -00
-
-
-* Update TLS 1.2 terminology
-* Specify "certificate-based" client authentication
-* Clarify that privacy guarantees don't apply when you have null encryption
-* Shorten some names
-* Address tracking implications of resumption
-
# Contributors
{:numbered="false"}
-~~~~
+
+~~~
Martin Abadi
University of California, Santa Cruz
abadi@cs.ucsc.edu
@@ -6280,17 +6858,17 @@ Since -00
benjamin.beurdouche@ens.fr
Karthikeyan Bhargavan
- (editor of [RFC7627])
+ (editor of {{RFC7627}})
INRIA
karthikeyan.bhargavan@inria.fr
Simon Blake-Wilson
- (co-author of [RFC4492])
+ (co-author of {{RFC4492}})
BCI
sblakewilson@bcisse.com
Nelson Bolyard
- (co-author of [RFC4492])
+ (co-author of {{RFC4492}})
Sun Microsystems, Inc.
nelson@bolyard.com
@@ -6319,7 +6897,7 @@ Since -00
cas.cremers@cs.ox.ac.uk
Antoine Delignat-Lavaud
- (co-author of [RFC7627])
+ (co-author of {{RFC7627}})
INRIA
antdl@microsoft.com
@@ -6375,12 +6953,12 @@ Since -00
mail@felixguenther.info
Vipul Gupta
- (co-author of [RFC4492])
+ (co-author of {{RFC4492}})
Sun Microsystems Laboratories
vipul.gupta@sun.com
Chris Hawk
- (co-author of [RFC4492])
+ (co-author of {{RFC4492}})
Corriente Networks LLC
chris@corriente.net
@@ -6429,7 +7007,7 @@ Since -00
hugokraw@us.ibm.com
Adam Langley
- (co-author of [RFC7627])
+ (co-author of {{RFC7627}})
Google
agl@google.com
@@ -6462,7 +7040,7 @@ Since -00
janm@transactionware.com
Bodo Moeller
- (co-author of [RFC4492])
+ (co-author of {{RFC4492}})
Google
bodo@acm.org
@@ -6491,7 +7069,7 @@ Since -00
cjpatton@ufl.edu
Alfredo Pironti
- (co-author of [RFC7627])
+ (co-author of {{RFC7627}})
INRIA
alfredo.pironti@inria.fr
@@ -6499,12 +7077,12 @@ Since -00
Microsoft
andrei.popov@microsoft.com
- John {{{Preuß Mattsson}}}
+ John Preuß Mattsson
Ericsson
john.mattsson@ericsson.com
Marsh Ray
- (co-author of [RFC7627])
+ (co-author of {{RFC7627}})
Microsoft
maray@microsoft.com
@@ -6631,4 +7209,67 @@ Since -00
Kazu Yamamoto
Internet Initiative Japan Inc.
kazu@iij.ad.jp
-~~~~
+~~~
+
+
+
+
+
+
+
+
+
+
+
+
+