idnits 2.17.1 draft-ietf-tls-tls13-24.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 32 instances of too long lines in the document, the longest one being 8 characters in excess of 72. -- The draft header indicates that this document obsoletes RFC5077, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC5246, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6066, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5705, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6961, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4492, 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 the creation date from RFC4492, updated by this document, for RFC5378 checks: 1998-03-18) -- 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 (February 15, 2018) is 2259 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 1010, but not defined -- Looks like a reference, but probably isn't: '0' on line 1133 -- Looks like a reference, but probably isn't: '1' on line 6723 -- Looks like a reference, but probably isn't: '3' on line 1208 -- Looks like a reference, but probably isn't: '9' on line 1173 -- Looks like a reference, but probably isn't: '2' on line 5567 -- Looks like a reference, but probably isn't: '4' on line 1209 -- Looks like a reference, but probably isn't: '8' on line 1210 -- Looks like a reference, but probably isn't: '10' on line 1326 -- Looks like a reference, but probably isn't: '32' on line 5565 == Unused Reference: 'RFC4681' is defined on line 5232, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DH' -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' ** 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) ** Obsolete normative reference: RFC 7539 (Obsoleted by RFC 8439) ** 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' -- Possible downref: Non-RFC (?) normative reference: ref. 'X962' -- 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'. == Outdated reference: A later version (-05) exists of draft-ietf-tls-iana-registry-updates-03 == Outdated reference: A later version (-07) exists of draft-ietf-tls-tls13-vectors-03 -- 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 (==), 33 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Obsoletes: 5077, 5246 (if approved) February 15, 2018 5 Updates: 4492, 5705, 6066, 6961 (if 6 approved) 7 Intended status: Standards Track 8 Expires: August 19, 2018 10 The Transport Layer Security (TLS) Protocol Version 1.3 11 draft-ietf-tls-tls13-24 13 Abstract 15 This document specifies version 1.3 of the Transport Layer Security 16 (TLS) protocol. TLS allows client/server applications to communicate 17 over the Internet in a way that is designed to prevent eavesdropping, 18 tampering, and message forgery. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 19, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 6 68 1.2. Change Log . . . . . . . . . . . . . . . . . . . . . . . 7 69 1.3. Major Differences from TLS 1.2 . . . . . . . . . . . . . 15 70 1.4. Updates Affecting TLS 1.2 . . . . . . . . . . . . . . . . 17 71 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 17 72 2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . . . 20 73 2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 21 74 2.3. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . 23 75 3. Presentation Language . . . . . . . . . . . . . . . . . . . . 25 76 3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 25 77 3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 25 78 3.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 26 79 3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 27 80 3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 27 81 3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 28 82 3.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 28 83 3.8. Variants . . . . . . . . . . . . . . . . . . . . . . . . 29 84 4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 30 85 4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 31 86 4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 31 87 4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 32 88 4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 35 89 4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 37 90 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 39 91 4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 42 92 4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 44 93 4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 44 94 4.2.4. Certificate Authorities . . . . . . . . . . . . . . . 48 95 4.2.5. OID Filters . . . . . . . . . . . . . . . . . . . . . 49 96 4.2.6. Post-Handshake Client Authentication . . . . . . . . 50 97 4.2.7. Negotiated Groups . . . . . . . . . . . . . . . . . . 50 98 4.2.8. Key Share . . . . . . . . . . . . . . . . . . . . . . 52 99 4.2.9. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 55 100 4.2.10. Early Data Indication . . . . . . . . . . . . . . . . 56 101 4.2.11. Pre-Shared Key Extension . . . . . . . . . . . . . . 58 102 4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 62 103 4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 62 104 4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 63 105 4.4. Authentication Messages . . . . . . . . . . . . . . . . . 64 106 4.4.1. The Transcript Hash . . . . . . . . . . . . . . . . . 65 107 4.4.2. Certificate . . . . . . . . . . . . . . . . . . . . . 66 108 4.4.3. Certificate Verify . . . . . . . . . . . . . . . . . 71 109 4.4.4. Finished . . . . . . . . . . . . . . . . . . . . . . 73 110 4.5. End of Early Data . . . . . . . . . . . . . . . . . . . . 75 111 4.6. Post-Handshake Messages . . . . . . . . . . . . . . . . . 75 112 4.6.1. New Session Ticket Message . . . . . . . . . . . . . 75 113 4.6.2. Post-Handshake Authentication . . . . . . . . . . . . 78 114 4.6.3. Key and IV Update . . . . . . . . . . . . . . . . . . 78 115 5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 79 116 5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 80 117 5.2. Record Payload Protection . . . . . . . . . . . . . . . . 82 118 5.3. Per-Record Nonce . . . . . . . . . . . . . . . . . . . . 84 119 5.4. Record Padding . . . . . . . . . . . . . . . . . . . . . 85 120 5.5. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 86 121 6. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . 86 122 6.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 88 123 6.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 89 124 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 92 125 7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 92 126 7.2. Updating Traffic Keys and IVs . . . . . . . . . . . . . . 95 127 7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 96 128 7.4. (EC)DHE Shared Secret Calculation . . . . . . . . . . . . 96 129 7.4.1. Finite Field Diffie-Hellman . . . . . . . . . . . . . 97 130 7.4.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 97 131 7.5. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 98 132 8. 0-RTT and Anti-Replay . . . . . . . . . . . . . . . . . . . . 98 133 8.1. Single-Use Tickets . . . . . . . . . . . . . . . . . . . 100 134 8.2. Client Hello Recording . . . . . . . . . . . . . . . . . 100 135 8.3. Freshness Checks . . . . . . . . . . . . . . . . . . . . 101 136 9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 103 137 9.1. Mandatory-to-Implement Cipher Suites . . . . . . . . . . 103 138 9.2. Mandatory-to-Implement Extensions . . . . . . . . . . . . 103 139 9.3. Protocol Invariants . . . . . . . . . . . . . . . . . . . 104 140 10. Security Considerations . . . . . . . . . . . . . . . . . . . 106 141 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106 142 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 107 143 12.1. Normative References . . . . . . . . . . . . . . . . . . 107 144 12.2. Informative References . . . . . . . . . . . . . . . . . 110 146 Appendix A. State Machine . . . . . . . . . . . . . . . . . . . 118 147 A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 118 148 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 119 149 Appendix B. Protocol Data Structures and Constant Values . . . . 119 150 B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 120 151 B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 120 152 B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 122 153 B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 122 154 B.3.2. Server Parameters Messages . . . . . . . . . . . . . 127 155 B.3.3. Authentication Messages . . . . . . . . . . . . . . . 128 156 B.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 129 157 B.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 129 158 B.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 130 159 Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 131 160 C.1. Random Number Generation and Seeding . . . . . . . . . . 131 161 C.2. Certificates and Authentication . . . . . . . . . . . . . 132 162 C.3. Implementation Pitfalls . . . . . . . . . . . . . . . . . 132 163 C.4. Client Tracking Prevention . . . . . . . . . . . . . . . 133 164 C.5. Unauthenticated Operation . . . . . . . . . . . . . . . . 134 165 Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 134 166 D.1. Negotiating with an older server . . . . . . . . . . . . 135 167 D.2. Negotiating with an older client . . . . . . . . . . . . 136 168 D.3. 0-RTT backwards compatibility . . . . . . . . . . . . . . 136 169 D.4. Middlebox Compatibility Mode . . . . . . . . . . . . . . 136 170 D.5. Backwards Compatibility Security Restrictions . . . . . . 137 171 Appendix E. Overview of Security Properties . . . . . . . . . . 138 172 E.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 138 173 E.1.1. Key Derivation and HKDF . . . . . . . . . . . . . . . 141 174 E.1.2. Client Authentication . . . . . . . . . . . . . . . . 142 175 E.1.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . 142 176 E.1.4. Exporter Independence . . . . . . . . . . . . . . . . 142 177 E.1.5. Post-Compromise Security . . . . . . . . . . . . . . 143 178 E.1.6. External References . . . . . . . . . . . . . . . . . 143 179 E.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 143 180 E.2.1. External References . . . . . . . . . . . . . . . . . 144 181 E.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 144 182 E.4. Side Channel Attacks . . . . . . . . . . . . . . . . . . 145 183 E.5. Replay Attacks on 0-RTT . . . . . . . . . . . . . . . . . 146 184 E.5.1. Replay and Exporters . . . . . . . . . . . . . . . . 147 185 E.6. Attacks on Static RSA . . . . . . . . . . . . . . . . . . 148 186 Appendix F. Working Group Information . . . . . . . . . . . . . 148 187 Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 148 188 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 155 190 1. Introduction 192 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this 193 draft is maintained in GitHub. Suggested changes should be submitted 194 as pull requests at https://github.com/tlswg/tls13-spec. 195 Instructions are on that page as well. Editorial changes can be 196 managed in GitHub, but any substantive change should be discussed on 197 the TLS mailing list. 199 The primary goal of TLS is to provide a secure channel between two 200 communicating peers. Specifically, the channel should provide the 201 following properties: 203 - Authentication: The server side of the channel is always 204 authenticated; the client side is optionally authenticated. 205 Authentication can happen via asymmetric cryptography (e.g., RSA 206 [RSA], ECDSA [ECDSA], EdDSA [RFC8032]) or a pre-shared key (PSK). 208 - Confidentiality: Data sent over the channel after establishment is 209 only visible to the endpoints. TLS does not hide the length of 210 the data it transmits, though endpoints are able to pad TLS 211 records in order to obscure lengths and improve protection against 212 traffic analysis techniques. 214 - Integrity: Data sent over the channel after establishment cannot 215 be modified by attackers. 217 These properties should be true even in the face of an attacker who 218 has complete control of the network, as described in [RFC3552]. See 219 Appendix E for a more complete statement of the relevant security 220 properties. 222 TLS consists of two primary components: 224 - A handshake protocol (Section 4) that authenticates the 225 communicating parties, negotiates cryptographic modes and 226 parameters, and establishes shared keying material. The handshake 227 protocol is designed to resist tampering; an active attacker 228 should not be able to force the peers to negotiate different 229 parameters than they would if the connection were not under 230 attack. 232 - A record protocol (Section 5) that uses the parameters established 233 by the handshake protocol to protect traffic between the 234 communicating peers. The record protocol divides traffic up into 235 a series of records, each of which is independently protected 236 using the traffic keys. 238 TLS is application protocol independent; higher-level protocols can 239 layer on top of TLS transparently. The TLS standard, however, does 240 not specify how protocols add security with TLS; how to initiate TLS 241 handshaking and how to interpret the authentication certificates 242 exchanged are left to the judgment of the designers and implementors 243 of protocols that run on top of TLS. 245 This document defines TLS version 1.3. While TLS 1.3 is not directly 246 compatible with previous versions, all versions of TLS incorporate a 247 versioning mechanism which allows clients and servers to 248 interoperably negotiate a common version if one is supported by both 249 peers. 251 This document supersedes and obsoletes previous versions of TLS 252 including version 1.2 [RFC5246]. It also obsoletes the TLS ticket 253 mechanism defined in [RFC5077] and replaces it with the mechanism 254 defined in Section 2.2. Section 4.2.7 updates [RFC4492] by modifying 255 the protocol attributes used to negotiate Elliptic Curves. Because 256 TLS 1.3 changes the way keys are derived it updates [RFC5705] as 257 described in Section 7.5 it also changes how OCSP messages are 258 carried and therefore updates [RFC6066] and obsoletes [RFC6961] as 259 described in section Section 4.4.2.1. 261 1.1. Conventions and Terminology 263 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 264 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 265 "OPTIONAL" in this document are to be interpreted as described in BCP 266 14 [RFC2119] [RFC8174] when, and only when, they appear in all 267 capitals, as shown here. 269 The following terms are used: 271 client: The endpoint initiating the TLS connection. 273 connection: A transport-layer connection between two endpoints. 275 endpoint: Either the client or server of the connection. 277 handshake: An initial negotiation between client and server that 278 establishes the parameters of their subsequent interactions. 280 peer: An endpoint. When discussing a particular endpoint, "peer" 281 refers to the endpoint that is not the primary subject of discussion. 283 receiver: An endpoint that is receiving records. 285 sender: An endpoint that is transmitting records. 287 server: The endpoint which did not initiate the TLS connection. 289 1.2. Change Log 291 RFC EDITOR PLEASE DELETE THIS SECTION. 293 (*) indicates changes to the wire protocol which may require 294 implementations to update. 296 draft-24 298 - Require that CH2 have version 0303 (*) 300 - Some clarifications 302 draft-23 - Renumber key_share (*) 304 - Add a new extension and new code points to allow negotiating PSS 305 separately for certificates and CertificateVerify (*) 307 - Slightly restrict when CCS must be accepted to make implementation 308 easier. 310 - Document protocol invariants 312 - Add some text on the security of static RSA. 314 draft-22 - Implement changes for improved middlebox penetration (*) 316 - Move server_certificate_type to encrypted extensions (*) 318 - Allow resumption with a different SNI (*) 320 - Padding extension can change on HRR (*) 322 - Allow an empty ticket_nonce (*) 324 - Remove requirement to immediately respond to close_notify with 325 close_notify (allowing half-close) 327 draft-21 329 - Add a per-ticket nonce so that each ticket is associated with a 330 different PSK (*). 332 - Clarify that clients should send alerts with the handshake key if 333 possible. 335 - Update state machine to show rekeying events 337 - Add discussion of 0-RTT and replay. Recommend that 338 implementations implement some anti-replay mechanism. 340 draft-20 342 - Add "post_handshake_auth" extension to negotiate post-handshake 343 authentication (*). 345 - Shorten labels for HKDF-Expand-Label so that we can fit within one 346 compression block (*). 348 - Define how RFC 7250 works (*). 350 - Re-enable post-handshake client authentication even when you do 351 PSK. The previous prohibition was editorial error. 353 - Remove cert_type and user_mapping, which don't work on TLS 1.3 354 anyway. 356 - Added the no_application_protocol alert from [RFC7301] to the list 357 of extensions. 359 - Added discussion of traffic analysis and side channel attacks. 361 draft-19 363 - Hash context_value input to Exporters (*) 365 - Add an additional Derive-Secret stage to Exporters (*). 367 - Hash ClientHello1 in the transcript when HRR is used. This 368 reduces the state that needs to be carried in cookies. (*) 370 - Restructure CertificateRequest to have the selectors in 371 extensions. This also allowed defining a 372 "certificate_authorities" extension which can be used by the 373 client instead of trusted_ca_keys (*). 375 - Tighten record framing requirements and require checking of them 376 (*). 378 - Consolidate "ticket_early_data_info" and "early_data" into a 379 single extension (*). 381 - Change end_of_early_data to be a handshake message (*). 383 - Add pre-extract Derive-Secret stages to key schedule (*). 385 - Remove spurious requirement to implement "pre_shared_key". 387 - Clarify location of "early_data" from server (it goes in EE, as 388 indicated by the table in S 10). 390 - Require peer public key validation 392 - Add state machine diagram. 394 draft-18 396 - Remove unnecessary resumption_psk which is the only thing expanded 397 from the resumption master secret. (*). 399 - Fix signature_algorithms entry in extensions table. 401 - Restate rule from RFC 6066 that you can't resume unless SNI is the 402 same. 404 draft-17 406 - Remove 0-RTT Finished and resumption_context, and replace with a 407 psk_binder field in the PSK itself (*) 409 - Restructure PSK key exchange negotiation modes (*) 411 - Add max_early_data_size field to TicketEarlyDataInfo (*) 413 - Add a 0-RTT exporter and change the transcript for the regular 414 exporter (*) 416 - Merge TicketExtensions and Extensions registry. Changes 417 ticket_early_data_info code point (*) 419 - Replace Client.key_shares in response to HRR (*) 421 - Remove redundant labels for traffic key derivation (*) 423 - Harmonize requirements about cipher suite matching: for resumption 424 you need to match KDF but for 0-RTT you need whole cipher suite. 425 This allows PSKs to actually negotiate cipher suites. (*) 427 - Move SCT and OCSP into Certificate.extensions (*) 429 - Explicitly allow non-offered extensions in NewSessionTicket 430 - Explicitly allow predicting client Finished for NST 432 - Clarify conditions for allowing 0-RTT with PSK 434 draft-16 436 - Revise version negotiation (*) 438 - Change RSASSA-PSS and EdDSA SignatureScheme codepoints for better 439 backwards compatibility (*) 441 - Move HelloRetryRequest.selected_group to an extension (*) 443 - Clarify the behavior of no exporter context and make it the same 444 as an empty context.(*) 446 - New KeyUpdate format that allows for requesting/not-requesting an 447 answer. This also means changes to the key schedule to support 448 independent updates (*) 450 - New certificate_required alert (*) 452 - Forbid CertificateRequest with 0-RTT and PSK. 454 - Relax requirement to check SNI for 0-RTT. 456 draft-15 458 - New negotiation syntax as discussed in Berlin (*) 460 - Require CertificateRequest.context to be empty during handshake 461 (*) 463 - Forbid empty tickets (*) 465 - Forbid application data messages in between post-handshake 466 messages from the same flight (*) 468 - Clean up alert guidance (*) 470 - Clearer guidance on what is needed for TLS 1.2. 472 - Guidance on 0-RTT time windows. 474 - Rename a bunch of fields. 476 - Remove old PRNG text. 478 - Explicitly require checking that handshake records not span key 479 changes. 481 draft-14 483 - Allow cookies to be longer (*) 485 - Remove the "context" from EarlyDataIndication as it was undefined 486 and nobody used it (*) 488 - Remove 0-RTT EncryptedExtensions and replace the ticket_age 489 extension with an obfuscated version. Also necessitates a change 490 to NewSessionTicket (*). 492 - Move the downgrade sentinel to the end of ServerHello.Random to 493 accommodate tlsdate (*). 495 - Define ecdsa_sha1 (*). 497 - Allow resumption even after fatal alerts. This matches current 498 practice. 500 - Remove non-closure warning alerts. Require treating unknown 501 alerts as fatal. 503 - Make the rules for accepting 0-RTT less restrictive. 505 - Clarify 0-RTT backward-compatibility rules. 507 - Clarify how 0-RTT and PSK identities interact. 509 - Add a section describing the data limits for each cipher. 511 - Major editorial restructuring. 513 - Replace the Security Analysis section with a WIP draft. 515 draft-13 517 - Allow server to send SupportedGroups. 519 - Remove 0-RTT client authentication 521 - Remove (EC)DHE 0-RTT. 523 - Flesh out 0-RTT PSK mode and shrink EarlyDataIndication 525 - Turn PSK-resumption response into an index to save room 526 - Move CertificateStatus to an extension 528 - Extra fields in NewSessionTicket. 530 - Restructure key schedule and add a resumption_context value. 532 - Require DH public keys and secrets to be zero-padded to the size 533 of the group. 535 - Remove the redundant length fields in KeyShareEntry. 537 - Define a cookie field for HRR. 539 draft-12 541 - Provide a list of the PSK cipher suites. 543 - Remove the ability for the ServerHello to have no extensions (this 544 aligns the syntax with the text). 546 - Clarify that the server can send application data after its first 547 flight (0.5 RTT data) 549 - Revise signature algorithm negotiation to group hash, signature 550 algorithm, and curve together. This is backwards compatible. 552 - Make ticket lifetime mandatory and limit it to a week. 554 - Make the purpose strings lower-case. This matches how people are 555 implementing for interop. 557 - Define exporters. 559 - Editorial cleanup 561 draft-11 563 - Port the CFRG curves & signatures work from RFC4492bis. 565 - Remove sequence number and version from additional_data, which is 566 now empty. 568 - Reorder values in HkdfLabel. 570 - Add support for version anti-downgrade mechanism. 572 - Update IANA considerations section and relax some of the policies. 574 - Unify authentication modes. Add post-handshake client 575 authentication. 577 - Remove early_handshake content type. Terminate 0-RTT data with an 578 alert. 580 - Reset sequence number upon key change (as proposed by Fournet et 581 al.) 583 draft-10 585 - Remove ClientCertificateTypes field from CertificateRequest and 586 add extensions. 588 - Merge client and server key shares into a single extension. 590 draft-09 592 - Change to RSA-PSS signatures for handshake messages. 594 - Remove support for DSA. 596 - Update key schedule per suggestions by Hugo, Hoeteck, and Bjoern 597 Tackmann. 599 - Add support for per-record padding. 601 - Switch to encrypted record ContentType. 603 - Change HKDF labeling to include protocol version and value 604 lengths. 606 - Shift the final decision to abort a handshake due to incompatible 607 certificates to the client rather than having servers abort early. 609 - Deprecate SHA-1 with signatures. 611 - Add MTI algorithms. 613 draft-08 615 - Remove support for weak and lesser used named curves. 617 - Remove support for MD5 and SHA-224 hashes with signatures. 619 - Update lists of available AEAD cipher suites and error alerts. 621 - Reduce maximum permitted record expansion for AEAD from 2048 to 622 256 octets. 624 - Require digital signatures even when a previous configuration is 625 used. 627 - Merge EarlyDataIndication and KnownConfiguration. 629 - Change code point for server_configuration to avoid collision with 630 server_hello_done. 632 - Relax certificate_list ordering requirement to match current 633 practice. 635 draft-07 637 - Integration of semi-ephemeral DH proposal. 639 - Add initial 0-RTT support. 641 - Remove resumption and replace with PSK + tickets. 643 - Move ClientKeyShare into an extension. 645 - Move to HKDF. 647 draft-06 649 - Prohibit RC4 negotiation for backwards compatibility. 651 - Freeze & deprecate record layer version field. 653 - Update format of signatures with context. 655 - Remove explicit IV. 657 draft-05 659 - Prohibit SSL negotiation for backwards compatibility. 661 - Fix which MS is used for exporters. 663 draft-04 665 - Modify key computations to include session hash. 667 - Remove ChangeCipherSpec. 669 - Renumber the new handshake messages to be somewhat more consistent 670 with existing convention and to remove a duplicate registration. 672 - Remove renegotiation. 674 - Remove point format negotiation. 676 draft-03 678 - Remove GMT time. 680 - Merge in support for ECC from RFC 4492 but without explicit 681 curves. 683 - Remove the unnecessary length field from the AD input to AEAD 684 ciphers. 686 - Rename {Client,Server}KeyExchange to {Client,Server}KeyShare. 688 - Add an explicit HelloRetryRequest to reject the client's. 690 draft-02 692 - Increment version number. 694 - Rework handshake to provide 1-RTT mode. 696 - Remove custom DHE groups. 698 - Remove support for compression. 700 - Remove support for static RSA and DH key exchange. 702 - Remove support for non-AEAD ciphers. 704 1.3. Major Differences from TLS 1.2 706 The following is a list of the major functional differences between 707 TLS 1.2 and TLS 1.3. It is not intended to be exhaustive and there 708 are many minor differences. 710 - The list of supported symmetric algorithms has been pruned of all 711 algorithms that are considered legacy. Those that remain all use 712 Authenticated Encryption with Associated Data (AEAD) algorithms. 713 The ciphersuite concept has been changed to separate the 714 authentication and key exchange mechanisms from the record 715 protection algorithm (including secret key length) and a hash to 716 be used with the key derivation function and HMAC. 718 - A 0-RTT mode was added, saving a round-trip at connection setup 719 for some application data, at the cost of certain security 720 properties. 722 - Static RSA and Diffie-Hellman cipher suites have been removed; all 723 public-key based key exchange mechanisms now provide forward 724 secrecy. 726 - All handshake messages after the ServerHello are now encrypted. 727 The newly introduced EncryptedExtension message allows various 728 extensions previously sent in clear in the ServerHello to also 729 enjoy confidentiality protection from active attackers. 731 - The key derivation functions have been re-designed. The new 732 design allows easier analysis by cryptographers due to their 733 improved key separation properties. The HMAC-based Extract-and- 734 Expand Key Derivation Function (HKDF) is used as an underlying 735 primitive. 737 - The handshake state machine has been significantly restructured to 738 be more consistent and to remove superfluous messages such as 739 ChangeCipherSpec. 741 - Elliptic curve algorithms are now in the base spec and includes 742 new signature algorithms, such as ed25519 and ed448. TLS 1.3 743 removed point format negotiation in favor of a single point format 744 for each curve. 746 - Other cryptographic improvements including the removal of 747 compression and custom DHE groups, changing the RSA padding to use 748 PSS, and the removal of DSA. 750 - The TLS 1.2 version negotiation mechanism has been deprecated in 751 favor of a version list in an extension. This increases 752 compatibility with servers which incorrectly implemented version 753 negotiation. 755 - Session resumption with and without server-side state as well as 756 the PSK-based ciphersuites of earlier TLS versions have been 757 replaced by a single new PSK exchange. 759 - Updated references to point to the updated versions of RFCs, as 760 appropriate (e.g., RFC 5280 rather than RFC 3280). 762 1.4. Updates Affecting TLS 1.2 764 This document defines several changes that optionally affect 765 implementations of TLS 1.2: 767 - A version downgrade protection mechanism is described in 768 Section 4.1.3. 770 - RSASSA-PSS signature schemes are defined in Section 4.2.3. 772 - The "supported_versions" ClientHello extension can be used to 773 negotiate the version of TLS to use, in preference to the 774 legacy_version field of the ClientHello. 776 An implementation of TLS 1.3 that also supports TLS 1.2 might need to 777 include changes to support these changes even when TLS 1.3 is not in 778 use. See the referenced sections for more details. 780 Additionally, this document clarifies some compliance requirements 781 for earlier versions of TLS; see Section 9.3. 783 2. Protocol Overview 785 The cryptographic parameters used by the secure channel are produced 786 by the TLS handshake protocol. This sub-protocol of TLS is used by 787 the client and server when first communicating with each other. The 788 handshake protocol allows peers to negotiate a protocol version, 789 select cryptographic algorithms, optionally authenticate each other, 790 and establish shared secret keying material. Once the handshake is 791 complete, the peers use the established keys to protect the 792 application layer traffic. 794 A failure of the handshake or other protocol error triggers the 795 termination of the connection, optionally preceded by an alert 796 message (Section 6). 798 TLS supports three basic key exchange modes: 800 - (EC)DHE (Diffie-Hellman over either finite fields or elliptic 801 curves) 803 - PSK-only 805 - PSK with (EC)DHE 807 Figure 1 below shows the basic full TLS handshake: 809 Client Server 811 Key ^ ClientHello 812 Exch | + key_share* 813 | + signature_algorithms* 814 | + psk_key_exchange_modes* 815 v + pre_shared_key* --------> 816 ServerHello ^ Key 817 + key_share* | Exch 818 + pre_shared_key* v 819 {EncryptedExtensions} ^ Server 820 {CertificateRequest*} v Params 821 {Certificate*} ^ 822 {CertificateVerify*} | Auth 823 {Finished} v 824 <-------- [Application Data*] 825 ^ {Certificate*} 826 Auth | {CertificateVerify*} 827 v {Finished} --------> 828 [Application Data] <-------> [Application Data] 830 + Indicates noteworthy extensions sent in the 831 previously noted message. 833 * Indicates optional or situation-dependent 834 messages/extensions that are not always sent. 836 {} Indicates messages protected using keys 837 derived from a [sender]_handshake_traffic_secret. 839 [] Indicates messages protected using keys 840 derived from [sender]_application_traffic_secret_N 842 Figure 1: Message flow for full TLS Handshake 844 The handshake can be thought of as having three phases (indicated in 845 the diagram above): 847 - Key Exchange: Establish shared keying material and select the 848 cryptographic parameters. Everything after this phase is 849 encrypted. 851 - Server Parameters: Establish other handshake parameters (whether 852 the client is authenticated, application layer protocol support, 853 etc.). 855 - Authentication: Authenticate the server (and optionally the 856 client) and provide key confirmation and handshake integrity. 858 In the Key Exchange phase, the client sends the ClientHello 859 (Section 4.1.2) message, which contains a random nonce 860 (ClientHello.random); its offered protocol versions; a list of 861 symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key 862 shares (in the "key_share" extension Section 4.2.8), a set of pre- 863 shared key labels (in the "pre_shared_key" extension Section 4.2.11) 864 or both; and potentially additional extensions. 866 The server processes the ClientHello and determines the appropriate 867 cryptographic parameters for the connection. It then responds with 868 its own ServerHello (Section 4.1.3), which indicates the negotiated 869 connection parameters. The combination of the ClientHello and the 870 ServerHello determines the shared keys. If (EC)DHE key establishment 871 is in use, then the ServerHello contains a "key_share" extension with 872 the server's ephemeral Diffie-Hellman share which MUST be in the same 873 group as one of the client's shares. If PSK key establishment is in 874 use, then the ServerHello contains a "pre_shared_key" extension 875 indicating which of the client's offered PSKs was selected. Note 876 that implementations can use (EC)DHE and PSK together, in which case 877 both extensions will be supplied. 879 The server then sends two messages to establish the Server 880 Parameters: 882 EncryptedExtensions: responses to ClientHello extensions that are 883 not required to determine the cryptographic parameters, other than 884 those that are specific to individual certificates. 885 [Section 4.3.1] 887 CertificateRequest: if certificate-based client authentication is 888 desired, the desired parameters for that certificate. This 889 message is omitted if client authentication is not desired. 890 [Section 4.3.2] 892 Finally, the client and server exchange Authentication messages. TLS 893 uses the same set of messages every time that authentication is 894 needed. Specifically: 896 Certificate: the certificate of the endpoint and any per-certificate 897 extensions. This message is omitted by the server if not 898 authenticating with a certificate and by the client if the server 899 did not send CertificateRequest (thus indicating that the client 900 should not authenticate with a certificate). Note that if raw 901 public keys [RFC7250] or the cached information extension 902 [RFC7924] are in use, then this message will not contain a 903 certificate but rather some other value corresponding to the 904 server's long-term key. [Section 4.4.2] 906 CertificateVerify: a signature over the entire handshake using the 907 private key corresponding to the public key in the Certificate 908 message. This message is omitted if the endpoint is not 909 authenticating via a certificate. [Section 4.4.3] 911 Finished: a MAC (Message Authentication Code) over the entire 912 handshake. This message provides key confirmation, binds the 913 endpoint's identity to the exchanged keys, and in PSK mode also 914 authenticates the handshake. [Section 4.4.4] 916 Upon receiving the server's messages, the client responds with its 917 Authentication messages, namely Certificate and CertificateVerify (if 918 requested), and Finished. 920 At this point, the handshake is complete, and the client and server 921 derive the keying material required by the record layer to exchange 922 application-layer data protected through authenticated encryption. 923 Application data MUST NOT be sent prior to sending the Finished 924 message and until the record layer starts using encryption keys. 925 Note that while the server may send application data prior to 926 receiving the client's Authentication messages, any data sent at that 927 point is, of course, being sent to an unauthenticated peer. 929 2.1. Incorrect DHE Share 931 If the client has not provided a sufficient "key_share" extension 932 (e.g., it includes only DHE or ECDHE groups unacceptable to or 933 unsupported by the server), the server corrects the mismatch with a 934 HelloRetryRequest and the client needs to restart the handshake with 935 an appropriate "key_share" extension, as shown in Figure 2. If no 936 common cryptographic parameters can be negotiated, the server MUST 937 abort the handshake with an appropriate alert. 939 Client Server 941 ClientHello 942 + key_share --------> 943 <-------- HelloRetryRequest 944 + key_share 946 ClientHello 947 + key_share --------> 948 ServerHello 949 + key_share 950 {EncryptedExtensions} 951 {CertificateRequest*} 952 {Certificate*} 953 {CertificateVerify*} 954 {Finished} 955 <-------- [Application Data*] 956 {Certificate*} 957 {CertificateVerify*} 958 {Finished} --------> 959 [Application Data] <-------> [Application Data] 961 Figure 2: Message flow for a full handshake with mismatched 962 parameters 964 Note: The handshake transcript includes the initial ClientHello/ 965 HelloRetryRequest exchange; it is not reset with the new ClientHello. 967 TLS also allows several optimized variants of the basic handshake, as 968 described in the following sections. 970 2.2. Resumption and Pre-Shared Key (PSK) 972 Although TLS PSKs can be established out of band, PSKs can also be 973 established in a previous connection and then reused ("session 974 resumption"). Once a handshake has completed, the server can send to 975 the client a PSK identity that corresponds to a unique key derived 976 from the initial handshake (see Section 4.6.1). The client can then 977 use that PSK identity in future handshakes to negotiate the use of 978 the associated PSK. If the server accepts it, then the security 979 context of the new connection is cryptographically tied to the 980 original connection and the key derived from the initial handshake is 981 used to bootstrap the cryptographic state instead of a full 982 handshake. In TLS 1.2 and below, this functionality was provided by 983 "session IDs" and "session tickets" [RFC5077]. Both mechanisms are 984 obsoleted in TLS 1.3. 986 PSKs can be used with (EC)DHE key exchange in order to provide 987 forward secrecy in combination with shared keys, or can be used 988 alone, at the cost of losing forward secrecy for the application 989 data. 991 Figure 3 shows a pair of handshakes in which the first establishes a 992 PSK and the second uses it: 994 Client Server 996 Initial Handshake: 997 ClientHello 998 + key_share --------> 999 ServerHello 1000 + key_share 1001 {EncryptedExtensions} 1002 {CertificateRequest*} 1003 {Certificate*} 1004 {CertificateVerify*} 1005 {Finished} 1006 <-------- [Application Data*] 1007 {Certificate*} 1008 {CertificateVerify*} 1009 {Finished} --------> 1010 <-------- [NewSessionTicket] 1011 [Application Data] <-------> [Application Data] 1013 Subsequent Handshake: 1014 ClientHello 1015 + key_share* 1016 + pre_shared_key --------> 1017 ServerHello 1018 + pre_shared_key 1019 + key_share* 1020 {EncryptedExtensions} 1021 {Finished} 1022 <-------- [Application Data*] 1023 {Finished} --------> 1024 [Application Data] <-------> [Application Data] 1026 Figure 3: Message flow for resumption and PSK 1028 As the server is authenticating via a PSK, it does not send a 1029 Certificate or a CertificateVerify message. When a client offers 1030 resumption via PSK, it SHOULD also supply a "key_share" extension to 1031 the server to allow the server to decline resumption and fall back to 1032 a full handshake, if needed. The server responds with a 1033 "pre_shared_key" extension to negotiate use of PSK key establishment 1034 and can (as shown here) respond with a "key_share" extension to do 1035 (EC)DHE key establishment, thus providing forward secrecy. 1037 When PSKs are provisioned out of band, the PSK identity and the KDF 1038 hash algorithm to be used with the PSK MUST also be provisioned. 1040 Note: When using an out-of-band provisioned pre-shared secret, a 1041 critical consideration is using sufficient entropy during the key 1042 generation, as discussed in [RFC4086]. Deriving a shared secret 1043 from a password or other low-entropy sources is not secure. A 1044 low-entropy secret, or password, is subject to dictionary attacks 1045 based on the PSK binder. The specified PSK authentication is not 1046 a strong password-based authenticated key exchange even when used 1047 with Diffie-Hellman key establishment. 1049 2.3. 0-RTT Data 1051 When clients and servers share a PSK (either obtained externally or 1052 via a previous handshake), TLS 1.3 allows clients to send data on the 1053 first flight ("early data"). The client uses the PSK to authenticate 1054 the server and to encrypt the early data. 1056 As shown in Figure 4, the 0-RTT data is just added to the 1-RTT 1057 handshake in the first flight. The rest of the handshake uses the 1058 same messages as with a 1-RTT handshake with PSK resumption. 1060 Client Server 1062 ClientHello 1063 + early_data 1064 + key_share* 1065 + psk_key_exchange_modes 1066 + pre_shared_key 1067 (Application Data*) --------> 1068 ServerHello 1069 + pre_shared_key 1070 + key_share* 1071 {EncryptedExtensions} 1072 + early_data* 1073 {Finished} 1074 <-------- [Application Data*] 1075 (EndOfEarlyData) 1076 {Finished} --------> 1078 [Application Data] <-------> [Application Data] 1080 + Indicates noteworthy extensions sent in the 1081 previously noted message. 1083 * Indicates optional or situation-dependent 1084 messages/extensions that are not always sent. 1086 () Indicates messages protected using keys 1087 derived from client_early_traffic_secret. 1089 {} Indicates messages protected using keys 1090 derived from a [sender]_handshake_traffic_secret. 1092 [] Indicates messages protected using keys 1093 derived from [sender]_application_traffic_secret_N 1095 Figure 4: Message flow for a zero round trip handshake 1097 IMPORTANT NOTE: The security properties for 0-RTT data are weaker 1098 than those for other kinds of TLS data. Specifically: 1100 1. This data is not forward secret, as it is encrypted solely under 1101 keys derived using the offered PSK. 1103 2. There are no guarantees of non-replay between connections. 1104 Protection against replay for ordinary TLS 1.3 1-RTT data is 1105 provided via the server's Random value, but 0-RTT data does not 1106 depend on the ServerHello and therefore has weaker guarantees. 1107 This is especially relevant if the data is authenticated either 1108 with TLS client authentication or inside the application 1109 protocol. The same warnings apply to any use of the 1110 early_exporter_master_secret. 1112 0-RTT data cannot be duplicated within a connection (i.e., the server 1113 will not process the same data twice for the same connection) and an 1114 attacker will not be able to make 0-RTT data appear to be 1-RTT data 1115 (because it is protected with different keys.) Appendix E.5 contains 1116 a description of potential attacks and Section 8 describes mechanisms 1117 which the server can use to limit the impact of replay. 1119 3. Presentation Language 1121 This document deals with the formatting of data in an external 1122 representation. The following very basic and somewhat casually 1123 defined presentation syntax will be used. 1125 3.1. Basic Block Size 1127 The representation of all data items is explicitly specified. The 1128 basic data block size is one byte (i.e., 8 bits). Multiple byte data 1129 items are concatenations of bytes, from left to right, from top to 1130 bottom. From the byte stream, a multi-byte item (a numeric in the 1131 example) is formed (using C notation) by: 1133 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | 1134 ... | byte[n-1]; 1136 This byte ordering for multi-byte values is the commonplace network 1137 byte order or big-endian format. 1139 3.2. Miscellaneous 1141 Comments begin with "/*" and end with "*/". 1143 Optional components are denoted by enclosing them in "[[ ]]" double 1144 brackets. 1146 Single-byte entities containing uninterpreted data are of type 1147 opaque. 1149 A type alias T' for an existing type T is defined by: 1151 T T'; 1153 3.3. Vectors 1155 A vector (single-dimensioned array) is a stream of homogeneous data 1156 elements. The size of the vector may be specified at documentation 1157 time or left unspecified until runtime. In either case, the length 1158 declares the number of bytes, not the number of elements, in the 1159 vector. The syntax for specifying a new type, T', that is a fixed- 1160 length vector of type T is 1162 T T'[n]; 1164 Here, T' occupies n bytes in the data stream, where n is a multiple 1165 of the size of T. The length of the vector is not included in the 1166 encoded stream. 1168 In the following example, Datum is defined to be three consecutive 1169 bytes that the protocol does not interpret, while Data is three 1170 consecutive Datum, consuming a total of nine bytes. 1172 opaque Datum[3]; /* three uninterpreted bytes */ 1173 Datum Data[9]; /* 3 consecutive 3-byte vectors */ 1175 Variable-length vectors are defined by specifying a subrange of legal 1176 lengths, inclusively, using the notation . When 1177 these are encoded, the actual length precedes the vector's contents 1178 in the byte stream. The length will be in the form of a number 1179 consuming as many bytes as required to hold the vector's specified 1180 maximum (ceiling) length. A variable-length vector with an actual 1181 length field of zero is referred to as an empty vector. 1183 T T'; 1185 In the following example, mandatory is a vector that must contain 1186 between 300 and 400 bytes of type opaque. It can never be empty. 1187 The actual length field consumes two bytes, a uint16, which is 1188 sufficient to represent the value 400 (see Section 3.4). Similarly, 1189 longer can represent up to 800 bytes of data, or 400 uint16 elements, 1190 and it may be empty. Its encoding will include a two-byte actual 1191 length field prepended to the vector. The length of an encoded 1192 vector must be an exact multiple of the length of a single element 1193 (e.g., a 17-byte vector of uint16 would be illegal). 1195 opaque mandatory<300..400>; 1196 /* length field is 2 bytes, cannot be empty */ 1197 uint16 longer<0..800>; 1198 /* zero to 400 16-bit unsigned integers */ 1200 3.4. Numbers 1202 The basic numeric data type is an unsigned byte (uint8). All larger 1203 numeric data types are formed from fixed-length series of bytes 1204 concatenated as described in Section 3.1 and are also unsigned. The 1205 following numeric types are predefined. 1207 uint8 uint16[2]; 1208 uint8 uint24[3]; 1209 uint8 uint32[4]; 1210 uint8 uint64[8]; 1212 All values, here and elsewhere in the specification, are stored in 1213 network byte (big-endian) order; the uint32 represented by the hex 1214 bytes 01 02 03 04 is equivalent to the decimal value 16909060. 1216 3.5. Enumerateds 1218 An additional sparse data type is available called enum. Each 1219 definition is a different type. Only enumerateds of the same type 1220 may be assigned or compared. Every element of an enumerated must be 1221 assigned a value, as demonstrated in the following example. Since 1222 the elements of the enumerated are not ordered, they can be assigned 1223 any unique value, in any order. 1225 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; 1227 Future extensions or additions to the protocol may define new values. 1228 Implementations need to be able to parse and ignore unknown values 1229 unless the definition of the field states otherwise. 1231 An enumerated occupies as much space in the byte stream as would its 1232 maximal defined ordinal value. The following definition would cause 1233 one byte to be used to carry fields of type Color. 1235 enum { red(3), blue(5), white(7) } Color; 1237 One may optionally specify a value without its associated tag to 1238 force the width definition without defining a superfluous element. 1240 In the following example, Taste will consume two bytes in the data 1241 stream but can only assume the values 1, 2, or 4 in the current 1242 version of the protocol. 1244 enum { sweet(1), sour(2), bitter(4), (32000) } Taste; 1246 The names of the elements of an enumeration are scoped within the 1247 defined type. In the first example, a fully qualified reference to 1248 the second element of the enumeration would be Color.blue. Such 1249 qualification is not required if the target of the assignment is well 1250 specified. 1252 Color color = Color.blue; /* overspecified, legal */ 1253 Color color = blue; /* correct, type implicit */ 1255 The names assigned to enumerateds do not need to be unique. The 1256 numerical value can describe a range over which the same name 1257 applies. The value includes the minimum and maximum inclusive values 1258 in that range, separated by two period characters. This is 1259 principally useful for reserving regions of the space. 1261 enum { sad(0), meh(1..254), happy(255) } Mood; 1263 3.6. Constructed Types 1265 Structure types may be constructed from primitive types for 1266 convenience. Each specification declares a new, unique type. The 1267 syntax for definition is much like that of C. 1269 struct { 1270 T1 f1; 1271 T2 f2; 1272 ... 1273 Tn fn; 1274 } T; 1276 Fixed- and variable-length vector fields are allowed using the 1277 standard vector syntax. Structures V1 and V2 in the variants example 1278 below demonstrate this. 1280 The fields within a structure may be qualified using the type's name, 1281 with a syntax much like that available for enumerateds. For example, 1282 T.f2 refers to the second field of the previous declaration. 1284 3.7. Constants 1286 Fields and variables may be assigned a fixed value using "=", as in: 1288 struct { 1289 T1 f1 = 8; /* T.f1 must always be 8 */ 1290 T2 f2; 1291 } T; 1293 3.8. Variants 1295 Defined structures may have variants based on some knowledge that is 1296 available within the environment. The selector must be an enumerated 1297 type that defines the possible variants the structure defines. Each 1298 arm of the select specifies the type of that variant's field and an 1299 optional field label. The mechanism by which the variant is selected 1300 at runtime is not prescribed by the presentation language. 1302 struct { 1303 T1 f1; 1304 T2 f2; 1305 .... 1306 Tn fn; 1307 select (E) { 1308 case e1: Te1 [[fe1]]; 1309 case e2: Te2 [[fe2]]; 1310 .... 1311 case en: Ten [[fen]]; 1312 }; 1313 } Tv; 1315 For example: 1317 enum { apple(0), orange(1) } VariantTag; 1319 struct { 1320 uint16 number; 1321 opaque string<0..10>; /* variable length */ 1322 } V1; 1324 struct { 1325 uint32 number; 1326 opaque string[10]; /* fixed length */ 1327 } V2; 1329 struct { 1330 VariantTag type; 1331 select (VariantRecord.type) { 1332 case apple: V1; 1333 case orange: V2; 1334 }; 1335 } VariantRecord; 1337 4. Handshake Protocol 1339 The handshake protocol is used to negotiate the security parameters 1340 of a connection. Handshake messages are supplied to the TLS record 1341 layer, where they are encapsulated within one or more TLSPlaintext or 1342 TLSCiphertext structures, which are processed and transmitted as 1343 specified by the current active connection state. 1345 enum { 1346 client_hello(1), 1347 server_hello(2), 1348 new_session_ticket(4), 1349 end_of_early_data(5), 1350 encrypted_extensions(8), 1351 certificate(11), 1352 certificate_request(13), 1353 certificate_verify(15), 1354 finished(20), 1355 key_update(24), 1356 message_hash(254), 1357 (255) 1358 } HandshakeType; 1360 struct { 1361 HandshakeType msg_type; /* handshake type */ 1362 uint24 length; /* bytes in message */ 1363 select (Handshake.msg_type) { 1364 case client_hello: ClientHello; 1365 case server_hello: ServerHello; 1366 case end_of_early_data: EndOfEarlyData; 1367 case encrypted_extensions: EncryptedExtensions; 1368 case certificate_request: CertificateRequest; 1369 case certificate: Certificate; 1370 case certificate_verify: CertificateVerify; 1371 case finished: Finished; 1372 case new_session_ticket: NewSessionTicket; 1373 case key_update: KeyUpdate; 1374 }; 1375 } Handshake; 1377 Protocol messages MUST be sent in the order defined in Section 4.4.1 1378 and shown in the diagrams in Section 2. A peer which receives a 1379 handshake message in an unexpected order MUST abort the handshake 1380 with an "unexpected_message" alert. 1382 New handshake message types are assigned by IANA as described in 1383 Section 11. 1385 4.1. Key Exchange Messages 1387 The key exchange messages are used to determine the security 1388 capabilities of the client and the server and to establish shared 1389 secrets including the traffic keys used to protect the rest of the 1390 handshake and the data. 1392 4.1.1. Cryptographic Negotiation 1394 In TLS, the cryptographic negotiation proceeds by the client offering 1395 the following four sets of options in its ClientHello: 1397 - A list of cipher suites which indicates the AEAD algorithm/HKDF 1398 hash pairs which the client supports. 1400 - A "supported_groups" (Section 4.2.7) extension which indicates the 1401 (EC)DHE groups which the client supports and a "key_share" 1402 (Section 4.2.8) extension which contains (EC)DHE shares for some 1403 or all of these groups. 1405 - A "signature_algorithms" (Section 4.2.3) extension which indicates 1406 the signature algorithms which the client can accept. 1408 - A "pre_shared_key" (Section 4.2.11) extension which contains a 1409 list of symmetric key identities known to the client and a 1410 "psk_key_exchange_modes" (Section 4.2.9) extension which indicates 1411 the key exchange modes that may be used with PSKs. 1413 If the server does not select a PSK, then the first three of these 1414 options are entirely orthogonal: the server independently selects a 1415 cipher suite, an (EC)DHE group and key share for key establishment, 1416 and a signature algorithm/certificate pair to authenticate itself to 1417 the client. If there is no overlap between the received 1418 "supported_groups" and the groups supported by the server then the 1419 server MUST abort the handshake with a "handshake_failure" or an 1420 "insufficient_security" alert. 1422 If the server selects a PSK, then it MUST also select a key 1423 establishment mode from the set indicated by client's 1424 "psk_key_exchange_modes" extension (at present, PSK alone or with 1425 (EC)DHE). Note that if the PSK can be used without (EC)DHE then non- 1426 overlap in the "supported_groups" parameters need not be fatal, as it 1427 is in the non-PSK case discussed in the previous paragraph. 1429 If the server selects an (EC)DHE group and the client did not offer a 1430 compatible "key_share" extension in the initial ClientHello, the 1431 server MUST respond with a HelloRetryRequest (Section 4.1.4) message. 1433 If the server successfully selects parameters and does not require a 1434 HelloRetryRequest, it indicates the selected parameters in the 1435 ServerHello as follows: 1437 - If PSK is being used, then the server will send a "pre_shared_key" 1438 extension indicating the selected key. 1440 - If PSK is not being used, then (EC)DHE and certificate-based 1441 authentication are always used. 1443 - When (EC)DHE is in use, the server will also provide a "key_share" 1444 extension. 1446 - When authenticating via a certificate, the server will send the 1447 Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3) 1448 messages. In TLS 1.3 as defined by this document, either a PSK or 1449 a certificate is always used, but not both. Future documents may 1450 define how to use them together. 1452 If the server is unable to negotiate a supported set of parameters 1453 (i.e., there is no overlap between the client and server parameters), 1454 it MUST abort the handshake with either a "handshake_failure" or 1455 "insufficient_security" fatal alert (see Section 6). 1457 4.1.2. Client Hello 1459 When a client first connects to a server, it is REQUIRED to send the 1460 ClientHello as its first message. The client will also send a 1461 ClientHello when the server has responded to its ClientHello with a 1462 HelloRetryRequest. In that case, the client MUST send the same 1463 ClientHello (without modification) except: 1465 - If a "key_share" extension was supplied in the HelloRetryRequest, 1466 replacing the list of shares with a list containing a single 1467 KeyShareEntry from the indicated group. 1469 - Removing the "early_data" extension (Section 4.2.10) if one was 1470 present. Early data is not permitted after HelloRetryRequest. 1472 - Including a "cookie" extension if one was provided in the 1473 HelloRetryRequest. 1475 - Updating the "pre_shared_key" extension if present by recomputing 1476 the "obfuscated_ticket_age" and binder values and (optionally) 1477 removing any PSKs which are incompatible with the server's 1478 indicated cipher suite. 1480 - Optionally adding, removing, or changing the length of the 1481 "padding" extension [RFC7685]. 1483 Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS 1484 1.3 and receives a ClientHello at any other time, it MUST terminate 1485 the connection with an "unexpected_message" alert. 1487 If a server established a TLS connection with a previous version of 1488 TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST 1489 retain the previous protocol version. In particular, it MUST NOT 1490 negotiate TLS 1.3. 1492 Structure of this message: 1494 uint16 ProtocolVersion; 1495 opaque Random[32]; 1497 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1499 struct { 1500 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 1501 Random random; 1502 opaque legacy_session_id<0..32>; 1503 CipherSuite cipher_suites<2..2^16-2>; 1504 opaque legacy_compression_methods<1..2^8-1>; 1505 Extension extensions<8..2^16-1>; 1506 } ClientHello; 1508 legacy_version In previous versions of TLS, this field was used for 1509 version negotiation and represented the highest version number 1510 supported by the client. Experience has shown that many servers 1511 do not properly implement version negotiation, leading to "version 1512 intolerance" in which the server rejects an otherwise acceptable 1513 ClientHello with a version number higher than it supports. In TLS 1514 1.3, the client indicates its version preferences in the 1515 "supported_versions" extension (Section 4.2.1) and the 1516 legacy_version field MUST be set to 0x0303, which is the version 1517 number for TLS 1.2. (See Appendix D for details about backward 1518 compatibility.) 1520 random 32 bytes generated by a secure random number generator. See 1521 Appendix C for additional information. 1523 legacy_session_id Versions of TLS before TLS 1.3 supported a 1524 "session resumption" feature which has been merged with Pre-Shared 1525 Keys in this version (see Section 2.2). A client which has a 1526 cached session ID set by a pre-TLS 1.3 server SHOULD set this 1527 field to that value. In compatibility mode (see Appendix D.4) 1528 this field MUST be non-empty, so a client not offering a pre-TLS 1529 1.3 session MUST generate a new 32-byte value. This value need 1530 not be random but SHOULD be unpredictable to avoid implementations 1531 fixating on a specific value (also known as ossification). 1532 Otherwise, it MUST be set as a zero length vector (i.e., a single 1533 zero byte length field). 1535 cipher_suites This is a list of the symmetric cipher options 1536 supported by the client, specifically the record protection 1537 algorithm (including secret key length) and a hash to be used with 1538 HKDF, in descending order of client preference. If the list 1539 contains cipher suites that the server does not recognize, support 1540 or wish to use, the server MUST ignore those cipher suites and 1541 process the remaining ones as usual. Values are defined in 1542 Appendix B.4. If the client is attempting a PSK key 1543 establishment, it SHOULD advertise at least one cipher suite 1544 indicating a Hash associated with the PSK. 1546 legacy_compression_methods Versions of TLS before 1.3 supported 1547 compression with the list of supported compression methods being 1548 sent in this field. For every TLS 1.3 ClientHello, this vector 1549 MUST contain exactly one byte set to zero, which corresponds to 1550 the "null" compression method in prior versions of TLS. If a TLS 1551 1.3 ClientHello is received with any other value in this field, 1552 the server MUST abort the handshake with an "illegal_parameter" 1553 alert. Note that TLS 1.3 servers might receive TLS 1.2 or prior 1554 ClientHellos which contain other compression methods and MUST 1555 follow the procedures for the appropriate prior version of TLS. 1556 TLS 1.3 ClientHellos are identified as having a legacy_version of 1557 0x0303 and a supported_versions extension present with 0x0304 as 1558 the highest version indicated therein. 1560 extensions Clients request extended functionality from servers by 1561 sending data in the extensions field. The actual "Extension" 1562 format is defined in Section 4.2. In TLS 1.3, use of certain 1563 extensions is mandatory, as functionality is moved into extensions 1564 to preserve ClientHello compatibility with previous versions of 1565 TLS. Servers MUST ignore unrecognized extensions. 1567 All versions of TLS allow an extensions field to optionally follow 1568 the compression_methods field. TLS 1.3 ClientHello messages always 1569 contain extensions (minimally "supported_versions", otherwise they 1570 will be interpreted as TLS 1.2 ClientHello messages). However, TLS 1571 1.3 servers might receive ClientHello messages without an extensions 1572 field from prior versions of TLS. The presence of extensions can be 1573 detected by determining whether there are bytes following the 1574 compression_methods field at the end of the ClientHello. Note that 1575 this method of detecting optional data differs from the normal TLS 1576 method of having a variable-length field, but it is used for 1577 compatibility with TLS before extensions were defined. TLS 1.3 1578 servers will need to perform this check first and only attempt to 1579 negotiate TLS 1.3 if the "supported_versions" extension is present. 1580 If negotiating a version of TLS prior to 1.3, a server MUST check 1581 that the message either contains no data after 1582 legacy_compression_methods or that it contains a valid extensions 1583 block with no data following. If not, then it MUST abort the 1584 handshake with a "decode_error" alert. 1586 In the event that a client requests additional functionality using 1587 extensions, and this functionality is not supplied by the server, the 1588 client MAY abort the handshake. 1590 After sending the ClientHello message, the client waits for a 1591 ServerHello or HelloRetryRequest message. If early data is in use, 1592 the client may transmit early application data (Section 2.3) while 1593 waiting for the next handshake message. 1595 4.1.3. Server Hello 1597 The server will send this message in response to a ClientHello 1598 message to proceed with the handshake if it is able to negotiate an 1599 acceptable set of handshake parameters based on the ClientHello. 1601 Structure of this message: 1603 struct { 1604 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 1605 Random random; 1606 opaque legacy_session_id_echo<0..32>; 1607 CipherSuite cipher_suite; 1608 uint8 legacy_compression_method = 0; 1609 Extension extensions<6..2^16-1>; 1610 } ServerHello; 1612 legacy_version In previous versions of TLS, this field was used for 1613 version negotiation and represented the selected version number 1614 for the connection. Unfortunately, some middleboxes fail when 1615 presented with new values. In TLS 1.3, the TLS server indicates 1616 its version using the "supported_versions" extension 1617 (Section 4.2.1), and the legacy_version field MUST be set to 1618 0x0303, which is the version number for TLS 1.2. (See Appendix D 1619 for details about backward compatibility.) 1621 random 32 bytes generated by a secure random number generator. See 1622 Appendix C for additional information. The last eight bytes MUST 1623 be overwritten as described below if negotiating TLS 1.2 or TLS 1624 1.1, but the remaining bytes MUST be random. This structure is 1625 generated by the server and MUST be generated independently of the 1626 ClientHello.random. 1628 legacy_session_id_echo The contents of the client's 1629 legacy_session_id field. Note that this field is echoed even if 1630 the client's value corresponded to a cached pre-TLS 1.3 session 1631 which the server has chosen not to resume. A client which 1632 receives a legacy_session_id field that does not match what it 1633 sent in the ClientHello MUST abort the handshake with an 1634 "illegal_parameter" alert. 1636 cipher_suite The single cipher suite selected by the server from the 1637 list in ClientHello.cipher_suites. A client which receives a 1638 cipher suite that was not offered MUST abort the handshake with an 1639 "illegal_parameter" alert. 1641 legacy_compression_method A single byte which MUST have the value 0. 1643 extensions A list of extensions. The ServerHello MUST only include 1644 extensions which are required to establish the cryptographic 1645 context and negotiate the protocol version. All TLS 1.3 1646 ServerHello messages MUST contain the "supported_versions" 1647 extension. Current ServerHello messages contain either the 1648 "pre_shared_key" or "key_share" extensions, or both when using a 1649 PSK with (EC)DHE key establishment. The remaining extensions are 1650 sent separately in the EncryptedExtensions message. 1652 For backward compatibility reasons with middleboxes (see 1653 Appendix D.4) the HelloRetryRequest message uses the same structure 1654 as the ServerHello, but with Random set to the special value of the 1655 SHA-256 of "HelloRetryRequest": 1657 CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91 1658 C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C 1660 Upon receiving a message with type server_hello, implementations MUST 1661 first examine the Random value and if it matches this value, process 1662 it as described in Section 4.1.4). 1664 TLS 1.3 has a downgrade protection mechanism embedded in the server's 1665 random value. TLS 1.3 servers which negotiate TLS 1.2 or below in 1666 response to a ClientHello MUST set the last eight bytes of their 1667 Random value specially. 1669 If negotiating TLS 1.2, TLS 1.3 servers MUST set the last eight bytes 1670 of their Random value to the bytes: 1672 44 4F 57 4E 47 52 44 01 1674 If negotiating TLS 1.1 or below, TLS 1.3 servers MUST and TLS 1.2 1675 servers SHOULD set the last eight bytes of their Random value to the 1676 bytes: 1678 44 4F 57 4E 47 52 44 00 1680 TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below 1681 MUST check that the last eight bytes are not equal to either of these 1682 values. TLS 1.2 clients SHOULD also check that the last eight bytes 1683 are not equal to the second value if the ServerHello indicates TLS 1684 1.1 or below. If a match is found, the client MUST abort the 1685 handshake with an "illegal_parameter" alert. This mechanism provides 1686 limited protection against downgrade attacks over and above what is 1687 provided by the Finished exchange: because the ServerKeyExchange, a 1688 message present in TLS 1.2 and below, includes a signature over both 1689 random values, it is not possible for an active attacker to modify 1690 the random values without detection as long as ephemeral ciphers are 1691 used. It does not provide downgrade protection when static RSA is 1692 used. 1694 Note: This is a change from [RFC5246], so in practice many TLS 1.2 1695 clients and servers will not behave as specified above. 1697 A legacy TLS client performing renegotiation with TLS 1.2 or prior 1698 and which receives a TLS 1.3 ServerHello during renegotiation MUST 1699 abort the handshake with a "protocol_version" alert. Note that 1700 renegotiation is not possible when TLS 1.3 has been negotiated. 1702 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of 1703 draft versions (see Section 4.2.1.1) of this specification SHOULD NOT 1704 implement this mechanism on either client and server. A pre-RFC 1705 client connecting to RFC servers, or vice versa, will appear to 1706 downgrade to TLS 1.2. With the mechanism enabled, this will cause an 1707 interoperability failure. 1709 4.1.4. Hello Retry Request 1711 The server will send this message in response to a ClientHello 1712 message if it is able to find an acceptable set of parameters but the 1713 ClientHello does not contain sufficient information to proceed with 1714 the handshake. As discussed in Section 4.1.3, the HelloRetryRequest 1715 has the same format as a ServerHello message, and the legacy_version, 1716 legacy_session_id_echo, cipher_suite, and legacy_compression methods 1717 fields have the same meaning. However, for convenience we discuss 1718 HelloRetryRequest throughout this document as if it were a distinct 1719 message. 1721 The server's extensions MUST contain "supported_versions" and 1722 otherwise the server SHOULD send only the extensions necessary for 1723 the client to generate a correct ClientHello pair. As with 1724 ServerHello, a HelloRetryRequest MUST NOT contain any extensions that 1725 were not first offered by the client in its ClientHello, with the 1726 exception of optionally the "cookie" (see Section 4.2.2) extension. 1728 Upon receipt of a HelloRetryRequest, the client MUST perform the 1729 checks specified in Section 4.1.3 and then process the extensions, 1730 starting with determining the version using "supported_versions". 1731 Clients MUST abort the handshake with an "illegal_parameter" alert if 1732 the HelloRetryRequest would not result in any change in the 1733 ClientHello. If a client receives a second HelloRetryRequest in the 1734 same connection (i.e., where the ClientHello was itself in response 1735 to a HelloRetryRequest), it MUST abort the handshake with an 1736 "unexpected_message" alert. 1738 Otherwise, the client MUST process all extensions in the 1739 HelloRetryRequest and send a second updated ClientHello. The 1740 HelloRetryRequest extensions defined in this specification are: 1742 - supported_versions (see Section 4.2.1) 1744 - cookie (see Section 4.2.2) 1746 - key_share (see Section 4.2.8) 1748 In addition, in its updated ClientHello, the client SHOULD NOT offer 1749 any pre-shared keys associated with a hash other than that of the 1750 selected cipher suite. This allows the client to avoid having to 1751 compute partial hash transcripts for multiple hashes in the second 1752 ClientHello. A client which receives a cipher suite that was not 1753 offered MUST abort the handshake. Servers MUST ensure that they 1754 negotiate the same cipher suite when receiving a conformant updated 1755 ClientHello (if the server selects the cipher suite as the first step 1756 in the negotiation, then this will happen automatically). Upon 1757 receiving the ServerHello, clients MUST check that the cipher suite 1758 supplied in the ServerHello is the same as that in the 1759 HelloRetryRequest and otherwise abort the handshake with an 1760 "illegal_parameter" alert. 1762 The value of selected_version in the HelloRetryRequest 1763 "supported_versions" extension MUST be retained in the ServerHello, 1764 and a client MUST abort the handshake with an "illegal_parameter" 1765 alert if the value changes. 1767 4.2. Extensions 1769 A number of TLS messages contain tag-length-value encoded extensions 1770 structures. 1772 struct { 1773 ExtensionType extension_type; 1774 opaque extension_data<0..2^16-1>; 1775 } Extension; 1777 enum { 1778 server_name(0), /* RFC 6066 */ 1779 max_fragment_length(1), /* RFC 6066 */ 1780 status_request(5), /* RFC 6066 */ 1781 supported_groups(10), /* RFC 4492, 7919 */ 1782 signature_algorithms(13), /* [[this document]] */ 1783 use_srtp(14), /* RFC 5764 */ 1784 heartbeat(15), /* RFC 6520 */ 1785 application_layer_protocol_negotiation(16), /* RFC 7301 */ 1786 signed_certificate_timestamp(18), /* RFC 6962 */ 1787 client_certificate_type(19), /* RFC 7250 */ 1788 server_certificate_type(20), /* RFC 7250 */ 1789 padding(21), /* RFC 7685 */ 1790 pre_shared_key(41), /* [[this document]] */ 1791 early_data(42), /* [[this document]] */ 1792 supported_versions(43), /* [[this document]] */ 1793 cookie(44), /* [[this document]] */ 1794 psk_key_exchange_modes(45), /* [[this document]] */ 1795 certificate_authorities(47), /* [[this document]] */ 1796 oid_filters(48), /* [[this document]] */ 1797 post_handshake_auth(49), /* [[this document]] */ 1798 signature_algorithms_cert(50), /* [[this document]] */ 1799 key_share(51), /* [[this document]] */ 1800 (65535) 1801 } ExtensionType; 1803 Here: 1805 - "extension_type" identifies the particular extension type. 1807 - "extension_data" contains information specific to the particular 1808 extension type. 1810 The list of extension types is maintained by IANA as described in 1811 Section 11. 1813 Extensions are generally structured in a request/response fashion, 1814 though some extensions are just indications with no corresponding 1815 response. The client sends its extension requests in the ClientHello 1816 message and the server sends its extension responses in the 1817 ServerHello, EncryptedExtensions, HelloRetryRequest and Certificate 1818 messages. The server sends extension requests in the 1819 CertificateRequest message which a client MAY respond to with a 1820 Certificate message. The server MAY also send unsolicited extensions 1821 in the NewSessionTicket, though the client does not respond directly 1822 to these. 1824 Implementations MUST NOT send extension responses if the remote 1825 endpoint did not send the corresponding extension requests, with the 1826 exception of the "cookie" extension in HelloRetryRequest. Upon 1827 receiving such an extension, an endpoint MUST abort the handshake 1828 with an "unsupported_extension" alert. 1830 The table below indicates the messages where a given extension may 1831 appear, using the following notation: CH (ClientHello), SH 1832 (ServerHello), EE (EncryptedExtensions), CT (Certificate), CR 1833 (CertificateRequest), NST (NewSessionTicket) and HRR 1834 (HelloRetryRequest). If an implementation receives an extension 1835 which it recognizes and which is not specified for the message in 1836 which it appears it MUST abort the handshake with an 1837 "illegal_parameter" alert. 1839 +--------------------------------------------------+-------------+ 1840 | Extension | TLS 1.3 | 1841 +--------------------------------------------------+-------------+ 1842 | server_name [RFC6066] | CH, EE | 1843 | | | 1844 | max_fragment_length [RFC6066] | CH, EE | 1845 | | | 1846 | status_request [RFC6066] | CH, CR, CT | 1847 | | | 1848 | supported_groups [RFC7919] | CH, EE | 1849 | | | 1850 | signature_algorithms [RFC5246] | CH, CR | 1851 | | | 1852 | use_srtp [RFC5764] | CH, EE | 1853 | | | 1854 | heartbeat [RFC6520] | CH, EE | 1855 | | | 1856 | application_layer_protocol_negotiation [RFC7301] | CH, EE | 1857 | | | 1858 | signed_certificate_timestamp [RFC6962] | CH, CR, CT | 1859 | | | 1860 | client_certificate_type [RFC7250] | CH, EE | 1861 | | | 1862 | server_certificate_type [RFC7250] | CH, EE | 1863 | | | 1864 | padding [RFC7685] | CH | 1865 | | | 1866 | key_share [[this document]] | CH, SH, HRR | 1867 | | | 1868 | pre_shared_key [[this document]] | CH, SH | 1869 | | | 1870 | psk_key_exchange_modes [[this document]] | CH | 1871 | | | 1872 | early_data [[this document]] | CH, EE, NST | 1873 | | | 1874 | cookie [[this document]] | CH, HRR | 1875 | | | 1876 | supported_versions [[this document]] | CH, SH, HRR | 1877 | | | 1878 | certificate_authorities [[this document]] | CH, CR | 1879 | | | 1880 | oid_filters [[this document]] | CR | 1881 | | | 1882 | post_handshake_auth [[this document]] | CH | 1883 | | | 1884 | signature_algorithms_cert [[this document]] | CH, CR | 1885 +--------------------------------------------------+-------------+ 1887 When multiple extensions of different types are present, the 1888 extensions MAY appear in any order, with the exception of 1889 "pre_shared_key" Section 4.2.11 which MUST be the last extension in 1890 the ClientHello. There MUST NOT be more than one extension of the 1891 same type in a given extension block. 1893 In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each 1894 handshake even when in resumption-PSK mode. However, 0-RTT 1895 parameters are those negotiated in the previous handshake; mismatches 1896 may require rejecting 0-RTT (see Section 4.2.10). 1898 There are subtle (and not so subtle) interactions that may occur in 1899 this protocol between new features and existing features which may 1900 result in a significant reduction in overall security. The following 1901 considerations should be taken into account when designing new 1902 extensions: 1904 - Some cases where a server does not agree to an extension are error 1905 conditions, and some are simply refusals to support particular 1906 features. In general, error alerts should be used for the former 1907 and a field in the server extension response for the latter. 1909 - Extensions should, as far as possible, be designed to prevent any 1910 attack that forces use (or non-use) of a particular feature by 1911 manipulation of handshake messages. This principle should be 1912 followed regardless of whether the feature is believed to cause a 1913 security problem. Often the fact that the extension fields are 1914 included in the inputs to the Finished message hashes will be 1915 sufficient, but extreme care is needed when the extension changes 1916 the meaning of messages sent in the handshake phase. Designers 1917 and implementors should be aware of the fact that until the 1918 handshake has been authenticated, active attackers can modify 1919 messages and insert, remove, or replace extensions. 1921 4.2.1. Supported Versions 1923 struct { 1924 select (Handshake.msg_type) { 1925 case client_hello: 1926 ProtocolVersion versions<2..254>; 1928 case server_hello: /* and HelloRetryRequest */ 1929 ProtocolVersion selected_version; 1930 }; 1931 } SupportedVersions; 1933 The "supported_versions" extension is used by the client to indicate 1934 which versions of TLS it supports and by the server to indicate which 1935 version it is using. The extension contains a list of supported 1936 versions in preference order, with the most preferred version first. 1937 Implementations of this specification MUST send this extension 1938 containing all versions of TLS which they are prepared to negotiate 1939 (for this specification, that means minimally 0x0304, but if previous 1940 versions of TLS are allowed to be negotiated, they MUST be present as 1941 well). 1943 If this extension is not present, servers which are compliant with 1944 this specification MUST negotiate TLS 1.2 or prior as specified in 1945 [RFC5246], even if ClientHello.legacy_version is 0x0304 or later. 1946 Servers MAY abort the handshake upon receiving a ClientHello with 1947 legacy_version 0x0304 or later. 1949 If this extension is present, servers MUST ignore the 1950 ClientHello.legacy_version value and MUST use only the 1951 "supported_versions" extension to determine client preferences. 1952 Servers MUST only select a version of TLS present in that extension 1953 and MUST ignore any unknown versions that are present in that 1954 extension. Note that this mechanism makes it possible to negotiate a 1955 version prior to TLS 1.2 if one side supports a sparse range. 1956 Implementations of TLS 1.3 which choose to support prior versions of 1957 TLS SHOULD support TLS 1.2. Servers should be prepared to receive 1958 ClientHellos that include this extension but do not include 0x0304 in 1959 the list of versions. 1961 A server which negotiates TLS 1.3 MUST respond by sending a 1962 "supported_versions" extension containing the selected version value 1963 (0x0304). It MUST set the ServerHello.legacy_version field to 0x0303 1964 (TLS 1.2). Clients MUST check for this extension prior to processing 1965 the rest of the ServerHello (although they will have to parse the 1966 ServerHello in order to read the extension). If this extension is 1967 present, clients MUST ignore the ServerHello.legacy_version value and 1968 MUST use only the "supported_versions" extension to determine client 1969 preferences. If the "supported_versions" extension contains a 1970 version not offered by the client, the client MUST abort the 1971 handshake with an "illegal_parameter" alert. 1973 4.2.1.1. Draft Version Indicator 1975 RFC EDITOR: PLEASE REMOVE THIS SECTION 1977 While the eventual version indicator for the RFC version of TLS 1.3 1978 will be 0x0304, implementations of draft versions of this 1979 specification SHOULD instead advertise 0x7f00 | draft_version in the 1980 ServerHello and HelloRetryRequest "supported_versions" extension. 1981 For instance, draft-17 would be encoded as the 0x7f11. This allows 1982 pre-RFC implementations to safely negotiate with each other, even if 1983 they would otherwise be incompatible. 1985 4.2.2. Cookie 1987 struct { 1988 opaque cookie<1..2^16-1>; 1989 } Cookie; 1991 Cookies serve two primary purposes: 1993 - Allowing the server to force the client to demonstrate 1994 reachability at their apparent network address (thus providing a 1995 measure of DoS protection). This is primarily useful for non- 1996 connection-oriented transports (see [RFC6347] for an example of 1997 this). 1999 - Allowing the server to offload state to the client, thus allowing 2000 it to send a HelloRetryRequest without storing any state. The 2001 server can do this by storing the hash of the ClientHello in the 2002 HelloRetryRequest cookie (protected with some suitable integrity 2003 algorithm). 2005 When sending a HelloRetryRequest, the server MAY provide a "cookie" 2006 extension to the client (this is an exception to the usual rule that 2007 the only extensions that may be sent are those that appear in the 2008 ClientHello). When sending the new ClientHello, the client MUST copy 2009 the contents of the extension received in the HelloRetryRequest into 2010 a "cookie" extension in the new ClientHello. Clients MUST NOT use 2011 cookies in their initial ClientHello in subsequent connections. 2013 When a server is operating statelessly it may receive an unprotected 2014 record of type change_cipher_spec between the first and second 2015 ClientHello (see Section 5). Since the server is not storing any 2016 state this will appear as if it were the first message to be 2017 received. Servers operating statelessly MUST ignore these records. 2019 4.2.3. Signature Algorithms 2021 TLS 1.3 provides two extensions for indicating which signature 2022 algorithms may be used in digital signatures. The 2023 "signature_algorithms_cert" extension applies to signatures in 2024 certificates and the "signature_algorithms" extension, which 2025 originally appeared in TLS 1.2, applies to signatures in 2026 CertificateVerify messages. The keys found in certificates MUST also 2027 be of appropriate type for the signature algorithms they are used 2028 with. This is a particular issue for RSA keys and PSS signatures, as 2029 described below. If no "signature_algorithms_cert" extension is 2030 present, then the "signature_algorithms" extension also applies to 2031 signatures appearing in certificates. Clients which desire the 2032 server to authenticate itself via a certificate MUST send 2033 "signature_algorithms". If a server is authenticating via a 2034 certificate and the client has not sent a "signature_algorithms" 2035 extension, then the server MUST abort the handshake with a 2036 "missing_extension" alert (see Section 9.2). 2038 The "signature_algorithms_cert" extension was added to allow 2039 implementations which supported different sets of algorithms for 2040 certificates and in TLS itself to clearly signal their capabilities. 2041 TLS 1.2 implementations SHOULD also process this extension. 2042 Implementations which have the same policy in both cases MAY omit the 2043 "signature_algorithms_cert" extension. 2045 The "extension_data" field of these extension contains a 2046 SignatureSchemeList value: 2048 enum { 2049 /* RSASSA-PKCS1-v1_5 algorithms */ 2050 rsa_pkcs1_sha256(0x0401), 2051 rsa_pkcs1_sha384(0x0501), 2052 rsa_pkcs1_sha512(0x0601), 2054 /* ECDSA algorithms */ 2055 ecdsa_secp256r1_sha256(0x0403), 2056 ecdsa_secp384r1_sha384(0x0503), 2057 ecdsa_secp521r1_sha512(0x0603), 2059 /* RSASSA-PSS algorithms with public key OID rsaEncryption */ 2060 rsa_pss_rsae_sha256(0x0804), 2061 rsa_pss_rsae_sha384(0x0805), 2062 rsa_pss_rsae_sha512(0x0806), 2064 /* EdDSA algorithms */ 2065 ed25519(0x0807), 2066 ed448(0x0808), 2068 /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */ 2069 rsa_pss_pss_sha256(0x0809), 2070 rsa_pss_pss_sha384(0x080a), 2071 rsa_pss_pss_sha512(0x080b), 2073 /* Legacy algorithms */ 2074 rsa_pkcs1_sha1(0x0201), 2075 ecdsa_sha1(0x0203), 2077 /* Reserved Code Points */ 2078 private_use(0xFE00..0xFFFF), 2079 (0xFFFF) 2080 } SignatureScheme; 2082 struct { 2083 SignatureScheme supported_signature_algorithms<2..2^16-2>; 2084 } SignatureSchemeList; 2086 Note: This enum is named "SignatureScheme" because there is already a 2087 "SignatureAlgorithm" type in TLS 1.2, which this replaces. We use 2088 the term "signature algorithm" throughout the text. 2090 Each SignatureScheme value lists a single signature algorithm that 2091 the client is willing to verify. The values are indicated in 2092 descending order of preference. Note that a signature algorithm 2093 takes as input an arbitrary-length message, rather than a digest. 2094 Algorithms which traditionally act on a digest should be defined in 2095 TLS to first hash the input with a specified hash algorithm and then 2096 proceed as usual. The code point groups listed above have the 2097 following meanings: 2099 RSASSA-PKCS1-v1_5 algorithms Indicates a signature algorithm using 2100 RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm 2101 as defined in [SHS]. These values refer solely to signatures 2102 which appear in certificates (see Section 4.4.2.2) and are not 2103 defined for use in signed TLS handshake messages, although they 2104 MAY appear in "signature_algorithms" and 2105 "signature_algorithms_cert" for backward compatibility with TLS 2106 1.2, 2108 ECDSA algorithms Indicates a signature algorithm using ECDSA 2109 [ECDSA], the corresponding curve as defined in ANSI X9.62 [X962] 2110 and FIPS 186-4 [DSS], and the corresponding hash algorithm as 2111 defined in [SHS]. The signature is represented as a DER-encoded 2112 [X690] ECDSA-Sig-Value structure. 2114 RSASSA-PSS RSAE algorithms Indicates a signature algorithm using 2115 RSASSA-PSS [RFC8017] with mask generation function 1. The digest 2116 used in the mask generation function and the digest being signed 2117 are both the corresponding hash algorithm as defined in [SHS]. 2118 The length of the salt MUST be equal to the length of the digest 2119 algorithm. If the public key is carried in an X.509 certificate, 2120 it MUST use the rsaEncryption OID [RFC5280]. 2122 EdDSA algorithms Indicates a signature algorithm using EdDSA as 2123 defined in [RFC8032] or its successors. Note that these 2124 correspond to the "PureEdDSA" algorithms and not the "prehash" 2125 variants. 2127 RSASSA-PSS PSS algorithms Indicates a signature algorithm using 2128 RSASSA-PSS [RFC8017] with mask generation function 1. The digest 2129 used in the mask generation function and the digest being signed 2130 are both the corresponding hash algorithm as defined in [SHS]. 2131 The length of the salt MUST be equal to the length of the digest 2132 algorithm. If the public key is carried in an X.509 certificate, 2133 it MUST use the RSASSA-PSS OID [RFC5756]. When used in 2134 certificate signatures, the algorithm parameters MUST be DER 2135 encoded. If the corresponding public key's parameters present, 2136 then the parameters in the signature MUST be identical to those in 2137 the public key. 2139 Legacy algorithms Indicates algorithms which are being deprecated 2140 because they use algorithms with known weaknesses, specifically 2141 SHA-1 which is used in this context with either with RSA using 2142 RSASSA-PKCS1-v1_5 or ECDSA. These values refer solely to 2143 signatures which appear in certificates (see Section 4.4.2.2) and 2144 are not defined for use in signed TLS handshake messages, even if 2145 they appear in the "signature_algorithms" list (this is necessary 2146 for backward compatibility with TLS 1.2). Endpoints SHOULD NOT 2147 negotiate these algorithms but are permitted to do so solely for 2148 backward compatibility. Clients offering these values MUST list 2149 them as the lowest priority (listed after all other algorithms in 2150 SignatureSchemeList). TLS 1.3 servers MUST NOT offer a SHA-1 2151 signed certificate unless no valid certificate chain can be 2152 produced without it (see Section 4.4.2.2). 2154 The signatures on certificates that are self-signed or certificates 2155 that are trust anchors are not validated since they begin a 2156 certification path (see [RFC5280], Section 3.2). A certificate that 2157 begins a certification path MAY use a signature algorithm that is not 2158 advertised as being supported in the "signature_algorithms" 2159 extension. 2161 Note that TLS 1.2 defines this extension differently. TLS 1.3 2162 implementations willing to negotiate TLS 1.2 MUST behave in 2163 accordance with the requirements of [RFC5246] when negotiating that 2164 version. In particular: 2166 - TLS 1.2 ClientHellos MAY omit this extension. 2168 - In TLS 1.2, the extension contained hash/signature pairs. The 2169 pairs are encoded in two octets, so SignatureScheme values have 2170 been allocated to align with TLS 1.2's encoding. Some legacy 2171 pairs are left unallocated. These algorithms are deprecated as of 2172 TLS 1.3. They MUST NOT be offered or negotiated by any 2173 implementation. In particular, MD5 [SLOTH], SHA-224, and DSA MUST 2174 NOT be used. 2176 - ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature 2177 pairs. However, the old semantics did not constrain the signing 2178 curve. If TLS 1.2 is negotiated, implementations MUST be prepared 2179 to accept a signature that uses any curve that they advertised in 2180 the "supported_groups" extension. 2182 - Implementations that advertise support for RSASSA-PSS (which is 2183 mandatory in TLS 1.3), MUST be prepared to accept a signature 2184 using that scheme even when TLS 1.2 is negotiated. In TLS 1.2, 2185 RSASSA-PSS is used with RSA cipher suites. 2187 4.2.4. Certificate Authorities 2189 The "certificate_authorities" extension is used to indicate the 2190 certificate authorities which an endpoint supports and which SHOULD 2191 be used by the receiving endpoint to guide certificate selection. 2193 The body of the "certificate_authorities" extension consists of a 2194 CertificateAuthoritiesExtension structure. 2196 opaque DistinguishedName<1..2^16-1>; 2198 struct { 2199 DistinguishedName authorities<3..2^16-1>; 2200 } CertificateAuthoritiesExtension; 2202 authorities A list of the distinguished names [X501] of acceptable 2203 certificate authorities, represented in DER-encoded [X690] format. 2204 These distinguished names specify a desired distinguished name for 2205 trust anchor or subordinate CA; thus, this message can be used to 2206 describe known trust anchors as well as a desired authorization 2207 space. 2209 The client MAY send the "certificate_authorities" extension in the 2210 ClientHello message. The server MAY send it in the 2211 CertificateRequest message. 2213 The "trusted_ca_keys" extension, which serves a similar purpose 2214 [RFC6066], but is more complicated, is not used in TLS 1.3 (although 2215 it may appear in ClientHello messages from clients which are offering 2216 prior versions of TLS). 2218 4.2.5. OID Filters 2220 The "oid_filters" extension allows servers to provide a set of OID/ 2221 value pairs which it would like the client's certificate to match. 2222 This extension, if provided by the server, MUST only be sent in the 2223 CertificateRequest message. 2225 struct { 2226 opaque certificate_extension_oid<1..2^8-1>; 2227 opaque certificate_extension_values<0..2^16-1>; 2228 } OIDFilter; 2230 struct { 2231 OIDFilter filters<0..2^16-1>; 2232 } OIDFilterExtension; 2234 filters A list of certificate extension OIDs [RFC5280] with their 2235 allowed values and represented in DER-encoded [X690] format. Some 2236 certificate extension OIDs allow multiple values (e.g., Extended 2237 Key Usage). If the server has included a non-empty filters list, 2238 the client certificate included in the response MUST contain all 2239 of the specified extension OIDs that the client recognizes. For 2240 each extension OID recognized by the client, all of the specified 2241 values MUST be present in the client certificate (but the 2242 certificate MAY have other values as well). However, the client 2243 MUST ignore and skip any unrecognized certificate extension OIDs. 2244 If the client ignored some of the required certificate extension 2245 OIDs and supplied a certificate that does not satisfy the request, 2246 the server MAY at its discretion either continue the connection 2247 without client authentication, or abort the handshake with an 2248 "unsupported_certificate" alert. 2250 PKIX RFCs define a variety of certificate extension OIDs and their 2251 corresponding value types. Depending on the type, matching 2252 certificate extension values are not necessarily bitwise-equal. It 2253 is expected that TLS implementations will rely on their PKI libraries 2254 to perform certificate selection using certificate extension OIDs. 2256 This document defines matching rules for two standard certificate 2257 extensions defined in [RFC5280]: 2259 - The Key Usage extension in a certificate matches the request when 2260 all key usage bits asserted in the request are also asserted in 2261 the Key Usage certificate extension. 2263 - The Extended Key Usage extension in a certificate matches the 2264 request when all key purpose OIDs present in the request are also 2265 found in the Extended Key Usage certificate extension. The 2266 special anyExtendedKeyUsage OID MUST NOT be used in the request. 2268 Separate specifications may define matching rules for other 2269 certificate extensions. 2271 4.2.6. Post-Handshake Client Authentication 2273 The "post_handshake_auth" extension is used to indicate that a client 2274 is willing to perform post-handshake authentication Section 4.6.2. 2275 Servers MUST NOT send a post-handshake CertificateRequest to clients 2276 which do not offer this extension. Servers MUST NOT send this 2277 extension. 2279 struct {} PostHandshakeAuth; 2281 The "extension_data" field of the "post_handshake_auth" extension is 2282 zero length. 2284 4.2.7. Negotiated Groups 2286 When sent by the client, the "supported_groups" extension indicates 2287 the named groups which the client supports for key exchange, ordered 2288 from most preferred to least preferred. 2290 Note: In versions of TLS prior to TLS 1.3, this extension was named 2291 "elliptic_curves" and only contained elliptic curve groups. See 2292 [RFC4492] and [RFC7919]. This extension was also used to negotiate 2293 ECDSA curves. Signature algorithms are now negotiated independently 2294 (see Section 4.2.3). 2296 The "extension_data" field of this extension contains a 2297 "NamedGroupList" value: 2299 enum { 2301 /* Elliptic Curve Groups (ECDHE) */ 2302 secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), 2303 x25519(0x001D), x448(0x001E), 2305 /* Finite Field Groups (DHE) */ 2306 ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), 2307 ffdhe6144(0x0103), ffdhe8192(0x0104), 2309 /* Reserved Code Points */ 2310 ffdhe_private_use(0x01FC..0x01FF), 2311 ecdhe_private_use(0xFE00..0xFEFF), 2312 (0xFFFF) 2313 } NamedGroup; 2315 struct { 2316 NamedGroup named_group_list<2..2^16-1>; 2317 } NamedGroupList; 2319 Elliptic Curve Groups (ECDHE) Indicates support for the 2320 corresponding named curve, defined either in FIPS 186-4 [DSS] or 2321 in [RFC7748]. Values 0xFE00 through 0xFEFF are reserved for 2322 private use. 2324 Finite Field Groups (DHE) Indicates support of the corresponding 2325 finite field group, defined in [RFC7919]. Values 0x01FC through 2326 0x01FF are reserved for private use. 2328 Items in named_group_list are ordered according to the client's 2329 preferences (most preferred choice first). 2331 As of TLS 1.3, servers are permitted to send the "supported_groups" 2332 extension to the client. Clients MUST NOT act upon any information 2333 found in "supported_groups" prior to successful completion of the 2334 handshake but MAY use the information learned from a successfully 2335 completed handshake to change what groups they use in their 2336 "key_share" extension in subsequent connections. If the server has a 2337 group it prefers to the ones in the "key_share" extension but is 2338 still willing to accept the ClientHello, it SHOULD send 2339 "supported_groups" to update the client's view of its preferences; 2340 this extension SHOULD contain all groups the server supports, 2341 regardless of whether they are currently supported by the client. 2343 4.2.8. Key Share 2345 The "key_share" extension contains the endpoint's cryptographic 2346 parameters. 2348 Clients MAY send an empty client_shares vector in order to request 2349 group selection from the server at the cost of an additional round 2350 trip. (see Section 4.1.4) 2352 struct { 2353 NamedGroup group; 2354 opaque key_exchange<1..2^16-1>; 2355 } KeyShareEntry; 2357 group The named group for the key being exchanged. Finite Field 2358 Diffie-Hellman [DH] parameters are described in Section 4.2.8.1; 2359 Elliptic Curve Diffie-Hellman parameters are described in 2360 Section 4.2.8.2. 2362 key_exchange Key exchange information. The contents of this field 2363 are determined by the specified group and its corresponding 2364 definition. 2366 In the ClientHello message, the "extension_data" field of this 2367 extension contains a "KeyShareClientHello" value: 2369 struct { 2370 KeyShareEntry client_shares<0..2^16-1>; 2371 } KeyShareClientHello; 2373 client_shares A list of offered KeyShareEntry values in descending 2374 order of client preference. 2376 This vector MAY be empty if the client is requesting a 2377 HelloRetryRequest. Each KeyShareEntry value MUST correspond to a 2378 group offered in the "supported_groups" extension and MUST appear in 2379 the same order. However, the values MAY be a non-contiguous subset 2380 of the "supported_groups" extension and MAY omit the most preferred 2381 groups. Such a situation could arise if the most preferred groups 2382 are new and unlikely to be supported in enough places to make 2383 pregenerating key shares for them efficient. 2385 Clients can offer an arbitrary number of KeyShareEntry values, each 2386 representing a single set of key exchange parameters. For instance, 2387 a client might offer shares for several elliptic curves or multiple 2388 FFDHE groups. The key_exchange values for each KeyShareEntry MUST be 2389 generated independently. Clients MUST NOT offer multiple 2390 KeyShareEntry values for the same group. Clients MUST NOT offer any 2391 KeyShareEntry values for groups not listed in the client's 2392 "supported_groups" extension. Servers MAY check for violations of 2393 these rules and abort the handshake with an "illegal_parameter" alert 2394 if one is violated. 2396 In a HelloRetryRequest message, the "extension_data" field of this 2397 extension contains a KeyShareHelloRetryRequest value: 2399 struct { 2400 NamedGroup selected_group; 2401 } KeyShareHelloRetryRequest; 2403 selected_group The mutually supported group the server intends to 2404 negotiate and is requesting a retried ClientHello/KeyShare for. 2406 Upon receipt of this extension in a HelloRetryRequest, the client 2407 MUST verify that (1) the selected_group field corresponds to a group 2408 which was provided in the "supported_groups" extension in the 2409 original ClientHello; and (2) the selected_group field does not 2410 correspond to a group which was provided in the "key_share" extension 2411 in the original ClientHello. If either of these checks fails, then 2412 the client MUST abort the handshake with an "illegal_parameter" 2413 alert. Otherwise, when sending the new ClientHello, the client MUST 2414 replace the original "key_share" extension with one containing only a 2415 new KeyShareEntry for the group indicated in the selected_group field 2416 of the triggering HelloRetryRequest. 2418 In a ServerHello message, the "extension_data" field of this 2419 extension contains a KeyShareServerHello value: 2421 struct { 2422 KeyShareEntry server_share; 2423 } KeyShareServerHello; 2425 server_share A single KeyShareEntry value that is in the same group 2426 as one of the client's shares. 2428 If using (EC)DHE key establishment, servers offer exactly one 2429 KeyShareEntry in the ServerHello. This value MUST be in the same 2430 group as the KeyShareEntry value offered by the client that the 2431 server has selected for the negotiated key exchange. Servers MUST 2432 NOT send a KeyShareEntry for any group not indicated in the 2433 "supported_groups" extension and MUST NOT send a KeyShareEntry when 2434 using the "psk_ke" PskKeyExchangeMode. If a HelloRetryRequest was 2435 received by the client, the client MUST verify that the selected 2436 NamedGroup in the ServerHello is the same as that in the 2437 HelloRetryRequest. If this check fails, the client MUST abort the 2438 handshake with an "illegal_parameter" alert. 2440 4.2.8.1. Diffie-Hellman Parameters 2442 Diffie-Hellman [DH] parameters for both clients and servers are 2443 encoded in the opaque key_exchange field of a KeyShareEntry in a 2444 KeyShare structure. The opaque value contains the Diffie-Hellman 2445 public value (Y = g^X mod p) for the specified group (see [RFC7919] 2446 for group definitions) encoded as a big-endian integer and padded to 2447 the left with zeros to the size of p in bytes. 2449 Note: For a given Diffie-Hellman group, the padding results in all 2450 public keys having the same length. 2452 Peers MUST validate each other's public key Y by ensuring that 1 < Y 2453 < p-1. This check ensures that the remote peer is properly behaved 2454 and isn't forcing the local system into a small subgroup. 2456 4.2.8.2. ECDHE Parameters 2458 ECDHE parameters for both clients and servers are encoded in the the 2459 opaque key_exchange field of a KeyShareEntry in a KeyShare structure. 2461 For secp256r1, secp384r1 and secp521r1, the contents are the 2462 serialized value of the following struct: 2464 struct { 2465 uint8 legacy_form = 4; 2466 opaque X[coordinate_length]; 2467 opaque Y[coordinate_length]; 2468 } UncompressedPointRepresentation; 2470 X and Y respectively are the binary representations of the X and Y 2471 values in network byte order. There are no internal length markers, 2472 so each number representation occupies as many octets as implied by 2473 the curve parameters. For P-256 this means that each of X and Y use 2474 32 octets, padded on the left by zeros if necessary. For P-384 they 2475 take 48 octets each, and for P-521 they take 66 octets each. 2477 For the curves secp256r1, secp384r1 and secp521r1, peers MUST 2478 validate each other's public value Y by ensuring that the point is a 2479 valid point on the elliptic curve. The appropriate validation 2480 procedures are defined in Section 4.3.7 of [X962] and alternatively 2481 in Section 5.6.2.3 of [KEYAGREEMENT]. This process consists of three 2482 steps: (1) verify that Y is not the point at infinity (O), (2) verify 2483 that for Y = (x, y) both integers are in the correct interval, (3) 2484 ensure that (x, y) is a correct solution to the elliptic curve 2485 equation. For these curves, implementers do not need to verify 2486 membership in the correct subgroup. 2488 For X25519 and X448, the contents of the public value are the byte 2489 string inputs and outputs of the corresponding functions defined in 2490 [RFC7748], 32 bytes for X25519 and 56 bytes for X448. 2492 Note: Versions of TLS prior to 1.3 permitted point format 2493 negotiation; TLS 1.3 removes this feature in favor of a single point 2494 format for each curve. 2496 4.2.9. Pre-Shared Key Exchange Modes 2498 In order to use PSKs, clients MUST also send a 2499 "psk_key_exchange_modes" extension. The semantics of this extension 2500 are that the client only supports the use of PSKs with these modes, 2501 which restricts both the use of PSKs offered in this ClientHello and 2502 those which the server might supply via NewSessionTicket. 2504 A client MUST provide a "psk_key_exchange_modes" extension if it 2505 offers a "pre_shared_key" extension. If clients offer 2506 "pre_shared_key" without a "psk_key_exchange_modes" extension, 2507 servers MUST abort the handshake. Servers MUST NOT select a key 2508 exchange mode that is not listed by the client. This extension also 2509 restricts the modes for use with PSK resumption; servers SHOULD NOT 2510 send NewSessionTicket with tickets that are not compatible with the 2511 advertised modes; however, if a server does so, the impact will just 2512 be that the client's attempts at resumption fail. 2514 The server MUST NOT send a "psk_key_exchange_modes" extension. 2516 enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; 2518 struct { 2519 PskKeyExchangeMode ke_modes<1..255>; 2520 } PskKeyExchangeModes; 2522 psk_ke PSK-only key establishment. In this mode, the server MUST 2523 NOT supply a "key_share" value. 2525 psk_dhe_ke PSK with (EC)DHE key establishment. In this mode, the 2526 client and servers MUST supply "key_share" values as described in 2527 Section 4.2.8. 2529 4.2.10. Early Data Indication 2531 When a PSK is used, the client can send application data in its first 2532 flight of messages. If the client opts to do so, it MUST supply both 2533 the "early_data" extension as well as the "pre_shared_key" extension. 2535 The "extension_data" field of this extension contains an 2536 "EarlyDataIndication" value. 2538 struct {} Empty; 2540 struct { 2541 select (Handshake.msg_type) { 2542 case new_session_ticket: uint32 max_early_data_size; 2543 case client_hello: Empty; 2544 case encrypted_extensions: Empty; 2545 }; 2546 } EarlyDataIndication; 2548 See Section 4.6.1 for the use of the max_early_data_size field. 2550 The parameters for the 0-RTT data (version, symmetric cipher suite, 2551 ALPN protocol, etc.) are those associated with the PSK in use. For 2552 externally established PSKs, the associated values are those 2553 provisioned along with the key. For PSKs established via a 2554 NewSessionTicket message, the associated values are those which were 2555 negotiated in the connection which established the PSK. The PSK used 2556 to encrypt the early data MUST be the first PSK listed in the 2557 client's "pre_shared_key" extension. 2559 For PSKs provisioned via NewSessionTicket, a server MUST validate 2560 that the ticket age for the selected PSK identity (computed by 2561 subtracting ticket_age_add from PskIdentity.obfuscated_ticket_age 2562 modulo 2^32) is within a small tolerance of the time since the ticket 2563 was issued (see Section 8). If it is not, the server SHOULD proceed 2564 with the handshake but reject 0-RTT, and SHOULD NOT take any other 2565 action that assumes that this ClientHello is fresh. 2567 0-RTT messages sent in the first flight have the same (encrypted) 2568 content types as their corresponding messages sent in other flights 2569 (handshake and application_data) but are protected under different 2570 keys. After receiving the server's Finished message, if the server 2571 has accepted early data, an EndOfEarlyData message will be sent to 2572 indicate the key change. This message will be encrypted with the 2573 0-RTT traffic keys. 2575 A server which receives an "early_data" extension MUST behave in one 2576 of three ways: 2578 - Ignore the extension and return a regular 1-RTT response. The 2579 server then ignores early data by attempting to decrypt received 2580 records in the handshake traffic keys until it is able to receive 2581 the client's second flight and complete an ordinary 1-RTT 2582 handshake, skipping records that fail to decrypt, up to the 2583 configured max_early_data_size. 2585 - Request that the client send another ClientHello by responding 2586 with a HelloRetryRequest. A client MUST NOT include the 2587 "early_data" extension in its followup ClientHello. The server 2588 then ignores early data by skipping all records with external 2589 content type of "application_data" (indicating that they are 2590 encrypted). 2592 - Return its own extension in EncryptedExtensions, indicating that 2593 it intends to process the early data. It is not possible for the 2594 server to accept only a subset of the early data messages. Even 2595 though the server sends a message accepting early data, the actual 2596 early data itself may already be in flight by the time the server 2597 generates this message. 2599 In order to accept early data, the server MUST have accepted a PSK 2600 cipher suite and selected the first key offered in the client's 2601 "pre_shared_key" extension. In addition, it MUST verify that the 2602 following values are consistent with those associated with the 2603 selected PSK: 2605 - The TLS version number 2607 - The selected cipher suite 2609 - The selected ALPN [RFC7301] protocol, if any 2611 These requirements are a superset of those needed to perform a 1-RTT 2612 handshake using the PSK in question. For externally established 2613 PSKs, the associated values are those provisioned along with the key. 2614 For PSKs established via a NewSessionTicket message, the associated 2615 values are those negotiated in the connection during which the ticket 2616 was established. 2618 Future extensions MUST define their interaction with 0-RTT. 2620 If any of these checks fail, the server MUST NOT respond with the 2621 extension and must discard all the first flight data using one of the 2622 first two mechanisms listed above (thus falling back to 1-RTT or 2623 2-RTT). If the client attempts a 0-RTT handshake but the server 2624 rejects it, the server will generally not have the 0-RTT record 2625 protection keys and must instead use trial decryption (either with 2626 the 1-RTT handshake keys or by looking for a cleartext ClientHello in 2627 the case of HelloRetryRequest) to find the first non-0-RTT message. 2629 If the server chooses to accept the "early_data" extension, then it 2630 MUST comply with the same error handling requirements specified for 2631 all records when processing early data records. Specifically, if the 2632 server fails to decrypt any 0-RTT record following an accepted 2633 "early_data" extension it MUST terminate the connection with a 2634 "bad_record_mac" alert as per Section 5.2. 2636 If the server rejects the "early_data" extension, the client 2637 application MAY opt to retransmit early data once the handshake has 2638 been completed. Note that automatic re-transmission of early data 2639 could result in assumptions about the status of the connection being 2640 incorrect. For instance, when the negotiated connection selects a 2641 different ALPN protocol from what was used for the early data, an 2642 application might need to construct different messages. Similarly, 2643 if early data assumes anything about the connection state, it might 2644 be sent in error after the handshake completes. 2646 A TLS implementation SHOULD NOT automatically re-send early data; 2647 applications are in a better position to decide when re-transmission 2648 is appropriate. A TLS implementation MUST NOT automatically re-send 2649 early data unless the negotiated connection selects the same ALPN 2650 protocol. 2652 4.2.11. Pre-Shared Key Extension 2654 The "pre_shared_key" extension is used to indicate the identity of 2655 the pre-shared key to be used with a given handshake in association 2656 with PSK key establishment. 2658 The "extension_data" field of this extension contains a 2659 "PreSharedKeyExtension" value: 2661 struct { 2662 opaque identity<1..2^16-1>; 2663 uint32 obfuscated_ticket_age; 2664 } PskIdentity; 2666 opaque PskBinderEntry<32..255>; 2668 struct { 2669 PskIdentity identities<7..2^16-1>; 2670 PskBinderEntry binders<33..2^16-1>; 2671 } OfferedPsks; 2673 struct { 2674 select (Handshake.msg_type) { 2675 case client_hello: OfferedPsks; 2676 case server_hello: uint16 selected_identity; 2677 }; 2678 } PreSharedKeyExtension; 2680 identity A label for a key. For instance, a ticket defined in 2681 Appendix B.3.4 or a label for a pre-shared key established 2682 externally. 2684 obfuscated_ticket_age An obfuscated version of the age of the key. 2685 Section 4.2.11.1 describes how to form this value for identities 2686 established via the NewSessionTicket message. For identities 2687 established externally an obfuscated_ticket_age of 0 SHOULD be 2688 used, and servers MUST ignore the value. 2690 identities A list of the identities that the client is willing to 2691 negotiate with the server. If sent alongside the "early_data" 2692 extension (see Section 4.2.10), the first identity is the one used 2693 for 0-RTT data. 2695 binders A series of HMAC values, one for each PSK offered in the 2696 "pre_shared_keys" extension and in the same order, computed as 2697 described below. 2699 selected_identity The server's chosen identity expressed as a 2700 (0-based) index into the identities in the client's list. 2702 Each PSK is associated with a single Hash algorithm. For PSKs 2703 established via the ticket mechanism (Section 4.6.1), this is the KDF 2704 Hash algorithm on the connection where the ticket was established. 2705 For externally established PSKs, the Hash algorithm MUST be set when 2706 the PSK is established, or default to SHA-256 if no such algorithm is 2707 defined. The server MUST ensure that it selects a compatible PSK (if 2708 any) and cipher suite. 2710 In TLS versions prior to TLS 1.3, the Server Name Identification 2711 (SNI) value was intended to be associated with the session (Section 3 2712 of [RFC6066]), with the server being required to enforce that the SNI 2713 value associated with the session matches the one specified in the 2714 resumption handshake. However, in reality the implementations were 2715 not consistent on which of two supplied SNI values they would use, 2716 leading to the consistency requirement being de-facto enforced by the 2717 clients. In TLS 1.3, the SNI value is always explicitly specified in 2718 the resumption handshake, and there is no need for the server to 2719 associate an SNI value with the ticket. Clients, however, SHOULD 2720 store the SNI with the PSK to fulfill the requirements of 2721 Section 4.6.1. 2723 Implementor's note: the most straightforward way to implement the 2724 PSK/cipher suite matching requirements is to negotiate the cipher 2725 suite first and then exclude any incompatible PSKs. Any unknown PSKs 2726 (e.g., they are not in the PSK database or are encrypted with an 2727 unknown key) SHOULD simply be ignored. If no acceptable PSKs are 2728 found, the server SHOULD perform a non-PSK handshake if possible. 2730 Prior to accepting PSK key establishment, the server MUST validate 2731 the corresponding binder value (see Section 4.2.11.2 below). If this 2732 value is not present or does not validate, the server MUST abort the 2733 handshake. Servers SHOULD NOT attempt to validate multiple binders; 2734 rather they SHOULD select a single PSK and validate solely the binder 2735 that corresponds to that PSK. In order to accept PSK key 2736 establishment, the server sends a "pre_shared_key" extension 2737 indicating the selected identity. 2739 Clients MUST verify that the server's selected_identity is within the 2740 range supplied by the client, that the server selected a cipher suite 2741 indicating a Hash associated with the PSK and that a server 2742 "key_share" extension is present if required by the ClientHello 2743 "psk_key_exchange_modes". If these values are not consistent the 2744 client MUST abort the handshake with an "illegal_parameter" alert. 2746 If the server supplies an "early_data" extension, the client MUST 2747 verify that the server's selected_identity is 0. If any other value 2748 is returned, the client MUST abort the handshake with an 2749 "illegal_parameter" alert. 2751 This extension MUST be the last extension in the ClientHello (this 2752 facilitates implementation as described below). Servers MUST check 2753 that it is the last extension and otherwise fail the handshake with 2754 an "illegal_parameter" alert. 2756 4.2.11.1. Ticket Age 2758 The client's view of the age of a ticket is the time since the 2759 receipt of the NewSessionTicket message. Clients MUST NOT attempt to 2760 use tickets which have ages greater than the "ticket_lifetime" value 2761 which was provided with the ticket. The "obfuscated_ticket_age" 2762 field of each PskIdentity contains an obfuscated version of the 2763 ticket age formed by taking the age in milliseconds and adding the 2764 "ticket_age_add" value that was included with the ticket, see 2765 Section 4.6.1 modulo 2^32. This addition prevents passive observers 2766 from correlating connections unless tickets are reused. Note that 2767 the "ticket_lifetime" field in the NewSessionTicket message is in 2768 seconds but the "obfuscated_ticket_age" is in milliseconds. Because 2769 ticket lifetimes are restricted to a week, 32 bits is enough to 2770 represent any plausible age, even in milliseconds. 2772 4.2.11.2. PSK Binder 2774 The PSK binder value forms a binding between a PSK and the current 2775 handshake, as well as between the handshake in which the PSK was 2776 generated (if via a NewSessionTicket message) and the handshake where 2777 it was used. Each entry in the binders list is computed as an HMAC 2778 over a transcript hash (see Section 4.4.1) containing a partial 2779 ClientHello up to and including the PreSharedKeyExtension.identities 2780 field. That is, it includes all of the ClientHello but not the 2781 binders list itself. The length fields for the message (including 2782 the overall length, the length of the extensions block, and the 2783 length of the "pre_shared_key" extension) are all set as if binders 2784 of the correct lengths were present. 2786 The PskBinderEntry is computed in the same way as the Finished 2787 message (Section 4.4.4) but with the BaseKey being the binder_key 2788 derived via the key schedule from the corresponding PSK which is 2789 being offered (see Section 7.1). 2791 If the handshake includes a HelloRetryRequest, the initial 2792 ClientHello and HelloRetryRequest are included in the transcript 2793 along with the new ClientHello. For instance, if the client sends 2794 ClientHello1, its binder will be computed over: 2796 Transcript-Hash(Truncate(ClientHello1)) 2798 Where Truncate() removes the binders list from the ClientHello. 2800 If the server responds with HelloRetryRequest, and the client then 2801 sends ClientHello2, its binder will be computed over: 2803 Transcript-Hash(ClientHello1, 2804 HelloRetryRequest, 2805 Truncate(ClientHello2)) 2807 The full ClientHello1/ClientHello2 is included in all other handshake 2808 hash computations. Note that in the first flight, 2809 Truncate(ClientHello1) is hashed directly, but in the second flight, 2810 ClientHello1 is hashed and then reinjected as a "message_hash" 2811 message, as described in Section 4.4.1. 2813 4.2.11.3. Processing Order 2815 Clients are permitted to "stream" 0-RTT data until they receive the 2816 server's Finished, only then sending the EndOfEarlyData message, 2817 followed by the rest of the handshake. In order to avoid deadlocks, 2818 when accepting "early_data", servers MUST process the client's 2819 ClientHello and then immediately send the ServerHello, rather than 2820 waiting for the client's EndOfEarlyData message. 2822 4.3. Server Parameters 2824 The next two messages from the server, EncryptedExtensions and 2825 CertificateRequest, contain information from the server that 2826 determines the rest of the handshake. These messages are encrypted 2827 with keys derived from the server_handshake_traffic_secret. 2829 4.3.1. Encrypted Extensions 2831 In all handshakes, the server MUST send the EncryptedExtensions 2832 message immediately after the ServerHello message. This is the first 2833 message that is encrypted under keys derived from the 2834 server_handshake_traffic_secret. 2836 The EncryptedExtensions message contains extensions that can be 2837 protected, i.e., any which are not needed to establish the 2838 cryptographic context, but which are not associated with individual 2839 certificates. The client MUST check EncryptedExtensions for the 2840 presence of any forbidden extensions and if any are found MUST abort 2841 the handshake with an "illegal_parameter" alert. 2843 Structure of this message: 2845 struct { 2846 Extension extensions<0..2^16-1>; 2847 } EncryptedExtensions; 2849 extensions A list of extensions. For more information, see the 2850 table in Section 4.2. 2852 4.3.2. Certificate Request 2854 A server which is authenticating with a certificate MAY optionally 2855 request a certificate from the client. This message, if sent, MUST 2856 follow EncryptedExtensions. 2858 Structure of this message: 2860 struct { 2861 opaque certificate_request_context<0..2^8-1>; 2862 Extension extensions<2..2^16-1>; 2863 } CertificateRequest; 2865 certificate_request_context An opaque string which identifies the 2866 certificate request and which will be echoed in the client's 2867 Certificate message. The certificate_request_context MUST be 2868 unique within the scope of this connection (thus preventing replay 2869 of client CertificateVerify messages). This field SHALL be zero 2870 length unless used for the post-handshake authentication exchanges 2871 described in Section 4.6.2. When requesting post-handshake 2872 authentication, the server SHOULD make the context unpredictable 2873 to the client (e.g., by randomly generating it) in order to 2874 prevent an attacker who has temporary access to the client's 2875 private key from pre-computing valid CertificateVerify messages. 2877 extensions A set of extensions describing the parameters of the 2878 certificate being requested. The "signature_algorithms" extension 2879 MUST be specified, and other extensions may optionally be included 2880 if defined for this message. Clients MUST ignore unrecognized 2881 extensions. 2883 In prior versions of TLS, the CertificateRequest message carried a 2884 list of signature algorithms and certificate authorities which the 2885 server would accept. In TLS 1.3 the former is expressed by sending 2886 the "signature_algorithms" and "signature_algorithms_cert" 2887 extensions. The latter is expressed by sending the 2888 "certificate_authorities" extension (see Section 4.2.4). 2890 Servers which are authenticating with a PSK MUST NOT send the 2891 CertificateRequest message in the main handshake, though they MAY 2892 send it in post-handshake authentication (see Section 4.6.2) provided 2893 that the client has sent the "post_handshake_auth" extension (see 2894 Section 4.2.6). 2896 4.4. Authentication Messages 2898 As discussed in Section 2, TLS generally uses a common set of 2899 messages for authentication, key confirmation, and handshake 2900 integrity: Certificate, CertificateVerify, and Finished. (The 2901 PreSharedKey binders also perform key confirmation, in a similar 2902 fashion.) These three messages are always sent as the last messages 2903 in their handshake flight. The Certificate and CertificateVerify 2904 messages are only sent under certain circumstances, as defined below. 2905 The Finished message is always sent as part of the Authentication 2906 block. These messages are encrypted under keys derived from 2907 [sender]_handshake_traffic_secret. 2909 The computations for the Authentication messages all uniformly take 2910 the following inputs: 2912 - The certificate and signing key to be used. 2914 - A Handshake Context consisting of the set of messages to be 2915 included in the transcript hash. 2917 - A base key to be used to compute a MAC key. 2919 Based on these inputs, the messages then contain: 2921 Certificate The certificate to be used for authentication, and any 2922 supporting certificates in the chain. Note that certificate-based 2923 client authentication is not available in 0-RTT mode. 2925 CertificateVerify A signature over the value Transcript- 2926 Hash(Handshake Context, Certificate) 2928 Finished A MAC over the value Transcript-Hash(Handshake Context, 2929 Certificate, CertificateVerify) using a MAC key derived from the 2930 base key. 2932 The following table defines the Handshake Context and MAC Base Key 2933 for each scenario: 2935 +-----------+----------------------------+--------------------------+ 2936 | Mode | Handshake Context | Base Key | 2937 +-----------+----------------------------+--------------------------+ 2938 | Server | ClientHello ... later of E | server_handshake_traffic | 2939 | | ncryptedExtensions/Certifi | _secret | 2940 | | cateRequest | | 2941 | | | | 2942 | Client | ClientHello ... later of | client_handshake_traffic | 2943 | | server | _secret | 2944 | | Finished/EndOfEarlyData | | 2945 | | | | 2946 | Post- | ClientHello ... client | client_application_traff | 2947 | Handshake | Finished + | ic_secret_N | 2948 | | CertificateRequest | | 2949 +-----------+----------------------------+--------------------------+ 2951 4.4.1. The Transcript Hash 2953 Many of the cryptographic computations in TLS make use of a 2954 transcript hash. This value is computed by hashing the concatenation 2955 of each included handshake message, including the handshake message 2956 header carrying the handshake message type and length fields, but not 2957 including record layer headers. I.e., 2959 Transcript-Hash(M1, M2, ... MN) = Hash(M1 || M2 ... MN) 2961 As an exception to this general rule, when the server responds to a 2962 ClientHello with a HelloRetryRequest, the value of ClientHello1 is 2963 replaced with a special synthetic handshake message of handshake type 2964 "message_hash" containing Hash(ClientHello1). I.e., 2966 Transcript-Hash(ClientHello1, HelloRetryRequest, ... MN) = 2967 Hash(message_hash || /* Handshake type */ 2968 00 00 Hash.length || /* Handshake message length (bytes) */ 2969 Hash(ClientHello1) || /* Hash of ClientHello1 */ 2970 HelloRetryRequest ... MN) 2972 The reason for this construction is to allow the server to do a 2973 stateless HelloRetryRequest by storing just the hash of ClientHello1 2974 in the cookie, rather than requiring it to export the entire 2975 intermediate hash state (see Section 4.2.2). 2977 For concreteness, the transcript hash is always taken from the 2978 following sequence of handshake messages, starting at the first 2979 ClientHello and including only those messages that were sent: 2980 ClientHello, HelloRetryRequest, ClientHello, ServerHello, 2981 EncryptedExtensions, server CertificateRequest, server Certificate, 2982 server CertificateVerify, server Finished, EndOfEarlyData, client 2983 Certificate, client CertificateVerify, client Finished. 2985 In general, implementations can implement the transcript by keeping a 2986 running transcript hash value based on the negotiated hash. Note, 2987 however, that subsequent post-handshake authentications do not 2988 include each other, just the messages through the end of the main 2989 handshake. 2991 4.4.2. Certificate 2993 This message conveys the endpoint's certificate chain to the peer. 2995 The server MUST send a Certificate message whenever the agreed-upon 2996 key exchange method uses certificates for authentication (this 2997 includes all key exchange methods defined in this document except 2998 PSK). 3000 The client MUST send a Certificate message if and only if the server 3001 has requested client authentication via a CertificateRequest message 3002 (Section 4.3.2). If the server requests client authentication but no 3003 suitable certificate is available, the client MUST send a Certificate 3004 message containing no certificates (i.e., with the "certificate_list" 3005 field having length 0). 3007 Structure of this message: 3009 enum { 3010 X509(0), 3011 RawPublicKey(2), 3012 (255) 3013 } CertificateType; 3015 struct { 3016 select (certificate_type) { 3017 case RawPublicKey: 3018 /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ 3019 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 3021 case X509: 3022 opaque cert_data<1..2^24-1>; 3023 }; 3024 Extension extensions<0..2^16-1>; 3025 } CertificateEntry; 3027 struct { 3028 opaque certificate_request_context<0..2^8-1>; 3029 CertificateEntry certificate_list<0..2^24-1>; 3030 } Certificate; 3032 certificate_request_context If this message is in response to a 3033 CertificateRequest, the value of certificate_request_context in 3034 that message. Otherwise (in the case of server authentication), 3035 this field SHALL be zero length. 3037 certificate_list This is a sequence (chain) of CertificateEntry 3038 structures, each containing a single certificate and set of 3039 extensions. 3041 extensions: A set of extension values for the CertificateEntry. The 3042 "Extension" format is defined in Section 4.2. Valid extensions 3043 for server certificates include OCSP Status extension ([RFC6066]) 3044 and SignedCertificateTimestamps ([RFC6962]). Extensions in the 3045 Certificate message from the server MUST correspond to one from 3046 the ClientHello message. Extensions in the Certificate from the 3047 client MUST correspond with an extension in the CertificateRequest 3048 message from the server. If an extension applies to the entire 3049 chain, it SHOULD be included in the first CertificateEntry. 3051 If the corresponding certificate type extension 3052 ("server_certificate_type" or "client_certificate_type") was not 3053 negotiated in Encrypted Extensions, or the X.509 certificate type was 3054 negotiated, then each CertificateEntry contains a DER-encoded X.509 3055 certificate. The sender's certificate MUST come in the first 3056 CertificateEntry in the list. Each following certificate SHOULD 3057 directly certify one preceding it. Because certificate validation 3058 requires that trust anchors be distributed independently, a 3059 certificate that specifies a trust anchor MAY be omitted from the 3060 chain, provided that supported peers are known to possess any omitted 3061 certificates. 3063 Note: Prior to TLS 1.3, "certificate_list" ordering required each 3064 certificate to certify the one immediately preceding it; however, 3065 some implementations allowed some flexibility. Servers sometimes 3066 send both a current and deprecated intermediate for transitional 3067 purposes, and others are simply configured incorrectly, but these 3068 cases can nonetheless be validated properly. For maximum 3069 compatibility, all implementations SHOULD be prepared to handle 3070 potentially extraneous certificates and arbitrary orderings from any 3071 TLS version, with the exception of the end-entity certificate which 3072 MUST be first. 3074 If the RawPublicKey certificate type was negotiated, then the 3075 certificate_list MUST contain no more than one CertificateEntry, 3076 which contains an ASN1_subjectPublicKeyInfo value as defined in 3077 [RFC7250], Section 3. 3079 The OpenPGP certificate type [RFC6091] MUST NOT be used with TLS 1.3. 3081 The server's certificate_list MUST always be non-empty. A client 3082 will send an empty certificate_list if it does not have an 3083 appropriate certificate to send in response to the server's 3084 authentication request. 3086 4.4.2.1. OCSP Status and SCT Extensions 3088 [RFC6066] and [RFC6961] provide extensions to negotiate the server 3089 sending OCSP responses to the client. In TLS 1.2 and below, the 3090 server replies with an empty extension to indicate negotiation of 3091 this extension and the OCSP information is carried in a 3092 CertificateStatus message. In TLS 1.3, the server's OCSP information 3093 is carried in an extension in the CertificateEntry containing the 3094 associated certificate. Specifically: The body of the 3095 "status_request" extension from the server MUST be a 3096 CertificateStatus structure as defined in [RFC6066], which is 3097 interpreted as defined in [RFC6960]. 3099 Note: status_request_v2 extension ([RFC6961]) is deprecated. TLS 1.3 3100 servers MUST NOT act upon its presence or information in it when 3101 processing Client Hello, in particular they MUST NOT send the 3102 status_request_v2 extension in the Encrypted Extensions, Certificate 3103 Request or the Certificate messages. TLS 1.3 servers MUST be able to 3104 process Client Hello messages that include it, as it MAY be sent by 3105 clients that wish to use it in earlier protocol versions. 3107 A server MAY request that a client present an OCSP response with its 3108 certificate by sending an empty "status_request" extension in its 3109 CertificateRequest message. If the client opts to send an OCSP 3110 response, the body of its "status_request" extension MUST be a 3111 CertificateStatus structure as defined in [RFC6066]. 3113 Similarly, [RFC6962] provides a mechanism for a server to send a 3114 Signed Certificate Timestamp (SCT) as an extension in the ServerHello 3115 in TLS 1.2 and below. In TLS 1.3, the server's SCT information is 3116 carried in an extension in CertificateEntry. 3118 4.4.2.2. Server Certificate Selection 3120 The following rules apply to the certificates sent by the server: 3122 - The certificate type MUST be X.509v3 [RFC5280], unless explicitly 3123 negotiated otherwise (e.g., [RFC7250]). 3125 - The server's end-entity certificate's public key (and associated 3126 restrictions) MUST be compatible with the selected authentication 3127 algorithm (currently RSA, ECDSA, or EdDSA). 3129 - The certificate MUST allow the key to be used for signing (i.e., 3130 the digitalSignature bit MUST be set if the Key Usage extension is 3131 present) with a signature scheme indicated in the client's 3132 "signature_algorithms"/"signature_algorithms_cert" extensions (see 3133 Section 4.2.3). 3135 - The "server_name" [RFC6066] and "certificate_authorities" 3136 extensions are used to guide certificate selection. As servers 3137 MAY require the presence of the "server_name" extension, clients 3138 SHOULD send this extension, when applicable. 3140 All certificates provided by the server MUST be signed by a signature 3141 algorithm advertised by the client, if they are able to provide such 3142 a chain (see Section 4.2.3). Certificates that are self-signed or 3143 certificates that are expected to be trust anchors are not validated 3144 as part of the chain and therefore MAY be signed with any algorithm. 3146 If the server cannot produce a certificate chain that is signed only 3147 via the indicated supported algorithms, then it SHOULD continue the 3148 handshake by sending the client a certificate chain of its choice 3149 that may include algorithms that are not known to be supported by the 3150 client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash 3151 algorithm in general, but MAY do so if the client's advertisement 3152 permits it, and MUST NOT do so otherwise. 3154 If the client cannot construct an acceptable chain using the provided 3155 certificates and decides to abort the handshake, then it MUST abort 3156 the handshake with an appropriate certificate-related alert (by 3157 default, "unsupported_certificate"; see Section 6.2 for more). 3159 If the server has multiple certificates, it chooses one of them based 3160 on the above-mentioned criteria (in addition to other criteria, such 3161 as transport layer endpoint, local configuration and preferences). 3163 4.4.2.3. Client Certificate Selection 3165 The following rules apply to certificates sent by the client: 3167 - The certificate type MUST be X.509v3 [RFC5280], unless explicitly 3168 negotiated otherwise (e.g., [RFC7250]). 3170 - If the "certificate_authorities" extension in the 3171 CertificateRequest message was present, at least one of the 3172 certificates in the certificate chain SHOULD be issued by one of 3173 the listed CAs. 3175 - The certificates MUST be signed using an acceptable signature 3176 algorithm, as described in Section 4.3.2. Note that this relaxes 3177 the constraints on certificate-signing algorithms found in prior 3178 versions of TLS. 3180 - If the CertificateRequest message contained a non-empty 3181 "oid_filters" extension, the end-entity certificate MUST match the 3182 extension OIDs recognized by the client, as described in 3183 Section 4.2.5. 3185 Note that, as with the server certificate, there are certificates 3186 that use algorithm combinations that cannot be currently used with 3187 TLS. 3189 4.4.2.4. Receiving a Certificate Message 3191 In general, detailed certificate validation procedures are out of 3192 scope for TLS (see [RFC5280]). This section provides TLS-specific 3193 requirements. 3195 If the server supplies an empty Certificate message, the client MUST 3196 abort the handshake with a "decode_error" alert. 3198 If the client does not send any certificates, the server MAY at its 3199 discretion either continue the handshake without client 3200 authentication, or abort the handshake with a "certificate_required" 3201 alert. Also, if some aspect of the certificate chain was 3202 unacceptable (e.g., it was not signed by a known, trusted CA), the 3203 server MAY at its discretion either continue the handshake 3204 (considering the client unauthenticated) or abort the handshake. 3206 Any endpoint receiving any certificate which it would need to 3207 validate using any signature algorithm using an MD5 hash MUST abort 3208 the handshake with a "bad_certificate" alert. SHA-1 is deprecated 3209 and it is RECOMMENDED that any endpoint receiving any certificate 3210 which it would need to validate using any signature algorithm using a 3211 SHA-1 hash abort the handshake with a "bad_certificate" alert. For 3212 clarity, this means that endpoints MAY accept these algorithms for 3213 certificates that are self-signed or are trust anchors. 3215 All endpoints are RECOMMENDED to transition to SHA-256 or better as 3216 soon as possible to maintain interoperability with implementations 3217 currently in the process of phasing out SHA-1 support. 3219 Note that a certificate containing a key for one signature algorithm 3220 MAY be signed using a different signature algorithm (for instance, an 3221 RSA key signed with an ECDSA key). 3223 4.4.3. Certificate Verify 3225 This message is used to provide explicit proof that an endpoint 3226 possesses the private key corresponding to its certificate. The 3227 CertificateVerify message also provides integrity for the handshake 3228 up to this point. Servers MUST send this message when authenticating 3229 via a certificate. Clients MUST send this message whenever 3230 authenticating via a certificate (i.e., when the Certificate message 3231 is non-empty). When sent, this message MUST appear immediately after 3232 the Certificate message and immediately prior to the Finished 3233 message. 3235 Structure of this message: 3237 struct { 3238 SignatureScheme algorithm; 3239 opaque signature<0..2^16-1>; 3240 } CertificateVerify; 3242 The algorithm field specifies the signature algorithm used (see 3243 Section 4.2.3 for the definition of this field). The signature is a 3244 digital signature using that algorithm. The content that is covered 3245 under the signature is the hash output as described in Section 4.4, 3246 namely: 3248 Transcript-Hash(Handshake Context, Certificate) 3250 The digital signature is then computed over the concatenation of: 3252 - A string that consists of octet 32 (0x20) repeated 64 times 3254 - The context string 3256 - A single 0 byte which serves as the separator 3258 - The content to be signed 3260 This structure is intended to prevent an attack on previous versions 3261 of TLS in which the ServerKeyExchange format meant that attackers 3262 could obtain a signature of a message with a chosen 32-byte prefix 3263 (ClientHello.random). The initial 64-byte pad clears that prefix 3264 along with the server-controlled ServerHello.random. 3266 The context string for a server signature is "TLS 1.3, server 3267 CertificateVerify" and for a client signature is "TLS 1.3, client 3268 CertificateVerify". It is used to provide separation between 3269 signatures made in different contexts, helping against potential 3270 cross-protocol attacks. 3272 For example, if the transcript hash was 32 bytes of 01 (this length 3273 would make sense for SHA-256), the content covered by the digital 3274 signature for a server CertificateVerify would be: 3276 2020202020202020202020202020202020202020202020202020202020202020 3277 2020202020202020202020202020202020202020202020202020202020202020 3278 544c5320312e332c207365727665722043657274696669636174655665726966 3279 79 3280 00 3281 0101010101010101010101010101010101010101010101010101010101010101 3283 On the sender side the process for computing the signature field of 3284 the CertificateVerify message takes as input: 3286 - The content covered by the digital signature 3288 - The private signing key corresponding to the certificate sent in 3289 the previous message 3291 If the CertificateVerify message is sent by a server, the signature 3292 algorithm MUST be one offered in the client's "signature_algorithms" 3293 extension unless no valid certificate chain can be produced without 3294 unsupported algorithms (see Section 4.2.3). 3296 If sent by a client, the signature algorithm used in the signature 3297 MUST be one of those present in the supported_signature_algorithms 3298 field of the "signature_algorithms" extension in the 3299 CertificateRequest message. 3301 In addition, the signature algorithm MUST be compatible with the key 3302 in the sender's end-entity certificate. RSA signatures MUST use an 3303 RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 3304 algorithms appear in "signature_algorithms". The SHA-1 algorithm 3305 MUST NOT be used in any signatures of CertificateVerify messages. 3306 All SHA-1 signature algorithms in this specification are defined 3307 solely for use in legacy certificates and are not valid for 3308 CertificateVerify signatures. 3310 The receiver of a CertificateVerify message MUST verify the signature 3311 field. The verification process takes as input: 3313 - The content covered by the digital signature 3315 - The public key contained in the end-entity certificate found in 3316 the associated Certificate message. 3318 - The digital signature received in the signature field of the 3319 CertificateVerify message 3321 If the verification fails, the receiver MUST terminate the handshake 3322 with a "decrypt_error" alert. 3324 4.4.4. Finished 3326 The Finished message is the final message in the authentication 3327 block. It is essential for providing authentication of the handshake 3328 and of the computed keys. 3330 Recipients of Finished messages MUST verify that the contents are 3331 correct and if incorrect MUST terminate the connection with a 3332 "decrypt_error" alert. 3334 Once a side has sent its Finished message and received and validated 3335 the Finished message from its peer, it may begin to send and receive 3336 application data over the connection. There are two settings in 3337 which it is permitted to send data prior to receiving the peer's 3338 Finished: 3340 1. Clients sending 0-RTT data as described in Section 4.2.10. 3342 2. Servers MAY send data after sending their first flight, but 3343 because the handshake is not yet complete, they have no assurance 3344 of either the peer's identity or of its liveness (i.e., the 3345 ClientHello might have been replayed). 3347 The key used to compute the finished message is computed from the 3348 Base key defined in Section 4.4 using HKDF (see Section 7.1). 3349 Specifically: 3351 finished_key = 3352 HKDF-Expand-Label(BaseKey, "finished", "", Hash.length) 3354 Structure of this message: 3356 struct { 3357 opaque verify_data[Hash.length]; 3358 } Finished; 3360 The verify_data value is computed as follows: 3362 verify_data = 3363 HMAC(finished_key, 3364 Transcript-Hash(Handshake Context, 3365 Certificate*, CertificateVerify*)) 3367 * Only included if present. 3369 HMAC [RFC2104] uses the Hash algorithm for the handshake. As noted 3370 above, the HMAC input can generally be implemented by a running hash, 3371 i.e., just the handshake hash at this point. 3373 In previous versions of TLS, the verify_data was always 12 octets 3374 long. In TLS 1.3, it is the size of the HMAC output for the Hash 3375 used for the handshake. 3377 Note: Alerts and any other record types are not handshake messages 3378 and are not included in the hash computations. 3380 Any records following a 1-RTT Finished message MUST be encrypted 3381 under the appropriate application traffic key as described in 3382 Section 7.2. In particular, this includes any alerts sent by the 3383 server in response to client Certificate and CertificateVerify 3384 messages. 3386 4.5. End of Early Data 3388 struct {} EndOfEarlyData; 3390 If the server sent an "early_data" extension, the client MUST send an 3391 EndOfEarlyData message after receiving the server Finished. If the 3392 server does not send an "early_data" extension, then the client MUST 3393 NOT send an EndOfEarlyData message. This message indicates that all 3394 0-RTT application_data messages, if any, have been transmitted and 3395 that the following records are protected under handshake traffic 3396 keys. Servers MUST NOT send this message and clients receiving it 3397 MUST terminate the connection with an "unexpected_message" alert. 3398 This message is encrypted under keys derived from the 3399 client_early_traffic_secret. 3401 4.6. Post-Handshake Messages 3403 TLS also allows other messages to be sent after the main handshake. 3404 These messages use a handshake content type and are encrypted under 3405 the appropriate application traffic key. 3407 4.6.1. New Session Ticket Message 3409 At any time after the server has received the client Finished 3410 message, it MAY send a NewSessionTicket message. This message 3411 creates a unique association between the ticket value and a secret 3412 PSK derived from the resumption master secret. 3414 The client MAY use this PSK for future handshakes by including the 3415 ticket value in the "pre_shared_key" extension in its ClientHello 3416 (Section 4.2.11). Servers MAY send multiple tickets on a single 3417 connection, either immediately after each other or after specific 3418 events (see Appendix C.4). For instance, the server might send a new 3419 ticket after post-handshake authentication in order to encapsulate 3420 the additional client authentication state. Multiple tickets are 3421 useful for clients for a variety of purposes, including: 3423 - Opening multiple parallel HTTP connections. 3425 - Performing connection racing across interfaces and address 3426 families via, e.g., Happy Eyeballs [RFC8305] or related 3427 techniques. 3429 Any ticket MUST only be resumed with a cipher suite that has the same 3430 KDF hash algorithm as that used to establish the original connection. 3432 Clients MUST only resume if the new SNI value is valid for the server 3433 certificate presented in the original session, and SHOULD only resume 3434 if the SNI value matches the one used in the original session. The 3435 latter is a performance optimization: normally, there is no reason to 3436 expect that different servers covered by a single certificate would 3437 be able to accept each other's tickets, hence attempting resumption 3438 in that case would waste a single-use ticket. If such an indication 3439 is provided (externally or by any other means), clients MAY resume 3440 with a different SNI value. 3442 On resumption, if reporting an SNI value to the calling application, 3443 implementations MUST use the value sent in the resumption ClientHello 3444 rather than the value sent in the previous session. Note that if a 3445 server implementation declines all PSK identities with different SNI 3446 values, these two values are always the same. 3448 Note: Although the resumption master secret depends on the client's 3449 second flight, servers which do not request client authentication MAY 3450 compute the remainder of the transcript independently and then send a 3451 NewSessionTicket immediately upon sending its Finished rather than 3452 waiting for the client Finished. This might be appropriate in cases 3453 where the client is expected to open multiple TLS connections in 3454 parallel and would benefit from the reduced overhead of a resumption 3455 handshake, for example. 3457 struct { 3458 uint32 ticket_lifetime; 3459 uint32 ticket_age_add; 3460 opaque ticket_nonce<0..255>; 3461 opaque ticket<1..2^16-1>; 3462 Extension extensions<0..2^16-2>; 3463 } NewSessionTicket; 3465 ticket_lifetime Indicates the lifetime in seconds as a 32-bit 3466 unsigned integer in network byte order from the time of ticket 3467 issuance. Servers MUST NOT use any value greater than 604800 3468 seconds (7 days). The value of zero indicates that the ticket 3469 should be discarded immediately. Clients MUST NOT cache tickets 3470 for longer than 7 days, regardless of the ticket_lifetime, and MAY 3471 delete the ticket earlier based on local policy. A server MAY 3472 treat a ticket as valid for a shorter period of time than what is 3473 stated in the ticket_lifetime. 3475 ticket_age_add A securely generated, random 32-bit value that is 3476 used to obscure the age of the ticket that the client includes in 3477 the "pre_shared_key" extension. The client-side ticket age is 3478 added to this value modulo 2^32 to obtain the value that is 3479 transmitted by the client. The server MUST generate a fresh value 3480 for each ticket it sends. 3482 ticket_nonce A per-ticket value that is unique across all tickets 3483 issued on this connection. 3485 ticket The value of the ticket to be used as the PSK identity. The 3486 ticket itself is an opaque label. It MAY either be a database 3487 lookup key or a self-encrypted and self-authenticated value. 3488 Section 4 of [RFC5077] describes a recommended ticket construction 3489 mechanism. 3491 extensions A set of extension values for the ticket. The 3492 "Extension" format is defined in Section 4.2. Clients MUST ignore 3493 unrecognized extensions. 3495 The sole extension currently defined for NewSessionTicket is 3496 "early_data", indicating that the ticket may be used to send 0-RTT 3497 data (Section 4.2.10)). It contains the following value: 3499 max_early_data_size The maximum amount of 0-RTT data that the client 3500 is allowed to send when using this ticket, in bytes. Only 3501 Application Data payload (i.e., plaintext but not padding or the 3502 inner content type byte) is counted. A server receiving more than 3503 max_early_data_size bytes of 0-RTT data SHOULD terminate the 3504 connection with an "unexpected_message" alert. Note that servers 3505 that reject early data due to lack of cryptographic material will 3506 be unable to differentiate padding from content, so clients SHOULD 3507 NOT depend on being able to send large quantities of padding in 3508 early data records. 3510 The PSK associated with the ticket is computed as: 3512 HKDF-Expand-Label(resumption_master_secret, 3513 "resumption", ticket_nonce, Hash.length) 3515 Because the ticket_nonce value is distinct for each NewSessionTicket 3516 message, a different PSK will be derived for each ticket. 3518 Note that in principle it is possible to continue issuing new tickets 3519 which indefinitely extend the lifetime of the keying material 3520 originally derived from an initial non-PSK handshake (which was most 3521 likely tied to the peer's certificate). It is RECOMMENDED that 3522 implementations place limits on the total lifetime of such keying 3523 material; these limits should take into account the lifetime of the 3524 peer's certificate, the likelihood of intervening revocation, and the 3525 time since the peer's online CertificateVerify signature. 3527 4.6.2. Post-Handshake Authentication 3529 When the client has sent the "post_handshake_auth" extension (see 3530 Section 4.2.6), a server MAY request client authentication at any 3531 time after the handshake has completed by sending a 3532 CertificateRequest message. The client MUST respond with the 3533 appropriate Authentication messages (see Section 4.4). If the client 3534 chooses to authenticate, it MUST send Certificate, CertificateVerify, 3535 and Finished. If it declines, it MUST send a Certificate message 3536 containing no certificates followed by Finished. All of the client's 3537 messages for a given response MUST appear consecutively on the wire 3538 with no intervening messages of other types. 3540 A client that receives a CertificateRequest message without having 3541 sent the "post_handshake_auth" extension MUST send an 3542 "unexpected_message" fatal alert. 3544 Note: Because client authentication could involve prompting the user, 3545 servers MUST be prepared for some delay, including receiving an 3546 arbitrary number of other messages between sending the 3547 CertificateRequest and receiving a response. In addition, clients 3548 which receive multiple CertificateRequests in close succession MAY 3549 respond to them in a different order than they were received (the 3550 certificate_request_context value allows the server to disambiguate 3551 the responses). 3553 4.6.3. Key and IV Update 3555 enum { 3556 update_not_requested(0), update_requested(1), (255) 3557 } KeyUpdateRequest; 3559 struct { 3560 KeyUpdateRequest request_update; 3561 } KeyUpdate; 3563 request_update Indicates whether the recipient of the KeyUpdate 3564 should respond with its own KeyUpdate. If an implementation 3565 receives any other value, it MUST terminate the connection with an 3566 "illegal_parameter" alert. 3568 The KeyUpdate handshake message is used to indicate that the sender 3569 is updating its sending cryptographic keys. This message can be sent 3570 by either peer after it has sent a Finished message. Implementations 3571 that receive a KeyUpdate message prior to receiving a Finished 3572 message MUST terminate the connection with an "unexpected_message" 3573 alert. After sending a KeyUpdate message, the sender SHALL send all 3574 its traffic using the next generation of keys, computed as described 3575 in Section 7.2. Upon receiving a KeyUpdate, the receiver MUST update 3576 its receiving keys. 3578 If the request_update field is set to "update_requested" then the 3579 receiver MUST send a KeyUpdate of its own with request_update set to 3580 "update_not_requested" prior to sending its next application data 3581 record. This mechanism allows either side to force an update to the 3582 entire connection, but causes an implementation which receives 3583 multiple KeyUpdates while it is silent to respond with a single 3584 update. Note that implementations may receive an arbitrary number of 3585 messages between sending a KeyUpdate with request_update set to 3586 update_requested and receiving the peer's KeyUpdate, because those 3587 messages may already be in flight. However, because send and receive 3588 keys are derived from independent traffic secrets, retaining the 3589 receive traffic secret does not threaten the forward secrecy of data 3590 sent before the sender changed keys. 3592 If implementations independently send their own KeyUpdates with 3593 request_update set to "update_requested", and they cross in flight, 3594 then each side will also send a response, with the result that each 3595 side increments by two generations. 3597 Both sender and receiver MUST encrypt their KeyUpdate messages with 3598 the old keys. Additionally, both sides MUST enforce that a KeyUpdate 3599 with the old key is received before accepting any messages encrypted 3600 with the new key. Failure to do so may allow message truncation 3601 attacks. 3603 5. Record Protocol 3605 The TLS record protocol takes messages to be transmitted, fragments 3606 the data into manageable blocks, protects the records, and transmits 3607 the result. Received data is verified, decrypted, reassembled, and 3608 then delivered to higher-level clients. 3610 TLS records are typed, which allows multiple higher-level protocols 3611 to be multiplexed over the same record layer. This document 3612 specifies four content types: handshake, application data, alert, and 3613 change_cipher_spec. The change_cipher_spec record is used only for 3614 compatibility purposes (see Appendix D.4). 3616 An implementation may receive an unencrypted record of type 3617 change_cipher_spec consisting of the single byte value 0x01 at any 3618 time after the first ClientHello message has been sent or received 3619 and before the peer's Finished message has been received and MUST 3620 simply drop it without further processing. Note that this record may 3621 appear at a point at the handshake where the implementation is 3622 expecting protected records and so it is necessary to detect this 3623 condition prior to attempting to deprotect the record. An 3624 implementation which receives any other change_cipher_spec value or 3625 which receives a protected change_cipher_spec record MUST abort the 3626 handshake with an "unexpected_message" alert. A change_cipher_spec 3627 record received before the first ClientHello message or after the 3628 peer's Finished message MUST be treated as an unexpected record type. 3630 Implementations MUST NOT send record types not defined in this 3631 document unless negotiated by some extension. If a TLS 3632 implementation receives an unexpected record type, it MUST terminate 3633 the connection with an "unexpected_message" alert. New record 3634 content type values are assigned by IANA in the TLS Content Type 3635 Registry as described in Section 11. 3637 5.1. Record Layer 3639 The record layer fragments information blocks into TLSPlaintext 3640 records carrying data in chunks of 2^14 bytes or less. Message 3641 boundaries are handled differently depending on the underlying 3642 ContentType. Any future content types MUST specify appropriate 3643 rules. Note that these rules are stricter than what was enforced in 3644 TLS 1.2. 3646 Handshake messages MAY be coalesced into a single TLSPlaintext record 3647 or fragmented across several records, provided that: 3649 - Handshake messages MUST NOT be interleaved with other record 3650 types. That is, if a handshake message is split over two or more 3651 records, there MUST NOT be any other records between them. 3653 - Handshake messages MUST NOT span key changes. Implementations 3654 MUST verify that all messages immediately preceding a key change 3655 align with a record boundary; if not, then they MUST terminate the 3656 connection with an "unexpected_message" alert. Because the 3657 ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate 3658 messages can immediately precede a key change, implementations 3659 MUST send these messages in alignment with a record boundary. 3661 Implementations MUST NOT send zero-length fragments of Handshake 3662 types, even if those fragments contain padding. 3664 Alert messages (Section 6) MUST NOT be fragmented across records and 3665 multiple Alert messages MUST NOT be coalesced into a single 3666 TLSPlaintext record. In other words, a record with an Alert type 3667 MUST contain exactly one message. 3669 Application Data messages contain data that is opaque to TLS. 3670 Application Data messages are always protected. Zero-length 3671 fragments of Application Data MAY be sent as they are potentially 3672 useful as a traffic analysis countermeasure. Application Data 3673 fragments MAY be split across multiple records or coalesced into a 3674 single record. 3676 enum { 3677 invalid(0), 3678 change_cipher_spec(20), 3679 alert(21), 3680 handshake(22), 3681 application_data(23), 3682 (255) 3683 } ContentType; 3685 struct { 3686 ContentType type; 3687 ProtocolVersion legacy_record_version; 3688 uint16 length; 3689 opaque fragment[TLSPlaintext.length]; 3690 } TLSPlaintext; 3692 type The higher-level protocol used to process the enclosed 3693 fragment. 3695 legacy_record_version This value MUST be set to 0x0303 for all 3696 records generated by a TLS 1.3 implementation other than an 3697 initial ClientHello (i.e., one not generated after a 3698 HelloRetryRequest), where it MAY also be 0x0301 for compatibility 3699 purposes. This field is deprecated and MUST be ignored for all 3700 purposes. Previous versions of TLS would use other values in this 3701 field under some circumstances. 3703 length The length (in bytes) of the following TLSPlaintext.fragment. 3704 The length MUST NOT exceed 2^14 bytes. An endpoint that receives 3705 a record that exceeds this length MUST terminate the connection 3706 with a "record_overflow" alert. 3708 fragment The data being transmitted. This value is transparent and 3709 is treated as an independent block to be dealt with by the higher- 3710 level protocol specified by the type field. 3712 This document describes TLS 1.3, which uses the version 0x0304. This 3713 version value is historical, deriving from the use of 0x0301 for TLS 3714 1.0 and 0x0300 for SSL 3.0. In order to maximize backwards 3715 compatibility, records containing an initial ClientHello MUST have 3716 version 0x0301 and a record containing a second ClientHello or a 3717 ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2 3718 respectively. When negotiating prior versions of TLS, endpoints 3719 follow the procedure and requirements in Appendix D. 3721 When record protection has not yet been engaged, TLSPlaintext 3722 structures are written directly onto the wire. Once record 3723 protection has started, TLSPlaintext records are protected and sent 3724 as described in the following section. 3726 5.2. Record Payload Protection 3728 The record protection functions translate a TLSPlaintext structure 3729 into a TLSCiphertext. The deprotection functions reverse the 3730 process. In TLS 1.3, as opposed to previous versions of TLS, all 3731 ciphers are modeled as "Authenticated Encryption with Additional 3732 Data" (AEAD) [RFC5116]. AEAD functions provide an unified encryption 3733 and authentication operation which turns plaintext into authenticated 3734 ciphertext and back again. Each encrypted record consists of a 3735 plaintext header followed by an encrypted body, which itself contains 3736 a type and optional padding. 3738 struct { 3739 opaque content[TLSPlaintext.length]; 3740 ContentType type; 3741 uint8 zeros[length_of_padding]; 3742 } TLSInnerPlaintext; 3744 struct { 3745 ContentType opaque_type = application_data; /* 23 */ 3746 ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */ 3747 uint16 length; 3748 opaque encrypted_record[TLSCiphertext.length]; 3749 } TLSCiphertext; 3751 content The byte encoding of a handshake or an alert message, or the 3752 raw bytes of the application's data to send. 3754 type The content type of the record. 3756 zeros An arbitrary-length run of zero-valued bytes may appear in the 3757 cleartext after the type field. This provides an opportunity for 3758 senders to pad any TLS record by a chosen amount as long as the 3759 total stays within record size limits. See Section 5.4 for more 3760 details. 3762 opaque_type The outer opaque_type field of a TLSCiphertext record is 3763 always set to the value 23 (application_data) for outward 3764 compatibility with middleboxes accustomed to parsing previous 3765 versions of TLS. The actual content type of the record is found 3766 in TLSInnerPlaintext.type after decryption. 3768 legacy_record_version The legacy_record_version field is always 3769 0x0303. TLS 1.3 TLSCiphertexts are not generated until after TLS 3770 1.3 has been negotiated, so there are no historical compatibility 3771 concerns where other values might be received. Implementations 3772 MAY verify that the legacy_record_version field is 0x0303 and 3773 abort the connection if it is not. Note that the handshake 3774 protocol including the ClientHello and ServerHello messages 3775 authenticates the protocol version, so this value is redundant. 3777 length The length (in bytes) of the following 3778 TLSCiphertext.encrypted_record, which is the sum of the lengths of 3779 the content and the padding, plus one for the inner content type, 3780 plus any expansion added by the AEAD algorithm. The length MUST 3781 NOT exceed 2^14 + 256 bytes. An endpoint that receives a record 3782 that exceeds this length MUST terminate the connection with a 3783 "record_overflow" alert. 3785 encrypted_record The AEAD-encrypted form of the serialized 3786 TLSInnerPlaintext structure. 3788 AEAD algorithms take as input a single key, a nonce, a plaintext, and 3789 "additional data" to be included in the authentication check, as 3790 described in Section 2.1 of [RFC5116]. The key is either the 3791 client_write_key or the server_write_key, the nonce is derived from 3792 the sequence number (see Section 5.3) and the client_write_iv or 3793 server_write_iv, and the additional data input is empty (zero 3794 length). Derivation of traffic keys is defined in Section 7.3. 3796 The plaintext input to the AEAD algorithm is the encoded 3797 TLSInnerPlaintext structure. 3799 The AEAD output consists of the ciphertext output from the AEAD 3800 encryption operation. The length of the plaintext is greater than 3801 the corresponding TLSPlaintext.length due to the inclusion of 3802 TLSInnerPlaintext.type and any padding supplied by the sender. The 3803 length of the AEAD output will generally be larger than the 3804 plaintext, but by an amount that varies with the AEAD algorithm. 3805 Since the ciphers might incorporate padding, the amount of overhead 3806 could vary with different lengths of plaintext. Symbolically, 3808 AEADEncrypted = 3809 AEAD-Encrypt(write_key, nonce, plaintext) 3811 In order to decrypt and verify, the cipher takes as input the key, 3812 nonce, and the AEADEncrypted value. The output is either the 3813 plaintext or an error indicating that the decryption failed. There 3814 is no separate integrity check. That is: 3816 plaintext of encrypted_record = 3817 AEAD-Decrypt(peer_write_key, nonce, AEADEncrypted) 3819 If the decryption fails, the receiver MUST terminate the connection 3820 with a "bad_record_mac" alert. 3822 An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion 3823 greater than 255 octets. An endpoint that receives a record from its 3824 peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST 3825 terminate the connection with a "record_overflow" alert. This limit 3826 is derived from the maximum TLSPlaintext length of 2^14 octets + 1 3827 octet for ContentType + the maximum AEAD expansion of 255 octets. 3829 5.3. Per-Record Nonce 3831 A 64-bit sequence number is maintained separately for reading and 3832 writing records. Each sequence number is set to zero at the 3833 beginning of a connection and whenever the key is changed. 3835 The appropriate sequence number is incremented by one after reading 3836 or writing each record. The first record transmitted under a 3837 particular traffic key MUST use sequence number 0. 3839 Because the size of sequence numbers is 64-bit, they should not wrap. 3840 If a TLS implementation would need to wrap a sequence number, it MUST 3841 either re-key (Section 4.6.3) or terminate the connection. 3843 Each AEAD algorithm will specify a range of possible lengths for the 3844 per-record nonce, from N_MIN bytes to N_MAX bytes of input 3845 ([RFC5116]). The length of the TLS per-record nonce (iv_length) is 3846 set to the larger of 8 bytes and N_MIN for the AEAD algorithm (see 3847 [RFC5116] Section 4). An AEAD algorithm where N_MAX is less than 8 3848 bytes MUST NOT be used with TLS. The per-record nonce for the AEAD 3849 construction is formed as follows: 3851 1. The 64-bit record sequence number is encoded in network byte 3852 order and padded to the left with zeros to iv_length. 3854 2. The padded sequence number is XORed with the static 3855 client_write_iv or server_write_iv, depending on the role. 3857 The resulting quantity (of length iv_length) is used as the per- 3858 record nonce. 3860 Note: This is a different construction from that in TLS 1.2, which 3861 specified a partially explicit nonce. 3863 5.4. Record Padding 3865 All encrypted TLS records can be padded to inflate the size of the 3866 TLSCiphertext. This allows the sender to hide the size of the 3867 traffic from an observer. 3869 When generating a TLSCiphertext record, implementations MAY choose to 3870 pad. An unpadded record is just a record with a padding length of 3871 zero. Padding is a string of zero-valued bytes appended to the 3872 ContentType field before encryption. Implementations MUST set the 3873 padding octets to all zeros before encrypting. 3875 Application Data records may contain a zero-length 3876 TLSInnerPlaintext.content if the sender desires. This permits 3877 generation of plausibly-sized cover traffic in contexts where the 3878 presence or absence of activity may be sensitive. Implementations 3879 MUST NOT send Handshake or Alert records that have a zero-length 3880 TLSInnerPlaintext.content; if such a message is received, the 3881 receiving implementation MUST terminate the connection with an 3882 "unexpected_message" alert. 3884 The padding sent is automatically verified by the record protection 3885 mechanism; upon successful decryption of a 3886 TLSCiphertext.encrypted_record, the receiving implementation scans 3887 the field from the end toward the beginning until it finds a non-zero 3888 octet. This non-zero octet is the content type of the message. This 3889 padding scheme was selected because it allows padding of any 3890 encrypted TLS record by an arbitrary size (from zero up to TLS record 3891 size limits) without introducing new content types. The design also 3892 enforces all-zero padding octets, which allows for quick detection of 3893 padding errors. 3895 Implementations MUST limit their scanning to the cleartext returned 3896 from the AEAD decryption. If a receiving implementation does not 3897 find a non-zero octet in the cleartext, it MUST terminate the 3898 connection with an "unexpected_message" alert. 3900 The presence of padding does not change the overall record size 3901 limitations - the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 3902 + 1 octets. If the maximum fragment length is reduced, as for 3903 example by the max_fragment_length extension from [RFC6066], then the 3904 reduced limit applies to the full plaintext, including the content 3905 type and padding. 3907 Selecting a padding policy that suggests when and how much to pad is 3908 a complex topic and is beyond the scope of this specification. If 3909 the application layer protocol on top of TLS has its own padding, it 3910 may be preferable to pad application_data TLS records within the 3911 application layer. Padding for encrypted handshake and alert TLS 3912 records must still be handled at the TLS layer, though. Later 3913 documents may define padding selection algorithms or define a padding 3914 policy request mechanism through TLS extensions or some other means. 3916 5.5. Limits on Key Usage 3918 There are cryptographic limits on the amount of plaintext which can 3919 be safely encrypted under a given set of keys. [AEAD-LIMITS] 3920 provides an analysis of these limits under the assumption that the 3921 underlying primitive (AES or ChaCha20) has no weaknesses. 3922 Implementations SHOULD do a key update as described in Section 4.6.3 3923 prior to reaching these limits. 3925 For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be 3926 encrypted on a given connection while keeping a safety margin of 3927 approximately 2^-57 for Authenticated Encryption (AE) security. For 3928 ChaCha20/Poly1305, the record sequence number would wrap before the 3929 safety limit is reached. 3931 6. Alert Protocol 3933 One of the content types supported by the TLS record layer is the 3934 alert type. Like other messages, alert messages are encrypted as 3935 specified by the current connection state. 3937 Alert messages convey a description of the alert and a legacy field 3938 that conveyed the severity of the message in previous versions of 3939 TLS. In TLS 1.3, the severity is implicit in the type of alert being 3940 sent, and the 'level' field can safely be ignored. The 3941 "close_notify" alert is used to indicate orderly closure of one 3942 direction of the connection. Upon receiving such an alert, the TLS 3943 implementation SHOULD indicate end-of-data to the application. 3945 Error alerts indicate abortive closure of the connection (see 3946 Section 6.2). Upon receiving an error alert, the TLS implementation 3947 SHOULD indicate an error to the application and MUST NOT allow any 3948 further data to be sent or received on the connection. Servers and 3949 clients MUST forget keys and secrets associated with a failed 3950 connection. Stateful implementations of tickets (as in many clients) 3951 SHOULD discard tickets associated with failed connections. 3953 All the alerts listed in Section 6.2 MUST be sent as fatal and MUST 3954 be treated as fatal regardless of the AlertLevel in the message. 3955 Unknown alert types MUST be treated as fatal. 3957 Note: TLS defines two generic alerts (see Section 6) to use upon 3958 failure to parse a message. Peers which receive a message which 3959 cannot be parsed according to the syntax (e.g., have a length 3960 extending beyond the message boundary or contain an out-of-range 3961 length) MUST terminate the connection with a "decode_error" alert. 3962 Peers which receive a message which is syntactically correct but 3963 semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) 3964 MUST terminate the connection with an "illegal_parameter" alert. 3966 enum { warning(1), fatal(2), (255) } AlertLevel; 3968 enum { 3969 close_notify(0), 3970 unexpected_message(10), 3971 bad_record_mac(20), 3972 record_overflow(22), 3973 handshake_failure(40), 3974 bad_certificate(42), 3975 unsupported_certificate(43), 3976 certificate_revoked(44), 3977 certificate_expired(45), 3978 certificate_unknown(46), 3979 illegal_parameter(47), 3980 unknown_ca(48), 3981 access_denied(49), 3982 decode_error(50), 3983 decrypt_error(51), 3984 protocol_version(70), 3985 insufficient_security(71), 3986 internal_error(80), 3987 inappropriate_fallback(86), 3988 user_canceled(90), 3989 missing_extension(109), 3990 unsupported_extension(110), 3991 certificate_unobtainable(111), 3992 unrecognized_name(112), 3993 bad_certificate_status_response(113), 3994 bad_certificate_hash_value(114), 3995 unknown_psk_identity(115), 3996 certificate_required(116), 3997 no_application_protocol(120), 3998 (255) 3999 } AlertDescription; 4001 struct { 4002 AlertLevel level; 4003 AlertDescription description; 4004 } Alert; 4006 6.1. Closure Alerts 4008 The client and the server must share knowledge that the connection is 4009 ending in order to avoid a truncation attack. 4011 close_notify This alert notifies the recipient that the sender will 4012 not send any more messages on this connection. Any data received 4013 after a closure alert has been received MUST be ignored. 4015 user_canceled This alert notifies the recipient that the sender is 4016 canceling the handshake for some reason unrelated to a protocol 4017 failure. If a user cancels an operation after the handshake is 4018 complete, just closing the connection by sending a "close_notify" 4019 is more appropriate. This alert SHOULD be followed by a 4020 "close_notify". This alert is generally a warning. 4022 Either party MAY initiate a close of its write side of the connection 4023 by sending a "close_notify" alert. Any data received after a closure 4024 alert has been received MUST be ignored. If a transport-level close 4025 is received prior to a "close_notify", the receiver cannot know that 4026 all the data that was sent has been received. 4028 Each party MUST send a "close_notify" alert before closing its write 4029 side of the connection, unless it has already sent some other fatal 4030 alert. This does not have any effect on its read side of the 4031 connection. Note that this is a change from versions of TLS prior to 4032 TLS 1.3 in which implementations were required to react to a 4033 "close_notify" by discarding pending writes and sending an immediate 4034 "close_notify" alert of their own. That previous requirement could 4035 cause truncation in the read side. Both parties need not wait to 4036 receive a "close_notify" alert before closing their read side of the 4037 connection. 4039 If the application protocol using TLS provides that any data may be 4040 carried over the underlying transport after the TLS connection is 4041 closed, the TLS implementation MUST receive a "close_notify" alert 4042 before indicating end-of-data to the application-layer. No part of 4043 this standard should be taken to dictate the manner in which a usage 4044 profile for TLS manages its data transport, including when 4045 connections are opened or closed. 4047 Note: It is assumed that closing the write side of a connection 4048 reliably delivers pending data before destroying the transport. 4050 6.2. Error Alerts 4052 Error handling in the TLS Handshake Protocol is very simple. When an 4053 error is detected, the detecting party sends a message to its peer. 4054 Upon transmission or receipt of a fatal alert message, both parties 4055 MUST immediately close the connection. 4057 Whenever an implementation encounters a fatal error condition, it 4058 SHOULD send an appropriate fatal alert and MUST close the connection 4059 without sending or receiving any additional data. In the rest of 4060 this specification, when the phrases "terminate the connection" and 4061 "abort the handshake" are used without a specific alert it means that 4062 the implementation SHOULD send the alert indicated by the 4063 descriptions below. The phrases "terminate the connection with a X 4064 alert" and "abort the handshake with a X alert" mean that the 4065 implementation MUST send alert X if it sends any alert. All alerts 4066 defined in this section below, as well as all unknown alerts, are 4067 universally considered fatal as of TLS 1.3 (see Section 6). The 4068 implementation SHOULD provide a way to facilitate logging the sending 4069 and receiving of alerts. 4071 The following error alerts are defined: 4073 unexpected_message An inappropriate message (e.g., the wrong 4074 handshake message, premature application data, etc.) was received. 4075 This alert should never be observed in communication between 4076 proper implementations. 4078 bad_record_mac This alert is returned if a record is received which 4079 cannot be deprotected. Because AEAD algorithms combine decryption 4080 and verification, and also to avoid side channel attacks, this 4081 alert is used for all deprotection failures. This alert should 4082 never be observed in communication between proper implementations, 4083 except when messages were corrupted in the network. 4085 record_overflow A TLSCiphertext record was received that had a 4086 length more than 2^14 + 256 bytes, or a record decrypted to a 4087 TLSPlaintext record with more than 2^14 bytes. This alert should 4088 never be observed in communication between proper implementations, 4089 except when messages were corrupted in the network. 4091 handshake_failure Receipt of a "handshake_failure" alert message 4092 indicates that the sender was unable to negotiate an acceptable 4093 set of security parameters given the options available. 4095 bad_certificate A certificate was corrupt, contained signatures that 4096 did not verify correctly, etc. 4098 unsupported_certificate A certificate was of an unsupported type. 4100 certificate_revoked A certificate was revoked by its signer. 4102 certificate_expired A certificate has expired or is not currently 4103 valid. 4105 certificate_unknown Some other (unspecified) issue arose in 4106 processing the certificate, rendering it unacceptable. 4108 illegal_parameter A field in the handshake was incorrect or 4109 inconsistent with other fields. This alert is used for errors 4110 which conform to the formal protocol syntax but are otherwise 4111 incorrect. 4113 unknown_ca A valid certificate chain or partial chain was received, 4114 but the certificate was not accepted because the CA certificate 4115 could not be located or could not be matched with a known trust 4116 anchor. 4118 access_denied A valid certificate or PSK was received, but when 4119 access control was applied, the sender decided not to proceed with 4120 negotiation. 4122 decode_error A message could not be decoded because some field was 4123 out of the specified range or the length of the message was 4124 incorrect. This alert is used for errors where the message does 4125 not conform to the formal protocol syntax. This alert should 4126 never be observed in communication between proper implementations, 4127 except when messages were corrupted in the network. 4129 decrypt_error A handshake (not record-layer) cryptographic operation 4130 failed, including being unable to correctly verify a signature or 4131 validate a Finished message or a PSK binder. 4133 protocol_version The protocol version the peer has attempted to 4134 negotiate is recognized but not supported. (see Appendix D) 4136 insufficient_security Returned instead of "handshake_failure" when a 4137 negotiation has failed specifically because the server requires 4138 parameters more secure than those supported by the client. 4140 internal_error An internal error unrelated to the peer or the 4141 correctness of the protocol (such as a memory allocation failure) 4142 makes it impossible to continue. 4144 inappropriate_fallback Sent by a server in response to an invalid 4145 connection retry attempt from a client (see [RFC7507]). 4147 missing_extension Sent by endpoints that receive a hello message not 4148 containing an extension that is mandatory to send for the offered 4149 TLS version or other negotiated parameters. 4151 unsupported_extension Sent by endpoints receiving any hello message 4152 containing an extension known to be prohibited for inclusion in 4153 the given hello message, or including any extensions in a 4154 ServerHello or Certificate not first offered in the corresponding 4155 ClientHello. 4157 certificate_unobtainable Sent by servers when unable to obtain a 4158 certificate from a URL provided by the client via the 4159 "client_certificate_url" extension (see [RFC6066]). 4161 unrecognized_name Sent by servers when no server exists identified 4162 by the name provided by the client via the "server_name" extension 4163 (see [RFC6066]). 4165 bad_certificate_status_response Sent by clients when an invalid or 4166 unacceptable OCSP response is provided by the server via the 4167 "status_request" extension (see [RFC6066]). 4169 bad_certificate_hash_value Sent by servers when a retrieved object 4170 does not have the correct hash provided by the client via the 4171 "client_certificate_url" extension (see [RFC6066]). 4173 unknown_psk_identity Sent by servers when PSK key establishment is 4174 desired but no acceptable PSK identity is provided by the client. 4175 Sending this alert is OPTIONAL; servers MAY instead choose to send 4176 a "decrypt_error" alert to merely indicate an invalid PSK 4177 identity. 4179 certificate_required Sent by servers when a client certificate is 4180 desired but none was provided by the client. 4182 no_application_protocol Sent by servers when a client 4183 "application_layer_protocol_negotiation" extension advertises only 4184 protocols that the server does not support (see [RFC7301]). 4186 New Alert values are assigned by IANA as described in Section 11. 4188 7. Cryptographic Computations 4190 The TLS handshake establishes one or more input secrets which are 4191 combined to create the actual working keying material, as detailed 4192 below. The key derivation process incorporates both the input 4193 secrets and the handshake transcript. Note that because the 4194 handshake transcript includes the random values from the Hello 4195 messages, any given handshake will have different traffic secrets, 4196 even if the same input secrets are used, as is the case when the same 4197 PSK is used for multiple connections. 4199 7.1. Key Schedule 4201 The key derivation process makes use of the HKDF-Extract and HKDF- 4202 Expand functions as defined for HKDF [RFC5869], as well as the 4203 functions defined below: 4205 HKDF-Expand-Label(Secret, Label, Context, Length) = 4206 HKDF-Expand(Secret, HkdfLabel, Length) 4208 Where HkdfLabel is specified as: 4210 struct { 4211 uint16 length = Length; 4212 opaque label<7..255> = "tls13 " + Label; 4213 opaque context<0..255> = Context; 4214 } HkdfLabel; 4216 Derive-Secret(Secret, Label, Messages) = 4217 HKDF-Expand-Label(Secret, Label, 4218 Transcript-Hash(Messages), Hash.length) 4220 The Hash function used by Transcript-Hash and HKDF is the cipher 4221 suite hash algorithm. Hash.length is its output length in bytes. 4222 Messages are the concatenation of the indicated handshake messages, 4223 including the handshake message type and length fields, but not 4224 including record layer headers. Note that in some cases a zero- 4225 length Context (indicated by "") is passed to HKDF-Expand-Label. The 4226 Labels specified in this document are all ASCII strings, and do not 4227 include a trailing NUL byte. 4229 Note: with common hash functions, any label longer than 12 characters 4230 requires an additional iteration of the hash function to compute. 4231 The labels in this specification have all been chosen to fit within 4232 this limit. 4234 Given a set of n InputSecrets, the final "master secret" is computed 4235 by iteratively invoking HKDF-Extract with InputSecret_1, 4236 InputSecret_2, etc. The initial secret is simply a string of 4237 Hash.length bytes set to zeros. Concretely, for the present version 4238 of TLS 1.3, secrets are added in the following order: 4240 - PSK (a pre-shared key established externally or derived from the 4241 resumption_master_secret value from a previous connection) 4243 - (EC)DHE shared secret (Section 7.4) 4245 This produces a full key derivation schedule shown in the diagram 4246 below. In this diagram, the following formatting conventions apply: 4248 - HKDF-Extract is drawn as taking the Salt argument from the top and 4249 the IKM argument from the left. 4251 - Derive-Secret's Secret argument is indicated by the incoming 4252 arrow. For instance, the Early Secret is the Secret for 4253 generating the client_early_traffic_secret. 4255 0 4256 | 4257 v 4258 PSK -> HKDF-Extract = Early Secret 4259 | 4260 +-----> Derive-Secret(., 4261 | "ext binder" | 4262 | "res binder", 4263 | "") 4264 | = binder_key 4265 | 4266 +-----> Derive-Secret(., "c e traffic", 4267 | ClientHello) 4268 | = client_early_traffic_secret 4269 | 4270 +-----> Derive-Secret(., "e exp master", 4271 | ClientHello) 4272 | = early_exporter_master_secret 4273 v 4274 Derive-Secret(., "derived", "") 4275 | 4276 v 4277 (EC)DHE -> HKDF-Extract = Handshake Secret 4278 | 4279 +-----> Derive-Secret(., "c hs traffic", 4280 | ClientHello...ServerHello) 4281 | = client_handshake_traffic_secret 4282 | 4283 +-----> Derive-Secret(., "s hs traffic", 4284 | ClientHello...ServerHello) 4285 | = server_handshake_traffic_secret 4286 v 4287 Derive-Secret(., "derived", "") 4288 | 4289 v 4290 0 -> HKDF-Extract = Master Secret 4291 | 4292 +-----> Derive-Secret(., "c ap traffic", 4293 | ClientHello...server Finished) 4294 | = client_application_traffic_secret_0 4295 | 4296 +-----> Derive-Secret(., "s ap traffic", 4297 | ClientHello...server Finished) 4298 | = server_application_traffic_secret_0 4299 | 4300 +-----> Derive-Secret(., "exp master", 4301 | ClientHello...server Finished) 4302 | = exporter_master_secret 4303 | 4304 +-----> Derive-Secret(., "res master", 4305 ClientHello...client Finished) 4306 = resumption_master_secret 4308 The general pattern here is that the secrets shown down the left side 4309 of the diagram are just raw entropy without context, whereas the 4310 secrets down the right side include handshake context and therefore 4311 can be used to derive working keys without additional context. Note 4312 that the different calls to Derive-Secret may take different Messages 4313 arguments, even with the same secret. In a 0-RTT exchange, Derive- 4314 Secret is called with four distinct transcripts; in a 1-RTT-only 4315 exchange with three distinct transcripts. 4317 If a given secret is not available, then the 0-value consisting of a 4318 string of Hash.length bytes set to zeros is used. Note that this 4319 does not mean skipping rounds, so if PSK is not in use Early Secret 4320 will still be HKDF-Extract(0, 0). For the computation of the 4321 binder_secret, the label is "ext binder" for external PSKs (those 4322 provisioned outside of TLS) and "res binder" for resumption PSKs 4323 (those provisioned as the resumption master secret of a previous 4324 handshake). The different labels prevent the substitution of one 4325 type of PSK for the other. 4327 There are multiple potential Early Secret values depending on which 4328 PSK the server ultimately selects. The client will need to compute 4329 one for each potential PSK; if no PSK is selected, it will then need 4330 to compute the early secret corresponding to the zero PSK. 4332 Once all the values which are to be derived from a given secret have 4333 been computed, that secret SHOULD be erased. 4335 7.2. Updating Traffic Keys and IVs 4337 Once the handshake is complete, it is possible for either side to 4338 update its sending traffic keys using the KeyUpdate handshake message 4339 defined in Section 4.6.3. The next generation of traffic keys is 4340 computed by generating client_/server_application_traffic_secret_N+1 4341 from client_/server_application_traffic_secret_N as described in this 4342 section then re-deriving the traffic keys as described in 4343 Section 7.3. 4345 The next-generation application_traffic_secret is computed as: 4347 application_traffic_secret_N+1 = 4348 HKDF-Expand-Label(application_traffic_secret_N, 4349 "traffic upd", "", Hash.length) 4351 Once client/server_application_traffic_secret_N+1 and its associated 4352 traffic keys have been computed, implementations SHOULD delete 4353 client_/server_application_traffic_secret_N and its associated 4354 traffic keys. 4356 7.3. Traffic Key Calculation 4358 The traffic keying material is generated from the following input 4359 values: 4361 - A secret value 4363 - A purpose value indicating the specific value being generated 4365 - The length of the key 4367 The traffic keying material is generated from an input traffic secret 4368 value using: 4370 [sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length) 4371 [sender]_write_iv = HKDF-Expand-Label(Secret, "iv" , "", iv_length) 4373 [sender] denotes the sending side. The Secret value for each record 4374 type is shown in the table below. 4376 +-------------------+---------------------------------------+ 4377 | Record Type | Secret | 4378 +-------------------+---------------------------------------+ 4379 | 0-RTT Application | client_early_traffic_secret | 4380 | | | 4381 | Handshake | [sender]_handshake_traffic_secret | 4382 | | | 4383 | Application Data | [sender]_application_traffic_secret_N | 4384 +-------------------+---------------------------------------+ 4386 All the traffic keying material is recomputed whenever the underlying 4387 Secret changes (e.g., when changing from the handshake to application 4388 data keys or upon a key update). 4390 7.4. (EC)DHE Shared Secret Calculation 4391 7.4.1. Finite Field Diffie-Hellman 4393 For finite field groups, a conventional Diffie-Hellman computation is 4394 performed. The negotiated key (Z) is converted to a byte string by 4395 encoding in big-endian and padded with zeros up to the size of the 4396 prime. This byte string is used as the shared secret in the key 4397 schedule as specified above. 4399 Note that this construction differs from previous versions of TLS 4400 which remove leading zeros. 4402 7.4.2. Elliptic Curve Diffie-Hellman 4404 For secp256r1, secp384r1 and secp521r1, ECDH calculations (including 4405 parameter and key generation as well as the shared secret 4406 calculation) are performed according to [IEEE1363] using the ECKAS- 4407 DH1 scheme with the identity map as key derivation function (KDF), so 4408 that the shared secret is the x-coordinate of the ECDH shared secret 4409 elliptic curve point represented as an octet string. Note that this 4410 octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the 4411 Field Element to Octet String Conversion Primitive, has constant 4412 length for any given field; leading zeros found in this octet string 4413 MUST NOT be truncated. 4415 (Note that this use of the identity KDF is a technicality. The 4416 complete picture is that ECDH is employed with a non-trivial KDF 4417 because TLS does not directly use this secret for anything other than 4418 for computing other secrets.) 4420 ECDH functions are used as follows: 4422 - The public key to put into the KeyShareEntry.key_exchange 4423 structure is the result of applying the ECDH scalar multiplication 4424 function to the secret key of appropriate length (into scalar 4425 input) and the standard public basepoint (into u-coordinate point 4426 input). 4428 - The ECDH shared secret is the result of applying the ECDH scalar 4429 multiplication function to the secret key (into scalar input) and 4430 the peer's public key (into u-coordinate point input). The output 4431 is used raw, with no processing. 4433 For X25519 and X448, implementations SHOULD use the approach 4434 specified in [RFC7748] to calculate the Diffie-Hellman shared secret. 4435 Implementations MUST check whether the computed Diffie-Hellman shared 4436 secret is the all-zero value and abort if so, as described in 4437 Section 6 of [RFC7748]. If implementers use an alternative 4438 implementation of these elliptic curves, they SHOULD perform the 4439 additional checks specified in Section 7 of [RFC7748]. 4441 7.5. Exporters 4443 [RFC5705] defines keying material exporters for TLS in terms of the 4444 TLS pseudorandom function (PRF). This document replaces the PRF with 4445 HKDF, thus requiring a new construction. The exporter interface 4446 remains the same. 4448 The exporter value is computed as: 4450 TLS-Exporter(label, context_value, key_length) = 4451 HKDF-Expand-Label(Derive-Secret(Secret, label, ""), 4452 "exporter", Hash(context_value), key_length) 4454 Where Secret is either the early_exporter_master_secret or the 4455 exporter_master_secret. Implementations MUST use the 4456 exporter_master_secret unless explicitly specified by the 4457 application. The early_exporter_master_secret is defined for use in 4458 settings where an exporter is needed for 0-RTT data. A separate 4459 interface for the early exporter is RECOMMENDED, especially on a 4460 server where a single interface can make the early exporter 4461 inaccessible. 4463 If no context is provided, the context_value is zero-length. 4464 Consequently, providing no context computes the same value as 4465 providing an empty context. This is a change from previous versions 4466 of TLS where an empty context produced a different output to an 4467 absent context. As of this document's publication, no allocated 4468 exporter label is used both with and without a context. Future 4469 specifications MUST NOT define a use of exporters that permit both an 4470 empty context and no context with the same label. New uses of 4471 exporters SHOULD provide a context in all exporter computations, 4472 though the value could be empty. 4474 Requirements for the format of exporter labels are defined in section 4475 4 of [RFC5705]. 4477 8. 0-RTT and Anti-Replay 4479 As noted in Section 2.3 and Appendix E.5, TLS does not provide 4480 inherent replay protections for 0-RTT data. There are two potential 4481 threats to be concerned with: 4483 - Network attackers who mount a replay attack by simply duplicating 4484 a flight of 0-RTT data. 4486 - Network attackers who take advantage of client retry behavior to 4487 arrange for the server to receive multiple copies of an 4488 application message. This threat already exists to some extent 4489 because clients that value robustness respond to network errors by 4490 attempting to retry requests. However, 0-RTT adds an additional 4491 dimension for any server system which does not maintain globally 4492 consistent server state. Specifically, if a server system has 4493 multiple zones where tickets from zone A will not be accepted in 4494 zone B, then an attacker can duplicate a ClientHello and early 4495 data intended for A to both A and B. At A, the data will be 4496 accepted in 0-RTT, but at B the server will reject 0-RTT data and 4497 instead force a full handshake. If the attacker blocks the 4498 ServerHello from A, then the client will complete the handshake 4499 with B and probably retry the request, leading to duplication on 4500 the server system as a whole. 4502 The first class of attack can be prevented by sharing state to 4503 guarantee that the 0-RTT data is accepted at most once. Servers 4504 SHOULD provide that level of replay safety, by implementing one of 4505 the methods described in this section or by equivalent means. It is 4506 understood, however, that due to operational concerns not all 4507 deployments will maintain state at that level. Therefore, in normal 4508 operation, clients will not know which, if any, of these mechanisms 4509 servers actually implement and hence MUST only send early data which 4510 they deem safe to be replayed. 4512 In addition to the direct effects of replays, there is a class of 4513 attacks where even operations normally considered idempotent could be 4514 exploited by a large number of replays (timing attacks, resource 4515 limit exhaustion and others described in Appendix E.5). Those can be 4516 mitigated by ensuring that every 0-RTT payload can be replayed only a 4517 limited number of times. The server MUST ensure that any instance of 4518 it (be it a machine, a thread or any other entity within the relevant 4519 serving infrastructure) would accept 0-RTT for the same 0-RTT 4520 handshake at most once; this limits the number of replays to the 4521 number of server instances in the deployment. Such a guarantee can 4522 be accomplished by locally recording data from recently-received 4523 ClientHellos and rejecting repeats, or by any other method that 4524 provides the same or a stronger guarantee. The "at most once per 4525 server instance" guarantee is a minimum requirement; servers SHOULD 4526 limit 0-RTT replays further when feasible. 4528 The second class of attack cannot be prevented at the TLS layer and 4529 MUST be dealt with by any application. Note that any application 4530 whose clients implement any kind of retry behavior already needs to 4531 implement some sort of anti-replay defense. 4533 8.1. Single-Use Tickets 4535 The simplest form of anti-replay defense is for the server to only 4536 allow each session ticket to be used once. For instance, the server 4537 can maintain a database of all outstanding valid tickets; deleting 4538 each ticket from the database as it is used. If an unknown ticket is 4539 provided, the server would then fall back to a full handshake. 4541 If the tickets are not self-contained but rather are database keys, 4542 and the corresponding PSKs are deleted upon use, then connections 4543 established using one PSK enjoy forward secrecy. This improves 4544 security for all 0-RTT data and PSK usage when PSK is used without 4545 (EC)DHE. 4547 Because this mechanism requires sharing the session database between 4548 server nodes in environments with multiple distributed servers, it 4549 may be hard to achieve high rates of successful PSK 0-RTT connections 4550 when compared to self-encrypted tickets. Unlike session databases, 4551 session tickets can successfully do PSK-based session establishment 4552 even without consistent storage, though when 0-RTT is allowed they 4553 still require consistent storage for anti-replay of 0-RTT data, as 4554 detailed in the following section. 4556 8.2. Client Hello Recording 4558 An alternative form of anti-replay is to record a unique value 4559 derived from the ClientHello (generally either the random value or 4560 the PSK binder) and reject duplicates. Recording all ClientHellos 4561 causes state to grow without bound, but a server can instead record 4562 ClientHellos within a given time window and use the 4563 "obfuscated_ticket_age" to ensure that tickets aren't reused outside 4564 that window. 4566 In order to implement this, when a ClientHello is received, the 4567 server first verifies the PSK binder as described Section 4.2.11. It 4568 then computes the expected_arrival_time as described in the next 4569 section and rejects 0-RTT if it is outside the recording window, 4570 falling back to the 1-RTT handshake. 4572 If the expected arrival time is in the window, then the server checks 4573 to see if it has recorded a matching ClientHello. If one is found, 4574 it either aborts the handshake with an "illegal_parameter" alert or 4575 accepts the PSK but reject 0-RTT. If no matching ClientHello is 4576 found, then it accepts 0-RTT and then stores the ClientHello for as 4577 long as the expected_arrival_time is inside the window. Servers MAY 4578 also implement data stores with false positives, such as Bloom 4579 filters, in which case they MUST respond to apparent replay by 4580 rejecting 0-RTT but MUST NOT abort the handshake. 4582 The server MUST derive the storage key only from validated sections 4583 of the ClientHello. If the ClientHello contains multiple PSK 4584 identities, then an attacker can create multiple ClientHellos with 4585 different binder values for the less-preferred identity on the 4586 assumption that the server will not verify it, as recommended by 4587 Section 4.2.11. I.e., if the client sends PSKs A and B but the 4588 server prefers A, then the attacker can change the binder for B 4589 without affecting the binder for A. This will cause the ClientHello 4590 to be accepted, and may cause side effects such as replay cache 4591 pollution, although any 0-RTT data will not be decryptable because it 4592 will use different keys. If the validated binder or the 4593 ClientHello.random are used as the storage key, then this attack is 4594 not possible. 4596 Because this mechanism does not require storing all outstanding 4597 tickets, it may be easier to implement in distributed systems with 4598 high rates of resumption and 0-RTT, at the cost of potentially weaker 4599 anti-replay defense because of the difficulty of reliably storing and 4600 retrieving the received ClientHello messages. In many such systems, 4601 it is impractical to have globally consistent storage of all the 4602 received ClientHellos. In this case, the best anti-replay protection 4603 is provided by having a single storage zone be authoritative for a 4604 given ticket and refusing 0-RTT for that ticket in any other zone. 4605 This approach prevents simple replay by the attacker because only one 4606 zone will accept 0-RTT data. A weaker design is to implement 4607 separate storage for each zone but allow 0-RTT in any zone. This 4608 approach limits the number of replays to once per zone. Application 4609 message duplication of course remains possible with either design. 4611 When implementations are freshly started, they SHOULD reject 0-RTT as 4612 long as any portion of their recording window overlaps the startup 4613 time. Otherwise, they run the risk of accepting replays which were 4614 originally sent during that period. 4616 Note: If the client's clock is running much faster than the server's 4617 then a ClientHello may be received that is outside the window in the 4618 future, in which case it might be accepted for 1-RTT, causing a 4619 client retry, and then acceptable later for 0-RTT. This is another 4620 variant of the second form of attack described above. 4622 8.3. Freshness Checks 4624 Because the ClientHello indicates the time at which the client sent 4625 it, it is possible to efficiently determine whether a ClientHello was 4626 likely sent reasonably recently and only accept 0-RTT for such a 4627 ClientHello, otherwise falling back to a 1-RTT handshake. This is 4628 necessary for the ClientHello storage mechanism described in 4629 Section 8.2 because otherwise the server needs to store an unlimited 4630 number of ClientHellos and is a useful optimization for single-use 4631 tickets because it allows efficient rejection of ClientHellos which 4632 cannot be used for 0-RTT. 4634 In order to implement this mechanism, a server needs to store the 4635 time that the server generated the session ticket, offset by an 4636 estimate of the round trip time between client and server. I.e., 4638 adjusted_creation_time = creation_time + estimated_RTT 4640 This value can be encoded in the ticket, thus avoiding the need to 4641 keep state for each outstanding ticket. The server can determine the 4642 client's view of the age of the ticket by subtracting the ticket's 4643 "ticket_age_add value" from the "obfuscated_ticket_age" parameter in 4644 the client's "pre_shared_key" extension. The server can determine 4645 the "expected arrival time" of the ClientHello as: 4647 expected_arrival_time = adjusted_creation_time + clients_ticket_age 4649 When a new ClientHello is received, the expected_arrival_time is then 4650 compared against the current server wall clock time and if they 4651 differ by more than a certain amount, 0-RTT is rejected, though the 4652 1-RTT handshake can be allowed to complete. 4654 There are several potential sources of error that might cause 4655 mismatches between the expected arrival time and the measured time. 4656 Variations in client and server clock rates are likely to be minimal, 4657 though potentially with gross time corrections. Network propagation 4658 delays are the most likely causes of a mismatch in legitimate values 4659 for elapsed time. Both the NewSessionTicket and ClientHello messages 4660 might be retransmitted and therefore delayed, which might be hidden 4661 by TCP. For clients on the Internet, this implies windows on the 4662 order of ten seconds to account for errors in clocks and variations 4663 in measurements; other deployment scenarios may have different needs. 4664 Clock skew distributions are not symmetric, so the optimal tradeoff 4665 may involve an asymmetric range of permissible mismatch values. 4667 Note that freshness checking alone is not sufficient to prevent 4668 replays because it does not detect them during the error window, 4669 which, depending on bandwidth and system capacity could include 4670 billions of replays in real-world settings. In addition, this 4671 freshness checking is only done at the time the ClientHello is 4672 received, and not when later early application data records are 4673 received. After early data is accepted, records may continue to be 4674 streamed to the server over a longer time period. 4676 9. Compliance Requirements 4678 9.1. Mandatory-to-Implement Cipher Suites 4680 In the absence of an application profile standard specifying 4681 otherwise, a TLS-compliant application MUST implement the 4682 TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the 4683 TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 4684 [RFC7539] cipher suites. (see Appendix B.4) 4686 A TLS-compliant application MUST support digital signatures with 4687 rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for 4688 CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A 4689 TLS-compliant application MUST support key exchange with secp256r1 4690 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. 4692 9.2. Mandatory-to-Implement Extensions 4694 In the absence of an application profile standard specifying 4695 otherwise, a TLS-compliant application MUST implement the following 4696 TLS extensions: 4698 - Supported Versions ("supported_versions"; Section 4.2.1) 4700 - Cookie ("cookie"; Section 4.2.2) 4702 - Signature Algorithms ("signature_algorithms"; Section 4.2.3) 4704 - Signature Algorithms Certificate ("signature_algorithms_cert"; 4705 Section 4.2.3) 4707 - Negotiated Groups ("supported_groups"; Section 4.2.7) 4709 - Key Share ("key_share"; Section 4.2.8) 4711 - Server Name Indication ("server_name"; Section 3 of [RFC6066]) 4713 All implementations MUST send and use these extensions when offering 4714 applicable features: 4716 - "supported_versions" is REQUIRED for all ClientHello, ServerHello 4717 and HelloRetryRequest messages. 4719 - "signature_algorithms" is REQUIRED for certificate authentication. 4721 - "supported_groups" is REQUIRED for ClientHello messages using DHE 4722 or ECDHE key exchange. 4724 - "key_share" is REQUIRED for DHE or ECDHE key exchange. 4726 - "pre_shared_key" is REQUIRED for PSK key agreement. 4728 - "psk_key_exchange_modes" is REQUIRED for PSK key agreement. 4730 A client is considered to be attempting to negotiate using this 4731 specification if the ClientHello contains a "supported_versions" 4732 extension with 0x0304 as the highest version number contained in its 4733 body. Such a ClientHello message MUST meet the following 4734 requirements: 4736 - If not containing a "pre_shared_key" extension, it MUST contain 4737 both a "signature_algorithms" extension and a "supported_groups" 4738 extension. 4740 - If containing a "supported_groups" extension, it MUST also contain 4741 a "key_share" extension, and vice versa. An empty 4742 KeyShare.client_shares vector is permitted. 4744 Servers receiving a ClientHello which does not conform to these 4745 requirements MUST abort the handshake with a "missing_extension" 4746 alert. 4748 Additionally, all implementations MUST support use of the 4749 "server_name" extension with applications capable of using it. 4750 Servers MAY require clients to send a valid "server_name" extension. 4751 Servers requiring this extension SHOULD respond to a ClientHello 4752 lacking a "server_name" extension by terminating the connection with 4753 a "missing_extension" alert. 4755 9.3. Protocol Invariants 4757 This section describes invariants that TLS endpoints and middleboxes 4758 MUST follow. It also applies to earlier versions, which assumed 4759 these rules but did not document them. 4761 TLS is designed to be securely and compatibly extensible. Newer 4762 clients or servers, when communicating with newer peers, SHOULD 4763 negotiate the most preferred common parameters. The TLS handshake 4764 provides downgrade protection: Middleboxes passing traffic between a 4765 newer client and newer server without terminating TLS should be 4766 unable to influence the handshake (see Appendix E.1). At the same 4767 time, deployments update at different rates, so a newer client or 4768 server MAY continue to support older parameters, which would allow it 4769 to interoperate with older endpoints. 4771 For this to work, implementations MUST correctly handle extensible 4772 fields: 4774 - A client sending a ClientHello MUST support all parameters 4775 advertised in it. Otherwise, the server may fail to interoperate 4776 by selecting one of those parameters. 4778 - A server receiving a ClientHello MUST correctly ignore all 4779 unrecognized cipher suites, extensions, and other parameters. 4780 Otherwise, it may fail to interoperate with newer clients. In TLS 4781 1.3, a client receiving a CertificateRequest or NewSessionTicket 4782 MUST also ignore all unrecognized extensions. 4784 - A middlebox which terminates a TLS connection MUST behave as a 4785 compliant TLS server (to the original client), including having a 4786 certificate which the client is willing to accept, and as a 4787 compliant TLS client (to the original server), including verifying 4788 the original server's certificate. In particular, it MUST 4789 generate its own ClientHello containing only parameters it 4790 understands, and it MUST generate a fresh ServerHello random 4791 value, rather than forwarding the endpoint's value. 4793 Note that TLS's protocol requirements and security analysis only 4794 apply to the two connections separately. Safely deploying a TLS 4795 terminator requires additional security considerations which are 4796 beyond the scope of this document. 4798 - An middlebox which forwards ClientHello parameters it does not 4799 understand MUST NOT process any messages beyond that ClientHello. 4800 It MUST forward all subsequent traffic unmodified. Otherwise, it 4801 may fail to interoperate with newer clients and servers. 4803 Forwarded ClientHellos may contain advertisements for features not 4804 supported by the middlebox, so the response may include future TLS 4805 additions the middlebox does not recognize. These additions MAY 4806 change any message beyond the ClientHello arbitrarily. In 4807 particular, the values sent in the ServerHello might change, the 4808 ServerHello format might change, and the TLSCiphertext format 4809 might change. 4811 The design of TLS 1.3 was constrained by widely-deployed non- 4812 compliant TLS middleboxes (see Appendix D.4), however it does not 4813 relax the invariants. Those middleboxes continue to be non- 4814 compliant. 4816 10. Security Considerations 4818 Security issues are discussed throughout this memo, especially in 4819 Appendix C, Appendix D, and Appendix E. 4821 11. IANA Considerations 4823 This document uses several registries that were originally created in 4824 [RFC4346]. IANA has updated these to reference this document. The 4825 registries and their allocation policies are below: 4827 - TLS Cipher Suite Registry: values with the first byte in the range 4828 0-254 (decimal) are assigned via Specification Required [RFC8126]. 4829 Values with the first byte 255 (decimal) are reserved for Private 4830 Use [RFC8126]. 4832 IANA [SHALL add/has added] the cipher suites listed in 4833 Appendix B.4 to the registry. The "Value" and "Description" 4834 columns are taken from the table. The "DTLS-OK" and "Recommended" 4835 columns are both marked as "Yes" for each new cipher suite. 4836 [[This assumes [I-D.ietf-tls-iana-registry-updates] has been 4837 applied.]] 4839 - TLS ContentType Registry: Future values are allocated via 4840 Standards Action [RFC8126]. 4842 - TLS Alert Registry: Future values are allocated via Standards 4843 Action [RFC8126]. IANA [SHALL update/has updated] this registry 4844 to include values for "missing_extension" and 4845 "certificate_required". 4847 - TLS HandshakeType Registry: Future values are allocated via 4848 Standards Action [RFC8126]. IANA [SHALL update/has updated] this 4849 registry to rename item 4 from "NewSessionTicket" to 4850 "new_session_ticket" and to add the 4851 "hello_retry_request_RESERVED", "encrypted_extensions", 4852 "end_of_early_data", "key_update", and "message_hash" values. 4854 This document also uses the TLS ExtensionType Registry originally 4855 created in [RFC4366]. IANA has updated it to reference this 4856 document. The registry and its allocation policy is listed below: 4858 - IANA [SHALL update/has updated] this registry to include the 4859 "key_share", "pre_shared_key", "psk_key_exchange_modes", 4860 "early_data", "cookie", "supported_versions", 4861 "certificate_authorities", "oid_filters", "post_handshake_auth", 4862 and "signature_algorithms_cert", extensions with the values 4863 defined in this document and the Recommended value of "Yes". 4865 - IANA [SHALL update/has updated] this registry to include a "TLS 4866 1.3" column which lists the messages in which the extension may 4867 appear. This column [SHALL be/has been] initially populated from 4868 the table in Section 4.2 with any extension not listed there 4869 marked as "-" to indicate that it is not used by TLS 1.3. 4871 In addition, this document defines a new registry to be maintained by 4872 IANA: 4874 - TLS SignatureScheme Registry: Values with the first byte in the 4875 range 0-253 (decimal) are assigned via Specification Required 4876 [RFC8126]. Values with the first byte 254 or 255 (decimal) are 4877 reserved for Private Use [RFC8126]. Values with the first byte in 4878 the range 0-6 or with the second byte in the range 0-3 that are 4879 not currently allocated are reserved for backwards compatibility. 4880 This registry SHALL have a "Recommended" column. The registry 4881 [shall be/ has been] initially populated with the values described 4882 in Section 4.2.3. The following values SHALL be marked as 4883 "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, 4884 rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. 4886 12. References 4888 12.1. Normative References 4890 [DH] Diffie, W. and M. Hellman, "New Directions in 4891 Cryptography", IEEE Transactions on Information Theory, 4892 V.IT-22 n.6 , June 1977. 4894 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 4895 Operation: Galois/Counter Mode (GCM) and GMAC", 4896 NIST Special Publication 800-38D, November 2007. 4898 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4899 Hashing for Message Authentication", RFC 2104, 4900 DOI 10.17487/RFC2104, February 1997, . 4903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4904 Requirement Levels", BCP 14, RFC 2119, 4905 DOI 10.17487/RFC2119, March 1997, . 4908 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 4909 Housley, R., and W. Polk, "Internet X.509 Public Key 4910 Infrastructure Certificate and Certificate Revocation List 4911 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 4912 . 4914 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 4915 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 4916 March 2010, . 4918 [RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 4919 "Updates for RSAES-OAEP and RSASSA-PSS Algorithm 4920 Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010, 4921 . 4923 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 4924 Key Derivation Function (HKDF)", RFC 5869, 4925 DOI 10.17487/RFC5869, May 2010, . 4928 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 4929 Extensions: Extension Definitions", RFC 6066, 4930 DOI 10.17487/RFC6066, January 2011, . 4933 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 4934 Transport Layer Security (TLS)", RFC 6655, 4935 DOI 10.17487/RFC6655, July 2012, . 4938 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 4939 Galperin, S., and C. Adams, "X.509 Internet Public Key 4940 Infrastructure Online Certificate Status Protocol - OCSP", 4941 RFC 6960, DOI 10.17487/RFC6960, June 2013, 4942 . 4944 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 4945 Multiple Certificate Status Request Extension", RFC 6961, 4946 DOI 10.17487/RFC6961, June 2013, . 4949 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 4950 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 4951 . 4953 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 4954 Algorithm (DSA) and Elliptic Curve Digital Signature 4955 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 4956 2013, . 4958 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 4959 "Transport Layer Security (TLS) Application-Layer Protocol 4960 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 4961 July 2014, . 4963 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 4964 Suite Value (SCSV) for Preventing Protocol Downgrade 4965 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 4966 . 4968 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 4969 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 4970 . 4972 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 4973 for Security", RFC 7748, DOI 10.17487/RFC7748, January 4974 2016, . 4976 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 4977 Ephemeral Parameters for Transport Layer Security (TLS)", 4978 RFC 7919, DOI 10.17487/RFC7919, August 2016, 4979 . 4981 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 4982 "PKCS #1: RSA Cryptography Specifications Version 2.2", 4983 RFC 8017, DOI 10.17487/RFC8017, November 2016, 4984 . 4986 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 4987 Signature Algorithm (EdDSA)", RFC 8032, 4988 DOI 10.17487/RFC8032, January 2017, . 4991 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4992 Writing an IANA Considerations Section in RFCs", BCP 26, 4993 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4994 . 4996 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4997 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4998 May 2017, . 5000 [SHS] Dang, Q., "Secure Hash Standard", National Institute of 5001 Standards and Technology report, 5002 DOI 10.6028/nist.fips.180-4, July 2015. 5004 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 5005 Specification of Basic Encoding Rules (BER), Canonical 5006 Encoding Rules (CER) and Distinguished Encoding Rules 5007 (DER)", ISO/IEC 8825-1:2002, 2002. 5009 [X962] ANSI, "Public Key Cryptography For The Financial Services 5010 Industry: The Elliptic Curve Digital Signature Algorithm 5011 (ECDSA)", ANSI X9.62, 1998. 5013 12.2. Informative References 5015 [AEAD-LIMITS] 5016 Luykx, A. and K. Paterson, "Limits on Authenticated 5017 Encryption Use in TLS", 2016, 5018 . 5020 [BBFKZG16] 5021 Bhargavan, K., Brzuska, C., Fournet, C., Kohlweiss, M., 5022 Zanella-Beguelin, S., and M. Green, "Downgrade Resilience 5023 in Key-Exchange Protocols", Proceedings of IEEE Symposium 5024 on Security and Privacy (Oakland) 2016 , 2016. 5026 [BBK17] Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified 5027 Models and Reference Implementations for the TLS 1.3 5028 Standard Candidate", Proceedings of IEEE Symposium on 5029 Security and Privacy (Oakland) 2017 , 2017. 5031 [BDFKPPRSZZ16] 5032 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., 5033 Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy, 5034 N., Zanella-Beguelin, S., and J. Zinzindohoue, 5035 "Implementing and Proving the TLS 1.3 Record Layer", 5036 Proceedings of IEEE Symposium on Security and Privacy 5037 (Oakland) 2017 , December 2016, 5038 . 5040 [Ben17a] Benjamin, D., "Presentation before the TLS WG at IETF 5041 100", 2017, 5042 . 5045 [Ben17b] Benjamin, D., "Additional TLS 1.3 results from Chrome", 5046 2017, . 5049 [BMMT15] Badertscher, C., Matt, C., Maurer, U., and B. Tackmann, 5050 "Augmented Secure Channels and the Goal of the TLS 1.3 5051 Record Layer", ProvSec 2015 , September 2015, 5052 . 5054 [BT16] Bellare, M. and B. Tackmann, "The Multi-User Security of 5055 Authenticated Encryption: AES-GCM in TLS 1.3", Proceedings 5056 of CRYPTO 2016 , 2016, . 5058 [CCG16] Cohn-Gordon, K., Cremers, C., and L. Garratt, "On Post- 5059 Compromise Security", IEEE Computer Security Foundations 5060 Symposium , 2015. 5062 [CHECKOWAY] 5063 Checkoway, S., Shacham, H., Maskiewicz, J., Garman, C., 5064 Fried, J., Cohney, S., Green, M., Heninger, N., Weinmann, 5065 R., and E. Rescorla, "A Systematic Analysis of the Juniper 5066 Dual EC Incident", Proceedings of the 2016 ACM SIGSAC 5067 Conference on Computer and Communications Security 5068 - CCS'16, DOI 10.1145/2976749.2978395, 2016. 5070 [CHHSV17] Cremers, C., Horvat, M., Hoyland, J., van der Merwe, T., 5071 and S. Scott, "Awkward Handshake: Possible mismatch of 5072 client/server view on client authentication in post- 5073 handshake mode in Revision 18", 2017, 5074 . 5077 [CHSV16] Cremers, C., Horvat, M., Scott, S., and T. van der Merwe, 5078 "Automated Analysis and Verification of TLS 1.3: 0-RTT, 5079 Resumption and Delayed Authentication", Proceedings of 5080 IEEE Symposium on Security and Privacy (Oakland) 2016 , 5081 2016, . 5083 [CK01] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange 5084 Protocols and Their Use for Building Secure Channels", 5085 Proceedings of Eurocrypt 2001 , 2001. 5087 [CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know 5088 Why You Went to the Clinic: Risks and Realization of HTTPS 5089 Traffic Analysis", Privacy Enhancing Technologies pp. 5090 143-163, DOI 10.1007/978-3-319-08506-7_8, 2014. 5092 [DFGS15] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, 5093 "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and 5094 Pre-shared Key Handshake Protocol", Proceedings of ACM CCS 5095 2015 , 2015, . 5097 [DFGS16] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, 5098 "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and 5099 Pre-shared Key Handshake Protocol", TRON 2016 , 2016, 5100 . 5102 [DOW92] Diffie, W., van Oorschot, P., and M. Wiener, 5103 ""Authentication and authenticated key exchanges"", 5104 Designs, Codes and Cryptography , 1992. 5106 [DSS] National Institute of Standards and Technology, U.S. 5107 Department of Commerce, "Digital Signature Standard, 5108 version 4", NIST FIPS PUB 186-4, 2013. 5110 [ECDSA] American National Standards Institute, "Public Key 5111 Cryptography for the Financial Services Industry: The 5112 Elliptic Curve Digital Signature Algorithm (ECDSA)", 5113 ANSI ANS X9.62-2005, November 2005. 5115 [FG17] Fischlin, M. and F. Guenther, "Replay Attacks on Zero 5116 Round-Trip Time: The Case of the TLS 1.3 Handshake 5117 Candidates", Proceedings of Euro S"P 2017 , 2017, 5118 . 5120 [FGSW16] Fischlin, M., Guenther, F., Schmidt, B., and B. Warinschi, 5121 "Key Confirmation in Key Exchange: A Formal Treatment and 5122 Implications for TLS 1.3", Proceedings of IEEE Symposium 5123 on Security and Privacy (Oakland) 2016 , 2016, 5124 . 5126 [FW15] Florian Weimer, ., "Factoring RSA Keys With TLS Perfect 5127 Forward Secrecy", September 2015. 5129 [HCJ16] Husak, M., Čermak, M., Jirsik, T., and P. 5130 Čeleda, "HTTPS traffic analysis and client 5131 identification using passive SSL/TLS fingerprinting", 5132 EURASIP Journal on Information Security Vol. 2016, 5133 DOI 10.1186/s13635-016-0030-7, February 2016. 5135 [HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes, 5136 "Prying Open Pandora's Box: KCI Attacks against TLS", 5137 Proceedings of USENIX Workshop on Offensive Technologies , 5138 2015. 5140 [I-D.ietf-tls-iana-registry-updates] 5141 Salowey, J. and S. Turner, "IANA Registry Updates for TLS 5142 and DTLS", draft-ietf-tls-iana-registry-updates-03 (work 5143 in progress), January 2018. 5145 [I-D.ietf-tls-tls13-vectors] 5146 Thomson, M., "Example Handshake Traces for TLS 1.3", 5147 draft-ietf-tls-tls13-vectors-03 (work in progress), 5148 December 2017. 5150 [IEEE1363] 5151 IEEE, "Standard Specifications for Public Key 5152 Cryptography", IEEE 1363 , 2000. 5154 [JSS15] Jager, T., Schwenk, J., and J. Somorovsky, "On the 5155 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 5156 v1.5 Encryption", Proceedings of ACM CCS 2015 , 2015, 5157 . 5160 [KEYAGREEMENT] 5161 Barker, E., Chen, L., Roginsky, A., and M. Smid, 5162 "Recommendation for Pair-Wise Key Establishment Schemes 5163 Using Discrete Logarithm Cryptography", National Institute 5164 of Standards and Technology report, 5165 DOI 10.6028/nist.sp.800-56ar2, May 2013. 5167 [Kraw10] Krawczyk, H., "Cryptographic Extraction and Key 5168 Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 , 5169 2010, . 5171 [Kraw16] Krawczyk, H., "A Unilateral-to-Mutual Authentication 5172 Compiler for Key Exchange (with Applications to Client 5173 Authentication in TLS 1.3", Proceedings of ACM CCS 2016 , 5174 2016, . 5176 [KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", 5177 Proceedings of Euro S"P 2016 , 2016, 5178 . 5180 [LXZFH16] Li, X., Xu, J., Feng, D., Zhang, Z., and H. Hu, "Multiple 5181 Handshakes Security of TLS 1.3 Candidates", Proceedings of 5182 IEEE Symposium on Security and Privacy (Oakland) 2016 , 5183 2016, . 5185 [Mac17] MacCarthaigh, C., "Security Review of TLS1.3 0-RTT", 2017, 5186 . 5188 [PSK-FINISHED] 5189 Cremers, C., Horvat, M., van der Merwe, T., and S. Scott, 5190 "Revision 10: possible attack if client authentication is 5191 allowed during PSK", 2015, . 5194 [REKEY] Abdalla, M. and M. Bellare, "Increasing the Lifetime of a 5195 Key: A Comparative Analysis of the Security of Re-keying 5196 Techniques", ASIACRYPT2000 , October 2000. 5198 [Res17a] Rescorla, E., "Preliminary data on Firefox TLS 1.3 5199 Middlebox experiment", 2017, . 5202 [Res17b] Rescorla, E., "More compatibility measurement results", 5203 2017, . 5206 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 5207 Text on Security Considerations", BCP 72, RFC 3552, 5208 DOI 10.17487/RFC3552, July 2003, . 5211 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 5212 "Randomness Requirements for Security", BCP 106, RFC 4086, 5213 DOI 10.17487/RFC4086, June 2005, . 5216 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 5217 (TLS) Protocol Version 1.1", RFC 4346, 5218 DOI 10.17487/RFC4346, April 2006, . 5221 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 5222 and T. Wright, "Transport Layer Security (TLS) 5223 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 5224 . 5226 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 5227 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 5228 for Transport Layer Security (TLS)", RFC 4492, 5229 DOI 10.17487/RFC4492, May 2006, . 5232 [RFC4681] Santesson, S., Medvinsky, A., and J. Ball, "TLS User 5233 Mapping Extension", RFC 4681, DOI 10.17487/RFC4681, 5234 October 2006, . 5236 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 5237 "Transport Layer Security (TLS) Session Resumption without 5238 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 5239 January 2008, . 5241 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 5242 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 5243 . 5245 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 5246 (TLS) Protocol Version 1.2", RFC 5246, 5247 DOI 10.17487/RFC5246, August 2008, . 5250 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 5251 Security (DTLS) Extension to Establish Keys for the Secure 5252 Real-time Transport Protocol (SRTP)", RFC 5764, 5253 DOI 10.17487/RFC5764, May 2010, . 5256 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 5257 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 5258 . 5260 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 5261 for Transport Layer Security (TLS) Authentication", 5262 RFC 6091, DOI 10.17487/RFC6091, February 2011, 5263 . 5265 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 5266 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 5267 2011, . 5269 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 5270 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 5271 January 2012, . 5273 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 5274 Layer Security (TLS) and Datagram Transport Layer Security 5275 (DTLS) Heartbeat Extension", RFC 6520, 5276 DOI 10.17487/RFC6520, February 2012, . 5279 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 5280 Protocol (HTTP/1.1): Message Syntax and Routing", 5281 RFC 7230, DOI 10.17487/RFC7230, June 2014, 5282 . 5284 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 5285 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 5286 Transport Layer Security (TLS) and Datagram Transport 5287 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 5288 June 2014, . 5290 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 5291 DOI 10.17487/RFC7465, February 2015, . 5294 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 5295 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 5296 DOI 10.17487/RFC7568, June 2015, . 5299 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 5300 Langley, A., and M. Ray, "Transport Layer Security (TLS) 5301 Session Hash and Extended Master Secret Extension", 5302 RFC 7627, DOI 10.17487/RFC7627, September 2015, 5303 . 5305 [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello 5306 Padding Extension", RFC 7685, DOI 10.17487/RFC7685, 5307 October 2015, . 5309 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 5310 (TLS) Cached Information Extension", RFC 7924, 5311 DOI 10.17487/RFC7924, July 2016, . 5314 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 5315 Better Connectivity Using Concurrency", RFC 8305, 5316 DOI 10.17487/RFC8305, December 2017, . 5319 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 5320 Obtaining Digital Signatures and Public-Key 5321 Cryptosystems", Communications of the ACM v. 21, n. 2, pp. 5322 120-126., February 1978. 5324 [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' approach to 5325 authenticated Diffie-Hellman and its use in the IKE 5326 protocols", Proceedings of CRYPTO 2003 , 2003. 5328 [SLOTH] Bhargavan, K. and G. Leurent, "Transcript Collision 5329 Attacks: Breaking Authentication in TLS, IKE, and SSH", 5330 Network and Distributed System Security Symposium (NDSS 5331 2016) , 2016. 5333 [SSL2] Hickman, K., "The SSL Protocol", February 1995. 5335 [SSL3] Freier, A., Karlton, P., and P. Kocher, "The SSL 3.0 5336 Protocol", November 1996. 5338 [TIMING] Boneh, D. and D. Brumley, "Remote timing attacks are 5339 practical", USENIX Security Symposium, 2003. 5341 [X501] "Information Technology - Open Systems Interconnection - 5342 The Directory: Models", ITU-T X.501, 1993. 5344 12.3. URIs 5346 [1] mailto:tls@ietf.org 5348 Appendix A. State Machine 5350 This section provides a summary of the legal state transitions for 5351 the client and server handshakes. State names (in all capitals, 5352 e.g., START) have no formal meaning but are provided for ease of 5353 comprehension. Actions which are taken only in certain circumstances 5354 are indicated in []. The notation "K_{send,recv} = foo" means "set 5355 the send/recv key to the given key". 5357 A.1. Client 5359 START <----+ 5360 Send ClientHello | | Recv HelloRetryRequest 5361 [K_send = early data] | | 5362 v | 5363 / WAIT_SH ----+ 5364 | | Recv ServerHello 5365 | | K_recv = handshake 5366 Can | V 5367 send | WAIT_EE 5368 early | | Recv EncryptedExtensions 5369 data | +--------+--------+ 5370 | Using | | Using certificate 5371 | PSK | v 5372 | | WAIT_CERT_CR 5373 | | Recv | | Recv CertificateRequest 5374 | | Certificate | v 5375 | | | WAIT_CERT 5376 | | | | Recv Certificate 5377 | | v v 5378 | | WAIT_CV 5379 | | | Recv CertificateVerify 5380 | +> WAIT_FINISHED <+ 5381 | | Recv Finished 5382 \ | [Send EndOfEarlyData] 5383 | K_send = handshake 5384 | [Send Certificate [+ CertificateVerify]] 5385 Can send | Send Finished 5386 app data --> | K_send = K_recv = application 5387 after here v 5388 CONNECTED 5390 Note that with the transitions as shown above, clients may send 5391 alerts that derive from post-ServerHello messages in the clear or 5392 with the early data keys. If clients need to send such alerts, they 5393 SHOULD first rekey to the handshake keys if possible. 5395 A.2. Server 5397 START <-----+ 5398 Recv ClientHello | | Send HelloRetryRequest 5399 v | 5400 RECVD_CH ----+ 5401 | Select parameters 5402 v 5403 NEGOTIATED 5404 | Send ServerHello 5405 | K_send = handshake 5406 | Send EncryptedExtensions 5407 | [Send CertificateRequest] 5408 Can send | [Send Certificate + CertificateVerify] 5409 app data | Send Finished 5410 after --> | K_send = application 5411 here +--------+--------+ 5412 No 0-RTT | | 0-RTT 5413 | | 5414 K_recv = handshake | | K_recv = early data 5415 [Skip decrypt errors] | +------> WAIT_EOED -+ 5416 | | Recv | | Recv EndOfEarlyData 5417 | | early data | | K_recv = handshake 5418 | +------------+ | 5419 | | 5420 +> WAIT_FLIGHT2 <--------+ 5421 | 5422 +--------+--------+ 5423 No auth | | Client auth 5424 | | 5425 | v 5426 | WAIT_CERT 5427 | Recv | | Recv Certificate 5428 | empty | v 5429 | Certificate | WAIT_CV 5430 | | | Recv 5431 | v | CertificateVerify 5432 +-> WAIT_FINISHED <---+ 5433 | Recv Finished 5434 | K_recv = application 5435 v 5436 CONNECTED 5438 Appendix B. Protocol Data Structures and Constant Values 5440 This section describes protocol types and constants. Values listed 5441 as _RESERVED were used in previous versions of TLS and are listed 5442 here for completeness. TLS 1.3 implementations MUST NOT send them 5443 but might receive them from older TLS implementations. 5445 B.1. Record Layer 5447 enum { 5448 invalid(0), 5449 change_cipher_spec(20), 5450 alert(21), 5451 handshake(22), 5452 application_data(23), 5453 (255) 5454 } ContentType; 5456 struct { 5457 ContentType type; 5458 ProtocolVersion legacy_record_version; 5459 uint16 length; 5460 opaque fragment[TLSPlaintext.length]; 5461 } TLSPlaintext; 5463 struct { 5464 opaque content[TLSPlaintext.length]; 5465 ContentType type; 5466 uint8 zeros[length_of_padding]; 5467 } TLSInnerPlaintext; 5469 struct { 5470 ContentType opaque_type = application_data; /* 23 */ 5471 ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */ 5472 uint16 length; 5473 opaque encrypted_record[TLSCiphertext.length]; 5474 } TLSCiphertext; 5476 B.2. Alert Messages 5477 enum { warning(1), fatal(2), (255) } AlertLevel; 5479 enum { 5480 close_notify(0), 5481 unexpected_message(10), 5482 bad_record_mac(20), 5483 decryption_failed_RESERVED(21), 5484 record_overflow(22), 5485 decompression_failure_RESERVED(30), 5486 handshake_failure(40), 5487 no_certificate_RESERVED(41), 5488 bad_certificate(42), 5489 unsupported_certificate(43), 5490 certificate_revoked(44), 5491 certificate_expired(45), 5492 certificate_unknown(46), 5493 illegal_parameter(47), 5494 unknown_ca(48), 5495 access_denied(49), 5496 decode_error(50), 5497 decrypt_error(51), 5498 export_restriction_RESERVED(60), 5499 protocol_version(70), 5500 insufficient_security(71), 5501 internal_error(80), 5502 inappropriate_fallback(86), 5503 user_canceled(90), 5504 no_renegotiation_RESERVED(100), 5505 missing_extension(109), 5506 unsupported_extension(110), 5507 certificate_unobtainable(111), 5508 unrecognized_name(112), 5509 bad_certificate_status_response(113), 5510 bad_certificate_hash_value(114), 5511 unknown_psk_identity(115), 5512 certificate_required(116), 5513 no_application_protocol(120), 5514 (255) 5515 } AlertDescription; 5517 struct { 5518 AlertLevel level; 5519 AlertDescription description; 5520 } Alert; 5522 B.3. Handshake Protocol 5524 enum { 5525 hello_request_RESERVED(0), 5526 client_hello(1), 5527 server_hello(2), 5528 hello_verify_request_RESERVED(3), 5529 new_session_ticket(4), 5530 end_of_early_data(5), 5531 hello_retry_request_RESERVED(6), 5532 encrypted_extensions(8), 5533 certificate(11), 5534 server_key_exchange_RESERVED(12), 5535 certificate_request(13), 5536 server_hello_done_RESERVED(14), 5537 certificate_verify(15), 5538 client_key_exchange_RESERVED(16), 5539 finished(20), 5540 key_update(24), 5541 message_hash(254), 5542 (255) 5543 } HandshakeType; 5545 struct { 5546 HandshakeType msg_type; /* handshake type */ 5547 uint24 length; /* bytes in message */ 5548 select (Handshake.msg_type) { 5549 case client_hello: ClientHello; 5550 case server_hello: ServerHello; 5551 case end_of_early_data: EndOfEarlyData; 5552 case encrypted_extensions: EncryptedExtensions; 5553 case certificate_request: CertificateRequest; 5554 case certificate: Certificate; 5555 case certificate_verify: CertificateVerify; 5556 case finished: Finished; 5557 case new_session_ticket: NewSessionTicket; 5558 case key_update: KeyUpdate; 5559 }; 5560 } Handshake; 5562 B.3.1. Key Exchange Messages 5564 uint16 ProtocolVersion; 5565 opaque Random[32]; 5567 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 5569 struct { 5570 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 5571 Random random; 5572 opaque legacy_session_id<0..32>; 5573 CipherSuite cipher_suites<2..2^16-2>; 5574 opaque legacy_compression_methods<1..2^8-1>; 5575 Extension extensions<8..2^16-1>; 5576 } ClientHello; 5578 struct { 5579 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 5580 Random random; 5581 opaque legacy_session_id_echo<0..32>; 5582 CipherSuite cipher_suite; 5583 uint8 legacy_compression_method = 0; 5584 Extension extensions<6..2^16-1>; 5585 } ServerHello; 5587 struct { 5588 ExtensionType extension_type; 5589 opaque extension_data<0..2^16-1>; 5590 } Extension; 5592 enum { 5593 server_name(0), /* RFC 6066 */ 5594 max_fragment_length(1), /* RFC 6066 */ 5595 status_request(5), /* RFC 6066 */ 5596 supported_groups(10), /* RFC 4492, 7919 */ 5597 signature_algorithms(13), /* [[this document]] */ 5598 use_srtp(14), /* RFC 5764 */ 5599 heartbeat(15), /* RFC 6520 */ 5600 application_layer_protocol_negotiation(16), /* RFC 7301 */ 5601 signed_certificate_timestamp(18), /* RFC 6962 */ 5602 client_certificate_type(19), /* RFC 7250 */ 5603 server_certificate_type(20), /* RFC 7250 */ 5604 padding(21), /* RFC 7685 */ 5605 RESERVED(40), /* Used but never assigned */ 5606 pre_shared_key(41), /* [[this document]] */ 5607 early_data(42), /* [[this document]] */ 5608 supported_versions(43), /* [[this document]] */ 5609 cookie(44), /* [[this document]] */ 5610 psk_key_exchange_modes(45), /* [[this document]] */ 5611 RESERVED(46), /* Used but never assigned */ 5612 certificate_authorities(47), /* [[this document]] */ 5613 oid_filters(48), /* [[this document]] */ 5614 post_handshake_auth(49), /* [[this document]] */ 5615 signature_algorithms_cert(50), /* [[this document]] */ 5616 key_share(51), /* [[this document]] */ 5617 (65535) 5619 } ExtensionType; 5621 struct { 5622 NamedGroup group; 5623 opaque key_exchange<1..2^16-1>; 5624 } KeyShareEntry; 5626 struct { 5627 KeyShareEntry client_shares<0..2^16-1>; 5628 } KeyShareClientHello; 5630 struct { 5631 NamedGroup selected_group; 5632 } KeyShareHelloRetryRequest; 5634 struct { 5635 KeyShareEntry server_share; 5636 } KeyShareServerHello; 5638 struct { 5639 uint8 legacy_form = 4; 5640 opaque X[coordinate_length]; 5641 opaque Y[coordinate_length]; 5642 } UncompressedPointRepresentation; 5644 enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; 5646 struct { 5647 PskKeyExchangeMode ke_modes<1..255>; 5648 } PskKeyExchangeModes; 5650 struct {} Empty; 5652 struct { 5653 select (Handshake.msg_type) { 5654 case new_session_ticket: uint32 max_early_data_size; 5655 case client_hello: Empty; 5656 case encrypted_extensions: Empty; 5657 }; 5658 } EarlyDataIndication; 5660 struct { 5661 opaque identity<1..2^16-1>; 5662 uint32 obfuscated_ticket_age; 5663 } PskIdentity; 5665 opaque PskBinderEntry<32..255>; 5666 struct { 5667 PskIdentity identities<7..2^16-1>; 5668 PskBinderEntry binders<33..2^16-1>; 5669 } OfferedPsks; 5671 struct { 5672 select (Handshake.msg_type) { 5673 case client_hello: OfferedPsks; 5674 case server_hello: uint16 selected_identity; 5675 }; 5676 } PreSharedKeyExtension; 5678 B.3.1.1. Version Extension 5680 struct { 5681 select (Handshake.msg_type) { 5682 case client_hello: 5683 ProtocolVersion versions<2..254>; 5685 case server_hello: /* and HelloRetryRequest */ 5686 ProtocolVersion selected_version; 5687 }; 5688 } SupportedVersions; 5690 B.3.1.2. Cookie Extension 5692 struct { 5693 opaque cookie<1..2^16-1>; 5694 } Cookie; 5696 B.3.1.3. Signature Algorithm Extension 5697 enum { 5698 /* RSASSA-PKCS1-v1_5 algorithms */ 5699 rsa_pkcs1_sha256(0x0401), 5700 rsa_pkcs1_sha384(0x0501), 5701 rsa_pkcs1_sha512(0x0601), 5703 /* ECDSA algorithms */ 5704 ecdsa_secp256r1_sha256(0x0403), 5705 ecdsa_secp384r1_sha384(0x0503), 5706 ecdsa_secp521r1_sha512(0x0603), 5708 /* RSASSA-PSS algorithms with public key OID rsaEncryption */ 5709 rsa_pss_rsae_sha256(0x0804), 5710 rsa_pss_rsae_sha384(0x0805), 5711 rsa_pss_rsae_sha512(0x0806), 5713 /* EdDSA algorithms */ 5714 ed25519(0x0807), 5715 ed448(0x0808), 5717 /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */ 5718 rsa_pss_pss_sha256(0x0809), 5719 rsa_pss_pss_sha384(0x080a), 5720 rsa_pss_pss_sha512(0x080b), 5722 /* Legacy algorithms */ 5723 rsa_pkcs1_sha1(0x0201), 5724 ecdsa_sha1(0x0203), 5726 /* Reserved Code Points */ 5727 obsolete_RESERVED(0x0000..0x0200), 5728 dsa_sha1_RESERVED(0x0202), 5729 obsolete_RESERVED(0x0204..0x0400), 5730 dsa_sha256_RESERVED(0x0402), 5731 obsolete_RESERVED(0x0404..0x0500), 5732 dsa_sha384_RESERVED(0x0502), 5733 obsolete_RESERVED(0x0504..0x0600), 5734 dsa_sha512_RESERVED(0x0602), 5735 obsolete_RESERVED(0x0604..0x06FF), 5736 private_use(0xFE00..0xFFFF), 5737 (0xFFFF) 5738 } SignatureScheme; 5740 struct { 5741 SignatureScheme supported_signature_algorithms<2..2^16-2>; 5742 } SignatureSchemeList; 5744 B.3.1.4. Supported Groups Extension 5746 enum { 5747 unallocated_RESERVED(0x0000), 5749 /* Elliptic Curve Groups (ECDHE) */ 5750 obsolete_RESERVED(0x0001..0x0016), 5751 secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), 5752 obsolete_RESERVED(0x001A..0x001C), 5753 x25519(0x001D), x448(0x001E), 5755 /* Finite Field Groups (DHE) */ 5756 ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), 5757 ffdhe6144(0x0103), ffdhe8192(0x0104), 5759 /* Reserved Code Points */ 5760 ffdhe_private_use(0x01FC..0x01FF), 5761 ecdhe_private_use(0xFE00..0xFEFF), 5762 obsolete_RESERVED(0xFF01..0xFF02), 5763 (0xFFFF) 5764 } NamedGroup; 5766 struct { 5767 NamedGroup named_group_list<2..2^16-1>; 5768 } NamedGroupList; 5770 Values within "obsolete_RESERVED" ranges are used in previous 5771 versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 5772 implementations. The obsolete curves have various known/theoretical 5773 weaknesses or have had very little usage, in some cases only due to 5774 unintentional server configuration issues. They are no longer 5775 considered appropriate for general use and should be assumed to be 5776 potentially unsafe. The set of curves specified here is sufficient 5777 for interoperability with all currently deployed and properly 5778 configured TLS implementations. 5780 B.3.2. Server Parameters Messages 5781 opaque DistinguishedName<1..2^16-1>; 5783 struct { 5784 DistinguishedName authorities<3..2^16-1>; 5785 } CertificateAuthoritiesExtension; 5787 struct { 5788 opaque certificate_extension_oid<1..2^8-1>; 5789 opaque certificate_extension_values<0..2^16-1>; 5790 } OIDFilter; 5792 struct { 5793 OIDFilter filters<0..2^16-1>; 5794 } OIDFilterExtension; 5796 struct {} PostHandshakeAuth; 5798 struct { 5799 Extension extensions<0..2^16-1>; 5800 } EncryptedExtensions; 5802 struct { 5803 opaque certificate_request_context<0..2^8-1>; 5804 Extension extensions<2..2^16-1>; 5805 } CertificateRequest; 5807 B.3.3. Authentication Messages 5808 enum { 5809 X509(0), 5810 OpenPGP_RESERVED(1), 5811 RawPublicKey(2), 5812 (255) 5813 } CertificateType; 5815 struct { 5816 select (certificate_type) { 5817 case RawPublicKey: 5818 /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ 5819 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 5821 case X509: 5822 opaque cert_data<1..2^24-1>; 5823 }; 5824 Extension extensions<0..2^16-1>; 5825 } CertificateEntry; 5827 struct { 5828 opaque certificate_request_context<0..2^8-1>; 5829 CertificateEntry certificate_list<0..2^24-1>; 5830 } Certificate; 5832 struct { 5833 SignatureScheme algorithm; 5834 opaque signature<0..2^16-1>; 5835 } CertificateVerify; 5837 struct { 5838 opaque verify_data[Hash.length]; 5839 } Finished; 5841 B.3.4. Ticket Establishment 5843 struct { 5844 uint32 ticket_lifetime; 5845 uint32 ticket_age_add; 5846 opaque ticket_nonce<0..255>; 5847 opaque ticket<1..2^16-1>; 5848 Extension extensions<0..2^16-2>; 5849 } NewSessionTicket; 5851 B.3.5. Updating Keys 5852 struct {} EndOfEarlyData; 5854 enum { 5855 update_not_requested(0), update_requested(1), (255) 5856 } KeyUpdateRequest; 5858 struct { 5859 KeyUpdateRequest request_update; 5860 } KeyUpdate; 5862 B.4. Cipher Suites 5864 A symmetric cipher suite defines the pair of the AEAD algorithm and 5865 hash algorithm to be used with HKDF. Cipher suite names follow the 5866 naming convention: 5868 CipherSuite TLS_AEAD_HASH = VALUE; 5870 +-----------+------------------------------------------------+ 5871 | Component | Contents | 5872 +-----------+------------------------------------------------+ 5873 | TLS | The string "TLS" | 5874 | | | 5875 | AEAD | The AEAD algorithm used for record protection | 5876 | | | 5877 | HASH | The hash algorithm used with HKDF | 5878 | | | 5879 | VALUE | The two byte ID assigned for this cipher suite | 5880 +-----------+------------------------------------------------+ 5882 This specification defines the following cipher suites for use with 5883 TLS 1.3. 5885 +------------------------------+-------------+ 5886 | Description | Value | 5887 +------------------------------+-------------+ 5888 | TLS_AES_128_GCM_SHA256 | {0x13,0x01} | 5889 | | | 5890 | TLS_AES_256_GCM_SHA384 | {0x13,0x02} | 5891 | | | 5892 | TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} | 5893 | | | 5894 | TLS_AES_128_CCM_SHA256 | {0x13,0x04} | 5895 | | | 5896 | TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} | 5897 +------------------------------+-------------+ 5899 The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, 5900 and AEAD_AES_128_CCM are defined in [RFC5116]. 5901 AEAD_CHACHA20_POLY1305 is defined in [RFC7539]. AEAD_AES_128_CCM_8 5902 is defined in [RFC6655]. The corresponding hash algorithms are 5903 defined in [SHS]. 5905 Although TLS 1.3 uses the same cipher suite space as previous 5906 versions of TLS, TLS 1.3 cipher suites are defined differently, only 5907 specifying the symmetric ciphers, and cannot be used for TLS 1.2. 5908 Similarly, TLS 1.2 and lower cipher suites cannot be used with TLS 5909 1.3. 5911 New cipher suite values are assigned by IANA as described in 5912 Section 11. 5914 Appendix C. Implementation Notes 5916 The TLS protocol cannot prevent many common security mistakes. This 5917 section provides several recommendations to assist implementors. 5918 [I-D.ietf-tls-tls13-vectors] provides test vectors for TLS 1.3 5919 handshakes. 5921 C.1. Random Number Generation and Seeding 5923 TLS requires a cryptographically secure pseudorandom number generator 5924 (CSPRNG). In most cases, the operating system provides an 5925 appropriate facility such as /dev/urandom, which should be used 5926 absent other (performance) concerns. It is RECOMMENDED to use an 5927 existing CSPRNG implementation in preference to crafting a new one. 5928 Many adequate cryptographic libraries are already available under 5929 favorable license terms. Should those prove unsatisfactory, 5930 [RFC4086] provides guidance on the generation of random values. 5932 TLS uses random values both in public protocol fields such as the 5933 public Random values in the ClientHello and ServerHello and to 5934 generate keying material. With a properly functioning CSPRNG, this 5935 does not present a security problem as it is not feasible to 5936 determine the CSPRNG state from its output. However, with a broken 5937 CSPRNG, it may be possible for an attacker to use the public output 5938 to determine the CSPRNG internal state and thereby predict the keying 5939 material, as documented in [CHECKOWAY]. Implementations can provide 5940 extra security against this form of attack by using separate CSPRNGs 5941 to generate public and private values. 5943 C.2. Certificates and Authentication 5945 Implementations are responsible for verifying the integrity of 5946 certificates and should generally support certificate revocation 5947 messages. Absent a specific indication from an application profile, 5948 Certificates should always be verified to ensure proper signing by a 5949 trusted Certificate Authority (CA). The selection and addition of 5950 trust anchors should be done very carefully. Users should be able to 5951 view information about the certificate and trust anchor. 5952 Applications SHOULD also enforce minimum and maximum key sizes. For 5953 example, certification paths containing keys or signatures weaker 5954 than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure 5955 applications. 5957 C.3. Implementation Pitfalls 5959 Implementation experience has shown that certain parts of earlier TLS 5960 specifications are not easy to understand and have been a source of 5961 interoperability and security problems. Many of these areas have 5962 been clarified in this document but this appendix contains a short 5963 list of the most important things that require special attention from 5964 implementors. 5966 TLS protocol issues: 5968 - Do you correctly handle handshake messages that are fragmented to 5969 multiple TLS records (see Section 5.1)? Including corner cases 5970 like a ClientHello that is split to several small fragments? Do 5971 you fragment handshake messages that exceed the maximum fragment 5972 size? In particular, the Certificate and CertificateRequest 5973 handshake messages can be large enough to require fragmentation. 5975 - Do you ignore the TLS record layer version number in all 5976 unencrypted TLS records? (see Appendix D) 5978 - Have you ensured that all support for SSL, RC4, EXPORT ciphers, 5979 and MD5 (via the "signature_algorithms" extension) is completely 5980 removed from all possible configurations that support TLS 1.3 or 5981 later, and that attempts to use these obsolete capabilities fail 5982 correctly? (see Appendix D) 5984 - Do you handle TLS extensions in ClientHello correctly, including 5985 unknown extensions? 5987 - When the server has requested a client certificate, but no 5988 suitable certificate is available, do you correctly send an empty 5989 Certificate message, instead of omitting the whole message (see 5990 Section 4.4.2.3)? 5992 - When processing the plaintext fragment produced by AEAD-Decrypt 5993 and scanning from the end for the ContentType, do you avoid 5994 scanning past the start of the cleartext in the event that the 5995 peer has sent a malformed plaintext of all-zeros? 5997 - Do you properly ignore unrecognized cipher suites (Section 4.1.2), 5998 hello extensions (Section 4.2), named groups (Section 4.2.7), key 5999 shares (Section 4.2.8), supported versions (Section 4.2.1), and 6000 signature algorithms (Section 4.2.3) in the ClientHello? 6002 - As a server, do you send a HelloRetryRequest to clients which 6003 support a compatible (EC)DHE group but do not predict it in the 6004 "key_share" extension? As a client, do you correctly handle a 6005 HelloRetryRequest from the server? 6007 Cryptographic details: 6009 - What countermeasures do you use to prevent timing attacks 6010 [TIMING]? 6012 - When using Diffie-Hellman key exchange, do you correctly preserve 6013 leading zero bytes in the negotiated key (see Section 7.4.1)? 6015 - Does your TLS client check that the Diffie-Hellman parameters sent 6016 by the server are acceptable, (see Section 4.2.8.1)? 6018 - Do you use a strong and, most importantly, properly seeded random 6019 number generator (see Appendix C.1) when generating Diffie-Hellman 6020 private values, the ECDSA "k" parameter, and other security- 6021 critical values? It is RECOMMENDED that implementations implement 6022 "deterministic ECDSA" as specified in [RFC6979]. 6024 - Do you zero-pad Diffie-Hellman public key values to the group size 6025 (see Section 4.2.8.1)? 6027 - Do you verify signatures after making them to protect against RSA- 6028 CRT key leaks? [FW15] 6030 C.4. Client Tracking Prevention 6032 Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of 6033 a ticket allows passive observers to correlate different connections. 6034 Servers that issue tickets SHOULD offer at least as many tickets as 6035 the number of connections that a client might use; for example, a web 6036 browser using HTTP/1.1 [RFC7230] might open six connections to a 6037 server. Servers SHOULD issue new tickets with every connection. 6038 This ensures that clients are always able to use a new ticket when 6039 creating a new connection. 6041 C.5. Unauthenticated Operation 6043 Previous versions of TLS offered explicitly unauthenticated cipher 6044 suites based on anonymous Diffie-Hellman. These modes have been 6045 deprecated in TLS 1.3. However, it is still possible to negotiate 6046 parameters that do not provide verifiable server authentication by 6047 several methods, including: 6049 - Raw public keys [RFC7250]. 6051 - Using a public key contained in a certificate but without 6052 validation of the certificate chain or any of its contents. 6054 Either technique used alone is vulnerable to man-in-the-middle 6055 attacks and therefore unsafe for general use. However, it is also 6056 possible to bind such connections to an external authentication 6057 mechanism via out-of-band validation of the server's public key, 6058 trust on first use, or a mechanism such as channel bindings (though 6059 the channel bindings described in [RFC5929] are not defined for TLS 6060 1.3). If no such mechanism is used, then the connection has no 6061 protection against active man-in-the-middle attack; applications MUST 6062 NOT use TLS in such a way absent explicit configuration or a specific 6063 application profile. 6065 Appendix D. Backward Compatibility 6067 The TLS protocol provides a built-in mechanism for version 6068 negotiation between endpoints potentially supporting different 6069 versions of TLS. 6071 TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can 6072 also handle clients trying to use future versions of TLS as long as 6073 the ClientHello format remains compatible and and there is at least 6074 one protocol version supported by both the client and the server. 6076 Prior versions of TLS used the record layer version number for 6077 various purposes. (TLSPlaintext.legacy_record_version and 6078 TLSCiphertext.legacy_record_version) As of TLS 1.3, this field is 6079 deprecated. The value of TLSPlaintext.legacy_record_version MUST be 6080 ignored by all implementations. The value of 6081 TLSCiphertext.legacy_record_version MAY be ignored, or MAY be 6082 validated to match the fixed constant value. Version negotiation is 6083 performed using only the handshake versions 6084 (ClientHello.legacy_version, ServerHello.legacy_version, as well as 6085 the ClientHello, HelloRetryRequest and ServerHello 6086 "supported_versions" extensions). In order to maximize 6087 interoperability with older endpoints, implementations that negotiate 6088 the use of TLS 1.0-1.2 SHOULD set the record layer version number to 6089 the negotiated version for the ServerHello and all records 6090 thereafter. 6092 For maximum compatibility with previously non-standard behavior and 6093 misconfigured deployments, all implementations SHOULD support 6094 validation of certification paths based on the expectations in this 6095 document, even when handling prior TLS versions' handshakes. (see 6096 Section 4.4.2.2) 6098 TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627] 6099 extension which digested large parts of the handshake transcript into 6100 the master secret. Because TLS 1.3 always hashes in the transcript 6101 up to the server CertificateVerify, implementations which support 6102 both TLS 1.3 and earlier versions SHOULD indicate the use of the 6103 Extended Master Secret extension in their APIs whenever TLS 1.3 is 6104 used. 6106 D.1. Negotiating with an older server 6108 A TLS 1.3 client who wishes to negotiate with servers that do not 6109 support TLS 1.3 will send a normal TLS 1.3 ClientHello containing 6110 0x0303 (TLS 1.2) in ClientHello.legacy_version but with the correct 6111 version(s) in the "supported_versions" extension. If the server does 6112 not support TLS 1.3 it will respond with a ServerHello containing an 6113 older version number. If the client agrees to use this version, the 6114 negotiation will proceed as appropriate for the negotiated protocol. 6115 A client using a ticket for resumption SHOULD initiate the connection 6116 using the version that was previously negotiated. 6118 Note that 0-RTT data is not compatible with older servers and SHOULD 6119 NOT be sent absent knowledge that the server supports TLS 1.3. See 6120 Appendix D.3. 6122 If the version chosen by the server is not supported by the client 6123 (or not acceptable), the client MUST abort the handshake with a 6124 "protocol_version" alert. 6126 Some legacy server implementations are known to not implement the TLS 6127 specification properly and might abort connections upon encountering 6128 TLS extensions or versions which they are not aware of. 6129 Interoperability with buggy servers is a complex topic beyond the 6130 scope of this document. Multiple connection attempts may be required 6131 in order to negotiate a backwards compatible connection; however, 6132 this practice is vulnerable to downgrade attacks and is NOT 6133 RECOMMENDED. 6135 D.2. Negotiating with an older client 6137 A TLS server can also receive a ClientHello indicating a version 6138 number smaller than its highest supported version. If the 6139 "supported_versions" extension is present, the server MUST negotiate 6140 using that extension as described in Section 4.2.1. If the 6141 "supported_versions" extension is not present, the server MUST 6142 negotiate the minimum of ClientHello.legacy_version and TLS 1.2. For 6143 example, if the server supports TLS 1.0, 1.1, and 1.2, and 6144 legacy_version is TLS 1.0, the server will proceed with a TLS 1.0 6145 ServerHello. If the "supported_versions" extension is absent and the 6146 server only supports versions greater than 6147 ClientHello.legacy_version, the server MUST abort the handshake with 6148 a "protocol_version" alert. 6150 Note that earlier versions of TLS did not clearly specify the record 6151 layer version number value in all cases 6152 (TLSPlaintext.legacy_record_version). Servers will receive various 6153 TLS 1.x versions in this field, but its value MUST always be ignored. 6155 D.3. 0-RTT backwards compatibility 6157 0-RTT data is not compatible with older servers. An older server 6158 will respond to the ClientHello with an older ServerHello, but it 6159 will not correctly skip the 0-RTT data and will fail to complete the 6160 handshake. This can cause issues when a client attempts to use 6161 0-RTT, particularly against multi-server deployments. For example, a 6162 deployment could deploy TLS 1.3 gradually with some servers 6163 implementing TLS 1.3 and some implementing TLS 1.2, or a TLS 1.3 6164 deployment could be downgraded to TLS 1.2. 6166 A client that attempts to send 0-RTT data MUST fail a connection if 6167 it receives a ServerHello with TLS 1.2 or older. A client that 6168 attempts to repair this error SHOULD NOT send a TLS 1.2 ClientHello, 6169 but instead send a TLS 1.3 ClientHello without 0-RTT data. 6171 To avoid this error condition, multi-server deployments SHOULD ensure 6172 a uniform and stable deployment of TLS 1.3 without 0-RTT prior to 6173 enabling 0-RTT. 6175 D.4. Middlebox Compatibility Mode 6177 Field measurements [Ben17a], [Ben17b], [Res17a], [Res17b] have found 6178 that a significant number of middleboxes misbehave when a TLS client/ 6179 server pair negotiates TLS 1.3. Implementations can increase the 6180 chance of making connections through those middleboxes by making the 6181 TLS 1.3 handshake look more like a TLS 1.2 handshake: 6183 - The client always provides a non-empty session ID in the 6184 ClientHello, as described in the legacy_session_id section of 6185 Section 4.1.2. 6187 - If not offering early data, the client sends a dummy 6188 change_cipher_spec record (see the third paragraph of Section 5.1) 6189 immediately before its second flight. This may either be before 6190 its second ClientHello or before its encrypted handshake flight. 6191 If offering early data, the record is placed immediately after the 6192 first ClientHello. 6194 - The server sends a dummy change_cipher_spec record immediately 6195 after its first handshake message. This may either be after a 6196 ServerHello or a HelloRetryRequest. 6198 When put together, these changes make the TLS 1.3 handshake resemble 6199 TLS 1.2 session resumption, which improves the chance of successfully 6200 connecting through middleboxes. This "compatibility mode" is 6201 partially negotiated: The client can opt to provide a session ID or 6202 not and the server has to echo it. Either side can send 6203 change_cipher_spec at any time during the handshake, as they must be 6204 ignored by the peer, but if the client sends a non-empty session ID, 6205 the server MUST send the change_cipher_spec as described in this 6206 section. 6208 D.5. Backwards Compatibility Security Restrictions 6210 Implementations negotiating use of older versions of TLS SHOULD 6211 prefer forward secret and AEAD cipher suites, when available. 6213 The security of RC4 cipher suites is considered insufficient for the 6214 reasons cited in [RFC7465]. Implementations MUST NOT offer or 6215 negotiate RC4 cipher suites for any version of TLS for any reason. 6217 Old versions of TLS permitted the use of very low strength ciphers. 6218 Ciphers with a strength less than 112 bits MUST NOT be offered or 6219 negotiated for any version of TLS for any reason. 6221 The security of SSL 3.0 [SSL3] is considered insufficient for the 6222 reasons enumerated in [RFC7568], and MUST NOT be negotiated for any 6223 reason. 6225 The security of SSL 2.0 [SSL2] is considered insufficient for the 6226 reasons enumerated in [RFC6176], and MUST NOT be negotiated for any 6227 reason. 6229 Implementations MUST NOT send an SSL version 2.0 compatible CLIENT- 6230 HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an 6231 SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT 6232 RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in 6233 order to negotiate older versions of TLS. 6235 Implementations MUST NOT send a ClientHello.legacy_version or 6236 ServerHello.legacy_version set to 0x0300 or less. Any endpoint 6237 receiving a Hello message with ClientHello.legacy_version or 6238 ServerHello.legacy_version set to 0x0300 MUST abort the handshake 6239 with a "protocol_version" alert. 6241 Implementations MUST NOT send any records with a version less than 6242 0x0300. Implementations SHOULD NOT accept any records with a version 6243 less than 0x0300 (but may inadvertently do so if the record version 6244 number is ignored completely). 6246 Implementations MUST NOT use the Truncated HMAC extension, defined in 6247 Section 7 of [RFC6066], as it is not applicable to AEAD algorithms 6248 and has been shown to be insecure in some scenarios. 6250 Appendix E. Overview of Security Properties 6252 A complete security analysis of TLS is outside the scope of this 6253 document. In this section, we provide an informal description the 6254 desired properties as well as references to more detailed work in the 6255 research literature which provides more formal definitions. 6257 We cover properties of the handshake separately from those of the 6258 record layer. 6260 E.1. Handshake 6262 The TLS handshake is an Authenticated Key Exchange (AKE) protocol 6263 which is intended to provide both one-way authenticated (server-only) 6264 and mutually authenticated (client and server) functionality. At the 6265 completion of the handshake, each side outputs its view of the 6266 following values: 6268 - A set of "session keys" (the various secrets derived from the 6269 master secret) from which can be derived a set of working keys. 6271 - A set of cryptographic parameters (algorithms, etc.) 6273 - The identities of the communicating parties. 6275 We assume the attacker to be an active network attacker, which means 6276 it has complete control over the network used to communicate between 6277 the parties [RFC3552]. Even under these conditions, the handshake 6278 should provide the properties listed below. Note that these 6279 properties are not necessarily independent, but reflect the protocol 6280 consumers' needs. 6282 Establishing the same session keys. The handshake needs to output 6283 the same set of session keys on both sides of the handshake, 6284 provided that it completes successfully on each endpoint (See 6285 [CK01]; defn 1, part 1). 6287 Secrecy of the session keys. The shared session keys should be known 6288 only to the communicating parties and not to the attacker (See 6289 [CK01]; defn 1, part 2). Note that in a unilaterally 6290 authenticated connection, the attacker can establish its own 6291 session keys with the server, but those session keys are distinct 6292 from those established by the client. 6294 Peer Authentication. The client's view of the peer identity should 6295 reflect the server's identity. If the client is authenticated, 6296 the server's view of the peer identity should match the client's 6297 identity. 6299 Uniqueness of the session keys: Any two distinct handshakes should 6300 produce distinct, unrelated session keys. Individual session keys 6301 produced by a handshake should also be distinct and unrelated. 6303 Downgrade protection. The cryptographic parameters should be the 6304 same on both sides and should be the same as if the peers had been 6305 communicating in the absence of an attack (See [BBFKZG16]; defns 8 6306 and 9}). 6308 Forward secret with respect to long-term keys If the long-term 6309 keying material (in this case the signature keys in certificate- 6310 based authentication modes or the external/resumption PSK in PSK 6311 with (EC)DHE modes) is compromised after the handshake is 6312 complete, this does not compromise the security of the session key 6313 (See [DOW92]), as long as the session key itself has been erased. 6314 The forward secrecy property is not satisfied when PSK is used in 6315 the "psk_ke" PskKeyExchangeMode. 6317 Key Compromise Impersonation (KCI) resistance In a mutually- 6318 authenticated connection with certificates, peer authentication 6319 should hold even if the local long-term secret was compromised 6320 before the connection was established (see [HGFS15]). For 6321 example, if a client's signature key is compromised, it should not 6322 be possible to impersonate arbitrary servers to that client in 6323 subsequent handshakes. 6325 Protection of endpoint identities. The server's identity 6326 (certificate) should be protected against passive attackers. The 6327 client's identity should be protected against both passive and 6328 active attackers. 6330 Informally, the signature-based modes of TLS 1.3 provide for the 6331 establishment of a unique, secret, shared key established by an 6332 (EC)DHE key exchange and authenticated by the server's signature over 6333 the handshake transcript, as well as tied to the server's identity by 6334 a MAC. If the client is authenticated by a certificate, it also 6335 signs over the handshake transcript and provides a MAC tied to both 6336 identities. [SIGMA] describes the design and analysis of this type 6337 of key exchange protocol. If fresh (EC)DHE keys are used for each 6338 connection, then the output keys are forward secret. 6340 The external PSK and resumption PSK bootstrap from a long-term shared 6341 secret into a unique per-connection set of short-term session keys. 6342 This secret may have been established in a previous handshake. If 6343 PSK with (EC)DHE key establishment is used, these session keys will 6344 also be forward secret. The resumption PSK has been designed so that 6345 the resumption master secret computed by connection N and needed to 6346 form connection N+1 is separate from the traffic keys used by 6347 connection N, thus providing forward secrecy between the connections. 6348 In addition, if multiple tickets are established on the same 6349 connection, they are associated with different keys, so compromise of 6350 the PSK associated with one ticket does not lead to the compromise of 6351 connections established with PSKs associated with other tickets. 6352 This property is most interesting if tickets are stored in a database 6353 (and so can be deleted) rather than if they are self-encrypted. 6355 The PSK binder value forms a binding between a PSK and the current 6356 handshake, as well as between the session where the PSK was 6357 established and the session where it was used. This binding 6358 transitively includes the original handshake transcript, because that 6359 transcript is digested into the values which produce the Resumption 6360 Master Secret. This requires that both the KDF used to produce the 6361 resumption master secret and the MAC used to compute the binder be 6362 collision resistant. See Appendix E.1.1 for more on this. Note: The 6363 binder does not cover the binder values from other PSKs, though they 6364 are included in the Finished MAC. 6366 Note: TLS does not currently permit the server to send a 6367 certificate_request message in non-certificate-based handshakes 6368 (e.g., PSK). If this restriction were to be relaxed in future, the 6369 client's signature would not cover the server's certificate directly. 6370 However, if the PSK was established through a NewSessionTicket, the 6371 client's signature would transitively cover the server's certificate 6372 through the PSK binder. [PSK-FINISHED] describes a concrete attack 6373 on constructions that do not bind to the server's certificate (see 6374 also [Kraw16]). It is unsafe to use certificate-based client 6375 authentication when the client might potentially share the same PSK/ 6376 key-id pair with two different endpoints. Implementations MUST NOT 6377 combine external PSKs with certificate-based authentication of either 6378 the client or the server unless negotiated by some extension. 6380 If an exporter is used, then it produces values which are unique and 6381 secret (because they are generated from a unique session key). 6382 Exporters computed with different labels and contexts are 6383 computationally independent, so it is not feasible to compute one 6384 from another or the session secret from the exported value. Note: 6385 exporters can produce arbitrary-length values. If exporters are to 6386 be used as channel bindings, the exported value MUST be large enough 6387 to provide collision resistance. The exporters provided in TLS 1.3 6388 are derived from the same handshake contexts as the early traffic 6389 keys and the application traffic keys respectively, and thus have 6390 similar security properties. Note that they do not include the 6391 client's certificate; future applications which wish to bind to the 6392 client's certificate may need to define a new exporter that includes 6393 the full handshake transcript. 6395 For all handshake modes, the Finished MAC (and where present, the 6396 signature), prevents downgrade attacks. In addition, the use of 6397 certain bytes in the random nonces as described in Section 4.1.3 6398 allows the detection of downgrade to previous TLS versions. See 6399 [BBFKZG16] for more detail on TLS 1.3 and downgrade. 6401 As soon as the client and the server have exchanged enough 6402 information to establish shared keys, the remainder of the handshake 6403 is encrypted, thus providing protection against passive attackers, 6404 even if the computed shared key is not authenticated. Because the 6405 server authenticates before the client, the client can ensure that if 6406 it authenticates to the server, it only reveals its identity to an 6407 authenticated server. Note that implementations must use the 6408 provided record padding mechanism during the handshake to avoid 6409 leaking information about the identities due to length. The client's 6410 proposed PSK identities are not encrypted, nor is the one that the 6411 server selects. 6413 E.1.1. Key Derivation and HKDF 6415 Key derivation in TLS 1.3 uses the HKDF function defined in [RFC5869] 6416 and its two components, HKDF-Extract and HKDF-Expand. The full 6417 rationale for the HKDF construction can be found in [Kraw10] and the 6418 rationale for the way it is used in TLS 1.3 in [KW16]. Throughout 6419 this document, each application of HKDF-Extract is followed by one or 6420 more invocations of HKDF-Expand. This ordering should always be 6421 followed (including in future revisions of this document), in 6422 particular, one SHOULD NOT use an output of HKDF-Extract as an input 6423 to another application of HKDF-Extract without an HKDF-Expand in 6424 between. Consecutive applications of HKDF-Expand are allowed as long 6425 as these are differentiated via the key and/or the labels. 6427 Note that HKDF-Expand implements a pseudorandom function (PRF) with 6428 both inputs and outputs of variable length. In some of the uses of 6429 HKDF in this document (e.g., for generating exporters and the 6430 resumption_master_secret), it is necessary that the application of 6431 HKDF-Expand be collision-resistant, namely, it should be infeasible 6432 to find two different inputs to HKDF-Expand that output the same 6433 value. This requires the underlying hash function to be collision 6434 resistant and the output length from HKDF-Expand to be of size at 6435 least 256 bits (or as much as needed for the hash function to prevent 6436 finding collisions). 6438 E.1.2. Client Authentication 6440 A client that has sent authentication data to a server, either during 6441 the handshake or in post-handshake authentication, cannot be sure if 6442 the server afterwards considers the client to be authenticated or 6443 not. If the client needs to determine if the server considers the 6444 connection to be unilaterally or mutually authenticated, this has to 6445 be provisioned by the application layer. See [CHHSV17] for details. 6446 In addition, the analysis of post-handshake authentication from 6447 [Kraw16] shows that the client identified by the certificate sent in 6448 the post-handshake phase possesses the traffic key. This party is 6449 therefore the client that participated in the original handshake or 6450 one to whom the original client delegated the traffic key (assuming 6451 that the traffic key has not been compromised). 6453 E.1.3. 0-RTT 6455 The 0-RTT mode of operation generally provides similar security 6456 properties as 1-RTT data, with the two exceptions that the 0-RTT 6457 encryption keys do not provide full forward secrecy and that the 6458 server is not able to guarantee uniqueness of the handshake (non- 6459 replayability) without keeping potentially undue amounts of state. 6460 See Section 4.2.10 for one mechanism to limit the exposure to replay. 6462 E.1.4. Exporter Independence 6464 The exporter_master_secret and early_exporter_master_secret are 6465 derived to be independent of the traffic keys and therefore do not 6466 represent a threat to the security of traffic encrypted with those 6467 keys. However, because these secrets can be used to compute any 6468 exporter value, they SHOULD be erased as soon as possible. If the 6469 total set of exporter labels is known, then implementations SHOULD 6470 pre-compute the inner Derive-Secret stage of the exporter computation 6471 for all those labels, then erase the [early_]exporter_master_secret, 6472 followed by each inner values as soon as it is known that it will not 6473 be needed again. 6475 E.1.5. Post-Compromise Security 6477 TLS does not provide security for handshakes which take place after 6478 the peer's long-term secret (signature key or external PSK) is 6479 compromised. It therefore does not provide post-compromise security 6480 [CCG16], sometimes also referred to as backwards or future secrecy. 6481 This is in contrast to KCI resistance, which describes the security 6482 guarantees that a party has after its own long-term secret has been 6483 compromised. 6485 E.1.6. External References 6487 The reader should refer to the following references for analysis of 6488 the TLS handshake: [DFGS15] [CHSV16] [DFGS16] [KW16] [Kraw16] 6489 [FGSW16] [LXZFH16] [FG17] [BBK17]. 6491 E.2. Record Layer 6493 The record layer depends on the handshake producing strong traffic 6494 secrets which can be used to derive bidirectional encryption keys and 6495 nonces. Assuming that is true, and the keys are used for no more 6496 data than indicated in Section 5.5 then the record layer should 6497 provide the following guarantees: 6499 Confidentiality. An attacker should not be able to determine the 6500 plaintext contents of a given record. 6502 Integrity. An attacker should not be able to craft a new record 6503 which is different from an existing record which will be accepted 6504 by the receiver. 6506 Order protection/non-replayability An attacker should not be able to 6507 cause the receiver to accept a record which it has already 6508 accepted or cause the receiver to accept record N+1 without having 6509 first processed record N. 6511 Length concealment. Given a record with a given external length, the 6512 attacker should not be able to determine the amount of the record 6513 that is content versus padding. 6515 Forward secrecy after key change. If the traffic key update 6516 mechanism described in Section 4.6.3 has been used and the 6517 previous generation key is deleted, an attacker who compromises 6518 the endpoint should not be able to decrypt traffic encrypted with 6519 the old key. 6521 Informally, TLS 1.3 provides these properties by AEAD-protecting the 6522 plaintext with a strong key. AEAD encryption [RFC5116] provides 6523 confidentiality and integrity for the data. Non-replayability is 6524 provided by using a separate nonce for each record, with the nonce 6525 being derived from the record sequence number (Section 5.3), with the 6526 sequence number being maintained independently at both sides thus 6527 records which are delivered out of order result in AEAD deprotection 6528 failures. In order to prevent mass cryptanalysis when the same 6529 plaintext is repeatedly encrypted by different users under the same 6530 key (as is commonly the case for HTTP), the nonce is formed by mixing 6531 the sequence number with a secret per-connection initialization 6532 vector derived along with the traffic keys. See [BT16] for analysis 6533 of this construction. 6535 The re-keying technique in TLS 1.3 (see Section 7.2) follows the 6536 construction of the serial generator in [REKEY], which shows that re- 6537 keying can allow keys to be used for a larger number of encryptions 6538 than without re-keying. This relies on the security of the HKDF- 6539 Expand-Label function as a pseudorandom function (PRF). In addition, 6540 as long as this function is truly one way, it is not possible to 6541 compute traffic keys from prior to a key change (forward secrecy). 6543 TLS does not provide security for data which is communicated on a 6544 connection after a traffic secret of that connection is compromised. 6545 That is, TLS does not provide post-compromise security/future 6546 secrecy/backward secrecy with respect to the traffic secret. Indeed, 6547 an attacker who learns a traffic secret can compute all future 6548 traffic secrets on that connection. Systems which want such 6549 guarantees need to do a fresh handshake and establish a new 6550 connection with an (EC)DHE exchange. 6552 E.2.1. External References 6554 The reader should refer to the following references for analysis of 6555 the TLS record layer: [BMMT15] [BT16] [BDFKPPRSZZ16] [BBK17]. 6557 E.3. Traffic Analysis 6559 TLS is susceptible to a variety of traffic analysis attacks based on 6560 observing the length and timing of encrypted packets [CLINIC] 6561 [HCJ16]. This is particularly easy when there is a small set of 6562 possible messages to be distinguished, such as for a video server 6563 hosting a fixed corpus of content, but still provides usable 6564 information even in more complicated scenarios. 6566 TLS does not provide any specific defenses against this form of 6567 attack but does include a padding mechanism for use by applications: 6568 The plaintext protected by the AEAD function consists of content plus 6569 variable-length padding, which allows the application to produce 6570 arbitrary length encrypted records as well as padding-only cover 6571 traffic to conceal the difference between periods of transmission and 6572 periods of silence. Because the padding is encrypted alongside the 6573 actual content, an attacker cannot directly determine the length of 6574 the padding, but may be able to measure it indirectly by the use of 6575 timing channels exposed during record processing (i.e., seeing how 6576 long it takes to process a record or trickling in records to see 6577 which ones elicit a response from the server). In general, it is not 6578 known how to remove all of these channels because even a constant 6579 time padding removal function will likely feed the content into data- 6580 dependent functions. At minimum, a fully constant time server or 6581 client would require close cooperation with the application layer 6582 protocol implementation, including making that higher level protocol 6583 constant time. 6585 Note: Robust traffic analysis defences will likely lead to inferior 6586 performance due to delay in transmitting packets and increased 6587 traffic volume. 6589 E.4. Side Channel Attacks 6591 In general, TLS does not have specific defenses against side-channel 6592 attacks (i.e., those which attack the communications via secondary 6593 channels such as timing) leaving those to the implementation of the 6594 relevant cryptographic primitives. However, certain features of TLS 6595 are designed to make it easier to write side-channel resistant code: 6597 - Unlike previous versions of TLS which used a composite MAC-then- 6598 encrypt structure, TLS 1.3 only uses AEAD algorithms, allowing 6599 implementations to use self-contained constant-time 6600 implementations of those primitives. 6602 - TLS uses a uniform "bad_record_mac" alert for all decryption 6603 errors, which is intended to prevent an attacker from gaining 6604 piecewise insight into portions of the message. Additional 6605 resistance is provided by terminating the connection on such 6606 errors; a new connection will have different cryptographic 6607 material, preventing attacks against the cryptographic primitives 6608 that require multiple trials. 6610 Information leakage through side channels can occur at layers above 6611 TLS, in application protocols and the applications that use them. 6612 Resistance to side-channel attacks depends on applications and 6613 application protocols separately ensuring that confidential 6614 information is not inadvertently leaked. 6616 E.5. Replay Attacks on 0-RTT 6618 Replayable 0-RTT data presents a number of security threats to TLS- 6619 using applications, unless those applications are specifically 6620 engineered to be safe under replay (minimally, this means idempotent, 6621 but in many cases may also require other stronger conditions, such as 6622 constant-time response). Potential attacks include: 6624 - Duplication of actions which cause side effects (e.g., purchasing 6625 an item or transferring money) to be duplicated, thus harming the 6626 site or the user. 6628 - Attackers can store and replay 0-RTT messages in order to re-order 6629 them with respect to other messages (e.g., moving a delete to 6630 after a create). 6632 - Exploiting cache timing behavior to discover the content of 0-RTT 6633 messages by replaying a 0-RTT message to a different cache node 6634 and then using a separate connection to measure request latency, 6635 to see if the two requests address the same resource. 6637 If data can be replayed a large number of times, additional attacks 6638 become possible, such as making repeated measurements of the the 6639 speed of cryptographic operations. In addition, they may be able to 6640 overload rate-limiting systems. For further description of these 6641 attacks, see [Mac17]. 6643 Ultimately, servers have the responsibility to protect themselves 6644 against attacks employing 0-RTT data replication. The mechanisms 6645 described in Section 8 are intended to prevent replay at the TLS 6646 layer but do not provide complete protection against receiving 6647 multiple copies of client data. TLS 1.3 falls back to the 1-RTT 6648 handshake when the server does not have any information about the 6649 client, e.g., because it is in a different cluster which does not 6650 share state or because the ticket has been deleted as described in 6651 Section 8.1. If the application layer protocol retransmits data in 6652 this setting, then it is possible for an attacker to induce message 6653 duplication by sending the ClientHello to both the original cluster 6654 (which processes the data immediately) and another cluster which will 6655 fall back to 1-RTT and process the data upon application layer 6656 replay. The scale of this attack is limited by the client's 6657 willingness to retry transactions and therefore only allows a limited 6658 amount of duplication, with each copy appearing as a new connection 6659 at the server. 6661 If implemented correctly, the mechanisms described in Section 8.1 and 6662 Section 8.2 prevent a replayed ClientHello and its associated 0-RTT 6663 data from being accepted multiple times by any cluster with 6664 consistent state; for servers which limit the use of 0-RTT to one 6665 cluster for a single ticket, then a given ClientHello and its 6666 associated 0-RTT data will only be accepted once. However, if state 6667 is not completely consistent, then an attacker might be able to have 6668 multiple copies of the data be accepted during the replication 6669 window. Because clients do not know the exact details of server 6670 behavior, they MUST NOT send messages in early data which are not 6671 safe to have replayed and which they would not be willing to retry 6672 across multiple 1-RTT connections. 6674 Application protocols MUST NOT use 0-RTT data without a profile that 6675 defines its use. That profile needs to identify which messages or 6676 interactions are safe to use with 0-RTT and how to handle the 6677 situation when the server rejects 0-RTT and falls back to 1-RTT. 6679 In addition, to avoid accidental misuse, TLS implementations MUST NOT 6680 enable 0-RTT (either sending or accepting) unless specifically 6681 requested by the application and MUST NOT automatically resend 0-RTT 6682 data if it is rejected by the server unless instructed by the 6683 application. Server-side applications may wish to implement special 6684 processing for 0-RTT data for some kinds of application traffic 6685 (e.g., abort the connection, request that data be resent at the 6686 application layer, or delay processing until the handshake 6687 completes). In order to allow applications to implement this kind of 6688 processing, TLS implementations MUST provide a way for the 6689 application to determine if the handshake has completed. 6691 E.5.1. Replay and Exporters 6693 Replays of the ClientHello produce the same early exporter, thus 6694 requiring additional care by applications which use these exporters. 6695 In particular, if these exporters are used as an authentication 6696 channel binding (e.g., by signing the output of the exporter) an 6697 attacker who compromises the PSK can transplant authenticators 6698 between connections without compromising the authentication key. 6700 In addition, the early exporter SHOULD NOT be used to generate 6701 server-to-client encryption keys because that would entail the reuse 6702 of those keys. This parallels the use of the early application 6703 traffic keys only in the client-to-server direction. 6705 E.6. Attacks on Static RSA 6707 Although TLS 1.3 does not use RSA key transport and so is not 6708 directly susceptible to Bleichenbacher-type attacks, if TLS 1.3 6709 servers also support static RSA in the context of previous versions 6710 of TLS, then it may be possible to impersonate the server for TLS 1.3 6711 connections [JSS15]. TLS 1.3 implementations can prevent this attack 6712 by disabling support for static RSA across all versions of TLS. In 6713 principle, implementations might also be able to separate 6714 certificates with different keyUsage bits for static RSA decryption 6715 and RSA signature, but this technique relies on clients refusing to 6716 accept signatures using keys in certificates that do not have the 6717 digitalSignature bit set, and many clients do not enforce this 6718 restriction. 6720 Appendix F. Working Group Information 6722 The discussion list for the IETF TLS working group is located at the 6723 e-mail address tls@ietf.org [1]. Information on the group and 6724 information on how to subscribe to the list is at 6725 https://www.ietf.org/mailman/listinfo/tls 6727 Archives of the list can be found at: https://www.ietf.org/mail- 6728 archive/web/tls/current/index.html 6730 Appendix G. Contributors 6732 - Martin Abadi 6733 University of California, Santa Cruz 6734 abadi@cs.ucsc.edu 6736 - Christopher Allen (co-editor of TLS 1.0) 6737 Alacrity Ventures 6738 ChristopherA@AlacrityManagement.com 6740 - Richard Barnes 6741 Cisco 6742 rlb@ipv.sx 6744 - Steven M. Bellovin 6745 Columbia University 6746 smb@cs.columbia.edu 6748 - David Benjamin 6749 Google 6750 davidben@google.com 6752 - Benjamin Beurdouche 6753 INRIA & Microsoft Research 6754 benjamin.beurdouche@ens.fr 6756 - Karthikeyan Bhargavan (co-author of [RFC7627]) 6757 INRIA 6758 karthikeyan.bhargavan@inria.fr 6760 - Simon Blake-Wilson (co-author of [RFC4492]) 6761 BCI 6762 sblakewilson@bcisse.com 6764 - Nelson Bolyard (co-author of [RFC4492]) 6765 Sun Microsystems, Inc. 6766 nelson@bolyard.com 6768 - Ran Canetti 6769 IBM 6770 canetti@watson.ibm.com 6772 - Matt Caswell 6773 OpenSSL 6774 matt@openssl.org 6776 - Stephen Checkoway 6777 University of Illinois at Chicago 6778 sfc@uic.edu 6780 - Pete Chown 6781 Skygate Technology Ltd 6782 pc@skygate.co.uk 6784 - Katriel Cohn-Gordon 6785 University of Oxford 6786 me@katriel.co.uk 6788 - Cas Cremers 6789 University of Oxford 6790 cas.cremers@cs.ox.ac.uk 6792 - Antoine Delignat-Lavaud (co-author of [RFC7627]) 6793 INRIA 6794 antoine.delignat-lavaud@inria.fr 6796 - Tim Dierks (co-editor of TLS 1.0, 1.1, and 1.2) 6797 Independent 6798 tim@dierks.org 6800 - Taher Elgamal 6801 Securify 6802 taher@securify.com 6804 - Pasi Eronen 6805 Nokia 6806 pasi.eronen@nokia.com 6808 - Cedric Fournet 6809 Microsoft 6810 fournet@microsoft.com 6812 - Anil Gangolli 6813 anil@busybuddha.org 6815 - David M. Garrett 6816 dave@nulldereference.com 6818 - Illya Gerasymchuk 6819 Independent 6820 illya@iluxonchik.me 6822 - Alessandro Ghedini 6823 Cloudflare Inc. 6824 alessandro@cloudflare.com 6826 - Daniel Kahn Gillmor 6827 ACLU 6828 dkg@fifthhorseman.net 6830 - Matthew Green 6831 Johns Hopkins University 6832 mgreen@cs.jhu.edu 6834 - Jens Guballa 6835 ETAS 6836 jens.guballa@etas.com 6838 - Felix Guenther 6839 TU Darmstadt 6840 mail@felixguenther.info 6842 - Vipul Gupta (co-author of [RFC4492]) 6843 Sun Microsystems Laboratories 6844 vipul.gupta@sun.com 6846 - Chris Hawk (co-author of [RFC4492]) 6847 Corriente Networks LLC 6848 chris@corriente.net 6850 - Kipp Hickman 6852 - Alfred Hoenes 6854 - David Hopwood 6855 Independent Consultant 6856 david.hopwood@blueyonder.co.uk 6858 - Marko Horvat 6859 MPI-SWS 6860 mhorvat@mpi-sws.org 6862 - Jonathan Hoyland 6863 Royal Holloway, University of London 6865 - Subodh Iyengar 6866 Facebook 6867 subodh@fb.com 6869 - Benjamin Kaduk 6870 Akamai 6871 kaduk@mit.edu 6873 - Hubert Kario 6874 Red Hat Inc. 6875 hkario@redhat.com 6877 - Phil Karlton (co-author of SSL 3.0) 6879 - Leon Klingele 6880 Independent 6881 mail@leonklingele.de 6883 - Paul Kocher (co-author of SSL 3.0) 6884 Cryptography Research 6885 paul@cryptography.com 6887 - Hugo Krawczyk 6888 IBM 6889 hugokraw@us.ibm.com 6891 - Adam Langley (co-author of [RFC7627]) 6892 Google 6893 agl@google.com 6895 - Olivier Levillain 6896 ANSSI 6897 olivier.levillain@ssi.gouv.fr 6899 - Xiaoyin Liu 6900 University of North Carolina at Chapel Hill 6901 xiaoyin.l@outlook.com 6903 - Ilari Liusvaara 6904 Independent 6905 ilariliusvaara@welho.com 6907 - Atul Luykx 6908 K.U. Leuven 6909 atul.luykx@kuleuven.be 6911 - Colm MacCarthaigh 6912 Amazon Web Services 6913 colm@allcosts.net 6915 - Carl Mehner 6916 USAA 6917 carl.mehner@usaa.com 6919 - Jan Mikkelsen 6920 Transactionware 6921 janm@transactionware.com 6923 - Bodo Moeller (co-author of [RFC4492]) 6924 Google 6925 bodo@openssl.org 6927 - Kyle Nekritz 6928 Facebook 6929 knekritz@fb.com 6931 - Erik Nygren 6932 Akamai Technologies 6933 erik+ietf@nygren.org 6935 - Magnus Nystrom 6936 Microsoft 6937 mnystrom@microsoft.com 6939 - Kazuho Oku 6940 DeNA Co., Ltd. 6941 kazuhooku@gmail.com 6943 - Kenny Paterson 6944 Royal Holloway, University of London 6945 kenny.paterson@rhul.ac.uk 6947 - Alfredo Pironti (co-author of [RFC7627]) 6948 INRIA 6949 alfredo.pironti@inria.fr 6951 - Andrei Popov 6952 Microsoft 6953 andrei.popov@microsoft.com 6955 - Marsh Ray (co-author of [RFC7627]) 6956 Microsoft 6957 maray@microsoft.com 6959 - Robert Relyea 6960 Netscape Communications 6961 relyea@netscape.com 6963 - Kyle Rose 6964 Akamai Technologies 6965 krose@krose.org 6967 - Jim Roskind 6968 Amazon 6969 jroskind@amazon.com 6971 - Michael Sabin 6973 - Joe Salowey 6974 Tableau Software 6975 joe@salowey.net 6977 - Rich Salz 6978 Akamai 6979 rsalz@akamai.com 6981 - David Schinazi 6982 Apple Inc. 6983 dschinazi@apple.com 6985 - Sam Scott 6986 Royal Holloway, University of London 6987 me@samjs.co.uk 6989 - Dan Simon 6990 Microsoft, Inc. 6991 dansimon@microsoft.com 6993 - Brian Smith 6994 Independent 6995 brian@briansmith.org 6997 - Brian Sniffen 6998 Akamai Technologies 6999 ietf@bts.evenmere.org 7001 - Nick Sullivan 7002 Cloudflare Inc. 7003 nick@cloudflare.com 7005 - Bjoern Tackmann 7006 University of California, San Diego 7007 btackmann@eng.ucsd.edu 7009 - Tim Taubert 7010 Mozilla 7011 ttaubert@mozilla.com 7013 - Martin Thomson 7014 Mozilla 7015 mt@mozilla.com 7017 - Sean Turner 7018 sn3rd 7019 sean@sn3rd.com 7021 - Steven Valdez 7022 Google 7023 svaldez@google.com 7025 - Filippo Valsorda 7026 Cloudflare Inc. 7027 filippo@cloudflare.com 7029 - Thyla van der Merwe 7030 Royal Holloway, University of London 7031 tjvdmerwe@gmail.com 7033 - Victor Vasiliev 7034 Google 7035 vasilvv@google.com 7037 - Tom Weinstein 7039 - Hoeteck Wee 7040 Ecole Normale Superieure, Paris 7041 hoeteck@alum.mit.edu 7043 - David Wong 7044 NCC Group 7045 david.wong@nccgroup.trust 7047 - Christopher A. Wood 7048 Apple Inc. 7049 cawood@apple.com 7051 - Tim Wright 7052 Vodafone 7053 timothy.wright@vodafone.com 7055 - Peter Wu 7056 Independent 7057 peter@lekensteyn.nl 7059 - Kazu Yamamoto 7060 Internet Initiative Japan Inc. 7061 kazu@iij.ad.jp 7063 Author's Address 7065 Eric Rescorla 7066 RTFM, Inc. 7068 EMail: ekr@rtfm.com