idnits 2.17.1 draft-ietf-tls-rfc8446bis-04.txt: -(4899): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 5 characters in excess of 72. -- The draft header indicates that this document obsoletes RFC8446, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC8422, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys. [AEAD-LIMITS] provides an analysis of these limits under the assumption that the underlying primitive (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key update 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 therefore implementations SHOULD not exceed the limits when sending early data. (Using the creation date from RFC5705, updated by this document, for RFC5378 checks: 2007-12-21) (Using the creation date from RFC6066, updated by this document, for RFC5378 checks: 2007-07-02) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (7 March 2022) is 781 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NewSessionTicket' is mentioned on line 619, but not defined -- Looks like a reference, but probably isn't: '0' on line 748 -- Looks like a reference, but probably isn't: '1' on line 748 -- Looks like a reference, but probably isn't: '2' on line 5367 -- Looks like a reference, but probably isn't: '3' on line 804 -- Looks like a reference, but probably isn't: '4' on line 777 -- Looks like a reference, but probably isn't: '8' on line 778 -- Looks like a reference, but probably isn't: '9' on line 805 -- Looks like a reference, but probably isn't: '10' on line 942 -- Looks like a reference, but probably isn't: '32' on line 5365 == Unused Reference: 'Blei98' is defined on line 4802, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DH76' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECDSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1363' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Obsolete normative reference: RFC 6961 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) ** Downref: Normative reference to an Informational RFC: RFC 6979 ** Obsolete normative reference: RFC 7507 (Obsoleted by RFC 8996) ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Downref: Normative reference to an Informational RFC: RFC 8017 ** Downref: Normative reference to an Informational RFC: RFC 8032 ** Downref: Normative reference to an Informational RFC: RFC 8439 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' -- No information found for draft-10 - is the name correct? -- No information found for draft-10 - is the name correct? -- Duplicate reference: draft-10, mentioned in 'DFGS16', was also mentioned in 'DFGS15'. -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 31 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft Mozilla 4 Obsoletes: 5077, 5246, 6961, 8446 (if approved) 7 March 2022 5 Updates: 5705, 6066, 7627, 8422 (if approved) 6 Intended status: Standards Track 7 Expires: 8 September 2022 9 The Transport Layer Security (TLS) Protocol Version 1.3 10 draft-ietf-tls-rfc8446bis-04 12 Abstract 14 This document specifies version 1.3 of the Transport Layer Security 15 (TLS) protocol. TLS allows client/server applications to communicate 16 over the Internet in a way that is designed to prevent eavesdropping, 17 tampering, and message forgery. 19 This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes 20 RFCs 5077, 5246, 6961, and 8446. This document also specifies new 21 requirements for TLS 1.2 implementations. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 8 September 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 6 70 1.2. Relationship to RFC 8446 . . . . . . . . . . . . . . . . 7 71 1.3. Major Differences from TLS 1.2 . . . . . . . . . . . . . 7 72 1.4. Updates Affecting TLS 1.2 . . . . . . . . . . . . . . . . 8 73 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 74 2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . . . 12 75 2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 13 76 2.3. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . 15 77 3. Presentation Language . . . . . . . . . . . . . . . . . . . . 17 78 3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 17 79 3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 17 80 3.3. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 3.4. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 19 83 3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 20 84 3.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 20 85 3.8. Variants . . . . . . . . . . . . . . . . . . . . . . . . 21 86 4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 22 87 4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 23 88 4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 23 89 4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 24 90 4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 27 91 4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 30 92 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 31 93 4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 35 94 4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 36 95 4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 37 96 4.2.4. Certificate Authorities . . . . . . . . . . . . . . . 41 97 4.2.5. OID Filters . . . . . . . . . . . . . . . . . . . . . 41 98 4.2.6. Post-Handshake Certificate-Based Client 99 Authentication . . . . . . . . . . . . . . . . . . . 42 100 4.2.7. Supported Groups . . . . . . . . . . . . . . . . . . 43 101 4.2.8. Key Share . . . . . . . . . . . . . . . . . . . . . . 44 102 4.2.9. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 47 103 4.2.10. Early Data Indication . . . . . . . . . . . . . . . . 48 104 4.2.11. Pre-Shared Key Extension . . . . . . . . . . . . . . 51 105 4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 55 106 4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 55 107 4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 55 108 4.4. Authentication Messages . . . . . . . . . . . . . . . . . 56 109 4.4.1. The Transcript Hash . . . . . . . . . . . . . . . . . 58 110 4.4.2. Certificate . . . . . . . . . . . . . . . . . . . . . 59 111 4.4.3. Certificate Verify . . . . . . . . . . . . . . . . . 64 112 4.4.4. Finished . . . . . . . . . . . . . . . . . . . . . . 66 113 4.5. End of Early Data . . . . . . . . . . . . . . . . . . . . 67 114 4.6. Post-Handshake Messages . . . . . . . . . . . . . . . . . 68 115 4.6.1. New Session Ticket Message . . . . . . . . . . . . . 68 116 4.6.2. Post-Handshake Authentication . . . . . . . . . . . . 70 117 4.6.3. Key and Initialization Vector Update . . . . . . . . 71 118 5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 72 119 5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 73 120 5.2. Record Payload Protection . . . . . . . . . . . . . . . . 75 121 5.3. Per-Record Nonce . . . . . . . . . . . . . . . . . . . . 77 122 5.4. Record Padding . . . . . . . . . . . . . . . . . . . . . 78 123 5.5. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 79 124 6. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . 79 125 6.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 81 126 6.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 82 127 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 85 128 7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 85 129 7.2. Updating Traffic Secrets . . . . . . . . . . . . . . . . 89 130 7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 89 131 7.4. (EC)DHE Shared Secret Calculation . . . . . . . . . . . . 90 132 7.4.1. Finite Field Diffie-Hellman . . . . . . . . . . . . . 90 133 7.4.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 90 134 7.5. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 91 135 8. 0-RTT and Anti-Replay . . . . . . . . . . . . . . . . . . . . 92 136 8.1. Single-Use Tickets . . . . . . . . . . . . . . . . . . . 93 137 8.2. Client Hello Recording . . . . . . . . . . . . . . . . . 94 138 8.3. Freshness Checks . . . . . . . . . . . . . . . . . . . . 95 139 9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 96 140 9.1. Mandatory-to-Implement Cipher Suites . . . . . . . . . . 96 141 9.2. Mandatory-to-Implement Extensions . . . . . . . . . . . . 97 142 9.3. Protocol Invariants . . . . . . . . . . . . . . . . . . . 98 143 10. Security Considerations . . . . . . . . . . . . . . . . . . . 99 144 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 99 145 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 102 146 12.1. Normative References . . . . . . . . . . . . . . . . . . 102 147 12.2. Informative References . . . . . . . . . . . . . . . . . 105 148 Appendix A. State Machine . . . . . . . . . . . . . . . . . . . 113 149 A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 113 150 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 114 151 Appendix B. Protocol Data Structures and Constant Values . . . . 115 152 B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 116 153 B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 116 154 B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 117 155 B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 118 156 B.3.2. Server Parameters Messages . . . . . . . . . . . . . 123 157 B.3.3. Authentication Messages . . . . . . . . . . . . . . . 124 158 B.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 125 159 B.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 125 160 B.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 126 161 Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 127 162 C.1. Random Number Generation and Seeding . . . . . . . . . . 127 163 C.2. Certificates and Authentication . . . . . . . . . . . . . 128 164 C.3. Implementation Pitfalls . . . . . . . . . . . . . . . . . 128 165 C.4. Client Tracking Prevention . . . . . . . . . . . . . . . 130 166 C.5. Unauthenticated Operation . . . . . . . . . . . . . . . . 130 167 Appendix D. Updates to TLS 1.2 . . . . . . . . . . . . . . . . . 131 168 Appendix E. Backward Compatibility . . . . . . . . . . . . . . . 131 169 E.1. Negotiating with an Older Server . . . . . . . . . . . . 132 170 E.2. Negotiating with an Older Client . . . . . . . . . . . . 133 171 E.3. 0-RTT Backward Compatibility . . . . . . . . . . . . . . 133 172 E.4. Middlebox Compatibility Mode . . . . . . . . . . . . . . 134 173 E.5. Security Restrictions Related to Backward 174 Compatibility . . . . . . . . . . . . . . . . . . . . . . 134 175 Appendix F. Overview of Security Properties . . . . . . . . . . 135 176 F.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 135 177 F.1.1. Key Derivation and HKDF . . . . . . . . . . . . . . . 139 178 F.1.2. Certificate-Based Client Authentication . . . . . . . 140 179 F.1.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . 140 180 F.1.4. Exporter Independence . . . . . . . . . . . . . . . . 140 181 F.1.5. Post-Compromise Security . . . . . . . . . . . . . . 141 182 F.1.6. External References . . . . . . . . . . . . . . . . . 141 183 F.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 141 184 F.2.1. External References . . . . . . . . . . . . . . . . . 142 185 F.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 142 186 F.4. Side Channel Attacks . . . . . . . . . . . . . . . . . . 143 187 F.5. Replay Attacks on 0-RTT . . . . . . . . . . . . . . . . . 144 188 F.5.1. Replay and Exporters . . . . . . . . . . . . . . . . 146 189 F.6. PSK Identity Exposure . . . . . . . . . . . . . . . . . . 146 190 F.7. Sharing PSKs . . . . . . . . . . . . . . . . . . . . . . 146 191 F.8. Attacks on Static RSA . . . . . . . . . . . . . . . . . . 147 192 Appendix G. Changes Since -00 . . . . . . . . . . . . . . . . . 147 193 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 147 194 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 155 196 1. Introduction 198 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this 199 draft is maintained in GitHub. Suggested changes should be submitted 200 as pull requests at https://github.com/ekr/tls13-spec. Instructions 201 are on that page as well. 203 The primary goal of TLS is to provide a secure channel between two 204 communicating peers; the only requirement from the underlying 205 transport is a reliable, in-order, data stream. Specifically, the 206 secure channel should provide the following properties: 208 * Authentication: The server side of the channel is always 209 authenticated; the client side is optionally authenticated. 210 Authentication can happen via asymmetric cryptography (e.g., RSA 211 [RSA], the Elliptic Curve Digital Signature Algorithm (ECDSA) 212 [ECDSA], or the Edwards-Curve Digital Signature Algorithm (EdDSA) 213 [RFC8032]) or a symmetric pre-shared key (PSK). 215 * Confidentiality: Data sent over the channel after establishment is 216 only visible to the endpoints. TLS does not hide the length of 217 the data it transmits, though endpoints are able to pad TLS 218 records in order to obscure lengths and improve protection against 219 traffic analysis techniques. 221 * Integrity: Data sent over the channel after establishment cannot 222 be modified by attackers without detection. 224 These properties should be true even in the face of an attacker who 225 has complete control of the network, as described in [RFC3552]. See 226 Appendix F for a more complete statement of the relevant security 227 properties. 229 TLS consists of two primary components: 231 * A handshake protocol (Section 4) that authenticates the 232 communicating parties, negotiates cryptographic modes and 233 parameters, and establishes shared keying material. The handshake 234 protocol is designed to resist tampering; an active attacker 235 should not be able to force the peers to negotiate different 236 parameters than they would if the connection were not under 237 attack. 239 * A record protocol (Section 5) that uses the parameters established 240 by the handshake protocol to protect traffic between the 241 communicating peers. The record protocol divides traffic up into 242 a series of records, each of which is independently protected 243 using the traffic keys. 245 TLS is application protocol independent; higher-level protocols can 246 layer on top of TLS transparently. The TLS standard, however, does 247 not specify how protocols add security with TLS; how to initiate TLS 248 handshaking and how to interpret the authentication certificates 249 exchanged are left to the judgment of the designers and implementors 250 of protocols that run on top of TLS. 252 This document defines TLS version 1.3. While TLS 1.3 is not directly 253 compatible with previous versions, all versions of TLS incorporate a 254 versioning mechanism which allows clients and servers to 255 interoperably negotiate a common version if one is supported by both 256 peers. 258 This document supersedes and obsoletes previous versions of TLS, 259 including version 1.2 [RFC5246]. It also obsoletes the TLS ticket 260 mechanism defined in [RFC5077] and replaces it with the mechanism 261 defined in Section 2.2. Because TLS 1.3 changes the way keys are 262 derived, it updates [RFC5705] as described in Section 7.5. It also 263 changes how Online Certificate Status Protocol (OCSP) messages are 264 carried and therefore updates [RFC6066] and obsoletes [RFC6961] as 265 described in Section 4.4.2.1. 267 1.1. Conventions and Terminology 269 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 270 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 271 "OPTIONAL" in this document are to be interpreted as described in BCP 272 14 [RFC2119] [RFC8174] when, and only when, they appear in all 273 capitals, as shown here. 275 The following terms are used: 277 client: The endpoint initiating the TLS connection. 279 connection: A transport-layer connection between two endpoints. 281 endpoint: Either the client or server of the connection. 283 handshake: An initial negotiation between client and server that 284 establishes the parameters of their subsequent interactions within 285 TLS. 287 peer: An endpoint. When discussing a particular endpoint, "peer" 288 refers to the endpoint that is not the primary subject of discussion. 290 receiver: An endpoint that is receiving records. 292 sender: An endpoint that is transmitting records. 294 server: The endpoint that did not initiate the TLS connection. 296 1.2. Relationship to RFC 8446 298 TLS 1.3 was originally specified in [RFC8446]. This document is 299 solely an editorial update. It contains updated text in areas which 300 were found to be unclear as well as other editorial improvements. In 301 addition, it removes the use of the term "master" as applied to 302 secrets in favor of the term "main" or shorter names where no term 303 was neccessary. 305 1.3. Major Differences from TLS 1.2 307 The following is a list of the major functional differences between 308 TLS 1.2 and TLS 1.3. It is not intended to be exhaustive, and there 309 are many minor differences. 311 * The list of supported symmetric encryption algorithms has been 312 pruned of all algorithms that are considered legacy. Those that 313 remain are all Authenticated Encryption with Associated Data 314 (AEAD) algorithms. The cipher suite concept has been changed to 315 separate the authentication and key exchange mechanisms from the 316 record protection algorithm (including secret key length) and a 317 hash to be used with both the key derivation function and 318 handshake message authentication code (MAC). 320 * A zero round-trip time (0-RTT) mode was added, saving a round trip 321 at connection setup for some application data, at the cost of 322 certain security properties. 324 * Static RSA and Diffie-Hellman cipher suites have been removed; all 325 public-key based key exchange mechanisms now provide forward 326 secrecy. 328 * All handshake messages after the ServerHello are now encrypted. 329 The newly introduced EncryptedExtensions message allows various 330 extensions previously sent in the clear in the ServerHello to also 331 enjoy confidentiality protection. 333 * The key derivation function has been redesigned. The new design 334 allows easier analysis by cryptographers due to their improved key 335 separation properties. The HMAC-based Extract-and-Expand Key 336 Derivation Function (HKDF) is used as an underlying primitive. 338 * The handshake state machine has been significantly restructured to 339 be more consistent and to remove superfluous messages such as 340 ChangeCipherSpec (except when needed for middlebox compatibility). 342 * Elliptic curve algorithms are now in the base spec, and new 343 signature algorithms, such as EdDSA, are included. TLS 1.3 344 removed point format negotiation in favor of a single point format 345 for each curve. 347 * Other cryptographic improvements were made, including changing the 348 RSA padding to use the RSA Probabilistic Signature Scheme (RSASSA- 349 PSS), and the removal of compression, the Digital Signature 350 Algorithm (DSA), and custom Ephemeral Diffie-Hellman (DHE) groups. 352 * The TLS 1.2 version negotiation mechanism has been deprecated in 353 favor of a version list in an extension. This increases 354 compatibility with existing servers that incorrectly implemented 355 version negotiation. 357 * Session resumption with and without server-side state as well as 358 the PSK-based cipher suites of earlier TLS versions have been 359 replaced by a single new PSK exchange. 361 * References have been updated to point to the updated versions of 362 RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280). 364 1.4. Updates Affecting TLS 1.2 366 This document defines several changes that optionally affect 367 implementations of TLS 1.2, including those which do not also support 368 TLS 1.3: 370 * A version downgrade protection mechanism is described in 371 Section 4.1.3. 373 * RSASSA-PSS signature schemes are defined in Section 4.2.3. 375 * The "supported_versions" ClientHello extension can be used to 376 negotiate the version of TLS to use, in preference to the 377 legacy_version field of the ClientHello. 379 * The "signature_algorithms_cert" extension allows a client to 380 indicate which signature algorithms it can validate in X.509 381 certificates. 383 * The term "master" as applied to secrets has been removed, and the 384 "extended_master_secret" extension [RFC7627] has been renamed to 385 "extended_main_secret". 387 Additionally, this document clarifies some compliance requirements 388 for earlier versions of TLS; see Section 9.3. 390 2. Protocol Overview 392 The cryptographic parameters used by the secure channel are produced 393 by the TLS handshake protocol. This sub-protocol of TLS is used by 394 the client and server when first communicating with each other. The 395 handshake protocol allows peers to negotiate a protocol version, 396 select cryptographic algorithms, authenticate each other (with client 397 authentication being optional), and establish shared secret keying 398 material. Once the handshake is complete, the peers use the 399 established keys to protect the application-layer traffic. 401 A failure of the handshake or other protocol error triggers the 402 termination of the connection, optionally preceded by an alert 403 message (Section 6). 405 TLS supports three basic key exchange modes: 407 * (EC)DHE (Diffie-Hellman over either finite fields or elliptic 408 curves) 410 * PSK-only 412 * PSK with (EC)DHE 414 Figure 1 below shows the basic full TLS handshake: 416 Client Server 418 Key ^ ClientHello 419 Exch | + key_share* 420 | + signature_algorithms* 421 | + psk_key_exchange_modes* 422 v + pre_shared_key* --------> 423 ServerHello ^ Key 424 + key_share* | Exch 425 + pre_shared_key* v 426 {EncryptedExtensions} ^ Server 427 {CertificateRequest*} v Params 428 {Certificate*} ^ 429 {CertificateVerify*} | Auth 430 {Finished} v 431 <-------- [Application Data*] 432 ^ {Certificate*} 433 Auth | {CertificateVerify*} 434 v {Finished} --------> 435 [Application Data] <-------> [Application Data] 437 + Indicates noteworthy extensions sent in the 438 previously noted message. 440 * Indicates optional or situation-dependent 441 messages/extensions that are not always sent. 443 {} Indicates messages protected using keys 444 derived from a [sender]_handshake_traffic_secret. 446 [] Indicates messages protected using keys 447 derived from [sender]_application_traffic_secret_N. 449 Figure 1: Message Flow for Full TLS Handshake 451 The handshake can be thought of as having three phases (indicated in 452 the diagram above): 454 * Key Exchange: Establish shared keying material and select the 455 cryptographic parameters. Everything after this phase is 456 encrypted. 458 * Server Parameters: Establish other handshake parameters (whether 459 the client is authenticated, application-layer protocol support, 460 etc.). 462 * Authentication: Authenticate the server (and, optionally, the 463 client) and provide key confirmation and handshake integrity. 465 In the Key Exchange phase, the client sends the ClientHello 466 (Section 4.1.2) message, which contains a random nonce 467 (ClientHello.random); its offered protocol versions; a list of 468 symmetric cipher/HKDF hash pairs; either a list of Diffie-Hellman key 469 shares (in the "key_share" (Section 4.2.8) extension), a list of pre- 470 shared key labels (in the "pre_shared_key" (Section 4.2.11) 471 extension), or both; and potentially additional extensions. 472 Additional fields and/or messages may also be present for middlebox 473 compatibility. 475 The server processes the ClientHello and determines the appropriate 476 cryptographic parameters for the connection. It then responds with 477 its own ServerHello (Section 4.1.3), which indicates the negotiated 478 connection parameters. The combination of the ClientHello and the 479 ServerHello determines the shared keys. If (EC)DHE key establishment 480 is in use, then the ServerHello contains a "key_share" extension with 481 the server's ephemeral Diffie-Hellman share; the server's share MUST 482 be in the same group as one of the client's shares. If PSK key 483 establishment is in use, then the ServerHello contains a 484 "pre_shared_key" extension indicating which of the client's offered 485 PSKs was selected. Note that implementations can use (EC)DHE and PSK 486 together, in which case both extensions will be supplied. 488 The server then sends two messages to establish the Server 489 Parameters: 491 EncryptedExtensions: responses to ClientHello extensions that are 492 not required to determine the cryptographic parameters, other than 493 those that are specific to individual certificates. 494 [Section 4.3.1] 496 CertificateRequest: if certificate-based client authentication is 497 desired, the desired parameters for that certificate. This 498 message is omitted if client authentication is not desired. 499 [Section 4.3.2] 501 Finally, the client and server exchange Authentication messages. TLS 502 uses the same set of messages every time that certificate-based 503 authentication is needed. (PSK-based authentication happens as a 504 side effect of key exchange.) Specifically: 506 Certificate: The certificate of the endpoint and any per-certificate 507 extensions. This message is omitted by the server if not 508 authenticating with a certificate and by the client if the server 509 did not send CertificateRequest (thus indicating that the client 510 should not authenticate with a certificate). Note that if raw 511 public keys [RFC7250] or the cached information extension 512 [RFC7924] are in use, then this message will not contain a 513 certificate but rather some other value corresponding to the 514 server's long-term key. [Section 4.4.2] 516 CertificateVerify: A signature over the entire handshake using the 517 private key corresponding to the public key in the Certificate 518 message. This message is omitted if the endpoint is not 519 authenticating via a certificate. [Section 4.4.3] 521 Finished: A MAC (Message Authentication Code) over the entire 522 handshake. This message provides key confirmation, binds the 523 endpoint's identity to the exchanged keys, and in PSK mode also 524 authenticates the handshake. [Section 4.4.4] 526 Upon receiving the server's messages, the client responds with its 527 Authentication messages, namely Certificate and CertificateVerify (if 528 requested), and Finished. 530 At this point, the handshake is complete, and the client and server 531 derive the keying material required by the record layer to exchange 532 application-layer data protected through authenticated encryption. 533 Application Data MUST NOT be sent prior to sending the Finished 534 message, except as specified in Section 2.3. Note that while the 535 server may send Application Data prior to receiving the client's 536 Authentication messages, any data sent at that point is, of course, 537 being sent to an unauthenticated peer. 539 2.1. Incorrect DHE Share 541 If the client has not provided a sufficient "key_share" extension 542 (e.g., it includes only DHE or ECDHE groups unacceptable to or 543 unsupported by the server), the server corrects the mismatch with a 544 HelloRetryRequest and the client needs to restart the handshake with 545 an appropriate "key_share" extension, as shown in Figure 2. If no 546 common cryptographic parameters can be negotiated, the server MUST 547 abort the handshake with an appropriate alert. 549 Client Server 551 ClientHello 552 + key_share --------> 553 HelloRetryRequest 554 <-------- + key_share 555 ClientHello 556 + key_share --------> 557 ServerHello 558 + key_share 559 {EncryptedExtensions} 560 {CertificateRequest*} 561 {Certificate*} 562 {CertificateVerify*} 563 {Finished} 564 <-------- [Application Data*] 565 {Certificate*} 566 {CertificateVerify*} 567 {Finished} --------> 568 [Application Data] <-------> [Application Data] 570 Figure 2: Message Flow for a Full Handshake with Mismatched 571 Parameters 573 Note: The handshake transcript incorporates the initial ClientHello/ 574 HelloRetryRequest exchange; it is not reset with the new ClientHello. 576 TLS also allows several optimized variants of the basic handshake, as 577 described in the following sections. 579 2.2. Resumption and Pre-Shared Key (PSK) 581 Although TLS PSKs can be established externally, PSKs can also be 582 established in a previous connection and then used to establish a new 583 connection ("session resumption" or "resuming" with a PSK). Once a 584 handshake has completed, the server can send the client a PSK 585 identity that corresponds to a unique key derived from the initial 586 handshake (see Section 4.6.1). The client can then use that PSK 587 identity in future handshakes to negotiate the use of the associated 588 PSK. If the server accepts the PSK, then the security context of the 589 new connection is cryptographically tied to the original connection 590 and the key derived from the initial handshake is used to bootstrap 591 the cryptographic state instead of a full handshake. In TLS 1.2 and 592 below, this functionality was provided by "session IDs" and "session 593 tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3. 595 PSKs can be used with (EC)DHE key exchange in order to provide 596 forward secrecy in combination with shared keys, or can be used 597 alone, at the cost of losing forward secrecy for the application 598 data. 600 Figure 3 shows a pair of handshakes in which the first handshake 601 establishes a PSK and the second handshake uses it: 603 Client Server 605 Initial Handshake: 606 ClientHello 607 + key_share --------> 608 ServerHello 609 + key_share 610 {EncryptedExtensions} 611 {CertificateRequest*} 612 {Certificate*} 613 {CertificateVerify*} 614 {Finished} 615 <-------- [Application Data*] 616 {Certificate*} 617 {CertificateVerify*} 618 {Finished} --------> 619 <-------- [NewSessionTicket] 620 [Application Data] <-------> [Application Data] 622 Subsequent Handshake: 623 ClientHello 624 + key_share* 625 + pre_shared_key --------> 626 ServerHello 627 + pre_shared_key 628 + key_share* 629 {EncryptedExtensions} 630 {Finished} 631 <-------- [Application Data*] 632 {Finished} --------> 633 [Application Data] <-------> [Application Data] 635 Figure 3: Message Flow for Resumption and PSK 637 As the server is authenticating via a PSK, it does not send a 638 Certificate or a CertificateVerify message. When a client offers 639 resumption via a PSK, it SHOULD also supply a "key_share" extension 640 to the server to allow the server to decline resumption and fall back 641 to a full handshake, if needed. The server responds with a 642 "pre_shared_key" extension to negotiate the use of PSK key 643 establishment and can (as shown here) respond with a "key_share" 644 extension to do (EC)DHE key establishment, thus providing forward 645 secrecy. 647 When PSKs are provisioned externally, the PSK identity and the KDF 648 hash algorithm to be used with the PSK MUST also be provisioned. 650 Note: When using an externally provisioned pre-shared secret, a 651 critical consideration is using sufficient entropy during the key 652 generation, as discussed in [RFC4086]. Deriving a shared secret 653 from a password or other low-entropy sources is not secure. A 654 low-entropy secret, or password, is subject to dictionary attacks 655 based on the PSK binder. The specified PSK authentication is not 656 a strong password-based authenticated key exchange even when used 657 with Diffie-Hellman key establishment. Specifically, it does not 658 prevent an attacker that can observe the handshake from performing 659 a brute-force attack on the password/pre-shared key. 661 2.3. 0-RTT Data 663 When clients and servers share a PSK (either obtained externally or 664 via a previous handshake), TLS 1.3 allows clients to send data on the 665 first flight ("early data"). The client uses the PSK to authenticate 666 the server and to encrypt the early data. 668 As shown in Figure 4, the 0-RTT data is just added to the 1-RTT 669 handshake in the first flight. The rest of the handshake uses the 670 same messages as for a 1-RTT handshake with PSK resumption. 672 Client Server 674 ClientHello 675 + early_data 676 + key_share* 677 + psk_key_exchange_modes 678 + pre_shared_key 679 (Application Data*) --------> 680 ServerHello 681 + pre_shared_key 682 + key_share* 683 {EncryptedExtensions} 684 + early_data* 685 {Finished} 686 <-------- [Application Data*] 687 (EndOfEarlyData) 688 {Finished} --------> 689 [Application Data] <-------> [Application Data] 691 + Indicates noteworthy extensions sent in the 692 previously noted message. 694 * Indicates optional or situation-dependent 695 messages/extensions that are not always sent. 697 () Indicates messages protected using keys 698 derived from a client_early_traffic_secret. 700 {} Indicates messages protected using keys 701 derived from a [sender]_handshake_traffic_secret. 703 [] Indicates messages protected using keys 704 derived from [sender]_application_traffic_secret_N. 706 Figure 4: Message Flow for a 0-RTT Handshake 708 IMPORTANT NOTE: The security properties for 0-RTT data are weaker 709 than those for other kinds of TLS data. Specifically: 711 1. The protocol does not provide any forward secrecy guarantees for 712 this data. The server's behavior determines what forward secrecy 713 guarantees, if any, apply (see Section 8.1). This behavior is 714 not communicated to the client as part of the protocol. 715 Therefore, absent out-of-band knowledge of the server's behavior, 716 the client should assume that this data is not forward secret. 718 2. There are no guarantees of non-replay between connections. 719 Protection against replay for ordinary TLS 1.3 1-RTT data is 720 provided via the server's Random value, but 0-RTT data does not 721 depend on the ServerHello and therefore has weaker guarantees. 722 This is especially relevant if the data is authenticated either 723 with TLS client authentication or inside the application 724 protocol. The same warnings apply to any use of the 725 early_exporter_secret. 727 0-RTT data cannot be duplicated within a connection (i.e., the server 728 will not process the same data twice for the same connection), and an 729 attacker will not be able to make 0-RTT data appear to be 1-RTT data 730 (because it is protected with different keys). Appendix F.5 contains 731 a description of potential attacks, and Section 8 describes 732 mechanisms which the server can use to limit the impact of replay. 734 3. Presentation Language 736 This document deals with the formatting of data in an external 737 representation. The following very basic and somewhat casually 738 defined presentation syntax will be used. 740 3.1. Basic Block Size 742 The representation of all data items is explicitly specified. The 743 basic data block size is one byte (i.e., 8 bits). Multiple-byte data 744 items are concatenations of bytes, from left to right, from top to 745 bottom. From the byte stream, a multi-byte item (a numeric in the 746 following example) is formed (using C notation) by: 748 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | 749 ... | byte[n-1]; 751 This byte ordering for multi-byte values is the commonplace network 752 byte order or big-endian format. 754 3.2. Miscellaneous 756 Comments begin with "/*" and end with "*/". 758 Optional components are denoted by enclosing them in "[[ ]]" (double 759 brackets). 761 Single-byte entities containing uninterpreted data are of type 762 opaque. 764 A type alias T' for an existing type T is defined by: 766 T T'; 768 3.3. Numbers 770 The basic numeric data type is an unsigned byte (uint8). All larger 771 numeric data types are constructed from a fixed-length series of 772 bytes concatenated as described in Section 3.1 and are also unsigned. 773 The following numeric types are predefined. 775 uint8 uint16[2]; 776 uint8 uint24[3]; 777 uint8 uint32[4]; 778 uint8 uint64[8]; 780 All values, here and elsewhere in the specification, are transmitted 781 in network byte (big-endian) order; the uint32 represented by the hex 782 bytes 01 02 03 04 is equivalent to the decimal value 16909060. 784 3.4. Vectors 786 A vector (single-dimensioned array) is a stream of homogeneous data 787 elements. For presentation purposes, this specification refers to 788 vectors as lists. The size of the vector may be specified at 789 documentation time or left unspecified until runtime. In either 790 case, the length declares the number of bytes, not the number of 791 elements, in the vector. The syntax for specifying a new type, T', 792 that is a fixed-length vector of type T is 794 T T'[n]; 796 Here, T' occupies n bytes in the data stream, where n is a multiple 797 of the size of T. The length of the vector is not included in the 798 encoded stream. 800 In the following example, Datum is defined to be three consecutive 801 bytes that the protocol does not interpret, while Data is three 802 consecutive Datum, consuming a total of nine bytes. 804 opaque Datum[3]; /* three uninterpreted bytes */ 805 Datum Data[9]; /* three consecutive 3-byte vectors */ 807 Variable-length vectors are defined by specifying a subrange of legal 808 lengths, inclusively, using the notation . When 809 these are encoded, the actual length precedes the vector's contents 810 in the byte stream. The length will be in the form of a number 811 consuming as many bytes as required to hold the vector's specified 812 maximum (ceiling) length. A variable-length vector with an actual 813 length field of zero is referred to as an empty vector. 815 T T'; 817 In the following example, "mandatory" is a vector that must contain 818 between 300 and 400 bytes of type opaque. It can never be empty. 819 The actual length field consumes two bytes, a uint16, which is 820 sufficient to represent the value 400 (see Section 3.3). Similarly, 821 "longer" can represent up to 800 bytes of data, or 400 uint16 822 elements, and it may be empty. Its encoding will include a two-byte 823 actual length field prepended to the vector. The length of an 824 encoded vector must be an exact multiple of the length of a single 825 element (e.g., a 17-byte vector of uint16 would be illegal). 827 opaque mandatory<300..400>; 828 /* length field is two bytes, cannot be empty */ 829 uint16 longer<0..800>; 830 /* zero to 400 16-bit unsigned integers */ 832 3.5. Enumerateds 834 An additional sparse data type, called "enum" or "enumerated", is 835 available. Each definition is a different type. Only enumerateds of 836 the same type may be assigned or compared. Every element of an 837 enumerated must be assigned a value, as demonstrated in the following 838 example. Since the elements of the enumerated are not ordered, they 839 can be assigned any unique value, in any order. 841 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; 843 Future extensions or additions to the protocol may define new values. 844 Implementations need to be able to parse and ignore unknown values 845 unless the definition of the field states otherwise. 847 An enumerated occupies as much space in the byte stream as would its 848 maximal defined ordinal value. The following definition would cause 849 one byte to be used to carry fields of type Color. 851 enum { red(3), blue(5), white(7) } Color; 853 One may optionally specify a value without its associated tag to 854 force the width definition without defining a superfluous element. 856 In the following example, Taste will consume two bytes in the data 857 stream but can only assume the values 1, 2, or 4 in the current 858 version of the protocol. 860 enum { sweet(1), sour(2), bitter(4), (32000) } Taste; 862 The names of the elements of an enumeration are scoped within the 863 defined type. In the first example, a fully qualified reference to 864 the second element of the enumeration would be Color.blue. Such 865 qualification is not required if the target of the assignment is well 866 specified. 868 Color color = Color.blue; /* overspecified, legal */ 869 Color color = blue; /* correct, type implicit */ 871 The names assigned to enumerateds do not need to be unique. The 872 numerical value can describe a range over which the same name 873 applies. The value includes the minimum and maximum inclusive values 874 in that range, separated by two period characters. This is 875 principally useful for reserving regions of the space. 877 enum { sad(0), meh(1..254), happy(255) } Mood; 879 3.6. Constructed Types 881 Structure types may be constructed from primitive types for 882 convenience. Each specification declares a new, unique type. The 883 syntax used for definitions is much like that of C. 885 struct { 886 T1 f1; 887 T2 f2; 888 ... 889 Tn fn; 890 } T; 892 Fixed- and variable-length list (vector) fields are allowed using the 893 standard list syntax. Structures V1 and V2 in the variants example 894 (Section 3.8) demonstrate this. 896 The fields within a structure may be qualified using the type's name, 897 with a syntax much like that available for enumerateds. For example, 898 T.f2 refers to the second field of the previous declaration. 900 3.7. Constants 902 Fields and variables may be assigned a fixed value using "=", as in: 904 struct { 905 T1 f1 = 8; /* T.f1 must always be 8 */ 906 T2 f2; 907 } T; 909 3.8. Variants 911 Defined structures may have variants based on some knowledge that is 912 available within the environment. The selector must be an enumerated 913 type that defines the possible variants the structure defines. Each 914 arm of the select (below) specifies the type of that variant's field 915 and an optional field label. The mechanism by which the variant is 916 selected at runtime is not prescribed by the presentation language. 918 struct { 919 T1 f1; 920 T2 f2; 921 .... 922 Tn fn; 923 select (E) { 924 case e1: Te1 [[fe1]]; 925 case e2: Te2 [[fe2]]; 926 .... 927 case en: Ten [[fen]]; 928 }; 929 } Tv; 931 For example: 933 enum { apple(0), orange(1) } VariantTag; 935 struct { 936 uint16 number; 937 opaque string<0..10>; /* variable length */ 938 } V1; 940 struct { 941 uint32 number; 942 opaque string[10]; /* fixed length */ 943 } V2; 945 struct { 946 VariantTag type; 947 select (VariantRecord.type) { 948 case apple: V1; 949 case orange: V2; 950 }; 951 } VariantRecord; 953 4. Handshake Protocol 955 The handshake protocol is used to negotiate the security parameters 956 of a connection. Handshake messages are supplied to the TLS record 957 layer, where they are encapsulated within one or more TLSPlaintext or 958 TLSCiphertext structures which are processed and transmitted as 959 specified by the current active connection state. 961 enum { 962 client_hello(1), 963 server_hello(2), 964 new_session_ticket(4), 965 end_of_early_data(5), 966 encrypted_extensions(8), 967 certificate(11), 968 certificate_request(13), 969 certificate_verify(15), 970 finished(20), 971 key_update(24), 972 message_hash(254), 973 (255) 974 } HandshakeType; 976 struct { 977 HandshakeType msg_type; /* handshake type */ 978 uint24 length; /* remaining bytes in message */ 979 select (Handshake.msg_type) { 980 case client_hello: ClientHello; 981 case server_hello: ServerHello; 982 case end_of_early_data: EndOfEarlyData; 983 case encrypted_extensions: EncryptedExtensions; 984 case certificate_request: CertificateRequest; 985 case certificate: Certificate; 986 case certificate_verify: CertificateVerify; 987 case finished: Finished; 988 case new_session_ticket: NewSessionTicket; 989 case key_update: KeyUpdate; 990 }; 991 } Handshake; 993 Protocol messages MUST be sent in the order defined in Section 4.4.1 994 and shown in the diagrams in Section 2. A peer which receives a 995 handshake message in an unexpected order MUST abort the handshake 996 with an "unexpected_message" alert. 998 New handshake message types are assigned by IANA as described in 999 Section 11. 1001 4.1. Key Exchange Messages 1003 The key exchange messages are used to determine the security 1004 capabilities of the client and the server and to establish shared 1005 secrets, including the traffic keys used to protect the rest of the 1006 handshake and the data. 1008 4.1.1. Cryptographic Negotiation 1010 In TLS, the cryptographic negotiation proceeds by the client offering 1011 the following four sets of options in its ClientHello: 1013 * A list of cipher suites which indicates the AEAD algorithm/HKDF 1014 hash pairs which the client supports. 1016 * A "supported_groups" (Section 4.2.7) extension which indicates the 1017 (EC)DHE groups which the client supports and a "key_share" 1018 (Section 4.2.8) extension which contains (EC)DHE shares for some 1019 or all of these groups. 1021 * A "signature_algorithms" (Section 4.2.3) extension which indicates 1022 the signature algorithms which the client can accept. A 1023 "signature_algorithms_cert" extension (Section 4.2.3) may also be 1024 added to indicate certificate-specific signature algorithms. 1026 * A "pre_shared_key" (Section 4.2.11) extension which contains a 1027 list of symmetric key identities known to the client and a 1028 "psk_key_exchange_modes" (Section 4.2.9) extension which indicates 1029 the key exchange modes that may be used with PSKs. 1031 If the server does not select a PSK, then the first three of these 1032 options are entirely orthogonal: the server independently selects a 1033 cipher suite, an (EC)DHE group and key share for key establishment, 1034 and a signature algorithm/certificate pair to authenticate itself to 1035 the client. If there is no overlap between the received 1036 "supported_groups" and the groups supported by the server, then the 1037 server MUST abort the handshake with a "handshake_failure" or an 1038 "insufficient_security" alert. 1040 If the server selects a PSK, then it MUST also select a key 1041 establishment mode from the list indicated by the client's 1042 "psk_key_exchange_modes" extension (at present, PSK alone or with 1043 (EC)DHE). Note that if the PSK can be used without (EC)DHE, then 1044 non-overlap in the "supported_groups" parameters need not be fatal, 1045 as it is in the non-PSK case discussed in the previous paragraph. 1047 If the server selects an (EC)DHE group and the client did not offer a 1048 compatible "key_share" extension in the initial ClientHello, the 1049 server MUST respond with a HelloRetryRequest (Section 4.1.4) message. 1051 If the server successfully selects parameters and does not require a 1052 HelloRetryRequest, it indicates the selected parameters in the 1053 ServerHello as follows: 1055 * If PSK is being used, then the server will send a "pre_shared_key" 1056 extension indicating the selected key. 1058 * When (EC)DHE is in use, the server will also provide a "key_share" 1059 extension. If PSK is not being used, then (EC)DHE and 1060 certificate-based authentication are always used. 1062 * When authenticating via a certificate, the server will send the 1063 Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3) 1064 messages. In TLS 1.3 as defined by this document, either a PSK or 1065 a certificate is always used, but not both. Future documents may 1066 define how to use them together. 1068 If the server is unable to negotiate a supported set of parameters 1069 (i.e., there is no overlap between the client and server parameters), 1070 it MUST abort the handshake with either a "handshake_failure" or 1071 "insufficient_security" fatal alert (see Section 6). 1073 4.1.2. Client Hello 1075 When a client first connects to a server, it is REQUIRED to send the 1076 ClientHello as its first TLS message. The client will also send a 1077 ClientHello when the server has responded to its ClientHello with a 1078 HelloRetryRequest. In that case, the client MUST send the same 1079 ClientHello without modification, except as follows: 1081 * If a "key_share" extension was supplied in the HelloRetryRequest, 1082 replacing the list of shares with a list containing a single 1083 KeyShareEntry from the indicated group. 1085 * Removing the "early_data" extension (Section 4.2.10) if one was 1086 present. Early data is not permitted after a HelloRetryRequest. 1088 * Including a "cookie" extension if one was provided in the 1089 HelloRetryRequest. 1091 * Updating the "pre_shared_key" extension if present by recomputing 1092 the "obfuscated_ticket_age" and binder values and (optionally) 1093 removing any PSKs which are incompatible with the server's 1094 indicated cipher suite. 1096 * Optionally adding, removing, or changing the length of the 1097 "padding" extension [RFC7685]. 1099 * Other modifications that may be allowed by an extension defined in 1100 the future and present in the HelloRetryRequest. 1102 Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS 1103 1.3 and receives a ClientHello at any other time, it MUST terminate 1104 the connection with an "unexpected_message" alert. 1106 If a server established a TLS connection with a previous version of 1107 TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST 1108 retain the previous protocol version. In particular, it MUST NOT 1109 negotiate TLS 1.3. 1111 Structure of this message: 1113 uint16 ProtocolVersion; 1114 opaque Random[32]; 1116 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1118 struct { 1119 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 1120 Random random; 1121 opaque legacy_session_id<0..32>; 1122 CipherSuite cipher_suites<2..2^16-2>; 1123 opaque legacy_compression_methods<1..2^8-1>; 1124 Extension extensions<8..2^16-1>; 1125 } ClientHello; 1127 legacy_version: In previous versions of TLS, this field was used for 1128 version negotiation and represented the highest version number 1129 supported by the client. Experience has shown that many servers 1130 do not properly implement version negotiation, leading to "version 1131 intolerance" in which the server rejects an otherwise acceptable 1132 ClientHello with a version number higher than it supports. In TLS 1133 1.3, the client indicates its version preferences in the 1134 "supported_versions" extension (Section 4.2.1) and the 1135 legacy_version field MUST be set to 0x0303, which is the version 1136 number for TLS 1.2. TLS 1.3 ClientHellos are identified as having 1137 a legacy_version of 0x0303 and a supported_versions extension 1138 present with 0x0304 as the highest version indicated therein. 1139 (See Appendix E for details about backward compatibility.) A 1140 server which receives a legacy_version value not equal to 0x0303 1141 MUST abort the handshake with an "illegal_parameter" alert. 1143 random: 32 bytes generated by a secure random number generator. See 1144 Appendix C for additional information. 1146 legacy_session_id: Versions of TLS before TLS 1.3 supported a 1147 "session resumption" feature which has been merged with pre-shared 1148 keys in this version (see Section 2.2). A client which has a 1149 cached session ID set by a pre-TLS 1.3 server SHOULD set this 1150 field to that value. In compatibility mode (see Appendix E.4), 1151 this field MUST be non-empty, so a client not offering a pre-TLS 1152 1.3 session MUST generate a new 32-byte value. This value need 1153 not be random but SHOULD be unpredictable to avoid implementations 1154 fixating on a specific value (also known as ossification). 1155 Otherwise, it MUST be set as a zero-length list (i.e., a zero- 1156 valued single byte length field). 1158 cipher_suites: A list of the symmetric cipher options supported by 1159 the client, specifically the record protection algorithm 1160 (including secret key length) and a hash to be used with HKDF, in 1161 descending order of client preference. Values are defined in 1162 Appendix B.4. If the list contains cipher suites that the server 1163 does not recognize, support, or wish to use, the server MUST 1164 ignore those cipher suites and process the remaining ones as 1165 usual. If the client is attempting a PSK key establishment, it 1166 SHOULD advertise at least one cipher suite indicating a Hash 1167 associated with the PSK. 1169 legacy_compression_methods: Versions of TLS before 1.3 supported 1170 compression with the list of supported compression methods being 1171 sent in this field. For every TLS 1.3 ClientHello, this list MUST 1172 contain exactly one byte, set to zero, which corresponds to the 1173 "null" compression method in prior versions of TLS. If a TLS 1.3 1174 ClientHello is received with any other value in this field, the 1175 server MUST abort the handshake with an "illegal_parameter" alert. 1176 Note that TLS 1.3 servers might receive TLS 1.2 or prior 1177 ClientHellos which contain other compression methods and (if 1178 negotiating such a prior version) MUST follow the procedures for 1179 the appropriate prior version of TLS. 1181 extensions: Clients request extended functionality from servers by 1182 sending data in the extensions field. The actual "Extension" 1183 format is defined in Section 4.2. In TLS 1.3, the use of certain 1184 extensions is mandatory, as functionality has moved into 1185 extensions to preserve ClientHello compatibility with previous 1186 versions of TLS. Servers MUST ignore unrecognized extensions. 1188 All versions of TLS allow an extensions field to optionally follow 1189 the compression_methods field. TLS 1.3 ClientHello messages always 1190 contain extensions (minimally "supported_versions", otherwise, they 1191 will be interpreted as TLS 1.2 ClientHello messages). However, TLS 1192 1.3 servers might receive ClientHello messages without an extensions 1193 field from prior versions of TLS. The presence of extensions can be 1194 detected by determining whether there are bytes following the 1195 compression_methods field at the end of the ClientHello. Note that 1196 this method of detecting optional data differs from the normal TLS 1197 method of having a variable-length field, but it is used for 1198 compatibility with TLS before extensions were defined. TLS 1.3 1199 servers will need to perform this check first and only attempt to 1200 negotiate TLS 1.3 if the "supported_versions" extension is present. 1201 If negotiating a version of TLS prior to 1.3, a server MUST check 1202 that the message either contains no data after 1203 legacy_compression_methods or that it contains a valid extensions 1204 block with no data following. If not, then it MUST abort the 1205 handshake with a "decode_error" alert. 1207 In the event that a client requests additional functionality using 1208 extensions and this functionality is not supplied by the server, the 1209 client MAY abort the handshake. 1211 After sending the ClientHello message, the client waits for a 1212 ServerHello or HelloRetryRequest message. If early data is in use, 1213 the client may transmit early Application Data (Section 2.3) while 1214 waiting for the next handshake message. 1216 4.1.3. Server Hello 1218 The server will send this message in response to a ClientHello 1219 message to proceed with the handshake if it is able to negotiate an 1220 acceptable set of handshake parameters based on the ClientHello. 1222 Structure of this message: 1224 struct { 1225 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 1226 Random random; 1227 opaque legacy_session_id_echo<0..32>; 1228 CipherSuite cipher_suite; 1229 uint8 legacy_compression_method = 0; 1230 Extension extensions<6..2^16-1>; 1231 } ServerHello; 1233 legacy_version: In previous versions of TLS, this field was used for 1234 version negotiation and represented the selected version number 1235 for the connection. Unfortunately, some middleboxes fail when 1236 presented with new values. In TLS 1.3, the TLS server indicates 1237 its version using the "supported_versions" extension 1238 (Section 4.2.1), and the legacy_version field MUST be set to 1239 0x0303, which is the version number for TLS 1.2. (See Appendix E 1240 for details about backward compatibility.) 1242 random: 32 bytes generated by a secure random number generator. See 1243 Appendix C for additional information. The last 8 bytes MUST be 1244 overwritten as described below if negotiating TLS 1.2 or TLS 1.1, 1245 but the remaining bytes MUST be random. This structure is 1246 generated by the server and MUST be generated independently of the 1247 ClientHello.random. 1249 legacy_session_id_echo: The contents of the client's 1250 legacy_session_id field. Note that this field is echoed even if 1251 the client's value corresponded to a cached pre-TLS 1.3 session 1252 which the server has chosen not to resume. A client which 1253 receives a legacy_session_id_echo field that does not match what 1254 it sent in the ClientHello MUST abort the handshake with an 1255 "illegal_parameter" alert. 1257 cipher_suite: The single cipher suite selected by the server from 1258 the ClientHello.cipher_suites list. A client which receives a 1259 cipher suite that was not offered MUST abort the handshake with an 1260 "illegal_parameter" alert. 1262 legacy_compression_method: A single byte which MUST have the value 1263 0. 1265 extensions: A list of extensions. The ServerHello MUST only include 1266 extensions which are required to establish the cryptographic 1267 context and negotiate the protocol version. All TLS 1.3 1268 ServerHello messages MUST contain the "supported_versions" 1269 extension. Current ServerHello messages additionally contain 1270 either the "pre_shared_key" extension or the "key_share" 1271 extension, or both (when using a PSK with (EC)DHE key 1272 establishment). Other extensions (see Section 4.2) are sent 1273 separately in the EncryptedExtensions message. 1275 For reasons of backward compatibility with middleboxes (see 1276 Appendix E.4), the HelloRetryRequest message uses the same structure 1277 as the ServerHello, but with Random set to the special value of the 1278 SHA-256 of "HelloRetryRequest": 1280 CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91 1281 C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C 1283 Upon receiving a message with type server_hello, implementations MUST 1284 first examine the Random value and, if it matches this value, process 1285 it as described in Section 4.1.4). 1287 TLS 1.3 has a downgrade protection mechanism embedded in the server's 1288 random value. TLS 1.3 servers which negotiate TLS 1.2 or below in 1289 response to a ClientHello MUST set the last 8 bytes of their Random 1290 value specially in their ServerHello. 1292 If negotiating TLS 1.2, TLS 1.3 servers MUST set the last 8 bytes of 1293 their Random value to the bytes: 1295 44 4F 57 4E 47 52 44 01 1297 If negotiating TLS 1.1 or below, TLS 1.3 servers MUST, and TLS 1.2 1298 servers SHOULD, set the last 8 bytes of their ServerHello.Random 1299 value to the bytes: 1301 44 4F 57 4E 47 52 44 00 1303 Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS 1304 versions below 1.2; implementations which do not follow that guidance 1305 MUST behave as described above. 1307 TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below 1308 MUST check that the last 8 bytes are not equal to either of these 1309 values. TLS 1.2 clients SHOULD also check that the last 8 bytes are 1310 not equal to the second value if the ServerHello indicates TLS 1.1 or 1311 below. If a match is found, the client MUST abort the handshake with 1312 an "illegal_parameter" alert. This mechanism provides limited 1313 protection against downgrade attacks over and above what is provided 1314 by the Finished exchange: because the ServerKeyExchange, a message 1315 present in TLS 1.2 and below, includes a signature over both random 1316 values, it is not possible for an active attacker to modify the 1317 random values without detection as long as ephemeral ciphers are 1318 used. It does not provide downgrade protection when static RSA is 1319 used. 1321 Note: This is a change from [RFC5246], so in practice many TLS 1.2 1322 clients and servers will not behave as specified above. 1324 A legacy TLS client performing renegotiation with TLS 1.2 or prior 1325 and which receives a TLS 1.3 ServerHello during renegotiation MUST 1326 abort the handshake with a "protocol_version" alert. Note that 1327 renegotiation is not possible when TLS 1.3 has been negotiated. 1329 4.1.4. Hello Retry Request 1331 The server will send this message in response to a ClientHello 1332 message if it is able to find an acceptable set of parameters but the 1333 ClientHello does not contain sufficient information to proceed with 1334 the handshake. As discussed in Section 4.1.3, the HelloRetryRequest 1335 has the same format as a ServerHello message, and the legacy_version, 1336 legacy_session_id_echo, cipher_suite, and legacy_compression_method 1337 fields have the same meaning. However, for convenience we discuss 1338 "HelloRetryRequest" throughout this document as if it were a distinct 1339 message. 1341 The server's extensions MUST contain "supported_versions". 1342 Additionally, it SHOULD contain the minimal set of extensions 1343 necessary for the client to generate a correct ClientHello pair. As 1344 with the ServerHello, a HelloRetryRequest MUST NOT contain any 1345 extensions that were not first offered by the client in its 1346 ClientHello, with the exception of optionally the "cookie" (see 1347 Section 4.2.2) extension. 1349 Upon receipt of a HelloRetryRequest, the client MUST check the 1350 legacy_version, legacy_session_id_echo, cipher_suite, and 1351 legacy_compression_method as specified in Section 4.1.3 and then 1352 process the extensions, starting with determining the version using 1353 "supported_versions". Clients MUST abort the handshake with an 1354 "illegal_parameter" alert if the HelloRetryRequest would not result 1355 in any change in the ClientHello. If a client receives a second 1356 HelloRetryRequest in the same connection (i.e., where the ClientHello 1357 was itself in response to a HelloRetryRequest), it MUST abort the 1358 handshake with an "unexpected_message" alert. 1360 Otherwise, the client MUST process all extensions in the 1361 HelloRetryRequest and send a second updated ClientHello. The 1362 HelloRetryRequest extensions defined in this specification are: 1364 * supported_versions (see Section 4.2.1) 1366 * cookie (see Section 4.2.2) 1368 * key_share (see Section 4.2.8) 1369 A client which receives a cipher suite that was not offered MUST 1370 abort the handshake. Servers MUST ensure that they negotiate the 1371 same cipher suite when receiving a conformant updated ClientHello (if 1372 the server selects the cipher suite as the first step in the 1373 negotiation, then this will happen automatically). Upon receiving 1374 the ServerHello, clients MUST check that the cipher suite supplied in 1375 the ServerHello is the same as that in the HelloRetryRequest and 1376 otherwise abort the handshake with an "illegal_parameter" alert. 1378 In addition, in its updated ClientHello, the client SHOULD NOT offer 1379 any pre-shared keys associated with a hash other than that of the 1380 selected cipher suite. This allows the client to avoid having to 1381 compute partial hash transcripts for multiple hashes in the second 1382 ClientHello. 1384 The value of selected_version in the HelloRetryRequest 1385 "supported_versions" extension MUST be retained in the ServerHello, 1386 and a client MUST abort the handshake with an "illegal_parameter" 1387 alert if the value changes. 1389 4.2. Extensions 1391 A number of TLS messages contain tag-length-value encoded extensions 1392 structures. 1394 struct { 1395 ExtensionType extension_type; 1396 opaque extension_data<0..2^16-1>; 1397 } Extension; 1399 enum { 1400 server_name(0), /* RFC 6066 */ 1401 max_fragment_length(1), /* RFC 6066 */ 1402 status_request(5), /* RFC 6066 */ 1403 supported_groups(10), /* RFC 8422, 7919 */ 1404 signature_algorithms(13), /* RFC 8446 */ 1405 use_srtp(14), /* RFC 5764 */ 1406 heartbeat(15), /* RFC 6520 */ 1407 application_layer_protocol_negotiation(16), /* RFC 7301 */ 1408 signed_certificate_timestamp(18), /* RFC 6962 */ 1409 client_certificate_type(19), /* RFC 7250 */ 1410 server_certificate_type(20), /* RFC 7250 */ 1411 padding(21), /* RFC 7685 */ 1412 pre_shared_key(41), /* RFC 8446 */ 1413 early_data(42), /* RFC 8446 */ 1414 supported_versions(43), /* RFC 8446 */ 1415 cookie(44), /* RFC 8446 */ 1416 psk_key_exchange_modes(45), /* RFC 8446 */ 1417 certificate_authorities(47), /* RFC 8446 */ 1418 oid_filters(48), /* RFC 8446 */ 1419 post_handshake_auth(49), /* RFC 8446 */ 1420 signature_algorithms_cert(50), /* RFC 8446 */ 1421 key_share(51), /* RFC 8446 */ 1422 (65535) 1423 } ExtensionType; 1425 Here: 1427 * "extension_type" identifies the particular extension type. 1429 * "extension_data" contains information specific to the particular 1430 extension type. 1432 The contents of the "extension_data" field are typically defined by 1433 an extension-specific structure defined in the TLS presentation 1434 language. Unless otherwise specified, trailing data is forbidden. 1435 That is, senders MUST NOT include data after the structure in the 1436 "extension_data" field. When processing an extension, receivers MUST 1437 abort the handshake with a "decode_error" alert if there is data left 1438 over after parsing the structure. This does not apply if the 1439 receiver does not implement or is configured to ignore an extension. 1441 The list of extension types is maintained by IANA as described in 1442 Section 11. 1444 Extensions are generally structured in a request/response fashion, 1445 though some extensions are just requests with no corresponding 1446 response (i.e., indications). The client sends its extension 1447 requests in the ClientHello message, and the server sends its 1448 extension responses in the ServerHello, EncryptedExtensions, 1449 HelloRetryRequest, and Certificate messages. The server sends 1450 extension requests in the CertificateRequest message which a client 1451 MAY respond to with a Certificate message. The server MAY also send 1452 unsolicited extensions in the NewSessionTicket, though the client 1453 does not respond directly to these. 1455 Implementations MUST NOT send extension responses if the remote 1456 endpoint did not send the corresponding extension requests, with the 1457 exception of the "cookie" extension in the HelloRetryRequest. Upon 1458 receiving such an extension, an endpoint MUST abort the handshake 1459 with an "unsupported_extension" alert. 1461 The table below indicates the messages where a given extension may 1462 appear, using the following notation: CH (ClientHello), SH 1463 (ServerHello), EE (EncryptedExtensions), CT (Certificate), CR 1464 (CertificateRequest), NST (NewSessionTicket), and HRR 1465 (HelloRetryRequest). If an implementation receives an extension 1466 which it recognizes and which is not specified for the message in 1467 which it appears, it MUST abort the handshake with an 1468 "illegal_parameter" alert. 1470 +==================================================+=============+ 1471 | Extension | TLS 1.3 | 1472 +==================================================+=============+ 1473 | server_name [RFC6066] | CH, EE | 1474 +--------------------------------------------------+-------------+ 1475 | max_fragment_length [RFC6066] | CH, EE | 1476 +--------------------------------------------------+-------------+ 1477 | status_request [RFC6066] | CH, CR, CT | 1478 +--------------------------------------------------+-------------+ 1479 | supported_groups [RFC7919] | CH, EE | 1480 +--------------------------------------------------+-------------+ 1481 | signature_algorithms (RFC8446) | CH, CR | 1482 +--------------------------------------------------+-------------+ 1483 | use_srtp [RFC5764] | CH, EE | 1484 +--------------------------------------------------+-------------+ 1485 | heartbeat [RFC6520] | CH, EE | 1486 +--------------------------------------------------+-------------+ 1487 | application_layer_protocol_negotiation [RFC7301] | CH, EE | 1488 +--------------------------------------------------+-------------+ 1489 | signed_certificate_timestamp [RFC6962] | CH, CR, CT | 1490 +--------------------------------------------------+-------------+ 1491 | client_certificate_type [RFC7250] | CH, EE | 1492 +--------------------------------------------------+-------------+ 1493 | server_certificate_type [RFC7250] | CH, EE | 1494 +--------------------------------------------------+-------------+ 1495 | padding [RFC7685] | CH | 1496 +--------------------------------------------------+-------------+ 1497 | cached_info [RFC7924] | CH, EE | 1498 +--------------------------------------------------+-------------+ 1499 | key_share (RFC 8446) | CH, SH, HRR | 1500 +--------------------------------------------------+-------------+ 1501 | pre_shared_key (RFC 8446) | CH, SH | 1502 +--------------------------------------------------+-------------+ 1503 | psk_key_exchange_modes (RFC 8446) | CH | 1504 +--------------------------------------------------+-------------+ 1505 | early_data (RFC 8446) | CH, EE, NST | 1506 +--------------------------------------------------+-------------+ 1507 | cookie (RFC 8446) | CH, HRR | 1508 +--------------------------------------------------+-------------+ 1509 | supported_versions (RFC 8446) | CH, SH, HRR | 1510 +--------------------------------------------------+-------------+ 1511 | certificate_authorities (RFC 8446) | CH, CR | 1512 +--------------------------------------------------+-------------+ 1513 | oid_filters (RFC 8446) | CR | 1514 +--------------------------------------------------+-------------+ 1515 | post_handshake_auth (RFC 8446) | CH | 1516 +--------------------------------------------------+-------------+ 1517 | signature_algorithms_cert (RFC 8446) | CH, CR | 1518 +--------------------------------------------------+-------------+ 1520 Table 1: TLS Extensions 1522 When multiple extensions of different types are present, the 1523 extensions MAY appear in any order, with the exception of 1524 "pre_shared_key" (Section 4.2.11) which MUST be the last extension in 1525 the ClientHello (but can appear anywhere in the ServerHello 1526 extensions block). There MUST NOT be more than one extension of the 1527 same type in a given extension block. 1529 In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each 1530 handshake even when in resumption-PSK mode. However, 0-RTT 1531 parameters are those negotiated in the previous handshake; mismatches 1532 may require rejecting 0-RTT (see Section 4.2.10). 1534 There are subtle (and not so subtle) interactions that may occur in 1535 this protocol between new features and existing features which may 1536 result in a significant reduction in overall security. The following 1537 considerations should be taken into account when designing new 1538 extensions: 1540 * Some cases where a server does not agree to an extension are error 1541 conditions (e.g., the handshake cannot continue), and some are 1542 simply refusals to support particular features. In general, error 1543 alerts should be used for the former and a field in the server 1544 extension response for the latter. 1546 * Extensions should, as far as possible, be designed to prevent any 1547 attack that forces use (or non-use) of a particular feature by 1548 manipulation of handshake messages. This principle should be 1549 followed regardless of whether the feature is believed to cause a 1550 security problem. Often the fact that the extension fields are 1551 included in the inputs to the Finished message hashes will be 1552 sufficient, but extreme care is needed when the extension changes 1553 the meaning of messages sent in the handshake phase. Designers 1554 and implementors should be aware of the fact that until the 1555 handshake has been authenticated, active attackers can modify 1556 messages and insert, remove, or replace extensions. 1558 4.2.1. Supported Versions 1560 struct { 1561 select (Handshake.msg_type) { 1562 case client_hello: 1563 ProtocolVersion versions<2..254>; 1565 case server_hello: /* and HelloRetryRequest */ 1566 ProtocolVersion selected_version; 1567 }; 1568 } SupportedVersions; 1570 The "supported_versions" extension is used by the client to indicate 1571 which versions of TLS it supports and by the server to indicate which 1572 version it is using. The extension contains a list of supported 1573 versions in preference order, with the most preferred version first. 1574 Implementations of this specification MUST send this extension in the 1575 ClientHello containing all versions of TLS which they are prepared to 1576 negotiate (for this specification, that means minimally 0x0304, but 1577 if previous versions of TLS are allowed to be negotiated, they MUST 1578 be present as well). 1580 If this extension is not present, servers which are compliant with 1581 this specification and which also support TLS 1.2 MUST negotiate TLS 1582 1.2 or prior as specified in [RFC5246], even if 1583 ClientHello.legacy_version is 0x0304 or later. Servers MAY abort the 1584 handshake upon receiving a ClientHello with legacy_version 0x0304 or 1585 later. 1587 If this extension is present in the ClientHello, servers MUST NOT use 1588 the ClientHello.legacy_version value for version negotiation and MUST 1589 use only the "supported_versions" extension to determine client 1590 preferences. Servers MUST only select a version of TLS present in 1591 that extension and MUST ignore any unknown versions that are present 1592 in that extension. Note that this mechanism makes it possible to 1593 negotiate a version prior to TLS 1.2 if one side supports a sparse 1594 range. Implementations of TLS 1.3 which choose to support prior 1595 versions of TLS SHOULD support TLS 1.2. Servers MUST be prepared to 1596 receive ClientHellos that include this extension but do not include 1597 0x0304 in the list of versions. 1599 A server which negotiates a version of TLS prior to TLS 1.3 MUST set 1600 ServerHello.version and MUST NOT send the "supported_versions" 1601 extension. A server which negotiates TLS 1.3 MUST respond by sending 1602 a "supported_versions" extension containing the selected version 1603 value (0x0304). It MUST set the ServerHello.legacy_version field to 1604 0x0303 (TLS 1.2). 1606 After checking ServerHello.random to determine if the server 1607 handshake message is a ServerHello or HelloRetryRequest, clients MUST 1608 check for this extension prior to processing the rest of the 1609 ServerHello. This will require clients to parse the ServerHello in 1610 order to read the extension. If this extension is present, clients 1611 MUST ignore the ServerHello.legacy_version value and MUST use only 1612 the "supported_versions" extension to determine the selected version. 1613 If the "supported_versions" extension in the ServerHello contains a 1614 version not offered by the client or contains a version prior to TLS 1615 1.3, the client MUST abort the handshake with an "illegal_parameter" 1616 alert. 1618 4.2.2. Cookie 1620 struct { 1621 opaque cookie<1..2^16-1>; 1622 } Cookie; 1624 Cookies serve two primary purposes: 1626 * Allowing the server to force the client to demonstrate 1627 reachability at their apparent network address (thus providing a 1628 measure of DoS protection). This is primarily useful for non- 1629 connection-oriented transports (see [RFC6347] for an example of 1630 this). 1632 * Allowing the server to offload state to the client, thus allowing 1633 it to send a HelloRetryRequest without storing any state. The 1634 server can do this by storing the hash of the ClientHello in the 1635 HelloRetryRequest cookie (protected with some suitable integrity 1636 protection algorithm). 1638 When sending a HelloRetryRequest, the server MAY provide a "cookie" 1639 extension to the client (this is an exception to the usual rule that 1640 the only extensions that may be sent are those that appear in the 1641 ClientHello). When sending the new ClientHello, the client MUST copy 1642 the contents of the extension received in the HelloRetryRequest into 1643 a "cookie" extension in the new ClientHello. Clients MUST NOT use 1644 cookies in their initial ClientHello in subsequent connections. 1646 When a server is operating statelessly, it may receive an unprotected 1647 record of type change_cipher_spec between the first and second 1648 ClientHello (see Section 5). Since the server is not storing any 1649 state, this will appear as if it were the first message to be 1650 received. Servers operating statelessly MUST ignore these records. 1652 4.2.3. Signature Algorithms 1654 TLS 1.3 provides two extensions for indicating which signature 1655 algorithms may be used in digital signatures. The 1656 "signature_algorithms_cert" extension applies to signatures in 1657 certificates, and the "signature_algorithms" extension, which 1658 originally appeared in TLS 1.2, applies to signatures in 1659 CertificateVerify messages. The keys found in certificates MUST also 1660 be of appropriate type for the signature algorithms they are used 1661 with. This is a particular issue for RSA keys and PSS signatures, as 1662 described below. If no "signature_algorithms_cert" extension is 1663 present, then the "signature_algorithms" extension also applies to 1664 signatures appearing in certificates. Clients which desire the 1665 server to authenticate itself via a certificate MUST send the 1666 "signature_algorithms" extension. If a server is authenticating via 1667 a certificate and the client has not sent a "signature_algorithms" 1668 extension, then the server MUST abort the handshake with a 1669 "missing_extension" alert (see Section 9.2). 1671 The "signature_algorithms_cert" extension was added to allow 1672 implementations which supported different sets of algorithms for 1673 certificates and in TLS itself to clearly signal their capabilities. 1675 TLS 1.2 implementations SHOULD also process this extension. 1676 Implementations which have the same policy in both cases MAY omit the 1677 "signature_algorithms_cert" extension. 1679 The "extension_data" field of these extensions contains a 1680 SignatureSchemeList value: 1682 enum { 1683 /* RSASSA-PKCS1-v1_5 algorithms */ 1684 rsa_pkcs1_sha256(0x0401), 1685 rsa_pkcs1_sha384(0x0501), 1686 rsa_pkcs1_sha512(0x0601), 1688 /* ECDSA algorithms */ 1689 ecdsa_secp256r1_sha256(0x0403), 1690 ecdsa_secp384r1_sha384(0x0503), 1691 ecdsa_secp521r1_sha512(0x0603), 1693 /* RSASSA-PSS algorithms with public key OID rsaEncryption */ 1694 rsa_pss_rsae_sha256(0x0804), 1695 rsa_pss_rsae_sha384(0x0805), 1696 rsa_pss_rsae_sha512(0x0806), 1698 /* EdDSA algorithms */ 1699 ed25519(0x0807), 1700 ed448(0x0808), 1702 /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */ 1703 rsa_pss_pss_sha256(0x0809), 1704 rsa_pss_pss_sha384(0x080a), 1705 rsa_pss_pss_sha512(0x080b), 1707 /* Legacy algorithms */ 1708 rsa_pkcs1_sha1(0x0201), 1709 ecdsa_sha1(0x0203), 1711 /* Reserved Code Points */ 1712 private_use(0xFE00..0xFFFF), 1713 (0xFFFF) 1714 } SignatureScheme; 1716 struct { 1717 SignatureScheme supported_signature_algorithms<2..2^16-2>; 1718 } SignatureSchemeList; 1720 Note: This enum is named "SignatureScheme" because there is already a 1721 "SignatureAlgorithm" type in TLS 1.2, which this replaces. We use 1722 the term "signature algorithm" throughout the text. 1724 Each SignatureScheme value lists a single signature algorithm that 1725 the client is willing to verify. The values are indicated in 1726 descending order of preference. Note that a signature algorithm 1727 takes as input an arbitrary-length message, rather than a digest. 1728 Algorithms which traditionally act on a digest should be defined in 1729 TLS to first hash the input with a specified hash algorithm and then 1730 proceed as usual. The code point groups listed above have the 1731 following meanings: 1733 RSASSA-PKCS1-v1_5 algorithms: Indicates a signature algorithm using 1734 RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm 1735 as defined in [SHS]. These values refer solely to signatures 1736 which appear in certificates (see Section 4.4.2.2) and are not 1737 defined for use in signed TLS handshake messages, although they 1738 MAY appear in "signature_algorithms" and 1739 "signature_algorithms_cert" for backward compatibility with TLS 1740 1.2. 1742 ECDSA algorithms: Indicates a signature algorithm using ECDSA 1743 [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA] 1744 and FIPS 186-4 [DSS], and the corresponding hash algorithm as 1745 defined in [SHS]. The signature is represented as a DER-encoded 1746 [X690] ECDSA-Sig-Value structure as defined in [RFC4492]. 1748 RSASSA-PSS RSAE algorithms: Indicates a signature algorithm using 1749 RSASSA-PSS [RFC8017] with mask generation function 1. The digest 1750 used in the mask generation function and the digest being signed 1751 are both the corresponding hash algorithm as defined in [SHS]. 1752 The length of the Salt MUST be equal to the length of the output 1753 of the digest algorithm. If the public key is carried in an X.509 1754 certificate, it MUST use the rsaEncryption OID [RFC5280]. 1756 EdDSA algorithms: Indicates a signature algorithm using EdDSA as 1757 defined in [RFC8032] or its successors. Note that these 1758 correspond to the "PureEdDSA" algorithms and not the "prehash" 1759 variants. 1761 RSASSA-PSS PSS algorithms: Indicates a signature algorithm using 1762 RSASSA-PSS [RFC8017] with mask generation function 1. The digest 1763 used in the mask generation function and the digest being signed 1764 are both the corresponding hash algorithm as defined in [SHS]. 1765 The length of the Salt MUST be equal to the length of the digest 1766 algorithm. If the public key is carried in an X.509 certificate, 1767 it MUST use the RSASSA-PSS OID [RFC5756]. When used in 1768 certificate signatures, the algorithm parameters MUST be DER 1769 encoded. If the corresponding public key's parameters are 1770 present, then the parameters in the signature MUST be identical to 1771 those in the public key. 1773 Legacy algorithms: Indicates algorithms which are being deprecated 1774 because they use algorithms with known weaknesses, specifically 1775 SHA-1 which is used in this context with either (1) RSA using 1776 RSASSA-PKCS1-v1_5 or (2) ECDSA. These values refer solely to 1777 signatures which appear in certificates (see Section 4.4.2.2) and 1778 are not defined for use in signed TLS handshake messages, although 1779 they MAY appear in "signature_algorithms" and 1780 "signature_algorithms_cert" for backward compatibility with TLS 1781 1.2. Endpoints SHOULD NOT negotiate these algorithms but are 1782 permitted to do so solely for backward compatibility. Clients 1783 offering these values MUST list them as the lowest priority 1784 (listed after all other algorithms in SignatureSchemeList). TLS 1785 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no 1786 valid certificate chain can be produced without it (see 1787 Section 4.4.2.2). 1789 The signatures on certificates that are self-signed or certificates 1790 that are trust anchors are not validated, since they begin a 1791 certification path (see [RFC5280], Section 3.2). A certificate that 1792 begins a certification path MAY use a signature algorithm that is not 1793 advertised as being supported in the "signature_algorithms" and 1794 "signature_algorithms_cert" extensions. 1796 Note that TLS 1.2 defines this extension differently. TLS 1.3 1797 implementations willing to negotiate TLS 1.2 MUST behave in 1798 accordance with the requirements of [RFC5246] when negotiating that 1799 version. In particular: 1801 * TLS 1.2 ClientHellos MAY omit this extension. 1803 * In TLS 1.2, the extension contained hash/signature pairs. The 1804 pairs are encoded in two octets, so SignatureScheme values have 1805 been allocated to align with TLS 1.2's encoding. Some legacy 1806 pairs are left unallocated. These algorithms are deprecated as of 1807 TLS 1.3. They MUST NOT be offered or negotiated by any 1808 implementation. In particular, MD5 [SLOTH], SHA-224, and DSA MUST 1809 NOT be used. 1811 * ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature 1812 pairs. However, the old semantics did not constrain the signing 1813 curve. If TLS 1.2 is negotiated, implementations MUST be prepared 1814 to accept a signature that uses any curve that they advertised in 1815 the "supported_groups" extension. 1817 * Implementations that advertise support for RSASSA-PSS (which is 1818 mandatory in TLS 1.3) MUST be prepared to accept a signature using 1819 that scheme even when TLS 1.2 is negotiated. In TLS 1.2, RSASSA- 1820 PSS is used with RSA cipher suites. 1822 4.2.4. Certificate Authorities 1824 The "certificate_authorities" extension is used to indicate the 1825 certificate authorities (CAs) which an endpoint supports and which 1826 SHOULD be used by the receiving endpoint to guide certificate 1827 selection. 1829 The body of the "certificate_authorities" extension consists of a 1830 CertificateAuthoritiesExtension structure. 1832 opaque DistinguishedName<1..2^16-1>; 1834 struct { 1835 DistinguishedName authorities<3..2^16-1>; 1836 } CertificateAuthoritiesExtension; 1838 authorities: A list of the distinguished names [X501] of acceptable 1839 certificate authorities, represented in DER-encoded [X690] format. 1840 These distinguished names specify a desired distinguished name for 1841 a trust anchor or subordinate CA; thus, this message can be used 1842 to describe known trust anchors as well as a desired authorization 1843 space. 1845 The client MAY send the "certificate_authorities" extension in the 1846 ClientHello message. The server MAY send it in the 1847 CertificateRequest message. 1849 The "trusted_ca_keys" extension [RFC6066], which serves a similar 1850 purpose, but is more complicated, is not used in TLS 1.3 (although it 1851 may appear in ClientHello messages from clients which are offering 1852 prior versions of TLS). 1854 4.2.5. OID Filters 1856 The "oid_filters" extension allows servers to provide a list of OID/ 1857 value pairs which it would like the client's certificate to match. 1858 This extension, if provided by the server, MUST only be sent in the 1859 CertificateRequest message. 1861 struct { 1862 opaque certificate_extension_oid<1..2^8-1>; 1863 opaque certificate_extension_values<0..2^16-1>; 1864 } OIDFilter; 1866 struct { 1867 OIDFilter filters<0..2^16-1>; 1868 } OIDFilterExtension; 1870 filters: A list of certificate extension OIDs [RFC5280] with their 1871 allowed value(s) and represented in DER-encoded [X690] format. 1872 Some certificate extension OIDs allow multiple values (e.g., 1873 Extended Key Usage). If the server has included a non-empty 1874 filters list, the client certificate included in the response MUST 1875 contain all of the specified extension OIDs that the client 1876 recognizes. For each extension OID recognized by the client, all 1877 of the specified values MUST be present in the client certificate 1878 (but the certificate MAY have other values as well). However, the 1879 client MUST ignore and skip any unrecognized certificate extension 1880 OIDs. If the client ignored some of the required certificate 1881 extension OIDs and supplied a certificate that does not satisfy 1882 the request, the server MAY at its discretion either continue the 1883 connection without client authentication or abort the handshake 1884 with an "unsupported_certificate" alert. Any given OID MUST NOT 1885 appear more than once in the filters list. 1887 PKIX RFCs define a variety of certificate extension OIDs and their 1888 corresponding value types. Depending on the type, matching 1889 certificate extension values are not necessarily bitwise-equal. It 1890 is expected that TLS implementations will rely on their PKI libraries 1891 to perform certificate selection using certificate extension OIDs. 1893 This document defines matching rules for two standard certificate 1894 extensions defined in [RFC5280]: 1896 * The Key Usage extension in a certificate matches the request when 1897 all key usage bits asserted in the request are also asserted in 1898 the Key Usage certificate extension. 1900 * The Extended Key Usage extension in a certificate matches the 1901 request when all key purpose OIDs present in the request are also 1902 found in the Extended Key Usage certificate extension. The 1903 special anyExtendedKeyUsage OID MUST NOT be used in the request. 1905 Separate specifications may define matching rules for other 1906 certificate extensions. 1908 4.2.6. Post-Handshake Certificate-Based Client Authentication 1910 The "post_handshake_auth" extension is used to indicate that a client 1911 is willing to perform post-handshake authentication (Section 4.6.2). 1912 Servers MUST NOT send a post-handshake CertificateRequest to clients 1913 which do not offer this extension. Servers MUST NOT send this 1914 extension. 1916 struct {} PostHandshakeAuth; 1918 The "extension_data" field of the "post_handshake_auth" extension is 1919 zero length. 1921 4.2.7. Supported Groups 1923 When sent by the client, the "supported_groups" extension indicates 1924 the named groups which the client supports for key exchange, ordered 1925 from most preferred to least preferred. 1927 Note: In versions of TLS prior to TLS 1.3, this extension was named 1928 "elliptic_curves" and only contained elliptic curve groups. See 1929 [RFC8422] and [RFC7919]. This extension was also used to negotiate 1930 ECDSA curves. Signature algorithms are now negotiated independently 1931 (see Section 4.2.3). 1933 The "extension_data" field of this extension contains a 1934 "NamedGroupList" value: 1936 enum { 1938 /* Elliptic Curve Groups (ECDHE) */ 1939 secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), 1940 x25519(0x001D), x448(0x001E), 1942 /* Finite Field Groups (DHE) */ 1943 ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), 1944 ffdhe6144(0x0103), ffdhe8192(0x0104), 1946 /* Reserved Code Points */ 1947 ffdhe_private_use(0x01FC..0x01FF), 1948 ecdhe_private_use(0xFE00..0xFEFF), 1949 (0xFFFF) 1950 } NamedGroup; 1952 struct { 1953 NamedGroup named_group_list<2..2^16-1>; 1954 } NamedGroupList; 1956 Elliptic Curve Groups (ECDHE): Indicates support for the 1957 corresponding named curve, defined in either FIPS 186-4 [DSS] or 1958 in [RFC7748]. Values 0xFE00 through 0xFEFF are reserved for 1959 Private Use [RFC8126]. 1961 Finite Field Groups (DHE): Indicates support for the corresponding 1962 finite field group, defined in [RFC7919]. Values 0x01FC through 1963 0x01FF are reserved for Private Use. 1965 Items in "named_group_list" are ordered according to the sender's 1966 preferences (most preferred choice first). 1968 As of TLS 1.3, servers are permitted to send the "supported_groups" 1969 extension to the client. Clients MUST NOT act upon any information 1970 found in "supported_groups" prior to successful completion of the 1971 handshake but MAY use the information learned from a successfully 1972 completed handshake to change what groups they use in their 1973 "key_share" extension in subsequent connections. If the server has a 1974 group it prefers to the ones in the "key_share" extension but is 1975 still willing to accept the ClientHello, it SHOULD send 1976 "supported_groups" to update the client's view of its preferences; 1977 this extension SHOULD contain all groups the server supports, 1978 regardless of whether they are currently supported by the client. 1980 4.2.8. Key Share 1982 The "key_share" extension contains the endpoint's cryptographic 1983 parameters. 1985 Clients MAY send an empty client_shares list in order to request 1986 group selection from the server, at the cost of an additional round 1987 trip (see Section 4.1.4). 1989 struct { 1990 NamedGroup group; 1991 opaque key_exchange<1..2^16-1>; 1992 } KeyShareEntry; 1994 group: The named group for the key being exchanged. 1996 key_exchange: Key exchange information. The contents of this field 1997 are determined by the specified group and its corresponding 1998 definition. Finite Field Diffie-Hellman [DH76] parameters are 1999 described in Section 4.2.8.1; Elliptic Curve Diffie-Hellman 2000 parameters are described in Section 4.2.8.2. 2002 In the ClientHello message, the "extension_data" field of this 2003 extension contains a "KeyShareClientHello" value: 2005 struct { 2006 KeyShareEntry client_shares<0..2^16-1>; 2007 } KeyShareClientHello; 2009 client_shares: A list of offered KeyShareEntry values in descending 2010 order of client preference. 2012 This list MAY be empty if the client is requesting a 2013 HelloRetryRequest. Each KeyShareEntry value MUST correspond to a 2014 group offered in the "supported_groups" extension and MUST appear in 2015 the same order. However, the values MAY be a non-contiguous subset 2016 of the "supported_groups" extension and MAY omit the most preferred 2017 groups. Such a situation could arise if the most preferred groups 2018 are new and unlikely to be supported in enough places to make 2019 pregenerating key shares for them efficient. 2021 Clients can offer as many KeyShareEntry values as the number of 2022 supported groups it is offering, each representing a single set of 2023 key exchange parameters. For instance, a client might offer shares 2024 for several elliptic curves or multiple FFDHE groups. The 2025 key_exchange values for each KeyShareEntry MUST be generated 2026 independently. Clients MUST NOT offer multiple KeyShareEntry values 2027 for the same group. Clients MUST NOT offer any KeyShareEntry values 2028 for groups not listed in the client's "supported_groups" extension. 2029 Servers MAY check for violations of these rules and abort the 2030 handshake with an "illegal_parameter" alert if one is violated. 2032 In a HelloRetryRequest message, the "extension_data" field of this 2033 extension contains a KeyShareHelloRetryRequest value: 2035 struct { 2036 NamedGroup selected_group; 2037 } KeyShareHelloRetryRequest; 2039 selected_group: The mutually supported group the server intends to 2040 negotiate and is requesting a retried ClientHello/KeyShare for. 2042 Upon receipt of this extension in a HelloRetryRequest, the client 2043 MUST verify that (1) the selected_group field corresponds to a group 2044 which was provided in the "supported_groups" extension in the 2045 original ClientHello and (2) the selected_group field does not 2046 correspond to a group which was provided in the "key_share" extension 2047 in the original ClientHello. If either of these checks fails, then 2048 the client MUST abort the handshake with an "illegal_parameter" 2049 alert. Otherwise, when sending the new ClientHello, the client MUST 2050 replace the original "key_share" extension with one containing only a 2051 new KeyShareEntry for the group indicated in the selected_group field 2052 of the triggering HelloRetryRequest. 2054 In a ServerHello message, the "extension_data" field of this 2055 extension contains a KeyShareServerHello value: 2057 struct { 2058 KeyShareEntry server_share; 2059 } KeyShareServerHello; 2061 server_share: A single KeyShareEntry value that is in the same group 2062 as one of the client's shares. 2064 If using (EC)DHE key establishment, servers offer exactly one 2065 KeyShareEntry in the ServerHello. This value MUST be in the same 2066 group as the KeyShareEntry value offered by the client that the 2067 server has selected for the negotiated key exchange. Servers MUST 2068 NOT send a KeyShareEntry for any group not indicated in the client's 2069 "supported_groups" extension and MUST NOT send a KeyShareEntry when 2070 using the "psk_ke" PskKeyExchangeMode. If using (EC)DHE key 2071 establishment and a HelloRetryRequest containing a "key_share" 2072 extension was received by the client, the client MUST verify that the 2073 selected NamedGroup in the ServerHello is the same as that in the 2074 HelloRetryRequest. If this check fails, the client MUST abort the 2075 handshake with an "illegal_parameter" alert. 2077 4.2.8.1. Diffie-Hellman Parameters 2079 Diffie-Hellman [DH76] parameters for both clients and servers are 2080 encoded in the opaque key_exchange field of a KeyShareEntry in a 2081 KeyShare structure. The opaque value contains the Diffie-Hellman 2082 public value (Y = g^X mod p) for the specified group (see [RFC7919] 2083 for group definitions) encoded as a big-endian integer and padded to 2084 the left with zeros to the size of p in bytes. 2086 Note: For a given Diffie-Hellman group, the padding results in all 2087 public keys having the same length. 2089 Peers MUST validate each other's public key Y by ensuring that 1 < Y 2090 < p-1. This check ensures that the remote peer is properly behaved 2091 and isn't forcing the local system into a small subgroup. 2093 4.2.8.2. ECDHE Parameters 2095 ECDHE parameters for both clients and servers are encoded in the 2096 opaque key_exchange field of a KeyShareEntry in a KeyShare structure. 2098 For secp256r1, secp384r1, and secp521r1, the contents are the 2099 serialized value of the following struct: 2101 struct { 2102 uint8 legacy_form = 4; 2103 opaque X[coordinate_length]; 2104 opaque Y[coordinate_length]; 2105 } UncompressedPointRepresentation; 2107 X and Y, respectively, are the binary representations of the x and y 2108 values in network byte order. There are no internal length markers, 2109 so each number representation occupies as many octets as implied by 2110 the curve parameters. For P-256, this means that each of X and Y use 2111 32 octets, padded on the left by zeros if necessary. For P-384, they 2112 take 48 octets each. For P-521, they take 66 octets each. 2114 For the curves secp256r1, secp384r1, and secp521r1, peers MUST 2115 validate each other's public value Q by ensuring that the point is a 2116 valid point on the elliptic curve. The appropriate validation 2117 procedures are defined in Section 4.3.7 of [ECDSA] and alternatively 2118 in Section 5.6.2.3 of [KEYAGREEMENT]. This process consists of three 2119 steps: (1) verify that Q is not the point at infinity (O), (2) verify 2120 that for Q = (x, y) both integers x and y are in the correct 2121 interval, and (3) ensure that (x, y) is a correct solution to the 2122 elliptic curve equation. For these curves, implementors do not need 2123 to verify membership in the correct subgroup. 2125 For X25519 and X448, the contents of the public value is the K_A or 2126 K_B value described in Section 6 of [RFC7748]. This is 32 bytes for 2127 X25519 and 56 bytes for X448. 2129 Note: Versions of TLS prior to 1.3 permitted point format 2130 negotiation; TLS 1.3 removes this feature in favor of a single point 2131 format for each curve. 2133 4.2.9. Pre-Shared Key Exchange Modes 2135 In order to use PSKs, clients MUST also send a 2136 "psk_key_exchange_modes" extension. The semantics of this extension 2137 are that the client only supports the use of PSKs with these modes, 2138 which restricts both the use of PSKs offered in this ClientHello and 2139 those which the server might supply via NewSessionTicket. 2141 A client MUST provide a "psk_key_exchange_modes" extension if it 2142 offers a "pre_shared_key" extension. If clients offer 2143 "pre_shared_key" without a "psk_key_exchange_modes" extension, 2144 servers MUST abort the handshake. Servers MUST NOT select a key 2145 exchange mode that is not listed by the client. This extension also 2146 restricts the modes for use with PSK resumption. Servers SHOULD NOT 2147 send NewSessionTicket with tickets that are not compatible with the 2148 advertised modes; however, if a server does so, the impact will just 2149 be that the client's attempts at resumption fail. 2151 The server MUST NOT send a "psk_key_exchange_modes" extension. 2153 enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; 2155 struct { 2156 PskKeyExchangeMode ke_modes<1..255>; 2157 } PskKeyExchangeModes; 2159 psk_ke: PSK-only key establishment. In this mode, the server MUST 2160 NOT supply a "key_share" value. 2162 psk_dhe_ke: PSK with (EC)DHE key establishment. In this mode, the 2163 client and server MUST supply "key_share" values as described in 2164 Section 4.2.8. 2166 Any future values that are allocated must ensure that the transmitted 2167 protocol messages unambiguously identify which mode was selected by 2168 the server; at present, this is indicated by the presence of the 2169 "key_share" in the ServerHello. 2171 4.2.10. Early Data Indication 2173 When a PSK is used and early data is allowed for that PSK (see for 2174 instance Appendix B.3.4), the client can send Application Data in its 2175 first flight of messages. If the client opts to do so, it MUST 2176 supply both the "pre_shared_key" and "early_data" extensions. 2178 The "extension_data" field of this extension contains an 2179 "EarlyDataIndication" value. 2181 struct {} Empty; 2183 struct { 2184 select (Handshake.msg_type) { 2185 case new_session_ticket: uint32 max_early_data_size; 2186 case client_hello: Empty; 2187 case encrypted_extensions: Empty; 2188 }; 2189 } EarlyDataIndication; 2191 See Section 4.6.1 for details regarding the use of the 2192 max_early_data_size field. 2194 The parameters for the 0-RTT data (version, symmetric cipher suite, 2195 Application-Layer Protocol Negotiation (ALPN) [RFC7301] protocol, 2196 etc.) are those associated with the PSK in use. For externally 2197 provisioned PSKs, the associated values are those provisioned along 2198 with the key. For PSKs established via a NewSessionTicket message, 2199 the associated values are those which were negotiated in the 2200 connection which established the PSK. The PSK used to encrypt the 2201 early data MUST be the first PSK listed in the client's 2202 "pre_shared_key" extension. 2204 For PSKs provisioned via NewSessionTicket, a server MUST validate 2205 that the ticket age for the selected PSK identity (computed by 2206 subtracting ticket_age_add from PskIdentity.obfuscated_ticket_age 2207 modulo 2^32) is within a small tolerance of the time since the ticket 2208 was issued (see Section 8). If it is not, the server SHOULD proceed 2209 with the handshake but reject 0-RTT, and SHOULD NOT take any other 2210 action that assumes that this ClientHello is fresh. 2212 0-RTT messages sent in the first flight have the same (encrypted) 2213 content types as messages of the same type sent in other flights 2214 (handshake and application_data) but are protected under different 2215 keys. After receiving the server's Finished message, if the server 2216 has accepted early data, an EndOfEarlyData message will be sent to 2217 indicate the key change. This message will be encrypted with the 2218 0-RTT traffic keys. 2220 A server which receives an "early_data" extension MUST behave in one 2221 of three ways: 2223 * Ignore the extension and return a regular 1-RTT response. The 2224 server then skips past early data by attempting to deprotect 2225 received records using the handshake traffic key, discarding 2226 records which fail deprotection (up to the configured 2227 max_early_data_size). Once a record is deprotected successfully, 2228 it is treated as the start of the client's second flight and the 2229 server proceeds as with an ordinary 1-RTT handshake. 2231 * Request that the client send another ClientHello by responding 2232 with a HelloRetryRequest. A client MUST NOT include the 2233 "early_data" extension in its followup ClientHello. The server 2234 then ignores early data by skipping all records with an external 2235 content type of "application_data" (indicating that they are 2236 encrypted), up to the configured max_early_data_size. 2238 * Return its own "early_data" extension in EncryptedExtensions, 2239 indicating that it intends to process the early data. It is not 2240 possible for the server to accept only a subset of the early data 2241 messages. Even though the server sends a message accepting early 2242 data, the actual early data itself may already be in flight by the 2243 time the server generates this message. 2245 In order to accept early data, the server MUST have selected the 2246 first key offered in the client's "pre_shared_key" extension. In 2247 addition, it MUST verify that the following values are the same as 2248 those associated with the selected PSK: 2250 * The selected TLS version number 2252 * The selected cipher suite 2254 * The selected ALPN [RFC7301] protocol, if any 2256 These requirements are a superset of those needed to perform a 1-RTT 2257 handshake using the PSK in question. 2259 Future extensions MUST define their interaction with 0-RTT. 2261 If any of these checks fail, the server MUST NOT respond with the 2262 extension and must discard all the first-flight data using one of the 2263 first two mechanisms listed above (thus falling back to 1-RTT or 2264 2-RTT). If the client attempts a 0-RTT handshake but the server 2265 rejects it, the server will generally not have the 0-RTT record 2266 protection keys and must instead use trial decryption (either with 2267 the 1-RTT handshake keys or by looking for a cleartext ClientHello in 2268 the case of a HelloRetryRequest) to find the first non-0-RTT message. 2270 If the server chooses to accept the "early_data" extension, then it 2271 MUST comply with the same error-handling requirements specified for 2272 all records when processing early data records. Specifically, if the 2273 server fails to decrypt a 0-RTT record following an accepted 2274 "early_data" extension, it MUST terminate the connection with a 2275 "bad_record_mac" alert as per Section 5.2. 2277 If the server rejects the "early_data" extension, the client 2278 application MAY opt to retransmit the Application Data previously 2279 sent in early data once the handshake has been completed. Note that 2280 automatic retransmission of early data could result in incorrect 2281 assumptions regarding the status of the connection. For instance, 2282 when the negotiated connection selects a different ALPN protocol from 2283 what was used for the early data, an application might need to 2284 construct different messages. Similarly, if early data assumes 2285 anything about the connection state, it might be sent in error after 2286 the handshake completes. 2288 A TLS implementation SHOULD NOT automatically resend early data; 2289 applications are in a better position to decide when retransmission 2290 is appropriate. A TLS implementation MUST NOT automatically resend 2291 early data unless the negotiated connection selects the same ALPN 2292 protocol. 2294 4.2.11. Pre-Shared Key Extension 2296 The "pre_shared_key" extension is used to negotiate the identity of 2297 the pre-shared key to be used with a given handshake in association 2298 with PSK key establishment. 2300 The "extension_data" field of this extension contains a 2301 "PreSharedKeyExtension" value: 2303 struct { 2304 opaque identity<1..2^16-1>; 2305 uint32 obfuscated_ticket_age; 2306 } PskIdentity; 2308 opaque PskBinderEntry<32..255>; 2310 struct { 2311 PskIdentity identities<7..2^16-1>; 2312 PskBinderEntry binders<33..2^16-1>; 2313 } OfferedPsks; 2315 struct { 2316 select (Handshake.msg_type) { 2317 case client_hello: OfferedPsks; 2318 case server_hello: uint16 selected_identity; 2319 }; 2320 } PreSharedKeyExtension; 2322 identity: A label for a key. For instance, a ticket (as defined in 2323 Appendix B.3.4) or a label for a pre-shared key established 2324 externally. 2326 obfuscated_ticket_age: An obfuscated version of the age of the key. 2327 Section 4.2.11.1 describes how to form this value for identities 2328 established via the NewSessionTicket message. For identities 2329 established externally, an obfuscated_ticket_age of 0 SHOULD be 2330 used, and servers MUST ignore the value. 2332 identities: A list of the identities that the client is willing to 2333 negotiate with the server. If sent alongside the "early_data" 2334 extension (see Section 4.2.10), the first identity is the one used 2335 for 0-RTT data. 2337 binders: A series of HMAC values, one for each value in the 2338 identities list and in the same order, computed as described 2339 below. 2341 selected_identity: The server's chosen identity expressed as a 2342 (0-based) index into the identities in the client's 2343 "OfferedPsks.identities" list. 2345 Each PSK is associated with a single Hash algorithm. For PSKs 2346 established via the ticket mechanism (Section 4.6.1), this is the KDF 2347 Hash algorithm on the connection where the ticket was established. 2348 For externally established PSKs, the Hash algorithm MUST be set when 2349 the PSK is established or default to SHA-256 if no such algorithm is 2350 defined. The server MUST ensure that it selects a compatible PSK (if 2351 any) and cipher suite. 2353 In TLS versions prior to TLS 1.3, the Server Name Indication (SNI) 2354 value was intended to be associated with the session (Section 3 of 2355 [RFC6066]), with the server being required to enforce that the SNI 2356 value associated with the session matches the one specified in the 2357 resumption handshake. However, in reality the implementations were 2358 not consistent on which of two supplied SNI values they would use, 2359 leading to the consistency requirement being de facto enforced by the 2360 clients. In TLS 1.3, the SNI value is always explicitly specified in 2361 the resumption handshake, and there is no need for the server to 2362 associate an SNI value with the ticket. Clients, however, SHOULD 2363 store the SNI with the PSK to fulfill the requirements of 2364 Section 4.6.1. 2366 Implementor's note: When session resumption is the primary use case 2367 of PSKs, the most straightforward way to implement the PSK/cipher 2368 suite matching requirements is to negotiate the cipher suite first 2369 and then exclude any incompatible PSKs. Any unknown PSKs (e.g., ones 2370 not in the PSK database or encrypted with an unknown key) SHOULD 2371 simply be ignored. If no acceptable PSKs are found, the server 2372 SHOULD perform a non-PSK handshake if possible. If backward 2373 compatibility is important, client-provided, externally established 2374 PSKs SHOULD influence cipher suite selection. 2376 Prior to accepting PSK key establishment, the server MUST validate 2377 the corresponding binder value (see Section 4.2.11.2 below). If this 2378 value is not present or does not validate, the server MUST abort the 2379 handshake. Servers SHOULD NOT attempt to validate multiple binders; 2380 rather, they SHOULD select a single PSK and validate solely the 2381 binder that corresponds to that PSK. See Section 8.2 and 2382 Appendix F.6 for the security rationale for this requirement. In 2383 order to accept PSK key establishment, the server sends a 2384 "pre_shared_key" extension indicating the selected identity. 2386 Clients MUST verify that the server's selected_identity is within the 2387 range supplied by the client, that the server selected a cipher suite 2388 indicating a Hash associated with the PSK, and that a server 2389 "key_share" extension is present if required by the ClientHello 2390 "psk_key_exchange_modes" extension. If these values are not 2391 consistent, the client MUST abort the handshake with an 2392 "illegal_parameter" alert. 2394 If the server supplies an "early_data" extension, the client MUST 2395 verify that the server's selected_identity is 0. If any other value 2396 is returned, the client MUST abort the handshake with an 2397 "illegal_parameter" alert. 2399 The "pre_shared_key" extension MUST be the last extension in the 2400 ClientHello (this facilitates implementation as described below). 2401 Servers MUST check that it is the last extension and otherwise fail 2402 the handshake with an "illegal_parameter" alert. 2404 4.2.11.1. Ticket Age 2406 The client's view of the age of a ticket is the time since the 2407 receipt of the NewSessionTicket message. Clients MUST NOT attempt to 2408 use tickets which have ages greater than the "ticket_lifetime" value 2409 which was provided with the ticket. The "obfuscated_ticket_age" 2410 field of each PskIdentity contains an obfuscated version of the 2411 ticket age formed by taking the age in milliseconds and adding the 2412 "ticket_age_add" value that was included with the ticket (see 2413 Section 4.6.1), modulo 2^32. This addition prevents passive 2414 observers from correlating connections unless tickets are reused. 2415 Note that the "ticket_lifetime" field in the NewSessionTicket message 2416 is in seconds but the "obfuscated_ticket_age" is in milliseconds. 2417 Because ticket lifetimes are restricted to a week, 32 bits is enough 2418 to represent any plausible age, even in milliseconds. 2420 4.2.11.2. PSK Binder 2422 The PSK binder value forms a binding between a PSK and the current 2423 handshake, as well as a binding between the handshake in which the 2424 PSK was generated (if via a NewSessionTicket message) and the current 2425 handshake. Each entry in the binders list is computed as an HMAC 2426 over a transcript hash (see Section 4.4.1) containing a partial 2427 ClientHello up to and including the PreSharedKeyExtension.identities 2428 field. That is, it includes all of the ClientHello but not the 2429 binders list itself. The length fields for the message (including 2430 the overall length, the length of the extensions block, and the 2431 length of the "pre_shared_key" extension) are all set as if binders 2432 of the correct lengths were present. 2434 The PskBinderEntry is computed in the same way as the Finished 2435 message (Section 4.4.4) but with the BaseKey being the binder_key 2436 derived via the key schedule from the corresponding PSK which is 2437 being offered (see Section 7.1). 2439 If the handshake includes a HelloRetryRequest, the initial 2440 ClientHello and HelloRetryRequest are included in the transcript 2441 along with the new ClientHello. For instance, if the client sends 2442 ClientHello1, its binder will be computed over: 2444 Transcript-Hash(Truncate(ClientHello1)) 2446 Where Truncate() removes the binders list from the ClientHello. 2448 If the server responds with a HelloRetryRequest and the client then 2449 sends ClientHello2, its binder will be computed over: 2451 Transcript-Hash(ClientHello1, 2452 HelloRetryRequest, 2453 Truncate(ClientHello2)) 2455 The full ClientHello1/ClientHello2 is included in all other handshake 2456 hash computations. Note that in the first flight, 2457 Truncate(ClientHello1) is hashed directly, but in the second flight, 2458 ClientHello1 is hashed and then reinjected as a "message_hash" 2459 message, as described in Section 4.4.1. 2461 4.2.11.3. Processing Order 2463 Clients are permitted to "stream" 0-RTT data until they receive the 2464 server's Finished, only then sending the EndOfEarlyData message, 2465 followed by the rest of the handshake. In order to avoid deadlocks, 2466 when accepting "early_data", servers MUST process the client's 2467 ClientHello and then immediately send their flight of messages, 2468 rather than waiting for the client's EndOfEarlyData message before 2469 sending its ServerHello. 2471 4.3. Server Parameters 2473 The next two messages from the server, EncryptedExtensions and 2474 CertificateRequest, contain information from the server that 2475 determines the rest of the handshake. These messages are encrypted 2476 with keys derived from the server_handshake_traffic_secret. 2478 4.3.1. Encrypted Extensions 2480 In all handshakes, the server MUST send the EncryptedExtensions 2481 message immediately after the ServerHello message. This is the first 2482 message that is encrypted under keys derived from the 2483 server_handshake_traffic_secret. 2485 The EncryptedExtensions message contains extensions that can be 2486 protected, i.e., any which are not needed to establish the 2487 cryptographic context but which are not associated with individual 2488 certificates. The client MUST check EncryptedExtensions for the 2489 presence of any forbidden extensions and if any are found MUST abort 2490 the handshake with an "illegal_parameter" alert. 2492 Structure of this message: 2494 struct { 2495 Extension extensions<0..2^16-1>; 2496 } EncryptedExtensions; 2498 extensions: A list of extensions. For more information, see the 2499 table in Section 4.2. 2501 4.3.2. Certificate Request 2503 A server which is authenticating with a certificate MAY optionally 2504 request a certificate from the client. This message, if sent, MUST 2505 follow EncryptedExtensions. 2507 Structure of this message: 2509 struct { 2510 opaque certificate_request_context<0..2^8-1>; 2511 Extension extensions<0..2^16-1>; 2512 } CertificateRequest; 2514 certificate_request_context: An opaque string which identifies the 2515 certificate request and which will be echoed in the client's 2516 Certificate message. The certificate_request_context MUST be 2517 unique within the scope of this connection (thus preventing replay 2518 of client CertificateVerify messages). This field SHALL be zero 2519 length unless used for the post-handshake authentication exchanges 2520 described in Section 4.6.2. When requesting post-handshake 2521 authentication, the server SHOULD make the context unpredictable 2522 to the client (e.g., by randomly generating it) in order to 2523 prevent an attacker who has temporary access to the client's 2524 private key from pre-computing valid CertificateVerify messages. 2526 extensions: A list of extensions describing the parameters of the 2527 certificate being requested. The "signature_algorithms" extension 2528 MUST be specified, and other extensions may optionally be included 2529 if defined for this message. Clients MUST ignore unrecognized 2530 extensions. 2532 In prior versions of TLS, the CertificateRequest message carried a 2533 list of signature algorithms and certificate authorities which the 2534 server would accept. In TLS 1.3, the former is expressed by sending 2535 the "signature_algorithms" and optionally "signature_algorithms_cert" 2536 extensions. The latter is expressed by sending the 2537 "certificate_authorities" extension (see Section 4.2.4). 2539 Servers which are authenticating with a resumption PSK MUST NOT send 2540 the CertificateRequest message in the main handshake, though they MAY 2541 send it in post-handshake authentication (see Section 4.6.2) provided 2542 that the client has sent the "post_handshake_auth" extension (see 2543 Section 4.2.6). Servers which are authenticating with an external 2544 PSK MUST NOT send the CertificateRequest message either in the main 2545 handshake or request post-handshake authentication. Future 2546 specifications MAY provide an extension to permit this. 2548 4.4. Authentication Messages 2550 As discussed in Section 2, TLS generally uses a common set of 2551 messages for authentication, key confirmation, and handshake 2552 integrity: Certificate, CertificateVerify, and Finished. (The PSK 2553 binders also perform key confirmation, in a similar fashion.) These 2554 three messages are always sent as the last messages in their 2555 handshake flight. The Certificate and CertificateVerify messages are 2556 only sent under certain circumstances, as defined below. The 2557 Finished message is always sent as part of the Authentication Block. 2558 These messages are encrypted under keys derived from the 2559 [sender]_handshake_traffic_secret. 2561 The computations for the Authentication messages all uniformly take 2562 the following inputs: 2564 * The certificate and signing key to be used. 2566 * A Handshake Context consisting of the list of messages to be 2567 included in the transcript hash. 2569 * A Base Key to be used to compute a MAC key. 2571 Based on these inputs, the messages then contain: 2573 Certificate The certificate to be used for authentication, and any 2574 supporting certificates in the chain. Note that certificate-based 2575 client authentication is not available in PSK handshake flows 2576 (including 0-RTT). 2578 CertificateVerify: A signature over the value Transcript- 2579 Hash(Handshake Context, Certificate) 2581 Finished: A MAC over the value Transcript-Hash(Handshake Context, 2582 Certificate, CertificateVerify) using a MAC key derived from the 2583 Base Key. 2585 The following table defines the Handshake Context and MAC Base Key 2586 for each scenario: 2588 +=========+====================+====================================+ 2589 |Mode |Handshake Context |Base Key | 2590 +=========+====================+====================================+ 2591 |Server |ClientHello ... |server_handshake_traffic_secret | 2592 | |later of | | 2593 | |EncryptedExtensions/| | 2594 | |CertificateRequest | | 2595 +---------+--------------------+------------------------------------+ 2596 |Client |ClientHello ... |client_handshake_traffic_secret | 2597 | |later of server | | 2598 | |Finished/ | | 2599 | |EndOfEarlyData | | 2600 +---------+--------------------+------------------------------------+ 2601 |Post- |ClientHello ... |client_application_traffic_secret_N | 2602 |Handshake|client Finished + | | 2603 | |CertificateRequest | | 2604 +---------+--------------------+------------------------------------+ 2606 Table 2: Authentication Inputs 2608 4.4.1. The Transcript Hash 2610 Many of the cryptographic computations in TLS make use of a 2611 transcript hash. This value is computed by hashing the concatenation 2612 of each included handshake message, including the handshake message 2613 header carrying the handshake message type and length fields, but not 2614 including record layer headers. I.e., 2616 Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn) 2618 As an exception to this general rule, when the server responds to a 2619 ClientHello with a HelloRetryRequest, the value of ClientHello1 is 2620 replaced with a special synthetic handshake message of handshake type 2621 "message_hash" containing Hash(ClientHello1). I.e., 2623 Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) = 2624 Hash(message_hash || /* Handshake type */ 2625 00 00 Hash.length || /* Handshake message length (bytes) */ 2626 Hash(ClientHello1) || /* Hash of ClientHello1 */ 2627 HelloRetryRequest || ... || Mn) 2629 The reason for this construction is to allow the server to do a 2630 stateless HelloRetryRequest by storing just the hash of ClientHello1 2631 in the cookie, rather than requiring it to export the entire 2632 intermediate hash state (see Section 4.2.2). 2634 For concreteness, the transcript hash is always taken from the 2635 following sequence of handshake messages, starting at the first 2636 ClientHello and including only those messages that were sent: 2637 ClientHello, HelloRetryRequest, ClientHello, ServerHello, 2638 EncryptedExtensions, server CertificateRequest, server Certificate, 2639 server CertificateVerify, server Finished, EndOfEarlyData, client 2640 Certificate, client CertificateVerify, client Finished. 2642 In general, implementations can implement the transcript by keeping a 2643 running transcript hash value based on the negotiated hash. Note, 2644 however, that subsequent post-handshake authentications do not 2645 include each other, just the messages through the end of the main 2646 handshake. 2648 4.4.2. Certificate 2650 This message conveys the endpoint's certificate chain to the peer. 2652 The server MUST send a Certificate message whenever the agreed-upon 2653 key exchange method uses certificates for authentication (this 2654 includes all key exchange methods defined in this document except 2655 PSK). 2657 The client MUST send a Certificate message if and only if the server 2658 has requested certificate-based client authentication via a 2659 CertificateRequest message (Section 4.3.2). If the server requests 2660 certificate-based client authentication but no suitable certificate 2661 is available, the client MUST send a Certificate message containing 2662 no certificates (i.e., with the "certificate_list" field having 2663 length 0). A Finished message MUST be sent regardless of whether the 2664 Certificate message is empty. 2666 Structure of this message: 2668 enum { 2669 X509(0), 2670 RawPublicKey(2), 2671 (255) 2672 } CertificateType; 2674 struct { 2675 select (certificate_type) { 2676 case RawPublicKey: 2677 /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ 2678 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 2680 case X509: 2681 opaque cert_data<1..2^24-1>; 2682 }; 2683 Extension extensions<0..2^16-1>; 2684 } CertificateEntry; 2686 struct { 2687 opaque certificate_request_context<0..2^8-1>; 2688 CertificateEntry certificate_list<0..2^24-1>; 2689 } Certificate; 2691 certificate_request_context: If this message is in response to a 2692 CertificateRequest, the value of certificate_request_context in 2693 that message. Otherwise (in the case of server authentication), 2694 this field SHALL be zero length. 2696 certificate_list: A list (chain) of CertificateEntry structures, 2697 each containing a single certificate and list of extensions. 2699 extensions: A list of extension values for the CertificateEntry. 2700 The "Extension" format is defined in Section 4.2. Valid 2701 extensions for server certificates at present include the OCSP 2702 Status extension [RFC6066] and the SignedCertificateTimestamp 2703 extension [RFC6962]; future extensions may be defined for this 2704 message as well. Extensions in the Certificate message from the 2705 server MUST correspond to ones from the ClientHello message. 2706 Extensions in the Certificate message from the client MUST 2707 correspond to extensions in the CertificateRequest message from 2708 the server. If an extension applies to the entire chain, it 2709 SHOULD be included in the first CertificateEntry. 2711 If the corresponding certificate type extension 2712 ("server_certificate_type" or "client_certificate_type") was not 2713 negotiated in EncryptedExtensions, or the X.509 certificate type was 2714 negotiated, then each CertificateEntry contains a DER-encoded X.509 2715 certificate. The sender's certificate MUST come in the first 2716 CertificateEntry in the list. Each following certificate SHOULD 2717 directly certify the one immediately preceding it. Because 2718 certificate validation requires that trust anchors be distributed 2719 independently, a certificate that specifies a trust anchor MAY be 2720 omitted from the chain, provided that supported peers are known to 2721 possess any omitted certificates. 2723 Note: Prior to TLS 1.3, "certificate_list" ordering required each 2724 certificate to certify the one immediately preceding it; however, 2725 some implementations allowed some flexibility. Servers sometimes 2726 send both a current and deprecated intermediate for transitional 2727 purposes, and others are simply configured incorrectly, but these 2728 cases can nonetheless be validated properly. For maximum 2729 compatibility, all implementations SHOULD be prepared to handle 2730 potentially extraneous certificates and arbitrary orderings from any 2731 TLS version, with the exception of the end-entity certificate which 2732 MUST be first. 2734 If the RawPublicKey certificate type was negotiated, then the 2735 certificate_list MUST contain no more than one CertificateEntry, 2736 which contains an ASN1_subjectPublicKeyInfo value as defined in 2737 [RFC7250], Section 3. 2739 The OpenPGP certificate type [RFC6091] MUST NOT be used with TLS 1.3. 2741 The server's certificate_list MUST always be non-empty. A client 2742 will send an empty certificate_list if it does not have an 2743 appropriate certificate to send in response to the server's 2744 authentication request. 2746 4.4.2.1. OCSP Status and SCT Extensions 2748 [RFC6066] and [RFC6961] provide extensions to negotiate the server 2749 sending OCSP responses to the client. In TLS 1.2 and below, the 2750 server replies with an empty extension to indicate negotiation of 2751 this extension and the OCSP information is carried in a 2752 CertificateStatus message. In TLS 1.3, the server's OCSP information 2753 is carried in an extension in the CertificateEntry containing the 2754 associated certificate. Specifically, the body of the 2755 "status_request" extension from the server MUST be a 2756 CertificateStatus structure as defined in [RFC6066], which is 2757 interpreted as defined in [RFC6960]. 2759 Note: The status_request_v2 extension [RFC6961] is deprecated. TLS 2760 1.3 servers MUST NOT act upon its presence or information in it when 2761 processing ClientHello messages; in particular, they MUST NOT send 2762 the status_request_v2 extension in the EncryptedExtensions, 2763 CertificateRequest, or Certificate messages. TLS 1.3 servers MUST be 2764 able to process ClientHello messages that include it, as it MAY be 2765 sent by clients that wish to use it in earlier protocol versions. 2767 A server MAY request that a client present an OCSP response with its 2768 certificate by sending an empty "status_request" extension in its 2769 CertificateRequest message. If the client opts to send an OCSP 2770 response, the body of its "status_request" extension MUST be a 2771 CertificateStatus structure as defined in [RFC6066]. 2773 Similarly, [RFC6962] provides a mechanism for a server to send a 2774 Signed Certificate Timestamp (SCT) as an extension in the ServerHello 2775 in TLS 1.2 and below. In TLS 1.3, the server's SCT information is 2776 carried in an extension in the CertificateEntry. 2778 4.4.2.2. Server Certificate Selection 2780 The following rules apply to the certificates sent by the server: 2782 * The certificate type MUST be X.509v3 [RFC5280], unless explicitly 2783 negotiated otherwise (e.g., [RFC7250]). 2785 * The end-entity certificate MUST allow the key to be used for 2786 signing with a signature scheme indicated in the client's 2787 "signature_algorithms" extension (see Section 4.2.3). That is, 2788 the digitalSignature bit MUST be set if the Key Usage extension is 2789 present, and the public key (with associated restrictions) MUST be 2790 compatible with some supported signature scheme. 2792 * The "server_name" [RFC6066] and "certificate_authorities" 2793 extensions are used to guide certificate selection. As servers 2794 MAY require the presence of the "server_name" extension, clients 2795 SHOULD send this extension when the server is identified by name. 2797 All certificates provided by the server MUST be signed by a signature 2798 algorithm advertised by the client, if it is able to provide such a 2799 chain (see Section 4.2.3). Certificates that are self-signed or 2800 certificates that are expected to be trust anchors are not validated 2801 as part of the chain and therefore MAY be signed with any algorithm. 2803 If the server cannot produce a certificate chain that is signed only 2804 via the indicated supported algorithms, then it SHOULD continue the 2805 handshake by sending the client a certificate chain of its choice 2806 that may include algorithms that are not known to be supported by the 2807 client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash 2808 algorithm in general, but MAY do so if the client's advertisement 2809 permits it, and MUST NOT do so otherwise. 2811 If the client cannot construct an acceptable chain using the provided 2812 certificates and decides to abort the handshake, then it MUST abort 2813 the handshake with an appropriate certificate-related alert (by 2814 default, "unsupported_certificate"; see Section 6.2 for more 2815 information). 2817 If the server has multiple certificates, it chooses one of them based 2818 on the above-mentioned criteria (in addition to other criteria, such 2819 as transport-layer endpoint, local configuration, and preferences). 2821 4.4.2.3. Client Certificate Selection 2823 The following rules apply to certificates sent by the client: 2825 * The certificate type MUST be X.509v3 [RFC5280], unless explicitly 2826 negotiated otherwise (e.g., [RFC7250]). 2828 * If the "certificate_authorities" extension in the 2829 CertificateRequest message was present, at least one of the 2830 certificates in the certificate chain SHOULD be issued by one of 2831 the listed CAs. 2833 * The certificates MUST be signed using an acceptable signature 2834 algorithm, as described in Section 4.3.2. Note that this relaxes 2835 the constraints on certificate-signing algorithms found in prior 2836 versions of TLS. 2838 * If the CertificateRequest message contained a non-empty 2839 "oid_filters" extension, the end-entity certificate MUST match the 2840 extension OIDs that are recognized by the client, as described in 2841 Section 4.2.5. 2843 4.4.2.4. Receiving a Certificate Message 2845 In general, detailed certificate validation procedures are out of 2846 scope for TLS (see [RFC5280]). This section provides TLS-specific 2847 requirements. 2849 If the server supplies an empty Certificate message, the client MUST 2850 abort the handshake with a "decode_error" alert. 2852 If the client does not send any certificates (i.e., it sends an empty 2853 Certificate message), the server MAY at its discretion either 2854 continue the handshake without client authentication, or abort the 2855 handshake with a "certificate_required" alert. Also, if some aspect 2856 of the certificate chain was unacceptable (e.g., it was not signed by 2857 a known, trusted CA), the server MAY at its discretion either 2858 continue the handshake (considering the client unauthenticated) or 2859 abort the handshake. 2861 Any endpoint receiving any certificate which it would need to 2862 validate using any signature algorithm using an MD5 hash MUST abort 2863 the handshake with a "bad_certificate" alert. SHA-1 is deprecated 2864 and it is RECOMMENDED that any endpoint receiving any certificate 2865 which it would need to validate using any signature algorithm using a 2866 SHA-1 hash abort the handshake with a "bad_certificate" alert. For 2867 clarity, this means that endpoints can accept these algorithms for 2868 certificates that are self-signed or are trust anchors. 2870 All endpoints are RECOMMENDED to transition to SHA-256 or better as 2871 soon as possible to maintain interoperability with implementations 2872 currently in the process of phasing out SHA-1 support. 2874 Note that a certificate containing a key for one signature algorithm 2875 MAY be signed using a different signature algorithm (for instance, an 2876 RSA key signed with an ECDSA key). 2878 4.4.3. Certificate Verify 2880 This message is used to provide explicit proof that an endpoint 2881 possesses the private key corresponding to its certificate. The 2882 CertificateVerify message also provides integrity for the handshake 2883 up to this point. Servers MUST send this message when authenticating 2884 via a certificate. Clients MUST send this message whenever 2885 authenticating via a certificate (i.e., when the Certificate message 2886 is non-empty). When sent, this message MUST appear immediately after 2887 the Certificate message and immediately prior to the Finished 2888 message. 2890 Structure of this message: 2892 struct { 2893 SignatureScheme algorithm; 2894 opaque signature<0..2^16-1>; 2895 } CertificateVerify; 2897 The algorithm field specifies the signature algorithm used (see 2898 Section 4.2.3 for the definition of this type). The signature is a 2899 digital signature using that algorithm. The content that is covered 2900 under the signature is the hash output as described in Section 4.4.1, 2901 namely: 2903 Transcript-Hash(Handshake Context, Certificate) 2905 The digital signature is then computed over the concatenation of: 2907 * A string that consists of octet 32 (0x20) repeated 64 times 2909 * The context string (defined below) 2911 * A single 0 byte which serves as the separator 2913 * The content to be signed 2915 This structure is intended to prevent an attack on previous versions 2916 of TLS in which the ServerKeyExchange format meant that attackers 2917 could obtain a signature of a message with a chosen 32-byte prefix 2918 (ClientHello.random). The initial 64-byte pad clears that prefix 2919 along with the server-controlled ServerHello.random. 2921 The context string for a server signature is "TLS 1.3, server 2922 CertificateVerify" The context string for a client signature is "TLS 2923 1.3, client CertificateVerify" It is used to provide separation 2924 between signatures made in different contexts, helping against 2925 potential cross-protocol attacks. 2927 For example, if the transcript hash was 32 bytes of 01 (this length 2928 would make sense for SHA-256), the content covered by the digital 2929 signature for a server CertificateVerify would be: 2931 2020202020202020202020202020202020202020202020202020202020202020 2932 2020202020202020202020202020202020202020202020202020202020202020 2933 544c5320312e332c207365727665722043657274696669636174655665726966 2934 79 2935 00 2936 0101010101010101010101010101010101010101010101010101010101010101 2938 On the sender side, the process for computing the signature field of 2939 the CertificateVerify message takes as input: 2941 * The content covered by the digital signature 2943 * The private signing key corresponding to the certificate sent in 2944 the previous message 2946 If the CertificateVerify message is sent by a server, the signature 2947 algorithm MUST be one offered in the client's "signature_algorithms" 2948 extension unless no valid certificate chain can be produced without 2949 unsupported algorithms (see Section 4.2.3). 2951 If sent by a client, the signature algorithm used in the signature 2952 MUST be one of those present in the supported_signature_algorithms 2953 field of the "signature_algorithms" extension in the 2954 CertificateRequest message. 2956 In addition, the signature algorithm MUST be compatible with the key 2957 in the sender's end-entity certificate. RSA signatures MUST use an 2958 RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 2959 algorithms appear in "signature_algorithms". The SHA-1 algorithm 2960 MUST NOT be used in any signatures of CertificateVerify messages. 2961 All SHA-1 signature algorithms in this specification are defined 2962 solely for use in legacy certificates and are not valid for 2963 CertificateVerify signatures. 2965 The receiver of a CertificateVerify message MUST verify the signature 2966 field. The verification process takes as input: 2968 * The content covered by the digital signature 2970 * The public key contained in the end-entity certificate found in 2971 the associated Certificate message 2973 * The digital signature received in the signature field of the 2974 CertificateVerify message 2976 If the verification fails, the receiver MUST terminate the handshake 2977 with a "decrypt_error" alert. 2979 4.4.4. Finished 2981 The Finished message is the final message in the Authentication 2982 Block. It is essential for providing authentication of the handshake 2983 and of the computed keys. 2985 Recipients of Finished messages MUST verify that the contents are 2986 correct and if incorrect MUST terminate the connection with a 2987 "decrypt_error" alert. 2989 Once a side has sent its Finished message and has received and 2990 validated the Finished message from its peer, it may begin to send 2991 and receive Application Data over the connection. There are two 2992 settings in which it is permitted to send data prior to receiving the 2993 peer's Finished: 2995 1. Clients sending 0-RTT data as described in Section 4.2.10. 2997 2. Servers MAY send data after sending their first flight, but 2998 because the handshake is not yet complete, they have no assurance 2999 of either the peer's identity or its liveness (i.e., the 3000 ClientHello might have been replayed). 3002 The key used to compute the Finished message is computed from the 3003 Base Key defined in Section 4.4 using HKDF (see Section 7.1). 3004 Specifically: 3006 finished_key = 3007 HKDF-Expand-Label(BaseKey, "finished", "", Hash.length) 3009 Structure of this message: 3011 struct { 3012 opaque verify_data[Hash.length]; 3013 } Finished; 3015 The verify_data value is computed as follows: 3017 verify_data = 3018 HMAC(finished_key, 3019 Transcript-Hash(Handshake Context, 3020 Certificate*, CertificateVerify*)) 3022 * Only included if present. 3024 HMAC [RFC2104] uses the Hash algorithm for the handshake. As noted 3025 above, the HMAC input can generally be implemented by a running hash, 3026 i.e., just the handshake hash at this point. 3028 In previous versions of TLS, the verify_data was always 12 octets 3029 long. In TLS 1.3, it is the size of the HMAC output for the Hash 3030 used for the handshake. 3032 Note: Alerts and any other non-handshake record types are not 3033 handshake messages and are not included in the hash computations. 3035 Any records following a Finished message MUST be encrypted under the 3036 appropriate application traffic key as described in Section 7.2. In 3037 particular, this includes any alerts sent by the server in response 3038 to client Certificate and CertificateVerify messages. 3040 4.5. End of Early Data 3042 struct {} EndOfEarlyData; 3044 If the server sent an "early_data" extension in EncryptedExtensions, 3045 the client MUST send an EndOfEarlyData message after receiving the 3046 server Finished. If the server does not send an "early_data" 3047 extension in EncryptedExtensions, then the client MUST NOT send an 3048 EndOfEarlyData message. This message indicates that all 0-RTT 3049 application_data messages, if any, have been transmitted and that the 3050 following records are protected under handshake traffic keys. 3051 Servers MUST NOT send this message, and clients receiving it MUST 3052 terminate the connection with an "unexpected_message" alert. This 3053 message is encrypted under keys derived from the 3054 client_early_traffic_secret. 3056 4.6. Post-Handshake Messages 3058 TLS also allows other messages to be sent after the main handshake. 3059 These messages use a handshake content type and are encrypted under 3060 the appropriate application traffic key. 3062 4.6.1. New Session Ticket Message 3064 At any time after the server has received the client Finished 3065 message, it MAY send a NewSessionTicket message. This message 3066 creates a unique association between the ticket value and a secret 3067 PSK derived from the resumption secret (see Section 7). 3069 The client MAY use this PSK for future handshakes by including the 3070 ticket value in the "pre_shared_key" extension in its ClientHello 3071 (Section 4.2.11). Resumption MAY be done while the original 3072 connection is still open. Servers MAY send multiple tickets on a 3073 single connection, either immediately after each other or after 3074 specific events (see Appendix C.4). For instance, the server might 3075 send a new ticket after post-handshake authentication in order to 3076 encapsulate the additional client authentication state. Multiple 3077 tickets are useful for clients for a variety of purposes, including: 3079 * Opening multiple parallel HTTP connections. 3081 * Performing connection racing across interfaces and address 3082 families via (for example) Happy Eyeballs [RFC8305] or related 3083 techniques. 3085 Any ticket MUST only be resumed with a cipher suite that has the same 3086 KDF hash algorithm as that used to establish the original connection. 3088 Clients MUST only resume if the new SNI value is valid for the server 3089 certificate presented in the original session, and SHOULD only resume 3090 if the SNI value matches the one used in the original session. The 3091 latter is a performance optimization: normally, there is no reason to 3092 expect that different servers covered by a single certificate would 3093 be able to accept each other's tickets; hence, attempting resumption 3094 in that case would waste a single-use ticket. If such an indication 3095 is provided (externally or by any other means), clients MAY resume 3096 with a different SNI value. 3098 On resumption, if reporting an SNI value to the calling application, 3099 implementations MUST use the value sent in the resumption ClientHello 3100 rather than the value sent in the previous session. Note that if a 3101 server implementation declines all PSK identities with different SNI 3102 values, these two values are always the same. 3104 Note: Although the resumption secret depends on the client's second 3105 flight, a server which does not request certificate-based client 3106 authentication MAY compute the remainder of the transcript 3107 independently and then send a NewSessionTicket immediately upon 3108 sending its Finished rather than waiting for the client Finished. 3109 This might be appropriate in cases where the client is expected to 3110 open multiple TLS connections in parallel and would benefit from the 3111 reduced overhead of a resumption handshake, for example. 3113 struct { 3114 uint32 ticket_lifetime; 3115 uint32 ticket_age_add; 3116 opaque ticket_nonce<0..255>; 3117 opaque ticket<1..2^16-1>; 3118 Extension extensions<0..2^16-1>; 3119 } NewSessionTicket; 3121 ticket_lifetime: Indicates the lifetime in seconds as a 32-bit 3122 unsigned integer in network byte order from the time of ticket 3123 issuance. Servers MUST NOT use any value greater than 604800 3124 seconds (7 days). The value of zero indicates that the ticket 3125 should be discarded immediately. Clients MUST NOT use tickets for 3126 longer than 7 days after issuance, regardless of the 3127 ticket_lifetime, and MAY delete tickets earlier based on local 3128 policy. A server MAY treat a ticket as valid for a shorter period 3129 of time than what is stated in the ticket_lifetime. 3131 ticket_age_add: A securely generated, random 32-bit value that is 3132 used to obscure the age of the ticket that the client includes in 3133 the "pre_shared_key" extension. The client-side ticket age is 3134 added to this value modulo 2^32 to obtain the value that is 3135 transmitted by the client. The server MUST generate a fresh value 3136 for each ticket it sends. 3138 ticket_nonce: A per-ticket value that is unique across all tickets 3139 issued on this connection. 3141 ticket: The value of the ticket to be used as the PSK identity. The 3142 ticket itself is an opaque label. It MAY be either a database 3143 lookup key or a self-encrypted and self-authenticated value. 3145 extensions: A list of extension values for the ticket. The 3146 "Extension" format is defined in Section 4.2. Clients MUST ignore 3147 unrecognized extensions. 3149 The sole extension currently defined for NewSessionTicket is 3150 "early_data", indicating that the ticket may be used to send 0-RTT 3151 data (Section 4.2.10). It contains the following value: 3153 max_early_data_size: The maximum amount of 0-RTT data that the 3154 client is allowed to send when using this ticket, in bytes. Only 3155 Application Data payload (i.e., plaintext but not padding or the 3156 inner content type byte) is counted. A server receiving more than 3157 max_early_data_size bytes of 0-RTT data SHOULD terminate the 3158 connection with an "unexpected_message" alert. Note that servers 3159 that reject early data due to lack of cryptographic material will 3160 be unable to differentiate padding from content, so clients SHOULD 3161 NOT depend on being able to send large quantities of padding in 3162 early data records. 3164 The PSK associated with the ticket is computed as: 3166 HKDF-Expand-Label(resumption_secret, 3167 "resumption", ticket_nonce, Hash.length) 3169 Because the ticket_nonce value is distinct for each NewSessionTicket 3170 message, a different PSK will be derived for each ticket. 3172 Note that in principle it is possible to continue issuing new tickets 3173 which indefinitely extend the lifetime of the keying material 3174 originally derived from an initial non-PSK handshake (which was most 3175 likely tied to the peer's certificate). It is RECOMMENDED that 3176 implementations place limits on the total lifetime of such keying 3177 material; these limits should take into account the lifetime of the 3178 peer's certificate, the likelihood of intervening revocation, and the 3179 time since the peer's online CertificateVerify signature. 3181 4.6.2. Post-Handshake Authentication 3183 When the client has sent the "post_handshake_auth" extension (see 3184 Section 4.2.6), a server MAY request certificate-based client 3185 authentication at any time after the handshake has completed by 3186 sending a CertificateRequest message. The client MUST respond with 3187 the appropriate Authentication messages (see Section 4.4). If the 3188 client chooses to authenticate, it MUST send Certificate, 3189 CertificateVerify, and Finished. If it declines, it MUST send a 3190 Certificate message containing no certificates followed by Finished. 3191 All of the client's messages for a given response MUST appear 3192 consecutively on the wire with no intervening messages of other 3193 types. 3195 A client that receives a CertificateRequest message without having 3196 sent the "post_handshake_auth" extension MUST send an 3197 "unexpected_message" fatal alert. 3199 Note: Because certificate-based client authentication could involve 3200 prompting the user, servers MUST be prepared for some delay, 3201 including receiving an arbitrary number of other messages between 3202 sending the CertificateRequest and receiving a response. In 3203 addition, clients which receive multiple CertificateRequests in close 3204 succession MAY respond to them in a different order than they were 3205 received (the certificate_request_context value allows the server to 3206 disambiguate the responses). 3208 4.6.3. Key and Initialization Vector Update 3210 The KeyUpdate handshake message is used to indicate that the sender 3211 is updating its sending cryptographic keys. This message can be sent 3212 by either peer after it has sent a Finished message. Implementations 3213 that receive a KeyUpdate message prior to receiving a Finished 3214 message MUST terminate the connection with an "unexpected_message" 3215 alert. After sending a KeyUpdate message, the sender SHALL send all 3216 its traffic using the next generation of keys, computed as described 3217 in Section 7.2. Upon receiving a KeyUpdate, the receiver MUST update 3218 its receiving keys. 3220 enum { 3221 update_not_requested(0), update_requested(1), (255) 3222 } KeyUpdateRequest; 3224 struct { 3225 KeyUpdateRequest request_update; 3226 } KeyUpdate; 3228 request_update: Indicates whether the recipient of the KeyUpdate 3229 should respond with its own KeyUpdate. If an implementation 3230 receives any other value, it MUST terminate the connection with an 3231 "illegal_parameter" alert. 3233 If the request_update field is set to "update_requested", then the 3234 receiver MUST send a KeyUpdate of its own with request_update set to 3235 "update_not_requested" prior to sending its next Application Data 3236 record. This mechanism allows either side to force an update to the 3237 entire connection, but causes an implementation which receives 3238 multiple KeyUpdates while it is silent to respond with a single 3239 update. Note that implementations may receive an arbitrary number of 3240 messages between sending a KeyUpdate with request_update set to 3241 "update_requested" and receiving the peer's KeyUpdate, because those 3242 messages may already be in flight. However, because send and receive 3243 keys are derived from independent traffic secrets, retaining the 3244 receive traffic secret does not threaten the forward secrecy of data 3245 sent before the sender changed keys. 3247 If implementations independently send their own KeyUpdates with 3248 request_update set to "update_requested", and they cross in flight, 3249 then each side will also send a response, with the result that each 3250 side increments by two generations. 3252 Both sender and receiver MUST encrypt their KeyUpdate messages with 3253 the old keys. Additionally, both sides MUST enforce that a KeyUpdate 3254 with the old key is received before accepting any messages encrypted 3255 with the new key. Failure to do so may allow message truncation 3256 attacks. 3258 5. Record Protocol 3260 The TLS record protocol takes messages to be transmitted, fragments 3261 the data into manageable blocks, protects the records, and transmits 3262 the result. Received data is verified, decrypted, reassembled, and 3263 then delivered to higher-level clients. 3265 TLS records are typed, which allows multiple higher-level protocols 3266 to be multiplexed over the same record layer. This document 3267 specifies four content types: handshake, application_data, alert, and 3268 change_cipher_spec. The change_cipher_spec record is used only for 3269 compatibility purposes (see Appendix E.4). 3271 An implementation may receive an unencrypted record of type 3272 change_cipher_spec consisting of the single byte value 0x01 at any 3273 time after the first ClientHello message has been sent or received 3274 and before the peer's Finished message has been received and MUST 3275 simply drop it without further processing. Note that this record may 3276 appear at a point at the handshake where the implementation is 3277 expecting protected records, and so it is necessary to detect this 3278 condition prior to attempting to deprotect the record. An 3279 implementation which receives any other change_cipher_spec value or 3280 which receives a protected change_cipher_spec record MUST abort the 3281 handshake with an "unexpected_message" alert. If an implementation 3282 detects a change_cipher_spec record received before the first 3283 ClientHello message or after the peer's Finished message, it MUST be 3284 treated as an unexpected record type (though stateless servers may 3285 not be able to distinguish these cases from allowed cases). 3287 Implementations MUST NOT send record types not defined in this 3288 document unless negotiated by some extension. If a TLS 3289 implementation receives an unexpected record type, it MUST terminate 3290 the connection with an "unexpected_message" alert. New record 3291 content type values are assigned by IANA in the TLS ContentType 3292 registry as described in Section 11. 3294 5.1. Record Layer 3296 The record layer fragments information blocks into TLSPlaintext 3297 records carrying data in chunks of 2^14 bytes or less. Message 3298 boundaries are handled differently depending on the underlying 3299 ContentType. Any future content types MUST specify appropriate 3300 rules. Note that these rules are stricter than what was enforced in 3301 TLS 1.2. 3303 Handshake messages MAY be coalesced into a single TLSPlaintext record 3304 or fragmented across several records, provided that: 3306 * Handshake messages MUST NOT be interleaved with other record 3307 types. That is, if a handshake message is split over two or more 3308 records, there MUST NOT be any other records between them. 3310 * Handshake messages MUST NOT span key changes. Implementations 3311 MUST verify that all messages immediately preceding a key change 3312 align with a record boundary; if not, then they MUST terminate the 3313 connection with an "unexpected_message" alert. Because the 3314 ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate 3315 messages can immediately precede a key change, implementations 3316 MUST send these messages in alignment with a record boundary. 3318 Implementations MUST NOT send zero-length fragments of Handshake 3319 types, even if those fragments contain padding. 3321 Alert messages (Section 6) MUST NOT be fragmented across records, and 3322 multiple alert messages MUST NOT be coalesced into a single 3323 TLSPlaintext record. In other words, a record with an Alert type 3324 MUST contain exactly one message. 3326 Application Data messages contain data that is opaque to TLS. 3327 Application Data messages are always protected. Zero-length 3328 fragments of Application Data MAY be sent, as they are potentially 3329 useful as a traffic analysis countermeasure. Application Data 3330 fragments MAY be split across multiple records or coalesced into a 3331 single record. 3333 enum { 3334 invalid(0), 3335 change_cipher_spec(20), 3336 alert(21), 3337 handshake(22), 3338 application_data(23), 3339 (255) 3340 } ContentType; 3342 struct { 3343 ContentType type; 3344 ProtocolVersion legacy_record_version; 3345 uint16 length; 3346 opaque fragment[TLSPlaintext.length]; 3347 } TLSPlaintext; 3349 type: The higher-level protocol used to process the enclosed 3350 fragment. 3352 legacy_record_version: MUST be set to 0x0303 for all records 3353 generated by a TLS 1.3 implementation other than an initial 3354 ClientHello (i.e., one not generated after a HelloRetryRequest), 3355 where it MAY also be 0x0301 for compatibility purposes. This 3356 field is deprecated and MUST be ignored for all purposes. 3357 Previous versions of TLS would use other values in this field 3358 under some circumstances. 3360 length: The length (in bytes) of the following 3361 TLSPlaintext.fragment. The length MUST NOT exceed 2^14 bytes. An 3362 endpoint that receives a record that exceeds this length MUST 3363 terminate the connection with a "record_overflow" alert. 3365 fragment The data being transmitted. This value is transparent and 3366 is treated as an independent block to be dealt with by the higher- 3367 level protocol specified by the type field. 3369 This document describes TLS 1.3, which uses the version 0x0304. This 3370 version value is historical, deriving from the use of 0x0301 for TLS 3371 1.0 and 0x0300 for SSL 3.0. In order to maximize backward 3372 compatibility, a record containing an initial ClientHello SHOULD have 3373 version 0x0301 (reflecting TLS 1.0) and a record containing a second 3374 ClientHello or a ServerHello MUST have version 0x0303 (reflecting TLS 3375 1.2). When negotiating prior versions of TLS, endpoints follow the 3376 procedure and requirements provided in Appendix E. 3378 When record protection has not yet been engaged, TLSPlaintext 3379 structures are written directly onto the wire. Once record 3380 protection has started, TLSPlaintext records are protected and sent 3381 as described in the following section. Note that Application Data 3382 records MUST NOT be written to the wire unprotected (see Section 2 3383 for details). 3385 5.2. Record Payload Protection 3387 The record protection functions translate a TLSPlaintext structure 3388 into a TLSCiphertext structure. The deprotection functions reverse 3389 the process. In TLS 1.3, as opposed to previous versions of TLS, all 3390 ciphers are modeled as "Authenticated Encryption with Associated 3391 Data" (AEAD) [RFC5116]. AEAD functions provide a unified encryption 3392 and authentication operation which turns plaintext into authenticated 3393 ciphertext and back again. Each encrypted record consists of a 3394 plaintext header followed by an encrypted body, which itself contains 3395 a type and optional padding. 3397 struct { 3398 opaque content[TLSPlaintext.length]; 3399 ContentType type; 3400 uint8 zeros[length_of_padding]; 3401 } TLSInnerPlaintext; 3403 struct { 3404 ContentType opaque_type = application_data; /* 23 */ 3405 ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */ 3406 uint16 length; 3407 opaque encrypted_record[TLSCiphertext.length]; 3408 } TLSCiphertext; 3410 content: The TLSPlaintext.fragment value, containing the byte 3411 encoding of a handshake or an alert message, or the raw bytes of 3412 the application's data to send. 3414 type: The TLSPlaintext.type value containing the content type of the 3415 record. 3417 zeros: An arbitrary-length run of zero-valued bytes may appear in 3418 the cleartext after the type field. This provides an opportunity 3419 for senders to pad any TLS record by a chosen amount as long as 3420 the total stays within record size limits. See Section 5.4 for 3421 more details. 3423 opaque_type: The outer opaque_type field of a TLSCiphertext record 3424 is always set to the value 23 (application_data) for outward 3425 compatibility with middleboxes accustomed to parsing previous 3426 versions of TLS. The actual content type of the record is found 3427 in TLSInnerPlaintext.type after decryption. 3429 legacy_record_version: The legacy_record_version field is always 3430 0x0303. TLS 1.3 TLSCiphertexts are not generated until after TLS 3431 1.3 has been negotiated, so there are no historical compatibility 3432 concerns where other values might be received. Note that the 3433 handshake protocol, including the ClientHello and ServerHello 3434 messages, authenticates the protocol version, so this value is 3435 redundant. 3437 length: The length (in bytes) of the following 3438 TLSCiphertext.encrypted_record, which is the sum of the lengths of 3439 the content and the padding, plus one for the inner content type, 3440 plus any expansion added by the AEAD algorithm. The length MUST 3441 NOT exceed 2^14 + 256 bytes. An endpoint that receives a record 3442 that exceeds this length MUST terminate the connection with a 3443 "record_overflow" alert. 3445 encrypted_record: The AEAD-encrypted form of the serialized 3446 TLSInnerPlaintext structure. 3448 AEAD algorithms take as input a single key, a nonce, a plaintext, and 3449 "additional data" to be included in the authentication check, as 3450 described in Section 2.1 of [RFC5116]. The key is either the 3451 client_write_key or the server_write_key, the nonce is derived from 3452 the sequence number and the client_write_iv or server_write_iv (see 3453 Section 5.3), and the additional data input is the record header. 3454 I.e., 3456 additional_data = TLSCiphertext.opaque_type || 3457 TLSCiphertext.legacy_record_version || 3458 TLSCiphertext.length 3460 The plaintext input to the AEAD algorithm is the encoded 3461 TLSInnerPlaintext structure. Derivation of traffic keys is defined 3462 in Section 7.3. 3464 The AEAD output consists of the ciphertext output from the AEAD 3465 encryption operation. The length of the plaintext is greater than 3466 the corresponding TLSPlaintext.length due to the inclusion of 3467 TLSInnerPlaintext.type and any padding supplied by the sender. The 3468 length of the AEAD output will generally be larger than the 3469 plaintext, but by an amount that varies with the AEAD algorithm. 3470 Since the ciphers might incorporate padding, the amount of overhead 3471 could vary with different lengths of plaintext. Symbolically, 3473 AEADEncrypted = 3474 AEAD-Encrypt(write_key, nonce, additional_data, plaintext) 3476 The encrypted_record field of TLSCiphertext is set to AEADEncrypted. 3478 In order to decrypt and verify, the cipher takes as input the key, 3479 nonce, additional data, and the AEADEncrypted value. The output is 3480 either the plaintext or an error indicating that the decryption 3481 failed. There is no separate integrity check. Symbolically, 3483 plaintext of encrypted_record = 3484 AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted) 3486 If the decryption fails, the receiver MUST terminate the connection 3487 with a "bad_record_mac" alert. 3489 An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion 3490 greater than 255 octets. An endpoint that receives a record from its 3491 peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST 3492 terminate the connection with a "record_overflow" alert. This limit 3493 is derived from the maximum TLSInnerPlaintext length of 2^14 octets + 3494 1 octet for ContentType + the maximum AEAD expansion of 255 octets. 3496 5.3. Per-Record Nonce 3498 A 64-bit sequence number is maintained separately for reading and 3499 writing records. The appropriate sequence number is incremented by 3500 one after reading or writing each record. Each sequence number is 3501 set to zero at the beginning of a connection and whenever the key is 3502 changed; the first record transmitted under a particular traffic key 3503 MUST use sequence number 0. 3505 Because the size of sequence numbers is 64-bit, they should not wrap. 3506 If a TLS implementation would need to wrap a sequence number, it MUST 3507 either rekey (Section 4.6.3) or terminate the connection. 3509 Each AEAD algorithm will specify a range of possible lengths for the 3510 per-record nonce, from N_MIN bytes to N_MAX bytes of input [RFC5116]. 3511 The length of the TLS per-record nonce (iv_length) is set to the 3512 larger of 8 bytes and N_MIN for the AEAD algorithm (see [RFC5116], 3513 Section 4). An AEAD algorithm where N_MAX is less than 8 bytes MUST 3514 NOT be used with TLS. The per-record nonce for the AEAD construction 3515 is formed as follows: 3517 1. The 64-bit record sequence number is encoded in network byte 3518 order and padded to the left with zeros to iv_length. 3520 2. The padded sequence number is XORed with either the static 3521 client_write_iv or server_write_iv (depending on the role). 3523 The resulting quantity (of length iv_length) is used as the per- 3524 record nonce. 3526 Note: This is a different construction from that in TLS 1.2, which 3527 specified a partially explicit nonce. 3529 5.4. Record Padding 3531 All encrypted TLS records can be padded to inflate the size of the 3532 TLSCiphertext. This allows the sender to hide the size of the 3533 traffic from an observer. 3535 When generating a TLSCiphertext record, implementations MAY choose to 3536 pad. An unpadded record is just a record with a padding length of 3537 zero. Padding is a string of zero-valued bytes appended to the 3538 ContentType field before encryption. Implementations MUST set the 3539 padding octets to all zeros before encrypting. 3541 Application Data records may contain a zero-length 3542 TLSInnerPlaintext.content if the sender desires. This permits 3543 generation of plausibly sized cover traffic in contexts where the 3544 presence or absence of activity may be sensitive. Implementations 3545 MUST NOT send Handshake and Alert records that have a zero-length 3546 TLSInnerPlaintext.content; if such a message is received, the 3547 receiving implementation MUST terminate the connection with an 3548 "unexpected_message" alert. 3550 The padding sent is automatically verified by the record protection 3551 mechanism; upon successful decryption of a 3552 TLSCiphertext.encrypted_record, the receiving implementation scans 3553 the field from the end toward the beginning until it finds a non-zero 3554 octet. This non-zero octet is the content type of the message. This 3555 padding scheme was selected because it allows padding of any 3556 encrypted TLS record by an arbitrary size (from zero up to TLS record 3557 size limits) without introducing new content types. The design also 3558 enforces all-zero padding octets, which allows for quick detection of 3559 padding errors. 3561 Implementations MUST limit their scanning to the cleartext returned 3562 from the AEAD decryption. If a receiving implementation does not 3563 find a non-zero octet in the cleartext, it MUST terminate the 3564 connection with an "unexpected_message" alert. 3566 The presence of padding does not change the overall record size 3567 limitations: the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 3568 + 1 octets. If the maximum fragment length is reduced -- as for 3569 example by the record_size_limit extension from [RFC8449] -- then the 3570 reduced limit applies to the full plaintext, including the content 3571 type and padding. 3573 Selecting a padding policy that suggests when and how much to pad is 3574 a complex topic and is beyond the scope of this specification. If 3575 the application-layer protocol on top of TLS has its own padding, it 3576 may be preferable to pad Application Data TLS records within the 3577 application layer. Padding for encrypted Handshake or Alert records 3578 must still be handled at the TLS layer, though. Later documents may 3579 define padding selection algorithms or define a padding policy 3580 request mechanism through TLS extensions or some other means. 3582 5.5. Limits on Key Usage 3584 There are cryptographic limits on the amount of plaintext which can 3585 be safely encrypted under a given set of keys. [AEAD-LIMITS] 3586 provides an analysis of these limits under the assumption that the 3587 underlying primitive (AES or ChaCha20) has no weaknesses. 3588 Implementations SHOULD do a key update as described in Section 4.6.3 3589 prior to reaching these limits. Note that it is not possible to 3590 perform a KeyUpdate for early data and therefore implementations 3591 SHOULD not exceed the limits when sending early data. 3593 For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be 3594 encrypted on a given connection while keeping a safety margin of 3595 approximately 2^-57 for Authenticated Encryption (AE) security. For 3596 ChaCha20/Poly1305, the record sequence number would wrap before the 3597 safety limit is reached. 3599 6. Alert Protocol 3601 TLS provides an Alert content type to indicate closure information 3602 and errors. Like other messages, alert messages are encrypted as 3603 specified by the current connection state. 3605 Alert messages convey a description of the alert and a legacy field 3606 that conveyed the severity level of the message in previous versions 3607 of TLS. Alerts are divided into two classes: closure alerts and 3608 error alerts. In TLS 1.3, the severity is implicit in the type of 3609 alert being sent, and the "level" field can safely be ignored. The 3610 "close_notify" alert is used to indicate orderly closure of one 3611 direction of the connection. Upon receiving such an alert, the TLS 3612 implementation SHOULD indicate end-of-data to the application. 3614 Error alerts indicate abortive closure of the connection (see 3615 Section 6.2). Upon receiving an error alert, the TLS implementation 3616 SHOULD indicate an error to the application and MUST NOT allow any 3617 further data to be sent or received on the connection. Servers and 3618 clients MUST forget the secret values and keys established in failed 3619 connections, with the exception of the PSKs associated with session 3620 tickets, which SHOULD be discarded if possible. 3622 All the alerts listed in Section 6.2 MUST be sent with 3623 AlertLevel=fatal and MUST be treated as error alerts when received 3624 regardless of the AlertLevel in the message. Unknown Alert types 3625 MUST be treated as error alerts. 3627 Note: TLS defines two generic alerts (see Section 6) to use upon 3628 failure to parse a message. Peers which receive a message which 3629 cannot be parsed according to the syntax (e.g., have a length 3630 extending beyond the message boundary or contain an out-of-range 3631 length) MUST terminate the connection with a "decode_error" alert. 3632 Peers which receive a message which is syntactically correct but 3633 semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) 3634 MUST terminate the connection with an "illegal_parameter" alert. 3636 enum { warning(1), fatal(2), (255) } AlertLevel; 3638 enum { 3639 close_notify(0), 3640 unexpected_message(10), 3641 bad_record_mac(20), 3642 record_overflow(22), 3643 handshake_failure(40), 3644 bad_certificate(42), 3645 unsupported_certificate(43), 3646 certificate_revoked(44), 3647 certificate_expired(45), 3648 certificate_unknown(46), 3649 illegal_parameter(47), 3650 unknown_ca(48), 3651 access_denied(49), 3652 decode_error(50), 3653 decrypt_error(51), 3654 protocol_version(70), 3655 insufficient_security(71), 3656 internal_error(80), 3657 inappropriate_fallback(86), 3658 user_canceled(90), 3659 missing_extension(109), 3660 unsupported_extension(110), 3661 unrecognized_name(112), 3662 bad_certificate_status_response(113), 3663 unknown_psk_identity(115), 3664 certificate_required(116), 3665 no_application_protocol(120), 3666 (255) 3667 } AlertDescription; 3669 struct { 3670 AlertLevel level; 3671 AlertDescription description; 3672 } Alert; 3674 6.1. Closure Alerts 3676 The client and the server must share knowledge that the connection is 3677 ending in order to avoid a truncation attack. 3679 close_notify: This alert notifies the recipient that the sender will 3680 not send any more messages on this connection. Any data received 3681 after a closure alert has been received MUST be ignored. 3683 user_canceled: This alert notifies the recipient that the sender is 3684 canceling the handshake for some reason unrelated to a protocol 3685 failure. If a user cancels an operation after the handshake is 3686 complete, just closing the connection by sending a "close_notify" 3687 is more appropriate. This alert SHOULD be followed by a 3688 "close_notify". This alert generally has AlertLevel=warning. 3690 Either party MAY initiate a close of its write side of the connection 3691 by sending a "close_notify" alert. Any data received after a closure 3692 alert has been received MUST be ignored. If a transport-level close 3693 is received prior to a "close_notify", the receiver cannot know that 3694 all the data that was sent has been received. 3696 Each party MUST send a "close_notify" alert before closing its write 3697 side of the connection, unless it has already sent some error alert. 3698 This does not have any effect on its read side of the connection. 3699 Note that this is a change from versions of TLS prior to TLS 1.3 in 3700 which implementations were required to react to a "close_notify" by 3701 discarding pending writes and sending an immediate "close_notify" 3702 alert of their own. That previous requirement could cause truncation 3703 in the read side. Both parties need not wait to receive a 3704 "close_notify" alert before closing their read side of the 3705 connection, though doing so would introduce the possibility of 3706 truncation. 3708 If the application protocol using TLS provides that any data may be 3709 carried over the underlying transport after the TLS connection is 3710 closed, the TLS implementation MUST receive a "close_notify" alert 3711 before indicating end-of-data to the application layer. No part of 3712 this standard should be taken to dictate the manner in which a usage 3713 profile for TLS manages its data transport, including when 3714 connections are opened or closed. 3716 Note: It is assumed that closing the write side of a connection 3717 reliably delivers pending data before destroying the transport. 3719 6.2. Error Alerts 3721 Error handling in TLS is very simple. When an error is detected, the 3722 detecting party sends a message to its peer. Upon transmission or 3723 receipt of a fatal alert message, both parties MUST immediately close 3724 the connection. 3726 Whenever an implementation encounters a fatal error condition, it 3727 SHOULD send an appropriate fatal alert and MUST close the connection 3728 without sending or receiving any additional data. Throughout this 3729 specification, when the phrases "terminate the connection" and "abort 3730 the handshake" are used without a specific alert it means that the 3731 implementation SHOULD send the alert indicated by the descriptions 3732 below. The phrases "terminate the connection with an X alert" and 3733 "abort the handshake with an X alert" mean that the implementation 3734 MUST send alert X if it sends any alert. All alerts defined below in 3735 this section, as well as all unknown alerts, are universally 3736 considered fatal as of TLS 1.3 (see Section 6). The implementation 3737 SHOULD provide a way to facilitate logging the sending and receiving 3738 of alerts. 3740 The following error alerts are defined: 3742 unexpected_message: An inappropriate message (e.g., the wrong 3743 handshake message, premature Application Data, etc.) was received. 3744 This alert should never be observed in communication between 3745 proper implementations. 3747 bad_record_mac: This alert is returned if a record is received which 3748 cannot be deprotected. Because AEAD algorithms combine decryption 3749 and verification, and also to avoid side-channel attacks, this 3750 alert is used for all deprotection failures. This alert should 3751 never be observed in communication between proper implementations, 3752 except when messages were corrupted in the network. 3754 record_overflow: A TLSCiphertext record was received that had a 3755 length more than 2^14 + 256 bytes, or a record decrypted to a 3756 TLSPlaintext record with more than 2^14 bytes (or some other 3757 negotiated limit). This alert should never be observed in 3758 communication between proper implementations, except when messages 3759 were corrupted in the network. 3761 handshake_failure: Receipt of a "handshake_failure" alert message 3762 indicates that the sender was unable to negotiate an acceptable 3763 set of security parameters given the options available. 3765 bad_certificate: A certificate was corrupt, contained signatures 3766 that did not verify correctly, etc. 3768 unsupported_certificate: A certificate was of an unsupported type. 3770 certificate_revoked: A certificate was revoked by its signer. 3772 certificate_expired: A certificate has expired or is not currently 3773 valid. 3775 certificate_unknown: Some other (unspecified) issue arose in 3776 processing the certificate, rendering it unacceptable. 3778 illegal_parameter: A field in the handshake was incorrect or 3779 inconsistent with other fields. This alert is used for errors 3780 which conform to the formal protocol syntax but are otherwise 3781 incorrect. 3783 unknown_ca: A valid certificate chain or partial chain was received, 3784 but the certificate was not accepted because the CA certificate 3785 could not be located or could not be matched with a known trust 3786 anchor. 3788 access_denied: A valid certificate or PSK was received, but when 3789 access control was applied, the sender decided not to proceed with 3790 negotiation. 3792 decode_error: A message could not be decoded because some field was 3793 out of the specified range or the length of the message was 3794 incorrect. This alert is used for errors where the message does 3795 not conform to the formal protocol syntax. This alert should 3796 never be observed in communication between proper implementations, 3797 except when messages were corrupted in the network. 3799 decrypt_error: A handshake (not record layer) cryptographic 3800 operation failed, including being unable to correctly verify a 3801 signature or validate a Finished message or a PSK binder. 3803 protocol_version: The protocol version the peer has attempted to 3804 negotiate is recognized but not supported (see Appendix E). 3806 insufficient_security: Returned instead of "handshake_failure" when 3807 a negotiation has failed specifically because the server requires 3808 parameters more secure than those supported by the client. 3810 internal_error: An internal error unrelated to the peer or the 3811 correctness of the protocol (such as a memory allocation failure) 3812 makes it impossible to continue. 3814 inappropriate_fallback: Sent by a server in response to an invalid 3815 connection retry attempt from a client (see [RFC7507]). 3817 missing_extension: Sent by endpoints that receive a handshake 3818 message not containing an extension that is mandatory to send for 3819 the offered TLS version or other negotiated parameters. 3821 unsupported_extension: Sent by endpoints receiving any handshake 3822 message containing an extension known to be prohibited for 3823 inclusion in the given handshake message, or including any 3824 extensions in a ServerHello or Certificate not first offered in 3825 the corresponding ClientHello or CertificateRequest. 3827 unrecognized_name: Sent by servers when no server exists identified 3828 by the name provided by the client via the "server_name" extension 3829 (see [RFC6066]). 3831 bad_certificate_status_response: Sent by clients when an invalid or 3832 unacceptable OCSP response is provided by the server via the 3833 "status_request" extension (see [RFC6066]). 3835 unknown_psk_identity: Sent by servers when PSK key establishment is 3836 desired but no acceptable PSK identity is provided by the client. 3837 Sending this alert is OPTIONAL; servers MAY instead choose to send 3838 a "decrypt_error" alert to merely indicate an invalid PSK 3839 identity. 3841 certificate_required: Sent by servers when a client certificate is 3842 desired but none was provided by the client. 3844 no_application_protocol: Sent by servers when a client 3845 "application_layer_protocol_negotiation" extension advertises only 3846 protocols that the server does not support (see [RFC7301]). 3848 New Alert values are assigned by IANA as described in Section 11. 3850 7. Cryptographic Computations 3852 The TLS handshake establishes one or more input secrets which are 3853 combined to create the actual working keying material, as detailed 3854 below. The key derivation process incorporates both the input 3855 secrets and the handshake transcript. Note that because the 3856 handshake transcript includes the random values from the Hello 3857 messages, any given handshake will have different traffic secrets, 3858 even if the same input secrets are used, as is the case when the same 3859 PSK is used for multiple connections. 3861 7.1. Key Schedule 3863 The key derivation process makes use of the HKDF-Extract and HKDF- 3864 Expand functions as defined for HKDF [RFC5869], as well as the 3865 functions defined below: 3867 HKDF-Expand-Label(Secret, Label, Context, Length) = 3868 HKDF-Expand(Secret, HkdfLabel, Length) 3870 Where HkdfLabel is specified as: 3872 struct { 3873 uint16 length = Length; 3874 opaque label<7..255> = "tls13 " + Label; 3875 opaque context<0..255> = Context; 3876 } HkdfLabel; 3878 Derive-Secret(Secret, Label, Messages) = 3879 HKDF-Expand-Label(Secret, Label, 3880 Transcript-Hash(Messages), Hash.length) 3882 The Hash function used by Transcript-Hash and HKDF is the cipher 3883 suite hash algorithm. Hash.length is its output length in bytes. 3884 Messages is the concatenation of the indicated handshake messages, 3885 including the handshake message type and length fields, but not 3886 including record layer headers. Note that in some cases a zero- 3887 length Context (indicated by "") is passed to HKDF-Expand-Label. The 3888 labels specified in this document are all ASCII strings and do not 3889 include a trailing NUL byte. 3891 Note: With common hash functions, any label longer than 12 characters 3892 requires an additional iteration of the hash function to compute. 3893 The labels in this specification have all been chosen to fit within 3894 this limit. 3896 Keys are derived from two input secrets using the HKDF-Extract and 3897 Derive-Secret functions. The general pattern for adding a new secret 3898 is to use HKDF-Extract with the Salt being the current secret state 3899 and the Input Keying Material (IKM) being the new secret to be added. 3900 In this version of TLS 1.3, the two input secrets are: 3902 * PSK (a pre-shared key established externally or derived from the 3903 resumption_secret value from a previous connection) 3905 * (EC)DHE shared secret (Section 7.4) 3907 This produces a full key derivation schedule shown in the diagram 3908 below. In this diagram, the following formatting conventions apply: 3910 * HKDF-Extract is drawn as taking the Salt argument from the top and 3911 the IKM argument from the left, with its output to the bottom and 3912 the name of the output on the right. 3914 * Derive-Secret's Secret argument is indicated by the incoming 3915 arrow. For instance, the Early Secret is the Secret for 3916 generating the client_early_traffic_secret. 3918 * "0" indicates a string of Hash.length bytes set to zero. 3920 Note: the key derivation labels use the string "master" even though 3921 the values are referred to as "main" secrets. This mismatch is a 3922 result of renaming the values while retaining compatibility. 3924 [[OPEN ISSUE: Replace the strings with hex value?]] 3926 0 3927 | 3928 v 3929 PSK -> HKDF-Extract = Early Secret 3930 | 3931 +-----> Derive-Secret(., 3932 | "ext binder" | 3933 | "res binder", 3934 | "") 3935 | = binder_key 3936 | 3937 +-----> Derive-Secret(., "c e traffic", 3938 | ClientHello) 3939 | = client_early_traffic_secret 3940 | 3941 +-----> Derive-Secret(., "e exp master", 3942 | ClientHello) 3943 | = early_exporter_secret 3944 v 3945 Derive-Secret(., "derived", "") 3946 | 3947 v 3948 (EC)DHE -> HKDF-Extract = Handshake Secret 3949 | 3950 +-----> Derive-Secret(., "c hs traffic", 3951 | ClientHello...ServerHello) 3952 | = client_handshake_traffic_secret 3953 | 3954 +-----> Derive-Secret(., "s hs traffic", 3955 | ClientHello...ServerHello) 3956 | = server_handshake_traffic_secret 3957 v 3958 Derive-Secret(., "derived", "") 3959 | 3960 v 3961 0 -> HKDF-Extract = Main Secret 3962 | 3963 +-----> Derive-Secret(., "c ap traffic", 3964 | ClientHello...server Finished) 3965 | = client_application_traffic_secret_0 3966 | 3967 +-----> Derive-Secret(., "s ap traffic", 3968 | ClientHello...server Finished) 3969 | = server_application_traffic_secret_0 3970 | 3971 +-----> Derive-Secret(., "exp master", 3972 | ClientHello...server Finished) 3973 | = exporter_secret 3974 | 3975 +-----> Derive-Secret(., "res master", 3976 ClientHello...client Finished) 3977 = resumption_secret 3979 The general pattern here is that the secrets shown down the left side 3980 of the diagram are just raw entropy without context, whereas the 3981 secrets down the right side include Handshake Context and therefore 3982 can be used to derive working keys without additional context. Note 3983 that the different calls to Derive-Secret may take different Messages 3984 arguments, even with the same secret. In a 0-RTT exchange, Derive- 3985 Secret is called with four distinct transcripts; in a 1-RTT-only 3986 exchange, it is called with three distinct transcripts. 3988 If a given secret is not available, then the 0-value consisting of a 3989 string of Hash.length bytes set to zeros is used. Note that this 3990 does not mean skipping rounds, so if PSK is not in use, Early Secret 3991 will still be HKDF-Extract(0, 0). For the computation of the 3992 binder_key, the label is "ext binder" for external PSKs (those 3993 provisioned outside of TLS) and "res binder" for resumption PSKs 3994 (those provisioned as the resumption secret of a previous handshake). 3995 The different labels prevent the substitution of one type of PSK for 3996 the other. 3998 There are multiple potential Early Secret values, depending on which 3999 PSK the server ultimately selects. The client will need to compute 4000 one for each potential PSK; if no PSK is selected, it will then need 4001 to compute the Early Secret corresponding to the zero PSK. 4003 Once all the values which are to be derived from a given secret have 4004 been computed, that secret SHOULD be erased. 4006 7.2. Updating Traffic Secrets 4008 Once the handshake is complete, it is possible for either side to 4009 update its sending traffic keys using the KeyUpdate handshake message 4010 defined in Section 4.6.3. The next generation of traffic keys is 4011 computed by generating client_/server_application_traffic_secret_N+1 4012 from client_/server_application_traffic_secret_N as described in this 4013 section and then re-deriving the traffic keys as described in 4014 Section 7.3. 4016 The next-generation application_traffic_secret is computed as: 4018 application_traffic_secret_N+1 = 4019 HKDF-Expand-Label(application_traffic_secret_N, 4020 "traffic upd", "", Hash.length) 4022 Once client_/server_application_traffic_secret_N+1 and its associated 4023 traffic keys have been computed, implementations SHOULD delete 4024 client_/server_application_traffic_secret_N and its associated 4025 traffic keys. 4027 7.3. Traffic Key Calculation 4029 The traffic keying material is generated from the following input 4030 values: 4032 * A secret value 4034 * A purpose value indicating the specific value being generated 4036 * The length of the key being generated 4038 The traffic keying material is generated from an input traffic secret 4039 value using: 4041 [sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length) 4042 [sender]_write_iv = HKDF-Expand-Label(Secret, "iv", "", iv_length) 4044 [sender] denotes the sending side. The value of Secret for each 4045 category of data is shown in the table below. 4047 +====================+=======================================+ 4048 | Data Type | Secret | 4049 +====================+=======================================+ 4050 | 0-RTT Application | client_early_traffic_secret | 4051 | and EndOfEarlyData | | 4052 +--------------------+---------------------------------------+ 4053 | Initial Handshake | [sender]_handshake_traffic_secret | 4054 +--------------------+---------------------------------------+ 4055 | Post-Handshake and | [sender]_application_traffic_secret_N | 4056 | Application Data | | 4057 +--------------------+---------------------------------------+ 4059 Table 3: Secrets for Traffic Keys 4061 Alerts are sent with the then current sending key (or as plaintext if 4062 no such key has been established.) All the traffic keying material 4063 is recomputed whenever the underlying Secret changes (e.g., when 4064 changing from the handshake to Application Data keys or upon a key 4065 update). 4067 7.4. (EC)DHE Shared Secret Calculation 4069 7.4.1. Finite Field Diffie-Hellman 4071 For finite field groups, a conventional Diffie-Hellman [DH76] 4072 computation is performed. The negotiated key (Z) is converted to a 4073 byte string by encoding in big-endian form and left-padded with zeros 4074 up to the size of the prime. This byte string is used as the shared 4075 secret in the key schedule as specified above. 4077 Note that this construction differs from previous versions of TLS 4078 which remove leading zeros. 4080 7.4.2. Elliptic Curve Diffie-Hellman 4082 For secp256r1, secp384r1 and secp521r1, ECDH calculations (including 4083 parameter and key generation as well as the shared secret 4084 calculation) are performed according to [IEEE1363] using the ECKAS- 4085 DH1 scheme with the identity map as the key derivation function 4086 (KDF), so that the shared secret is the x-coordinate of the ECDH 4087 shared secret elliptic curve point represented as an octet string. 4088 Note that this octet string ("Z" in IEEE 1363 terminology) as output 4089 by FE2OSP (the Field Element to Octet String Conversion Primitive) 4090 has constant length for any given field; leading zeros found in this 4091 octet string MUST NOT be truncated. 4093 (Note that this use of the identity KDF is a technicality. The 4094 complete picture is that ECDH is employed with a non-trivial KDF 4095 because TLS does not directly use this secret for anything other than 4096 for computing other secrets.) 4098 For X25519 and X448, the ECDH calculations are as follows: 4100 * The public key to put into the KeyShareEntry.key_exchange 4101 structure is the result of applying the ECDH scalar multiplication 4102 function to the secret key of appropriate length (into scalar 4103 input) and the standard public basepoint (into u-coordinate point 4104 input). 4106 * The ECDH shared secret is the result of applying the ECDH scalar 4107 multiplication function to the secret key (into scalar input) and 4108 the peer's public key (into u-coordinate point input). The output 4109 is used raw, with no processing. 4111 For these curves, implementations SHOULD use the approach specified 4112 in [RFC7748] to calculate the Diffie-Hellman shared secret. 4113 Implementations MUST check whether the computed Diffie-Hellman shared 4114 secret is the all-zero value and abort if so, as described in 4115 Section 6 of [RFC7748]. If implementors use an alternative 4116 implementation of these elliptic curves, they SHOULD perform the 4117 additional checks specified in Section 7 of [RFC7748]. 4119 7.5. Exporters 4121 [RFC5705] defines keying material exporters for TLS in terms of the 4122 TLS pseudorandom function (PRF). This document replaces the PRF with 4123 HKDF, thus requiring a new construction. The exporter interface 4124 remains the same. 4126 The exporter value is computed as: 4128 TLS-Exporter(label, context_value, key_length) = 4129 HKDF-Expand-Label(Derive-Secret(Secret, label, ""), 4130 "exporter", Hash(context_value), key_length) 4132 Where Secret is either the early_exporter_secret or the 4133 exporter_secret. Implementations MUST use the exporter_secret unless 4134 explicitly specified by the application. The early_exporter_secret 4135 is defined for use in settings where an exporter is needed for 0-RTT 4136 data. A separate interface for the early exporter is RECOMMENDED; 4137 this avoids the exporter user accidentally using an early exporter 4138 when a regular one is desired or vice versa. 4140 If no context is provided, the context_value is zero length. 4141 Consequently, providing no context computes the same value as 4142 providing an empty context. This is a change from previous versions 4143 of TLS where an empty context produced a different output than an 4144 absent context. As of this document's publication, no allocated 4145 exporter label is used both with and without a context. Future 4146 specifications MUST NOT define a use of exporters that permit both an 4147 empty context and no context with the same label. New uses of 4148 exporters SHOULD provide a context in all exporter computations, 4149 though the value could be empty. 4151 Requirements for the format of exporter labels are defined in 4152 Section 4 of [RFC5705]. 4154 8. 0-RTT and Anti-Replay 4156 As noted in Section 2.3 and Appendix F.5, TLS does not provide 4157 inherent replay protections for 0-RTT data. There are two potential 4158 threats to be concerned with: 4160 * Network attackers who mount a replay attack by simply duplicating 4161 a flight of 0-RTT data. 4163 * Network attackers who take advantage of client retry behavior to 4164 arrange for the server to receive multiple copies of an 4165 application message. This threat already exists to some extent 4166 because clients that value robustness respond to network errors by 4167 attempting to retry requests. However, 0-RTT adds an additional 4168 dimension for any server system which does not maintain globally 4169 consistent server state. Specifically, if a server system has 4170 multiple zones where tickets from zone A will not be accepted in 4171 zone B, then an attacker can duplicate a ClientHello and early 4172 data intended for A to both A and B. At A, the data will be 4173 accepted in 0-RTT, but at B the server will reject 0-RTT data and 4174 instead force a full handshake. If the attacker blocks the 4175 ServerHello from A, then the client will complete the handshake 4176 with B and probably retry the request, leading to duplication on 4177 the server system as a whole. 4179 The first class of attack can be prevented by sharing state to 4180 guarantee that the 0-RTT data is accepted at most once. Servers 4181 SHOULD provide that level of replay safety by implementing one of the 4182 methods described in this section or by equivalent means. It is 4183 understood, however, that due to operational concerns not all 4184 deployments will maintain state at that level. Therefore, in normal 4185 operation, clients will not know which, if any, of these mechanisms 4186 servers actually implement and hence MUST only send early data which 4187 they deem safe to be replayed. 4189 In addition to the direct effects of replays, there is a class of 4190 attacks where even operations normally considered idempotent could be 4191 exploited by a large number of replays (timing attacks, resource 4192 limit exhaustion and others, as described in Appendix F.5). Those 4193 can be mitigated by ensuring that every 0-RTT payload can be replayed 4194 only a limited number of times. The server MUST ensure that any 4195 instance of it (be it a machine, a thread, or any other entity within 4196 the relevant serving infrastructure) would accept 0-RTT for the same 4197 0-RTT handshake at most once; this limits the number of replays to 4198 the number of server instances in the deployment. Such a guarantee 4199 can be accomplished by locally recording data from recently received 4200 ClientHellos and rejecting repeats, or by any other method that 4201 provides the same or a stronger guarantee. The "at most once per 4202 server instance" guarantee is a minimum requirement; servers SHOULD 4203 limit 0-RTT replays further when feasible. 4205 The second class of attack cannot be prevented at the TLS layer and 4206 MUST be dealt with by any application. Note that any application 4207 whose clients implement any kind of retry behavior already needs to 4208 implement some sort of anti-replay defense. 4210 8.1. Single-Use Tickets 4212 The simplest form of anti-replay defense is for the server to only 4213 allow each session ticket to be used once. For instance, the server 4214 can maintain a database of all outstanding valid tickets, deleting 4215 each ticket from the database as it is used. If an unknown ticket is 4216 provided, the server would then fall back to a full handshake. 4218 If the tickets are not self-contained but rather are database keys, 4219 and the corresponding PSKs are deleted upon use, then connections 4220 established using PSKs enjoy not only anti-replay protection, but 4221 also forward secrecy once all copies of the PSK from the database 4222 entry have been deleted. This mechanism also improves security for 4223 PSK usage when PSK is used without (EC)DHE. 4225 Because this mechanism requires sharing the session database between 4226 server nodes in environments with multiple distributed servers, it 4227 may be hard to achieve high rates of successful PSK 0-RTT connections 4228 when compared to self-encrypted tickets. Unlike session databases, 4229 session tickets can successfully do PSK-based session establishment 4230 even without consistent storage, though when 0-RTT is allowed they 4231 still require consistent storage for anti-replay of 0-RTT data, as 4232 detailed in the following section. 4234 8.2. Client Hello Recording 4236 An alternative form of anti-replay is to record a unique value 4237 derived from the ClientHello (generally either the random value or 4238 the PSK binder) and reject duplicates. Recording all ClientHellos 4239 causes state to grow without bound, but a server can instead record 4240 ClientHellos within a given time window and use the 4241 "obfuscated_ticket_age" to ensure that tickets aren't reused outside 4242 that window. 4244 In order to implement this, when a ClientHello is received, the 4245 server first verifies the PSK binder as described in Section 4.2.11. 4246 It then computes the expected_arrival_time as described in the next 4247 section and rejects 0-RTT if it is outside the recording window, 4248 falling back to the 1-RTT handshake. 4250 If the expected_arrival_time is in the window, then the server checks 4251 to see if it has recorded a matching ClientHello. If one is found, 4252 it either aborts the handshake with an "illegal_parameter" alert or 4253 accepts the PSK but rejects 0-RTT. If no matching ClientHello is 4254 found, then it accepts 0-RTT and then stores the ClientHello for as 4255 long as the expected_arrival_time is inside the window. Servers MAY 4256 also implement data stores with false positives, such as Bloom 4257 filters, in which case they MUST respond to apparent replay by 4258 rejecting 0-RTT but MUST NOT abort the handshake. 4260 The server MUST derive the storage key only from validated sections 4261 of the ClientHello. If the ClientHello contains multiple PSK 4262 identities, then an attacker can create multiple ClientHellos with 4263 different binder values for the less-preferred identity on the 4264 assumption that the server will not verify it (as recommended by 4265 Section 4.2.11). I.e., if the client sends PSKs A and B but the 4266 server prefers A, then the attacker can change the binder for B 4267 without affecting the binder for A. If the binder for B is part of 4268 the storage key, then this ClientHello will not appear as a 4269 duplicate, which will cause the ClientHello to be accepted, and may 4270 cause side effects such as replay cache pollution, although any 0-RTT 4271 data will not be decryptable because it will use different keys. If 4272 the validated binder or the ClientHello.random is used as the storage 4273 key, then this attack is not possible. 4275 Because this mechanism does not require storing all outstanding 4276 tickets, it may be easier to implement in distributed systems with 4277 high rates of resumption and 0-RTT, at the cost of potentially weaker 4278 anti-replay defense because of the difficulty of reliably storing and 4279 retrieving the received ClientHello messages. In many such systems, 4280 it is impractical to have globally consistent storage of all the 4281 received ClientHellos. In this case, the best anti-replay protection 4282 is provided by having a single storage zone be authoritative for a 4283 given ticket and refusing 0-RTT for that ticket in any other zone. 4284 This approach prevents simple replay by the attacker because only one 4285 zone will accept 0-RTT data. A weaker design is to implement 4286 separate storage for each zone but allow 0-RTT in any zone. This 4287 approach limits the number of replays to once per zone. Application 4288 message duplication of course remains possible with either design. 4290 When implementations are freshly started, they SHOULD reject 0-RTT as 4291 long as any portion of their recording window overlaps the startup 4292 time. Otherwise, they run the risk of accepting replays which were 4293 originally sent during that period. 4295 Note: If the client's clock is running much faster than the server's, 4296 then a ClientHello may be received that is outside the window in the 4297 future, in which case it might be accepted for 1-RTT, causing a 4298 client retry, and then acceptable later for 0-RTT. This is another 4299 variant of the second form of attack described in Section 8. 4301 8.3. Freshness Checks 4303 Because the ClientHello indicates the time at which the client sent 4304 it, it is possible to efficiently determine whether a ClientHello was 4305 likely sent reasonably recently and only accept 0-RTT for such a 4306 ClientHello, otherwise falling back to a 1-RTT handshake. This is 4307 necessary for the ClientHello storage mechanism described in 4308 Section 8.2 because otherwise the server needs to store an unlimited 4309 number of ClientHellos, and is a useful optimization for self- 4310 contained single-use tickets because it allows efficient rejection of 4311 ClientHellos which cannot be used for 0-RTT. 4313 In order to implement this mechanism, a server needs to store the 4314 time that the server generated the session ticket, offset by an 4315 estimate of the round-trip time between client and server. I.e., 4317 adjusted_creation_time = creation_time + estimated_RTT 4319 This value can be encoded in the ticket, thus avoiding the need to 4320 keep state for each outstanding ticket. The server can determine the 4321 client's view of the age of the ticket by subtracting the ticket's 4322 "ticket_age_add" value from the "obfuscated_ticket_age" parameter in 4323 the client's "pre_shared_key" extension. The server can determine 4324 the expected_arrival_time of the ClientHello as: 4326 expected_arrival_time = adjusted_creation_time + clients_ticket_age 4328 When a new ClientHello is received, the expected_arrival_time is then 4329 compared against the current server wall clock time and if they 4330 differ by more than a certain amount, 0-RTT is rejected, though the 4331 1-RTT handshake can be allowed to complete. 4333 There are several potential sources of error that might cause 4334 mismatches between the expected_arrival_time and the measured time. 4335 Variations in client and server clock rates are likely to be minimal, 4336 though potentially the absolute times may be off by large values. 4337 Network propagation delays are the most likely causes of a mismatch 4338 in legitimate values for elapsed time. Both the NewSessionTicket and 4339 ClientHello messages might be retransmitted and therefore delayed, 4340 which might be hidden by TCP. For clients on the Internet, this 4341 implies windows on the order of ten seconds to account for errors in 4342 clocks and variations in measurements; other deployment scenarios may 4343 have different needs. Clock skew distributions are not symmetric, so 4344 the optimal tradeoff may involve an asymmetric range of permissible 4345 mismatch values. 4347 Note that freshness checking alone is not sufficient to prevent 4348 replays because it does not detect them during the error window, 4349 which -- depending on bandwidth and system capacity -- could include 4350 billions of replays in real-world settings. In addition, this 4351 freshness checking is only done at the time the ClientHello is 4352 received, and not when subsequent early Application Data records are 4353 received. After early data is accepted, records may continue to be 4354 streamed to the server over a longer time period. 4356 9. Compliance Requirements 4358 9.1. Mandatory-to-Implement Cipher Suites 4360 In the absence of an application profile standard specifying 4361 otherwise: 4363 A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 4364 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 4365 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see 4366 Appendix B.4). 4368 A TLS-compliant application MUST support digital signatures with 4369 rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for 4370 CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A 4371 TLS-compliant application MUST support key exchange with secp256r1 4372 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. 4374 9.2. Mandatory-to-Implement Extensions 4376 In the absence of an application profile standard specifying 4377 otherwise, a TLS-compliant application MUST implement the following 4378 TLS extensions: 4380 * Supported Versions ("supported_versions"; Section 4.2.1) 4382 * Cookie ("cookie"; Section 4.2.2) 4384 * Signature Algorithms ("signature_algorithms"; Section 4.2.3) 4386 * Signature Algorithms Certificate ("signature_algorithms_cert"; 4387 Section 4.2.3) 4389 * Negotiated Groups ("supported_groups"; Section 4.2.7) 4391 * Key Share ("key_share"; Section 4.2.8) 4393 * Server Name Indication ("server_name"; Section 3 of [RFC6066]) 4395 All implementations MUST send and use these extensions when offering 4396 applicable features: 4398 * "supported_versions" is REQUIRED for all ClientHello, ServerHello, 4399 and HelloRetryRequest messages. 4401 * "signature_algorithms" is REQUIRED for certificate authentication. 4403 * "supported_groups" is REQUIRED for ClientHello messages using DHE 4404 or ECDHE key exchange. 4406 * "key_share" is REQUIRED for DHE or ECDHE key exchange. 4408 * "pre_shared_key" is REQUIRED for PSK key agreement. 4410 * "psk_key_exchange_modes" is REQUIRED for PSK key agreement. 4412 A client is considered to be attempting to negotiate using this 4413 specification if the ClientHello contains a "supported_versions" 4414 extension with 0x0304 contained in its body. Such a ClientHello 4415 message MUST meet the following requirements: 4417 * If not containing a "pre_shared_key" extension, it MUST contain 4418 both a "signature_algorithms" extension and a "supported_groups" 4419 extension. 4421 * If containing a "supported_groups" extension, it MUST also contain 4422 a "key_share" extension, and vice versa. An empty 4423 KeyShare.client_shares list is permitted. 4425 Servers receiving a ClientHello which does not conform to these 4426 requirements MUST abort the handshake with a "missing_extension" 4427 alert. 4429 Additionally, all implementations MUST support the use of the 4430 "server_name" extension with applications capable of using it. 4431 Servers MAY require clients to send a valid "server_name" extension. 4432 Servers requiring this extension SHOULD respond to a ClientHello 4433 lacking a "server_name" extension by terminating the connection with 4434 a "missing_extension" alert. 4436 9.3. Protocol Invariants 4438 This section describes invariants that TLS endpoints and middleboxes 4439 MUST follow. It also applies to earlier versions of TLS. 4441 TLS is designed to be securely and compatibly extensible. Newer 4442 clients or servers, when communicating with newer peers, should 4443 negotiate the most preferred common parameters. The TLS handshake 4444 provides downgrade protection: Middleboxes passing traffic between a 4445 newer client and newer server without terminating TLS should be 4446 unable to influence the handshake (see Appendix F.1). At the same 4447 time, deployments update at different rates, so a newer client or 4448 server MAY continue to support older parameters, which would allow it 4449 to interoperate with older endpoints. 4451 For this to work, implementations MUST correctly handle extensible 4452 fields: 4454 * A client sending a ClientHello MUST support all parameters 4455 advertised in it. Otherwise, the server may fail to interoperate 4456 by selecting one of those parameters. 4458 * A server receiving a ClientHello MUST correctly ignore all 4459 unrecognized cipher suites, extensions, and other parameters. 4460 Otherwise, it may fail to interoperate with newer clients. In TLS 4461 1.3, a client receiving a CertificateRequest or NewSessionTicket 4462 MUST also ignore all unrecognized extensions. 4464 * A middlebox which terminates a TLS connection MUST behave as a 4465 compliant TLS server (to the original client), including having a 4466 certificate which the client is willing to accept, and also as a 4467 compliant TLS client (to the original server), including verifying 4468 the original server's certificate. In particular, it MUST 4469 generate its own ClientHello containing only parameters it 4470 understands, and it MUST generate a fresh ServerHello random 4471 value, rather than forwarding the endpoint's value. 4473 Note that TLS's protocol requirements and security analysis only 4474 apply to the two connections separately. Safely deploying a TLS 4475 terminator requires additional security considerations which are 4476 beyond the scope of this document. 4478 * A middlebox which forwards ClientHello parameters it does not 4479 understand MUST NOT process any messages beyond that ClientHello. 4480 It MUST forward all subsequent traffic unmodified. Otherwise, it 4481 may fail to interoperate with newer clients and servers. 4483 Forwarded ClientHellos may contain advertisements for features not 4484 supported by the middlebox, so the response may include future TLS 4485 additions the middlebox does not recognize. These additions MAY 4486 change any message beyond the ClientHello arbitrarily. In 4487 particular, the values sent in the ServerHello might change, the 4488 ServerHello format might change, and the TLSCiphertext format 4489 might change. 4491 The design of TLS 1.3 was constrained by widely deployed non- 4492 compliant TLS middleboxes (see Appendix E.4); however, it does not 4493 relax the invariants. Those middleboxes continue to be non- 4494 compliant. 4496 10. Security Considerations 4498 Security issues are discussed throughout this memo, especially in 4499 Appendix C, Appendix E, and Appendix F. 4501 11. IANA Considerations 4503 [[OPEN ISSUE: Should we remove this? I am reluctant to create a 4504 situation where one needs to read 8446 to process this document.]] 4506 [[OPEN ISSUE: Add some text to rename the extended_master_secret 4507 entry in the extensions registry to extended_main_secret, after the 4508 above is resolved.]] 4510 This document uses several registries that were originally created in 4511 [RFC4346] and updated in [RFC8447]. IANA has updated these to 4512 reference this document. The registries and their allocation 4513 policies are below: 4515 * TLS Cipher Suites registry: values with the first byte in the 4516 range 0-254 (decimal) are assigned via Specification Required 4517 [RFC8126]. Values with the first byte 255 (decimal) are reserved 4518 for Private Use [RFC8126]. 4520 IANA has added the cipher suites listed in Appendix B.4 to the 4521 registry. The "Value" and "Description" columns are taken from 4522 the table. The "DTLS-OK" and "Recommended" columns are both 4523 marked as "Y" for each new cipher suite. 4525 * TLS ContentType registry: Future values are allocated via 4526 Standards Action [RFC8126]. 4528 * TLS Alerts registry: Future values are allocated via Standards 4529 Action [RFC8126]. IANA has populated this registry with the 4530 values from Appendix B.2. The "DTLS-OK" column is marked as "Y" 4531 for all such values. Values marked as "_RESERVED" have comments 4532 describing their previous usage. 4534 * TLS HandshakeType registry: Future values are allocated via 4535 Standards Action [RFC8126]. IANA has updated this registry to 4536 rename item 4 from "NewSessionTicket" to "new_session_ticket" and 4537 populated this registry with the values from Appendix B.3. The 4538 "DTLS-OK" column is marked as "Y" for all such values. Values 4539 marked "_RESERVED" have comments describing their previous or 4540 temporary usage. 4542 This document also uses the TLS ExtensionType Values registry 4543 originally created in [RFC4366]. IANA has updated it to reference 4544 this document. Changes to the registry follow: 4546 * IANA has updated the registration policy as follows: 4548 Values with the first byte in the range 0-254 (decimal) are 4549 assigned via Specification Required [RFC8126]. Values with the 4550 first byte 255 (decimal) are reserved for Private Use [RFC8126]. 4552 * IANA has updated this registry to include the "key_share", 4553 "pre_shared_key", "psk_key_exchange_modes", "early_data", 4554 "cookie", "supported_versions", "certificate_authorities", 4555 "oid_filters", "post_handshake_auth", and 4556 "signature_algorithms_cert" extensions with the values defined in 4557 this document and the "Recommended" value of "Y". 4559 * IANA has updated this registry to include a "TLS 1.3" column which 4560 lists the messages in which the extension may appear. This column 4561 has been initially populated from the table in Section 4.2, with 4562 any extension not listed there marked as "-" to indicate that it 4563 is not used by TLS 1.3. 4565 This document updates an entry in the TLS Certificate Types registry 4566 originally created in [RFC6091] and updated in [RFC8447]. IANA has 4567 updated the entry for value 1 to have the name "OpenPGP_RESERVED", 4568 "Recommended" value "N", and comment "Used in TLS versions prior to 4569 1.3." IANA has updated the entry for value 0 to have the name 4570 "X509", "Recommended" value "Y", and comment "Was X.509 before TLS 4571 1.3". 4573 This document updates an entry in the TLS Certificate Status Types 4574 registry originally created in [RFC6961]. IANA has updated the entry 4575 for value 2 to have the name "ocsp_multi_RESERVED" and comment "Used 4576 in TLS versions prior to 1.3". 4578 This document updates two entries in the TLS Supported Groups 4579 registry (created under a different name by [RFC4492]; now maintained 4580 by [RFC8422]) and updated by [RFC7919] and [RFC8447]. The entries 4581 for values 29 and 30 (x25519 and x448) have been updated to also 4582 refer to this document. 4584 In addition, this document defines two new registries that are 4585 maintained by IANA: 4587 * TLS SignatureScheme registry: Values with the first byte in the 4588 range 0-253 (decimal) are assigned via Specification Required 4589 [RFC8126]. Values with the first byte 254 or 255 (decimal) are 4590 reserved for Private Use [RFC8126]. Values with the first byte in 4591 the range 0-6 or with the second byte in the range 0-3 that are 4592 not currently allocated are reserved for backward compatibility. 4593 This registry has a "Recommended" column. The registry has been 4594 initially populated with the values described in Section 4.2.3. 4595 The following values are marked as "Recommended": 4596 ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, 4597 rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, 4598 rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and 4599 ed25519. The "Recommended" column is assigned a value of "N" 4600 unless explicitly requested, and adding a value with a 4601 "Recommended" value of "Y" requires Standards Action [RFC8126]. 4602 IESG Approval is REQUIRED for a Y->N transition. 4604 * TLS PskKeyExchangeMode registry: Values in the range 0-253 4605 (decimal) are assigned via Specification Required [RFC8126]. The 4606 values 254 and 255 (decimal) are reserved for Private Use 4608 [RFC8126]. This registry has a "Recommended" column. The 4609 registry has been initially populated with psk_ke (0) and 4610 psk_dhe_ke (1). Both are marked as "Recommended". The 4611 "Recommended" column is assigned a value of "N" unless explicitly 4612 requested, and adding a value with a "Recommended" value of "Y" 4613 requires Standards Action [RFC8126]. IESG Approval is REQUIRED 4614 for a Y->N transition. 4616 12. References 4618 12.1. Normative References 4620 [DH76] Diffie, W. and M. Hellman, "New directions in 4621 cryptography", IEEE Transactions on Information 4622 Theory Vol. 22, pp. 644-654, DOI 10.1109/tit.1976.1055638, 4623 November 1976, . 4625 [ECDSA] American National Standards Institute, "Public Key 4626 Cryptography for the Financial Services Industry: The 4627 Elliptic Curve Digital Signature Algorithm (ECDSA)", 4628 ANSI ANS X9.62-2005, November 2005. 4630 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 4631 Operation: Galois/Counter Mode (GCM) and GMAC", 4632 NIST Special Publication 800-38D, November 2007. 4634 [IEEE1363] "IEEE Standard Specifications for Public-Key 4635 Cryptography", IEEE standard, 4636 DOI 10.1109/ieeestd.2000.92292, n.d., 4637 . 4639 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4640 Hashing for Message Authentication", RFC 2104, 4641 DOI 10.17487/RFC2104, February 1997, 4642 . 4644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4645 Requirement Levels", BCP 14, RFC 2119, 4646 DOI 10.17487/RFC2119, March 1997, 4647 . 4649 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 4650 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 4651 . 4653 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 4654 Housley, R., and W. Polk, "Internet X.509 Public Key 4655 Infrastructure Certificate and Certificate Revocation List 4656 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 4657 . 4659 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 4660 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 4661 March 2010, . 4663 [RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 4664 "Updates for RSAES-OAEP and RSASSA-PSS Algorithm 4665 Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010, 4666 . 4668 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 4669 Key Derivation Function (HKDF)", RFC 5869, 4670 DOI 10.17487/RFC5869, May 2010, 4671 . 4673 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 4674 Extensions: Extension Definitions", RFC 6066, 4675 DOI 10.17487/RFC6066, January 2011, 4676 . 4678 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 4679 Transport Layer Security (TLS)", RFC 6655, 4680 DOI 10.17487/RFC6655, July 2012, 4681 . 4683 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 4684 Galperin, S., and C. Adams, "X.509 Internet Public Key 4685 Infrastructure Online Certificate Status Protocol - OCSP", 4686 RFC 6960, DOI 10.17487/RFC6960, June 2013, 4687 . 4689 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 4690 Multiple Certificate Status Request Extension", RFC 6961, 4691 DOI 10.17487/RFC6961, June 2013, 4692 . 4694 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 4695 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 4696 . 4698 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 4699 Algorithm (DSA) and Elliptic Curve Digital Signature 4700 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 4701 2013, . 4703 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 4704 "Transport Layer Security (TLS) Application-Layer Protocol 4705 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 4706 July 2014, . 4708 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 4709 Suite Value (SCSV) for Preventing Protocol Downgrade 4710 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 4711 . 4713 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 4714 Langley, A., and M. Ray, "Transport Layer Security (TLS) 4715 Session Hash and Extended Master Secret Extension", 4716 RFC 7627, DOI 10.17487/RFC7627, September 2015, 4717 . 4719 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 4720 for Security", RFC 7748, DOI 10.17487/RFC7748, January 4721 2016, . 4723 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 4724 Ephemeral Parameters for Transport Layer Security (TLS)", 4725 RFC 7919, DOI 10.17487/RFC7919, August 2016, 4726 . 4728 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 4729 "PKCS #1: RSA Cryptography Specifications Version 2.2", 4730 RFC 8017, DOI 10.17487/RFC8017, November 2016, 4731 . 4733 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 4734 Signature Algorithm (EdDSA)", RFC 8032, 4735 DOI 10.17487/RFC8032, January 2017, 4736 . 4738 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4739 Writing an IANA Considerations Section in RFCs", BCP 26, 4740 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4741 . 4743 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4744 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4745 May 2017, . 4747 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 4748 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 4749 . 4751 [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 4752 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 4753 . 4755 [SHS] Dang, Q., "Secure Hash Standard", National Institute of 4756 Standards and Technology report, 4757 DOI 10.6028/nist.fips.180-4, July 2015, 4758 . 4760 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 4761 Specification of Basic Encoding Rules (BER), Canonical 4762 Encoding Rules (CER) and Distinguished Encoding Rules 4763 (DER)", ISO/IEC 8824-1:2021 , February 2021. 4765 12.2. Informative References 4767 [AEAD-LIMITS] 4768 Luykx, A. and K. Paterson, "Limits on Authenticated 4769 Encryption Use in TLS", August 2017, 4770 . 4772 [BBFGKZ16] Bhargavan, K., Brzuska, C., Fournet, C., Green, M., 4773 Kohlweiss, M., and S. Zanella-Beguelin, "Downgrade 4774 Resilience in Key-Exchange Protocols", 2016 IEEE Symposium 4775 on Security and Privacy (SP), DOI 10.1109/sp.2016.37, May 4776 2016, . 4778 [BBK17] Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified 4779 Models and Reference Implementations for the TLS 1.3 4780 Standard Candidate", 2017 IEEE Symposium on Security and 4781 Privacy (SP), DOI 10.1109/sp.2017.26, May 2017, 4782 . 4784 [BDFKPPRSZZ16] 4785 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., 4786 Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy, 4787 N., Zanella-Beguelin, S., and J. Zinzindohoue, 4788 "Implementing and Proving the TLS 1.3 Record Layer", 4789 Proceedings of IEEE Symposium on Security and Privacy (San 4790 Jose) 2017 , December 2016, 4791 . 4793 [Ben17a] Benjamin, D., "Presentation before the TLS WG at IETF 4794 100", 2017, 4795 . 4798 [Ben17b] Benjamin, D., "Additional TLS 1.3 results from Chrome", 4799 2017, . 4802 [Blei98] Bleichenbacher, D., "Chosen Ciphertext Attacks against 4803 Protocols Based on RSA Encryption Standard PKCS #1", 4804 Proceedings of CRYPTO '98 , 1998. 4806 [BMMRT15] Badertscher, C., Matt, C., Maurer, U., Rogaway, P., and B. 4807 Tackmann, "Augmented Secure Channels and the Goal of the 4808 TLS 1.3 Record Layer", ProvSec 2015 , September 2015, 4809 . 4811 [BT16] Bellare, M. and B. Tackmann, "The Multi-User Security of 4812 Authenticated Encryption: AES-GCM in TLS 1.3", Proceedings 4813 of CRYPTO 2016 , July 2016, 4814 . 4816 [CCG16] Cohn-Gordon, K., Cremers, C., and L. Garratt, "On Post- 4817 compromise Security", 2016 IEEE 29th Computer Security 4818 Foundations Symposium (CSF), DOI 10.1109/csf.2016.19, June 4819 2016, . 4821 [CHECKOWAY] 4822 Checkoway, S., Maskiewicz, J., Garman, C., Fried, J., 4823 Cohney, S., Green, M., Heninger, N., Weinmann, R., 4824 Rescorla, E., and H. Shacham, "A Systematic Analysis of 4825 the Juniper Dual EC Incident", Proceedings of the 2016 ACM 4826 SIGSAC Conference on Computer and Communications Security, 4827 DOI 10.1145/2976749.2978395, October 2016, 4828 . 4830 [CHHSV17] Cremers, C., Horvat, M., Hoyland, J., van der Merwe, T., 4831 and S. Scott, "Awkward Handshake: Possible mismatch of 4832 client/server view on client authentication in post- 4833 handshake mode in Revision 18", message to the TLS mailing 4834 list , February 2017, . 4837 [CHSV16] Cremers, C., Horvat, M., Scott, S., and T. van der Merwe, 4838 "Automated Analysis and Verification of TLS 1.3: 0-RTT, 4839 Resumption and Delayed Authentication", 2016 IEEE 4840 Symposium on Security and Privacy (SP), 4841 DOI 10.1109/sp.2016.35, May 2016, 4842 . 4844 [CK01] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange 4845 Protocols and Their Use for Building Secure Channels", 4846 Lecture Notes in Computer Science pp. 453-474, 4847 DOI 10.1007/3-540-44987-6_28, 2001, 4848 . 4850 [CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know 4851 Why You Went to the Clinic: Risks and Realization of HTTPS 4852 Traffic Analysis", Privacy Enhancing Technologies pp. 4853 143-163, DOI 10.1007/978-3-319-08506-7_8, 2014, 4854 . 4856 [DFGS15] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, 4857 "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and 4858 Pre-shared Key Handshake Protocol", Proceedings of ACM CCS 4859 2015 , October 2016, . 4861 [DFGS16] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, 4862 "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and 4863 Pre-shared Key Handshake Protocol", TRON 2016 , February 4864 2016, . 4866 [DOW92] Diffie, W., Van Oorschot, P., and M. Wiener, 4867 "Authentication and authenticated key exchanges", Designs, 4868 Codes and Cryptography Vol. 2, pp. 107-125, 4869 DOI 10.1007/bf00124891, June 1992, 4870 . 4872 [DSA-1571-1] 4873 The Debian Project, "openssl -- predictable random number 4874 generator", May 2008, 4875 . 4877 [DSS] "Digital Signature Standard (DSS)", National Institute of 4878 Standards and Technology report, 4879 DOI 10.6028/nist.fips.186-4, July 2013, 4880 . 4882 [FETCH] WHATWG, "Fetch Standard", March 2022, 4883 . 4885 [FG17] Fischlin, M. and F. Guenther, "Replay Attacks on Zero 4886 Round-Trip Time: The Case of the TLS 1.3 Handshake 4887 Candidates", Proceedings of Euro S&P 2017 , 2017, 4888 . 4890 [FGSW16] Fischlin, M., Guenther, F., Schmidt, B., and B. Warinschi, 4891 "Key Confirmation in Key Exchange: A Formal Treatment and 4892 Implications for TLS 1.3", Proceedings of IEEE Symposium 4893 on Security and Privacy (Oakland) 2016 , 2016, 4894 . 4896 [FW15] Weimer, F., "Factoring RSA Keys With TLS Perfect Forward 4897 Secrecy", September 2015. 4899 [HCJC16] Husák, M., Čermák, M., Jirsík, T., and P. Čeleda, "HTTPS 4900 traffic analysis and client identification using passive 4901 SSL/TLS fingerprinting", EURASIP Journal on Information 4902 Security Vol. 2016, DOI 10.1186/s13635-016-0030-7, 4903 February 2016, 4904 . 4906 [HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes, 4907 "Prying Open Pandora's Box: KCI Attacks against TLS", 4908 Proceedings of USENIX Workshop on Offensive Technologies , 4909 2015. 4911 [JSS15] Jager, T., Schwenk, J., and J. Somorovsky, "On the 4912 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 4913 v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC 4914 Conference on Computer and Communications Security, 4915 DOI 10.1145/2810103.2813657, October 2015, 4916 . 4918 [KEYAGREEMENT] 4919 Barker, E., Chen, L., Roginsky, A., and M. Smid, 4920 "Recommendation for Pair-Wise Key Establishment Schemes 4921 Using Discrete Logarithm Cryptography", National Institute 4922 of Standards and Technology report, 4923 DOI 10.6028/nist.sp.800-56ar2, May 2013, 4924 . 4926 [Kraw10] Krawczyk, H., "Cryptographic Extraction and Key 4927 Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 , 4928 2010, . 4930 [Kraw16] Krawczyk, H., "A Unilateral-to-Mutual Authentication 4931 Compiler for Key Exchange (with Applications to Client 4932 Authentication in TLS 1.3", Proceedings of ACM CCS 2016 , 4933 October 2016, . 4935 [KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", 4936 Proceedings of Euro S&P 2016 , 2016, 4937 . 4939 [LXZFH16] Li, X., Xu, J., Zhang, Z., Feng, D., and H. Hu, "Multiple 4940 Handshakes Security of TLS 1.3 Candidates", 2016 IEEE 4941 Symposium on Security and Privacy (SP), 4942 DOI 10.1109/sp.2016.36, May 2016, 4943 . 4945 [Mac17] MacCarthaigh, C., "Security Review of TLS1.3 0-RTT", March 4946 2017, . 4948 [PS18] Patton, C. and T. Shrimpton, "Partially specified 4949 channels: The TLS 1.3 record layer without elision", 2018, 4950 . 4952 [PSK-FINISHED] 4953 Cremers, C., Horvat, M., van der Merwe, T., and S. Scott, 4954 "Revision 10: possible attack if client authentication is 4955 allowed during PSK", message to the TLS mailing list, , 4956 2015, . 4959 [REKEY] Abdalla, M. and M. Bellare, "Increasing the Lifetime of a 4960 Key: A Comparative Analysis of the Security of Re-keying 4961 Techniques", Advances in Cryptology - ASIACRYPT 2000 pp. 4962 546-559, DOI 10.1007/3-540-44448-3_42, 2000, 4963 . 4965 [Res17a] Rescorla, E., "Preliminary data on Firefox TLS 1.3 4966 Middlebox experiment", message to the TLS mailing list , 4967 2017, . 4970 [Res17b] Rescorla, E., "More compatibility measurement results", 4971 message to the TLS mailing list , December 2017, 4972 . 4975 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 4976 RFC 2246, DOI 10.17487/RFC2246, January 1999, 4977 . 4979 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 4980 Text on Security Considerations", BCP 72, RFC 3552, 4981 DOI 10.17487/RFC3552, July 2003, 4982 . 4984 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 4985 "Randomness Requirements for Security", BCP 106, RFC 4086, 4986 DOI 10.17487/RFC4086, June 2005, 4987 . 4989 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 4990 (TLS) Protocol Version 1.1", RFC 4346, 4991 DOI 10.17487/RFC4346, April 2006, 4992 . 4994 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 4995 and T. Wright, "Transport Layer Security (TLS) 4996 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 4997 . 4999 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 5000 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 5001 for Transport Layer Security (TLS)", RFC 4492, 5002 DOI 10.17487/RFC4492, May 2006, 5003 . 5005 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 5006 "Transport Layer Security (TLS) Session Resumption without 5007 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 5008 January 2008, . 5010 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 5011 (TLS) Protocol Version 1.2", RFC 5246, 5012 DOI 10.17487/RFC5246, August 2008, 5013 . 5015 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 5016 Security (DTLS) Extension to Establish Keys for the Secure 5017 Real-time Transport Protocol (SRTP)", RFC 5764, 5018 DOI 10.17487/RFC5764, May 2010, 5019 . 5021 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 5022 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 5023 . 5025 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 5026 for Transport Layer Security (TLS) Authentication", 5027 RFC 6091, DOI 10.17487/RFC6091, February 2011, 5028 . 5030 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 5031 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 5032 DOI 10.17487/RFC6101, August 2011, 5033 . 5035 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 5036 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 5037 2011, . 5039 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 5040 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 5041 January 2012, . 5043 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 5044 Layer Security (TLS) and Datagram Transport Layer Security 5045 (DTLS) Heartbeat Extension", RFC 6520, 5046 DOI 10.17487/RFC6520, February 2012, 5047 . 5049 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 5050 Protocol (HTTP/1.1): Message Syntax and Routing", 5051 RFC 7230, DOI 10.17487/RFC7230, June 2014, 5052 . 5054 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 5055 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 5056 Transport Layer Security (TLS) and Datagram Transport 5057 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 5058 June 2014, . 5060 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 5061 DOI 10.17487/RFC7465, February 2015, 5062 . 5064 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 5065 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 5066 DOI 10.17487/RFC7568, June 2015, 5067 . 5069 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 5070 Trammell, B., Huitema, C., and D. Borkmann, 5071 "Confidentiality in the Face of Pervasive Surveillance: A 5072 Threat Model and Problem Statement", RFC 7624, 5073 DOI 10.17487/RFC7624, August 2015, 5074 . 5076 [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello 5077 Padding Extension", RFC 7685, DOI 10.17487/RFC7685, 5078 October 2015, . 5080 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 5081 (TLS) Cached Information Extension", RFC 7924, 5082 DOI 10.17487/RFC7924, July 2016, 5083 . 5085 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 5086 Better Connectivity Using Concurrency", RFC 8305, 5087 DOI 10.17487/RFC8305, December 2017, 5088 . 5090 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 5091 Curve Cryptography (ECC) Cipher Suites for Transport Layer 5092 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 5093 DOI 10.17487/RFC8422, August 2018, 5094 . 5096 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5097 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5098 . 5100 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 5101 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 5102 . 5104 [RFC8448] Thomson, M., "Example Handshake Traces for TLS 1.3", 5105 RFC 8448, DOI 10.17487/RFC8448, January 2019, 5106 . 5108 [RFC8449] Thomson, M., "Record Size Limit Extension for TLS", 5109 RFC 8449, DOI 10.17487/RFC8449, August 2018, 5110 . 5112 [RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate 5113 Compression", RFC 8879, DOI 10.17487/RFC8879, December 5114 2020, . 5116 [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 5117 and C. Wood, "Randomness Improvements for Security 5118 Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, 5119 . 5121 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A method for 5122 obtaining digital signatures and public-key 5123 cryptosystems", Communications of the ACM Vol. 21, pp. 5124 120-126, DOI 10.1145/359340.359342, February 1978, 5125 . 5127 [SIGMA] Krawczyk, H., "SIGMA: The ‘SIGn-and-MAc’ Approach to 5128 Authenticated Diffie-Hellman and Its Use in the IKE 5129 Protocols", Advances in Cryptology - CRYPTO 2003 pp. 5130 400-425, DOI 10.1007/978-3-540-45146-4_24, 2003, 5131 . 5133 [SLOTH] Bhargavan, K. and G. Leurent, "Transcript Collision 5134 Attacks: Breaking Authentication in TLS, IKE, and SSH", 5135 Proceedings 2016 Network and Distributed System 5136 Security Symposium, DOI 10.14722/ndss.2016.23418, 2016, 5137 . 5139 [SSL2] Hickman, K., "The SSL Protocol", 9 February 1995. 5141 [TIMING] Boneh, D. and D. Brumley, "Remote Timing Attacks Are 5142 Practical", USENIX Security Symposium, 2003. 5144 [X501] ITU-T, "Information Technology - Open Systems 5145 Interconnection - The Directory: Models", ISO/IEC 5146 9594-2:2020 , October 2019. 5148 Appendix A. State Machine 5150 This appendix provides a summary of the legal state transitions for 5151 the client and server handshakes. State names (in all capitals, 5152 e.g., START) have no formal meaning but are provided for ease of 5153 comprehension. Actions which are taken only in certain circumstances 5154 are indicated in []. The notation "K_{send,recv} = foo" means "set 5155 the send/recv key to the given key". 5157 A.1. Client 5158 START <----+ 5159 Send ClientHello | | Recv HelloRetryRequest 5160 [K_send = early data] | | 5161 v | 5162 / WAIT_SH ----+ 5163 | | Recv ServerHello 5164 | | K_recv = handshake 5165 Can | V 5166 send | WAIT_EE 5167 early | | Recv EncryptedExtensions 5168 data | +--------+--------+ 5169 | Using | | Using certificate 5170 | PSK | v 5171 | | WAIT_CERT_CR 5172 | | Recv | | Recv CertificateRequest 5173 | | Certificate | v 5174 | | | WAIT_CERT 5175 | | | | Recv Certificate 5176 | | v v 5177 | | WAIT_CV 5178 | | | Recv CertificateVerify 5179 | +> WAIT_FINISHED <+ 5180 | | Recv Finished 5181 \ | [Send EndOfEarlyData] 5182 | K_send = handshake 5183 | [Send Certificate [+ CertificateVerify]] 5184 Can send | Send Finished 5185 app data --> | K_send = K_recv = application 5186 after here v 5187 CONNECTED 5189 Note that with the transitions as shown above, clients may send 5190 alerts that derive from post-ServerHello messages in the clear or 5191 with the early data keys. If clients need to send such alerts, they 5192 SHOULD first rekey to the handshake keys if possible. 5194 A.2. Server 5195 START <-----+ 5196 Recv ClientHello | | Send HelloRetryRequest 5197 v | 5198 RECVD_CH ----+ 5199 | Select parameters 5200 v 5201 NEGOTIATED 5202 | Send ServerHello 5203 | K_send = handshake 5204 | Send EncryptedExtensions 5205 | [Send CertificateRequest] 5206 Can send | [Send Certificate + CertificateVerify] 5207 app data | Send Finished 5208 after --> | K_send = application 5209 here +--------+--------+ 5210 No 0-RTT | | 0-RTT 5211 | | 5212 K_recv = handshake | | K_recv = early data 5213 [Skip decrypt errors] | +------> WAIT_EOED -+ 5214 | | Recv | | Recv EndOfEarlyData 5215 | | early data | | K_recv = handshake 5216 | +------------+ | 5217 | | 5218 +> WAIT_FLIGHT2 <--------+ 5219 | 5220 +--------+--------+ 5221 No auth | | Cert-based client auth 5222 | | 5223 | v 5224 | WAIT_CERT 5225 | Recv | | Recv Certificate 5226 | empty | v 5227 | Certificate | WAIT_CV 5228 | | | Recv 5229 | v | CertificateVerify 5230 +-> WAIT_FINISHED <---+ 5231 | Recv Finished 5232 | K_recv = application 5233 v 5234 CONNECTED 5236 Appendix B. Protocol Data Structures and Constant Values 5238 This appendix provides the normative protocol types and the 5239 definitions for constants. Values listed as "_RESERVED" were used in 5240 previous versions of TLS and are listed here for completeness. TLS 5241 1.3 implementations MUST NOT send them but might receive them from 5242 older TLS implementations. 5244 B.1. Record Layer 5246 enum { 5247 invalid(0), 5248 change_cipher_spec(20), 5249 alert(21), 5250 handshake(22), 5251 application_data(23), 5252 (255) 5253 } ContentType; 5255 struct { 5256 ContentType type; 5257 ProtocolVersion legacy_record_version; 5258 uint16 length; 5259 opaque fragment[TLSPlaintext.length]; 5260 } TLSPlaintext; 5262 struct { 5263 opaque content[TLSPlaintext.length]; 5264 ContentType type; 5265 uint8 zeros[length_of_padding]; 5266 } TLSInnerPlaintext; 5268 struct { 5269 ContentType opaque_type = application_data; /* 23 */ 5270 ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */ 5271 uint16 length; 5272 opaque encrypted_record[TLSCiphertext.length]; 5273 } TLSCiphertext; 5275 B.2. Alert Messages 5276 enum { warning(1), fatal(2), (255) } AlertLevel; 5278 enum { 5279 close_notify(0), 5280 unexpected_message(10), 5281 bad_record_mac(20), 5282 decryption_failed_RESERVED(21), 5283 record_overflow(22), 5284 decompression_failure_RESERVED(30), 5285 handshake_failure(40), 5286 no_certificate_RESERVED(41), 5287 bad_certificate(42), 5288 unsupported_certificate(43), 5289 certificate_revoked(44), 5290 certificate_expired(45), 5291 certificate_unknown(46), 5292 illegal_parameter(47), 5293 unknown_ca(48), 5294 access_denied(49), 5295 decode_error(50), 5296 decrypt_error(51), 5297 export_restriction_RESERVED(60), 5298 protocol_version(70), 5299 insufficient_security(71), 5300 internal_error(80), 5301 inappropriate_fallback(86), 5302 user_canceled(90), 5303 no_renegotiation_RESERVED(100), 5304 missing_extension(109), 5305 unsupported_extension(110), 5306 certificate_unobtainable_RESERVED(111), 5307 unrecognized_name(112), 5308 bad_certificate_status_response(113), 5309 bad_certificate_hash_value_RESERVED(114), 5310 unknown_psk_identity(115), 5311 certificate_required(116), 5312 no_application_protocol(120), 5313 (255) 5314 } AlertDescription; 5316 struct { 5317 AlertLevel level; 5318 AlertDescription description; 5319 } Alert; 5321 B.3. Handshake Protocol 5322 enum { 5323 hello_request_RESERVED(0), 5324 client_hello(1), 5325 server_hello(2), 5326 hello_verify_request_RESERVED(3), 5327 new_session_ticket(4), 5328 end_of_early_data(5), 5329 hello_retry_request_RESERVED(6), 5330 encrypted_extensions(8), 5331 certificate(11), 5332 server_key_exchange_RESERVED(12), 5333 certificate_request(13), 5334 server_hello_done_RESERVED(14), 5335 certificate_verify(15), 5336 client_key_exchange_RESERVED(16), 5337 finished(20), 5338 certificate_url_RESERVED(21), 5339 certificate_status_RESERVED(22), 5340 supplemental_data_RESERVED(23), 5341 key_update(24), 5342 message_hash(254), 5343 (255) 5344 } HandshakeType; 5346 struct { 5347 HandshakeType msg_type; /* handshake type */ 5348 uint24 length; /* remaining bytes in message */ 5349 select (Handshake.msg_type) { 5350 case client_hello: ClientHello; 5351 case server_hello: ServerHello; 5352 case end_of_early_data: EndOfEarlyData; 5353 case encrypted_extensions: EncryptedExtensions; 5354 case certificate_request: CertificateRequest; 5355 case certificate: Certificate; 5356 case certificate_verify: CertificateVerify; 5357 case finished: Finished; 5358 case new_session_ticket: NewSessionTicket; 5359 case key_update: KeyUpdate; 5360 }; 5361 } Handshake; 5363 B.3.1. Key Exchange Messages 5364 uint16 ProtocolVersion; 5365 opaque Random[32]; 5367 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 5369 struct { 5370 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 5371 Random random; 5372 opaque legacy_session_id<0..32>; 5373 CipherSuite cipher_suites<2..2^16-2>; 5374 opaque legacy_compression_methods<1..2^8-1>; 5375 Extension extensions<8..2^16-1>; 5376 } ClientHello; 5378 struct { 5379 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 5380 Random random; 5381 opaque legacy_session_id_echo<0..32>; 5382 CipherSuite cipher_suite; 5383 uint8 legacy_compression_method = 0; 5384 Extension extensions<6..2^16-1>; 5385 } ServerHello; 5387 struct { 5388 ExtensionType extension_type; 5389 opaque extension_data<0..2^16-1>; 5390 } Extension; 5392 enum { 5393 server_name(0), /* RFC 6066 */ 5394 max_fragment_length(1), /* RFC 6066 */ 5395 status_request(5), /* RFC 6066 */ 5396 supported_groups(10), /* RFC 8422, 7919 */ 5397 signature_algorithms(13), /* RFC 8446 */ 5398 use_srtp(14), /* RFC 5764 */ 5399 heartbeat(15), /* RFC 6520 */ 5400 application_layer_protocol_negotiation(16), /* RFC 7301 */ 5401 signed_certificate_timestamp(18), /* RFC 6962 */ 5402 client_certificate_type(19), /* RFC 7250 */ 5403 server_certificate_type(20), /* RFC 7250 */ 5404 padding(21), /* RFC 7685 */ 5405 pre_shared_key(41), /* RFC 8446 */ 5406 early_data(42), /* RFC 8446 */ 5407 supported_versions(43), /* RFC 8446 */ 5408 cookie(44), /* RFC 8446 */ 5409 psk_key_exchange_modes(45), /* RFC 8446 */ 5410 certificate_authorities(47), /* RFC 8446 */ 5411 oid_filters(48), /* RFC 8446 */ 5412 post_handshake_auth(49), /* RFC 8446 */ 5413 signature_algorithms_cert(50), /* RFC 8446 */ 5414 key_share(51), /* RFC 8446 */ 5415 (65535) 5416 } ExtensionType; 5418 struct { 5419 NamedGroup group; 5420 opaque key_exchange<1..2^16-1>; 5421 } KeyShareEntry; 5423 struct { 5424 KeyShareEntry client_shares<0..2^16-1>; 5425 } KeyShareClientHello; 5427 struct { 5428 NamedGroup selected_group; 5429 } KeyShareHelloRetryRequest; 5431 struct { 5432 KeyShareEntry server_share; 5433 } KeyShareServerHello; 5435 struct { 5436 uint8 legacy_form = 4; 5437 opaque X[coordinate_length]; 5438 opaque Y[coordinate_length]; 5439 } UncompressedPointRepresentation; 5441 enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; 5443 struct { 5444 PskKeyExchangeMode ke_modes<1..255>; 5445 } PskKeyExchangeModes; 5447 struct {} Empty; 5449 struct { 5450 select (Handshake.msg_type) { 5451 case new_session_ticket: uint32 max_early_data_size; 5452 case client_hello: Empty; 5453 case encrypted_extensions: Empty; 5454 }; 5455 } EarlyDataIndication; 5457 struct { 5458 opaque identity<1..2^16-1>; 5459 uint32 obfuscated_ticket_age; 5461 } PskIdentity; 5463 opaque PskBinderEntry<32..255>; 5465 struct { 5466 PskIdentity identities<7..2^16-1>; 5467 PskBinderEntry binders<33..2^16-1>; 5468 } OfferedPsks; 5470 struct { 5471 select (Handshake.msg_type) { 5472 case client_hello: OfferedPsks; 5473 case server_hello: uint16 selected_identity; 5474 }; 5475 } PreSharedKeyExtension; 5477 B.3.1.1. Version Extension 5479 struct { 5480 select (Handshake.msg_type) { 5481 case client_hello: 5482 ProtocolVersion versions<2..254>; 5484 case server_hello: /* and HelloRetryRequest */ 5485 ProtocolVersion selected_version; 5486 }; 5487 } SupportedVersions; 5489 B.3.1.2. Cookie Extension 5491 struct { 5492 opaque cookie<1..2^16-1>; 5493 } Cookie; 5495 B.3.1.3. Signature Algorithm Extension 5496 enum { 5497 /* RSASSA-PKCS1-v1_5 algorithms */ 5498 rsa_pkcs1_sha256(0x0401), 5499 rsa_pkcs1_sha384(0x0501), 5500 rsa_pkcs1_sha512(0x0601), 5502 /* ECDSA algorithms */ 5503 ecdsa_secp256r1_sha256(0x0403), 5504 ecdsa_secp384r1_sha384(0x0503), 5505 ecdsa_secp521r1_sha512(0x0603), 5507 /* RSASSA-PSS algorithms with public key OID rsaEncryption */ 5508 rsa_pss_rsae_sha256(0x0804), 5509 rsa_pss_rsae_sha384(0x0805), 5510 rsa_pss_rsae_sha512(0x0806), 5512 /* EdDSA algorithms */ 5513 ed25519(0x0807), 5514 ed448(0x0808), 5516 /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */ 5517 rsa_pss_pss_sha256(0x0809), 5518 rsa_pss_pss_sha384(0x080a), 5519 rsa_pss_pss_sha512(0x080b), 5521 /* Legacy algorithms */ 5522 rsa_pkcs1_sha1(0x0201), 5523 ecdsa_sha1(0x0203), 5525 /* Reserved Code Points */ 5526 obsolete_RESERVED(0x0000..0x0200), 5527 dsa_sha1_RESERVED(0x0202), 5528 obsolete_RESERVED(0x0204..0x0400), 5529 dsa_sha256_RESERVED(0x0402), 5530 obsolete_RESERVED(0x0404..0x0500), 5531 dsa_sha384_RESERVED(0x0502), 5532 obsolete_RESERVED(0x0504..0x0600), 5533 dsa_sha512_RESERVED(0x0602), 5534 obsolete_RESERVED(0x0604..0x06FF), 5535 private_use(0xFE00..0xFFFF), 5536 (0xFFFF) 5537 } SignatureScheme; 5539 struct { 5540 SignatureScheme supported_signature_algorithms<2..2^16-2>; 5541 } SignatureSchemeList; 5543 B.3.1.4. Supported Groups Extension 5545 enum { 5546 unallocated_RESERVED(0x0000), 5548 /* Elliptic Curve Groups (ECDHE) */ 5549 obsolete_RESERVED(0x0001..0x0016), 5550 secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), 5551 obsolete_RESERVED(0x001A..0x001C), 5552 x25519(0x001D), x448(0x001E), 5554 /* Finite Field Groups (DHE) */ 5555 ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), 5556 ffdhe6144(0x0103), ffdhe8192(0x0104), 5558 /* Reserved Code Points */ 5559 ffdhe_private_use(0x01FC..0x01FF), 5560 ecdhe_private_use(0xFE00..0xFEFF), 5561 obsolete_RESERVED(0xFF01..0xFF02), 5562 (0xFFFF) 5563 } NamedGroup; 5565 struct { 5566 NamedGroup named_group_list<2..2^16-1>; 5567 } NamedGroupList; 5569 Values within "obsolete_RESERVED" ranges are used in previous 5570 versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 5571 implementations. The obsolete curves have various known/theoretical 5572 weaknesses or have had very little usage, in some cases only due to 5573 unintentional server configuration issues. They are no longer 5574 considered appropriate for general use and should be assumed to be 5575 potentially unsafe. The set of curves specified here is sufficient 5576 for interoperability with all currently deployed and properly 5577 configured TLS implementations. 5579 B.3.2. Server Parameters Messages 5580 opaque DistinguishedName<1..2^16-1>; 5582 struct { 5583 DistinguishedName authorities<3..2^16-1>; 5584 } CertificateAuthoritiesExtension; 5586 struct { 5587 opaque certificate_extension_oid<1..2^8-1>; 5588 opaque certificate_extension_values<0..2^16-1>; 5589 } OIDFilter; 5591 struct { 5592 OIDFilter filters<0..2^16-1>; 5593 } OIDFilterExtension; 5595 struct {} PostHandshakeAuth; 5597 struct { 5598 Extension extensions<0..2^16-1>; 5599 } EncryptedExtensions; 5601 struct { 5602 opaque certificate_request_context<0..2^8-1>; 5603 Extension extensions<0..2^16-1>; 5604 } CertificateRequest; 5606 B.3.3. Authentication Messages 5607 enum { 5608 X509(0), 5609 OpenPGP_RESERVED(1), 5610 RawPublicKey(2), 5611 (255) 5612 } CertificateType; 5614 struct { 5615 select (certificate_type) { 5616 case RawPublicKey: 5617 /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ 5618 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 5620 case X509: 5621 opaque cert_data<1..2^24-1>; 5622 }; 5623 Extension extensions<0..2^16-1>; 5624 } CertificateEntry; 5626 struct { 5627 opaque certificate_request_context<0..2^8-1>; 5628 CertificateEntry certificate_list<0..2^24-1>; 5629 } Certificate; 5631 struct { 5632 SignatureScheme algorithm; 5633 opaque signature<0..2^16-1>; 5634 } CertificateVerify; 5636 struct { 5637 opaque verify_data[Hash.length]; 5638 } Finished; 5640 B.3.4. Ticket Establishment 5642 struct { 5643 uint32 ticket_lifetime; 5644 uint32 ticket_age_add; 5645 opaque ticket_nonce<0..255>; 5646 opaque ticket<1..2^16-1>; 5647 Extension extensions<0..2^16-1>; 5648 } NewSessionTicket; 5650 B.3.5. Updating Keys 5651 struct {} EndOfEarlyData; 5653 enum { 5654 update_not_requested(0), update_requested(1), (255) 5655 } KeyUpdateRequest; 5657 struct { 5658 KeyUpdateRequest request_update; 5659 } KeyUpdate; 5661 B.4. Cipher Suites 5663 A cipher suite defines the pair of the AEAD algorithm and hash 5664 algorithm to be used with HKDF. Cipher suite names follow the naming 5665 convention: 5667 CipherSuite TLS_AEAD_HASH = VALUE; 5669 +===========+================================================+ 5670 | Component | Contents | 5671 +===========+================================================+ 5672 | TLS | The string "TLS" | 5673 +-----------+------------------------------------------------+ 5674 | AEAD | The AEAD algorithm used for record protection | 5675 +-----------+------------------------------------------------+ 5676 | HASH | The hash algorithm used with HKDF | 5677 +-----------+------------------------------------------------+ 5678 | VALUE | The two byte ID assigned for this cipher suite | 5679 +-----------+------------------------------------------------+ 5681 Table 4: Cipher Suite Name Structure 5683 This specification defines the following cipher suites for use with 5684 TLS 1.3. 5686 +==============================+=============+ 5687 | Description | Value | 5688 +==============================+=============+ 5689 | TLS_AES_128_GCM_SHA256 | {0x13,0x01} | 5690 +------------------------------+-------------+ 5691 | TLS_AES_256_GCM_SHA384 | {0x13,0x02} | 5692 +------------------------------+-------------+ 5693 | TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} | 5694 +------------------------------+-------------+ 5695 | TLS_AES_128_CCM_SHA256 | {0x13,0x04} | 5696 +------------------------------+-------------+ 5697 | TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} | 5698 +------------------------------+-------------+ 5700 Table 5: Cipher Suite List 5702 The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, 5703 and AEAD_AES_128_CCM are defined in [RFC5116]. 5704 AEAD_CHACHA20_POLY1305 is defined in [RFC8439]. AEAD_AES_128_CCM_8 5705 is defined in [RFC6655]. The corresponding hash algorithms are 5706 defined in [SHS]. 5708 Although TLS 1.3 uses the same cipher suite space as previous 5709 versions of TLS, TLS 1.3 cipher suites are defined differently, only 5710 specifying the symmetric ciphers, and cannot be used for TLS 1.2. 5711 Similarly, cipher suites for TLS 1.2 and lower cannot be used with 5712 TLS 1.3. 5714 New cipher suite values are assigned by IANA as described in 5715 Section 11. 5717 Appendix C. Implementation Notes 5719 The TLS protocol cannot prevent many common security mistakes. This 5720 appendix provides several recommendations to assist implementors. 5721 [RFC8448] provides test vectors for TLS 1.3 handshakes. 5723 C.1. Random Number Generation and Seeding 5725 TLS requires a cryptographically secure pseudorandom number generator 5726 (CSPRNG). In most cases, the operating system provides an 5727 appropriate facility such as /dev/urandom, which should be used 5728 absent other (e.g., performance) concerns. It is RECOMMENDED to use 5729 an existing CSPRNG implementation in preference to crafting a new 5730 one. Many adequate cryptographic libraries are already available 5731 under favorable license terms. Should those prove unsatisfactory, 5732 [RFC4086] provides guidance on the generation of random values. 5734 TLS uses random values (1) in public protocol fields such as the 5735 public Random values in the ClientHello and ServerHello and (2) to 5736 generate keying material. With a properly functioning CSPRNG, this 5737 does not present a security problem, as it is not feasible to 5738 determine the CSPRNG state from its output. However, with a broken 5739 CSPRNG, it may be possible for an attacker to use the public output 5740 to determine the CSPRNG internal state and thereby predict the keying 5741 material, as documented in [CHECKOWAY] and [DSA-1571-1]. 5743 Implementations can provide extra security against this form of 5744 attack by using separate CSPRNGs to generate public and private 5745 values. 5747 [RFC8937] describes a way way for security protocol implementations 5748 to augment their (pseudo)random number generators using a long-term 5749 private key and a deterministic signature function. This improves 5750 randomness from broken or otherwise subverted random number 5751 generators. 5753 C.2. Certificates and Authentication 5755 Implementations are responsible for verifying the integrity of 5756 certificates and should generally support certificate revocation 5757 messages. Absent a specific indication from an application profile, 5758 certificates should always be verified to ensure proper signing by a 5759 trusted certificate authority (CA). The selection and addition of 5760 trust anchors should be done very carefully. Users should be able to 5761 view information about the certificate and trust anchor. 5762 Applications SHOULD also enforce minimum and maximum key sizes. For 5763 example, certification paths containing keys or signatures weaker 5764 than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure 5765 applications. 5767 C.3. Implementation Pitfalls 5769 Implementation experience has shown that certain parts of earlier TLS 5770 specifications are not easy to understand and have been a source of 5771 interoperability and security problems. Many of these areas have 5772 been clarified in this document but this appendix contains a short 5773 list of the most important things that require special attention from 5774 implementors. 5776 TLS protocol issues: 5778 * Do you correctly handle handshake messages that are fragmented to 5779 multiple TLS records (see Section 5.1)? Do you correctly handle 5780 corner cases like a ClientHello that is split into several small 5781 fragments? Do you fragment handshake messages that exceed the 5782 maximum fragment size? In particular, the Certificate and 5783 CertificateRequest handshake messages can be large enough to 5784 require fragmentation. Certificate compression as defined in 5785 [RFC8879] can be used to reduce the risk of fragmentation. 5787 * Do you ignore the TLS record layer version number in all 5788 unencrypted TLS records (see Appendix E)? 5790 * Have you ensured that all support for SSL, RC4, EXPORT ciphers, 5791 and MD5 (via the "signature_algorithms" extension) is completely 5792 removed from all possible configurations that support TLS 1.3 or 5793 later, and that attempts to use these obsolete capabilities fail 5794 correctly? (see Appendix E)? 5796 * Do you handle TLS extensions in ClientHellos correctly, including 5797 unknown extensions? 5799 * When the server has requested a client certificate but no suitable 5800 certificate is available, do you correctly send an empty 5801 Certificate message, instead of omitting the whole message (see 5802 Section 4.4.2)? 5804 * When processing the plaintext fragment produced by AEAD-Decrypt 5805 and scanning from the end for the ContentType, do you avoid 5806 scanning past the start of the cleartext in the event that the 5807 peer has sent a malformed plaintext of all zeros? 5809 * Do you properly ignore unrecognized cipher suites (Section 4.1.2), 5810 hello extensions (Section 4.2), named groups (Section 4.2.7), key 5811 shares (Section 4.2.8), supported versions (Section 4.2.1), and 5812 signature algorithms (Section 4.2.3) in the ClientHello? 5814 * As a server, do you send a HelloRetryRequest to clients which 5815 support a compatible (EC)DHE group but do not predict it in the 5816 "key_share" extension? As a client, do you correctly handle a 5817 HelloRetryRequest from the server? 5819 Cryptographic details: 5821 * What countermeasures do you use to prevent timing attacks 5822 [TIMING]? 5824 * When using Diffie-Hellman key exchange, do you correctly preserve 5825 leading zero bytes in the negotiated key (see Section 7.4.1)? 5827 * Does your TLS client check that the Diffie-Hellman parameters sent 5828 by the server are acceptable (see Section 4.2.8.1)? 5830 * Do you use a strong and, most importantly, properly seeded random 5831 number generator (see Appendix C.1) when generating Diffie-Hellman 5832 private values, the ECDSA "k" parameter, and other security- 5833 critical values? It is RECOMMENDED that implementations implement 5834 "deterministic ECDSA" as specified in [RFC6979]. Note that purely 5835 deterministic ECC signatures such as deterministic ECDSA and EdDSA 5836 may be vulnerable to certain side-channel and fault injection 5837 attacks in easily accessible IoT devices. 5839 * Do you zero-pad Diffie-Hellman public key values and shared 5840 secrets to the group size (see Section 4.2.8.1 and Section 7.4.1)? 5842 * Do you verify signatures after making them, to protect against 5843 RSA-CRT key leaks [FW15]? 5845 C.4. Client Tracking Prevention 5847 Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of 5848 a ticket allows passive observers to correlate different connections. 5849 Servers that issue tickets SHOULD offer at least as many tickets as 5850 the number of connections that a client might use; for example, a web 5851 browser using HTTP/1.1 [RFC7230] might open six connections to a 5852 server. Servers SHOULD issue new tickets with every connection. 5853 This ensures that clients are always able to use a new ticket when 5854 creating a new connection. 5856 Offering a ticket to a server additionally allows the server to 5857 correlate different connections. This is possible independent of 5858 ticket reuse. Client applications SHOULD NOT offer tickets across 5859 connections that are meant to be uncorrelated. For example, [FETCH] 5860 defines network partition keys to separate cache lookups in web 5861 browsers. 5863 C.5. Unauthenticated Operation 5865 Previous versions of TLS offered explicitly unauthenticated cipher 5866 suites based on anonymous Diffie-Hellman. These modes have been 5867 deprecated in TLS 1.3. However, it is still possible to negotiate 5868 parameters that do not provide verifiable server authentication by 5869 several methods, including: 5871 * Raw public keys [RFC7250]. 5873 * Using a public key contained in a certificate but without 5874 validation of the certificate chain or any of its contents. 5876 Either technique used alone is vulnerable to man-in-the-middle 5877 attacks and therefore unsafe for general use. However, it is also 5878 possible to bind such connections to an external authentication 5879 mechanism via out-of-band validation of the server's public key, 5880 trust on first use, or a mechanism such as channel bindings (though 5881 the channel bindings described in [RFC5929] are not defined for TLS 5882 1.3). If no such mechanism is used, then the connection has no 5883 protection against active man-in-the-middle attack; applications MUST 5884 NOT use TLS in such a way absent explicit configuration or a specific 5885 application profile. 5887 Appendix D. Updates to TLS 1.2 5889 To align with the names used this document, the following terms from 5890 [RFC5246] are renamed: 5892 * The master secret, computed in Section 8.1 of [RFC5246], is 5893 renamed to the main secret. It is referred to as main_secret in 5894 formulas and structures, instead of master_secret. However, the 5895 label parameter to the PRF function is left unchanged for 5896 compatibility. 5898 * The premaster secret is renamed to the preliminary secret. It is 5899 referred to as preliminary_secret in formulas and structures, 5900 instead of pre_master_secret. 5902 * The PreMasterSecret and EncryptedPreMasterSecret structures, 5903 defined in Section 7.4.7.1 of [RFC5246], are renamed to 5904 PreliminarySecret and EncryptedPreliminarySecret, respectively. 5906 Correspondingly, the extension defined in [RFC7627] is renamed to the 5907 "Extended Main Secret" extension. The extension code point is 5908 renamed to "extended_main_secret". The label parameter to the PRF 5909 function in Section 4 of [RFC7627] is left unchanged for 5910 compatibility. 5912 Appendix E. Backward Compatibility 5914 The TLS protocol provides a built-in mechanism for version 5915 negotiation between endpoints potentially supporting different 5916 versions of TLS. 5918 TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can 5919 also handle clients trying to use future versions of TLS as long as 5920 the ClientHello format remains compatible and there is at least one 5921 protocol version supported by both the client and the server. 5923 Prior versions of TLS used the record layer version number 5924 (TLSPlaintext.legacy_record_version and 5925 TLSCiphertext.legacy_record_version) for various purposes. As of TLS 5926 1.3, this field is deprecated. The value of 5927 TLSPlaintext.legacy_record_version MUST be ignored by all 5928 implementations. The value of TLSCiphertext.legacy_record_version is 5929 included in the additional data for deprotection but MAY otherwise be 5930 ignored or MAY be validated to match the fixed constant value. 5931 Version negotiation is performed using only the handshake versions 5932 (ClientHello.legacy_version and ServerHello.legacy_version, as well 5933 as the ClientHello, HelloRetryRequest, and ServerHello 5934 "supported_versions" extensions). In order to maximize 5935 interoperability with older endpoints, implementations that negotiate 5936 the use of TLS 1.0-1.2 SHOULD set the record layer version number to 5937 the negotiated version for the ServerHello and all records 5938 thereafter. 5940 For maximum compatibility with previously non-standard behavior and 5941 misconfigured deployments, all implementations SHOULD support 5942 validation of certification paths based on the expectations in this 5943 document, even when handling prior TLS versions' handshakes (see 5944 Section 4.4.2.2). 5946 TLS 1.2 and prior supported an "Extended Main Secret" [RFC7627] 5947 extension which digested large parts of the handshake transcript into 5948 the secret and derived keys. Note this extension was renamed in 5949 Appendix D. Because TLS 1.3 always hashes in the transcript up to 5950 the server Finished, implementations which support both TLS 1.3 and 5951 earlier versions SHOULD indicate the use of the Extended Main Secret 5952 extension in their APIs whenever TLS 1.3 is used. 5954 E.1. Negotiating with an Older Server 5956 A TLS 1.3 client who wishes to negotiate with servers that do not 5957 support TLS 1.3 will send a normal TLS 1.3 ClientHello containing 5958 0x0303 (TLS 1.2) in ClientHello.legacy_version but with the correct 5959 version(s) in the "supported_versions" extension. If the server does 5960 not support TLS 1.3, it will respond with a ServerHello containing an 5961 older version number. If the client agrees to use this version, the 5962 negotiation will proceed as appropriate for the negotiated protocol. 5963 A client using a ticket for resumption SHOULD initiate the connection 5964 using the version that was previously negotiated. 5966 Note that 0-RTT data is not compatible with older servers and SHOULD 5967 NOT be sent absent knowledge that the server supports TLS 1.3. See 5968 Appendix E.3. 5970 If the version chosen by the server is not supported by the client 5971 (or is not acceptable), the client MUST abort the handshake with a 5972 "protocol_version" alert. 5974 Some legacy server implementations are known to not implement the TLS 5975 specification properly and might abort connections upon encountering 5976 TLS extensions or versions which they are not aware of. 5977 Interoperability with buggy servers is a complex topic beyond the 5978 scope of this document. Multiple connection attempts may be required 5979 in order to negotiate a backward-compatible connection; however, this 5980 practice is vulnerable to downgrade attacks and is NOT RECOMMENDED. 5982 E.2. Negotiating with an Older Client 5984 A TLS server can also receive a ClientHello indicating a version 5985 number smaller than its highest supported version. If the 5986 "supported_versions" extension is present, the server MUST negotiate 5987 using that extension as described in Section 4.2.1. If the 5988 "supported_versions" extension is not present, the server MUST 5989 negotiate the minimum of ClientHello.legacy_version and TLS 1.2. For 5990 example, if the server supports TLS 1.0, 1.1, and 1.2, and 5991 legacy_version is TLS 1.0, the server will proceed with a TLS 1.0 5992 ServerHello. If the "supported_versions" extension is absent and the 5993 server only supports versions greater than 5994 ClientHello.legacy_version, the server MUST abort the handshake with 5995 a "protocol_version" alert. 5997 Note that earlier versions of TLS did not clearly specify the record 5998 layer version number value in all cases 5999 (TLSPlaintext.legacy_record_version). Servers will receive various 6000 TLS 1.x versions in this field, but its value MUST always be ignored. 6002 E.3. 0-RTT Backward Compatibility 6004 0-RTT data is not compatible with older servers. An older server 6005 will respond to the ClientHello with an older ServerHello, but it 6006 will not correctly skip the 0-RTT data and will fail to complete the 6007 handshake. This can cause issues when a client attempts to use 6008 0-RTT, particularly against multi-server deployments. For example, a 6009 deployment could deploy TLS 1.3 gradually with some servers 6010 implementing TLS 1.3 and some implementing TLS 1.2, or a TLS 1.3 6011 deployment could be downgraded to TLS 1.2. 6013 A client that attempts to send 0-RTT data MUST fail a connection if 6014 it receives a ServerHello with TLS 1.2 or older. It can then retry 6015 the connection with 0-RTT disabled. To avoid a downgrade attack, the 6016 client SHOULD NOT disable TLS 1.3, only 0-RTT. 6018 To avoid this error condition, multi-server deployments SHOULD ensure 6019 a uniform and stable deployment of TLS 1.3 without 0-RTT prior to 6020 enabling 0-RTT. 6022 E.4. Middlebox Compatibility Mode 6024 Field measurements [Ben17a] [Ben17b] [Res17a] [Res17b] have found 6025 that a significant number of middleboxes misbehave when a TLS client/ 6026 server pair negotiates TLS 1.3. Implementations can increase the 6027 chance of making connections through those middleboxes by making the 6028 TLS 1.3 handshake look more like a TLS 1.2 handshake: 6030 * The client always provides a non-empty session ID in the 6031 ClientHello, as described in the legacy_session_id section of 6032 Section 4.1.2. 6034 * If not offering early data, the client sends a dummy 6035 change_cipher_spec record (see the third paragraph of Section 5) 6036 immediately before its second flight. This may either be before 6037 its second ClientHello or before its encrypted handshake flight. 6038 If offering early data, the record is placed immediately after the 6039 first ClientHello. 6041 * The server sends a dummy change_cipher_spec record immediately 6042 after its first handshake message. This may either be after a 6043 ServerHello or a HelloRetryRequest. 6045 When put together, these changes make the TLS 1.3 handshake resemble 6046 TLS 1.2 session resumption, which improves the chance of successfully 6047 connecting through middleboxes. This "compatibility mode" is 6048 partially negotiated: the client can opt to provide a session ID or 6049 not, and the server has to echo it. Either side can send 6050 change_cipher_spec at any time during the handshake, as they must be 6051 ignored by the peer, but if the client sends a non-empty session ID, 6052 the server MUST send the change_cipher_spec as described in this 6053 appendix. 6055 E.5. Security Restrictions Related to Backward Compatibility 6057 Implementations negotiating the use of older versions of TLS SHOULD 6058 prefer forward secret and AEAD cipher suites, when available. 6060 The security of RC4 cipher suites is considered insufficient for the 6061 reasons cited in [RFC7465]. Implementations MUST NOT offer or 6062 negotiate RC4 cipher suites for any version of TLS for any reason. 6064 Old versions of TLS permitted the use of very low strength ciphers. 6065 Ciphers with a strength less than 112 bits MUST NOT be offered or 6066 negotiated for any version of TLS for any reason. 6068 The security of SSL 2.0 [SSL2], SSL 3.0 [RFC6101], TLS 1.0 [RFC2246], 6069 and TLS 1.1 [RFC4346] are considered insufficient for the reasons 6070 enumerated in [RFC6176], [RFC7568], and [RFC8996] and they MUST NOT 6071 be negotiated for any reason. 6073 Implementations MUST NOT send an SSL version 2.0 compatible CLIENT- 6074 HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an 6075 SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT 6076 RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in 6077 order to negotiate older versions of TLS. 6079 Implementations MUST NOT send a ClientHello.legacy_version or 6080 ServerHello.legacy_version set to 0x0300 or less. Any endpoint 6081 receiving a Hello message with ClientHello.legacy_version or 6082 ServerHello.legacy_version set to 0x0300 MUST abort the handshake 6083 with a "protocol_version" alert. 6085 Implementations MUST NOT send any records with a version less than 6086 0x0300. Implementations SHOULD NOT accept any records with a version 6087 less than 0x0300 (but may inadvertently do so if the record version 6088 number is ignored completely). 6090 Implementations MUST NOT use the Truncated HMAC extension, defined in 6091 Section 7 of [RFC6066], as it is not applicable to AEAD algorithms 6092 and has been shown to be insecure in some scenarios. 6094 Appendix F. Overview of Security Properties 6096 A complete security analysis of TLS is outside the scope of this 6097 document. In this appendix, we provide an informal description of 6098 the desired properties as well as references to more detailed work in 6099 the research literature which provides more formal definitions. 6101 We cover properties of the handshake separately from those of the 6102 record layer. 6104 F.1. Handshake 6106 The TLS handshake is an Authenticated Key Exchange (AKE) protocol 6107 which is intended to provide both one-way authenticated (server-only) 6108 and mutually authenticated (client and server) functionality. At the 6109 completion of the handshake, each side outputs its view of the 6110 following values: 6112 * A set of "session keys" (the various secrets derived from the main 6113 secret) from which can be derived a set of working keys. 6115 * A set of cryptographic parameters (algorithms, etc.). 6117 * The identities of the communicating parties. 6119 We assume the attacker to be an active network attacker, which means 6120 it has complete control over the network used to communicate between 6121 the parties [RFC3552]. Even under these conditions, the handshake 6122 should provide the properties listed below. Note that these 6123 properties are not necessarily independent, but reflect the protocol 6124 consumers' needs. 6126 Establishing the same session keys: The handshake needs to output 6127 the same set of session keys on both sides of the handshake, 6128 provided that it completes successfully on each endpoint (see 6129 [CK01]; Definition 1, part 1). 6131 Secrecy of the session keys: The shared session keys should be known 6132 only to the communicating parties and not to the attacker (see 6133 [CK01]; Definition 1, part 2). Note that in a unilaterally 6134 authenticated connection, the attacker can establish its own 6135 session keys with the server, but those session keys are distinct 6136 from those established by the client. 6138 Peer Authentication: The client's view of the peer identity should 6139 reflect the server's identity. If the client is authenticated, 6140 the server's view of the peer identity should match the client's 6141 identity. 6143 Uniqueness of the session keys: Any two distinct handshakes should 6144 produce distinct, unrelated session keys. Individual session keys 6145 produced by a handshake should also be distinct and independent. 6147 Downgrade Protection: The cryptographic parameters should be the 6148 same on both sides and should be the same as if the peers had been 6149 communicating in the absence of an attack (see [BBFGKZ16]; 6150 Definitions 8 and 9). 6152 Forward secret with respect to long-term keys: If the long-term 6153 keying material (in this case the signature keys in certificate- 6154 based authentication modes or the external/resumption PSK in PSK 6155 with (EC)DHE modes) is compromised after the handshake is 6156 complete, this does not compromise the security of the session key 6157 (see [DOW92]), as long as the session key itself has been erased. 6158 The forward secrecy property is not satisfied when PSK is used in 6159 the "psk_ke" PskKeyExchangeMode. 6161 Key Compromise Impersonation (KCI) resistance: In a mutually 6162 authenticated connection with certificates, compromising the long- 6163 term secret of one actor should not break that actor's 6164 authentication of their peer in the given connection (see 6165 [HGFS15]). For example, if a client's signature key is 6166 compromised, it should not be possible to impersonate arbitrary 6167 servers to that client in subsequent handshakes. 6169 Protection of endpoint identities: The server's identity 6170 (certificate) should be protected against passive attackers. The 6171 client's identity (certificate) should be protected against both 6172 passive and active attackers. This property does not hold for 6173 cipher suites without confidentiality; while this specification 6174 does not define any such cipher suites, other documents may do so. 6176 Informally, the signature-based modes of TLS 1.3 provide for the 6177 establishment of a unique, secret, shared key established by an 6178 (EC)DHE key exchange and authenticated by the server's signature over 6179 the handshake transcript, as well as tied to the server's identity by 6180 a MAC. If the client is authenticated by a certificate, it also 6181 signs over the handshake transcript and provides a MAC tied to both 6182 identities. [SIGMA] describes the design and analysis of this type 6183 of key exchange protocol. If fresh (EC)DHE keys are used for each 6184 connection, then the output keys are forward secret. 6186 The external PSK and resumption PSK bootstrap from a long-term shared 6187 secret into a unique per-connection set of short-term session keys. 6188 This secret may have been established in a previous handshake. If 6189 PSK with (EC)DHE key establishment is used, these session keys will 6190 also be forward secret. The resumption PSK has been designed so that 6191 the resumption secret computed by connection N and needed to form 6192 connection N+1 is separate from the traffic keys used by connection 6193 N, thus providing forward secrecy between the connections. In 6194 addition, if multiple tickets are established on the same connection, 6195 they are associated with different keys, so compromise of the PSK 6196 associated with one ticket does not lead to the compromise of 6197 connections established with PSKs associated with other tickets. 6198 This property is most interesting if tickets are stored in a database 6199 (and so can be deleted) rather than if they are self-encrypted. 6201 Forward secrecy limits the effect of key leakage in one direction 6202 (compromise of a key at time T2 does not compromise some key at time 6203 T1 where T1 < T2). Protection in the other direction (compromise at 6204 time T1 does not compromise keys at time T2) can be achieved by 6205 rerunning EC(DHE). If a long-term authentication key has been 6206 compromised, a full handshake with EC(DHE) gives protection against 6207 passive attackers. If the resumption_master_secret has been 6208 compromised, a resumption handshake with EC(DHE) gives protection 6209 against passive attackers and a full handshake with EC(DHE) gives 6210 protection against active attackers. If a traffic secret has been 6211 compromised, any handshake with EC(DHE) gives protection against 6212 active attackers. Using the terms in [RFC7624], forward secrecy 6213 without rerunning EC(DHE) does not stop an attacker from doing static 6214 key exfiltration. After key exfiltration of 6215 application_traffic_secret_N, an attacker can e.g., passively 6216 eavesdrop on all future data sent on the connection including data 6217 encrypted with application_traffic_secret_N+1, 6218 application_traffic_secret_N+2, etc. Frequently rerunning EC(DHE) 6219 forces an attacker to do dynamic key exfiltration (or content 6220 exfiltration). 6222 The PSK binder value forms a binding between a PSK and the current 6223 handshake, as well as between the session where the PSK was 6224 established and the current session. This binding transitively 6225 includes the original handshake transcript, because that transcript 6226 is digested into the values which produce the resumption secret. 6227 This requires that both the KDF used to produce the resumption secret 6228 and the MAC used to compute the binder be collision resistant. See 6229 Appendix F.1.1 for more on this. Note: The binder does not cover the 6230 binder values from other PSKs, though they are included in the 6231 Finished MAC. 6233 Note: TLS does not currently permit the server to send a 6234 certificate_request message in non-certificate-based handshakes 6235 (e.g., PSK). If this restriction were to be relaxed in future, the 6236 client's signature would not cover the server's certificate directly. 6237 However, if the PSK was established through a NewSessionTicket, the 6238 client's signature would transitively cover the server's certificate 6239 through the PSK binder. [PSK-FINISHED] describes a concrete attack 6240 on constructions that do not bind to the server's certificate (see 6241 also [Kraw16]). It is unsafe to use certificate-based client 6242 authentication when the client might potentially share the same PSK/ 6243 key-id pair with two different endpoints. Implementations MUST NOT 6244 combine external PSKs with certificate-based authentication of either 6245 the client or server. Future specifications MAY provide an extension 6246 to permit this. 6248 If an exporter is used, then it produces values which are unique and 6249 secret (because they are generated from a unique session key). 6250 Exporters computed with different labels and contexts are 6251 computationally independent, so it is not feasible to compute one 6252 from another or the session secret from the exported value. Note: 6253 Exporters can produce arbitrary-length values; if exporters are to be 6254 used as channel bindings, the exported value MUST be large enough to 6255 provide collision resistance. The exporters provided in TLS 1.3 are 6256 derived from the same Handshake Contexts as the early traffic keys 6257 and the application traffic keys, respectively, and thus have similar 6258 security properties. Note that they do not include the client's 6259 certificate; future applications which wish to bind to the client's 6260 certificate may need to define a new exporter that includes the full 6261 handshake transcript. 6263 For all handshake modes, the Finished MAC (and, where present, the 6264 signature) prevents downgrade attacks. In addition, the use of 6265 certain bytes in the random nonces as described in Section 4.1.3 6266 allows the detection of downgrade to previous TLS versions. See 6267 [BBFGKZ16] for more details on TLS 1.3 and downgrade. 6269 As soon as the client and the server have exchanged enough 6270 information to establish shared keys, the remainder of the handshake 6271 is encrypted, thus providing protection against passive attackers, 6272 even if the computed shared key is not authenticated. Because the 6273 server authenticates before the client, the client can ensure that if 6274 it authenticates to the server, it only reveals its identity to an 6275 authenticated server. Note that implementations must use the 6276 provided record-padding mechanism during the handshake to avoid 6277 leaking information about the identities due to length. The client's 6278 proposed PSK identities are not encrypted, nor is the one that the 6279 server selects. 6281 F.1.1. Key Derivation and HKDF 6283 Key derivation in TLS 1.3 uses HKDF as defined in [RFC5869] and its 6284 two components, HKDF-Extract and HKDF-Expand. The full rationale for 6285 the HKDF construction can be found in [Kraw10] and the rationale for 6286 the way it is used in TLS 1.3 in [KW16]. Throughout this document, 6287 each application of HKDF-Extract is followed by one or more 6288 invocations of HKDF-Expand. This ordering should always be followed 6289 (including in future revisions of this document); in particular, one 6290 SHOULD NOT use an output of HKDF-Extract as an input to another 6291 application of HKDF-Extract without an HKDF-Expand in between. 6292 Multiple applications of HKDF-Expand to some of the same inputs are 6293 allowed as long as these are differentiated via the key and/or the 6294 labels. 6296 Note that HKDF-Expand implements a pseudorandom function (PRF) with 6297 both inputs and outputs of variable length. In some of the uses of 6298 HKDF in this document (e.g., for generating exporters and the 6299 resumption_secret), it is necessary that the application of HKDF- 6300 Expand be collision resistant; namely, it should be infeasible to 6301 find two different inputs to HKDF-Expand that output the same value. 6302 This requires the underlying hash function to be collision resistant 6303 and the output length from HKDF-Expand to be of size at least 256 6304 bits (or as much as needed for the hash function to prevent finding 6305 collisions). 6307 F.1.2. Certificate-Based Client Authentication 6309 A client that has sent certificate-based authentication data to a 6310 server, either during the handshake or in post-handshake 6311 authentication, cannot be sure whether the server afterwards 6312 considers the client to be authenticated or not. If the client needs 6313 to determine if the server considers the connection to be 6314 unilaterally or mutually authenticated, this has to be provisioned by 6315 the application layer. See [CHHSV17] for details. In addition, the 6316 analysis of post-handshake authentication from [Kraw16] shows that 6317 the client identified by the certificate sent in the post-handshake 6318 phase possesses the traffic key. This party is therefore the client 6319 that participated in the original handshake or one to whom the 6320 original client delegated the traffic key (assuming that the traffic 6321 key has not been compromised). 6323 F.1.3. 0-RTT 6325 The 0-RTT mode of operation generally provides security properties 6326 similar to those of 1-RTT data, with the two exceptions that the 6327 0-RTT encryption keys do not provide full forward secrecy and that 6328 the server is not able to guarantee uniqueness of the handshake (non- 6329 replayability) without keeping potentially undue amounts of state. 6330 See Section 8 for mechanisms to limit the exposure to replay. 6332 F.1.4. Exporter Independence 6334 The exporter_secret and early_exporter_secret are derived to be 6335 independent of the traffic keys and therefore do not represent a 6336 threat to the security of traffic encrypted with those keys. 6337 However, because these secrets can be used to compute any exporter 6338 value, they SHOULD be erased as soon as possible. If the total set 6339 of exporter labels is known, then implementations SHOULD pre-compute 6340 the inner Derive-Secret stage of the exporter computation for all 6341 those labels, then erase the [early_]exporter_secret, followed by 6342 each inner values as soon as it is known that it will not be needed 6343 again. 6345 F.1.5. Post-Compromise Security 6347 TLS does not provide security for handshakes which take place after 6348 the peer's long-term secret (signature key or external PSK) is 6349 compromised. It therefore does not provide post-compromise security 6350 [CCG16], sometimes also referred to as backwards or future secrecy. 6351 This is in contrast to KCI resistance, which describes the security 6352 guarantees that a party has after its own long-term secret has been 6353 compromised. 6355 F.1.6. External References 6357 The reader should refer to the following references for analysis of 6358 the TLS handshake: [DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16], 6359 [FGSW16], [LXZFH16], [FG17], and [BBK17]. 6361 F.2. Record Layer 6363 The record layer depends on the handshake producing strong traffic 6364 secrets which can be used to derive bidirectional encryption keys and 6365 nonces. Assuming that is true, and the keys are used for no more 6366 data than indicated in Section 5.5, then the record layer should 6367 provide the following guarantees: 6369 Confidentiality: An attacker should not be able to determine the 6370 plaintext contents of a given record. 6372 Integrity: An attacker should not be able to craft a new record 6373 which is different from an existing record which will be accepted 6374 by the receiver. 6376 Order protection/non-replayability: An attacker should not be able 6377 to cause the receiver to accept a record which it has already 6378 accepted or cause the receiver to accept record N+1 without having 6379 first processed record N. 6381 Length concealment: Given a record with a given external length, the 6382 attacker should not be able to determine the amount of the record 6383 that is content versus padding. 6385 Forward secrecy after key change: If the traffic key update 6386 mechanism described in Section 4.6.3 has been used and the 6387 previous generation key is deleted, an attacker who compromises 6388 the endpoint should not be able to decrypt traffic encrypted with 6389 the old key. 6391 Informally, TLS 1.3 provides these properties by AEAD-protecting the 6392 plaintext with a strong key. AEAD encryption [RFC5116] provides 6393 confidentiality and integrity for the data. Non-replayability is 6394 provided by using a separate nonce for each record, with the nonce 6395 being derived from the record sequence number (Section 5.3), with the 6396 sequence number being maintained independently at both sides; thus 6397 records which are delivered out of order result in AEAD deprotection 6398 failures. In order to prevent mass cryptanalysis when the same 6399 plaintext is repeatedly encrypted by different users under the same 6400 key (as is commonly the case for HTTP), the nonce is formed by mixing 6401 the sequence number with a secret per-connection initialization 6402 vector derived along with the traffic keys. See [BT16] for analysis 6403 of this construction. 6405 The rekeying technique in TLS 1.3 (see Section 7.2) follows the 6406 construction of the serial generator as discussed in [REKEY], which 6407 shows that rekeying can allow keys to be used for a larger number of 6408 encryptions than without rekeying. This relies on the security of 6409 the HKDF-Expand-Label function as a pseudorandom function (PRF). In 6410 addition, as long as this function is truly one way, it is not 6411 possible to compute traffic keys from prior to a key change (forward 6412 secrecy). 6414 TLS does not provide security for data which is communicated on a 6415 connection after a traffic secret of that connection is compromised. 6416 That is, TLS does not provide post-compromise security/future 6417 secrecy/backward secrecy with respect to the traffic secret. Indeed, 6418 an attacker who learns a traffic secret can compute all future 6419 traffic secrets on that connection. Systems which want such 6420 guarantees need to do a fresh handshake and establish a new 6421 connection with an (EC)DHE exchange. 6423 F.2.1. External References 6425 The reader should refer to the following references for analysis of 6426 the TLS record layer: [BMMRT15], [BT16], [BDFKPPRSZZ16], [BBK17], and 6427 [PS18]. 6429 F.3. Traffic Analysis 6431 TLS is susceptible to a variety of traffic analysis attacks based on 6432 observing the length and timing of encrypted packets [CLINIC] 6433 [HCJC16]. This is particularly easy when there is a small set of 6434 possible messages to be distinguished, such as for a video server 6435 hosting a fixed corpus of content, but still provides usable 6436 information even in more complicated scenarios. 6438 TLS does not provide any specific defenses against this form of 6439 attack but does include a padding mechanism for use by applications: 6440 The plaintext protected by the AEAD function consists of content plus 6441 variable-length padding, which allows the application to produce 6442 arbitrary-length encrypted records as well as padding-only cover 6443 traffic to conceal the difference between periods of transmission and 6444 periods of silence. Because the padding is encrypted alongside the 6445 actual content, an attacker cannot directly determine the length of 6446 the padding, but may be able to measure it indirectly by the use of 6447 timing channels exposed during record processing (i.e., seeing how 6448 long it takes to process a record or trickling in records to see 6449 which ones elicit a response from the server). In general, it is not 6450 known how to remove all of these channels because even a constant- 6451 time padding removal function will likely feed the content into data- 6452 dependent functions. At minimum, a fully constant-time server or 6453 client would require close cooperation with the application-layer 6454 protocol implementation, including making that higher-level protocol 6455 constant time. 6457 Note: Robust traffic analysis defenses will likely lead to inferior 6458 performance due to delays in transmitting packets and increased 6459 traffic volume. 6461 F.4. Side Channel Attacks 6463 In general, TLS does not have specific defenses against side-channel 6464 attacks (i.e., those which attack the communications via secondary 6465 channels such as timing), leaving those to the implementation of the 6466 relevant cryptographic primitives. However, certain features of TLS 6467 are designed to make it easier to write side-channel resistant code: 6469 * Unlike previous versions of TLS which used a composite MAC-then- 6470 encrypt structure, TLS 1.3 only uses AEAD algorithms, allowing 6471 implementations to use self-contained constant-time 6472 implementations of those primitives. 6474 * TLS uses a uniform "bad_record_mac" alert for all decryption 6475 errors, which is intended to prevent an attacker from gaining 6476 piecewise insight into portions of the message. Additional 6477 resistance is provided by terminating the connection on such 6478 errors; a new connection will have different cryptographic 6479 material, preventing attacks against the cryptographic primitives 6480 that require multiple trials. 6482 Information leakage through side channels can occur at layers above 6483 TLS, in application protocols and the applications that use them. 6484 Resistance to side-channel attacks depends on applications and 6485 application protocols separately ensuring that confidential 6486 information is not inadvertently leaked. 6488 F.5. Replay Attacks on 0-RTT 6490 Replayable 0-RTT data presents a number of security threats to TLS- 6491 using applications, unless those applications are specifically 6492 engineered to be safe under replay (minimally, this means idempotent, 6493 but in many cases may also require other stronger conditions, such as 6494 constant-time response). Potential attacks include: 6496 * Duplication of actions which cause side effects (e.g., purchasing 6497 an item or transferring money) to be duplicated, thus harming the 6498 site or the user. 6500 * Attackers can store and replay 0-RTT messages in order to reorder 6501 them with respect to other messages (e.g., moving a delete to 6502 after a create). 6504 * Exploiting cache timing behavior to discover the content of 0-RTT 6505 messages by replaying a 0-RTT message to a different cache node 6506 and then using a separate connection to measure request latency, 6507 to see if the two requests address the same resource. 6509 If data can be replayed a large number of times, additional attacks 6510 become possible, such as making repeated measurements of the speed of 6511 cryptographic operations. In addition, they may be able to overload 6512 rate-limiting systems. For a further description of these attacks, 6513 see [Mac17]. 6515 Ultimately, servers have the responsibility to protect themselves 6516 against attacks employing 0-RTT data replication. The mechanisms 6517 described in Section 8 are intended to prevent replay at the TLS 6518 layer but do not provide complete protection against receiving 6519 multiple copies of client data. TLS 1.3 falls back to the 1-RTT 6520 handshake when the server does not have any information about the 6521 client, e.g., because it is in a different cluster which does not 6522 share state or because the ticket has been deleted as described in 6523 Section 8.1. If the application-layer protocol retransmits data in 6524 this setting, then it is possible for an attacker to induce message 6525 duplication by sending the ClientHello to both the original cluster 6526 (which processes the data immediately) and another cluster which will 6527 fall back to 1-RTT and process the data upon application-layer 6528 replay. The scale of this attack is limited by the client's 6529 willingness to retry transactions and therefore only allows a limited 6530 amount of duplication, with each copy appearing as a new connection 6531 at the server. 6533 If implemented correctly, the mechanisms described in Section 8.1 and 6534 Section 8.2 prevent a replayed ClientHello and its associated 0-RTT 6535 data from being accepted multiple times by any cluster with 6536 consistent state; for servers which limit the use of 0-RTT to one 6537 cluster for a single ticket, then a given ClientHello and its 6538 associated 0-RTT data will only be accepted once. However, if state 6539 is not completely consistent, then an attacker might be able to have 6540 multiple copies of the data be accepted during the replication 6541 window. Because clients do not know the exact details of server 6542 behavior, they MUST NOT send messages in early data which are not 6543 safe to have replayed and which they would not be willing to retry 6544 across multiple 1-RTT connections. 6546 Application protocols MUST NOT use 0-RTT data without a profile that 6547 defines its use. That profile needs to identify which messages or 6548 interactions are safe to use with 0-RTT and how to handle the 6549 situation when the server rejects 0-RTT and falls back to 1-RTT. 6551 In addition, to avoid accidental misuse, TLS implementations MUST NOT 6552 enable 0-RTT (either sending or accepting) unless specifically 6553 requested by the application and MUST NOT automatically resend 0-RTT 6554 data if it is rejected by the server unless instructed by the 6555 application. Server-side applications may wish to implement special 6556 processing for 0-RTT data for some kinds of application traffic 6557 (e.g., abort the connection, request that data be resent at the 6558 application layer, or delay processing until the handshake 6559 completes). In order to allow applications to implement this kind of 6560 processing, TLS implementations MUST provide a way for the 6561 application to determine if the handshake has completed. 6563 F.5.1. Replay and Exporters 6565 Replays of the ClientHello produce the same early exporter, thus 6566 requiring additional care by applications which use these exporters. 6567 In particular, if these exporters are used as an authentication 6568 channel binding (e.g., by signing the output of the exporter) an 6569 attacker who compromises the PSK can transplant authenticators 6570 between connections without compromising the authentication key. 6572 In addition, the early exporter SHOULD NOT be used to generate 6573 server-to-client encryption keys because that would entail the reuse 6574 of those keys. This parallels the use of the early application 6575 traffic keys only in the client-to-server direction. 6577 F.6. PSK Identity Exposure 6579 Because implementations respond to an invalid PSK binder by aborting 6580 the handshake, it may be possible for an attacker to verify whether a 6581 given PSK identity is valid. Specifically, if a server accepts both 6582 external-PSK and certificate-based handshakes, a valid PSK identity 6583 will result in a failed handshake, whereas an invalid identity will 6584 just be skipped and result in a successful certificate handshake. 6585 Servers which solely support PSK handshakes may be able to resist 6586 this form of attack by treating the cases where there is no valid PSK 6587 identity and where there is an identity but it has an invalid binder 6588 identically. 6590 F.7. Sharing PSKs 6592 TLS 1.3 takes a conservative approach to PSKs by binding them to a 6593 specific KDF. By contrast, TLS 1.2 allows PSKs to be used with any 6594 hash function and the TLS 1.2 PRF. Thus, any PSK which is used with 6595 both TLS 1.2 and TLS 1.3 must be used with only one hash in TLS 1.3, 6596 which is less than optimal if users want to provision a single PSK. 6597 The constructions in TLS 1.2 and TLS 1.3 are different, although they 6598 are both based on HMAC. While there is no known way in which the 6599 same PSK might produce related output in both versions, only limited 6600 analysis has been done. Implementations can ensure safety from 6601 cross-protocol related output by not reusing PSKs between TLS 1.3 and 6602 TLS 1.2. 6604 F.8. Attacks on Static RSA 6606 Although TLS 1.3 does not use RSA key transport and so is not 6607 directly susceptible to Bleichenbacher-type attacks [Blei98]if TLS 6608 1.3 servers also support static RSA in the context of previous 6609 versions of TLS, then it may be possible to impersonate the server 6610 for TLS 1.3 connections [JSS15]. TLS 1.3 implementations can prevent 6611 this attack by disabling support for static RSA across all versions 6612 of TLS. In principle, implementations might also be able to separate 6613 certificates with different keyUsage bits for static RSA decryption 6614 and RSA signature, but this technique relies on clients refusing to 6615 accept signatures using keys in certificates that do not have the 6616 digitalSignature bit set, and many clients do not enforce this 6617 restriction. 6619 Appendix G. Changes Since -00 6621 [[RFC EDITOR: Please remove in final RFC.]] 6623 * Update TLS 1.2 terminology 6625 * Specify "certificate-based" client authentication 6627 * Clarify that privacy guarantees don't apply when you have null 6628 encryption 6630 * Shorten some names 6632 * Address tracking implications of resumption 6634 Contributors 6636 Martin Abadi 6637 University of California, Santa Cruz 6638 abadi@cs.ucsc.edu 6640 Christopher Allen 6641 (co-editor of TLS 1.0) 6642 Alacrity Ventures 6643 ChristopherA@AlacrityManagement.com 6645 Nimrod Aviram 6646 Tel Aviv University 6647 nimrod.aviram@gmail.com 6649 Richard Barnes 6650 Cisco 6651 rlb@ipv.sx 6652 Steven M. Bellovin 6653 Columbia University 6654 smb@cs.columbia.edu 6656 David Benjamin 6657 Google 6658 davidben@google.com 6660 Benjamin Beurdouche 6661 INRIA & Microsoft Research 6662 benjamin.beurdouche@ens.fr 6664 Karthikeyan Bhargavan 6665 (editor of [RFC7627]) 6666 INRIA 6667 karthikeyan.bhargavan@inria.fr 6669 Simon Blake-Wilson 6670 (co-author of [RFC4492]) 6671 BCI 6672 sblakewilson@bcisse.com 6674 Nelson Bolyard 6675 (co-author of [RFC4492]) 6676 Sun Microsystems, Inc. 6677 nelson@bolyard.com 6679 Ran Canetti 6680 IBM 6681 canetti@watson.ibm.com 6683 Matt Caswell 6684 OpenSSL 6685 matt@openssl.org 6687 Stephen Checkoway 6688 University of Illinois at Chicago 6689 sfc@uic.edu 6691 Pete Chown 6692 Skygate Technology Ltd 6693 pc@skygate.co.uk 6695 Katriel Cohn-Gordon 6696 University of Oxford 6697 me@katriel.co.uk 6699 Cas Cremers 6700 University of Oxford 6701 cas.cremers@cs.ox.ac.uk 6703 Antoine Delignat-Lavaud 6704 (co-author of [RFC7627]) 6705 INRIA 6706 antdl@microsoft.com 6708 Tim Dierks 6709 (co-author of TLS 1.0, co-editor of TLS 1.1 and 1.2) 6710 Independent 6711 tim@dierks.org 6713 Roelof DuToit 6714 Symantec Corporation 6715 roelof_dutoit@symantec.com 6717 Taher Elgamal 6718 Securify 6719 taher@securify.com 6721 Pasi Eronen 6722 Nokia 6723 pasi.eronen@nokia.com 6725 Cedric Fournet 6726 Microsoft 6727 fournet@microsoft.com 6729 Anil Gangolli 6730 anil@busybuddha.org 6732 David M. Garrett 6733 dave@nulldereference.com 6735 Illya Gerasymchuk 6736 Independent 6737 illya@iluxonchik.me 6739 Alessandro Ghedini 6740 Cloudflare Inc. 6741 alessandro@cloudflare.com 6743 Daniel Kahn Gillmor 6744 ACLU 6745 dkg@fifthhorseman.net 6747 Matthew Green 6748 Johns Hopkins University 6749 mgreen@cs.jhu.edu 6751 Jens Guballa 6752 ETAS 6753 jens.guballa@etas.com 6755 Felix Guenther 6756 TU Darmstadt 6757 mail@felixguenther.info 6759 Vipul Gupta 6760 (co-author of [RFC4492]) 6761 Sun Microsystems Laboratories 6762 vipul.gupta@sun.com 6764 Chris Hawk 6765 (co-author of [RFC4492]) 6766 Corriente Networks LLC 6767 chris@corriente.net 6769 Kipp Hickman 6771 Alfred Hoenes 6773 David Hopwood 6774 Independent Consultant 6775 david.hopwood@blueyonder.co.uk 6777 Marko Horvat 6778 MPI-SWS 6779 mhorvat@mpi-sws.org 6781 Jonathan Hoyland 6782 Royal Holloway, University of London 6783 jonathan.hoyland@gmail.com 6785 Subodh Iyengar 6786 Facebook 6787 subodh@fb.com 6789 Benjamin Kaduk 6790 Akamai Technologies 6791 kaduk@mit.edu 6793 Hubert Kario 6794 Red Hat Inc. 6795 hkario@redhat.com 6796 Phil Karlton 6797 (co-author of SSL 3.0) 6799 Leon Klingele 6800 Independent 6801 mail@leonklingele.de 6803 Paul Kocher 6804 (co-author of SSL 3.0) 6805 Cryptography Research 6806 paul@cryptography.com 6808 Hugo Krawczyk 6809 IBM 6810 hugokraw@us.ibm.com 6812 Adam Langley 6813 (co-author of [RFC7627]) 6814 Google 6815 agl@google.com 6817 Olivier Levillain 6818 ANSSI 6819 olivier.levillain@ssi.gouv.fr 6821 Xiaoyin Liu 6822 University of North Carolina at Chapel Hill 6823 xiaoyin.l@outlook.com 6825 Ilari Liusvaara 6826 Independent 6827 ilariliusvaara@welho.com 6829 Atul Luykx 6830 K.U. Leuven 6831 atul.luykx@kuleuven.be 6833 Colm MacCarthaigh 6834 Amazon Web Services 6835 colm@allcosts.net 6837 Carl Mehner 6838 USAA 6839 carl.mehner@usaa.com 6841 Jan Mikkelsen 6842 Transactionware 6843 janm@transactionware.com 6844 Bodo Moeller 6845 (co-author of [RFC4492]) 6846 Google 6847 bodo@acm.org 6849 Kyle Nekritz 6850 Facebook 6851 knekritz@fb.com 6853 Erik Nygren 6854 Akamai Technologies 6855 erik+ietf@nygren.org 6857 Magnus Nystrom 6858 Microsoft 6859 mnystrom@microsoft.com 6861 Kazuho Oku 6862 DeNA Co., Ltd. 6863 kazuhooku@gmail.com 6865 Kenny Paterson 6866 Royal Holloway, University of London 6867 kenny.paterson@rhul.ac.uk 6869 Christopher Patton 6870 University of Florida 6871 cjpatton@ufl.edu 6873 Alfredo Pironti 6874 (co-author of [RFC7627]) 6875 INRIA 6876 alfredo.pironti@inria.fr 6878 Andrei Popov 6879 Microsoft 6880 andrei.popov@microsoft.com 6882 Marsh Ray 6883 (co-author of [RFC7627]) 6884 Microsoft 6885 maray@microsoft.com 6887 Robert Relyea 6888 Netscape Communications 6889 relyea@netscape.com 6891 Kyle Rose 6892 Akamai Technologies 6893 krose@krose.org 6895 Jim Roskind 6896 Amazon 6897 jroskind@amazon.com 6899 Michael Sabin 6901 Joe Salowey 6902 Tableau Software 6903 joe@salowey.net 6905 Rich Salz 6906 Akamai 6907 rsalz@akamai.com 6909 David Schinazi 6910 Apple Inc. 6911 dschinazi@apple.com 6913 Sam Scott 6914 Royal Holloway, University of London 6915 me@samjs.co.uk 6917 Thomas Shrimpton 6918 University of Florida 6919 teshrim@ufl.edu 6921 Dan Simon 6922 Microsoft, Inc. 6923 dansimon@microsoft.com 6925 Brian Smith 6926 Independent 6927 brian@briansmith.org 6929 Brian Sniffen 6930 Akamai Technologies 6931 ietf@bts.evenmere.org 6933 Nick Sullivan 6934 Cloudflare Inc. 6935 nick@cloudflare.com 6937 Bjoern Tackmann 6938 University of California, San Diego 6939 btackmann@eng.ucsd.edu 6940 Tim Taubert 6941 Mozilla 6942 ttaubert@mozilla.com 6944 Martin Thomson 6945 Mozilla 6946 mt@mozilla.com 6948 Hannes Tschofenig 6949 Arm Limited 6950 Hannes.Tschofenig@arm.com 6952 Sean Turner 6953 sn3rd 6954 sean@sn3rd.com 6956 Steven Valdez 6957 Google 6958 svaldez@google.com 6960 Filippo Valsorda 6961 Cloudflare Inc. 6962 filippo@cloudflare.com 6964 Thyla van der Merwe 6965 Royal Holloway, University of London 6966 tjvdmerwe@gmail.com 6968 Victor Vasiliev 6969 Google 6970 vasilvv@google.com 6972 Hoeteck Wee 6973 Ecole Normale Superieure, Paris 6974 hoeteck@alum.mit.edu 6976 Tom Weinstein 6978 David Wong 6979 NCC Group 6980 david.wong@nccgroup.trust 6982 Christopher A. Wood 6983 Apple Inc. 6984 cawood@apple.com 6986 Tim Wright 6987 Vodafone 6988 timothy.wright@vodafone.com 6990 Peter Wu 6991 Independent 6992 peter@lekensteyn.nl 6994 Kazu Yamamoto 6995 Internet Initiative Japan Inc. 6996 kazu@iij.ad.jp 6998 Author's Address 7000 Eric Rescorla 7001 Mozilla 7002 Email: ekr@rtfm.com