rfc9846.original   rfc9846.txt 
Transport Layer Security E. Rescorla Internet Engineering Task Force (IETF) E. Rescorla
Internet-Draft Independent Request for Comments: 9846 Independent
Obsoletes: 8446 (if approved) 13 September 2025 Obsoletes: 8446 22 December 2025
Updates: 5705, 6066, 7627, 8422 (if approved) Updates: 5705, 6066, 7627, 8422
Intended status: Standards Track Category: Standards Track
Expires: 17 March 2026 ISSN: 2070-1721
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-rfc8446bis-14
Abstract Abstract
This document specifies version 1.3 of the Transport Layer Security This document specifies version 1.3 of the Transport Layer Security
(TLS) protocol. TLS allows client/server applications to communicate (TLS) protocol. TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping, over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery. tampering, and message forgery.
This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes
RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies
new requirements for TLS 1.2 implementations. new requirements for TLS 1.2 implementations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 17 March 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9846.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 6 1.1. Conventions and Terminology
1.2. Relationship to RFC 8446 . . . . . . . . . . . . . . . . 7 1.2. Relationship to RFC 8446
1.3. Major Differences from TLS 1.2 . . . . . . . . . . . . . 8 1.3. Major Differences from TLS 1.2
1.4. Updates Affecting TLS 1.2 . . . . . . . . . . . . . . . . 9 1.4. Updates Affecting TLS 1.2
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 2. Protocol Overview
2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . . . 13 2.1. Incorrect DHE Share
2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 14 2.2. Resumption and Pre-Shared Key (PSK)
2.3. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . 16 2.3. 0-RTT Data
3. Presentation Language . . . . . . . . . . . . . . . . . . . . 18 3. Presentation Language
3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 18 3.1. Basic Block Size
3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 18 3.2. Miscellaneous
3.3. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3. Numbers
3.4. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4. Vectors
3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 20 3.5. Enumerateds
3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 21 3.6. Constructed Types
3.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 21 3.7. Constants
3.8. Variants . . . . . . . . . . . . . . . . . . . . . . . . 22 3.8. Variants
4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 23 4. Handshake Protocol
4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 24 4.1. Key Exchange Messages
4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 24 4.1.1. Cryptographic Negotiation
4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 25 4.1.2. Client Hello
4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 28 4.1.3. Server Hello
4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 31 4.1.4. Hello Retry Request
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 32 4.2. Extensions
4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 36 4.2.1. Supported Versions
4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 37 4.2.2. Cookie
4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 38 4.2.3. Signature Algorithms
4.2.4. Certificate Authorities . . . . . . . . . . . . . . . 42 4.2.4. Certificate Authorities
4.2.5. OID Filters . . . . . . . . . . . . . . . . . . . . . 42 4.2.5. OID Filters
4.2.6. Post-Handshake Certificate-Based Client 4.2.6. Post-Handshake Certificate-Based Client Authentication
Authentication . . . . . . . . . . . . . . . . . . . 43 4.2.7. Supported Groups
4.2.7. Supported Groups . . . . . . . . . . . . . . . . . . 44 4.2.8. Key Share
4.2.8. Key Share . . . . . . . . . . . . . . . . . . . . . . 45 4.2.9. Pre-Shared Key Exchange Modes
4.2.9. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 48 4.2.10. Early Data Indication
4.2.10. Early Data Indication . . . . . . . . . . . . . . . . 49 4.2.11. Pre-Shared Key Extension
4.2.11. Pre-Shared Key Extension . . . . . . . . . . . . . . 52 4.3. Server Parameters
4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 56 4.3.1. Encrypted Extensions
4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 56 4.3.2. Certificate Request
4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 57 4.4. Authentication Messages
4.4. Authentication Messages . . . . . . . . . . . . . . . . . 58 4.4.1. The Transcript Hash
4.4.1. The Transcript Hash . . . . . . . . . . . . . . . . . 59 4.4.2. Certificate
4.4.2. Certificate . . . . . . . . . . . . . . . . . . . . . 60 4.4.3. Certificate Verify
4.4.3. Certificate Verify . . . . . . . . . . . . . . . . . 65 4.4.4. Finished
4.4.4. Finished . . . . . . . . . . . . . . . . . . . . . . 67 4.5. End of Early Data
4.5. End of Early Data . . . . . . . . . . . . . . . . . . . . 69 4.6. Post-Handshake Messages
4.6. Post-Handshake Messages . . . . . . . . . . . . . . . . . 69 4.6.1. New Session Ticket Message
4.6.1. New Session Ticket Message . . . . . . . . . . . . . 69 4.6.2. Post-Handshake Authentication
4.6.2. Post-Handshake Authentication . . . . . . . . . . . . 72 4.6.3. Key and Initialization Vector Update
4.6.3. Key and Initialization Vector Update . . . . . . . . 72 5. Record Protocol
5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 74 5.1. Record Layer
5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 74 5.2. Record Payload Protection
5.2. Record Payload Protection . . . . . . . . . . . . . . . . 76 5.3. Per-Record Nonce
5.3. Per-Record Nonce . . . . . . . . . . . . . . . . . . . . 79 5.4. Record Padding
5.4. Record Padding . . . . . . . . . . . . . . . . . . . . . 79 5.5. Limits on Key Usage
5.5. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 81 6. Alert Protocol
6. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . 81 6.1. Closure Alerts
6.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 83 6.2. Error Alerts
6.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 84 7. Cryptographic Computations
7. Cryptographic Computations . . . . . . . . . . . . . . . . . 87 7.1. Key Schedule
7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 87 7.2. Updating Traffic Secrets
7.2. Updating Traffic Secrets . . . . . . . . . . . . . . . . 90 7.3. Traffic Key Calculation
7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 90 7.4. (EC)DHE Shared Secret Calculation
7.4. (EC)DHE Shared Secret Calculation . . . . . . . . . . . . 91 7.4.1. Finite Field Diffie-Hellman
7.4.1. Finite Field Diffie-Hellman . . . . . . . . . . . . . 91 7.4.2. Elliptic Curve Diffie-Hellman
7.4.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 92 7.5. Exporters
7.5. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 92 8. 0-RTT and Anti-Replay
8. 0-RTT and Anti-Replay . . . . . . . . . . . . . . . . . . . . 93 8.1. Single-Use Tickets
8.1. Single-Use Tickets . . . . . . . . . . . . . . . . . . . 94 8.2. Client Hello Recording
8.2. Client Hello Recording . . . . . . . . . . . . . . . . . 95 8.3. Freshness Checks
8.3. Freshness Checks . . . . . . . . . . . . . . . . . . . . 97 9. Compliance Requirements
9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 98 9.1. Mandatory-to-Implement Cipher Suites
9.1. Mandatory-to-Implement Cipher Suites . . . . . . . . . . 98 9.2. Mandatory-to-Implement Extensions
9.2. Mandatory-to-Implement Extensions . . . . . . . . . . . . 98 9.3. Protocol Invariants
9.3. Protocol Invariants . . . . . . . . . . . . . . . . . . . 99 10. Security Considerations
10. Security Considerations . . . . . . . . . . . . . . . . . . . 101 11. IANA Considerations
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 101 11.1. Changes for this RFC
11.1. Changes for this RFC . . . . . . . . . . . . . . . . . . 103 12. References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 104 12.1. Normative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 104 12.2. Informative References
12.2. Informative References . . . . . . . . . . . . . . . . . 107 Appendix A. State Machine
Appendix A. State Machine . . . . . . . . . . . . . . . . . . . 117 A.1. Client
A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 117 A.2. Server
A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 118 Appendix B. Protocol Data Structures and Constant Values
Appendix B. Protocol Data Structures and Constant Values . . . . 119 B.1. Record Layer
B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 120 B.2. Alert Messages
B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 120 B.3. Handshake Protocol
B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 121 B.3.1. Key Exchange Messages
B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 122 B.3.2. Server Parameters Messages
B.3.2. Server Parameters Messages . . . . . . . . . . . . . 127 B.3.3. Authentication Messages
B.3.3. Authentication Messages . . . . . . . . . . . . . . . 128 B.3.4. Ticket Establishment
B.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 129 B.3.5. Updating Keys
B.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 129 B.4. Cipher Suites
B.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 130 Appendix C. Implementation Notes
Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 131 C.1. Random Number Generation and Seeding
C.1. Random Number Generation and Seeding . . . . . . . . . . 131 C.2. Certificates and Authentication
C.2. Certificates and Authentication . . . . . . . . . . . . . 132 C.3. Implementation Pitfalls
C.3. Implementation Pitfalls . . . . . . . . . . . . . . . . . 132 C.4. Client and Server Tracking Prevention
C.4. Client and Server Tracking Prevention . . . . . . . . . . 134 C.5. Unauthenticated Operation
C.5. Unauthenticated Operation . . . . . . . . . . . . . . . . 135 Appendix D. Updates to TLS 1.2
Appendix D. Updates to TLS 1.2 . . . . . . . . . . . . . . . . . 135 Appendix E. Backward Compatibility
Appendix E. Backward Compatibility . . . . . . . . . . . . . . . 136 E.1. Negotiating with an Older Server
E.1. Negotiating with an Older Server . . . . . . . . . . . . 137 E.2. Negotiating with an Older Client
E.2. Negotiating with an Older Client . . . . . . . . . . . . 137 E.3. 0-RTT Backward Compatibility
E.3. 0-RTT Backward Compatibility . . . . . . . . . . . . . . 138 E.4. Middlebox Compatibility Mode
E.4. Middlebox Compatibility Mode . . . . . . . . . . . . . . 138 E.5. Security Restrictions Related to Backward Compatibility
E.5. Security Restrictions Related to Backward Appendix F. Overview of Security Properties
Compatibility . . . . . . . . . . . . . . . . . . . . . . 139 F.1. Handshake
Appendix F. Overview of Security Properties . . . . . . . . . . 140 F.1.1. Key Derivation and HKDF
F.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 140 F.1.2. Certificate-Based Client Authentication
F.1.1. Key Derivation and HKDF . . . . . . . . . . . . . . . 144 F.1.3. 0-RTT
F.1.2. Certificate-Based Client Authentication . . . . . . . 145 F.1.4. Exporter Independence
F.1.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . 145 F.1.5. Post-Compromise Security
F.1.4. Exporter Independence . . . . . . . . . . . . . . . . 145 F.1.6. External References
F.1.5. Post-Compromise Security . . . . . . . . . . . . . . 146 F.2. Record Layer
F.1.6. External References . . . . . . . . . . . . . . . . . 146 F.2.1. External References
F.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 146 F.3. Traffic Analysis
F.2.1. External References . . . . . . . . . . . . . . . . . 147 F.4. Side Channel Attacks
F.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 147 F.5. Replay Attacks on 0-RTT
F.4. Side Channel Attacks . . . . . . . . . . . . . . . . . . 148 F.5.1. Replay and Exporters
F.5. Replay Attacks on 0-RTT . . . . . . . . . . . . . . . . . 149 F.6. PSK Identity Exposure
F.5.1. Replay and Exporters . . . . . . . . . . . . . . . . 150 F.7. Sharing PSKs Across Protocol Versions
F.6. PSK Identity Exposure . . . . . . . . . . . . . . . . . . 151 F.8. External PSKs and Rerouting
F.7. Sharing PSKs Across Protocol Versions . . . . . . . . . . 151 F.9. Misbinding When Using Self-Signed Certificates or Raw
F.8. External PSKs and Rerouting . . . . . . . . . . . . . . . 151 Public Keys
F.9. Misbinding when using Self-Signed Certificates or Raw F.10. Attacks on Static RSA
Public Keys . . . . . . . . . . . . . . . . . . . . . . 152 Contributors
F.10. Attacks on Static RSA . . . . . . . . . . . . . . . . . . 152 Author's Address
Appendix G. Change Log . . . . . . . . . . . . . . . . . . . . . 152
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 161
1. Introduction 1. 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 The primary goal of TLS is to provide a secure channel between two
communicating peers; the only requirement from the underlying communicating peers; the only requirement from the underlying
transport is a reliable, in-order data stream. Specifically, the transport is a reliable, in-order data stream. Specifically, the
secure channel should provide the following properties: secure channel should provide the following properties:
* Authentication: The server side of the channel is always * Authentication: The server side of the channel is always
authenticated; the client side is optionally authenticated. authenticated; the client side is optionally authenticated.
Authentication can happen via asymmetric cryptography (e.g., RSA Authentication can happen via asymmetric cryptography (e.g., RSA
[RSA], the Elliptic Curve Digital Signature Algorithm (ECDSA) [RSA], the Elliptic Curve Digital Signature Algorithm (ECDSA)
[DSS], or the Edwards-Curve Digital Signature Algorithm (EdDSA) [DSS], or the Edwards-Curve Digital Signature Algorithm (EdDSA)
skipping to change at page 6, line 49 skipping to change at line 268
defined in Section 2.2. Because TLS 1.3 changes the way keys are defined in Section 2.2. Because TLS 1.3 changes the way keys are
derived, it updates [RFC5705] as described in Section 7.5. It also derived, it updates [RFC5705] as described in Section 7.5. It also
changes how Online Certificate Status Protocol (OCSP) messages are changes how Online Certificate Status Protocol (OCSP) messages are
carried and therefore updates [RFC6066] and obsoletes [RFC6961] as carried and therefore updates [RFC6066] and obsoletes [RFC6961] as
described in Section 4.4.2.1. described in Section 4.4.2.1.
1.1. Conventions and Terminology 1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms are used: 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 handshake: An initial negotiation between client and server that
establishes the parameters of their subsequent interactions within establishes the parameters of their subsequent interactions within
TLS. TLS.
peer: An endpoint. When discussing a particular endpoint, "peer" peer: An endpoint. When discussing a particular endpoint, "peer"
refers to the endpoint that is not the primary subject of discussion. 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. sender: An endpoint that is transmitting records.
server: The endpoint that did not initiate the TLS connection. server: The endpoint that did not initiate the TLS connection.
1.2. Relationship to RFC 8446 1.2. Relationship to RFC 8446
TLS 1.3 was originally specified in [RFC8446]. This document is a TLS 1.3 was originally specified in [RFC8446]. This document is a
minor update to TLS 1.3 that retains the same version number and is minor update to TLS 1.3 that retains the same version number and is
backward compatible. It tightens some requirements and contains backward compatible. It tightens some requirements and contains
updated text in areas which were found to be unclear as well as other updated text in areas which were found to be unclear as well as other
editorial improvements. In addition, it removes the use of the term editorial improvements. In addition, it removes the use of the term
"master" as applied to secrets in favor of the term "main" or shorter "master" as applied to secrets in favor of the term "main" or shorter
names where no term was necessary. This document makes the following names where no term was necessary. This document makes the following
skipping to change at page 9, line 5 skipping to change at line 370
* The key derivation function has been redesigned. The new design * The key derivation function has been redesigned. The new design
allows easier analysis by cryptographers due to their improved key allows easier analysis by cryptographers due to their improved key
separation properties. The HMAC-based Extract-and-Expand Key separation properties. The HMAC-based Extract-and-Expand Key
Derivation Function (HKDF) is used as an underlying primitive. Derivation Function (HKDF) is used as an underlying primitive.
* The handshake state machine has been significantly restructured to * The handshake state machine has been significantly restructured to
be more consistent and to remove superfluous messages such as be more consistent and to remove superfluous messages such as
ChangeCipherSpec (except when needed for middlebox compatibility). ChangeCipherSpec (except when needed for middlebox compatibility).
* Elliptic curve algorithms are now in the base spec and new * Elliptic curve algorithms are now in the base specification, and
signature algorithms, such as EdDSA, are included. TLS 1.3 new signature algorithms, such as EdDSA, are included. TLS 1.3
removed point format negotiation in favor of a single point format removed point format negotiation in favor of a single point format
for each curve. for each curve.
* Other cryptographic improvements were made, including changing the * Other cryptographic improvements were made, including changing the
RSA padding to use the RSA Probabilistic Signature Scheme (RSASSA- RSA padding to use the RSA Probabilistic Signature Scheme (RSASSA-
PSS), and the removal of compression, the Digital Signature PSS) and the removal of compression, the Digital Signature
Algorithm (DSA), and custom Ephemeral Diffie-Hellman (DHE) groups. Algorithm (DSA), and custom Ephemeral Diffie-Hellman (DHE) groups.
* The TLS 1.2 version negotiation mechanism has been deprecated in * The TLS 1.2 version negotiation mechanism has been deprecated in
favor of a version list in an extension. This increases favor of a version list in an extension. This increases
compatibility with existing servers that incorrectly implemented compatibility with existing servers that incorrectly implemented
version negotiation. version negotiation.
* Session resumption with and without server-side state as well as * Session resumption with and without server-side state as well as
the PSK-based cipher suites of earlier TLS versions have been the PSK-based cipher suites of earlier TLS versions have been
replaced by a single new PSK exchange. replaced by a single new PSK exchange.
skipping to change at page 11, line 5 skipping to change at line 444
* (EC)DHE (Diffie-Hellman over either finite fields or elliptic * (EC)DHE (Diffie-Hellman over either finite fields or elliptic
curves) curves)
* PSK-only * PSK-only
* PSK with (EC)DHE * PSK with (EC)DHE
Figure 1 below shows the basic full TLS handshake: Figure 1 below shows the basic full TLS handshake:
Client Server Client Server
Key ^ ClientHello Key ^ ClientHello
Exch | + key_share* Exch | + key_share*
| + signature_algorithms* | + signature_algorithms*
| + psk_key_exchange_modes* | + psk_key_exchange_modes*
v + pre_shared_key* --------> v + pre_shared_key* -------->
ServerHello ^ Key ServerHello ^ Key
+ key_share* | Exch + key_share* | Exch
+ pre_shared_key* v + pre_shared_key* v
{EncryptedExtensions} ^ Server {EncryptedExtensions} ^ Server
{CertificateRequest*} v Params {CertificateRequest*} v Params
{Certificate*} ^ {Certificate*} ^
{CertificateVerify*} | Auth {CertificateVerify*} | Auth
{Finished} v {Finished} v
<-------- [Application Data*] <-------- [Application Data*]
^ {Certificate*} ^ {Certificate*}
Auth | {CertificateVerify*} Auth | {CertificateVerify*}
v {Finished} --------> v {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the + Indicates noteworthy extensions sent in the
previously noted message. previously noted message.
* Indicates optional or situation-dependent * Indicates optional or situation-dependent
messages/extensions that are not always sent. messages/extensions that are not always sent.
{} Indicates messages protected using keys {} Indicates messages protected using keys
derived from a [sender]_handshake_traffic_secret. derived from a [sender]_handshake_traffic_secret.
skipping to change at page 14, line 5 skipping to change at line 578
2.1. Incorrect DHE Share 2.1. Incorrect DHE Share
If the client has not provided a sufficient "key_share" extension If the client has not provided a sufficient "key_share" extension
(e.g., it includes only DHE or ECDHE groups unacceptable to or (e.g., it includes only DHE or ECDHE groups unacceptable to or
unsupported by the server), the server corrects the mismatch with a unsupported by the server), the server corrects the mismatch with a
HelloRetryRequest and the client needs to restart the handshake with HelloRetryRequest and the client needs to restart the handshake with
an appropriate "key_share" extension, as shown in Figure 2. If no an appropriate "key_share" extension, as shown in Figure 2. If no
common cryptographic parameters can be negotiated, the server MUST common cryptographic parameters can be negotiated, the server MUST
abort the handshake with an appropriate alert. abort the handshake with an appropriate alert.
Client Server Client Server
ClientHello ClientHello
+ key_share --------> + key_share -------->
HelloRetryRequest HelloRetryRequest
<-------- + key_share <-------- + key_share
ClientHello ClientHello
+ key_share --------> + key_share -------->
ServerHello ServerHello
+ key_share + key_share
{EncryptedExtensions} {EncryptedExtensions}
{CertificateRequest*} {CertificateRequest*}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} {Finished}
<-------- [Application Data*] <-------- [Application Data*]
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Figure 2: Message Flow for a Full Handshake with Mismatched Figure 2: Message Flow for a Full Handshake with Mismatched
Parameters Parameters
Note: The handshake transcript incorporates the initial ClientHello/ Note: The handshake transcript incorporates the initial ClientHello/
HelloRetryRequest exchange; it is not reset with the new ClientHello. HelloRetryRequest exchange; it is not reset with the new ClientHello.
TLS also allows several optimized variants of the basic handshake, as TLS also allows several optimized variants of the basic handshake, as
described in the following sections. described in the following sections.
skipping to change at page 16, line 12 skipping to change at line 679
to the server to allow the server to decline resumption and fall back to the server to allow the server to decline resumption and fall back
to a full handshake, if needed. The server responds with a to a full handshake, if needed. The server responds with a
"pre_shared_key" extension to negotiate the use of PSK key "pre_shared_key" extension to negotiate the use of PSK key
establishment and can (as shown here) respond with a "key_share" establishment and can (as shown here) respond with a "key_share"
extension to do (EC)DHE key establishment, thus providing forward extension to do (EC)DHE key establishment, thus providing forward
secrecy. secrecy.
When PSKs are provisioned externally, the PSK identity and the KDF When PSKs are provisioned externally, the PSK identity and the KDF
hash algorithm to be used with the PSK MUST also be provisioned. hash algorithm to be used with the PSK MUST also be provisioned.
Note: When using an externally provisioned pre-shared secret, a Note: When using an externally provisioned pre-shared secret, a
critical consideration is using sufficient entropy during the key critical consideration is using sufficient entropy during the key
generation, as discussed in [RFC4086]. Deriving a shared secret generation, as discussed in [RFC4086]. Deriving a shared secret from
from a password or other low-entropy sources is not secure. A a password or other low-entropy sources is not secure. A low-entropy
low-entropy secret, or password, is subject to dictionary attacks secret, or password, is subject to dictionary attacks based on the
based on the PSK binder. The specified PSK authentication is not PSK binder. The specified PSK authentication is not a strong
a strong password-based authenticated key exchange even when used password-based authenticated key exchange even when used with Diffie-
with Diffie-Hellman key establishment. Specifically, it does not Hellman key establishment. Specifically, it does not prevent an
prevent an attacker that can observe the handshake from performing attacker that can observe the handshake from performing a brute-force
a brute-force attack on the password/pre-shared key. attack on the password/pre-shared key.
2.3. 0-RTT Data 2.3. 0-RTT Data
When clients and servers share a PSK (either obtained externally or When clients and servers share a PSK (either obtained externally or
via a previous handshake), TLS 1.3 allows clients to send data on the via a previous handshake), TLS 1.3 allows clients to send data on the
first flight ("early data"). The client uses the PSK to authenticate first flight ("early data"). The client uses the PSK to authenticate
the server and to encrypt the early data. the server and to encrypt the early data.
As shown in Figure 4, the 0-RTT data is just added to the 1-RTT As shown in Figure 4, the 0-RTT data is just added to the 1-RTT
handshake in the first flight. The rest of the handshake uses the handshake in the first flight. The rest of the handshake uses the
same messages as for a 1-RTT handshake with PSK resumption. same messages as for a 1-RTT handshake with PSK resumption.
Client Server Client Server
ClientHello ClientHello
+ early_data + early_data
+ key_share* + key_share*
+ psk_key_exchange_modes + psk_key_exchange_modes
+ pre_shared_key + pre_shared_key
(Application Data*) --------> (Application Data*) -------->
ServerHello ServerHello
+ pre_shared_key + pre_shared_key
+ key_share* + key_share*
{EncryptedExtensions} {EncryptedExtensions}
+ early_data* + early_data*
{Finished} {Finished}
<-------- [Application Data*] <-------- [Application Data*]
(EndOfEarlyData) (EndOfEarlyData)
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the + Indicates noteworthy extensions sent in the
previously noted message. previously noted message.
* Indicates optional or situation-dependent * Indicates optional or situation-dependent
messages/extensions that are not always sent. messages/extensions that are not always sent.
() Indicates messages protected using keys () Indicates messages protected using keys
derived from a client_early_traffic_secret. derived from a client_early_traffic_secret.
{} Indicates messages protected using keys {} Indicates messages protected using keys
derived from a [sender]_handshake_traffic_secret. derived from a [sender]_handshake_traffic_secret.
[] Indicates messages protected using keys [] Indicates messages protected using keys
derived from [sender]_application_traffic_secret_N. derived from [sender]_application_traffic_secret_N.
Figure 4: Message Flow for a 0-RTT Handshake Figure 4: Message Flow for a 0-RTT Handshake
IMPORTANT NOTE: The security properties for 0-RTT data are weaker IMPORTANT NOTE: The security properties for 0-RTT data are weaker
than those for other kinds of TLS data. Specifically: than those for other kinds of TLS data. Specifically:
1. The protocol does not provide any forward secrecy guarantees for 1. The protocol does not provide any forward secrecy guarantees for
this data. The server's behavior determines what forward secrecy this data. The server's behavior determines what forward secrecy
guarantees, if any, apply (see Section 8.1). This behavior is guarantees, if any, apply (see Section 8.1). This behavior is
not communicated to the client as part of the protocol. not communicated to the client as part of the protocol.
skipping to change at page 29, line 38 skipping to change at line 1303
legacy_compression_method: A single byte which MUST have the value legacy_compression_method: A single byte which MUST have the value
0. If a TLS 1.3 ServerHello is received with any other value in 0. If a TLS 1.3 ServerHello is received with any other value in
this field, the client MUST abort the handshake with an this field, the client MUST abort the handshake with an
"illegal_parameter" alert. "illegal_parameter" alert.
extensions: A list of extensions. The ServerHello MUST only include extensions: A list of extensions. The ServerHello MUST only include
extensions which are required to establish the cryptographic extensions which are required to establish the cryptographic
context and negotiate the protocol version. All TLS 1.3 context and negotiate the protocol version. All TLS 1.3
ServerHello messages MUST contain the "supported_versions" ServerHello messages MUST contain the "supported_versions"
extension. Current ServerHello messages additionally contain extension. Current ServerHello messages additionally contain the
either the "pre_shared_key" extension or the "key_share" "pre_shared_key" extension or the "key_share" extension, or both
extension, or both (when using a PSK with (EC)DHE key (when using a PSK with (EC)DHE key establishment). Other
establishment). Other extensions (see Section 4.2) are sent extensions (see Section 4.2) are sent separately in the
separately in the EncryptedExtensions message. EncryptedExtensions message.
For reasons of backward compatibility with middleboxes (see For reasons of backward compatibility with middleboxes (see
Appendix E.4), the HelloRetryRequest message uses the same structure Appendix E.4), the HelloRetryRequest message uses the same structure
as the ServerHello, but with Random set to the special value of the as the ServerHello, but with Random set to the special value of the
SHA-256 of "HelloRetryRequest": SHA-256 of "HelloRetryRequest":
CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91 CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91
C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C
Upon receiving a message with type server_hello, implementations MUST Upon receiving a message with type server_hello, implementations MUST
first examine the Random value and, if it matches this value, process first examine the Random value and, if it matches this value, process
it as described in Section 4.1.4). it as described in Section 4.1.4.
TLS 1.3 has a downgrade protection mechanism embedded in the server's 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 random value. TLS 1.3 servers which negotiate TLS 1.2 or below in
response to a ClientHello MUST set the last 8 bytes of their Random response to a ClientHello MUST set the last 8 bytes of their Random
value specially in their ServerHello. value specially in their ServerHello.
If negotiating TLS 1.2, TLS 1.3 servers MUST set the last 8 bytes of If negotiating TLS 1.2, TLS 1.3 servers MUST set the last 8 bytes of
their Random value to the bytes: their Random value to the bytes:
44 4F 57 4E 47 52 44 01 44 4F 57 4E 47 52 44 01
skipping to change at page 34, line 36 skipping to change at line 1533
| client_certificate_type [RFC7250] | CH, EE | | client_certificate_type [RFC7250] | CH, EE |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| server_certificate_type [RFC7250] | CH, EE | | server_certificate_type [RFC7250] | CH, EE |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| padding [RFC7685] | CH | | padding [RFC7685] | CH |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| cached_info [RFC7924] | CH, EE | | cached_info [RFC7924] | CH, EE |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| compress_certificate [RFC8879] | CH, CR | | compress_certificate [RFC8879] | CH, CR |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| record_size_limit [RFC8849] | CH, EE | | record_size_limit [RFC8449] | CH, EE |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| delegated_credentials [RFC9345] | CH, CR, CT | | delegated_credentials [RFC9345] | CH, CR, CT |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| supported_ekt_ciphers [RFC8870] | CH, EE | | supported_ekt_ciphers [RFC8870] | CH, EE |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| pre_shared_key [RFC8446] | CH, SH | | pre_shared_key [RFC8446] | CH, SH |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| early_data [RFC8446] | CH, EE, NST | | early_data [RFC8446] | CH, EE, NST |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| psk_key_exchange_modes [RFC8446] | CH | | psk_key_exchange_modes [RFC8446] | CH |
skipping to change at page 35, line 28 skipping to change at line 1574
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| external_session_id [RFC8844] | CH, EE | | external_session_id [RFC8844] | CH, EE |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| quic_transport_parameters [RFC9001] | CH, EE | | quic_transport_parameters [RFC9001] | CH, EE |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| ticket_request [RFC9149] | CH, EE | | ticket_request [RFC9149] | CH, EE |
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
Table 1: TLS Extensions Table 1: TLS Extensions
Note: this table includes only extensions marked "Recommended" at the Note: This table includes only extensions marked "Recommended" at the
time of this writing. time of this writing.
When multiple extensions of different types are present, the When multiple extensions of different types are present, the
extensions MAY appear in any order, with the exception of extensions MAY appear in any order, with the exception of
"pre_shared_key" (Section 4.2.11) which MUST be the last extension in "pre_shared_key" (Section 4.2.11) which MUST be the last extension in
the ClientHello (but can appear anywhere in the ServerHello the ClientHello (but can appear anywhere in the ServerHello
extensions block). There MUST NOT be more than one extension of the extensions block). There MUST NOT be more than one extension of the
same type in a given extension block. same type in a given extension block.
In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each
skipping to change at page 57, line 49 skipping to change at line 2618
the "signature_algorithms" and optionally "signature_algorithms_cert" the "signature_algorithms" and optionally "signature_algorithms_cert"
extensions. The latter is expressed by sending the extensions. The latter is expressed by sending the
"certificate_authorities" extension (see Section 4.2.4). "certificate_authorities" extension (see Section 4.2.4).
Servers which are authenticating with a resumption PSK MUST NOT send Servers which are authenticating with a resumption PSK MUST NOT send
the CertificateRequest message in the main handshake, though they MAY the CertificateRequest message in the main handshake, though they MAY
send it in post-handshake authentication (see Section 4.6.2) provided send it in post-handshake authentication (see Section 4.6.2) provided
that the client has sent the "post_handshake_auth" extension (see that the client has sent the "post_handshake_auth" extension (see
Section 4.2.6). In the absence of some other specification to the Section 4.2.6). In the absence of some other specification to the
contrary, servers which are authenticating with an external PSK MUST contrary, servers which are authenticating with an external PSK MUST
NOT send the CertificateRequest message either in the main handshake NOT send the CertificateRequest message in the main handshake or
or request post-handshake authentication. [RFC8773] provides an request post-handshake authentication. [RFC8773] provides an
extension to permit this, but has received less analysis than this extension to permit this but has received less analysis than this
specification. specification.
4.4. Authentication Messages 4.4. Authentication Messages
As discussed in Section 2, TLS generally uses a common set of As discussed in Section 2, TLS generally uses a common set of
messages for authentication, key confirmation, and handshake messages for authentication, key confirmation, and handshake
integrity: Certificate, CertificateVerify, and Finished. (The PSK integrity: Certificate, CertificateVerify, and Finished. (The PSK
binders also perform key confirmation, in a similar fashion.) These binders also perform key confirmation, in a similar fashion.) These
three messages are always sent as the last messages in their three messages are always sent as the last messages in their
handshake flight. The Certificate and CertificateVerify messages are handshake flight. The Certificate and CertificateVerify messages are
skipping to change at page 58, line 31 skipping to change at line 2649
* The certificate and signing key to be used. * The certificate and signing key to be used.
* A Handshake Context consisting of the list of messages to be * A Handshake Context consisting of the list of messages to be
included in the transcript hash. included in the transcript hash.
* A Base Key to be used to compute a MAC key. * A Base Key to be used to compute a MAC key.
Based on these inputs, the messages then contain: Based on these inputs, the messages then contain:
Certificate The certificate to be used for authentication, and any Certificate: The certificate to be used for authentication, and any
supporting certificates in the chain. Note that certificate-based supporting certificates in the chain. Note that certificate-based
client authentication is not available in PSK handshake flows client authentication is not available in PSK handshake flows
(including 0-RTT). (including 0-RTT).
CertificateVerify: A signature over the value Transcript- CertificateVerify: A signature over the value Transcript-
Hash(Handshake Context, Certificate) Hash(Handshake Context, Certificate).
Finished: A MAC over the value Transcript-Hash(Handshake Context, Finished: A MAC over the value Transcript-Hash(Handshake Context,
Certificate, CertificateVerify) using a MAC key derived from the Certificate, CertificateVerify) using a MAC key derived from the
Base Key. Base Key.
The following table defines the Handshake Context and MAC Base Key The following table defines the Handshake Context and MAC Base Key
for each scenario: for each scenario:
+=========+====================+=====================================+ +=========+====================+=====================================+
|Mode |Handshake Context |Base Key | |Mode |Handshake Context |Base Key |
skipping to change at page 61, line 5 skipping to change at line 2744
has requested certificate-based client authentication via a has requested certificate-based client authentication via a
CertificateRequest message (Section 4.3.2). If the server requests CertificateRequest message (Section 4.3.2). If the server requests
certificate-based client authentication but no suitable certificate certificate-based client authentication but no suitable certificate
is available, the client MUST send a Certificate message containing is available, the client MUST send a Certificate message containing
no certificates (i.e., with the "certificate_list" field having no certificates (i.e., with the "certificate_list" field having
length 0). A Finished message MUST be sent regardless of whether the length 0). A Finished message MUST be sent regardless of whether the
Certificate message is empty. Certificate message is empty.
Structure of this message: Structure of this message:
enum { enum {
X509(0), X509(0),
RawPublicKey(2), RawPublicKey(2),
(255) (255)
} CertificateType; } CertificateType;
struct { struct {
select (certificate_type) { select (certificate_type) {
case RawPublicKey: case RawPublicKey:
/* From RFC 7250 ASN.1_subjectPublicKeyInfo */ /* From RFC 7250 ASN.1_subjectPublicKeyInfo */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
case X509: case X509:
opaque cert_data<1..2^24-1>; opaque cert_data<1..2^24-1>;
}; };
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} CertificateEntry; } CertificateEntry;
struct { struct {
opaque certificate_request_context<0..2^8-1>; opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>; CertificateEntry certificate_list<0..2^24-1>;
} Certificate; } Certificate;
certificate_request_context: If this message is in response to a certificate_request_context: If this message is in response to a
CertificateRequest, the value of certificate_request_context in CertificateRequest, the value of certificate_request_context in
that message. Otherwise (in the case of server authentication), that message. Otherwise (in the case of server authentication),
this field SHALL be zero length. this field SHALL be zero length.
certificate_list: A list (chain) of CertificateEntry structures, certificate_list: A list (chain) of CertificateEntry structures,
each containing a single certificate and list of extensions. each containing a single certificate and list of extensions.
extensions: A list of extension values for the CertificateEntry. extensions: A list of extension values for the CertificateEntry.
skipping to change at page 64, line 25 skipping to change at line 2904
If the sender is the server, and the server cannot produce a If the sender is the server, and the server cannot produce a
certificate chain that is signed only via the indicated supported certificate chain that is signed only via the indicated supported
algorithms, then it SHOULD continue the handshake by sending a algorithms, then it SHOULD continue the handshake by sending a
certificate chain of its choice that may include algorithms that are certificate chain of its choice that may include algorithms that are
not known to be supported by the client. This fallback chain MUST not known to be supported by the client. This fallback chain MUST
NOT use the deprecated SHA-1 hash, unless the client specifically NOT use the deprecated SHA-1 hash, unless the client specifically
advertises that it is willing to accept SHA-1. advertises that it is willing to accept SHA-1.
If the sender is the client, the client MAY use a fallback chain as If the sender is the client, the client MAY use a fallback chain as
above, or continue the handshake anonymously. above or continue the handshake anonymously.
If the receiver cannot construct an acceptable chain using the If the receiver cannot construct an acceptable chain using the
provided certificates and decides to abort the handshake, then it provided certificates and decides to abort the handshake, then it
MUST abort the handshake with an appropriate certificate-related MUST abort the handshake with an appropriate certificate-related
alert (by default, "unsupported_certificate"; see Section 6.2 for alert (by default, "unsupported_certificate"; see Section 6.2 for
more information). more information).
If the sender has multiple certificates, it chooses one of them based If the sender has multiple certificates, it chooses one of them based
on the above-mentioned criteria (in addition to other criteria, such on the above-mentioned criteria (in addition to other criteria, such
as transport-layer endpoint, local configuration, and preferences). as transport-layer endpoint, local configuration, and preferences).
skipping to change at page 66, line 30 skipping to change at line 2995
* The content to be signed * The content to be signed
This structure is intended to prevent an attack on previous versions This structure is intended to prevent an attack on previous versions
of TLS in which the ServerKeyExchange format meant that attackers of TLS in which the ServerKeyExchange format meant that attackers
could obtain a signature of a message with a chosen 32-byte prefix could obtain a signature of a message with a chosen 32-byte prefix
(ClientHello.random). The initial 64-byte pad clears that prefix (ClientHello.random). The initial 64-byte pad clears that prefix
along with the server-controlled ServerHello.random. along with the server-controlled ServerHello.random.
The context string for a server signature is "TLS 1.3, server The context string for a server signature is "TLS 1.3, server
CertificateVerify" The context string for a client signature is "TLS CertificateVerify". The context string for a client signature is
1.3, client CertificateVerify" It is used to provide separation "TLS 1.3, client CertificateVerify". It is used to provide
between signatures made in different contexts, helping against separation between signatures made in different contexts, helping
potential cross-protocol attacks. against potential cross-protocol attacks.
For example, if the transcript hash was 32 bytes of 01 (this length For example, if the transcript hash was 32 bytes of 01 (this length
would make sense for SHA-256), the content covered by the digital would make sense for SHA-256), the content covered by the digital
signature for a server CertificateVerify would be: signature for a server CertificateVerify would be:
2020202020202020202020202020202020202020202020202020202020202020 2020202020202020202020202020202020202020202020202020202020202020
2020202020202020202020202020202020202020202020202020202020202020 2020202020202020202020202020202020202020202020202020202020202020
544c5320312e332c207365727665722043657274696669636174655665726966 544c5320312e332c207365727665722043657274696669636174655665726966
79 79
00 00
skipping to change at page 68, line 32 skipping to change at line 3095
opaque verify_data[Hash.length]; opaque verify_data[Hash.length];
} Finished; } Finished;
The verify_data value is computed as follows: The verify_data value is computed as follows:
verify_data = verify_data =
HMAC(finished_key, HMAC(finished_key,
Transcript-Hash(Handshake Context, Transcript-Hash(Handshake Context,
Certificate*, CertificateVerify*)) Certificate*, CertificateVerify*))
* Only included if present. * Only included if present.
HMAC [RFC2104] uses the Hash algorithm for the handshake. As noted HMAC [RFC2104] uses the Hash algorithm for the handshake. As noted
above, the HMAC input can generally be implemented by a running hash, above, the HMAC input can generally be implemented by a running hash,
i.e., just the handshake hash at this point. i.e., just the handshake hash at this point.
In previous versions of TLS, the verify_data was always 12 octets In previous versions of TLS, the verify_data was always 12 octets
long. In TLS 1.3, it is the size of the HMAC output for the Hash long. In TLS 1.3, it is the size of the HMAC output for the Hash
used for the handshake. used for the handshake.
Note: Alerts and any other non-handshake record types are not Note: Alerts and any other non-handshake record types are not
skipping to change at page 69, line 30 skipping to change at line 3138
4.6. Post-Handshake Messages 4.6. Post-Handshake Messages
TLS also allows other messages to be sent after the main handshake. TLS also allows other messages to be sent after the main handshake.
These messages use a handshake content type and are encrypted under These messages use a handshake content type and are encrypted under
the appropriate application traffic key. the appropriate application traffic key.
4.6.1. New Session Ticket Message 4.6.1. New Session Ticket Message
If the client's hello contained a suitable "psk_key_exchange_modes" If the client's hello contained a suitable "psk_key_exchange_modes"
extension, at any time after the server has received the client extension at any time after the server has received the client
Finished message, it MAY send a NewSessionTicket message. This Finished message, it MAY send a NewSessionTicket message. This
message creates a unique association between the ticket value and a message creates a unique association between the ticket value and a
secret PSK derived from the resumption secret (see Section 7). secret PSK derived from the resumption secret (see Section 7).
The client MAY use this PSK for future handshakes by including the The client MAY use this PSK for future handshakes by including the
ticket value in the "pre_shared_key" extension in its ClientHello ticket value in the "pre_shared_key" extension in its ClientHello
(Section 4.2.11). Clients which receive a NewSessionTicket message (Section 4.2.11). Clients which receive a NewSessionTicket message
but do not support resumption MUST silently ignore this message. but do not support resumption MUST silently ignore this message.
Resumption MAY be done while the original connection is still open. Resumption MAY be done while the original connection is still open.
Servers MAY send multiple tickets on a single connection, either Servers MAY send multiple tickets on a single connection, either
skipping to change at page 73, line 51 skipping to change at line 3352
chance of a joint key/IV collision is much lower. To provide an chance of a joint key/IV collision is much lower. To provide an
extra margin of security, sending implementations MUST NOT allow the extra margin of security, sending implementations MUST NOT allow the
epoch -- and hence the number of key updates -- to exceed 2^48-1. In epoch -- and hence the number of key updates -- to exceed 2^48-1. In
order to allow this value to be changed later -- for instance for order to allow this value to be changed later -- for instance for
ciphers with more than 128-bit keys -- receiving implementations MUST ciphers with more than 128-bit keys -- receiving implementations MUST
NOT enforce this rule. If a sending implementation receives a NOT enforce this rule. If a sending implementation receives a
KeyUpdate with request_update set to "update_requested", it MUST NOT KeyUpdate with request_update set to "update_requested", it MUST NOT
send its own KeyUpdate if that would cause it to exceed these limits send its own KeyUpdate if that would cause it to exceed these limits
and SHOULD instead ignore the "update_requested" flag. This may and SHOULD instead ignore the "update_requested" flag. This may
result in an eventual need to terminate the connection when the result in an eventual need to terminate the connection when the
limits in Section 5.5 are reached. limits described in Section 5.5 are reached.
5. Record Protocol 5. Record Protocol
The TLS record protocol takes messages to be transmitted, fragments The TLS record protocol takes messages to be transmitted, fragments
the data into manageable blocks, protects the records, and transmits the data into manageable blocks, protects the records, and transmits
the result. Received data is verified, decrypted, reassembled, and the result. Received data is verified, decrypted, reassembled, and
then delivered to higher-level clients. then delivered to higher-level clients.
TLS records are typed, which allows multiple higher-level protocols TLS records are typed, which allows multiple higher-level protocols
to be multiplexed over the same record layer. This document to be multiplexed over the same record layer. This document
skipping to change at page 78, line 43 skipping to change at line 3580
AEADEncrypted = AEADEncrypted =
AEAD-Encrypt(write_key, nonce, additional_data, plaintext) AEAD-Encrypt(write_key, nonce, additional_data, plaintext)
The encrypted_record field of TLSCiphertext is set to AEADEncrypted. The encrypted_record field of TLSCiphertext is set to AEADEncrypted.
To decrypt and verify, the cipher takes as input the key, nonce, To decrypt and verify, the cipher takes as input the key, nonce,
additional data, and the AEADEncrypted value. The output is either additional data, and the AEADEncrypted value. The output is either
the plaintext or an error indicating that the decryption failed. the plaintext or an error indicating that the decryption failed.
There is no separate integrity check. Symbolically, There is no separate integrity check. Symbolically,
plaintext of encrypted_record = plaintext of encrypted_record =
AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted) AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted)
If the decryption fails, the receiver MUST terminate the connection If the decryption fails, the receiver MUST terminate the connection
with a "bad_record_mac" alert. with a "bad_record_mac" alert.
An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion 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 greater than 255 octets. An endpoint that receives a record from its
peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST
terminate the connection with a "record_overflow" alert. This limit terminate the connection with a "record_overflow" alert. This limit
is derived from the maximum TLSInnerPlaintext length of 2^14 octets + is derived from the maximum TLSInnerPlaintext length of 2^14 octets +
1 octet for ContentType + the maximum AEAD expansion of 255 octets. 1 octet for ContentType + the maximum AEAD expansion of 255 octets.
skipping to change at page 81, line 13 skipping to change at line 3687
request mechanism through TLS extensions or some other means. request mechanism through TLS extensions or some other means.
5.5. Limits on Key Usage 5.5. Limits on Key Usage
There are cryptographic limits on the amount of plaintext which can There are cryptographic limits on the amount of plaintext which can
be safely encrypted under a given set of keys. [AEAD-LIMITS] be safely encrypted under a given set of keys. [AEAD-LIMITS]
provides an analysis of these limits under the assumption that the provides an analysis of these limits under the assumption that the
underlying primitive (AES or ChaCha20) has no weaknesses. underlying primitive (AES or ChaCha20) has no weaknesses.
Implementations MUST either close the connection or do a key update Implementations MUST either close the connection or do a key update
as described in Section 4.6.3 prior to reaching these limits. Note as described in Section 4.6.3 prior to reaching these limits. Note
that it is not possible to perform a KeyUpdate for early data and that it is not possible to perform a KeyUpdate for early data;
therefore implementations MUST NOT exceed the limits when sending therefore, implementations MUST NOT exceed the limits when sending
early data. Receiving implementations SHOULD NOT enforce these early data. Receiving implementations SHOULD NOT enforce these
limits, as future analyses may result in updated values. limits, as future analyses may result in updated values.
For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be
encrypted on a given connection while keeping a safety margin of encrypted on a given connection while keeping a safety margin of
approximately 2^-57 for Authenticated Encryption (AE) security. For approximately 2^-57 for Authenticated Encryption (AE) security. For
ChaCha20/Poly1305, the record sequence number would wrap before the ChaCha20/Poly1305, the record sequence number would wrap before the
safety limit is reached. safety limit is reached.
6. Alert Protocol 6. Alert Protocol
skipping to change at page 83, line 45 skipping to change at line 3814
discarding pending writes and sending an immediate "close_notify" discarding pending writes and sending an immediate "close_notify"
alert of their own. That previous requirement could cause truncation alert of their own. That previous requirement could cause truncation
in the read side. Both parties need not wait to receive a in the read side. Both parties need not wait to receive a
"close_notify" alert before closing their read side of the "close_notify" alert before closing their read side of the
connection, though doing so would introduce the possibility of connection, though doing so would introduce the possibility of
truncation. truncation.
Application protocols MAY choose to flush their send buffers and Application protocols MAY choose to flush their send buffers and
immediately send a close_notify upon receiving a close_notify, but immediately send a close_notify upon receiving a close_notify, but
this allows an attacker to influence the data that the peer receives this allows an attacker to influence the data that the peer receives
by delaying the close_notify or by delaying the transport level by delaying the close_notify or by delaying the transport-level
delivery of the application's packets. These issues can be addressed delivery of the application's packets. These issues can be addressed
at the application layer, for instance by ignoring packets received at the application layer, for instance by ignoring packets received
after transmitting the close_notify. after transmitting the close_notify.
If the application protocol using TLS provides that any data may be If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is carried over the underlying transport after the TLS connection is
closed, the TLS implementation MUST receive a "close_notify" alert closed, the TLS implementation MUST receive a "close_notify" alert
before indicating end-of-data to the application layer. No part of before indicating end-of-data to the application layer. No part of
this standard should be taken to dictate the manner in which a usage this standard should be taken to dictate the manner in which a usage
profile for TLS manages its data transport, including when profile for TLS manages its data transport, including when
skipping to change at page 87, line 27 skipping to change at line 3985
7.1. Key Schedule 7.1. Key Schedule
The key derivation process makes use of the HKDF-Extract and HKDF- The key derivation process makes use of the HKDF-Extract and HKDF-
Expand functions as defined for HKDF [RFC5869], as well as the Expand functions as defined for HKDF [RFC5869], as well as the
functions defined below: functions defined below:
HKDF-Expand-Label(Secret, Label, Context, Length) = HKDF-Expand-Label(Secret, Label, Context, Length) =
HKDF-Expand(Secret, HkdfLabel, Length) HKDF-Expand(Secret, HkdfLabel, Length)
Where HkdfLabel is specified as: Where HkdfLabel is specified as:
struct { struct {
uint16 length = Length; uint16 length = Length;
opaque label<7..255> = "tls13 " + Label; opaque label<7..255> = "tls13 " + Label;
opaque context<0..255> = Context; opaque context<0..255> = Context;
} HkdfLabel; } HkdfLabel;
Derive-Secret(Secret, Label, Messages) = Derive-Secret(Secret, Label, Messages) =
HKDF-Expand-Label(Secret, Label, HKDF-Expand-Label(Secret, Label,
Transcript-Hash(Messages), Hash.length) Transcript-Hash(Messages), Hash.length)
skipping to change at page 88, line 21 skipping to change at line 4028
Derive-Secret functions. The general pattern for adding a new secret Derive-Secret functions. The general pattern for adding a new secret
is to use HKDF-Extract with the Salt being the current secret state is to use HKDF-Extract with the Salt being the current secret state
and the Input Keying Material (IKM) being the new secret to be added. and the Input Keying Material (IKM) being the new secret to be added.
In this version of TLS 1.3, the two input secrets are: In this version of TLS 1.3, the two input secrets are:
* PSK (a pre-shared key established externally or derived from the * PSK (a pre-shared key established externally or derived from the
resumption_secret value from a previous connection) resumption_secret value from a previous connection)
* (EC)DHE shared secret (Section 7.4) * (EC)DHE shared secret (Section 7.4)
This produces the key schedule shown in the diagram below (Figure 5. This produces the key schedule shown in the diagram below (Figure 5).
In this diagram, the following formatting conventions apply: In this diagram, the following formatting conventions apply:
* HKDF-Extract is drawn as taking the Salt argument from the top and * 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 the IKM argument from the left, with its output to the bottom and
the name of the output on the right. the name of the output on the right.
* Derive-Secret's Secret argument is indicated by the incoming * Derive-Secret's Secret argument is indicated by the incoming
arrow. For instance, the Early Secret is the Secret for arrow. For instance, the Early Secret is the Secret for
generating the client_early_traffic_secret. generating the client_early_traffic_secret.
* "0" indicates a string of Hash.length bytes set to zero. * "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 the values are referred to as "main" secrets. This mismatch is a
result of renaming the values while retaining compatibility. result of renaming the values while retaining compatibility.
Note: this does not show all the leaf keys such as the separate AEAD 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 and IV keys but rather the first set of secrets derived from the
handshake. handshake.
0 0
| |
v v
PSK --> HKDF-Extract = Early Secret PSK --> HKDF-Extract = Early Secret
| |
+-----> Derive-Secret(., +-----> Derive-Secret(.,
| "ext binder" | | "ext binder" |
skipping to change at page 91, line 14 skipping to change at line 4166
* A secret value * A secret value
* A purpose value indicating the specific value being generated * A purpose value indicating the specific value being generated
* The length of the key being generated * The length of the key being generated
The traffic keying material is generated from an input traffic secret The traffic keying material is generated from an input traffic secret
value using: value using:
[sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length) [sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)
[sender]_write_iv = HKDF-Expand-Label(Secret, "iv", "", iv_length) [sender]_write_iv = HKDF-Expand-Label(Secret, "iv", "", iv_length)
[sender] denotes the sending side. The value of Secret for each [sender] denotes the sending side. The value of Secret for each
category of data is shown in the table below. category of data is shown in the table below.
+====================+=======================================+ +====================+=======================================+
| Data Type | Secret | | Data Type | Secret |
+====================+=======================================+ +====================+=======================================+
| 0-RTT Application | client_early_traffic_secret | | 0-RTT Application | client_early_traffic_secret |
| and EndOfEarlyData | | | and EndOfEarlyData | |
+--------------------+---------------------------------------+ +--------------------+---------------------------------------+
| Initial Handshake | [sender]_handshake_traffic_secret | | Initial Handshake | [sender]_handshake_traffic_secret |
+--------------------+---------------------------------------+ +--------------------+---------------------------------------+
| Post-Handshake and | [sender]_application_traffic_secret_N | | Post-Handshake and | [sender]_application_traffic_secret_N |
| Application Data | | | Application Data | |
+--------------------+---------------------------------------+ +--------------------+---------------------------------------+
Table 3: Secrets for Traffic Keys Table 3: Secrets for Traffic Keys
Alerts are sent with the then current sending key (or as plaintext if Alerts are sent with the then-current sending key (or as plaintext if
no such key has been established.) All the traffic keying material no such key has been established.) All the traffic keying material
is recomputed whenever the underlying Secret changes (e.g., when is recomputed whenever the underlying Secret changes (e.g., when
changing from the handshake to Application Data keys or upon a key changing from the handshake to Application Data keys or upon a key
update). update).
7.4. (EC)DHE Shared Secret Calculation 7.4. (EC)DHE Shared Secret Calculation
7.4.1. Finite Field Diffie-Hellman 7.4.1. Finite Field Diffie-Hellman
For finite field groups, a conventional Diffie-Hellman [KEYAGREEMENT] For finite field groups, a conventional Diffie-Hellman [KEYAGREEMENT]
computation is performed. The negotiated key (Z) is converted to a computation is performed. The negotiated key (Z) is converted to a
byte string by encoding in big-endian form and left-padded with zeros byte string by encoding in big-endian form and left-padded with zeros
up to the size of the prime. This byte string is used as the shared up to the size of the prime. This byte string is used as the shared
secret in the key schedule as specified above. secret in the key schedule as specified above.
Note that this construction differs from previous versions of TLS Note that this construction differs from previous versions of TLS
which remove leading zeros. which remove leading zeros.
7.4.2. Elliptic Curve Diffie-Hellman 7.4.2. Elliptic Curve Diffie-Hellman
For secp256r1, secp384r1 and secp521r1, ECDH calculations (including For secp256r1, secp384r1, and secp521r1, ECDH calculations (including
key generation and shared secret calculation) are performed according 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 to Sections 5.6.1.2 and 5.7.1.2 of [KEYAGREEMENT] using the Elliptic
Curve Cryptography Cofactor Diffie-Hellman Primitive. The shared Curve Cryptography Cofactor Diffie-Hellman Primitive. The shared
secret Z is the x-coordinate of the ECDH shared secret elliptic curve 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 point represented as an octet string. Note that the octet string Z
as output by the Field-Element-to-Byte String Conversion specified in as output by the Field-Element-to-Byte String Conversion specified in
Appendix C.2 of [KEYAGREEMENT] has constant length for any given Appendix C.2 of [KEYAGREEMENT] has constant length for any given
field; leading zeros found in this octet string MUST NOT be field; leading zeros found in this octet string MUST NOT be
truncated. See Section 4.2.8.2 for requirements on public-key truncated. See Section 4.2.8.2 for requirements on public-key
validation. validation.
skipping to change at page 101, line 27 skipping to change at line 4626
10. Security Considerations 10. Security Considerations
Security issues are discussed throughout this memo, especially in Security issues are discussed throughout this memo, especially in
Appendix C, Appendix E, and Appendix F. Appendix C, Appendix E, and Appendix F.
11. IANA Considerations 11. IANA Considerations
This document uses several registries that were originally created in This document uses several registries that were originally created in
[RFC4346] and updated in [RFC8446] and [RFC8447]. The changes [RFC4346] and updated in [RFC8446] and [RFC8447]. The changes
between [RFC8446] and [RFC8447] this document are described in between [RFC8446], [RFC8447], and this document are described in
Section 11.1. IANA has updated these to reference this document. Section 11.1. IANA has replaced references to these RFCs with
references to this document. The registries and their allocation
The registries and their allocation policies are below: policies are below:
* TLS Cipher Suites registry: values with the first byte in the * TLS Cipher Suites registry: Values with the first byte in the
range 0-254 (decimal) are assigned via Specification Required range 0-254 (decimal) are assigned via Specification Required
[RFC8126]. Values with the first byte 255 (decimal) are reserved [RFC8126]. Values with the first byte 255 (decimal) are reserved
for Private Use [RFC8126]. for Private Use [RFC8126].
IANA has added the cipher suites listed in Appendix B.4 to the IANA has added the cipher suites listed in Appendix B.4 to the
registry. The "Value" and "Description" columns are taken from registry. The "Value" and "Description" columns are taken from
the table. The "DTLS-OK" and "Recommended" columns are both the table. The "DTLS-OK" and "Recommended" columns are both
marked as "Y" for each new cipher suite. marked as "Y" for each new cipher suite.
* TLS ContentType registry: Future values are allocated via * TLS ContentType registry: Future values are allocated via
Standards Action [RFC8126]. Standards Action [RFC8126].
* TLS Alerts registry: Future values are allocated via Standards * TLS Alerts registry: Future values are allocated via Standards
Action [RFC8126]. IANA [is requested to/has] populated this Action [RFC8126]. IANA has populated this registry with the
registry with the values from Appendix B.2. The "DTLS-OK" column values from Appendix B.2. The "DTLS-OK" column is marked as "Y"
is marked as "Y" for all such values. Values marked as for all such values. Values marked as "_RESERVED" have comments
"_RESERVED" have comments describing their previous usage. describing their previous usage.
* TLS HandshakeType registry: Future values are allocated via * TLS HandshakeType registry: Future values are allocated via
Standards Action [RFC8126]. IANA has updated this registry to Standards Action [RFC8126]. IANA has updated this registry to
rename item 4 from "NewSessionTicket" to "new_session_ticket" and rename item 4 from "NewSessionTicket" to "new_session_ticket" and
populated this registry with the values from Appendix B.3. The populated this registry with the values from Appendix B.3. The
"DTLS-OK" column is marked as "Y" for all such values. Values "DTLS-OK" column is marked as "Y" for all such values. Values
marked "_RESERVED" have comments describing their previous or marked "_RESERVED" have comments describing their previous or
temporary usage. temporary usage.
This document also uses the TLS ExtensionType Values registry This document also uses the TLS ExtensionType Values registry
skipping to change at page 103, line 7 skipping to change at line 4696
have the name "X509", "Recommended" value "Y", and comment "Was X.509 have the name "X509", "Recommended" value "Y", and comment "Was X.509
before TLS 1.3". before TLS 1.3".
This document updates an entry in the TLS Certificate Status Types This document updates an entry in the TLS Certificate Status Types
registry originally created in [RFC6961]. IANA has updated the entry registry originally created in [RFC6961]. IANA has updated the entry
for value 2 to have the name "ocsp_multi_RESERVED" and comment "Used for value 2 to have the name "ocsp_multi_RESERVED" and comment "Used
in TLS versions prior to 1.3". in TLS versions prior to 1.3".
This document updates two entries in the TLS Supported Groups This document updates two entries in the TLS Supported Groups
registry (created under a different name by [RFC4492]; now maintained 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 for values 29 and 30 (x25519 and x448) have been updated to also
refer to this document. refer to this document.
In addition, this document defines two new registries that are In addition, this document defines two new registries that are
maintained by IANA: maintained by IANA:
* TLS SignatureScheme registry: Values with the first byte in the * TLS SignatureScheme registry: Values with the first byte in the
range 0-253 (decimal) are assigned via Specification Required range 0-253 (decimal) are assigned via Specification Required
[RFC8126]. Values with the first byte 254 or 255 (decimal) are [RFC8126]. Values with the first byte 254 or 255 (decimal) are
reserved for Private Use [RFC8126]. Values with the first byte in reserved for Private Use [RFC8126]. Values with the first byte in
skipping to change at page 103, line 44 skipping to change at line 4733
[RFC8126]. This registry has a "Recommended" column. The [RFC8126]. This registry has a "Recommended" column. The
registry has been initially populated with psk_ke (0) and registry has been initially populated with psk_ke (0) and
psk_dhe_ke (1). Both are marked as "Recommended". The psk_dhe_ke (1). Both are marked as "Recommended". The
"Recommended" column is assigned a value of "N" unless explicitly "Recommended" column is assigned a value of "N" unless explicitly
requested, and adding a value with a "Recommended" value of "Y" requested, and adding a value with a "Recommended" value of "Y"
requires Standards Action [RFC8126]. IESG Approval is REQUIRED requires Standards Action [RFC8126]. IESG Approval is REQUIRED
for a Y->N transition. for a Y->N transition.
11.1. Changes for this RFC 11.1. Changes for this RFC
IANA [shall update/has updated] all references to RFC 8446 in the IANA has updated all references to [RFC8446] in the IANA registries
IANA registries with references to this document. with references to this document.
IANA [shall rename/has renamed] the "extended_master_secret" value in IANA has renamed the "extended_master_secret" value in the TLS
the TLS ExtensionType Values registry to "extended_main_secret". ExtensionType Values registry to "extended_main_secret".
IANA [shall create/has created] a value for the "general_error" alert IANA has created a value for the "general_error" alert in the TLS
in the TLS Alerts Registry with the value given in Section 6. Alerts registry with the value given in Section 6.
12. References 12. References
12.1. Normative References 12.1. Normative References
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", Operation: Galois/Counter Mode (GCM) and GMAC", NIST SP
NIST Special Publication 800-38D, November 2007, 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007,
<https://doi.org/10.6028/NIST.SP.800-38D>. <https://doi.org/10.6028/NIST.SP.800-38D>.
[KEYAGREEMENT] [KEYAGREEMENT]
Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
Davis, "Recommendation for pair-wise key-establishment Davis, "Recommendation for pair-wise key-establishment
schemes using discrete logarithm cryptography", National schemes using discrete logarithm cryptography", National
Institute of Standards and Technology, Institute of Standards and Technology,
DOI 10.6028/nist.sp.800-56ar3, April 2018, DOI 10.6028/nist.sp.800-56ar3, April 2018,
<https://doi.org/10.6028/nist.sp.800-56ar3>. <https://doi.org/10.6028/nist.sp.800-56ar3>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/rfc/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/rfc/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/rfc/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, [RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Updates for RSAES-OAEP and RSASSA-PSS Algorithm "Updates for RSAES-OAEP and RSASSA-PSS Algorithm
Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010, Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010,
<https://www.rfc-editor.org/rfc/rfc5756>. <https://www.rfc-editor.org/info/rfc5756>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/rfc/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", RFC 6655, Transport Layer Security (TLS)", RFC 6655,
DOI 10.17487/RFC6655, July 2012, DOI 10.17487/RFC6655, July 2012,
<https://www.rfc-editor.org/rfc/rfc6655>. <https://www.rfc-editor.org/info/rfc6655>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/rfc/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961, Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, DOI 10.17487/RFC6961, June 2013,
<https://www.rfc-editor.org/rfc/rfc6961>. <https://www.rfc-editor.org/info/rfc6961>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/rfc/rfc6962>. <https://www.rfc-editor.org/info/rfc6962>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/rfc/rfc6979>. 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/rfc/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade Suite Value (SCSV) for Preventing Protocol Downgrade
Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
<https://www.rfc-editor.org/rfc/rfc7507>. <https://www.rfc-editor.org/info/rfc7507>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS) Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension", Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015, RFC 7627, DOI 10.17487/RFC7627, September 2015,
<https://www.rfc-editor.org/rfc/rfc7627>. <https://www.rfc-editor.org/info/rfc7627>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/rfc/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman
Ephemeral Parameters for Transport Layer Security (TLS)", Ephemeral Parameters for Transport Layer Security (TLS)",
RFC 7919, DOI 10.17487/RFC7919, August 2016, RFC 7919, DOI 10.17487/RFC7919, August 2016,
<https://www.rfc-editor.org/rfc/rfc7919>. <https://www.rfc-editor.org/info/rfc7919>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/rfc/rfc8017>. <https://www.rfc-editor.org/info/rfc8017>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/rfc/rfc8439>. <https://www.rfc-editor.org/info/rfc8439>.
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/rfc/rfc8996>. <https://www.rfc-editor.org/info/rfc8996>.
[SHS] "Secure hash standard", National Institute of Standards [SHS] "Secure hash standard", National Institute of Standards
and Technology (U.S.), DOI 10.6028/nist.fips.180-4, 2015, and Technology (U.S.), DOI 10.6028/nist.fips.180-4, 2015,
<https://doi.org/10.6028/nist.fips.180-4>. <https://doi.org/10.6028/nist.fips.180-4>.
[X690] ITU-T, "Information technology - ASN.1 encoding Rules: [X690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T X.690 , February 2021, (DER)", ITU-T Recommendation X.690, February 2021,
<https://www.itu.int/rec/T-REC-X.690-202102-I/en>. <https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
12.2. Informative References 12.2. Informative References
[AEAD-LIMITS] [AEAD-LIMITS]
Luykx, A. and K. Paterson, "Limits on Authenticated Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", August 2017, Encryption Use in TLS", August 2017,
<https://eprint.iacr.org/2024/051.pdf>. <https://eprint.iacr.org/2024/051>.
[BBFGKZ16] Bhargavan, K., Brzuska, C., Fournet, C., Green, M., [BBFGKZ16] Bhargavan, K., Brzuska, C., Fournet, C., Green, M.,
Kohlweiss, M., and S. Zanella-Beguelin, "Downgrade Kohlweiss, M., and S. Zanella-Beguelin, "Downgrade
Resilience in Key-Exchange Protocols", IEEE, 2016 IEEE Resilience in Key-Exchange Protocols", IEEE, 2016 IEEE
Symposium on Security and Privacy (SP), Symposium on Security and Privacy (SP),
DOI 10.1109/sp.2016.37, May 2016, DOI 10.1109/sp.2016.37, May 2016,
<https://doi.org/10.1109/sp.2016.37>. <https://doi.org/10.1109/sp.2016.37>.
[BBK17] Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified [BBK17] Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified
Models and Reference Implementations for the TLS 1.3 Models and Reference Implementations for the TLS 1.3
Standard Candidate", IEEE, 2017 IEEE Symposium on Security Standard Candidate", IEEE, 2017 IEEE Symposium on Security
and Privacy (SP) pp. 483-502, DOI 10.1109/sp.2017.26, May and Privacy (SP) pp. 483-502, DOI 10.1109/sp.2017.26, May
2017, <https://doi.org/10.1109/sp.2017.26>. 2017, <https://doi.org/10.1109/sp.2017.26>.
[BDFKPPRSZZ16] [BDFKPPRSZZ16]
Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Bhargavan, K., Delignat-Lavaud, A., Fournet, C.,
Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy, Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy,
N., Zanella-Beguelin, S., and J. Zinzindohoue, N., Zanella-Beguelin, S., and J. Zinzindohoue,
"Implementing and Proving the TLS 1.3 Record Layer", "Implementing and Proving the TLS 1.3 Record Layer",
Proceedings of IEEE Symposium on Security and Privacy (San Proceedings of IEEE Symposium on Security and Privacy (San
Jose) 2017 , December 2016, Jose) 2017, December 2016,
<https://eprint.iacr.org/2016/1178>. <https://eprint.iacr.org/2016/1178>.
[Ben17a] Benjamin, D., "Presentation before the TLS WG at IETF [Ben17a] Benjamin, D., "Presentation before the TLS WG at IETF
100", 2017, 100", IETF 100 Proceedings, November 2017,
<https://datatracker.ietf.org/meeting/100/materials/ <https://datatracker.ietf.org/meeting/100/materials/
slides-100-tls-sessa-tls13/>. slides-100-tls-sessa-tls13/>.
[Ben17b] Benjamin, D., "Additional TLS 1.3 results from Chrome", [Ben17b] Benjamin, D., "Additional TLS 1.3 results from Chrome",
2017, <https://www.ietf.org/mail-archive/web/tls/current/ message to the TLS mailing list, 18 December 2017,
msg25168.html>. <https://mailarchive.ietf.org/arch/msg/tls/
i9blmvG2BEPf1s1OJkenHknRw9c/>.
[Blei98] Bleichenbacher, D., "Chosen Ciphertext Attacks against [Blei98] Bleichenbacher, D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS #1", Protocols Based on RSA Encryption Standard PKCS #1",
Proceedings of CRYPTO '98 , 1998. Proceedings of CRYPTO '98, 1998,
<https://link.springer.com/chapter/10.1007/bfb0055716>.
[BMMRT15] Badertscher, C., Matt, C., Maurer, U., Rogaway, P., and B. [BMMRT15] Badertscher, C., Matt, C., Maurer, U., Rogaway, P., and B.
Tackmann, "Augmented Secure Channels and the Goal of the Tackmann, "Augmented Secure Channels and the Goal of the
TLS 1.3 Record Layer", ProvSec 2015 , September 2015, TLS 1.3 Record Layer", ProvSec 2015, September 2015,
<https://eprint.iacr.org/2015/394>. <https://eprint.iacr.org/2015/394>.
[BT16] Bellare, M. and B. Tackmann, "The Multi-User Security of [BT16] Bellare, M. and B. Tackmann, "The Multi-User Security of
Authenticated Encryption: AES-GCM in TLS 1.3", Proceedings Authenticated Encryption: AES-GCM in TLS 1.3", Proceedings
of CRYPTO 2016 , July 2016, of CRYPTO 2016, July 2016,
<https://eprint.iacr.org/2016/564>. <https://eprint.iacr.org/2016/564>.
[CCG16] Cohn-Gordon, K., Cremers, C., and L. Garratt, "On Post- [CCG16] Cohn-Gordon, K., Cremers, C., and L. Garratt, "On Post-
compromise Security", IEEE, 2016 IEEE 29th Computer compromise Security", IEEE, 2016 IEEE 29th Computer
Security Foundations Symposium (CSF) pp. 164-178, Security Foundations Symposium (CSF) pp. 164-178,
DOI 10.1109/csf.2016.19, June 2016, DOI 10.1109/csf.2016.19, June 2016,
<https://doi.org/10.1109/csf.2016.19>. <https://doi.org/10.1109/csf.2016.19>.
[CHECKOWAY] [CHECKOWAY]
Checkoway, S., Maskiewicz, J., Garman, C., Fried, J., Checkoway, S., Maskiewicz, J., Garman, C., Fried, J.,
skipping to change at page 108, line 34 skipping to change at line 4958
Rescorla, E., and H. Shacham, "A Systematic Analysis of Rescorla, E., and H. Shacham, "A Systematic Analysis of
the Juniper Dual EC Incident", ACM, Proceedings of the the Juniper Dual EC Incident", ACM, Proceedings of the
2016 ACM SIGSAC Conference on Computer and Communications 2016 ACM SIGSAC Conference on Computer and Communications
Security pp. 468-479, DOI 10.1145/2976749.2978395, October Security pp. 468-479, DOI 10.1145/2976749.2978395, October
2016, <https://doi.org/10.1145/2976749.2978395>. 2016, <https://doi.org/10.1145/2976749.2978395>.
[CHHSV17] Cremers, C., Horvat, M., Hoyland, J., van der Merwe, T., [CHHSV17] Cremers, C., Horvat, M., Hoyland, J., van der Merwe, T.,
and S. Scott, "Awkward Handshake: Possible mismatch of and S. Scott, "Awkward Handshake: Possible mismatch of
client/server view on client authentication in post- client/server view on client authentication in post-
handshake mode in Revision 18", message to the TLS mailing handshake mode in Revision 18", message to the TLS mailing
list , February 2017, <https://www.ietf.org/mail- list, 10 February 2017,
archive/web/tls/current/msg22382.html>. <https://mailarchive.ietf.org/arch/msg/tls/crdSCgiW-
94z2joulYJtuA52E9E/>.
[CHSV16] Cremers, C., Horvat, M., Scott, S., and T. van der Merwe, [CHSV16] Cremers, C., Horvat, M., Scott, S., and T. van der Merwe,
"Automated Analysis and Verification of TLS 1.3: 0-RTT, "Automated Analysis and Verification of TLS 1.3: 0-RTT,
Resumption and Delayed Authentication", IEEE, 2016 IEEE Resumption and Delayed Authentication", IEEE, 2016 IEEE
Symposium on Security and Privacy (SP) pp. 470-485, Symposium on Security and Privacy (SP) pp. 470-485,
DOI 10.1109/sp.2016.35, May 2016, DOI 10.1109/sp.2016.35, May 2016,
<https://doi.org/10.1109/sp.2016.35>. <https://doi.org/10.1109/sp.2016.35>.
[CK01] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange [CK01] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange
Protocols and Their Use for Building Secure Channels", Protocols and Their Use for Building Secure Channels",
skipping to change at page 109, line 16 skipping to change at line 4987
Why You Went to the Clinic: Risks and Realization of HTTPS Why You Went to the Clinic: Risks and Realization of HTTPS
Traffic Analysis", Springer International Publishing, Traffic Analysis", Springer International Publishing,
Lecture Notes in Computer Science pp. 143-163, Lecture Notes in Computer Science pp. 143-163,
DOI 10.1007/978-3-319-08506-7_8, ISBN ["9783319085050", DOI 10.1007/978-3-319-08506-7_8, ISBN ["9783319085050",
"9783319085067"], 2014, "9783319085067"], 2014,
<https://doi.org/10.1007/978-3-319-08506-7_8>. <https://doi.org/10.1007/978-3-319-08506-7_8>.
[DFGS15] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, [DFGS15] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila,
"A Cryptographic Analysis of the TLS 1.3 draft-10 Full and "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and
Pre-shared Key Handshake Protocol", Proceedings of ACM CCS Pre-shared Key Handshake Protocol", Proceedings of ACM CCS
2015 , October 2016, <https://eprint.iacr.org/2015/914>. 2015, October 2015, <https://eprint.iacr.org/2015/914>.
[DFGS16] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, [DFGS16] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila,
"A Cryptographic Analysis of the TLS 1.3 draft-10 Full and "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and
Pre-shared Key Handshake Protocol", TRON 2016 , February Pre-shared Key Handshake Protocol", TRON 2016, February
2016, <https://eprint.iacr.org/2016/081>. 2016, <https://eprint.iacr.org/2016/081>.
[DH76] Diffie, W. and M. Hellman, "New directions in [DH76] Diffie, W. and M. Hellman, "New directions in
cryptography", Institute of Electrical and Electronics cryptography", Institute of Electrical and Electronics
Engineers (IEEE), IEEE Transactions on Information Engineers (IEEE), IEEE Transactions on Information
Theory vol. 22, no. 6, pp. 644-654, Theory vol. 22, no. 6, pp. 644-654,
DOI 10.1109/tit.1976.1055638, November 1976, DOI 10.1109/tit.1976.1055638, November 1976,
<https://doi.org/10.1109/tit.1976.1055638>. <https://doi.org/10.1109/tit.1976.1055638>.
[DOW92] Diffie, W., Van Oorschot, P., and M. Wiener, [DOW92] Diffie, W., Van Oorschot, P., and M. Wiener,
"Authentication and authenticated key exchanges", Springer "Authentication and authenticated key exchanges", Springer
Science and Business Media LLC, Designs, Codes and Science and Business Media LLC, Designs, Codes and
Cryptography vol. 2, no. 2, pp. 107-125, Cryptography vol. 2, no. 2, pp. 107-125,
DOI 10.1007/bf00124891, June 1992, DOI 10.1007/bf00124891, June 1992,
<https://doi.org/10.1007/bf00124891>. <https://doi.org/10.1007/bf00124891>.
[DSA-1571-1] [DSA-1571-1]
The Debian Project, "openssl -- predictable random number Weimer, F., "[SECURITY] [DSA 1571-1] New openssl packages
generator", May 2008, fix predictable random number generator", message to the
debian-security-announce mailing list, May 2008,
<https://www.debian.org/security/2008/dsa-1571>. <https://www.debian.org/security/2008/dsa-1571>.
[DSS] "Digital Signature Standard (DSS)", National Institute of [DSS] "Digital Signature Standard (DSS)", National Institute of
Standards and Technology (U.S.), Standards and Technology (U.S.),
DOI 10.6028/nist.fips.186-5, February 2023, DOI 10.6028/nist.fips.186-5, February 2023,
<https://doi.org/10.6028/nist.fips.186-5>. <https://doi.org/10.6028/nist.fips.186-5>.
[ECDP] Chen, L., Moody, D., Regenscheid, A., Robinson, A., and K. [ECDP] Chen, L., Moody, D., Regenscheid, A., Robinson, A., and K.
Randall, "Recommendations for Discrete Logarithm-based Randall, "Recommendations for Discrete Logarithm-based
Cryptography:: Elliptic Curve Domain Parameters", National Cryptography:: Elliptic Curve Domain Parameters", National
Institute of Standards and Technology, Institute of Standards and Technology,
DOI 10.6028/nist.sp.800-186, February 2023, DOI 10.6028/nist.sp.800-186, February 2023,
<https://doi.org/10.6028/nist.sp.800-186>. <https://doi.org/10.6028/nist.sp.800-186>.
[FETCH] WHATWG, "Fetch Standard", September 2025, [FETCH] WHATWG, "Fetch", WHATWG Living Standard,
<https://fetch.spec.whatwg.org/>. <https://fetch.spec.whatwg.org/>. Commit snapshot:
https://fetch.spec.whatwg.org/commit-
snapshots/4775fcb48042c8411df497c0b7cf167b4240004f/
[FG17] Fischlin, M. and F. Guenther, "Replay Attacks on Zero [FG17] Fischlin, M. and F. Guenther, "Replay Attacks on Zero
Round-Trip Time: The Case of the TLS 1.3 Handshake Round-Trip Time: The Case of the TLS 1.3 Handshake
Candidates", Proceedings of Euro S&P 2017 , 2017, Candidates", Proceedings of Euro S&P 2017, April 2017,
<https://eprint.iacr.org/2017/082>. <https://eprint.iacr.org/2017/082>.
[FGSW16] Fischlin, M., Guenther, F., Schmidt, B., and B. Warinschi, [FGSW16] Fischlin, M., Guenther, F., Schmidt, B., and B. Warinschi,
"Key Confirmation in Key Exchange: A Formal Treatment and "Key Confirmation in Key Exchange: A Formal Treatment and
Implications for TLS 1.3", Proceedings of IEEE Symposium Implications for TLS 1.3", Proceedings of IEEE Symposium
on Security and Privacy (Oakland) 2016 , 2016, on Security and Privacy (Oakland) 2016,
DOI 10.1109/SP.2016.34, 2016,
<http://ieeexplore.ieee.org/document/7546517/>. <http://ieeexplore.ieee.org/document/7546517/>.
[FW15] Weimer, F., "Factoring RSA Keys With TLS Perfect Forward [FW15] Weimer, F., "Factoring RSA Keys With TLS Perfect Forward
Secrecy", September 2015. Secrecy", Red Hat Blog, 2 September 2015,
<https://www.redhat.com/en/blog/factoring-rsa-keys-tls-
perfect-forward-secrecy>.
[HCJC16] Husák, M., Čermák, M., Jirsík, T., and P. Čeleda, "HTTPS [HCJC16] Husák, M., Čermák, M., Jirsík, T., and P. Čeleda, "HTTPS
traffic analysis and client identification using passive traffic analysis and client identification using passive
SSL/TLS fingerprinting", Springer Science and Business SSL/TLS fingerprinting", Springer Science and Business
Media LLC, EURASIP Journal on Information Security vol. Media LLC, EURASIP Journal on Information Security vol.
2016, no. 1, DOI 10.1186/s13635-016-0030-7, February 2016, 2016, no. 1, DOI 10.1186/s13635-016-0030-7, February 2016,
<https://doi.org/10.1186/s13635-016-0030-7>. <https://doi.org/10.1186/s13635-016-0030-7>.
[HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes, [HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes,
"Prying Open Pandora's Box: KCI Attacks against TLS", "Prying Open Pandora's Box: KCI Attacks against TLS",
Proceedings of USENIX Workshop on Offensive Technologies , Proceedings of USENIX Workshop on Offensive Technologies,
2015. 2015, <https://www.usenix.org/conference/woot15/workshop-
program/presentation/hlauschek>.
[I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-25, 14 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-25>.
[JSS15] Jager, T., Schwenk, J., and J. Somorovsky, "On the [JSS15] Jager, T., Schwenk, J., and J. Somorovsky, "On the
Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1
v1.5 Encryption", ACM, Proceedings of the 22nd ACM SIGSAC v1.5 Encryption", ACM, Proceedings of the 22nd ACM SIGSAC
Conference on Computer and Communications Security pp. Conference on Computer and Communications Security pp.
1185-1196, DOI 10.1145/2810103.2813657, October 2015, 1185-1196, DOI 10.1145/2810103.2813657, October 2015,
<https://doi.org/10.1145/2810103.2813657>. <https://doi.org/10.1145/2810103.2813657>.
[Kraw10] Krawczyk, H., "Cryptographic Extraction and Key [Kraw10] Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 , Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010,
2010, <https://eprint.iacr.org/2010/264>. 2010, <https://eprint.iacr.org/2010/264>.
[Kraw16] Krawczyk, H., "A Unilateral-to-Mutual Authentication [Kraw16] Krawczyk, H., "A Unilateral-to-Mutual Authentication
Compiler for Key Exchange (with Applications to Client Compiler for Key Exchange (with Applications to Client
Authentication in TLS 1.3", Proceedings of ACM CCS 2016 , Authentication in TLS 1.3", Proceedings of ACM CCS 2016,
October 2016, <https://eprint.iacr.org/2016/711>. October 2016, <https://eprint.iacr.org/2016/711>.
[KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", [KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3",
Proceedings of Euro S&P 2016 , 2016, Proceedings of Euro S&P 2016, March 2016,
<https://eprint.iacr.org/2015/978>. <https://eprint.iacr.org/2015/978>.
[LXZFH16] Li, X., Xu, J., Zhang, Z., Feng, D., and H. Hu, "Multiple [LXZFH16] Li, X., Xu, J., Zhang, Z., Feng, D., and H. Hu, "Multiple
Handshakes Security of TLS 1.3 Candidates", IEEE, 2016 Handshakes Security of TLS 1.3 Candidates", IEEE, 2016
IEEE Symposium on Security and Privacy (SP) pp. 486-505, IEEE Symposium on Security and Privacy (SP) pp. 486-505,
DOI 10.1109/sp.2016.36, May 2016, DOI 10.1109/sp.2016.36, May 2016,
<https://doi.org/10.1109/sp.2016.36>. <https://doi.org/10.1109/sp.2016.36>.
[Mac17] MacCarthaigh, C., "Security Review of TLS1.3 0-RTT", March [Mac17] MacCarthaigh, C., "Security Review of TLS1.3 0-RTT", May
2017, <https://github.com/tlswg/tls13-spec/issues/1001>. 2017, <https://github.com/tlswg/tls13-spec/issues/1001>.
[MM24] Moustafa, M., Sethi, M., and T. Aura, "Misbinding Raw [MM24] Moustafa, M., Sethi, M., and T. Aura, "Misbinding Raw
Public Keys to Identities in TLS", 2024, Public Keys to Identities in TLS", arxiv:2411.09770, 29
<https://arxiv.org/pdf/2411.09770>. September 2025, <https://arxiv.org/pdf/2411.09770>.
[PRE-RFC9849]
Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", RFC PRE-RFC9849,
DOI 10.17487/preRFC9849, December 2025,
<https://www.rfc-editor.org/info/rfc9849>.
[PS18] Patton, C. and T. Shrimpton, "Partially specified [PS18] Patton, C. and T. Shrimpton, "Partially specified
channels: The TLS 1.3 record layer without elision", 2018, channels: The TLS 1.3 record layer without elision", 2018,
<https://eprint.iacr.org/2018/634>. <https://eprint.iacr.org/2018/634>.
[PSK-FINISHED] [PSK-FINISHED]
Cremers, C., Horvat, M., van der Merwe, T., and S. Scott, Cremers, C., Horvat, M., van der Merwe, T., and S. Scott,
"Revision 10: possible attack if client authentication is "Revision 10: possible attack if client authentication is
allowed during PSK", message to the TLS mailing list, , allowed during PSK", message to the TLS mailing list, 31
2015, <https://www.ietf.org/mail-archive/web/tls/current/ October 2015, <https://mailarchive.ietf.org/arch/msg/tls/
msg18215.html>. TugB5ddJu3nYg7chcyeIyUqWSbA/>.
[REKEY] Abdalla, M. and M. Bellare, "Increasing the Lifetime of a [REKEY] Abdalla, M. and M. Bellare, "Increasing the Lifetime of a
Key: A Comparative Analysis of the Security of Re-keying Key: A Comparative Analysis of the Security of Re-keying
Techniques", Springer Berlin Heidelberg, Lecture Notes in Techniques", Springer Berlin Heidelberg, Lecture Notes in
Computer Science pp. 546-559, Computer Science pp. 546-559,
DOI 10.1007/3-540-44448-3_42, ISBN ["9783540414049", DOI 10.1007/3-540-44448-3_42, ISBN ["9783540414049",
"9783540444480"], 2000, "9783540444480"], 2000,
<https://doi.org/10.1007/3-540-44448-3_42>. <https://doi.org/10.1007/3-540-44448-3_42>.
[Res17a] Rescorla, E., "Preliminary data on Firefox TLS 1.3 [Res17a] Rescorla, E., "Preliminary data on Firefox TLS 1.3
Middlebox experiment", message to the TLS mailing list , Middlebox experiment", message to the TLS mailing list, 5
2017, <https://www.ietf.org/mail-archive/web/tls/current/ December 2017, <https://mailarchive.ietf.org/arch/msg/tls/
msg25091.html>. RBp0X-OWNuWXugFJRV7c_hIU0dI/>.
[Res17b] Rescorla, E., "More compatibility measurement results", [Res17b] Rescorla, E., "More compatibility measurement results",
message to the TLS mailing list , December 2017, message to the TLS mailing list, 22 December 2017,
<https://www.ietf.org/mail-archive/web/tls/current/ <https://mailarchive.ietf.org/arch/msg/tls/6pGGT-
msg25179.html>. wm5vSkacMFPEPvFMEnj-M/>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246, January 1999, RFC 2246, DOI 10.17487/RFC2246, January 1999,
<https://www.rfc-editor.org/rfc/rfc2246>. <https://www.rfc-editor.org/info/rfc2246>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/rfc/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, (TLS) Protocol Version 1.1", RFC 4346,
DOI 10.17487/RFC4346, April 2006, DOI 10.17487/RFC4346, April 2006,
<https://www.rfc-editor.org/rfc/rfc4346>. <https://www.rfc-editor.org/info/rfc4346>.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
<https://www.rfc-editor.org/rfc/rfc4366>. <https://www.rfc-editor.org/info/rfc4366>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, for Transport Layer Security (TLS)", RFC 4492,
DOI 10.17487/RFC4492, May 2006, DOI 10.17487/RFC4492, May 2006,
<https://www.rfc-editor.org/rfc/rfc4492>. <https://www.rfc-editor.org/info/rfc4492>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/rfc/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/rfc/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/rfc/rfc5763>. 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010,
<https://www.rfc-editor.org/rfc/rfc5764>. <https://www.rfc-editor.org/info/rfc5764>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<https://www.rfc-editor.org/rfc/rfc5929>. <https://www.rfc-editor.org/info/rfc5929>.
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
for Transport Layer Security (TLS) Authentication", for Transport Layer Security (TLS) Authentication",
RFC 6091, DOI 10.17487/RFC6091, February 2011, RFC 6091, DOI 10.17487/RFC6091, February 2011,
<https://www.rfc-editor.org/rfc/rfc6091>. <https://www.rfc-editor.org/info/rfc6091>.
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
DOI 10.17487/RFC6101, August 2011, DOI 10.17487/RFC6101, August 2011,
<https://www.rfc-editor.org/rfc/rfc6101>. <https://www.rfc-editor.org/info/rfc6101>.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
(SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March
2011, <https://www.rfc-editor.org/rfc/rfc6176>. 2011, <https://www.rfc-editor.org/info/rfc6176>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/rfc/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport
Layer Security (TLS) and Datagram Transport Layer Security Layer Security (TLS) and Datagram Transport Layer Security
(DTLS) Heartbeat Extension", RFC 6520, (DTLS) Heartbeat Extension", RFC 6520,
DOI 10.17487/RFC6520, February 2012, DOI 10.17487/RFC6520, February 2012,
<https://www.rfc-editor.org/rfc/rfc6520>. <https://www.rfc-editor.org/info/rfc6520>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/rfc/rfc7250>. June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
DOI 10.17487/RFC7465, February 2015, DOI 10.17487/RFC7465, February 2015,
<https://www.rfc-editor.org/rfc/rfc7465>. <https://www.rfc-editor.org/info/rfc7465>.
[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", RFC 7568, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
DOI 10.17487/RFC7568, June 2015, DOI 10.17487/RFC7568, June 2015,
<https://www.rfc-editor.org/rfc/rfc7568>. <https://www.rfc-editor.org/info/rfc7568>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann, Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A "Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624, Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015, DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/rfc/rfc7624>. <https://www.rfc-editor.org/info/rfc7624>.
[RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello
Padding Extension", RFC 7685, DOI 10.17487/RFC7685, Padding Extension", RFC 7685, DOI 10.17487/RFC7685,
October 2015, <https://www.rfc-editor.org/rfc/rfc7685>. October 2015, <https://www.rfc-editor.org/info/rfc7685>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924, (TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016, DOI 10.17487/RFC7924, July 2016,
<https://www.rfc-editor.org/rfc/rfc7924>. <https://www.rfc-editor.org/info/rfc7924>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/rfc/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422, Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018, DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/rfc/rfc8422>. <https://www.rfc-editor.org/info/rfc8422>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/rfc/rfc8447>. <https://www.rfc-editor.org/info/rfc8447>.
[RFC8448] Thomson, M., "Example Handshake Traces for TLS 1.3", [RFC8448] Thomson, M., "Example Handshake Traces for TLS 1.3",
RFC 8448, DOI 10.17487/RFC8448, January 2019, RFC 8448, DOI 10.17487/RFC8448, January 2019,
<https://www.rfc-editor.org/rfc/rfc8448>. <https://www.rfc-editor.org/info/rfc8448>.
[RFC8449] Thomson, M., "Record Size Limit Extension for TLS", [RFC8449] Thomson, M., "Record Size Limit Extension for TLS",
RFC 8449, DOI 10.17487/RFC8449, August 2018, RFC 8449, DOI 10.17487/RFC8449, August 2018,
<https://www.rfc-editor.org/rfc/rfc8449>. <https://www.rfc-editor.org/info/rfc8449>.
[RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based [RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based
Authentication with an External Pre-Shared Key", RFC 8773, Authentication with an External Pre-Shared Key", RFC 8773,
DOI 10.17487/RFC8773, March 2020, DOI 10.17487/RFC8773, March 2020,
<https://www.rfc-editor.org/rfc/rfc8773>. <https://www.rfc-editor.org/info/rfc8773>.
[RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on [RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on
Uses of TLS with the Session Description Protocol (SDP)", Uses of TLS with the Session Description Protocol (SDP)",
RFC 8844, DOI 10.17487/RFC8844, January 2021, RFC 8844, DOI 10.17487/RFC8844, January 2021,
<https://www.rfc-editor.org/rfc/rfc8844>. <https://www.rfc-editor.org/info/rfc8844>.
[RFC8849] Even, R. and J. Lennox, "Mapping RTP Streams to
Controlling Multiple Streams for Telepresence (CLUE) Media
Captures", RFC 8849, DOI 10.17487/RFC8849, January 2021,
<https://www.rfc-editor.org/rfc/rfc8849>.
[RFC8870] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. [RFC8870] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F.
Andreasen, "Encrypted Key Transport for DTLS and Secure Andreasen, "Encrypted Key Transport for DTLS and Secure
RTP", RFC 8870, DOI 10.17487/RFC8870, January 2021, RTP", RFC 8870, DOI 10.17487/RFC8870, January 2021,
<https://www.rfc-editor.org/rfc/rfc8870>. <https://www.rfc-editor.org/info/rfc8870>.
[RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate [RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate
Compression", RFC 8879, DOI 10.17487/RFC8879, December Compression", RFC 8879, DOI 10.17487/RFC8879, December
2020, <https://www.rfc-editor.org/rfc/rfc8879>. 2020, <https://www.rfc-editor.org/info/rfc8879>.
[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
and C. Wood, "Randomness Improvements for Security and C. Wood, "Randomness Improvements for Security
Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
<https://www.rfc-editor.org/rfc/rfc8937>. <https://www.rfc-editor.org/info/rfc8937>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/rfc/rfc9001>. <https://www.rfc-editor.org/info/rfc9001>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/rfc/rfc9112>. June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC9146] Rescorla, E., Ed., Tschofenig, H., Ed., Fossati, T., and [RFC9146] Rescorla, E., Ed., Tschofenig, H., Ed., Fossati, T., and
A. Kraus, "Connection Identifier for DTLS 1.2", RFC 9146, A. Kraus, "Connection Identifier for DTLS 1.2", RFC 9146,
DOI 10.17487/RFC9146, March 2022, DOI 10.17487/RFC9146, March 2022,
<https://www.rfc-editor.org/rfc/rfc9146>. <https://www.rfc-editor.org/info/rfc9146>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/rfc/rfc9147>. <https://www.rfc-editor.org/info/rfc9147>.
[RFC9149] Pauly, T., Schinazi, D., and C.A. Wood, "TLS Ticket [RFC9149] Pauly, T., Schinazi, D., and C.A. Wood, "TLS Ticket
Requests", RFC 9149, DOI 10.17487/RFC9149, April 2022, Requests", RFC 9149, DOI 10.17487/RFC9149, April 2022,
<https://www.rfc-editor.org/rfc/rfc9149>. <https://www.rfc-editor.org/info/rfc9149>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/rfc/rfc9162>. December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood, [RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood,
"Guidance for External Pre-Shared Key (PSK) Usage in TLS", "Guidance for External Pre-Shared Key (PSK) Usage in TLS",
RFC 9257, DOI 10.17487/RFC9257, July 2022, RFC 9257, DOI 10.17487/RFC9257, July 2022,
<https://www.rfc-editor.org/rfc/rfc9257>. <https://www.rfc-editor.org/info/rfc9257>.
[RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre- [RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre-
Shared Keys (PSKs) for TLS 1.3", RFC 9258, Shared Keys (PSKs) for TLS 1.3", RFC 9258,
DOI 10.17487/RFC9258, July 2022, DOI 10.17487/RFC9258, July 2022,
<https://www.rfc-editor.org/rfc/rfc9258>. <https://www.rfc-editor.org/info/rfc9258>.
[RFC9345] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, [RFC9345] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS and DTLS", RFC 9345, "Delegated Credentials for TLS and DTLS", RFC 9345,
DOI 10.17487/RFC9345, July 2023, DOI 10.17487/RFC9345, July 2023,
<https://www.rfc-editor.org/rfc/rfc9345>. <https://www.rfc-editor.org/info/rfc9345>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023, RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/rfc/rfc9525>. <https://www.rfc-editor.org/info/rfc9525>.
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A method for [RSA] Rivest, R., Shamir, A., and L. Adleman, "A method for
obtaining digital signatures and public-key obtaining digital signatures and public-key
cryptosystems", Association for Computing Machinery (ACM), cryptosystems", Association for Computing Machinery (ACM),
Communications of the ACM vol. 21, no. 2, pp. 120-126, Communications of the ACM vol. 21, no. 2, pp. 120-126,
DOI 10.1145/359340.359342, February 1978, DOI 10.1145/359340.359342, February 1978,
<https://doi.org/10.1145/359340.359342>. <https://doi.org/10.1145/359340.359342>.
[Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3 [Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3
with PSK", 2019, <https://eprint.iacr.org/2019/347.pdf>. with PSK", 2019, <https://eprint.iacr.org/2019/347>.
[SIGMA] Krawczyk, H., "SIGMA: The ‘SIGn-and-MAc’ Approach to [SIGMA] Krawczyk, H., "SIGMA: The ‘SIGn-and-MAc’ Approach to
Authenticated Diffie-Hellman and Its Use in the IKE Authenticated Diffie-Hellman and Its Use in the IKE
Protocols", Springer Berlin Heidelberg, Lecture Notes in Protocols", Springer Berlin Heidelberg, Lecture Notes in
Computer Science pp. 400-425, Computer Science pp. 400-425,
DOI 10.1007/978-3-540-45146-4_24, ISBN ["9783540406747", DOI 10.1007/978-3-540-45146-4_24, ISBN ["9783540406747",
"9783540451464"], 2003, "9783540451464"], 2003,
<https://doi.org/10.1007/978-3-540-45146-4_24>. <https://doi.org/10.1007/978-3-540-45146-4_24>.
[SLOTH] Bhargavan, K. and G. Leurent, "Transcript Collision [SLOTH] Bhargavan, K. and G. Leurent, "Transcript Collision
Attacks: Breaking Authentication in TLS, IKE, and SSH", Attacks: Breaking Authentication in TLS, IKE, and SSH",
Internet Society, Proceedings 2016 Network and Distributed Internet Society, Proceedings 2016 Network and Distributed
System Security Symposium, DOI 10.14722/ndss.2016.23418, System Security Symposium, DOI 10.14722/ndss.2016.23418,
2016, <https://doi.org/10.14722/ndss.2016.23418>. 2016, <https://doi.org/10.14722/ndss.2016.23418>.
[SSL2] Hickman, K., "The SSL Protocol", 9 February 1995. [SSL2] Hickman, K., "The SSL Protocol", 9 February 1995.
[TIMING] Boneh, D. and D. Brumley, "Remote Timing Attacks Are [TIMING] Boneh, D. and D. Brumley, "Remote Timing Attacks Are
Practical", USENIX Security Symposium, 2003. Practical", 12th USENIX Security Symposium (USENIX
Security 03), 2003, <https://www.usenix.org/
conference/12th-usenix-security-symposium/remote-timing-
attacks-are-practical>.
[X501] ITU-T, "Information Technology - Open Systems [X501] ITU-T, "Information Technology - Open Systems
Interconnection - The Directory: Models", ISO/IEC Interconnection - The Directory: Models",
9594-2:2020 , October 2019. ITU-T Recommendation X.501, ISO/IEC 9594-2:2020, October
2019, <https://www.itu.int/rec/T-REC-X.501-201910-I/en>.
Appendix A. State Machine Appendix A. State Machine
This appendix provides a summary of the legal state transitions for This appendix provides a summary of the legal state transitions for
the client and server handshakes. State names (in all capitals, the client and server handshakes. State names (in all capitals,
e.g., START) have no formal meaning but are provided for ease of e.g., START) have no formal meaning but are provided for ease of
comprehension. Actions which are taken only in certain circumstances comprehension. Actions which are taken only in certain circumstances
are indicated in []. The notation "K_{send,recv} = foo" means "set are indicated in []. The notation "K_{send,recv} = foo" means "set
the send/recv key to the given key". the send/recv key to the given key".
skipping to change at page 131, line 45 skipping to change at line 5962
Appendix C. Implementation Notes Appendix C. Implementation Notes
The TLS protocol cannot prevent many common security mistakes. This The TLS protocol cannot prevent many common security mistakes. This
appendix provides several recommendations to assist implementors. appendix provides several recommendations to assist implementors.
[RFC8448] provides test vectors for TLS 1.3 handshakes. [RFC8448] provides test vectors for TLS 1.3 handshakes.
C.1. Random Number Generation and Seeding C.1. Random Number Generation and Seeding
TLS requires a cryptographically secure pseudorandom number generator TLS requires a cryptographically secure pseudorandom number generator
(CSPRNG). A performant and appropriately-secure CSPRNG is provided (CSPRNG). A performant and appropriately secure CSPRNG is provided
by most operating systems or can be sourced from a cryptographic by most operating systems or can be sourced from a cryptographic
library. It is RECOMMENDED to use an existing CSPRNG implementation library. It is RECOMMENDED to use an existing CSPRNG implementation
in preference to crafting a new one. Many adequate cryptographic in preference to crafting a new one. Many adequate cryptographic
libraries are already available under favorable license terms. libraries are already available under favorable license terms.
Should those prove unsatisfactory, [RFC4086] provides guidance on the Should those prove unsatisfactory, [RFC4086] provides guidance on the
generation of random values. generation of random values.
TLS uses random values (1) in public protocol fields such as the TLS uses random values (1) in public protocol fields such as the
public Random values in the ClientHello and ServerHello and (2) to public Random values in the ClientHello and ServerHello and (2) to
generate keying material. With a properly functioning CSPRNG, this generate keying material. With a properly functioning CSPRNG, this
skipping to change at page 132, line 40 skipping to change at line 6005
trusted certificate authority (CA). The selection and addition of trusted certificate authority (CA). The selection and addition of
trust anchors should be done very carefully. Users should be able to trust anchors should be done very carefully. Users should be able to
view information about the certificate and trust anchor. view information about the certificate and trust anchor.
Applications SHOULD also enforce minimum and maximum key sizes. For Applications SHOULD also enforce minimum and maximum key sizes. For
example, certification paths containing keys or signatures weaker example, certification paths containing keys or signatures weaker
than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure
applications. applications.
Note that it is common practice in some protocols to use the same Note that it is common practice in some protocols to use the same
certificate in both client and server modes. This setting has not certificate in both client and server modes. This setting has not
been extensively analyzed and it is the responsibility of the higher been extensively analyzed, and it is the responsibility of the
level protocol to ensure there is no ambiguity in this case about the higher-level protocol to ensure there is no ambiguity in this case
higher-level semantics. about the higher-level semantics.
C.3. Implementation Pitfalls C.3. Implementation Pitfalls
Implementation experience has shown that certain parts of earlier TLS Implementation experience has shown that certain parts of earlier TLS
specifications are not easy to understand and have been a source of specifications are not easy to understand and have been a source of
interoperability and security problems. Many of these areas have interoperability and security problems. Many of these areas have
been clarified in this document but this appendix contains a short been clarified in this document but this appendix contains a short
list of the most important things that require special attention from list of the most important things that require special attention from
implementors. implementors.
skipping to change at page 133, line 23 skipping to change at line 6036
require fragmentation. Certificate compression as defined in require fragmentation. Certificate compression as defined in
[RFC8879] can be used to reduce the risk of fragmentation. [RFC8879] can be used to reduce the risk of fragmentation.
* Do you ignore the TLS record layer version number in all * Do you ignore the TLS record layer version number in all
unencrypted TLS records (see Appendix E)? unencrypted TLS records (see Appendix E)?
* Have you ensured that all support for SSL, RC4, EXPORT ciphers, * Have you ensured that all support for SSL, RC4, EXPORT ciphers,
and MD5 (via the "signature_algorithms" extension) is completely and MD5 (via the "signature_algorithms" extension) is completely
removed from all possible configurations that support TLS 1.3 or removed from all possible configurations that support TLS 1.3 or
later, and that attempts to use these obsolete capabilities fail later, and that attempts to use these obsolete capabilities fail
correctly? (see Appendix E)? correctly (see Appendix E)?
* Do you handle TLS extensions in ClientHellos correctly, including * Do you handle TLS extensions in ClientHellos correctly, including
unknown extensions? unknown extensions?
* When the server has requested a client certificate but no suitable * When the server has requested a client certificate but no suitable
certificate is available, do you correctly send an empty certificate is available, do you correctly send an empty
Certificate message, instead of omitting the whole message (see Certificate message, instead of omitting the whole message (see
Section 4.4.2)? Section 4.4.2)?
* When processing the plaintext fragment produced by AEAD-Decrypt * When processing the plaintext fragment produced by AEAD-Decrypt
skipping to change at page 134, line 16 skipping to change at line 6077
leading zero bytes in the negotiated key (see Section 7.4.1)? leading zero bytes in the negotiated key (see Section 7.4.1)?
* Does your TLS client check that the Diffie-Hellman parameters sent * Does your TLS client check that the Diffie-Hellman parameters sent
by the server are acceptable (see Section 4.2.8.1)? by the server are acceptable (see Section 4.2.8.1)?
* Do you use a strong and, most importantly, properly seeded random * Do you use a strong and, most importantly, properly seeded random
number generator (see Appendix C.1) when generating Diffie-Hellman number generator (see Appendix C.1) when generating Diffie-Hellman
private values, the ECDSA "k" parameter, and other security- private values, the ECDSA "k" parameter, and other security-
critical values? It is RECOMMENDED that implementations implement critical values? It is RECOMMENDED that implementations implement
"deterministic ECDSA" as specified in [RFC6979]. Note that purely "deterministic ECDSA" as specified in [RFC6979]. Note that purely
deterministic ECC signatures such as deterministic ECDSA and EdDSA deterministic Elliptic Curve Cryptography (ECC) signatures such as
may be vulnerable to certain side-channel and fault injection deterministic ECDSA and EdDSA may be vulnerable to certain side-
attacks in easily accessible IoT devices. channel and fault injection attacks in easily accessible Internet
of Things (IoT) devices.
* Do you zero-pad Diffie-Hellman public key values and shared * Do you zero-pad Diffie-Hellman public key values and shared
secrets to the group size (see Section 4.2.8.1 and Section 7.4.1)? secrets to the group size (see Section 4.2.8.1 and Section 7.4.1)?
* Do you verify signatures after making them, to protect against * Do you verify signatures after making them, to protect against
RSA-CRT key leaks [FW15]? RSA-CRT key leaks [FW15]?
C.4. Client and Server Tracking Prevention C.4. Client and Server Tracking Prevention
Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of
skipping to change at page 134, line 44 skipping to change at line 6106
This ensures that clients are always able to use a new ticket when This ensures that clients are always able to use a new ticket when
creating a new connection. creating a new connection.
Offering a ticket to a server additionally allows the server to Offering a ticket to a server additionally allows the server to
correlate different connections. This is possible independent of correlate different connections. This is possible independent of
ticket reuse. Client applications SHOULD NOT offer tickets across ticket reuse. Client applications SHOULD NOT offer tickets across
connections that are meant to be uncorrelated. For example, [FETCH] connections that are meant to be uncorrelated. For example, [FETCH]
defines network partition keys to separate cache lookups in web defines network partition keys to separate cache lookups in web
browsers. browsers.
Clients and Servers SHOULD NOT reuse a key share for multiple Clients and servers SHOULD NOT reuse a key share for multiple
connections. Reuse of a key share allows passive observers to connections. Reuse of a key share allows passive observers to
correlate different connections. Reuse of a client key share to the correlate different connections. Reuse of a client key share to the
same server additionally allows the server to correlate different same server additionally allows the server to correlate different
connections. connections.
It is RECOMMENDED that the labels for external identities be selected It is RECOMMENDED that the labels for external identities be selected
so that they do not provide additional information about the identity so that they do not provide additional information about the identity
of the user. For instance, if the label includes an e-mail address, of the user. For instance, if the label includes an email address,
then this trivially identifies the user to a passive attacker, unlike then this trivially identifies the user to a passive attacker, unlike
the client's Certificate, which is encrypted. There are a number of the client's Certificate, which is encrypted. There are a number of
potential ways to avoid this risk, including (1) using random potential ways to avoid this risk, including (1) using random
identity labels (2) pre-encrypting the identity under a key known to identity labels, (2) pre-encrypting the identity under a key known to
the server or (3) using the Encrypted Client Hello the server, or (3) using the Encrypted Client Hello extension
[I-D.ietf-tls-esni] extension. [PRE-RFC9849].
If an external PSK identity is used for multiple connections, then it If an external PSK identity is used for multiple connections, then it
will generally be possible for an external observer to track clients will generally be possible for an external observer to track clients
and/or servers across connections. Use of the Encrypted Client Hello and/or servers across connections. Use of the Encrypted Client Hello
[I-D.ietf-tls-esni] extension can mitigate this risk, as can extension [PRE-RFC9849] can mitigate this risk, as can mechanisms
mechanisms external to TLS that rotate or encrypt the PSK identity. external to TLS that rotate or encrypt the PSK identity.
C.5. Unauthenticated Operation C.5. Unauthenticated Operation
Previous versions of TLS offered explicitly unauthenticated cipher Previous versions of TLS offered explicitly unauthenticated cipher
suites based on anonymous Diffie-Hellman. These modes have been suites based on anonymous Diffie-Hellman. These modes have been
deprecated in TLS 1.3. However, it is still possible to negotiate deprecated in TLS 1.3. However, it is still possible to negotiate
parameters that do not provide verifiable server authentication by parameters that do not provide verifiable server authentication by
several methods, including: several methods, including:
* Raw public keys [RFC7250]. * Raw public keys [RFC7250].
skipping to change at page 135, line 37 skipping to change at line 6148
* Using a public key contained in a certificate but without * Using a public key contained in a certificate but without
validation of the certificate chain or any of its contents. validation of the certificate chain or any of its contents.
Either technique used alone is vulnerable to man-in-the-middle Either technique used alone is vulnerable to man-in-the-middle
attacks and therefore unsafe for general use. However, it is also attacks and therefore unsafe for general use. However, it is also
possible to bind such connections to an external authentication possible to bind such connections to an external authentication
mechanism via out-of-band validation of the server's public key, mechanism via out-of-band validation of the server's public key,
trust on first use, or a mechanism such as channel bindings (though trust on first use, or a mechanism such as channel bindings (though
the channel bindings described in [RFC5929] are not defined for TLS the channel bindings described in [RFC5929] are not defined for TLS
1.3). If no such mechanism is used, then the connection has no 1.3). If no such mechanism is used, then the connection has no
protection against active man-in-the-middle attack; applications MUST protection against an active man-in-the-middle attack; applications
NOT use TLS in such a way absent explicit configuration or a specific MUST NOT use TLS in such a way absent explicit configuration or a
application profile. specific application profile.
Appendix D. Updates to TLS 1.2 Appendix D. Updates to TLS 1.2
To align with the names used this document, the following terms from To align with the names used this document, the following terms from
[RFC5246] are renamed: [RFC5246] are renamed:
* The master secret, computed in Section 8.1 of [RFC5246], is * The master secret, computed in Section 8.1 of [RFC5246], is
renamed to the main secret. It is referred to as main_secret in renamed to the main secret. It is referred to as main_secret in
formulas and structures, instead of master_secret. However, the formulas and structures, instead of master_secret. However, the
label parameter to the PRF function is left unchanged for label parameter to the PRF function is left unchanged for
skipping to change at page 140, line 28 skipping to change at line 6377
F.1. Handshake F.1. Handshake
The TLS handshake is an Authenticated Key Exchange (AKE) protocol The TLS handshake is an Authenticated Key Exchange (AKE) protocol
which is intended to provide both one-way authenticated (server-only) which is intended to provide both one-way authenticated (server-only)
and mutually authenticated (client and server) functionality. At the and mutually authenticated (client and server) functionality. At the
completion of the handshake, each side outputs its view of the completion of the handshake, each side outputs its view of the
following values: following values:
* A set of "session keys" (the various secrets derived from the main * A set of "session keys" (the various secrets derived from the main
secret) from which can be derived a set of working keys. Note secret) from which a set of working keys can be derived. Note
that when early data is in use, secrets are also derived from the that when early data is in use, secrets are also derived from the
early secret. These enjoy somewhat weaker properties than those early secret. These enjoy somewhat weaker properties than those
derived from the main secret, as detailed below. derived from the main secret, as detailed below.
* A set of cryptographic parameters (algorithms, etc.). * A set of cryptographic parameters (algorithms, etc.).
* The identities of the communicating parties. * The identities of the communicating parties.
We assume the attacker to be an active network attacker, which means We assume the attacker to be an active network attacker, which means
it has complete control over the network used to communicate between it has complete control over the network used to communicate between
skipping to change at page 141, line 32 skipping to change at line 6427
Definitions 8 and 9). Definitions 8 and 9).
Forward secret with respect to long-term keys: If the long-term Forward secret with respect to long-term keys: If the long-term
keying material (in this case the signature keys in certificate- keying material (in this case the signature keys in certificate-
based authentication modes or the external/resumption PSK in PSK based authentication modes or the external/resumption PSK in PSK
with (EC)DHE modes) is compromised after the handshake is with (EC)DHE modes) is compromised after the handshake is
complete, this does not compromise the security of the session key complete, this does not compromise the security of the session key
(see [DOW92]), as long as the session key itself (and all material (see [DOW92]), as long as the session key itself (and all material
that could be used to recreate the session key) has been erased. that could be used to recreate the session key) has been erased.
In particular, private keys corresponding to key shares, shared In particular, private keys corresponding to key shares, shared
secrets, and keys derived in the TLS Key Schedule other than secrets, and keys derived in the TLS key schedule other than
binder_key, resumption_secret, and PSKs derived from the binder_key, resumption_secret, and PSKs derived from the
resumption_secret also need to be erased. The forward secrecy resumption_secret also need to be erased. The forward secrecy
property is not satisfied when PSK is used in the "psk_ke" property is not satisfied when PSK is used in the "psk_ke"
PskKeyExchangeMode. Failing to erase keys or secrets intended to PskKeyExchangeMode. Failing to erase keys or secrets intended to
be ephemeral or connection-specific in effect creates additional be ephemeral or connection-specific in effect creates additional
long-term keys that must be protected. Compromise of those long- long-term keys that must be protected. Compromise of those long-
term keys (even after the handshake is complete) can result in term keys (even after the handshake is complete) can result in
loss of protection for the connection's traffic. loss of protection for the connection's traffic.
Key Compromise Impersonation (KCI) resistance: In a mutually Key Compromise Impersonation (KCI) resistance: In a mutually
authenticated connection with certificates, compromising the long- authenticated connection with certificates, compromising the long-
term secret of one actor should not break that actor’s term secret of one actor should not break that actor's
authentication of their peer in the given connection (see authentication of their peer in the given connection (see
[HGFS15]). For example, if a client's signature key is [HGFS15]). For example, if a client's signature key is
compromised, it should not be possible to impersonate arbitrary compromised, it should not be possible to impersonate arbitrary
servers to that client in subsequent handshakes. servers to that client in subsequent handshakes.
Protection of endpoint identities: The server's identity Protection of endpoint identities: The server's identity
(certificate) should be protected against passive attackers. The (certificate) should be protected against passive attackers. The
client's identity (certificate) should be protected against both client's identity (certificate) should be protected against both
passive and active attackers. This property does not hold for passive and active attackers. This property does not hold for
cipher suites without confidentiality; while this specification cipher suites without confidentiality; while this specification
skipping to change at page 143, line 19 skipping to change at line 6491
rerunning (EC)DHE. If a long-term authentication key has been rerunning (EC)DHE. If a long-term authentication key has been
compromised, a full handshake with (EC)DHE gives protection against compromised, a full handshake with (EC)DHE gives protection against
passive attackers. If the resumption_secret has been compromised, a passive attackers. If the resumption_secret has been compromised, a
resumption handshake with (EC)DHE gives protection against passive resumption handshake with (EC)DHE gives protection against passive
attackers and a full handshake with (EC)DHE gives protection against attackers and a full handshake with (EC)DHE gives protection against
active attackers. If a traffic secret has been compromised, any active attackers. If a traffic secret has been compromised, any
handshake with (EC)DHE gives protection against active attackers. handshake with (EC)DHE gives protection against active attackers.
Using the terms in [RFC7624], forward secrecy without rerunning Using the terms in [RFC7624], forward secrecy without rerunning
(EC)DHE does not stop an attacker from doing static key exfiltration. (EC)DHE does not stop an attacker from doing static key exfiltration.
After key exfiltration of application_traffic_secret_N, an attacker After key exfiltration of application_traffic_secret_N, an attacker
can e.g., passively eavesdrop on all future data sent on the can, e.g., passively eavesdrop on all future data sent on the
connection including data encrypted with connection including data encrypted with
application_traffic_secret_N+1, application_traffic_secret_N+2, etc. application_traffic_secret_N+1, application_traffic_secret_N+2, etc.
Frequently rerunning (EC)DHE forces an attacker to do dynamic key Frequently rerunning (EC)DHE forces an attacker to do dynamic key
exfiltration (or content exfiltration). exfiltration (or content exfiltration).
The PSK binder value forms a binding between a PSK and the current The PSK binder value forms a binding between a PSK and the current
handshake, as well as between the session where the PSK was handshake, as well as between the session where the PSK was
established and the current session. This binding transitively established and the current session. This binding transitively
includes the original handshake transcript, because that transcript includes the original handshake transcript, because that transcript
is digested into the values which produce the resumption secret. is digested into the values which produce the resumption secret.
skipping to change at page 147, line 10 skipping to change at line 6672
mechanism described in Section 4.6.3 has been used and the mechanism described in Section 4.6.3 has been used and the
previous generation key is deleted, an attacker who compromises previous generation key is deleted, an attacker who compromises
the endpoint should not be able to decrypt traffic encrypted with the endpoint should not be able to decrypt traffic encrypted with
the old key. the old key.
Informally, TLS 1.3 provides these properties by AEAD-protecting the Informally, TLS 1.3 provides these properties by AEAD-protecting the
plaintext with a strong key. AEAD encryption [RFC5116] provides plaintext with a strong key. AEAD encryption [RFC5116] provides
confidentiality and integrity for the data. Non-replayability is confidentiality and integrity for the data. Non-replayability is
provided by using a separate nonce for each record, with the nonce provided by using a separate nonce for each record, with the nonce
being derived from the record sequence number (Section 5.3), with the being derived from the record sequence number (Section 5.3), with the
sequence number being maintained independently at both sides; thus sequence number being maintained independently at both sides; thus,
records which are delivered out of order result in AEAD deprotection records which are delivered out of order result in AEAD deprotection
failures. In order to prevent mass cryptanalysis when the same failures. In order to prevent mass cryptanalysis when the same
plaintext is repeatedly encrypted by different users under the same plaintext is repeatedly encrypted by different users under the same
key (as is commonly the case for HTTP), the nonce is formed by mixing key (as is commonly the case for HTTP), the nonce is formed by mixing
the sequence number with a secret per-connection initialization the sequence number with a secret per-connection initialization
vector derived along with the traffic keys. See [BT16] for analysis vector derived along with the traffic keys. See [BT16] for analysis
of this construction. of this construction.
The rekeying technique in TLS 1.3 (see Section 7.2) follows the The rekeying technique in TLS 1.3 (see Section 7.2) follows the
construction of the serial generator as discussed in [REKEY], which construction of the serial generator as discussed in [REKEY], which
skipping to change at page 151, line 48 skipping to change at line 6894
External PSKs in TLS are designed to be known to exactly one client External PSKs in TLS are designed to be known to exactly one client
and one server. However, as noted in [RFC9257], there are use cases and one server. However, as noted in [RFC9257], there are use cases
where PSKs are shared between more than two entities. In such where PSKs are shared between more than two entities. In such
scenarios, in addition to the expected security weakness where a scenarios, in addition to the expected security weakness where a
compromised group member can impersonate any other member, a compromised group member can impersonate any other member, a
malicious non-member can reroute handshakes between honest group malicious non-member can reroute handshakes between honest group
members to connect them in unintended ways [Selfie]. [RFC9257] members to connect them in unintended ways [Selfie]. [RFC9257]
provides recommendations for external PSK usage, including the use of provides recommendations for external PSK usage, including the use of
external PSK importers as defined in [RFC9258], that prevent such external PSK importers as defined in [RFC9258], that prevent such
malicious rerouting of messages malicious rerouting of messages.
F.9. Misbinding when using Self-Signed Certificates or Raw Public Keys F.9. Misbinding When Using Self-Signed Certificates or Raw Public Keys
When TLS 1.3 is used with self-signed certificates without useful When TLS 1.3 is used with self-signed certificates without useful
identities (as in DTLS-SRTP [RFC5763]) or raw public keys [RFC7250] identities (as in DTLS-SRTP [RFC5763]) or raw public keys [RFC7250]
for peer authentication, it may be vulnerable to misbinding attacks for peer authentication, it may be vulnerable to misbinding attacks
[MM24]. This risk can be mitigated by using the "external_id_hash" [MM24]. This risk can be mitigated by using the "external_id_hash"
extension [RFC8844] or, if only the server is being authenticated, by extension [RFC8844] or, if only the server is being authenticated, by
the server verifying that the "server_name" extension matches its the server verifying that the "server_name" extension matches its
expected identity. expected identity.
F.10. Attacks on Static RSA F.10. Attacks on Static RSA
skipping to change at page 152, line 30 skipping to change at line 6921
versions of TLS, then it may be possible to impersonate the server versions of TLS, then it may be possible to impersonate the server
for TLS 1.3 connections [JSS15]. TLS 1.3 implementations can prevent for TLS 1.3 connections [JSS15]. TLS 1.3 implementations can prevent
this attack by disabling support for static RSA across all versions this attack by disabling support for static RSA across all versions
of TLS. In principle, implementations might also be able to separate of TLS. In principle, implementations might also be able to separate
certificates with different keyUsage bits for static RSA decryption certificates with different keyUsage bits for static RSA decryption
and RSA signature, but this technique relies on clients refusing to and RSA signature, but this technique relies on clients refusing to
accept signatures using keys in certificates that do not have the accept signatures using keys in certificates that do not have the
digitalSignature bit set, and many clients do not enforce this digitalSignature bit set, and many clients do not enforce this
restriction. restriction.
Appendix G. 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 Contributors
Martin Abadi Martin Abadi
University of California, Santa Cruz University of California, Santa Cruz
abadi@cs.ucsc.edu abadi@cs.ucsc.edu
Christopher Allen Christopher Allen
(co-editor of TLS 1.0) (co-editor of TLS 1.0)
Alacrity Ventures Alacrity Ventures
ChristopherA@AlacrityManagement.com ChristopherA@AlacrityManagement.com
skipping to change at page 154, line 20 skipping to change at line 6953
David Benjamin David Benjamin
Google Google
davidben@google.com davidben@google.com
Benjamin Beurdouche Benjamin Beurdouche
INRIA & Microsoft Research INRIA & Microsoft Research
benjamin.beurdouche@ens.fr benjamin.beurdouche@ens.fr
Karthikeyan Bhargavan Karthikeyan Bhargavan
(editor of [RFC7627]) (editor of {{RFC7627}})
INRIA INRIA
karthikeyan.bhargavan@inria.fr karthikeyan.bhargavan@inria.fr
Simon Blake-Wilson Simon Blake-Wilson
(co-author of [RFC4492]) (co-author of {{RFC4492}})
BCI BCI
sblakewilson@bcisse.com sblakewilson@bcisse.com
Nelson Bolyard Nelson Bolyard
(co-author of [RFC4492]) (co-author of {{RFC4492}})
Sun Microsystems, Inc. Sun Microsystems, Inc.
nelson@bolyard.com nelson@bolyard.com
Ran Canetti Ran Canetti
IBM IBM
canetti@watson.ibm.com canetti@watson.ibm.com
Matt Caswell Matt Caswell
OpenSSL OpenSSL
matt@openssl.org matt@openssl.org
skipping to change at page 155, line 11 skipping to change at line 6992
Katriel Cohn-Gordon Katriel Cohn-Gordon
University of Oxford University of Oxford
me@katriel.co.uk me@katriel.co.uk
Cas Cremers Cas Cremers
University of Oxford University of Oxford
cas.cremers@cs.ox.ac.uk cas.cremers@cs.ox.ac.uk
Antoine Delignat-Lavaud Antoine Delignat-Lavaud
(co-author of [RFC7627]) (co-author of {{RFC7627}})
INRIA INRIA
antdl@microsoft.com antdl@microsoft.com
Tim Dierks Tim Dierks
(co-author of TLS 1.0, co-editor of TLS 1.1 and 1.2) (co-author of TLS 1.0, co-editor of TLS 1.1 and 1.2)
Independent Independent
tim@dierks.org tim@dierks.org
Roelof DuToit Roelof DuToit
Symantec Corporation Symantec Corporation
skipping to change at page 156, line 19 skipping to change at line 7048
Jens Guballa Jens Guballa
ETAS ETAS
jens.guballa@etas.com jens.guballa@etas.com
Felix Guenther Felix Guenther
TU Darmstadt TU Darmstadt
mail@felixguenther.info mail@felixguenther.info
Vipul Gupta Vipul Gupta
(co-author of [RFC4492]) (co-author of {{RFC4492}})
Sun Microsystems Laboratories Sun Microsystems Laboratories
vipul.gupta@sun.com vipul.gupta@sun.com
Chris Hawk Chris Hawk
(co-author of [RFC4492]) (co-author of {{RFC4492}})
Corriente Networks LLC Corriente Networks LLC
chris@corriente.net chris@corriente.net
Kipp Hickman Kipp Hickman
Alfred Hoenes Alfred Hoenes
David Hopwood David Hopwood
Independent Consultant Independent Consultant
david.hopwood@blueyonder.co.uk david.hopwood@blueyonder.co.uk
skipping to change at page 157, line 25 skipping to change at line 7102
Paul Kocher Paul Kocher
(co-author of SSL 3.0) (co-author of SSL 3.0)
Cryptography Research Cryptography Research
paul@cryptography.com paul@cryptography.com
Hugo Krawczyk Hugo Krawczyk
IBM IBM
hugokraw@us.ibm.com hugokraw@us.ibm.com
Adam Langley Adam Langley
(co-author of [RFC7627]) (co-author of {{RFC7627}})
Google Google
agl@google.com agl@google.com
Olivier Levillain Olivier Levillain
ANSSI ANSSI
olivier.levillain@ssi.gouv.fr olivier.levillain@ssi.gouv.fr
Xiaoyin Liu Xiaoyin Liu
University of North Carolina at Chapel Hill University of North Carolina at Chapel Hill
xiaoyin.l@outlook.com xiaoyin.l@outlook.com
skipping to change at page 158, line 4 skipping to change at line 7129
K.U. Leuven K.U. Leuven
atul.luykx@kuleuven.be atul.luykx@kuleuven.be
Colm MacCarthaigh Colm MacCarthaigh
Amazon Web Services Amazon Web Services
colm@allcosts.net colm@allcosts.net
Carl Mehner Carl Mehner
USAA USAA
carl.mehner@usaa.com carl.mehner@usaa.com
Jan Mikkelsen Jan Mikkelsen
Transactionware Transactionware
janm@transactionware.com janm@transactionware.com
Bodo Moeller Bodo Moeller
(co-author of [RFC4492]) (co-author of {{RFC4492}})
Google Google
bodo@acm.org bodo@acm.org
Kyle Nekritz Kyle Nekritz
Facebook Facebook
knekritz@fb.com knekritz@fb.com
Erik Nygren Erik Nygren
Akamai Technologies Akamai Technologies
erik+ietf@nygren.org erik+ietf@nygren.org
skipping to change at page 158, line 38 skipping to change at line 7164
Kenny Paterson Kenny Paterson
Royal Holloway, University of London Royal Holloway, University of London
kenny.paterson@rhul.ac.uk kenny.paterson@rhul.ac.uk
Christopher Patton Christopher Patton
University of Florida University of Florida
cjpatton@ufl.edu cjpatton@ufl.edu
Alfredo Pironti Alfredo Pironti
(co-author of [RFC7627]) (co-author of {{RFC7627}})
INRIA INRIA
alfredo.pironti@inria.fr alfredo.pironti@inria.fr
Andrei Popov Andrei Popov
Microsoft Microsoft
andrei.popov@microsoft.com andrei.popov@microsoft.com
John {{{Preuß Mattsson}}} John Preuß Mattsson
Ericsson Ericsson
john.mattsson@ericsson.com john.mattsson@ericsson.com
Marsh Ray Marsh Ray
(co-author of [RFC7627]) (co-author of {{RFC7627}})
Microsoft Microsoft
maray@microsoft.com maray@microsoft.com
Robert Relyea Robert Relyea
Netscape Communications Netscape Communications
relyea@netscape.com relyea@netscape.com
Kyle Rose Kyle Rose
Akamai Technologies Akamai Technologies
krose@krose.org krose@krose.org
 End of changes. 190 change blocks. 
529 lines changed or deleted 474 lines changed or added

This html diff was produced by rfcdiff 1.48.