idnits 2.17.1 draft-ietf-tls-tls13-27.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 33 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 RFC6961, 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. 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 (March 18, 2018) is 2230 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 1032, but not defined -- Looks like a reference, but probably isn't: '0' on line 1156 -- Looks like a reference, but probably isn't: '1' on line 6818 -- Looks like a reference, but probably isn't: '2' on line 5658 -- Looks like a reference, but probably isn't: '3' on line 1211 -- Looks like a reference, but probably isn't: '4' on line 1185 -- Looks like a reference, but probably isn't: '8' on line 1186 -- Looks like a reference, but probably isn't: '9' on line 1212 -- Looks like a reference, but probably isn't: '10' on line 1349 -- Looks like a reference, but probably isn't: '32' on line 5656 -- Possible downref: Non-RFC (?) normative reference: ref. 'DH' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH76' -- 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-04 == 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 (~~), 4 warnings (==), 30 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, 6961 (if March 18, 2018 5 approved) 6 Updates: 4492, 5705, 6066 (if approved) 7 Intended status: Standards Track 8 Expires: September 19, 2018 10 The Transport Layer Security (TLS) Protocol Version 1.3 11 draft-ietf-tls-tls13-27 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 This document updates RFCs 4492, 5705, and 6066 and it obsoletes RFCs 21 5077, 5246, and 6961. This document also specifies new requirements 22 for TLS 1.2 implementations. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 19, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 71 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 6 72 1.2. Change Log . . . . . . . . . . . . . . . . . . . . . . . 7 73 1.3. Major Differences from TLS 1.2 . . . . . . . . . . . . . 16 74 1.4. Updates Affecting TLS 1.2 . . . . . . . . . . . . . . . . 17 75 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 17 76 2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . . . 20 77 2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 21 78 2.3. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . 23 79 3. Presentation Language . . . . . . . . . . . . . . . . . . . . 25 80 3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 25 81 3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 25 82 3.3. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 26 83 3.4. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 26 84 3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 27 85 3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 28 86 3.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 28 87 3.8. Variants . . . . . . . . . . . . . . . . . . . . . . . . 29 88 4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 30 89 4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 31 90 4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 31 91 4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 32 92 4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 35 93 4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 37 94 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 39 95 4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 42 96 4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 44 97 4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 45 98 4.2.4. Certificate Authorities . . . . . . . . . . . . . . . 49 99 4.2.5. OID Filters . . . . . . . . . . . . . . . . . . . . . 49 100 4.2.6. Post-Handshake Client Authentication . . . . . . . . 50 101 4.2.7. Negotiated Groups . . . . . . . . . . . . . . . . . . 51 102 4.2.8. Key Share . . . . . . . . . . . . . . . . . . . . . . 52 103 4.2.9. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 55 104 4.2.10. Early Data Indication . . . . . . . . . . . . . . . . 56 105 4.2.11. Pre-Shared Key Extension . . . . . . . . . . . . . . 59 106 4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 62 107 4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 62 108 4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 63 109 4.4. Authentication Messages . . . . . . . . . . . . . . . . . 64 110 4.4.1. The Transcript Hash . . . . . . . . . . . . . . . . . 65 111 4.4.2. Certificate . . . . . . . . . . . . . . . . . . . . . 66 112 4.4.3. Certificate Verify . . . . . . . . . . . . . . . . . 71 113 4.4.4. Finished . . . . . . . . . . . . . . . . . . . . . . 73 114 4.5. End of Early Data . . . . . . . . . . . . . . . . . . . . 74 115 4.6. Post-Handshake Messages . . . . . . . . . . . . . . . . . 75 116 4.6.1. New Session Ticket Message . . . . . . . . . . . . . 75 117 4.6.2. Post-Handshake Authentication . . . . . . . . . . . . 77 118 4.6.3. Key and IV Update . . . . . . . . . . . . . . . . . . 78 119 5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 79 120 5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 80 121 5.2. Record Payload Protection . . . . . . . . . . . . . . . . 82 122 5.3. Per-Record Nonce . . . . . . . . . . . . . . . . . . . . 84 123 5.4. Record Padding . . . . . . . . . . . . . . . . . . . . . 85 124 5.5. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 86 125 6. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . 86 126 6.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 88 127 6.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 89 128 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 92 129 7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 92 130 7.2. Updating Traffic Secrets . . . . . . . . . . . . . . . . 95 131 7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 96 132 7.4. (EC)DHE Shared Secret Calculation . . . . . . . . . . . . 97 133 7.4.1. Finite Field Diffie-Hellman . . . . . . . . . . . . . 97 134 7.4.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 97 135 7.5. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 98 136 8. 0-RTT and Anti-Replay . . . . . . . . . . . . . . . . . . . . 98 137 8.1. Single-Use Tickets . . . . . . . . . . . . . . . . . . . 100 138 8.2. Client Hello Recording . . . . . . . . . . . . . . . . . 100 139 8.3. Freshness Checks . . . . . . . . . . . . . . . . . . . . 101 140 9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 103 141 9.1. Mandatory-to-Implement Cipher Suites . . . . . . . . . . 103 142 9.2. Mandatory-to-Implement Extensions . . . . . . . . . . . . 103 143 9.3. Protocol Invariants . . . . . . . . . . . . . . . . . . . 104 144 10. Security Considerations . . . . . . . . . . . . . . . . . . . 105 145 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106 146 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 107 147 12.1. Normative References . . . . . . . . . . . . . . . . . . 107 148 12.2. Informative References . . . . . . . . . . . . . . . . . 110 149 Appendix A. State Machine . . . . . . . . . . . . . . . . . . . 118 150 A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 118 151 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 119 152 Appendix B. Protocol Data Structures and Constant Values . . . . 119 153 B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 120 154 B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 120 155 B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 122 156 B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 122 157 B.3.2. Server Parameters Messages . . . . . . . . . . . . . 127 158 B.3.3. Authentication Messages . . . . . . . . . . . . . . . 128 159 B.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 129 160 B.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 130 161 B.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 130 162 Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 131 163 C.1. Random Number Generation and Seeding . . . . . . . . . . 131 164 C.2. Certificates and Authentication . . . . . . . . . . . . . 132 165 C.3. Implementation Pitfalls . . . . . . . . . . . . . . . . . 132 166 C.4. Client Tracking Prevention . . . . . . . . . . . . . . . 133 167 C.5. Unauthenticated Operation . . . . . . . . . . . . . . . . 134 168 Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 134 169 D.1. Negotiating with an older server . . . . . . . . . . . . 135 170 D.2. Negotiating with an older client . . . . . . . . . . . . 136 171 D.3. 0-RTT backwards compatibility . . . . . . . . . . . . . . 136 172 D.4. Middlebox Compatibility Mode . . . . . . . . . . . . . . 136 173 D.5. Backwards Compatibility Security Restrictions . . . . . . 137 174 Appendix E. Overview of Security Properties . . . . . . . . . . 138 175 E.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 138 176 E.1.1. Key Derivation and HKDF . . . . . . . . . . . . . . . 141 177 E.1.2. Client Authentication . . . . . . . . . . . . . . . . 142 178 E.1.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . 142 179 E.1.4. Exporter Independence . . . . . . . . . . . . . . . . 142 180 E.1.5. Post-Compromise Security . . . . . . . . . . . . . . 143 181 E.1.6. External References . . . . . . . . . . . . . . . . . 143 182 E.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 143 183 E.2.1. External References . . . . . . . . . . . . . . . . . 144 184 E.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 144 185 E.4. Side Channel Attacks . . . . . . . . . . . . . . . . . . 145 186 E.5. Replay Attacks on 0-RTT . . . . . . . . . . . . . . . . . 146 187 E.5.1. Replay and Exporters . . . . . . . . . . . . . . . . 147 188 E.6. Attacks on Static RSA . . . . . . . . . . . . . . . . . . 148 189 Appendix F. Working Group Information . . . . . . . . . . . . . 148 190 Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 148 191 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 155 193 1. Introduction 195 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this 196 draft is maintained in GitHub. Suggested changes should be submitted 197 as pull requests at https://github.com/tlswg/tls13-spec. 198 Instructions are on that page as well. Editorial changes can be 199 managed in GitHub, but any substantive change should be discussed on 200 the TLS mailing list. 202 The primary goal of TLS is to provide a secure channel between two 203 communicating peers; the only requirement from the underlying 204 transport is a reliable, in-order, data stream. Specifically, the 205 secure channel should provide the following properties: 207 - Authentication: The server side of the channel is always 208 authenticated; the client side is optionally authenticated. 209 Authentication can happen via asymmetric cryptography (e.g., RSA 210 [RSA], ECDSA [ECDSA], EdDSA [RFC8032]) or a pre-shared key (PSK). 212 - Confidentiality: Data sent over the channel after establishment is 213 only visible to the endpoints. TLS does not hide the length of 214 the data it transmits, though endpoints are able to pad TLS 215 records in order to obscure lengths and improve protection against 216 traffic analysis techniques. 218 - Integrity: Data sent over the channel after establishment cannot 219 be modified by attackers. 221 These properties should be true even in the face of an attacker who 222 has complete control of the network, as described in [RFC3552]. See 223 Appendix E for a more complete statement of the relevant security 224 properties. 226 TLS consists of two primary components: 228 - A handshake protocol (Section 4) that authenticates the 229 communicating parties, negotiates cryptographic modes and 230 parameters, and establishes shared keying material. The handshake 231 protocol is designed to resist tampering; an active attacker 232 should not be able to force the peers to negotiate different 233 parameters than they would if the connection were not under 234 attack. 236 - A record protocol (Section 5) that uses the parameters established 237 by the handshake protocol to protect traffic between the 238 communicating peers. The record protocol divides traffic up into 239 a series of records, each of which is independently protected 240 using the traffic keys. 242 TLS is application protocol independent; higher-level protocols can 243 layer on top of TLS transparently. The TLS standard, however, does 244 not specify how protocols add security with TLS; how to initiate TLS 245 handshaking and how to interpret the authentication certificates 246 exchanged are left to the judgment of the designers and implementors 247 of protocols that run on top of TLS. 249 This document defines TLS version 1.3. While TLS 1.3 is not directly 250 compatible with previous versions, all versions of TLS incorporate a 251 versioning mechanism which allows clients and servers to 252 interoperably negotiate a common version if one is supported by both 253 peers. 255 This document supersedes and obsoletes previous versions of TLS 256 including version 1.2 [RFC5246]. It also obsoletes the TLS ticket 257 mechanism defined in [RFC5077] and replaces it with the mechanism 258 defined in Section 2.2. Section 4.2.7 updates [RFC4492] by modifying 259 the protocol attributes used to negotiate Elliptic Curves. Because 260 TLS 1.3 changes the way keys are derived, it updates [RFC5705] as 261 described in Section 7.5. It also changes how OCSP messages are 262 carried and therefore updates [RFC6066] and obsoletes [RFC6961] as 263 described in section Section 4.4.2.1. 265 1.1. Conventions and Terminology 267 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 268 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 269 "OPTIONAL" in this document are to be interpreted as described in BCP 270 14 [RFC2119] [RFC8174] when, and only when, they appear in all 271 capitals, as shown here. 273 The following terms are used: 275 client: The endpoint initiating the TLS connection. 277 connection: A transport-layer connection between two endpoints. 279 endpoint: Either the client or server of the connection. 281 handshake: An initial negotiation between client and server that 282 establishes the parameters of their subsequent interactions within 283 TLS. 285 peer: An endpoint. When discussing a particular endpoint, "peer" 286 refers to the endpoint that is not the primary subject of discussion. 288 receiver: An endpoint that is receiving records. 290 sender: An endpoint that is transmitting records. 292 server: The endpoint which did not initiate the TLS connection. 294 1.2. Change Log 296 RFC EDITOR PLEASE DELETE THIS SECTION. 298 (*) indicates changes to the wire protocol which may require 299 implementations to update. 301 draft-26 303 - Clarify that you can't negotiate pre-TLS 1.3 with 304 supported_versions. 306 draft-25 308 - Add the header to additional data (*) 310 - Minor clarifications. 312 - IANA cleanup. 314 draft-24 316 - Require that CH2 have version 0303 (*) 318 - Some clarifications 320 draft-23 322 - Renumber key_share (*) 324 - Add a new extension and new code points to allow negotiating PSS 325 separately for certificates and CertificateVerify (*) 327 - Slightly restrict when CCS must be accepted to make implementation 328 easier. 330 - Document protocol invariants 332 - Add some text on the security of static RSA. 334 draft-22 336 - Implement changes for improved middlebox penetration (*) 337 - Move server_certificate_type to encrypted extensions (*) 339 - Allow resumption with a different SNI (*) 341 - Padding extension can change on HRR (*) 343 - Allow an empty ticket_nonce (*) 345 - Remove requirement to immediately respond to close_notify with 346 close_notify (allowing half-close) 348 draft-21 350 - Add a per-ticket nonce so that each ticket is associated with a 351 different PSK (*). 353 - Clarify that clients should send alerts with the handshake key if 354 possible. 356 - Update state machine to show rekeying events 358 - Add discussion of 0-RTT and replay. Recommend that 359 implementations implement some anti-replay mechanism. 361 draft-20 363 - Add "post_handshake_auth" extension to negotiate post-handshake 364 authentication (*). 366 - Shorten labels for HKDF-Expand-Label so that we can fit within one 367 compression block (*). 369 - Define how RFC 7250 works (*). 371 - Re-enable post-handshake client authentication even when you do 372 PSK. The previous prohibition was editorial error. 374 - Remove cert_type and user_mapping, which don't work on TLS 1.3 375 anyway. 377 - Added the no_application_protocol alert from [RFC7301] to the list 378 of extensions. 380 - Added discussion of traffic analysis and side channel attacks. 382 draft-19 384 - Hash context_value input to Exporters (*) 385 - Add an additional Derive-Secret stage to Exporters (*). 387 - Hash ClientHello1 in the transcript when HRR is used. This 388 reduces the state that needs to be carried in cookies. (*) 390 - Restructure CertificateRequest to have the selectors in 391 extensions. This also allowed defining a 392 "certificate_authorities" extension which can be used by the 393 client instead of trusted_ca_keys (*). 395 - Tighten record framing requirements and require checking of them 396 (*). 398 - Consolidate "ticket_early_data_info" and "early_data" into a 399 single extension (*). 401 - Change end_of_early_data to be a handshake message (*). 403 - Add pre-extract Derive-Secret stages to key schedule (*). 405 - Remove spurious requirement to implement "pre_shared_key". 407 - Clarify location of "early_data" from server (it goes in EE, as 408 indicated by the table in S 10). 410 - Require peer public key validation 412 - Add state machine diagram. 414 draft-18 416 - Remove unnecessary resumption_psk which is the only thing expanded 417 from the resumption master secret. (*). 419 - Fix signature_algorithms entry in extensions table. 421 - Restate rule from RFC 6066 that you can't resume unless SNI is the 422 same. 424 draft-17 426 - Remove 0-RTT Finished and resumption_context, and replace with a 427 psk_binder field in the PSK itself (*) 429 - Restructure PSK key exchange negotiation modes (*) 431 - Add max_early_data_size field to TicketEarlyDataInfo (*) 432 - Add a 0-RTT exporter and change the transcript for the regular 433 exporter (*) 435 - Merge TicketExtensions and Extensions registry. Changes 436 ticket_early_data_info code point (*) 438 - Replace Client.key_shares in response to HRR (*) 440 - Remove redundant labels for traffic key derivation (*) 442 - Harmonize requirements about cipher suite matching: for resumption 443 you need to match KDF but for 0-RTT you need whole cipher suite. 444 This allows PSKs to actually negotiate cipher suites. (*) 446 - Move SCT and OCSP into Certificate.extensions (*) 448 - Explicitly allow non-offered extensions in NewSessionTicket 450 - Explicitly allow predicting client Finished for NST 452 - Clarify conditions for allowing 0-RTT with PSK 454 draft-16 456 - Revise version negotiation (*) 458 - Change RSASSA-PSS and EdDSA SignatureScheme codepoints for better 459 backwards compatibility (*) 461 - Move HelloRetryRequest.selected_group to an extension (*) 463 - Clarify the behavior of no exporter context and make it the same 464 as an empty context.(*) 466 - New KeyUpdate format that allows for requesting/not-requesting an 467 answer. This also means changes to the key schedule to support 468 independent updates (*) 470 - New certificate_required alert (*) 472 - Forbid CertificateRequest with 0-RTT and PSK. 474 - Relax requirement to check SNI for 0-RTT. 476 draft-15 478 - New negotiation syntax as discussed in Berlin (*) 479 - Require CertificateRequest.context to be empty during handshake 480 (*) 482 - Forbid empty tickets (*) 484 - Forbid application data messages in between post-handshake 485 messages from the same flight (*) 487 - Clean up alert guidance (*) 489 - Clearer guidance on what is needed for TLS 1.2. 491 - Guidance on 0-RTT time windows. 493 - Rename a bunch of fields. 495 - Remove old PRNG text. 497 - Explicitly require checking that handshake records not span key 498 changes. 500 draft-14 502 - Allow cookies to be longer (*) 504 - Remove the "context" from EarlyDataIndication as it was undefined 505 and nobody used it (*) 507 - Remove 0-RTT EncryptedExtensions and replace the ticket_age 508 extension with an obfuscated version. Also necessitates a change 509 to NewSessionTicket (*). 511 - Move the downgrade sentinel to the end of ServerHello.Random to 512 accommodate tlsdate (*). 514 - Define ecdsa_sha1 (*). 516 - Allow resumption even after fatal alerts. This matches current 517 practice. 519 - Remove non-closure warning alerts. Require treating unknown 520 alerts as fatal. 522 - Make the rules for accepting 0-RTT less restrictive. 524 - Clarify 0-RTT backward-compatibility rules. 526 - Clarify how 0-RTT and PSK identities interact. 528 - Add a section describing the data limits for each cipher. 530 - Major editorial restructuring. 532 - Replace the Security Analysis section with a WIP draft. 534 draft-13 536 - Allow server to send SupportedGroups. 538 - Remove 0-RTT client authentication 540 - Remove (EC)DHE 0-RTT. 542 - Flesh out 0-RTT PSK mode and shrink EarlyDataIndication 544 - Turn PSK-resumption response into an index to save room 546 - Move CertificateStatus to an extension 548 - Extra fields in NewSessionTicket. 550 - Restructure key schedule and add a resumption_context value. 552 - Require DH public keys and secrets to be zero-padded to the size 553 of the group. 555 - Remove the redundant length fields in KeyShareEntry. 557 - Define a cookie field for HRR. 559 draft-12 561 - Provide a list of the PSK cipher suites. 563 - Remove the ability for the ServerHello to have no extensions (this 564 aligns the syntax with the text). 566 - Clarify that the server can send application data after its first 567 flight (0.5 RTT data) 569 - Revise signature algorithm negotiation to group hash, signature 570 algorithm, and curve together. This is backwards compatible. 572 - Make ticket lifetime mandatory and limit it to a week. 574 - Make the purpose strings lower-case. This matches how people are 575 implementing for interop. 577 - Define exporters. 579 - Editorial cleanup 581 draft-11 583 - Port the CFRG curves & signatures work from RFC4492bis. 585 - Remove sequence number and version from additional_data, which is 586 now empty. 588 - Reorder values in HkdfLabel. 590 - Add support for version anti-downgrade mechanism. 592 - Update IANA considerations section and relax some of the policies. 594 - Unify authentication modes. Add post-handshake client 595 authentication. 597 - Remove early_handshake content type. Terminate 0-RTT data with an 598 alert. 600 - Reset sequence number upon key change (as proposed by Fournet et 601 al.) 603 draft-10 605 - Remove ClientCertificateTypes field from CertificateRequest and 606 add extensions. 608 - Merge client and server key shares into a single extension. 610 draft-09 612 - Change to RSA-PSS signatures for handshake messages. 614 - Remove support for DSA. 616 - Update key schedule per suggestions by Hugo, Hoeteck, and Bjoern 617 Tackmann. 619 - Add support for per-record padding. 621 - Switch to encrypted record ContentType. 623 - Change HKDF labeling to include protocol version and value 624 lengths. 626 - Shift the final decision to abort a handshake due to incompatible 627 certificates to the client rather than having servers abort early. 629 - Deprecate SHA-1 with signatures. 631 - Add MTI algorithms. 633 draft-08 635 - Remove support for weak and lesser used named curves. 637 - Remove support for MD5 and SHA-224 hashes with signatures. 639 - Update lists of available AEAD cipher suites and error alerts. 641 - Reduce maximum permitted record expansion for AEAD from 2048 to 642 256 octets. 644 - Require digital signatures even when a previous configuration is 645 used. 647 - Merge EarlyDataIndication and KnownConfiguration. 649 - Change code point for server_configuration to avoid collision with 650 server_hello_done. 652 - Relax certificate_list ordering requirement to match current 653 practice. 655 draft-07 657 - Integration of semi-ephemeral DH proposal. 659 - Add initial 0-RTT support. 661 - Remove resumption and replace with PSK + tickets. 663 - Move ClientKeyShare into an extension. 665 - Move to HKDF. 667 draft-06 669 - Prohibit RC4 negotiation for backwards compatibility. 671 - Freeze & deprecate record layer version field. 673 - Update format of signatures with context. 675 - Remove explicit IV. 677 draft-05 679 - Prohibit SSL negotiation for backwards compatibility. 681 - Fix which MS is used for exporters. 683 draft-04 685 - Modify key computations to include session hash. 687 - Remove ChangeCipherSpec. 689 - Renumber the new handshake messages to be somewhat more consistent 690 with existing convention and to remove a duplicate registration. 692 - Remove renegotiation. 694 - Remove point format negotiation. 696 draft-03 698 - Remove GMT time. 700 - Merge in support for ECC from RFC 4492 but without explicit 701 curves. 703 - Remove the unnecessary length field from the AD input to AEAD 704 ciphers. 706 - Rename {Client,Server}KeyExchange to {Client,Server}KeyShare. 708 - Add an explicit HelloRetryRequest to reject the client's. 710 draft-02 712 - Increment version number. 714 - Rework handshake to provide 1-RTT mode. 716 - Remove custom DHE groups. 718 - Remove support for compression. 720 - Remove support for static RSA and DH key exchange. 722 - Remove support for non-AEAD ciphers. 724 1.3. Major Differences from TLS 1.2 726 The following is a list of the major functional differences between 727 TLS 1.2 and TLS 1.3. It is not intended to be exhaustive and there 728 are many minor differences. 730 - The list of supported symmetric algorithms has been pruned of all 731 algorithms that are considered legacy. Those that remain all use 732 Authenticated Encryption with Associated Data (AEAD) algorithms. 733 The ciphersuite concept has been changed to separate the 734 authentication and key exchange mechanisms from the record 735 protection algorithm (including secret key length) and a hash to 736 be used with the key derivation function and HMAC. 738 - A 0-RTT mode was added, saving a round-trip at connection setup 739 for some application data, at the cost of certain security 740 properties. 742 - Static RSA and Diffie-Hellman cipher suites have been removed; all 743 public-key based key exchange mechanisms now provide forward 744 secrecy. 746 - All handshake messages after the ServerHello are now encrypted. 747 The newly introduced EncryptedExtension message allows various 748 extensions previously sent in clear in the ServerHello to also 749 enjoy confidentiality protection from active attackers. 751 - The key derivation functions have been re-designed. The new 752 design allows easier analysis by cryptographers due to their 753 improved key separation properties. The HMAC-based Extract-and- 754 Expand Key Derivation Function (HKDF) is used as an underlying 755 primitive. 757 - The handshake state machine has been significantly restructured to 758 be more consistent and to remove superfluous messages such as 759 ChangeCipherSpec (except when needed for middlebox compatibility). 761 - Elliptic curve algorithms are now in the base spec and new 762 signature algorithms, such as ed25519 and ed448, are included. 763 TLS 1.3 removed point format negotiation in favor of a single 764 point format for each curve. 766 - Other cryptographic improvements including the removal of 767 compression and custom DHE groups, changing the RSA padding to use 768 RSASSA-PSS, and the removal of DSA. 770 - The TLS 1.2 version negotiation mechanism has been deprecated in 771 favor of a version list in an extension. This increases 772 compatibility with existing servers that incorrectly implemented 773 version negotiation. 775 - Session resumption with and without server-side state as well as 776 the PSK-based ciphersuites of earlier TLS versions have been 777 replaced by a single new PSK exchange. 779 - Updated references to point to the updated versions of RFCs, as 780 appropriate (e.g., RFC 5280 rather than RFC 3280). 782 1.4. Updates Affecting TLS 1.2 784 This document defines several changes that optionally affect 785 implementations of TLS 1.2, including those which do not also support 786 TLS 1.3: 788 - A version downgrade protection mechanism is described in 789 Section 4.1.3. 791 - RSASSA-PSS signature schemes are defined in Section 4.2.3. 793 - The "supported_versions" ClientHello extension can be used to 794 negotiate the version of TLS to use, in preference to the 795 legacy_version field of the ClientHello. 797 - The "signature_algorithms_cert" extension allows a client to 798 indicate which signature algorithms it can validate in X.509 799 certificates 801 Additionally, this document clarifies some compliance requirements 802 for earlier versions of TLS; see Section 9.3. 804 2. Protocol Overview 806 The cryptographic parameters used by the secure channel are produced 807 by the TLS handshake protocol. This sub-protocol of TLS is used by 808 the client and server when first communicating with each other. The 809 handshake protocol allows peers to negotiate a protocol version, 810 select cryptographic algorithms, optionally authenticate each other, 811 and establish shared secret keying material. Once the handshake is 812 complete, the peers use the established keys to protect the 813 application layer traffic. 815 A failure of the handshake or other protocol error triggers the 816 termination of the connection, optionally preceded by an alert 817 message (Section 6). 819 TLS supports three basic key exchange modes: 821 - (EC)DHE (Diffie-Hellman over either finite fields or elliptic 822 curves) 824 - PSK-only 826 - PSK with (EC)DHE 828 Figure 1 below shows the basic full TLS handshake: 830 Client Server 832 Key ^ ClientHello 833 Exch | + key_share* 834 | + signature_algorithms* 835 | + psk_key_exchange_modes* 836 v + pre_shared_key* --------> 837 ServerHello ^ Key 838 + key_share* | Exch 839 + pre_shared_key* v 840 {EncryptedExtensions} ^ Server 841 {CertificateRequest*} v Params 842 {Certificate*} ^ 843 {CertificateVerify*} | Auth 844 {Finished} v 845 <-------- [Application Data*] 846 ^ {Certificate*} 847 Auth | {CertificateVerify*} 848 v {Finished} --------> 849 [Application Data] <-------> [Application Data] 851 + Indicates noteworthy extensions sent in the 852 previously noted message. 854 * Indicates optional or situation-dependent 855 messages/extensions that are not always sent. 857 {} Indicates messages protected using keys 858 derived from a [sender]_handshake_traffic_secret. 860 [] Indicates messages protected using keys 861 derived from [sender]_application_traffic_secret_N 863 Figure 1: Message flow for full TLS Handshake 865 The handshake can be thought of as having three phases (indicated in 866 the diagram above): 868 - Key Exchange: Establish shared keying material and select the 869 cryptographic parameters. Everything after this phase is 870 encrypted. 872 - Server Parameters: Establish other handshake parameters (whether 873 the client is authenticated, application layer protocol support, 874 etc.). 876 - Authentication: Authenticate the server (and optionally the 877 client) and provide key confirmation and handshake integrity. 879 In the Key Exchange phase, the client sends the ClientHello 880 (Section 4.1.2) message, which contains a random nonce 881 (ClientHello.random); its offered protocol versions; a list of 882 symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key 883 shares (in the "key_share" extension Section 4.2.8), a set of pre- 884 shared key labels (in the "pre_shared_key" extension Section 4.2.11) 885 or both; and potentially additional extensions. Additional fields 886 and/or messages may also be present for middlebox compatibility. 888 The server processes the ClientHello and determines the appropriate 889 cryptographic parameters for the connection. It then responds with 890 its own ServerHello (Section 4.1.3), which indicates the negotiated 891 connection parameters. The combination of the ClientHello and the 892 ServerHello determines the shared keys. If (EC)DHE key establishment 893 is in use, then the ServerHello contains a "key_share" extension with 894 the server's ephemeral Diffie-Hellman share; the server's share MUST 895 be in the same group as one of the client's shares. If PSK key 896 establishment is in use, then the ServerHello contains a 897 "pre_shared_key" extension indicating which of the client's offered 898 PSKs was selected. Note that implementations can use (EC)DHE and PSK 899 together, in which case both extensions will be supplied. 901 The server then sends two messages to establish the Server 902 Parameters: 904 EncryptedExtensions: responses to ClientHello extensions that are 905 not required to determine the cryptographic parameters, other than 906 those that are specific to individual certificates. 907 [Section 4.3.1] 909 CertificateRequest: if certificate-based client authentication is 910 desired, the desired parameters for that certificate. This 911 message is omitted if client authentication is not desired. 912 [Section 4.3.2] 914 Finally, the client and server exchange Authentication messages. TLS 915 uses the same set of messages every time that certificate-based 916 authentication is needed. (PSK-based authentication happens as a 917 side effect of key exchange.) Specifically: 919 Certificate: the certificate of the endpoint and any per-certificate 920 extensions. This message is omitted by the server if not 921 authenticating with a certificate and by the client if the server 922 did not send CertificateRequest (thus indicating that the client 923 should not authenticate with a certificate). Note that if raw 924 public keys [RFC7250] or the cached information extension 925 [RFC7924] are in use, then this message will not contain a 926 certificate but rather some other value corresponding to the 927 server's long-term key. [Section 4.4.2] 929 CertificateVerify: a signature over the entire handshake using the 930 private key corresponding to the public key in the Certificate 931 message. This message is omitted if the endpoint is not 932 authenticating via a certificate. [Section 4.4.3] 934 Finished: a MAC (Message Authentication Code) over the entire 935 handshake. This message provides key confirmation, binds the 936 endpoint's identity to the exchanged keys, and in PSK mode also 937 authenticates the handshake. [Section 4.4.4] 939 Upon receiving the server's messages, the client responds with its 940 Authentication messages, namely Certificate and CertificateVerify (if 941 requested), and Finished. 943 At this point, the handshake is complete, and the client and server 944 derive the keying material required by the record layer to exchange 945 application-layer data protected through authenticated encryption. 946 Application data MUST NOT be sent prior to sending the Finished 947 message, except as specified in [Section 2.3]. Note that while the 948 server may send application data prior to receiving the client's 949 Authentication messages, any data sent at that point is, of course, 950 being sent to an unauthenticated peer. 952 2.1. Incorrect DHE Share 954 If the client has not provided a sufficient "key_share" extension 955 (e.g., it includes only DHE or ECDHE groups unacceptable to or 956 unsupported by the server), the server corrects the mismatch with a 957 HelloRetryRequest and the client needs to restart the handshake with 958 an appropriate "key_share" extension, as shown in Figure 2. If no 959 common cryptographic parameters can be negotiated, the server MUST 960 abort the handshake with an appropriate alert. 962 Client Server 964 ClientHello 965 + key_share --------> 966 HelloRetryRequest 967 <-------- + key_share 968 ClientHello 969 + key_share --------> 970 ServerHello 971 + key_share 972 {EncryptedExtensions} 973 {CertificateRequest*} 974 {Certificate*} 975 {CertificateVerify*} 976 {Finished} 977 <-------- [Application Data*] 978 {Certificate*} 979 {CertificateVerify*} 980 {Finished} --------> 981 [Application Data] <-------> [Application Data] 983 Figure 2: Message flow for a full handshake with mismatched 984 parameters 986 Note: The handshake transcript incorporates the initial ClientHello/ 987 HelloRetryRequest exchange; it is not reset with the new ClientHello. 989 TLS also allows several optimized variants of the basic handshake, as 990 described in the following sections. 992 2.2. Resumption and Pre-Shared Key (PSK) 994 Although TLS PSKs can be established out of band, PSKs can also be 995 established in a previous connection and then used to establish a new 996 connection ("session resumption" or "resuming" with a PSK). Once a 997 handshake has completed, the server can send to the client a PSK 998 identity that corresponds to a unique key derived from the initial 999 handshake (see Section 4.6.1). The client can then use that PSK 1000 identity in future handshakes to negotiate the use of the associated 1001 PSK. If the server accepts the PSK, then the security context of the 1002 new connection is cryptographically tied to the original connection 1003 and the key derived from the initial handshake is used to bootstrap 1004 the cryptographic state instead of a full handshake. In TLS 1.2 and 1005 below, this functionality was provided by "session IDs" and "session 1006 tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3. 1008 PSKs can be used with (EC)DHE key exchange in order to provide 1009 forward secrecy in combination with shared keys, or can be used 1010 alone, at the cost of losing forward secrecy for the application 1011 data. 1013 Figure 3 shows a pair of handshakes in which the first establishes a 1014 PSK and the second uses it: 1016 Client Server 1018 Initial Handshake: 1019 ClientHello 1020 + key_share --------> 1021 ServerHello 1022 + key_share 1023 {EncryptedExtensions} 1024 {CertificateRequest*} 1025 {Certificate*} 1026 {CertificateVerify*} 1027 {Finished} 1028 <-------- [Application Data*] 1029 {Certificate*} 1030 {CertificateVerify*} 1031 {Finished} --------> 1032 <-------- [NewSessionTicket] 1033 [Application Data] <-------> [Application Data] 1035 Subsequent Handshake: 1036 ClientHello 1037 + key_share* 1038 + pre_shared_key --------> 1039 ServerHello 1040 + pre_shared_key 1041 + key_share* 1042 {EncryptedExtensions} 1043 {Finished} 1044 <-------- [Application Data*] 1045 {Finished} --------> 1046 [Application Data] <-------> [Application Data] 1048 Figure 3: Message flow for resumption and PSK 1050 As the server is authenticating via a PSK, it does not send a 1051 Certificate or a CertificateVerify message. When a client offers 1052 resumption via PSK, it SHOULD also supply a "key_share" extension to 1053 the server to allow the server to decline resumption and fall back to 1054 a full handshake, if needed. The server responds with a 1055 "pre_shared_key" extension to negotiate use of PSK key establishment 1056 and can (as shown here) respond with a "key_share" extension to do 1057 (EC)DHE key establishment, thus providing forward secrecy. 1059 When PSKs are provisioned out of band, the PSK identity and the KDF 1060 hash algorithm to be used with the PSK MUST also be provisioned. 1062 Note: When using an out-of-band provisioned pre-shared secret, a 1063 critical consideration is using sufficient entropy during the key 1064 generation, as discussed in [RFC4086]. Deriving a shared secret 1065 from a password or other low-entropy sources is not secure. A 1066 low-entropy secret, or password, is subject to dictionary attacks 1067 based on the PSK binder. The specified PSK authentication is not 1068 a strong password-based authenticated key exchange even when used 1069 with Diffie-Hellman key establishment. Specifically, it does not 1070 prevent an attacker that can observe the handshake from performing 1071 a brute-force attack on the password/pre-shared key. 1073 2.3. 0-RTT Data 1075 When clients and servers share a PSK (either obtained externally or 1076 via a previous handshake), TLS 1.3 allows clients to send data on the 1077 first flight ("early data"). The client uses the PSK to authenticate 1078 the server and to encrypt the early data. 1080 As shown in Figure 4, the 0-RTT data is just added to the 1-RTT 1081 handshake in the first flight. The rest of the handshake uses the 1082 same messages as for a 1-RTT handshake with PSK resumption. 1084 Client Server 1086 ClientHello 1087 + early_data 1088 + key_share* 1089 + psk_key_exchange_modes 1090 + pre_shared_key 1091 (Application Data*) --------> 1092 ServerHello 1093 + pre_shared_key 1094 + key_share* 1095 {EncryptedExtensions} 1096 + early_data* 1097 {Finished} 1098 <-------- [Application Data*] 1099 (EndOfEarlyData) 1100 {Finished} --------> 1101 [Application Data] <-------> [Application Data] 1103 + Indicates noteworthy extensions sent in the 1104 previously noted message. 1106 * Indicates optional or situation-dependent 1107 messages/extensions that are not always sent. 1109 () Indicates messages protected using keys 1110 derived from client_early_traffic_secret. 1112 {} Indicates messages protected using keys 1113 derived from a [sender]_handshake_traffic_secret. 1115 [] Indicates messages protected using keys 1116 derived from [sender]_application_traffic_secret_N 1118 Figure 4: Message flow for a zero round trip handshake 1120 IMPORTANT NOTE: The security properties for 0-RTT data are weaker 1121 than those for other kinds of TLS data. Specifically: 1123 1. This data is not forward secret, as it is encrypted solely under 1124 keys derived using the offered PSK. 1126 2. There are no guarantees of non-replay between connections. 1127 Protection against replay for ordinary TLS 1.3 1-RTT data is 1128 provided via the server's Random value, but 0-RTT data does not 1129 depend on the ServerHello and therefore has weaker guarantees. 1130 This is especially relevant if the data is authenticated either 1131 with TLS client authentication or inside the application 1132 protocol. The same warnings apply to any use of the 1133 early_exporter_master_secret. 1135 0-RTT data cannot be duplicated within a connection (i.e., the server 1136 will not process the same data twice for the same connection) and an 1137 attacker will not be able to make 0-RTT data appear to be 1-RTT data 1138 (because it is protected with different keys.) Appendix E.5 contains 1139 a description of potential attacks and Section 8 describes mechanisms 1140 which the server can use to limit the impact of replay. 1142 3. Presentation Language 1144 This document deals with the formatting of data in an external 1145 representation. The following very basic and somewhat casually 1146 defined presentation syntax will be used. 1148 3.1. Basic Block Size 1150 The representation of all data items is explicitly specified. The 1151 basic data block size is one byte (i.e., 8 bits). Multiple byte data 1152 items are concatenations of bytes, from left to right, from top to 1153 bottom. From the byte stream, a multi-byte item (a numeric in the 1154 example) is formed (using C notation) by: 1156 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | 1157 ... | byte[n-1]; 1159 This byte ordering for multi-byte values is the commonplace network 1160 byte order or big-endian format. 1162 3.2. Miscellaneous 1164 Comments begin with "/*" and end with "*/". 1166 Optional components are denoted by enclosing them in "[[ ]]" double 1167 brackets. 1169 Single-byte entities containing uninterpreted data are of type 1170 opaque. 1172 A type alias T' for an existing type T is defined by: 1174 T T'; 1176 3.3. Numbers 1178 The basic numeric data type is an unsigned byte (uint8). All larger 1179 numeric data types are formed from fixed-length series of bytes 1180 concatenated as described in Section 3.1 and are also unsigned. The 1181 following numeric types are predefined. 1183 uint8 uint16[2]; 1184 uint8 uint24[3]; 1185 uint8 uint32[4]; 1186 uint8 uint64[8]; 1188 All values, here and elsewhere in the specification, are transmitted 1189 in network byte (big-endian) order; the uint32 represented by the hex 1190 bytes 01 02 03 04 is equivalent to the decimal value 16909060. 1192 3.4. Vectors 1194 A vector (single-dimensioned array) is a stream of homogeneous data 1195 elements. The size of the vector may be specified at documentation 1196 time or left unspecified until runtime. In either case, the length 1197 declares the number of bytes, not the number of elements, in the 1198 vector. The syntax for specifying a new type, T', that is a fixed- 1199 length vector of type T is 1201 T T'[n]; 1203 Here, T' occupies n bytes in the data stream, where n is a multiple 1204 of the size of T. The length of the vector is not included in the 1205 encoded stream. 1207 In the following example, Datum is defined to be three consecutive 1208 bytes that the protocol does not interpret, while Data is three 1209 consecutive Datum, consuming a total of nine bytes. 1211 opaque Datum[3]; /* three uninterpreted bytes */ 1212 Datum Data[9]; /* 3 consecutive 3-byte vectors */ 1214 Variable-length vectors are defined by specifying a subrange of legal 1215 lengths, inclusively, using the notation . When 1216 these are encoded, the actual length precedes the vector's contents 1217 in the byte stream. The length will be in the form of a number 1218 consuming as many bytes as required to hold the vector's specified 1219 maximum (ceiling) length. A variable-length vector with an actual 1220 length field of zero is referred to as an empty vector. 1222 T T'; 1224 In the following example, mandatory is a vector that must contain 1225 between 300 and 400 bytes of type opaque. It can never be empty. 1226 The actual length field consumes two bytes, a uint16, which is 1227 sufficient to represent the value 400 (see Section 3.3). Similarly, 1228 longer can represent up to 800 bytes of data, or 400 uint16 elements, 1229 and it may be empty. Its encoding will include a two-byte actual 1230 length field prepended to the vector. The length of an encoded 1231 vector must be an exact multiple of the length of a single element 1232 (e.g., a 17-byte vector of uint16 would be illegal). 1234 opaque mandatory<300..400>; 1235 /* length field is 2 bytes, cannot be empty */ 1236 uint16 longer<0..800>; 1237 /* zero to 400 16-bit unsigned integers */ 1239 3.5. Enumerateds 1241 An additional sparse data type is available called enum or 1242 enumerated. Each definition is a different type. Only enumerateds 1243 of the same type may be assigned or compared. Every element of an 1244 enumerated must be assigned a value, as demonstrated in the following 1245 example. Since the elements of the enumerated are not ordered, they 1246 can be assigned any unique value, in any order. 1248 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; 1250 Future extensions or additions to the protocol may define new values. 1251 Implementations need to be able to parse and ignore unknown values 1252 unless the definition of the field states otherwise. 1254 An enumerated occupies as much space in the byte stream as would its 1255 maximal defined ordinal value. The following definition would cause 1256 one byte to be used to carry fields of type Color. 1258 enum { red(3), blue(5), white(7) } Color; 1260 One may optionally specify a value without its associated tag to 1261 force the width definition without defining a superfluous element. 1263 In the following example, Taste will consume two bytes in the data 1264 stream but can only assume the values 1, 2, or 4 in the current 1265 version of the protocol. 1267 enum { sweet(1), sour(2), bitter(4), (32000) } Taste; 1269 The names of the elements of an enumeration are scoped within the 1270 defined type. In the first example, a fully qualified reference to 1271 the second element of the enumeration would be Color.blue. Such 1272 qualification is not required if the target of the assignment is well 1273 specified. 1275 Color color = Color.blue; /* overspecified, legal */ 1276 Color color = blue; /* correct, type implicit */ 1278 The names assigned to enumerateds do not need to be unique. The 1279 numerical value can describe a range over which the same name 1280 applies. The value includes the minimum and maximum inclusive values 1281 in that range, separated by two period characters. This is 1282 principally useful for reserving regions of the space. 1284 enum { sad(0), meh(1..254), happy(255) } Mood; 1286 3.6. Constructed Types 1288 Structure types may be constructed from primitive types for 1289 convenience. Each specification declares a new, unique type. The 1290 syntax for definition is much like that of C. 1292 struct { 1293 T1 f1; 1294 T2 f2; 1295 ... 1296 Tn fn; 1297 } T; 1299 Fixed- and variable-length vector fields are allowed using the 1300 standard vector syntax. Structures V1 and V2 in the variants example 1301 below demonstrate this. 1303 The fields within a structure may be qualified using the type's name, 1304 with a syntax much like that available for enumerateds. For example, 1305 T.f2 refers to the second field of the previous declaration. 1307 3.7. Constants 1309 Fields and variables may be assigned a fixed value using "=", as in: 1311 struct { 1312 T1 f1 = 8; /* T.f1 must always be 8 */ 1313 T2 f2; 1314 } T; 1316 3.8. Variants 1318 Defined structures may have variants based on some knowledge that is 1319 available within the environment. The selector must be an enumerated 1320 type that defines the possible variants the structure defines. Each 1321 arm of the select specifies the type of that variant's field and an 1322 optional field label. The mechanism by which the variant is selected 1323 at runtime is not prescribed by the presentation language. 1325 struct { 1326 T1 f1; 1327 T2 f2; 1328 .... 1329 Tn fn; 1330 select (E) { 1331 case e1: Te1 [[fe1]]; 1332 case e2: Te2 [[fe2]]; 1333 .... 1334 case en: Ten [[fen]]; 1335 }; 1336 } Tv; 1338 For example: 1340 enum { apple(0), orange(1) } VariantTag; 1342 struct { 1343 uint16 number; 1344 opaque string<0..10>; /* variable length */ 1345 } V1; 1347 struct { 1348 uint32 number; 1349 opaque string[10]; /* fixed length */ 1350 } V2; 1352 struct { 1353 VariantTag type; 1354 select (VariantRecord.type) { 1355 case apple: V1; 1356 case orange: V2; 1357 }; 1358 } VariantRecord; 1360 4. Handshake Protocol 1362 The handshake protocol is used to negotiate the security parameters 1363 of a connection. Handshake messages are supplied to the TLS record 1364 layer, where they are encapsulated within one or more TLSPlaintext or 1365 TLSCiphertext structures, which are processed and transmitted as 1366 specified by the current active connection state. 1368 enum { 1369 client_hello(1), 1370 server_hello(2), 1371 new_session_ticket(4), 1372 end_of_early_data(5), 1373 encrypted_extensions(8), 1374 certificate(11), 1375 certificate_request(13), 1376 certificate_verify(15), 1377 finished(20), 1378 key_update(24), 1379 message_hash(254), 1380 (255) 1381 } HandshakeType; 1383 struct { 1384 HandshakeType msg_type; /* handshake type */ 1385 uint24 length; /* bytes in message */ 1386 select (Handshake.msg_type) { 1387 case client_hello: ClientHello; 1388 case server_hello: ServerHello; 1389 case end_of_early_data: EndOfEarlyData; 1390 case encrypted_extensions: EncryptedExtensions; 1391 case certificate_request: CertificateRequest; 1392 case certificate: Certificate; 1393 case certificate_verify: CertificateVerify; 1394 case finished: Finished; 1395 case new_session_ticket: NewSessionTicket; 1396 case key_update: KeyUpdate; 1397 }; 1398 } Handshake; 1400 Protocol messages MUST be sent in the order defined in Section 4.4.1 1401 and shown in the diagrams in Section 2. A peer which receives a 1402 handshake message in an unexpected order MUST abort the handshake 1403 with an "unexpected_message" alert. 1405 New handshake message types are assigned by IANA as described in 1406 Section 11. 1408 4.1. Key Exchange Messages 1410 The key exchange messages are used to determine the security 1411 capabilities of the client and the server and to establish shared 1412 secrets including the traffic keys used to protect the rest of the 1413 handshake and the data. 1415 4.1.1. Cryptographic Negotiation 1417 In TLS, the cryptographic negotiation proceeds by the client offering 1418 the following four sets of options in its ClientHello: 1420 - A list of cipher suites which indicates the AEAD algorithm/HKDF 1421 hash pairs which the client supports. 1423 - A "supported_groups" (Section 4.2.7) extension which indicates the 1424 (EC)DHE groups which the client supports and a "key_share" 1425 (Section 4.2.8) extension which contains (EC)DHE shares for some 1426 or all of these groups. 1428 - A "signature_algorithms" (Section 4.2.3) extension which indicates 1429 the signature algorithms which the client can accept. 1431 - A "pre_shared_key" (Section 4.2.11) extension which contains a 1432 list of symmetric key identities known to the client and a 1433 "psk_key_exchange_modes" (Section 4.2.9) extension which indicates 1434 the key exchange modes that may be used with PSKs. 1436 If the server does not select a PSK, then the first three of these 1437 options are entirely orthogonal: the server independently selects a 1438 cipher suite, an (EC)DHE group and key share for key establishment, 1439 and a signature algorithm/certificate pair to authenticate itself to 1440 the client. If there is no overlap between the received 1441 "supported_groups" and the groups supported by the server then the 1442 server MUST abort the handshake with a "handshake_failure" or an 1443 "insufficient_security" alert. 1445 If the server selects a PSK, then it MUST also select a key 1446 establishment mode from the set indicated by client's 1447 "psk_key_exchange_modes" extension (at present, PSK alone or with 1448 (EC)DHE). Note that if the PSK can be used without (EC)DHE then non- 1449 overlap in the "supported_groups" parameters need not be fatal, as it 1450 is in the non-PSK case discussed in the previous paragraph. 1452 If the server selects an (EC)DHE group and the client did not offer a 1453 compatible "key_share" extension in the initial ClientHello, the 1454 server MUST respond with a HelloRetryRequest (Section 4.1.4) message. 1456 If the server successfully selects parameters and does not require a 1457 HelloRetryRequest, it indicates the selected parameters in the 1458 ServerHello as follows: 1460 - If PSK is being used, then the server will send a "pre_shared_key" 1461 extension indicating the selected key. 1463 - If PSK is not being used, then (EC)DHE and certificate-based 1464 authentication are always used. 1466 - When (EC)DHE is in use, the server will also provide a "key_share" 1467 extension. 1469 - When authenticating via a certificate, the server will send the 1470 Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3) 1471 messages. In TLS 1.3 as defined by this document, either a PSK or 1472 a certificate is always used, but not both. Future documents may 1473 define how to use them together. 1475 If the server is unable to negotiate a supported set of parameters 1476 (i.e., there is no overlap between the client and server parameters), 1477 it MUST abort the handshake with either a "handshake_failure" or 1478 "insufficient_security" fatal alert (see Section 6). 1480 4.1.2. Client Hello 1482 When a client first connects to a server, it is REQUIRED to send the 1483 ClientHello as its first TLS message. The client will also send a 1484 ClientHello when the server has responded to its ClientHello with a 1485 HelloRetryRequest. In that case, the client MUST send the same 1486 ClientHello without modification, except: 1488 - If a "key_share" extension was supplied in the HelloRetryRequest, 1489 replacing the list of shares with a list containing a single 1490 KeyShareEntry from the indicated group. 1492 - Removing the "early_data" extension (Section 4.2.10) if one was 1493 present. Early data is not permitted after HelloRetryRequest. 1495 - Including a "cookie" extension if one was provided in the 1496 HelloRetryRequest. 1498 - Updating the "pre_shared_key" extension if present by recomputing 1499 the "obfuscated_ticket_age" and binder values and (optionally) 1500 removing any PSKs which are incompatible with the server's 1501 indicated cipher suite. 1503 - Optionally adding, removing, or changing the length of the 1504 "padding" extension [RFC7685]. 1506 - Other modifications that may be allowed by an extension defined in 1507 the future and present in the HelloRetryRequest. 1509 Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS 1510 1.3 and receives a ClientHello at any other time, it MUST terminate 1511 the connection with an "unexpected_message" alert. 1513 If a server established a TLS connection with a previous version of 1514 TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST 1515 retain the previous protocol version. In particular, it MUST NOT 1516 negotiate TLS 1.3. 1518 Structure of this message: 1520 uint16 ProtocolVersion; 1521 opaque Random[32]; 1523 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1525 struct { 1526 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 1527 Random random; 1528 opaque legacy_session_id<0..32>; 1529 CipherSuite cipher_suites<2..2^16-2>; 1530 opaque legacy_compression_methods<1..2^8-1>; 1531 Extension extensions<8..2^16-1>; 1532 } ClientHello; 1534 legacy_version In previous versions of TLS, this field was used for 1535 version negotiation and represented the highest version number 1536 supported by the client. Experience has shown that many servers 1537 do not properly implement version negotiation, leading to "version 1538 intolerance" in which the server rejects an otherwise acceptable 1539 ClientHello with a version number higher than it supports. In TLS 1540 1.3, the client indicates its version preferences in the 1541 "supported_versions" extension (Section 4.2.1) and the 1542 legacy_version field MUST be set to 0x0303, which is the version 1543 number for TLS 1.2. (See Appendix D for details about backward 1544 compatibility.) 1546 random 32 bytes generated by a secure random number generator. See 1547 Appendix C for additional information. 1549 legacy_session_id Versions of TLS before TLS 1.3 supported a 1550 "session resumption" feature which has been merged with Pre-Shared 1551 Keys in this version (see Section 2.2). A client which has a 1552 cached session ID set by a pre-TLS 1.3 server SHOULD set this 1553 field to that value. In compatibility mode (see Appendix D.4) 1554 this field MUST be non-empty, so a client not offering a pre-TLS 1555 1.3 session MUST generate a new 32-byte value. This value need 1556 not be random but SHOULD be unpredictable to avoid implementations 1557 fixating on a specific value (also known as ossification). 1558 Otherwise, it MUST be set as a zero length vector (i.e., a single 1559 zero byte length field). 1561 cipher_suites This is a list of the symmetric cipher options 1562 supported by the client, specifically the record protection 1563 algorithm (including secret key length) and a hash to be used with 1564 HKDF, in descending order of client preference. If the list 1565 contains cipher suites that the server does not recognize, support 1566 or wish to use, the server MUST ignore those cipher suites and 1567 process the remaining ones as usual. Values are defined in 1568 Appendix B.4. If the client is attempting a PSK key 1569 establishment, it SHOULD advertise at least one cipher suite 1570 indicating a Hash associated with the PSK. 1572 legacy_compression_methods Versions of TLS before 1.3 supported 1573 compression with the list of supported compression methods being 1574 sent in this field. For every TLS 1.3 ClientHello, this vector 1575 MUST contain exactly one byte, set to zero, which corresponds to 1576 the "null" compression method in prior versions of TLS. If a TLS 1577 1.3 ClientHello is received with any other value in this field, 1578 the server MUST abort the handshake with an "illegal_parameter" 1579 alert. Note that TLS 1.3 servers might receive TLS 1.2 or prior 1580 ClientHellos which contain other compression methods and (if 1581 negotiating such a prior version) MUST follow the procedures for 1582 the appropriate prior version of TLS. TLS 1.3 ClientHellos are 1583 identified as having a legacy_version of 0x0303 and a 1584 supported_versions extension present with 0x0304 as the highest 1585 version indicated therein. 1587 extensions Clients request extended functionality from servers by 1588 sending data in the extensions field. The actual "Extension" 1589 format is defined in Section 4.2. In TLS 1.3, use of certain 1590 extensions is mandatory, as functionality is moved into extensions 1591 to preserve ClientHello compatibility with previous versions of 1592 TLS. Servers MUST ignore unrecognized extensions. 1594 All versions of TLS allow an extensions field to optionally follow 1595 the compression_methods field. TLS 1.3 ClientHello messages always 1596 contain extensions (minimally "supported_versions", otherwise they 1597 will be interpreted as TLS 1.2 ClientHello messages). However, TLS 1598 1.3 servers might receive ClientHello messages without an extensions 1599 field from prior versions of TLS. The presence of extensions can be 1600 detected by determining whether there are bytes following the 1601 compression_methods field at the end of the ClientHello. Note that 1602 this method of detecting optional data differs from the normal TLS 1603 method of having a variable-length field, but it is used for 1604 compatibility with TLS before extensions were defined. TLS 1.3 1605 servers will need to perform this check first and only attempt to 1606 negotiate TLS 1.3 if the "supported_versions" extension is present. 1607 If negotiating a version of TLS prior to 1.3, a server MUST check 1608 that the message either contains no data after 1609 legacy_compression_methods or that it contains a valid extensions 1610 block with no data following. If not, then it MUST abort the 1611 handshake with a "decode_error" alert. 1613 In the event that a client requests additional functionality using 1614 extensions, and this functionality is not supplied by the server, the 1615 client MAY abort the handshake. 1617 After sending the ClientHello message, the client waits for a 1618 ServerHello or HelloRetryRequest message. If early data is in use, 1619 the client may transmit early application data (Section 2.3) while 1620 waiting for the next handshake message. 1622 4.1.3. Server Hello 1624 The server will send this message in response to a ClientHello 1625 message to proceed with the handshake if it is able to negotiate an 1626 acceptable set of handshake parameters based on the ClientHello. 1628 Structure of this message: 1630 struct { 1631 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 1632 Random random; 1633 opaque legacy_session_id_echo<0..32>; 1634 CipherSuite cipher_suite; 1635 uint8 legacy_compression_method = 0; 1636 Extension extensions<6..2^16-1>; 1637 } ServerHello; 1639 legacy_version In previous versions of TLS, this field was used for 1640 version negotiation and represented the selected version number 1641 for the connection. Unfortunately, some middleboxes fail when 1642 presented with new values. In TLS 1.3, the TLS server indicates 1643 its version using the "supported_versions" extension 1644 (Section 4.2.1), and the legacy_version field MUST be set to 1645 0x0303, which is the version number for TLS 1.2. (See Appendix D 1646 for details about backward compatibility.) 1648 random 32 bytes generated by a secure random number generator. See 1649 Appendix C for additional information. The last eight bytes MUST 1650 be overwritten as described below if negotiating TLS 1.2 or TLS 1651 1.1, but the remaining bytes MUST be random. This structure is 1652 generated by the server and MUST be generated independently of the 1653 ClientHello.random. 1655 legacy_session_id_echo The contents of the client's 1656 legacy_session_id field. Note that this field is echoed even if 1657 the client's value corresponded to a cached pre-TLS 1.3 session 1658 which the server has chosen not to resume. A client which 1659 receives a legacy_session_id_echo field that does not match what 1660 it sent in the ClientHello MUST abort the handshake with an 1661 "illegal_parameter" alert. 1663 cipher_suite The single cipher suite selected by the server from the 1664 list in ClientHello.cipher_suites. A client which receives a 1665 cipher suite that was not offered MUST abort the handshake with an 1666 "illegal_parameter" alert. 1668 legacy_compression_method A single byte which MUST have the value 0. 1670 extensions A list of extensions. The ServerHello MUST only include 1671 extensions which are required to establish the cryptographic 1672 context and negotiate the protocol version. All TLS 1.3 1673 ServerHello messages MUST contain the "supported_versions" 1674 extension. Current ServerHello messages additionally contain 1675 either the "pre_shared_key" or "key_share" extensions, or both 1676 when using a PSK with (EC)DHE key establishment. Other extensions 1677 are sent separately in the EncryptedExtensions message. 1679 For reasons of backward compatibility with middleboxes (see 1680 Appendix D.4) the HelloRetryRequest message uses the same structure 1681 as the ServerHello, but with Random set to the special value of the 1682 SHA-256 of "HelloRetryRequest": 1684 CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91 1685 C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C 1687 Upon receiving a message with type server_hello, implementations MUST 1688 first examine the Random value and if it matches this value, process 1689 it as described in Section 4.1.4). 1691 TLS 1.3 has a downgrade protection mechanism embedded in the server's 1692 random value. TLS 1.3 servers which negotiate TLS 1.2 or below in 1693 response to a ClientHello MUST set the last eight bytes of their 1694 Random value specially. 1696 If negotiating TLS 1.2, TLS 1.3 servers MUST set the last eight bytes 1697 of their Random value to the bytes: 1699 44 4F 57 4E 47 52 44 01 1701 If negotiating TLS 1.1 or below, TLS 1.3 servers MUST and TLS 1.2 1702 servers SHOULD set the last eight bytes of their Random value to the 1703 bytes: 1705 44 4F 57 4E 47 52 44 00 1707 TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below 1708 MUST check that the last eight bytes are not equal to either of these 1709 values. TLS 1.2 clients SHOULD also check that the last eight bytes 1710 are not equal to the second value if the ServerHello indicates TLS 1711 1.1 or below. If a match is found, the client MUST abort the 1712 handshake with an "illegal_parameter" alert. This mechanism provides 1713 limited protection against downgrade attacks over and above what is 1714 provided by the Finished exchange: because the ServerKeyExchange, a 1715 message present in TLS 1.2 and below, includes a signature over both 1716 random values, it is not possible for an active attacker to modify 1717 the random values without detection as long as ephemeral ciphers are 1718 used. It does not provide downgrade protection when static RSA is 1719 used. 1721 Note: This is a change from [RFC5246], so in practice many TLS 1.2 1722 clients and servers will not behave as specified above. 1724 A legacy TLS client performing renegotiation with TLS 1.2 or prior 1725 and which receives a TLS 1.3 ServerHello during renegotiation MUST 1726 abort the handshake with a "protocol_version" alert. Note that 1727 renegotiation is not possible when TLS 1.3 has been negotiated. 1729 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of 1730 draft versions (see Section 4.2.1.1) of this specification SHOULD NOT 1731 implement this mechanism on either client and server. A pre-RFC 1732 client connecting to RFC servers, or vice versa, will appear to 1733 downgrade to TLS 1.2. With the mechanism enabled, this will cause an 1734 interoperability failure. 1736 4.1.4. Hello Retry Request 1738 The server will send this message in response to a ClientHello 1739 message if it is able to find an acceptable set of parameters but the 1740 ClientHello does not contain sufficient information to proceed with 1741 the handshake. As discussed in Section 4.1.3, the HelloRetryRequest 1742 has the same format as a ServerHello message, and the legacy_version, 1743 legacy_session_id_echo, cipher_suite, and legacy_compression methods 1744 fields have the same meaning. However, for convenience we discuss 1745 HelloRetryRequest throughout this document as if it were a distinct 1746 message. 1748 The server's extensions MUST contain "supported_versions" and 1749 otherwise the server SHOULD send only the extensions necessary for 1750 the client to generate a correct ClientHello pair. As with 1751 ServerHello, a HelloRetryRequest MUST NOT contain any extensions that 1752 were not first offered by the client in its ClientHello, with the 1753 exception of optionally the "cookie" (see Section 4.2.2) extension. 1755 Upon receipt of a HelloRetryRequest, the client MUST check the 1756 legacy_version, legacy_session_id_echo, cipher_suite, and 1757 legacy_compression_method as specified in Section 4.1.3 and then 1758 process the extensions, starting with determining the version using 1759 "supported_versions". Clients MUST abort the handshake with an 1760 "illegal_parameter" alert if the HelloRetryRequest would not result 1761 in any change in the ClientHello. If a client receives a second 1762 HelloRetryRequest in the same connection (i.e., where the ClientHello 1763 was itself in response to a HelloRetryRequest), it MUST abort the 1764 handshake with an "unexpected_message" alert. 1766 Otherwise, the client MUST process all extensions in the 1767 HelloRetryRequest and send a second updated ClientHello. The 1768 HelloRetryRequest extensions defined in this specification are: 1770 - supported_versions (see Section 4.2.1) 1772 - cookie (see Section 4.2.2) 1774 - key_share (see Section 4.2.8) 1776 In addition, in its updated ClientHello, the client SHOULD NOT offer 1777 any pre-shared keys associated with a hash other than that of the 1778 selected cipher suite. This allows the client to avoid having to 1779 compute partial hash transcripts for multiple hashes in the second 1780 ClientHello. A client which receives a cipher suite that was not 1781 offered MUST abort the handshake. Servers MUST ensure that they 1782 negotiate the same cipher suite when receiving a conformant updated 1783 ClientHello (if the server selects the cipher suite as the first step 1784 in the negotiation, then this will happen automatically). Upon 1785 receiving the ServerHello, clients MUST check that the cipher suite 1786 supplied in the ServerHello is the same as that in the 1787 HelloRetryRequest and otherwise abort the handshake with an 1788 "illegal_parameter" alert. 1790 The value of selected_version in the HelloRetryRequest 1791 "supported_versions" extension MUST be retained in the ServerHello, 1792 and a client MUST abort the handshake with an "illegal_parameter" 1793 alert if the value changes. 1795 4.2. Extensions 1797 A number of TLS messages contain tag-length-value encoded extensions 1798 structures. 1800 struct { 1801 ExtensionType extension_type; 1802 opaque extension_data<0..2^16-1>; 1803 } Extension; 1805 enum { 1806 server_name(0), /* RFC 6066 */ 1807 max_fragment_length(1), /* RFC 6066 */ 1808 status_request(5), /* RFC 6066 */ 1809 supported_groups(10), /* RFC 4492, 7919 */ 1810 signature_algorithms(13), /* [[this document]] */ 1811 use_srtp(14), /* RFC 5764 */ 1812 heartbeat(15), /* RFC 6520 */ 1813 application_layer_protocol_negotiation(16), /* RFC 7301 */ 1814 signed_certificate_timestamp(18), /* RFC 6962 */ 1815 client_certificate_type(19), /* RFC 7250 */ 1816 server_certificate_type(20), /* RFC 7250 */ 1817 padding(21), /* RFC 7685 */ 1818 pre_shared_key(41), /* [[this document]] */ 1819 early_data(42), /* [[this document]] */ 1820 supported_versions(43), /* [[this document]] */ 1821 cookie(44), /* [[this document]] */ 1822 psk_key_exchange_modes(45), /* [[this document]] */ 1823 certificate_authorities(47), /* [[this document]] */ 1824 oid_filters(48), /* [[this document]] */ 1825 post_handshake_auth(49), /* [[this document]] */ 1826 signature_algorithms_cert(50), /* [[this document]] */ 1827 key_share(51), /* [[this document]] */ 1828 (65535) 1829 } ExtensionType; 1831 Here: 1833 - "extension_type" identifies the particular extension type. 1835 - "extension_data" contains information specific to the particular 1836 extension type. 1838 The list of extension types is maintained by IANA as described in 1839 Section 11. 1841 Extensions are generally structured in a request/response fashion, 1842 though some extensions are just indications with no corresponding 1843 response. The client sends its extension requests in the ClientHello 1844 message and the server sends its extension responses in the 1845 ServerHello, EncryptedExtensions, HelloRetryRequest and Certificate 1846 messages. The server sends extension requests in the 1847 CertificateRequest message which a client MAY respond to with a 1848 Certificate message. The server MAY also send unsolicited extensions 1849 in the NewSessionTicket, though the client does not respond directly 1850 to these. 1852 Implementations MUST NOT send extension responses if the remote 1853 endpoint did not send the corresponding extension requests, with the 1854 exception of the "cookie" extension in HelloRetryRequest. Upon 1855 receiving such an extension, an endpoint MUST abort the handshake 1856 with an "unsupported_extension" alert. 1858 The table below indicates the messages where a given extension may 1859 appear, using the following notation: CH (ClientHello), SH 1860 (ServerHello), EE (EncryptedExtensions), CT (Certificate), CR 1861 (CertificateRequest), NST (NewSessionTicket) and HRR 1862 (HelloRetryRequest). If an implementation receives an extension 1863 which it recognizes and which is not specified for the message in 1864 which it appears it MUST abort the handshake with an 1865 "illegal_parameter" alert. 1867 +--------------------------------------------------+-------------+ 1868 | Extension | TLS 1.3 | 1869 +--------------------------------------------------+-------------+ 1870 | server_name [RFC6066] | CH, EE | 1871 | | | 1872 | max_fragment_length [RFC6066] | CH, EE | 1873 | | | 1874 | status_request [RFC6066] | CH, CR, CT | 1875 | | | 1876 | supported_groups [RFC7919] | CH, EE | 1877 | | | 1878 | signature_algorithms [RFC5246] | CH, CR | 1879 | | | 1880 | use_srtp [RFC5764] | CH, EE | 1881 | | | 1882 | heartbeat [RFC6520] | CH, EE | 1883 | | | 1884 | application_layer_protocol_negotiation [RFC7301] | CH, EE | 1885 | | | 1886 | signed_certificate_timestamp [RFC6962] | CH, CR, CT | 1887 | | | 1888 | client_certificate_type [RFC7250] | CH, EE | 1889 | | | 1890 | server_certificate_type [RFC7250] | CH, EE | 1891 | | | 1892 | padding [RFC7685] | CH | 1893 | | | 1894 | key_share [[this document]] | CH, SH, HRR | 1895 | | | 1896 | pre_shared_key [[this document]] | CH, SH | 1897 | | | 1898 | psk_key_exchange_modes [[this document]] | CH | 1899 | | | 1900 | early_data [[this document]] | CH, EE, NST | 1901 | | | 1902 | cookie [[this document]] | CH, HRR | 1903 | | | 1904 | supported_versions [[this document]] | CH, SH, HRR | 1905 | | | 1906 | certificate_authorities [[this document]] | CH, CR | 1907 | | | 1908 | oid_filters [[this document]] | CR | 1909 | | | 1910 | post_handshake_auth [[this document]] | CH | 1911 | | | 1912 | signature_algorithms_cert [[this document]] | CH, CR | 1913 +--------------------------------------------------+-------------+ 1915 When multiple extensions of different types are present, the 1916 extensions MAY appear in any order, with the exception of 1917 "pre_shared_key" Section 4.2.11 which MUST be the last extension in 1918 the ClientHello. There MUST NOT be more than one extension of the 1919 same type in a given extension block. 1921 In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each 1922 handshake even when in resumption-PSK mode. However, 0-RTT 1923 parameters are those negotiated in the previous handshake; mismatches 1924 may require rejecting 0-RTT (see Section 4.2.10). 1926 There are subtle (and not so subtle) interactions that may occur in 1927 this protocol between new features and existing features which may 1928 result in a significant reduction in overall security. The following 1929 considerations should be taken into account when designing new 1930 extensions: 1932 - Some cases where a server does not agree to an extension are error 1933 conditions (e.g., the handshake cannot continue), and some are 1934 simply refusals to support particular features. In general, error 1935 alerts should be used for the former and a field in the server 1936 extension response for the latter. 1938 - Extensions should, as far as possible, be designed to prevent any 1939 attack that forces use (or non-use) of a particular feature by 1940 manipulation of handshake messages. This principle should be 1941 followed regardless of whether the feature is believed to cause a 1942 security problem. Often the fact that the extension fields are 1943 included in the inputs to the Finished message hashes will be 1944 sufficient, but extreme care is needed when the extension changes 1945 the meaning of messages sent in the handshake phase. Designers 1946 and implementors should be aware of the fact that until the 1947 handshake has been authenticated, active attackers can modify 1948 messages and insert, remove, or replace extensions. 1950 4.2.1. Supported Versions 1952 struct { 1953 select (Handshake.msg_type) { 1954 case client_hello: 1955 ProtocolVersion versions<2..254>; 1957 case server_hello: /* and HelloRetryRequest */ 1958 ProtocolVersion selected_version; 1959 }; 1960 } SupportedVersions; 1962 The "supported_versions" extension is used by the client to indicate 1963 which versions of TLS it supports and by the server to indicate which 1964 version it is using. The extension contains a list of supported 1965 versions in preference order, with the most preferred version first. 1966 Implementations of this specification MUST send this extension in the 1967 ClientHello containing all versions of TLS which they are prepared to 1968 negotiate (for this specification, that means minimally 0x0304, but 1969 if previous versions of TLS are allowed to be negotiated, they MUST 1970 be present as well). 1972 If this extension is not present, servers which are compliant with 1973 this specification, and which also support TLS 1.2, MUST negotiate 1974 TLS 1.2 or prior as specified in [RFC5246], even if 1975 ClientHello.legacy_version is 0x0304 or later. Servers MAY abort the 1976 handshake upon receiving a ClientHello with legacy_version 0x0304 or 1977 later. 1979 If this extension is present in the ClientHello, servers MUST NOT use 1980 the ClientHello.legacy_version value for version negotiation and MUST 1981 use only the "supported_versions" extension to determine client 1982 preferences. Servers MUST only select a version of TLS present in 1983 that extension and MUST ignore any unknown versions that are present 1984 in that extension. Note that this mechanism makes it possible to 1985 negotiate a version prior to TLS 1.2 if one side supports a sparse 1986 range. Implementations of TLS 1.3 which choose to support prior 1987 versions of TLS SHOULD support TLS 1.2. Servers MUST be prepared to 1988 receive ClientHellos that include this extension but do not include 1989 0x0304 in the list of versions. 1991 A server which negotiates a version of TLS prior to TLS 1.3 MUST set 1992 ServerHello.version and MUST NOT send the "supported_versions" 1993 extension. A server which negotiates TLS 1.3 MUST respond by sending 1994 a "supported_versions" extension containing the selected version 1995 value (0x0304). It MUST set the ServerHello.legacy_version field to 1996 0x0303 (TLS 1.2). Clients MUST check for this extension prior to 1997 processing the rest of the ServerHello (although they will have to 1998 parse the ServerHello in order to read the extension). If this 1999 extension is present, clients MUST ignore the 2000 ServerHello.legacy_version value and MUST use only the 2001 "supported_versions" extension to determine the selected version. If 2002 the "supported_versions" extension in the ServerHello contains a 2003 version not offered by the client or contains a version prior to TLS 2004 1.3, the client MUST abort the handshake with an "illegal_parameter" 2005 alert. 2007 4.2.1.1. Draft Version Indicator 2009 RFC EDITOR: PLEASE REMOVE THIS SECTION 2011 While the eventual version indicator for the RFC version of TLS 1.3 2012 will be 0x0304, implementations of draft versions of this 2013 specification SHOULD instead advertise 0x7f00 | draft_version in the 2014 ServerHello and HelloRetryRequest "supported_versions" extension. 2015 For instance, draft-17 would be encoded as the 0x7f11. This allows 2016 pre-RFC implementations to safely negotiate with each other, even if 2017 they would otherwise be incompatible. 2019 4.2.2. Cookie 2021 struct { 2022 opaque cookie<1..2^16-1>; 2023 } Cookie; 2025 Cookies serve two primary purposes: 2027 - Allowing the server to force the client to demonstrate 2028 reachability at their apparent network address (thus providing a 2029 measure of DoS protection). This is primarily useful for non- 2030 connection-oriented transports (see [RFC6347] for an example of 2031 this). 2033 - Allowing the server to offload state to the client, thus allowing 2034 it to send a HelloRetryRequest without storing any state. The 2035 server can do this by storing the hash of the ClientHello in the 2036 HelloRetryRequest cookie (protected with some suitable integrity 2037 algorithm). 2039 When sending a HelloRetryRequest, the server MAY provide a "cookie" 2040 extension to the client (this is an exception to the usual rule that 2041 the only extensions that may be sent are those that appear in the 2042 ClientHello). When sending the new ClientHello, the client MUST copy 2043 the contents of the extension received in the HelloRetryRequest into 2044 a "cookie" extension in the new ClientHello. Clients MUST NOT use 2045 cookies in their initial ClientHello in subsequent connections. 2047 When a server is operating statelessly it may receive an unprotected 2048 record of type change_cipher_spec between the first and second 2049 ClientHello (see Section 5). Since the server is not storing any 2050 state this will appear as if it were the first message to be 2051 received. Servers operating statelessly MUST ignore these records. 2053 4.2.3. Signature Algorithms 2055 TLS 1.3 provides two extensions for indicating which signature 2056 algorithms may be used in digital signatures. The 2057 "signature_algorithms_cert" extension applies to signatures in 2058 certificates and the "signature_algorithms" extension, which 2059 originally appeared in TLS 1.2, applies to signatures in 2060 CertificateVerify messages. The keys found in certificates MUST also 2061 be of appropriate type for the signature algorithms they are used 2062 with. This is a particular issue for RSA keys and PSS signatures, as 2063 described below. If no "signature_algorithms_cert" extension is 2064 present, then the "signature_algorithms" extension also applies to 2065 signatures appearing in certificates. Clients which desire the 2066 server to authenticate itself via a certificate MUST send 2067 "signature_algorithms". If a server is authenticating via a 2068 certificate and the client has not sent a "signature_algorithms" 2069 extension, then the server MUST abort the handshake with a 2070 "missing_extension" alert (see Section 9.2). 2072 The "signature_algorithms_cert" extension was added to allow 2073 implementations which supported different sets of algorithms for 2074 certificates and in TLS itself to clearly signal their capabilities. 2075 TLS 1.2 implementations SHOULD also process this extension. 2076 Implementations which have the same policy in both cases MAY omit the 2077 "signature_algorithms_cert" extension. 2079 The "extension_data" field of these extensions contains a 2080 SignatureSchemeList value: 2082 enum { 2083 /* RSASSA-PKCS1-v1_5 algorithms */ 2084 rsa_pkcs1_sha256(0x0401), 2085 rsa_pkcs1_sha384(0x0501), 2086 rsa_pkcs1_sha512(0x0601), 2088 /* ECDSA algorithms */ 2089 ecdsa_secp256r1_sha256(0x0403), 2090 ecdsa_secp384r1_sha384(0x0503), 2091 ecdsa_secp521r1_sha512(0x0603), 2093 /* RSASSA-PSS algorithms with public key OID rsaEncryption */ 2094 rsa_pss_rsae_sha256(0x0804), 2095 rsa_pss_rsae_sha384(0x0805), 2096 rsa_pss_rsae_sha512(0x0806), 2098 /* EdDSA algorithms */ 2099 ed25519(0x0807), 2100 ed448(0x0808), 2102 /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */ 2103 rsa_pss_pss_sha256(0x0809), 2104 rsa_pss_pss_sha384(0x080a), 2105 rsa_pss_pss_sha512(0x080b), 2107 /* Legacy algorithms */ 2108 rsa_pkcs1_sha1(0x0201), 2109 ecdsa_sha1(0x0203), 2111 /* Reserved Code Points */ 2112 private_use(0xFE00..0xFFFF), 2113 (0xFFFF) 2114 } SignatureScheme; 2116 struct { 2117 SignatureScheme supported_signature_algorithms<2..2^16-2>; 2118 } SignatureSchemeList; 2120 Note: This enum is named "SignatureScheme" because there is already a 2121 "SignatureAlgorithm" type in TLS 1.2, which this replaces. We use 2122 the term "signature algorithm" throughout the text. 2124 Each SignatureScheme value lists a single signature algorithm that 2125 the client is willing to verify. The values are indicated in 2126 descending order of preference. Note that a signature algorithm 2127 takes as input an arbitrary-length message, rather than a digest. 2128 Algorithms which traditionally act on a digest should be defined in 2129 TLS to first hash the input with a specified hash algorithm and then 2130 proceed as usual. The code point groups listed above have the 2131 following meanings: 2133 RSASSA-PKCS1-v1_5 algorithms Indicates a signature algorithm using 2134 RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm 2135 as defined in [SHS]. These values refer solely to signatures 2136 which appear in certificates (see Section 4.4.2.2) and are not 2137 defined for use in signed TLS handshake messages, although they 2138 MAY appear in "signature_algorithms" and 2139 "signature_algorithms_cert" for backward compatibility with TLS 2140 1.2, 2142 ECDSA algorithms Indicates a signature algorithm using ECDSA 2143 [ECDSA], the corresponding curve as defined in ANSI X9.62 [X962] 2144 and FIPS 186-4 [DSS], and the corresponding hash algorithm as 2145 defined in [SHS]. The signature is represented as a DER-encoded 2146 [X690] ECDSA-Sig-Value structure. 2148 RSASSA-PSS RSAE algorithms Indicates a signature algorithm using 2149 RSASSA-PSS [RFC8017] with mask generation function 1. The digest 2150 used in the mask generation function and the digest being signed 2151 are both the corresponding hash algorithm as defined in [SHS]. 2152 The length of the salt MUST be equal to the length of the output 2153 of the digest algorithm. If the public key is carried in an X.509 2154 certificate, it MUST use the rsaEncryption OID [RFC5280]. 2156 EdDSA algorithms Indicates a signature algorithm using EdDSA as 2157 defined in [RFC8032] or its successors. Note that these 2158 correspond to the "PureEdDSA" algorithms and not the "prehash" 2159 variants. 2161 RSASSA-PSS PSS algorithms Indicates a signature algorithm using 2162 RSASSA-PSS [RFC8017] with mask generation function 1. The digest 2163 used in the mask generation function and the digest being signed 2164 are both the corresponding hash algorithm as defined in [SHS]. 2165 The length of the salt MUST be equal to the length of the digest 2166 algorithm. If the public key is carried in an X.509 certificate, 2167 it MUST use the RSASSA-PSS OID [RFC5756]. When used in 2168 certificate signatures, the algorithm parameters MUST be DER 2169 encoded. If the corresponding public key's parameters are 2170 present, then the parameters in the signature MUST be identical to 2171 those in the public key. 2173 Legacy algorithms Indicates algorithms which are being deprecated 2174 because they use algorithms with known weaknesses, specifically 2175 SHA-1 which is used in this context with either with RSA using 2176 RSASSA-PKCS1-v1_5 or ECDSA. These values refer solely to 2177 signatures which appear in certificates (see Section 4.4.2.2) and 2178 are not defined for use in signed TLS handshake messages, although 2179 they MAY appear in "signature_algorithms" and 2180 "signature_algorithms_cert" for backward compatibility with TLS 2181 1.2, Endpoints SHOULD NOT negotiate these algorithms but are 2182 permitted to do so solely for backward compatibility. Clients 2183 offering these values MUST list them as the lowest priority 2184 (listed after all other algorithms in SignatureSchemeList). TLS 2185 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no 2186 valid certificate chain can be produced without it (see 2187 Section 4.4.2.2). 2189 The signatures on certificates that are self-signed or certificates 2190 that are trust anchors are not validated since they begin a 2191 certification path (see [RFC5280], Section 3.2). A certificate that 2192 begins a certification path MAY use a signature algorithm that is not 2193 advertised as being supported in the "signature_algorithms" 2194 extension. 2196 Note that TLS 1.2 defines this extension differently. TLS 1.3 2197 implementations willing to negotiate TLS 1.2 MUST behave in 2198 accordance with the requirements of [RFC5246] when negotiating that 2199 version. In particular: 2201 - TLS 1.2 ClientHellos MAY omit this extension. 2203 - In TLS 1.2, the extension contained hash/signature pairs. The 2204 pairs are encoded in two octets, so SignatureScheme values have 2205 been allocated to align with TLS 1.2's encoding. Some legacy 2206 pairs are left unallocated. These algorithms are deprecated as of 2207 TLS 1.3. They MUST NOT be offered or negotiated by any 2208 implementation. In particular, MD5 [SLOTH], SHA-224, and DSA MUST 2209 NOT be used. 2211 - ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature 2212 pairs. However, the old semantics did not constrain the signing 2213 curve. If TLS 1.2 is negotiated, implementations MUST be prepared 2214 to accept a signature that uses any curve that they advertised in 2215 the "supported_groups" extension. 2217 - Implementations that advertise support for RSASSA-PSS (which is 2218 mandatory in TLS 1.3), MUST be prepared to accept a signature 2219 using that scheme even when TLS 1.2 is negotiated. In TLS 1.2, 2220 RSASSA-PSS is used with RSA cipher suites. 2222 4.2.4. Certificate Authorities 2224 The "certificate_authorities" extension is used to indicate the 2225 certificate authorities which an endpoint supports and which SHOULD 2226 be used by the receiving endpoint to guide certificate selection. 2228 The body of the "certificate_authorities" extension consists of a 2229 CertificateAuthoritiesExtension structure. 2231 opaque DistinguishedName<1..2^16-1>; 2233 struct { 2234 DistinguishedName authorities<3..2^16-1>; 2235 } CertificateAuthoritiesExtension; 2237 authorities A list of the distinguished names [X501] of acceptable 2238 certificate authorities, represented in DER-encoded [X690] format. 2239 These distinguished names specify a desired distinguished name for 2240 trust anchor or subordinate CA; thus, this message can be used to 2241 describe known trust anchors as well as a desired authorization 2242 space. 2244 The client MAY send the "certificate_authorities" extension in the 2245 ClientHello message. The server MAY send it in the 2246 CertificateRequest message. 2248 The "trusted_ca_keys" extension, which serves a similar purpose 2249 [RFC6066], but is more complicated, is not used in TLS 1.3 (although 2250 it may appear in ClientHello messages from clients which are offering 2251 prior versions of TLS). 2253 4.2.5. OID Filters 2255 The "oid_filters" extension allows servers to provide a set of OID/ 2256 value pairs which it would like the client's certificate to match. 2257 This extension, if provided by the server, MUST only be sent in the 2258 CertificateRequest message. 2260 struct { 2261 opaque certificate_extension_oid<1..2^8-1>; 2262 opaque certificate_extension_values<0..2^16-1>; 2263 } OIDFilter; 2265 struct { 2266 OIDFilter filters<0..2^16-1>; 2267 } OIDFilterExtension; 2269 filters A list of certificate extension OIDs [RFC5280] with their 2270 allowed value(s) and represented in DER-encoded [X690] format. 2271 Some certificate extension OIDs allow multiple values (e.g., 2272 Extended Key Usage). If the server has included a non-empty 2273 filters list, the client certificate included in the response MUST 2274 contain all of the specified extension OIDs that the client 2275 recognizes. For each extension OID recognized by the client, all 2276 of the specified values MUST be present in the client certificate 2277 (but the certificate MAY have other values as well). However, the 2278 client MUST ignore and skip any unrecognized certificate extension 2279 OIDs. If the client ignored some of the required certificate 2280 extension OIDs and supplied a certificate that does not satisfy 2281 the request, the server MAY at its discretion either continue the 2282 connection without client authentication, or abort the handshake 2283 with an "unsupported_certificate" alert. Any given OID MUST NOT 2284 appear more than once in the filters list. 2286 PKIX RFCs define a variety of certificate extension OIDs and their 2287 corresponding value types. Depending on the type, matching 2288 certificate extension values are not necessarily bitwise-equal. It 2289 is expected that TLS implementations will rely on their PKI libraries 2290 to perform certificate selection using certificate extension OIDs. 2292 This document defines matching rules for two standard certificate 2293 extensions defined in [RFC5280]: 2295 - The Key Usage extension in a certificate matches the request when 2296 all key usage bits asserted in the request are also asserted in 2297 the Key Usage certificate extension. 2299 - The Extended Key Usage extension in a certificate matches the 2300 request when all key purpose OIDs present in the request are also 2301 found in the Extended Key Usage certificate extension. The 2302 special anyExtendedKeyUsage OID MUST NOT be used in the request. 2304 Separate specifications may define matching rules for other 2305 certificate extensions. 2307 4.2.6. Post-Handshake Client Authentication 2309 The "post_handshake_auth" extension is used to indicate that a client 2310 is willing to perform post-handshake authentication (Section 4.6.2). 2311 Servers MUST NOT send a post-handshake CertificateRequest to clients 2312 which do not offer this extension. Servers MUST NOT send this 2313 extension. 2315 struct {} PostHandshakeAuth; 2317 The "extension_data" field of the "post_handshake_auth" extension is 2318 zero length. 2320 4.2.7. Negotiated Groups 2322 When sent by the client, the "supported_groups" extension indicates 2323 the named groups which the client supports for key exchange, ordered 2324 from most preferred to least preferred. 2326 Note: In versions of TLS prior to TLS 1.3, this extension was named 2327 "elliptic_curves" and only contained elliptic curve groups. See 2328 [RFC4492] and [RFC7919]. This extension was also used to negotiate 2329 ECDSA curves. Signature algorithms are now negotiated independently 2330 (see Section 4.2.3). 2332 The "extension_data" field of this extension contains a 2333 "NamedGroupList" value: 2335 enum { 2337 /* Elliptic Curve Groups (ECDHE) */ 2338 secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), 2339 x25519(0x001D), x448(0x001E), 2341 /* Finite Field Groups (DHE) */ 2342 ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), 2343 ffdhe6144(0x0103), ffdhe8192(0x0104), 2345 /* Reserved Code Points */ 2346 ffdhe_private_use(0x01FC..0x01FF), 2347 ecdhe_private_use(0xFE00..0xFEFF), 2348 (0xFFFF) 2349 } NamedGroup; 2351 struct { 2352 NamedGroup named_group_list<2..2^16-1>; 2353 } NamedGroupList; 2355 Elliptic Curve Groups (ECDHE) Indicates support for the 2356 corresponding named curve, defined either in FIPS 186-4 [DSS] or 2357 in [RFC7748]. Values 0xFE00 through 0xFEFF are reserved for 2358 private use. 2360 Finite Field Groups (DHE) Indicates support of the corresponding 2361 finite field group, defined in [RFC7919]. Values 0x01FC through 2362 0x01FF are reserved for private use. 2364 Items in named_group_list are ordered according to the client's 2365 preferences (most preferred choice first). 2367 As of TLS 1.3, servers are permitted to send the "supported_groups" 2368 extension to the client. Clients MUST NOT act upon any information 2369 found in "supported_groups" prior to successful completion of the 2370 handshake but MAY use the information learned from a successfully 2371 completed handshake to change what groups they use in their 2372 "key_share" extension in subsequent connections. If the server has a 2373 group it prefers to the ones in the "key_share" extension but is 2374 still willing to accept the ClientHello, it SHOULD send 2375 "supported_groups" to update the client's view of its preferences; 2376 this extension SHOULD contain all groups the server supports, 2377 regardless of whether they are currently supported by the client. 2379 4.2.8. Key Share 2381 The "key_share" extension contains the endpoint's cryptographic 2382 parameters. 2384 Clients MAY send an empty client_shares vector in order to request 2385 group selection from the server at the cost of an additional round 2386 trip. (see Section 4.1.4) 2388 struct { 2389 NamedGroup group; 2390 opaque key_exchange<1..2^16-1>; 2391 } KeyShareEntry; 2393 group The named group for the key being exchanged. 2395 key_exchange Key exchange information. The contents of this field 2396 are determined by the specified group and its corresponding 2397 definition. Finite Field Diffie-Hellman [DH] parameters are 2398 described in Section 4.2.8.1; Elliptic Curve Diffie-Hellman 2399 parameters are described in Section 4.2.8.2. 2401 In the ClientHello message, the "extension_data" field of this 2402 extension contains a "KeyShareClientHello" value: 2404 struct { 2405 KeyShareEntry client_shares<0..2^16-1>; 2406 } KeyShareClientHello; 2408 client_shares A list of offered KeyShareEntry values in descending 2409 order of client preference. 2411 This vector MAY be empty if the client is requesting a 2412 HelloRetryRequest. Each KeyShareEntry value MUST correspond to a 2413 group offered in the "supported_groups" extension and MUST appear in 2414 the same order. However, the values MAY be a non-contiguous subset 2415 of the "supported_groups" extension and MAY omit the most preferred 2416 groups. Such a situation could arise if the most preferred groups 2417 are new and unlikely to be supported in enough places to make 2418 pregenerating key shares for them efficient. 2420 Clients can offer as many KeyShareEntry values as the number of 2421 supported groups it is offering, each representing a single set of 2422 key exchange parameters. For instance, a client might offer shares 2423 for several elliptic curves or multiple FFDHE groups. The 2424 key_exchange values for each KeyShareEntry MUST be generated 2425 independently. Clients MUST NOT offer multiple KeyShareEntry values 2426 for the same group. Clients MUST NOT offer any KeyShareEntry values 2427 for groups not listed in the client's "supported_groups" extension. 2428 Servers MAY check for violations of these rules and abort the 2429 handshake with an "illegal_parameter" alert if one is violated. 2431 In a HelloRetryRequest message, the "extension_data" field of this 2432 extension contains a KeyShareHelloRetryRequest value: 2434 struct { 2435 NamedGroup selected_group; 2436 } KeyShareHelloRetryRequest; 2438 selected_group The mutually supported group the server intends to 2439 negotiate and is requesting a retried ClientHello/KeyShare for. 2441 Upon receipt of this extension in a HelloRetryRequest, the client 2442 MUST verify that (1) the selected_group field corresponds to a group 2443 which was provided in the "supported_groups" extension in the 2444 original ClientHello; and (2) the selected_group field does not 2445 correspond to a group which was provided in the "key_share" extension 2446 in the original ClientHello. If either of these checks fails, then 2447 the client MUST abort the handshake with an "illegal_parameter" 2448 alert. Otherwise, when sending the new ClientHello, the client MUST 2449 replace the original "key_share" extension with one containing only a 2450 new KeyShareEntry for the group indicated in the selected_group field 2451 of the triggering HelloRetryRequest. 2453 In a ServerHello message, the "extension_data" field of this 2454 extension contains a KeyShareServerHello value: 2456 struct { 2457 KeyShareEntry server_share; 2458 } KeyShareServerHello; 2460 server_share A single KeyShareEntry value that is in the same group 2461 as one of the client's shares. 2463 If using (EC)DHE key establishment, servers offer exactly one 2464 KeyShareEntry in the ServerHello. This value MUST be in the same 2465 group as the KeyShareEntry value offered by the client that the 2466 server has selected for the negotiated key exchange. Servers MUST 2467 NOT send a KeyShareEntry for any group not indicated in the 2468 "supported_groups" extension and MUST NOT send a KeyShareEntry when 2469 using the "psk_ke" PskKeyExchangeMode. If using (EC)DHE key 2470 establishment, and a HelloRetryRequest containing a "key_share" 2471 extension was received by the client, the client MUST verify that the 2472 selected NamedGroup in the ServerHello is the same as that in the 2473 HelloRetryRequest. If this check fails, the client MUST abort the 2474 handshake with an "illegal_parameter" alert. 2476 4.2.8.1. Diffie-Hellman Parameters 2478 Diffie-Hellman [DH] parameters for both clients and servers are 2479 encoded in the opaque key_exchange field of a KeyShareEntry in a 2480 KeyShare structure. The opaque value contains the Diffie-Hellman 2481 public value (Y = g^X mod p) for the specified group (see [RFC7919] 2482 for group definitions) encoded as a big-endian integer and padded to 2483 the left with zeros to the size of p in bytes. 2485 Note: For a given Diffie-Hellman group, the padding results in all 2486 public keys having the same length. 2488 Peers MUST validate each other's public key Y by ensuring that 1 < Y 2489 < p-1. This check ensures that the remote peer is properly behaved 2490 and isn't forcing the local system into a small subgroup. 2492 4.2.8.2. ECDHE Parameters 2494 ECDHE parameters for both clients and servers are encoded in the 2495 opaque key_exchange field of a KeyShareEntry in a KeyShare structure. 2497 For secp256r1, secp384r1 and secp521r1, the contents are the 2498 serialized value of the following struct: 2500 struct { 2501 uint8 legacy_form = 4; 2502 opaque X[coordinate_length]; 2503 opaque Y[coordinate_length]; 2504 } UncompressedPointRepresentation; 2506 X and Y respectively are the binary representations of the x and y 2507 values in network byte order. There are no internal length markers, 2508 so each number representation occupies as many octets as implied by 2509 the curve parameters. For P-256 this means that each of X and Y use 2510 32 octets, padded on the left by zeros if necessary. For P-384 they 2511 take 48 octets each, and for P-521 they take 66 octets each. 2513 For the curves secp256r1, secp384r1 and secp521r1, peers MUST 2514 validate each other's public value Q by ensuring that the point is a 2515 valid point on the elliptic curve. The appropriate validation 2516 procedures are defined in Section 4.3.7 of [X962] and alternatively 2517 in Section 5.6.2.3 of [KEYAGREEMENT]. This process consists of three 2518 steps: (1) verify that Q is not the point at infinity (O), (2) verify 2519 that for Q = (x, y) both integers x and y are in the correct 2520 interval, (3) ensure that (x, y) is a correct solution to the 2521 elliptic curve equation. For these curves, implementers do not need 2522 to verify membership in the correct subgroup. 2524 For X25519 and X448, the contents of the public value are the byte 2525 string inputs and outputs of the corresponding functions defined in 2526 [RFC7748], 32 bytes for X25519 and 56 bytes for X448. 2528 Note: Versions of TLS prior to 1.3 permitted point format 2529 negotiation; TLS 1.3 removes this feature in favor of a single point 2530 format for each curve. 2532 4.2.9. Pre-Shared Key Exchange Modes 2534 In order to use PSKs, clients MUST also send a 2535 "psk_key_exchange_modes" extension. The semantics of this extension 2536 are that the client only supports the use of PSKs with these modes, 2537 which restricts both the use of PSKs offered in this ClientHello and 2538 those which the server might supply via NewSessionTicket. 2540 A client MUST provide a "psk_key_exchange_modes" extension if it 2541 offers a "pre_shared_key" extension. If clients offer 2542 "pre_shared_key" without a "psk_key_exchange_modes" extension, 2543 servers MUST abort the handshake. Servers MUST NOT select a key 2544 exchange mode that is not listed by the client. This extension also 2545 restricts the modes for use with PSK resumption; servers SHOULD NOT 2546 send NewSessionTicket with tickets that are not compatible with the 2547 advertised modes; however, if a server does so, the impact will just 2548 be that the client's attempts at resumption fail. 2550 The server MUST NOT send a "psk_key_exchange_modes" extension. 2552 enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; 2554 struct { 2555 PskKeyExchangeMode ke_modes<1..255>; 2556 } PskKeyExchangeModes; 2558 psk_ke PSK-only key establishment. In this mode, the server MUST 2559 NOT supply a "key_share" value. 2561 psk_dhe_ke PSK with (EC)DHE key establishment. In this mode, the 2562 client and server MUST supply "key_share" values as described in 2563 Section 4.2.8. 2565 Any future values that are allocated must ensure that the transmitted 2566 protocol messages unambiguously identify which mode was selected by 2567 the server; at present, this is indicated by the presence of the 2568 "key_share" in the ServerHello. 2570 4.2.10. Early Data Indication 2572 When a PSK is used and early data is allowed for that PSK, the client 2573 can send application data in its first flight of messages. If the 2574 client opts to do so, it MUST supply both the "early_data" extension 2575 as well as the "pre_shared_key" extension. 2577 The "extension_data" field of this extension contains an 2578 "EarlyDataIndication" value. 2580 struct {} Empty; 2582 struct { 2583 select (Handshake.msg_type) { 2584 case new_session_ticket: uint32 max_early_data_size; 2585 case client_hello: Empty; 2586 case encrypted_extensions: Empty; 2587 }; 2588 } EarlyDataIndication; 2590 See Section 4.6.1 for the use of the max_early_data_size field. 2592 The parameters for the 0-RTT data (version, symmetric cipher suite, 2593 ALPN protocol, etc.) are those associated with the PSK in use. For 2594 externally provisioned PSKs, the associated values are those 2595 provisioned along with the key. For PSKs established via a 2596 NewSessionTicket message, the associated values are those which were 2597 negotiated in the connection which established the PSK. The PSK used 2598 to encrypt the early data MUST be the first PSK listed in the 2599 client's "pre_shared_key" extension. 2601 For PSKs provisioned via NewSessionTicket, a server MUST validate 2602 that the ticket age for the selected PSK identity (computed by 2603 subtracting ticket_age_add from PskIdentity.obfuscated_ticket_age 2604 modulo 2^32) is within a small tolerance of the time since the ticket 2605 was issued (see Section 8). If it is not, the server SHOULD proceed 2606 with the handshake but reject 0-RTT, and SHOULD NOT take any other 2607 action that assumes that this ClientHello is fresh. 2609 0-RTT messages sent in the first flight have the same (encrypted) 2610 content types as messages of the same type sent in other flights 2611 (handshake and application_data) but are protected under different 2612 keys. After receiving the server's Finished message, if the server 2613 has accepted early data, an EndOfEarlyData message will be sent to 2614 indicate the key change. This message will be encrypted with the 2615 0-RTT traffic keys. 2617 A server which receives an "early_data" extension MUST behave in one 2618 of three ways: 2620 - Ignore the extension and return a regular 1-RTT response. The 2621 server then skips past early data by attempting to deprotect 2622 received records using the handshake traffic key, discarding 2623 records which fail deprotection (up to the configured 2624 max_early_data_size). Once a record is deprotected successfully, 2625 it is treated as the start of the client's second flight and the 2626 the server proceeds as with an ordinary 1-RTT handshake. 2628 - Request that the client send another ClientHello by responding 2629 with a HelloRetryRequest. A client MUST NOT include the 2630 "early_data" extension in its followup ClientHello. The server 2631 then ignores early data by skipping all records with external 2632 content type of "application_data" (indicating that they are 2633 encrypted), up to the configured max_early_data_size. 2635 - Return its own "early_data" extension in EncryptedExtensions, 2636 indicating that it intends to process the early data. It is not 2637 possible for the server to accept only a subset of the early data 2638 messages. Even though the server sends a message accepting early 2639 data, the actual early data itself may already be in flight by the 2640 time the server generates this message. 2642 In order to accept early data, the server MUST have accepted a PSK 2643 cipher suite and selected the first key offered in the client's 2644 "pre_shared_key" extension. In addition, it MUST verify that the 2645 following values are the same as those associated with the selected 2646 PSK: 2648 - The TLS version number 2649 - The selected cipher suite 2651 - The selected ALPN [RFC7301] protocol, if any 2653 These requirements are a superset of those needed to perform a 1-RTT 2654 handshake using the PSK in question. For externally established 2655 PSKs, the associated values are those provisioned along with the key. 2656 For PSKs established via a NewSessionTicket message, the associated 2657 values are those negotiated in the connection during which the ticket 2658 was established. 2660 Future extensions MUST define their interaction with 0-RTT. 2662 If any of these checks fail, the server MUST NOT respond with the 2663 extension and must discard all the first flight data using one of the 2664 first two mechanisms listed above (thus falling back to 1-RTT or 2665 2-RTT). If the client attempts a 0-RTT handshake but the server 2666 rejects it, the server will generally not have the 0-RTT record 2667 protection keys and must instead use trial decryption (either with 2668 the 1-RTT handshake keys or by looking for a cleartext ClientHello in 2669 the case of HelloRetryRequest) to find the first non-0-RTT message. 2671 If the server chooses to accept the "early_data" extension, then it 2672 MUST comply with the same error handling requirements specified for 2673 all records when processing early data records. Specifically, if the 2674 server fails to decrypt a 0-RTT record following an accepted 2675 "early_data" extension it MUST terminate the connection with a 2676 "bad_record_mac" alert as per Section 5.2. 2678 If the server rejects the "early_data" extension, the client 2679 application MAY opt to retransmit the application data previously 2680 sent in early data once the handshake has been completed. Note that 2681 automatic re-transmission of early data could result in assumptions 2682 about the status of the connection being incorrect. For instance, 2683 when the negotiated connection selects a different ALPN protocol from 2684 what was used for the early data, an application might need to 2685 construct different messages. Similarly, if early data assumes 2686 anything about the connection state, it might be sent in error after 2687 the handshake completes. 2689 A TLS implementation SHOULD NOT automatically re-send early data; 2690 applications are in a better position to decide when re-transmission 2691 is appropriate. A TLS implementation MUST NOT automatically re-send 2692 early data unless the negotiated connection selects the same ALPN 2693 protocol. 2695 4.2.11. Pre-Shared Key Extension 2697 The "pre_shared_key" extension is used to negotiate the identity of 2698 the pre-shared key to be used with a given handshake in association 2699 with PSK key establishment. 2701 The "extension_data" field of this extension contains a 2702 "PreSharedKeyExtension" value: 2704 struct { 2705 opaque identity<1..2^16-1>; 2706 uint32 obfuscated_ticket_age; 2707 } PskIdentity; 2709 opaque PskBinderEntry<32..255>; 2711 struct { 2712 PskIdentity identities<7..2^16-1>; 2713 PskBinderEntry binders<33..2^16-1>; 2714 } OfferedPsks; 2716 struct { 2717 select (Handshake.msg_type) { 2718 case client_hello: OfferedPsks; 2719 case server_hello: uint16 selected_identity; 2720 }; 2721 } PreSharedKeyExtension; 2723 identity A label for a key. For instance, a ticket defined in 2724 Appendix B.3.4 or a label for a pre-shared key established 2725 externally. 2727 obfuscated_ticket_age An obfuscated version of the age of the key. 2728 Section 4.2.11.1 describes how to form this value for identities 2729 established via the NewSessionTicket message. For identities 2730 established externally an obfuscated_ticket_age of 0 SHOULD be 2731 used, and servers MUST ignore the value. 2733 identities A list of the identities that the client is willing to 2734 negotiate with the server. If sent alongside the "early_data" 2735 extension (see Section 4.2.10), the first identity is the one used 2736 for 0-RTT data. 2738 binders A series of HMAC values, one for each PSK offered in the 2739 "pre_shared_keys" extension and in the same order, computed as 2740 described below. 2742 selected_identity The server's chosen identity expressed as a 2743 (0-based) index into the identities in the client's list. 2745 Each PSK is associated with a single Hash algorithm. For PSKs 2746 established via the ticket mechanism (Section 4.6.1), this is the KDF 2747 Hash algorithm on the connection where the ticket was established. 2748 For externally established PSKs, the Hash algorithm MUST be set when 2749 the PSK is established, or default to SHA-256 if no such algorithm is 2750 defined. The server MUST ensure that it selects a compatible PSK (if 2751 any) and cipher suite. 2753 In TLS versions prior to TLS 1.3, the Server Name Identification 2754 (SNI) value was intended to be associated with the session (Section 3 2755 of [RFC6066]), with the server being required to enforce that the SNI 2756 value associated with the session matches the one specified in the 2757 resumption handshake. However, in reality the implementations were 2758 not consistent on which of two supplied SNI values they would use, 2759 leading to the consistency requirement being de-facto enforced by the 2760 clients. In TLS 1.3, the SNI value is always explicitly specified in 2761 the resumption handshake, and there is no need for the server to 2762 associate an SNI value with the ticket. Clients, however, SHOULD 2763 store the SNI with the PSK to fulfill the requirements of 2764 Section 4.6.1. 2766 Implementor's note: when session resumption is the primary use case 2767 of PSKs the most straightforward way to implement the PSK/cipher 2768 suite matching requirements is to negotiate the cipher suite first 2769 and then exclude any incompatible PSKs. Any unknown PSKs (e.g., they 2770 are not in the PSK database or are encrypted with an unknown key) 2771 SHOULD simply be ignored. If no acceptable PSKs are found, the 2772 server SHOULD perform a non-PSK handshake if possible. If backwards 2773 compatibility is important, client provided, externally established 2774 PSKs SHOULD influence cipher suite selection. 2776 Prior to accepting PSK key establishment, the server MUST validate 2777 the corresponding binder value (see Section 4.2.11.2 below). If this 2778 value is not present or does not validate, the server MUST abort the 2779 handshake. Servers SHOULD NOT attempt to validate multiple binders; 2780 rather they SHOULD select a single PSK and validate solely the binder 2781 that corresponds to that PSK. See [Section 8.2] for the security 2782 rationale for this requirement. In order to accept PSK key 2783 establishment, the server sends a "pre_shared_key" extension 2784 indicating the selected identity. 2786 Clients MUST verify that the server's selected_identity is within the 2787 range supplied by the client, that the server selected a cipher suite 2788 indicating a Hash associated with the PSK and that a server 2789 "key_share" extension is present if required by the ClientHello 2790 "psk_key_exchange_modes". If these values are not consistent the 2791 client MUST abort the handshake with an "illegal_parameter" alert. 2793 If the server supplies an "early_data" extension, the client MUST 2794 verify that the server's selected_identity is 0. If any other value 2795 is returned, the client MUST abort the handshake with an 2796 "illegal_parameter" alert. 2798 The "pre_shared_key" extension MUST be the last extension in the 2799 ClientHello (this facilitates implementation as described below). 2800 Servers MUST check that it is the last extension and otherwise fail 2801 the handshake with an "illegal_parameter" alert. 2803 4.2.11.1. Ticket Age 2805 The client's view of the age of a ticket is the time since the 2806 receipt of the NewSessionTicket message. Clients MUST NOT attempt to 2807 use tickets which have ages greater than the "ticket_lifetime" value 2808 which was provided with the ticket. The "obfuscated_ticket_age" 2809 field of each PskIdentity contains an obfuscated version of the 2810 ticket age formed by taking the age in milliseconds and adding the 2811 "ticket_age_add" value that was included with the ticket (see 2812 Section 4.6.1), modulo 2^32. This addition prevents passive 2813 observers from correlating connections unless tickets are reused. 2814 Note that the "ticket_lifetime" field in the NewSessionTicket message 2815 is in seconds but the "obfuscated_ticket_age" is in milliseconds. 2816 Because ticket lifetimes are restricted to a week, 32 bits is enough 2817 to represent any plausible age, even in milliseconds. 2819 4.2.11.2. PSK Binder 2821 The PSK binder value forms a binding between a PSK and the current 2822 handshake, as well as a binding between the handshake in which the 2823 PSK was generated (if via a NewSessionTicket message) and the current 2824 handshake. Each entry in the binders list is computed as an HMAC 2825 over a transcript hash (see Section 4.4.1) containing a partial 2826 ClientHello up to and including the PreSharedKeyExtension.identities 2827 field. That is, it includes all of the ClientHello but not the 2828 binders list itself. The length fields for the message (including 2829 the overall length, the length of the extensions block, and the 2830 length of the "pre_shared_key" extension) are all set as if binders 2831 of the correct lengths were present. 2833 The PskBinderEntry is computed in the same way as the Finished 2834 message (Section 4.4.4) but with the BaseKey being the binder_key 2835 derived via the key schedule from the corresponding PSK which is 2836 being offered (see Section 7.1). 2838 If the handshake includes a HelloRetryRequest, the initial 2839 ClientHello and HelloRetryRequest are included in the transcript 2840 along with the new ClientHello. For instance, if the client sends 2841 ClientHello1, its binder will be computed over: 2843 Transcript-Hash(Truncate(ClientHello1)) 2845 Where Truncate() removes the binders list from the ClientHello. 2847 If the server responds with HelloRetryRequest, and the client then 2848 sends ClientHello2, its binder will be computed over: 2850 Transcript-Hash(ClientHello1, 2851 HelloRetryRequest, 2852 Truncate(ClientHello2)) 2854 The full ClientHello1/ClientHello2 is included in all other handshake 2855 hash computations. Note that in the first flight, 2856 Truncate(ClientHello1) is hashed directly, but in the second flight, 2857 ClientHello1 is hashed and then reinjected as a "message_hash" 2858 message, as described in Section 4.4.1. 2860 4.2.11.3. Processing Order 2862 Clients are permitted to "stream" 0-RTT data until they receive the 2863 server's Finished, only then sending the EndOfEarlyData message, 2864 followed by the rest of the handshake. In order to avoid deadlocks, 2865 when accepting "early_data", servers MUST process the client's 2866 ClientHello and then immediately send their flight of messages, 2867 rather than waiting for the client's EndOfEarlyData message before 2868 sending its ServerHello. 2870 4.3. Server Parameters 2872 The next two messages from the server, EncryptedExtensions and 2873 CertificateRequest, contain information from the server that 2874 determines the rest of the handshake. These messages are encrypted 2875 with keys derived from the server_handshake_traffic_secret. 2877 4.3.1. Encrypted Extensions 2879 In all handshakes, the server MUST send the EncryptedExtensions 2880 message immediately after the ServerHello message. This is the first 2881 message that is encrypted under keys derived from the 2882 server_handshake_traffic_secret. 2884 The EncryptedExtensions message contains extensions that can be 2885 protected, i.e., any which are not needed to establish the 2886 cryptographic context, but which are not associated with individual 2887 certificates. The client MUST check EncryptedExtensions for the 2888 presence of any forbidden extensions and if any are found MUST abort 2889 the handshake with an "illegal_parameter" alert. 2891 Structure of this message: 2893 struct { 2894 Extension extensions<0..2^16-1>; 2895 } EncryptedExtensions; 2897 extensions A list of extensions. For more information, see the 2898 table in Section 4.2. 2900 4.3.2. Certificate Request 2902 A server which is authenticating with a certificate MAY optionally 2903 request a certificate from the client. This message, if sent, MUST 2904 follow EncryptedExtensions. 2906 Structure of this message: 2908 struct { 2909 opaque certificate_request_context<0..2^8-1>; 2910 Extension extensions<2..2^16-1>; 2911 } CertificateRequest; 2913 certificate_request_context An opaque string which identifies the 2914 certificate request and which will be echoed in the client's 2915 Certificate message. The certificate_request_context MUST be 2916 unique within the scope of this connection (thus preventing replay 2917 of client CertificateVerify messages). This field SHALL be zero 2918 length unless used for the post-handshake authentication exchanges 2919 described in Section 4.6.2. When requesting post-handshake 2920 authentication, the server SHOULD make the context unpredictable 2921 to the client (e.g., by randomly generating it) in order to 2922 prevent an attacker who has temporary access to the client's 2923 private key from pre-computing valid CertificateVerify messages. 2925 extensions A set of extensions describing the parameters of the 2926 certificate being requested. The "signature_algorithms" extension 2927 MUST be specified, and other extensions may optionally be included 2928 if defined for this message. Clients MUST ignore unrecognized 2929 extensions. 2931 In prior versions of TLS, the CertificateRequest message carried a 2932 list of signature algorithms and certificate authorities which the 2933 server would accept. In TLS 1.3 the former is expressed by sending 2934 the "signature_algorithms" and optionally "signature_algorithms_cert" 2935 extensions. The latter is expressed by sending the 2936 "certificate_authorities" extension (see Section 4.2.4). 2938 Servers which are authenticating with a PSK MUST NOT send the 2939 CertificateRequest message in the main handshake, though they MAY 2940 send it in post-handshake authentication (see Section 4.6.2) provided 2941 that the client has sent the "post_handshake_auth" extension (see 2942 Section 4.2.6). 2944 4.4. Authentication Messages 2946 As discussed in Section 2, TLS generally uses a common set of 2947 messages for authentication, key confirmation, and handshake 2948 integrity: Certificate, CertificateVerify, and Finished. (The 2949 PreSharedKey binders also perform key confirmation, in a similar 2950 fashion.) These three messages are always sent as the last messages 2951 in their handshake flight. The Certificate and CertificateVerify 2952 messages are only sent under certain circumstances, as defined below. 2953 The Finished message is always sent as part of the Authentication 2954 block. These messages are encrypted under keys derived from 2955 [sender]_handshake_traffic_secret. 2957 The computations for the Authentication messages all uniformly take 2958 the following inputs: 2960 - The certificate and signing key to be used. 2962 - A Handshake Context consisting of the set of messages to be 2963 included in the transcript hash. 2965 - A base key to be used to compute a MAC key. 2967 Based on these inputs, the messages then contain: 2969 Certificate The certificate to be used for authentication, and any 2970 supporting certificates in the chain. Note that certificate-based 2971 client authentication is not available in PSK (including 0-RTT) 2972 flows. 2974 CertificateVerify A signature over the value Transcript- 2975 Hash(Handshake Context, Certificate) 2977 Finished A MAC over the value Transcript-Hash(Handshake Context, 2978 Certificate, CertificateVerify) using a MAC key derived from the 2979 base key. 2981 The following table defines the Handshake Context and MAC Base Key 2982 for each scenario: 2984 +-----------+----------------------------+--------------------------+ 2985 | Mode | Handshake Context | Base Key | 2986 +-----------+----------------------------+--------------------------+ 2987 | Server | ClientHello ... later of E | server_handshake_traffic | 2988 | | ncryptedExtensions/Certifi | _secret | 2989 | | cateRequest | | 2990 | | | | 2991 | Client | ClientHello ... later of | client_handshake_traffic | 2992 | | server | _secret | 2993 | | Finished/EndOfEarlyData | | 2994 | | | | 2995 | Post- | ClientHello ... client | client_application_traff | 2996 | Handshake | Finished + | ic_secret_N | 2997 | | CertificateRequest | | 2998 +-----------+----------------------------+--------------------------+ 3000 4.4.1. The Transcript Hash 3002 Many of the cryptographic computations in TLS make use of a 3003 transcript hash. This value is computed by hashing the concatenation 3004 of each included handshake message, including the handshake message 3005 header carrying the handshake message type and length fields, but not 3006 including record layer headers. I.e., 3008 Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn) 3010 As an exception to this general rule, when the server responds to a 3011 ClientHello with a HelloRetryRequest, the value of ClientHello1 is 3012 replaced with a special synthetic handshake message of handshake type 3013 "message_hash" containing Hash(ClientHello1). I.e., 3015 Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) = 3016 Hash(message_hash || /* Handshake type */ 3017 00 00 Hash.length || /* Handshake message length (bytes) */ 3018 Hash(ClientHello1) || /* Hash of ClientHello1 */ 3019 HelloRetryRequest || ... || Mn) 3021 The reason for this construction is to allow the server to do a 3022 stateless HelloRetryRequest by storing just the hash of ClientHello1 3023 in the cookie, rather than requiring it to export the entire 3024 intermediate hash state (see Section 4.2.2). 3026 For concreteness, the transcript hash is always taken from the 3027 following sequence of handshake messages, starting at the first 3028 ClientHello and including only those messages that were sent: 3030 ClientHello, HelloRetryRequest, ClientHello, ServerHello, 3031 EncryptedExtensions, server CertificateRequest, server Certificate, 3032 server CertificateVerify, server Finished, EndOfEarlyData, client 3033 Certificate, client CertificateVerify, client Finished. 3035 In general, implementations can implement the transcript by keeping a 3036 running transcript hash value based on the negotiated hash. Note, 3037 however, that subsequent post-handshake authentications do not 3038 include each other, just the messages through the end of the main 3039 handshake. 3041 4.4.2. Certificate 3043 This message conveys the endpoint's certificate chain to the peer. 3045 The server MUST send a Certificate message whenever the agreed-upon 3046 key exchange method uses certificates for authentication (this 3047 includes all key exchange methods defined in this document except 3048 PSK). 3050 The client MUST send a Certificate message if and only if the server 3051 has requested client authentication via a CertificateRequest message 3052 (Section 4.3.2). If the server requests client authentication but no 3053 suitable certificate is available, the client MUST send a Certificate 3054 message containing no certificates (i.e., with the "certificate_list" 3055 field having length 0). A Finished message MUST be sent regardless 3056 of whether the Certificate message is empty. 3058 Structure of this message: 3060 /* Managed by IANA */ 3061 enum { 3062 X509(0), 3063 RawPublicKey(2), 3064 (255) 3065 } CertificateType; 3067 struct { 3068 select (certificate_type) { 3069 case RawPublicKey: 3070 /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ 3071 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 3073 case X509: 3074 opaque cert_data<1..2^24-1>; 3075 }; 3076 Extension extensions<0..2^16-1>; 3077 } CertificateEntry; 3079 struct { 3080 opaque certificate_request_context<0..2^8-1>; 3081 CertificateEntry certificate_list<0..2^24-1>; 3082 } Certificate; 3084 certificate_request_context If this message is in response to a 3085 CertificateRequest, the value of certificate_request_context in 3086 that message. Otherwise (in the case of server authentication), 3087 this field SHALL be zero length. 3089 certificate_list This is a sequence (chain) of CertificateEntry 3090 structures, each containing a single certificate and set of 3091 extensions. 3093 extensions: A set of extension values for the CertificateEntry. The 3094 "Extension" format is defined in Section 4.2. Valid extensions 3095 for server certificates at present include OCSP Status extension 3096 ([RFC6066]) and SignedCertificateTimestamps ([RFC6962]); future 3097 extensions may be defined for this message as well. Extensions in 3098 the Certificate message from the server MUST correspond to ones 3099 from the ClientHello message. Extensions in the Certificate from 3100 the client MUST correspond with extensions in the 3101 CertificateRequest message from the server. If an extension 3102 applies to the entire chain, it SHOULD be included in the first 3103 CertificateEntry. 3105 If the corresponding certificate type extension 3106 ("server_certificate_type" or "client_certificate_type") was not 3107 negotiated in Encrypted Extensions, or the X.509 certificate type was 3108 negotiated, then each CertificateEntry contains a DER-encoded X.509 3109 certificate. The sender's certificate MUST come in the first 3110 CertificateEntry in the list. Each following certificate SHOULD 3111 directly certify the one immediately preceding it. Because 3112 certificate validation requires that trust anchors be distributed 3113 independently, a certificate that specifies a trust anchor MAY be 3114 omitted from the chain, provided that supported peers are known to 3115 possess any omitted certificates. 3117 Note: Prior to TLS 1.3, "certificate_list" ordering required each 3118 certificate to certify the one immediately preceding it; however, 3119 some implementations allowed some flexibility. Servers sometimes 3120 send both a current and deprecated intermediate for transitional 3121 purposes, and others are simply configured incorrectly, but these 3122 cases can nonetheless be validated properly. For maximum 3123 compatibility, all implementations SHOULD be prepared to handle 3124 potentially extraneous certificates and arbitrary orderings from any 3125 TLS version, with the exception of the end-entity certificate which 3126 MUST be first. 3128 If the RawPublicKey certificate type was negotiated, then the 3129 certificate_list MUST contain no more than one CertificateEntry, 3130 which contains an ASN1_subjectPublicKeyInfo value as defined in 3131 [RFC7250], Section 3. 3133 The OpenPGP certificate type [RFC6091] MUST NOT be used with TLS 1.3. 3135 The server's certificate_list MUST always be non-empty. A client 3136 will send an empty certificate_list if it does not have an 3137 appropriate certificate to send in response to the server's 3138 authentication request. 3140 4.4.2.1. OCSP Status and SCT Extensions 3142 [RFC6066] and [RFC6961] provide extensions to negotiate the server 3143 sending OCSP responses to the client. In TLS 1.2 and below, the 3144 server replies with an empty extension to indicate negotiation of 3145 this extension and the OCSP information is carried in a 3146 CertificateStatus message. In TLS 1.3, the server's OCSP information 3147 is carried in an extension in the CertificateEntry containing the 3148 associated certificate. Specifically: The body of the 3149 "status_request" extension from the server MUST be a 3150 CertificateStatus structure as defined in [RFC6066], which is 3151 interpreted as defined in [RFC6960]. 3153 Note: status_request_v2 extension ([RFC6961]) is deprecated. TLS 1.3 3154 servers MUST NOT act upon its presence or information in it when 3155 processing Client Hello, in particular they MUST NOT send the 3156 status_request_v2 extension in the Encrypted Extensions, Certificate 3157 Request or the Certificate messages. TLS 1.3 servers MUST be able to 3158 process Client Hello messages that include it, as it MAY be sent by 3159 clients that wish to use it in earlier protocol versions. 3161 A server MAY request that a client present an OCSP response with its 3162 certificate by sending an empty "status_request" extension in its 3163 CertificateRequest message. If the client opts to send an OCSP 3164 response, the body of its "status_request" extension MUST be a 3165 CertificateStatus structure as defined in [RFC6066]. 3167 Similarly, [RFC6962] provides a mechanism for a server to send a 3168 Signed Certificate Timestamp (SCT) as an extension in the ServerHello 3169 in TLS 1.2 and below. In TLS 1.3, the server's SCT information is 3170 carried in an extension in CertificateEntry. 3172 4.4.2.2. Server Certificate Selection 3174 The following rules apply to the certificates sent by the server: 3176 - The certificate type MUST be X.509v3 [RFC5280], unless explicitly 3177 negotiated otherwise (e.g., [RFC7250]). 3179 - The server's end-entity certificate's public key (and associated 3180 restrictions) MUST be compatible with the selected authentication 3181 algorithm from the client's "signature_algorithms" extension 3182 (currently RSA, ECDSA, or EdDSA). 3184 - The certificate MUST allow the key to be used for signing (i.e., 3185 the digitalSignature bit MUST be set if the Key Usage extension is 3186 present) with a signature scheme indicated in the client's 3187 "signature_algorithms"/"signature_algorithms_cert" extensions (see 3188 Section 4.2.3). 3190 - The "server_name" [RFC6066] and "certificate_authorities" 3191 extensions are used to guide certificate selection. As servers 3192 MAY require the presence of the "server_name" extension, clients 3193 SHOULD send this extension, when applicable. 3195 All certificates provided by the server MUST be signed by a signature 3196 algorithm advertised by the client, if it is able to provide such a 3197 chain (see Section 4.2.3). Certificates that are self-signed or 3198 certificates that are expected to be trust anchors are not validated 3199 as part of the chain and therefore MAY be signed with any algorithm. 3201 If the server cannot produce a certificate chain that is signed only 3202 via the indicated supported algorithms, then it SHOULD continue the 3203 handshake by sending the client a certificate chain of its choice 3204 that may include algorithms that are not known to be supported by the 3205 client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash 3206 algorithm in general, but MAY do so if the client's advertisement 3207 permits it, and MUST NOT do so otherwise. 3209 If the client cannot construct an acceptable chain using the provided 3210 certificates and decides to abort the handshake, then it MUST abort 3211 the handshake with an appropriate certificate-related alert (by 3212 default, "unsupported_certificate"; see Section 6.2 for more). 3214 If the server has multiple certificates, it chooses one of them based 3215 on the above-mentioned criteria (in addition to other criteria, such 3216 as transport layer endpoint, local configuration and preferences). 3218 4.4.2.3. Client Certificate Selection 3220 The following rules apply to certificates sent by the client: 3222 - The certificate type MUST be X.509v3 [RFC5280], unless explicitly 3223 negotiated otherwise (e.g., [RFC7250]). 3225 - If the "certificate_authorities" extension in the 3226 CertificateRequest message was present, at least one of the 3227 certificates in the certificate chain SHOULD be issued by one of 3228 the listed CAs. 3230 - The certificates MUST be signed using an acceptable signature 3231 algorithm, as described in Section 4.3.2. Note that this relaxes 3232 the constraints on certificate-signing algorithms found in prior 3233 versions of TLS. 3235 - If the CertificateRequest message contained a non-empty 3236 "oid_filters" extension, the end-entity certificate MUST match the 3237 extension OIDs that are recognized by the client, as described in 3238 Section 4.2.5. 3240 Note that, as with the server certificate, there are certificates 3241 that use algorithm combinations that cannot be currently used with 3242 TLS. 3244 4.4.2.4. Receiving a Certificate Message 3246 In general, detailed certificate validation procedures are out of 3247 scope for TLS (see [RFC5280]). This section provides TLS-specific 3248 requirements. 3250 If the server supplies an empty Certificate message, the client MUST 3251 abort the handshake with a "decode_error" alert. 3253 If the client does not send any certificates (i.e., it sends an empty 3254 Certificate message), the server MAY at its discretion either 3255 continue the handshake without client authentication, or abort the 3256 handshake with a "certificate_required" alert. Also, if some aspect 3257 of the certificate chain was unacceptable (e.g., it was not signed by 3258 a known, trusted CA), the server MAY at its discretion either 3259 continue the handshake (considering the client unauthenticated) or 3260 abort the handshake. 3262 Any endpoint receiving any certificate which it would need to 3263 validate using any signature algorithm using an MD5 hash MUST abort 3264 the handshake with a "bad_certificate" alert. SHA-1 is deprecated 3265 and it is RECOMMENDED that any endpoint receiving any certificate 3266 which it would need to validate using any signature algorithm using a 3267 SHA-1 hash abort the handshake with a "bad_certificate" alert. For 3268 clarity, this means that endpoints MAY accept these algorithms for 3269 certificates that are self-signed or are trust anchors. 3271 All endpoints are RECOMMENDED to transition to SHA-256 or better as 3272 soon as possible to maintain interoperability with implementations 3273 currently in the process of phasing out SHA-1 support. 3275 Note that a certificate containing a key for one signature algorithm 3276 MAY be signed using a different signature algorithm (for instance, an 3277 RSA key signed with an ECDSA key). 3279 4.4.3. Certificate Verify 3281 This message is used to provide explicit proof that an endpoint 3282 possesses the private key corresponding to its certificate. The 3283 CertificateVerify message also provides integrity for the handshake 3284 up to this point. Servers MUST send this message when authenticating 3285 via a certificate. Clients MUST send this message whenever 3286 authenticating via a certificate (i.e., when the Certificate message 3287 is non-empty). When sent, this message MUST appear immediately after 3288 the Certificate message and immediately prior to the Finished 3289 message. 3291 Structure of this message: 3293 struct { 3294 SignatureScheme algorithm; 3295 opaque signature<0..2^16-1>; 3296 } CertificateVerify; 3298 The algorithm field specifies the signature algorithm used (see 3299 Section 4.2.3 for the definition of this field). The signature is a 3300 digital signature using that algorithm. The content that is covered 3301 under the signature is the hash output as described in Section 4.4.1, 3302 namely: 3304 Transcript-Hash(Handshake Context, Certificate) 3306 The digital signature is then computed over the concatenation of: 3308 - A string that consists of octet 32 (0x20) repeated 64 times 3310 - The context string 3312 - A single 0 byte which serves as the separator 3314 - The content to be signed 3316 This structure is intended to prevent an attack on previous versions 3317 of TLS in which the ServerKeyExchange format meant that attackers 3318 could obtain a signature of a message with a chosen 32-byte prefix 3319 (ClientHello.random). The initial 64-byte pad clears that prefix 3320 along with the server-controlled ServerHello.random. 3322 The context string for a server signature is: "TLS 1.3, server 3323 CertificateVerify" The context string for a client signature is: "TLS 3324 1.3, client CertificateVerify" It is used to provide separation 3325 between signatures made in different contexts, helping against 3326 potential cross-protocol attacks. 3328 For example, if the transcript hash was 32 bytes of 01 (this length 3329 would make sense for SHA-256), the content covered by the digital 3330 signature for a server CertificateVerify would be: 3332 2020202020202020202020202020202020202020202020202020202020202020 3333 2020202020202020202020202020202020202020202020202020202020202020 3334 544c5320312e332c207365727665722043657274696669636174655665726966 3335 79 3336 00 3337 0101010101010101010101010101010101010101010101010101010101010101 3339 On the sender side the process for computing the signature field of 3340 the CertificateVerify message takes as input: 3342 - The content covered by the digital signature 3344 - The private signing key corresponding to the certificate sent in 3345 the previous message 3347 If the CertificateVerify message is sent by a server, the signature 3348 algorithm MUST be one offered in the client's "signature_algorithms" 3349 extension unless no valid certificate chain can be produced without 3350 unsupported algorithms (see Section 4.2.3). 3352 If sent by a client, the signature algorithm used in the signature 3353 MUST be one of those present in the supported_signature_algorithms 3354 field of the "signature_algorithms" extension in the 3355 CertificateRequest message. 3357 In addition, the signature algorithm MUST be compatible with the key 3358 in the sender's end-entity certificate. RSA signatures MUST use an 3359 RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 3360 algorithms appear in "signature_algorithms". The SHA-1 algorithm 3361 MUST NOT be used in any signatures of CertificateVerify messages. 3362 All SHA-1 signature algorithms in this specification are defined 3363 solely for use in legacy certificates and are not valid for 3364 CertificateVerify signatures. 3366 The receiver of a CertificateVerify message MUST verify the signature 3367 field. The verification process takes as input: 3369 - The content covered by the digital signature 3371 - The public key contained in the end-entity certificate found in 3372 the associated Certificate message. 3374 - The digital signature received in the signature field of the 3375 CertificateVerify message 3377 If the verification fails, the receiver MUST terminate the handshake 3378 with a "decrypt_error" alert. 3380 4.4.4. Finished 3382 The Finished message is the final message in the authentication 3383 block. It is essential for providing authentication of the handshake 3384 and of the computed keys. 3386 Recipients of Finished messages MUST verify that the contents are 3387 correct and if incorrect MUST terminate the connection with a 3388 "decrypt_error" alert. 3390 Once a side has sent its Finished message and received and validated 3391 the Finished message from its peer, it may begin to send and receive 3392 application data over the connection. There are two settings in 3393 which it is permitted to send data prior to receiving the peer's 3394 Finished: 3396 1. Clients sending 0-RTT data as described in Section 4.2.10. 3398 2. Servers MAY send data after sending their first flight, but 3399 because the handshake is not yet complete, they have no assurance 3400 of either the peer's identity or of its liveness (i.e., the 3401 ClientHello might have been replayed). 3403 The key used to compute the Finished message is computed from the 3404 Base key defined in Section 4.4 using HKDF (see Section 7.1). 3405 Specifically: 3407 finished_key = 3408 HKDF-Expand-Label(BaseKey, "finished", "", Hash.length) 3410 Structure of this message: 3412 struct { 3413 opaque verify_data[Hash.length]; 3414 } Finished; 3416 The verify_data value is computed as follows: 3418 verify_data = 3419 HMAC(finished_key, 3420 Transcript-Hash(Handshake Context, 3421 Certificate*, CertificateVerify*)) 3423 * Only included if present. 3425 HMAC [RFC2104] uses the Hash algorithm for the handshake. As noted 3426 above, the HMAC input can generally be implemented by a running hash, 3427 i.e., just the handshake hash at this point. 3429 In previous versions of TLS, the verify_data was always 12 octets 3430 long. In TLS 1.3, it is the size of the HMAC output for the Hash 3431 used for the handshake. 3433 Note: Alerts and any other record types are not handshake messages 3434 and are not included in the hash computations. 3436 Any records following a Finished message MUST be encrypted under the 3437 appropriate application traffic key as described in Section 7.2. In 3438 particular, this includes any alerts sent by the server in response 3439 to client Certificate and CertificateVerify messages. 3441 4.5. End of Early Data 3443 struct {} EndOfEarlyData; 3445 If the server sent an "early_data" extension, the client MUST send an 3446 EndOfEarlyData message after receiving the server Finished. If the 3447 server does not send an "early_data" extension, then the client MUST 3448 NOT send an EndOfEarlyData message. This message indicates that all 3449 0-RTT application_data messages, if any, have been transmitted and 3450 that the following records are protected under handshake traffic 3451 keys. Servers MUST NOT send this message and clients receiving it 3452 MUST terminate the connection with an "unexpected_message" alert. 3453 This message is encrypted under keys derived from the 3454 client_early_traffic_secret. 3456 4.6. Post-Handshake Messages 3458 TLS also allows other messages to be sent after the main handshake. 3459 These messages use a handshake content type and are encrypted under 3460 the appropriate application traffic key. 3462 4.6.1. New Session Ticket Message 3464 At any time after the server has received the client Finished 3465 message, it MAY send a NewSessionTicket message. This message 3466 creates a unique association between the ticket value and a secret 3467 PSK derived from the resumption master secret (see Section 7. 3469 The client MAY use this PSK for future handshakes by including the 3470 ticket value in the "pre_shared_key" extension in its ClientHello 3471 (Section 4.2.11). Servers MAY send multiple tickets on a single 3472 connection, either immediately after each other or after specific 3473 events (see Appendix C.4). For instance, the server might send a new 3474 ticket after post-handshake authentication in order to encapsulate 3475 the additional client authentication state. Multiple tickets are 3476 useful for clients for a variety of purposes, including: 3478 - Opening multiple parallel HTTP connections. 3480 - Performing connection racing across interfaces and address 3481 families via, e.g., Happy Eyeballs [RFC8305] or related 3482 techniques. 3484 Any ticket MUST only be resumed with a cipher suite that has the same 3485 KDF hash algorithm as that used to establish the original connection. 3487 Clients MUST only resume if the new SNI value is valid for the server 3488 certificate presented in the original session, and SHOULD only resume 3489 if the SNI value matches the one used in the original session. The 3490 latter is a performance optimization: normally, there is no reason to 3491 expect that different servers covered by a single certificate would 3492 be able to accept each other's tickets, hence attempting resumption 3493 in that case would waste a single-use ticket. If such an indication 3494 is provided (externally or by any other means), clients MAY resume 3495 with a different SNI value. 3497 On resumption, if reporting an SNI value to the calling application, 3498 implementations MUST use the value sent in the resumption ClientHello 3499 rather than the value sent in the previous session. Note that if a 3500 server implementation declines all PSK identities with different SNI 3501 values, these two values are always the same. 3503 Note: Although the resumption master secret depends on the client's 3504 second flight, servers which do not request client authentication MAY 3505 compute the remainder of the transcript independently and then send a 3506 NewSessionTicket immediately upon sending its Finished rather than 3507 waiting for the client Finished. This might be appropriate in cases 3508 where the client is expected to open multiple TLS connections in 3509 parallel and would benefit from the reduced overhead of a resumption 3510 handshake, for example. 3512 struct { 3513 uint32 ticket_lifetime; 3514 uint32 ticket_age_add; 3515 opaque ticket_nonce<0..255>; 3516 opaque ticket<1..2^16-1>; 3517 Extension extensions<0..2^16-2>; 3518 } NewSessionTicket; 3520 ticket_lifetime Indicates the lifetime in seconds as a 32-bit 3521 unsigned integer in network byte order from the time of ticket 3522 issuance. Servers MUST NOT use any value greater than 604800 3523 seconds (7 days). The value of zero indicates that the ticket 3524 should be discarded immediately. Clients MUST NOT cache tickets 3525 for longer than 7 days, regardless of the ticket_lifetime, and MAY 3526 delete tickets earlier based on local policy. A server MAY treat 3527 a ticket as valid for a shorter period of time than what is stated 3528 in the ticket_lifetime. 3530 ticket_age_add A securely generated, random 32-bit value that is 3531 used to obscure the age of the ticket that the client includes in 3532 the "pre_shared_key" extension. The client-side ticket age is 3533 added to this value modulo 2^32 to obtain the value that is 3534 transmitted by the client. The server MUST generate a fresh value 3535 for each ticket it sends. 3537 ticket_nonce A per-ticket value that is unique across all tickets 3538 issued on this connection. 3540 ticket The value of the ticket to be used as the PSK identity. The 3541 ticket itself is an opaque label. It MAY either be a database 3542 lookup key or a self-encrypted and self-authenticated value. 3543 Section 4 of [RFC5077] describes a recommended ticket construction 3544 mechanism. 3546 extensions A set of extension values for the ticket. The 3547 "Extension" format is defined in Section 4.2. Clients MUST ignore 3548 unrecognized extensions. 3550 The sole extension currently defined for NewSessionTicket is 3551 "early_data", indicating that the ticket may be used to send 0-RTT 3552 data (Section 4.2.10)). It contains the following value: 3554 max_early_data_size The maximum amount of 0-RTT data that the client 3555 is allowed to send when using this ticket, in bytes. Only 3556 Application Data payload (i.e., plaintext but not padding or the 3557 inner content type byte) is counted. A server receiving more than 3558 max_early_data_size bytes of 0-RTT data SHOULD terminate the 3559 connection with an "unexpected_message" alert. Note that servers 3560 that reject early data due to lack of cryptographic material will 3561 be unable to differentiate padding from content, so clients SHOULD 3562 NOT depend on being able to send large quantities of padding in 3563 early data records. 3565 The PSK associated with the ticket is computed as: 3567 HKDF-Expand-Label(resumption_master_secret, 3568 "resumption", ticket_nonce, Hash.length) 3570 Because the ticket_nonce value is distinct for each NewSessionTicket 3571 message, a different PSK will be derived for each ticket. 3573 Note that in principle it is possible to continue issuing new tickets 3574 which indefinitely extend the lifetime of the keying material 3575 originally derived from an initial non-PSK handshake (which was most 3576 likely tied to the peer's certificate). It is RECOMMENDED that 3577 implementations place limits on the total lifetime of such keying 3578 material; these limits should take into account the lifetime of the 3579 peer's certificate, the likelihood of intervening revocation, and the 3580 time since the peer's online CertificateVerify signature. 3582 4.6.2. Post-Handshake Authentication 3584 When the client has sent the "post_handshake_auth" extension (see 3585 Section 4.2.6), a server MAY request client authentication at any 3586 time after the handshake has completed by sending a 3587 CertificateRequest message. The client MUST respond with the 3588 appropriate Authentication messages (see Section 4.4). If the client 3589 chooses to authenticate, it MUST send Certificate, CertificateVerify, 3590 and Finished. If it declines, it MUST send a Certificate message 3591 containing no certificates followed by Finished. All of the client's 3592 messages for a given response MUST appear consecutively on the wire 3593 with no intervening messages of other types. 3595 A client that receives a CertificateRequest message without having 3596 sent the "post_handshake_auth" extension MUST send an 3597 "unexpected_message" fatal alert. 3599 Note: Because client authentication could involve prompting the user, 3600 servers MUST be prepared for some delay, including receiving an 3601 arbitrary number of other messages between sending the 3602 CertificateRequest and receiving a response. In addition, clients 3603 which receive multiple CertificateRequests in close succession MAY 3604 respond to them in a different order than they were received (the 3605 certificate_request_context value allows the server to disambiguate 3606 the responses). 3608 4.6.3. Key and IV Update 3610 enum { 3611 update_not_requested(0), update_requested(1), (255) 3612 } KeyUpdateRequest; 3614 struct { 3615 KeyUpdateRequest request_update; 3616 } KeyUpdate; 3618 request_update Indicates whether the recipient of the KeyUpdate 3619 should respond with its own KeyUpdate. If an implementation 3620 receives any other value, it MUST terminate the connection with an 3621 "illegal_parameter" alert. 3623 The KeyUpdate handshake message is used to indicate that the sender 3624 is updating its sending cryptographic keys. This message can be sent 3625 by either peer after it has sent a Finished message. Implementations 3626 that receive a KeyUpdate message prior to receiving a Finished 3627 message MUST terminate the connection with an "unexpected_message" 3628 alert. After sending a KeyUpdate message, the sender SHALL send all 3629 its traffic using the next generation of keys, computed as described 3630 in Section 7.2. Upon receiving a KeyUpdate, the receiver MUST update 3631 its receiving keys. 3633 If the request_update field is set to "update_requested" then the 3634 receiver MUST send a KeyUpdate of its own with request_update set to 3635 "update_not_requested" prior to sending its next application data 3636 record. This mechanism allows either side to force an update to the 3637 entire connection, but causes an implementation which receives 3638 multiple KeyUpdates while it is silent to respond with a single 3639 update. Note that implementations may receive an arbitrary number of 3640 messages between sending a KeyUpdate with request_update set to 3641 update_requested and receiving the peer's KeyUpdate, because those 3642 messages may already be in flight. However, because send and receive 3643 keys are derived from independent traffic secrets, retaining the 3644 receive traffic secret does not threaten the forward secrecy of data 3645 sent before the sender changed keys. 3647 If implementations independently send their own KeyUpdates with 3648 request_update set to "update_requested", and they cross in flight, 3649 then each side will also send a response, with the result that each 3650 side increments by two generations. 3652 Both sender and receiver MUST encrypt their KeyUpdate messages with 3653 the old keys. Additionally, both sides MUST enforce that a KeyUpdate 3654 with the old key is received before accepting any messages encrypted 3655 with the new key. Failure to do so may allow message truncation 3656 attacks. 3658 5. Record Protocol 3660 The TLS record protocol takes messages to be transmitted, fragments 3661 the data into manageable blocks, protects the records, and transmits 3662 the result. Received data is verified, decrypted, reassembled, and 3663 then delivered to higher-level clients. 3665 TLS records are typed, which allows multiple higher-level protocols 3666 to be multiplexed over the same record layer. This document 3667 specifies four content types: handshake, application data, alert, and 3668 change_cipher_spec. The change_cipher_spec record is used only for 3669 compatibility purposes (see Appendix D.4). 3671 An implementation may receive an unencrypted record of type 3672 change_cipher_spec consisting of the single byte value 0x01 at any 3673 time after the first ClientHello message has been sent or received 3674 and before the peer's Finished message has been received and MUST 3675 simply drop it without further processing. Note that this record may 3676 appear at a point at the handshake where the implementation is 3677 expecting protected records and so it is necessary to detect this 3678 condition prior to attempting to deprotect the record. An 3679 implementation which receives any other change_cipher_spec value or 3680 which receives a protected change_cipher_spec record MUST abort the 3681 handshake with an "unexpected_message" alert. A change_cipher_spec 3682 record received before the first ClientHello message or after the 3683 peer's Finished message MUST be treated as an unexpected record type 3684 (though stateless servers may not be able to distinguish these cases 3685 from allowed cases). 3687 Implementations MUST NOT send record types not defined in this 3688 document unless negotiated by some extension. If a TLS 3689 implementation receives an unexpected record type, it MUST terminate 3690 the connection with an "unexpected_message" alert. New record 3691 content type values are assigned by IANA in the TLS Content Type 3692 Registry as described in Section 11. 3694 5.1. Record Layer 3696 The record layer fragments information blocks into TLSPlaintext 3697 records carrying data in chunks of 2^14 bytes or less. Message 3698 boundaries are handled differently depending on the underlying 3699 ContentType. Any future content types MUST specify appropriate 3700 rules. Note that these rules are stricter than what was enforced in 3701 TLS 1.2. 3703 Handshake messages MAY be coalesced into a single TLSPlaintext record 3704 or fragmented across several records, provided that: 3706 - Handshake messages MUST NOT be interleaved with other record 3707 types. That is, if a handshake message is split over two or more 3708 records, there MUST NOT be any other records between them. 3710 - Handshake messages MUST NOT span key changes. Implementations 3711 MUST verify that all messages immediately preceding a key change 3712 align with a record boundary; if not, then they MUST terminate the 3713 connection with an "unexpected_message" alert. Because the 3714 ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate 3715 messages can immediately precede a key change, implementations 3716 MUST send these messages in alignment with a record boundary. 3718 Implementations MUST NOT send zero-length fragments of Handshake 3719 types, even if those fragments contain padding. 3721 Alert messages (Section 6) MUST NOT be fragmented across records and 3722 multiple Alert messages MUST NOT be coalesced into a single 3723 TLSPlaintext record. In other words, a record with an Alert type 3724 MUST contain exactly one message. 3726 Application Data messages contain data that is opaque to TLS. 3727 Application Data messages are always protected. Zero-length 3728 fragments of Application Data MAY be sent as they are potentially 3729 useful as a traffic analysis countermeasure. Application Data 3730 fragments MAY be split across multiple records or coalesced into a 3731 single record. 3733 enum { 3734 invalid(0), 3735 change_cipher_spec(20), 3736 alert(21), 3737 handshake(22), 3738 application_data(23), 3739 (255) 3740 } ContentType; 3742 struct { 3743 ContentType type; 3744 ProtocolVersion legacy_record_version; 3745 uint16 length; 3746 opaque fragment[TLSPlaintext.length]; 3747 } TLSPlaintext; 3749 type The higher-level protocol used to process the enclosed 3750 fragment. 3752 legacy_record_version This value MUST be set to 0x0303 for all 3753 records generated by a TLS 1.3 implementation other than an 3754 initial ClientHello (i.e., one not generated after a 3755 HelloRetryRequest), where it MAY also be 0x0301 for compatibility 3756 purposes. This field is deprecated and MUST be ignored for all 3757 purposes. Previous versions of TLS would use other values in this 3758 field under some circumstances. 3760 length The length (in bytes) of the following TLSPlaintext.fragment. 3761 The length MUST NOT exceed 2^14 bytes. An endpoint that receives 3762 a record that exceeds this length MUST terminate the connection 3763 with a "record_overflow" alert. 3765 fragment The data being transmitted. This value is transparent and 3766 is treated as an independent block to be dealt with by the higher- 3767 level protocol specified by the type field. 3769 This document describes TLS 1.3, which uses the version 0x0304. This 3770 version value is historical, deriving from the use of 0x0301 for TLS 3771 1.0 and 0x0300 for SSL 3.0. In order to maximize backwards 3772 compatibility, records containing an initial ClientHello SHOULD have 3773 version 0x0301 and a record containing a second ClientHello or a 3774 ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2 3775 respectively. When negotiating prior versions of TLS, endpoints 3776 follow the procedure and requirements in Appendix D. 3778 When record protection has not yet been engaged, TLSPlaintext 3779 structures are written directly onto the wire. Once record 3780 protection has started, TLSPlaintext records are protected and sent 3781 as described in the following section. Note that application data 3782 records MUST NOT be written to the wire unprotected (see Section 2 3783 for details). 3785 5.2. Record Payload Protection 3787 The record protection functions translate a TLSPlaintext structure 3788 into a TLSCiphertext. The deprotection functions reverse the 3789 process. In TLS 1.3, as opposed to previous versions of TLS, all 3790 ciphers are modeled as "Authenticated Encryption with Additional 3791 Data" (AEAD) [RFC5116]. AEAD functions provide an unified encryption 3792 and authentication operation which turns plaintext into authenticated 3793 ciphertext and back again. Each encrypted record consists of a 3794 plaintext header followed by an encrypted body, which itself contains 3795 a type and optional padding. 3797 struct { 3798 opaque content[TLSPlaintext.length]; 3799 ContentType type; 3800 uint8 zeros[length_of_padding]; 3801 } TLSInnerPlaintext; 3803 struct { 3804 ContentType opaque_type = application_data; /* 23 */ 3805 ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */ 3806 uint16 length; 3807 opaque encrypted_record[TLSCiphertext.length]; 3808 } TLSCiphertext; 3810 content The TLSPLaintext.fragment value, containing the byte 3811 encoding of a handshake or an alert message, or the raw bytes of 3812 the application's data to send. 3814 type The TLSPlaintext.type value containing the content type of the 3815 record. 3817 zeros An arbitrary-length run of zero-valued bytes may appear in the 3818 cleartext after the type field. This provides an opportunity for 3819 senders to pad any TLS record by a chosen amount as long as the 3820 total stays within record size limits. See Section 5.4 for more 3821 details. 3823 opaque_type The outer opaque_type field of a TLSCiphertext record is 3824 always set to the value 23 (application_data) for outward 3825 compatibility with middleboxes accustomed to parsing previous 3826 versions of TLS. The actual content type of the record is found 3827 in TLSInnerPlaintext.type after decryption. 3829 legacy_record_version The legacy_record_version field is always 3830 0x0303. TLS 1.3 TLSCiphertexts are not generated until after TLS 3831 1.3 has been negotiated, so there are no historical compatibility 3832 concerns where other values might be received. Note that the 3833 handshake protocol including the ClientHello and ServerHello 3834 messages authenticates the protocol version, so this value is 3835 redundant. 3837 length The length (in bytes) of the following 3838 TLSCiphertext.encrypted_record, which is the sum of the lengths of 3839 the content and the padding, plus one for the inner content type, 3840 plus any expansion added by the AEAD algorithm. The length MUST 3841 NOT exceed 2^14 + 256 bytes. An endpoint that receives a record 3842 that exceeds this length MUST terminate the connection with a 3843 "record_overflow" alert. 3845 encrypted_record The AEAD-encrypted form of the serialized 3846 TLSInnerPlaintext structure. 3848 AEAD algorithms take as input a single key, a nonce, a plaintext, and 3849 "additional data" to be included in the authentication check, as 3850 described in Section 2.1 of [RFC5116]. The key is either the 3851 client_write_key or the server_write_key, the nonce is derived from 3852 the sequence number and the client_write_iv or server_write_iv (see 3853 Section 5.3), and the additional data input is the record header. 3854 I.e., 3856 additional_data = TLSCiphertext.opaque_type || 3857 TLSCiphertext.legacy_record_version || 3858 TLSCiphertext.length 3860 The plaintext input to the AEAD algorithm is the encoded 3861 TLSInnerPlaintext structure. Derivation of traffic keys is defined 3862 in Section 7.3. 3864 The AEAD output consists of the ciphertext output from the AEAD 3865 encryption operation. The length of the plaintext is greater than 3866 the corresponding TLSPlaintext.length due to the inclusion of 3867 TLSInnerPlaintext.type and any padding supplied by the sender. The 3868 length of the AEAD output will generally be larger than the 3869 plaintext, but by an amount that varies with the AEAD algorithm. 3870 Since the ciphers might incorporate padding, the amount of overhead 3871 could vary with different lengths of plaintext. Symbolically, 3873 AEADEncrypted = 3874 AEAD-Encrypt(write_key, nonce, additional_data, plaintext) 3876 Then the encrypted_record field of TLSCiphertext is set to 3877 AEADEncrypted. 3879 In order to decrypt and verify, the cipher takes as input the key, 3880 nonce, additional data, and the AEADEncrypted value. The output is 3881 either the plaintext or an error indicating that the decryption 3882 failed. There is no separate integrity check. That is: 3884 plaintext of encrypted_record = 3885 AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted) 3887 If the decryption fails, the receiver MUST terminate the connection 3888 with a "bad_record_mac" alert. 3890 An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion 3891 greater than 255 octets. An endpoint that receives a record from its 3892 peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST 3893 terminate the connection with a "record_overflow" alert. This limit 3894 is derived from the maximum TLSInnerPlaintext length of 2^14 octets + 3895 1 octet for ContentType + the maximum AEAD expansion of 255 octets. 3897 5.3. Per-Record Nonce 3899 A 64-bit sequence number is maintained separately for reading and 3900 writing records. The appropriate sequence number is incremented by 3901 one after reading or writing each record. Each sequence number is 3902 set to zero at the beginning of a connection and whenever the key is 3903 changed; the first record transmitted under a particular traffic key 3904 MUST use sequence number 0. 3906 Because the size of sequence numbers is 64-bit, they should not wrap. 3907 If a TLS implementation would need to wrap a sequence number, it MUST 3908 either re-key (Section 4.6.3) or terminate the connection. 3910 Each AEAD algorithm will specify a range of possible lengths for the 3911 per-record nonce, from N_MIN bytes to N_MAX bytes of input 3912 ([RFC5116]). The length of the TLS per-record nonce (iv_length) is 3913 set to the larger of 8 bytes and N_MIN for the AEAD algorithm (see 3914 [RFC5116] Section 4). An AEAD algorithm where N_MAX is less than 8 3915 bytes MUST NOT be used with TLS. The per-record nonce for the AEAD 3916 construction is formed as follows: 3918 1. The 64-bit record sequence number is encoded in network byte 3919 order and padded to the left with zeros to iv_length. 3921 2. The padded sequence number is XORed with the static 3922 client_write_iv or server_write_iv, depending on the role. 3924 The resulting quantity (of length iv_length) is used as the per- 3925 record nonce. 3927 Note: This is a different construction from that in TLS 1.2, which 3928 specified a partially explicit nonce. 3930 5.4. Record Padding 3932 All encrypted TLS records can be padded to inflate the size of the 3933 TLSCiphertext. This allows the sender to hide the size of the 3934 traffic from an observer. 3936 When generating a TLSCiphertext record, implementations MAY choose to 3937 pad. An unpadded record is just a record with a padding length of 3938 zero. Padding is a string of zero-valued bytes appended to the 3939 ContentType field before encryption. Implementations MUST set the 3940 padding octets to all zeros before encrypting. 3942 Application Data records may contain a zero-length 3943 TLSInnerPlaintext.content if the sender desires. This permits 3944 generation of plausibly-sized cover traffic in contexts where the 3945 presence or absence of activity may be sensitive. Implementations 3946 MUST NOT send Handshake or Alert records that have a zero-length 3947 TLSInnerPlaintext.content; if such a message is received, the 3948 receiving implementation MUST terminate the connection with an 3949 "unexpected_message" alert. 3951 The padding sent is automatically verified by the record protection 3952 mechanism; upon successful decryption of a 3953 TLSCiphertext.encrypted_record, the receiving implementation scans 3954 the field from the end toward the beginning until it finds a non-zero 3955 octet. This non-zero octet is the content type of the message. This 3956 padding scheme was selected because it allows padding of any 3957 encrypted TLS record by an arbitrary size (from zero up to TLS record 3958 size limits) without introducing new content types. The design also 3959 enforces all-zero padding octets, which allows for quick detection of 3960 padding errors. 3962 Implementations MUST limit their scanning to the cleartext returned 3963 from the AEAD decryption. If a receiving implementation does not 3964 find a non-zero octet in the cleartext, it MUST terminate the 3965 connection with an "unexpected_message" alert. 3967 The presence of padding does not change the overall record size 3968 limitations - the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 3969 + 1 octets. If the maximum fragment length is reduced, as for 3970 example by the max_fragment_length extension from [RFC6066], then the 3971 reduced limit applies to the full plaintext, including the content 3972 type and padding. 3974 Selecting a padding policy that suggests when and how much to pad is 3975 a complex topic and is beyond the scope of this specification. If 3976 the application layer protocol on top of TLS has its own padding, it 3977 may be preferable to pad application_data TLS records within the 3978 application layer. Padding for encrypted handshake and alert TLS 3979 records must still be handled at the TLS layer, though. Later 3980 documents may define padding selection algorithms or define a padding 3981 policy request mechanism through TLS extensions or some other means. 3983 5.5. Limits on Key Usage 3985 There are cryptographic limits on the amount of plaintext which can 3986 be safely encrypted under a given set of keys. [AEAD-LIMITS] 3987 provides an analysis of these limits under the assumption that the 3988 underlying primitive (AES or ChaCha20) has no weaknesses. 3989 Implementations SHOULD do a key update as described in Section 4.6.3 3990 prior to reaching these limits. 3992 For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be 3993 encrypted on a given connection while keeping a safety margin of 3994 approximately 2^-57 for Authenticated Encryption (AE) security. For 3995 ChaCha20/Poly1305, the record sequence number would wrap before the 3996 safety limit is reached. 3998 6. Alert Protocol 4000 One of the content types supported by the TLS record layer is the 4001 alert type. Like other messages, alert messages are encrypted as 4002 specified by the current connection state. 4004 Alert messages convey a description of the alert and a legacy field 4005 that conveyed the severity of the message in previous versions of 4006 TLS. Alerts are divided into two classes: closure alerts and error 4007 alerts. In TLS 1.3, the severity is implicit in the type of alert 4008 being sent, and the 'level' field can safely be ignored. The 4009 "close_notify" alert is used to indicate orderly closure of one 4010 direction of the connection. Upon receiving such an alert, the TLS 4011 implementation SHOULD indicate end-of-data to the application. 4013 Error alerts indicate abortive closure of the connection (see 4014 Section 6.2). Upon receiving an error alert, the TLS implementation 4015 SHOULD indicate an error to the application and MUST NOT allow any 4016 further data to be sent or received on the connection. Servers and 4017 clients MUST forget the secret values and keys established in failed 4018 connections, with the exception of the PSKs associated with session 4019 tickets, which SHOULD be discarded if possible. 4021 All the alerts listed in Section 6.2 MUST be sent with 4022 AlertLevel=fatal and MUST be treated as error alerts regardless of 4023 the AlertLevel in the message. Unknown alert types MUST be treated 4024 as error alerts. 4026 Note: TLS defines two generic alerts (see Section 6) to use upon 4027 failure to parse a message. Peers which receive a message which 4028 cannot be parsed according to the syntax (e.g., have a length 4029 extending beyond the message boundary or contain an out-of-range 4030 length) MUST terminate the connection with a "decode_error" alert. 4031 Peers which receive a message which is syntactically correct but 4032 semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) 4033 MUST terminate the connection with an "illegal_parameter" alert. 4035 enum { warning(1), fatal(2), (255) } AlertLevel; 4037 enum { 4038 close_notify(0), 4039 unexpected_message(10), 4040 bad_record_mac(20), 4041 record_overflow(22), 4042 handshake_failure(40), 4043 bad_certificate(42), 4044 unsupported_certificate(43), 4045 certificate_revoked(44), 4046 certificate_expired(45), 4047 certificate_unknown(46), 4048 illegal_parameter(47), 4049 unknown_ca(48), 4050 access_denied(49), 4051 decode_error(50), 4052 decrypt_error(51), 4053 protocol_version(70), 4054 insufficient_security(71), 4055 internal_error(80), 4056 inappropriate_fallback(86), 4057 user_canceled(90), 4058 missing_extension(109), 4059 unsupported_extension(110), 4060 unrecognized_name(112), 4061 bad_certificate_status_response(113), 4062 unknown_psk_identity(115), 4063 certificate_required(116), 4064 no_application_protocol(120), 4065 (255) 4066 } AlertDescription; 4068 struct { 4069 AlertLevel level; 4070 AlertDescription description; 4071 } Alert; 4073 6.1. Closure Alerts 4075 The client and the server must share knowledge that the connection is 4076 ending in order to avoid a truncation attack. 4078 close_notify This alert notifies the recipient that the sender will 4079 not send any more messages on this connection. Any data received 4080 after a closure alert has been received MUST be ignored. 4082 user_canceled This alert notifies the recipient that the sender is 4083 canceling the handshake for some reason unrelated to a protocol 4084 failure. If a user cancels an operation after the handshake is 4085 complete, just closing the connection by sending a "close_notify" 4086 is more appropriate. This alert SHOULD be followed by a 4087 "close_notify". This alert generally has AlertLevel=warning. 4089 Either party MAY initiate a close of its write side of the connection 4090 by sending a "close_notify" alert. Any data received after a closure 4091 alert has been received MUST be ignored. If a transport-level close 4092 is received prior to a "close_notify", the receiver cannot know that 4093 all the data that was sent has been received. 4095 Each party MUST send a "close_notify" alert before closing its write 4096 side of the connection, unless it has already sent some error alert. 4097 This does not have any effect on its read side of the connection. 4098 Note that this is a change from versions of TLS prior to TLS 1.3 in 4099 which implementations were required to react to a "close_notify" by 4100 discarding pending writes and sending an immediate "close_notify" 4101 alert of their own. That previous requirement could cause truncation 4102 in the read side. Both parties need not wait to receive a 4103 "close_notify" alert before closing their read side of the 4104 connection, though doing so would introduce the possibility of 4105 truncation. 4107 If the application protocol using TLS provides that any data may be 4108 carried over the underlying transport after the TLS connection is 4109 closed, the TLS implementation MUST receive a "close_notify" alert 4110 before indicating end-of-data to the application-layer. No part of 4111 this standard should be taken to dictate the manner in which a usage 4112 profile for TLS manages its data transport, including when 4113 connections are opened or closed. 4115 Note: It is assumed that closing the write side of a connection 4116 reliably delivers pending data before destroying the transport. 4118 6.2. Error Alerts 4120 Error handling in the TLS Handshake Protocol is very simple. When an 4121 error is detected, the detecting party sends a message to its peer. 4122 Upon transmission or receipt of a fatal alert message, both parties 4123 MUST immediately close the connection. 4125 Whenever an implementation encounters a fatal error condition, it 4126 SHOULD send an appropriate fatal alert and MUST close the connection 4127 without sending or receiving any additional data. In the rest of 4128 this specification, when the phrases "terminate the connection" and 4129 "abort the handshake" are used without a specific alert it means that 4130 the implementation SHOULD send the alert indicated by the 4131 descriptions below. The phrases "terminate the connection with a X 4132 alert" and "abort the handshake with a X alert" mean that the 4133 implementation MUST send alert X if it sends any alert. All alerts 4134 defined in this section below, as well as all unknown alerts, are 4135 universally considered fatal as of TLS 1.3 (see Section 6). The 4136 implementation SHOULD provide a way to facilitate logging the sending 4137 and receiving of alerts. 4139 The following error alerts are defined: 4141 unexpected_message An inappropriate message (e.g., the wrong 4142 handshake message, premature application data, etc.) was received. 4143 This alert should never be observed in communication between 4144 proper implementations. 4146 bad_record_mac This alert is returned if a record is received which 4147 cannot be deprotected. Because AEAD algorithms combine decryption 4148 and verification, and also to avoid side channel attacks, this 4149 alert is used for all deprotection failures. This alert should 4150 never be observed in communication between proper implementations, 4151 except when messages were corrupted in the network. 4153 record_overflow A TLSCiphertext record was received that had a 4154 length more than 2^14 + 256 bytes, or a record decrypted to a 4155 TLSPlaintext record with more than 2^14 bytes (or some other 4156 negotiated limit). This alert should never be observed in 4157 communication between proper implementations, except when messages 4158 were corrupted in the network. 4160 handshake_failure Receipt of a "handshake_failure" alert message 4161 indicates that the sender was unable to negotiate an acceptable 4162 set of security parameters given the options available. 4164 bad_certificate A certificate was corrupt, contained signatures that 4165 did not verify correctly, etc. 4167 unsupported_certificate A certificate was of an unsupported type. 4169 certificate_revoked A certificate was revoked by its signer. 4171 certificate_expired A certificate has expired or is not currently 4172 valid. 4174 certificate_unknown Some other (unspecified) issue arose in 4175 processing the certificate, rendering it unacceptable. 4177 illegal_parameter A field in the handshake was incorrect or 4178 inconsistent with other fields. This alert is used for errors 4179 which conform to the formal protocol syntax but are otherwise 4180 incorrect. 4182 unknown_ca A valid certificate chain or partial chain was received, 4183 but the certificate was not accepted because the CA certificate 4184 could not be located or could not be matched with a known trust 4185 anchor. 4187 access_denied A valid certificate or PSK was received, but when 4188 access control was applied, the sender decided not to proceed with 4189 negotiation. 4191 decode_error A message could not be decoded because some field was 4192 out of the specified range or the length of the message was 4193 incorrect. This alert is used for errors where the message does 4194 not conform to the formal protocol syntax. This alert should 4195 never be observed in communication between proper implementations, 4196 except when messages were corrupted in the network. 4198 decrypt_error A handshake (not record-layer) cryptographic operation 4199 failed, including being unable to correctly verify a signature or 4200 validate a Finished message or a PSK binder. 4202 protocol_version The protocol version the peer has attempted to 4203 negotiate is recognized but not supported. (see Appendix D) 4205 insufficient_security Returned instead of "handshake_failure" when a 4206 negotiation has failed specifically because the server requires 4207 parameters more secure than those supported by the client. 4209 internal_error An internal error unrelated to the peer or the 4210 correctness of the protocol (such as a memory allocation failure) 4211 makes it impossible to continue. 4213 inappropriate_fallback Sent by a server in response to an invalid 4214 connection retry attempt from a client (see [RFC7507]). 4216 missing_extension Sent by endpoints that receive a handshake message 4217 not containing an extension that is mandatory to send for the 4218 offered TLS version or other negotiated parameters. 4220 unsupported_extension Sent by endpoints receiving any handshake 4221 message containing an extension known to be prohibited for 4222 inclusion in the given handshake message, or including any 4223 extensions in a ServerHello or Certificate not first offered in 4224 the corresponding ClientHello. 4226 unrecognized_name Sent by servers when no server exists identified 4227 by the name provided by the client via the "server_name" extension 4228 (see [RFC6066]). 4230 bad_certificate_status_response Sent by clients when an invalid or 4231 unacceptable OCSP response is provided by the server via the 4232 "status_request" extension (see [RFC6066]). 4234 unknown_psk_identity Sent by servers when PSK key establishment is 4235 desired but no acceptable PSK identity is provided by the client. 4236 Sending this alert is OPTIONAL; servers MAY instead choose to send 4237 a "decrypt_error" alert to merely indicate an invalid PSK 4238 identity. 4240 certificate_required Sent by servers when a client certificate is 4241 desired but none was provided by the client. 4243 no_application_protocol Sent by servers when a client 4244 "application_layer_protocol_negotiation" extension advertises only 4245 protocols that the server does not support (see [RFC7301]). 4247 New Alert values are assigned by IANA as described in Section 11. 4249 7. Cryptographic Computations 4251 The TLS handshake establishes one or more input secrets which are 4252 combined to create the actual working keying material, as detailed 4253 below. The key derivation process incorporates both the input 4254 secrets and the handshake transcript. Note that because the 4255 handshake transcript includes the random values from the Hello 4256 messages, any given handshake will have different traffic secrets, 4257 even if the same input secrets are used, as is the case when the same 4258 PSK is used for multiple connections. 4260 7.1. Key Schedule 4262 The key derivation process makes use of the HKDF-Extract and HKDF- 4263 Expand functions as defined for HKDF [RFC5869], as well as the 4264 functions defined below: 4266 HKDF-Expand-Label(Secret, Label, Context, Length) = 4267 HKDF-Expand(Secret, HkdfLabel, Length) 4269 Where HkdfLabel is specified as: 4271 struct { 4272 uint16 length = Length; 4273 opaque label<7..255> = "tls13 " + Label; 4274 opaque context<0..255> = Context; 4275 } HkdfLabel; 4277 Derive-Secret(Secret, Label, Messages) = 4278 HKDF-Expand-Label(Secret, Label, 4279 Transcript-Hash(Messages), Hash.length) 4281 The Hash function used by Transcript-Hash and HKDF is the cipher 4282 suite hash algorithm. Hash.length is its output length in bytes. 4283 Messages is the concatenation of the indicated handshake messages, 4284 including the handshake message type and length fields, but not 4285 including record layer headers. Note that in some cases a zero- 4286 length Context (indicated by "") is passed to HKDF-Expand-Label. The 4287 Labels specified in this document are all ASCII strings, and do not 4288 include a trailing NUL byte. 4290 Note: with common hash functions, any label longer than 12 characters 4291 requires an additional iteration of the hash function to compute. 4292 The labels in this specification have all been chosen to fit within 4293 this limit. 4295 Keys are derived from two input secrets using the HKDF-Extract and 4296 Derive-Secret functions. The general pattern for adding a new secret 4297 is to use HKDF-Extract with the salt being the current secret state 4298 and the IKM being the new secret to be added. In this version of TLS 4299 1.3, the two input secrets are: 4301 - PSK (a pre-shared key established externally or derived from the 4302 resumption_master_secret value from a previous connection) 4304 - (EC)DHE shared secret (Section 7.4) 4306 This produces a full key derivation schedule shown in the diagram 4307 below. In this diagram, the following formatting conventions apply: 4309 - HKDF-Extract is drawn as taking the Salt argument from the top and 4310 the IKM argument from the left, with its output to the bottom and 4311 the name of the output on the right. 4313 - Derive-Secret's Secret argument is indicated by the incoming 4314 arrow. For instance, the Early Secret is the Secret for 4315 generating the client_early_traffic_secret. 4317 - "0" indicates a string of Hash-lengths bytes set to 0. 4319 0 4320 | 4321 v 4322 PSK -> HKDF-Extract = Early Secret 4323 | 4324 +-----> Derive-Secret(., 4325 | "ext binder" | 4326 | "res binder", 4327 | "") 4328 | = binder_key 4329 | 4330 +-----> Derive-Secret(., "c e traffic", 4331 | ClientHello) 4332 | = client_early_traffic_secret 4333 | 4334 +-----> Derive-Secret(., "e exp master", 4335 | ClientHello) 4336 | = early_exporter_master_secret 4337 v 4338 Derive-Secret(., "derived", "") 4339 | 4340 v 4341 (EC)DHE -> HKDF-Extract = Handshake Secret 4342 | 4343 +-----> Derive-Secret(., "c hs traffic", 4344 | ClientHello...ServerHello) 4345 | = client_handshake_traffic_secret 4346 | 4347 +-----> Derive-Secret(., "s hs traffic", 4348 | ClientHello...ServerHello) 4349 | = server_handshake_traffic_secret 4350 v 4351 Derive-Secret(., "derived", "") 4352 | 4353 v 4354 0 -> HKDF-Extract = Master Secret 4355 | 4356 +-----> Derive-Secret(., "c ap traffic", 4357 | ClientHello...server Finished) 4358 | = client_application_traffic_secret_0 4359 | 4360 +-----> Derive-Secret(., "s ap traffic", 4361 | ClientHello...server Finished) 4362 | = server_application_traffic_secret_0 4363 | 4364 +-----> Derive-Secret(., "exp master", 4365 | ClientHello...server Finished) 4366 | = exporter_master_secret 4367 | 4368 +-----> Derive-Secret(., "res master", 4369 ClientHello...client Finished) 4370 = resumption_master_secret 4372 The general pattern here is that the secrets shown down the left side 4373 of the diagram are just raw entropy without context, whereas the 4374 secrets down the right side include handshake context and therefore 4375 can be used to derive working keys without additional context. Note 4376 that the different calls to Derive-Secret may take different Messages 4377 arguments, even with the same secret. In a 0-RTT exchange, Derive- 4378 Secret is called with four distinct transcripts; in a 1-RTT-only 4379 exchange with three distinct transcripts. 4381 If a given secret is not available, then the 0-value consisting of a 4382 string of Hash.length bytes set to zeros is used. Note that this 4383 does not mean skipping rounds, so if PSK is not in use Early Secret 4384 will still be HKDF-Extract(0, 0). For the computation of the 4385 binder_secret, the label is "ext binder" for external PSKs (those 4386 provisioned outside of TLS) and "res binder" for resumption PSKs 4387 (those provisioned as the resumption master secret of a previous 4388 handshake). The different labels prevent the substitution of one 4389 type of PSK for the other. 4391 There are multiple potential Early Secret values depending on which 4392 PSK the server ultimately selects. The client will need to compute 4393 one for each potential PSK; if no PSK is selected, it will then need 4394 to compute the early secret corresponding to the zero PSK. 4396 Once all the values which are to be derived from a given secret have 4397 been computed, that secret SHOULD be erased. 4399 7.2. Updating Traffic Secrets 4401 Once the handshake is complete, it is possible for either side to 4402 update its sending traffic keys using the KeyUpdate handshake message 4403 defined in Section 4.6.3. The next generation of traffic keys is 4404 computed by generating client_/server_application_traffic_secret_N+1 4405 from client_/server_application_traffic_secret_N as described in this 4406 section then re-deriving the traffic keys as described in 4407 Section 7.3. 4409 The next-generation application_traffic_secret is computed as: 4411 application_traffic_secret_N+1 = 4412 HKDF-Expand-Label(application_traffic_secret_N, 4413 "traffic upd", "", Hash.length) 4415 Once client/server_application_traffic_secret_N+1 and its associated 4416 traffic keys have been computed, implementations SHOULD delete 4417 client_/server_application_traffic_secret_N and its associated 4418 traffic keys. 4420 7.3. Traffic Key Calculation 4422 The traffic keying material is generated from the following input 4423 values: 4425 - A secret value 4427 - A purpose value indicating the specific value being generated 4429 - The length of the key being generated 4431 The traffic keying material is generated from an input traffic secret 4432 value using: 4434 [sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length) 4435 [sender]_write_iv = HKDF-Expand-Label(Secret, "iv" , "", iv_length) 4437 [sender] denotes the sending side. The Secret value for each record 4438 type is shown in the table below. 4440 +-------------------+---------------------------------------+ 4441 | Record Type | Secret | 4442 +-------------------+---------------------------------------+ 4443 | 0-RTT Application | client_early_traffic_secret | 4444 | | | 4445 | Handshake | [sender]_handshake_traffic_secret | 4446 | | | 4447 | Application Data | [sender]_application_traffic_secret_N | 4448 +-------------------+---------------------------------------+ 4450 All the traffic keying material is recomputed whenever the underlying 4451 Secret changes (e.g., when changing from the handshake to application 4452 data keys or upon a key update). 4454 7.4. (EC)DHE Shared Secret Calculation 4456 7.4.1. Finite Field Diffie-Hellman 4458 For finite field groups, a conventional Diffie-Hellman [DH76] 4459 computation is performed. The negotiated key (Z) is converted to a 4460 byte string by encoding in big-endian and left padded with zeros up 4461 to the size of the prime. This byte string is used as the shared 4462 secret in the key schedule as specified above. 4464 Note that this construction differs from previous versions of TLS 4465 which remove leading zeros. 4467 7.4.2. Elliptic Curve Diffie-Hellman 4469 For secp256r1, secp384r1 and secp521r1, ECDH calculations (including 4470 parameter and key generation as well as the shared secret 4471 calculation) are performed according to [IEEE1363] using the ECKAS- 4472 DH1 scheme with the identity map as key derivation function (KDF), so 4473 that the shared secret is the x-coordinate of the ECDH shared secret 4474 elliptic curve point represented as an octet string. Note that this 4475 octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the 4476 Field Element to Octet String Conversion Primitive, has constant 4477 length for any given field; leading zeros found in this octet string 4478 MUST NOT be truncated. 4480 (Note that this use of the identity KDF is a technicality. The 4481 complete picture is that ECDH is employed with a non-trivial KDF 4482 because TLS does not directly use this secret for anything other than 4483 for computing other secrets.) 4485 ECDH functions are used as follows: 4487 - The public key to put into the KeyShareEntry.key_exchange 4488 structure is the result of applying the ECDH scalar multiplication 4489 function to the secret key of appropriate length (into scalar 4490 input) and the standard public basepoint (into u-coordinate point 4491 input). 4493 - The ECDH shared secret is the result of applying the ECDH scalar 4494 multiplication function to the secret key (into scalar input) and 4495 the peer's public key (into u-coordinate point input). The output 4496 is used raw, with no processing. 4498 For X25519 and X448, implementations SHOULD use the approach 4499 specified in [RFC7748] to calculate the Diffie-Hellman shared secret. 4500 Implementations MUST check whether the computed Diffie-Hellman shared 4501 secret is the all-zero value and abort if so, as described in 4502 Section 6 of [RFC7748]. If implementors use an alternative 4503 implementation of these elliptic curves, they SHOULD perform the 4504 additional checks specified in Section 7 of [RFC7748]. 4506 7.5. Exporters 4508 [RFC5705] defines keying material exporters for TLS in terms of the 4509 TLS pseudorandom function (PRF). This document replaces the PRF with 4510 HKDF, thus requiring a new construction. The exporter interface 4511 remains the same. 4513 The exporter value is computed as: 4515 TLS-Exporter(label, context_value, key_length) = 4516 HKDF-Expand-Label(Derive-Secret(Secret, label, ""), 4517 "exporter", Hash(context_value), key_length) 4519 Where Secret is either the early_exporter_master_secret or the 4520 exporter_master_secret. Implementations MUST use the 4521 exporter_master_secret unless explicitly specified by the 4522 application. The early_exporter_master_secret is defined for use in 4523 settings where an exporter is needed for 0-RTT data. A separate 4524 interface for the early exporter is RECOMMENDED; this avoids the 4525 exporter user accidentally using an early exporter when a regular one 4526 is desired or vice versa. 4528 If no context is provided, the context_value is zero-length. 4529 Consequently, providing no context computes the same value as 4530 providing an empty context. This is a change from previous versions 4531 of TLS where an empty context produced a different output to an 4532 absent context. As of this document's publication, no allocated 4533 exporter label is used both with and without a context. Future 4534 specifications MUST NOT define a use of exporters that permit both an 4535 empty context and no context with the same label. New uses of 4536 exporters SHOULD provide a context in all exporter computations, 4537 though the value could be empty. 4539 Requirements for the format of exporter labels are defined in section 4540 4 of [RFC5705]. 4542 8. 0-RTT and Anti-Replay 4544 As noted in Section 2.3 and Appendix E.5, TLS does not provide 4545 inherent replay protections for 0-RTT data. There are two potential 4546 threats to be concerned with: 4548 - Network attackers who mount a replay attack by simply duplicating 4549 a flight of 0-RTT data. 4551 - Network attackers who take advantage of client retry behavior to 4552 arrange for the server to receive multiple copies of an 4553 application message. This threat already exists to some extent 4554 because clients that value robustness respond to network errors by 4555 attempting to retry requests. However, 0-RTT adds an additional 4556 dimension for any server system which does not maintain globally 4557 consistent server state. Specifically, if a server system has 4558 multiple zones where tickets from zone A will not be accepted in 4559 zone B, then an attacker can duplicate a ClientHello and early 4560 data intended for A to both A and B. At A, the data will be 4561 accepted in 0-RTT, but at B the server will reject 0-RTT data and 4562 instead force a full handshake. If the attacker blocks the 4563 ServerHello from A, then the client will complete the handshake 4564 with B and probably retry the request, leading to duplication on 4565 the server system as a whole. 4567 The first class of attack can be prevented by sharing state to 4568 guarantee that the 0-RTT data is accepted at most once. Servers 4569 SHOULD provide that level of replay safety, by implementing one of 4570 the methods described in this section or by equivalent means. It is 4571 understood, however, that due to operational concerns not all 4572 deployments will maintain state at that level. Therefore, in normal 4573 operation, clients will not know which, if any, of these mechanisms 4574 servers actually implement and hence MUST only send early data which 4575 they deem safe to be replayed. 4577 In addition to the direct effects of replays, there is a class of 4578 attacks where even operations normally considered idempotent could be 4579 exploited by a large number of replays (timing attacks, resource 4580 limit exhaustion and others described in Appendix E.5). Those can be 4581 mitigated by ensuring that every 0-RTT payload can be replayed only a 4582 limited number of times. The server MUST ensure that any instance of 4583 it (be it a machine, a thread or any other entity within the relevant 4584 serving infrastructure) would accept 0-RTT for the same 0-RTT 4585 handshake at most once; this limits the number of replays to the 4586 number of server instances in the deployment. Such a guarantee can 4587 be accomplished by locally recording data from recently-received 4588 ClientHellos and rejecting repeats, or by any other method that 4589 provides the same or a stronger guarantee. The "at most once per 4590 server instance" guarantee is a minimum requirement; servers SHOULD 4591 limit 0-RTT replays further when feasible. 4593 The second class of attack cannot be prevented at the TLS layer and 4594 MUST be dealt with by any application. Note that any application 4595 whose clients implement any kind of retry behavior already needs to 4596 implement some sort of anti-replay defense. 4598 8.1. Single-Use Tickets 4600 The simplest form of anti-replay defense is for the server to only 4601 allow each session ticket to be used once. For instance, the server 4602 can maintain a database of all outstanding valid tickets; deleting 4603 each ticket from the database as it is used. If an unknown ticket is 4604 provided, the server would then fall back to a full handshake. 4606 If the tickets are not self-contained but rather are database keys, 4607 and the corresponding PSKs are deleted upon use, then connections 4608 established using PSKs enjoy forward secrecy. This improves security 4609 for all 0-RTT data and PSK usage when PSK is used without (EC)DHE. 4611 Because this mechanism requires sharing the session database between 4612 server nodes in environments with multiple distributed servers, it 4613 may be hard to achieve high rates of successful PSK 0-RTT connections 4614 when compared to self-encrypted tickets. Unlike session databases, 4615 session tickets can successfully do PSK-based session establishment 4616 even without consistent storage, though when 0-RTT is allowed they 4617 still require consistent storage for anti-replay of 0-RTT data, as 4618 detailed in the following section. 4620 8.2. Client Hello Recording 4622 An alternative form of anti-replay is to record a unique value 4623 derived from the ClientHello (generally either the random value or 4624 the PSK binder) and reject duplicates. Recording all ClientHellos 4625 causes state to grow without bound, but a server can instead record 4626 ClientHellos within a given time window and use the 4627 "obfuscated_ticket_age" to ensure that tickets aren't reused outside 4628 that window. 4630 In order to implement this, when a ClientHello is received, the 4631 server first verifies the PSK binder as described Section 4.2.11. It 4632 then computes the expected_arrival_time as described in the next 4633 section and rejects 0-RTT if it is outside the recording window, 4634 falling back to the 1-RTT handshake. 4636 If the expected arrival time is in the window, then the server checks 4637 to see if it has recorded a matching ClientHello. If one is found, 4638 it either aborts the handshake with an "illegal_parameter" alert or 4639 accepts the PSK but reject 0-RTT. If no matching ClientHello is 4640 found, then it accepts 0-RTT and then stores the ClientHello for as 4641 long as the expected_arrival_time is inside the window. Servers MAY 4642 also implement data stores with false positives, such as Bloom 4643 filters, in which case they MUST respond to apparent replay by 4644 rejecting 0-RTT but MUST NOT abort the handshake. 4646 The server MUST derive the storage key only from validated sections 4647 of the ClientHello. If the ClientHello contains multiple PSK 4648 identities, then an attacker can create multiple ClientHellos with 4649 different binder values for the less-preferred identity on the 4650 assumption that the server will not verify it, as recommended by 4651 Section 4.2.11. I.e., if the client sends PSKs A and B but the 4652 server prefers A, then the attacker can change the binder for B 4653 without affecting the binder for A. If the binder for B is part of 4654 the storage key, then this ClientHello will not appear as a 4655 duplicate, which will cause the ClientHello to be accepted, and may 4656 cause side effects such as replay cache pollution, although any 0-RTT 4657 data will not be decryptable because it will use different keys. If 4658 the validated binder or the ClientHello.random are used as the 4659 storage key, then this attack is not possible. 4661 Because this mechanism does not require storing all outstanding 4662 tickets, it may be easier to implement in distributed systems with 4663 high rates of resumption and 0-RTT, at the cost of potentially weaker 4664 anti-replay defense because of the difficulty of reliably storing and 4665 retrieving the received ClientHello messages. In many such systems, 4666 it is impractical to have globally consistent storage of all the 4667 received ClientHellos. In this case, the best anti-replay protection 4668 is provided by having a single storage zone be authoritative for a 4669 given ticket and refusing 0-RTT for that ticket in any other zone. 4670 This approach prevents simple replay by the attacker because only one 4671 zone will accept 0-RTT data. A weaker design is to implement 4672 separate storage for each zone but allow 0-RTT in any zone. This 4673 approach limits the number of replays to once per zone. Application 4674 message duplication of course remains possible with either design. 4676 When implementations are freshly started, they SHOULD reject 0-RTT as 4677 long as any portion of their recording window overlaps the startup 4678 time. Otherwise, they run the risk of accepting replays which were 4679 originally sent during that period. 4681 Note: If the client's clock is running much faster than the server's 4682 then a ClientHello may be received that is outside the window in the 4683 future, in which case it might be accepted for 1-RTT, causing a 4684 client retry, and then acceptable later for 0-RTT. This is another 4685 variant of the second form of attack described above. 4687 8.3. Freshness Checks 4689 Because the ClientHello indicates the time at which the client sent 4690 it, it is possible to efficiently determine whether a ClientHello was 4691 likely sent reasonably recently and only accept 0-RTT for such a 4692 ClientHello, otherwise falling back to a 1-RTT handshake. This is 4693 necessary for the ClientHello storage mechanism described in 4694 Section 8.2 because otherwise the server needs to store an unlimited 4695 number of ClientHellos and is a useful optimization for self- 4696 contained single-use tickets because it allows efficient rejection of 4697 ClientHellos which cannot be used for 0-RTT. 4699 In order to implement this mechanism, a server needs to store the 4700 time that the server generated the session ticket, offset by an 4701 estimate of the round trip time between client and server. I.e., 4703 adjusted_creation_time = creation_time + estimated_RTT 4705 This value can be encoded in the ticket, thus avoiding the need to 4706 keep state for each outstanding ticket. The server can determine the 4707 client's view of the age of the ticket by subtracting the ticket's 4708 "ticket_age_add value" from the "obfuscated_ticket_age" parameter in 4709 the client's "pre_shared_key" extension. The server can determine 4710 the "expected arrival time" of the ClientHello as: 4712 expected_arrival_time = adjusted_creation_time + clients_ticket_age 4714 When a new ClientHello is received, the expected_arrival_time is then 4715 compared against the current server wall clock time and if they 4716 differ by more than a certain amount, 0-RTT is rejected, though the 4717 1-RTT handshake can be allowed to complete. 4719 There are several potential sources of error that might cause 4720 mismatches between the expected arrival time and the measured time. 4721 Variations in client and server clock rates are likely to be minimal, 4722 though potentially the absolute times may be off by large values. 4723 Network propagation delays are the most likely causes of a mismatch 4724 in legitimate values for elapsed time. Both the NewSessionTicket and 4725 ClientHello messages might be retransmitted and therefore delayed, 4726 which might be hidden by TCP. For clients on the Internet, this 4727 implies windows on the order of ten seconds to account for errors in 4728 clocks and variations in measurements; other deployment scenarios may 4729 have different needs. Clock skew distributions are not symmetric, so 4730 the optimal tradeoff may involve an asymmetric range of permissible 4731 mismatch values. 4733 Note that freshness checking alone is not sufficient to prevent 4734 replays because it does not detect them during the error window, 4735 which, depending on bandwidth and system capacity could include 4736 billions of replays in real-world settings. In addition, this 4737 freshness checking is only done at the time the ClientHello is 4738 received, and not when later early application data records are 4739 received. After early data is accepted, records may continue to be 4740 streamed to the server over a longer time period. 4742 9. Compliance Requirements 4744 9.1. Mandatory-to-Implement Cipher Suites 4746 In the absence of an application profile standard specifying 4747 otherwise, a TLS-compliant application MUST implement the 4748 TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the 4749 TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 4750 [RFC7539] cipher suites. (see Appendix B.4) 4752 A TLS-compliant application MUST support digital signatures with 4753 rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for 4754 CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A 4755 TLS-compliant application MUST support key exchange with secp256r1 4756 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. 4758 9.2. Mandatory-to-Implement Extensions 4760 In the absence of an application profile standard specifying 4761 otherwise, a TLS-compliant application MUST implement the following 4762 TLS extensions: 4764 - Supported Versions ("supported_versions"; Section 4.2.1) 4766 - Cookie ("cookie"; Section 4.2.2) 4768 - Signature Algorithms ("signature_algorithms"; Section 4.2.3) 4770 - Signature Algorithms Certificate ("signature_algorithms_cert"; 4771 Section 4.2.3) 4773 - Negotiated Groups ("supported_groups"; Section 4.2.7) 4775 - Key Share ("key_share"; Section 4.2.8) 4777 - Server Name Indication ("server_name"; Section 3 of [RFC6066]) 4779 All implementations MUST send and use these extensions when offering 4780 applicable features: 4782 - "supported_versions" is REQUIRED for all ClientHello, ServerHello 4783 and HelloRetryRequest messages. 4785 - "signature_algorithms" is REQUIRED for certificate authentication. 4787 - "supported_groups" is REQUIRED for ClientHello messages using DHE 4788 or ECDHE key exchange. 4790 - "key_share" is REQUIRED for DHE or ECDHE key exchange. 4792 - "pre_shared_key" is REQUIRED for PSK key agreement. 4794 - "psk_key_exchange_modes" is REQUIRED for PSK key agreement. 4796 A client is considered to be attempting to negotiate using this 4797 specification if the ClientHello contains a "supported_versions" 4798 extension with 0x0304 contained in its body. Such a ClientHello 4799 message MUST meet the following requirements: 4801 - If not containing a "pre_shared_key" extension, it MUST contain 4802 both a "signature_algorithms" extension and a "supported_groups" 4803 extension. 4805 - If containing a "supported_groups" extension, it MUST also contain 4806 a "key_share" extension, and vice versa. An empty 4807 KeyShare.client_shares vector is permitted. 4809 Servers receiving a ClientHello which does not conform to these 4810 requirements MUST abort the handshake with a "missing_extension" 4811 alert. 4813 Additionally, all implementations MUST support use of the 4814 "server_name" extension with applications capable of using it. 4815 Servers MAY require clients to send a valid "server_name" extension. 4816 Servers requiring this extension SHOULD respond to a ClientHello 4817 lacking a "server_name" extension by terminating the connection with 4818 a "missing_extension" alert. 4820 9.3. Protocol Invariants 4822 This section describes invariants that TLS endpoints and middleboxes 4823 MUST follow. It also applies to earlier versions of TLS. 4825 TLS is designed to be securely and compatibly extensible. Newer 4826 clients or servers, when communicating with newer peers, should 4827 negotiate the most preferred common parameters. The TLS handshake 4828 provides downgrade protection: Middleboxes passing traffic between a 4829 newer client and newer server without terminating TLS should be 4830 unable to influence the handshake (see Appendix E.1). At the same 4831 time, deployments update at different rates, so a newer client or 4832 server MAY continue to support older parameters, which would allow it 4833 to interoperate with older endpoints. 4835 For this to work, implementations MUST correctly handle extensible 4836 fields: 4838 - A client sending a ClientHello MUST support all parameters 4839 advertised in it. Otherwise, the server may fail to interoperate 4840 by selecting one of those parameters. 4842 - A server receiving a ClientHello MUST correctly ignore all 4843 unrecognized cipher suites, extensions, and other parameters. 4844 Otherwise, it may fail to interoperate with newer clients. In TLS 4845 1.3, a client receiving a CertificateRequest or NewSessionTicket 4846 MUST also ignore all unrecognized extensions. 4848 - A middlebox which terminates a TLS connection MUST behave as a 4849 compliant TLS server (to the original client), including having a 4850 certificate which the client is willing to accept, and as a 4851 compliant TLS client (to the original server), including verifying 4852 the original server's certificate. In particular, it MUST 4853 generate its own ClientHello containing only parameters it 4854 understands, and it MUST generate a fresh ServerHello random 4855 value, rather than forwarding the endpoint's value. 4857 Note that TLS's protocol requirements and security analysis only 4858 apply to the two connections separately. Safely deploying a TLS 4859 terminator requires additional security considerations which are 4860 beyond the scope of this document. 4862 - An middlebox which forwards ClientHello parameters it does not 4863 understand MUST NOT process any messages beyond that ClientHello. 4864 It MUST forward all subsequent traffic unmodified. Otherwise, it 4865 may fail to interoperate with newer clients and servers. 4867 Forwarded ClientHellos may contain advertisements for features not 4868 supported by the middlebox, so the response may include future TLS 4869 additions the middlebox does not recognize. These additions MAY 4870 change any message beyond the ClientHello arbitrarily. In 4871 particular, the values sent in the ServerHello might change, the 4872 ServerHello format might change, and the TLSCiphertext format 4873 might change. 4875 The design of TLS 1.3 was constrained by widely-deployed non- 4876 compliant TLS middleboxes (see Appendix D.4), however it does not 4877 relax the invariants. Those middleboxes continue to be non- 4878 compliant. 4880 10. Security Considerations 4882 Security issues are discussed throughout this memo, especially in 4883 Appendix C, Appendix D, and Appendix E. 4885 11. IANA Considerations 4887 This document uses several registries that were originally created in 4888 [RFC4346]. IANA [SHALL update/has updated] these to reference this 4889 document. The registries and their allocation policies are below: 4891 - TLS Cipher Suite Registry: values with the first byte in the range 4892 0-254 (decimal) are assigned via Specification Required [RFC8126]. 4893 Values with the first byte 255 (decimal) are reserved for Private 4894 Use [RFC8126]. 4896 IANA [SHALL add/has added] the cipher suites listed in 4897 Appendix B.4 to the registry. The "Value" and "Description" 4898 columns are taken from the table. The "DTLS-OK" and "Recommended" 4899 columns are both marked as "Yes" for each new cipher suite. 4900 [[This assumes [I-D.ietf-tls-iana-registry-updates] has been 4901 applied.]] 4903 - TLS ContentType Registry: Future values are allocated via 4904 Standards Action [RFC8126]. 4906 - TLS Alert Registry: Future values are allocated via Standards 4907 Action [RFC8126]. IANA [SHALL update/has updated] this registry 4908 to include values for "missing_extension" and 4909 "certificate_required". The "DTLS-OK" column is marked as "Yes" 4910 for each new alert. 4912 - TLS HandshakeType Registry: Future values are allocated via 4913 Standards Action [RFC8126]. IANA [SHALL update/has updated] this 4914 registry to rename item 4 from "NewSessionTicket" to 4915 "new_session_ticket" and to add the 4916 "hello_retry_request_RESERVED", "encrypted_extensions", 4917 "end_of_early_data", "key_update", and "message_hash" values. The 4918 "DTLS-OK" are marked as "Yes" for each of these additions. 4920 This document also uses the TLS ExtensionType Registry originally 4921 created in [RFC4366]. IANA has updated it to reference this 4922 document. Changes to the registry follow: 4924 - IANA [SHALL update/has updated] the registration policy as 4925 follows: 4927 Values with the first byte in the range 0-254 (decimal) are 4928 assigned via Specification Required [RFC8126]. Values with the 4929 first byte 255 (decimal) are reserved for Private Use [RFC8126]. 4931 - IANA [SHALL update/has updated] this registry to include the 4932 "key_share", "pre_shared_key", "psk_key_exchange_modes", 4933 "early_data", "cookie", "supported_versions", 4934 "certificate_authorities", "oid_filters", "post_handshake_auth", 4935 and "signature_algorithms_cert", extensions with the values 4936 defined in this document and the Recommended value of "Yes". 4938 - IANA [SHALL update/has updated] this registry to include a "TLS 4939 1.3" column which lists the messages in which the extension may 4940 appear. This column [SHALL be/has been] initially populated from 4941 the table in Section 4.2 with any extension not listed there 4942 marked as "-" to indicate that it is not used by TLS 1.3. 4944 In addition, this document defines two new registries to be 4945 maintained by IANA: 4947 - TLS SignatureScheme Registry: Values with the first byte in the 4948 range 0-253 (decimal) are assigned via Specification Required 4949 [RFC8126]. Values with the first byte 254 or 255 (decimal) are 4950 reserved for Private Use [RFC8126]. Values with the first byte in 4951 the range 0-6 or with the second byte in the range 0-3 that are 4952 not currently allocated are reserved for backwards compatibility. 4953 This registry SHALL have a "Recommended" column. The registry 4954 [shall be/ has been] initially populated with the values described 4955 in Section 4.2.3. The following values SHALL be marked as 4956 "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, 4957 rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, 4958 rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and 4959 ed25519. 4961 - TLS PskKeyExchangeMode Registry: Values in the range 0-253 4962 (decimal) are assigned via Specification Required [RFC8126]. 4963 Values with the first byte 254 or 255 (decimal) are reserved for 4964 Private Use [RFC8126]. This registry SHALL have a "Recommended" 4965 column. The registry [shall be/ has been] initially populated 4966 psk_ke (0) and psk_dhe_ke (1). Both SHALL be marked as 4967 "Recommended". 4969 12. References 4971 12.1. Normative References 4973 [DH] Diffie, W. and M. Hellman, "New Directions in 4974 Cryptography", IEEE Transactions on Information Theory, 4975 V.IT-22 n.6 , June 1977. 4977 [DH76] Diffie, W. and M. Hellman, "New directions in 4978 cryptography", IEEE Transactions on Information 4979 Theory Vol. 22, pp. 644-654, DOI 10.1109/tit.1976.1055638, 4980 November 1976. 4982 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 4983 Operation: Galois/Counter Mode (GCM) and GMAC", 4984 NIST Special Publication 800-38D, November 2007. 4986 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4987 Hashing for Message Authentication", RFC 2104, 4988 DOI 10.17487/RFC2104, February 1997, . 4991 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4992 Requirement Levels", BCP 14, RFC 2119, 4993 DOI 10.17487/RFC2119, March 1997, . 4996 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 4997 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 4998 . 5000 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 5001 Housley, R., and W. Polk, "Internet X.509 Public Key 5002 Infrastructure Certificate and Certificate Revocation List 5003 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 5004 . 5006 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 5007 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 5008 March 2010, . 5010 [RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 5011 "Updates for RSAES-OAEP and RSASSA-PSS Algorithm 5012 Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010, 5013 . 5015 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 5016 Key Derivation Function (HKDF)", RFC 5869, 5017 DOI 10.17487/RFC5869, May 2010, . 5020 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 5021 Extensions: Extension Definitions", RFC 6066, 5022 DOI 10.17487/RFC6066, January 2011, . 5025 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 5026 Transport Layer Security (TLS)", RFC 6655, 5027 DOI 10.17487/RFC6655, July 2012, . 5030 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 5031 Galperin, S., and C. Adams, "X.509 Internet Public Key 5032 Infrastructure Online Certificate Status Protocol - OCSP", 5033 RFC 6960, DOI 10.17487/RFC6960, June 2013, 5034 . 5036 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 5037 Multiple Certificate Status Request Extension", RFC 6961, 5038 DOI 10.17487/RFC6961, June 2013, . 5041 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 5042 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 5043 . 5045 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 5046 Algorithm (DSA) and Elliptic Curve Digital Signature 5047 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 5048 2013, . 5050 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 5051 "Transport Layer Security (TLS) Application-Layer Protocol 5052 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 5053 July 2014, . 5055 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 5056 Suite Value (SCSV) for Preventing Protocol Downgrade 5057 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 5058 . 5060 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 5061 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 5062 . 5064 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 5065 for Security", RFC 7748, DOI 10.17487/RFC7748, January 5066 2016, . 5068 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 5069 Ephemeral Parameters for Transport Layer Security (TLS)", 5070 RFC 7919, DOI 10.17487/RFC7919, August 2016, 5071 . 5073 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 5074 "PKCS #1: RSA Cryptography Specifications Version 2.2", 5075 RFC 8017, DOI 10.17487/RFC8017, November 2016, 5076 . 5078 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 5079 Signature Algorithm (EdDSA)", RFC 8032, 5080 DOI 10.17487/RFC8032, January 2017, . 5083 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 5084 Writing an IANA Considerations Section in RFCs", BCP 26, 5085 RFC 8126, DOI 10.17487/RFC8126, June 2017, 5086 . 5088 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5089 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5090 May 2017, . 5092 [SHS] Dang, Q., "Secure Hash Standard", National Institute of 5093 Standards and Technology report, 5094 DOI 10.6028/nist.fips.180-4, July 2015. 5096 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 5097 Specification of Basic Encoding Rules (BER), Canonical 5098 Encoding Rules (CER) and Distinguished Encoding Rules 5099 (DER)", ISO/IEC 8825-1:2002, 2002. 5101 [X962] ANSI, "Public Key Cryptography For The Financial Services 5102 Industry: The Elliptic Curve Digital Signature Algorithm 5103 (ECDSA)", ANSI X9.62, 1998. 5105 12.2. Informative References 5107 [AEAD-LIMITS] 5108 Luykx, A. and K. Paterson, "Limits on Authenticated 5109 Encryption Use in TLS", 2016, 5110 . 5112 [Anon18] Anonymous, A., "Secure Channels for Multiplexed Data 5113 Streams: Analyzing the TLS 1.3 Record Layer Without 5114 Elision", In submission to CRYPTO 2018. RFC EDITOR: PLEASE 5115 UPDATE THIS REFERENCE AFTER FINAL NOTIFICATION 5116 (2018-4-29). , 2018. 5118 [BBFKZG16] 5119 Bhargavan, K., Brzuska, C., Fournet, C., Kohlweiss, M., 5120 Zanella-Beguelin, S., and M. Green, "Downgrade Resilience 5121 in Key-Exchange Protocols", Proceedings of IEEE Symposium 5122 on Security and Privacy (Oakland) 2016 , 2016. 5124 [BBK17] Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified 5125 Models and Reference Implementations for the TLS 1.3 5126 Standard Candidate", Proceedings of IEEE Symposium on 5127 Security and Privacy (Oakland) 2017 , 2017. 5129 [BDFKPPRSZZ16] 5130 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., 5131 Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy, 5132 N., Zanella-Beguelin, S., and J. Zinzindohoue, 5133 "Implementing and Proving the TLS 1.3 Record Layer", 5134 Proceedings of IEEE Symposium on Security and Privacy 5135 (Oakland) 2017 , December 2016, 5136 . 5138 [Ben17a] Benjamin, D., "Presentation before the TLS WG at IETF 5139 100", 2017, 5140 . 5143 [Ben17b] Benjamin, D., "Additional TLS 1.3 results from Chrome", 5144 2017, . 5147 [BMMT15] Badertscher, C., Matt, C., Maurer, U., and B. Tackmann, 5148 "Augmented Secure Channels and the Goal of the TLS 1.3 5149 Record Layer", ProvSec 2015 , September 2015, 5150 . 5152 [BT16] Bellare, M. and B. Tackmann, "The Multi-User Security of 5153 Authenticated Encryption: AES-GCM in TLS 1.3", Proceedings 5154 of CRYPTO 2016 , 2016, . 5156 [CCG16] Cohn-Gordon, K., Cremers, C., and L. Garratt, "On Post- 5157 Compromise Security", IEEE Computer Security Foundations 5158 Symposium , 2015. 5160 [CHECKOWAY] 5161 Checkoway, S., Shacham, H., Maskiewicz, J., Garman, C., 5162 Fried, J., Cohney, S., Green, M., Heninger, N., Weinmann, 5163 R., and E. Rescorla, "A Systematic Analysis of the Juniper 5164 Dual EC Incident", Proceedings of the 2016 ACM SIGSAC 5165 Conference on Computer and Communications Security 5166 - CCS'16, DOI 10.1145/2976749.2978395, 2016. 5168 [CHHSV17] Cremers, C., Horvat, M., Hoyland, J., van der Merwe, T., 5169 and S. Scott, "Awkward Handshake: Possible mismatch of 5170 client/server view on client authentication in post- 5171 handshake mode in Revision 18", 2017, 5172 . 5175 [CHSV16] Cremers, C., Horvat, M., Scott, S., and T. van der Merwe, 5176 "Automated Analysis and Verification of TLS 1.3: 0-RTT, 5177 Resumption and Delayed Authentication", Proceedings of 5178 IEEE Symposium on Security and Privacy (Oakland) 2016 , 5179 2016, . 5181 [CK01] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange 5182 Protocols and Their Use for Building Secure Channels", 5183 Proceedings of Eurocrypt 2001 , 2001. 5185 [CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know 5186 Why You Went to the Clinic: Risks and Realization of HTTPS 5187 Traffic Analysis", Privacy Enhancing Technologies pp. 5188 143-163, DOI 10.1007/978-3-319-08506-7_8, 2014. 5190 [DFGS15] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, 5191 "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and 5192 Pre-shared Key Handshake Protocol", Proceedings of ACM CCS 5193 2015 , 2015, . 5195 [DFGS16] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, 5196 "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and 5197 Pre-shared Key Handshake Protocol", TRON 2016 , 2016, 5198 . 5200 [DOW92] Diffie, W., van Oorschot, P., and M. Wiener, 5201 "Authentication and authenticated key exchanges", Designs, 5202 Codes and Cryptography , 1992. 5204 [DSS] National Institute of Standards and Technology, U.S. 5205 Department of Commerce, "Digital Signature Standard, 5206 version 4", NIST FIPS PUB 186-4, 2013. 5208 [ECDSA] American National Standards Institute, "Public Key 5209 Cryptography for the Financial Services Industry: The 5210 Elliptic Curve Digital Signature Algorithm (ECDSA)", 5211 ANSI ANS X9.62-2005, November 2005. 5213 [FG17] Fischlin, M. and F. Guenther, "Replay Attacks on Zero 5214 Round-Trip Time: The Case of the TLS 1.3 Handshake 5215 Candidates", Proceedings of Euro S"P 2017 , 2017, 5216 . 5218 [FGSW16] Fischlin, M., Guenther, F., Schmidt, B., and B. Warinschi, 5219 "Key Confirmation in Key Exchange: A Formal Treatment and 5220 Implications for TLS 1.3", Proceedings of IEEE Symposium 5221 on Security and Privacy (Oakland) 2016 , 2016, 5222 . 5224 [FW15] Florian Weimer, ., "Factoring RSA Keys With TLS Perfect 5225 Forward Secrecy", September 2015. 5227 [HCJ16] Husak, M., Čermak, M., Jirsik, T., and P. 5228 Čeleda, "HTTPS traffic analysis and client 5229 identification using passive SSL/TLS fingerprinting", 5230 EURASIP Journal on Information Security Vol. 2016, 5231 DOI 10.1186/s13635-016-0030-7, February 2016. 5233 [HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes, 5234 "Prying Open Pandora's Box: KCI Attacks against TLS", 5235 Proceedings of USENIX Workshop on Offensive Technologies , 5236 2015. 5238 [I-D.ietf-tls-iana-registry-updates] 5239 Salowey, J. and S. Turner, "IANA Registry Updates for TLS 5240 and DTLS", draft-ietf-tls-iana-registry-updates-04 (work 5241 in progress), February 2018. 5243 [I-D.ietf-tls-tls13-vectors] 5244 Thomson, M., "Example Handshake Traces for TLS 1.3", 5245 draft-ietf-tls-tls13-vectors-03 (work in progress), 5246 December 2017. 5248 [IEEE1363] 5249 IEEE, "Standard Specifications for Public Key 5250 Cryptography", IEEE 1363 , 2000. 5252 [JSS15] Jager, T., Schwenk, J., and J. Somorovsky, "On the 5253 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 5254 v1.5 Encryption", Proceedings of ACM CCS 2015 , 2015, 5255 . 5258 [KEYAGREEMENT] 5259 Barker, E., Chen, L., Roginsky, A., and M. Smid, 5260 "Recommendation for Pair-Wise Key Establishment Schemes 5261 Using Discrete Logarithm Cryptography", National Institute 5262 of Standards and Technology report, 5263 DOI 10.6028/nist.sp.800-56ar2, May 2013. 5265 [Kraw10] Krawczyk, H., "Cryptographic Extraction and Key 5266 Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 , 5267 2010, . 5269 [Kraw16] Krawczyk, H., "A Unilateral-to-Mutual Authentication 5270 Compiler for Key Exchange (with Applications to Client 5271 Authentication in TLS 1.3", Proceedings of ACM CCS 2016 , 5272 2016, . 5274 [KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", 5275 Proceedings of Euro S"P 2016 , 2016, 5276 . 5278 [LXZFH16] Li, X., Xu, J., Feng, D., Zhang, Z., and H. Hu, "Multiple 5279 Handshakes Security of TLS 1.3 Candidates", Proceedings of 5280 IEEE Symposium on Security and Privacy (Oakland) 2016 , 5281 2016, . 5283 [Mac17] MacCarthaigh, C., "Security Review of TLS1.3 0-RTT", 2017, 5284 . 5286 [PSK-FINISHED] 5287 Cremers, C., Horvat, M., van der Merwe, T., and S. Scott, 5288 "Revision 10: possible attack if client authentication is 5289 allowed during PSK", 2015, . 5292 [REKEY] Abdalla, M. and M. Bellare, "Increasing the Lifetime of a 5293 Key: A Comparative Analysis of the Security of Re-keying 5294 Techniques", ASIACRYPT2000 , October 2000. 5296 [Res17a] Rescorla, E., "Preliminary data on Firefox TLS 1.3 5297 Middlebox experiment", 2017, . 5300 [Res17b] Rescorla, E., "More compatibility measurement results", 5301 2017, . 5304 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 5305 Text on Security Considerations", BCP 72, RFC 3552, 5306 DOI 10.17487/RFC3552, July 2003, . 5309 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 5310 "Randomness Requirements for Security", BCP 106, RFC 4086, 5311 DOI 10.17487/RFC4086, June 2005, . 5314 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 5315 (TLS) Protocol Version 1.1", RFC 4346, 5316 DOI 10.17487/RFC4346, April 2006, . 5319 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 5320 and T. Wright, "Transport Layer Security (TLS) 5321 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 5322 . 5324 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 5325 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 5326 for Transport Layer Security (TLS)", RFC 4492, 5327 DOI 10.17487/RFC4492, May 2006, . 5330 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 5331 "Transport Layer Security (TLS) Session Resumption without 5332 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 5333 January 2008, . 5335 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 5336 (TLS) Protocol Version 1.2", RFC 5246, 5337 DOI 10.17487/RFC5246, August 2008, . 5340 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 5341 Security (DTLS) Extension to Establish Keys for the Secure 5342 Real-time Transport Protocol (SRTP)", RFC 5764, 5343 DOI 10.17487/RFC5764, May 2010, . 5346 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 5347 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 5348 . 5350 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 5351 for Transport Layer Security (TLS) Authentication", 5352 RFC 6091, DOI 10.17487/RFC6091, February 2011, 5353 . 5355 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 5356 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 5357 2011, . 5359 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 5360 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 5361 January 2012, . 5363 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 5364 Layer Security (TLS) and Datagram Transport Layer Security 5365 (DTLS) Heartbeat Extension", RFC 6520, 5366 DOI 10.17487/RFC6520, February 2012, . 5369 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 5370 Protocol (HTTP/1.1): Message Syntax and Routing", 5371 RFC 7230, DOI 10.17487/RFC7230, June 2014, 5372 . 5374 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 5375 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 5376 Transport Layer Security (TLS) and Datagram Transport 5377 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 5378 June 2014, . 5380 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 5381 DOI 10.17487/RFC7465, February 2015, . 5384 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 5385 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 5386 DOI 10.17487/RFC7568, June 2015, . 5389 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 5390 Langley, A., and M. Ray, "Transport Layer Security (TLS) 5391 Session Hash and Extended Master Secret Extension", 5392 RFC 7627, DOI 10.17487/RFC7627, September 2015, 5393 . 5395 [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello 5396 Padding Extension", RFC 7685, DOI 10.17487/RFC7685, 5397 October 2015, . 5399 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 5400 (TLS) Cached Information Extension", RFC 7924, 5401 DOI 10.17487/RFC7924, July 2016, . 5404 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 5405 Better Connectivity Using Concurrency", RFC 8305, 5406 DOI 10.17487/RFC8305, December 2017, . 5409 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 5410 Obtaining Digital Signatures and Public-Key 5411 Cryptosystems", Communications of the ACM v. 21, n. 2, pp. 5412 120-126., February 1978. 5414 [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' approach to 5415 authenticated Diffie-Hellman and its use in the IKE 5416 protocols", Proceedings of CRYPTO 2003 , 2003. 5418 [SLOTH] Bhargavan, K. and G. Leurent, "Transcript Collision 5419 Attacks: Breaking Authentication in TLS, IKE, and SSH", 5420 Network and Distributed System Security Symposium (NDSS 5421 2016) , 2016. 5423 [SSL2] Hickman, K., "The SSL Protocol", February 1995. 5425 [SSL3] Freier, A., Karlton, P., and P. Kocher, "The SSL 3.0 5426 Protocol", November 1996. 5428 [TIMING] Boneh, D. and D. Brumley, "Remote timing attacks are 5429 practical", USENIX Security Symposium, 2003. 5431 [X501] "Information Technology - Open Systems Interconnection - 5432 The Directory: Models", ITU-T X.501, 1993. 5434 12.3. URIs 5436 [1] mailto:tls@ietf.org 5438 Appendix A. State Machine 5440 This section provides a summary of the legal state transitions for 5441 the client and server handshakes. State names (in all capitals, 5442 e.g., START) have no formal meaning but are provided for ease of 5443 comprehension. Actions which are taken only in certain circumstances 5444 are indicated in []. The notation "K_{send,recv} = foo" means "set 5445 the send/recv key to the given key". 5447 A.1. Client 5449 START <----+ 5450 Send ClientHello | | Recv HelloRetryRequest 5451 [K_send = early data] | | 5452 v | 5453 / WAIT_SH ----+ 5454 | | Recv ServerHello 5455 | | K_recv = handshake 5456 Can | V 5457 send | WAIT_EE 5458 early | | Recv EncryptedExtensions 5459 data | +--------+--------+ 5460 | Using | | Using certificate 5461 | PSK | v 5462 | | WAIT_CERT_CR 5463 | | Recv | | Recv CertificateRequest 5464 | | Certificate | v 5465 | | | WAIT_CERT 5466 | | | | Recv Certificate 5467 | | v v 5468 | | WAIT_CV 5469 | | | Recv CertificateVerify 5470 | +> WAIT_FINISHED <+ 5471 | | Recv Finished 5472 \ | [Send EndOfEarlyData] 5473 | K_send = handshake 5474 | [Send Certificate [+ CertificateVerify]] 5475 Can send | Send Finished 5476 app data --> | K_send = K_recv = application 5477 after here v 5478 CONNECTED 5480 Note that with the transitions as shown above, clients may send 5481 alerts that derive from post-ServerHello messages in the clear or 5482 with the early data keys. If clients need to send such alerts, they 5483 SHOULD first rekey to the handshake keys if possible. 5485 A.2. Server 5487 START <-----+ 5488 Recv ClientHello | | Send HelloRetryRequest 5489 v | 5490 RECVD_CH ----+ 5491 | Select parameters 5492 v 5493 NEGOTIATED 5494 | Send ServerHello 5495 | K_send = handshake 5496 | Send EncryptedExtensions 5497 | [Send CertificateRequest] 5498 Can send | [Send Certificate + CertificateVerify] 5499 app data | Send Finished 5500 after --> | K_send = application 5501 here +--------+--------+ 5502 No 0-RTT | | 0-RTT 5503 | | 5504 K_recv = handshake | | K_recv = early data 5505 [Skip decrypt errors] | +------> WAIT_EOED -+ 5506 | | Recv | | Recv EndOfEarlyData 5507 | | early data | | K_recv = handshake 5508 | +------------+ | 5509 | | 5510 +> WAIT_FLIGHT2 <--------+ 5511 | 5512 +--------+--------+ 5513 No auth | | Client auth 5514 | | 5515 | v 5516 | WAIT_CERT 5517 | Recv | | Recv Certificate 5518 | empty | v 5519 | Certificate | WAIT_CV 5520 | | | Recv 5521 | v | CertificateVerify 5522 +-> WAIT_FINISHED <---+ 5523 | Recv Finished 5524 | K_recv = application 5525 v 5526 CONNECTED 5528 Appendix B. Protocol Data Structures and Constant Values 5530 This section provides the normative protocol types and constants 5531 definitions. Values listed as _RESERVED were used in previous 5532 versions of TLS and are listed here for completeness. TLS 1.3 5533 implementations MUST NOT send them but might receive them from older 5534 TLS implementations. 5536 B.1. Record Layer 5538 enum { 5539 invalid(0), 5540 change_cipher_spec(20), 5541 alert(21), 5542 handshake(22), 5543 application_data(23), 5544 (255) 5545 } ContentType; 5547 struct { 5548 ContentType type; 5549 ProtocolVersion legacy_record_version; 5550 uint16 length; 5551 opaque fragment[TLSPlaintext.length]; 5552 } TLSPlaintext; 5554 struct { 5555 opaque content[TLSPlaintext.length]; 5556 ContentType type; 5557 uint8 zeros[length_of_padding]; 5558 } TLSInnerPlaintext; 5560 struct { 5561 ContentType opaque_type = application_data; /* 23 */ 5562 ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */ 5563 uint16 length; 5564 opaque encrypted_record[TLSCiphertext.length]; 5565 } TLSCiphertext; 5567 B.2. Alert Messages 5568 enum { warning(1), fatal(2), (255) } AlertLevel; 5570 enum { 5571 close_notify(0), 5572 unexpected_message(10), 5573 bad_record_mac(20), 5574 decryption_failed_RESERVED(21), 5575 record_overflow(22), 5576 decompression_failure_RESERVED(30), 5577 handshake_failure(40), 5578 no_certificate_RESERVED(41), 5579 bad_certificate(42), 5580 unsupported_certificate(43), 5581 certificate_revoked(44), 5582 certificate_expired(45), 5583 certificate_unknown(46), 5584 illegal_parameter(47), 5585 unknown_ca(48), 5586 access_denied(49), 5587 decode_error(50), 5588 decrypt_error(51), 5589 export_restriction_RESERVED(60), 5590 protocol_version(70), 5591 insufficient_security(71), 5592 internal_error(80), 5593 inappropriate_fallback(86), 5594 user_canceled(90), 5595 no_renegotiation_RESERVED(100), 5596 missing_extension(109), 5597 unsupported_extension(110), 5598 certificate_unobtainable_RESERVED(111), 5599 unrecognized_name(112), 5600 bad_certificate_status_response(113), 5601 bad_certificate_hash_value_RESERVED(114), 5602 unknown_psk_identity(115), 5603 certificate_required(116), 5604 no_application_protocol(120), 5605 (255) 5606 } AlertDescription; 5608 struct { 5609 AlertLevel level; 5610 AlertDescription description; 5611 } Alert; 5613 B.3. Handshake Protocol 5615 enum { 5616 hello_request_RESERVED(0), 5617 client_hello(1), 5618 server_hello(2), 5619 hello_verify_request_RESERVED(3), 5620 new_session_ticket(4), 5621 end_of_early_data(5), 5622 hello_retry_request_RESERVED(6), 5623 encrypted_extensions(8), 5624 certificate(11), 5625 server_key_exchange_RESERVED(12), 5626 certificate_request(13), 5627 server_hello_done_RESERVED(14), 5628 certificate_verify(15), 5629 client_key_exchange_RESERVED(16), 5630 finished(20), 5631 key_update(24), 5632 message_hash(254), 5633 (255) 5634 } HandshakeType; 5636 struct { 5637 HandshakeType msg_type; /* handshake type */ 5638 uint24 length; /* bytes in message */ 5639 select (Handshake.msg_type) { 5640 case client_hello: ClientHello; 5641 case server_hello: ServerHello; 5642 case end_of_early_data: EndOfEarlyData; 5643 case encrypted_extensions: EncryptedExtensions; 5644 case certificate_request: CertificateRequest; 5645 case certificate: Certificate; 5646 case certificate_verify: CertificateVerify; 5647 case finished: Finished; 5648 case new_session_ticket: NewSessionTicket; 5649 case key_update: KeyUpdate; 5650 }; 5651 } Handshake; 5653 B.3.1. Key Exchange Messages 5655 uint16 ProtocolVersion; 5656 opaque Random[32]; 5658 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 5660 struct { 5661 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 5662 Random random; 5663 opaque legacy_session_id<0..32>; 5664 CipherSuite cipher_suites<2..2^16-2>; 5665 opaque legacy_compression_methods<1..2^8-1>; 5666 Extension extensions<8..2^16-1>; 5667 } ClientHello; 5669 struct { 5670 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 5671 Random random; 5672 opaque legacy_session_id_echo<0..32>; 5673 CipherSuite cipher_suite; 5674 uint8 legacy_compression_method = 0; 5675 Extension extensions<6..2^16-1>; 5676 } ServerHello; 5678 struct { 5679 ExtensionType extension_type; 5680 opaque extension_data<0..2^16-1>; 5681 } Extension; 5683 enum { 5684 server_name(0), /* RFC 6066 */ 5685 max_fragment_length(1), /* RFC 6066 */ 5686 status_request(5), /* RFC 6066 */ 5687 supported_groups(10), /* RFC 4492, 7919 */ 5688 signature_algorithms(13), /* [[this document]] */ 5689 use_srtp(14), /* RFC 5764 */ 5690 heartbeat(15), /* RFC 6520 */ 5691 application_layer_protocol_negotiation(16), /* RFC 7301 */ 5692 signed_certificate_timestamp(18), /* RFC 6962 */ 5693 client_certificate_type(19), /* RFC 7250 */ 5694 server_certificate_type(20), /* RFC 7250 */ 5695 padding(21), /* RFC 7685 */ 5696 RESERVED(40), /* Used but never assigned */ 5697 pre_shared_key(41), /* [[this document]] */ 5698 early_data(42), /* [[this document]] */ 5699 supported_versions(43), /* [[this document]] */ 5700 cookie(44), /* [[this document]] */ 5701 psk_key_exchange_modes(45), /* [[this document]] */ 5702 RESERVED(46), /* Used but never assigned */ 5703 certificate_authorities(47), /* [[this document]] */ 5704 oid_filters(48), /* [[this document]] */ 5705 post_handshake_auth(49), /* [[this document]] */ 5706 signature_algorithms_cert(50), /* [[this document]] */ 5707 key_share(51), /* [[this document]] */ 5708 (65535) 5710 } ExtensionType; 5712 struct { 5713 NamedGroup group; 5714 opaque key_exchange<1..2^16-1>; 5715 } KeyShareEntry; 5717 struct { 5718 KeyShareEntry client_shares<0..2^16-1>; 5719 } KeyShareClientHello; 5721 struct { 5722 NamedGroup selected_group; 5723 } KeyShareHelloRetryRequest; 5725 struct { 5726 KeyShareEntry server_share; 5727 } KeyShareServerHello; 5729 struct { 5730 uint8 legacy_form = 4; 5731 opaque X[coordinate_length]; 5732 opaque Y[coordinate_length]; 5733 } UncompressedPointRepresentation; 5735 enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; 5737 struct { 5738 PskKeyExchangeMode ke_modes<1..255>; 5739 } PskKeyExchangeModes; 5741 struct {} Empty; 5743 struct { 5744 select (Handshake.msg_type) { 5745 case new_session_ticket: uint32 max_early_data_size; 5746 case client_hello: Empty; 5747 case encrypted_extensions: Empty; 5748 }; 5749 } EarlyDataIndication; 5751 struct { 5752 opaque identity<1..2^16-1>; 5753 uint32 obfuscated_ticket_age; 5754 } PskIdentity; 5756 opaque PskBinderEntry<32..255>; 5757 struct { 5758 PskIdentity identities<7..2^16-1>; 5759 PskBinderEntry binders<33..2^16-1>; 5760 } OfferedPsks; 5762 struct { 5763 select (Handshake.msg_type) { 5764 case client_hello: OfferedPsks; 5765 case server_hello: uint16 selected_identity; 5766 }; 5767 } PreSharedKeyExtension; 5769 B.3.1.1. Version Extension 5771 struct { 5772 select (Handshake.msg_type) { 5773 case client_hello: 5774 ProtocolVersion versions<2..254>; 5776 case server_hello: /* and HelloRetryRequest */ 5777 ProtocolVersion selected_version; 5778 }; 5779 } SupportedVersions; 5781 B.3.1.2. Cookie Extension 5783 struct { 5784 opaque cookie<1..2^16-1>; 5785 } Cookie; 5787 B.3.1.3. Signature Algorithm Extension 5788 enum { 5789 /* RSASSA-PKCS1-v1_5 algorithms */ 5790 rsa_pkcs1_sha256(0x0401), 5791 rsa_pkcs1_sha384(0x0501), 5792 rsa_pkcs1_sha512(0x0601), 5794 /* ECDSA algorithms */ 5795 ecdsa_secp256r1_sha256(0x0403), 5796 ecdsa_secp384r1_sha384(0x0503), 5797 ecdsa_secp521r1_sha512(0x0603), 5799 /* RSASSA-PSS algorithms with public key OID rsaEncryption */ 5800 rsa_pss_rsae_sha256(0x0804), 5801 rsa_pss_rsae_sha384(0x0805), 5802 rsa_pss_rsae_sha512(0x0806), 5804 /* EdDSA algorithms */ 5805 ed25519(0x0807), 5806 ed448(0x0808), 5808 /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */ 5809 rsa_pss_pss_sha256(0x0809), 5810 rsa_pss_pss_sha384(0x080a), 5811 rsa_pss_pss_sha512(0x080b), 5813 /* Legacy algorithms */ 5814 rsa_pkcs1_sha1(0x0201), 5815 ecdsa_sha1(0x0203), 5817 /* Reserved Code Points */ 5818 obsolete_RESERVED(0x0000..0x0200), 5819 dsa_sha1_RESERVED(0x0202), 5820 obsolete_RESERVED(0x0204..0x0400), 5821 dsa_sha256_RESERVED(0x0402), 5822 obsolete_RESERVED(0x0404..0x0500), 5823 dsa_sha384_RESERVED(0x0502), 5824 obsolete_RESERVED(0x0504..0x0600), 5825 dsa_sha512_RESERVED(0x0602), 5826 obsolete_RESERVED(0x0604..0x06FF), 5827 private_use(0xFE00..0xFFFF), 5828 (0xFFFF) 5829 } SignatureScheme; 5831 struct { 5832 SignatureScheme supported_signature_algorithms<2..2^16-2>; 5833 } SignatureSchemeList; 5835 B.3.1.4. Supported Groups Extension 5837 enum { 5838 unallocated_RESERVED(0x0000), 5840 /* Elliptic Curve Groups (ECDHE) */ 5841 obsolete_RESERVED(0x0001..0x0016), 5842 secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), 5843 obsolete_RESERVED(0x001A..0x001C), 5844 x25519(0x001D), x448(0x001E), 5846 /* Finite Field Groups (DHE) */ 5847 ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), 5848 ffdhe6144(0x0103), ffdhe8192(0x0104), 5850 /* Reserved Code Points */ 5851 ffdhe_private_use(0x01FC..0x01FF), 5852 ecdhe_private_use(0xFE00..0xFEFF), 5853 obsolete_RESERVED(0xFF01..0xFF02), 5854 (0xFFFF) 5855 } NamedGroup; 5857 struct { 5858 NamedGroup named_group_list<2..2^16-1>; 5859 } NamedGroupList; 5861 Values within "obsolete_RESERVED" ranges are used in previous 5862 versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 5863 implementations. The obsolete curves have various known/theoretical 5864 weaknesses or have had very little usage, in some cases only due to 5865 unintentional server configuration issues. They are no longer 5866 considered appropriate for general use and should be assumed to be 5867 potentially unsafe. The set of curves specified here is sufficient 5868 for interoperability with all currently deployed and properly 5869 configured TLS implementations. 5871 B.3.2. Server Parameters Messages 5872 opaque DistinguishedName<1..2^16-1>; 5874 struct { 5875 DistinguishedName authorities<3..2^16-1>; 5876 } CertificateAuthoritiesExtension; 5878 struct { 5879 opaque certificate_extension_oid<1..2^8-1>; 5880 opaque certificate_extension_values<0..2^16-1>; 5881 } OIDFilter; 5883 struct { 5884 OIDFilter filters<0..2^16-1>; 5885 } OIDFilterExtension; 5887 struct {} PostHandshakeAuth; 5889 struct { 5890 Extension extensions<0..2^16-1>; 5891 } EncryptedExtensions; 5893 struct { 5894 opaque certificate_request_context<0..2^8-1>; 5895 Extension extensions<2..2^16-1>; 5896 } CertificateRequest; 5898 B.3.3. Authentication Messages 5899 /* Managed by IANA */ 5900 enum { 5901 X509(0), 5902 OpenPGP_RESERVED(1), 5903 RawPublicKey(2), 5904 (255) 5905 } CertificateType; 5907 struct { 5908 select (certificate_type) { 5909 case RawPublicKey: 5910 /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ 5911 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 5913 case X509: 5914 opaque cert_data<1..2^24-1>; 5915 }; 5916 Extension extensions<0..2^16-1>; 5917 } CertificateEntry; 5919 struct { 5920 opaque certificate_request_context<0..2^8-1>; 5921 CertificateEntry certificate_list<0..2^24-1>; 5922 } Certificate; 5924 struct { 5925 SignatureScheme algorithm; 5926 opaque signature<0..2^16-1>; 5927 } CertificateVerify; 5929 struct { 5930 opaque verify_data[Hash.length]; 5931 } Finished; 5933 B.3.4. Ticket Establishment 5935 struct { 5936 uint32 ticket_lifetime; 5937 uint32 ticket_age_add; 5938 opaque ticket_nonce<0..255>; 5939 opaque ticket<1..2^16-1>; 5940 Extension extensions<0..2^16-2>; 5941 } NewSessionTicket; 5943 B.3.5. Updating Keys 5945 struct {} EndOfEarlyData; 5947 enum { 5948 update_not_requested(0), update_requested(1), (255) 5949 } KeyUpdateRequest; 5951 struct { 5952 KeyUpdateRequest request_update; 5953 } KeyUpdate; 5955 B.4. Cipher Suites 5957 A symmetric cipher suite defines the pair of the AEAD algorithm and 5958 hash algorithm to be used with HKDF. Cipher suite names follow the 5959 naming convention: 5961 CipherSuite TLS_AEAD_HASH = VALUE; 5963 +-----------+------------------------------------------------+ 5964 | Component | Contents | 5965 +-----------+------------------------------------------------+ 5966 | TLS | The string "TLS" | 5967 | | | 5968 | AEAD | The AEAD algorithm used for record protection | 5969 | | | 5970 | HASH | The hash algorithm used with HKDF | 5971 | | | 5972 | VALUE | The two byte ID assigned for this cipher suite | 5973 +-----------+------------------------------------------------+ 5975 This specification defines the following cipher suites for use with 5976 TLS 1.3. 5978 +------------------------------+-------------+ 5979 | Description | Value | 5980 +------------------------------+-------------+ 5981 | TLS_AES_128_GCM_SHA256 | {0x13,0x01} | 5982 | | | 5983 | TLS_AES_256_GCM_SHA384 | {0x13,0x02} | 5984 | | | 5985 | TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} | 5986 | | | 5987 | TLS_AES_128_CCM_SHA256 | {0x13,0x04} | 5988 | | | 5989 | TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} | 5990 +------------------------------+-------------+ 5992 The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, 5993 and AEAD_AES_128_CCM are defined in [RFC5116]. 5994 AEAD_CHACHA20_POLY1305 is defined in [RFC7539]. AEAD_AES_128_CCM_8 5995 is defined in [RFC6655]. The corresponding hash algorithms are 5996 defined in [SHS]. 5998 Although TLS 1.3 uses the same cipher suite space as previous 5999 versions of TLS, TLS 1.3 cipher suites are defined differently, only 6000 specifying the symmetric ciphers, and cannot be used for TLS 1.2. 6001 Similarly, TLS 1.2 and lower cipher suites cannot be used with TLS 6002 1.3. 6004 New cipher suite values are assigned by IANA as described in 6005 Section 11. 6007 Appendix C. Implementation Notes 6009 The TLS protocol cannot prevent many common security mistakes. This 6010 section provides several recommendations to assist implementors. 6011 [I-D.ietf-tls-tls13-vectors] provides test vectors for TLS 1.3 6012 handshakes. 6014 C.1. Random Number Generation and Seeding 6016 TLS requires a cryptographically secure pseudorandom number generator 6017 (CSPRNG). In most cases, the operating system provides an 6018 appropriate facility such as /dev/urandom, which should be used 6019 absent other (performance) concerns. It is RECOMMENDED to use an 6020 existing CSPRNG implementation in preference to crafting a new one. 6021 Many adequate cryptographic libraries are already available under 6022 favorable license terms. Should those prove unsatisfactory, 6023 [RFC4086] provides guidance on the generation of random values. 6025 TLS uses random values both in public protocol fields such as the 6026 public Random values in the ClientHello and ServerHello and to 6027 generate keying material. With a properly functioning CSPRNG, this 6028 does not present a security problem as it is not feasible to 6029 determine the CSPRNG state from its output. However, with a broken 6030 CSPRNG, it may be possible for an attacker to use the public output 6031 to determine the CSPRNG internal state and thereby predict the keying 6032 material, as documented in [CHECKOWAY]. Implementations can provide 6033 extra security against this form of attack by using separate CSPRNGs 6034 to generate public and private values. 6036 C.2. Certificates and Authentication 6038 Implementations are responsible for verifying the integrity of 6039 certificates and should generally support certificate revocation 6040 messages. Absent a specific indication from an application profile, 6041 Certificates should always be verified to ensure proper signing by a 6042 trusted Certificate Authority (CA). The selection and addition of 6043 trust anchors should be done very carefully. Users should be able to 6044 view information about the certificate and trust anchor. 6045 Applications SHOULD also enforce minimum and maximum key sizes. For 6046 example, certification paths containing keys or signatures weaker 6047 than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure 6048 applications. 6050 C.3. Implementation Pitfalls 6052 Implementation experience has shown that certain parts of earlier TLS 6053 specifications are not easy to understand and have been a source of 6054 interoperability and security problems. Many of these areas have 6055 been clarified in this document but this appendix contains a short 6056 list of the most important things that require special attention from 6057 implementors. 6059 TLS protocol issues: 6061 - Do you correctly handle handshake messages that are fragmented to 6062 multiple TLS records (see Section 5.1)? Including corner cases 6063 like a ClientHello that is split to several small fragments? Do 6064 you fragment handshake messages that exceed the maximum fragment 6065 size? In particular, the Certificate and CertificateRequest 6066 handshake messages can be large enough to require fragmentation. 6068 - Do you ignore the TLS record layer version number in all 6069 unencrypted TLS records? (see Appendix D) 6071 - Have you ensured that all support for SSL, RC4, EXPORT ciphers, 6072 and MD5 (via the "signature_algorithms" extension) is completely 6073 removed from all possible configurations that support TLS 1.3 or 6074 later, and that attempts to use these obsolete capabilities fail 6075 correctly? (see Appendix D) 6077 - Do you handle TLS extensions in ClientHello correctly, including 6078 unknown extensions? 6080 - When the server has requested a client certificate, but no 6081 suitable certificate is available, do you correctly send an empty 6082 Certificate message, instead of omitting the whole message (see 6083 Section 4.4.2.3)? 6085 - When processing the plaintext fragment produced by AEAD-Decrypt 6086 and scanning from the end for the ContentType, do you avoid 6087 scanning past the start of the cleartext in the event that the 6088 peer has sent a malformed plaintext of all-zeros? 6090 - Do you properly ignore unrecognized cipher suites (Section 4.1.2), 6091 hello extensions (Section 4.2), named groups (Section 4.2.7), key 6092 shares (Section 4.2.8), supported versions (Section 4.2.1), and 6093 signature algorithms (Section 4.2.3) in the ClientHello? 6095 - As a server, do you send a HelloRetryRequest to clients which 6096 support a compatible (EC)DHE group but do not predict it in the 6097 "key_share" extension? As a client, do you correctly handle a 6098 HelloRetryRequest from the server? 6100 Cryptographic details: 6102 - What countermeasures do you use to prevent timing attacks 6103 [TIMING]? 6105 - When using Diffie-Hellman key exchange, do you correctly preserve 6106 leading zero bytes in the negotiated key (see Section 7.4.1)? 6108 - Does your TLS client check that the Diffie-Hellman parameters sent 6109 by the server are acceptable, (see Section 4.2.8.1)? 6111 - Do you use a strong and, most importantly, properly seeded random 6112 number generator (see Appendix C.1) when generating Diffie-Hellman 6113 private values, the ECDSA "k" parameter, and other security- 6114 critical values? It is RECOMMENDED that implementations implement 6115 "deterministic ECDSA" as specified in [RFC6979]. 6117 - Do you zero-pad Diffie-Hellman public key values to the group size 6118 (see Section 4.2.8.1)? 6120 - Do you verify signatures after making them to protect against RSA- 6121 CRT key leaks? [FW15] 6123 C.4. Client Tracking Prevention 6125 Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of 6126 a ticket allows passive observers to correlate different connections. 6127 Servers that issue tickets SHOULD offer at least as many tickets as 6128 the number of connections that a client might use; for example, a web 6129 browser using HTTP/1.1 [RFC7230] might open six connections to a 6130 server. Servers SHOULD issue new tickets with every connection. 6131 This ensures that clients are always able to use a new ticket when 6132 creating a new connection. 6134 C.5. Unauthenticated Operation 6136 Previous versions of TLS offered explicitly unauthenticated cipher 6137 suites based on anonymous Diffie-Hellman. These modes have been 6138 deprecated in TLS 1.3. However, it is still possible to negotiate 6139 parameters that do not provide verifiable server authentication by 6140 several methods, including: 6142 - Raw public keys [RFC7250]. 6144 - Using a public key contained in a certificate but without 6145 validation of the certificate chain or any of its contents. 6147 Either technique used alone is vulnerable to man-in-the-middle 6148 attacks and therefore unsafe for general use. However, it is also 6149 possible to bind such connections to an external authentication 6150 mechanism via out-of-band validation of the server's public key, 6151 trust on first use, or a mechanism such as channel bindings (though 6152 the channel bindings described in [RFC5929] are not defined for TLS 6153 1.3). If no such mechanism is used, then the connection has no 6154 protection against active man-in-the-middle attack; applications MUST 6155 NOT use TLS in such a way absent explicit configuration or a specific 6156 application profile. 6158 Appendix D. Backward Compatibility 6160 The TLS protocol provides a built-in mechanism for version 6161 negotiation between endpoints potentially supporting different 6162 versions of TLS. 6164 TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can 6165 also handle clients trying to use future versions of TLS as long as 6166 the ClientHello format remains compatible and there is at least one 6167 protocol version supported by both the client and the server. 6169 Prior versions of TLS used the record layer version number 6170 (TLSPlaintext.legacy_record_version and 6171 TLSCiphertext.legacy_record_version) for various purposes. As of TLS 6172 1.3, this field is deprecated. The value of 6173 TLSPlaintext.legacy_record_version MUST be ignored by all 6174 implementations. The value of TLSCiphertext.legacy_record_version is 6175 included in the additional data for deprotection but MAY otherwise be 6176 ignored or MAY be validated to match the fixed constant value. 6177 Version negotiation is performed using only the handshake versions 6178 (ClientHello.legacy_version, ServerHello.legacy_version, as well as 6179 the ClientHello, HelloRetryRequest and ServerHello 6180 "supported_versions" extensions). In order to maximize 6181 interoperability with older endpoints, implementations that negotiate 6182 the use of TLS 1.0-1.2 SHOULD set the record layer version number to 6183 the negotiated version for the ServerHello and all records 6184 thereafter. 6186 For maximum compatibility with previously non-standard behavior and 6187 misconfigured deployments, all implementations SHOULD support 6188 validation of certification paths based on the expectations in this 6189 document, even when handling prior TLS versions' handshakes. (see 6190 Section 4.4.2.2) 6192 TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627] 6193 extension which digested large parts of the handshake transcript into 6194 the master secret. Because TLS 1.3 always hashes in the transcript 6195 up to the server CertificateVerify, implementations which support 6196 both TLS 1.3 and earlier versions SHOULD indicate the use of the 6197 Extended Master Secret extension in their APIs whenever TLS 1.3 is 6198 used. 6200 D.1. Negotiating with an older server 6202 A TLS 1.3 client who wishes to negotiate with servers that do not 6203 support TLS 1.3 will send a normal TLS 1.3 ClientHello containing 6204 0x0303 (TLS 1.2) in ClientHello.legacy_version but with the correct 6205 version(s) in the "supported_versions" extension. If the server does 6206 not support TLS 1.3 it will respond with a ServerHello containing an 6207 older version number. If the client agrees to use this version, the 6208 negotiation will proceed as appropriate for the negotiated protocol. 6209 A client using a ticket for resumption SHOULD initiate the connection 6210 using the version that was previously negotiated. 6212 Note that 0-RTT data is not compatible with older servers and SHOULD 6213 NOT be sent absent knowledge that the server supports TLS 1.3. See 6214 Appendix D.3. 6216 If the version chosen by the server is not supported by the client 6217 (or not acceptable), the client MUST abort the handshake with a 6218 "protocol_version" alert. 6220 Some legacy server implementations are known to not implement the TLS 6221 specification properly and might abort connections upon encountering 6222 TLS extensions or versions which they are not aware of. 6223 Interoperability with buggy servers is a complex topic beyond the 6224 scope of this document. Multiple connection attempts may be required 6225 in order to negotiate a backwards compatible connection; however, 6226 this practice is vulnerable to downgrade attacks and is NOT 6227 RECOMMENDED. 6229 D.2. Negotiating with an older client 6231 A TLS server can also receive a ClientHello indicating a version 6232 number smaller than its highest supported version. If the 6233 "supported_versions" extension is present, the server MUST negotiate 6234 using that extension as described in Section 4.2.1. If the 6235 "supported_versions" extension is not present, the server MUST 6236 negotiate the minimum of ClientHello.legacy_version and TLS 1.2. For 6237 example, if the server supports TLS 1.0, 1.1, and 1.2, and 6238 legacy_version is TLS 1.0, the server will proceed with a TLS 1.0 6239 ServerHello. If the "supported_versions" extension is absent and the 6240 server only supports versions greater than 6241 ClientHello.legacy_version, the server MUST abort the handshake with 6242 a "protocol_version" alert. 6244 Note that earlier versions of TLS did not clearly specify the record 6245 layer version number value in all cases 6246 (TLSPlaintext.legacy_record_version). Servers will receive various 6247 TLS 1.x versions in this field, but its value MUST always be ignored. 6249 D.3. 0-RTT backwards compatibility 6251 0-RTT data is not compatible with older servers. An older server 6252 will respond to the ClientHello with an older ServerHello, but it 6253 will not correctly skip the 0-RTT data and will fail to complete the 6254 handshake. This can cause issues when a client attempts to use 6255 0-RTT, particularly against multi-server deployments. For example, a 6256 deployment could deploy TLS 1.3 gradually with some servers 6257 implementing TLS 1.3 and some implementing TLS 1.2, or a TLS 1.3 6258 deployment could be downgraded to TLS 1.2. 6260 A client that attempts to send 0-RTT data MUST fail a connection if 6261 it receives a ServerHello with TLS 1.2 or older. A client that 6262 attempts to repair this error SHOULD NOT send a TLS 1.2 ClientHello, 6263 but instead send a TLS 1.3 ClientHello without 0-RTT data. 6265 To avoid this error condition, multi-server deployments SHOULD ensure 6266 a uniform and stable deployment of TLS 1.3 without 0-RTT prior to 6267 enabling 0-RTT. 6269 D.4. Middlebox Compatibility Mode 6271 Field measurements [Ben17a], [Ben17b], [Res17a], [Res17b] have found 6272 that a significant number of middleboxes misbehave when a TLS client/ 6273 server pair negotiates TLS 1.3. Implementations can increase the 6274 chance of making connections through those middleboxes by making the 6275 TLS 1.3 handshake look more like a TLS 1.2 handshake: 6277 - The client always provides a non-empty session ID in the 6278 ClientHello, as described in the legacy_session_id section of 6279 Section 4.1.2. 6281 - If not offering early data, the client sends a dummy 6282 change_cipher_spec record (see the third paragraph of Section 5.1) 6283 immediately before its second flight. This may either be before 6284 its second ClientHello or before its encrypted handshake flight. 6285 If offering early data, the record is placed immediately after the 6286 first ClientHello. 6288 - The server sends a dummy change_cipher_spec record immediately 6289 after its first handshake message. This may either be after a 6290 ServerHello or a HelloRetryRequest. 6292 When put together, these changes make the TLS 1.3 handshake resemble 6293 TLS 1.2 session resumption, which improves the chance of successfully 6294 connecting through middleboxes. This "compatibility mode" is 6295 partially negotiated: The client can opt to provide a session ID or 6296 not and the server has to echo it. Either side can send 6297 change_cipher_spec at any time during the handshake, as they must be 6298 ignored by the peer, but if the client sends a non-empty session ID, 6299 the server MUST send the change_cipher_spec as described in this 6300 section. 6302 D.5. Backwards Compatibility Security Restrictions 6304 Implementations negotiating use of older versions of TLS SHOULD 6305 prefer forward secret and AEAD cipher suites, when available. 6307 The security of RC4 cipher suites is considered insufficient for the 6308 reasons cited in [RFC7465]. Implementations MUST NOT offer or 6309 negotiate RC4 cipher suites for any version of TLS for any reason. 6311 Old versions of TLS permitted the use of very low strength ciphers. 6312 Ciphers with a strength less than 112 bits MUST NOT be offered or 6313 negotiated for any version of TLS for any reason. 6315 The security of SSL 3.0 [SSL3] is considered insufficient for the 6316 reasons enumerated in [RFC7568], and it MUST NOT be negotiated for 6317 any reason. 6319 The security of SSL 2.0 [SSL2] is considered insufficient for the 6320 reasons enumerated in [RFC6176], and it MUST NOT be negotiated for 6321 any reason. 6323 Implementations MUST NOT send an SSL version 2.0 compatible CLIENT- 6324 HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an 6325 SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT 6326 RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in 6327 order to negotiate older versions of TLS. 6329 Implementations MUST NOT send a ClientHello.legacy_version or 6330 ServerHello.legacy_version set to 0x0300 or less. Any endpoint 6331 receiving a Hello message with ClientHello.legacy_version or 6332 ServerHello.legacy_version set to 0x0300 MUST abort the handshake 6333 with a "protocol_version" alert. 6335 Implementations MUST NOT send any records with a version less than 6336 0x0300. Implementations SHOULD NOT accept any records with a version 6337 less than 0x0300 (but may inadvertently do so if the record version 6338 number is ignored completely). 6340 Implementations MUST NOT use the Truncated HMAC extension, defined in 6341 Section 7 of [RFC6066], as it is not applicable to AEAD algorithms 6342 and has been shown to be insecure in some scenarios. 6344 Appendix E. Overview of Security Properties 6346 A complete security analysis of TLS is outside the scope of this 6347 document. In this section, we provide an informal description the 6348 desired properties as well as references to more detailed work in the 6349 research literature which provides more formal definitions. 6351 We cover properties of the handshake separately from those of the 6352 record layer. 6354 E.1. Handshake 6356 The TLS handshake is an Authenticated Key Exchange (AKE) protocol 6357 which is intended to provide both one-way authenticated (server-only) 6358 and mutually authenticated (client and server) functionality. At the 6359 completion of the handshake, each side outputs its view of the 6360 following values: 6362 - A set of "session keys" (the various secrets derived from the 6363 master secret) from which can be derived a set of working keys. 6365 - A set of cryptographic parameters (algorithms, etc.) 6367 - The identities of the communicating parties. 6369 We assume the attacker to be an active network attacker, which means 6370 it has complete control over the network used to communicate between 6371 the parties [RFC3552]. Even under these conditions, the handshake 6372 should provide the properties listed below. Note that these 6373 properties are not necessarily independent, but reflect the protocol 6374 consumers' needs. 6376 Establishing the same session keys. The handshake needs to output 6377 the same set of session keys on both sides of the handshake, 6378 provided that it completes successfully on each endpoint (See 6379 [CK01]; defn 1, part 1). 6381 Secrecy of the session keys. The shared session keys should be known 6382 only to the communicating parties and not to the attacker (See 6383 [CK01]; defn 1, part 2). Note that in a unilaterally 6384 authenticated connection, the attacker can establish its own 6385 session keys with the server, but those session keys are distinct 6386 from those established by the client. 6388 Peer Authentication. The client's view of the peer identity should 6389 reflect the server's identity. If the client is authenticated, 6390 the server's view of the peer identity should match the client's 6391 identity. 6393 Uniqueness of the session keys: Any two distinct handshakes should 6394 produce distinct, unrelated session keys. Individual session keys 6395 produced by a handshake should also be distinct and independent. 6397 Downgrade protection. The cryptographic parameters should be the 6398 same on both sides and should be the same as if the peers had been 6399 communicating in the absence of an attack (See [BBFKZG16]; defns 8 6400 and 9}). 6402 Forward secret with respect to long-term keys If the long-term 6403 keying material (in this case the signature keys in certificate- 6404 based authentication modes or the external/resumption PSK in PSK 6405 with (EC)DHE modes) is compromised after the handshake is 6406 complete, this does not compromise the security of the session key 6407 (See [DOW92]), as long as the session key itself has been erased. 6408 The forward secrecy property is not satisfied when PSK is used in 6409 the "psk_ke" PskKeyExchangeMode. 6411 Key Compromise Impersonation (KCI) resistance In a mutually- 6412 authenticated connection with certificates, compromising the long- 6413 term secret of one actor should not break that actor's 6414 authentication of their peer in the given connection (see 6415 [HGFS15]). For example, if a client's signature key is 6416 compromised, it should not be possible to impersonate arbitrary 6417 servers to that client in subsequent handshakes. 6419 Protection of endpoint identities. The server's identity 6420 (certificate) should be protected against passive attackers. The 6421 client's identity should be protected against both passive and 6422 active attackers. 6424 Informally, the signature-based modes of TLS 1.3 provide for the 6425 establishment of a unique, secret, shared key established by an 6426 (EC)DHE key exchange and authenticated by the server's signature over 6427 the handshake transcript, as well as tied to the server's identity by 6428 a MAC. If the client is authenticated by a certificate, it also 6429 signs over the handshake transcript and provides a MAC tied to both 6430 identities. [SIGMA] describes the design and analysis of this type 6431 of key exchange protocol. If fresh (EC)DHE keys are used for each 6432 connection, then the output keys are forward secret. 6434 The external PSK and resumption PSK bootstrap from a long-term shared 6435 secret into a unique per-connection set of short-term session keys. 6436 This secret may have been established in a previous handshake. If 6437 PSK with (EC)DHE key establishment is used, these session keys will 6438 also be forward secret. The resumption PSK has been designed so that 6439 the resumption master secret computed by connection N and needed to 6440 form connection N+1 is separate from the traffic keys used by 6441 connection N, thus providing forward secrecy between the connections. 6442 In addition, if multiple tickets are established on the same 6443 connection, they are associated with different keys, so compromise of 6444 the PSK associated with one ticket does not lead to the compromise of 6445 connections established with PSKs associated with other tickets. 6446 This property is most interesting if tickets are stored in a database 6447 (and so can be deleted) rather than if they are self-encrypted. 6449 The PSK binder value forms a binding between a PSK and the current 6450 handshake, as well as between the session where the PSK was 6451 established and the current session. This binding transitively 6452 includes the original handshake transcript, because that transcript 6453 is digested into the values which produce the Resumption Master 6454 Secret. This requires that both the KDF used to produce the 6455 resumption master secret and the MAC used to compute the binder be 6456 collision resistant. See Appendix E.1.1 for more on this. Note: The 6457 binder does not cover the binder values from other PSKs, though they 6458 are included in the Finished MAC. 6460 Note: TLS does not currently permit the server to send a 6461 certificate_request message in non-certificate-based handshakes 6462 (e.g., PSK). If this restriction were to be relaxed in future, the 6463 client's signature would not cover the server's certificate directly. 6464 However, if the PSK was established through a NewSessionTicket, the 6465 client's signature would transitively cover the server's certificate 6466 through the PSK binder. [PSK-FINISHED] describes a concrete attack 6467 on constructions that do not bind to the server's certificate (see 6468 also [Kraw16]). It is unsafe to use certificate-based client 6469 authentication when the client might potentially share the same PSK/ 6470 key-id pair with two different endpoints. Implementations MUST NOT 6471 combine external PSKs with certificate-based authentication of either 6472 the client or the server unless negotiated by some extension. 6474 If an exporter is used, then it produces values which are unique and 6475 secret (because they are generated from a unique session key). 6476 Exporters computed with different labels and contexts are 6477 computationally independent, so it is not feasible to compute one 6478 from another or the session secret from the exported value. Note: 6479 exporters can produce arbitrary-length values. If exporters are to 6480 be used as channel bindings, the exported value MUST be large enough 6481 to provide collision resistance. The exporters provided in TLS 1.3 6482 are derived from the same handshake contexts as the early traffic 6483 keys and the application traffic keys respectively, and thus have 6484 similar security properties. Note that they do not include the 6485 client's certificate; future applications which wish to bind to the 6486 client's certificate may need to define a new exporter that includes 6487 the full handshake transcript. 6489 For all handshake modes, the Finished MAC (and where present, the 6490 signature), prevents downgrade attacks. In addition, the use of 6491 certain bytes in the random nonces as described in Section 4.1.3 6492 allows the detection of downgrade to previous TLS versions. See 6493 [BBFKZG16] for more detail on TLS 1.3 and downgrade. 6495 As soon as the client and the server have exchanged enough 6496 information to establish shared keys, the remainder of the handshake 6497 is encrypted, thus providing protection against passive attackers, 6498 even if the computed shared key is not authenticated. Because the 6499 server authenticates before the client, the client can ensure that if 6500 it authenticates to the server, it only reveals its identity to an 6501 authenticated server. Note that implementations must use the 6502 provided record padding mechanism during the handshake to avoid 6503 leaking information about the identities due to length. The client's 6504 proposed PSK identities are not encrypted, nor is the one that the 6505 server selects. 6507 E.1.1. Key Derivation and HKDF 6509 Key derivation in TLS 1.3 uses the HKDF function defined in [RFC5869] 6510 and its two components, HKDF-Extract and HKDF-Expand. The full 6511 rationale for the HKDF construction can be found in [Kraw10] and the 6512 rationale for the way it is used in TLS 1.3 in [KW16]. Throughout 6513 this document, each application of HKDF-Extract is followed by one or 6514 more invocations of HKDF-Expand. This ordering should always be 6515 followed (including in future revisions of this document), in 6516 particular, one SHOULD NOT use an output of HKDF-Extract as an input 6517 to another application of HKDF-Extract without an HKDF-Expand in 6518 between. Consecutive applications of HKDF-Expand are allowed as long 6519 as these are differentiated via the key and/or the labels. 6521 Note that HKDF-Expand implements a pseudorandom function (PRF) with 6522 both inputs and outputs of variable length. In some of the uses of 6523 HKDF in this document (e.g., for generating exporters and the 6524 resumption_master_secret), it is necessary that the application of 6525 HKDF-Expand be collision-resistant, namely, it should be infeasible 6526 to find two different inputs to HKDF-Expand that output the same 6527 value. This requires the underlying hash function to be collision 6528 resistant and the output length from HKDF-Expand to be of size at 6529 least 256 bits (or as much as needed for the hash function to prevent 6530 finding collisions). 6532 E.1.2. Client Authentication 6534 A client that has sent authentication data to a server, either during 6535 the handshake or in post-handshake authentication, cannot be sure if 6536 the server afterwards considers the client to be authenticated or 6537 not. If the client needs to determine if the server considers the 6538 connection to be unilaterally or mutually authenticated, this has to 6539 be provisioned by the application layer. See [CHHSV17] for details. 6540 In addition, the analysis of post-handshake authentication from 6541 [Kraw16] shows that the client identified by the certificate sent in 6542 the post-handshake phase possesses the traffic key. This party is 6543 therefore the client that participated in the original handshake or 6544 one to whom the original client delegated the traffic key (assuming 6545 that the traffic key has not been compromised). 6547 E.1.3. 0-RTT 6549 The 0-RTT mode of operation generally provides similar security 6550 properties as 1-RTT data, with the two exceptions that the 0-RTT 6551 encryption keys do not provide full forward secrecy and that the 6552 server is not able to guarantee uniqueness of the handshake (non- 6553 replayability) without keeping potentially undue amounts of state. 6554 See Section 8 for mechanisms to limit the exposure to replay. 6556 E.1.4. Exporter Independence 6558 The exporter_master_secret and early_exporter_master_secret are 6559 derived to be independent of the traffic keys and therefore do not 6560 represent a threat to the security of traffic encrypted with those 6561 keys. However, because these secrets can be used to compute any 6562 exporter value, they SHOULD be erased as soon as possible. If the 6563 total set of exporter labels is known, then implementations SHOULD 6564 pre-compute the inner Derive-Secret stage of the exporter computation 6565 for all those labels, then erase the [early_]exporter_master_secret, 6566 followed by each inner values as soon as it is known that it will not 6567 be needed again. 6569 E.1.5. Post-Compromise Security 6571 TLS does not provide security for handshakes which take place after 6572 the peer's long-term secret (signature key or external PSK) is 6573 compromised. It therefore does not provide post-compromise security 6574 [CCG16], sometimes also referred to as backwards or future secrecy. 6575 This is in contrast to KCI resistance, which describes the security 6576 guarantees that a party has after its own long-term secret has been 6577 compromised. 6579 E.1.6. External References 6581 The reader should refer to the following references for analysis of 6582 the TLS handshake: [DFGS15] [CHSV16] [DFGS16] [KW16] [Kraw16] 6583 [FGSW16] [LXZFH16] [FG17] [BBK17]. 6585 E.2. Record Layer 6587 The record layer depends on the handshake producing strong traffic 6588 secrets which can be used to derive bidirectional encryption keys and 6589 nonces. Assuming that is true, and the keys are used for no more 6590 data than indicated in Section 5.5 then the record layer should 6591 provide the following guarantees: 6593 Confidentiality. An attacker should not be able to determine the 6594 plaintext contents of a given record. 6596 Integrity. An attacker should not be able to craft a new record 6597 which is different from an existing record which will be accepted 6598 by the receiver. 6600 Order protection/non-replayability An attacker should not be able to 6601 cause the receiver to accept a record which it has already 6602 accepted or cause the receiver to accept record N+1 without having 6603 first processed record N. 6605 Length concealment. Given a record with a given external length, the 6606 attacker should not be able to determine the amount of the record 6607 that is content versus padding. 6609 Forward secrecy after key change. If the traffic key update 6610 mechanism described in Section 4.6.3 has been used and the 6611 previous generation key is deleted, an attacker who compromises 6612 the endpoint should not be able to decrypt traffic encrypted with 6613 the old key. 6615 Informally, TLS 1.3 provides these properties by AEAD-protecting the 6616 plaintext with a strong key. AEAD encryption [RFC5116] provides 6617 confidentiality and integrity for the data. Non-replayability is 6618 provided by using a separate nonce for each record, with the nonce 6619 being derived from the record sequence number (Section 5.3), with the 6620 sequence number being maintained independently at both sides thus 6621 records which are delivered out of order result in AEAD deprotection 6622 failures. In order to prevent mass cryptanalysis when the same 6623 plaintext is repeatedly encrypted by different users under the same 6624 key (as is commonly the case for HTTP), the nonce is formed by mixing 6625 the sequence number with a secret per-connection initialization 6626 vector derived along with the traffic keys. See [BT16] for analysis 6627 of this construction. 6629 The re-keying technique in TLS 1.3 (see Section 7.2) follows the 6630 construction of the serial generator in [REKEY], which shows that re- 6631 keying can allow keys to be used for a larger number of encryptions 6632 than without re-keying. This relies on the security of the HKDF- 6633 Expand-Label function as a pseudorandom function (PRF). In addition, 6634 as long as this function is truly one way, it is not possible to 6635 compute traffic keys from prior to a key change (forward secrecy). 6637 TLS does not provide security for data which is communicated on a 6638 connection after a traffic secret of that connection is compromised. 6639 That is, TLS does not provide post-compromise security/future 6640 secrecy/backward secrecy with respect to the traffic secret. Indeed, 6641 an attacker who learns a traffic secret can compute all future 6642 traffic secrets on that connection. Systems which want such 6643 guarantees need to do a fresh handshake and establish a new 6644 connection with an (EC)DHE exchange. 6646 E.2.1. External References 6648 The reader should refer to the following references for analysis of 6649 the TLS record layer: [BMMT15] [BT16] [BDFKPPRSZZ16] [BBK17] 6650 [Anon18]. 6652 E.3. Traffic Analysis 6654 TLS is susceptible to a variety of traffic analysis attacks based on 6655 observing the length and timing of encrypted packets [CLINIC] 6656 [HCJ16]. This is particularly easy when there is a small set of 6657 possible messages to be distinguished, such as for a video server 6658 hosting a fixed corpus of content, but still provides usable 6659 information even in more complicated scenarios. 6661 TLS does not provide any specific defenses against this form of 6662 attack but does include a padding mechanism for use by applications: 6663 The plaintext protected by the AEAD function consists of content plus 6664 variable-length padding, which allows the application to produce 6665 arbitrary length encrypted records as well as padding-only cover 6666 traffic to conceal the difference between periods of transmission and 6667 periods of silence. Because the padding is encrypted alongside the 6668 actual content, an attacker cannot directly determine the length of 6669 the padding, but may be able to measure it indirectly by the use of 6670 timing channels exposed during record processing (i.e., seeing how 6671 long it takes to process a record or trickling in records to see 6672 which ones elicit a response from the server). In general, it is not 6673 known how to remove all of these channels because even a constant 6674 time padding removal function will likely feed the content into data- 6675 dependent functions. At minimum, a fully constant time server or 6676 client would require close cooperation with the application layer 6677 protocol implementation, including making that higher level protocol 6678 constant time. 6680 Note: Robust traffic analysis defences will likely lead to inferior 6681 performance due to delay in transmitting packets and increased 6682 traffic volume. 6684 E.4. Side Channel Attacks 6686 In general, TLS does not have specific defenses against side-channel 6687 attacks (i.e., those which attack the communications via secondary 6688 channels such as timing) leaving those to the implementation of the 6689 relevant cryptographic primitives. However, certain features of TLS 6690 are designed to make it easier to write side-channel resistant code: 6692 - Unlike previous versions of TLS which used a composite MAC-then- 6693 encrypt structure, TLS 1.3 only uses AEAD algorithms, allowing 6694 implementations to use self-contained constant-time 6695 implementations of those primitives. 6697 - TLS uses a uniform "bad_record_mac" alert for all decryption 6698 errors, which is intended to prevent an attacker from gaining 6699 piecewise insight into portions of the message. Additional 6700 resistance is provided by terminating the connection on such 6701 errors; a new connection will have different cryptographic 6702 material, preventing attacks against the cryptographic primitives 6703 that require multiple trials. 6705 Information leakage through side channels can occur at layers above 6706 TLS, in application protocols and the applications that use them. 6707 Resistance to side-channel attacks depends on applications and 6708 application protocols separately ensuring that confidential 6709 information is not inadvertently leaked. 6711 E.5. Replay Attacks on 0-RTT 6713 Replayable 0-RTT data presents a number of security threats to TLS- 6714 using applications, unless those applications are specifically 6715 engineered to be safe under replay (minimally, this means idempotent, 6716 but in many cases may also require other stronger conditions, such as 6717 constant-time response). Potential attacks include: 6719 - Duplication of actions which cause side effects (e.g., purchasing 6720 an item or transferring money) to be duplicated, thus harming the 6721 site or the user. 6723 - Attackers can store and replay 0-RTT messages in order to re-order 6724 them with respect to other messages (e.g., moving a delete to 6725 after a create). 6727 - Exploiting cache timing behavior to discover the content of 0-RTT 6728 messages by replaying a 0-RTT message to a different cache node 6729 and then using a separate connection to measure request latency, 6730 to see if the two requests address the same resource. 6732 If data can be replayed a large number of times, additional attacks 6733 become possible, such as making repeated measurements of the speed of 6734 cryptographic operations. In addition, they may be able to overload 6735 rate-limiting systems. For further description of these attacks, see 6736 [Mac17]. 6738 Ultimately, servers have the responsibility to protect themselves 6739 against attacks employing 0-RTT data replication. The mechanisms 6740 described in Section 8 are intended to prevent replay at the TLS 6741 layer but do not provide complete protection against receiving 6742 multiple copies of client data. TLS 1.3 falls back to the 1-RTT 6743 handshake when the server does not have any information about the 6744 client, e.g., because it is in a different cluster which does not 6745 share state or because the ticket has been deleted as described in 6746 Section 8.1. If the application layer protocol retransmits data in 6747 this setting, then it is possible for an attacker to induce message 6748 duplication by sending the ClientHello to both the original cluster 6749 (which processes the data immediately) and another cluster which will 6750 fall back to 1-RTT and process the data upon application layer 6751 replay. The scale of this attack is limited by the client's 6752 willingness to retry transactions and therefore only allows a limited 6753 amount of duplication, with each copy appearing as a new connection 6754 at the server. 6756 If implemented correctly, the mechanisms described in Section 8.1 and 6757 Section 8.2 prevent a replayed ClientHello and its associated 0-RTT 6758 data from being accepted multiple times by any cluster with 6759 consistent state; for servers which limit the use of 0-RTT to one 6760 cluster for a single ticket, then a given ClientHello and its 6761 associated 0-RTT data will only be accepted once. However, if state 6762 is not completely consistent, then an attacker might be able to have 6763 multiple copies of the data be accepted during the replication 6764 window. Because clients do not know the exact details of server 6765 behavior, they MUST NOT send messages in early data which are not 6766 safe to have replayed and which they would not be willing to retry 6767 across multiple 1-RTT connections. 6769 Application protocols MUST NOT use 0-RTT data without a profile that 6770 defines its use. That profile needs to identify which messages or 6771 interactions are safe to use with 0-RTT and how to handle the 6772 situation when the server rejects 0-RTT and falls back to 1-RTT. 6774 In addition, to avoid accidental misuse, TLS implementations MUST NOT 6775 enable 0-RTT (either sending or accepting) unless specifically 6776 requested by the application and MUST NOT automatically resend 0-RTT 6777 data if it is rejected by the server unless instructed by the 6778 application. Server-side applications may wish to implement special 6779 processing for 0-RTT data for some kinds of application traffic 6780 (e.g., abort the connection, request that data be resent at the 6781 application layer, or delay processing until the handshake 6782 completes). In order to allow applications to implement this kind of 6783 processing, TLS implementations MUST provide a way for the 6784 application to determine if the handshake has completed. 6786 E.5.1. Replay and Exporters 6788 Replays of the ClientHello produce the same early exporter, thus 6789 requiring additional care by applications which use these exporters. 6790 In particular, if these exporters are used as an authentication 6791 channel binding (e.g., by signing the output of the exporter) an 6792 attacker who compromises the PSK can transplant authenticators 6793 between connections without compromising the authentication key. 6795 In addition, the early exporter SHOULD NOT be used to generate 6796 server-to-client encryption keys because that would entail the reuse 6797 of those keys. This parallels the use of the early application 6798 traffic keys only in the client-to-server direction. 6800 E.6. Attacks on Static RSA 6802 Although TLS 1.3 does not use RSA key transport and so is not 6803 directly susceptible to Bleichenbacher-type attacks, if TLS 1.3 6804 servers also support static RSA in the context of previous versions 6805 of TLS, then it may be possible to impersonate the server for TLS 1.3 6806 connections [JSS15]. TLS 1.3 implementations can prevent this attack 6807 by disabling support for static RSA across all versions of TLS. In 6808 principle, implementations might also be able to separate 6809 certificates with different keyUsage bits for static RSA decryption 6810 and RSA signature, but this technique relies on clients refusing to 6811 accept signatures using keys in certificates that do not have the 6812 digitalSignature bit set, and many clients do not enforce this 6813 restriction. 6815 Appendix F. Working Group Information 6817 The discussion list for the IETF TLS working group is located at the 6818 e-mail address tls@ietf.org [1]. Information on the group and 6819 information on how to subscribe to the list is at 6820 https://www.ietf.org/mailman/listinfo/tls 6822 Archives of the list can be found at: https://www.ietf.org/mail- 6823 archive/web/tls/current/index.html 6825 Appendix G. Contributors 6827 - Martin Abadi 6828 University of California, Santa Cruz 6829 abadi@cs.ucsc.edu 6831 - Christopher Allen (co-editor of TLS 1.0) 6832 Alacrity Ventures 6833 ChristopherA@AlacrityManagement.com 6835 - Richard Barnes 6836 Cisco 6837 rlb@ipv.sx 6839 - Steven M. Bellovin 6840 Columbia University 6841 smb@cs.columbia.edu 6843 - David Benjamin 6844 Google 6845 davidben@google.com 6847 - Benjamin Beurdouche 6848 INRIA & Microsoft Research 6849 benjamin.beurdouche@ens.fr 6851 - Karthikeyan Bhargavan (co-author of [RFC7627]) 6852 INRIA 6853 karthikeyan.bhargavan@inria.fr 6855 - Simon Blake-Wilson (co-author of [RFC4492]) 6856 BCI 6857 sblakewilson@bcisse.com 6859 - Nelson Bolyard (co-author of [RFC4492]) 6860 Sun Microsystems, Inc. 6861 nelson@bolyard.com 6863 - Ran Canetti 6864 IBM 6865 canetti@watson.ibm.com 6867 - Matt Caswell 6868 OpenSSL 6869 matt@openssl.org 6871 - Stephen Checkoway 6872 University of Illinois at Chicago 6873 sfc@uic.edu 6875 - Pete Chown 6876 Skygate Technology Ltd 6877 pc@skygate.co.uk 6879 - Katriel Cohn-Gordon 6880 University of Oxford 6881 me@katriel.co.uk 6883 - Cas Cremers 6884 University of Oxford 6885 cas.cremers@cs.ox.ac.uk 6887 - Antoine Delignat-Lavaud (co-author of [RFC7627]) 6888 INRIA 6889 antdl@microsoft.com 6891 - Tim Dierks (co-editor of TLS 1.0, 1.1, and 1.2) 6892 Independent 6893 tim@dierks.org 6895 - Roelof DuToit 6896 Symantec Corporation 6897 roelof_dutoit@symantec.com 6899 - Taher Elgamal 6900 Securify 6901 taher@securify.com 6903 - Pasi Eronen 6904 Nokia 6905 pasi.eronen@nokia.com 6907 - Cedric Fournet 6908 Microsoft 6909 fournet@microsoft.com 6911 - Anil Gangolli 6912 anil@busybuddha.org 6914 - David M. Garrett 6915 dave@nulldereference.com 6917 - Illya Gerasymchuk 6918 Independent 6919 illya@iluxonchik.me 6921 - Alessandro Ghedini 6922 Cloudflare Inc. 6923 alessandro@cloudflare.com 6925 - Daniel Kahn Gillmor 6926 ACLU 6927 dkg@fifthhorseman.net 6929 - Matthew Green 6930 Johns Hopkins University 6931 mgreen@cs.jhu.edu 6933 - Jens Guballa 6934 ETAS 6935 jens.guballa@etas.com 6937 - Felix Guenther 6938 TU Darmstadt 6939 mail@felixguenther.info 6941 - Vipul Gupta (co-author of [RFC4492]) 6942 Sun Microsystems Laboratories 6943 vipul.gupta@sun.com 6945 - Chris Hawk (co-author of [RFC4492]) 6946 Corriente Networks LLC 6947 chris@corriente.net 6949 - Kipp Hickman 6951 - Alfred Hoenes 6953 - David Hopwood 6954 Independent Consultant 6955 david.hopwood@blueyonder.co.uk 6957 - Marko Horvat 6958 MPI-SWS 6959 mhorvat@mpi-sws.org 6961 - Jonathan Hoyland 6962 Royal Holloway, University of London jonathan.hoyland@gmail.com 6964 - Subodh Iyengar 6965 Facebook 6966 subodh@fb.com 6968 - Benjamin Kaduk 6969 Akamai 6970 kaduk@mit.edu 6972 - Hubert Kario 6973 Red Hat Inc. 6974 hkario@redhat.com 6976 - Phil Karlton (co-author of SSL 3.0) 6978 - Leon Klingele 6979 Independent 6980 mail@leonklingele.de 6982 - Paul Kocher (co-author of SSL 3.0) 6983 Cryptography Research 6984 paul@cryptography.com 6986 - Hugo Krawczyk 6987 IBM 6988 hugokraw@us.ibm.com 6990 - Adam Langley (co-author of [RFC7627]) 6991 Google 6992 agl@google.com 6994 - Olivier Levillain 6995 ANSSI 6996 olivier.levillain@ssi.gouv.fr 6998 - Xiaoyin Liu 6999 University of North Carolina at Chapel Hill 7000 xiaoyin.l@outlook.com 7002 - Ilari Liusvaara 7003 Independent 7004 ilariliusvaara@welho.com 7006 - Atul Luykx 7007 K.U. Leuven 7008 atul.luykx@kuleuven.be 7010 - Colm MacCarthaigh 7011 Amazon Web Services 7012 colm@allcosts.net 7014 - Carl Mehner 7015 USAA 7016 carl.mehner@usaa.com 7018 - Jan Mikkelsen 7019 Transactionware 7020 janm@transactionware.com 7022 - Bodo Moeller (co-author of [RFC4492]) 7023 Google 7024 bodo@acm.org 7026 - Kyle Nekritz 7027 Facebook 7028 knekritz@fb.com 7030 - Erik Nygren 7031 Akamai Technologies 7032 erik+ietf@nygren.org 7034 - Magnus Nystrom 7035 Microsoft 7036 mnystrom@microsoft.com 7038 - Kazuho Oku 7039 DeNA Co., Ltd. 7040 kazuhooku@gmail.com 7042 - Kenny Paterson 7043 Royal Holloway, University of London 7044 kenny.paterson@rhul.ac.uk 7046 - Alfredo Pironti (co-author of [RFC7627]) 7047 INRIA 7048 alfredo.pironti@inria.fr 7050 - Andrei Popov 7051 Microsoft 7052 andrei.popov@microsoft.com 7054 - Marsh Ray (co-author of [RFC7627]) 7055 Microsoft 7056 maray@microsoft.com 7058 - Robert Relyea 7059 Netscape Communications 7060 relyea@netscape.com 7062 - Kyle Rose 7063 Akamai Technologies 7064 krose@krose.org 7066 - Jim Roskind 7067 Amazon 7068 jroskind@amazon.com 7070 - Michael Sabin 7072 - Joe Salowey 7073 Tableau Software 7074 joe@salowey.net 7076 - Rich Salz 7077 Akamai 7078 rsalz@akamai.com 7080 - David Schinazi 7081 Apple Inc. 7082 dschinazi@apple.com 7084 - Sam Scott 7085 Royal Holloway, University of London 7086 me@samjs.co.uk 7088 - Dan Simon 7089 Microsoft, Inc. 7091 dansimon@microsoft.com 7093 - Brian Smith 7094 Independent 7095 brian@briansmith.org 7097 - Brian Sniffen 7098 Akamai Technologies 7099 ietf@bts.evenmere.org 7101 - Nick Sullivan 7102 Cloudflare Inc. 7103 nick@cloudflare.com 7105 - Bjoern Tackmann 7106 University of California, San Diego 7107 btackmann@eng.ucsd.edu 7109 - Tim Taubert 7110 Mozilla 7111 ttaubert@mozilla.com 7113 - Martin Thomson 7114 Mozilla 7115 mt@mozilla.com 7117 - Sean Turner 7118 sn3rd 7119 sean@sn3rd.com 7121 - Steven Valdez 7122 Google 7123 svaldez@google.com 7125 - Filippo Valsorda 7126 Cloudflare Inc. 7127 filippo@cloudflare.com 7129 - Thyla van der Merwe 7130 Royal Holloway, University of London 7131 tjvdmerwe@gmail.com 7133 - Victor Vasiliev 7134 Google 7135 vasilvv@google.com 7137 - Tom Weinstein 7138 - Hoeteck Wee 7139 Ecole Normale Superieure, Paris 7140 hoeteck@alum.mit.edu 7142 - David Wong 7143 NCC Group 7144 david.wong@nccgroup.trust 7146 - Christopher A. Wood 7147 Apple Inc. 7148 cawood@apple.com 7150 - Tim Wright 7151 Vodafone 7152 timothy.wright@vodafone.com 7154 - Peter Wu 7155 Independent 7156 peter@lekensteyn.nl 7158 - Kazu Yamamoto 7159 Internet Initiative Japan Inc. 7160 kazu@iij.ad.jp 7162 Author's Address 7164 Eric Rescorla 7165 RTFM, Inc. 7167 EMail: ekr@rtfm.com