idnits 2.17.1 draft-ietf-tls-tls13-04.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3268, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC4346, 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 obsoletes RFC4366, 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 == Line 797 has weird spacing: '...gorithm rec...' == Line 2411 has weird spacing: '...ixed_dh a c...' == Line 2412 has weird spacing: '...ixed_dh a c...' == Line 2659 has weird spacing: '...ed_ecdh sam...' == Line 3478 has weird spacing: '...gorithm rec...' (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 (January 03, 2015) is 3401 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) -- Looks like a reference, but probably isn't: '0' on line 332 -- Looks like a reference, but probably isn't: '1' on line 3139 -- Looks like a reference, but probably isn't: '3' on line 3870 -- Looks like a reference, but probably isn't: '9' on line 368 -- Looks like a reference, but probably isn't: '2' on line 4126 -- Looks like a reference, but probably isn't: '4' on line 404 -- Looks like a reference, but probably isn't: '8' on line 405 -- Looks like a reference, but probably isn't: '10' on line 515 -- Looks like a reference, but probably isn't: '48' on line 3483 -- Looks like a reference, but probably isn't: '32' on line 3485 -- Looks like a reference, but probably isn't: '13' on line 2132 == Missing Reference: 'TODO' is mentioned on line 2771, but not defined -- Looks like a reference, but probably isn't: '6' on line 2830 == Unused Reference: 'SCH' is defined on line 2972, but no explicit reference was found in the text == Unused Reference: 'TRIPLEDES' is defined on line 2979, but no explicit reference was found in the text == Unused Reference: 'CCM' is defined on line 3009, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 3014, but no explicit reference was found in the text == Unused Reference: 'ENCAUTH' is defined on line 3026, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 3061, but no explicit reference was found in the text == Unused Reference: 'RFC2785' is defined on line 3064, but no explicit reference was found in the text == Unused Reference: 'RFC3268' is defined on line 3068, but no explicit reference was found in the text == Unused Reference: 'RFC3526' is defined on line 3072, but no explicit reference was found in the text == Unused Reference: 'RFC3766' is defined on line 3076, but no explicit reference was found in the text == Unused Reference: 'RFC4307' is defined on line 3089, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) -- Possible downref: Non-RFC (?) normative reference: ref. 'SCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Possible downref: Non-RFC (?) normative reference: ref. 'TRIPLEDES' -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' -- Possible downref: Non-RFC (?) normative reference: ref. 'X962' == Outdated reference: A later version (-10) exists of draft-ietf-tls-negotiated-ff-dhe-05 == Outdated reference: A later version (-06) exists of draft-ietf-tls-session-hash-03 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 3268 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4307 (Obsoleted by RFC 8247) -- 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 5081 (Obsoleted by RFC 6091) Summary: 5 errors (**), 0 flaws (~~), 20 warnings (==), 37 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Dierks 3 Internet-Draft Independent 4 Obsoletes: 3268, 4346, 4366, 5246 (if E. Rescorla 5 approved) RTFM, Inc. 6 Updates: 4492 (if approved) January 03, 2015 7 Intended status: Standards Track 8 Expires: July 7, 2015 10 The Transport Layer Security (TLS) Protocol Version 1.3 11 draft-ietf-tls-tls13-04 13 Abstract 15 This document specifies Version 1.3 of the Transport Layer Security 16 (TLS) protocol. The TLS protocol provides communications security 17 over the Internet. The protocol allows client/server applications to 18 communicate in a way that is designed to prevent eavesdropping, 19 tampering, or message forgery. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 7, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 5 69 1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 5 70 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Goals of This Document . . . . . . . . . . . . . . . . . . . 7 72 4. Presentation Language . . . . . . . . . . . . . . . . . . . . 7 73 4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 7 74 4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 8 75 4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 10 79 4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 10 80 4.7. Cryptographic Attributes . . . . . . . . . . . . . . . . 12 81 4.8. Constants . . . . . . . . . . . . . . . . . . . . . . . . 14 82 5. The Pseudorandom Function . . . . . . . . . . . . . . . . . . 14 83 6. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 15 84 6.1. Connection States . . . . . . . . . . . . . . . . . . . . 16 85 6.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 18 86 6.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 18 87 6.2.2. Record Payload Protection . . . . . . . . . . . . . . 19 88 6.3. Key Calculation . . . . . . . . . . . . . . . . . . . . . 21 89 7. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 22 90 7.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 23 91 7.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 24 92 7.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 25 93 7.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 28 94 7.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 33 95 7.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 34 96 7.3.2. Client Key Share Message . . . . . . . . . . . . . . 37 97 7.3.3. Server Key Share Message . . . . . . . . . . . . . . 48 98 7.3.4. Encrypted Extensions . . . . . . . . . . . . . . . . 49 99 7.3.5. Server Certificate . . . . . . . . . . . . . . . . . 49 100 7.3.6. Certificate Request . . . . . . . . . . . . . . . . . 52 101 7.3.7. Server Certificate Verify . . . . . . . . . . . . . . 53 102 7.3.8. Server Finished . . . . . . . . . . . . . . . . . . . 55 103 7.3.9. Client Certificate . . . . . . . . . . . . . . . . . 56 104 7.3.10. Client Certificate Verify . . . . . . . . . . . . . . 58 105 8. Cryptographic Computations . . . . . . . . . . . . . . . . . 58 106 8.1. Computing the Master Secret . . . . . . . . . . . . . . . 59 107 8.1.1. The Session Hash . . . . . . . . . . . . . . . . . . 60 108 8.1.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 61 109 8.1.3. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 61 110 9. Mandatory Cipher Suites . . . . . . . . . . . . . . . . . . . 61 111 10. Application Data Protocol . . . . . . . . . . . . . . . . . . 61 112 11. Security Considerations . . . . . . . . . . . . . . . . . . . 62 113 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 114 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 115 13.1. Normative References . . . . . . . . . . . . . . . . . . 63 116 13.2. Informative References . . . . . . . . . . . . . . . . . 65 117 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 68 118 Appendix A. Protocol Data Structures and Constant Values . . . . 69 119 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 69 120 A.2. Change Cipher Specs Message . . . . . . . . . . . . . . . 69 121 A.3. Alert Messages . . . . . . . . . . . . . . . . . . . . . 69 122 A.4. Handshake Protocol . . . . . . . . . . . . . . . . . . . 70 123 A.4.1. Hello Messages . . . . . . . . . . . . . . . . . . . 71 124 A.4.2. Server Authentication and Key Exchange Messages . . . 73 125 A.4.3. Client Authentication and Key Exchange Messages . . . 73 126 A.4.4. Handshake Finalization Message . . . . . . . . . . . 74 127 A.5. The Cipher Suite . . . . . . . . . . . . . . . . . . . . 74 128 A.6. The Security Parameters . . . . . . . . . . . . . . . . . 76 129 A.7. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 76 130 Appendix B. Glossary . . . . . . . . . . . . . . . . . . . . . . 77 131 Appendix C. Cipher Suite Definitions . . . . . . . . . . . . . . 80 132 Appendix D. Implementation Notes . . . . . . . . . . . . . . . . 80 133 D.1. Random Number Generation and Seeding . . . . . . . . . . 80 134 D.2. Certificates and Authentication . . . . . . . . . . . . . 81 135 D.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 81 136 D.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 81 137 Appendix E. Backward Compatibility . . . . . . . . . . . . . . . 82 138 E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 . . . . . . . 82 139 E.2. Compatibility with SSL 2.0 . . . . . . . . . . . . . . . 84 140 E.3. Avoiding Man-in-the-Middle Version Rollback . . . . . . . 85 141 Appendix F. Security Analysis . . . . . . . . . . . . . . . . . 86 142 F.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 86 143 F.1.1. Authentication and Key Exchange . . . . . . . . . . . 86 144 F.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 87 145 F.1.3. Detecting Attacks Against the Handshake Protocol . . 88 146 F.1.4. Resuming Sessions . . . . . . . . . . . . . . . . . . 88 147 F.2. Protecting Application Data . . . . . . . . . . . . . . . 88 148 F.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 89 149 F.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 89 150 Appendix G. Working Group Information . . . . . . . . . . . . . 89 151 Appendix H. Contributors . . . . . . . . . . . . . . . . . . . . 90 153 1. Introduction 155 DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen 156 significant security analysis. 158 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this 159 draft is maintained in GitHub. Suggested changes should be submitted 160 as pull requests at https://github.com/tlswg/tls13-spec. 161 Instructions are on that page as well. Editorial changes can be 162 managed in GitHub, but any substantive change should be discussed on 163 the TLS mailing list. 165 The primary goal of the TLS protocol is to provide privacy and data 166 integrity between two communicating applications. The protocol is 167 composed of two layers: the TLS Record Protocol and the TLS Handshake 168 Protocol. At the lowest level, layered on top of some reliable 169 transport protocol (e.g., TCP [RFC0793]), is the TLS Record Protocol. 170 The TLS Record Protocol provides connection security that has two 171 basic properties: 173 - The connection is private. Symmetric cryptography is used for 174 data encryption (e.g., AES [AES], etc.). The keys for this 175 symmetric encryption are generated uniquely for each connection 176 and are based on a secret negotiated by another protocol (such as 177 the TLS Handshake Protocol). The Record Protocol can also be used 178 without encryption, i.e., in integrity-only modes. 180 - The connection is reliable. Messages include an authentication 181 tag which protects them against modification. 183 - The Record Protocol can operate in an insecure mode but is 184 generally only used in this mode while another protocol is using 185 the Record Protocol as a transport for negotiating security 186 parameters. 188 The TLS Record Protocol is used for encapsulation of various higher- 189 level protocols. One such encapsulated protocol, the TLS Handshake 190 Protocol, allows the server and client to authenticate each other and 191 to negotiate an encryption algorithm and cryptographic keys before 192 the application protocol transmits or receives its first byte of 193 data. The TLS Handshake Protocol provides connection security that 194 has three basic properties: 196 - The peer's identity can be authenticated using asymmetric, or 197 public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.). This 198 authentication can be made optional, but is generally required for 199 at least one of the peers. 201 - The negotiation of a shared secret is secure: the negotiated 202 secret is unavailable to eavesdroppers, and for any authenticated 203 connection the secret cannot be obtained, even by an attacker who 204 can place himself in the middle of the connection. 206 - The negotiation is reliable: no attacker can modify the 207 negotiation communication without being detected by the parties to 208 the communication. 210 One advantage of TLS is that it is application protocol independent. 211 Higher-level protocols can layer on top of the TLS protocol 212 transparently. The TLS standard, however, does not specify how 213 protocols add security with TLS; the decisions on how to initiate TLS 214 handshaking and how to interpret the authentication certificates 215 exchanged are left to the judgment of the designers and implementors 216 of protocols that run on top of TLS. 218 1.1. Requirements Terminology 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 222 document are to be interpreted as described in RFC 2119 [RFC2119]. 224 1.2. Major Differences from TLS 1.2 226 draft-04 228 - Modify key computations to include session hash. 230 - Remove ChangeCipherSpec 232 - Renumber the new handshake messages to be somewhat more consistent 233 with existing convention and to remove a duplicate registration. 235 - Remove renegotiation. 237 - Update format of signatures with context. 239 - Remove point format negotiation. 241 - Remove GMT time. 243 - Merge in support for ECC from RFC 4492 but without explicit 244 curves. 246 - Remove the unnecessary length field from the AD input to AEAD 247 ciphers. 249 - Rename {Client,Server}KeyExchange to {Client,Server}KeyShare 251 - Add an explicit HelloRetryRequest to reject the client's 253 draft-02 255 - Increment version number. 257 - Reworked handshake to provide 1-RTT mode. 259 - Remove custom DHE groups. 261 - Removed support for compression. 263 - Removed support for static RSA and DH key exchange. 265 - Removed support for non-AEAD ciphers 267 2. Goals 269 The goals of the TLS protocol, in order of priority, are as follows: 271 1. Cryptographic security: TLS should be used to establish a secure 272 connection between two parties. 274 2. Interoperability: Independent programmers should be able to 275 develop applications utilizing TLS that can successfully exchange 276 cryptographic parameters without knowledge of one another's code. 278 3. Extensibility: TLS seeks to provide a framework into which new 279 public key and record protection methods can be incorporated as 280 necessary. This will also accomplish two sub-goals: preventing 281 the need to create a new protocol (and risking the introduction 282 of possible new weaknesses) and avoiding the need to implement an 283 entire new security library. 285 4. Relative efficiency: Cryptographic operations tend to be highly 286 CPU intensive, particularly public key operations. For this 287 reason, the TLS protocol has incorporated an optional session 288 caching scheme to reduce the number of connections that need to 289 be established from scratch. Additionally, care has been taken 290 to reduce network activity. 292 3. Goals of This Document 294 This document and the TLS protocol itself are based on the SSL 3.0 295 Protocol Specification as published by Netscape. The differences 296 between this protocol and SSL 3.0 are not dramatic, but they are 297 significant enough that the various versions of TLS and SSL 3.0 do 298 not interoperate (although each protocol incorporates a mechanism by 299 which an implementation can back down to prior versions). This 300 document is intended primarily for readers who will be implementing 301 the protocol and for those doing cryptographic analysis of it. The 302 specification has been written with this in mind, and it is intended 303 to reflect the needs of those two groups. For that reason, many of 304 the algorithm-dependent data structures and rules are included in the 305 body of the text (as opposed to in an appendix), providing easier 306 access to them. 308 This document is not intended to supply any details of service 309 definition or of interface definition, although it does cover select 310 areas of policy as they are required for the maintenance of solid 311 security. 313 4. Presentation Language 315 This document deals with the formatting of data in an external 316 representation. The following very basic and somewhat casually 317 defined presentation syntax will be used. The syntax draws from 318 several sources in its structure. Although it resembles the 319 programming language "C" in its syntax and XDR [RFC4506] in both its 320 syntax and intent, it would be risky to draw too many parallels. The 321 purpose of this presentation language is to document TLS only; it has 322 no general application beyond that particular goal. 324 4.1. Basic Block Size 326 The representation of all data items is explicitly specified. The 327 basic data block size is one byte (i.e., 8 bits). Multiple byte data 328 items are concatenations of bytes, from left to right, from top to 329 bottom. From the byte stream, a multi-byte item (a numeric in the 330 example) is formed (using C notation) by: 332 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | 333 ... | byte[n-1]; 335 This byte ordering for multi-byte values is the commonplace network 336 byte order or big-endian format. 338 4.2. Miscellaneous 340 Comments begin with "/*" and end with "*/". 342 Optional components are denoted by enclosing them in "[[ ]]" double 343 brackets. 345 Single-byte entities containing uninterpreted data are of type 346 opaque. 348 4.3. Vectors 350 A vector (single-dimensioned array) is a stream of homogeneous data 351 elements. The size of the vector may be specified at documentation 352 time or left unspecified until runtime. In either case, the length 353 declares the number of bytes, not the number of elements, in the 354 vector. The syntax for specifying a new type, T', that is a fixed- 355 length vector of type T is 357 T T'[n]; 359 Here, T' occupies n bytes in the data stream, where n is a multiple 360 of the size of T. The length of the vector is not included in the 361 encoded stream. 363 In the following example, Datum is defined to be three consecutive 364 bytes that the protocol does not interpret, while Data is three 365 consecutive Datum, consuming a total of nine bytes. 367 opaque Datum[3]; /* three uninterpreted bytes */ 368 Datum Data[9]; /* 3 consecutive 3 byte vectors */ 370 Variable-length vectors are defined by specifying a subrange of legal 371 lengths, inclusively, using the notation . When 372 these are encoded, the actual length precedes the vector's contents 373 in the byte stream. The length will be in the form of a number 374 consuming as many bytes as required to hold the vector's specified 375 maximum (ceiling) length. A variable-length vector with an actual 376 length field of zero is referred to as an empty vector. 378 T T'; 380 In the following example, mandatory is a vector that must contain 381 between 300 and 400 bytes of type opaque. It can never be empty. 382 The actual length field consumes two bytes, a uint16, which is 383 sufficient to represent the value 400 (see Section 4.4). On the 384 other hand, longer can represent up to 800 bytes of data, or 400 385 uint16 elements, and it may be empty. Its encoding will include a 386 two-byte actual length field prepended to the vector. The length of 387 an encoded vector must be an even multiple of the length of a single 388 element (for example, a 17-byte vector of uint16 would be illegal). 390 opaque mandatory<300..400>; 391 /* length field is 2 bytes, cannot be empty */ 392 uint16 longer<0..800>; 393 /* zero to 400 16-bit unsigned integers */ 395 4.4. Numbers 397 The basic numeric data type is an unsigned byte (uint8). All larger 398 numeric data types are formed from fixed-length series of bytes 399 concatenated as described in Section 4.1 and are also unsigned. The 400 following numeric types are predefined. 402 uint8 uint16[2]; 403 uint8 uint24[3]; 404 uint8 uint32[4]; 405 uint8 uint64[8]; 407 All values, here and elsewhere in the specification, are stored in 408 network byte (big-endian) order; the uint32 represented by the hex 409 bytes 01 02 03 04 is equivalent to the decimal value 16909060. 411 Note that in some cases (e.g., DH parameters) it is necessary to 412 represent integers as opaque vectors. In such cases, they are 413 represented as unsigned integers (i.e., leading zero octets are not 414 required even if the most significant bit is set). 416 4.5. Enumerateds 418 An additional sparse data type is available called enum. A field of 419 type enum can only assume the values declared in the definition. 420 Each definition is a different type. Only enumerateds of the same 421 type may be assigned or compared. Every element of an enumerated 422 must be assigned a value, as demonstrated in the following example. 423 Since the elements of the enumerated are not ordered, they can be 424 assigned any unique value, in any order. 426 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; 428 An enumerated occupies as much space in the byte stream as would its 429 maximal defined ordinal value. The following definition would cause 430 one byte to be used to carry fields of type Color. 432 enum { red(3), blue(5), white(7) } Color; 434 One may optionally specify a value without its associated tag to 435 force the width definition without defining a superfluous element. 437 In the following example, Taste will consume two bytes in the data 438 stream but can only assume the values 1, 2, or 4. 440 enum { sweet(1), sour(2), bitter(4), (32000) } Taste; 442 The names of the elements of an enumeration are scoped within the 443 defined type. In the first example, a fully qualified reference to 444 the second element of the enumeration would be Color.blue. Such 445 qualification is not required if the target of the assignment is well 446 specified. 448 Color color = Color.blue; /* overspecified, legal */ 449 Color color = blue; /* correct, type implicit */ 451 For enumerateds that are never converted to external representation, 452 the numerical information may be omitted. 454 enum { low, medium, high } Amount; 456 4.6. Constructed Types 458 Structure types may be constructed from primitive types for 459 convenience. Each specification declares a new, unique type. The 460 syntax for definition is much like that of C. 462 struct { 463 T1 f1; 464 T2 f2; 465 ... 466 Tn fn; 467 } [[T]]; 469 The fields within a structure may be qualified using the type's name, 470 with a syntax much like that available for enumerateds. For example, 471 T.f2 refers to the second field of the previous declaration. 472 Structure definitions may be embedded. 474 4.6.1. Variants 476 Defined structures may have variants based on some knowledge that is 477 available within the environment. The selector must be an enumerated 478 type that defines the possible variants the structure defines. There 479 must be a case arm for every element of the enumeration declared in 480 the select. Case arms have limited fall-through: if two case arms 481 follow in immediate succession with no fields in between, then they 482 both contain the same fields. Thus, in the example below, "orange" 483 and "banana" both contain V2. Note that this is a new piece of 484 syntax in TLS 1.2. 486 The body of the variant structure may be given a label for reference. 487 The mechanism by which the variant is selected at runtime is not 488 prescribed by the presentation language. 490 struct { 491 T1 f1; 492 T2 f2; 493 .... 494 Tn fn; 495 select (E) { 496 case e1: Te1; 497 case e2: Te2; 498 case e3: case e4: Te3; 499 .... 500 case en: Ten; 501 } [[fv]]; 502 } [[Tv]]; 504 For example: 506 enum { apple, orange, banana } VariantTag; 508 struct { 509 uint16 number; 510 opaque string<0..10>; /* variable length */ 511 } V1; 513 struct { 514 uint32 number; 515 opaque string[10]; /* fixed length */ 516 } V2; 518 struct { 519 select (VariantTag) { /* value of selector is implicit */ 520 case apple: 521 V1; /* VariantBody, tag = apple */ 522 case orange: 523 case banana: 524 V2; /* VariantBody, tag = orange or banana */ 525 } variant_body; /* optional label on variant */ 526 } VariantRecord; 528 4.7. Cryptographic Attributes 530 The two cryptographic operations -- digital signing, and 531 authenticated encryption with additional data (AEAD) -- are 532 designated digitally-signed, and aead-ciphered, respectively. A 533 field's cryptographic processing is specified by prepending an 534 appropriate key word designation before the field's type 535 specification. Cryptographic keys are implied by the current session 536 state (see Section 6.1). 538 A digitally-signed element is encoded as a struct DigitallySigned: 540 struct { 541 SignatureAndHashAlgorithm algorithm; 542 opaque signature<0..2^16-1>; 543 } DigitallySigned; 545 The algorithm field specifies the algorithm used (see 546 Section 7.3.2.5.1 for the definition of this field). Note that the 547 algorithm field was introduced in TLS 1.2, and is not in earlier 548 versions. The signature is a digital signature using those 549 algorithms over the contents of the element. The contents themselves 550 do not appear on the wire but are simply calculated. The length of 551 the signature is specified by the signing algorithm and key. 553 In previous versions of TLS, the ServerKeyExchange format meant that 554 attackers can obtain a signature of a message with a chosen, 32-byte 555 prefix. Because TLS 1.3 servers are likely to also implement prior 556 versions, the contents of the element always start with 64 bytes of 557 octet 32 in order to clear that chosen-prefix. 559 Following that padding is a NUL-terminated context string in order to 560 disambiguate signatures for different purposes. The context string 561 will be specified whenever a digitally-signed element is used. 563 Finally, the specified contents of the digitally-signed structure 564 follow the NUL at the end of the context string. (See the example at 565 the end of this section.) 567 In RSA signing, the opaque vector contains the signature generated 568 using the RSASSA-PKCS1-v1_5 signature scheme defined in [RFC3447]. 569 As discussed in [RFC3447], the DigestInfo MUST be DER-encoded [X680] 570 [X690]. For hash algorithms without parameters (which includes SHA- 571 1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL, 572 but implementations MUST accept both without parameters and with NULL 573 parameters. Note that earlier versions of TLS used a different RSA 574 signature scheme that did not include a DigestInfo encoding. 576 In DSA, the 20 bytes of the SHA-1 hash are run directly through the 577 Digital Signing Algorithm with no additional hashing. This produces 578 two values, r and s. The DSA signature is an opaque vector, as 579 above, the contents of which are the DER encoding of: 581 Dss-Sig-Value ::= SEQUENCE { 582 r INTEGER, 583 s INTEGER 584 } 586 Note: In current terminology, DSA refers to the Digital Signature 587 Algorithm and DSS refers to the NIST standard. In the original SSL 588 and TLS specs, "DSS" was used universally. This document uses "DSA" 589 to refer to the algorithm, "DSS" to refer to the standard, and it 590 uses "DSS" in the code point definitions for historical continuity. 592 All ECDSA computations MUST be performed according to ANSI X9.62 593 [X962] or its successors. Data to be signed/verified is hashed, and 594 the result run directly through the ECDSA algorithm with no 595 additional hashing. The default hash function is SHA-1 [SHS]. 596 However, an alternative hash function, such as one of the new SHA 597 hash functions specified in FIPS 180-2 may be used instead if the 598 certificate containing the EC public key explicitly requires use of 599 another hash function. (The mechanism for specifying the required 600 hash function has not been standardized, but this provision 601 anticipates such standardization and obviates the need to update this 602 document in response. Future PKIX RFCs may choose, for example, to 603 specify the hash function to be used with a public key in the 604 parameters field of subjectPublicKeyInfo.) [[OPEN ISSUE: This needs 605 updating per 4492-bis https://github.com/tlswg/tls13-spec/issues/59]] 607 In AEAD encryption, the plaintext is simultaneously encrypted and 608 integrity protected. The input may be of any length, and aead- 609 ciphered output is generally larger than the input in order to 610 accommodate the integrity check value. 612 In the following example 614 struct { 615 uint8 field1; 616 uint8 field2; 617 digitally-signed opaque { 618 uint8 field3<0..255>; 619 uint8 field4; 620 }; 621 } UserType; 623 Assume that the context string for the signature was specified as 624 "Example". The input for the signature/hash algorithm would be: 626 2020202020202020202020202020202020202020202020202020202020202020 627 2020202020202020202020202020202020202020202020202020202020202020 628 4578616d706c6500 630 followed by the encoding of the inner struct (field3 and field4). 632 The length of the structure, in bytes, would be equal to two bytes 633 for field1 and field2, plus two bytes for the signature and hash 634 algorithm, plus two bytes for the length of the signature, plus the 635 length of the output of the signing algorithm. The length of the 636 signature is known because the algorithm and key used for the signing 637 are known prior to encoding or decoding this structure. 639 4.8. Constants 641 Typed constants can be defined for purposes of specification by 642 declaring a symbol of the desired type and assigning values to it. 644 Under-specified types (opaque, variable-length vectors, and 645 structures that contain opaque) cannot be assigned values. No fields 646 of a multi-element structure or vector may be elided. 648 For example: 650 struct { 651 uint8 f1; 652 uint8 f2; 653 } Example1; 655 Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */ 657 5. The Pseudorandom Function 659 A construction is required to do expansion of secrets into blocks of 660 data for the purposes of key generation or validation. This 661 pseudorandom function (PRF) takes as input a secret, a seed, and an 662 identifying label and produces an output of arbitrary length. 664 In this section, we define one PRF, based on HMAC [RFC2104]. This 665 PRF with the SHA-256 hash function is used for all cipher suites 666 defined in this document and in TLS documents published prior to this 667 document when TLS 1.2 is negotiated. New cipher suites MUST 668 explicitly specify a PRF and, in general, SHOULD use the TLS PRF with 669 SHA-256 or a stronger standard hash function. 671 First, we define a data expansion function, P_hash(secret, data), 672 that uses a single hash function to expand a secret and seed into an 673 arbitrary quantity of output: 675 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + 676 HMAC_hash(secret, A(2) + seed) + 677 HMAC_hash(secret, A(3) + seed) + ... 679 where + indicates concatenation. 681 A() is defined as: 683 A(0) = seed 684 A(i) = HMAC_hash(secret, A(i-1)) 686 P_hash can be iterated as many times as necessary to produce the 687 required quantity of data. For example, if P_SHA256 is being used to 688 create 80 bytes of data, it will have to be iterated three times 689 (through A(3)), creating 96 bytes of output data; the last 16 bytes 690 of the final iteration will then be discarded, leaving 80 bytes of 691 output data. 693 TLS's PRF is created by applying P_hash to the secret as: 695 PRF(secret, label, seed) = P_(secret, label + seed) 697 The label is an ASCII string. It should be included in the exact 698 form it is given without a length byte or trailing null character. 699 For example, the label "slithy toves" would be processed by hashing 700 the following bytes: 702 73 6C 69 74 68 79 20 74 6F 76 65 73 704 6. The TLS Record Protocol 706 The TLS Record Protocol is a layered protocol. At each layer, 707 messages may include fields for length, description, and content. 708 The Record Protocol takes messages to be transmitted, fragments the 709 data into manageable blocks, protects the records, and transmits the 710 result. Received data is decrypted and verified, reassembled, and 711 then delivered to higher-level clients. 713 Four protocols that use the record protocol are described in this 714 document: the handshake protocol, the alert protocol, the change 715 cipher spec protocol, and the application data protocol. In order to 716 allow extension of the TLS protocol, additional record content types 717 can be supported by the record protocol. New record content type 718 values are assigned by IANA in the TLS Content Type Registry as 719 described in Section 12. 721 Implementations MUST NOT send record types not defined in this 722 document unless negotiated by some extension. If a TLS 723 implementation receives an unexpected record type, it MUST send an 724 unexpected_message alert. 726 Any protocol designed for use over TLS must be carefully designed to 727 deal with all possible attacks against it. As a practical matter, 728 this means that the protocol designer must be aware of what security 729 properties TLS does and does not provide and cannot safely rely on 730 the latter. 732 Note in particular that type and length of a record are not protected 733 by encryption. If this information is itself sensitive, application 734 designers may wish to take steps (padding, cover traffic) to minimize 735 information leakage. 737 6.1. Connection States 739 A TLS connection state is the operating environment of the TLS Record 740 Protocol. It specifies a record protection algorithm and its 741 parameters as well as the record protection keys and IVs for the 742 connection in both the read and the write directions. The security 743 parameters are be set by the TLS Handshake Protocol, which also 744 determines when new cryptographic keys are installed and used for 745 record protection. The initial current state always specifies that 746 records are not protected. 748 The security parameters for a TLS Connection read and write state are 749 set by providing the following values: 751 connection end 752 Whether this entity is considered the "client" or the "server" in 753 this connection. 755 PRF algorithm 756 An algorithm used to generate keys from the master secret (see 757 Section 5 and Section 6.3). 759 record protection algorithm 760 The algorithm to be used for record protection. This algorithm 761 must be of the AEAD type and thus provides integrity and 762 confidentiality as a single primitive. It is possible to have 763 AEAD algorithms which do not provide any confidentiality and 764 Section 6.2.2 defines a special NULL_NULL AEAD algorithm for use 765 in the initial handshake). This specification includes the key 766 size of this algorithm and the lengths of explicit and implicit 767 initialization vectors (or nonces). 769 handshake master secret 770 A 48-byte secret shared between the two peers in the connection 771 and used to generate keys for protecting the handshake. 773 master secret 774 A 48-byte secret shared between the two peers in the connection 775 and used to generate keys for protecting application data. 777 client random 778 A 32-byte value provided by the client. 780 server random 781 A 32-byte value provided by the server. 783 These parameters are defined in the presentation language as: 785 enum { server, client } ConnectionEnd; 787 enum { tls_prf_sha256 } PRFAlgorithm; 789 enum { aes_gcm } RecordProtAlgorithm; 791 /* The algorithms specified in PRFAlgorithm and 792 RecordProtAlgorithm may be added to. */ 794 struct { 795 ConnectionEnd entity; 796 PRFAlgorithm prf_algorithm; 797 RecordProtAlgorithm record_prot_algorithm; 798 uint8 enc_key_length; 799 uint8 block_length; 800 uint8 fixed_iv_length; 801 uint8 record_iv_length; 802 opaque hs_master_secret[48]; 803 opaque master_secret[48]; 804 opaque client_random[32]; 805 opaque server_random[32]; 806 } SecurityParameters; 808 The record layer will use the security parameters to generate the 809 following four items (some of which are not required by all ciphers, 810 and are thus empty): 812 client write key 813 server write key 814 client write IV 815 server write IV 817 The client write parameters are used by the server when receiving and 818 processing records and vice versa. The algorithm used for generating 819 these items from the security parameters is described in Section 6.3 821 Once the security parameters have been set and the keys have been 822 generated, the connection states can be instantiated by making them 823 the current states. These current states MUST be updated for each 824 record processed. Each connection state includes the following 825 elements: 827 cipher state 828 The current state of the encryption algorithm. This will consist 829 of the scheduled key for that connection. 831 sequence number 832 Each connection state contains a sequence number, which is 833 maintained separately for read and write states. The sequence 834 number MUST be set to zero whenever a connection state is made the 835 active state. Sequence numbers are of type uint64 and may not 836 exceed 2^64-1. Sequence numbers do not wrap. If a TLS 837 implementation would need to wrap a sequence number, it must 838 terminate the connection. A sequence number is incremented after 839 each record: specifically, the first record transmitted under a 840 particular connection state MUST use sequence number 0. 842 6.2. Record Layer 844 The TLS record layer receives uninterpreted data from higher layers 845 in non-empty blocks of arbitrary size. 847 6.2.1. Fragmentation 849 The record layer fragments information blocks into TLSPlaintext 850 records carrying data in chunks of 2^14 bytes or less. Client 851 message boundaries are not preserved in the record layer (i.e., 852 multiple client messages of the same ContentType MAY be coalesced 853 into a single TLSPlaintext record, or a single message MAY be 854 fragmented across several records). 856 struct { 857 uint8 major; 858 uint8 minor; 859 } ProtocolVersion; 861 enum { 862 reserved(20), alert(21), handshake(22), 863 application_data(23), (255) 864 } ContentType; 866 struct { 867 ContentType type; 868 ProtocolVersion version; 869 uint16 length; 870 opaque fragment[TLSPlaintext.length]; 871 } TLSPlaintext; 873 type 874 The higher-level protocol used to process the enclosed fragment. 876 version 877 The version of the protocol being employed. This document 878 describes TLS Version 1.3, which uses the version { 3, 4 }. The 879 version value 3.4 is historical, deriving from the use of {3, 1} 880 for TLS 1.0. (See Appendix A.1.) Note that a client that 881 supports multiple versions of TLS may not know what version will 882 be employed before it receives the ServerHello. See Appendix E 883 for discussion about what record layer version number should be 884 employed for ClientHello. 886 length 887 The length (in bytes) of the following TLSPlaintext.fragment. The 888 length MUST NOT exceed 2^14. 890 fragment 891 The application data. This data is transparent and treated as an 892 independent block to be dealt with by the higher-level protocol 893 specified by the type field. 895 Implementations MUST NOT send zero-length fragments of Handshake or 896 Alert types. Zero-length fragments of Application data MAY be sent 897 as they are potentially useful as a traffic analysis countermeasure. 899 6.2.2. Record Payload Protection 901 The record protection functions translate a TLSPlaintext structure 902 into a TLSCiphertext. The deprotection functions reverse the 903 process. In TLS 1.3 as opposed to previous versions of TLS, all 904 ciphers are modelled as "Authenticated Encryption with Additional 905 Data" (AEAD) [RFC5116]. AEAD functions provide a unified encryption 906 and authentication operation which turns plaintext into authenticated 907 ciphertext and back again. 909 AEAD ciphers take as input a single key, a nonce, a plaintext, and 910 "additional data" to be included in the authentication check, as 911 described in Section 2.1 of [RFC5116]. The key is either the 912 client_write_key or the server_write_key. 914 struct { 915 ContentType type; 916 ProtocolVersion version; 917 uint16 length; 918 opaque nonce_explicit[SecurityParameters.record_iv_length]; 919 aead-ciphered struct { 920 opaque content[TLSPlaintext.length]; 921 } fragment; 922 } TLSCiphertext; 924 type 925 The type field is identical to TLSPlaintext.type. 927 version 928 The version field is identical to TLSPlaintext.version. 930 length 931 The length (in bytes) of the following TLSCiphertext.fragment. 932 The length MUST NOT exceed 2^14 + 2048. 934 fragment 935 The AEAD encrypted form of TLSPlaintext.fragment. 937 Each AEAD cipher suite MUST specify how the nonce supplied to the 938 AEAD operation is constructed, and what is the length of the 939 TLSCiphertext.nonce_explicit part. In many cases, it is appropriate 940 to use the partially implicit nonce technique described in 941 Section 3.2.1 of [RFC5116]; with record_iv_length being the length of 942 the explicit part. In this case, the implicit part SHOULD be derived 943 from key_block as client_write_iv and server_write_iv (as described 944 in Section 6.3), and the explicit part is included in 945 GenericAEAEDCipher.nonce_explicit. 947 The plaintext is the TLSPlaintext.fragment. 949 The additional authenticated data, which we denote as 950 additional_data, is defined as follows: 952 additional_data = seq_num + TLSPlaintext.type + 953 TLSPlaintext.version 955 where "+" denotes concatenation. 957 Note: In versions of TLS prior to 1.3, the additional_data included a 958 length field. This presents a problem for cipher constructions with 959 data-dependent padding (such as CBC). TLS 1.3 removes the length 960 field and relies on the AEAD cipher to provide integrity for the 961 length of the data. 963 The AEAD output consists of the ciphertext output by the AEAD 964 encryption operation. The length will generally be larger than 965 TLSPlaintext.length, but by an amount that varies with the AEAD 966 cipher. Since the ciphers might incorporate padding, the amount of 967 overhead could vary with different TLSPlaintext.length values. Each 968 AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. 969 Symbolically, 971 AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, 972 additional_data) 974 [[OPEN ISSUE: Reduce these values? https://github.com/tlswg/tls13- 975 spec/issues/55]] 977 In order to decrypt and verify, the cipher takes as input the key, 978 nonce, the "additional_data", and the AEADEncrypted value. The 979 output is either the plaintext or an error indicating that the 980 decryption failed. There is no separate integrity check. That is: 982 TLSPlaintext.fragment = AEAD-Decrypt(write_key, nonce, 983 AEADEncrypted, 984 additional_data) 986 If the decryption fails, a fatal bad_record_mac alert MUST be 987 generated. 989 As a special case, we define the NULL_NULL AEAD cipher which is 990 simply the identity operation and thus provides no security. This 991 cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL 992 cipher suite. 994 6.3. Key Calculation 996 [[OPEN ISSUE: This needs to be revised. See 997 https://github.com/tlswg/tls13-spec/issues/5]] The Record Protocol 998 requires an algorithm to generate keys required by the current 999 connection state (see Appendix A.6) from the security parameters 1000 provided by the handshake protocol. 1002 The master secret is expanded into a sequence of secure bytes, which 1003 is then split to a client write encryption key and a server write 1004 encryption key. Each of these is generated from the byte sequence in 1005 that order. Unused values are empty. Some ciphers may additionally 1006 require a client write IV and a server write IV. 1008 When keys are generated, the then current master secret (MS) is used 1009 as an entropy source. For handshake records, this means the 1010 hs_master_secret. For application data records, this means the 1011 regular master_secret. 1013 To generate the key material, compute 1015 key_block = PRF(MS, 1016 "key expansion", 1017 SecurityParameters.server_random + 1018 SecurityParameters.client_random); 1020 where MS is the relevant master secret. The PRF is computed enough 1021 times to generate the necessary amount of data for the key_block, 1022 which is then partitioned as follows: 1024 client_write_key[SecurityParameters.enc_key_length] 1025 server_write_key[SecurityParameters.enc_key_length] 1026 client_write_IV[SecurityParameters.fixed_iv_length] 1027 server_write_IV[SecurityParameters.fixed_iv_length] 1029 Currently, the client_write_IV and server_write_IV are only generated 1030 for implicit nonce techniques as described in Section 3.2.1 of 1031 [RFC5116]. 1033 7. The TLS Handshaking Protocols 1035 TLS has three subprotocols that are used to allow peers to agree upon 1036 security parameters for the record layer, to authenticate themselves, 1037 to instantiate negotiated security parameters, and to report error 1038 conditions to each other. 1040 The Handshake Protocol is responsible for negotiating a session, 1041 which consists of the following items: 1043 session identifier 1044 An arbitrary byte sequence chosen by the server to identify an 1045 active or resumable session state. 1047 peer certificate 1048 X509v3 [RFC3280] certificate of the peer. This element of the 1049 state may be null. 1051 cipher spec 1052 Specifies the authentication and key establishment algorithms, the 1053 pseudorandom function (PRF) used to generate keying material, and 1054 the record protection algorithm (See Appendix A.6 for formal 1055 definition.) 1057 resumption premaster secret 1058 48-byte secret shared between the client and server. 1060 is resumable 1061 A flag indicating whether the session can be used to initiate new 1062 connections. 1064 These items are then used to create security parameters for use by 1065 the record layer when protecting application data. Many connections 1066 can be instantiated using the same session through the resumption 1067 feature of the TLS Handshake Protocol. 1069 7.1. Alert Protocol 1071 One of the content types supported by the TLS record layer is the 1072 alert type. Alert messages convey the severity of the message 1073 (warning or fatal) and a description of the alert. Alert messages 1074 with a level of fatal result in the immediate termination of the 1075 connection. In this case, other connections corresponding to the 1076 session may continue, but the session identifier MUST be invalidated, 1077 preventing the failed session from being used to establish new 1078 connections. Like other messages, alert messages are encrypted as 1079 specified by the current connection state. 1081 enum { warning(1), fatal(2), (255) } AlertLevel; 1083 enum { 1084 close_notify(0), 1085 unexpected_message(10), 1086 bad_record_mac(20), 1087 decryption_failed_RESERVED(21), 1088 record_overflow(22), 1089 decompression_failure_RESERVED(30), 1090 handshake_failure(40), 1091 no_certificate_RESERVED(41), 1092 bad_certificate(42), 1093 unsupported_certificate(43), 1094 certificate_revoked(44), 1095 certificate_expired(45), 1096 certificate_unknown(46), 1097 illegal_parameter(47), 1098 unknown_ca(48), 1099 access_denied(49), 1100 decode_error(50), 1101 decrypt_error(51), 1102 export_restriction_RESERVED(60), 1103 protocol_version(70), 1104 insufficient_security(71), 1105 internal_error(80), 1106 user_canceled(90), 1107 no_renegotiation(100), 1108 unsupported_extension(110), 1109 (255) 1110 } AlertDescription; 1112 struct { 1113 AlertLevel level; 1114 AlertDescription description; 1115 } Alert; 1117 7.1.1. Closure Alerts 1119 The client and the server must share knowledge that the connection is 1120 ending in order to avoid a truncation attack. Either party may 1121 initiate the exchange of closing messages. 1123 close_notify 1124 This message notifies the recipient that the sender will not send 1125 any more messages on this connection. Note that as of TLS 1.1, 1126 failure to properly close a connection no longer requires that a 1127 session not be resumed. This is a change from TLS 1.0 to conform 1128 with widespread implementation practice. 1130 Either party may initiate a close by sending a close_notify alert. 1131 Any data received after a closure alert is ignored. 1133 Unless some other fatal alert has been transmitted, each party is 1134 required to send a close_notify alert before closing the write side 1135 of the connection. The other party MUST respond with a close_notify 1136 alert of its own and close down the connection immediately, 1137 discarding any pending writes. It is not required for the initiator 1138 of the close to wait for the responding close_notify alert before 1139 closing the read side of the connection. 1141 If the application protocol using TLS provides that any data may be 1142 carried over the underlying transport after the TLS connection is 1143 closed, the TLS implementation must receive the responding 1144 close_notify alert before indicating to the application layer that 1145 the TLS connection has ended. If the application protocol will not 1146 transfer any additional data, but will only close the underlying 1147 transport connection, then the implementation MAY choose to close the 1148 transport without waiting for the responding close_notify. No part 1149 of this standard should be taken to dictate the manner in which a 1150 usage profile for TLS manages its data transport, including when 1151 connections are opened or closed. 1153 Note: It is assumed that closing a connection reliably delivers 1154 pending data before destroying the transport. 1156 7.1.2. Error Alerts 1158 Error handling in the TLS Handshake protocol is very simple. When an 1159 error is detected, the detecting party sends a message to the other 1160 party. Upon transmission or receipt of a fatal alert message, both 1161 parties immediately close the connection. Servers and clients MUST 1162 forget any session-identifiers, keys, and secrets associated with a 1163 failed connection. Thus, any connection terminated with a fatal 1164 alert MUST NOT be resumed. 1166 Whenever an implementation encounters a condition which is defined as 1167 a fatal alert, it MUST send the appropriate alert prior to closing 1168 the connection. For all errors where an alert level is not 1169 explicitly specified, the sending party MAY determine at its 1170 discretion whether to treat this as a fatal error or not. If the 1171 implementation chooses to send an alert but intends to close the 1172 connection immediately afterwards, it MUST send that alert at the 1173 fatal alert level. 1175 If an alert with a level of warning is sent and received, generally 1176 the connection can continue normally. If the receiving party decides 1177 not to proceed with the connection (e.g., after having received a 1178 no_renegotiation alert that it is not willing to accept), it SHOULD 1179 send a fatal alert to terminate the connection. Given this, the 1180 sending party cannot, in general, know how the receiving party will 1181 behave. Therefore, warning alerts are not very useful when the 1182 sending party wants to continue the connection, and thus are 1183 sometimes omitted. For example, if a peer decides to accept an 1184 expired certificate (perhaps after confirming this with the user) and 1185 wants to continue the connection, it would not generally send a 1186 certificate_expired alert. 1188 The following error alerts are defined: 1190 unexpected_message 1191 An inappropriate message was received. This alert is always fatal 1192 and should never be observed in communication between proper 1193 implementations. 1195 bad_record_mac 1196 This alert is returned if a record is received which cannot be 1197 deprotected. Because AEAD algorithms combine decryption and 1198 verification, this message is used for all deprotection failures. 1199 This message is always fatal and should never be observed in 1200 communication between proper implementations (except when messages 1201 were corrupted in the network). 1203 decryption_failed_RESERVED 1204 This alert was used in some earlier versions of TLS, and may have 1205 permitted certain attacks against the CBC mode [CBCATT]. It MUST 1206 NOT be sent by compliant implementations. 1208 record_overflow 1209 A TLSCiphertext record was received that had a length more than 1210 2^14+2048 bytes, or a record decrypted to a TLSPlaintext record 1211 with more than 2^14 bytes. This message is always fatal and 1212 should never be observed in communication between proper 1213 implementations (except when messages were corrupted in the 1214 network). 1216 decompression_failure 1217 This alert was used in previous versions of TLS. TLS 1.3 does not 1218 include compression and TLS 1.3 implementations MUST NOT send this 1219 alert when in TLS 1.3 mode. 1221 handshake_failure 1222 Reception of a handshake_failure alert message indicates that the 1223 sender was unable to negotiate an acceptable set of security 1224 parameters given the options available. This is a fatal error. 1226 no_certificate_RESERVED 1227 This alert was used in SSLv3 but not any version of TLS. It MUST 1228 NOT be sent by compliant implementations. 1230 bad_certificate 1231 A certificate was corrupt, contained signatures that did not 1232 verify correctly, etc. 1234 unsupported_certificate 1235 A certificate was of an unsupported type. 1237 certificate_revoked 1238 A certificate was revoked by its signer. 1240 certificate_expired 1241 A certificate has expired or is not currently valid. 1243 certificate_unknown 1244 Some other (unspecified) issue arose in processing the 1245 certificate, rendering it unacceptable. 1247 illegal_parameter 1248 A field in the handshake was out of range or inconsistent with 1249 other fields. This message is always fatal. 1251 unknown_ca 1252 A valid certificate chain or partial chain was received, but the 1253 certificate was not accepted because the CA certificate could not 1254 be located or couldn't be matched with a known, trusted CA. This 1255 message is always fatal. 1257 access_denied 1258 A valid certificate was received, but when access control was 1259 applied, the sender decided not to proceed with negotiation. This 1260 message is always fatal. 1262 decode_error 1263 A message could not be decoded because some field was out of the 1264 specified range or the length of the message was incorrect. This 1265 message is always fatal and should never be observed in 1266 communication between proper implementations (except when messages 1267 were corrupted in the network). 1269 decrypt_error 1270 A handshake cryptographic operation failed, including being unable 1271 to correctly verify a signature or validate a Finished message. 1272 This message is always fatal. 1274 export_restriction_RESERVED 1275 This alert was used in some earlier versions of TLS. It MUST NOT 1276 be sent by compliant implementations. 1278 protocol_version 1279 The protocol version the client has attempted to negotiate is 1280 recognized but not supported. (For example, old protocol versions 1281 might be avoided for security reasons.) This message is always 1282 fatal. 1284 insufficient_security 1285 Returned instead of handshake_failure when a negotiation has 1286 failed specifically because the server requires ciphers more 1287 secure than those supported by the client. This message is always 1288 fatal. 1290 internal_error 1291 An internal error unrelated to the peer or the correctness of the 1292 protocol (such as a memory allocation failure) makes it impossible 1293 to continue. This message is always fatal. 1295 user_canceled 1296 This handshake is being canceled for some reason unrelated to a 1297 protocol failure. If the user cancels an operation after the 1298 handshake is complete, just closing the connection by sending a 1299 close_notify is more appropriate. This alert should be followed 1300 by a close_notify. This message is generally a warning. 1302 no_renegotiation 1303 Sent by the client in response to a hello request or by the server 1304 in response to a client hello after initial handshaking. Versions 1305 of TLS prior to TLS 1.3 supported renegotiation of a previously 1306 established connection; TLS 1.3 removes this feature. This 1307 message is always fatal. 1309 unsupported_extension 1310 sent by clients that receive an extended server hello containing 1311 an extension that they did not put in the corresponding client 1312 hello. This message is always fatal. 1314 New Alert values are assigned by IANA as described in Section 12. 1316 7.2. Handshake Protocol Overview 1318 The cryptographic parameters of the session state are produced by the 1319 TLS Handshake Protocol, which operates on top of the TLS record 1320 layer. When a TLS client and server first start communicating, they 1321 agree on a protocol version, select cryptographic algorithms, 1322 optionally authenticate each other, and use public-key encryption 1323 techniques to generate shared secrets. 1325 The TLS Handshake Protocol involves the following steps: 1327 - Exchange hello messages to agree on a protocol version, 1328 algorithms, exchange random values, and check for session 1329 resumption. 1331 - Exchange the necessary cryptographic parameters to allow the 1332 client and server to agree on a premaster secret. 1334 - Exchange certificates and cryptographic information to allow the 1335 client and server to authenticate themselves. 1337 - Generate a master secret from the premaster secret and exchanged 1338 random values. 1340 - Provide security parameters to the record layer. 1342 - Allow the client and server to verify that their peer has 1343 calculated the same security parameters and that the handshake 1344 occurred without tampering by an attacker. 1346 Note that higher layers should not be overly reliant on whether TLS 1347 always negotiates the strongest possible connection between two 1348 peers. There are a number of ways in which a man-in-the-middle 1349 attacker can attempt to make two entities drop down to the least 1350 secure method they support. The protocol has been designed to 1351 minimize this risk, but there are still attacks available: for 1352 example, an attacker could block access to the port a secure service 1353 runs on, or attempt to get the peers to negotiate an unauthenticated 1354 connection. The fundamental rule is that higher levels must be 1355 cognizant of what their security requirements are and never transmit 1356 information over a channel less secure than what they require. The 1357 TLS protocol is secure in that any cipher suite offers its promised 1358 level of security: if you negotiate AES-GCM [GCM] with a 1024-bit DHE 1359 key exchange with a host whose certificate you have verified, you can 1360 expect to be that secure. 1362 These goals are achieved by the handshake protocol, which can be 1363 summarized as follows: The client sends a ClientHello message which 1364 contains a random nonce (ClientHello.random), its preferences for 1365 Protocol Version, Cipher Suite, and a variety of extensions. In the 1366 same flight, it sends a ClientKeyShare message which contains its 1367 share of the parameters for key agreement for some set of expected 1368 server parameters (DHE/ECDHE groups, etc.). 1370 If the client has provided a ClientKeyShare with an appropriate set 1371 of keying material, the server responds to the ClientHello with a 1372 ServerHello message. The ServerHello contains the server's nonce 1373 (ServerHello.random), the server's choice of the Protocol Version, 1374 Session ID and Cipher Suite, and the server's response to the 1375 extensions the client offered. 1377 The server can then generate its own keying material share and send a 1378 ServerKeyShare message which contains its share of the parameters for 1379 the key agreement. The server can now compute the shared secret (the 1380 premaster secret). At this point, the server starts encrypting all 1381 remaining handshake traffic with the negotiated cipher suite using a 1382 key derived from the premaster secret (via the "handshake master 1383 secret"). The remainder of the server's handshake messages will be 1384 encrypted using that key. 1386 Following these messages, the server will send an EncryptedExtensions 1387 message which contains a response to any client's extensions which 1388 are not necessary to establish the Cipher Suite. The server will 1389 then send its certificate in a Certificate message if it is to be 1390 authenticated. The server may optionally request a certificate from 1391 the client by sending a CertificateRequest message at this point. 1392 Finally, if the server is authenticated, it will send a 1393 CertificateVerify message which provides a signature over the entire 1394 handshake up to this point. This serves both to authenticate the 1395 server and to establish the integrity of the negotiation. Finally, 1396 the server sends a Finished message which includes an integrity check 1397 over the handshake keyed by the shared secret and demonstrates that 1398 the server and client have agreed upon the same keys. [[TODO: If the 1399 server is not requesting client authentication, it MAY start sending 1400 application data following the Finished, though the server has no way 1401 of knowing who will be receiving the data. Add this.]] 1403 Once the client receives the ServerKeyShare, it can also compute the 1404 premaster secret and decrypt the server's remaining handshake 1405 messages. The client generates its own sending keys based on the 1406 premaster secret and will encrypt the remainder of its handshake 1407 messages using those keys and the newly established cipher suite. If 1408 the server has sent a CertificateRequest message, the client MUST 1409 send the Certificate message, though it may contain zero 1410 certificates. If the client has sent a certificate, a digitally- 1411 signed CertificateVerify message is sent to explicitly verify 1412 possession of the private key in the certificate. Finally, the 1413 client sends the Finished message. 1415 At this point, the handshake is complete, and the client and server 1416 may exchange application layer data, which is protected using a new 1417 set of keys derived from both the premaster secret and the handshake 1418 transcript (see [I-D.ietf-tls-session-hash] for the security 1419 rationale for this.) 1421 Application data MUST NOT be sent prior to the Finished message. 1422 [[TODO: can we make this clearer and more clearly match the text 1423 above about server-side False Start.]] Client Server 1425 ClientHello 1426 ClientKeyShare --------> 1427 ServerHello 1428 ServerKeyShare 1429 {EncryptedExtensions*} 1430 {Certificate*} 1431 {CertificateRequest*} 1432 {CertificateVerify*} 1433 <-------- {Finished} 1434 {Certificate*} 1435 {CertificateVerify*} 1436 {Finished} --------> 1437 [Application Data] <-------> [Application Data] 1439 Figure 1. Message flow for a full handshake 1441 * Indicates optional or situation-dependent messages that are not 1442 always sent. 1444 {} Indicates messages protected using keys derived from the handshake 1445 master secret. 1447 [] Indicates messages protected using keys derived from the master 1448 secret. 1450 If the client has not provided an appropriate ClientKeyShare (e.g. it 1451 includes only DHE or ECDHE groups unacceptable or unsupported by the 1452 server), the server corrects the mismatch with a HelloRetryRequest 1453 and the client will need to restart the handshake with an appropriate 1454 ClientKeyShare, as shown in Figure 2: 1456 Client Server 1458 ClientHello 1459 ClientKeyShare --------> 1460 <-------- HelloRetryRequest 1462 ClientHello 1463 ClientKeyShare --------> 1464 ServerHello 1465 ServerKeyShare 1466 {EncryptedExtensions*} 1467 {Certificate*} 1468 {CertificateRequest*} 1469 {CertificateVerify*} 1470 <-------- {Finished} 1471 {Certificate*} 1472 {CertificateVerify*} 1473 {Finished} --------> 1474 [Application Data] <-------> [Application Data] 1476 Figure 2. Message flow for a full handshake with mismatched 1477 parameters 1479 [[OPEN ISSUE: Should we restart the handshake hash? 1480 https://github.com/tlswg/tls13-spec/issues/104.]] [[OPEN ISSUE: We 1481 need to make sure that this flow doesn't introduce downgrade issues. 1482 Potential options include continuing the handshake hashes (as long as 1483 clients don't change their opinion of the server's capabilities with 1484 aborted handshakes) and requiring the client to send the same 1485 ClientHello (as is currently done) and then checking you get the same 1486 negotiated parameters.]] 1488 If no common cryptographic parameters can be negotiated, the server 1489 will send a fatal alert. 1491 When the client and server decide to resume a previous session or 1492 duplicate an existing session (instead of negotiating new security 1493 parameters), the message flow is as follows: 1495 The client sends a ClientHello using the Session ID of the session to 1496 be resumed. The server then checks its session cache for a match. 1497 If a match is found, and the server is willing to re-establish the 1498 connection under the specified session state, it will send a 1499 ServerHello with the same Session ID value. At this point, both 1500 client and server MUST proceed directly to sending Finished messages, 1501 which are protected using handshake keys as described above, computed 1502 using resumption premaster secret created in the first handshake as 1503 the premaster secret. Once the re-establishment is complete, the 1504 client and server MAY begin to exchange application layer data, which 1505 is protected using the application secrets (See flow chart below.) 1506 If a Session ID match is not found, the server generates a new 1507 session ID, and the TLS client and server perform a full handshake. 1509 Client Server 1511 ClientHello 1512 ClientKeyExhange --------> 1513 ServerHello 1514 <-------- {Finished} 1515 {Finished} --------> 1516 [Application Data] <-------> [Application Data] 1518 Figure 3. Message flow for an abbreviated handshake 1520 The contents and significance of each message will be presented in 1521 detail in the following sections. 1523 7.3. Handshake Protocol 1525 The TLS Handshake Protocol is one of the defined higher-level clients 1526 of the TLS Record Protocol. This protocol is used to negotiate the 1527 secure attributes of a session. Handshake messages are supplied to 1528 the TLS record layer, where they are encapsulated within one or more 1529 TLSPlaintext structures, which are processed and transmitted as 1530 specified by the current active session state. 1532 enum { 1533 reserved(0), client_hello(1), server_hello(2), 1534 client_key_share(5), hello_retry_request(6), 1535 server_key_share(7), certificate(11), reserved(12), 1536 certificate_request(13), certificate_verify(15), 1537 reserved(16), finished(20), (255) 1538 } HandshakeType; 1540 struct { 1541 HandshakeType msg_type; /* handshake type */ 1542 uint24 length; /* bytes in message */ 1543 select (HandshakeType) { 1544 case client_hello: ClientHello; 1545 case client_key_share: ClientKeyShare; 1546 case server_hello: ServerHello; 1547 case hello_retry_request: HelloRetryRequest; 1548 case server_key_share: ServerKeyShare; 1549 case certificate: Certificate; 1550 case certificate_request: CertificateRequest; 1551 case certificate_verify: CertificateVerify; 1552 case finished: Finished; 1553 } body; 1554 } Handshake; 1556 The handshake protocol messages are presented below in the order they 1557 MUST be sent; sending handshake messages in an unexpected order 1558 results in a fatal error. Unneeded handshake messages can be 1559 omitted, however. 1561 New handshake message types are assigned by IANA as described in 1562 Section 12. 1564 7.3.1. Hello Messages 1566 The hello phase messages are used to exchange security enhancement 1567 capabilities between the client and server. When a new session 1568 begins, the record layer's connection state AEAD algorithm is 1569 initialized to NULL_NULL. The current connection state is used for 1570 renegotiation messages. 1572 7.3.1.1. Client Hello 1574 When this message will be sent: 1576 When a client first connects to a server, it is required to send 1577 the ClientHello as its first message. The client will also send a 1578 ClientHello when the server has responded to its ClientHello with 1579 a ServerHello that selects cryptographic parameters that don't 1580 match the client's ClientKeyShare. In that case, the client MUST 1581 send the same ClientHello (without modification) along with the 1582 new ClientKeyShare. If a server receives a ClientHello at any 1583 other time, it MUST send a fatal no_renegotiation alert. 1585 Structure of this message: 1587 The ClientHello message includes a random structure, which is used 1588 later in the protocol. 1590 struct { 1591 opaque random_bytes[32]; 1592 } Random; 1594 random_bytes 1595 32 bytes generated by a secure random number generator. 1597 Note: Versions of TLS prior to TLS 1.3 used the top 32 bits of the 1598 Random value to encode the time since the UNIX epoch. 1600 Note: The ClientHello message includes a variable-length session 1601 identifier. If not empty, the value identifies a session between the 1602 same client and server whose security parameters the client wishes to 1603 reuse. The session identifier MAY be from an earlier connection, 1604 this connection, or from another currently active connection. The 1605 second option is useful if the client only wishes to update the 1606 random structures and derived values of a connection, and the third 1607 option makes it possible to establish several independent secure 1608 connections without repeating the full handshake protocol. These 1609 independent connections may occur sequentially or simultaneously; a 1610 SessionID becomes valid when the handshake negotiating it completes 1611 with the exchange of Finished messages and persists until it is 1612 removed due to aging or because a fatal error was encountered on a 1613 connection associated with the session. The actual contents of the 1614 SessionID are defined by the server. 1616 opaque SessionID<0..32>; 1618 Warning: Because the SessionID is transmitted without confidentiality 1619 or integrity protection, servers MUST NOT place confidential 1620 information in session identifiers or let the contents of fake 1621 session identifiers cause any breach of security. (Note that the 1622 content of the handshake as a whole, including the SessionID, is 1623 protected by the Finished messages exchanged at the end of the 1624 handshake.) 1626 The cipher suite list, passed from the client to the server in the 1627 ClientHello message, contains the combinations of cryptographic 1628 algorithms supported by the client in order of the client's 1629 preference (favorite choice first). Each cipher suite defines a key 1630 exchange algorithm, a record protection algorithm (including secret 1631 key length) and a PRF. The server will select a cipher suite or, if 1632 no acceptable choices are presented, return a handshake failure alert 1633 and close the connection. If the list contains cipher suites the 1634 server does not recognize, support, or wish to use, the server MUST 1635 ignore those cipher suites, and process the remaining ones as usual. 1637 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1639 enum { null(0), (255) } CompressionMethod; 1641 struct { 1642 ProtocolVersion client_version; 1643 Random random; 1644 SessionID session_id; 1645 CipherSuite cipher_suites<2..2^16-2>; 1646 CompressionMethod compression_methods<1..2^8-1>; 1647 select (extensions_present) { 1648 case false: 1649 struct {}; 1650 case true: 1651 Extension extensions<0..2^16-1>; 1652 }; 1653 } ClientHello; 1655 TLS allows extensions to follow the compression_methods field in an 1656 extensions block. The presence of extensions can be detected by 1657 determining whether there are bytes following the compression_methods 1658 at the end of the ClientHello. Note that this method of detecting 1659 optional data differs from the normal TLS method of having a 1660 variable-length field, but it is used for compatibility with TLS 1661 before extensions were defined. 1663 client_version 1664 The version of the TLS protocol by which the client wishes to 1665 communicate during this session. This SHOULD be the latest 1666 (highest valued) version supported by the client. For this 1667 version of the specification, the version will be 3.4 (see 1668 Appendix E for details about backward compatibility). 1670 random 1671 A client-generated random structure. 1673 session_id 1674 The ID of a session the client wishes to use for this connection. 1675 This field is empty if no session_id is available, or if the 1676 client wishes to generate new security parameters. 1678 cipher_suites 1679 This is a list of the cryptographic options supported by the 1680 client, with the client's first preference first. If the 1681 session_id field is not empty (implying a session resumption 1682 request), this vector MUST include at least the cipher_suite from 1683 that session. Values are defined in Appendix A.5. 1685 compression_methods 1686 Versions of TLS before 1.3 supported compression and the list of 1687 compression methods was supplied in this field. For any TLS 1.3 1688 ClientHello, this field MUST contain only the "null" compression 1689 method with the code point of 0. If a TLS 1.3 ClientHello is 1690 received with any other value in this field, the server MUST 1691 generate a fatal "illegal_parameter" alert. Note that TLS 1.3 1692 servers may receive TLS 1.2 or prior ClientHellos which contain 1693 other compression methods and MUST follow the procedures for the 1694 appropriate prior version of TLS. 1696 extensions 1697 Clients MAY request extended functionality from servers by sending 1698 data in the extensions field. The actual "Extension" format is 1699 defined in Section 7.3.2.5. 1701 In the event that a client requests additional functionality using 1702 extensions, and this functionality is not supplied by the server, the 1703 client MAY abort the handshake. A server MUST accept ClientHello 1704 messages both with and without the extensions field, and (as for all 1705 other messages) it MUST check that the amount of data in the message 1706 precisely matches one of these formats; if not, then it MUST send a 1707 fatal "decode_error" alert. 1709 After sending the ClientHello message, the client waits for a 1710 ServerHello or HelloRetryRequest message. 1712 7.3.2. Client Key Share Message 1714 When this message will be sent: 1716 This message is always sent by the client. It MUST immediately 1717 follow the ClientHello message. In backward compatibility mode 1718 (see Section XXX) it will be included in the EarlyData extension 1719 (Section 7.3.2.5.3) in the ClientHello. 1721 Meaning of this message: 1723 This message contains the client's cryptographic parameters for 1724 zero or more key establishment methods. 1726 Structure of this message: 1728 struct { 1729 NamedGroup group; 1730 opaque key_exchange<1..2^16-1>; 1731 } ClientKeyShareOffer; 1733 group The named group for the key share offer. This identifies the 1734 specific key exchange method that the ClientKeyShareOffer 1735 describes. Finite Field Diffie-Hellman parameters are described 1736 in Section 7.3.2.1; Elliptic Curve Diffie-Hellman parameters are 1737 described in Section 7.3.2.2. 1739 key_exchange Key exchange information. The contents of this field 1740 are determined by the value of NamedGroup entry and its 1741 corresponding definition. 1743 struct { 1744 ClientKeyShareOffer offers<0..2^16-1>; 1745 } ClientKeyShare; 1747 offers 1748 A list of ClientKeyShareOffer values. 1750 Clients may offer an arbitrary number of ClientKeyShareOffer values, 1751 each representing a single set of key agreement parameters; for 1752 instance a client might offer shares for several elliptic curves or 1753 multiple integer DH groups. The shares for each ClientKeyShareOffer 1754 MUST by generated independently. Clients MUST NOT offer multiple 1755 ClientKeyShareOffers for the same parameters. It is explicitly 1756 permitted to send an empty ClientKeyShare message, as this is used to 1757 elicit the server's parameters if the client has no useful 1758 information. [TODO: Recommendation about what the client offers. 1759 Presumably which integer DH groups and which curves.] [TODO: Work 1760 out how this interacts with PSK and SRP.] 1762 7.3.2.1. Diffie-Hellman Parameters 1764 Diffie-Hellman parameters for both clients and servers are encoded in 1765 the opaque key_exchange field of the ClientKeyShareOffer or 1766 ServerKeyShare structures. The opaque value contains the Diffie- 1767 Hellman public value (dh_Y = g^X mod p), encoded as a big-endian 1768 integer. 1770 opaque dh_Y<1..2^16-1>; 1772 7.3.2.2. ECHDE Parameters 1774 ECDHE parameters for both clients and servers are encoded in the 1775 opaque key_exchange field of the ClientKeyShareOffer or 1776 ServerKeyShare structures. The opaque value conveys the Elliptic 1777 Curve Diffie-Hellman public value (ecdh_Y) represented as a byte 1778 string ECPoint.point. 1780 opaque point <1..2^8-1>; 1782 point 1783 This is the byte string representation of an elliptic curve point 1784 following the conversion routine in Section 4.3.6 of ANSI X9.62 1785 {{X962}. 1787 Although X9.62 supports multiple point formats, any given curve MUST 1788 specify only a single point format. All curves currently specified 1789 in this document MUST only be used with the uncompressed point 1790 format. 1792 Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS 1793 1.3 removes this feature in favor of a single point format for each 1794 curve. 1796 [[OPEN ISSUE: We will need to adjust the compressed/uncompressed 1797 point issue if we have new curves that don't need point compression. 1798 This depends on the CFRG's recommendations. The expectation is that 1799 future curves will come with defined point formats and that existing 1800 curves conform to X9.62.]] 1802 7.3.2.3. Server Hello 1804 When this message will be sent: 1806 The server will send this message in response to a ClientHello 1807 message when it was able to find an acceptable set of algorithms 1808 and the client's ClientKeyShare message was acceptable. If the 1809 client proposed groups are not acceptable by the server, it will 1810 respond with an insufficient_security fatal alert. 1812 Structure of this message: 1814 struct { 1815 ProtocolVersion server_version; 1816 Random random; 1817 SessionID session_id; 1818 CipherSuite cipher_suite; 1819 select (extensions_present) { 1820 case false: 1821 struct {}; 1822 case true: 1823 Extension extensions<0..2^16-1>; 1824 }; 1825 } ServerHello; 1827 The presence of extensions can be detected by determining whether 1828 there are bytes following the cipher_suite field at the end of the 1829 ServerHello. 1831 server_version 1832 This field will contain the lower of that suggested by the client 1833 in the client hello and the highest supported by the server. For 1834 this version of the specification, the version is 3.4. (See 1835 Appendix E for details about backward compatibility.) 1837 random 1838 This structure is generated by the server and MUST be generated 1839 independently of the ClientHello.random. 1841 session_id 1842 This is the identity of the session corresponding to this 1843 connection. If the ClientHello.session_id was non-empty, the 1844 server will look in its session cache for a match. If a match is 1845 found and the server is willing to establish the new connection 1846 using the specified session state, the server will respond with 1847 the same value as was supplied by the client. This indicates a 1848 resumed session and dictates that the parties must proceed 1849 directly to the Finished messages. Otherwise, this field will 1850 contain a different value identifying the new session. The server 1851 may return an empty session_id to indicate that the session will 1852 not be cached and therefore cannot be resumed. If a session is 1853 resumed, it must be resumed using the same cipher suite it was 1854 originally negotiated with. Note that there is no requirement 1855 that the server resume any session even if it had formerly 1856 provided a session_id. Clients MUST be prepared to do a full 1857 negotiation -- including negotiating new cipher suites -- during 1858 any handshake. 1860 cipher_suite 1861 The single cipher suite selected by the server from the list in 1862 ClientHello.cipher_suites. For resumed sessions, this field is 1863 the value from the state of the session being resumed. 1865 extensions 1866 A list of extensions. Note that only extensions offered by the 1867 client can appear in the server's list. In TLS 1.3 as opposed to 1868 previous versions of TLS, the server's extensions are split 1869 between the ServerHello and the EncryptedExtensions Section 7.3.4 1870 message. The ServerHello MUST only include extensions which are 1871 required to establish the cryptographic context. 1873 7.3.2.4. HelloRetryRequest 1875 When this message will be sent: 1877 The server will send this message in response to a ClientHello 1878 message when it was able to find an acceptable set of algorithms 1879 but the client's ClientKeyShare message did not contain an 1880 acceptable offer. If it cannot find such a match, it will respond 1881 with a handshake failure alert. 1883 Structure of this message: 1885 struct { 1886 ProtocolVersion server_version; 1887 CipherSuite cipher_suite; 1888 NamedGroup selected_group; 1889 Extension extensions<0..2^16-1>; 1890 } HelloRetryRequest; 1892 [[OPEN ISSUE: Merge in DTLS Cookies?]] 1894 selected_group 1895 The group which the client MUST use for its new ClientHello. 1897 The "server_version", "cipher_suite" and "extensions" fields have the 1898 same meanings as their corresponding values in the ServerHello. The 1899 server SHOULD send only the extensions necessary for the client to 1900 generate a correct ClientHello/ClientKeyShare pair. 1902 Upon receipt of a HelloRetryRequest, the client MUST send a new 1903 ClientHello/ClientKeyShare pair to the server. The ClientKeyShare 1904 MUST contain both the groups in the original ClientKeyShare as well 1905 as a ClientKeyShareOffer consistent with the "selected_group" field. 1906 I.e., it MUST be a superset of the previous ClientKeyShareOffer. 1908 Upon re-sending the ClientHello/ClientKeyShare and receiving the 1909 server's ServerHello/ServerKeyShare, the client MUST verify that the 1910 selected ciphersuite and NamedGroup match that supplied in the 1911 HelloRetryRequest. 1913 7.3.2.5. Hello Extensions 1915 The extension format is: 1917 struct { 1918 ExtensionType extension_type; 1919 opaque extension_data<0..2^16-1>; 1920 } Extension; 1922 enum { 1923 signature_algorithms(13), early_data(TBD), (65535) 1924 } ExtensionType; 1926 Here: 1928 - "extension_type" identifies the particular extension type. 1930 - "extension_data" contains information specific to the particular 1931 extension type. 1933 The initial set of extensions is defined in a companion document 1934 [TLSEXT]. The list of extension types is maintained by IANA as 1935 described in Section 12. 1937 An extension type MUST NOT appear in the ServerHello unless the same 1938 extension type appeared in the corresponding ClientHello. If a 1939 client receives an extension type in ServerHello that it did not 1940 request in the associated ClientHello, it MUST abort the handshake 1941 with an unsupported_extension fatal alert. 1943 Nonetheless, "server-oriented" extensions may be provided in the 1944 future within this framework. Such an extension (say, of type x) 1945 would require the client to first send an extension of type x in a 1946 ClientHello with empty extension_data to indicate that it supports 1947 the extension type. In this case, the client is offering the 1948 capability to understand the extension type, and the server is taking 1949 the client up on its offer. 1951 When multiple extensions of different types are present in the 1952 ClientHello or ServerHello messages, the extensions MAY appear in any 1953 order. There MUST NOT be more than one extension of the same type. 1955 Finally, note that extensions can be sent both when starting a new 1956 session and when requesting session resumption. Indeed, a client 1957 that requests session resumption does not in general know whether the 1958 server will accept this request, and therefore it SHOULD send the 1959 same extensions as it would send if it were not attempting 1960 resumption. 1962 In general, the specification of each extension type needs to 1963 describe the effect of the extension both during full handshake and 1964 session resumption. Most current TLS extensions are relevant only 1965 when a session is initiated: when an older session is resumed, the 1966 server does not process these extensions in Client Hello, and does 1967 not include them in Server Hello. However, some extensions may 1968 specify different behavior during session resumption. 1970 There are subtle (and not so subtle) interactions that may occur in 1971 this protocol between new features and existing features which may 1972 result in a significant reduction in overall security. The following 1973 considerations should be taken into account when designing new 1974 extensions: 1976 - Some cases where a server does not agree to an extension are error 1977 conditions, and some are simply refusals to support particular 1978 features. In general, error alerts should be used for the former, 1979 and a field in the server extension response for the latter. 1981 - Extensions should, as far as possible, be designed to prevent any 1982 attack that forces use (or non-use) of a particular feature by 1983 manipulation of handshake messages. This principle should be 1984 followed regardless of whether the feature is believed to cause a 1985 security problem. 1987 Often the fact that the extension fields are included in the 1988 inputs to the Finished message hashes will be sufficient, but 1989 extreme care is needed when the extension changes the meaning of 1990 messages sent in the handshake phase. Designers and implementors 1991 should be aware of the fact that until the handshake has been 1992 authenticated, active attackers can modify messages and insert, 1993 remove, or replace extensions. 1995 - It would be technically possible to use extensions to change major 1996 aspects of the design of TLS; for example the design of cipher 1997 suite negotiation. This is not recommended; it would be more 1998 appropriate to define a new version of TLS -- particularly since 1999 the TLS handshake algorithms have specific protection against 2000 version rollback attacks based on the version number, and the 2001 possibility of version rollback should be a significant 2002 consideration in any major design change. 2004 7.3.2.5.1. Signature Algorithms 2006 The client uses the "signature_algorithms" extension to indicate to 2007 the server which signature/hash algorithm pairs may be used in 2008 digital signatures. The "extension_data" field of this extension 2009 contains a "supported_signature_algorithms" value. 2011 enum { 2012 none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), 2013 sha512(6), (255) 2014 } HashAlgorithm; 2016 enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } 2017 SignatureAlgorithm; 2019 struct { 2020 HashAlgorithm hash; 2021 SignatureAlgorithm signature; 2022 } SignatureAndHashAlgorithm; 2024 SignatureAndHashAlgorithm 2025 supported_signature_algorithms<2..2^16-2>; 2027 Each SignatureAndHashAlgorithm value lists a single hash/signature 2028 pair that the client is willing to verify. The values are indicated 2029 in descending order of preference. 2031 Note: Because not all signature algorithms and hash algorithms may be 2032 accepted by an implementation (e.g., DSA with SHA-1, but not SHA- 2033 256), algorithms here are listed in pairs. 2035 hash 2036 This field indicates the hash algorithm which may be used. The 2037 values indicate support for unhashed data, MD5 [RFC1321], SHA-1, 2038 SHA-224, SHA-256, SHA-384, and SHA-512 [SHS], respectively. The 2039 "none" value is provided for future extensibility, in case of a 2040 signature algorithm which does not require hashing before signing. 2042 signature 2043 This field indicates the signature algorithm that may be used. 2044 The values indicate anonymous signatures, RSASSA-PKCS1-v1_5 2045 [RFC3447] and DSA [DSS], and ECDSA [ECDSA], respectively. The 2046 "anonymous" value is meaningless in this context but used in 2047 Section 7.3.3. It MUST NOT appear in this extension. 2049 The semantics of this extension are somewhat complicated because the 2050 cipher suite indicates permissible signature algorithms but not hash 2051 algorithms. Section 7.3.5 and Section 7.3.3 describe the appropriate 2052 rules. 2054 If the client supports only the default hash and signature algorithms 2055 (listed in this section), it MAY omit the signature_algorithms 2056 extension. If the client does not support the default algorithms, or 2057 supports other hash and signature algorithms (and it is willing to 2058 use them for verifying messages sent by the server, i.e., server 2059 certificates and server key share), it MUST send the 2060 signature_algorithms extension, listing the algorithms it is willing 2061 to accept. 2063 If the client does not send the signature_algorithms extension, the 2064 server MUST do the following: 2066 - If the negotiated key exchange algorithm is one of (DHE_RSA, 2067 ECDHE_RSA), behave as if client had sent the value {sha1,rsa}. 2069 - If the negotiated key exchange algorithm is DHE_DSS, behave as if 2070 the client had sent the value {sha1,dsa}. 2072 - If the negotiated key exchange algorithm is ECDHE_ECDSA, behave as 2073 if the client had sent value {sha1,ecdsa}. 2075 Note: this is a change from TLS 1.1 where there are no explicit 2076 rules, but as a practical matter one can assume that the peer 2077 supports MD5 and SHA-1. 2079 Note: this extension is not meaningful for TLS versions prior to 1.2. 2080 Clients MUST NOT offer it if they are offering prior versions. 2081 However, even if clients do offer it, the rules specified in [TLSEXT] 2082 require servers to ignore extensions they do not understand. 2084 Servers MUST NOT send this extension. TLS servers MUST support 2085 receiving this extension. 2087 When performing session resumption, this extension is not included in 2088 Server Hello, and the server ignores the extension in Client Hello 2089 (if present). 2091 7.3.2.5.2. Negotiated Groups 2093 When sent by the client, the "supported_groups" extension indicates 2094 the named groups which the client supports, ordered from most 2095 preferred to least preferred. 2097 Note: In versions of TLS prior to TLS 1.3, this extension was named 2098 "elliptic curves" and only contained elliptic curve groups. See 2099 [RFC4492] and [I-D.ietf-tls-negotiated-ff-dhe]. 2101 The "extension_data" field of this extension SHALL contain a 2102 "NamedGroupList" value: 2104 enum { 2105 // Elliptic Curve Groups. 2106 sect163k1 (1), sect163r1 (2), sect163r2 (3), 2107 sect193r1 (4), sect193r2 (5), sect233k1 (6), 2108 sect233r1 (7), sect239k1 (8), sect283k1 (9), 2109 sect283r1 (10), sect409k1 (11), sect409r1 (12), 2110 sect571k1 (13), sect571r1 (14), secp160k1 (15), 2111 secp160r1 (16), secp160r2 (17), secp192k1 (18), 2112 secp192r1 (19), secp224k1 (20), secp224r1 (21), 2113 secp256k1 (22), secp256r1 (23), secp384r1 (24), 2114 secp521r1 (25), 2116 // Finite Field Groups. 2117 ffdhe2432(256), ffdhe3072(257), ffdhe4096(258), 2118 ffdhe6144(259), ffdhe8192(260), 2120 // Reserved Code Points. 2121 reserved (0xFE00..0xFEFF), 2122 reserved(0xFF01), 2123 reserved(0xFF02), 2124 (0xFFFF) 2125 } NamedGroup; 2127 struct { 2128 NamedGroup named_group_list<1..2^16-1> 2129 } NamedGroupList; 2131 sect163k1, etc: Indicates support of the corresponding named curve 2132 The named curves defined here are those specified in SEC 2 [13]. 2133 Note that many of these curves are also recommended in ANSI X9.62 2134 [X962] and FIPS 186-2 [DSS]. Values 0xFE00 through 0xFEFF are 2135 reserved for private use. Values 0xFF01 and 0xFF02 were used in 2136 previous versions of TLS but MUST NOT be offered by TLS 1.3 2137 implementations. [[OPEN ISSUE: Triage curve list.]] 2139 ffdhe2432, etc: Indicates support of the corresponding finite field 2140 group, defined in [I-D.ietf-tls-negotiated-ff-dhe] 2142 Items in named_curve_list are ordered according to the client's 2143 preferences (favorite choice first). 2145 As an example, a client that only supports secp192r1 (aka NIST P-192; 2146 value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) 2147 and prefers to use secp192r1 would include a TLS extension consisting 2148 of the following octets. Note that the first two octets indicate the 2149 extension type (Supported Group Extension): 2151 00 0A 00 06 00 04 00 13 00 15 2153 The client MUST supply a "named_groups" extension containing at least 2154 one group for each key exchange algorithm (currently DHE and ECDHE) 2155 for which it offers a cipher suite. If the client does not supply a 2156 "named_groups" extension with a compatible group, the server MUST NOT 2157 negotiate a cipher suite of the relevant type. For instance, if a 2158 client supplies only ECDHE groups, the server MUST NOT negotiate 2159 finite field Diffie-Hellman. If no acceptable group can be selected 2160 across all cipher suites, then the server MUST generate a fatal 2161 "handshake_failure" alert. 2163 NOTE: A server participating in an ECDHE-ECDSA key exchange may use 2164 different curves for (i) the ECDSA key in its certificate, and (ii) 2165 the ephemeral ECDH key in the ServerKeyExchange message. The server 2166 must consider the supported groups in both cases. 2168 [[TODO: IANA Considerations.]] 2170 7.3.2.5.3. Early Data Extension 2172 TLS versions before 1.3 have a strict message ordering and do not 2173 permit additional messages to follow the ClientHello. The EarlyData 2174 extension allows TLS messages which would otherwise be sent as 2175 separate records to be instead inserted in the ClientHello. The 2176 extension simply contains the TLS records which would otherwise have 2177 been included in the client's first flight. 2179 struct { 2180 TLSCipherText messages<5 .. 2^24-1>; 2181 } EarlyDataExtension; 2183 Extra messages for the client's first flight MAY either be 2184 transmitted standalone or sent as EarlyData. However, when a client 2185 does not know whether TLS 1.3 can be negotiated - e.g., because the 2186 server may support a prior version of TLS or because of network 2187 intermediaries - it SHOULD use the EarlyData extension. If the 2188 EarlyData extension is used, then clients MUST NOT send any messages 2189 other than the ClientHello in their initial flight. 2191 Any data included in EarlyData is not integrated into the handshake 2192 hashes directly. E.g., if the ClientKeyShare is included in 2193 EarlyData, then the handshake hashes consist of ClientHello + 2194 ServerHello, etc. However, because the ClientKeyShare is in a 2195 ClientHello extension, it is still hashed transitively. This 2196 procedure guarantees that the Finished message covers these messages 2197 even if they are ultimately ignored by the server (e.g., because it 2198 is sent to a TLS 1.2 server). TLS 1.3 servers MUST understand 2199 messages sent in EarlyData, and aside from hashing them differently, 2200 MUST treat them as if they had been sent immediately after the 2201 ClientHello. 2203 Servers MUST NOT send the EarlyData extension. Negotiating TLS 1.3 2204 serves as acknowledgement that it was processed as described above. 2206 [[OPEN ISSUE: This is a fairly general mechanism which is possibly 2207 overkill in the 1-RTT case, where it would potentially be more 2208 attractive to just have a "ClientKeyShare" extension. However, for 2209 the 0-RTT case we will want to send the Certificate, 2210 CertificateVerify, and application data, so a more general extension 2211 seems appropriate at least until we have determined we don't need it 2212 for 0-RTT.]] 2214 7.3.3. Server Key Share Message 2216 When this message will be sent: 2218 This message will be sent immediately after the ServerHello 2219 message if the client has provided a ClientKeyShare message which 2220 is compatible with the selected cipher suite and group parameters. 2222 Meaning of this message: 2224 This message conveys cryptographic information to allow the client 2225 to compute the premaster secret: a Diffie-Hellman public key with 2226 which the client can complete a key exchange (with the result 2227 being the premaster secret) or a public key for some other 2228 algorithm. 2230 Structure of this message: 2232 struct { 2233 NamedGroup group; 2234 opaque key_exchange<1..2^16-1>; 2235 } ServerKeyShare; 2237 group The named group for the key share offer. This identifies the 2238 selected key exchange method from the ClientKeyShare message 2239 (Section 7.3.2), identifying which value from the 2240 ClientKeyShareOffer the server has accepted as is responding to. 2242 key_exchange Key exchange information. The contents of this field 2243 are determined by the value of NamedGroup entry and its 2244 corresponding definition. 2246 7.3.4. Encrypted Extensions 2248 When this message will be sent: 2250 If this message is sent, it MUST be sent immediately after the 2251 server's ServerKeyShare. 2253 Meaning of this message: 2255 The EncryptedExtensions message simply contains any extensions 2256 which should be protected, i.e., any which are not needed to 2257 establish the cryptographic context. The same extension types 2258 MUST NOT appear in both the ServerHello and EncryptedExtensions. 2259 If the same extension appears in both locations, the client MUST 2260 rely only on the value in the EncryptedExtensions block. [[OPEN 2261 ISSUE: Should we just produce a canonical list of what goes where 2262 and have it be an error to have it in the wrong place? That seems 2263 simpler. Perhaps have a whitelist of which extensions can be 2264 unencrypted and everything else MUST be encrypted.]] 2266 Structure of this message: 2268 struct { 2269 Extension extensions<0..2^16-1>; 2270 } EncryptedExtensions; 2272 extensions 2273 A list of extensions. 2275 7.3.5. Server Certificate 2277 When this message will be sent: 2279 The server MUST send a Certificate message whenever the agreed- 2280 upon key exchange method uses certificates for authentication 2281 (this includes all key exchange methods defined in this document 2282 except DH_anon). This message will always immediately follow 2283 either the EncryptedExtensions message if one is sent or the 2284 ServerKeyShare message. 2286 Meaning of this message: 2288 This message conveys the server's certificate chain to the client. 2290 The certificate MUST be appropriate for the negotiated cipher 2291 suite's key exchange algorithm and any negotiated extensions. 2293 Structure of this message: 2295 opaque ASN1Cert<1..2^24-1>; 2297 struct { 2298 ASN1Cert certificate_list<0..2^24-1>; 2299 } Certificate; 2301 certificate_list 2302 This is a sequence (chain) of certificates. The sender's 2303 certificate MUST come first in the list. Each following 2304 certificate MUST directly certify the one preceding it. Because 2305 certificate validation requires that root keys be distributed 2306 independently, the self-signed certificate that specifies the root 2307 certificate authority MAY be omitted from the chain, under the 2308 assumption that the remote end must already possess it in order to 2309 validate it in any case. 2311 The same message type and structure will be used for the client's 2312 response to a certificate request message. Note that a client MAY 2313 send no certificates if it does not have an appropriate certificate 2314 to send in response to the server's authentication request. 2316 Note: PKCS #7 [PKCS7] is not used as the format for the certificate 2317 vector because PKCS #6 [PKCS6] extended certificates are not used. 2318 Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task 2319 of parsing the list more difficult. 2321 The following rules apply to the certificates sent by the server: 2323 - The certificate type MUST be X.509v3, unless explicitly negotiated 2324 otherwise (e.g., [RFC5081]). 2326 - The end entity certificate's public key (and associated 2327 restrictions) MUST be compatible with the selected key exchange 2328 algorithm. 2330 Key Exchange Alg. Certificate Key Type 2332 DHE_RSA RSA public key; the certificate MUST allow the 2333 ECDHE_RSA key to be used for signing (the 2334 digitalSignature bit MUST be set if the key 2335 usage extension is present) with the signature 2336 scheme and hash algorithm that will be employed 2337 in the server key exchange message. 2338 Note: ECDHE_RSA is defined in [RFC4492]. 2340 DHE_DSS DSA public key; the certificate MUST allow the 2341 key to be used for signing with the hash 2342 algorithm that will be employed in the server 2343 key exchange message. 2345 ECDHE_ECDSA ECDSA-capable public key; the certificate MUST 2346 allow the key to be used for signing with the 2347 hash algorithm that will be employed in the 2348 server key exchange message. The public key 2349 MUST use a curve and point format supported by 2350 the client, as described in [RFC4492]. 2352 - The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are 2353 used to guide certificate selection. 2355 If the client provided a "signature_algorithms" extension, then all 2356 certificates provided by the server MUST be signed by a hash/ 2357 signature algorithm pair that appears in that extension. Note that 2358 this implies that a certificate containing a key for one signature 2359 algorithm MAY be signed using a different signature algorithm (for 2360 instance, an RSA key signed with a DSA key). This is a departure 2361 from TLS 1.1, which required that the algorithms be the same. 2363 If the server has multiple certificates, it chooses one of them based 2364 on the above-mentioned criteria (in addition to other criteria, such 2365 as transport layer endpoint, local configuration and preferences, 2366 etc.). If the server has a single certificate, it SHOULD attempt to 2367 validate that it meets these criteria. 2369 Note that there are certificates that use algorithms and/or algorithm 2370 combinations that cannot be currently used with TLS. For example, a 2371 certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in 2372 SubjectPublicKeyInfo) cannot be used because TLS defines no 2373 corresponding signature algorithm. 2375 As cipher suites that specify new key exchange methods are specified 2376 for the TLS protocol, they will imply the certificate format and the 2377 required encoded keying information. 2379 7.3.6. Certificate Request 2381 When this message will be sent: 2383 A non-anonymous server can optionally request a certificate from 2384 the client, if appropriate for the selected cipher suite. This 2385 message, if sent, will immediately follow the server's Certificate 2386 message). 2388 Structure of this message: 2390 enum { 2391 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), 2392 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), 2393 fortezza_dms_RESERVED(20), (255) 2394 } ClientCertificateType; 2396 opaque DistinguishedName<1..2^16-1>; 2398 struct { 2399 ClientCertificateType certificate_types<1..2^8-1>; 2400 SignatureAndHashAlgorithm 2401 supported_signature_algorithms<2..2^16-2>; 2402 DistinguishedName certificate_authorities<0..2^16-1>; 2403 } CertificateRequest; 2405 certificate_types 2406 A list of the types of certificate types that the client may 2407 offer. 2409 rsa_sign a certificate containing an RSA key 2410 dss_sign a certificate containing a DSA key 2411 rsa_fixed_dh a certificate containing a static DH key. 2412 dss_fixed_dh a certificate containing a static DH key 2414 supported_signature_algorithms 2415 A list of the hash/signature algorithm pairs that the server is 2416 able to verify, listed in descending order of preference. 2418 certificate_authorities 2419 A list of the distinguished names [X501] of acceptable 2420 certificate_authorities, represented in DER-encoded format. These 2421 distinguished names may specify a desired distinguished name for a 2422 root CA or for a subordinate CA; thus, this message can be used to 2423 describe known roots as well as a desired authorization space. If 2424 the certificate_authorities list is empty, then the client MAY 2425 send any certificate of the appropriate ClientCertificateType, 2426 unless there is some external arrangement to the contrary. 2428 The interaction of the certificate_types and 2429 supported_signature_algorithms fields is somewhat complicated. 2430 certificate_types has been present in TLS since SSLv3, but was 2431 somewhat underspecified. Much of its functionality is superseded by 2432 supported_signature_algorithms. The following rules apply: 2434 - Any certificates provided by the client MUST be signed using a 2435 hash/signature algorithm pair found in 2436 supported_signature_algorithms. 2438 - The end-entity certificate provided by the client MUST contain a 2439 key that is compatible with certificate_types. If the key is a 2440 signature key, it MUST be usable with some hash/signature 2441 algorithm pair in supported_signature_algorithms. 2443 - For historical reasons, the names of some client certificate types 2444 include the algorithm used to sign the certificate. For example, 2445 in earlier versions of TLS, rsa_fixed_dh meant a certificate 2446 signed with RSA and containing a static DH key. In TLS 1.2, this 2447 functionality has been obsoleted by the 2448 supported_signature_algorithms, and the certificate type no longer 2449 restricts the algorithm used to sign the certificate. For 2450 example, if the server sends dss_fixed_dh certificate type and 2451 {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply 2452 with a certificate containing a static DH key, signed with RSA- 2453 SHA1. 2455 New ClientCertificateType values are assigned by IANA as described in 2456 Section 12. 2458 Note: Values listed as RESERVED may not be used. They were used in 2459 SSLv3. 2461 Note: It is a fatal handshake_failure alert for an anonymous server 2462 to request client authentication. 2464 7.3.7. Server Certificate Verify 2466 When this message will be sent: 2468 This message is used to provide explicit proof that the server 2469 possesses the private key corresponding to its certificate. 2470 certificate and also provides integrity for the handshake up to 2471 this point. This message is only sent when the server is 2472 authenticated via a certificate. When sent, it MUST be the last 2473 server handshake message prior to the Finished. 2475 Structure of this message: 2477 struct { 2478 digitally-signed struct { 2479 opaque handshake_messages_hash[hash_length]; 2480 } 2481 } CertificateVerify; 2483 Here handshake_messages_hash is a digest of all handshake messages 2484 sent or received, starting at ClientHello and up to, but not 2485 including, this message, including the type and length fields of 2486 the handshake messages. This is a digest of the concatenation of 2487 all the Handshake structures (as defined in Section 7.3) exchanged 2488 thus far. For the PRF defined in Section 5, the digest MUST be 2489 the Hash used as the basis for the PRF. Any cipher suite which 2490 defines a different PRF MUST also define the Hash to use in this 2491 computation. Note that this is the same running hash that is used 2492 in the Finished message Section 7.3.8. 2494 The context string for the signature is "TLS 1.3, server 2495 CertificateVerify". A hash of the handshake messages is signed 2496 rather than the messages themselves because the digitally-signed 2497 format requires padding and context bytes at the beginning of the 2498 input. Thus, by signing a digest of the messages, an 2499 implementation need only maintain one running hash per hash type 2500 for CertificateVerify, Finished and other messages. 2502 If the client has offered the "signature_algorithms" extension, 2503 the signature algorithm and hash algorithm MUST be a pair listed 2504 in that extension. Note that there is a possibility for 2505 inconsistencies here. For instance, the client might offer 2506 DHE_DSS key exchange but omit any DSA pairs from its 2507 "signature_algorithms" extension. In order to negotiate 2508 correctly, the server MUST check any candidate cipher suites 2509 against the "signature_algorithms" extension before selecting 2510 them. This is somewhat inelegant but is a compromise designed to 2511 minimize changes to the original cipher suite design. 2513 In addition, the hash and signature algorithms MUST be compatible 2514 with the key in the server's end-entity certificate. RSA keys MAY 2515 be used with any permitted hash algorithm, subject to restrictions 2516 in the certificate, if any. 2518 Because DSA signatures do not contain any secure indication of 2519 hash algorithm, there is a risk of hash substitution if multiple 2520 hashes may be used with any key. Currently, DSA [DSS] may only be 2521 used with SHA-1. Future revisions of DSS [DSS-3] are expected to 2522 allow the use of other digest algorithms with DSA, as well as 2523 guidance as to which digest algorithms should be used with each 2524 key size. In addition, future revisions of [RFC3280] may specify 2525 mechanisms for certificates to indicate which digest algorithms 2526 are to be used with DSA. [[TODO: Update this to deal with DSS-3 2527 and DSS-4. https://github.com/tlswg/tls13-spec/issues/59]] 2529 7.3.8. Server Finished 2531 When this message will be sent: 2533 The Server's Finished message is the final message sent by the 2534 server and indicates that the key exchange and authentication 2535 processes were successful. 2537 Meaning of this message: 2539 Recipients of Finished messages MUST verify that the contents are 2540 correct. Once a side has sent its Finished message and received 2541 and validated the Finished message from its peer, it may begin to 2542 send and receive application data over the connection. This data 2543 will be protected under keys derived from the hs_master_secret 2544 (see Section 8. 2546 Structure of this message: 2548 struct { 2549 opaque verify_data[verify_data_length]; 2550 } Finished; 2552 verify_data 2553 PRF(hs_master_secret, finished_label, Hash(handshake_messages)) 2554 [0..verify_data_length-1]; 2556 finished_label 2557 For Finished messages sent by the client, the string 2558 "client finished". For Finished messages sent by the server, 2559 the string "server finished". 2561 Hash denotes a Hash of the handshake messages. For the PRF 2562 defined in Section 5, the Hash MUST be the Hash used as the basis 2563 for the PRF. Any cipher suite which defines a different PRF MUST 2564 also define the Hash to use in the Finished computation. 2566 In previous versions of TLS, the verify_data was always 12 octets 2567 long. In the current version of TLS, it depends on the cipher 2568 suite. Any cipher suite which does not explicitly specify 2569 verify_data_length has a verify_data_length equal to 12. This 2570 includes all existing cipher suites. Note that this 2571 representation has the same encoding as with previous versions. 2573 Future cipher suites MAY specify other lengths but such length 2574 MUST be at least 12 bytes. 2576 handshake_messages 2577 All of the data from all messages in this handshake (not including 2578 any HelloRequest messages) up to, but not including, this message. 2579 This is only data visible at the handshake layer and does not 2580 include record layer headers. This is the concatenation of all 2581 the Handshake structures as defined in Section 7.3, exchanged thus 2582 far. 2584 The value handshake_messages includes all handshake messages starting 2585 at ClientHello up to, but not including, this Finished message. This 2586 may be different from handshake_messages in Section 7.3.7 or 2587 Section 7.3.10. Also, the handshake_messages for the Finished 2588 message sent by the client will be different from that for the 2589 Finished message sent by the server, because the one that is sent 2590 second will include the prior one. 2592 Note: Alerts and any other record types are not handshake messages 2593 and are not included in the hash computations. Also, HelloRequest 2594 messages are omitted from handshake hashes. 2596 7.3.9. Client Certificate 2598 When this message will be sent: 2600 This message is the first handshake message the client can send 2601 after receiving the server's Finished. This message is only sent 2602 if the server requests a certificate. If no suitable certificate 2603 is available, the client MUST send a certificate message 2604 containing no certificates. That is, the certificate_list 2605 structure has a length of zero. If the client does not send any 2606 certificates, the server MAY at its discretion either continue the 2607 handshake without client authentication, or respond with a fatal 2608 handshake_failure alert. Also, if some aspect of the certificate 2609 chain was unacceptable (e.g., it was not signed by a known, 2610 trusted CA), the server MAY at its discretion either continue the 2611 handshake (considering the client unauthenticated) or send a fatal 2612 alert. 2614 Client certificates are sent using the Certificate structure 2615 defined in Section 7.3.5. 2617 Meaning of this message: 2619 This message conveys the client's certificate chain to the server; 2620 the server will use it when verifying the CertificateVerify 2621 message (when the client authentication is based on signing) or 2622 calculating the premaster secret (for non-ephemeral Diffie- 2623 Hellman). The certificate MUST be appropriate for the negotiated 2624 cipher suite's key exchange algorithm, and any negotiated 2625 extensions. 2627 In particular: 2629 - The certificate type MUST be X.509v3, unless explicitly negotiated 2630 otherwise (e.g., [RFC5081]). 2632 - The end-entity certificate's public key (and associated 2633 restrictions) has to be compatible with the certificate types 2634 listed in CertificateRequest: 2636 Client Cert. Type Certificate Key Type 2638 rsa_sign RSA public key; the certificate MUST allow the 2639 key to be used for signing with the signature 2640 scheme and hash algorithm that will be 2641 employed in the certificate verify message. 2643 dss_sign DSA public key; the certificate MUST allow the 2644 key to be used for signing with the hash 2645 algorithm that will be employed in the 2646 certificate verify message. 2648 ecdsa_sign ECDSA-capable public key; the certificate MUST 2649 allow the key to be used for signing with the 2650 hash algorithm that will be employed in the 2651 certificate verify message; the public key 2652 MUST use a curve and point format supported by 2653 the server. 2655 rsa_fixed_dh Diffie-Hellman public key; MUST use the same 2656 dss_fixed_dh parameters as server's key. 2658 rsa_fixed_ecdh ECDH-capable public key; MUST use the 2659 ecdsa_fixed_ecdh same curve as the server's key, and MUST use a 2660 point format supported by the server. 2662 - If the certificate_authorities list in the certificate request 2663 message was non-empty, one of the certificates in the certificate 2664 chain SHOULD be issued by one of the listed CAs. 2666 - The certificates MUST be signed using an acceptable hash/ 2667 signature algorithm pair, as described in Section 7.3.6. Note 2668 that this relaxes the constraints on certificate-signing 2669 algorithms found in prior versions of TLS. 2671 Note that, as with the server certificate, there are certificates 2672 that use algorithms/algorithm combinations that cannot be currently 2673 used with TLS. 2675 7.3.10. Client Certificate Verify 2677 When this message will be sent: 2679 This message is used to provide explicit verification of a client 2680 certificate. This message is only sent following a client 2681 certificate that has signing capability (i.e., all certificates 2682 except those containing fixed Diffie-Hellman parameters). When 2683 sent, it MUST immediately follow the client's Certificate message. 2684 The contents of the message are computed as described in 2685 Section 7.3.7, except that the context string is "TLS 1.3, client 2686 CertificateVerify". 2688 The hash and signature algorithms used in the signature MUST be 2689 one of those present in the supported_signature_algorithms field 2690 of the CertificateRequest message. In addition, the hash and 2691 signature algorithms MUST be compatible with the key in the 2692 client's end-entity certificate. RSA keys MAY be used with any 2693 permitted hash algorithm, subject to restrictions in the 2694 certificate, if any. 2696 Because DSA signatures do not contain any secure indication of 2697 hash algorithm, there is a risk of hash substitution if multiple 2698 hashes may be used with any key. Currently, DSA [DSS] may only be 2699 used with SHA-1. Future revisions of DSS [DSS-3] are expected to 2700 allow the use of other digest algorithms with DSA, as well as 2701 guidance as to which digest algorithms should be used with each 2702 key size. In addition, future revisions of [RFC3280] may specify 2703 mechanisms for certificates to indicate which digest algorithms 2704 are to be used with DSA. 2706 8. Cryptographic Computations 2708 In order to begin connection protection, the TLS Record Protocol 2709 requires specification of a suite of algorithms, a master secret, and 2710 the client and server random values. The authentication, key 2711 agreement, and record protection algorithms are determined by the 2712 cipher_suite selected by the server and revealed in the ServerHello 2713 message. The random values are exchanged in the hello messages. All 2714 that remains is to calculate the master secret. 2716 8.1. Computing the Master Secret 2718 The pre_master_secret is used to generate a series of master secret 2719 values, as shown in the following diagram and described below. 2721 Premaster Secret <---------+ 2722 | | 2723 PRF | 2724 | | 2725 v | 2726 Handshake <-PRF- Handshake | 2727 Traffic Keys Master Secret | 2728 | | Via 2729 | | Session 2730 +----------+----------+ | Cache 2731 | | | 2732 PRF PRF | 2733 | | | 2734 v v | 2735 Application <-PRF- Master Resumption | 2736 Traffic Keys Secret Premaster --+ 2737 Secret 2739 First, as soon as the ClientKeyShare and ServerKeyShare messages have 2740 been exchanged, the client and server each use the unauthenticated 2741 key shares to generate a master secret which is used for the 2742 protection of the remaining handshake records. Specifically, they 2743 generate: 2745 hs_master_secret = PRF(pre_master_secret, "handshake master secret", 2746 session_hash) 2747 [0..47]; 2749 During resumption, the premaster secret is initialized with the 2750 "resumption premaster secret", rather than using the values from the 2751 ClientKeyShare/ServerKeyShare exchange. 2753 This master secret value is used to generate the record protection 2754 keys used for the handshake, as described in Section 6.3. It is also 2755 used with TLS Exporters [RFC5705]. 2757 Once the hs_master_secret has been computed, the premaster secret 2758 SHOULD be deleted from memory. 2760 Once the last non-Finished message has been sent, the client and 2761 server then compute the master secret which will be used for the 2762 remainder of the session: 2764 master_secret = PRF(hs_master_secret, "extended master secret", 2765 session_hash) 2766 [0..47]; 2768 If the server does not request client authentication, the master 2769 secret can be computed at the time that the server sends its 2770 Finished, thus allowing the server to send traffic on its first 2771 flight (see [TODO] for security considerations on this practice.) If 2772 the server requests client authentication, this secret can be 2773 computed after the client's Certificate and CertificateVerify have 2774 been sent, or, if the client refuses client authentication, after the 2775 client's empty Certificate message has been sent. 2777 For full handshakes, each side also derives a new secret which will 2778 be used as the premaster_secret for future resumptions of the newly 2779 established session. This is computed as: 2781 resumption_premaster_secret = PRF(hs_master_secret, 2782 "resumption premaster secret", 2783 session_hash) 2784 [0..47]; 2786 The session_hash value is a running hash of the handshake as defined 2787 in Section 8.1.1. Thus, the hs_master_secret is generated using a 2788 different session_hash from the other two secrets. 2790 All master secrets are always exactly 48 bytes in length. The length 2791 of the premaster secret will vary depending on key exchange method. 2793 8.1.1. The Session Hash 2795 When a handshake takes place, we define 2797 session_hash = Hash(handshake_messages) 2799 where "handshake_messages" refers to all handshake messages sent or 2800 received, starting at client hello up to the present time, with the 2801 exception of the Finished message, including the type and length 2802 fields of the handshake messages. This is the concatenation of all 2803 the exchanged Handshake structures. 2805 For concreteness, at the point where the handshake master secret is 2806 derived, the session hash includes the ClientHello, ClientKeyShare, 2807 ServerHello, and ServerKeyShare, and HelloRetryRequest (if any) 2808 (though see [https://github.com/tlswg/tls13-spec/issues/104]). At 2809 the point where the master secret is derived, it includes every 2810 handshake message, with the exception of the Finished messages. Note 2811 that if client authentication is not used, then the session hash is 2812 complete at the point when the server has sent its first flight. 2813 Otherwise, it is only complete when the client has sent its first 2814 flight, as it covers the client's Certificate and CertificateVerify. 2816 8.1.2. Diffie-Hellman 2818 A conventional Diffie-Hellman computation is performed. The 2819 negotiated key (Z) is used as the pre_master_secret, and is converted 2820 into the master_secret, as specified above. Leading bytes of Z that 2821 contain all zero bits are stripped before it is used as the 2822 pre_master_secret. 2824 Note: Diffie-Hellman parameters are specified by the server and may 2825 be either ephemeral or contained within the server's certificate. 2827 8.1.3. Elliptic Curve Diffie-Hellman 2829 All ECDH calculations (including parameter and key generation as well 2830 as the shared secret calculation) are performed according to [6] 2831 using the ECKAS-DH1 scheme with the identity map as key derivation 2832 function (KDF), so that the premaster secret is the x-coordinate of 2833 the ECDH shared secret elliptic curve point represented as an octet 2834 string. Note that this octet string (Z in IEEE 1363 terminology) as 2835 output by FE2OSP, the Field Element to Octet String Conversion 2836 Primitive, has constant length for any given field; leading zeros 2837 found in this octet string MUST NOT be truncated. 2839 (Note that this use of the identity KDF is a technicality. The 2840 complete picture is that ECDH is employed with a non-trivial KDF 2841 because TLS does not directly use the premaster secret for anything 2842 other than for computing the master secret.) 2844 9. Mandatory Cipher Suites 2846 In the absence of an application profile standard specifying 2847 otherwise, a TLS-compliant application MUST implement the cipher 2848 suite TODO:Needs to be selected [1]. (See Appendix A.5 for the 2849 definition). 2851 10. Application Data Protocol 2853 Application data messages are carried by the record layer and are 2854 fragmented and encrypted based on the current connection state. The 2855 messages are treated as transparent data to the record layer. 2857 11. Security Considerations 2859 Security issues are discussed throughout this memo, especially in 2860 Appendices D, E, and F. 2862 12. IANA Considerations 2864 [[TODO: Update https://github.com/tlswg/tls13-spec/issues/62]] 2866 This document uses several registries that were originally created in 2867 [RFC4346]. IANA has updated these to reference this document. The 2868 registries and their allocation policies (unchanged from [RFC4346]) 2869 are listed below. 2871 - TLS ClientCertificateType Identifiers Registry: Future values in 2872 the range 0-63 (decimal) inclusive are assigned via Standards 2873 Action [RFC2434]. Values in the range 64-223 (decimal) inclusive 2874 are assigned via Specification Required [RFC2434]. Values from 2875 224-255 (decimal) inclusive are reserved for Private Use 2876 [RFC2434]. 2878 - TLS Cipher Suite Registry: Future values with the first byte in 2879 the range 0-191 (decimal) inclusive are assigned via Standards 2880 Action [RFC2434]. Values with the first byte in the range 192-254 2881 (decimal) are assigned via Specification Required [RFC2434]. 2882 Values with the first byte 255 (decimal) are reserved for Private 2883 Use [RFC2434]. 2885 - TLS ContentType Registry: Future values are allocated via 2886 Standards Action [RFC2434]. 2888 - TLS Alert Registry: Future values are allocated via Standards 2889 Action [RFC2434]. 2891 - TLS HandshakeType Registry: Future values are allocated via 2892 Standards Action [RFC2434]. 2894 This document also uses a registry originally created in [RFC4366]. 2895 IANA has updated it to reference this document. The registry and its 2896 allocation policy (unchanged from [RFC4366]) is listed below: 2898 - TLS ExtensionType Registry: Future values are allocated via IETF 2899 Consensus [RFC2434]. IANA has updated this registry to include 2900 the signature_algorithms extension and its corresponding value 2901 (see Section 7.3.2.5). 2903 This document also uses two registries originally created in 2904 [RFC4492]. IANA [should update/has updated] it to reference this 2905 document. The registries and their allocation policies are listed 2906 below. 2908 - TLS NamedCurve registry: Future values are allocated via IETF 2909 Consensus [RFC2434]. 2911 - TLS ECPointFormat Registry: Future values are allocated via IETF 2912 Consensus [RFC2434]. 2914 In addition, this document defines two new registries to be 2915 maintained by IANA: 2917 - TLS SignatureAlgorithm Registry: The registry has been initially 2918 populated with the values described in Section 7.3.2.5.1. Future 2919 values in the range 0-63 (decimal) inclusive are assigned via 2920 Standards Action [RFC2434]. Values in the range 64-223 (decimal) 2921 inclusive are assigned via Specification Required [RFC2434]. 2922 Values from 224-255 (decimal) inclusive are reserved for Private 2923 Use [RFC2434]. 2925 - TLS HashAlgorithm Registry: The registry has been initially 2926 populated with the values described in Section 7.3.2.5.1. Future 2927 values in the range 0-63 (decimal) inclusive are assigned via 2928 Standards Action [RFC2434]. Values in the range 64-223 (decimal) 2929 inclusive are assigned via Specification Required [RFC2434]. 2930 Values from 224-255 (decimal) inclusive are reserved for Private 2931 Use [RFC2434]. 2933 13. References 2935 13.1. Normative References 2937 [AES] National Institute of Standards and Technology, 2938 "Specification for the Advanced Encryption Standard 2939 (AES)", NIST FIPS 197, November 2001. 2941 [DSS] National Institute of Standards and Technology, U.S. 2942 Department of Commerce, "Digital Signature Standard", NIST 2943 FIPS PUB 186-2, 2000. 2945 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2946 April 1992. 2948 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2949 Hashing for Message Authentication", RFC 2104, February 2950 1997. 2952 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2953 Requirement Levels", BCP 14, RFC 2119, March 1997. 2955 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2956 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2957 October 1998. 2959 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 2960 X.509 Public Key Infrastructure Certificate and 2961 Certificate Revocation List (CRL) Profile", RFC 3280, 2962 April 2002. 2964 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2965 Standards (PKCS) #1: RSA Cryptography Specifications 2966 Version 2.1", RFC 3447, February 2003. 2968 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 2969 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 2970 August 2008. 2972 [SCH] Schneier, B., "Applied Cryptography: Protocols, 2973 Algorithms, and Source Code in C, 2nd ed.", 1996. 2975 [SHS] National Institute of Standards and Technology, U.S. 2976 Department of Commerce, "Secure Hash Standard", NIST FIPS 2977 PUB 180-2, August 2002. 2979 [TRIPLEDES] 2980 National Institute of Standards and Technology, 2981 "Recommendation for the Triple Data Encryption Algorithm 2982 (TDEA) Block Cipher", NIST Special Publication 800-67, May 2983 2004. 2985 [X680] ITU-T, "Information technology - Abstract Syntax Notation 2986 One (ASN.1): Specification of basic notation", ISO/IEC 2987 8824-1:2002, 2002. 2989 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 2990 Specification of Basic Encoding Rules (BER), Canonical 2991 Encoding Rules (CER) and Distinguished Encoding Rules 2992 (DER)", ISO/IEC 8825-1:2002, 2002. 2994 [X962] ANSI, "Public Key Cryptography For The Financial Services 2995 Industry: The Elliptic Curve Digital Signature Algorithm 2996 (ECDSA)", ANSI X9.62, 1998. 2998 13.2. Informative References 3000 [BLEI] Bleichenbacher, D., "Chosen Ciphertext Attacks against 3001 Protocols Based on RSA Encryption Standard PKCS", CRYPTO98 3002 LNCS vol. 1462, pages: 1-12, 1998, Advances in Cryptology, 3003 1998. 3005 [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: 3006 Problems and Countermeasures", May 2004, 3007 . 3009 [CCM] "NIST Special Publication 800-38C: The CCM Mode for 3010 Authentication and Confidentiality", May 2004, 3011 . 3014 [DES] "Data Encryption Standard (DES)", NIST FIPS PUB 46-3, 3015 October 1999. 3017 [DSS-3] National Institute of Standards and Technology, U.S., 3018 "Digital Signature Standard", NIST FIPS PUB 186-3 Draft, 3019 2006. 3021 [ECDSA] American National Standards Institute, "Public Key 3022 Cryptography for the Financial Services Industry: The 3023 Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI 3024 ANS X9.62-2005, November 2005. 3026 [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication 3027 for Protecting Communications (Or: How Secure is SSL?)", 3028 2001. 3030 [FI06] "Bleichenbacher's RSA signature forgery based on 3031 implementation error", August 2006, . 3034 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 3035 Operation: Galois/Counter Mode (GCM) and GMAC", NIST 3036 Special Publication 800-38D, November 2007. 3038 [I-D.ietf-tls-negotiated-ff-dhe] 3039 Gillmor, D., "Negotiated Finite Field Diffie-Hellman 3040 Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- 3041 ff-dhe-05 (work in progress), December 2014. 3043 [I-D.ietf-tls-session-hash] 3044 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 3045 A., and M. Ray, "Transport Layer Security (TLS) Session 3046 Hash and Extended Master Secret Extension", draft-ietf- 3047 tls-session-hash-03 (work in progress), November 2014. 3049 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate 3050 Syntax Standard, version 1.5", November 1993. 3052 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message 3053 Syntax Standard, version 1.5", November 1993. 3055 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 3056 793, September 1981. 3058 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 3059 RFC 1948, May 1996. 3061 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 3062 RFC 2246, January 1999. 3064 [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" 3065 Attacks on the Diffie-Hellman Key Agreement Method for S/ 3066 MIME", RFC 2785, March 2000. 3068 [RFC3268] Chown, P., "Advanced Encryption Standard (AES) 3069 Ciphersuites for Transport Layer Security (TLS)", RFC 3070 3268, June 2002. 3072 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 3073 Diffie-Hellman groups for Internet Key Exchange (IKE)", 3074 RFC 3526, May 2003. 3076 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 3077 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 3078 RFC 3766, April 2004. 3080 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3081 Requirements for Security", BCP 106, RFC 4086, June 2005. 3083 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 3084 2005. 3086 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 3087 4303, December 2005. 3089 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 3090 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 3091 December 2005. 3093 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 3094 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 3096 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 3097 and T. Wright, "Transport Layer Security (TLS) 3098 Extensions", RFC 4366, April 2006. 3100 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 3101 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 3102 for Transport Layer Security (TLS)", RFC 4492, May 2006. 3104 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 3105 STD 67, RFC 4506, May 2006. 3107 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 3108 Layer Security (TLS) Authentication", RFC 5081, November 3109 2007. 3111 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 3112 Encryption", RFC 5116, January 2008. 3114 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 3115 Layer Security (TLS)", RFC 5705, March 2010. 3117 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 3118 Obtaining Digital Signatures and Public-Key 3119 Cryptosystems", Communications of the ACM v. 21, n. 2, pp. 3120 120-126., February 1978. 3122 [SSL2] Netscape Communications Corp., "The SSL Protocol", 3123 February 1995. 3125 [SSL3] Freier, A., Karlton, P., and P. Kocher, "The SSL 3.0 3126 Protocol", November 1996. 3128 [TIMING] Boneh, D. and D. Brumley, "Remote timing attacks are 3129 practical", USENIX Security Symposium, 2003. 3131 [TLSEXT] Eastlake 3rd, D., "Transport Layer Security (TLS) 3132 Extensions: Extension Definitions", February 2008. 3134 [X501] "Information Technology - Open Systems Interconnection - 3135 The Directory: Models", ITU-T X.501, 1993. 3137 13.3. URIs 3139 [1] https://github.com/tlswg/tls13-spec/issues/32 3141 [2] mailto:tls@ietf.org 3143 Appendix A. Protocol Data Structures and Constant Values 3145 This section describes protocol types and constants. 3147 [[TODO: Clean this up to match the in-text description.]] 3149 A.1. Record Layer 3151 struct { 3152 uint8 major; 3153 uint8 minor; 3154 } ProtocolVersion; 3156 ProtocolVersion version = { 3, 4 }; /* TLS v1.3*/ 3158 enum { 3159 change_cipher_spec(20), alert(21), handshake(22), 3160 application_data(23), (255) 3161 } ContentType; 3163 struct { 3164 ContentType type; 3165 ProtocolVersion version; 3166 uint16 length; 3167 opaque fragment[TLSPlaintext.length]; 3168 } TLSPlaintext; 3170 struct { 3171 ContentType type; 3172 ProtocolVersion version; 3173 uint16 length; 3174 opaque nonce_explicit[SecurityParameters.record_iv_length]; 3175 aead-ciphered struct { 3176 opaque content[TLSPlaintext.length]; 3177 } fragment; 3178 } TLSCiphertext; 3180 A.2. Change Cipher Specs Message 3182 struct { 3183 enum { change_cipher_spec(1), (255) } type; 3184 } ChangeCipherSpec; 3186 A.3. Alert Messages 3187 enum { warning(1), fatal(2), (255) } AlertLevel; 3189 enum { 3190 close_notify(0), 3191 unexpected_message(10), 3192 bad_record_mac(20), 3193 decryption_failed_RESERVED(21), 3194 record_overflow(22), 3195 decompression_failure_RESERVED(30), 3196 handshake_failure(40), 3197 no_certificate_RESERVED(41), 3198 bad_certificate(42), 3199 unsupported_certificate(43), 3200 certificate_revoked(44), 3201 certificate_expired(45), 3202 certificate_unknown(46), 3203 illegal_parameter(47), 3204 unknown_ca(48), 3205 access_denied(49), 3206 decode_error(50), 3207 decrypt_error(51), 3208 export_restriction_RESERVED(60), 3209 protocol_version(70), 3210 insufficient_security(71), 3211 internal_error(80), 3212 user_canceled(90), 3213 no_renegotiation(100), 3214 unsupported_extension(110), /* new */ 3215 (255) 3216 } AlertDescription; 3218 struct { 3219 AlertLevel level; 3220 AlertDescription description; 3221 } Alert; 3223 A.4. Handshake Protocol 3224 enum { 3225 reserved(0), client_hello(1), server_hello(2), 3226 client_key_share(5), hello_retry_request(6), 3227 server_key_share(7), certificate(11), reserved(12), 3228 certificate_request(13), certificate_verify(15), 3229 reserved(16), finished(20), (255) 3230 } HandshakeType; 3232 struct { 3233 HandshakeType msg_type; 3234 uint24 length; 3235 select (HandshakeType) { 3236 case hello_request: HelloRequest; 3237 case client_hello: ClientHello; 3238 case server_hello: ServerHello; 3239 case hello_retry_request: HelloRetryRequest; 3240 case certificate: Certificate; 3241 case server_key_share: ServerKeyShare; 3242 case certificate_request: CertificateRequest; 3243 case server_hello_done: ServerHelloDone; 3244 case certificate_verify: CertificateVerify; 3245 case client_key_share: ClientKeyShare; 3246 case finished: Finished; 3247 } body; 3248 } Handshake; 3250 A.4.1. Hello Messages 3252 struct { } HelloRequest; 3254 struct { 3255 opaque random_bytes[32]; 3256 } Random; 3258 opaque SessionID<0..32>; 3260 uint8 CipherSuite[2]; 3262 enum { null(0), (255) } CompressionMethod; 3264 struct { 3265 ProtocolVersion client_version; 3266 Random random; 3267 SessionID session_id; 3268 CipherSuite cipher_suites<2..2^16-2>; 3269 CompressionMethod compression_methods<1..2^8-1>; 3270 select (extensions_present) { 3271 case false: 3273 struct {}; 3274 case true: 3275 Extension extensions<0..2^16-1>; 3276 }; 3277 } ClientHello; 3279 struct { 3280 ProtocolVersion server_version; 3281 Random random; 3282 SessionID session_id; 3283 CipherSuite cipher_suite; 3284 select (extensions_present) { 3285 case false: 3286 struct {}; 3287 case true: 3288 Extension extensions<0..2^16-1>; 3289 }; 3290 } ServerHello; 3292 struct { 3293 ExtensionType extension_type; 3294 opaque extension_data<0..2^16-1>; 3295 } Extension; 3297 enum { 3298 signature_algorithms(13), (65535) 3299 } ExtensionType; 3301 enum{ 3302 none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), 3303 sha512(6), (255) 3304 } HashAlgorithm; 3305 enum { 3306 anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) 3307 } SignatureAlgorithm; 3309 struct { 3310 HashAlgorithm hash; 3311 SignatureAlgorithm signature; 3312 } SignatureAndHashAlgorithm; 3314 SignatureAndHashAlgorithm 3315 supported_signature_algorithms<2..2^16-2>; 3317 A.4.2. Server Authentication and Key Exchange Messages 3319 opaque ASN1Cert<2^24-1>; 3321 struct { 3322 ASN1Cert certificate_list<0..2^24-1>; 3323 } Certificate; 3325 struct { 3326 NamedGroup group; 3327 opaque key_exchange<1..2^16-1>; 3328 } ServerKeyShare; 3330 enum { 3331 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), 3332 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), 3333 fortezza_dms_RESERVED(20), 3334 (255) 3335 } ClientCertificateType; 3337 opaque DistinguishedName<1..2^16-1>; 3339 struct { 3340 ClientCertificateType certificate_types<1..2^8-1>; 3341 DistinguishedName certificate_authorities<0..2^16-1>; 3342 } CertificateRequest; 3344 struct { } ServerHelloDone; 3346 A.4.3. Client Authentication and Key Exchange Messages 3348 struct { 3349 ClientKeyShareOffer offers<0..2^16-1>; 3350 } ClientKeyShare; 3352 struct { 3353 NamedGroup group; 3354 opaque key_exchange<1..2^16-1>; 3355 } ClientKeyShareOffer; 3357 struct { 3358 digitally-signed struct { 3359 opaque handshake_messages_hash[hash_length]; 3360 } 3361 } CertificateVerify; 3363 The context string for the signature is "TLS 1.3, client 3364 CertificateVerify". 3366 A.4.4. Handshake Finalization Message 3368 struct { 3369 opaque verify_data[verify_data_length]; 3370 } Finished; 3372 A.5. The Cipher Suite 3374 The following values define the cipher suite codes used in the 3375 ClientHello and ServerHello messages. 3377 A cipher suite defines a cipher specification supported in TLS 3378 Version 1.2. 3380 TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a 3381 TLS connection during the first handshake on that channel, but MUST 3382 NOT be negotiated, as it provides no more protection than an 3383 unsecured connection. 3385 CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; 3387 The following cipher suite definitions, defined in {{RFC5288}, are 3388 used for server-authenticated (and optionally client-authenticated) 3389 Diffie-Hellman. DHE denotes ephemeral Diffie-Hellman, where the 3390 Diffie-Hellman parameters are signed by a signature-capable 3391 certificate, which has been signed by the CA. The signing algorithm 3392 used by the server is specified after the DHE component of the 3393 CipherSuite name. The server can request any signature-capable 3394 certificate from the client for client authentication. 3396 CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C} 3397 CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D} 3398 CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E} 3399 CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F} 3400 CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2} 3401 CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3} 3403 The following cipher suite definitions, defined in {{RFC5289}, are 3404 used for server-authenticated (and optionally client-authenticated) 3405 Elliptic Curve Diffie-Hellman. ECDHE denotes ephemeral Diffie- 3406 Hellman, where the Diffie-Hellman parameters are signed by a 3407 signature-capable certificate, which has been signed by the CA. The 3408 signing algorithm used by the server is specified after the DHE 3409 component of the CipherSuite name. The server can request any 3410 signature-capable certificate from the client for client 3411 authentication. 3413 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 = {0xC0,0x2B}; 3414 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x2C}; 3415 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 = {0xC0,0x2F}; 3416 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x30}; 3418 The following ciphers, defined in [RFC5288], are used for completely 3419 anonymous Diffie-Hellman communications in which neither party is 3420 authenticated. Note that this mode is vulnerable to man-in-the- 3421 middle attacks. Using this mode therefore is of limited use: These 3422 cipher suites MUST NOT be used by TLS 1.2 implementations unless the 3423 application layer has specifically requested to allow anonymous key 3424 exchange. (Anonymous key exchange may sometimes be acceptable, for 3425 example, to support opportunistic encryption when no set-up for 3426 authentication is in place, or when TLS is used as part of more 3427 complex security protocols that have other means to ensure 3428 authentication.) 3430 CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6} 3431 CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7} 3433 [[TODO: Add all the defined AEAD ciphers. This currently only lists 3434 GCM. https://github.com/tlswg/tls13-spec/issues/53]] Note that using 3435 non-anonymous key exchange without actually verifying the key 3436 exchange is essentially equivalent to anonymous key exchange, and the 3437 same precautions apply. While non-anonymous key exchange will 3438 generally involve a higher computational and communicational cost 3439 than anonymous key exchange, it may be in the interest of 3440 interoperability not to disable non-anonymous key exchange when the 3441 application layer is allowing anonymous key exchange. 3443 The PRFs SHALL be as follows: 3445 o For cipher suites ending with _SHA256, the PRF is the TLS PRF with 3446 SHA-256 as the hash function. 3448 o For cipher suites ending with _SHA384, the PRF is the TLS PRF with 3449 SHA-384 as the hash function. 3451 New cipher suite values are been assigned by IANA as described in 3452 Section 12. 3454 Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are 3455 reserved to avoid collision with Fortezza-based cipher suites in SSL 3456 3. 3458 A.6. The Security Parameters 3460 These security parameters are determined by the TLS Handshake 3461 Protocol and provided as parameters to the TLS record layer in order 3462 to initialize a connection state. SecurityParameters includes: 3464 enum { null(0), (255) } CompressionMethod; 3466 enum { server, client } ConnectionEnd; 3468 enum { tls_prf_sha256 } PRFAlgorithm; 3470 enum { aes_gcm } RecordProtAlgorithm; 3472 /* Other values may be added to the algorithms specified in 3473 PRFAlgorithm and RecordProtAlgorithm */ 3475 struct { 3476 ConnectionEnd entity; 3477 PRFAlgorithm prf_algorithm; 3478 RecordProtAlgorithm record_prot_algorithm; 3479 uint8 enc_key_length; 3480 uint8 block_length; 3481 uint8 fixed_iv_length; 3482 uint8 record_iv_length; 3483 opaque master_secret[48]; 3484 opaque client_random[32]; 3485 opaque server_random[32]; 3486 } SecurityParameters; 3488 A.7. Changes to RFC 4492 3490 RFC 4492 [RFC4492] adds Elliptic Curve cipher suites to TLS. This 3491 document changes some of the structures used in that document. This 3492 section details the required changes for implementors of both RFC 3493 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing 3494 RFC 4492 do not need to read this section. 3496 This document adds a "signature_algorithm" field to the digitally- 3497 signed element in order to identify the signature and digest 3498 algorithms used to create a signature. This change applies to 3499 digital signatures formed using ECDSA as well, thus allowing ECDSA 3500 signatures to be used with digest algorithms other than SHA-1, 3501 provided such use is compatible with the certificate and any 3502 restrictions imposed by future revisions of [RFC3280]. 3504 As described in Section 7.3.5 and Section 7.3.9, the restrictions on 3505 the signature algorithms used to sign certificates are no longer tied 3506 to the cipher suite (when used by the server) or the 3507 ClientCertificateType (when used by the client). Thus, the 3508 restrictions on the algorithm used to sign certificates specified in 3509 Sections 2 and 3 of RFC 4492 are also relaxed. As in this document, 3510 the restrictions on the keys in the end-entity certificate remain. 3512 Appendix B. Glossary 3514 Advanced Encryption Standard (AES) 3515 AES [AES] is a widely used symmetric encryption algorithm. AES is 3516 a block cipher with a 128-, 192-, or 256-bit keys and a 16-byte 3517 block size. TLS currently only supports the 128- and 256-bit key 3518 sizes. 3520 application protocol 3521 An application protocol is a protocol that normally layers 3522 directly on top of the transport layer (e.g., TCP/IP). Examples 3523 include HTTP, TELNET, FTP, and SMTP. 3525 asymmetric cipher 3526 See public key cryptography. 3528 authenticated encryption with additional data (AEAD) 3529 A symmetric encryption algorithm that simultaneously provides 3530 confidentiality and message integrity. 3532 authentication 3533 Authentication is the ability of one entity to determine the 3534 identity of another entity. 3536 certificate 3537 As part of the X.509 protocol (a.k.a. ISO Authentication 3538 framework), certificates are assigned by a trusted Certificate 3539 Authority and provide a strong binding between a party's identity 3540 or some other attributes and its public key. 3542 client 3543 The application entity that initiates a TLS connection to a 3544 server. This may or may not imply that the client initiated the 3545 underlying transport connection. The primary operational 3546 difference between the server and client is that the server is 3547 generally authenticated, while the client is only optionally 3548 authenticated. 3550 client write key 3551 The key used to protect data written by the client. 3553 connection 3554 A connection is a transport (in the OSI layering model definition) 3555 that provides a suitable type of service. For TLS, such 3556 connections are peer-to-peer relationships. The connections are 3557 transient. Every connection is associated with one session. 3559 Digital Signature Standard (DSS) 3560 A standard for digital signing, including the Digital Signing 3561 Algorithm, approved by the National Institute of Standards and 3562 Technology, defined in NIST FIPS PUB 186-2, "Digital Signature 3563 Standard", published January 2000 by the U.S. Department of 3564 Commerce [DSS]. A significant update [DSS-3] has been drafted and 3565 was published in March 2006. 3567 digital signatures 3568 Digital signatures utilize public key cryptography and one-way 3569 hash functions to produce a signature of the data that can be 3570 authenticated, and is difficult to forge or repudiate. 3572 handshake 3573 An initial negotiation between client and server that establishes 3574 the parameters of their transactions. 3576 Initialization Vector (IV) 3577 Some AEAD ciphers require an initialization vector to allow the 3578 cipher to safely protect multiple chunks of data with the same 3579 keying material. The size of the IV depends on the cipher suite. 3581 Message Authentication Code (MAC) 3582 A Message Authentication Code is a one-way hash computed from a 3583 message and some secret data. It is difficult to forge without 3584 knowing the secret data. Its purpose is to detect if the message 3585 has been altered. 3587 master secret 3588 Secure secret data used for generating keys and IVs. 3590 MD5 3591 MD5 [RFC1321] is a hashing function that converts an arbitrarily 3592 long data stream into a hash of fixed size (16 bytes). Due to 3593 significant progress in cryptanalysis, at the time of publication 3594 of this document, MD5 no longer can be considered a 'secure' 3595 hashing function. 3597 public key cryptography 3598 A class of cryptographic techniques employing two-key ciphers. 3599 Messages encrypted with the public key can only be decrypted with 3600 the associated private key. Conversely, messages signed with the 3601 private key can be verified with the public key. 3603 one-way hash function 3604 A one-way transformation that converts an arbitrary amount of data 3605 into a fixed-length hash. It is computationally hard to reverse 3606 the transformation or to find collisions. MD5 and SHA are 3607 examples of one-way hash functions. 3609 RSA 3610 A very widely used public key algorithm that can be used for 3611 either encryption or digital signing. [RSA] 3613 server 3614 The server is the application entity that responds to requests for 3615 connections from clients. See also "client". 3617 session 3618 A TLS session is an association between a client and a server. 3619 Sessions are created by the handshake protocol. Sessions define a 3620 set of cryptographic security parameters that can be shared among 3621 multiple connections. Sessions are used to avoid the expensive 3622 negotiation of new security parameters for each connection. 3624 session identifier 3625 A session identifier is a value generated by a server that 3626 identifies a particular session. 3628 server write key 3629 The key used to protect data written by the server. 3631 SHA 3632 The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2. It 3633 produces a 20-byte output. Note that all references to SHA 3634 (without a numerical suffix) actually use the modified SHA-1 3635 algorithm. 3637 SHA-256 3638 The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. 3639 It produces a 32-byte output. 3641 SSL 3642 Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on 3643 SSL Version 3.0. 3645 Transport Layer Security (TLS) 3646 This protocol; also, the Transport Layer Security working group of 3647 the Internet Engineering Task Force (IETF). See "Working Group 3648 Information" at the end of this document (see page 99). 3650 Appendix C. Cipher Suite Definitions 3652 Cipher Suite Key Record 3653 Exchange Protection PRF 3655 TLS_NULL_WITH_NULL_NULL NULL NULL_NULL N/A 3656 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DHE_RSA AES_128_GCM SHA256 3657 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 DHE_RSA AES_256_GCM SHA384 3658 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 DHE_DSS AES_128_GCM SHA256 3659 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 DHE_DSS AES_256_GCM SHA384 3660 TLS_DH_anon_WITH_AES_128_GCM_SHA256 DH_anon AES_128_GCM SHA256 3661 TLS_DH_anon_WITH_AES_256_GCM_SHA384 DH_anon AES_128_GCM SHA384 3663 Key Implicit IV Explicit IV 3664 Cipher Material Size Size 3665 ------------ -------- ---------- ----------- 3666 NULL 0 0 0 3667 AES_128_GCM 16 4 8 3668 AES_256_GCM 32 4 8 3670 Key Material 3671 The number of bytes from the key_block that are used for 3672 generating the write keys. 3674 Implicit IV Size 3675 The amount of data to be generated for the per-connection part of 3676 the initialization vector. This is equal to 3677 SecurityParameters.fixed_iv_length). 3679 Explicit IV Size 3680 The amount of data needed to be generated for the per-record part 3681 of the initialization vector. This is equal to 3682 SecurityParameters.record_iv_length). 3684 Appendix D. Implementation Notes 3686 The TLS protocol cannot prevent many common security mistakes. This 3687 section provides several recommendations to assist implementors. 3689 D.1. Random Number Generation and Seeding 3691 TLS requires a cryptographically secure pseudorandom number generator 3692 (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs 3693 based on secure hash operations, most notably SHA-1, are acceptable, 3694 but cannot provide more security than the size of the random number 3695 generator state. 3697 To estimate the amount of seed material being produced, add the 3698 number of bits of unpredictable information in each seed byte. For 3699 example, keystroke timing values taken from a PC compatible's 18.2 Hz 3700 timer provide 1 or 2 secure bits each, even though the total size of 3701 the counter value is 16 bits or more. Seeding a 128-bit PRNG would 3702 thus require approximately 100 such timer values. 3704 [RFC4086] provides guidance on the generation of random values. 3706 D.2. Certificates and Authentication 3708 Implementations are responsible for verifying the integrity of 3709 certificates and should generally support certificate revocation 3710 messages. Certificates should always be verified to ensure proper 3711 signing by a trusted Certificate Authority (CA). The selection and 3712 addition of trusted CAs should be done very carefully. Users should 3713 be able to view information about the certificate and root CA. 3715 D.3. Cipher Suites 3717 TLS supports a range of key sizes and security levels, including some 3718 that provide no or minimal security. A proper implementation will 3719 probably not support many cipher suites. For instance, anonymous 3720 Diffie-Hellman is strongly discouraged because it cannot prevent man- 3721 in-the-middle attacks. Applications should also enforce minimum and 3722 maximum key sizes. For example, certificate chains containing 512- 3723 bit RSA keys or signatures are not appropriate for high-security 3724 applications. 3726 D.4. Implementation Pitfalls 3728 Implementation experience has shown that certain parts of earlier TLS 3729 specifications are not easy to understand, and have been a source of 3730 interoperability and security problems. Many of these areas have 3731 been clarified in this document, but this appendix contains a short 3732 list of the most important things that require special attention from 3733 implementors. 3735 TLS protocol issues: 3737 - Do you correctly handle handshake messages that are fragmented to 3738 multiple TLS records (see Section 6.2.1)? Including corner cases 3739 like a ClientHello that is split to several small fragments? Do 3740 you fragment handshake messages that exceed the maximum fragment 3741 size? In particular, the certificate and certificate request 3742 handshake messages can be large enough to require fragmentation. 3744 - Do you ignore the TLS record layer version number in all TLS 3745 records before ServerHello (see Appendix E.1)? 3747 - Do you handle TLS extensions in ClientHello correctly, including 3748 omitting the extensions field completely? 3750 - When the server has requested a client certificate, but no 3751 suitable certificate is available, do you correctly send an empty 3752 Certificate message, instead of omitting the whole message (see 3753 Section 7.3.9)? 3755 Cryptographic details: 3757 - What countermeasures do you use to prevent timing attacks against 3758 RSA signing operations [TIMING]. 3760 - When verifying RSA signatures, do you accept both NULL and missing 3761 parameters (see Section 4.7)? Do you verify that the RSA padding 3762 doesn't have additional data after the hash value? [FI06] 3764 - When using Diffie-Hellman key exchange, do you correctly strip 3765 leading zero bytes from the negotiated key (see Section 8.1.2)? 3767 - Does your TLS client check that the Diffie-Hellman parameters sent 3768 by the server are acceptable (see Appendix F.1.1.2)? 3770 - Do you use a strong and, most importantly, properly seeded random 3771 number generator (see Appendix D.1) Diffie-Hellman private values, 3772 the DSA "k" parameter, and other security-critical values? 3774 Appendix E. Backward Compatibility 3776 E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 3778 [[TODO: Revise backward compatibility section for TLS 1.3. 3779 https://github.com/tlswg/tls13-spec/issues/54]] Since there are 3780 various versions of TLS (1.0, 1.1, 1.2, and any future versions) and 3781 SSL (2.0 and 3.0), means are needed to negotiate the specific 3782 protocol version to use. The TLS protocol provides a built-in 3783 mechanism for version negotiation so as not to bother other protocol 3784 components with the complexities of version selection. 3786 TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use 3787 compatible ClientHello messages; thus, supporting all of them is 3788 relatively easy. Similarly, servers can easily handle clients trying 3789 to use future versions of TLS as long as the ClientHello format 3790 remains compatible, and the client supports the highest protocol 3791 version available in the server. 3793 A TLS 1.3 client who wishes to negotiate with such older servers will 3794 send a normal TLS 1.3 ClientHello, containing { 3, 4 } (TLS 1.3) in 3795 ClientHello.client_version. If the server does not support this 3796 version, it will respond with a ServerHello containing an older 3797 version number. If the client agrees to use this version, the 3798 negotiation will proceed as appropriate for the negotiated protocol. 3800 If the version chosen by the server is not supported by the client 3801 (or not acceptable), the client MUST send a "protocol_version" alert 3802 message and close the connection. 3804 If a TLS server receives a ClientHello containing a version number 3805 greater than the highest version supported by the server, it MUST 3806 reply according to the highest version supported by the server. 3808 A TLS server can also receive a ClientHello containing a version 3809 number smaller than the highest supported version. If the server 3810 wishes to negotiate with old clients, it will proceed as appropriate 3811 for the highest version supported by the server that is not greater 3812 than ClientHello.client_version. For example, if the server supports 3813 TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will 3814 proceed with a TLS 1.0 ServerHello. If server supports (or is 3815 willing to use) only versions greater than client_version, it MUST 3816 send a "protocol_version" alert message and close the connection. 3818 Whenever a client already knows the highest protocol version known to 3819 a server (for example, when resuming a session), it SHOULD initiate 3820 the connection in that native protocol. 3822 Note: some server implementations are known to implement version 3823 negotiation incorrectly. For example, there are buggy TLS 1.0 3824 servers that simply close the connection when the client offers a 3825 version newer than TLS 1.0. Also, it is known that some servers will 3826 refuse the connection if any TLS extensions are included in 3827 ClientHello. Interoperability with such buggy servers is a complex 3828 topic beyond the scope of this document, and may require multiple 3829 connection attempts by the client. 3831 Earlier versions of the TLS specification were not fully clear on 3832 what the record layer version number (TLSPlaintext.version) should 3833 contain when sending ClientHello (i.e., before it is known which 3834 version of the protocol will be employed). Thus, TLS servers 3835 compliant with this specification MUST accept any value {03,XX} as 3836 the record layer version number for ClientHello. 3838 TLS clients that wish to negotiate with older servers MAY send any 3839 value {03,XX} as the record layer version number. Typical values 3840 would be {03,00}, the lowest version number supported by the client, 3841 and the value of ClientHello.client_version. No single value will 3842 guarantee interoperability with all old servers, but this is a 3843 complex topic beyond the scope of this document. 3845 E.2. Compatibility with SSL 2.0 3847 TLS 1.2 clients that wish to support SSL 2.0 servers MUST send 3848 version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message 3849 MUST contain the same version number as would be used for ordinary 3850 ClientHello, and MUST encode the supported TLS cipher suites in the 3851 CIPHER-SPECS-DATA field as described below. 3853 Warning: The ability to send version 2.0 CLIENT-HELLO messages will 3854 be phased out with all due haste, since the newer ClientHello format 3855 provides better mechanisms for moving to newer versions and 3856 negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0. 3858 However, even TLS servers that do not support SSL 2.0 MAY accept 3859 version 2.0 CLIENT-HELLO messages. The message is presented below in 3860 sufficient detail for TLS server implementors; the true definition is 3861 still assumed to be [SSL2]. 3863 For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same 3864 way as a ClientHello with a "null" compression method and no 3865 extensions. Note that this message MUST be sent directly on the 3866 wire, not wrapped as a TLS record. For the purposes of calculating 3867 Finished and CertificateVerify, the msg_length field is not 3868 considered to be a part of the handshake message. 3870 uint8 V2CipherSpec[3]; 3871 struct { 3872 uint16 msg_length; 3873 uint8 msg_type; 3874 Version version; 3875 uint16 cipher_spec_length; 3876 uint16 session_id_length; 3877 uint16 challenge_length; 3878 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; 3879 opaque session_id[V2ClientHello.session_id_length]; 3880 opaque challenge[V2ClientHello.challenge_length; 3881 } V2ClientHello; 3883 msg_length 3884 The highest bit MUST be 1; the remaining bits contain the length 3885 of the following data in bytes. 3887 msg_type 3888 This field, in conjunction with the version field, identifies a 3889 version 2 ClientHello message. The value MUST be 1. 3891 version 3892 Equal to ClientHello.client_version. 3894 cipher_spec_length 3895 This field is the total length of the field cipher_specs. It 3896 cannot be zero and MUST be a multiple of the V2CipherSpec length 3897 (3). 3899 session_id_length 3900 This field MUST have a value of zero for a client that claims to 3901 support TLS 1.2. 3903 challenge_length 3904 The length in bytes of the client's challenge to the server to 3905 authenticate itself. Historically, permissible values are between 3906 16 and 32 bytes inclusive. When using the SSLv2 backward- 3907 compatible handshake the client SHOULD use a 32-byte challenge. 3909 cipher_specs 3910 This is a list of all CipherSpecs the client is willing and able 3911 to use. In addition to the 2.0 cipher specs defined in [SSL2], 3912 this includes the TLS cipher suites normally sent in 3913 ClientHello.cipher_suites, with each cipher suite prefixed by a 3914 zero byte. For example, the TLS cipher suite {0x00,0x0A} would be 3915 sent as {0x00,0x00,0x0A}. 3917 session_id 3918 This field MUST be empty. 3920 challenge 3921 Corresponds to ClientHello.random. If the challenge length is 3922 less than 32, the TLS server will pad the data with leading (note: 3923 not trailing) zero bytes to make it 32 bytes long. 3925 Note: Requests to resume a TLS session MUST use a TLS client hello. 3927 E.3. Avoiding Man-in-the-Middle Version Rollback 3929 When TLS clients fall back to Version 2.0 compatibility mode, they 3930 MUST use special PKCS#1 block formatting. This is done so that TLS 3931 servers will reject Version 2.0 sessions with TLS-capable clients. 3933 When a client negotiates SSL 2.0 but also supports TLS, it MUST set 3934 the right-hand (least-significant) 8 random bytes of the PKCS padding 3935 (not including the terminal null of the padding) for the RSA 3936 encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY 3937 to 0x03 (the other padding bytes are random). 3939 When a TLS-capable server negotiates SSL 2.0 it SHOULD, after 3940 decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding 3941 bytes are 0x03. If they are not, the server SHOULD generate a random 3942 value for SECRET-KEY-DATA, and continue the handshake (which will 3943 eventually fail since the keys will not match). Note that reporting 3944 the error situation to the client could make the server vulnerable to 3945 attacks described in [BLEI]. 3947 Appendix F. Security Analysis 3949 The TLS protocol is designed to establish a secure connection between 3950 a client and a server communicating over an insecure channel. This 3951 document makes several traditional assumptions, including that 3952 attackers have substantial computational resources and cannot obtain 3953 secret information from sources outside the protocol. Attackers are 3954 assumed to have the ability to capture, modify, delete, replay, and 3955 otherwise tamper with messages sent over the communication channel. 3956 This appendix outlines how TLS has been designed to resist a variety 3957 of attacks. 3959 F.1. Handshake Protocol 3961 The handshake protocol is responsible for selecting a cipher spec and 3962 generating a master secret, which together comprise the primary 3963 cryptographic parameters associated with a secure session. The 3964 handshake protocol can also optionally authenticate parties who have 3965 certificates signed by a trusted certificate authority. 3967 F.1.1. Authentication and Key Exchange 3969 TLS supports three authentication modes: authentication of both 3970 parties, server authentication with an unauthenticated client, and 3971 total anonymity. Whenever the server is authenticated, the channel 3972 is secure against man-in-the-middle attacks, but completely anonymous 3973 sessions are inherently vulnerable to such attacks. Anonymous 3974 servers cannot authenticate clients. If the server is authenticated, 3975 its certificate message must provide a valid certificate chain 3976 leading to an acceptable certificate authority. Similarly, 3977 authenticated clients must supply an acceptable certificate to the 3978 server. Each party is responsible for verifying that the other's 3979 certificate is valid and has not expired or been revoked. 3981 The general goal of the key exchange process is to create a 3982 pre_master_secret known to the communicating parties and not to 3983 attackers. The pre_master_secret will be used to generate the 3984 master_secret (see Section 8.1). The master_secret is required to 3985 generate the Finished messages and record protection keys (see 3986 Section 7.3.8 and Section 6.3). By sending a correct Finished 3987 message, parties thus prove that they know the correct 3988 pre_master_secret. 3990 F.1.1.1. Anonymous Key Exchange 3992 Completely anonymous sessions can be established using Diffie-Hellman 3993 for key exchange. The server's public parameters are contained in 3994 the server key share message, and the client's are sent in the client 3995 key share message. Eavesdroppers who do not know the private values 3996 should not be able to find the Diffie-Hellman result (i.e., the 3997 pre_master_secret). 3999 Warning: Completely anonymous connections only provide protection 4000 against passive eavesdropping. Unless an independent tamper-proof 4001 channel is used to verify that the Finished messages were not 4002 replaced by an attacker, server authentication is required in 4003 environments where active man-in-the-middle attacks are a concern. 4005 F.1.1.2. Diffie-Hellman Key Exchange with Authentication 4007 When Diffie-Hellman key exchange is used, the client and server use 4008 the client key exchange and server key exchange messages to send 4009 temporary Diffie-Hellman parameters. The signature in the 4010 certificate verify message (if present) covers the entire handshake 4011 up to that point and thus attests the certificate holder's desire to 4012 use the the ephemeral DHE keys. 4014 Peers SHOULD validate each other's public key Y (dh_Ys offered by the 4015 server or DH_Yc offered by the client) by ensuring that 1 < Y < p-1. 4016 This simple check ensures that the remote peer is properly behaved 4017 and isn't forcing the local system into a small subgroup. 4019 Additionally, using a fresh key for each handshake provides Perfect 4020 Forward Secrecy. Implementations SHOULD generate a new X for each 4021 handshake when using DHE cipher suites. 4023 F.1.2. Version Rollback Attacks 4025 Because TLS includes substantial improvements over SSL Version 2.0, 4026 attackers may try to make TLS-capable clients and servers fall back 4027 to Version 2.0. This attack can occur if (and only if) two TLS- 4028 capable parties use an SSL 2.0 handshake. 4030 Although the solution using non-random PKCS #1 block type 2 message 4031 padding is inelegant, it provides a reasonably secure way for Version 4032 3.0 servers to detect the attack. This solution is not secure 4033 against attackers who can brute-force the key and substitute a new 4034 ENCRYPTED-KEY-DATA message containing the same key (but with normal 4035 padding) before the application-specified wait threshold has expired. 4036 Altering the padding of the least-significant 8 bytes of the PKCS 4037 padding does not impact security for the size of the signed hashes 4038 and RSA key lengths used in the protocol, since this is essentially 4039 equivalent to increasing the input block size by 8 bytes. 4041 F.1.3. Detecting Attacks Against the Handshake Protocol 4043 An attacker might try to influence the handshake exchange to make the 4044 parties select different encryption algorithms than they would 4045 normally choose. 4047 For this attack, an attacker must actively change one or more 4048 handshake messages. If this occurs, the client and server will 4049 compute different values for the handshake message hashes. As a 4050 result, the parties will not accept each others' Finished messages. 4051 Without the master_secret, the attacker cannot repair the Finished 4052 messages, so the attack will be discovered. 4054 F.1.4. Resuming Sessions 4056 When a connection is established by resuming a session, new 4057 ClientHello.random and ServerHello.random values are hashed with the 4058 session's master_secret. Provided that the master_secret has not 4059 been compromised and that the secure hash operations used to produce 4060 the record protection kayes are secure, the connection should be 4061 secure and effectively independent from previous connections. 4062 Attackers cannot use known keys to compromise the master_secret 4063 without breaking the secure hash operations. 4065 Sessions cannot be resumed unless both the client and server agree. 4066 If either party suspects that the session may have been compromised, 4067 or that certificates may have expired or been revoked, it should 4068 force a full handshake. An upper limit of 24 hours is suggested for 4069 session ID lifetimes, since an attacker who obtains a master_secret 4070 may be able to impersonate the compromised party until the 4071 corresponding session ID is retired. Applications that may be run in 4072 relatively insecure environments should not write session IDs to 4073 stable storage. 4075 F.2. Protecting Application Data 4077 The master_secret is hashed with the ClientHello.random and 4078 ServerHello.random to produce unique record protection secrets for 4079 each connection. 4081 Outgoing data is protected using an AEAD algorithm before 4082 transmission. The authentication data includes the sequence number, 4083 message type, message length, and the message contents. The message 4084 type field is necessary to ensure that messages intended for one TLS 4085 record layer client are not redirected to another. The sequence 4086 number ensures that attempts to delete or reorder messages will be 4087 detected. Since sequence numbers are 64 bits long, they should never 4088 overflow. Messages from one party cannot be inserted into the 4089 other's output, since they use independent keys. 4091 F.3. Denial of Service 4093 TLS is susceptible to a number of denial-of-service (DoS) attacks. 4094 In particular, an attacker who initiates a large number of TCP 4095 connections can cause a server to consume large amounts of CPU doing 4096 asymmetric crypto operations. However, because TLS is generally used 4097 over TCP, it is difficult for the attacker to hide his point of 4098 origin if proper TCP SYN randomization is used [RFC1948] by the TCP 4099 stack. 4101 Because TLS runs over TCP, it is also susceptible to a number of DoS 4102 attacks on individual connections. In particular, attackers can 4103 forge RSTs, thereby terminating connections, or forge partial TLS 4104 records, thereby causing the connection to stall. These attacks 4105 cannot in general be defended against by a TCP-using protocol. 4106 Implementors or users who are concerned with this class of attack 4107 should use IPsec AH [RFC4302] or ESP [RFC4303]. 4109 F.4. Final Notes 4111 For TLS to be able to provide a secure connection, both the client 4112 and server systems, keys, and applications must be secure. In 4113 addition, the implementation must be free of security errors. 4115 The system is only as strong as the weakest key exchange and 4116 authentication algorithm supported, and only trustworthy 4117 cryptographic functions should be used. Short public keys and 4118 anonymous servers should be used with great caution. Implementations 4119 and users must be careful when deciding which certificates and 4120 certificate authorities are acceptable; a dishonest certificate 4121 authority can do tremendous damage. 4123 Appendix G. Working Group Information 4125 The discussion list for the IETF TLS working group is located at the 4126 e-mail address tls@ietf.org [2]. Information on the group and 4127 information on how to subscribe to the list is at 4128 https://www1.ietf.org/mailman/listinfo/tls 4129 Archives of the list can be found at: http://www.ietf.org/mail- 4130 archive/web/tls/current/index.html 4132 Appendix H. Contributors 4134 Christopher Allen (co-editor of TLS 1.0) 4135 Alacrity Ventures 4136 ChristopherA@AlacrityManagement.com 4138 Martin Abadi 4139 University of California, Santa Cruz 4140 abadi@cs.ucsc.edu 4142 Karthikeyan Bhargavan (co-author of [I-D.ietf-tls-session-hash]) 4143 INRIA 4144 karthikeyan.bhargavan@inria.fr 4146 Steven M. Bellovin 4147 Columbia University 4148 smb@cs.columbia.edu 4150 Simon Blake-Wilson (co-author of RFC4492) 4151 BCI 4152 sblakewilson@bcisse.com 4154 Nelson Bolyard 4155 Sun Microsystems, Inc. 4156 nelson@bolyard.com (co-author of RFC4492) 4158 Ran Canetti 4159 IBM 4160 canetti@watson.ibm.com 4162 Pete Chown 4163 Skygate Technology Ltd 4164 pc@skygate.co.uk 4166 Antoine Delignat-Lavaud (co-author of [I-D.ietf-tls-session-hash]) 4167 INRIA 4168 antoine.delignat-lavaud@inria.fr 4170 Taher Elgamal 4171 taher@securify.com 4172 Securify 4174 Pasi Eronen 4175 pasi.eronen@nokia.com 4176 Nokia 4177 Anil Gangolli 4178 anil@busybuddha.org 4180 Vipul Gupta (co-author of RFC4492) 4181 Sun Microsystems Laboratories 4182 vipul.gupta@sun.com 4184 Kipp Hickman 4186 Chris Hawk (co-author of RFC4492) 4187 Corriente Networks LLC 4188 chris@corriente.net 4190 Alfred Hoenes 4192 David Hopwood 4193 Independent Consultant 4194 david.hopwood@blueyonder.co.uk 4196 Daniel Kahn Gillmor 4197 ACLU 4198 dkg@fifthhorseman.net 4200 Phil Karlton (co-author of SSLv3) 4202 Paul Kocher (co-author of SSLv3) 4203 Cryptography Research 4204 paul@cryptography.com 4206 Hugo Krawczyk 4207 IBM 4208 hugo@ee.technion.ac.il 4210 Adam Langley (co-author of [I-D.ietf-tls-session-hash]) 4211 Google 4212 agl@google.com 4214 Ilari Liusvaara 4215 ilari.liusvaara@elisanet.fi 4217 Jan Mikkelsen 4218 Transactionware 4219 janm@transactionware.com 4221 Bodo Moeller (co-author of RFC4492) 4222 Google 4223 bodo@openssl.org 4224 Magnus Nystrom 4225 RSA Security 4226 magnus@rsasecurity.com 4228 Alfredo Pironti (co-author of [I-D.ietf-tls-session-hash]) 4229 INRIA 4230 alfredo.pironti@inria.fr 4232 Marsh Ray (co-author of [I-D.ietf-tls-session-hash]) 4233 Microsoft 4234 maray@microsoft.com 4236 Robert Relyea 4237 Netscape Communications 4238 relyea@netscape.com 4240 Jim Roskind 4241 Netscape Communications 4242 jar@netscape.com 4244 Michael Sabin 4246 Dan Simon 4247 Microsoft, Inc. 4248 dansimon@microsoft.com 4250 Martin Thomson 4251 Mozilla 4252 mt@mozilla.com 4254 Tom Weinstein 4256 Tim Wright 4257 Vodafone 4258 timothy.wright@vodafone.com 4260 Authors' Addresses 4262 Tim Dierks 4263 Independent 4265 EMail: tim@dierks.org 4267 Eric Rescorla 4268 RTFM, Inc. 4270 EMail: ekr@rtfm.com