idnits 2.17.1 draft-ietf-tls-tls13-21.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 26 instances of too long lines in the document, the longest one being 5 characters in excess of 72. -- The draft header indicates that this document obsoletes RFC5077, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC5246, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6066, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5705, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6961, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4492, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The "post_handshake_auth" extension is used to indicate that a client is willing to perform post-handshake authentication Section 4.6.2. Servers MUST not send a post-handshake CertificateRequest to clients which do not offer this extension. Servers MUST NOT send this extension. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The presence of padding does not change the overall record size limitations - the full encoded TLSInnerPlaintext MUST not exceed 2^14 octets. If the maximum fragment length is reduced, as for example by the max_fragment_length extension from [RFC6066], then the reduced limit applies to the full plaintext, including the padding. (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 (July 03, 2017) is 2489 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 965, but not defined -- Looks like a reference, but probably isn't: '0' on line 1101 -- Looks like a reference, but probably isn't: '1' on line 6267 -- Looks like a reference, but probably isn't: '3' on line 1172 -- Looks like a reference, but probably isn't: '9' on line 1137 -- Looks like a reference, but probably isn't: '2' on line 5200 -- Looks like a reference, but probably isn't: '4' on line 1173 -- Looks like a reference, but probably isn't: '8' on line 1174 -- Looks like a reference, but probably isn't: '10' on line 1288 -- Looks like a reference, but probably isn't: '32' on line 5198 == Unused Reference: 'RFC4681' is defined on line 4869, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DH' -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** 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-01 == Outdated reference: A later version (-07) exists of draft-ietf-tls-tls13-vectors-01 -- 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: 12 errors (**), 0 flaws (~~), 7 warnings (==), 33 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Obsoletes: 5077, 5246 (if approved) July 03, 2017 5 Updates: 4492, 5705, 6066, 6961 (if 6 approved) 7 Intended status: Standards Track 8 Expires: January 4, 2018 10 The Transport Layer Security (TLS) Protocol Version 1.3 11 draft-ietf-tls-tls13-21 13 Abstract 15 This document specifies version 1.3 of the Transport Layer Security 16 (TLS) protocol. TLS allows client/server applications to communicate 17 over the Internet in a way that is designed to prevent eavesdropping, 18 tampering, and message forgery. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 4, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 6 68 1.2. Change Log . . . . . . . . . . . . . . . . . . . . . . . 6 69 1.3. Major Differences from TLS 1.2 . . . . . . . . . . . . . 14 70 1.4. Updates Affecting TLS 1.2 . . . . . . . . . . . . . . . . 16 71 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 16 72 2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . . . 19 73 2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 20 74 2.3. Zero-RTT Data . . . . . . . . . . . . . . . . . . . . . . 22 75 3. Presentation Language . . . . . . . . . . . . . . . . . . . . 24 76 3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 24 77 3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 24 78 3.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 24 79 3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 25 80 3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 26 81 3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 27 82 3.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 27 83 3.8. Variants . . . . . . . . . . . . . . . . . . . . . . . . 27 84 4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 28 85 4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 29 86 4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 30 87 4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 31 88 4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 34 89 4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 35 90 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 37 91 4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 40 92 4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 41 93 4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 42 94 4.2.4. Certificate Authorities . . . . . . . . . . . . . . . 45 95 4.2.5. Post-Handshake Client Authentication . . . . . . . . 47 96 4.2.6. Negotiated Groups . . . . . . . . . . . . . . . . . . 47 97 4.2.7. Key Share . . . . . . . . . . . . . . . . . . . . . . 48 98 4.2.8. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 52 99 4.2.9. Early Data Indication . . . . . . . . . . . . . . . . 52 100 4.2.10. Pre-Shared Key Extension . . . . . . . . . . . . . . 55 101 4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 58 102 4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 58 103 4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 59 104 4.4. Authentication Messages . . . . . . . . . . . . . . . . . 59 105 4.4.1. The Transcript Hash . . . . . . . . . . . . . . . . . 61 106 4.4.2. Certificate . . . . . . . . . . . . . . . . . . . . . 62 107 4.4.3. Certificate Verify . . . . . . . . . . . . . . . . . 66 108 4.4.4. Finished . . . . . . . . . . . . . . . . . . . . . . 68 109 4.5. End of Early Data . . . . . . . . . . . . . . . . . . . . 70 110 4.6. Post-Handshake Messages . . . . . . . . . . . . . . . . . 70 111 4.6.1. New Session Ticket Message . . . . . . . . . . . . . 70 112 4.6.2. Post-Handshake Authentication . . . . . . . . . . . . 72 113 4.6.3. Key and IV Update . . . . . . . . . . . . . . . . . . 73 114 5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 74 115 5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 74 116 5.2. Record Payload Protection . . . . . . . . . . . . . . . . 76 117 5.3. Per-Record Nonce . . . . . . . . . . . . . . . . . . . . 78 118 5.4. Record Padding . . . . . . . . . . . . . . . . . . . . . 79 119 5.5. Limits on Key Usage . . . . . . . . . . . . . . . . . . . 80 120 6. Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . 80 121 6.1. Closure Alerts . . . . . . . . . . . . . . . . . . . . . 82 122 6.2. Error Alerts . . . . . . . . . . . . . . . . . . . . . . 83 123 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 85 124 7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 86 125 7.2. Updating Traffic Keys and IVs . . . . . . . . . . . . . . 88 126 7.3. Traffic Key Calculation . . . . . . . . . . . . . . . . . 89 127 7.4. (EC)DHE Shared Secret Calculation . . . . . . . . . . . . 90 128 7.4.1. Finite Field Diffie-Hellman . . . . . . . . . . . . . 90 129 7.4.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 90 130 7.5. Exporters . . . . . . . . . . . . . . . . . . . . . . . . 91 131 8. 0-RTT and Anti-Replay . . . . . . . . . . . . . . . . . . . . 91 132 8.1. Single-Use Tickets . . . . . . . . . . . . . . . . . . . 92 133 8.2. Client Hello Recording . . . . . . . . . . . . . . . . . 93 134 8.3. Freshness Checks . . . . . . . . . . . . . . . . . . . . 94 135 9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 95 136 9.1. Mandatory-to-Implement Cipher Suites . . . . . . . . . . 95 137 9.2. Mandatory-to-Implement Extensions . . . . . . . . . . . . 96 138 10. Security Considerations . . . . . . . . . . . . . . . . . . . 97 139 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97 140 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 98 141 12.1. Normative References . . . . . . . . . . . . . . . . . . 98 142 12.2. Informative References . . . . . . . . . . . . . . . . . 101 143 Appendix A. State Machine . . . . . . . . . . . . . . . . . . . 108 144 A.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 108 145 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 109 146 Appendix B. Protocol Data Structures and Constant Values . . . . 109 147 B.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 110 148 B.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 110 149 B.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 112 150 B.3.1. Key Exchange Messages . . . . . . . . . . . . . . . . 112 151 B.3.2. Server Parameters Messages . . . . . . . . . . . . . 117 152 B.3.3. Authentication Messages . . . . . . . . . . . . . . . 118 153 B.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 119 154 B.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 119 155 B.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 120 156 Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 121 157 C.1. Random Number Generation and Seeding . . . . . . . . . . 121 158 C.2. Certificates and Authentication . . . . . . . . . . . . . 121 159 C.3. Implementation Pitfalls . . . . . . . . . . . . . . . . . 121 160 C.4. Client Tracking Prevention . . . . . . . . . . . . . . . 123 161 C.5. Unauthenticated Operation . . . . . . . . . . . . . . . . 123 162 Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 124 163 D.1. Negotiating with an older server . . . . . . . . . . . . 124 164 D.2. Negotiating with an older client . . . . . . . . . . . . 125 165 D.3. Zero-RTT backwards compatibility . . . . . . . . . . . . 125 166 D.4. Backwards Compatibility Security Restrictions . . . . . . 126 167 Appendix E. Overview of Security Properties . . . . . . . . . . 127 168 E.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 127 169 E.1.1. Key Derivation and HKDF . . . . . . . . . . . . . . . 130 170 E.1.2. Client Authentication . . . . . . . . . . . . . . . . 131 171 E.1.3. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . 131 172 E.1.4. Exporter Independence . . . . . . . . . . . . . . . . 131 173 E.1.5. Post-Compromise Security . . . . . . . . . . . . . . 131 174 E.1.6. External References . . . . . . . . . . . . . . . . . 132 175 E.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 132 176 E.2.1. External References . . . . . . . . . . . . . . . . . 133 177 E.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 133 178 E.4. Side Channel Attacks . . . . . . . . . . . . . . . . . . 134 179 E.5. Replay Attacks on 0-RTT . . . . . . . . . . . . . . . . . 134 180 E.5.1. Replay and Exporters . . . . . . . . . . . . . . . . 136 181 Appendix F. Working Group Information . . . . . . . . . . . . . 136 182 Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 136 183 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 143 185 1. Introduction 187 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this 188 draft is maintained in GitHub. Suggested changes should be submitted 189 as pull requests at https://github.com/tlswg/tls13-spec. 190 Instructions are on that page as well. Editorial changes can be 191 managed in GitHub, but any substantive change should be discussed on 192 the TLS mailing list. 194 The primary goal of TLS is to provide a secure channel between two 195 communicating peers. Specifically, the channel should provide the 196 following properties: 198 - Authentication: The server side of the channel is always 199 authenticated; the client side is optionally authenticated. 200 Authentication can happen via asymmetric cryptography (e.g., RSA 201 [RSA], ECDSA [ECDSA], EdDSA [RFC8032]) or a pre-shared key (PSK). 203 - Confidentiality: Data sent over the channel after establishment is 204 only visible to the endpoints. TLS does not hide the length of 205 the data it transmits, though endpoints are able to pad TLS 206 records in order to obscure lengths and improve protection agains 207 traffic analysis techniques. 209 - Integrity: Data sent over the channel after establishment cannot 210 be modified by attackers. 212 These properties should be true even in the face of an attacker who 213 has complete control of the network, as described in [RFC3552]. See 214 Appendix E for a more complete statement of the relevant security 215 properties. 217 TLS consists of two primary components: 219 - A handshake protocol (Section 4) that authenticates the 220 communicating parties, negotiates cryptographic modes and 221 parameters, and establishes shared keying material. The handshake 222 protocol is designed to resist tampering; an active attacker 223 should not be able to force the peers to negotiate different 224 parameters than they would if the connection were not under 225 attack. 227 - A record protocol (Section 5) that uses the parameters established 228 by the handshake protocol to protect traffic between the 229 communicating peers. The record protocol divides traffic up into 230 a series of records, each of which is independently protected 231 using the traffic keys. 233 TLS is application protocol independent; higher-level protocols can 234 layer on top of TLS transparently. The TLS standard, however, does 235 not specify how protocols add security with TLS; how to initiate TLS 236 handshaking and how to interpret the authentication certificates 237 exchanged are left to the judgment of the designers and implementors 238 of protocols that run on top of TLS. 240 This document defines TLS version 1.3. While TLS 1.3 is not directly 241 compatible with previous versions, all versions of TLS incorporate a 242 versioning mechanism which allows clients and servers to 243 interoperably negotiate a common version if one is supported by both 244 peers. 246 This document supersedes and obsoletes previous versions of TLS 247 including version 1.2 [RFC5246]. It also obsoletes the TLS ticket 248 mechanism defined in [RFC5077] and replaces it with the mechanism 249 defined in Section 2.2. Section 4.2.6 updates [RFC4492] by modifying 250 the protocol attributes used to negotiate Elliptic Curves. Because 251 TLS 1.3 changes the way keys are derived it updates [RFC5705] as 252 described in Section 7.5 it also changes how OCSP messages are 253 carried and therefore updates [RFC6066] and obsoletes [RFC6961] as 254 described in section Section 4.4.2.1. 256 1.1. Conventions and Terminology 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 260 "OPTIONAL" in this document are to be interpreted as described in RFC 261 2119 [RFC2119]. 263 The following terms are used: 265 client: The endpoint initiating the TLS connection. 267 connection: A transport-layer connection between two endpoints. 269 endpoint: Either the client or server of the connection. 271 handshake: An initial negotiation between client and server that 272 establishes the parameters of their subsequent interactions. 274 peer: An endpoint. When discussing a particular endpoint, "peer" 275 refers to the endpoint that is not the primary subject of discussion. 277 receiver: An endpoint that is receiving records. 279 sender: An endpoint that is transmitting records. 281 server: The endpoint which did not initiate the TLS connection. 283 1.2. Change Log 285 RFC EDITOR PLEASE DELETE THIS SECTION. 287 (*) indicates changes to the wire protocol which may require 288 implementations to update. 290 - Add a per-ticket nonce so that each ticket is associated with a 291 different PSK (*). 293 - Clarify that clients should send alerts with the handshake key if 294 possible. 296 - Update state machine to show rekeying events 298 - Add discussion of 0-RTT and replay. Recommend that 299 implementations implement some anti-replay mechanism. 301 draft-20 303 - Add "post_handshake_auth" extension to negotiate post-handshake 304 authentication (*). 306 - Shorten labels for HKDF-Expand-Label so that we can fit within one 307 compression block (*). 309 - Define how RFC 7250 works (*). 311 - Re-enable post-handshake client authentication even when you do 312 PSK. The previous prohibition was editorial error. 314 - Remove cert_type and user_mapping, which don't work on TLS 1.3 315 anyway. 317 - Added the no_application_protocol alert from [RFC7301] to the list 318 of extensions. 320 - Added discussion of traffic analysis and side channel attacks. 322 draft-19 324 - Hash context_value input to Exporters (*) 326 - Add an additional Derive-Secret stage to Exporters (*). 328 - Hash ClientHello1 in the transcript when HRR is used. This 329 reduces the state that needs to be carried in cookies. (*) 331 - Restructure CertificateRequest to have the selectors in 332 extensions. This also allowed defining a 333 "certificate_authorities" extension which can be used by the 334 client instead of trusted_ca_keys (*). 336 - Tighten record framing requirements and require checking of them 337 (*). 339 - Consolidate "ticket_early_data_info" and "early_data" into a 340 single extension (*). 342 - Change end_of_early_data to be a handshake message (*). 344 - Add pre-extract Derive-Secret stages to key schedule (*). 346 - Remove spurious requirement to implement "pre_shared_key". 348 - Clarify location of "early_data" from server (it goes in EE, as 349 indicated by the table in S 10). 351 - Require peer public key validation 353 - Add state machine diagram. 355 draft-18 357 - Remove unnecessary resumption_psk which is the only thing expanded 358 from the resumption master secret. (*). 360 - Fix signature_algorithms entry in extensions table. 362 - Restate rule from RFC 6066 that you can't resume unless SNI is the 363 same. 365 draft-17 367 - Remove 0-RTT Finished and resumption_context, and replace with a 368 psk_binder field in the PSK itself (*) 370 - Restructure PSK key exchange negotiation modes (*) 372 - Add max_early_data_size field to TicketEarlyDataInfo (*) 374 - Add a 0-RTT exporter and change the transcript for the regular 375 exporter (*) 377 - Merge TicketExtensions and Extensions registry. Changes 378 ticket_early_data_info code point (*) 380 - Replace Client.key_shares in response to HRR (*) 382 - Remove redundant labels for traffic key derivation (*) 383 - Harmonize requirements about cipher suite matching: for resumption 384 you need to match KDF but for 0-RTT you need whole cipher suite. 385 This allows PSKs to actually negotiate cipher suites. (*) 387 - Move SCT and OCSP into Certificate.extensions (*) 389 - Explicitly allow non-offered extensions in NewSessionTicket 391 - Explicitly allow predicting client Finished for NST 393 - Clarify conditions for allowing 0-RTT with PSK 395 draft-16 397 - Revise version negotiation (*) 399 - Change RSASSA-PSS and EdDSA SignatureScheme codepoints for better 400 backwards compatibility (*) 402 - Move HelloRetryRequest.selected_group to an extension (*) 404 - Clarify the behavior of no exporter context and make it the same 405 as an empty context.(*) 407 - New KeyUpdate format that allows for requesting/not-requesting an 408 answer. This also means changes to the key schedule to support 409 independent updates (*) 411 - New certificate_required alert (*) 413 - Forbid CertificateRequest with 0-RTT and PSK. 415 - Relax requirement to check SNI for 0-RTT. 417 draft-15 419 - New negotiation syntax as discussed in Berlin (*) 421 - Require CertificateRequest.context to be empty during handshake 422 (*) 424 - Forbid empty tickets (*) 426 - Forbid application data messages in between post-handshake 427 messages from the same flight (*) 429 - Clean up alert guidance (*) 430 - Clearer guidance on what is needed for TLS 1.2. 432 - Guidance on 0-RTT time windows. 434 - Rename a bunch of fields. 436 - Remove old PRNG text. 438 - Explicitly require checking that handshake records not span key 439 changes. 441 draft-14 443 - Allow cookies to be longer (*) 445 - Remove the "context" from EarlyDataIndication as it was undefined 446 and nobody used it (*) 448 - Remove 0-RTT EncryptedExtensions and replace the ticket_age 449 extension with an obfuscated version. Also necessitates a change 450 to NewSessionTicket (*). 452 - Move the downgrade sentinel to the end of ServerHello.Random to 453 accommodate tlsdate (*). 455 - Define ecdsa_sha1 (*). 457 - Allow resumption even after fatal alerts. This matches current 458 practice. 460 - Remove non-closure warning alerts. Require treating unknown 461 alerts as fatal. 463 - Make the rules for accepting 0-RTT less restrictive. 465 - Clarify 0-RTT backward-compatibility rules. 467 - Clarify how 0-RTT and PSK identities interact. 469 - Add a section describing the data limits for each cipher. 471 - Major editorial restructuring. 473 - Replace the Security Analysis section with a WIP draft. 475 draft-13 477 - Allow server to send SupportedGroups. 479 - Remove 0-RTT client authentication 481 - Remove (EC)DHE 0-RTT. 483 - Flesh out 0-RTT PSK mode and shrink EarlyDataIndication 485 - Turn PSK-resumption response into an index to save room 487 - Move CertificateStatus to an extension 489 - Extra fields in NewSessionTicket. 491 - Restructure key schedule and add a resumption_context value. 493 - Require DH public keys and secrets to be zero-padded to the size 494 of the group. 496 - Remove the redundant length fields in KeyShareEntry. 498 - Define a cookie field for HRR. 500 draft-12 502 - Provide a list of the PSK cipher suites. 504 - Remove the ability for the ServerHello to have no extensions (this 505 aligns the syntax with the text). 507 - Clarify that the server can send application data after its first 508 flight (0.5 RTT data) 510 - Revise signature algorithm negotiation to group hash, signature 511 algorithm, and curve together. This is backwards compatible. 513 - Make ticket lifetime mandatory and limit it to a week. 515 - Make the purpose strings lower-case. This matches how people are 516 implementing for interop. 518 - Define exporters. 520 - Editorial cleanup 522 draft-11 524 - Port the CFRG curves & signatures work from RFC4492bis. 526 - Remove sequence number and version from additional_data, which is 527 now empty. 529 - Reorder values in HkdfLabel. 531 - Add support for version anti-downgrade mechanism. 533 - Update IANA considerations section and relax some of the policies. 535 - Unify authentication modes. Add post-handshake client 536 authentication. 538 - Remove early_handshake content type. Terminate 0-RTT data with an 539 alert. 541 - Reset sequence number upon key change (as proposed by Fournet et 542 al.) 544 draft-10 546 - Remove ClientCertificateTypes field from CertificateRequest and 547 add extensions. 549 - Merge client and server key shares into a single extension. 551 draft-09 553 - Change to RSA-PSS signatures for handshake messages. 555 - Remove support for DSA. 557 - Update key schedule per suggestions by Hugo, Hoeteck, and Bjoern 558 Tackmann. 560 - Add support for per-record padding. 562 - Switch to encrypted record ContentType. 564 - Change HKDF labeling to include protocol version and value 565 lengths. 567 - Shift the final decision to abort a handshake due to incompatible 568 certificates to the client rather than having servers abort early. 570 - Deprecate SHA-1 with signatures. 572 - Add MTI algorithms. 574 - Remove support for weak and lesser used named curves. 576 - Remove support for MD5 and SHA-224 hashes with signatures. 578 - Update lists of available AEAD cipher suites and error alerts. 580 - Reduce maximum permitted record expansion for AEAD from 2048 to 581 256 octets. 583 - Require digital signatures even when a previous configuration is 584 used. 586 - Merge EarlyDataIndication and KnownConfiguration. 588 - Change code point for server_configuration to avoid collision with 589 server_hello_done. 591 - Relax certificate_list ordering requirement to match current 592 practice. 594 draft-07 596 - Integration of semi-ephemeral DH proposal. 598 - Add initial 0-RTT support. 600 - Remove resumption and replace with PSK + tickets. 602 - Move ClientKeyShare into an extension. 604 - Move to HKDF. 606 draft-06 608 - Prohibit RC4 negotiation for backwards compatibility. 610 - Freeze & deprecate record layer version field. 612 - Update format of signatures with context. 614 - Remove explicit IV. 616 draft-05 618 - Prohibit SSL negotiation for backwards compatibility. 620 - Fix which MS is used for exporters. 622 draft-04 624 - Modify key computations to include session hash. 626 - Remove ChangeCipherSpec. 628 - Renumber the new handshake messages to be somewhat more consistent 629 with existing convention and to remove a duplicate registration. 631 - Remove renegotiation. 633 - Remove point format negotiation. 635 draft-03 637 - Remove GMT time. 639 - Merge in support for ECC from RFC 4492 but without explicit 640 curves. 642 - Remove the unnecessary length field from the AD input to AEAD 643 ciphers. 645 - Rename {Client,Server}KeyExchange to {Client,Server}KeyShare. 647 - Add an explicit HelloRetryRequest to reject the client's. 649 draft-02 651 - Increment version number. 653 - Rework handshake to provide 1-RTT mode. 655 - Remove custom DHE groups. 657 - Remove support for compression. 659 - Remove support for static RSA and DH key exchange. 661 - Remove support for non-AEAD ciphers. 663 1.3. Major Differences from TLS 1.2 665 The following is a list of the major functional differences between 666 TLS 1.2 and TLS 1.3. It is not intended to be exhaustive and there 667 are many minor differences. 669 - The list of supported symmetric algorithms has been pruned of all 670 algorithms that are considered legacy. Those that remain all use 671 Authenticated Encryption with Associated Data (AEAD) algorithms. 672 The ciphersuite concept has been changed to separate the 673 authentication and key exchange mechanisms from the record 674 protection algorithm (including secret key length) and a hash to 675 be used with the key derivation function and HMAC. 677 - A Zero-RTT mode was added, saving a round-trip at connection setup 678 for some application data, at the cost of certain security 679 properties. 681 - Static RSA and Diffie-Hellman cipher suites have been removed; all 682 public-key based key exchange mechanisms now provide forward 683 secrecy. 685 - All handshake messages after the ServerHello are now encrypted. 686 The newly introduced EncryptedExtension message allows various 687 extensions previously sent in clear in the ServerHello to also 688 enjoy confidentiality protection. 690 - The key derivation functions have been re-designed. The new 691 design allows easier analysis by cryptographers due to their 692 improved key separation properties. The HMAC-based Extract-and- 693 Expand Key Derivation Function (HKDF) is used as an underlying 694 primitive. 696 - The handshake state machine has been significantly restructured to 697 be more consistent and to remove superfluous messages such as 698 ChangeCipherSpec. 700 - ECC is now in the base spec and includes new signature algorithms, 701 such as ed25519 and ed448. TLS 1.3 removed point format 702 negotiation in favor of a single point format for each curve. 704 - Other cryptographic improvements including the removal of 705 compression and custom DHE groups, changing the RSA padding to use 706 PSS, and the removal of DSA. 708 - The TLS 1.2 version negotiation mechanism has been deprecated in 709 favor of a version list in an extension. This increases 710 compatibility with servers which incorrectly implemented version 711 negotiation. 713 - Session resumption with and without server-side state as well as 714 the PSK-based ciphersuites of earlier TLS versions have been 715 replaced by a single new PSK exchange. 717 - Updated references to point to the updated versions of RFCs, as 718 appropriate (e.g., RFC 5280 rather than RFC 3280). 720 1.4. Updates Affecting TLS 1.2 722 This document defines several changes that optionally affect 723 implementations of TLS 1.2: 725 - A version downgrade protection mechanism is described in 726 Section 4.1.3. 728 - RSASSA-PSS signature schemes are defined in Section 4.2.3. 730 - The "supported_versions" ClientHello extension can be used to 731 negotiate the version of TLS to use, in preference to the 732 legacy_version field of the ClientHello. 734 An implementation of TLS 1.3 that also supports TLS 1.2 might need to 735 include changes to support these changes even when TLS 1.3 is not in 736 use. See the referenced sections for more details. 738 2. Protocol Overview 740 The cryptographic parameters used by the secure channel are produced 741 by the TLS handshake protocol. This sub-protocol of TLS is used by 742 the client and server when first communicating with each other. The 743 handshake protocol allows peers to negotiate a protocol version, 744 select cryptographic algorithms, optionally authenticate each other, 745 and establish shared secret keying material. Once the handshake is 746 complete, the peers use the established keys to protect the 747 application layer traffic. 749 A failure of the handshake or other protocol error triggers the 750 termination of the connection, optionally preceded by an alert 751 message (Section 6). 753 TLS supports three basic key exchange modes: 755 - (EC)DHE (Diffie-Hellman over either finite fields or elliptic 756 curves) 758 - PSK-only 760 - PSK with (EC)DHE 762 Figure 1 below shows the basic full TLS handshake: 764 Client Server 766 Key ^ ClientHello 767 Exch | + key_share* 768 | + signature_algorithms* 769 | + psk_key_exchange_modes* 770 v + pre_shared_key* --------> 771 ServerHello ^ Key 772 + key_share* | Exch 773 + pre_shared_key* v 774 {EncryptedExtensions} ^ Server 775 {CertificateRequest*} v Params 776 {Certificate*} ^ 777 {CertificateVerify*} | Auth 778 {Finished} v 779 <-------- [Application Data*] 780 ^ {Certificate*} 781 Auth | {CertificateVerify*} 782 v {Finished} --------> 783 [Application Data] <-------> [Application Data] 785 + Indicates noteworthy extensions sent in the 786 previously noted message. 788 * Indicates optional or situation-dependent 789 messages/extensions that are not always sent. 791 {} Indicates messages protected using keys 792 derived from a [sender]_handshake_traffic_secret. 794 [] Indicates messages protected using keys 795 derived from [sender]_application_traffic_secret_N 797 Figure 1: Message flow for full TLS Handshake 799 The handshake can be thought of as having three phases (indicated in 800 the diagram above): 802 - Key Exchange: Establish shared keying material and select the 803 cryptographic parameters. Everything after this phase is 804 encrypted. 806 - Server Parameters: Establish other handshake parameters (whether 807 the client is authenticated, application layer protocol support, 808 etc.). 810 - Authentication: Authenticate the server (and optionally the 811 client) and provide key confirmation and handshake integrity. 813 In the Key Exchange phase, the client sends the ClientHello 814 (Section 4.1.2) message, which contains a random nonce 815 (ClientHello.random); its offered protocol versions; a list of 816 symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key 817 shares (in the "key_share" extension Section 4.2.7), a set of pre- 818 shared key labels (in the "pre_shared_key" extension Section 4.2.10) 819 or both; and potentially additional extensions. 821 The server processes the ClientHello and determines the appropriate 822 cryptographic parameters for the connection. It then responds with 823 its own ServerHello (Section 4.1.3), which indicates the negotiated 824 connection parameters. The combination of the ClientHello and the 825 ServerHello determines the shared keys. If (EC)DHE key establishment 826 is in use, then the ServerHello contains a "key_share" extension with 827 the server's ephemeral Diffie-Hellman share which MUST be in the same 828 group as one of the client's shares. If PSK key establishment is in 829 use, then the ServerHello contains a "pre_shared_key" extension 830 indicating which of the client's offered PSKs was selected. Note 831 that implementations can use (EC)DHE and PSK together, in which case 832 both extensions will be supplied. 834 The server then sends two messages to establish the Server 835 Parameters: 837 EncryptedExtensions: responses to ClientHello extensions that are 838 not required to determine the cryptographic parameters, other than 839 those that are specific to individual certificates. 840 [Section 4.3.1] 842 CertificateRequest: if certificate-based client authentication is 843 desired, the desired parameters for that certificate. This 844 message is omitted if client authentication is not desired. 845 [Section 4.3.2] 847 Finally, the client and server exchange Authentication messages. TLS 848 uses the same set of messages every time that authentication is 849 needed. Specifically: 851 Certificate: the certificate of the endpoint and any per-certificate 852 extensions. This message is omitted by the server if not 853 authenticating with a certificate and by the client if the server 854 did not send CertificateRequest (thus indicating that the client 855 should not authenticate with a certificate). Note that if raw 856 public keys [RFC7250] or the cached information extension 857 [RFC7924] are in use, then this message will not contain a 858 certificate but rather some other value corresponding to the 859 server's long-term key. [Section 4.4.2] 861 CertificateVerify: a signature over the entire handshake using the 862 private key corresponding to the public key in the Certificate 863 message. This message is omitted if the endpoint is not 864 authenticating via a certificate. [Section 4.4.3] 866 Finished: a MAC (Message Authentication Code) over the entire 867 handshake. This message provides key confirmation, binds the 868 endpoint's identity to the exchanged keys, and in PSK mode also 869 authenticates the handshake. [Section 4.4.4] 871 Upon receiving the server's messages, the client responds with its 872 Authentication messages, namely Certificate and CertificateVerify (if 873 requested), and Finished. 875 At this point, the handshake is complete, and the client and server 876 must derive the keying material required by the record layer to 877 exchange application-layer data protected through authenticated 878 encryption. Application data MUST NOT be sent prior to sending the 879 Finished message and until the record layer starts using encryption 880 keys. Note that while the server may send application data prior to 881 receiving the client's Authentication messages, any data sent at that 882 point is, of course, being sent to an unauthenticated peer. 884 2.1. Incorrect DHE Share 886 If the client has not provided a sufficient "key_share" extension 887 (e.g., it includes only DHE or ECDHE groups unacceptable to or 888 unsupported by the server), the server corrects the mismatch with a 889 HelloRetryRequest and the client needs to restart the handshake with 890 an appropriate "key_share" extension, as shown in Figure 2. If no 891 common cryptographic parameters can be negotiated, the server MUST 892 abort the handshake with an appropriate alert. 894 Client Server 896 ClientHello 897 + key_share --------> 898 <-------- HelloRetryRequest 899 + key_share 901 ClientHello 902 + key_share --------> 903 ServerHello 904 + key_share 905 {EncryptedExtensions} 906 {CertificateRequest*} 907 {Certificate*} 908 {CertificateVerify*} 909 {Finished} 910 <-------- [Application Data*] 911 {Certificate*} 912 {CertificateVerify*} 913 {Finished} --------> 914 [Application Data] <-------> [Application Data] 916 Figure 2: Message flow for a full handshake with mismatched 917 parameters 919 Note: The handshake transcript includes the initial ClientHello/ 920 HelloRetryRequest exchange; it is not reset with the new ClientHello. 922 TLS also allows several optimized variants of the basic handshake, as 923 described in the following sections. 925 2.2. Resumption and Pre-Shared Key (PSK) 927 Although TLS PSKs can be established out of band, PSKs can also be 928 established in a previous connection and then reused ("session 929 resumption"). Once a handshake has completed, the server can send to 930 the client a PSK identity that corresponds to a unique key derived 931 from the initial handshake (see Section 4.6.1). The client can then 932 use that PSK identity in future handshakes to negotiate the use of 933 the associated PSK. If the server accepts it, then the security 934 context of the new connection is cryptographically tied to the 935 original connection and the key derived from the initial handshake is 936 used to bootstrap the cryptographic state instead of a full 937 handshake. In TLS 1.2 and below, this functionality was provided by 938 "session IDs" and "session tickets" [RFC5077]. Both mechanisms are 939 obsoleted in TLS 1.3. 941 PSKs can be used with (EC)DHE key exchange in order to provide 942 forward secrecy in combination with shared keys, or can be used 943 alone, at the cost of losing forward secrecy for the application 944 data. 946 Figure 3 shows a pair of handshakes in which the first establishes a 947 PSK and the second uses it: 949 Client Server 951 Initial Handshake: 952 ClientHello 953 + key_share --------> 954 ServerHello 955 + key_share 956 {EncryptedExtensions} 957 {CertificateRequest*} 958 {Certificate*} 959 {CertificateVerify*} 960 {Finished} 961 <-------- [Application Data*] 962 {Certificate*} 963 {CertificateVerify*} 964 {Finished} --------> 965 <-------- [NewSessionTicket] 966 [Application Data] <-------> [Application Data] 968 Subsequent Handshake: 969 ClientHello 970 + key_share* 971 + psk_key_exchange_modes 972 + pre_shared_key --------> 973 ServerHello 974 + pre_shared_key 975 + key_share* 976 {EncryptedExtensions} 977 {Finished} 978 <-------- [Application Data*] 979 {Finished} --------> 980 [Application Data] <-------> [Application Data] 982 Figure 3: Message flow for resumption and PSK 984 As the server is authenticating via a PSK, it does not send a 985 Certificate or a CertificateVerify message. When a client offers 986 resumption via PSK, it SHOULD also supply a "key_share" extension to 987 the server to allow the server to decline resumption and fall back to 988 a full handshake, if needed. The server responds with a 989 "pre_shared_key" extension to negotiate use of PSK key establishment 990 and can (as shown here) respond with a "key_share" extension to do 991 (EC)DHE key establishment, thus providing forward secrecy. 993 When PSKs are provisioned out of band, the PSK identity and the KDF 994 hash algorithm to be used with the PSK MUST also be provisioned. 995 Note: When using an out-of-band provisioned pre-shared secret, a 996 critical consideration is using sufficient entropy during the key 997 generation, as discussed in [RFC4086]. Deriving a shared secret from 998 a password or other low-entropy sources is not secure. A low-entropy 999 secret, or password, is subject to dictionary attacks based on the 1000 PSK binder. The specified PSK authentication is not a strong 1001 password-based authenticated key exchange even when used with Diffie- 1002 Hellman key establishment. 1004 2.3. Zero-RTT Data 1006 When clients and servers share a PSK (either obtained externally or 1007 via a previous handshake), TLS 1.3 allows clients to send data on the 1008 first flight ("early data"). The client uses the PSK to authenticate 1009 the server and to encrypt the early data. 1011 When clients use a PSK obtained externally to send early data, then 1012 the following additional information MUST be provisioned to both 1013 parties: 1015 - The TLS version number for use with this PSK 1017 - The cipher suite for use with this PSK 1019 - The Application-Layer Protocol Negotiation (ALPN) protocol 1020 [RFC7301], if any is to be used 1022 - The Server Name Indication (SNI), if any is to be used 1024 As shown in Figure 4, the 0-RTT data is just added to the 1-RTT 1025 handshake in the first flight. The rest of the handshake uses the 1026 same messages as with a 1-RTT handshake with PSK resumption. 1028 Client Server 1030 ClientHello 1031 + early_data 1032 + key_share* 1033 + psk_key_exchange_modes 1034 + pre_shared_key 1035 (Application Data*) --------> 1036 ServerHello 1037 + pre_shared_key 1038 + key_share* 1039 {EncryptedExtensions} 1040 + early_data* 1041 {Finished} 1042 <-------- [Application Data*] 1043 (EndOfEarlyData) 1044 {Finished} --------> 1046 [Application Data] <-------> [Application Data] 1048 + Indicates noteworthy extensions sent in the 1049 previously noted message. 1051 * Indicates optional or situation-dependent 1052 messages/extensions that are not always sent. 1054 () Indicates messages protected using keys 1055 derived from client_early_traffic_secret. 1057 {} Indicates messages protected using keys 1058 derived from a [sender]_handshake_traffic_secret. 1060 [] Indicates messages protected using keys 1061 derived from [sender]_application_traffic_secret_N 1063 Figure 4: Message flow for a zero round trip handshake 1065 IMPORTANT NOTE: The security properties for 0-RTT data are weaker 1066 than those for other kinds of TLS data. Specifically: 1068 1. This data is not forward secret, as it is encrypted solely under 1069 keys derived using the offered PSK. 1071 2. There are no guarantees of non-replay between connections. 1072 Protection against replay for ordinary TLS 1.3 1-RTT data is 1073 provided via the server's Random value, but 0-RTT data does not 1074 depend on the ServerHello and therefore has weaker guarantees. 1075 This is especially relevant if the data is authenticated either 1076 with TLS client authentication or inside the application 1077 protocol. The same warnings apply to any use of the 1078 early_exporter_master_secret. 1080 0-RTT data cannot be duplicated within a connection (i.e., the server 1081 will not process the same data twice for the same connection) and an 1082 attacker will not be able to make 0-RTT data appear to be 1-RTT data 1083 (because it is protected with different keys.) Appendix E.5 contains 1084 a description of potential attacks and Section 8 describes mechanisms 1085 which the server can use to limit the impact of replay. 1087 3. Presentation Language 1089 This document deals with the formatting of data in an external 1090 representation. The following very basic and somewhat casually 1091 defined presentation syntax will be used. 1093 3.1. Basic Block Size 1095 The representation of all data items is explicitly specified. The 1096 basic data block size is one byte (i.e., 8 bits). Multiple byte data 1097 items are concatenations of bytes, from left to right, from top to 1098 bottom. From the byte stream, a multi-byte item (a numeric in the 1099 example) is formed (using C notation) by: 1101 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | 1102 ... | byte[n-1]; 1104 This byte ordering for multi-byte values is the commonplace network 1105 byte order or big-endian format. 1107 3.2. Miscellaneous 1109 Comments begin with "/*" and end with "*/". 1111 Optional components are denoted by enclosing them in "[[ ]]" double 1112 brackets. 1114 Single-byte entities containing uninterpreted data are of type 1115 opaque. 1117 3.3. Vectors 1119 A vector (single-dimensioned array) is a stream of homogeneous data 1120 elements. The size of the vector may be specified at documentation 1121 time or left unspecified until runtime. In either case, the length 1122 declares the number of bytes, not the number of elements, in the 1123 vector. The syntax for specifying a new type, T', that is a fixed- 1124 length vector of type T is 1126 T T'[n]; 1128 Here, T' occupies n bytes in the data stream, where n is a multiple 1129 of the size of T. The length of the vector is not included in the 1130 encoded stream. 1132 In the following example, Datum is defined to be three consecutive 1133 bytes that the protocol does not interpret, while Data is three 1134 consecutive Datum, consuming a total of nine bytes. 1136 opaque Datum[3]; /* three uninterpreted bytes */ 1137 Datum Data[9]; /* 3 consecutive 3-byte vectors */ 1139 Variable-length vectors are defined by specifying a subrange of legal 1140 lengths, inclusively, using the notation . When 1141 these are encoded, the actual length precedes the vector's contents 1142 in the byte stream. The length will be in the form of a number 1143 consuming as many bytes as required to hold the vector's specified 1144 maximum (ceiling) length. A variable-length vector with an actual 1145 length field of zero is referred to as an empty vector. 1147 T T'; 1149 In the following example, mandatory is a vector that must contain 1150 between 300 and 400 bytes of type opaque. It can never be empty. 1151 The actual length field consumes two bytes, a uint16, which is 1152 sufficient to represent the value 400 (see Section 3.4). Similarly, 1153 longer can represent up to 800 bytes of data, or 400 uint16 elements, 1154 and it may be empty. Its encoding will include a two-byte actual 1155 length field prepended to the vector. The length of an encoded 1156 vector must be an exact multiple of the length of a single element 1157 (e.g., a 17-byte vector of uint16 would be illegal). 1159 opaque mandatory<300..400>; 1160 /* length field is 2 bytes, cannot be empty */ 1161 uint16 longer<0..800>; 1162 /* zero to 400 16-bit unsigned integers */ 1164 3.4. Numbers 1166 The basic numeric data type is an unsigned byte (uint8). All larger 1167 numeric data types are formed from fixed-length series of bytes 1168 concatenated as described in Section 3.1 and are also unsigned. The 1169 following numeric types are predefined. 1171 uint8 uint16[2]; 1172 uint8 uint24[3]; 1173 uint8 uint32[4]; 1174 uint8 uint64[8]; 1176 All values, here and elsewhere in the specification, are stored in 1177 network byte (big-endian) order; the uint32 represented by the hex 1178 bytes 01 02 03 04 is equivalent to the decimal value 16909060. 1180 3.5. Enumerateds 1182 An additional sparse data type is available called enum. Each 1183 definition is a different type. Only enumerateds of the same type 1184 may be assigned or compared. Every element of an enumerated must be 1185 assigned a value, as demonstrated in the following example. Since 1186 the elements of the enumerated are not ordered, they can be assigned 1187 any unique value, in any order. 1189 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; 1191 Future extensions or additions to the protocol may define new values. 1192 Implementations need to be able to parse and ignore unknown values 1193 unless the definition of the field states otherwise. 1195 An enumerated occupies as much space in the byte stream as would its 1196 maximal defined ordinal value. The following definition would cause 1197 one byte to be used to carry fields of type Color. 1199 enum { red(3), blue(5), white(7) } Color; 1201 One may optionally specify a value without its associated tag to 1202 force the width definition without defining a superfluous element. 1204 In the following example, Taste will consume two bytes in the data 1205 stream but can only assume the values 1, 2, or 4 in the current 1206 version of the protocol. 1208 enum { sweet(1), sour(2), bitter(4), (32000) } Taste; 1210 The names of the elements of an enumeration are scoped within the 1211 defined type. In the first example, a fully qualified reference to 1212 the second element of the enumeration would be Color.blue. Such 1213 qualification is not required if the target of the assignment is well 1214 specified. 1216 Color color = Color.blue; /* overspecified, legal */ 1217 Color color = blue; /* correct, type implicit */ 1219 The names assigned to enumerateds do not need to be unique. The 1220 numerical value can describe a range over which the same name 1221 applies. The value includes the minimum and maximum inclusive values 1222 in that range, separated by two period characters. This is 1223 principally useful for reserving regions of the space. 1225 enum { sad(0), meh(1..254), happy(255) } Mood; 1227 3.6. Constructed Types 1229 Structure types may be constructed from primitive types for 1230 convenience. Each specification declares a new, unique type. The 1231 syntax for definition is much like that of C. 1233 struct { 1234 T1 f1; 1235 T2 f2; 1236 ... 1237 Tn fn; 1238 } [[T]]; 1240 The fields within a structure may be qualified using the type's name, 1241 with a syntax much like that available for enumerateds. For example, 1242 T.f2 refers to the second field of the previous declaration. 1243 Structure definitions may be embedded. Anonymous structs may also be 1244 defined inside other structures. 1246 3.7. Constants 1248 Fields and variables may be assigned a fixed value using "=", as in: 1250 struct { 1251 T1 f1 = 8; /* T.f1 must always be 8 */ 1252 T2 f2; 1253 } T; 1255 3.8. Variants 1257 Defined structures may have variants based on some knowledge that is 1258 available within the environment. The selector must be an enumerated 1259 type that defines the possible variants the structure defines. The 1260 body of the variant structure may be given a label for reference. 1261 The mechanism by which the variant is selected at runtime is not 1262 prescribed by the presentation language. 1264 struct { 1265 T1 f1; 1266 T2 f2; 1267 .... 1268 Tn fn; 1269 select (E) { 1270 case e1: Te1; 1271 case e2: Te2; 1272 .... 1273 case en: Ten; 1274 } [[fv]]; 1275 } [[Tv]]; 1277 For example: 1279 enum { apple(0), orange(1) } VariantTag; 1281 struct { 1282 uint16 number; 1283 opaque string<0..10>; /* variable length */ 1284 } V1; 1286 struct { 1287 uint32 number; 1288 opaque string[10]; /* fixed length */ 1289 } V2; 1291 struct { 1292 VariantTag type; 1293 select (VariantRecord.type) { 1294 case apple: V1; 1295 case orange: V2; 1296 }; 1297 } VariantRecord; 1299 4. Handshake Protocol 1301 The handshake protocol is used to negotiate the security parameters 1302 of a connection. Handshake messages are supplied to the TLS record 1303 layer, where they are encapsulated within one or more TLSPlaintext or 1304 TLSCiphertext structures, which are processed and transmitted as 1305 specified by the current active connection state. 1307 enum { 1308 client_hello(1), 1309 server_hello(2), 1310 new_session_ticket(4), 1311 end_of_early_data(5), 1312 hello_retry_request(6), 1313 encrypted_extensions(8), 1314 certificate(11), 1315 certificate_request(13), 1316 certificate_verify(15), 1317 finished(20), 1318 key_update(24), 1319 message_hash(254), 1320 (255) 1321 } HandshakeType; 1323 struct { 1324 HandshakeType msg_type; /* handshake type */ 1325 uint24 length; /* bytes in message */ 1326 select (Handshake.msg_type) { 1327 case client_hello: ClientHello; 1328 case server_hello: ServerHello; 1329 case end_of_early_data: EndOfEarlyData; 1330 case hello_retry_request: HelloRetryRequest; 1331 case encrypted_extensions: EncryptedExtensions; 1332 case certificate_request: CertificateRequest; 1333 case certificate: Certificate; 1334 case certificate_verify: CertificateVerify; 1335 case finished: Finished; 1336 case new_session_ticket: NewSessionTicket; 1337 case key_update: KeyUpdate; 1338 } body; 1339 } Handshake; 1341 Protocol messages MUST be sent in the order defined in Section 4.4.1 1342 and shown in the diagrams in Section 2. A peer which receives a 1343 handshake message in an unexpected order MUST abort the handshake 1344 with an "unexpected_message" alert. 1346 New handshake message types are assigned by IANA as described in 1347 Section 11. 1349 4.1. Key Exchange Messages 1351 The key exchange messages are used to determine the security 1352 capabilities of the client and the server and to establish shared 1353 secrets including the traffic keys used to protect the rest of the 1354 handshake and the data. 1356 4.1.1. Cryptographic Negotiation 1358 In TLS, the cryptographic negotiation proceeds by the client offering 1359 the following four sets of options in its ClientHello: 1361 - A list of cipher suites which indicates the AEAD algorithm/HKDF 1362 hash pairs which the client supports. 1364 - A "supported_groups" (Section 4.2.6) extension which indicates the 1365 (EC)DHE groups which the client supports and a "key_share" 1366 (Section 4.2.7) extension which contains (EC)DHE shares for some 1367 or all of these groups. 1369 - A "signature_algorithms" (Section 4.2.3) extension which indicates 1370 the signature algorithms which the client can accept. 1372 - A "pre_shared_key" (Section 4.2.10) extension which contains a 1373 list of symmetric key identities known to the client and a 1374 "psk_key_exchange_modes" (Section 4.2.8) extension which indicates 1375 the key exchange modes that may be used with PSKs. 1377 If the server does not select a PSK, then the first three of these 1378 options are entirely orthogonal: the server independently selects a 1379 cipher suite, an (EC)DHE group and key share for key establishment, 1380 and a signature algorithm/certificate pair to authenticate itself to 1381 the client. If there is no overlap between the received 1382 "supported_groups" and the groups supported by the server then the 1383 server MUST abort the handshake with a "handshake_failure" or an 1384 "insufficient_security" alert. 1386 If the server selects a PSK, then it MUST also select a key 1387 establishment mode from the set indicated by client's 1388 "psk_key_exchange_modes" extension (at present, PSK alone or with 1389 (EC)DHE). Note that if the PSK can be used without (EC)DHE then non- 1390 overlap in the "supported_groups" parameters need not be fatal, as it 1391 is in the non-PSK case discussed in the previous paragraph. 1393 If the server selects an (EC)DHE group and the client did not offer a 1394 compatible "key_share" extension in the initial ClientHello, the 1395 server MUST respond with a HelloRetryRequest (Section 4.1.4) message. 1397 If the server successfully selects parameters and does not require a 1398 HelloRetryRequest, it indicates the selected parameters in the 1399 ServerHello as follows: 1401 - If PSK is being used, then the server will send a "pre_shared_key" 1402 extension indicating the selected key. 1404 - If PSK is not being used, then (EC)DHE and certificate-based 1405 authentication are always used. 1407 - When (EC)DHE is in use, the server will also provide a "key_share" 1408 extension. 1410 - When authenticating via a certificate, the server will send the 1411 Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3) 1412 messages. In TLS 1.3 as defined by this document, either a PSK or 1413 a certificate is always used, but not both. Future documents may 1414 define how to use them together. 1416 If the server is unable to negotiate a supported set of parameters 1417 (i.e., there is no overlap between the client and server parameters), 1418 it MUST abort the handshake with either a "handshake_failure" or 1419 "insufficient_security" fatal alert (see Section 6). 1421 4.1.2. Client Hello 1423 When a client first connects to a server, it is REQUIRED to send the 1424 ClientHello as its first message. The client will also send a 1425 ClientHello when the server has responded to its ClientHello with a 1426 HelloRetryRequest. In that case, the client MUST send the same 1427 ClientHello (without modification) except: 1429 - If a "key_share" extension was supplied in the HelloRetryRequest, 1430 replacing the list of shares with a list containing a single 1431 KeyShareEntry from the indicated group. 1433 - Removing the "early_data" extension (Section 4.2.9) if one was 1434 present. Early data is not permitted after HelloRetryRequest. 1436 - Including a "cookie" extension if one was provided in the 1437 HelloRetryRequest. 1439 - Updating the "pre_shared_key" extension if present by recomputing 1440 the "obfuscated_ticket_age" and binder values and (optionally) 1441 removing any PSKs which are incompatible with the server's 1442 indicated cipher suite. 1444 Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS 1445 1.3 and receives a ClientHello at any other time, it MUST terminate 1446 the connection with an "unexpected_message" alert. 1448 If a server established a TLS connection with a previous version of 1449 TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST 1450 retain the previous protocol version. In particular, it MUST NOT 1451 negotiate TLS 1.3. 1453 Structure of this message: 1455 uint16 ProtocolVersion; 1456 opaque Random[32]; 1458 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1460 struct { 1461 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 1462 Random random; 1463 opaque legacy_session_id<0..32>; 1464 CipherSuite cipher_suites<2..2^16-2>; 1465 opaque legacy_compression_methods<1..2^8-1>; 1466 Extension extensions<8..2^16-1>; 1467 } ClientHello; 1469 legacy_version In previous versions of TLS, this field was used for 1470 version negotiation and represented the highest version number 1471 supported by the client. Experience has shown that many servers 1472 do not properly implement version negotiation, leading to "version 1473 intolerance" in which the server rejects an otherwise acceptable 1474 ClientHello with a version number higher than it supports. In TLS 1475 1.3, the client indicates its version preferences in the 1476 "supported_versions" extension (Section 4.2.1) and the 1477 legacy_version field MUST be set to 0x0303, which is the version 1478 number for TLS 1.2. (See Appendix D for details about backward 1479 compatibility.) 1481 random 32 bytes generated by a secure random number generator. See 1482 Appendix C for additional information. 1484 legacy_session_id Versions of TLS before TLS 1.3 supported a 1485 "session resumption" feature which has been merged with Pre-Shared 1486 Keys in this version (see Section 2.2). This field MUST be 1487 ignored by a server negotiating TLS 1.3 and MUST be set as a zero 1488 length vector (i.e., a single zero byte length field) by clients 1489 that do not have a cached session ID set by a pre-TLS 1.3 server. 1491 cipher_suites This is a list of the symmetric cipher options 1492 supported by the client, specifically the record protection 1493 algorithm (including secret key length) and a hash to be used with 1494 HKDF, in descending order of client preference. If the list 1495 contains cipher suites that the server does not recognize, support 1496 or wish to use, the server MUST ignore those cipher suites and 1497 process the remaining ones as usual. Values are defined in 1498 Appendix B.4. If the client is attempting a PSK key 1499 establishment, it SHOULD advertise at least one cipher suite 1500 indicating a Hash associated with the PSK. 1502 legacy_compression_methods Versions of TLS before 1.3 supported 1503 compression with the list of supported compression methods being 1504 sent in this field. For every TLS 1.3 ClientHello, this vector 1505 MUST contain exactly one byte set to zero, which corresponds to 1506 the "null" compression method in prior versions of TLS. If a TLS 1507 1.3 ClientHello is received with any other value in this field, 1508 the server MUST abort the handshake with an "illegal_parameter" 1509 alert. Note that TLS 1.3 servers might receive TLS 1.2 or prior 1510 ClientHellos which contain other compression methods and MUST 1511 follow the procedures for the appropriate prior version of TLS. 1512 TLS 1.3 ClientHellos are identified as having a legacy_version of 1513 0x0303 and a supported_versions extension present with 0x0304 as 1514 the highest version indicated therein. 1516 extensions Clients request extended functionality from servers by 1517 sending data in the extensions field. The actual "Extension" 1518 format is defined in Section 4.2. In TLS 1.3, use of certain 1519 extensions is mandatory, as functionality is moved into extensions 1520 to preserve ClientHello compatibility with previous versions of 1521 TLS. Servers MUST ignore unrecognized extensions. 1523 All versions of TLS allow an extensions field to optionally follow 1524 the compression_methods field. TLS 1.3 ClientHello messages always 1525 contain extensions (minimally "supported_versions", otherwise they 1526 will be interpreted as TLS 1.2 ClientHello messages). However, TLS 1527 1.3 servers might receive ClientHello messages without an extensions 1528 field from prior versions of TLS. The presence of extensions can be 1529 detected by determining whether there are bytes following the 1530 compression_methods field at the end of the ClientHello. Note that 1531 this method of detecting optional data differs from the normal TLS 1532 method of having a variable-length field, but it is used for 1533 compatibility with TLS before extensions were defined. TLS 1.3 1534 servers will need to perform this check first and only attempt to 1535 negotiate TLS 1.3 if a "supported_version" extension is present. If 1536 negotiating a version of TLS prior to 1.3, a server MUST check that 1537 the message either contains no data after legacy_compression_methods 1538 or that it contains a valid extensions block with no data following. 1539 If not, then it MUST abort the handshake with a "decode_error" alert. 1541 In the event that a client requests additional functionality using 1542 extensions, and this functionality is not supplied by the server, the 1543 client MAY abort the handshake. 1545 After sending the ClientHello message, the client waits for a 1546 ServerHello or HelloRetryRequest message. If early data is in use, 1547 the client may transmit early application data Section 2.3 while 1548 waiting for the next handshake message. 1550 4.1.3. Server Hello 1552 The server will send this message in response to a ClientHello 1553 message to proceed with the handshake if it is able to negotiate an 1554 acceptable set of handshake parameters based on the ClientHello. 1556 Structure of this message: 1558 struct { 1559 ProtocolVersion version; 1560 Random random; 1561 CipherSuite cipher_suite; 1562 Extension extensions<6..2^16-1>; 1563 } ServerHello; 1565 version This field contains the version of TLS negotiated for this 1566 connection. Servers MUST select a version from the list in 1567 ClientHello's supported_versions extension, or otherwise negotiate 1568 TLS 1.2 or previous. A client that receives a version that was 1569 not offered MUST abort the handshake. For this version of the 1570 specification, the version is 0x0304. (See Appendix D for details 1571 about backward compatibility.) 1573 random 32 bytes generated by a secure random number generator. See 1574 Appendix C for additional information. The last eight bytes MUST 1575 be overwritten as described below if negotiating TLS 1.2 or TLS 1576 1.1, but the remaining bytes MUST be random. This structure is 1577 generated by the server and MUST be generated independently of the 1578 ClientHello.random. 1580 cipher_suite The single cipher suite selected by the server from the 1581 list in ClientHello.cipher_suites. A client which receives a 1582 cipher suite that was not offered MUST abort the handshake with an 1583 "illegal_parameter" alert. 1585 extensions A list of extensions. The ServerHello MUST only include 1586 extensions which are required to establish the cryptographic 1587 context. Currently the only such extensions are "key_share" and 1588 "pre_shared_key". All current TLS 1.3 ServerHello messages will 1589 contain one of these two extensions, or both when using a PSK with 1590 (EC)DHE key establishment. The remaining extensions are sent 1591 separately in the EncryptedExtensions message. 1593 TLS 1.3 has a downgrade protection mechanism embedded in the server's 1594 random value. TLS 1.3 servers which negotiate TLS 1.2 or below in 1595 response to a ClientHello MUST set the last eight bytes of their 1596 Random value specially. 1598 If negotiating TLS 1.2, TLS 1.3 servers MUST set the last eight bytes 1599 of their Random value to the bytes: 1601 44 4F 57 4E 47 52 44 01 1603 If negotiating TLS 1.1 or below, TLS 1.3 servers MUST and TLS 1.2 1604 servers SHOULD set the last eight bytes of their Random value to the 1605 bytes: 1607 44 4F 57 4E 47 52 44 00 1609 TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below 1610 MUST check that the last eight bytes are not equal to either of these 1611 values. TLS 1.2 clients SHOULD also check that the last eight bytes 1612 are not equal to the second value if the ServerHello indicates TLS 1613 1.1 or below. If a match is found, the client MUST abort the 1614 handshake with an "illegal_parameter" alert. This mechanism provides 1615 limited protection against downgrade attacks over and above what is 1616 provided by the Finished exchange: because the ServerKeyExchange, a 1617 message present in TLS 1.2 and below, includes a signature over both 1618 random values, it is not possible for an active attacker to modify 1619 the random values without detection as long as ephemeral ciphers are 1620 used. It does not provide downgrade protection when static RSA is 1621 used. 1623 Note: This is a change from [RFC5246], so in practice many TLS 1.2 1624 clients and servers will not behave as specified above. 1626 A legacy TLS client performing renegotiation with TLS 1.2 or prior 1627 and which receives a TLS 1.3 ServerHello during renegotiation MUST 1628 abort the handshake with a "protocol_version" alert. Note that 1629 renegotiation is not possible when TLS 1.3 has been negotiated. 1631 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of 1632 draft versions (see Section 4.2.1.1) of this specification SHOULD NOT 1633 implement this mechanism on either client and server. A pre-RFC 1634 client connecting to RFC servers, or vice versa, will appear to 1635 downgrade to TLS 1.2. With the mechanism enabled, this will cause an 1636 interoperability failure. 1638 4.1.4. Hello Retry Request 1640 The server will send this message in response to a ClientHello 1641 message if it is able to find an acceptable set of parameters but the 1642 ClientHello does not contain sufficient information to proceed with 1643 the handshake. 1645 Structure of this message: 1647 struct { 1648 ProtocolVersion server_version; 1649 CipherSuite cipher_suite; 1650 Extension extensions<2..2^16-1>; 1651 } HelloRetryRequest; 1653 The version, cipher_suite, and extensions fields have the same 1654 meanings as their corresponding values in the ServerHello. The 1655 server SHOULD send only the extensions necessary for the client to 1656 generate a correct ClientHello pair. As with ServerHello, a 1657 HelloRetryRequest MUST NOT contain any extensions that were not first 1658 offered by the client in its ClientHello, with the exception of 1659 optionally the "cookie" (see Section 4.2.2) extension. 1661 Upon receipt of a HelloRetryRequest, the client MUST verify that the 1662 extensions block is not empty and otherwise MUST abort the handshake 1663 with a "decode_error" alert. Clients MUST abort the handshake with 1664 an "illegal_parameter" alert if the HelloRetryRequest would not 1665 result in any change in the ClientHello. If a client receives a 1666 second HelloRetryRequest in the same connection (i.e., where the 1667 ClientHello was itself in response to a HelloRetryRequest), it MUST 1668 abort the handshake with an "unexpected_message" alert. 1670 Otherwise, the client MUST process all extensions in the 1671 HelloRetryRequest and send a second updated ClientHello. The 1672 HelloRetryRequest extensions defined in this specification are: 1674 - cookie (see Section 4.2.2) 1676 - key_share (see Section 4.2.7) 1678 In addition, in its updated ClientHello, the client SHOULD NOT offer 1679 any pre-shared keys associated with a hash other than that of the 1680 selected cipher suite. This allows the client to avoid having to 1681 compute partial hash transcripts for multiple hashes in the second 1682 ClientHello. A client which receives a cipher suite that was not 1683 offered MUST abort the handshake. Servers MUST ensure that they 1684 negotiate the same cipher suite when receiving a conformant updated 1685 ClientHello (if the server selects the cipher suite as the first step 1686 in the negotiation, then this will happen automatically). Upon 1687 receiving the ServerHello, clients MUST check that the cipher suite 1688 supplied in the ServerHello is the same as that in the 1689 HelloRetryRequest and otherwise abort the handshake with an 1690 "illegal_parameter" alert. 1692 4.2. Extensions 1694 A number of TLS messages contain tag-length-value encoded extensions 1695 structures. 1697 struct { 1698 ExtensionType extension_type; 1699 opaque extension_data<0..2^16-1>; 1700 } Extension; 1702 enum { 1703 server_name(0), /* RFC 6066 */ 1704 max_fragment_length(1), /* RFC 6066 */ 1705 status_request(5), /* RFC 6066 */ 1706 supported_groups(10), /* RFC 4492, 7919 */ 1707 signature_algorithms(13), /* RFC 5246 */ 1708 use_srtp(14), /* RFC 5764 */ 1709 heartbeat(15), /* RFC 6520 */ 1710 application_layer_protocol_negotiation(16), /* RFC 7301 */ 1711 signed_certificate_timestamp(18), /* RFC 6962 */ 1712 client_certificate_type(19), /* RFC 7250 */ 1713 server_certificate_type(20), /* RFC 7250 */ 1714 padding(21), /* RFC 7685 */ 1715 key_share(40), /* [[this document]] */ 1716 pre_shared_key(41), /* [[this document]] */ 1717 early_data(42), /* [[this document]] */ 1718 supported_versions(43), /* [[this document]] */ 1719 cookie(44), /* [[this document]] */ 1720 psk_key_exchange_modes(45), /* [[this document]] */ 1721 certificate_authorities(47), /* [[this document]] */ 1722 oid_filters(48), /* [[this document]] */ 1723 post_handshake_auth(49), /* [[this document]] */ 1724 (65535) 1725 } ExtensionType; 1727 Here: 1729 - "extension_type" identifies the particular extension type. 1731 - "extension_data" contains information specific to the particular 1732 extension type. 1734 The list of extension types is maintained by IANA as described in 1735 Section 11. 1737 Extensions are generally structured in a request/response fashion, 1738 though some extensions are just indications with no corresponding 1739 response. The client sends its extension requests in the ClientHello 1740 message and the server sends its extension responses in the 1741 ServerHello, EncryptedExtensions, HelloRetryRequest and Certificate 1742 messages. The server sends extension requests in the 1743 CertificateRequest message which a client MAY respond to with a 1744 Certificate message. The server MAY also send unsolicited extensions 1745 in the NewSessionTicket, though the client does not respond directly 1746 to these. 1748 Implementations MUST NOT send extension responses if the remote 1749 endpoint did not send the corresponding extension requests, with the 1750 exception of the "cookie" extension in HelloRetryRequest. Upon 1751 receiving such an extension, an endpoint MUST abort the handshake 1752 with an "unsupported_extension" alert. 1754 The table below indicates the messages where a given extension may 1755 appear, using the following notation: CH (ClientHello), SH 1756 (ServerHello), EE (EncryptedExtensions), CT (Certificate), CR 1757 (CertificateRequest), NST (NewSessionTicket) and HRR 1758 (HelloRetryRequest). If an implementation receives an extension 1759 which it recognizes and which is not specified for the message in 1760 which it appears it MUST abort the handshake with an 1761 "illegal_parameter" alert. 1763 +--------------------------------------------------+-------------+ 1764 | Extension | TLS 1.3 | 1765 +--------------------------------------------------+-------------+ 1766 | server_name [RFC6066] | CH, EE | 1767 | | | 1768 | max_fragment_length [RFC6066] | CH, EE | 1769 | | | 1770 | status_request [RFC6066] | CH, CR, CT | 1771 | | | 1772 | supported_groups [RFC7919] | CH, EE | 1773 | | | 1774 | signature_algorithms [RFC5246] | CH, CR | 1775 | | | 1776 | use_srtp [RFC5764] | CH, EE | 1777 | | | 1778 | heartbeat [RFC6520] | CH, EE | 1779 | | | 1780 | application_layer_protocol_negotiation [RFC7301] | CH, EE | 1781 | | | 1782 | signed_certificate_timestamp [RFC6962] | CH, CR, CT | 1783 | | | 1784 | client_certificate_type [RFC7250] | CH, EE | 1785 | | | 1786 | server_certificate_type [RFC7250] | CH, CT | 1787 | | | 1788 | padding [RFC7685] | CH | 1789 | | | 1790 | key_share [[this document]] | CH, SH, HRR | 1791 | | | 1792 | pre_shared_key [[this document]] | CH, SH | 1793 | | | 1794 | psk_key_exchange_modes [[this document]] | CH | 1795 | | | 1796 | early_data [[this document]] | CH, EE, NST | 1797 | | | 1798 | cookie [[this document]] | CH, HRR | 1799 | | | 1800 | supported_versions [[this document]] | CH | 1801 | | | 1802 | certificate_authorities [[this document]] | CH, CR | 1803 | | | 1804 | oid_filters [[this document]] | CR | 1805 | | | 1806 | post_handshake_auth [[this document]] | CH | 1807 +--------------------------------------------------+-------------+ 1809 When multiple extensions of different types are present, the 1810 extensions MAY appear in any order, with the exception of 1811 "pre_shared_key" Section 4.2.10 which MUST be the last extension in 1812 the ClientHello. There MUST NOT be more than one extension of the 1813 same type in a given extension block. 1815 In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each 1816 handshake even when in resumption-PSK mode. However, 0-RTT 1817 parameters are those negotiated in the previous handshake; mismatches 1818 may require rejecting 0-RTT (see Section 4.2.9). 1820 There are subtle (and not so subtle) interactions that may occur in 1821 this protocol between new features and existing features which may 1822 result in a significant reduction in overall security. The following 1823 considerations should be taken into account when designing new 1824 extensions: 1826 - Some cases where a server does not agree to an extension are error 1827 conditions, and some are simply refusals to support particular 1828 features. In general, error alerts should be used for the former 1829 and a field in the server extension response for the latter. 1831 - Extensions should, as far as possible, be designed to prevent any 1832 attack that forces use (or non-use) of a particular feature by 1833 manipulation of handshake messages. This principle should be 1834 followed regardless of whether the feature is believed to cause a 1835 security problem. Often the fact that the extension fields are 1836 included in the inputs to the Finished message hashes will be 1837 sufficient, but extreme care is needed when the extension changes 1838 the meaning of messages sent in the handshake phase. Designers 1839 and implementors should be aware of the fact that until the 1840 handshake has been authenticated, active attackers can modify 1841 messages and insert, remove, or replace extensions. 1843 4.2.1. Supported Versions 1845 struct { 1846 ProtocolVersion versions<2..254>; 1847 } SupportedVersions; 1849 The "supported_versions" extension is used by the client to indicate 1850 which versions of TLS it supports. The extension contains a list of 1851 supported versions in preference order, with the most preferred 1852 version first. Implementations of this specification MUST send this 1853 extension containing all versions of TLS which they are prepared to 1854 negotiate (for this specification, that means minimally 0x0304, but 1855 if previous versions of TLS are allowed to be negotiated, they MUST 1856 be present as well). 1858 If this extension is not present, servers which are compliant with 1859 this specification MUST negotiate TLS 1.2 or prior as specified in 1860 [RFC5246], even if ClientHello.legacy_version is 0x0304 or later. 1861 Servers MAY abort the handshake upon receiving a ClientHello with 1862 legacy_version 0x0304 or later. 1864 If this extension is present, servers MUST ignore the 1865 ClientHello.legacy_version value and MUST use only the 1866 "supported_versions" extension to determine client preferences. 1867 Servers MUST only select a version of TLS present in that extension 1868 and MUST ignore any unknown versions that are present in that 1869 extension. Note that this mechanism makes it possible to negotiate a 1870 version prior to TLS 1.2 if one side supports a sparse range. 1871 Implementations of TLS 1.3 which choose to support prior versions of 1872 TLS SHOULD support TLS 1.2. Servers should be prepared to receive 1873 ClientHellos that include this extension but do not include 0x0304 in 1874 the list of versions. 1876 The server MUST NOT send the "supported_versions" extension. The 1877 server's selected version is contained in the ServerHello.version 1878 field as in previous versions of TLS. 1880 4.2.1.1. Draft Version Indicator 1882 RFC EDITOR: PLEASE REMOVE THIS SECTION 1884 While the eventual version indicator for the RFC version of TLS 1.3 1885 will be 0x0304, implementations of draft versions of this 1886 specification SHOULD instead advertise 0x7f00 | draft_version in 1887 ServerHello.version, and HelloRetryRequest.server_version. For 1888 instance, draft-17 would be encoded as the 0x7f11. This allows pre- 1889 RFC implementations to safely negotiate with each other, even if they 1890 would otherwise be incompatible. 1892 4.2.2. Cookie 1894 struct { 1895 opaque cookie<1..2^16-1>; 1896 } Cookie; 1898 Cookies serve two primary purposes: 1900 - Allowing the server to force the client to demonstrate 1901 reachability at their apparent network address (thus providing a 1902 measure of DoS protection). This is primarily useful for non- 1903 connection-oriented transports (see [RFC6347] for an example of 1904 this). 1906 - Allowing the server to offload state to the client, thus allowing 1907 it to send a HelloRetryRequest without storing any state. The 1908 server can do this by storing the hash of the ClientHello in the 1909 HelloRetryRequest cookie (protected with some suitable integrity 1910 algorithm). 1912 When sending a HelloRetryRequest, the server MAY provide a "cookie" 1913 extension to the client (this is an exception to the usual rule that 1914 the only extensions that may be sent are those that appear in the 1915 ClientHello). When sending the new ClientHello, the client MUST copy 1916 the contents of the extension received in the HelloRetryRequest into 1917 a "cookie" extension in the new ClientHello. Clients MUST NOT use 1918 cookies in subsequent connections. 1920 4.2.3. Signature Algorithms 1922 The client uses the "signature_algorithms" extension to indicate to 1923 the server which signature algorithms may be used in digital 1924 signatures. Clients which desire the server to authenticate itself 1925 via a certificate MUST send this extension. If a server is 1926 authenticating via a certificate and the client has not sent a 1927 "signature_algorithms" extension, then the server MUST abort the 1928 handshake with a "missing_extension" alert (see Section 9.2). 1930 The "extension_data" field of this extension in a ClientHello 1931 contains a SignatureSchemeList value: 1933 enum { 1934 /* RSASSA-PKCS1-v1_5 algorithms */ 1935 rsa_pkcs1_sha256(0x0401), 1936 rsa_pkcs1_sha384(0x0501), 1937 rsa_pkcs1_sha512(0x0601), 1939 /* ECDSA algorithms */ 1940 ecdsa_secp256r1_sha256(0x0403), 1941 ecdsa_secp384r1_sha384(0x0503), 1942 ecdsa_secp521r1_sha512(0x0603), 1944 /* RSASSA-PSS algorithms */ 1945 rsa_pss_sha256(0x0804), 1946 rsa_pss_sha384(0x0805), 1947 rsa_pss_sha512(0x0806), 1949 /* EdDSA algorithms */ 1950 ed25519(0x0807), 1951 ed448(0x0808), 1953 /* Legacy algorithms */ 1954 rsa_pkcs1_sha1(0x0201), 1955 ecdsa_sha1(0x0203), 1957 /* Reserved Code Points */ 1958 private_use(0xFE00..0xFFFF), 1959 (0xFFFF) 1960 } SignatureScheme; 1962 struct { 1963 SignatureScheme supported_signature_algorithms<2..2^16-2>; 1964 } SignatureSchemeList; 1966 Note: This enum is named "SignatureScheme" because there is already a 1967 "SignatureAlgorithm" type in TLS 1.2, which this replaces. We use 1968 the term "signature algorithm" throughout the text. 1970 Each SignatureScheme value lists a single signature algorithm that 1971 the client is willing to verify. The values are indicated in 1972 descending order of preference. Note that a signature algorithm 1973 takes as input an arbitrary-length message, rather than a digest. 1974 Algorithms which traditionally act on a digest should be defined in 1975 TLS to first hash the input with a specified hash algorithm and then 1976 proceed as usual. The code point groups listed above have the 1977 following meanings: 1979 RSASSA-PKCS1-v1_5 algorithms Indicates a signature algorithm using 1980 RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm 1981 as defined in [SHS]. These values refer solely to signatures 1982 which appear in certificates (see Section 4.4.2.2) and are not 1983 defined for use in signed TLS handshake messages. 1985 ECDSA algorithms Indicates a signature algorithm using ECDSA 1986 [ECDSA], the corresponding curve as defined in ANSI X9.62 [X962] 1987 and FIPS 186-4 [DSS], and the corresponding hash algorithm as 1988 defined in [SHS]. The signature is represented as a DER-encoded 1989 [X690] ECDSA-Sig-Value structure. 1991 RSASSA-PSS algorithms Indicates a signature algorithm using RSASSA- 1992 PSS [RFC8017] with mask generation function 1. The digest used in 1993 the mask generation function and the digest being signed are both 1994 the corresponding hash algorithm as defined in [SHS]. When used 1995 in signed TLS handshake messages, the length of the salt MUST be 1996 equal to the length of the digest output. This codepoint is new 1997 in this document and is also defined for use with TLS 1.2. 1999 EdDSA algorithms Indicates a signature algorithm using EdDSA as 2000 defined in [RFC8032] or its successors. Note that these 2001 correspond to the "PureEdDSA" algorithms and not the "prehash" 2002 variants. 2004 Legacy algorithms Indicates algorithms which are being deprecated 2005 because they use algorithms with known weaknesses, specifically 2006 SHA-1 which is used in this context with either with RSA using 2007 RSASSA-PKCS1-v1_5 or ECDSA. These values refer solely to 2008 signatures which appear in certificates (see Section 4.4.2.2) and 2009 are not defined for use in signed TLS handshake messages. 2010 Endpoints SHOULD NOT negotiate these algorithms but are permitted 2011 to do so solely for backward compatibility. Clients offering 2012 these values MUST list them as the lowest priority (listed after 2013 all other algorithms in SignatureSchemeList). TLS 1.3 servers 2014 MUST NOT offer a SHA-1 signed certificate unless no valid 2015 certificate chain can be produced without it (see 2016 Section 4.4.2.2). 2018 The signatures on certificates that are self-signed or certificates 2019 that are trust anchors are not validated since they begin a 2020 certification path (see [RFC5280], Section 3.2). A certificate that 2021 begins a certification path MAY use a signature algorithm that is not 2022 advertised as being supported in the "signature_algorithms" 2023 extension. 2025 Note that TLS 1.2 defines this extension differently. TLS 1.3 2026 implementations willing to negotiate TLS 1.2 MUST behave in 2027 accordance with the requirements of [RFC5246] when negotiating that 2028 version. In particular: 2030 - TLS 1.2 ClientHellos MAY omit this extension. 2032 - In TLS 1.2, the extension contained hash/signature pairs. The 2033 pairs are encoded in two octets, so SignatureScheme values have 2034 been allocated to align with TLS 1.2's encoding. Some legacy 2035 pairs are left unallocated. These algorithms are deprecated as of 2036 TLS 1.3. They MUST NOT be offered or negotiated by any 2037 implementation. In particular, MD5 [SLOTH], SHA-224, and DSA MUST 2038 NOT be used. 2040 - ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature 2041 pairs. However, the old semantics did not constrain the signing 2042 curve. If TLS 1.2 is negotiated, implementations MUST be prepared 2043 to accept a signature that uses any curve that they advertised in 2044 the "supported_groups" extension. 2046 - Implementations that advertise support for RSASSA-PSS (which is 2047 mandatory in TLS 1.3), MUST be prepared to accept a signature 2048 using that scheme even when TLS 1.2 is negotiated. In TLS 1.2, 2049 RSASSA-PSS is used with RSA cipher suites. 2051 4.2.4. Certificate Authorities 2053 The "certificate_authorities" extension is used to indicate the 2054 certificate authorities which an endpoint supports and which SHOULD 2055 be used by the receiving endpoint to guide certificate selection. 2057 The body of the "certificate_authorities" extension consists of a 2058 CertificateAuthoritiesExtension structure. 2060 opaque DistinguishedName<1..2^16-1>; 2062 struct { 2063 DistinguishedName authorities<3..2^16-1>; 2064 } CertificateAuthoritiesExtension; 2066 authorities A list of the distinguished names [X501] of acceptable 2067 certificate authorities, represented in DER-encoded [X690] format. 2068 These distinguished names specify a desired distinguished name for 2069 trust anchor or subordinate CA; thus, this message can be used to 2070 describe known trust anchors as well as a desired authorization 2071 space. 2073 The client MAY send the "certificate_authorities" extension in the 2074 ClientHello message. The server MAY send it in the 2075 CertificateRequest message. 2077 The "trusted_ca_keys" extension, which serves a similar purpose 2078 [RFC6066], but is more complicated, is not used in TLS 1.3 (although 2079 it may appear in ClientHello messages from clients which are offering 2080 prior versions of TLS). 2082 4.2.4.1. OID Filters 2084 The "oid_filters" extension allows servers to provide a set of OID/ 2085 value pairs which it would like the client's certificate to match. 2086 This extension, if provided by the server, MUST only be sent in the 2087 CertificateRequest message. 2089 struct { 2090 opaque certificate_extension_oid<1..2^8-1>; 2091 opaque certificate_extension_values<0..2^16-1>; 2092 } OIDFilter; 2094 struct { 2095 OIDFilter filters<0..2^16-1>; 2096 } OIDFilterExtension; 2098 filters A list of certificate extension OIDs [RFC5280] with their 2099 allowed values and represented in DER-encoded [X690] format. Some 2100 certificate extension OIDs allow multiple values (e.g., Extended 2101 Key Usage). If the server has included a non-empty filters list, 2102 the client certificate included in the response MUST contain all 2103 of the specified extension OIDs that the client recognizes. For 2104 each extension OID recognized by the client, all of the specified 2105 values MUST be present in the client certificate (but the 2106 certificate MAY have other values as well). However, the client 2107 MUST ignore and skip any unrecognized certificate extension OIDs. 2108 If the client ignored some of the required certificate extension 2109 OIDs and supplied a certificate that does not satisfy the request, 2110 the server MAY at its discretion either continue the connection 2111 without client authentication, or abort the handshake with an 2112 "unsupported_certificate" alert. 2114 PKIX RFCs define a variety of certificate extension OIDs and their 2115 corresponding value types. Depending on the type, matching 2116 certificate extension values are not necessarily bitwise-equal. It 2117 is expected that TLS implementations will rely on their PKI libraries 2118 to perform certificate selection using certificate extension OIDs. 2120 This document defines matching rules for two standard certificate 2121 extensions defined in [RFC5280]: 2123 - The Key Usage extension in a certificate matches the request when 2124 all key usage bits asserted in the request are also asserted in 2125 the Key Usage certificate extension. 2127 - The Extended Key Usage extension in a certificate matches the 2128 request when all key purpose OIDs present in the request are also 2129 found in the Extended Key Usage certificate extension. The 2130 special anyExtendedKeyUsage OID MUST NOT be used in the request. 2132 Separate specifications may define matching rules for other 2133 certificate extensions. 2135 4.2.5. Post-Handshake Client Authentication 2137 The "post_handshake_auth" extension is used to indicate that a client 2138 is willing to perform post-handshake authentication Section 4.6.2. 2139 Servers MUST not send a post-handshake CertificateRequest to clients 2140 which do not offer this extension. Servers MUST NOT send this 2141 extension. 2143 The "extension_data" field of the "post_handshake_auth" extension is 2144 zero length. 2146 4.2.6. Negotiated Groups 2148 When sent by the client, the "supported_groups" extension indicates 2149 the named groups which the client supports for key exchange, ordered 2150 from most preferred to least preferred. 2152 Note: In versions of TLS prior to TLS 1.3, this extension was named 2153 "elliptic_curves" and only contained elliptic curve groups. See 2154 [RFC4492] and [RFC7919]. This extension was also used to negotiate 2155 ECDSA curves. Signature algorithms are now negotiated independently 2156 (see Section 4.2.3). 2158 The "extension_data" field of this extension contains a 2159 "NamedGroupList" value: 2161 enum { 2162 /* Elliptic Curve Groups (ECDHE) */ 2163 secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), 2164 x25519(0x001D), x448(0x001E), 2166 /* Finite Field Groups (DHE) */ 2167 ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096 (0x0102), 2168 ffdhe6144(0x0103), ffdhe8192(0x0104), 2170 /* Reserved Code Points */ 2171 ffdhe_private_use(0x01FC..0x01FF), 2172 ecdhe_private_use(0xFE00..0xFEFF), 2173 (0xFFFF) 2174 } NamedGroup; 2176 struct { 2177 NamedGroup named_group_list<2..2^16-1>; 2178 } NamedGroupList; 2180 Elliptic Curve Groups (ECDHE) Indicates support for the 2181 corresponding named curve, defined either in FIPS 186-4 [DSS] or 2182 in [RFC7748]. Values 0xFE00 through 0xFEFF are reserved for 2183 private use. 2185 Finite Field Groups (DHE) Indicates support of the corresponding 2186 finite field group, defined in [RFC7919]. Values 0x01FC through 2187 0x01FF are reserved for private use. 2189 Items in named_group_list are ordered according to the client's 2190 preferences (most preferred choice first). 2192 As of TLS 1.3, servers are permitted to send the "supported_groups" 2193 extension to the client. Clients MUST NOT act upon any information 2194 found in "supported_groups" prior to successful completion of the 2195 handshake but MAY use the information learned from a successfully 2196 completed handshake to change what groups they use in their 2197 "key_share" extension in subsequent connections. If the server has a 2198 group it prefers to the ones in the "key_share" extension but is 2199 still willing to accept the ClientHello, it SHOULD send 2200 "supported_groups" to update the client's view of its preferences; 2201 this extension SHOULD contain all groups the server supports, 2202 regardless of whether they are currently supported by the client. 2204 4.2.7. Key Share 2206 The "key_share" extension contains the endpoint's cryptographic 2207 parameters. 2209 Clients MAY send an empty client_shares vector in order to request 2210 group selection from the server at the cost of an additional round 2211 trip. (see Section 4.1.4) 2213 struct { 2214 NamedGroup group; 2215 opaque key_exchange<1..2^16-1>; 2216 } KeyShareEntry; 2218 group The named group for the key being exchanged. Finite Field 2219 Diffie-Hellman [DH] parameters are described in Section 4.2.7.1; 2220 Elliptic Curve Diffie-Hellman parameters are described in 2221 Section 4.2.7.2. 2223 key_exchange Key exchange information. The contents of this field 2224 are determined by the specified group and its corresponding 2225 definition. 2227 The "extension_data" field of this extension contains a "KeyShare" 2228 value: 2230 struct { 2231 select (Handshake.msg_type) { 2232 case client_hello: 2233 KeyShareEntry client_shares<0..2^16-1>; 2235 case hello_retry_request: 2236 NamedGroup selected_group; 2238 case server_hello: 2239 KeyShareEntry server_share; 2240 }; 2241 } KeyShare; 2243 client_shares A list of offered KeyShareEntry values in descending 2244 order of client preference. This vector MAY be empty if the 2245 client is requesting a HelloRetryRequest. Each KeyShareEntry 2246 value MUST correspond to a group offered in the "supported_groups" 2247 extension and MUST appear in the same order. However, the values 2248 MAY be a non-contiguous subset of the "supported_groups" extension 2249 and MAY omit the most preferred groups. Such a situation could 2250 arise if the most preferred groups are new and unlikely to be 2251 supported in enough places to make pregenerating key shares for 2252 them efficient. 2254 selected_group The mutually supported group the server intends to 2255 negotiate and is requesting a retried ClientHello/KeyShare for. 2257 server_share A single KeyShareEntry value that is in the same group 2258 as one of the client's shares. 2260 Clients can offer an arbitrary number of KeyShareEntry values, each 2261 representing a single set of key exchange parameters. For instance, 2262 a client might offer shares for several elliptic curves or multiple 2263 FFDHE groups. The key_exchange values for each KeyShareEntry MUST be 2264 generated independently. Clients MUST NOT offer multiple 2265 KeyShareEntry values for the same group. Clients MUST NOT offer any 2266 KeyShareEntry values for groups not listed in the client's 2267 "supported_groups" extension. Servers MAY check for violations of 2268 these rules and abort the handshake with an "illegal_parameter" alert 2269 if one is violated. 2271 Upon receipt of this extension in a HelloRetryRequest, the client 2272 MUST verify that (1) the selected_group field corresponds to a group 2273 which was provided in the "supported_groups" extension in the 2274 original ClientHello; and (2) the selected_group field does not 2275 correspond to a group which was provided in the "key_share" extension 2276 in the original ClientHello. If either of these checks fails, then 2277 the client MUST abort the handshake with an "illegal_parameter" 2278 alert. Otherwise, when sending the new ClientHello, the client MUST 2279 replace the original "key_share" extension with one containing only a 2280 new KeyShareEntry for the group indicated in the selected_group field 2281 of the triggering HelloRetryRequest. 2283 If using (EC)DHE key establishment, servers offer exactly one 2284 KeyShareEntry in the ServerHello. This value MUST be in the same 2285 group as the KeyShareEntry value offered by the client that the 2286 server has selected for the negotiated key exchange. Servers MUST 2287 NOT send a KeyShareEntry for any group not indicated in the 2288 "supported_groups" extension and MUST NOT send a KeyShareEntry when 2289 using the "psk_ke" PskKeyExchangeMode. If a HelloRetryRequest was 2290 received by the client, the client MUST verify that the selected 2291 NamedGroup in the ServerHello is the same as that in the 2292 HelloRetryRequest. If this check fails, the client MUST abort the 2293 handshake with an "illegal_parameter" alert. 2295 4.2.7.1. Diffie-Hellman Parameters 2297 Diffie-Hellman [DH] parameters for both clients and servers are 2298 encoded in the opaque key_exchange field of a KeyShareEntry in a 2299 KeyShare structure. The opaque value contains the Diffie-Hellman 2300 public value (Y = g^X mod p) for the specified group (see [RFC7919] 2301 for group definitions) encoded as a big-endian integer and padded to 2302 the left with zeros to the size of p in bytes. 2304 Note: For a given Diffie-Hellman group, the padding results in all 2305 public keys having the same length. 2307 Peers MUST validate each other's public key Y by ensuring that 1 < Y 2308 < p-1. This check ensures that the remote peer is properly behaved 2309 and isn't forcing the local system into a small subgroup. 2311 4.2.7.2. ECDHE Parameters 2313 ECDHE parameters for both clients and servers are encoded in the the 2314 opaque key_exchange field of a KeyShareEntry in a KeyShare structure. 2316 For secp256r1, secp384r1 and secp521r1, the contents are the 2317 serialized value of the following struct: 2319 struct { 2320 uint8 legacy_form = 4; 2321 opaque X[coordinate_length]; 2322 opaque Y[coordinate_length]; 2323 } UncompressedPointRepresentation; 2325 X and Y respectively are the binary representations of the X and Y 2326 values in network byte order. There are no internal length markers, 2327 so each number representation occupies as many octets as implied by 2328 the curve parameters. For P-256 this means that each of X and Y use 2329 32 octets, padded on the left by zeros if necessary. For P-384 they 2330 take 48 octets each, and for P-521 they take 66 octets each. 2332 For the curves secp256r1, secp384r1 and secp521r1, peers MUST 2333 validate each other's public value Y by ensuring that the point is a 2334 valid point on the elliptic curve. The appropriate validation 2335 procedures are defined in Section 4.3.7 of [X962] and alternatively 2336 in Section 5.6.2.6 of [KEYAGREEMENT]. This process consists of three 2337 steps: (1) verify that Y is not the point at infinity (O), (2) verify 2338 that for Y = (x, y) both integers are in the correct interval, (3) 2339 ensure that (x, y) is a correct solution to the elliptic curve 2340 equation. For these curves, implementers do not need to verify 2341 membership in the correct subgroup. 2343 For X25519 and X448, the contents of the public value are the byte 2344 string inputs and outputs of the corresponding functions defined in 2345 [RFC7748], 32 bytes for X25519 and 56 bytes for X448. 2347 Note: Versions of TLS prior to 1.3 permitted point format 2348 negotiation; TLS 1.3 removes this feature in favor of a single point 2349 format for each curve. 2351 4.2.8. Pre-Shared Key Exchange Modes 2353 In order to use PSKs, clients MUST also send a 2354 "psk_key_exchange_modes" extension. The semantics of this extension 2355 are that the client only supports the use of PSKs with these modes, 2356 which restricts both the use of PSKs offered in this ClientHello and 2357 those which the server might supply via NewSessionTicket. 2359 A client MUST provide a "psk_key_exchange_modes" extension if it 2360 offers a "pre_shared_key" extension. If clients offer 2361 "pre_shared_key" without a "psk_key_exchange_modes" extension, 2362 servers MUST abort the handshake. Servers MUST NOT select a key 2363 exchange mode that is not listed by the client. This extension also 2364 restricts the modes for use with PSK resumption; servers SHOULD NOT 2365 send NewSessionTicket with tickets that are not compatible with the 2366 advertised modes; however, if a server does so, the impact will just 2367 be that the client's attempts at resumption fail. 2369 The server MUST NOT send a "psk_key_exchange_modes" extension. 2371 enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; 2373 struct { 2374 PskKeyExchangeMode ke_modes<1..255>; 2375 } PskKeyExchangeModes; 2377 psk_ke PSK-only key establishment. In this mode, the server MUST 2378 NOT supply a "key_share" value. 2380 psk_dhe_ke PSK with (EC)DHE key establishment. In this mode, the 2381 client and servers MUST supply "key_share" values as described in 2382 Section 4.2.7. 2384 4.2.9. Early Data Indication 2386 When a PSK is used, the client can send application data in its first 2387 flight of messages. If the client opts to do so, it MUST supply both 2388 the "early_data" extension as well as the "pre_shared_key" extension. 2390 The "extension_data" field of this extension contains an 2391 "EarlyDataIndication" value. 2393 struct {} Empty; 2395 struct { 2396 select (Handshake.msg_type) { 2397 case new_session_ticket: uint32 max_early_data_size; 2398 case client_hello: Empty; 2399 case encrypted_extensions: Empty; 2400 }; 2401 } EarlyDataIndication; 2403 See Section 4.6.1 for the use of the max_early_data_size field. 2405 The parameters for the 0-RTT data (symmetric cipher suite, ALPN 2406 protocol, etc.) are the same as those which were negotiated in the 2407 connection which established the PSK. The PSK used to encrypt the 2408 early data MUST be the first PSK listed in the client's 2409 "pre_shared_key" extension. 2411 For PSKs provisioned via NewSessionTicket, a server MUST validate 2412 that the ticket age for the selected PSK identity (computed by 2413 subtracting ticket_age_add from PskIdentity.obfuscated_ticket_age 2414 modulo 2^32) is within a small tolerance of the time since the ticket 2415 was issued (see Section 8). If it is not, the server SHOULD proceed 2416 with the handshake but reject 0-RTT, and SHOULD NOT take any other 2417 action that assumes that this ClientHello is fresh. 2419 0-RTT messages sent in the first flight have the same (encrypted) 2420 content types as their corresponding messages sent in other flights 2421 (handshake and application_data) but are protected under different 2422 keys. After receiving the server's Finished message, if the server 2423 has accepted early data, an EndOfEarlyData message will be sent to 2424 indicate the key change. This message will be encrypted with the 2425 0-RTT traffic keys. 2427 A server which receives an "early_data" extension MUST behave in one 2428 of three ways: 2430 - Ignore the extension and return a regular 1-RTT response. The 2431 server then ignores early data by attempting to decrypt received 2432 records in the handshake traffic keys until it is able to receive 2433 the client's second flight and complete an ordinary 1-RTT 2434 handshake, skipping records that fail to decrypt, up to the 2435 configured max_early_data_size. 2437 - Request that the client send another ClientHello by responding 2438 with a HelloRetryRequest. A client MUST NOT include the 2439 "early_data" extension in its followup ClientHello. The server 2440 then ignores early data by skipping all records with external 2441 content type of "application_data" (indicating that they are 2442 encrypted). 2444 - Return its own extension in EncryptedExtensions, indicating that 2445 it intends to process the early data. It is not possible for the 2446 server to accept only a subset of the early data messages. Even 2447 though the server sends a message accepting early data, the actual 2448 early data itself may already be in flight by the time the server 2449 generates this message. 2451 In order to accept early data, the server MUST have accepted a PSK 2452 cipher suite and selected the first key offered in the client's 2453 "pre_shared_key" extension. In addition, it MUST verify that the 2454 following values are consistent with those negotiated in the 2455 connection during which the ticket was established. 2457 - The TLS version number and cipher suite. 2459 - The selected ALPN [RFC7301] protocol, if any. 2461 Future extensions MUST define their interaction with 0-RTT. 2463 If any of these checks fail, the server MUST NOT respond with the 2464 extension and must discard all the first flight data using one of the 2465 first two mechanisms listed above (thus falling back to 1-RTT or 2466 2-RTT). If the client attempts a 0-RTT handshake but the server 2467 rejects it, the server will generally not have the 0-RTT record 2468 protection keys and must instead use trial decryption (either with 2469 the 1-RTT handshake keys or by looking for a cleartext ClientHello in 2470 the case of HelloRetryRequest) to find the first non-0RTT message. 2472 If the server chooses to accept the "early_data" extension, then it 2473 MUST comply with the same error handling requirements specified for 2474 all records when processing early data records. Specifically, if the 2475 server fails to decrypt any 0-RTT record following an accepted 2476 "early_data" extension it MUST terminate the connection with a 2477 "bad_record_mac" alert as per Section 5.2. 2479 If the server rejects the "early_data" extension, the client 2480 application MAY opt to retransmit early data once the handshake has 2481 been completed. Note that automatic re-transmission of early data 2482 could result in assumptions about the status of the connection being 2483 incorrect. For instance, when the negotiated connection selects a 2484 different ALPN protocol from what was used for the early data, an 2485 application might need to construct different messages. Similarly, 2486 if early data assumes anything about the connection state, it might 2487 be sent in error after the handshake completes. 2489 A TLS implementation SHOULD NOT automatically re-send early data; 2490 applications are in a better position to decide when re-transmission 2491 is appropriate. A TLS implementation MUST NOT automatically re-send 2492 early data unless the negotiated connection selects the same ALPN 2493 protocol. 2495 4.2.10. Pre-Shared Key Extension 2497 The "pre_shared_key" extension is used to indicate the identity of 2498 the pre-shared key to be used with a given handshake in association 2499 with PSK key establishment. 2501 The "extension_data" field of this extension contains a 2502 "PreSharedKeyExtension" value: 2504 struct { 2505 opaque identity<1..2^16-1>; 2506 uint32 obfuscated_ticket_age; 2507 } PskIdentity; 2509 opaque PskBinderEntry<32..255>; 2511 struct { 2512 select (Handshake.msg_type) { 2513 case client_hello: 2514 PskIdentity identities<7..2^16-1>; 2515 PskBinderEntry binders<33..2^16-1>; 2517 case server_hello: 2518 uint16 selected_identity; 2519 }; 2521 } PreSharedKeyExtension; 2523 identity A label for a key. For instance, a ticket defined in 2524 Appendix B.3.4 or a label for a pre-shared key established 2525 externally. 2527 obfuscated_ticket_age An obfuscated version of the age of the key. 2528 Section 4.2.10.1 describes how to form this value for identities 2529 established via the NewSessionTicket message. For identities 2530 established externally an obfuscated_ticket_age of 0 SHOULD be 2531 used, and servers MUST ignore the value. 2533 identities A list of the identities that the client is willing to 2534 negotiate with the server. If sent alongside the "early_data" 2535 extension (see Section 4.2.9), the first identity is the one used 2536 for 0-RTT data. 2538 binders A series of HMAC values, one for each PSK offered in the 2539 "pre_shared_keys" extension and in the same order, computed as 2540 described below. 2542 selected_identity The server's chosen identity expressed as a 2543 (0-based) index into the identities in the client's list. 2545 Each PSK is associated with a single Hash algorithm. For PSKs 2546 established via the ticket mechanism (Section 4.6.1), this is the KDF 2547 Hash algorithm on the connection where the ticket was established. 2548 For externally established PSKs, the Hash algorithm MUST be set when 2549 the PSK is established, or default to SHA-256 if no such algorithm is 2550 defined. The server must ensure that it selects a compatible PSK (if 2551 any) and cipher suite. 2553 Implementor's note: the most straightforward way to implement the 2554 PSK/cipher suite matching requirements is to negotiate the cipher 2555 suite first and then exclude any incompatible PSKs. Any unknown PSKs 2556 (e.g., they are not in the PSK database or are encrypted with an 2557 unknown key) SHOULD simply be ignored. If no acceptable PSKs are 2558 found, the server SHOULD perform a non-PSK handshake if possible. 2560 Prior to accepting PSK key establishment, the server MUST validate 2561 the corresponding binder value (see Section 4.2.10.2 below). If this 2562 value is not present or does not validate, the server MUST abort the 2563 handshake. Servers SHOULD NOT attempt to validate multiple binders; 2564 rather they SHOULD select a single PSK and validate solely the binder 2565 that corresponds to that PSK. In order to accept PSK key 2566 establishment, the server sends a "pre_shared_key" extension 2567 indicating the selected identity. 2569 Clients MUST verify that the server's selected_identity is within the 2570 range supplied by the client, that the server selected a cipher suite 2571 indicating a Hash associated with the PSK and that a server 2572 "key_share" extension is present if required by the ClientHello 2573 "psk_key_exchange_modes". If these values are not consistent the 2574 client MUST abort the handshake with an "illegal_parameter" alert. 2576 If the server supplies an "early_data" extension, the client MUST 2577 verify that the server's selected_identity is 0. If any other value 2578 is returned, the client MUST abort the handshake with an 2579 "illegal_parameter" alert. 2581 This extension MUST be the last extension in the ClientHello (this 2582 facilitates implementation as described below). Servers MUST check 2583 that it is the last extension and otherwise fail the handshake with 2584 an "illegal_parameter" alert. 2586 4.2.10.1. Ticket Age 2588 The client's view of the age of a ticket is the time since the 2589 receipt of the NewSessionTicket message. Clients MUST NOT attempt to 2590 use tickets which have ages greater than the "ticket_lifetime" value 2591 which was provided with the ticket. The "obfuscated_ticket_age" 2592 field of each PskIdentity contains an obfuscated version of the 2593 ticket age formed by taking the age in milliseconds and adding the 2594 "ticket_age_add" value that was included with the ticket, see 2595 Section 4.6.1 modulo 2^32. This addition prevents passive observers 2596 from correlating connections unless tickets are reused. Note that 2597 the "ticket_lifetime" field in the NewSessionTicket message is in 2598 seconds but the "obfuscated_ticket_age" is in milliseconds. Because 2599 ticket lifetimes are restricted to a week, 32 bits is enough to 2600 represent any plausible age, even in milliseconds. 2602 4.2.10.2. PSK Binder 2604 The PSK binder value forms a binding between a PSK and the current 2605 handshake, as well as between the handshake in which the PSK was 2606 generated (if via a NewSessionTicket message) and the handshake where 2607 it was used. Each entry in the binders list is computed as an HMAC 2608 over a transcript hash (see Section 4.4.1) containing a partial 2609 ClientHello up to and including the PreSharedKeyExtension.identities 2610 field. That is, it includes all of the ClientHello but not the 2611 binders list itself. The length fields for the message (including 2612 the overall length, the length of the extensions block, and the 2613 length of the "pre_shared_key" extension) are all set as if binders 2614 of the correct lengths were present. 2616 The PskBinderEntry is computed in the same way as the Finished 2617 message (Section 4.4.4) but with the BaseKey being the binder_key 2618 derived via the key schedule from the corresponding PSK which is 2619 being offered (see Section 7.1). 2621 If the handshake includes a HelloRetryRequest, the initial 2622 ClientHello and HelloRetryRequest are included in the transcript 2623 along with the new ClientHello. For instance, if the client sends 2624 ClientHello1, its binder will be computed over: 2626 Transcript-Hash(ClientHello1[truncated]) 2628 If the server responds with HelloRetryRequest, and the client then 2629 sends ClientHello2, its binder will be computed over: 2631 Transcript-Hash(ClientHello1, 2632 HelloRetryRequest, 2633 ClientHello2[truncated]) 2635 The full ClientHello1 is included in all other handshake hash 2636 computations. Note that in the first flight, ClientHello1[truncated] 2637 is hashed directly, but in the second flight, ClientHello1 is hashed 2638 and then reinjected as a "handshake_hash" message, as described in 2639 Section 4.4.1. 2641 4.2.10.3. Processing Order 2643 Clients are permitted to "stream" 0-RTT data until they receive the 2644 server's Finished, only then sending the EndOfEarlyData message, 2645 followed by the rest of the handshake. In order to avoid deadlocks, 2646 when accepting "early_data", servers MUST process the client's 2647 ClientHello and then immediately send the ServerHello, rather than 2648 waiting for the client's EndOfEarlyData message. 2650 4.3. Server Parameters 2652 The next two messages from the server, EncryptedExtensions and 2653 CertificateRequest, contain information from the server that 2654 determines the rest of the handshake. These messages are encrypted 2655 with keys derived from the server_handshake_traffic_secret. 2657 4.3.1. Encrypted Extensions 2659 In all handshakes, the server MUST send the EncryptedExtensions 2660 message immediately after the ServerHello message. This is the first 2661 message that is encrypted under keys derived from the 2662 server_handshake_traffic_secret. 2664 The EncryptedExtensions message contains extensions that can be 2665 protected, i.e., any which are not needed to establish the 2666 cryptographic context, but which are not associated with individual 2667 certificates. The client MUST check EncryptedExtensions for the 2668 presence of any forbidden extensions and if any are found MUST abort 2669 the handshake with an "illegal_parameter" alert. 2671 Structure of this message: 2673 struct { 2674 Extension extensions<0..2^16-1>; 2675 } EncryptedExtensions; 2677 extensions A list of extensions. For more information, see the 2678 table in Section 4.2. 2680 4.3.2. Certificate Request 2682 A server which is authenticating with a certificate MAY optionally 2683 request a certificate from the client. This message, if sent, MUST 2684 follow EncryptedExtensions. 2686 Structure of this message: 2688 struct { 2689 opaque certificate_request_context<0..2^8-1>; 2690 Extension extensions<2..2^16-1>; 2691 } CertificateRequest; 2693 certificate_request_context An opaque string which identifies the 2694 certificate request and which will be echoed in the client's 2695 Certificate message. The certificate_request_context MUST be 2696 unique within the scope of this connection (thus preventing replay 2697 of client CertificateVerify messages). This field SHALL be zero 2698 length unless used for the post-handshake authentication exchanges 2699 described in Section 4.6.2. When requesting post-handshake 2700 authentication, the server SHOULD make the context unpredictable 2701 to the client (e.g., by randomly generating it) in order to 2702 prevent an attacker who has temporary access to the client's 2703 private key from pre-computing valid CertificateVerify messages. 2705 extensions A set of extensions describing the parameters of the 2706 certificate being requested. The "signature_algorithms" extension 2707 MUST be specified, and other extensions may optionally be included 2708 if defined for this message. Clients MUST ignore unrecognized 2709 extensions. 2711 In prior versions of TLS, the CertificateRequest message carried a 2712 list of signature algorithms and certificate authorities which the 2713 server would accept. In TLS 1.3 the former is expressed by sending 2714 the "signature_algorithms" extension. The latter is expressed by 2715 sending the "certificate_authorities" extension (see Section 4.2.4). 2717 Servers which are authenticating with a PSK MUST NOT send the 2718 CertificateRequest message in the main handshake, though they MAY 2719 send it in post-handshake authentication (see Section 4.6.2) provided 2720 that the client has sent the "post_handshake_auth" extension (see 2721 Section 4.2.5). 2723 4.4. Authentication Messages 2725 As discussed in Section 2, TLS generally uses a common set of 2726 messages for authentication, key confirmation, and handshake 2727 integrity: Certificate, CertificateVerify, and Finished. (The 2728 PreSharedKey binders also perform key confirmation, in a similar 2729 fashion.) These three messages are always sent as the last messages 2730 in their handshake flight. The Certificate and CertificateVerify 2731 messages are only sent under certain circumstances, as defined below. 2732 The Finished message is always sent as part of the Authentication 2733 block. These messages are encrypted under keys derived from 2734 [sender]_handshake_traffic_secret. 2736 The computations for the Authentication messages all uniformly take 2737 the following inputs: 2739 - The certificate and signing key to be used. 2741 - A Handshake Context consisting of the set of messages to be 2742 included in the transcript hash. 2744 - A base key to be used to compute a MAC key. 2746 Based on these inputs, the messages then contain: 2748 Certificate The certificate to be used for authentication, and any 2749 supporting certificates in the chain. Note that certificate-based 2750 client authentication is not available in 0-RTT mode. 2752 CertificateVerify A signature over the value Transcript- 2753 Hash(Handshake Context, Certificate) 2755 Finished A MAC over the value Transcript-Hash(Handshake Context, 2756 Certificate, CertificateVerify) using a MAC key derived from the 2757 base key. 2759 The following table defines the Handshake Context and MAC Base Key 2760 for each scenario: 2762 +-----------+----------------------------+--------------------------+ 2763 | Mode | Handshake Context | Base Key | 2764 +-----------+----------------------------+--------------------------+ 2765 | Server | ClientHello ... later of E | server_handshake_traffic | 2766 | | ncryptedExtensions/Certifi | _secret | 2767 | | cateRequest | | 2768 | | | | 2769 | Client | ClientHello ... later of | client_handshake_traffic | 2770 | | server | _secret | 2771 | | Finished/EndOfEarlyData | | 2772 | | | | 2773 | Post- | ClientHello ... client | client_application_traff | 2774 | Handshake | Finished + | ic_secret_N | 2775 | | CertificateRequest | | 2776 +-----------+----------------------------+--------------------------+ 2778 4.4.1. The Transcript Hash 2780 Many of the cryptographic computations in TLS make use of a 2781 transcript hash. This value is computed by hashing the concatenation 2782 of each included handshake message, including the handshake message 2783 header carrying the handshake message type and length fields, but not 2784 including record layer headers. I.e., 2786 Transcript-Hash(M1, M2, ... MN) = Hash(M1 || M2 ... MN) 2788 As an exception to this general rule, when the server responds to a 2789 ClientHello with a HelloRetryRequest, the value of ClientHello1 is 2790 replaced with a special synthetic handshake message of handshake type 2791 "message_hash" containing Hash(ClientHello1). I.e., 2793 Transcript-Hash(ClientHello1, HelloRetryRequest, ... MN) = 2794 Hash(message_hash || // Handshake type 2795 00 00 Hash.length || // Handshake message length 2796 Hash(ClientHello1) || // Hash of ClientHello1 2797 HelloRetryRequest ... MN) 2799 The reason for this construction is to allow the server to do a 2800 stateless HelloRetryRequest by storing just the hash of ClientHello1 2801 in the cookie, rather than requiring it to export the entire 2802 intermediate hash state (see Section 4.2.2). 2804 For concreteness, the transcript hash is always taken from the 2805 following sequence of handshake messages, starting at the first 2806 ClientHello and including only those messages that were sent: 2807 ClientHello, HelloRetryRequest, ClientHello, ServerHello, 2808 EncryptedExtensions, server CertificateRequest, server Certificate, 2809 server CertificateVerify, server Finished, EndOfEarlyData, client 2810 Certificate, client CertificateVerify, client Finished. 2812 In general, implementations can implement the transcript by keeping a 2813 running transcript hash value based on the negotiated hash. Note, 2814 however, that subsequent post-handshake authentications do not 2815 include each other, just the messages through the end of the main 2816 handshake. 2818 4.4.2. Certificate 2820 This message conveys the endpoint's certificate chain to the peer. 2822 The server MUST send a Certificate message whenever the agreed-upon 2823 key exchange method uses certificates for authentication (this 2824 includes all key exchange methods defined in this document except 2825 PSK). 2827 The client MUST send a Certificate message if and only if the server 2828 has requested client authentication via a CertificateRequest message 2829 (Section 4.3.2). If the server requests client authentication but no 2830 suitable certificate is available, the client MUST send a Certificate 2831 message containing no certificates (i.e., with the "certificate_list" 2832 field having length 0). 2834 Structure of this message: 2836 struct { 2837 select(certificate_type){ 2838 case RawPublicKey: 2839 // From RFC 7250 ASN.1_subjectPublicKeyInfo 2840 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 2842 case X509: 2843 opaque cert_data<1..2^24-1>; 2844 }; 2845 Extension extensions<0..2^16-1>; 2846 } CertificateEntry; 2848 struct { 2849 opaque certificate_request_context<0..2^8-1>; 2850 CertificateEntry certificate_list<0..2^24-1>; 2851 } Certificate; 2853 certificate_request_context If this message is in response to a 2854 CertificateRequest, the value of certificate_request_context in 2855 that message. Otherwise (in the case of server authentication), 2856 this field SHALL be zero length. 2858 certificate_list This is a sequence (chain) of CertificateEntry 2859 structures, each containing a single certificate and set of 2860 extensions. 2862 extensions: A set of extension values for the CertificateEntry. The 2863 "Extension" format is defined in Section 4.2. Valid extensions 2864 include OCSP Status extensions ([RFC6066] and [RFC6961]) and 2865 SignedCertificateTimestamps ([RFC6962]). An extension MUST only 2866 be present in a Certificate message if the corresponding 2867 ClientHello extension was presented in the initial handshake. If 2868 an extension applies to the entire chain, it SHOULD be included in 2869 the first CertificateEntry. 2871 If the corresponding certificate type extension 2872 ("server_certificate_type" or "client_certificate_type") was not used 2873 or the X.509 certificate type was negotiated, then each 2874 CertificateEntry contains an X.509 certificate. The sender's 2875 certificate MUST come in the first CertificateEntry in the list. 2876 Each following certificate SHOULD directly certify one preceding it. 2877 Because certificate validation requires that trust anchors be 2878 distributed independently, a certificate that specifies a trust 2879 anchor MAY be omitted from the chain, provided that supported peers 2880 are known to possess any omitted certificates. 2882 Note: Prior to TLS 1.3, "certificate_list" ordering required each 2883 certificate to certify the one immediately preceding it; however, 2884 some implementations allowed some flexibility. Servers sometimes 2885 send both a current and deprecated intermediate for transitional 2886 purposes, and others are simply configured incorrectly, but these 2887 cases can nonetheless be validated properly. For maximum 2888 compatibility, all implementations SHOULD be prepared to handle 2889 potentially extraneous certificates and arbitrary orderings from any 2890 TLS version, with the exception of the end-entity certificate which 2891 MUST be first. 2893 If the RawPublicKey certificate type was negotiated, then the 2894 certificate_list MUST contain no more than one CertificateEntry, 2895 which contains an ASN1_subjectPublicKeyInfo value as defined in 2896 [RFC7250], Section 3. 2898 The OpenPGP certificate type [RFC6091] MUST NOT be used with TLS 1.3. 2900 The server's certificate_list MUST always be non-empty. A client 2901 will send an empty certificate_list if it does not have an 2902 appropriate certificate to send in response to the server's 2903 authentication request. 2905 4.4.2.1. OCSP Status and SCT Extensions 2907 [RFC6066] and [RFC6961] provide extensions to negotiate the server 2908 sending OCSP responses to the client. In TLS 1.2 and below, the 2909 server replies with an empty extension to indicate negotiation of 2910 this extension and the OCSP information is carried in a 2911 CertificateStatus message. In TLS 1.3, the server's OCSP information 2912 is carried in an extension in the CertificateEntry containing the 2913 associated certificate. Specifically: The body of the 2914 "status_request" extension from the server MUST be a 2915 CertificateStatus structure as defined in [RFC6066], which is 2916 interpreted as defined in [RFC6960]. 2918 A server MAY request that a client present an OCSP response with its 2919 certificate by sending an empty "status_request" extension in its 2920 CertificateRequest message. If the client opts to send an OCSP 2921 response, the body of its "status_request" extension MUST be a 2922 CertificateStatus structure as defined in [RFC6066]. 2924 Similarly, [RFC6962] provides a mechanism for a server to send a 2925 Signed Certificate Timestamp (SCT) as an extension in the ServerHello 2926 in TLS 1.2 and below. In TLS 1.3, the server's SCT information is 2927 carried in an extension in CertificateEntry. 2929 4.4.2.2. Server Certificate Selection 2931 The following rules apply to the certificates sent by the server: 2933 - The certificate type MUST be X.509v3 [RFC5280], unless explicitly 2934 negotiated otherwise (e.g., [RFC7250]). 2936 - The server's end-entity certificate's public key (and associated 2937 restrictions) MUST be compatible with the selected authentication 2938 algorithm (currently RSA, ECDSA, or EdDSA). 2940 - The certificate MUST allow the key to be used for signing (i.e., 2941 the digitalSignature bit MUST be set if the Key Usage extension is 2942 present) with a signature scheme indicated in the client's 2943 "signature_algorithms" extension. 2945 - The "server_name" and "certificate_authorities" extensions 2946 [RFC6066] are used to guide certificate selection. As servers MAY 2947 require the presence of the "server_name" extension, clients 2948 SHOULD send this extension, when applicable. 2950 All certificates provided by the server MUST be signed by a signature 2951 algorithm that appears in the "signature_algorithms" extension 2952 provided by the client, if they are able to provide such a chain (see 2953 Section 4.2.3). Certificates that are self-signed or certificates 2954 that are expected to be trust anchors are not validated as part of 2955 the chain and therefore MAY be signed with any algorithm. 2957 If the server cannot produce a certificate chain that is signed only 2958 via the indicated supported algorithms, then it SHOULD continue the 2959 handshake by sending the client a certificate chain of its choice 2960 that may include algorithms that are not known to be supported by the 2961 client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash 2962 algorithm in general, but MAY do so if the "signature_algorithms" 2963 extension provided by the client permits it, and MUST NOT do so 2964 otherwise. 2966 If the client cannot construct an acceptable chain using the provided 2967 certificates and decides to abort the handshake, then it MUST abort 2968 the handshake with an appropriate certificate-related alert (by 2969 default, "unsupported_certificate"; see Section 6.2 for more). 2971 If the server has multiple certificates, it chooses one of them based 2972 on the above-mentioned criteria (in addition to other criteria, such 2973 as transport layer endpoint, local configuration and preferences). 2975 4.4.2.3. Client Certificate Selection 2977 The following rules apply to certificates sent by the client: 2979 - The certificate type MUST be X.509v3 [RFC5280], unless explicitly 2980 negotiated otherwise (e.g., [RFC7250]). 2982 - If the "certificate_authorities" extension in the 2983 CertificateRequest message was present, at least one of the 2984 certificates in the certificate chain SHOULD be issued by one of 2985 the listed CAs. 2987 - The certificates MUST be signed using an acceptable signature 2988 algorithm, as described in Section 4.3.2. Note that this relaxes 2989 the constraints on certificate-signing algorithms found in prior 2990 versions of TLS. 2992 - If the CertificateRequest message contained a non-empty 2993 "oid_filters" extension, the end-entity certificate MUST match the 2994 extension OIDs recognized by the client, as described in 2995 Section 4.2.4.1. 2997 Note that, as with the server certificate, there are certificates 2998 that use algorithm combinations that cannot be currently used with 2999 TLS. 3001 4.4.2.4. Receiving a Certificate Message 3003 In general, detailed certificate validation procedures are out of 3004 scope for TLS (see [RFC5280]). This section provides TLS-specific 3005 requirements. 3007 If the server supplies an empty Certificate message, the client MUST 3008 abort the handshake with a "decode_error" alert. 3010 If the client does not send any certificates, the server MAY at its 3011 discretion either continue the handshake without client 3012 authentication, or abort the handshake with a "certificate_required" 3013 alert. Also, if some aspect of the certificate chain was 3014 unacceptable (e.g., it was not signed by a known, trusted CA), the 3015 server MAY at its discretion either continue the handshake 3016 (considering the client unauthenticated) or abort the handshake. 3018 Any endpoint receiving any certificate which it would need to 3019 validate using any signature algorithm using an MD5 hash MUST abort 3020 the handshake with a "bad_certificate" alert. SHA-1 is deprecated 3021 and it is RECOMMENDED that any endpoint receiving any certificate 3022 which it would need to validate using any signature algorithm using a 3023 SHA-1 hash abort the handshake with a "bad_certificate" alert. For 3024 clarity, this means that endpoints MAY accept these algorithms for 3025 certificates that are self-signed or are trust anchors. 3027 All endpoints are RECOMMENDED to transition to SHA-256 or better as 3028 soon as possible to maintain interoperability with implementations 3029 currently in the process of phasing out SHA-1 support. 3031 Note that a certificate containing a key for one signature algorithm 3032 MAY be signed using a different signature algorithm (for instance, an 3033 RSA key signed with an ECDSA key). 3035 4.4.3. Certificate Verify 3037 This message is used to provide explicit proof that an endpoint 3038 possesses the private key corresponding to its certificate. The 3039 CertificateVerify message also provides integrity for the handshake 3040 up to this point. Servers MUST send this message when authenticating 3041 via a certificate. Clients MUST send this message whenever 3042 authenticating via a certificate (i.e., when the Certificate message 3043 is non-empty). When sent, this message MUST appear immediately after 3044 the Certificate message and immediately prior to the Finished 3045 message. 3047 Structure of this message: 3049 struct { 3050 SignatureScheme algorithm; 3051 opaque signature<0..2^16-1>; 3052 } CertificateVerify; 3054 The algorithm field specifies the signature algorithm used (see 3055 Section 4.2.3 for the definition of this field). The signature is a 3056 digital signature using that algorithm. The content that is covered 3057 under the signature is the hash output as described in Section 4.4, 3058 namely: 3060 Transcript-Hash(Handshake Context, Certificate) 3062 The digital signature is then computed over the concatenation of: 3064 - A string that consists of octet 32 (0x20) repeated 64 times 3066 - The context string 3068 - A single 0 byte which serves as the separator 3070 - The content to be signed 3072 This structure is intended to prevent an attack on previous versions 3073 of TLS in which the ServerKeyExchange format meant that attackers 3074 could obtain a signature of a message with a chosen 32-byte prefix 3075 (ClientHello.random). The initial 64-byte pad clears that prefix 3076 along with the server-controlled ServerHello.random. 3078 The context string for a server signature is "TLS 1.3, server 3079 CertificateVerify" and for a client signature is "TLS 1.3, client 3080 CertificateVerify". It is used to provide separation between 3081 signatures made in different contexts, helping against potential 3082 cross-protocol attacks. 3084 For example, if the transcript hash was 32 bytes of 01 (this length 3085 would make sense for SHA-256), the content covered by the digital 3086 signature for a server CertificateVerify would be: 3088 2020202020202020202020202020202020202020202020202020202020202020 3089 2020202020202020202020202020202020202020202020202020202020202020 3090 544c5320312e332c207365727665722043657274696669636174655665726966 3091 79 3092 00 3093 0101010101010101010101010101010101010101010101010101010101010101 3095 On the sender side the process for computing the signature field of 3096 the CertificateVerify message takes as input: 3098 - The content covered by the digital signature 3100 - The private signing key corresponding to the certificate sent in 3101 the previous message 3103 If the CertificateVerify message is sent by a server, the signature 3104 algorithm MUST be one offered in the client's "signature_algorithms" 3105 extension unless no valid certificate chain can be produced without 3106 unsupported algorithms (see Section 4.2.3). 3108 If sent by a client, the signature algorithm used in the signature 3109 MUST be one of those present in the supported_signature_algorithms 3110 field of the "signature_algorithms" extension in the 3111 CertificateRequest message. 3113 In addition, the signature algorithm MUST be compatible with the key 3114 in the sender's end-entity certificate. RSA signatures MUST use an 3115 RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 3116 algorithms appear in "signature_algorithms". The SHA-1 algorithm 3117 MUST NOT be used in any signatures of CertificateVerify messages. 3118 All SHA-1 signature algorithms in this specification are defined 3119 solely for use in legacy certificates and are not valid for 3120 CertificateVerify signatures. 3122 The receiver of a CertificateVerify message MUST verify the signature 3123 field. The verification process takes as input: 3125 - The content covered by the digital signature 3127 - The public key contained in the end-entity certificate found in 3128 the associated Certificate message. 3130 - The digital signature received in the signature field of the 3131 CertificateVerify message 3133 If the verification fails, the receiver MUST terminate the handshake 3134 with a "decrypt_error" alert. 3136 4.4.4. Finished 3138 The Finished message is the final message in the authentication 3139 block. It is essential for providing authentication of the handshake 3140 and of the computed keys. 3142 Recipients of Finished messages MUST verify that the contents are 3143 correct and if incorrect MUST terminate the connection with a 3144 "decrypt_error" alert. 3146 Once a side has sent its Finished message and received and validated 3147 the Finished message from its peer, it may begin to send and receive 3148 application data over the connection. There are two settings in 3149 which it is permitted to send data prior to receiving the peer's 3150 Finished: 3152 1. Clients ending 0-RTT data as described in Section 4.2.9. 3154 2. Servers MAY send data after sending their first flight, but 3155 because the handshake is not yet complete, they have no assurance 3156 of either the peer's identity or of its liveness (i.e., the 3157 ClientHello might have been replayed). 3159 The key used to compute the finished message is computed from the 3160 Base key defined in Section 4.4 using HKDF (see Section 7.1). 3161 Specifically: 3163 finished_key = 3164 HKDF-Expand-Label(BaseKey, "finished", "", Hash.length) 3166 Structure of this message: 3168 struct { 3169 opaque verify_data[Hash.length]; 3170 } Finished; 3172 The verify_data value is computed as follows: 3174 verify_data = 3175 HMAC(finished_key, 3176 Transcript-Hash(Handshake Context, 3177 Certificate*, CertificateVerify*)) 3179 * Only included if present. 3181 HMAC [RFC2104] uses the Hash algorithm for the handshake. As noted 3182 above, the HMAC input can generally be implemented by a running hash, 3183 i.e., just the handshake hash at this point. 3185 In previous versions of TLS, the verify_data was always 12 octets 3186 long. In TLS 1.3, it is the size of the HMAC output for the Hash 3187 used for the handshake. 3189 Note: Alerts and any other record types are not handshake messages 3190 and are not included in the hash computations. 3192 Any records following a 1-RTT Finished message MUST be encrypted 3193 under the appropriate application traffic key as described in 3194 Section 7.2. In particular, this includes any alerts sent by the 3195 server in response to client Certificate and CertificateVerify 3196 messages. 3198 4.5. End of Early Data 3200 struct {} EndOfEarlyData; 3202 If the server sent an "early_data" extension, the client MUST send an 3203 EndOfEarlyData message after receiving the server Finished. If the 3204 server does not send an "early_data" extension, then the client MUST 3205 NOT send an EndOfEarlyData message. This message indicates that all 3206 0-RTT application_data messages, if any, have been transmitted and 3207 that the following records are protected under handshake traffic 3208 keys. Servers MUST NOT send this message and clients receiving it 3209 MUST terminate the connection with an "unexpected_message" alert. 3210 This message is encrypted under keys derived from the 3211 client_early_traffic_secret. 3213 4.6. Post-Handshake Messages 3215 TLS also allows other messages to be sent after the main handshake. 3216 These messages use a handshake content type and are encrypted under 3217 the appropriate application traffic key. 3219 4.6.1. New Session Ticket Message 3221 At any time after the server has received the client Finished 3222 message, it MAY send a NewSessionTicket message. This message 3223 creates a unique association between the ticket value and a secret 3224 PSK derived from the resumption master secret. 3226 The client MAY use this PSK for future handshakes by including the 3227 ticket value in the "pre_shared_key" extension in its ClientHello 3228 (Section 4.2.10). Servers MAY send multiple tickets on a single 3229 connection, either immediately after each other or after specific 3230 events. For instance, the server might send a new ticket after post- 3231 handshake authentication in order to encapsulate the additional 3232 client authentication state. Clients SHOULD attempt to use each 3233 ticket no more than once, with more recent tickets being used first. 3235 Any ticket MUST only be resumed with a cipher suite that has the same 3236 KDF hash algorithm as that used to establish the original connection, 3237 and only if the client provides the same SNI value as in the original 3238 connection, as described in Section 3 of [RFC6066]. 3240 Note: Although the resumption master secret depends on the client's 3241 second flight, servers which do not request client authentication MAY 3242 compute the remainder of the transcript independently and then send a 3243 NewSessionTicket immediately upon sending its Finished rather than 3244 waiting for the client Finished. This might be appropriate in cases 3245 where the client is expected to open multiple TLS connections in 3246 parallel and would benefit from the reduced overhead of a resumption 3247 handshake, for example. 3249 struct { 3250 uint32 ticket_lifetime; 3251 uint32 ticket_age_add; 3252 opaque ticket_nonce<1..255>; 3253 opaque ticket<1..2^16-1>; 3254 Extension extensions<0..2^16-2>; 3255 } NewSessionTicket; 3257 ticket_lifetime Indicates the lifetime in seconds as a 32-bit 3258 unsigned integer in network byte order from the time of ticket 3259 issuance. Servers MUST NOT use any value greater than 604800 3260 seconds (7 days). The value of zero indicates that the ticket 3261 should be discarded immediately. Clients MUST NOT cache tickets 3262 for longer than 7 days, regardless of the ticket_lifetime, and MAY 3263 delete the ticket earlier based on local policy. A server MAY 3264 treat a ticket as valid for a shorter period of time than what is 3265 stated in the ticket_lifetime. 3267 ticket_age_add A securely generated, random 32-bit value that is 3268 used to obscure the age of the ticket that the client includes in 3269 the "pre_shared_key" extension. The client-side ticket age is 3270 added to this value modulo 2^32 to obtain the value that is 3271 transmitted by the client. The server MUST generate a fresh value 3272 for each ticket it sends. 3274 ticket_nonce A unique per-ticket value. 3276 ticket The value of the ticket to be used as the PSK identity. The 3277 ticket itself is an opaque label. It MAY either be a database 3278 lookup key or a self-encrypted and self-authenticated value. 3279 Section 4 of [RFC5077] describes a recommended ticket construction 3280 mechanism. 3282 extensions A set of extension values for the ticket. The 3283 "Extension" format is defined in Section 4.2. Clients MUST ignore 3284 unrecognized extensions. 3286 The sole extension currently defined for NewSessionTicket is 3287 "early_data", indicating that the ticket may be used to send 0-RTT 3288 data (Section 4.2.9)). It contains the following value: 3290 max_early_data_size The maximum amount of 0-RTT data that the client 3291 is allowed to send when using this ticket, in bytes. Only 3292 Application Data payload (i.e., plaintext but not padding or the 3293 inner content type byte) is counted. A server receiving more than 3294 max_early_data_size bytes of 0-RTT data SHOULD terminate the 3295 connection with an "unexpected_message" alert. Note that servers 3296 that reject early data due to lack of cryptographic material will 3297 be unable to differentiate padding from content, so clients SHOULD 3298 NOT depend on being able to send large quantities of padding in 3299 early data records. 3301 The PSK associated with the ticket is computed as: 3303 HKDF-Expand-Label(resumption_master_secret, 3304 "resumption", ticket_nonce, Hash.length) 3306 Because the ticket_nonce value is distinct for each NewSessionTicket 3307 message, a different PSK will be derived for each ticket. 3309 Note that in principle it is possible to continue issuing new tickets 3310 which indefinitely extend the lifetime of the keying material 3311 originally derived from an initial non-PSK handshake (which was most 3312 likely tied to the peer's certificate). It is RECOMMENDED that 3313 implementations place limits on the total lifetime of such keying 3314 material; these limits should take into account the lifetime of the 3315 peer's certificate, the likelihood of intervening revocation, and the 3316 time since the peer's online CertificateVerify signature. 3318 4.6.2. Post-Handshake Authentication 3320 When the client has sent the "post_handshake_auth" extension (see 3321 Section 4.2.5), a server MAY request client authentication at any 3322 time after the handshake has completed by sending a 3323 CertificateRequest message. The client MUST respond with the 3324 appropriate Authentication messages (see Section 4.4). If the client 3325 chooses to authenticate, it MUST send Certificate, CertificateVerify, 3326 and Finished. If it declines, it MUST send a Certificate message 3327 containing no certificates followed by Finished. All of the client's 3328 messages for a given response MUST appear consecutively on the wire 3329 with no intervening messages of other types. 3331 A client that receives a CertificateRequest message without having 3332 sent the "post_handshake_auth" extension MUST send an 3333 "unexpected_message" fatal alert. 3335 Note: Because client authentication could involve prompting the user, 3336 servers MUST be prepared for some delay, including receiving an 3337 arbitrary number of other messages between sending the 3338 CertificateRequest and receiving a response. In addition, clients 3339 which receive multiple CertificateRequests in close succession MAY 3340 respond to them in a different order than they were received (the 3341 certificate_request_context value allows the server to disambiguate 3342 the responses). 3344 4.6.3. Key and IV Update 3346 enum { 3347 update_not_requested(0), update_requested(1), (255) 3348 } KeyUpdateRequest; 3350 struct { 3351 KeyUpdateRequest request_update; 3352 } KeyUpdate; 3354 request_update Indicates whether the recipient of the KeyUpdate 3355 should respond with its own KeyUpdate. If an implementation 3356 receives any other value, it MUST terminate the connection with an 3357 "illegal_parameter" alert. 3359 The KeyUpdate handshake message is used to indicate that the sender 3360 is updating its sending cryptographic keys. This message can be sent 3361 by either peer after it has sent a Finished message. Implementations 3362 that receive a KeyUpdate message prior to receiving a Finished 3363 message MUST terminate the connection with an "unexpected_message" 3364 alert. After sending a KeyUpdate message, the sender SHALL send all 3365 its traffic using the next generation of keys, computed as described 3366 in Section 7.2. Upon receiving a KeyUpdate, the receiver MUST update 3367 its receiving keys. 3369 If the request_update field is set to "update_requested" then the 3370 receiver MUST send a KeyUpdate of its own with request_update set to 3371 "update_not_requested" prior to sending its next application data 3372 record. This mechanism allows either side to force an update to the 3373 entire connection, but causes an implementation which receives 3374 multiple KeyUpdates while it is silent to respond with a single 3375 update. Note that implementations may receive an arbitrary number of 3376 messages between sending a KeyUpdate with request_update set to 3377 update_requested and receiving the peer's KeyUpdate, because those 3378 messages may already be in flight. However, because send and receive 3379 keys are derived from independent traffic secrets, retaining the 3380 receive traffic secret does not threaten the forward secrecy of data 3381 sent before the sender changed keys. 3383 If implementations independently send their own KeyUpdates with 3384 request_update set to "update_requested", and they cross in flight, 3385 then each side will also send a response, with the result that each 3386 side increments by two generations. 3388 Both sender and receiver MUST encrypt their KeyUpdate messages with 3389 the old keys. Additionally, both sides MUST enforce that a KeyUpdate 3390 with the old key is received before accepting any messages encrypted 3391 with the new key. Failure to do so may allow message truncation 3392 attacks. 3394 5. Record Protocol 3396 The TLS record protocol takes messages to be transmitted, fragments 3397 the data into manageable blocks, protects the records, and transmits 3398 the result. Received data is verified, decrypted, reassembled, and 3399 then delivered to higher-level clients. 3401 TLS records are typed, which allows multiple higher-level protocols 3402 to be multiplexed over the same record layer. This document 3403 specifies three content types: handshake, application data, and 3404 alert. Implementations MUST NOT send record types not defined in 3405 this document unless negotiated by some extension. If a TLS 3406 implementation receives an unexpected record type, it MUST terminate 3407 the connection with an "unexpected_message" alert. New record 3408 content type values are assigned by IANA in the TLS Content Type 3409 Registry as described in Section 11. 3411 5.1. Record Layer 3413 The record layer fragments information blocks into TLSPlaintext 3414 records carrying data in chunks of 2^14 bytes or less. Message 3415 boundaries are handled differently depending on the underlying 3416 ContentType. Any future content types MUST specify appropriate 3417 rules. Note that these rules are stricter than what was enforced in 3418 TLS 1.2. 3420 Handshake messages MAY be coalesced into a single TLSPlaintext record 3421 or fragmented across several records, provided that: 3423 - Handshake messages MUST NOT be interleaved with other record 3424 types. That is, if a handshake message is split over two or more 3425 records, there MUST NOT be any other records between them. 3427 - Handshake messages MUST NOT span key changes. Implementations 3428 MUST verify that all messages immediately preceding a key change 3429 align with a record boundary; if not, then they MUST terminate the 3430 connection with an "unexpected_message" alert. Because the 3431 ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate 3432 messages can immediately precede a key change, implementations 3433 MUST send these messages in alignment with a record boundary. 3435 Implementations MUST NOT send zero-length fragments of Handshake 3436 types, even if those fragments contain padding. 3438 Alert messages (Section 6) MUST NOT be fragmented across records and 3439 multiple Alert messages MUST NOT be coalesced into a single 3440 TLSPlaintext record. In other words, a record with an Alert type 3441 MUST contain exactly one message. 3443 Application Data messages contain data that is opaque to TLS. 3444 Application Data messages are always protected. Zero-length 3445 fragments of Application Data MAY be sent as they are potentially 3446 useful as a traffic analysis countermeasure. 3448 enum { 3449 invalid(0), 3450 alert(21), 3451 handshake(22), 3452 application_data(23), 3453 (255) 3454 } ContentType; 3456 struct { 3457 ContentType type; 3458 ProtocolVersion legacy_record_version; 3459 uint16 length; 3460 opaque fragment[TLSPlaintext.length]; 3461 } TLSPlaintext; 3463 type The higher-level protocol used to process the enclosed 3464 fragment. 3466 legacy_record_version This value MUST be set to 0x0301 for all 3467 records generated by a TLS 1.3 implementation. This field is 3468 deprecated and MUST be ignored for all purposes. Previous 3469 versions of TLS would use other values in this field under some 3470 circumstances. 3472 length The length (in bytes) of the following TLSPlaintext.fragment. 3473 The length MUST NOT exceed 2^14 bytes. An endpoint that receives 3474 a record that exceeds this length MUST terminate the connection 3475 with a "record_overflow" alert. 3477 fragment The data being transmitted. This value is transparent and 3478 is treated as an independent block to be dealt with by the higher- 3479 level protocol specified by the type field. 3481 This document describes TLS 1.3, which uses the version 0x0304. This 3482 version value is historical, deriving from the use of 0x0301 for TLS 3483 1.0 and 0x0300 for SSL 3.0. In order to maximize backwards 3484 compatibility, the record layer version identifies as simply TLS 1.0. 3485 Endpoints supporting multiple versions negotiate the version to use 3486 by following the procedure and requirements in Appendix D. 3488 When record protection has not yet been engaged, TLSPlaintext 3489 structures are written directly onto the wire. Once record 3490 protection has started, TLSPlaintext records are protected and sent 3491 as described in the following section. 3493 5.2. Record Payload Protection 3495 The record protection functions translate a TLSPlaintext structure 3496 into a TLSCiphertext. The deprotection functions reverse the 3497 process. In TLS 1.3, as opposed to previous versions of TLS, all 3498 ciphers are modeled as "Authenticated Encryption with Additional 3499 Data" (AEAD) [RFC5116]. AEAD functions provide an unified encryption 3500 and authentication operation which turns plaintext into authenticated 3501 ciphertext and back again. Each encrypted record consists of a 3502 plaintext header followed by an encrypted body, which itself contains 3503 a type and optional padding. 3505 struct { 3506 opaque content[TLSPlaintext.length]; 3507 ContentType type; 3508 uint8 zeros[length_of_padding]; 3509 } TLSInnerPlaintext; 3511 struct { 3512 ContentType opaque_type = 23; /* application_data */ 3513 ProtocolVersion legacy_record_version = 0x0301; /* TLS v1.x */ 3514 uint16 length; 3515 opaque encrypted_record[length]; 3516 } TLSCiphertext; 3518 content The byte encoding of a handshake or an alert message, or the 3519 raw bytes of the application's data to send. 3521 type The content type of the record. 3523 zeros An arbitrary-length run of zero-valued bytes may appear in the 3524 cleartext after the type field. This provides an opportunity for 3525 senders to pad any TLS record by a chosen amount as long as the 3526 total stays within record size limits. See Section 5.4 for more 3527 details. 3529 opaque_type The outer opaque_type field of a TLSCiphertext record is 3530 always set to the value 23 (application_data) for outward 3531 compatibility with middleboxes accustomed to parsing previous 3532 versions of TLS. The actual content type of the record is found 3533 in TLSInnerPlaintext.type after decryption. 3535 legacy_record_version The legacy_record_version field is always 3536 0x0301. TLS 1.3 TLSCiphertexts are not generated until after TLS 3537 1.3 has been negotiated, so there are no historical compatibility 3538 concerns where other values might be received. Implementations 3539 MAY verify that the legacy_record_version field is 0x0301 and 3540 abort the connection if it is not. Note that the handshake 3541 protocol including the ClientHello and ServerHello messages 3542 authenticates the protocol version, so this value is redundant. 3544 length The length (in bytes) of the following 3545 TLSCiphertext.encrypted_record, which is the sum of the lengths of 3546 the content and the padding, plus one for the inner content type, 3547 plus any expansion added by the AEAD algorithm. The length MUST 3548 NOT exceed 2^14 + 256 bytes. An endpoint that receives a record 3549 that exceeds this length MUST terminate the connection with a 3550 "record_overflow" alert. 3552 encrypted_record The AEAD-encrypted form of the serialized 3553 TLSInnerPlaintext structure. 3555 AEAD algorithms take as input a single key, a nonce, a plaintext, and 3556 "additional data" to be included in the authentication check, as 3557 described in Section 2.1 of [RFC5116]. The key is either the 3558 client_write_key or the server_write_key, the nonce is derived from 3559 the sequence number (see Section 5.3) and the client_write_iv or 3560 server_write_iv, and the additional data input is empty (zero 3561 length). Derivation of traffic keys is defined in Section 7.3. 3563 The plaintext input to the AEAD algorithm is the encoded 3564 TLSInnerPlaintext structure. 3566 The AEAD output consists of the ciphertext output from the AEAD 3567 encryption operation. The length of the plaintext is greater than 3568 the corresponding TLSPlaintext.length due to the inclusion of 3569 TLSInnerPlaintext.type and any padding supplied by the sender. The 3570 length of the AEAD output will generally be larger than the 3571 plaintext, but by an amount that varies with the AEAD algorithm. 3572 Since the ciphers might incorporate padding, the amount of overhead 3573 could vary with different lengths of plaintext. Symbolically, 3575 AEADEncrypted = 3576 AEAD-Encrypt(write_key, nonce, plaintext) 3578 In order to decrypt and verify, the cipher takes as input the key, 3579 nonce, and the AEADEncrypted value. The output is either the 3580 plaintext or an error indicating that the decryption failed. There 3581 is no separate integrity check. That is: 3583 plaintext of encrypted_record = 3584 AEAD-Decrypt(peer_write_key, nonce, AEADEncrypted) 3586 If the decryption fails, the receiver MUST terminate the connection 3587 with a "bad_record_mac" alert. 3589 An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion 3590 greater than 255 octets. An endpoint that receives a record from its 3591 peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST 3592 terminate the connection with a "record_overflow" alert. This limit 3593 is derived from the maximum TLSPlaintext length of 2^14 octets + 1 3594 octet for ContentType + the maximum AEAD expansion of 255 octets. 3596 5.3. Per-Record Nonce 3598 A 64-bit sequence number is maintained separately for reading and 3599 writing records. Each sequence number is set to zero at the 3600 beginning of a connection and whenever the key is changed. 3602 The appropriate sequence number is incremented by one after reading 3603 or writing each record. The first record transmitted under a 3604 particular traffic key MUST use sequence number 0. 3606 Because the size of sequence numbers is 64-bit, they should not wrap. 3607 If a TLS implementation would need to wrap a sequence number, it MUST 3608 either re-key (Section 4.6.3) or terminate the connection. 3610 Each AEAD algorithm will specify a range of possible lengths for the 3611 per-record nonce, from N_MIN bytes to N_MAX bytes of input 3612 ([RFC5116]). The length of the TLS per-record nonce (iv_length) is 3613 set to the larger of 8 bytes and N_MIN for the AEAD algorithm (see 3614 [RFC5116] Section 4). An AEAD algorithm where N_MAX is less than 8 3615 bytes MUST NOT be used with TLS. The per-record nonce for the AEAD 3616 construction is formed as follows: 3618 1. The 64-bit record sequence number is encoded in network byte 3619 order and padded to the left with zeros to iv_length. 3621 2. The padded sequence number is XORed with the static 3622 client_write_iv or server_write_iv, depending on the role. 3624 The resulting quantity (of length iv_length) is used as the per- 3625 record nonce. 3627 Note: This is a different construction from that in TLS 1.2, which 3628 specified a partially explicit nonce. 3630 5.4. Record Padding 3632 All encrypted TLS records can be padded to inflate the size of the 3633 TLSCiphertext. This allows the sender to hide the size of the 3634 traffic from an observer. 3636 When generating a TLSCiphertext record, implementations MAY choose to 3637 pad. An unpadded record is just a record with a padding length of 3638 zero. Padding is a string of zero-valued bytes appended to the 3639 ContentType field before encryption. Implementations MUST set the 3640 padding octets to all zeros before encrypting. 3642 Application Data records may contain a zero-length 3643 TLSInnerPlaintext.content if the sender desires. This permits 3644 generation of plausibly-sized cover traffic in contexts where the 3645 presence or absence of activity may be sensitive. Implementations 3646 MUST NOT send Handshake or Alert records that have a zero-length 3647 TLSInnerPlaintext.content; if such a message is received, the 3648 receiving implementation MUST terminate the connection with an 3649 "unexpected_message" alert. 3651 The padding sent is automatically verified by the record protection 3652 mechanism; upon successful decryption of a 3653 TLSCiphertext.encrypted_record, the receiving implementation scans 3654 the field from the end toward the beginning until it finds a non-zero 3655 octet. This non-zero octet is the content type of the message. This 3656 padding scheme was selected because it allows padding of any 3657 encrypted TLS record by an arbitrary size (from zero up to TLS record 3658 size limits) without introducing new content types. The design also 3659 enforces all-zero padding octets, which allows for quick detection of 3660 padding errors. 3662 Implementations MUST limit their scanning to the cleartext returned 3663 from the AEAD decryption. If a receiving implementation does not 3664 find a non-zero octet in the cleartext, it MUST terminate the 3665 connection with an "unexpected_message" alert. 3667 The presence of padding does not change the overall record size 3668 limitations - the full encoded TLSInnerPlaintext MUST not exceed 2^14 3669 octets. If the maximum fragment length is reduced, as for example by 3670 the max_fragment_length extension from [RFC6066], then the reduced 3671 limit applies to the full plaintext, including the padding. 3673 Selecting a padding policy that suggests when and how much to pad is 3674 a complex topic and is beyond the scope of this specification. If 3675 the application layer protocol on top of TLS has its own padding, it 3676 may be preferable to pad application_data TLS records within the 3677 application layer. Padding for encrypted handshake and alert TLS 3678 records must still be handled at the TLS layer, though. Later 3679 documents may define padding selection algorithms or define a padding 3680 policy request mechanism through TLS extensions or some other means. 3682 5.5. Limits on Key Usage 3684 There are cryptographic limits on the amount of plaintext which can 3685 be safely encrypted under a given set of keys. [AEAD-LIMITS] 3686 provides an analysis of these limits under the assumption that the 3687 underlying primitive (AES or ChaCha20) has no weaknesses. 3688 Implementations SHOULD do a key update as described in Section 4.6.3 3689 prior to reaching these limits. 3691 For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be 3692 encrypted on a given connection while keeping a safety margin of 3693 approximately 2^-57 for Authenticated Encryption (AE) security. For 3694 ChaCha20/Poly1305, the record sequence number would wrap before the 3695 safety limit is reached. 3697 6. Alert Protocol 3699 One of the content types supported by the TLS record layer is the 3700 alert type. Like other messages, alert messages are encrypted as 3701 specified by the current connection state. 3703 Alert messages convey a description of the alert and a legacy field 3704 that conveyed the severity of the message in previous versions of 3705 TLS. In TLS 1.3, the severity is implicit in the type of alert being 3706 sent, and the 'level' field can safely be ignored. The 3707 "close_notify" alert is used to indicate orderly closure of the 3708 connection. Upon receiving such an alert, the TLS implementation 3709 SHOULD indicate end-of-data to the application. 3711 Error alerts indicate abortive closure of the connection (see 3712 Section 6.2). Upon receiving an error alert, the TLS implementation 3713 SHOULD indicate an error to the application and MUST NOT allow any 3714 further data to be sent or received on the connection. Servers and 3715 clients MUST forget keys and secrets associated with a failed 3716 connection. Stateful implementations of tickets (as in many clients) 3717 SHOULD discard tickets associated with failed connections. 3719 All the alerts listed in Section 6.2 MUST be sent as fatal and MUST 3720 be treated as fatal regardless of the AlertLevel in the message. 3721 Unknown alert types MUST be treated as fatal. 3723 Note: TLS defines two generic alerts (see Section 6) to use upon 3724 failure to parse a message. Peers which receive a message which 3725 cannot be parsed according to the syntax (e.g., have a length 3726 extending beyond the message boundary or contain an out-of-range 3727 length) MUST terminate the connection with a "decode_error" alert. 3728 Peers which receive a message which is syntactically correct but 3729 semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) 3730 MUST terminate the connection with an "illegal_parameter" alert. 3732 enum { warning(1), fatal(2), (255) } AlertLevel; 3734 enum { 3735 close_notify(0), 3736 unexpected_message(10), 3737 bad_record_mac(20), 3738 record_overflow(22), 3739 handshake_failure(40), 3740 bad_certificate(42), 3741 unsupported_certificate(43), 3742 certificate_revoked(44), 3743 certificate_expired(45), 3744 certificate_unknown(46), 3745 illegal_parameter(47), 3746 unknown_ca(48), 3747 access_denied(49), 3748 decode_error(50), 3749 decrypt_error(51), 3750 protocol_version(70), 3751 insufficient_security(71), 3752 internal_error(80), 3753 inappropriate_fallback(86), 3754 user_canceled(90), 3755 missing_extension(109), 3756 unsupported_extension(110), 3757 certificate_unobtainable(111), 3758 unrecognized_name(112), 3759 bad_certificate_status_response(113), 3760 bad_certificate_hash_value(114), 3761 unknown_psk_identity(115), 3762 certificate_required(116), 3763 no_application_protocol(120), 3764 (255) 3765 } AlertDescription; 3767 struct { 3768 AlertLevel level; 3769 AlertDescription description; 3770 } Alert; 3772 6.1. Closure Alerts 3774 The client and the server must share knowledge that the connection is 3775 ending in order to avoid a truncation attack. 3777 close_notify This alert notifies the recipient that the sender will 3778 not send any more messages on this connection. Any data received 3779 after a closure MUST be ignored. 3781 user_canceled This alert notifies the recipient that the sender is 3782 canceling the handshake for some reason unrelated to a protocol 3783 failure. If a user cancels an operation after the handshake is 3784 complete, just closing the connection by sending a "close_notify" 3785 is more appropriate. This alert SHOULD be followed by a 3786 "close_notify". This alert is generally a warning. 3788 Either party MAY initiate a close by sending a "close_notify" alert. 3789 Any data received after a closure alert MUST be ignored. If a 3790 transport-level close is received prior to a "close_notify", the 3791 receiver cannot know that all the data that was sent has been 3792 received. 3794 Each party MUST send a "close_notify" alert before closing the write 3795 side of the connection, unless some other fatal alert has been 3796 transmitted. The other party MUST respond with a "close_notify" 3797 alert of its own and close down the connection immediately, 3798 discarding any pending writes. The initiator of the close need not 3799 wait for the responding "close_notify" alert before closing the read 3800 side of the connection. 3802 If the application protocol using TLS provides that any data may be 3803 carried over the underlying transport after the TLS connection is 3804 closed, the TLS implementation MUST receive the responding 3805 "close_notify" alert before indicating to the application layer that 3806 the TLS connection has ended. If the application protocol will not 3807 transfer any additional data but will only close the underlying 3808 transport connection, then the implementation MAY choose to close the 3809 transport without waiting for the responding "close_notify". No part 3810 of this standard should be taken to dictate the manner in which a 3811 usage profile for TLS manages its data transport, including when 3812 connections are opened or closed. 3814 Note: It is assumed that closing a connection reliably delivers 3815 pending data before destroying the transport. 3817 6.2. Error Alerts 3819 Error handling in the TLS Handshake Protocol is very simple. When an 3820 error is detected, the detecting party sends a message to its peer. 3821 Upon transmission or receipt of a fatal alert message, both parties 3822 MUST immediately close the connection. 3824 Whenever an implementation encounters a fatal error condition, it 3825 SHOULD send an appropriate fatal alert and MUST close the connection 3826 without sending or receiving any additional data. In the rest of 3827 this specification, when the phrases "terminate the connection" and 3828 "abort the handshake" are used without a specific alert it means that 3829 the implementation SHOULD send the alert indicated by the 3830 descriptions below. The phrases "terminate the connection with a X 3831 alert" and "abort the handshake with a X alert" mean that the 3832 implementation MUST send alert X if it sends any alert. All alerts 3833 defined in this section below, as well as all unknown alerts, are 3834 universally considered fatal as of TLS 1.3 (see Section 6). The 3835 implementation SHOULD provide a way to facilitate logging the sending 3836 and receiving of alerts. 3838 unexpected_message An inappropriate message (e.g., the wrong 3839 handshake message, premature application data, etc.) was received. 3840 This alert should never be observed in communication between 3841 proper implementations. 3843 bad_record_mac This alert is returned if a record is received which 3844 cannot be deprotected. Because AEAD algorithms combine decryption 3845 and verification, and also to avoid side channel attacks, this 3846 alert is used for all deprotection failures. This alert should 3847 never be observed in communication between proper implementations, 3848 except when messages were corrupted in the network. 3850 record_overflow A TLSCiphertext record was received that had a 3851 length more than 2^14 + 256 bytes, or a record decrypted to a 3852 TLSPlaintext record with more than 2^14 bytes. This alert should 3853 never be observed in communication between proper implementations, 3854 except when messages were corrupted in the network. 3856 handshake_failure Receipt of a "handshake_failure" alert message 3857 indicates that the sender was unable to negotiate an acceptable 3858 set of security parameters given the options available. 3860 bad_certificate A certificate was corrupt, contained signatures that 3861 did not verify correctly, etc. 3863 unsupported_certificate A certificate was of an unsupported type. 3865 certificate_revoked A certificate was revoked by its signer. 3867 certificate_expired A certificate has expired or is not currently 3868 valid. 3870 certificate_unknown Some other (unspecified) issue arose in 3871 processing the certificate, rendering it unacceptable. 3873 illegal_parameter A field in the handshake was incorrect or 3874 inconsistent with other fields. This alert is used for errors 3875 which conform to the formal protocol syntax but are otherwise 3876 incorrect. 3878 unknown_ca A valid certificate chain or partial chain was received, 3879 but the certificate was not accepted because the CA certificate 3880 could not be located or could not be matched with a known trust 3881 anchor. 3883 access_denied A valid certificate or PSK was received, but when 3884 access control was applied, the sender decided not to proceed with 3885 negotiation. 3887 decode_error A message could not be decoded because some field was 3888 out of the specified range or the length of the message was 3889 incorrect. This alert is used for errors where the message does 3890 not conform to the formal protocol syntax. This alert should 3891 never be observed in communication between proper implementations, 3892 except when messages were corrupted in the network. 3894 decrypt_error A handshake (not record-layer) cryptographic operation 3895 failed, including being unable to correctly verify a signature or 3896 validate a Finished message or a PSK binder. 3898 protocol_version The protocol version the peer has attempted to 3899 negotiate is recognized but not supported. (see Appendix D) 3901 insufficient_security Returned instead of "handshake_failure" when a 3902 negotiation has failed specifically because the server requires 3903 parameters more secure than those supported by the client. 3905 internal_error An internal error unrelated to the peer or the 3906 correctness of the protocol (such as a memory allocation failure) 3907 makes it impossible to continue. 3909 inappropriate_fallback Sent by a server in response to an invalid 3910 connection retry attempt from a client (see [RFC7507]). 3912 missing_extension Sent by endpoints that receive a hello message not 3913 containing an extension that is mandatory to send for the offered 3914 TLS version or other negotiated parameters. 3916 unsupported_extension Sent by endpoints receiving any hello message 3917 containing an extension known to be prohibited for inclusion in 3918 the given hello message, or including any extensions in a 3919 ServerHello or Certificate not first offered in the corresponding 3920 ClientHello. 3922 certificate_unobtainable Sent by servers when unable to obtain a 3923 certificate from a URL provided by the client via the 3924 "client_certificate_url" extension (see [RFC6066]). 3926 unrecognized_name Sent by servers when no server exists identified 3927 by the name provided by the client via the "server_name" extension 3928 (see [RFC6066]). 3930 bad_certificate_status_response Sent by clients when an invalid or 3931 unacceptable OCSP response is provided by the server via the 3932 "status_request" extension (see [RFC6066]). 3934 bad_certificate_hash_value Sent by servers when a retrieved object 3935 does not have the correct hash provided by the client via the 3936 "client_certificate_url" extension (see [RFC6066]). 3938 unknown_psk_identity Sent by servers when PSK key establishment is 3939 desired but no acceptable PSK identity is provided by the client. 3940 Sending this alert is OPTIONAL; servers MAY instead choose to send 3941 a "decrypt_error" alert to merely indicate an invalid PSK 3942 identity. 3944 certificate_required Sent by servers when a client certificate is 3945 desired but none was provided by the client. 3947 no_application_protocol Sent by servers when a client 3948 "application_layer_protocol_negotiation" extension advertises 3949 protocols that the server does not support (see [RFC7301]). 3951 New Alert values are assigned by IANA as described in Section 11. 3953 7. Cryptographic Computations 3955 The TLS handshake establishes one or more input secrets which are 3956 combined to create the actual working keying material, as detailed 3957 below. The key derivation process incorporates both the input 3958 secrets and the handshake transcript. Note that because the 3959 handshake transcript includes the random values from the Hello 3960 messages, any given handshake will have different traffic secrets, 3961 even if the same input secrets are used, as is the case when the same 3962 PSK is used for multiple connections 3964 7.1. Key Schedule 3966 The key derivation process makes use of the HKDF-Extract and HKDF- 3967 Expand functions as defined for HKDF [RFC5869], as well as the 3968 functions defined below: 3970 HKDF-Expand-Label(Secret, Label, HashValue, Length) = 3971 HKDF-Expand(Secret, HkdfLabel, Length) 3973 Where HkdfLabel is specified as: 3975 struct { 3976 uint16 length = Length; 3977 opaque label<7..255> = "tls13 " + Label; 3978 opaque hash_value<0..255> = HashValue; 3979 } HkdfLabel; 3981 Derive-Secret(Secret, Label, Messages) = 3982 HKDF-Expand-Label(Secret, Label, 3983 Transcript-Hash(Messages), Hash.length) 3985 The Hash function used by Transcript-Hash and HKDF is the cipher 3986 suite hash algorithm. Hash.length is its output length in bytes. 3987 Messages are the concatenation of the indicated handshake messages, 3988 including the handshake message type and length fields, but not 3989 including record layer headers. Note that in some cases a zero- 3990 length HashValue (indicated by "") is passed to HKDF-Expand-Label. 3992 Note: with common hash functions, any label longer than 12 characters 3993 requires an additional iteration of the hash function to compute. 3994 The labels in this specification have all been chosen to fit within 3995 this limit. 3997 Given a set of n InputSecrets, the final "master secret" is computed 3998 by iteratively invoking HKDF-Extract with InputSecret_1, 3999 InputSecret_2, etc. The initial secret is simply a string of 4000 Hash.length zero bytes. Concretely, for the present version of TLS 4001 1.3, secrets are added in the following order: 4003 - PSK (a pre-shared key established externally or derived from the 4004 resumption_master_secret value from a previous connection) 4006 - (EC)DHE shared secret (Section 7.4) 4007 This produces a full key derivation schedule shown in the diagram 4008 below. In this diagram, the following formatting conventions apply: 4010 - HKDF-Extract is drawn as taking the Salt argument from the top and 4011 the IKM argument from the left. 4013 - Derive-Secret's Secret argument is indicated by the incoming 4014 arrow. For instance, the Early Secret is the Secret for 4015 generating the client_early_traffic_secret. 4017 0 4018 | 4019 v 4020 PSK -> HKDF-Extract = Early Secret 4021 | 4022 +-----> Derive-Secret(., 4023 | "ext binder" | 4024 | "res binder", 4025 | "") 4026 | = binder_key 4027 | 4028 +-----> Derive-Secret(., "c e traffic", 4029 | ClientHello) 4030 | = client_early_traffic_secret 4031 | 4032 +-----> Derive-Secret(., "e exp master", 4033 | ClientHello) 4034 | = early_exporter_master_secret 4035 v 4036 Derive-Secret(., "derived", "") 4037 | 4038 v 4039 (EC)DHE -> HKDF-Extract = Handshake Secret 4040 | 4041 +-----> Derive-Secret(., "c hs traffic", 4042 | ClientHello...ServerHello) 4043 | = client_handshake_traffic_secret 4044 | 4045 +-----> Derive-Secret(., "s hs traffic", 4046 | ClientHello...ServerHello) 4047 | = server_handshake_traffic_secret 4048 v 4049 Derive-Secret(., "derived", "") 4050 | 4051 v 4052 0 -> HKDF-Extract = Master Secret 4053 | 4054 +-----> Derive-Secret(., "c ap traffic", 4055 | ClientHello...server Finished) 4056 | = client_application_traffic_secret_0 4057 | 4058 +-----> Derive-Secret(., "s ap traffic", 4059 | ClientHello...server Finished) 4060 | = server_application_traffic_secret_0 4061 | 4062 +-----> Derive-Secret(., "exp master", 4063 | ClientHello...server Finished) 4064 | = exporter_master_secret 4065 | 4066 +-----> Derive-Secret(., "res master", 4067 ClientHello...client Finished) 4068 = resumption_master_secret 4070 The general pattern here is that the secrets shown down the left side 4071 of the diagram are just raw entropy without context, whereas the 4072 secrets down the right side include handshake context and therefore 4073 can be used to derive working keys without additional context. Note 4074 that the different calls to Derive-Secret may take different Messages 4075 arguments, even with the same secret. In a 0-RTT exchange, Derive- 4076 Secret is called with four distinct transcripts; in a 1-RTT-only 4077 exchange with three distinct transcripts. 4079 If a given secret is not available, then the 0-value consisting of a 4080 string of Hash.length zero bytes is used. Note that this does not 4081 mean skipping rounds, so if PSK is not in use Early Secret will still 4082 be HKDF-Extract(0, 0). For the computation of the binder_secret, the 4083 label is "ext binder" for external PSKs (those provisioned outside of 4084 TLS) and "res binder" for resumption PSKs (those provisioned as the 4085 resumption master secret of a previous handshake). The different 4086 labels prevent the substitution of one type of PSK for the other. 4088 There are multiple potential Early Secret values depending on which 4089 PSK the server ultimately selects. The client will need to compute 4090 one for each potential PSK; if no PSK is selected, it will then need 4091 to compute the early secret corresponding to the zero PSK. 4093 Once all the values which are to be derived from a given secret have 4094 been computed, that secret SHOULD be erased. 4096 7.2. Updating Traffic Keys and IVs 4098 Once the handshake is complete, it is possible for either side to 4099 update its sending traffic keys using the KeyUpdate handshake message 4100 defined in Section 4.6.3. The next generation of traffic keys is 4101 computed by generating client_/server_application_traffic_secret_N+1 4102 from client_/server_application_traffic_secret_N as described in this 4103 section then re-deriving the traffic keys as described in 4104 Section 7.3. 4106 The next-generation application_traffic_secret is computed as: 4108 application_traffic_secret_N+1 = 4109 HKDF-Expand-Label(application_traffic_secret_N, 4110 "traffic upd", "", Hash.length) 4112 Once client/server_application_traffic_secret_N+1 and its associated 4113 traffic keys have been computed, implementations SHOULD delete 4114 client_/server_application_traffic_secret_N and its associated 4115 traffic keys. 4117 7.3. Traffic Key Calculation 4119 The traffic keying material is generated from the following input 4120 values: 4122 - A secret value 4124 - A purpose value indicating the specific value being generated 4126 - The length of the key 4128 The traffic keying material is generated from an input traffic secret 4129 value using: 4131 [sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length) 4132 [sender]_write_iv = HKDF-Expand-Label(Secret, "iv" , "", iv_length) 4134 [sender] denotes the sending side. The Secret value for each record 4135 type is shown in the table below. 4137 +-------------------+---------------------------------------+ 4138 | Record Type | Secret | 4139 +-------------------+---------------------------------------+ 4140 | 0-RTT Application | client_early_traffic_secret | 4141 | | | 4142 | Handshake | [sender]_handshake_traffic_secret | 4143 | | | 4144 | Application Data | [sender]_application_traffic_secret_N | 4145 +-------------------+---------------------------------------+ 4147 All the traffic keying material is recomputed whenever the underlying 4148 Secret changes (e.g., when changing from the handshake to application 4149 data keys or upon a key update). 4151 7.4. (EC)DHE Shared Secret Calculation 4153 7.4.1. Finite Field Diffie-Hellman 4155 For finite field groups, a conventional Diffie-Hellman computation is 4156 performed. The negotiated key (Z) is converted to a byte string by 4157 encoding in big-endian and padded with zeros up to the size of the 4158 prime. This byte string is used as the shared secret in the key 4159 schedule as specified above. 4161 Note that this construction differs from previous versions of TLS 4162 which remove leading zeros. 4164 7.4.2. Elliptic Curve Diffie-Hellman 4166 For secp256r1, secp384r1 and secp521r1, ECDH calculations (including 4167 parameter and key generation as well as the shared secret 4168 calculation) are performed according to [IEEE1363] using the ECKAS- 4169 DH1 scheme with the identity map as key derivation function (KDF), so 4170 that the shared secret is the x-coordinate of the ECDH shared secret 4171 elliptic curve point represented as an octet string. Note that this 4172 octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the 4173 Field Element to Octet String Conversion Primitive, has constant 4174 length for any given field; leading zeros found in this octet string 4175 MUST NOT be truncated. 4177 (Note that this use of the identity KDF is a technicality. The 4178 complete picture is that ECDH is employed with a non-trivial KDF 4179 because TLS does not directly use this secret for anything other than 4180 for computing other secrets.) 4182 ECDH functions are used as follows: 4184 - The public key to put into the KeyShareEntry.key_exchange 4185 structure is the result of applying the ECDH scalar multiplication 4186 function to the secret key of appropriate length (into scalar 4187 input) and the standard public basepoint (into u-coordinate point 4188 input). 4190 - The ECDH shared secret is the result of applying the ECDH scalar 4191 multiplication function to the secret key (into scalar input) and 4192 the peer's public key (into u-coordinate point input). The output 4193 is used raw, with no processing. 4195 For X25519 and X448, implementations SHOULD use the approach 4196 specified in [RFC7748] to calculate the Diffie-Hellman shared secret. 4197 Implementations MUST check whether the computed Diffie-Hellman shared 4198 secret is the all-zero value and abort if so, as described in 4199 Section 6 of [RFC7748]. If implementers use an alternative 4200 implementation of these elliptic curves, they SHOULD perform the 4201 additional checks specified in Section 7 of [RFC7748]. 4203 7.5. Exporters 4205 [RFC5705] defines keying material exporters for TLS in terms of the 4206 TLS pseudorandom function (PRF). This document replaces the PRF with 4207 HKDF, thus requiring a new construction. The exporter interface 4208 remains the same. 4210 The exporter value is computed as: 4212 HKDF-Expand-Label(Derive-Secret(Secret, label, ""), 4213 "exporter", Hash(context_value), key_length) 4215 Where Secret is either the early_exporter_master_secret or the 4216 exporter_master_secret. Implementations MUST use the 4217 exporter_master_secret unless explicitly specified by the 4218 application. The early_exporter_master_secret is defined for use in 4219 settings where an exporter is needed for 0-RTT data. A separate 4220 interface for the early exporter is RECOMMENDED, especially on a 4221 server where a single interface can make the early exporter 4222 inaccessible. 4224 If no context is provided, the context_value is zero-length. 4225 Consequently, providing no context computes the same value as 4226 providing an empty context. This is a change from previous versions 4227 of TLS where an empty context produced a different output to an 4228 absent context. As of this document's publication, no allocated 4229 exporter label is used both with and without a context. Future 4230 specifications MUST NOT define a use of exporters that permit both an 4231 empty context and no context with the same label. New uses of 4232 exporters SHOULD provide a context in all exporter computations, 4233 though the value could be empty. 4235 Requirements for the format of exporter labels are defined in section 4236 4 of [RFC5705]. 4238 8. 0-RTT and Anti-Replay 4240 As noted in Section 2.3 and Appendix E.5, TLS does not provide 4241 inherent replay protections for 0-RTT data. There are two potential 4242 threats to be concerned with: 4244 - Network attackers who mount a replay attack by simply duplicating 4245 a flight of 0-RTT data. 4247 - Network attackers who take advantage of client retry behavior to 4248 arrange for the server to receive multiple copies of an 4249 application message. This threat already exists to some extent 4250 because clients that value robustness respond to network errors by 4251 attempting to retry requests. However, 0-RTT adds an additional 4252 dimension for any server system which does not maintain globally 4253 consistent server state. Specifically, if a server system has 4254 multiple zones where tickets from zone A will not be accepted in 4255 zone B, then an attacker can duplicate a ClientHello and early 4256 data intended for A to both A and B. At A, the data will be 4257 accepted in 0-RTT, but at B the server will reject 0-RTT data and 4258 instead force a full handshake. If the attacker blocks the 4259 ServerHello from A, then the client will complete the handshake 4260 with B and probably retry the request, leading to duplication on 4261 the server system as a whole. 4263 The first class of attack can be prevented by the mechanism described 4264 in this section. Servers need not permit 0-RTT at all, but those 4265 which do SHOULD implement either the single-use tickets or 4266 ClientHello recording techniques described in the following two 4267 sections. 4269 The second class of attack cannot be prevented at the TLS layer and 4270 MUST be dealt with by any application. Note that any application 4271 whose clients implement any kind of retry behavior already needs to 4272 implement some sort of anti-replay defense. 4274 In normal operation, clients will not know which, if any, of these 4275 mechanisms servers actually implement and therefore MUST only send 4276 early data which they are willing to have subject to the attacks 4277 described in Appendix E.5. 4279 8.1. Single-Use Tickets 4281 The simplest form of anti-replay defense is for the server to only 4282 allow each session ticket to be used once. For instance, the server 4283 can maintain a database of all outstanding valid tickets; deleting 4284 each ticket from the database as it is used. If an unknown ticket is 4285 provided, the server would then fall back to a full handshake. 4287 If the tickets are not self-contained but rather are database keys, 4288 and the corresponding PSKs are deleted upon use, then connections 4289 established using one PSK enjoy forward security. This improves 4290 security for all 0-RTT data and PSK usage when PSK is used without 4291 (EC)DHE. 4293 Because this mechanism requires sharing the session database between 4294 server nodes in environments with multiple distributed servers, it 4295 may be hard to achieve high rates of successful PSK 0-RTT connections 4296 when compared to self-encrypted tickets. Unlike session databases, 4297 session tickets can successfully do PSK-based session establishment 4298 even without consistent storage, though when 0-RTT is allowed they 4299 still require consistent storage for anti-replay of 0-RTT data, as 4300 detailed in the following section. 4302 8.2. Client Hello Recording 4304 An alternative form of anti-replay is to record a unique value 4305 derived from the ClientHello (generally either the random value or 4306 the PSK binder) and reject duplicates. Recording all ClientHellos 4307 causes state to grow without bound, but a server can instead record 4308 ClientHellos within a given time window and use the 4309 "obfuscated_ticket_age" to ensure that tickets aren't reused outside 4310 that window. 4312 In order to implement this, when a ClientHello is received, the 4313 server first verifies the PSK binder as described Section 4.2.10. It 4314 then computes the expected_arrival_time as described in the next 4315 section and rejects 0-RTT if it is outside the recording window, 4316 falling back to the 1-RTT handshake. 4318 If the expected arrival time is in the window, then the server checks 4319 to see if it has recorded a matching ClientHello. If one is found, 4320 it either aborts the handshake with an "illegal_parameter" alert or 4321 accepts the PSK but reject 0-RTT. If no matching ClientHello is 4322 found, then it accepts 0-RTT and then stores the ClientHello for as 4323 long as the expected_arrival_time is inside the window. Servers MAY 4324 also implement data stores with false positives, such as Bloom 4325 filters, in which case they MUST respond to apparent replay by 4326 rejecting 0-RTT but MUST NOT abort the handshake. 4328 The server MUST derive the storage key only from validated sections 4329 of the ClientHello. If the ClientHello contains multiple PSK 4330 identities, then an attacker can create multiple ClientHellos with 4331 different binder values for the less-preferred identity on the 4332 assumption that the server will not verify it, as recommended by 4333 Section 4.2.10. I.e., if the client sends PSKs A and B but the 4334 server prefers A, then the attacker can change the binder for B 4335 without affecting the binder for A. This will cause the ClientHello 4336 to be accepted, and may casue side effects such as replay cache 4337 pollution, although any 0-RTT data will not be decryptable because it 4338 will use different keys. If the validated binder or the 4339 ClientHello.random are used as the storage key, then this attack is 4340 not possible. 4342 Because this mechanism does not require storing all outstanding 4343 tickets, it may be easier to implement in distributed systems with 4344 high rates of resumption and 0-RTT, at the cost of potentially weaker 4345 anti-replay defense because of the difficulty of reliably storing and 4346 retrieving the received ClientHello messages. In many such systems, 4347 it is impractical to have globally consistent storage of all the 4348 received ClientHellos. In this case, the best anti-replay protection 4349 is provided by having a single storage zone be authoritative for a 4350 given ticket and refusing 0-RTT for that ticket in any other zone. 4351 This approach prevents simple replay by the attacker because only one 4352 zone will accept 0-RTT data. A weaker design is to implement 4353 separate storage for each zone but allow 0-RTT in any zone. This 4354 approach limits the number of replays to once per zone. Application 4355 message duplication of course remains possible with either design. 4357 When implementations are freshly started, they SHOULD reject 0-RTT as 4358 long as any portion of their recording window overlaps the startup 4359 time. Otherwise, they run the risk of accepting replays which were 4360 originally sent during that period. 4362 Note: If the client's clock is running much faster than the server's 4363 then a ClientHello may be received that is outside the window in the 4364 future, in which case it might be accepted for 1-RTT, causing a 4365 client retry, and then acceptable later for 0-RTT. This is another 4366 variant of the second form of attack described above. 4368 8.3. Freshness Checks 4370 Because the ClientHello indicates the time at which the client sent 4371 it, it is possible to efficiently determine whether a ClientHello was 4372 likely sent reasonably recently and only accept 0-RTT for such a 4373 ClientHello, otherwise falling back to a 1-RTT handshake. This is 4374 necessary for the ClientHello storage mechanism described in 4375 Section 8.2 because otherwise the server needs to store an unlimited 4376 number of ClientHellos and is a useful optimization for single-use 4377 tickets because it allows efficient rejection of ClientHellos which 4378 cannot be used for 0-RTT. 4380 In order to implement this mechanism, a server needs to store the 4381 time that the server generated the session ticket, offset by an 4382 estimate of the round trip time between client and server. I.e., 4384 adjusted_creation_time = creation_time + estimated_RTT 4386 This value can be encoded in the ticket, thus avoiding the need to 4387 keep state for each outstanding ticket. The server can determine the 4388 client's view of the age of the ticket by subtracting the ticket's 4389 "ticket_age_add value" from the "obfuscated_ticket_age" parameter in 4390 the client's "pre_shared_key" extension. The server can determine 4391 the "expected arrival time" of the ClientHello as: 4393 expected_arrival_time = adjusted_creation_time + clients_ticket_age 4395 When a new ClientHello is received, the expected_arrival_time is then 4396 compared against the current server wall clock time and if they 4397 differ by more than a certain amount, 0-RTT is rejected, though the 4398 1-RTT handshake can be allowed to complete. 4400 There are several potential sources of error that might cause 4401 mismatches between the expected arrival time and the measured time. 4402 Variations in client and server clock rates are likely to be minimal, 4403 though potentially with gross time corrections. Network propagation 4404 delays are the most likely causes of a mismatch in legitimate values 4405 for elapsed time. Both the NewSessionTicket and ClientHello messages 4406 might be retransmitted and therefore delayed, which might be hidden 4407 by TCP. For clients on the Internet, this implies windows on the 4408 order of ten seconds to account for errors in clocks and variations 4409 in measurements; other deployment scenarios may have different needs. 4410 Clock skew distributions are not symmetric, so the optimal tradeoff 4411 may involve an asymmetric range of permissible mismatch values. 4413 Note that freshness checking alone is not sufficient to prevent 4414 replays because it does not detect them during the error window, 4415 which, depending on bandwidth and system capacity could include 4416 billions of replays in real-world settings. In addition, this 4417 freshness checking is only done at the time the ClientHello is 4418 received, and not when later early application data records are 4419 received. After early data is accepted, records may continue to be 4420 streamed to the server over a longer time period. 4422 9. Compliance Requirements 4424 9.1. Mandatory-to-Implement Cipher Suites 4426 In the absence of an application profile standard specifying 4427 otherwise, a TLS-compliant application MUST implement the 4428 TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the 4429 TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 4430 [RFC7539] cipher suites. (see Appendix B.4) 4432 A TLS-compliant application MUST support digital signatures with 4433 rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for 4434 CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A 4435 TLS-compliant application MUST support key exchange with secp256r1 4436 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. 4438 9.2. Mandatory-to-Implement Extensions 4440 In the absence of an application profile standard specifying 4441 otherwise, a TLS-compliant application MUST implement the following 4442 TLS extensions: 4444 - Supported Versions ("supported_versions"; Section 4.2.1) 4446 - Cookie ("cookie"; Section 4.2.2) 4448 - Signature Algorithms ("signature_algorithms"; Section 4.2.3) 4450 - Negotiated Groups ("supported_groups"; Section 4.2.6) 4452 - Key Share ("key_share"; Section 4.2.7) 4454 - Server Name Indication ("server_name"; Section 3 of [RFC6066]) 4456 All implementations MUST send and use these extensions when offering 4457 applicable features: 4459 - "supported_versions" is REQUIRED for all ClientHello messages. 4461 - "signature_algorithms" is REQUIRED for certificate authentication. 4463 - "supported_groups" is REQUIRED for ClientHello messages using DHE 4464 or ECDHE key exchange. 4466 - "key_share" is REQUIRED for DHE or ECDHE key exchange. 4468 - "pre_shared_key" is REQUIRED for PSK key agreement. 4470 A client is considered to be attempting to negotiate using this 4471 specification if the ClientHello contains a "supported_versions" 4472 extension 0x0304 the highest version number contained in its body. 4473 Such a ClientHello message MUST meet the following requirements: 4475 - If not containing a "pre_shared_key" extension, it MUST contain 4476 both a "signature_algorithms" extension and a "supported_groups" 4477 extension. 4479 - If containing a "supported_groups" extension, it MUST also contain 4480 a "key_share" extension, and vice versa. An empty 4481 KeyShare.client_shares vector is permitted. 4483 Servers receiving a ClientHello which does not conform to these 4484 requirements MUST abort the handshake with a "missing_extension" 4485 alert. 4487 Additionally, all implementations MUST support use of the 4488 "server_name" extension with applications capable of using it. 4489 Servers MAY require clients to send a valid "server_name" extension. 4490 Servers requiring this extension SHOULD respond to a ClientHello 4491 lacking a "server_name" extension by terminating the connection with 4492 a "missing_extension" alert. 4494 10. Security Considerations 4496 Security issues are discussed throughout this memo, especially in 4497 Appendix C, Appendix D, and Appendix E. 4499 11. IANA Considerations 4501 This document uses several registries that were originally created in 4502 [RFC4346]. IANA has updated these to reference this document. The 4503 registries and their allocation policies are below: 4505 - TLS Cipher Suite Registry: values with the first byte in the range 4506 0-254 (decimal) are assigned via Specification Required [RFC5226]. 4507 Values with the first byte 255 (decimal) are reserved for Private 4508 Use [RFC5226]. 4510 IANA [SHALL add/has added] the cipher suites listed in 4511 Appendix B.4 to the registry. The "Value" and "Description" 4512 columns are taken from the table. The "DTLS-OK" and "Recommended" 4513 columns are both marked as "Yes" for each new cipher suite. 4514 [[This assumes [I-D.ietf-tls-iana-registry-updates] has been 4515 applied.]] 4517 - TLS ContentType Registry: Future values are allocated via 4518 Standards Action [RFC5226]. 4520 - TLS Alert Registry: Future values are allocated via Standards 4521 Action [RFC5226]. IANA [SHALL update/has updated] this registry 4522 to include values for "missing_extension" and 4523 "certificate_required". 4525 - TLS HandshakeType Registry: Future values are allocated via 4526 Standards Action [RFC5226]. IANA [SHALL update/has updated] this 4527 registry to rename item 4 from "NewSessionTicket" to 4528 "new_session_ticket" and to add the "hello_retry_request", 4529 "encrypted_extensions", "end_of_early_data", "key_update", and 4530 "handshake_hash" values. 4532 This document also uses the TLS ExtensionType Registry originally 4533 created in [RFC4366]. IANA has updated it to reference this 4534 document. The registry and its allocation policy is listed below: 4536 - IANA [SHALL update/has updated] this registry to include the 4537 "key_share", "pre_shared_key", "psk_key_exchange_modes", 4538 "early_data", "cookie", "supported_versions", 4539 "certificate_authorities", "oid_filters", and 4540 "post_handshake_auth" extensions with the values defined in this 4541 document and the Recommended value of "Yes". 4543 - IANA [SHALL update/has updated] this registry to include a "TLS 4544 1.3" column which lists the messages in which the extension may 4545 appear. This column [SHALL be/has been] initially populated from 4546 the table in Section 4.2 with any extension not listed there 4547 marked as "-" to indicate that it is not used by TLS 1.3. 4549 In addition, this document defines a new registry to be maintained by 4550 IANA: 4552 - TLS SignatureScheme Registry: Values with the first byte in the 4553 range 0-254 (decimal) are assigned via Specification Required 4554 [RFC5226]. Values with the first byte 255 (decimal) are reserved 4555 for Private Use [RFC5226]. Values with the first byte in the 4556 range 0-6 or with the second byte in the range 0-3 that are not 4557 currently allocated are reserved for backwards compatibility. 4558 This registry SHALL have a "Recommended" column. The registry 4559 [shall be/ has been] initially populated with the values described 4560 in Section 4.2.3. The following values SHALL be marked as 4561 "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, 4562 rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. 4564 12. References 4566 12.1. Normative References 4568 [DH] Diffie, W. and M. Hellman, "New Directions in 4569 Cryptography", IEEE Transactions on Information Theory, 4570 V.IT-22 n.6 , June 1977. 4572 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 4573 Operation: Galois/Counter Mode (GCM) and GMAC", 4574 NIST Special Publication 800-38D, November 2007. 4576 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4577 Hashing for Message Authentication", RFC 2104, 4578 DOI 10.17487/RFC2104, February 1997, 4579 . 4581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4582 Requirement Levels", BCP 14, RFC 2119, 4583 DOI 10.17487/RFC2119, March 1997, 4584 . 4586 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 4587 IANA Considerations Section in RFCs", RFC 5226, 4588 DOI 10.17487/RFC5226, May 2008, 4589 . 4591 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 4592 Housley, R., and W. Polk, "Internet X.509 Public Key 4593 Infrastructure Certificate and Certificate Revocation List 4594 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 4595 . 4597 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 4598 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 4599 March 2010, . 4601 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 4602 Key Derivation Function (HKDF)", RFC 5869, 4603 DOI 10.17487/RFC5869, May 2010, 4604 . 4606 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 4607 Extensions: Extension Definitions", RFC 6066, 4608 DOI 10.17487/RFC6066, January 2011, 4609 . 4611 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 4612 Transport Layer Security (TLS)", RFC 6655, 4613 DOI 10.17487/RFC6655, July 2012, 4614 . 4616 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 4617 Galperin, S., and C. Adams, "X.509 Internet Public Key 4618 Infrastructure Online Certificate Status Protocol - OCSP", 4619 RFC 6960, DOI 10.17487/RFC6960, June 2013, 4620 . 4622 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 4623 Multiple Certificate Status Request Extension", RFC 6961, 4624 DOI 10.17487/RFC6961, June 2013, 4625 . 4627 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 4628 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 4629 . 4631 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 4632 Algorithm (DSA) and Elliptic Curve Digital Signature 4633 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 4634 2013, . 4636 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 4637 "Transport Layer Security (TLS) Application-Layer Protocol 4638 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 4639 July 2014, . 4641 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 4642 Suite Value (SCSV) for Preventing Protocol Downgrade 4643 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 4644 . 4646 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 4647 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 4648 . 4650 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 4651 for Security", RFC 7748, DOI 10.17487/RFC7748, January 4652 2016, . 4654 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 4655 Ephemeral Parameters for Transport Layer Security (TLS)", 4656 RFC 7919, DOI 10.17487/RFC7919, August 2016, 4657 . 4659 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 4660 "PKCS #1: RSA Cryptography Specifications Version 2.2", 4661 RFC 8017, DOI 10.17487/RFC8017, November 2016, 4662 . 4664 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 4665 Signature Algorithm (EdDSA)", RFC 8032, 4666 DOI 10.17487/RFC8032, January 2017, 4667 . 4669 [SHS] National Institute of Standards and Technology, U.S. 4670 Department of Commerce, "Secure Hash Standard", NIST FIPS 4671 PUB 180-4, March 2012. 4673 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 4674 Specification of Basic Encoding Rules (BER), Canonical 4675 Encoding Rules (CER) and Distinguished Encoding Rules 4676 (DER)", ISO/IEC 8825-1:2002, 2002. 4678 [X962] ANSI, "Public Key Cryptography For The Financial Services 4679 Industry: The Elliptic Curve Digital Signature Algorithm 4680 (ECDSA)", ANSI X9.62, 1998. 4682 12.2. Informative References 4684 [AEAD-LIMITS] 4685 Luykx, A. and K. Paterson, "Limits on Authenticated 4686 Encryption Use in TLS", 2016, 4687 . 4689 [BBFKZG16] 4690 Bhargavan, K., Brzuska, C., Fournet, C., Kohlweiss, M., 4691 Zanella-Beguelin, S., and M. Green, "Downgrade Resilience 4692 in Key-Exchange Protocols", Proceedings of IEEE Symposium 4693 on Security and Privacy (Oakland) 2016 , 2016. 4695 [BBK17] Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified 4696 Models and Reference Implementations for the TLS 1.3 4697 Standard Candidate", Proceedings of IEEE Symposium on 4698 Security and Privacy (Oakland) 2017 , 2017. 4700 [BDFKPPRSZZ16] 4701 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., 4702 Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy, 4703 N., Zanella-Beguelin, S., and J. Zinzindohoue, 4704 "Implementing and Proving the TLS 1.3 Record Layer", 4705 Proceedings of IEEE Symposium on Security and Privacy 4706 (Oakland) 2017 , December 2016, 4707 . 4709 [BMMT15] Badertscher, C., Matt, C., Maurer, U., and B. Tackmann, 4710 "Augmented Secure Channels and the Goal of the TLS 1.3 4711 Record Layer", ProvSec 2015 , September 2015, 4712 . 4714 [BT16] Bellare, M. and B. Tackmann, "The Multi-User Security of 4715 Authenticated Encryption: AES-GCM in TLS 1.3", Proceedings 4716 of CRYPTO 2016 , 2016, . 4718 [CCG16] Cohn-Gordon, K., Cremers, C., and L. Garratt, "On Post- 4719 Compromise Security", IEEE Computer Security Foundations 4720 Symposium , 2015. 4722 [CHHSV17] Cremers, C., Horvat, M., Hoyland, J., van der Merwe, T., 4723 and S. Scott, "Awkward Handshake: Possible mismatch of 4724 client/server view on client authentication in post- 4725 handshake mode in Revision 18", 2017, 4726 . 4729 [CHSV16] Cremers, C., Horvat, M., Scott, S., and T. van der Merwe, 4730 "Automated Analysis and Verification of TLS 1.3: 0-RTT, 4731 Resumption and Delayed Authentication", Proceedings of 4732 IEEE Symposium on Security and Privacy (Oakland) 2016 , 4733 2016, . 4735 [CK01] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange 4736 Protocols and Their Use for Building Secure Channels", 4737 Proceedings of Eurocrypt 2001 , 2001. 4739 [CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know 4740 Why You Went to the Clinic: Risks and Realization of HTTPS 4741 Traffic Analysis", Privacy Enhancing Technologies pp. 4742 143-163, DOI 10.1007/978-3-319-08506-7_8, 2014. 4744 [DFGS15] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, 4745 "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and 4746 Pre-shared Key Handshake Protocol", Proceedings of ACM CCS 4747 2015 , 2015, . 4749 [DFGS16] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, 4750 "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and 4751 Pre-shared Key Handshake Protocol", TRON 2016 , 2016, 4752 . 4754 [DOW92] Diffie, W., van Oorschot, P., and M. Wiener, 4755 ""Authentication and authenticated key exchanges"", 4756 Designs, Codes and Cryptography , 1992. 4758 [DSS] National Institute of Standards and Technology, U.S. 4759 Department of Commerce, "Digital Signature Standard, 4760 version 4", NIST FIPS PUB 186-4, 2013. 4762 [ECDSA] American National Standards Institute, "Public Key 4763 Cryptography for the Financial Services Industry: The 4764 Elliptic Curve Digital Signature Algorithm (ECDSA)", 4765 ANSI ANS X9.62-2005, November 2005. 4767 [FG17] Fischlin, M. and F. Guenther, "Replay Attacks on Zero 4768 Round-Trip Time: The Case of the TLS 1.3 Handshake 4769 Candidates", Proceedings of Euro S"P 2017 , 2017, 4770 . 4772 [FGSW16] Fischlin, M., Guenther, F., Schmidt, B., and B. Warinschi, 4773 "Key Confirmation in Key Exchange: A Formal Treatment and 4774 Implications for TLS 1.3", Proceedings of IEEE Symposium 4775 on Security and Privacy (Oakland) 2016 , 2016, 4776 . 4778 [FW15] Florian Weimer, ., "Factoring RSA Keys With TLS Perfect 4779 Forward Secrecy", September 2015. 4781 [HCJ16] Husak, M., Čermak, M., Jirsik, T., and P. 4782 Čeleda, "HTTPS traffic analysis and client 4783 identification using passive SSL/TLS fingerprinting", 4784 EURASIP Journal on Information Security Vol. 2016, 4785 DOI 10.1186/s13635-016-0030-7, February 2016. 4787 [HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes, 4788 "Prying Open Pandora's Box: KCI Attacks against TLS", 4789 Proceedings of USENIX Workshop on Offensive Technologies , 4790 2015. 4792 [I-D.ietf-tls-iana-registry-updates] 4793 Salowey, J. and S. Turner, "D/TLS IANA Registry Updates", 4794 draft-ietf-tls-iana-registry-updates-01 (work in 4795 progress), April 2017. 4797 [I-D.ietf-tls-tls13-vectors] 4798 Thomson, M., "Example Handshake Traces for TLS 1.3", 4799 draft-ietf-tls-tls13-vectors-01 (work in progress), June 4800 2017. 4802 [IEEE1363] 4803 IEEE, "Standard Specifications for Public Key 4804 Cryptography", IEEE 1363 , 2000. 4806 [KEYAGREEMENT] 4807 Barker, E., Lily Chen, ., Roginsky, A., and M. Smid, 4808 "Recommendation for Pair-Wise Key Establishment Schemes 4809 Using Discrete Logarithm Cryptography", NIST Special 4810 Publication 800-38D, May 2013. 4812 [Kraw10] Krawczyk, H., "Cryptographic Extraction and Key 4813 Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 , 4814 2010, . 4816 [Kraw16] Krawczyk, H., "A Unilateral-to-Mutual Authentication 4817 Compiler for Key Exchange (with Applications to Client 4818 Authentication in TLS 1.3", Proceedings of ACM CCS 2016 , 4819 2016, . 4821 [KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", 4822 Proceedings of Euro S"P 2016 , 2016, 4823 . 4825 [LXZFH16] Li, X., Xu, J., Feng, D., Zhang, Z., and H. Hu, "Multiple 4826 Handshakes Security of TLS 1.3 Candidates", Proceedings of 4827 IEEE Symposium on Security and Privacy (Oakland) 2016 , 4828 2016, . 4830 [Mac17] MacCarthaigh, C., "Security Review of TLS1.3 0-RTT", 2017, 4831 . 4833 [PSK-FINISHED] 4834 Cremers, C., Horvat, M., van der Merwe, T., and S. Scott, 4835 "Revision 10: possible attack if client authentication is 4836 allowed during PSK", 2015, . 4839 [REKEY] Abdalla, M. and M. Bellare, "Increasing the Lifetime of a 4840 Key: A Comparative Analysis of the Security of Re-keying 4841 Techniques", ASIACRYPT2000 , October 2000. 4843 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 4844 Text on Security Considerations", BCP 72, RFC 3552, 4845 DOI 10.17487/RFC3552, July 2003, 4846 . 4848 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 4849 "Randomness Requirements for Security", BCP 106, RFC 4086, 4850 DOI 10.17487/RFC4086, June 2005, 4851 . 4853 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 4854 (TLS) Protocol Version 1.1", RFC 4346, 4855 DOI 10.17487/RFC4346, April 2006, 4856 . 4858 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 4859 and T. Wright, "Transport Layer Security (TLS) 4860 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 4861 . 4863 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 4864 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 4865 for Transport Layer Security (TLS)", RFC 4492, 4866 DOI 10.17487/RFC4492, May 2006, 4867 . 4869 [RFC4681] Santesson, S., Medvinsky, A., and J. Ball, "TLS User 4870 Mapping Extension", RFC 4681, DOI 10.17487/RFC4681, 4871 October 2006, . 4873 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 4874 "Transport Layer Security (TLS) Session Resumption without 4875 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 4876 January 2008, . 4878 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 4879 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 4880 . 4882 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 4883 (TLS) Protocol Version 1.2", RFC 5246, 4884 DOI 10.17487/RFC5246, August 2008, 4885 . 4887 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 4888 Security (DTLS) Extension to Establish Keys for the Secure 4889 Real-time Transport Protocol (SRTP)", RFC 5764, 4890 DOI 10.17487/RFC5764, May 2010, 4891 . 4893 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 4894 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 4895 . 4897 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 4898 for Transport Layer Security (TLS) Authentication", 4899 RFC 6091, DOI 10.17487/RFC6091, February 2011, 4900 . 4902 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 4903 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 4904 2011, . 4906 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4907 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 4908 January 2012, . 4910 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 4911 Layer Security (TLS) and Datagram Transport Layer Security 4912 (DTLS) Heartbeat Extension", RFC 6520, 4913 DOI 10.17487/RFC6520, February 2012, 4914 . 4916 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 4917 Protocol (HTTP/1.1): Message Syntax and Routing", 4918 RFC 7230, DOI 10.17487/RFC7230, June 2014, 4919 . 4921 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 4922 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 4923 Transport Layer Security (TLS) and Datagram Transport 4924 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 4925 June 2014, . 4927 [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, 4928 DOI 10.17487/RFC7465, February 2015, 4929 . 4931 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 4932 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 4933 DOI 10.17487/RFC7568, June 2015, 4934 . 4936 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 4937 Langley, A., and M. Ray, "Transport Layer Security (TLS) 4938 Session Hash and Extended Master Secret Extension", 4939 RFC 7627, DOI 10.17487/RFC7627, September 2015, 4940 . 4942 [RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello 4943 Padding Extension", RFC 7685, DOI 10.17487/RFC7685, 4944 October 2015, . 4946 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 4947 (TLS) Cached Information Extension", RFC 7924, 4948 DOI 10.17487/RFC7924, July 2016, 4949 . 4951 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 4952 Obtaining Digital Signatures and Public-Key 4953 Cryptosystems", Communications of the ACM v. 21, n. 2, pp. 4954 120-126., February 1978. 4956 [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' approach to 4957 authenticated Diffie-Hellman and its use in the IKE 4958 protocols", Proceedings of CRYPTO 2003 , 2003. 4960 [SLOTH] Bhargavan, K. and G. Leurent, "Transcript Collision 4961 Attacks: Breaking Authentication in TLS, IKE, and SSH", 4962 Network and Distributed System Security Symposium (NDSS 4963 2016) , 2016. 4965 [SSL2] Hickman, K., "The SSL Protocol", February 1995. 4967 [SSL3] Freier, A., Karlton, P., and P. Kocher, "The SSL 3.0 4968 Protocol", November 1996. 4970 [TIMING] Boneh, D. and D. Brumley, "Remote timing attacks are 4971 practical", USENIX Security Symposium, 2003. 4973 [X501] "Information Technology - Open Systems Interconnection - 4974 The Directory: Models", ITU-T X.501, 1993. 4976 12.3. URIs 4978 [1] mailto:tls@ietf.org 4980 Appendix A. State Machine 4982 This section provides a summary of the legal state transitions for 4983 the client and server handshakes. State names (in all capitals, 4984 e.g., START) have no formal meaning but are provided for ease of 4985 comprehension. Actions which are taken only in certain circumstances 4986 are indicated in []. The notation "K_{send,recv} = foo" means "set 4987 the send/recv key to the given key". 4989 A.1. Client 4991 START <----+ 4992 Send ClientHello | | Recv HelloRetryRequest 4993 [K_send = early data] | | 4994 v | 4995 / WAIT_SH ----+ 4996 | | Recv ServerHello 4997 | | K_recv = handshake 4998 Can | V 4999 send | WAIT_EE 5000 early | | Recv EncryptedExtensions 5001 data | +--------+--------+ 5002 | Using | | Using certificate 5003 | PSK | v 5004 | | WAIT_CERT_CR 5005 | | Recv | | Recv CertificateRequest 5006 | | Certificate | v 5007 | | | WAIT_CERT 5008 | | | | Recv Certificate 5009 | | v v 5010 | | WAIT_CV 5011 | | | Recv CertificateVerify 5012 | +> WAIT_FINISHED <+ 5013 | | Recv Finished 5014 \ | [Send EndOfEarlyData] 5015 | K_send = handshake 5016 | [Send Certificate [+ CertificateVerify]] 5017 Can send | Send Finished 5018 app data --> | K_send = K_recv = application 5019 after here v 5020 CONNECTED 5022 Note that with the transitions as shown above, clients may send 5023 alerts that derive from post-ServerHello messages in the clear or 5024 with the early data keys. If clients need to send such alerts, they 5025 SHOULD first rekey to the handshake keys if possible. 5027 A.2. Server 5029 START <-----+ 5030 Recv ClientHello | | Send HelloRetryRequest 5031 v | 5032 RECVD_CH ----+ 5033 | Select parameters 5034 v 5035 NEGOTIATED 5036 | Send ServerHello 5037 | K_send = handshake 5038 | Send EncryptedExtensions 5039 | [Send CertificateRequest] 5040 Can send | [Send Certificate + CertificateVerify] 5041 app data | Send Finished 5042 after --> | K_send = application 5043 here +--------+--------+ 5044 No 0-RTT | | 0-RTT 5045 K_recv = handshake | | K_recv = early_data 5046 [Skip decrypt errors] | WAIT_EOED <---+ 5047 | Recv | | | Recv 5048 | EndOfEarlyData | | | Early data 5049 | K_recv = | +-----+ 5050 | handshake | 5051 | | 5052 +> WAIT_FLIGHT2 <-+ 5053 | 5054 +--------+--------+ 5055 No auth | | Client auth 5056 | | 5057 | v 5058 | WAIT_CERT 5059 | Recv | | Recv Certificate 5060 | empty | v 5061 | Certificate | WAIT_CV 5062 | | | Recv 5063 | v | CertificateVerify 5064 +-> WAIT_FINISHED <---+ 5065 | Recv Finished 5066 | K_recv = application 5067 v 5068 CONNECTED 5070 Appendix B. Protocol Data Structures and Constant Values 5072 This section describes protocol types and constants. Values listed 5073 as _RESERVED were used in previous versions of TLS and are listed 5074 here for completeness. TLS 1.3 implementations MUST NOT send them 5075 but might receive them from older TLS implementations. 5077 B.1. Record Layer 5079 enum { 5080 invalid(0), 5081 change_cipher_spec_RESERVED(20), 5082 alert(21), 5083 handshake(22), 5084 application_data(23), 5085 (255) 5086 } ContentType; 5088 struct { 5089 ContentType type; 5090 ProtocolVersion legacy_record_version; 5091 uint16 length; 5092 opaque fragment[TLSPlaintext.length]; 5093 } TLSPlaintext; 5095 struct { 5096 opaque content[TLSPlaintext.length]; 5097 ContentType type; 5098 uint8 zeros[length_of_padding]; 5099 } TLSInnerPlaintext; 5101 struct { 5102 ContentType opaque_type = 23; /* application_data */ 5103 ProtocolVersion legacy_record_version = 0x0301; /* TLS v1.x */ 5104 uint16 length; 5105 opaque encrypted_record[length]; 5106 } TLSCiphertext; 5108 B.2. Alert Messages 5109 enum { warning(1), fatal(2), (255) } AlertLevel; 5111 enum { 5112 close_notify(0), 5113 unexpected_message(10), 5114 bad_record_mac(20), 5115 decryption_failed_RESERVED(21), 5116 record_overflow(22), 5117 decompression_failure_RESERVED(30), 5118 handshake_failure(40), 5119 no_certificate_RESERVED(41), 5120 bad_certificate(42), 5121 unsupported_certificate(43), 5122 certificate_revoked(44), 5123 certificate_expired(45), 5124 certificate_unknown(46), 5125 illegal_parameter(47), 5126 unknown_ca(48), 5127 access_denied(49), 5128 decode_error(50), 5129 decrypt_error(51), 5130 export_restriction_RESERVED(60), 5131 protocol_version(70), 5132 insufficient_security(71), 5133 internal_error(80), 5134 inappropriate_fallback(86), 5135 user_canceled(90), 5136 no_renegotiation_RESERVED(100), 5137 missing_extension(109), 5138 unsupported_extension(110), 5139 certificate_unobtainable(111), 5140 unrecognized_name(112), 5141 bad_certificate_status_response(113), 5142 bad_certificate_hash_value(114), 5143 unknown_psk_identity(115), 5144 certificate_required(116), 5145 no_application_protocol(120), 5146 (255) 5147 } AlertDescription; 5149 struct { 5150 AlertLevel level; 5151 AlertDescription description; 5152 } Alert; 5154 B.3. Handshake Protocol 5156 enum { 5157 hello_request_RESERVED(0), 5158 client_hello(1), 5159 server_hello(2), 5160 hello_verify_request_RESERVED(3), 5161 new_session_ticket(4), 5162 end_of_early_data(5), 5163 hello_retry_request(6), 5164 encrypted_extensions(8), 5165 certificate(11), 5166 server_key_exchange_RESERVED(12), 5167 certificate_request(13), 5168 server_hello_done_RESERVED(14), 5169 certificate_verify(15), 5170 client_key_exchange_RESERVED(16), 5171 finished(20), 5172 key_update(24), 5173 message_hash(254), 5174 (255) 5175 } HandshakeType; 5177 struct { 5178 HandshakeType msg_type; /* handshake type */ 5179 uint24 length; /* bytes in message */ 5180 select (Handshake.msg_type) { 5181 case client_hello: ClientHello; 5182 case server_hello: ServerHello; 5183 case end_of_early_data: EndOfEarlyData; 5184 case hello_retry_request: HelloRetryRequest; 5185 case encrypted_extensions: EncryptedExtensions; 5186 case certificate_request: CertificateRequest; 5187 case certificate: Certificate; 5188 case certificate_verify: CertificateVerify; 5189 case finished: Finished; 5190 case new_session_ticket: NewSessionTicket; 5191 case key_update: KeyUpdate; 5192 } body; 5193 } Handshake; 5195 B.3.1. Key Exchange Messages 5197 uint16 ProtocolVersion; 5198 opaque Random[32]; 5200 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 5201 struct { 5202 ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ 5203 Random random; 5204 opaque legacy_session_id<0..32>; 5205 CipherSuite cipher_suites<2..2^16-2>; 5206 opaque legacy_compression_methods<1..2^8-1>; 5207 Extension extensions<8..2^16-1>; 5208 } ClientHello; 5210 struct { 5211 ProtocolVersion version; 5212 Random random; 5213 CipherSuite cipher_suite; 5214 Extension extensions<6..2^16-1>; 5215 } ServerHello; 5217 struct { 5218 ProtocolVersion server_version; 5219 CipherSuite cipher_suite; 5220 Extension extensions<2..2^16-1>; 5221 } HelloRetryRequest; 5223 struct { 5224 ExtensionType extension_type; 5225 opaque extension_data<0..2^16-1>; 5226 } Extension; 5228 enum { 5229 server_name(0), /* RFC 6066 */ 5230 max_fragment_length(1), /* RFC 6066 */ 5231 status_request(5), /* RFC 6066 */ 5232 supported_groups(10), /* RFC 4492, 7919 */ 5233 signature_algorithms(13), /* RFC 5246 */ 5234 use_srtp(14), /* RFC 5764 */ 5235 heartbeat(15), /* RFC 6520 */ 5236 application_layer_protocol_negotiation(16), /* RFC 7301 */ 5237 signed_certificate_timestamp(18), /* RFC 6962 */ 5238 client_certificate_type(19), /* RFC 7250 */ 5239 server_certificate_type(20), /* RFC 7250 */ 5240 padding(21), /* RFC 7685 */ 5241 key_share(40), /* [[this document]] */ 5242 pre_shared_key(41), /* [[this document]] */ 5243 early_data(42), /* [[this document]] */ 5244 supported_versions(43), /* [[this document]] */ 5245 cookie(44), /* [[this document]] */ 5246 psk_key_exchange_modes(45), /* [[this document]] */ 5247 certificate_authorities(47), /* [[this document]] */ 5248 oid_filters(48), /* [[this document]] */ 5249 post_handshake_auth(49), /* [[this document]] */ 5250 (65535) 5251 } ExtensionType; 5253 struct { 5254 NamedGroup group; 5255 opaque key_exchange<1..2^16-1>; 5256 } KeyShareEntry; 5258 struct { 5259 select (Handshake.msg_type) { 5260 case client_hello: 5261 KeyShareEntry client_shares<0..2^16-1>; 5263 case hello_retry_request: 5264 NamedGroup selected_group; 5266 case server_hello: 5267 KeyShareEntry server_share; 5268 }; 5269 } KeyShare; 5271 enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; 5273 struct { 5274 PskKeyExchangeMode ke_modes<1..255>; 5275 } PskKeyExchangeModes; 5277 struct {} Empty; 5279 struct { 5280 select (Handshake.msg_type) { 5281 case new_session_ticket: uint32 max_early_data_size; 5282 case client_hello: Empty; 5283 case encrypted_extensions: Empty; 5284 }; 5285 } EarlyDataIndication; 5287 struct { 5288 opaque identity<1..2^16-1>; 5289 uint32 obfuscated_ticket_age; 5290 } PskIdentity; 5292 opaque PskBinderEntry<32..255>; 5294 struct { 5295 select (Handshake.msg_type) { 5296 case client_hello: 5298 PskIdentity identities<7..2^16-1>; 5299 PskBinderEntry binders<33..2^16-1>; 5301 case server_hello: 5302 uint16 selected_identity; 5303 }; 5305 } PreSharedKeyExtension; 5307 B.3.1.1. Version Extension 5309 struct { 5310 ProtocolVersion versions<2..254>; 5311 } SupportedVersions; 5313 B.3.1.2. Cookie Extension 5315 struct { 5316 opaque cookie<1..2^16-1>; 5317 } Cookie; 5319 B.3.1.3. Signature Algorithm Extension 5320 enum { 5321 /* RSASSA-PKCS1-v1_5 algorithms */ 5322 rsa_pkcs1_sha256(0x0401), 5323 rsa_pkcs1_sha384(0x0501), 5324 rsa_pkcs1_sha512(0x0601), 5326 /* ECDSA algorithms */ 5327 ecdsa_secp256r1_sha256(0x0403), 5328 ecdsa_secp384r1_sha384(0x0503), 5329 ecdsa_secp521r1_sha512(0x0603), 5331 /* RSASSA-PSS algorithms */ 5332 rsa_pss_sha256(0x0804), 5333 rsa_pss_sha384(0x0805), 5334 rsa_pss_sha512(0x0806), 5336 /* EdDSA algorithms */ 5337 ed25519(0x0807), 5338 ed448(0x0808), 5340 /* Legacy algorithms */ 5341 rsa_pkcs1_sha1(0x0201), 5342 ecdsa_sha1(0x0203), 5344 /* Reserved Code Points */ 5345 obsolete_RESERVED(0x0000..0x0200), 5346 dsa_sha1_RESERVED(0x0202), 5347 obsolete_RESERVED(0x0204..0x0400), 5348 dsa_sha256_RESERVED(0x0402), 5349 obsolete_RESERVED(0x0404..0x0500), 5350 dsa_sha384_RESERVED(0x0502), 5351 obsolete_RESERVED(0x0504..0x0600), 5352 dsa_sha512_RESERVED(0x0602), 5353 obsolete_RESERVED(0x0604..0x06FF), 5354 private_use(0xFE00..0xFFFF), 5355 (0xFFFF) 5356 } SignatureScheme; 5358 struct { 5359 SignatureScheme supported_signature_algorithms<2..2^16-2>; 5360 } SignatureSchemeList; 5362 B.3.1.4. Supported Groups Extension 5363 enum { 5364 /* Elliptic Curve Groups (ECDHE) */ 5365 obsolete_RESERVED(0x0001..0x0016), 5366 secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), 5367 obsolete_RESERVED(0x001A..0x001C), 5368 x25519(0x001D), x448(0x001E), 5370 /* Finite Field Groups (DHE) */ 5371 ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096 (0x0102), 5372 ffdhe6144(0x0103), ffdhe8192(0x0104), 5374 /* Reserved Code Points */ 5375 ffdhe_private_use(0x01FC..0x01FF), 5376 ecdhe_private_use(0xFE00..0xFEFF), 5377 obsolete_RESERVED(0xFF01..0xFF02), 5378 (0xFFFF) 5379 } NamedGroup; 5381 struct { 5382 NamedGroup named_group_list<2..2^16-1>; 5383 } NamedGroupList; 5385 Values within "obsolete_RESERVED" ranges are used in previous 5386 versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 5387 implementations. The obsolete curves have various known/theoretical 5388 weaknesses or have had very little usage, in some cases only due to 5389 unintentional server configuration issues. They are no longer 5390 considered appropriate for general use and should be assumed to be 5391 potentially unsafe. The set of curves specified here is sufficient 5392 for interoperability with all currently deployed and properly 5393 configured TLS implementations. 5395 B.3.2. Server Parameters Messages 5396 opaque DistinguishedName<1..2^16-1>; 5398 struct { 5399 DistinguishedName authorities<3..2^16-1>; 5400 } CertificateAuthoritiesExtension; 5402 struct { 5403 opaque certificate_extension_oid<1..2^8-1>; 5404 opaque certificate_extension_values<0..2^16-1>; 5405 } OIDFilter; 5407 struct { 5408 OIDFilter filters<0..2^16-1>; 5409 } OIDFilterExtension; 5411 struct { 5412 Extension extensions<0..2^16-1>; 5413 } EncryptedExtensions; 5415 struct { 5416 opaque certificate_request_context<0..2^8-1>; 5417 Extension extensions<2..2^16-1>; 5418 } CertificateRequest; 5420 B.3.3. Authentication Messages 5421 struct { 5422 select(certificate_type){ 5423 case RawPublicKey: 5424 // From RFC 7250 ASN.1_subjectPublicKeyInfo 5425 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 5427 case X509: 5428 opaque cert_data<1..2^24-1>; 5429 }; 5430 Extension extensions<0..2^16-1>; 5431 } CertificateEntry; 5433 struct { 5434 opaque certificate_request_context<0..2^8-1>; 5435 CertificateEntry certificate_list<0..2^24-1>; 5436 } Certificate; 5438 struct { 5439 SignatureScheme algorithm; 5440 opaque signature<0..2^16-1>; 5441 } CertificateVerify; 5443 struct { 5444 opaque verify_data[Hash.length]; 5445 } Finished; 5447 B.3.4. Ticket Establishment 5449 struct { 5450 uint32 ticket_lifetime; 5451 uint32 ticket_age_add; 5452 opaque ticket_nonce<1..255>; 5453 opaque ticket<1..2^16-1>; 5454 Extension extensions<0..2^16-2>; 5455 } NewSessionTicket; 5457 B.3.5. Updating Keys 5459 struct {} EndOfEarlyData; 5461 enum { 5462 update_not_requested(0), update_requested(1), (255) 5463 } KeyUpdateRequest; 5465 struct { 5466 KeyUpdateRequest request_update; 5467 } KeyUpdate; 5469 B.4. Cipher Suites 5471 A symmetric cipher suite defines the pair of the AEAD algorithm and 5472 hash algorithm to be used with HKDF. Cipher suite names follow the 5473 naming convention: 5475 CipherSuite TLS_AEAD_HASH = VALUE; 5477 +-----------+------------------------------------------------+ 5478 | Component | Contents | 5479 +-----------+------------------------------------------------+ 5480 | TLS | The string "TLS" | 5481 | | | 5482 | AEAD | The AEAD algorithm used for record protection | 5483 | | | 5484 | HASH | The hash algorithm used with HKDF | 5485 | | | 5486 | VALUE | The two byte ID assigned for this cipher suite | 5487 +-----------+------------------------------------------------+ 5489 This specification defines the following cipher suites for use with 5490 TLS 1.3. 5492 +------------------------------+-------------+ 5493 | Description | Value | 5494 +------------------------------+-------------+ 5495 | TLS_AES_128_GCM_SHA256 | {0x13,0x01} | 5496 | | | 5497 | TLS_AES_256_GCM_SHA384 | {0x13,0x02} | 5498 | | | 5499 | TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} | 5500 | | | 5501 | TLS_AES_128_CCM_SHA256 | {0x13,0x04} | 5502 | | | 5503 | TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} | 5504 +------------------------------+-------------+ 5506 The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, 5507 and AEAD_AES_128_CCM are defined in [RFC5116]. 5508 AEAD_CHACHA20_POLY1305 is defined in [RFC7539]. AEAD_AES_128_CCM_8 5509 is defined in [RFC6655]. The corresponding hash algorithms are 5510 defined in [SHS]. 5512 Although TLS 1.3 uses the same cipher suite space as previous 5513 versions of TLS, TLS 1.3 cipher suites are defined differently, only 5514 specifying the symmetric ciphers, and cannot be used for TLS 1.2. 5515 Similarly, TLS 1.2 and lower cipher suites cannot be used with TLS 5516 1.3. 5518 New cipher suite values are assigned by IANA as described in 5519 Section 11. 5521 Appendix C. Implementation Notes 5523 The TLS protocol cannot prevent many common security mistakes. This 5524 section provides several recommendations to assist implementors. 5525 [I-D.ietf-tls-tls13-vectors] provides test vectors for TLS 1.3 5526 handshakes. 5528 C.1. Random Number Generation and Seeding 5530 TLS requires a cryptographically secure pseudorandom number generator 5531 (CSPRNG). In most cases, the operating system provides an 5532 appropriate facility such as /dev/urandom, which should be used 5533 absent other (performance) concerns. It is RECOMMENDED to use an 5534 existing CSPRNG implementation in preference to crafting a new one. 5535 Many adequate cryptographic libraries are already available under 5536 favorable license terms. Should those prove unsatisfactory, 5537 [RFC4086] provides guidance on the generation of random values. 5539 C.2. Certificates and Authentication 5541 Implementations are responsible for verifying the integrity of 5542 certificates and should generally support certificate revocation 5543 messages. Absent a specific indication from an application profile, 5544 Certificates should always be verified to ensure proper signing by a 5545 trusted Certificate Authority (CA). The selection and addition of 5546 trust anchors should be done very carefully. Users should be able to 5547 view information about the certificate and trust anchor. 5548 Applications SHOULD also enforce minimum and maximum key sizes. For 5549 example, certification paths containing keys or signatures weaker 5550 than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure 5551 applications. 5553 C.3. Implementation Pitfalls 5555 Implementation experience has shown that certain parts of earlier TLS 5556 specifications are not easy to understand and have been a source of 5557 interoperability and security problems. Many of these areas have 5558 been clarified in this document but this appendix contains a short 5559 list of the most important things that require special attention from 5560 implementors. 5562 TLS protocol issues: 5564 - Do you correctly handle handshake messages that are fragmented to 5565 multiple TLS records (see Section 5.1)? Including corner cases 5566 like a ClientHello that is split to several small fragments? Do 5567 you fragment handshake messages that exceed the maximum fragment 5568 size? In particular, the Certificate and CertificateRequest 5569 handshake messages can be large enough to require fragmentation. 5571 - Do you ignore the TLS record layer version number in all 5572 unencrypted TLS records? (see Appendix D) 5574 - Have you ensured that all support for SSL, RC4, EXPORT ciphers, 5575 and MD5 (via the "signature_algorithms" extension) is completely 5576 removed from all possible configurations that support TLS 1.3 or 5577 later, and that attempts to use these obsolete capabilities fail 5578 correctly? (see Appendix D) 5580 - Do you handle TLS extensions in ClientHello correctly, including 5581 unknown extensions? 5583 - When the server has requested a client certificate, but no 5584 suitable certificate is available, do you correctly send an empty 5585 Certificate message, instead of omitting the whole message (see 5586 Section 4.4.2.3)? 5588 - When processing the plaintext fragment produced by AEAD-Decrypt 5589 and scanning from the end for the ContentType, do you avoid 5590 scanning past the start of the cleartext in the event that the 5591 peer has sent a malformed plaintext of all-zeros? 5593 - Do you properly ignore unrecognized cipher suites (Section 4.1.2), 5594 hello extensions (Section 4.2), named groups (Section 4.2.6), key 5595 shares Section 4.2.7, supported versions Section 4.2.1, and 5596 signature algorithms (Section 4.2.3) in the ClientHello? 5598 - As a server, do you send a HelloRetryRequest to clients which 5599 support a compatible (EC)DHE group but do not predict it in the 5600 "key_share" extension? As a client, do you correctly handle a 5601 HelloRetryRequest from the server? 5603 Cryptographic details: 5605 - What countermeasures do you use to prevent timing attacks 5606 [TIMING]? 5608 - When using Diffie-Hellman key exchange, do you correctly preserve 5609 leading zero bytes in the negotiated key (see Section 7.4.1)? 5611 - Does your TLS client check that the Diffie-Hellman parameters sent 5612 by the server are acceptable, (see Section 4.2.7.1)? 5614 - Do you use a strong and, most importantly, properly seeded random 5615 number generator (see Appendix C.1) when generating Diffie-Hellman 5616 private values, the ECDSA "k" parameter, and other security- 5617 critical values? It is RECOMMENDED that implementations implement 5618 "deterministic ECDSA" as specified in [RFC6979]. 5620 - Do you zero-pad Diffie-Hellman public key values to the group size 5621 (see Section 4.2.7.1)? 5623 - Do you verify signatures after making them to protect against RSA- 5624 CRT key leaks? [FW15] 5626 C.4. Client Tracking Prevention 5628 Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of 5629 a ticket allows passive observers to correlate different connections. 5630 Servers that issue tickets SHOULD offer at least as many tickets as 5631 the number of connections that a client might use; for example, a web 5632 browser using HTTP/1.1 [RFC7230] might open six connections to a 5633 server. Servers SHOULD issue new tickets with every connection. 5634 This ensures that clients are always able to use a new ticket when 5635 creating a new connection. 5637 C.5. Unauthenticated Operation 5639 Previous versions of TLS offered explicitly unauthenticated cipher 5640 suites based on anonymous Diffie-Hellman. These modes have been 5641 deprecated in TLS 1.3. However, it is still possible to negotiate 5642 parameters that do not provide verifiable server authentication by 5643 several methods, including: 5645 - Raw public keys [RFC7250]. 5647 - Using a public key contained in a certificate but without 5648 validation of the certificate chain or any of its contents. 5650 Either technique used alone is vulnerable to man-in-the-middle 5651 attacks and therefore unsafe for general use. However, it is also 5652 possible to bind such connections to an external authentication 5653 mechanism via out-of-band validation of the server's public key, 5654 trust on first use, or a mechanism such as channel bindings (though 5655 the channel bindings described in [RFC5929] are not defined for TLS 5656 1.3). If no such mechanism is used, then the connection has no 5657 protection against active man-in-the-middle attack; applications MUST 5658 NOT use TLS in such a way absent explicit configuration or a specific 5659 application profile. 5661 Appendix D. Backward Compatibility 5663 The TLS protocol provides a built-in mechanism for version 5664 negotiation between endpoints potentially supporting different 5665 versions of TLS. 5667 TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can 5668 also handle clients trying to use future versions of TLS as long as 5669 the ClientHello format remains compatible and the client supports the 5670 highest protocol version available in the server. 5672 Prior versions of TLS used the record layer version number for 5673 various purposes. (TLSPlaintext.legacy_record_version and 5674 TLSCiphertext.legacy_record_version) As of TLS 1.3, this field is 5675 deprecated. The value of TLSPlaintext.legacy_record_version MUST be 5676 ignored by all implementations. The value of 5677 TLSCiphertext.legacy_record_version MAY be ignored, or MAY be 5678 validated to match the fixed constant value. Version negotiation is 5679 performed using only the handshake versions 5680 (ClientHello.legacy_version, ClientHello "supported_versions" 5681 extension, and ServerHello.version). In order to maximize 5682 interoperability with older endpoints, implementations that negotiate 5683 the use of TLS 1.0-1.2 SHOULD set the record layer version number to 5684 the negotiated version for the ServerHello and all records 5685 thereafter. 5687 For maximum compatibility with previously non-standard behavior and 5688 misconfigured deployments, all implementations SHOULD support 5689 validation of certification paths based on the expectations in this 5690 document, even when handling prior TLS versions' handshakes. (see 5691 Section 4.4.2.2) 5693 TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627] 5694 extension which digested large parts of the handshake transcript into 5695 the master secret. Because TLS 1.3 always hashes in the transcript 5696 up to the server CertificateVerify, implementations which support 5697 both TLS 1.3 and earlier versions SHOULD indicate the use of the 5698 Extended Master Secret extension in their APIs whenever TLS 1.3 is 5699 used. 5701 D.1. Negotiating with an older server 5703 A TLS 1.3 client who wishes to negotiate with servers that do not 5704 support TLS 1.3 will send a normal TLS 1.3 ClientHello containing 5705 0x0303 (TLS 1.2) in ClientHello.legacy_version but with the correct 5706 version in the "supported_versions" extension. If the server does 5707 not support TLS 1.3 it will respond with a ServerHello containing an 5708 older version number. If the client agrees to use this version, the 5709 negotiation will proceed as appropriate for the negotiated protocol. 5710 A client using a ticket for resumption SHOULD initiate the connection 5711 using the version that was previously negotiated. 5713 Note that 0-RTT data is not compatible with older servers and SHOULD 5714 NOT be sent absent knowledge that the server supports TLS 1.3. See 5715 Appendix D.3. 5717 If the version chosen by the server is not supported by the client 5718 (or not acceptable), the client MUST abort the handshake with a 5719 "protocol_version" alert. 5721 Some legacy server implementations are known to not implement the TLS 5722 specification properly and might abort connections upon encountering 5723 TLS extensions or versions which they are not aware of. 5724 Interoperability with buggy servers is a complex topic beyond the 5725 scope of this document. Multiple connection attempts may be required 5726 in order to negotiate a backwards compatible connection; however, 5727 this practice is vulnerable to downgrade attacks and is NOT 5728 RECOMMENDED. 5730 D.2. Negotiating with an older client 5732 A TLS server can also receive a ClientHello indicating a version 5733 number smaller than its highest supported version. If the 5734 "supported_versions" extension is present, the server MUST negotiate 5735 using that extension as described in Section 4.2.1. If the 5736 "supported_versions" extension is not present, the server MUST 5737 negotiate the minimum of ClientHello.legacy_version and TLS 1.2. For 5738 example, if the server supports TLS 1.0, 1.1, and 1.2, and 5739 legacy_version is TLS 1.0, the server will proceed with a TLS 1.0 5740 ServerHello. If the "supported_versions" extension is absent and the 5741 server only supports versions greater than 5742 ClientHello.legacy_version, the server MUST abort the handshake with 5743 a "protocol_version" alert. 5745 Note that earlier versions of TLS did not clearly specify the record 5746 layer version number value in all cases 5747 (TLSPlaintext.legacy_record_version). Servers will receive various 5748 TLS 1.x versions in this field, but its value MUST always be ignored. 5750 D.3. Zero-RTT backwards compatibility 5752 0-RTT data is not compatible with older servers. An older server 5753 will respond to the ClientHello with an older ServerHello, but it 5754 will not correctly skip the 0-RTT data and will fail to complete the 5755 handshake. This can cause issues when a client attempts to use 5756 0-RTT, particularly against multi-server deployments. For example, a 5757 deployment could deploy TLS 1.3 gradually with some servers 5758 implementing TLS 1.3 and some implementing TLS 1.2, or a TLS 1.3 5759 deployment could be downgraded to TLS 1.2. 5761 A client that attempts to send 0-RTT data MUST fail a connection if 5762 it receives a ServerHello with TLS 1.2 or older. A client that 5763 attempts to repair this error SHOULD NOT send a TLS 1.2 ClientHello, 5764 but instead send a TLS 1.3 ClientHello without 0-RTT data. 5766 To avoid this error condition, multi-server deployments SHOULD ensure 5767 a uniform and stable deployment of TLS 1.3 without 0-RTT prior to 5768 enabling 0-RTT. 5770 D.4. Backwards Compatibility Security Restrictions 5772 Implementations negotiating use of older versions of TLS SHOULD 5773 prefer forward secret and AEAD cipher suites, when available. 5775 The security of RC4 cipher suites is considered insufficient for the 5776 reasons cited in [RFC7465]. Implementations MUST NOT offer or 5777 negotiate RC4 cipher suites for any version of TLS for any reason. 5779 Old versions of TLS permitted the use of very low strength ciphers. 5780 Ciphers with a strength less than 112 bits MUST NOT be offered or 5781 negotiated for any version of TLS for any reason. 5783 The security of SSL 3.0 [SSL3] is considered insufficient for the 5784 reasons enumerated in [RFC7568], and MUST NOT be negotiated for any 5785 reason. 5787 The security of SSL 2.0 [SSL2] is considered insufficient for the 5788 reasons enumerated in [RFC6176], and MUST NOT be negotiated for any 5789 reason. 5791 Implementations MUST NOT send an SSL version 2.0 compatible CLIENT- 5792 HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an 5793 SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT 5794 RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in 5795 order to negotiate older versions of TLS. 5797 Implementations MUST NOT send a ClientHello.legacy_version or 5798 ServerHello.version set to 0x0300 or less. Any endpoint receiving a 5799 Hello message with ClientHello.legacy_version or ServerHello.version 5800 set to 0x0300 MUST abort the handshake with a "protocol_version" 5801 alert. 5803 Implementations MUST NOT send any records with a version less than 5804 0x0300. Implementations SHOULD NOT accept any records with a version 5805 less than 0x0300 (but may inadvertently do so if the record version 5806 number is ignored completely). 5808 Implementations MUST NOT use the Truncated HMAC extension, defined in 5809 Section 7 of [RFC6066], as it is not applicable to AEAD algorithms 5810 and has been shown to be insecure in some scenarios. 5812 Appendix E. Overview of Security Properties 5814 A complete security analysis of TLS is outside the scope of this 5815 document. In this section, we provide an informal description the 5816 desired properties as well as references to more detailed work in the 5817 research literature which provides more formal definitions. 5819 We cover properties of the handshake separately from those of the 5820 record layer. 5822 E.1. Handshake 5824 The TLS handshake is an Authenticated Key Exchange (AKE) protocol 5825 which is intended to provide both one-way authenticated (server-only) 5826 and mutually authenticated (client and server) functionality. At the 5827 completion of the handshake, each side outputs its view of the 5828 following values: 5830 - A set of "session keys" (the various secrets derived from the 5831 master secret) from which can be derived a set of working keys. 5833 - A set of cryptographic parameters (algorithms, etc.) 5835 - The identities of the communicating parties. 5837 We assume the attacker to be an active network attacker, which means 5838 it has complete control over the network used to communicate between 5839 the parties [RFC3552]. Even under these conditions, the handshake 5840 should provide the properties listed below. Note that these 5841 properties are not necessarily independent, but reflect the protocol 5842 consumers' needs. 5844 Establishing the same session keys. The handshake needs to output 5845 the same set of session keys on both sides of the handshake, 5846 provided that it completes successfully on each endpoint (See 5847 [CK01]; defn 1, part 1). 5849 Secrecy of the session keys. The shared session keys should be known 5850 only to the communicating parties and not to the attacker (See 5851 [CK01]; defn 1, part 2). Note that in a unilaterally 5852 authenticated connection, the attacker can establish its own 5853 session keys with the server, but those session keys are distinct 5854 from those established by the client. 5856 Peer Authentication. The client's view of the peer identity should 5857 reflect the server's identity. If the client is authenticated, 5858 the server's view of the peer identity should match the client's 5859 identity. 5861 Uniqueness of the session keys: Any two distinct handshakes should 5862 produce distinct, unrelated session keys. Individual session keys 5863 produced by a handshake should also be distinct and unrelated. 5865 Downgrade protection. The cryptographic parameters should be the 5866 same on both sides and should be the same as if the peers had been 5867 communicating in the absence of an attack (See [BBFKZG16]; defns 8 5868 and 9}). 5870 Forward secret with respect to long-term keys If the long-term 5871 keying material (in this case the signature keys in certificate- 5872 based authentication modes or the external/resumption PSK in PSK 5873 with (EC)DHE modes) is compromised after the handshake is 5874 complete, this does not compromise the security of the session key 5875 (See [DOW92]), as long as the session key itself has been erased. 5876 The forward secrecy property is not satisfied when PSK is used in 5877 the "psk_ke" PskKeyExchangeMode. 5879 Key Compromise Impersonation (KCI) resistance In a mutually- 5880 authenticated connection with certificates, peer authentication 5881 should hold even if the local long-term secret was compromised 5882 before the connection was established (see [HGFS15]). For 5883 example, if a client's signature key is compromised, it should not 5884 be possible to impersonate arbitrary servers to that client in 5885 subsequent handshakes. 5887 Protection of endpoint identities. The server's identity 5888 (certificate) should be protected against passive attackers. The 5889 client's identity should be protected against both passive and 5890 active attackers. 5892 Informally, the signature-based modes of TLS 1.3 provide for the 5893 establishment of a unique, secret, shared key established by an 5894 (EC)DHE key exchange and authenticated by the server's signature over 5895 the handshake transcript, as well as tied to the server's identity by 5896 a MAC. If the client is authenticated by a certificate, it also 5897 signs over the handshake transcript and provides a MAC tied to both 5898 identities. [SIGMA] describes the design and analysis of this type 5899 of key exchange protocol. If fresh (EC)DHE keys are used for each 5900 connection, then the output keys are forward secret. 5902 The external PSK and resumption PSK bootstrap from a long-term shared 5903 secret into a unique per-connection set of short-term session keys. 5904 This secret may have been established in a previous handshake. If 5905 PSK with (EC)DHE key establishment is used, these session keys will 5906 also be forward secret. The resumption PSK has been designed so that 5907 the resumption master secret computed by connection N and needed to 5908 form connection N+1 is separate from the traffic keys used by 5909 connection N, thus providing forward secrecy between the connections. 5910 In addition, if multiple tickets are established on the same 5911 connection, they are associated with different keys, so compromise of 5912 the PSK associated with one ticket does not lead to the compromise of 5913 connections established with PSKs associated with other tickets. 5914 This property is most interesting if tickets are stored in a database 5915 (and so can be deleted) rather than if they are self-encrypted. 5917 The PSK binder value forms a binding between a PSK and the current 5918 handshake, as well as between the session where the PSK was 5919 established and the session where it was used. This binding 5920 transitively includes the original handshake transcript, because that 5921 transcript is digested into the values which produce the Resumption 5922 Master Secret. This requires that both the KDF used to produce the 5923 resumption master secret and the MAC used to compute the binder be 5924 collision resistant. See Appendix E.1.1 for more on this. Note: The 5925 binder does not cover the binder values from other PSKs, though they 5926 are included in the Finished MAC. 5928 Note: TLS does not currently permit the server to send a 5929 certificate_request message in non-certificate-based handshakes 5930 (e.g., PSK). If this restriction were to be relaxed in future, the 5931 client's signature would not cover the server's certificate directly. 5932 However, if the PSK was established through a NewSessionTicket, the 5933 client's signature would transitively cover the server's certificate 5934 through the PSK binder. [PSK-FINISHED] describes a concrete attack 5935 on constructions that do not bind to the server's certificate (see 5936 also [Kraw16]). It is unsafe to use certificate-based client 5937 authentication when the client might potentially share the same PSK/ 5938 key-id pair with two different endpoints. Implementations MUST NOT 5939 combine external PSKs with certificate-based authentication of either 5940 the client or the server. 5942 If an exporter is used, then it produces values which are unique and 5943 secret (because they are generated from a unique session key). 5944 Exporters computed with different labels and contexts are 5945 computationally independent, so it is not feasible to compute one 5946 from another or the session secret from the exported value. Note: 5947 exporters can produce arbitrary-length values. If exporters are to 5948 be used as channel bindings, the exported value MUST be large enough 5949 to provide collision resistance. The exporters provided in TLS 1.3 5950 are derived from the same handshake contexts as the early traffic 5951 keys and the application traffic keys respectively, and thus have 5952 similar security properties. Note that they do not include the 5953 client's certificate; future applications which wish to bind to the 5954 client's certificate may need to define a new exporter that includes 5955 the full handshake transcript. 5957 For all handshake modes, the Finished MAC (and where present, the 5958 signature), prevents downgrade attacks. In addition, the use of 5959 certain bytes in the random nonces as described in Section 4.1.3 5960 allows the detection of downgrade to previous TLS versions. See 5961 [BBFKZG16] for more detail on TLS 1.3 and downgrade. 5963 As soon as the client and the server have exchanged enough 5964 information to establish shared keys, the remainder of the handshake 5965 is encrypted, thus providing protection against passive attackers, 5966 even if the computed shared key is not authenticated. Because the 5967 server authenticates before the client, the client can ensure that if 5968 it authenticates to the server, it only reveals its identity to an 5969 authenticated server. Note that implementations must use the 5970 provided record padding mechanism during the handshake to avoid 5971 leaking information about the identities due to length. The client's 5972 proposed PSK identities are not encrypted, nor is the one that the 5973 server selects. 5975 E.1.1. Key Derivation and HKDF 5977 Key derivation in TLS 1.3 uses the HKDF function defined in [RFC5869] 5978 and its two components, HKDF-Extract and HKDF-Expand. The full 5979 rationale for the HKDF construction can be found in [Kraw10] and the 5980 rationale for the way it is used in TLS 1.3 in [KW16]. Throughout 5981 this document, each application of HKDF-Extract is followed by one or 5982 more invocations of HKDF-Expand. This ordering should always be 5983 followed (including in future revisions of this document), in 5984 particular, one SHOULD NOT use an output of HKDF-Extract as an input 5985 to another application of HKDF-Extract without an HKDF-Expand in 5986 between. Consecutive applications of HKDF-Expand are allowed as long 5987 as these are differentiated via the key and/or the labels. 5989 Note that HKDF-Expand implements a pseudorandom function (PRF) with 5990 both inputs and outputs of variable length. In some of the uses of 5991 HKDF in this document (e.g., for generating exporters and the 5992 resumption_master_secret), it is necessary that the application of 5993 HKDF-Expand be collision-resistant, namely, it should be infeasible 5994 to find two different inputs to HKDF-Expand that output the same 5995 value. This requires the underlying hash function to be collision 5996 resistant and the output length from HKDF-Expand to be of size at 5997 least 256 bits (or as much as needed for the hash function to prevent 5998 finding collisions). 6000 E.1.2. Client Authentication 6002 A client that has sent authentication data to a server, either during 6003 the handshake or in post-handshake authentication, cannot be sure if 6004 the server afterwards considers the client to be authenticated or 6005 not. If the client needs to determine if the server considers the 6006 connection to be unilaterally or mutually authenticated, this has to 6007 be provisioned by the application layer. See [CHHSV17] for details. 6008 In addition, the analysis of post-handshake authentication from 6009 [Kraw16] shows that the client identified by the certificate sent in 6010 the post-handshake phase possesses the traffic key. This party is 6011 therefore the client that participated in the original handshake or 6012 one to whom the original client delegated the traffic key (assuming 6013 that the traffic key has not been compromised). 6015 E.1.3. 0-RTT 6017 The 0-RTT mode of operation generally provides similar security 6018 properties as 1-RTT data, with the two exceptions that the 0-RTT 6019 encryption keys do not provide full forward secrecy and that the 6020 server is not able to guarantee uniqueness of the handshake (non- 6021 replayability) without keeping potentially undue amounts of state. 6022 See Section 4.2.9 for one mechanism to limit the exposure to replay. 6024 E.1.4. Exporter Independence 6026 The exporter_master_secret and early_exporter_master_secret are 6027 derived to be independent of the traffic keys and therefore do not 6028 represent a threat to the security of traffic encrypted with those 6029 keys. However, because these secrets can be used to compute any 6030 exporter value, they SHOULD be erased as soon as possible. If the 6031 total set of exporter labels is known, then implementations SHOULD 6032 pre-compute the inner Derive-Secret stage of the exporter computation 6033 for all those labels, then erase the [early_]exporter_master_secret, 6034 followed by each inner values as soon as it is known that it will not 6035 be needed again. 6037 E.1.5. Post-Compromise Security 6039 TLS does not provide security for handshakes which take place after 6040 the peer's long-term secret (signature key or external PSK) is 6041 compromised. It therefore does not provide post-compromise security 6042 [CCG16], sometimes also referred to as backwards or future secrecy. 6043 This is in contrast to KCI resistance, which describes the security 6044 guarantees that a party has after its own long-term secret has been 6045 compromised. 6047 E.1.6. External References 6049 The reader should refer to the following references for analysis of 6050 the TLS handshake: [DFGS15] [CHSV16] [DFGS16] [KW16] [Kraw16] 6051 [FGSW16] [LXZFH16] [FG17] [BBK17]. 6053 E.2. Record Layer 6055 The record layer depends on the handshake producing strong traffic 6056 secrets which can be used to derive bidirectional encryption keys and 6057 nonces. Assuming that is true, and the keys are used for no more 6058 data than indicated in Section 5.5 then the record layer should 6059 provide the following guarantees: 6061 Confidentiality. An attacker should not be able to determine the 6062 plaintext contents of a given record. 6064 Integrity. An attacker should not be able to craft a new record 6065 which is different from an existing record which will be accepted 6066 by the receiver. 6068 Order protection/non-replayability An attacker should not be able to 6069 cause the receiver to accept a record which it has already 6070 accepted or cause the receiver to accept record N+1 without having 6071 first processed record N. 6073 Length concealment. Given a record with a given external length, the 6074 attacker should not be able to determine the amount of the record 6075 that is content versus padding. 6077 Forward secrecy after key change. If the traffic key update 6078 mechanism described in Section 4.6.3 has been used and the 6079 previous generation key is deleted, an attacker who compromises 6080 the endpoint should not be able to decrypt traffic encrypted with 6081 the old key. 6083 Informally, TLS 1.3 provides these properties by AEAD-protecting the 6084 plaintext with a strong key. AEAD encryption [RFC5116] provides 6085 confidentiality and integrity for the data. Non-replayability is 6086 provided by using a separate nonce for each record, with the nonce 6087 being derived from the record sequence number (Section 5.3), with the 6088 sequence number being maintained independently at both sides thus 6089 records which are delivered out of order result in AEAD deprotection 6090 failures. In order to prevent mass cryptanalysis when the same 6091 plaintext is repeatedly encrypted by different users under the same 6092 key (as is commonly the case for HTTP), the nonce is formed by mixing 6093 the sequence number with a secret per-connection initialization 6094 vector derived along with the traffic keys. See [BT16] for analysis 6095 of this construction. 6097 The re-keying technique in TLS 1.3 (see Section 7.2) follows the 6098 construction of the serial generator in [REKEY], which shows that re- 6099 keying can allow keys to be used for a larger number of encryptions 6100 than without re-keying. This relies on the security of the HKDF- 6101 Expand-Label function as a pseudorandom function (PRF). In addition, 6102 as long as this function is truly one way, it is not possible to 6103 compute traffic keys from prior to a key change (forward secrecy). 6105 TLS does not provide security for data which is communicated on a 6106 connection after a traffic secret of that connection is compromised. 6107 That is, TLS does not provide post-compromise security/future 6108 secrecy/backward secrecy with respect to the traffic secret. Indeed, 6109 an attacker who learns a traffic secret can compute all future 6110 traffic secrets on that connection. Systems which want such 6111 guarantees need to do a fresh handshake and establish a new 6112 connection with an (EC)DHE exchange. 6114 E.2.1. External References 6116 The reader should refer to the following references for analysis of 6117 the TLS record layer: [BMMT15] [BT16] [BDFKPPRSZZ16] [BBK17]. 6119 E.3. Traffic Analysis 6121 TLS is susceptible to a variety of traffic analysis attacks based on 6122 observing the length and timing of encrypted packets [CLINIC] 6123 [HCJ16]. This is particularly easy when there is a small set of 6124 possible messages to be distinguished, such as for a video server 6125 hosting a fixed corpus of content, but still provides usable 6126 information even in more complicated scenarios. 6128 TLS does not provide any specific defenses against this form of 6129 attack but does include a padding mechanism for use by applications: 6130 The plaintext protected by the AEAD function consists of content plus 6131 variable-length padding, which allows the application to produce 6132 arbitrary length encrypted records as well as padding-only cover 6133 traffic to conceal the difference between periods of transmission and 6134 periods of silence. Because the padding is encrypted alongside the 6135 actual content, an attacker cannot directly determine the length of 6136 the padding, but may be able to measure it indirectly by the use of 6137 timing channels exposed during record processing (i.e., seeing how 6138 long it takes to process a record or trickling in records to see 6139 which ones elicit a response from the server). In general, it is not 6140 known how to remove all of these channels because even a constant 6141 time padding removal function will then feed the content into data- 6142 dependent functions. 6144 Note: Robust traffic analysis defences will likely lead to inferior 6145 performance due to delay in transmitting packets and increased 6146 traffic volume. 6148 E.4. Side Channel Attacks 6150 In general, TLS does not have specific defenses against side-channel 6151 attacks (i.e., those which attack the communications via secondary 6152 channels such as timing) leaving those to the implementation of the 6153 relevant cryptographic primitives. However, certain features of TLS 6154 are designed to make it easier to write side-channel resistant code: 6156 - Unlike previous versions of TLS which used a composite MAC-then- 6157 encrypt structure, TLS 1.3 only uses AEAD algorithms, allowing 6158 implementations to use self-contained constant-time 6159 implementations of those primitives. 6161 - TLS uses a uniform "bad_record_mac" alert for all decryption 6162 errors, which is intended to prevent an attacker from gaining 6163 piecewise insight into portions of the message. Additional 6164 resistance is provided by terminating the connection on such 6165 errors; a new connection will have different cryptographic 6166 material, preventing attacks against the cryptographic primitives 6167 that require multiple trials. 6169 Information leakage through side channels can occur at layers above 6170 TLS, in application protocols and the applications that use them. 6171 Resistance to side-channel attacks depends on applications and 6172 application protocols separately ensuring that confidential 6173 information is not inadvertently leaked. 6175 E.5. Replay Attacks on 0-RTT 6177 Replayable 0-RTT data presents a number of security threats to TLS- 6178 using applications, unless those applications are specifically 6179 engineered to be safe under replay (minimally, this means idempotent, 6180 but in many cases may also require other stronger conditions, such as 6181 constant-time response). Potential attacks include: 6183 - Duplication of actions which cause side effects (e.g., purchasing 6184 an item or transferring money) to be duplicated, thus harming the 6185 site or the user. 6187 - Attackers can store and replay 0-RTT messages in order to re-order 6188 them with respect to other messages (e.g., moving a delete to 6189 after a create). 6191 - Exploiting cache timing behavior to discover the content of 0-RTT 6192 messages by replaying a 0-RTT message to a different cache node 6193 and then using a separate connection to measure request latency, 6194 to see if the two requests address the same resource. 6196 If data can be replayed a large number of times, additional attacks 6197 become possible, such as making repeated measurements of the the 6198 speed of cryptographic operations. In addition, they may be able to 6199 overload rate-limiting systems. For further description of these 6200 attacks, see [Mac17]. 6202 Ultimately, servers have the responsibility to protect themselves 6203 against attacks employing 0-RTT data replication. The mechanisms 6204 described in Section 8 are intended to prevent replay at the TLS 6205 layer do not provide complete protection against receiving multiple 6206 copies of client data. TLS 1.3 falls back to the 1-RTT handshake 6207 when the server does not have any information about the client, e.g., 6208 because it is in a different cluster which does not share state or 6209 because the ticket has been deleted as described in Section 8.1. If 6210 the application layer protocol retransmits data in this setting, then 6211 it is possible for an attacker to induce message duplication by 6212 sending the ClientHello to both the original cluster (which processes 6213 the data immediately) and another cluster which will fall back to 6214 1-RTT and process the data upon application layer replay. The scale 6215 of this attack is limited by the client's willingness to retry 6216 transactions and therefore only allows a limited amount of 6217 duplication, with each copy appearing as a new connection at the 6218 server. 6220 If implemented correctly, the mechanisms described in Section 8.1 and 6221 Section 8.2 prevent a replayed ClientHello and its associated 0-RTT 6222 data from being accepted multiple times by any cluster with 6223 consistent state; for servers which limit the use of 0-RTT to one 6224 cluster for a single ticket, then a given ClientHello and its 6225 associated 0-RTT data will only be accepted once. However, if state 6226 is not completely consistent, then an attacker might be able to have 6227 multiple copies of the data be accepted during the replication 6228 window. Because clients do not know the exact details of server 6229 behavior, they MUST NOT send messages in early data which are not 6230 safe to have replayed and which they would not be willing to retry 6231 across multiple 1-RTT connections. 6233 Application protocols MUST NOT use 0-RTT data without a profile that 6234 defines its use. That profile needs to identify which messages or 6235 interactions are safe to use with 0-RTT and how to handle the 6236 situation when the server rejects 0-RTT and falls back to 1-RTT. 6238 In addition, to avoid accidental misuse, TLS implementations MUST NOT 6239 enable 0-RTT (either sending or accepting) unless specifically 6240 requested by the application and MUST NOT automatically resend 0-RTT 6241 data if it is rejected by the server unless instructed by the 6242 application. Server-side applications may wish to implement special 6243 processing for 0-RTT data for some kinds of application traffic 6244 (e.g., abort the connection, request that data be resent at the 6245 application layer, or delay processing until the handshake 6246 completes). In order to allow applications to implement this kind of 6247 processing, TLS implementations MUST provide a way for the 6248 application to determine if the handshake has completed. 6250 E.5.1. Replay and Exporters 6252 Replays of the ClientHello produce the same early exporter, thus 6253 requiring additional care by applications which use these exporters. 6254 In particular, if these exporters are used as an authentication 6255 channel binding (e.g., by signing the output of the exporter) an 6256 attacker who compromises the PSK can transplant authenticators 6257 between connections without compromising the authentication key. 6259 In addition, the early exporter SHOULD NOT be used to generate 6260 server-to-client encryption keys because that would entail the reuse 6261 of those keys. This parallels the use of the early application 6262 traffic keys only in the client-to-server direction. 6264 Appendix F. Working Group Information 6266 The discussion list for the IETF TLS working group is located at the 6267 e-mail address tls@ietf.org [1]. Information on the group and 6268 information on how to subscribe to the list is at 6269 https://www.ietf.org/mailman/listinfo/tls 6271 Archives of the list can be found at: https://www.ietf.org/mail- 6272 archive/web/tls/current/index.html 6274 Appendix G. Contributors 6276 - Martin Abadi 6277 University of California, Santa Cruz 6278 abadi@cs.ucsc.edu 6280 - Christopher Allen (co-editor of TLS 1.0) 6281 Alacrity Ventures 6282 ChristopherA@AlacrityManagement.com 6284 - Steven M. Bellovin 6285 Columbia University 6286 smb@cs.columbia.edu 6288 - David Benjamin 6289 Google 6290 davidben@google.com 6292 - Benjamin Beurdouche 6293 INRIA & Microsoft Research 6294 benjamin.beurdouche@ens.fr 6296 - Karthikeyan Bhargavan (co-author of [RFC7627]) 6297 INRIA 6298 karthikeyan.bhargavan@inria.fr 6300 - Simon Blake-Wilson (co-author of [RFC4492]) 6301 BCI 6302 sblakewilson@bcisse.com 6304 - Nelson Bolyard (co-author of [RFC4492]) 6305 Sun Microsystems, Inc. 6306 nelson@bolyard.com 6308 - Ran Canetti 6309 IBM 6310 canetti@watson.ibm.com 6312 - Matt Caswell 6313 OpenSSL 6314 matt@openssl.org 6316 - Pete Chown 6317 Skygate Technology Ltd 6318 pc@skygate.co.uk 6320 - Katriel Cohn-Gordon 6321 University of Oxford 6322 me@katriel.co.uk 6324 - Cas Cremers 6325 University of Oxford 6326 cas.cremers@cs.ox.ac.uk 6328 - Antoine Delignat-Lavaud (co-author of [RFC7627]) 6329 INRIA 6330 antoine.delignat-lavaud@inria.fr 6332 - Tim Dierks (co-editor of TLS 1.0, 1.1, and 1.2) 6333 Independent 6334 tim@dierks.org 6336 - Taher Elgamal 6337 Securify 6338 taher@securify.com 6340 - Pasi Eronen 6341 Nokia 6342 pasi.eronen@nokia.com 6344 - Cedric Fournet 6345 Microsoft 6346 fournet@microsoft.com 6348 - Anil Gangolli 6349 anil@busybuddha.org 6351 - David M. Garrett 6352 dave@nulldereference.com 6354 - Alessandro Ghedini 6355 Cloudflare Inc. 6356 alessandro@cloudflare.com 6358 - Daniel Kahn Gillmor 6359 ACLU 6360 dkg@fifthhorseman.net 6362 - Matthew Green 6363 Johns Hopkins University 6364 mgreen@cs.jhu.edu 6366 - Jens Guballa 6367 ETAS 6368 jens.guballa@etas.com 6370 - Felix Guenther 6371 TU Darmstadt 6372 mail@felixguenther.info 6374 - Vipul Gupta (co-author of [RFC4492]) 6375 Sun Microsystems Laboratories 6376 vipul.gupta@sun.com 6378 - Chris Hawk (co-author of [RFC4492]) 6379 Corriente Networks LLC 6380 chris@corriente.net 6382 - Kipp Hickman 6384 - Alfred Hoenes 6386 - David Hopwood 6387 Independent Consultant 6388 david.hopwood@blueyonder.co.uk 6390 - Marko Horvat 6391 MPI-SWS 6392 mhorvat@mpi-sws.org 6394 - Jonathan Hoyland 6395 Royal Holloway, University of London 6397 - Subodh Iyengar 6398 Facebook 6399 subodh@fb.com 6401 - Benjamin Kaduk 6402 Akamai 6403 kaduk@mit.edu 6405 - Hubert Kario 6406 Red Hat Inc. 6407 hkario@redhat.com 6409 - Phil Karlton (co-author of SSL 3.0) 6411 - Leon Klingele 6412 Independent 6413 mail@leonklingele.de 6415 - Paul Kocher (co-author of SSL 3.0) 6416 Cryptography Research 6417 paul@cryptography.com 6419 - Hugo Krawczyk 6420 IBM 6421 hugokraw@us.ibm.com 6423 - Adam Langley (co-author of [RFC7627]) 6424 Google 6425 agl@google.com 6427 - Olivier Levillain 6428 ANSSI 6429 olivier.levillain@ssi.gouv.fr 6431 - Xiaoyin Liu 6432 University of North Carolina at Chapel Hill 6433 xiaoyin.l@outlook.com 6435 - Ilari Liusvaara 6436 Independent 6437 ilariliusvaara@welho.com 6439 - Atul Luykx 6440 K.U. Leuven 6441 atul.luykx@kuleuven.be 6443 - Colm MacCarthaigh 6444 Amazon Web Services 6445 colm@allcosts.net 6447 - Carl Mehner 6448 USAA 6449 carl.mehner@usaa.com 6451 - Jan Mikkelsen 6452 Transactionware 6453 janm@transactionware.com 6455 - Bodo Moeller (co-author of [RFC4492]) 6456 Google 6457 bodo@openssl.org 6459 - Kyle Nekritz 6460 Facebook 6461 knekritz@fb.com 6463 - Erik Nygren 6464 Akamai Technologies 6465 erik+ietf@nygren.org 6467 - Magnus Nystrom 6468 Microsoft 6469 mnystrom@microsoft.com 6471 - Kazuho Oku 6472 DeNA Co., Ltd. 6473 kazuhooku@gmail.com 6475 - Kenny Paterson 6476 Royal Holloway, University of London 6477 kenny.paterson@rhul.ac.uk 6479 - Alfredo Pironti (co-author of [RFC7627]) 6480 INRIA 6481 alfredo.pironti@inria.fr 6483 - Andrei Popov 6484 Microsoft 6485 andrei.popov@microsoft.com 6487 - Marsh Ray (co-author of [RFC7627]) 6488 Microsoft 6489 maray@microsoft.com 6491 - Robert Relyea 6492 Netscape Communications 6493 relyea@netscape.com 6495 - Kyle Rose 6496 Akamai Technologies 6497 krose@krose.org 6499 - Jim Roskind 6500 Amazon 6501 jroskind@amazon.com 6503 - Michael Sabin 6505 - Joe Salowey 6506 Tableau Software 6507 joe@salowey.net 6509 - Rich Salz 6510 Akamai 6511 rsalz@akamai.com 6513 - Sam Scott 6514 Royal Holloway, University of London 6515 me@samjs.co.uk 6517 - Dan Simon 6518 Microsoft, Inc. 6519 dansimon@microsoft.com 6521 - Brian Smith 6522 Independent 6523 brian@briansmith.org 6525 - Brian Sniffen 6526 Akamai Technologies 6527 ietf@bts.evenmere.org 6529 - Nick Sullivan 6530 Cloudflare Inc. 6531 nick@cloudflare.com 6533 - Bjoern Tackmann 6534 University of California, San Diego 6535 btackmann@eng.ucsd.edu 6537 - Tim Taubert 6538 Mozilla 6539 ttaubert@mozilla.com 6541 - Martin Thomson 6542 Mozilla 6543 mt@mozilla.com 6545 - Sean Turner 6546 sn3rd 6547 sean@sn3rd.com 6549 - Filippo Valsorda 6550 Cloudflare Inc. 6551 filippo@cloudflare.com 6553 - Thyla van der Merwe 6554 Royal Holloway, University of London 6555 tjvdmerwe@gmail.com 6557 - Tom Weinstein 6559 - Hoeteck Wee 6560 Ecole Normale Superieure, Paris 6561 hoeteck@alum.mit.edu 6563 - David Wong 6564 NCC Group 6565 david.wong@nccgroup.trust 6567 - Tim Wright 6568 Vodafone 6569 timothy.wright@vodafone.com 6571 - Kazu Yamamoto 6572 Internet Initiative Japan Inc. 6574 kazu@iij.ad.jp 6576 Author's Address 6578 Eric Rescorla 6579 RTFM, Inc. 6581 EMail: ekr@rtfm.com