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 15 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 (IV) 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 20 skipping to change at line 239
parameters than they would if the connection were not under parameters than they would if the connection were not under
attack. attack.
* A record protocol (Section 5) that uses the parameters established * A record protocol (Section 5) that uses the parameters established
by the handshake protocol to protect traffic between the by the handshake protocol to protect traffic between the
communicating peers. The record protocol divides traffic up into communicating peers. The record protocol divides traffic up into
a series of records, each of which is independently protected a series of records, each of which is independently protected
using the traffic keys. using the traffic keys.
TLS is application protocol independent; higher-level protocols can TLS is application protocol independent; higher-level protocols can
layer on top of TLS transparently. The TLS standard, however, does layer on top of TLS transparently. However, the TLS standard does
not specify how protocols add security with TLS; how to initiate TLS not specify how protocols add security with TLS; how to initiate TLS
handshaking and how to interpret the authentication certificates handshaking and how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors exchanged are left to the judgment of the designers and implementors
of protocols that run on top of TLS. Application protocols using TLS of protocols that run on top of TLS. Application protocols using TLS
MUST specify how TLS works with their application protocol, including MUST specify how TLS works with their application protocol, including
how and when handshaking occurs, and how to do identity verification. how and when handshaking occurs, and how to do identity verification.
[RFC9525] provides useful guidance on integrating TLS with [RFC9525] provides useful guidance on integrating TLS with
application protocols. application protocols.
This document defines TLS version 1.3. While TLS 1.3 is not directly This document defines TLS version 1.3. While TLS 1.3 is not directly
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 8, line 30 skipping to change at line 346
TLS 1.2 and TLS 1.3. It is not intended to be exhaustive, and there TLS 1.2 and TLS 1.3. It is not intended to be exhaustive, and there
are many minor differences. are many minor differences.
* The list of supported symmetric encryption algorithms has been * The list of supported symmetric encryption algorithms has been
pruned of all algorithms that are considered legacy. Those that pruned of all algorithms that are considered legacy. Those that
remain are all Authenticated Encryption with Associated Data remain are all Authenticated Encryption with Associated Data
(AEAD) algorithms. The cipher suite concept has been changed to (AEAD) algorithms. The cipher suite concept has been changed to
separate the authentication and key exchange mechanisms from the separate the authentication and key exchange mechanisms from the
record protection algorithm (including secret key length) and a record protection algorithm (including secret key length) and a
hash to be used with both the key derivation function and hash to be used with both the key derivation function and
handshake message authentication code (MAC). handshake Message Authentication Code (MAC).
* A zero round-trip time (0-RTT) mode was added, saving a round trip * A zero round-trip time (0-RTT) mode was added, saving a round trip
at connection setup for some application data, at the cost of at connection setup for some application data, at the cost of
certain security properties. certain security properties.
* Static RSA and Diffie-Hellman cipher suites have been removed; all * Static RSA and Diffie-Hellman cipher suites have been removed; all
public-key based key exchange mechanisms now provide forward public-key-based key exchange mechanisms now provide forward
secrecy. secrecy.
* All handshake messages after the ServerHello are now encrypted. * All handshake messages after the ServerHello are now encrypted.
The newly introduced EncryptedExtensions message allows various The newly introduced EncryptedExtensions message allows various
extensions previously sent in the clear in the ServerHello to also extensions previously sent in the clear in the ServerHello to also
enjoy confidentiality protection. enjoy confidentiality protection.
* 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 12, line 33 skipping to change at line 521
establishment is in use, then the ServerHello contains a establishment is in use, then the ServerHello contains a
"pre_shared_key" extension indicating which of the client's offered "pre_shared_key" extension indicating which of the client's offered
PSKs was selected. Note that implementations can use (EC)DHE and PSK PSKs was selected. Note that implementations can use (EC)DHE and PSK
together, in which case both extensions will be supplied. together, in which case both extensions will be supplied.
The server then sends two messages to establish the Server The server then sends two messages to establish the Server
Parameters: Parameters:
EncryptedExtensions: responses to ClientHello extensions that are EncryptedExtensions: responses to ClientHello extensions that are
not required to determine the cryptographic parameters, other than not required to determine the cryptographic parameters, other than
those that are specific to individual certificates. those that are specific to individual certificates. Section 4.3.1
[Section 4.3.1]
CertificateRequest: if certificate-based client authentication is CertificateRequest: if certificate-based client authentication is
desired, the desired parameters for that certificate. This desired, the desired parameters for that certificate. This
message is omitted if client authentication is not desired. message is omitted if client authentication is not desired.
[Section 4.3.2] Section 4.3.2
Finally, the client and server exchange Authentication messages. TLS Finally, the client and server exchange Authentication messages. TLS
uses the same set of messages every time that certificate-based uses the same set of messages every time that certificate-based
authentication is needed. (PSK-based authentication happens as a authentication is needed. (PSK-based authentication happens as a
side effect of key exchange.) Specifically: side effect of key exchange.) Specifically:
Certificate: The certificate of the endpoint and any per-certificate Certificate: The certificate of the endpoint and any per-certificate
extensions. This message is omitted by the server if not extensions. This message is omitted by the server if not
authenticating with a certificate and by the client if the server authenticating with a certificate and by the client if the server
did not send CertificateRequest (thus indicating that the client did not send CertificateRequest (thus indicating that the client
should not authenticate with a certificate). Note that if raw should not authenticate with a certificate). Note that if raw
public keys [RFC7250] or the cached information extension public keys [RFC7250] or the cached information extension
[RFC7924] are in use, then this message will not contain a [RFC7924] are in use, then this message will not contain a
certificate but rather some other value corresponding to the certificate but rather some other value corresponding to the
server's long-term key. [Section 4.4.2] server's long-term key. Section 4.4.2
CertificateVerify: A signature over the entire handshake using the CertificateVerify: A signature over the entire handshake using the
private key corresponding to the public key in the Certificate private key corresponding to the public key in the Certificate
message. This message is omitted if the endpoint is not message. This message is omitted if the endpoint is not
authenticating via a certificate. [Section 4.4.3] authenticating via a certificate. Section 4.4.3
Finished: A MAC (Message Authentication Code) over the entire Finished: A Message Authentication Code (MAC) over the entire
handshake. This message provides key confirmation for the shared handshake. This message provides key confirmation for the shared
secrets established in the handshake binds the endpoint's identity secrets established in the handshake, binds the endpoint's
to the exchanged keys, and in PSK mode also authenticates the identity to the exchanged keys, and in PSK mode also authenticates
handshake. [Section 4.4.4] the handshake. Section 4.4.4
Upon receiving the server's messages, the client responds with its Upon receiving the server's messages, the client responds with its
Authentication messages, namely Certificate and CertificateVerify (if Authentication messages, namely Certificate and CertificateVerify (if
requested), and Finished. requested), and Finished.
At this point, the handshake is complete, and the client and server At this point, the handshake is complete, and the client and server
derive the keying material required by the record layer to exchange derive the keying material required by the record layer to exchange
application-layer data protected through authenticated encryption. application-layer data protected through authenticated encryption.
Application Data MUST NOT be sent prior to sending the Finished Application Data MUST NOT be sent prior to sending the Finished
message, except as specified in Section 2.3. Note that while the message, except as specified in Section 2.3. Note that while the
skipping to change at page 16, line 12 skipping to change at line 678
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
skipping to change at page 24, line 17 skipping to change at line 1041
The key exchange messages are used to determine the security The key exchange messages are used to determine the security
capabilities of the client and the server and to establish shared capabilities of the client and the server and to establish shared
secrets, including the traffic keys used to protect the rest of the secrets, including the traffic keys used to protect the rest of the
handshake and the data. handshake and the data.
4.1.1. Cryptographic Negotiation 4.1.1. Cryptographic Negotiation
In TLS, the cryptographic negotiation proceeds by the client offering In TLS, the cryptographic negotiation proceeds by the client offering
the following four sets of options in its ClientHello: the following four sets of options in its ClientHello:
* A list of cipher suites which indicates the AEAD algorithm/HKDF * A list of cipher suites that indicates the AEAD algorithm / HKDF
hash pairs which the client supports. hash pairs which the client supports.
* A "supported_groups" (Section 4.2.7) extension which indicates the * A "supported_groups" (Section 4.2.7) extension which indicates the
(EC)DHE groups which the client supports and a "key_share" (EC)DHE groups that the client supports and a "key_share"
(Section 4.2.8) extension which contains (EC)DHE shares for some (Section 4.2.8) extension which contains (EC)DHE shares for some
or all of these groups. or all of these groups.
* A "signature_algorithms" (Section 4.2.3) extension which indicates * A "signature_algorithms" (Section 4.2.3) extension which indicates
the signature algorithms which the client can accept. A the signature algorithms that the client can accept. A
"signature_algorithms_cert" extension (Section 4.2.3) may also be "signature_algorithms_cert" extension (Section 4.2.3) may also be
added to indicate certificate-specific signature algorithms. added to indicate certificate-specific signature algorithms.
* A "pre_shared_key" (Section 4.2.11) extension which contains a * A "pre_shared_key" (Section 4.2.11) extension which contains a
list of symmetric key identities known to the client and a list of symmetric key identities known to the client and a
"psk_key_exchange_modes" (Section 4.2.9) extension which indicates "psk_key_exchange_modes" (Section 4.2.9) extension which indicates
the key exchange modes that may be used with PSKs. the key exchange modes that may be used with PSKs.
If the server does not select a PSK, then the first three of these If the server does not select a PSK, then the first three of these
options are entirely orthogonal: the server independently selects a options are entirely orthogonal: The server independently selects a
cipher suite, an (EC)DHE group and key share for key establishment, cipher suite, an (EC)DHE group and key share for key establishment,
and a signature algorithm/certificate pair to authenticate itself to and a signature algorithm/certificate pair to authenticate itself to
the client. If there is no overlap between the received the client. If there is no overlap between the received
"supported_groups" and the groups supported by the server, then the "supported_groups" and the groups supported by the server, then the
server MUST abort the handshake with a "handshake_failure" or an server MUST abort the handshake with a "handshake_failure" or an
"insufficient_security" alert. "insufficient_security" alert.
If the server selects a PSK, then it MUST also select a key If the server selects a PSK, then it MUST also select a key
establishment mode from the list indicated by the client's establishment mode from the list indicated by the client's
"psk_key_exchange_modes" extension (at present, PSK alone or with "psk_key_exchange_modes" extension (at present, PSK alone or with
skipping to change at page 25, line 22 skipping to change at line 1092
* If PSK is being used, then the server will send a "pre_shared_key" * If PSK is being used, then the server will send a "pre_shared_key"
extension indicating the selected key. extension indicating the selected key.
* When (EC)DHE is in use, the server will also provide a "key_share" * When (EC)DHE is in use, the server will also provide a "key_share"
extension. If PSK is not being used, then (EC)DHE and extension. If PSK is not being used, then (EC)DHE and
certificate-based authentication are always used. certificate-based authentication are always used.
* When authenticating via a certificate, the server will send the * When authenticating via a certificate, the server will send the
Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3) Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
messages. In TLS 1.3 as defined by this document, either a PSK or messages. In TLS 1.3, as defined by this document, either a PSK
a certificate is always used, but not both. Future documents may or a certificate is always used, but not both. Future documents
define how to use them together. may define how to use them together.
If the server is unable to negotiate a supported set of parameters If the server is unable to negotiate a supported set of parameters
(i.e., there is no overlap between the client and server parameters), (i.e., there is no overlap between the client and server parameters),
it MUST abort the handshake with either a "handshake_failure" or it MUST abort the handshake with either a "handshake_failure" or
"insufficient_security" fatal alert (see Section 6). "insufficient_security" fatal alert (see Section 6).
4.1.2. Client Hello 4.1.2. Client Hello
When a client first connects to a server, it is REQUIRED to send the When a client first connects to a server, it is REQUIRED to send the
ClientHello as its first TLS message. The client will also send a ClientHello as its first TLS message. The client will also send a
skipping to change at page 26, line 22 skipping to change at line 1141
1.3 and receives a ClientHello at any other time, it MUST terminate 1.3 and receives a ClientHello at any other time, it MUST terminate
the connection with an "unexpected_message" alert. the connection with an "unexpected_message" alert.
If a server established a TLS connection with a previous version of If a server established a TLS connection with a previous version of
TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST
retain the previous protocol version. In particular, it MUST NOT retain the previous protocol version. In particular, it MUST NOT
negotiate TLS 1.3. negotiate TLS 1.3.
Structure of this message: Structure of this message:
uint16 ProtocolVersion; uint16 ProtocolVersion;
opaque Random[32]; opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct { struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random; Random random;
opaque legacy_session_id<0..32>; opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>; CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>; opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>; Extension extensions<8..2^16-1>;
} ClientHello; } ClientHello;
legacy_version: In previous versions of TLS, this field was used for legacy_version: In previous versions of TLS, this field was used for
version negotiation and represented the highest version number version negotiation and represented the highest version number
supported by the client. Experience has shown that many servers supported by the client. Experience has shown that many servers
do not properly implement version negotiation, leading to "version do not properly implement version negotiation, leading to "version
intolerance" in which the server rejects an otherwise acceptable intolerance" in which the server rejects an otherwise acceptable
ClientHello with a version number higher than it supports. In TLS ClientHello with a version number higher than it supports. In TLS
1.3, the client indicates its version preferences in the 1.3, the client indicates its version preferences in the
"supported_versions" extension (Section 4.2.1) and the "supported_versions" extension (Section 4.2.1) and the
legacy_version field MUST be set to 0x0303, which is the version legacy_version field MUST be set to 0x0303, which is the version
skipping to change at page 28, line 36 skipping to change at line 1252
waiting for the next handshake message. waiting for the next handshake message.
4.1.3. Server Hello 4.1.3. Server Hello
The server will send this message in response to a ClientHello The server will send this message in response to a ClientHello
message to proceed with the handshake if it is able to negotiate an message to proceed with the handshake if it is able to negotiate an
acceptable set of handshake parameters based on the ClientHello. acceptable set of handshake parameters based on the ClientHello.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random; Random random;
opaque legacy_session_id_echo<0..32>; opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite; CipherSuite cipher_suite;
uint8 legacy_compression_method = 0; uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>; Extension extensions<6..2^16-1>;
} ServerHello; } ServerHello;
legacy_version: In previous versions of TLS, this field was used for legacy_version: In previous versions of TLS, this field was used for
version negotiation and represented the selected version number version negotiation and represented the selected version number
for the connection. Unfortunately, some middleboxes fail when for the connection. Unfortunately, some middleboxes fail when
presented with new values. In TLS 1.3, the TLS server indicates presented with new values. In TLS 1.3, the TLS server indicates
its version using the "supported_versions" extension its version using the "supported_versions" extension
(Section 4.2.1), and the legacy_version field MUST be set to (Section 4.2.1), and the legacy_version field MUST be set to
0x0303, which is the version number for TLS 1.2. (See Appendix E 0x0303, which is the version number for TLS 1.2. (See Appendix E
for details about backward compatibility.) A client which for details about backward compatibility.) A client which
receives a TLS 1.3 Server Hello with a legacy_version value not receives a TLS 1.3 Server Hello with a legacy_version value not
skipping to change at page 29, line 38 skipping to change at line 1302
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, "key_share" extension, or both (when
extension, or both (when using a PSK with (EC)DHE key using a PSK with (EC)DHE key establishment). Other extensions
establishment). Other extensions (see Section 4.2) are sent (see Section 4.2) are sent separately in the EncryptedExtensions
separately in the EncryptedExtensions message. 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 33, line 28 skipping to change at line 1480
The list of extension types is maintained by IANA as described in The list of extension types is maintained by IANA as described in
Section 11. Section 11.
Extensions are generally structured in a request/response fashion, Extensions are generally structured in a request/response fashion,
though some extensions are just requests with no corresponding though some extensions are just requests with no corresponding
response (i.e., indications). The client sends its extension response (i.e., indications). The client sends its extension
requests in the ClientHello message, and the server sends its requests in the ClientHello message, and the server sends its
extension responses in the ServerHello, EncryptedExtensions, extension responses in the ServerHello, EncryptedExtensions,
HelloRetryRequest, and Certificate messages. The server sends HelloRetryRequest, and Certificate messages. The server sends
extension requests in the CertificateRequest message which a client extension requests in the CertificateRequest message, which a client
MAY respond to with a Certificate message. The server MAY also send MAY respond to with a Certificate message. The server MAY also send
unsolicited extensions in the NewSessionTicket, though the client unsolicited extensions in the NewSessionTicket, though the client
does not respond directly to these. does not respond directly to these.
Implementations MUST NOT send extension responses (i.e., in the Implementations MUST NOT send extension responses (i.e., in the
ServerHello, EncryptedExtensions, HelloRetryRequest, and Certificate ServerHello, EncryptedExtensions, HelloRetryRequest, and Certificate
messages) if the remote endpoint did not send the corresponding messages) if the remote endpoint did not send the corresponding
extension requests, with the exception of the "cookie" extension in extension requests, with the exception of the "cookie" extension in
the HelloRetryRequest. Upon receiving such an extension, an endpoint the HelloRetryRequest. Upon receiving such an extension, an endpoint
MUST abort the handshake with an "unsupported_extension" alert. MUST abort the handshake with an "unsupported_extension" alert.
skipping to change at page 34, line 36 skipping to change at line 1532
| 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 1573
+--------------------------------------------------+-------------+ +--------------------------------------------------+-------------+
| 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 only includes extensions marked as "Recommended" at
time of this writing. the 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
the ClientHello (but can appear anywhere in the ServerHello in 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
handshake even when in resumption-PSK mode. However, 0-RTT handshake even when in resumption-PSK mode. However, 0-RTT
parameters are those negotiated in the previous handshake; mismatches parameters are those negotiated in the previous handshake; mismatches
may require rejecting 0-RTT (see Section 4.2.10). may require rejecting 0-RTT (see Section 4.2.10).
There are subtle (and not so subtle) interactions that may occur in There are subtle (and not so subtle) interactions that may occur in
this protocol between new features and existing features which may this protocol between new features and existing features, which may
result in a significant reduction in overall security. The following result in a significant reduction in overall security. The following
considerations should be taken into account when designing new considerations should be taken into account when designing new
extensions: extensions:
* Some cases where a server does not agree to an extension are error * Some cases where a server does not agree to an extension are error
conditions (e.g., the handshake cannot continue), and some are conditions (e.g., the handshake cannot continue), and some are
simply refusals to support particular features. In general, error simply refusals to support particular features. In general, error
alerts should be used for the former and a field in the server alerts should be used for the former and a field in the server
extension response for the latter. extension response for the latter.
skipping to change at page 41, line 7 skipping to change at line 1828
The length of the Salt MUST be equal to the length of the digest The length of the Salt MUST be equal to the length of the digest
algorithm. If the public key is carried in an X.509 certificate, algorithm. If the public key is carried in an X.509 certificate,
it MUST use the RSASSA-PSS OID [RFC5756]. When used in it MUST use the RSASSA-PSS OID [RFC5756]. When used in
certificate signatures, the algorithm parameters MUST be DER certificate signatures, the algorithm parameters MUST be DER
encoded. If the corresponding public key's parameters are encoded. If the corresponding public key's parameters are
present, then the parameters in the signature MUST be identical to present, then the parameters in the signature MUST be identical to
those in the public key. those in the public key.
Legacy algorithms: Indicates algorithms which are being deprecated Legacy algorithms: Indicates algorithms which are being deprecated
because they use algorithms with known weaknesses, specifically because they use algorithms with known weaknesses, specifically
SHA-1 which is used in this context with either (1) RSA using SHA-1, which is used in this context with either (1) RSA using
RSASSA-PKCS1-v1_5 or (2) ECDSA. These values refer solely to RSASSA-PKCS1-v1_5 or (2) ECDSA. These values refer solely to
signatures which appear in certificates (see Section 4.4.2.2) and signatures which appear in certificates (see Section 4.4.2.2) and
are not defined for use in signed TLS handshake messages, although are not defined for use in signed TLS handshake messages, although
they MAY appear in "signature_algorithms" and they MAY appear in "signature_algorithms" and
"signature_algorithms_cert" for backward compatibility with TLS "signature_algorithms_cert" for backward compatibility with TLS
1.2. Endpoints SHOULD NOT negotiate these algorithms but are 1.2. Endpoints SHOULD NOT negotiate these algorithms but are
permitted to do so solely for backward compatibility. Clients permitted to do so solely for backward compatibility. Clients
offering these values MUST list them as the lowest priority offering these values MUST list them as the lowest priority
(listed after all other algorithms in SignatureSchemeList). TLS (listed after all other algorithms in SignatureSchemeList). TLS
1.3 servers MUST NOT offer a SHA-1 signed certificate unless no 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no
skipping to change at page 42, line 33 skipping to change at line 1903
These distinguished names specify a desired distinguished name for These distinguished names specify a desired distinguished name for
a trust anchor or subordinate CA; thus, this message can be used a trust anchor or subordinate CA; thus, this message can be used
to describe known trust anchors as well as a desired authorization to describe known trust anchors as well as a desired authorization
space. space.
The client MAY send the "certificate_authorities" extension in the The client MAY send the "certificate_authorities" extension in the
ClientHello message. The server MAY send it in the ClientHello message. The server MAY send it in the
CertificateRequest message. CertificateRequest message.
The "trusted_ca_keys" extension [RFC6066], which serves a similar The "trusted_ca_keys" extension [RFC6066], which serves a similar
purpose, but is more complicated, is not used in TLS 1.3 (although it purpose but is more complicated, is not used in TLS 1.3 (although it
may appear in ClientHello messages from clients which are offering may appear in ClientHello messages from clients which are offering
prior versions of TLS). prior versions of TLS).
4.2.5. OID Filters 4.2.5. OID Filters
The "oid_filters" extension allows servers to provide a list of OID/ The "oid_filters" extension allows servers to provide a list of OID/
value pairs which it would like the client's certificate to match. value pairs which it would like the client's certificate to match.
This extension, if provided by the server, MUST only be sent in the This extension, if provided by the server, MUST only be sent in the
CertificateRequest message. CertificateRequest message.
skipping to change at page 43, line 18 skipping to change at line 1936
Extended Key Usage). If the server has included a non-empty Extended Key Usage). If the server has included a non-empty
filters list, the client certificate included in the response MUST filters list, the client certificate included in the response MUST
contain all of the specified extension OIDs that the client contain all of the specified extension OIDs that the client
recognizes. For each extension OID recognized by the client, all recognizes. For each extension OID recognized by the client, all
of the specified values MUST be present in the client certificate of the specified values MUST be present in the client certificate
(but the certificate MAY have other values as well). However, the (but the certificate MAY have other values as well). However, the
client MUST ignore and skip any unrecognized certificate extension client MUST ignore and skip any unrecognized certificate extension
OIDs. If the client ignored some of the required certificate OIDs. If the client ignored some of the required certificate
extension OIDs and supplied a certificate that does not satisfy extension OIDs and supplied a certificate that does not satisfy
the request, the server MAY at its discretion either continue the the request, the server MAY at its discretion either continue the
connection without client authentication or abort the handshake connection without client authentication, or abort the handshake
with an "unsupported_certificate" alert. Any given OID MUST NOT with an "unsupported_certificate" alert. Any given OID MUST NOT
appear more than once in the filters list. appear more than once in the filters list.
PKIX RFCs define a variety of certificate extension OIDs and their PKIX RFCs define a variety of certificate extension OIDs and their
corresponding value types. Depending on the type, matching corresponding value types. Depending on the type, matching
certificate extension values are not necessarily bitwise-equal. It certificate extension values are not necessarily bitwise-equal. It
is expected that TLS implementations will rely on their PKI libraries is expected that TLS implementations will rely on their PKI libraries
to perform certificate selection using certificate extension OIDs. to perform certificate selection using certificate extension OIDs.
This document defines matching rules for two standard certificate This document defines matching rules for two standard certificate
skipping to change at page 46, line 27 skipping to change at line 2089
Selecting a group based on KeyShareEntry may result in the use of a Selecting a group based on KeyShareEntry may result in the use of a
less preferred group than the client and server mutually support, less preferred group than the client and server mutually support,
though saving the round trip of HelloRetryRequest. Servers that wish though saving the round trip of HelloRetryRequest. Servers that wish
to respect the client's group preferences SHOULD first select a group to respect the client's group preferences SHOULD first select a group
based on "supported_groups" and then either send a ServerHello or a based on "supported_groups" and then either send a ServerHello or a
HelloRetryRequest depending on the contents of KeyshareClienthello. HelloRetryRequest depending on the contents of KeyshareClienthello.
Clients can offer as many KeyShareEntry values as the number of Clients can offer as many KeyShareEntry values as the number of
supported groups it is offering, each representing a single set of supported groups it is offering, each representing a single set of
key exchange parameters. For instance, a client might offer shares key exchange parameters. For instance, a client might offer shares
for several elliptic curves or multiple FFDHE groups. The for several elliptic curves or multiple Finite Field DHE (FFDHE)
key_exchange values for each KeyShareEntry MUST be generated groups. The key_exchange values for each KeyShareEntry MUST be
independently. Clients MUST NOT offer multiple KeyShareEntry values generated independently. Clients MUST NOT offer multiple
for the same group. Clients MUST NOT offer any KeyShareEntry values KeyShareEntry values for the same group. Clients MUST NOT offer any
for groups not listed in the client's "supported_groups" extension. KeyShareEntry values for groups not listed in the client's
Servers MAY check for violations of these rules and abort the "supported_groups" extension. Servers MAY check for violations of
handshake with an "illegal_parameter" alert if one is violated. these rules and abort the handshake with an "illegal_parameter" alert
if one is violated.
In a HelloRetryRequest message, the "extension_data" field of this In a HelloRetryRequest message, the "extension_data" field of this
extension contains a KeyShareHelloRetryRequest value: extension contains a KeyShareHelloRetryRequest value:
struct { struct {
NamedGroup selected_group; NamedGroup selected_group;
} KeyShareHelloRetryRequest; } KeyShareHelloRetryRequest;
selected_group: The mutually supported group the server intends to selected_group: The mutually supported group the server intends to
negotiate and is requesting a retried ClientHello/KeyShare for. negotiate and is requesting a retried ClientHello/KeyShare for.
skipping to change at page 49, line 31 skipping to change at line 2239
client and server MUST supply "key_share" values as described in client and server MUST supply "key_share" values as described in
Section 4.2.8. Section 4.2.8.
Any future values that are allocated must ensure that the transmitted Any future values that are allocated must ensure that the transmitted
protocol messages unambiguously identify which mode was selected by protocol messages unambiguously identify which mode was selected by
the server; at present, this is indicated by the presence of the the server; at present, this is indicated by the presence of the
"key_share" in the ServerHello. "key_share" in the ServerHello.
4.2.10. Early Data Indication 4.2.10. Early Data Indication
When a PSK is used and early data is allowed for that PSK (see for When a PSK is used and early data is allowed for that PSK (for
instance Appendix B.3.4), the client can send Application Data in its instance, see Appendix B.3.4), the client can send Application Data
first flight of messages. If the client opts to do so, it MUST in its first flight of messages. If the client opts to do so, it
supply both the "pre_shared_key" and "early_data" extensions. MUST supply both the "pre_shared_key" and "early_data" extensions.
The "extension_data" field of this extension contains an The "extension_data" field of this extension contains an
"EarlyDataIndication" value. "EarlyDataIndication" value.
struct {} Empty; struct {} Empty;
struct { struct {
select (Handshake.msg_type) { select (Handshake.msg_type) {
case new_session_ticket: uint32 max_early_data_size; case new_session_ticket: uint32 max_early_data_size;
case client_hello: Empty; case client_hello: Empty;
skipping to change at page 50, line 20 skipping to change at line 2275
the associated values are those which were negotiated in the the associated values are those which were negotiated in the
connection which established the PSK. The PSK used to encrypt the connection which established the PSK. The PSK used to encrypt the
early data MUST be the first PSK listed in the client's early data MUST be the first PSK listed in the client's
"pre_shared_key" extension. "pre_shared_key" extension.
For PSKs provisioned via NewSessionTicket, a server MUST validate For PSKs provisioned via NewSessionTicket, a server MUST validate
that the ticket age for the selected PSK identity (computed by that the ticket age for the selected PSK identity (computed by
subtracting ticket_age_add from PskIdentity.obfuscated_ticket_age subtracting ticket_age_add from PskIdentity.obfuscated_ticket_age
modulo 2^32) is within a small tolerance of the time since the ticket modulo 2^32) is within a small tolerance of the time since the ticket
was issued (see Section 8). If it is not, the server SHOULD proceed was issued (see Section 8). If it is not, the server SHOULD proceed
with the handshake but reject 0-RTT, and SHOULD NOT take any other with the handshake but reject 0-RTT and SHOULD NOT take any other
action that assumes that this ClientHello is fresh. action that assumes that this ClientHello is fresh.
0-RTT messages sent in the first flight have the same (encrypted) 0-RTT messages sent in the first flight have the same (encrypted)
content types as messages of the same type sent in other flights content types as messages of the same type sent in other flights
(handshake and application_data) but are protected under different (handshake and application_data) but are protected under different
keys. After receiving the server's Finished message, if the server keys. After receiving the server's Finished message, if the server
has accepted early data, an EndOfEarlyData message will be sent to has accepted early data, an EndOfEarlyData message will be sent to
indicate the key change. This message will be encrypted with the indicate the key change. This message will be encrypted with the
0-RTT traffic keys. 0-RTT traffic keys.
skipping to change at page 53, line 41 skipping to change at line 2428
In TLS versions prior to TLS 1.3, the Server Name Indication (SNI) In TLS versions prior to TLS 1.3, the Server Name Indication (SNI)
value was intended to be associated with the session (Section 3 of value was intended to be associated with the session (Section 3 of
[RFC6066]), with the server being required to enforce that the SNI [RFC6066]), with the server being required to enforce that the SNI
value associated with the session matches the one specified in the value associated with the session matches the one specified in the
resumption handshake. However, in reality the implementations were resumption handshake. However, in reality the implementations were
not consistent on which of two supplied SNI values they would use, not consistent on which of two supplied SNI values they would use,
leading to the consistency requirement being de facto enforced by the leading to the consistency requirement being de facto enforced by the
clients. In TLS 1.3, the SNI value is always explicitly specified in clients. In TLS 1.3, the SNI value is always explicitly specified in
the resumption handshake, and there is no need for the server to the resumption handshake, and there is no need for the server to
associate an SNI value with the ticket. Clients, however, SHOULD associate an SNI value with the ticket. However, clients SHOULD
store the SNI with the PSK to fulfill the requirements of store the SNI with the PSK to fulfill the requirements of
Section 4.6.1. Section 4.6.1.
Implementor's note: When session resumption is the primary use case Implementor's note: When session resumption is the primary use case
of PSKs, the most straightforward way to implement the PSK/cipher of PSKs, the most straightforward way to implement the PSK / cipher
suite matching requirements is to negotiate the cipher suite first suite matching requirements is to negotiate the cipher suite first
and then exclude any incompatible PSKs. Any unknown PSKs (e.g., ones and then exclude any incompatible PSKs. Any unknown PSKs (e.g., ones
not in the PSK database or encrypted with an unknown key) SHOULD not in the PSK database or encrypted with an unknown key) SHOULD
simply be ignored. If no acceptable PSKs are found, the server simply be ignored. If no acceptable PSKs are found, the server
SHOULD perform a non-PSK handshake if possible. If backward SHOULD perform a non-PSK handshake if possible. If backward
compatibility is important, client-provided, externally established compatibility is important, client-provided, externally established
PSKs SHOULD influence cipher suite selection. PSKs SHOULD influence cipher suite selection.
Prior to accepting PSK key establishment, the server MUST validate Prior to accepting PSK key establishment, the server MUST validate
the corresponding binder value (see Section 4.2.11.2 below). If this the corresponding binder value (see Section 4.2.11.2 below). If this
value is not present or does not validate, the server MUST abort the value is not present or does not validate, the server MUST abort the
handshake. Servers SHOULD NOT attempt to validate multiple binders; handshake. Servers SHOULD NOT attempt to validate multiple binders;
rather, they SHOULD select a single PSK and validate solely the rather, they SHOULD select a single PSK and solely validate the
binder that corresponds to that PSK. See Section 8.2 and binder that corresponds to that PSK. See Section 8.2 and
Appendix F.6 for the security rationale for this requirement. To Appendix F.6 for the security rationale for this requirement. To
accept PSK key establishment, the server sends a "pre_shared_key" accept PSK key establishment, the server sends a "pre_shared_key"
extension indicating the selected identity. extension indicating the selected identity.
Clients MUST verify that the server's selected_identity is within the Clients MUST verify that the server's selected_identity is within the
range supplied by the client, that the server selected a cipher suite range supplied by the client, that the server selected a cipher suite
indicating a Hash associated with the PSK, and that a server indicating a Hash associated with the PSK, and that a server
"key_share" extension is present if required by the ClientHello "key_share" extension is present if required by the ClientHello
"psk_key_exchange_modes" extension. If these values are not "psk_key_exchange_modes" extension. If these values are not
skipping to change at page 55, line 37 skipping to change at line 2513
derived via the key schedule from the corresponding PSK which is derived via the key schedule from the corresponding PSK which is
being offered (see Section 7.1). being offered (see Section 7.1).
If the handshake includes a HelloRetryRequest, the initial If the handshake includes a HelloRetryRequest, the initial
ClientHello and HelloRetryRequest are included in the transcript ClientHello and HelloRetryRequest are included in the transcript
along with the new ClientHello. For instance, if the client sends along with the new ClientHello. For instance, if the client sends
ClientHello1, its binder will be computed over: ClientHello1, its binder will be computed over:
Transcript-Hash(Truncate(ClientHello1)) Transcript-Hash(Truncate(ClientHello1))
Where Truncate() removes the binders list from the ClientHello. Note where Truncate() removes the binders list from the ClientHello. Note
that this hash will be computed using the hash associated with the that this hash will be computed using the hash associated with the
PSK, as the client does not know which cipher suite the server will PSK, as the client does not know which cipher suite the server will
select. select.
If the server responds with a HelloRetryRequest and the client then If the server responds with a HelloRetryRequest and the client then
sends ClientHello2, its binder will be computed over: sends ClientHello2, its binder will be computed over:
Transcript-Hash(ClientHello1, Transcript-Hash(ClientHello1,
HelloRetryRequest, HelloRetryRequest,
Truncate(ClientHello2)) Truncate(ClientHello2))
skipping to change at page 56, line 43 skipping to change at line 2567
The EncryptedExtensions message contains extensions that can be The EncryptedExtensions message contains extensions that can be
protected, i.e., any which are not needed to establish the protected, i.e., any which are not needed to establish the
cryptographic context but which are not associated with individual cryptographic context but which are not associated with individual
certificates. The client MUST check EncryptedExtensions for the certificates. The client MUST check EncryptedExtensions for the
presence of any forbidden extensions and if any are found MUST abort presence of any forbidden extensions and if any are found MUST abort
the handshake with an "illegal_parameter" alert. the handshake with an "illegal_parameter" alert.
Structure of this message: Structure of this message:
struct { struct {
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} EncryptedExtensions; } EncryptedExtensions;
extensions: A list of extensions. For more information, see the extensions: A list of extensions. For more information, see the
table in Section 4.2. table in Section 4.2.
4.3.2. Certificate Request 4.3.2. Certificate Request
A server which is authenticating with a certificate MAY optionally A server which is authenticating with a certificate MAY optionally
request a certificate from the client. This message, if sent, MUST request a certificate from the client. If sent, this message MUST
follow EncryptedExtensions. follow EncryptedExtensions.
Structure of this message: Structure of this message:
struct { struct {
opaque certificate_request_context<0..2^8-1>; opaque certificate_request_context<0..2^8-1>;
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} CertificateRequest; } CertificateRequest;
certificate_request_context: An opaque string which identifies the certificate_request_context: An opaque string which identifies the
certificate request and which will be echoed in the client's certificate request and which will be echoed in the client's
Certificate message. The certificate_request_context MUST be Certificate message. The certificate_request_context MUST be
unique within the scope of this connection (thus preventing replay unique within the scope of this connection (thus preventing replay
of client CertificateVerify messages). This field SHALL be zero of client CertificateVerify messages). This field SHALL be zero
length unless used for the post-handshake authentication exchanges length unless used for the post-handshake authentication exchanges
described in Section 4.6.2. When requesting post-handshake described in Section 4.6.2. When requesting post-handshake
authentication, the server SHOULD make the context unpredictable authentication, the server SHOULD make the context unpredictable
to the client (e.g., by randomly generating it) to prevent an to the client (e.g., by randomly generating it) to prevent an
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
only sent under certain circumstances, as defined below. The only sent under certain circumstances, as defined below. The
Finished message is always sent as part of the Authentication Block. Finished message is always sent as part of the Authentication Block.
These messages are encrypted under keys derived from the These messages are encrypted under keys derived from the
[sender]_handshake_traffic_secret, except for post-handshake [sender]_handshake_traffic_secret, except for post-handshake
authentication. authentication.
The computations for the Authentication messages all uniformly take The computations for the Authentication messages all uniformly take
the following inputs: the following inputs:
* 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 59, line 30 skipping to change at line 2689
| |CertificateRequest | | | |CertificateRequest | |
+---------+--------------------+-------------------------------------+ +---------+--------------------+-------------------------------------+
Table 2: Authentication Inputs Table 2: Authentication Inputs
4.4.1. The Transcript Hash 4.4.1. The Transcript Hash
Many of the cryptographic computations in TLS make use of a Many of the cryptographic computations in TLS make use of a
transcript hash. This value is computed by hashing the concatenation transcript hash. This value is computed by hashing the concatenation
of each included handshake message, including the handshake message of each included handshake message, including the handshake message
header carrying the handshake message type and length fields, but not header carrying the handshake message type and length fields but not
including record layer headers. I.e., including record layer headers. That is,
Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn) Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn)
As an exception to this general rule, when the server responds to a As an exception to this general rule, when the server responds to a
ClientHello with a HelloRetryRequest, the value of ClientHello1 is ClientHello with a HelloRetryRequest, the value of ClientHello1 is
replaced with a special synthetic handshake message of handshake type replaced with a special synthetic handshake message of handshake type
"message_hash" containing Hash(ClientHello1). I.e., "message_hash" containing Hash(ClientHello1). That is,
Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) = Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) =
Hash(message_hash || /* Handshake type */ Hash(message_hash || /* Handshake type */
00 00 Hash.length || /* Handshake message length (bytes) */ 00 00 Hash.length || /* Handshake message length (bytes) */
Hash(ClientHello1) || /* Hash of ClientHello1 */ Hash(ClientHello1) || /* Hash of ClientHello1 */
HelloRetryRequest || ... || Mn) HelloRetryRequest || ... || Mn)
The reason for this construction is to allow the server to do a The reason for this construction is to allow the server to do a
stateless HelloRetryRequest by storing just the hash of ClientHello1 stateless HelloRetryRequest by storing just the hash of ClientHello1
in the cookie, rather than requiring it to export the entire in the cookie, rather than requiring it to export the entire
skipping to change at page 60, line 14 skipping to change at line 2719
For concreteness, the transcript hash is always taken from the For concreteness, the transcript hash is always taken from the
following sequence of handshake messages, starting at the first following sequence of handshake messages, starting at the first
ClientHello and including only those messages that were sent: ClientHello and including only those messages that were sent:
ClientHello, HelloRetryRequest, ClientHello, ServerHello, ClientHello, HelloRetryRequest, ClientHello, ServerHello,
EncryptedExtensions, server CertificateRequest, server Certificate, EncryptedExtensions, server CertificateRequest, server Certificate,
server CertificateVerify, server Finished, EndOfEarlyData, client server CertificateVerify, server Finished, EndOfEarlyData, client
Certificate, client CertificateVerify, and client Finished. Certificate, client CertificateVerify, and client Finished.
In general, implementations can implement the transcript by keeping a In general, implementations can implement the transcript by keeping a
running transcript hash value based on the negotiated hash. Note, running transcript hash value based on the negotiated hash. However,
however, that subsequent post-handshake authentications do not note that subsequent post-handshake authentications do not include
include each other, just the messages through the end of the main each other, just the messages through the end of the main handshake.
handshake.
4.4.2. Certificate 4.4.2. Certificate
This message conveys the endpoint's certificate chain to the peer. This message conveys the endpoint's certificate chain to the peer.
The server MUST send a Certificate message whenever the agreed-upon The server MUST send a Certificate message whenever the agreed-upon
key exchange method uses certificates for authentication (this key exchange method uses certificates for authentication (this
includes all key exchange methods defined in this document except includes all key exchange methods defined in this document except
PSK). PSK).
skipping to change at page 61, line 5 skipping to change at line 2743
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 11 skipping to change at line 2889
The following rule additionally applies to certificates sent by the The following rule additionally applies to certificates sent by the
server: server:
* The "server_name" [RFC6066] extension is used to guide certificate * The "server_name" [RFC6066] extension is used to guide certificate
selection. As servers MAY require the presence of the selection. As servers MAY require the presence of the
"server_name" extension, clients SHOULD send this extension when "server_name" extension, clients SHOULD send this extension when
the server is identified by name. the server is identified by name.
All certificates provided by the sender MUST be signed by a signature All certificates provided by the sender MUST be signed by a signature
algorithm advertised by the peer, if it is able to provide such a algorithm advertised by the peer if it is able to provide such a
chain (see Section 4.2.3). Certificates that are self-signed or chain (see Section 4.2.3). Certificates that are self-signed or
certificates that are expected to be trust anchors are not validated certificates that are expected to be trust anchors are not validated
as part of the chain and therefore MAY be signed with any algorithm. as part of the chain and therefore MAY be signed with any algorithm.
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 65, line 7 skipping to change at line 2926
In general, detailed certificate validation procedures are out of In general, detailed certificate validation procedures are out of
scope for TLS (see [RFC5280]). This section provides TLS-specific scope for TLS (see [RFC5280]). This section provides TLS-specific
requirements. requirements.
If the server supplies an empty Certificate message, the client MUST If the server supplies an empty Certificate message, the client MUST
abort the handshake with a "decode_error" alert. abort the handshake with a "decode_error" alert.
If the client does not send any certificates (i.e., it sends an empty If the client does not send any certificates (i.e., it sends an empty
Certificate message), the server MAY at its discretion either Certificate message), the server MAY at its discretion either
continue the handshake without client authentication, or abort the continue the handshake without client authentication or abort the
handshake with a "certificate_required" alert. Also, if some aspect handshake with a "certificate_required" alert. Also, if some aspect
of the certificate chain was unacceptable (e.g., it was not signed by of the certificate chain was unacceptable (e.g., it was not signed by
a known, trusted CA), the server MAY at its discretion either a known, trusted CA), the server MAY at its discretion either
continue the handshake (considering the client unauthenticated) or continue the handshake (considering the client unauthenticated) or
abort the handshake. abort the handshake.
Any endpoint receiving any certificate which it would need to Any endpoint receiving any certificate which it would need to
validate using any signature algorithm using an MD5 hash MUST abort validate using any signature algorithm using an MD5 hash MUST abort
the handshake with a "bad_certificate" alert. SHA-1 is deprecated the handshake with a "bad_certificate" alert. SHA-1 is deprecated
and it is RECOMMENDED that any endpoint receiving any certificate and it is RECOMMENDED that any endpoint receiving any certificate
skipping to change at page 65, line 45 skipping to change at line 2964
CertificateVerify message also provides integrity for the handshake CertificateVerify message also provides integrity for the handshake
up to this point. Servers MUST send this message when authenticating up to this point. Servers MUST send this message when authenticating
via a certificate. Clients MUST send this message whenever via a certificate. Clients MUST send this message whenever
authenticating via a certificate (i.e., when the Certificate message authenticating via a certificate (i.e., when the Certificate message
is non-empty). When sent, this message MUST appear immediately after is non-empty). When sent, this message MUST appear immediately after
the Certificate message and immediately prior to the Finished the Certificate message and immediately prior to the Finished
message. message.
Structure of this message: Structure of this message:
struct { struct {
SignatureScheme algorithm; SignatureScheme algorithm;
opaque signature<0..2^16-1>; opaque signature<0..2^16-1>;
} CertificateVerify; } CertificateVerify;
The algorithm field specifies the signature algorithm used (see The algorithm field specifies the signature algorithm used (see
Section 4.2.3 for the definition of this type). The signature is a Section 4.2.3 for the definition of this type). The signature is a
digital signature using that algorithm. The content that is covered digital signature using that algorithm. The content that is covered
under the signature is the hash output as described in Section 4.4.1, under the signature is the hash output as described in Section 4.4.1,
namely: namely:
Transcript-Hash(Handshake Context, Certificate) Transcript-Hash(Handshake Context, Certificate)
The digital signature is then computed over the concatenation of: The digital signature is then computed over the concatenation of:
skipping to change at page 66, line 30 skipping to change at line 2994
* 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 21 skipping to change at line 3083
The key used to compute the Finished message is computed from the The key used to compute the Finished message is computed from the
Base Key defined in Section 4.4 using HKDF (see Section 7.1). Base Key defined in Section 4.4 using HKDF (see Section 7.1).
Specifically: Specifically:
finished_key = finished_key =
HKDF-Expand-Label(BaseKey, "finished", "", Hash.length) HKDF-Expand-Label(BaseKey, "finished", "", Hash.length)
Structure of this message: Structure of this message:
struct { struct {
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 3137
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
immediately after each other or after specific events (see immediately after each other or after specific events (see
Appendix C.4). For instance, the server might send a new ticket Appendix C.4). For instance, the server might send a new ticket
after post-handshake authentication thus encapsulating the additional after post-handshake authentication, thus encapsulating the
client authentication state. Multiple tickets are useful for clients additional client authentication state. Multiple tickets are useful
for a variety of purposes, including: for clients for a variety of purposes, including:
* Opening multiple parallel HTTP connections. * Opening multiple parallel HTTP connections.
* Performing connection racing across interfaces and address * Performing connection racing across interfaces and address
families via (for example) Happy Eyeballs [RFC8305] or related families via, for example, Happy Eyeballs [RFC8305] or related
techniques. techniques.
Any ticket MUST only be resumed with a cipher suite that has the same Any ticket MUST only be resumed with a cipher suite that has the same
KDF hash algorithm as that used to establish the original connection. KDF hash algorithm as that used to establish the original connection.
Clients MUST only resume if the new SNI value is valid for the server Clients MUST only resume if the new SNI value is valid for the server
certificate presented in the original session, and SHOULD only resume certificate presented in the original session, and SHOULD only resume
if the SNI value matches the one used in the original session. The if the SNI value matches the one used in the original session. The
latter is a performance optimization: normally, there is no reason to latter is a performance optimization: normally, there is no reason to
expect that different servers covered by a single certificate would expect that different servers covered by a single certificate would
skipping to change at page 72, line 32 skipping to change at line 3283
Note: Because certificate-based client authentication could involve Note: Because certificate-based client authentication could involve
prompting the user, servers MUST be prepared for some delay, prompting the user, servers MUST be prepared for some delay,
including receiving an arbitrary number of other messages between including receiving an arbitrary number of other messages between
sending the CertificateRequest and receiving a response. In sending the CertificateRequest and receiving a response. In
addition, clients which receive multiple CertificateRequests in close addition, clients which receive multiple CertificateRequests in close
succession MAY respond to them in a different order than they were succession MAY respond to them in a different order than they were
received (the certificate_request_context value allows the server to received (the certificate_request_context value allows the server to
disambiguate the responses). disambiguate the responses).
4.6.3. Key and Initialization Vector Update 4.6.3. Key and Initialization Vector (IV) Update
The KeyUpdate handshake message is used to indicate that the sender The KeyUpdate handshake message is used to indicate that the sender
is updating its sending cryptographic keys. This message can be sent is updating its sending cryptographic keys. This message can be sent
by either peer after it has sent a Finished message. Implementations by either peer after it has sent a Finished message. Implementations
that receive a KeyUpdate message prior to receiving a Finished that receive a KeyUpdate message prior to receiving a Finished
message MUST terminate the connection with an "unexpected_message" message MUST terminate the connection with an "unexpected_message"
alert. After sending a KeyUpdate message, the sender SHALL send all alert. After sending a KeyUpdate message, the sender SHALL send all
its traffic using the next generation of keys, computed as described its traffic using the next generation of keys, computed as described
in Section 7.2. Upon receiving a KeyUpdate, the receiver MUST update in Section 7.2. Upon receiving a KeyUpdate, the receiver MUST update
its receiving keys. its receiving keys.
skipping to change at page 73, line 44 skipping to change at line 3344
with the old key is received before accepting any messages encrypted with the old key is received before accepting any messages encrypted
with the new key. Failure to do so may allow message truncation with the new key. Failure to do so may allow message truncation
attacks. attacks.
With a 128-bit key as in AES-128, rekeying 2^64 times has a high With a 128-bit key as in AES-128, rekeying 2^64 times has a high
probability of key reuse within a given connection. Note that even probability of key reuse within a given connection. Note that even
if the key repeats, the IV is also independently generated, so the if the key repeats, the IV is also independently generated, so the
chance of a joint key/IV collision is much lower. To provide an 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 74, line 38 skipping to change at line 3386
handshake with an "unexpected_message" alert. If an implementation handshake with an "unexpected_message" alert. If an implementation
detects a change_cipher_spec record received before the first detects a change_cipher_spec record received before the first
ClientHello message or after the peer's Finished message, it MUST be ClientHello message or after the peer's Finished message, it MUST be
treated as an unexpected record type (though stateless servers may treated as an unexpected record type (though stateless servers may
not be able to distinguish these cases from allowed cases). not be able to distinguish these cases from allowed cases).
Implementations MUST NOT send record types not defined in this Implementations MUST NOT send record types not defined in this
document unless negotiated by some extension. If a TLS document unless negotiated by some extension. If a TLS
implementation receives an unexpected record type, it MUST terminate implementation receives an unexpected record type, it MUST terminate
the connection with an "unexpected_message" alert. New record the connection with an "unexpected_message" alert. New record
content type values are assigned by IANA in the TLS ContentType content type values are assigned by IANA in the "TLS ContentType"
registry as described in Section 11. registry as described in Section 11.
5.1. Record Layer 5.1. Record Layer
The record layer fragments information blocks into TLSPlaintext The record layer fragments information blocks into TLSPlaintext
records carrying data in chunks of 2^14 bytes or less. Message records carrying data in chunks of 2^14 bytes or less. Message
boundaries are handled differently depending on the underlying boundaries are handled differently depending on the underlying
ContentType. Any future content types MUST specify appropriate ContentType. Any future content types MUST specify appropriate
rules. Note that these rules are stricter than what was enforced in rules. Note that these rules are stricter than what was enforced in
TLS 1.2. TLS 1.2.
skipping to change at page 78, line 14 skipping to change at line 3550
encrypted_record: The AEAD-encrypted form of the serialized encrypted_record: The AEAD-encrypted form of the serialized
TLSInnerPlaintext structure. TLSInnerPlaintext structure.
AEAD algorithms take as input a single key, a nonce, a plaintext, and AEAD algorithms take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as "additional data" to be included in the authentication check, as
described in Section 2.1 of [RFC5116]. The key is either the described in Section 2.1 of [RFC5116]. The key is either the
client_write_key or the server_write_key, the nonce is derived from client_write_key or the server_write_key, the nonce is derived from
the sequence number and the client_write_iv or server_write_iv (see the sequence number and the client_write_iv or server_write_iv (see
Section 5.3), and the additional data input is the record header. Section 5.3), and the additional data input is the record header.
I.e., That is,
additional_data = TLSCiphertext.opaque_type || additional_data = TLSCiphertext.opaque_type ||
TLSCiphertext.legacy_record_version || TLSCiphertext.legacy_record_version ||
TLSCiphertext.length TLSCiphertext.length
The plaintext input to the AEAD algorithm is the encoded The plaintext input to the AEAD algorithm is the encoded
TLSInnerPlaintext structure. Derivation of traffic keys is defined TLSInnerPlaintext structure. Derivation of traffic keys is defined
in Section 7.3. in Section 7.3.
The AEAD output consists of the ciphertext output from the AEAD The AEAD output consists of the ciphertext output from the AEAD
skipping to change at page 78, line 43 skipping to change at line 3579
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.
5.3. Per-Record Nonce 5.3. Per-Record Nonce
A 64-bit sequence number is maintained separately for reading and A 64-bit sequence number is maintained separately for reading and
writing records. The appropriate sequence number is incremented by writing records. The appropriate sequence number is incremented by
one after reading or writing each record. Each sequence number is one after reading or writing each record. Each sequence number is
set to zero at the beginning of a connection and whenever the key is set to zero at the beginning of a connection and whenever the key is
changed; the first record transmitted under a particular traffic key changed; the first record transmitted under a particular traffic key
MUST use sequence number 0. MUST use sequence number 0.
Because the size of sequence numbers is 64-bit, they should not wrap. Because the size of sequence numbers is 64 bits, they should not
If a TLS implementation would need to wrap a sequence number, it MUST wrap. If a TLS implementation would need to wrap a sequence number,
either rekey (Section 4.6.3) or terminate the connection. it MUST either rekey (Section 4.6.3) or terminate the connection.
Each AEAD algorithm will specify a range of possible lengths for the Each AEAD algorithm will specify a range of possible lengths for the
per-record nonce, from N_MIN bytes to N_MAX bytes of input [RFC5116]. per-record nonce, from N_MIN bytes to N_MAX bytes of input [RFC5116].
The length of the TLS per-record nonce (iv_length) is set to the The length of the TLS per-record nonce (iv_length) is set to the
larger of 8 bytes and N_MIN for the AEAD algorithm (see [RFC5116], larger of 8 bytes and N_MIN for the AEAD algorithm (see [RFC5116],
Section 4). An AEAD algorithm where N_MAX is less than 8 bytes MUST Section 4). An AEAD algorithm where N_MAX is less than 8 bytes MUST
NOT be used with TLS. The per-record nonce for the AEAD construction NOT be used with TLS. The per-record nonce for the AEAD construction
is formed as follows: is formed as follows:
1. The 64-bit record sequence number is encoded in network byte 1. The 64-bit record sequence number is encoded in network byte
skipping to change at page 80, line 37 skipping to change at line 3663
size limits) without introducing new content types. The design also size limits) without introducing new content types. The design also
enforces all-zero padding octets, which allows for quick detection of enforces all-zero padding octets, which allows for quick detection of
padding errors. padding errors.
Implementations MUST limit their scanning to the cleartext returned Implementations MUST limit their scanning to the cleartext returned
from the AEAD decryption. If a receiving implementation does not from the AEAD decryption. If a receiving implementation does not
find a non-zero octet in the cleartext, it MUST terminate the find a non-zero octet in the cleartext, it MUST terminate the
connection with an "unexpected_message" alert. connection with an "unexpected_message" alert.
The presence of padding does not change the overall record size The presence of padding does not change the overall record size
limitations: the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 limitations: The full encoded TLSInnerPlaintext MUST NOT exceed 2^14
+ 1 octets. If the maximum fragment length is reduced -- as for + 1 octets. If the maximum fragment length is reduced -- as for
example by the record_size_limit extension from [RFC8449] -- then the example by the record_size_limit extension from [RFC8449] -- then the
reduced limit applies to the full plaintext, including the content reduced limit applies to the full plaintext, including the content
type and padding. type and padding.
Selecting a padding policy that suggests when and how much to pad is Selecting a padding policy that suggests when and how much to pad is
a complex topic and is beyond the scope of this specification. If a complex topic and is beyond the scope of this specification. If
the application-layer protocol on top of TLS has its own padding, it the application-layer protocol on top of TLS has its own padding, it
may be preferable to pad Application Data TLS records within the may be preferable to pad Application Data TLS records within the
application layer. Padding for encrypted Handshake or Alert records application layer. However, padding for encrypted Handshake or Alert
must still be handled at the TLS layer, though. Later documents may records must still be handled at the TLS layer. Later documents may
define padding selection algorithms or define a padding policy define padding selection algorithms or define a padding policy
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 3813
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 84, line 23 skipping to change at line 3840
Error handling in TLS is very simple. When an error is detected, the Error handling in TLS is very simple. When an error is detected, the
detecting party sends a message to its peer. Upon transmission or detecting party sends a message to its peer. Upon transmission or
receipt of a fatal alert message, both parties MUST immediately close receipt of a fatal alert message, both parties MUST immediately close
the connection. the connection.
Whenever an implementation encounters a fatal error condition, it Whenever an implementation encounters a fatal error condition, it
SHOULD send an appropriate fatal alert and MUST close the connection SHOULD send an appropriate fatal alert and MUST close the connection
without sending or receiving any additional data. Throughout this without sending or receiving any additional data. Throughout this
specification, when the phrases "terminate the connection" and "abort specification, when the phrases "terminate the connection" and "abort
the handshake" are used without a specific alert it means that the the handshake" are used without a specific alert, it means that the
implementation SHOULD send the alert indicated by the descriptions implementation SHOULD send the alert indicated by the descriptions
below. The phrases "terminate the connection with an X alert" and below. The phrases "terminate the connection with an X alert" and
"abort the handshake with an X alert" mean that the implementation "abort the handshake with an X alert" mean that the implementation
MUST send alert X if it sends any alert. All alerts defined below in MUST send alert X if it sends any alert. All alerts defined below in
this section, as well as all unknown alerts, are universally this section, as well as all unknown alerts, are universally
considered fatal as of TLS 1.3 (see Section 6). The implementation considered fatal as of TLS 1.3 (see Section 6). The implementation
SHOULD provide a way to facilitate logging the sending and receiving SHOULD provide a way to facilitate logging the sending and receiving
of alerts. of alerts.
The following error alerts are defined: The following error alerts are defined:
skipping to change at page 86, line 51 skipping to change at line 3959
certificate_required: Sent by servers when a client certificate is certificate_required: Sent by servers when a client certificate is
desired but none was provided by the client. desired but none was provided by the client.
general_error: Sent to indicate an error condition in cases when general_error: Sent to indicate an error condition in cases when
either no more specific error is available or the senders wishes either no more specific error is available or the senders wishes
to conceal the specific error code. Implementations SHOULD use to conceal the specific error code. Implementations SHOULD use
more specific errors when available. more specific errors when available.
no_application_protocol: Sent by servers when a client no_application_protocol: Sent by servers when a client
"application_layer_protocol_negotiation" extension advertises only "application_layer_protocol_negotiation" extension only advertises
protocols that the server does not support (see [RFC7301]). protocols that the server does not support (see [RFC7301]).
New Alert values are assigned by IANA as described in Section 11. New Alert values are assigned by IANA as described in Section 11.
7. Cryptographic Computations 7. Cryptographic Computations
The TLS handshake establishes one or more input secrets which are The TLS handshake establishes one or more input secrets which are
combined to create the actual working keying material, as detailed combined to create the actual working keying material, as detailed
below. The key derivation process incorporates both the input below. The key derivation process incorporates both the input
secrets and the handshake transcript. Note that because the secrets and the handshake transcript. Note that because the
skipping to change at page 87, line 27 skipping to change at line 3984
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)
The Hash function used by Transcript-Hash and HKDF is the cipher The Hash function used by Transcript-Hash and HKDF is the cipher
suite hash algorithm. Hash.length is its output length in bytes. suite hash algorithm. Hash.length is its output length in bytes.
Messages is the concatenation of the indicated handshake messages, Messages is the concatenation of the indicated handshake messages,
including the handshake message type and length fields, but not including the handshake message type and length fields but not
including record layer headers. Note that in some cases a zero- including record layer headers. Note that in some cases a zero-
length Context (indicated by "") is passed to HKDF-Expand-Label. The length Context (indicated by "") is passed to HKDF-Expand-Label. The
labels specified in this document are all ASCII strings and do not labels specified in this document are all ASCII strings and do not
include a trailing NUL byte. include a trailing NUL byte.
Any extensions to TLS which use "HKDF-Expand-Label" use the HkdfLabel Any extensions to TLS which use "HKDF-Expand-Label" use the HkdfLabel
definition associated with the version of TLS with which they are definition associated with the version of TLS with which they are
being used. When used with this specification, that means using being used. When used with this specification, that means using
HkdfLabel as defined above; when used with DTLS [RFC9147] that means HkdfLabel as defined above; when used with DTLS [RFC9147] that means
using the version defined in [RFC9147], Section 5.9. using the version defined in [RFC9147], Section 5.9.
skipping to change at page 88, line 21 skipping to change at line 4027
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 4165
* 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 93, line 5 skipping to change at line 4252
TLS pseudorandom function (PRF). This document replaces the PRF with TLS pseudorandom function (PRF). This document replaces the PRF with
HKDF, thus requiring a new construction. The exporter interface HKDF, thus requiring a new construction. The exporter interface
remains the same. remains the same.
The exporter value is computed as: The exporter value is computed as:
TLS-Exporter(label, context_value, key_length) = TLS-Exporter(label, context_value, key_length) =
HKDF-Expand-Label(Derive-Secret(Secret, label, ""), HKDF-Expand-Label(Derive-Secret(Secret, label, ""),
"exporter", Hash(context_value), key_length) "exporter", Hash(context_value), key_length)
Where Secret is either the early_exporter_secret or the where Secret is either the early_exporter_secret or the
exporter_secret. Implementations MUST use the exporter_secret unless exporter_secret. Implementations MUST use the exporter_secret unless
explicitly specified by the application. The early_exporter_secret explicitly specified by the application. The early_exporter_secret
is defined for use in settings where an exporter is needed for 0-RTT is defined for use in settings where an exporter is needed for 0-RTT
data. A separate interface for the early exporter is RECOMMENDED; data. A separate interface for the early exporter is RECOMMENDED;
this avoids the exporter user accidentally using an early exporter this avoids the exporter user accidentally using an early exporter
when a regular one is desired or vice versa. when a regular one is desired or vice versa.
If no context is provided, the context_value is zero length. If no context is provided, the context_value is zero length.
Consequently, providing no context computes the same value as Consequently, providing no context computes the same value as
providing an empty context. This is a change from previous versions providing an empty context. This is a change from previous versions
skipping to change at page 93, line 46 skipping to change at line 4293
* Network attackers who take advantage of client retry behavior to * Network attackers who take advantage of client retry behavior to
arrange for the server to receive multiple copies of an arrange for the server to receive multiple copies of an
application message. This threat already exists to some extent application message. This threat already exists to some extent
because clients that value robustness respond to network errors by because clients that value robustness respond to network errors by
attempting to retry requests. However, 0-RTT adds an additional attempting to retry requests. However, 0-RTT adds an additional
dimension for any server system which does not maintain globally dimension for any server system which does not maintain globally
consistent server state. Specifically, if a server system has consistent server state. Specifically, if a server system has
multiple zones where tickets from zone A will not be accepted in multiple zones where tickets from zone A will not be accepted in
zone B, then an attacker can duplicate a ClientHello and early zone B, then an attacker can duplicate a ClientHello and early
data intended for A to both A and B. At A, the data will be data intended for A to both A and B. At A, the data will be
accepted in 0-RTT, but at B the server will reject 0-RTT data and accepted in 0-RTT, but at B, the server will reject 0-RTT data and
instead force a full handshake. If the attacker blocks the instead force a full handshake. If the attacker blocks the
ServerHello from A, then the client will complete the handshake ServerHello from A, then the client will complete the handshake
with B and probably retry the request, leading to duplication on with B and probably retry the request, leading to duplication on
the server system as a whole. the server system as a whole.
The first class of attack can be prevented by sharing state to The first class of attack can be prevented by sharing state to
guarantee that the 0-RTT data is accepted at most once. Servers guarantee that the 0-RTT data is accepted at most once. Servers
SHOULD provide that level of replay safety by implementing one of the SHOULD provide that level of replay safety by implementing one of the
methods described in this section or by equivalent means. It is methods described in this section or by equivalent means. However,
understood, however, that due to operational concerns not all it is understood that due to operational concerns not all deployments
deployments will maintain state at that level. Therefore, in normal will maintain state at that level. Therefore, in normal operation,
operation, clients will not know which, if any, of these mechanisms clients will not know which, if any, of these mechanisms servers
servers actually implement and hence MUST only send early data which actually implement and hence MUST only send early data which they
they deem safe to be replayed. deem safe to be replayed.
In addition to the direct effects of replays, there is a class of In addition to the direct effects of replays, there is a class of
attacks where even operations normally considered idempotent could be attacks where even operations normally considered idempotent could be
exploited by a large number of replays (timing attacks, resource exploited by a large number of replays (timing attacks, resource
limit exhaustion and others, as described in Appendix F.5). Those limit exhaustion, and others, as described in Appendix F.5). Those
can be mitigated by ensuring that every 0-RTT payload can be replayed can be mitigated by ensuring that every 0-RTT payload can be replayed
only a limited number of times. The server MUST ensure that any only a limited number of times. The server MUST ensure that any
instance of it (be it a machine, a thread, or any other entity within instance of it (be it a machine, a thread, or any other entity within
the relevant serving infrastructure) would accept 0-RTT for the same the relevant serving infrastructure) would accept 0-RTT for the same
0-RTT handshake at most once; this limits the number of replays to 0-RTT handshake at most once; this limits the number of replays to
the number of server instances in the deployment. Such a guarantee the number of server instances in the deployment. Such a guarantee
can be accomplished by locally recording data from recently received can be accomplished by locally recording data from recently received
ClientHellos and rejecting repeats, or by any other method that ClientHellos and rejecting repeats or by any other method that
provides the same or a stronger guarantee. The "at most once per provides the same or a stronger guarantee. The "at most once per
server instance" guarantee is a minimum requirement; servers SHOULD server instance" guarantee is a minimum requirement; servers SHOULD
limit 0-RTT replays further when feasible. limit 0-RTT replays further when feasible.
The second class of attack cannot be prevented at the TLS layer and The second class of attack cannot be prevented at the TLS layer and
MUST be dealt with by any application. Note that any application MUST be dealt with by any application. Note that any application
whose clients implement any kind of retry behavior already needs to whose clients implement any kind of retry behavior already needs to
implement some sort of anti-replay defense. implement some sort of anti-replay defense.
8.1. Single-Use Tickets 8.1. Single-Use Tickets
The simplest form of anti-replay defense is for the server to only The simplest form of anti-replay defense is for the server to only
allow each session ticket to be used once. For instance, the server allow each session ticket to be used once. For instance, the server
can maintain a database of all outstanding valid tickets, deleting can maintain a database of all outstanding valid tickets, deleting
each ticket from the database as it is used. If an unknown ticket is each ticket from the database as it is used. If an unknown ticket is
provided, the server would then fall back to a full handshake. provided, the server would then fall back to a full handshake.
If the tickets are not self-contained but rather are database keys, If the tickets are not self-contained but rather are database keys,
and the corresponding PSKs are deleted upon use, then connections and the corresponding PSKs are deleted upon use, then connections
established using PSKs enjoy not only anti-replay protection, but established using PSKs enjoy not only anti-replay protection but also
also forward secrecy once all copies of the PSK from the database forward secrecy once all copies of the PSK from the database entry
entry have been deleted. This mechanism also improves security for have been deleted. This mechanism also improves security for PSK
PSK usage when PSK is used without (EC)DHE. usage when PSK is used without (EC)DHE.
Because this mechanism requires sharing the session database between Because this mechanism requires sharing the session database between
server nodes in environments with multiple distributed servers, it server nodes in environments with multiple distributed servers, it
may be hard to achieve high rates of successful PSK 0-RTT connections may be hard to achieve high rates of successful PSK 0-RTT connections
when compared to self-encrypted tickets. Unlike session databases, when compared to self-encrypted tickets. Unlike session databases,
session tickets can successfully do PSK-based session establishment session tickets can successfully do PSK-based session establishment
even without consistent storage, though when 0-RTT is allowed they even without consistent storage, though when 0-RTT is allowed they
still require consistent storage for anti-replay of 0-RTT data, as still require consistent storage for anti-replay of 0-RTT data, as
detailed in the following section. detailed in the following section.
skipping to change at page 96, line 10 skipping to change at line 4385
long as the expected_arrival_time is inside the window. Servers MAY long as the expected_arrival_time is inside the window. Servers MAY
also implement data stores with false positives, such as Bloom also implement data stores with false positives, such as Bloom
filters, in which case they MUST respond to apparent replay by filters, in which case they MUST respond to apparent replay by
rejecting 0-RTT but MUST NOT abort the handshake. rejecting 0-RTT but MUST NOT abort the handshake.
The server MUST derive the storage key only from validated sections The server MUST derive the storage key only from validated sections
of the ClientHello. If the ClientHello contains multiple PSK of the ClientHello. If the ClientHello contains multiple PSK
identities, then an attacker can create multiple ClientHellos with identities, then an attacker can create multiple ClientHellos with
different binder values for the less-preferred identity on the different binder values for the less-preferred identity on the
assumption that the server will not verify it (as recommended by assumption that the server will not verify it (as recommended by
Section 4.2.11). I.e., if the client sends PSKs A and B but the Section 4.2.11). That is, if the client sends PSKs A and B but the
server prefers A, then the attacker can change the binder for B server prefers A, then the attacker can change the binder for B
without affecting the binder for A. If the binder for B is part of without affecting the binder for A. If the binder for B is part of
the storage key, then this ClientHello will not appear as a the storage key, then this ClientHello will not appear as a
duplicate, which will cause the ClientHello to be accepted, and may duplicate, which will cause the ClientHello to be accepted, and may
cause side effects such as replay cache pollution, although any 0-RTT cause side effects such as replay cache pollution, although any 0-RTT
data will not be decryptable because it will use different keys. If data will not be decryptable because it will use different keys. If
the validated binder or the ClientHello.random is used as the storage the validated binder or the ClientHello.random is used as the storage
key, then this attack is not possible. key, then this attack is not possible.
Because this mechanism does not require storing all outstanding Because this mechanism does not require storing all outstanding
skipping to change at page 97, line 19 skipping to change at line 4435
likely sent reasonably recently and only accept 0-RTT for such a likely sent reasonably recently and only accept 0-RTT for such a
ClientHello, otherwise falling back to a 1-RTT handshake. This is ClientHello, otherwise falling back to a 1-RTT handshake. This is
necessary for the ClientHello storage mechanism described in necessary for the ClientHello storage mechanism described in
Section 8.2 because otherwise the server needs to store an unlimited Section 8.2 because otherwise the server needs to store an unlimited
number of ClientHellos, and is a useful optimization for self- number of ClientHellos, and is a useful optimization for self-
contained single-use tickets because it allows efficient rejection of contained single-use tickets because it allows efficient rejection of
ClientHellos which cannot be used for 0-RTT. ClientHellos which cannot be used for 0-RTT.
To implement this mechanism, a server needs to store the time that To implement this mechanism, a server needs to store the time that
the server generated the session ticket, offset by an estimate of the the server generated the session ticket, offset by an estimate of the
round-trip time between client and server. I.e., round-trip time between client and server. That is,
adjusted_creation_time = creation_time + estimated_RTT adjusted_creation_time = creation_time + estimated_RTT
This value can be encoded in the ticket, thus avoiding the need to This value can be encoded in the ticket, thus avoiding the need to
keep state for each outstanding ticket. The server can determine the keep state for each outstanding ticket. The server can determine the
client's view of the age of the ticket by subtracting the ticket's client's view of the age of the ticket by subtracting the ticket's
"ticket_age_add" value from the "obfuscated_ticket_age" parameter in "ticket_age_add" value from the "obfuscated_ticket_age" parameter in
the client's "pre_shared_key" extension. The server can determine the client's "pre_shared_key" extension. The server can determine
the expected_arrival_time of the ClientHello as: the expected_arrival_time of the ClientHello as:
expected_arrival_time = adjusted_creation_time + clients_ticket_age expected_arrival_time = adjusted_creation_time + clients_ticket_age
When a new ClientHello is received, the expected_arrival_time is then When a new ClientHello is received, the expected_arrival_time is then
compared against the current server wall clock time and if they compared against the current server wall clock time, and if they
differ by more than a certain amount, 0-RTT is rejected, though the differ by more than a certain amount, 0-RTT is rejected, though the
1-RTT handshake can be allowed to complete. 1-RTT handshake can be allowed to complete.
There are several potential sources of error that might cause There are several potential sources of error that might cause
mismatches between the expected_arrival_time and the measured time. mismatches between the expected_arrival_time and the measured time.
Variations in client and server clock rates are likely to be minimal, Variations in client and server clock rates are likely to be minimal,
though potentially the absolute times may be off by large values. though potentially the absolute times may be off by large values.
Network propagation delays are the most likely causes of a mismatch Network propagation delays are the most likely causes of a mismatch
in legitimate values for elapsed time. Both the NewSessionTicket and in legitimate values for elapsed time. Both the NewSessionTicket and
ClientHello messages might be retransmitted and therefore delayed, ClientHello messages might be retransmitted and therefore delayed,
skipping to change at page 101, line 21 skipping to change at line 4619
might change. might change.
The design of TLS 1.3 was constrained by widely deployed non- The design of TLS 1.3 was constrained by widely deployed non-
compliant TLS middleboxes (see Appendix E.4); however, it does not compliant TLS middleboxes (see Appendix E.4); however, it does not
relax the invariants. Those middleboxes continue to be non- relax the invariants. Those middleboxes continue to be non-
compliant. compliant.
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. Appendices C, E, and 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 as "_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
originally created in [RFC4366]. IANA has updated it to reference originally created in [RFC4366]. IANA has updated it to reference
this document. Changes to the registry follow: this document. Changes to the registry follow:
* IANA has updated the registration policy as follows: * IANA has updated the registration policy as follows:
Values with the first byte in the range 0-254 (decimal) are Values with the first byte in the range 0-254 (decimal) are
assigned via Specification Required [RFC8126]. Values with the assigned via Specification Required [RFC8126]. Values with the
first byte 255 (decimal) are reserved for Private Use [RFC8126]. first byte 255 (decimal) are reserved for Private Use [RFC8126].
* IANA has updated this registry to include the "key_share", * IANA has updated this registry to include the "key_share",
"pre_shared_key", "psk_key_exchange_modes", "early_data", "pre_shared_key", "psk_key_exchange_modes", "early_data",
"cookie", "supported_versions", "certificate_authorities", "cookie", "supported_versions", "certificate_authorities",
"oid_filters", "post_handshake_auth", and "oid_filters", "post_handshake_auth", and
"signature_algorithms_cert" extensions with the values defined in "signature_algorithms_cert" extensions with the values defined in
this document and the "Recommended" value of "Y". this document and the "Recommended" value of "Y".
* IANA has updated this registry to include a "TLS 1.3" column which * IANA has updated this registry to include a "TLS 1.3" column,
lists the messages in which the extension may appear. This column which lists the messages in which the extension may appear. This
has been initially populated from the table in Section 4.2, with column has been initially populated from the table in Section 4.2,
any extension not listed there marked as "-" to indicate that it with any extension not listed there marked as "-" to indicate that
is not used by TLS 1.3. it is not used by TLS 1.3.
This document updates two entries in the TLS Certificate Types This document updates two entries in the "TLS Certificate Types"
registry originally created in [RFC6091] and updated in [RFC8447]. registry originally created in [RFC6091] and updated in [RFC8447].
IANA has updated the entry for value 1 to have the name IANA has updated the entry for value 1 to have the name
"OpenPGP_RESERVED", "Recommended" value "N", and comment "Used in TLS "OpenPGP_RESERVED", "Recommended" value "N", and comment "Used in TLS
versions prior to 1.3." IANA has updated the entry for value 0 to versions prior to 1.3.". IANA has updated the entry for value 0 to
have the name "X509", "Recommended" value "Y", and comment "Was X.509 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
the range 0-6 or with the second byte in the range 0-3 that are the range 0-6 or with the second byte in the range 0-3 that are
not currently allocated are reserved for backward compatibility. not currently allocated are reserved for backward compatibility.
This registry has a "Recommended" column. The registry has been This registry has a "Recommended" column. The registry has been
initially populated with the values described in Section 4.2.3. initially populated with the values described in Section 4.2.3.
The following values are marked as "Recommended": The following values are marked as "Recommended":
ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512,
rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and
ed25519. The "Recommended" column is assigned a value of "N" ed25519. The "Recommended" column is assigned a value of "N"
unless explicitly requested, and adding a value with a unless explicitly requested, and adding a value with a
"Recommended" value of "Y" requires Standards Action [RFC8126]. "Recommended" value of "Y" requires Standards Action [RFC8126].
IESG Approval is REQUIRED for a Y->N transition. IESG Approval is REQUIRED for a Y->N transition.
* TLS PskKeyExchangeMode registry: Values in the range 0-253 * "TLS PskKeyExchangeMode" registry: Values in the range 0-253
(decimal) are assigned via Specification Required [RFC8126]. The (decimal) are assigned via Specification Required [RFC8126]. The
values 254 and 255 (decimal) are reserved for Private Use values 254 and 255 (decimal) are reserved for Private Use
[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", Cryptology ePrint Archive, Paper
<https://eprint.iacr.org/2024/051.pdf>. 2024/051, 2024, <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 Cryptology ePrint Archive, Paper 2016/1178, 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. Advances in Cryptology - CRYPTO '98, Lecture Notes in
Computer Science, vol. 1462, pp. 1-12, 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", Cryptology ePrint Archive, Paper
<https://eprint.iacr.org/2015/394>. 2015/394, 2015, <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", Cryptology
of CRYPTO 2016 , July 2016, ePrint Archive, Paper 2016/564, 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 4957
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 15 skipping to change at line 4985
[CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know [CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know
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", Cryptology ePrint
2015 , October 2016, <https://eprint.iacr.org/2015/914>. Archive, Paper 2015/914, 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", Cryptology ePrint
2016, <https://eprint.iacr.org/2016/081>. Archive, Paper 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", Cryptology ePrint Archive, Paper 2017/082,
<https://eprint.iacr.org/2017/082>. 2017, <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", 2016 IEEE Symposium on Security
on Security and Privacy (Oakland) 2016 , 2016, and Privacy (SP), pp. 452-469, DOI 10.1109/SP.2016.34,
<http://ieeexplore.ieee.org/document/7546517/>. 2016, <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", 9th
Proceedings of USENIX Workshop on Offensive Technologies , USENIX Workshop on Offensive Technologies (WOOT 15), 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", Cryptology ePrint Archive,
2010, <https://eprint.iacr.org/2010/264>. Paper 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", Cryptology ePrint Archive,
October 2016, <https://eprint.iacr.org/2016/711>. Paper 2016/711, 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, Cryptology ePrint Archive, Paper 2015/978, 2015,
<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",
Cryptology ePrint Archive, Paper 2018/634, 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", Cryptology ePrint Archive, Paper 2019/347,
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 127, line 34 skipping to change at line 5805
(0xFFFF) (0xFFFF)
} NamedGroup; } NamedGroup;
struct { struct {
NamedGroup named_group_list<2..2^16-1>; NamedGroup named_group_list<2..2^16-1>;
} NamedGroupList; } NamedGroupList;
Values within "obsolete_RESERVED" ranges are used in previous Values within "obsolete_RESERVED" ranges are used in previous
versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 versions of TLS and MUST NOT be offered or negotiated by TLS 1.3
implementations. The obsolete curves have various known/theoretical implementations. The obsolete curves have various known/theoretical
weaknesses or have had very little usage, in some cases only due to weaknesses or have had very little usage, in some cases, only due to
unintentional server configuration issues. They are no longer unintentional server configuration issues. They are no longer
considered appropriate for general use and should be assumed to be considered appropriate for general use and should be assumed to be
potentially unsafe. The set of curves specified here is sufficient potentially unsafe. The set of curves specified here is sufficient
for interoperability with all currently deployed and properly for interoperability with all currently deployed and properly
configured TLS implementations. configured TLS implementations.
B.3.2. Server Parameters Messages B.3.2. Server Parameters Messages
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
DistinguishedName authorities<3..2^16-1>; DistinguishedName authorities<3..2^16-1>;
} CertificateAuthoritiesExtension; } CertificateAuthoritiesExtension;
struct { struct {
opaque certificate_extension_oid<1..2^8-1>; opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>; opaque certificate_extension_values<0..2^16-1>;
} OIDFilter; } OIDFilter;
skipping to change at page 130, line 32 skipping to change at line 5915
+===========+=======================================================+ +===========+=======================================================+
| Component | Contents | | Component | Contents |
+===========+=======================================================+ +===========+=======================================================+
| TLS | The string "TLS" | | TLS | The string "TLS" |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| AEAD | The AEAD algorithm used for record protection | | AEAD | The AEAD algorithm used for record protection |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| HASH | The hash algorithm used with HKDF and | | HASH | The hash algorithm used with HKDF and |
| | Transcript-Hash | | | Transcript-Hash |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| VALUE | The two byte ID assigned for this cipher | | VALUE | The two-byte ID assigned for this cipher |
| | suite | | | suite |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 4: Cipher Suite Name Structure Table 4: Cipher Suite Name Structure
This specification defines the following cipher suites for use with This specification defines the following cipher suites for use with
TLS 1.3. TLS 1.3.
+==============================+=============+ +==============================+=============+
| Description | Value | | Description | Value |
skipping to change at page 131, line 45 skipping to change at line 5964
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 6007
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.
TLS protocol issues: TLS protocol issues:
* Do you correctly handle handshake messages that are fragmented to * Do you correctly handle handshake messages that are fragmented to
multiple TLS records (see Section 5.1)? Do you correctly handle multiple TLS records (see Section 5.1)? Do you correctly handle
corner cases like a ClientHello that is split into several small corner cases like a ClientHello that is split into several small
fragments? Do you fragment handshake messages that exceed the fragments? Do you fragment handshake messages that exceed the
maximum fragment size? In particular, the Certificate and maximum fragment size? In particular, the Certificate and
skipping to change at page 133, line 23 skipping to change at line 6038
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 6079
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 Sections 4.2.8.1 and 7.4.1)?
* Do you verify signatures after making them, to protect against * Do you verify signatures after making them to protect against RSA-
RSA-CRT key leaks [FW15]? 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
a ticket allows passive observers to correlate different connections. a ticket allows passive observers to correlate different connections.
Servers that issue tickets SHOULD offer at least as many tickets as Servers that issue tickets SHOULD offer at least as many tickets as
the number of connections that a client might use; for example, a web the number of connections that a client might use; for example, a web
browser using HTTP/1.1 [RFC9112] might open six connections to a browser using HTTP/1.1 [RFC9112] might open six connections to a
server. Servers SHOULD issue new tickets with every connection. server. Servers SHOULD issue new tickets with every connection.
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 [PRE-RFC9849] extension 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 6150
* 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 137, line 46 skipping to change at line 6253
Interoperability with buggy servers is a complex topic beyond the Interoperability with buggy servers is a complex topic beyond the
scope of this document. Multiple connection attempts may be required scope of this document. Multiple connection attempts may be required
to negotiate a backward-compatible connection; however, this practice to negotiate a backward-compatible connection; however, this practice
is vulnerable to downgrade attacks and is NOT RECOMMENDED. is vulnerable to downgrade attacks and is NOT RECOMMENDED.
E.2. Negotiating with an Older Client E.2. Negotiating with an Older Client
A TLS server can also receive a ClientHello indicating a version A TLS server can also receive a ClientHello indicating a version
number smaller than its highest supported version. If the number smaller than its highest supported version. If the
"supported_versions" extension is present, the server MUST negotiate "supported_versions" extension is present, the server MUST negotiate
using that extension as described in Section 4.2.1. If the using that extension, as described in Section 4.2.1. If the
"supported_versions" extension is not present, the server MUST "supported_versions" extension is not present, the server MUST
negotiate the minimum of ClientHello.legacy_version and TLS 1.2. For negotiate the minimum of ClientHello.legacy_version and TLS 1.2. For
example, if the server supports TLS 1.0, 1.1, and 1.2, and example, if the server supports TLS 1.0, 1.1, and 1.2 and
legacy_version is TLS 1.0, the server will proceed with a TLS 1.0 legacy_version is TLS 1.0, the server will proceed with a TLS 1.0
ServerHello. If the "supported_versions" extension is absent and the ServerHello. If the "supported_versions" extension is absent and the
server only supports versions greater than server only supports versions greater than
ClientHello.legacy_version, the server MUST abort the handshake with ClientHello.legacy_version, the server MUST abort the handshake with
a "protocol_version" alert. a "protocol_version" alert.
Note that earlier versions of TLS did not clearly specify the record Note that earlier versions of TLS did not clearly specify the record
layer version number value in all cases layer version number value in all cases
(TLSPlaintext.legacy_record_version). Servers will receive various (TLSPlaintext.legacy_record_version). Servers will receive various
TLS 1.x versions in this field, but its value MUST always be ignored. TLS 1.x versions in this field, but its value MUST always be ignored.
skipping to change at page 139, line 12 skipping to change at line 6314
If offering early data, the record is placed immediately after the If offering early data, the record is placed immediately after the
first ClientHello. first ClientHello.
* The server sends a dummy change_cipher_spec record immediately * The server sends a dummy change_cipher_spec record immediately
after its first handshake message. This may either be after a after its first handshake message. This may either be after a
ServerHello or a HelloRetryRequest. ServerHello or a HelloRetryRequest.
When put together, these changes make the TLS 1.3 handshake resemble When put together, these changes make the TLS 1.3 handshake resemble
TLS 1.2 session resumption, which improves the chance of successfully TLS 1.2 session resumption, which improves the chance of successfully
connecting through middleboxes. This "compatibility mode" is connecting through middleboxes. This "compatibility mode" is
partially negotiated: the client can opt to provide a session ID or partially negotiated: The client can opt to provide a session ID or
not, and the server has to echo it. Either side can send not and the server has to echo it. Either side can send
change_cipher_spec at any time during the handshake, as they must be change_cipher_spec at any time during the handshake, as they must be
ignored by the peer, but if the client sends a non-empty session ID, ignored by the peer, but if the client sends a non-empty session ID,
the server MUST send the change_cipher_spec as described in this the server MUST send the change_cipher_spec, as described in this
appendix. appendix.
E.5. Security Restrictions Related to Backward Compatibility E.5. Security Restrictions Related to Backward Compatibility
Implementations negotiating the use of older versions of TLS SHOULD Implementations negotiating the use of older versions of TLS SHOULD
prefer forward secret and AEAD cipher suites, when available. prefer forward secret and AEAD cipher suites, when available.
The security of RC4 cipher suites is considered insufficient for the The security of RC4 cipher suites is considered insufficient for the
reasons cited in [RFC7465]. Implementations MUST NOT offer or reasons cited in [RFC7465]. Implementations MUST NOT offer or
negotiate RC4 cipher suites for any version of TLS for any reason. negotiate RC4 cipher suites for any version of TLS for any reason.
Old versions of TLS permitted the use of very low strength ciphers. Old versions of TLS permitted the use of very low-strength ciphers.
Ciphers with a strength less than 112 bits MUST NOT be offered or Ciphers with a strength less than 112 bits MUST NOT be offered or
negotiated for any version of TLS for any reason. negotiated for any version of TLS for any reason.
The security of SSL 2.0 [SSL2], SSL 3.0 [RFC6101], TLS 1.0 [RFC2246], The security of SSL 2.0 [SSL2], SSL 3.0 [RFC6101], TLS 1.0 [RFC2246],
and TLS 1.1 [RFC4346] are considered insufficient for the reasons and TLS 1.1 [RFC4346] are considered insufficient for the reasons
enumerated in [RFC6176], [RFC7568], and [RFC8996] and they MUST NOT enumerated in [RFC6176], [RFC7568], and [RFC8996], and they MUST NOT
be negotiated for any reason. be negotiated for any reason.
Implementations MUST NOT send an SSL version 2.0 compatible CLIENT- Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-
HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an
SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT
RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO to RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO to
negotiate older versions of TLS. negotiate older versions of TLS.
Implementations MUST NOT send a ClientHello.legacy_version or Implementations MUST NOT send a ClientHello.legacy_version or
ServerHello.legacy_version set to 0x0300 or less. Any endpoint ServerHello.legacy_version set to 0x0300 or less. Any endpoint
skipping to change at page 140, line 28 skipping to change at line 6379
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
the parties [RFC3552]. Even under these conditions, the handshake the parties [RFC3552]. Even under these conditions, the handshake
should provide the properties listed below. Note that these should provide the properties listed below. Note that these
properties are not necessarily independent, but reflect the protocol properties are not necessarily independent but reflect the protocol
consumers' needs. consumers' needs.
Establishing the same session keys: The handshake needs to output Establishing the same session keys: The handshake needs to output
the same set of session keys on both sides of the handshake, the same set of session keys on both sides of the handshake,
provided that it completes successfully on each endpoint (see provided that it completes successfully on each endpoint (see
[CK01], Definition 1, part 1). [CK01], Definition 1, part 1).
Secrecy of the session keys: The shared session keys should be known Secrecy of the session keys: The shared session keys should be known
only to the communicating parties and not to the attacker (see only to the communicating parties and not to the attacker (see
[CK01]; Definition 1, part 2). Note that in a unilaterally [CK01], Definition 1, part 2). Note that in a unilaterally
authenticated connection, the attacker can establish its own authenticated connection, the attacker can establish its own
session keys with the server, but those session keys are distinct session keys with the server, but those session keys are distinct
from those established by the client. from those established by the client.
Peer Authentication: The client's view of the peer identity should Peer Authentication: The client's view of the peer identity should
reflect the server's identity. If the client is authenticated, reflect the server's identity. If the client is authenticated,
the server's view of the peer identity should match the client's the server's view of the peer identity should match the client's
identity. identity.
Uniqueness of the session keys: Any two distinct handshakes should Uniqueness of the session keys: Any two distinct handshakes should
produce distinct, unrelated session keys. Individual session keys produce distinct, unrelated session keys. Individual session keys
produced by a handshake should also be distinct and independent. produced by a handshake should also be distinct and independent.
Downgrade Protection: The cryptographic parameters should be the Downgrade Protection: The cryptographic parameters should be the
same on both sides and should be the same as if the peers had been same on both sides and should be the same as if the peers had been
communicating in the absence of an attack (see [BBFGKZ16]; communicating in the absence of an attack (see [BBFGKZ16];
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 6493
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 145, line 27 skipping to change at line 6596
A client that has sent certificate-based authentication data to a A client that has sent certificate-based authentication data to a
server, either during the handshake or in post-handshake server, either during the handshake or in post-handshake
authentication, cannot be sure whether the server afterwards authentication, cannot be sure whether the server afterwards
considers the client to be authenticated or not. If the client needs considers the client to be authenticated or not. If the client needs
to determine if the server considers the connection to be to determine if the server considers the connection to be
unilaterally or mutually authenticated, this has to be provisioned by unilaterally or mutually authenticated, this has to be provisioned by
the application layer. See [CHHSV17] for details. In addition, the the application layer. See [CHHSV17] for details. In addition, the
analysis of post-handshake authentication from [Kraw16] shows that analysis of post-handshake authentication from [Kraw16] shows that
the client identified by the certificate sent in the post-handshake the client identified by the certificate sent in the post-handshake
phase possesses the traffic key. This party is therefore the client phase possesses the traffic key. Therefore, this party is the client
that participated in the original handshake or one to whom the that participated in the original handshake or one to whom the
original client delegated the traffic key (assuming that the traffic original client delegated the traffic key (assuming that the traffic
key has not been compromised). key has not been compromised).
F.1.3. 0-RTT F.1.3. 0-RTT
The 0-RTT mode of operation generally provides security properties The 0-RTT mode of operation generally provides security properties
similar to those of 1-RTT data, with the two exceptions that the similar to those of 1-RTT data, with the two exceptions that the
0-RTT encryption keys do not provide full forward secrecy and that 0-RTT encryption keys do not provide full forward secrecy and that
the server is not able to guarantee uniqueness of the handshake (non- the server is not able to guarantee uniqueness of the handshake (non-
skipping to change at page 146, line 9 skipping to change at line 6627
of exporter labels is known, then implementations SHOULD pre-compute of exporter labels is known, then implementations SHOULD pre-compute
the inner Derive-Secret stage of the exporter computation for all the inner Derive-Secret stage of the exporter computation for all
those labels, then erase the [early_]exporter_secret, followed by those labels, then erase the [early_]exporter_secret, followed by
each inner values as soon as it is known that it will not be needed each inner values as soon as it is known that it will not be needed
again. again.
F.1.5. Post-Compromise Security F.1.5. Post-Compromise Security
TLS does not provide security for handshakes which take place after TLS does not provide security for handshakes which take place after
the peer's long-term secret (signature key or external PSK) is the peer's long-term secret (signature key or external PSK) is
compromised. It therefore does not provide post-compromise security compromised. Therefore, it does not provide post-compromise security
[CCG16], sometimes also referred to as backwards or future secrecy. [CCG16], sometimes also referred to as backward or future secrecy.
This is in contrast to KCI resistance, which describes the security This is in contrast to KCI resistance, which describes the security
guarantees that a party has after its own long-term secret has been guarantees that a party has after its own long-term secret has been
compromised. compromised.
F.1.6. External References F.1.6. External References
The reader should refer to the following references for analysis of The reader should refer to the following references for analysis of
the TLS handshake: [DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16], the TLS handshake: [DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16],
[FGSW16], [LXZFH16], [FG17], and [BBK17]. [FGSW16], [LXZFH16], [FG17], and [BBK17].
skipping to change at page 146, line 32 skipping to change at line 6650
The record layer depends on the handshake producing strong traffic The record layer depends on the handshake producing strong traffic
secrets which can be used to derive bidirectional encryption keys and secrets which can be used to derive bidirectional encryption keys and
nonces. Assuming that is true, and the keys are used for no more nonces. Assuming that is true, and the keys are used for no more
data than indicated in Section 5.5, then the record layer should data than indicated in Section 5.5, then the record layer should
provide the following guarantees: provide the following guarantees:
Confidentiality: An attacker should not be able to determine the Confidentiality: An attacker should not be able to determine the
plaintext contents of a given record. plaintext contents of a given record.
Integrity: An attacker should not be able to craft a new record Integrity: An attacker should not be able to craft a new record that
which is different from an existing record which will be accepted is different from an existing record which will be accepted by the
by the receiver. receiver.
Order protection/non-replayability: An attacker should not be able Order protection/non-replayability: An attacker should not be able
to cause the receiver to accept a record which it has already to cause the receiver to accept a record which it has already
accepted or cause the receiver to accept record N+1 without having accepted or cause the receiver to accept record N+1 without having
first processed record N. first processed record N.
Length concealment: Given a record with a given external length, the Length concealment: Given a record with a given external length, the
attacker should not be able to determine the amount of the record attacker should not be able to determine the amount of the record
that is content versus padding. that is content versus padding.
skipping to change at page 147, line 10 skipping to change at line 6674
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
shows that rekeying can allow keys to be used for a larger number of shows that rekeying can allow keys to be used for a larger number of
encryptions than without rekeying. This relies on the security of encryptions than without rekeying. This relies on the security of
the HKDF-Expand-Label function as a pseudorandom function (PRF). In the HKDF-Expand-Label function as a pseudorandom function (PRF). In
addition, as long as this function is truly one way, it is not addition, as long as this function is truly one way, it is not
possible to compute traffic keys from prior to a key change (forward possible to compute traffic keys from prior to a key change (forward
secrecy). secrecy).
TLS does not provide security for data which is communicated on a TLS does not provide security for data which is communicated on a
connection after a traffic secret of that connection is compromised. connection after a traffic secret of that connection is compromised.
That is, TLS does not provide post-compromise security/future That is, TLS does not provide post-compromise security / future
secrecy/backward secrecy with respect to the traffic secret. Indeed, secrecy / backward secrecy with respect to the traffic secret.
an attacker who learns a traffic secret can compute all future Indeed, an attacker who learns a traffic secret can compute all
traffic secrets on that connection. Systems which want such future traffic secrets on that connection. Systems which want such
guarantees need to do a fresh handshake and establish a new guarantees need to do a fresh handshake and establish a new
connection with an (EC)DHE exchange. connection with an (EC)DHE exchange.
F.2.1. External References F.2.1. External References
The reader should refer to the following references for analysis of The reader should refer to the following references for analysis of
the TLS record layer: [BMMRT15], [BT16], [BDFKPPRSZZ16], [BBK17], and the TLS record layer: [BMMRT15], [BT16], [BDFKPPRSZZ16], [BBK17], and
[PS18]. [PS18].
F.3. Traffic Analysis F.3. Traffic Analysis
skipping to change at page 148, line 13 skipping to change at line 6724
information even in more complicated scenarios. information even in more complicated scenarios.
TLS does not provide any specific defenses against this form of TLS does not provide any specific defenses against this form of
attack but does include a padding mechanism for use by applications: attack but does include a padding mechanism for use by applications:
The plaintext protected by the AEAD function consists of content plus The plaintext protected by the AEAD function consists of content plus
variable-length padding, which allows the application to produce variable-length padding, which allows the application to produce
arbitrary-length encrypted records as well as padding-only cover arbitrary-length encrypted records as well as padding-only cover
traffic to conceal the difference between periods of transmission and traffic to conceal the difference between periods of transmission and
periods of silence. Because the padding is encrypted alongside the periods of silence. Because the padding is encrypted alongside the
actual content, an attacker cannot directly determine the length of actual content, an attacker cannot directly determine the length of
the padding, but may be able to measure it indirectly by the use of the padding but may be able to measure it indirectly by the use of
timing channels exposed during record processing (i.e., seeing how timing channels exposed during record processing (i.e., seeing how
long it takes to process a record or trickling in records to see long it takes to process a record or trickling in records to see
which ones elicit a response from the server). In general, it is not which ones elicit a response from the server). In general, it is not
known how to remove all of these channels because even a constant- known how to remove all of these channels because even a constant-
time padding removal function will likely feed the content into data- time padding removal function will likely feed the content into data-
dependent functions. At minimum, a fully constant-time server or dependent functions. At minimum, a fully constant-time server or
client would require close cooperation with the application-layer client would require close cooperation with the application-layer
protocol implementation, including making that higher-level protocol protocol implementation, including making that higher-level protocol
constant time. constant time.
skipping to change at page 149, line 15 skipping to change at line 6770
Information leakage through side channels can occur at layers above Information leakage through side channels can occur at layers above
TLS, in application protocols and the applications that use them. TLS, in application protocols and the applications that use them.
Resistance to side-channel attacks depends on applications and Resistance to side-channel attacks depends on applications and
application protocols separately ensuring that confidential application protocols separately ensuring that confidential
information is not inadvertently leaked. information is not inadvertently leaked.
F.5. Replay Attacks on 0-RTT F.5. Replay Attacks on 0-RTT
Replayable 0-RTT data presents a number of security threats to TLS- Replayable 0-RTT data presents a number of security threats to TLS-
using applications, unless those applications are specifically using applications, unless those applications are specifically
engineered to be safe under replay (minimally, this means idempotent, engineered to be safe under replay (minimally, this means idempotent
but in many cases may also require other stronger conditions, such as but in many cases may also require other stronger conditions, such as
constant-time response). Potential attacks include: constant-time response). Potential attacks include:
* Duplication of actions which cause side effects (e.g., purchasing * Duplication of actions which cause side effects (e.g., purchasing
an item or transferring money) to be duplicated, thus harming the an item or transferring money) to be duplicated, thus harming the
site or the user. site or the user.
* Attackers can store and replay 0-RTT messages to reorder them with * Attackers can store and replay 0-RTT messages to reorder them with
respect to other messages (e.g., moving a delete to after a respect to other messages (e.g., moving a delete to after a
create). create).
* Amplifying existing information leaks caused by side effects like * Amplifying existing information leaks caused by side effects like
caching. An attacker could learn information about the content of caching. An attacker could learn information about the content of
a 0-RTT message by replaying it to some cache node that has not a 0-RTT message by replaying it to some cache node that has not
cached some resource of interest, and then using a separate cached some resource of interest and then using a separate
connection to check whether that resource has been added to the connection to check whether that resource has been added to the
cache. This could be repeated with different cache nodes as often cache. This could be repeated with different cache nodes as often
as the 0-RTT message is replayable. as the 0-RTT message is replayable.
If data can be replayed a large number of times, additional attacks If data can be replayed a large number of times, additional attacks
become possible, such as making repeated measurements of the speed of become possible, such as making repeated measurements of the speed of
cryptographic operations. In addition, they may be able to overload cryptographic operations. In addition, they may be able to overload
rate-limiting systems. For a further description of these attacks, rate-limiting systems. For a further description of these attacks,
see [Mac17]. see [Mac17].
Ultimately, servers have the responsibility to protect themselves Ultimately, servers have the responsibility to protect themselves
against attacks employing 0-RTT data replication. The mechanisms against attacks employing 0-RTT data replication. The mechanisms
described in Section 8 are intended to prevent replay at the TLS described in Section 8 are intended to prevent replay at the TLS
layer but do not provide complete protection against receiving layer but do not provide complete protection against receiving
multiple copies of client data. TLS 1.3 falls back to the 1-RTT multiple copies of client data. TLS 1.3 falls back to the 1-RTT
handshake when the server does not have any information about the handshake when the server does not have any information about the
client, e.g., because it is in a different cluster which does not client, e.g., because it is in a different cluster which does not
share state or because the ticket has been deleted as described in share state or because the ticket has been deleted, as described in
Section 8.1. If the application-layer protocol retransmits data in Section 8.1. If the application-layer protocol retransmits data in
this setting, then it is possible for an attacker to induce message this setting, then it is possible for an attacker to induce message
duplication by sending the ClientHello to both the original cluster duplication by sending the ClientHello to both the original cluster
(which processes the data immediately) and another cluster which will (which processes the data immediately) and another cluster which will
fall back to 1-RTT and process the data upon application-layer fall back to 1-RTT and process the data upon application-layer
replay. The scale of this attack is limited by the client's replay. The scale of this attack is limited by the client's
willingness to retry transactions and therefore only allows a limited willingness to retry transactions and therefore only allows a limited
amount of duplication, with each copy appearing as a new connection amount of duplication, with each copy appearing as a new connection
at the server. at the server.
If implemented correctly, the mechanisms described in Section 8.1 and If implemented correctly, the mechanisms described in Sections 8.1
Section 8.2 prevent a replayed ClientHello and its associated 0-RTT and 8.2 prevent a replayed ClientHello and its associated 0-RTT data
data from being accepted multiple times by any cluster with from being accepted multiple times by any cluster with consistent
consistent state; for servers which limit the use of 0-RTT to one state; for servers which limit the use of 0-RTT to one cluster for a
cluster for a single ticket, then a given ClientHello and its single ticket, a given ClientHello and its associated 0-RTT data will
associated 0-RTT data will only be accepted once. However, if state only be accepted once. However, if state is not completely
is not completely consistent, then an attacker might be able to have consistent, then an attacker might be able to have multiple copies of
multiple copies of the data be accepted during the replication the data be accepted during the replication window. Because clients
window. Because clients do not know the exact details of server do not know the exact details of server behavior, they MUST NOT send
behavior, they MUST NOT send messages in early data which are not messages in early data which are not safe to have replayed and which
safe to have replayed and which they would not be willing to retry they would not be willing to retry across multiple 1-RTT connections.
across multiple 1-RTT connections.
Application protocols MUST NOT use 0-RTT data without a profile that Application protocols MUST NOT use 0-RTT data without a profile that
defines its use. That profile needs to identify which messages or defines its use. That profile needs to identify which messages or
interactions are safe to use with 0-RTT and how to handle the interactions are safe to use with 0-RTT and how to handle the
situation when the server rejects 0-RTT and falls back to 1-RTT. situation when the server rejects 0-RTT and falls back to 1-RTT.
In addition, to avoid accidental misuse, TLS implementations MUST NOT In addition, to avoid accidental misuse, TLS implementations MUST NOT
enable 0-RTT (either sending or accepting) unless specifically enable 0-RTT (either sending or accepting) unless specifically
requested by the application and MUST NOT automatically resend 0-RTT requested by the application and MUST NOT automatically resend 0-RTT
data if it is rejected by the server unless instructed by the data if it is rejected by the server unless instructed by the
skipping to change at page 151, line 47 skipping to change at line 6894
F.8. External PSKs and Rerouting F.8. External PSKs and Rerouting
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 prevents 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
Although TLS 1.3 does not use RSA key transport and so is not Although TLS 1.3 does not use RSA key transport and so is not
directly susceptible to Bleichenbacher-type attacks [Blei98] if TLS directly susceptible to Bleichenbacher-type attacks [Blei98], if TLS
1.3 servers also support static RSA in the context of previous 1.3 servers also support static RSA in the context of previous
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 6954
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 6993
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 7049
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 7103
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 7130
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 7165
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. 287 change blocks. 
686 lines changed or deleted 633 lines changed or added

This html diff was produced by rfcdiff 1.48.