idnits 2.17.00 (12 Aug 2021) /tmp/idnits23972/draft-ietf-tls-rfc2246-bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 564 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 678: '... protocol. Any new record types SHOULD...' RFC 2119 keyword, line 682: '... SHOULD just ignore it. Any protocol...' RFC 2119 keyword, line 685: '...encryption, care SHOULD be taken to mi...' RFC 2119 keyword, line 786: '...e current states MUST be updated for e...' RFC 2119 keyword, line 805: '... number MUST be set to zero when...' (79 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 759 has weird spacing: '...gorithm bul...' == Line 3585 has weird spacing: '...tegrity and |...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: close_notify This message notifies the recipient that the sender will not send | any more messages on this connection. The session MUST not be | resumed if any connection is terminated without proper close_notify messages with level equal to warning. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: After sending a hello request, servers SHOULD not repeat the request | until the subsequent handshake negotiation is complete. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: opaque SessionID<0..32>; Warning: Because the SessionID is transmitted without encryption or | immediate MAC protection, servers MUST not place confidential information in session identifiers or let the contents of fake session identifiers cause any breach of security. (Note that the content of the handshake as a whole, including the SessionID, is protected by the Finished messages exchanged at the end of the handshake.) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Meaning of this message: With this message, the premaster secret is set, either though direct transmission of the RSA-encrypted secret, or by the transmission of Diffie-Hellman parameters which will allow each side to agree upon the same premaster secret. When the key exchange method is DH_RSA or DH_DSS, client certification has been requested, and the client was able to respond with a certificate which contained a Diffie-Hellman public key whose parameters (group and generator) matched those specified by the | server in its certificate, this message MUST not contain any data. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'TCP' on line 3844 looks like a reference -- Missing reference section? 'DES' on line 3726 looks like a reference -- Missing reference section? 'RC4' on line 3768 looks like a reference -- Missing reference section? 'RSA' on line 3771 looks like a reference -- Missing reference section? 'DSS' on line 3734 looks like a reference -- Missing reference section? 'REQ' on line 3786 looks like a reference -- Missing reference section? 'XDR' on line 3850 looks like a reference -- Missing reference section? '0' on line 321 looks like a reference -- Missing reference section? '1' on line 321 looks like a reference -- Missing reference section? '3' on line 3268 looks like a reference -- Missing reference section? '9' on line 357 looks like a reference -- Missing reference section? '2' on line 2594 looks like a reference -- Missing reference section? '4' on line 392 looks like a reference -- Missing reference section? '8' on line 393 looks like a reference -- Missing reference section? '10' on line 487 looks like a reference -- Missing reference section? 'PKCS1' on line 3752 looks like a reference -- Missing reference section? '20' on line 2666 looks like a reference -- Missing reference section? 'HMAC' on line 3738 looks like a reference -- Missing reference section? '48' on line 2841 looks like a reference -- Missing reference section? '32' on line 2843 looks like a reference -- Missing reference section? 'CBCATT' on line 3808 looks like a reference -- Missing reference section? 'CBCTIME' on line 3812 looks like a reference -- Missing reference section? 'X509' on line 3795 looks like a reference -- Missing reference section? 'ChangeCipherSpec' on line 1604 looks like a reference -- Missing reference section? '28' on line 2589 looks like a reference -- Missing reference section? 'TLSEXT' on line 3792 looks like a reference -- Missing reference section? 'PKIX' on line 3761 looks like a reference -- Missing reference section? 'PKCS7' on line 3758 looks like a reference -- Missing reference section? 'PKCS6' on line 3755 looks like a reference -- Missing reference section? '16' on line 2661 looks like a reference -- Missing reference section? '46' on line 2697 looks like a reference -- Missing reference section? 'BLEI' on line 3803 looks like a reference -- Missing reference section? 'TIMING' on line 3847 looks like a reference -- Missing reference section? 'KPR03' on line 3828 looks like a reference -- Missing reference section? '12' on line 2719 looks like a reference -- Missing reference section? '3DES' on line 3723 looks like a reference -- Missing reference section? 'IDEA' on line 3742 looks like a reference -- Missing reference section? 'MD5' on line 3749 looks like a reference -- Missing reference section? 'RSADSI' on line 3831 looks like a reference -- Missing reference section? 'RC2' on line 3765 looks like a reference -- Missing reference section? 'SHA' on line 3776 looks like a reference -- Missing reference section? 'SSL3' on line 3783 looks like a reference -- Missing reference section? 'SSL2' on line 3780 looks like a reference -- Missing reference section? 'SUBGROUP' on line 3840 looks like a reference -- Missing reference section? 'ENCAUTH' on line 3815 looks like a reference -- Missing reference section? 'SEQNUM' on line 3837 looks like a reference -- Missing reference section? 'AH' on line 3800 looks like a reference -- Missing reference section? 'ESP' on line 3819 looks like a reference -- Missing reference section? 'DH1' on line 3730 looks like a reference -- Missing reference section? 'MD2' on line 3746 looks like a reference -- Missing reference section? 'FTP' on line 3822 looks like a reference -- Missing reference section? 'HTTP' on line 3825 looks like a reference -- Missing reference section? 'SCH' on line 3833 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 56 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Tim Dierks | 3 Independent | 4 Eric Rescorla | 5 INTERNET-DRAFT RTFM, Inc. | 6 June 2003 (Expires December 2003) | 8 The TLS Protocol 9 Version 1.1 | 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with | 14 all provisions of Section 10 of RFC2026. Internet-Drafts are working | 15 documents of the Internet Engineering Task Force (IETF), its areas, | 16 and its working groups. Note that other groups may also distribute | 17 working documents as Internet-Drafts. | 19 Internet-Drafts are draft documents valid for a maximum of six months | 20 and may be updated, replaced, or obsoleted by other documents at any | 21 time. It is inappropriate to use Internet-Drafts as reference | 22 material or to cite them other than as "work in progress." | 24 To learn the current status of any Internet-Draft, please check the | 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow | 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), | 27 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or | 28 ftp.isi.edu (US West Coast). 29 Copyright Notice 31 Copyright (C) The Internet Society (1999). All Rights Reserved. 33 Abstract 35 This document specifies Version 1.1 of the Transport Layer Security | 36 (TLS) protocol. The TLS protocol provides communications privacy over 37 the Internet. The protocol allows client/server applications to 38 communicate in a way that is designed to prevent eavesdropping, 39 tampering, or message forgery. 41 Table of Contents 43 1. Introduction 3 44 2. Goals 4 45 3. Goals of this document 5 46 4. Presentation language 5 47 4.1. Basic block size 6 48 4.2. Miscellaneous 6 49 4.3. Vectors 6 50 4.4. Numbers 7 51 4.5. Enumerateds 7 52 4.6. Constructed types 8 53 4.6.1. Variants 9 54 4.7. Cryptographic attributes 10 55 4.8. Constants 11 56 5. HMAC and the pseudorandom function 11 57 6. The TLS Record Protocol 13 58 6.1. Connection states 14 59 6.2. Record layer 16 60 6.2.1. Fragmentation 16 61 6.2.2. Record compression and decompression 17 62 6.2.3. Record payload protection 18 63 6.2.3.1. Null or standard stream cipher 19 64 6.2.3.2. CBC block cipher 19 65 6.3. Key calculation 21 66 6.3.1. Export key generation example 22 67 7. The TLS Handshake Protocol 23 68 7.1. Change cipher spec protocol 24 69 7.2. Alert protocol 24 70 7.2.1. Closure alerts 25 71 7.2.2. Error alerts 26 72 7.3. Handshake Protocol overview 29 73 7.4. Handshake protocol 32 74 7.4.1. Hello messages 33 75 7.4.1.1. Hello request 33 76 7.4.1.2. Client hello 34 77 7.4.1.3. Server hello 36 78 7.4.2. Server certificate 37 79 7.4.3. Server key exchange message 39 80 7.4.4. Certificate request 41 81 7.4.5. Server hello done 42 82 7.4.6. Client certificate 43 83 7.4.7. Client key exchange message 43 84 7.4.7.1. RSA encrypted premaster secret message 44 85 7.4.7.2. Client Diffie-Hellman public value 45 86 7.4.8. Certificate verify 45 87 7.4.9. Finished 46 88 8. Cryptographic computations 47 89 8.1. Computing the master secret 47 90 8.1.1. RSA 48 91 8.1.2. Diffie-Hellman 48 92 9. Mandatory Cipher Suites 48 93 10. Application data protocol 48 94 A. Protocol constant values 49 95 A.1. Record layer 49 96 A.2. Change cipher specs message 50 97 A.3. Alert messages 50 98 A.4. Handshake protocol 51 99 A.4.1. Hello messages 51 100 A.4.2. Server authentication and key exchange messages 52 101 A.4.3. Client authentication and key exchange messages 53 102 A.4.4. Handshake finalization message 54 103 A.5. The CipherSuite 54 104 A.6. The Security Parameters 56 105 B. Glossary 57 106 C. CipherSuite definitions 61 107 D. Implementation Notes 64 108 D.1. Temporary RSA keys 64 109 D.2. Random Number Generation and Seeding 64 110 D.3. Certificates and authentication 65 111 D.4. CipherSuites 65 112 E. Backward Compatibility With SSL 66 113 E.1. Version 2 client hello 67 114 E.2. Avoiding man-in-the-middle version rollback 68 115 F. Security analysis 69 116 F.1. Handshake protocol 69 117 F.1.1. Authentication and key exchange 69 118 F.1.1.1. Anonymous key exchange 69 119 F.1.1.2. RSA key exchange and authentication 70 120 F.1.1.3. Diffie-Hellman key exchange with authentication 71 121 F.1.2. Version rollback attacks 71 122 F.1.3. Detecting attacks against the handshake protocol 72 123 F.1.4. Resuming sessions 72 124 F.1.5. MD5 and SHA 72 125 F.2. Protecting application data 72 126 F.3. Final notes 73 127 G. Patent Statement 74 128 Security Considerations 75 129 References 75 130 Credits 77 131 Comments 78 132 Full Copyright Statement 80 134 Change history | 136 Note: Change bars in this draft are from RFC 2246, not draft-00 | 138 26-Jun-03 ekr@rtfm.com | 139 * Incorporated Last Call comments from Franke Marcus, Jack Lloyd, | 140 Brad Wetmore, and others. | 142 22-Apr-03 ekr@rtfm.com | 143 * coverage of the Vaudenay, Boneh-Brumley, and KPR attacks | 144 * cleaned up IV text a bit. | 145 * Added discussion of Denial of Service attacks. | 146 | 147 11-Feb-02 ekr@rtfm.com | 148 * Clarified the behavior of empty certificate lists [Nelson Bolyard] | 149 * Added text explaining the security implications of authenticate | 150 then encrypt. | 151 * Cleaned up the explicit IV text. | 152 * Added some more acknowledgement names | 154 02-Nov-02 ekr@rtfm.com | 155 * Changed this to be TLS 1.1. | 156 * Added fixes for the Rogaway and Vaudenay CBC attacks | 157 * Separated references into normative and informative | 159 01-Mar-02 ekr@rtfm.com | 160 * Tightened up the language in F.1.1.2 [Peter Watkins] | 161 * Fixed smart quotes [Bodo Moeller] | 162 * Changed handling of padding errors to prevent CBC-based attack | 163 [Bodo Moeller] | 164 * Fixed certificate_list spec in the appendix [Aman Sawrup] | 165 * Fixed a bug in the V2 definitions [Aman Sawrup] | 166 * Fixed S 7.2.1 to point out that you don't need a close notify | 167 if you just sent some other fatal alert [Andreas Sterbenz] | 168 * Marked alert 41 reserved [Andreas Sterbenz] | 169 * Changed S 7.4.2 to point out that 512-bit keys cannot be used for | 170 signing [Andreas Sterbenz] | 171 * Added reserved client key types from SSLv3 [Andreas Sterbenz] | 172 * Changed EXPORT40 to "40-bit EXPORT" in S 9 [Andreas Sterbenz] | 173 * Removed RSA patent statement [Andreas Sterbenz] | 174 * Removed references to BSAFE and RSAREF [Andreas Sterbenz] | 176 14-Feb-02 ekr@rtfm.com | 177 * Re-converted to I-D from RFC | 178 * Made RSA/3DES the mandatory cipher suite. | 179 * Added discussion of the EncryptedPMS encoding and PMS version number| 180 issues to 7.4.7.1 | 181 * Removed the requirement in 7.4.1.3 that the Server random must be | 182 different from the Client random, since these are randomly generated| 183 and we don't expect servers to reject Server random values which | 184 coincidentally are the same as the Client random. | 185 * Replaced may/should/must with MAY/SHOULD/MUST where appropriate. | 186 In many cases, shoulds became MUSTs, where I believed that was the | 187 actual sense of the text. Added an RFC 2119 bulletin. | 188 * Clarified the meaning of "empty certificate" message. [Peter Gutmann]| 189 * Redid the CertificateRequest grammar to allow no distinguished names.| 190 [Peter Gutmann] | 191 * Removed the reference to requiring the master secret to generate | 192 the CertificateVerify in F.1.1 [Bodo Moeller] | 193 * Deprecated EXPORT40. | 194 * Fixed a bunch of errors in the SSLv2 backward compatible client hello.| 196 1. Introduction 198 The primary goal of the TLS Protocol is to provide privacy and data 199 integrity between two communicating applications. The protocol is 200 composed of two layers: the TLS Record Protocol and the TLS Handshake 201 Protocol. At the lowest level, layered on top of some reliable 202 transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The 203 TLS Record Protocol provides connection security that has two basic 204 properties: 206 - - The connection is private. Symmetric cryptography is used for 207 data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for 208 this symmetric encryption are generated uniquely for each 209 connection and are based on a secret negotiated by another 210 protocol (such as the TLS Handshake Protocol). The Record 211 Protocol can also be used without encryption. 213 - - The connection is reliable. Message transport includes a 214 message integrity check using a keyed MAC. Secure hash functions 215 (e.g., SHA, MD5, etc.) are used for MAC computations. The Record 216 Protocol can operate without a MAC, but is generally only used in 217 this mode while another protocol is using the Record Protocol as 218 a transport for negotiating security parameters. 220 The TLS Record Protocol is used for encapsulation of various higher 221 level protocols. One such encapsulated protocol, the TLS Handshake 222 Protocol, allows the server and client to authenticate each other and 223 to negotiate an encryption algorithm and cryptographic keys before 224 the application protocol transmits or receives its first byte of 225 data. The TLS Handshake Protocol provides connection security that 226 has three basic properties: 228 - - The peer's identity can be authenticated using asymmetric, or 229 public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This 230 authentication can be made optional, but is generally required 231 for at least one of the peers. 233 - - The negotiation of a shared secret is secure: the negotiated | 234 secret is unavailable to eavesdroppers, and for any authenticated 235 connection the secret cannot be obtained, even by an attacker who 236 can place himself in the middle of the connection. 238 - - The negotiation is reliable: no attacker can modify the 239 negotiation communication without being detected by the parties 240 to the communication. 242 One advantage of TLS is that it is application protocol independent. 243 Higher level protocols can layer on top of the TLS Protocol 244 transparently. The TLS standard, however, does not specify how 245 protocols add security with TLS; the decisions on how to initiate TLS 246 handshaking and how to interpret the authentication certificates 247 exchanged are left up to the judgment of the designers and 248 implementors of protocols which run on top of TLS. 250 1.1 Requirements Terminology | 252 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and | 253 "MAY" that appear in this document are to be interpreted as described | 254 in RFC 2119 [REQ]. | 256 2. Goals 258 The goals of TLS Protocol, in order of their priority, are: 260 1. Cryptographic security: TLS should be used to establish a secure 261 connection between two parties. 263 2. Interoperability: Independent programmers should be able to 264 develop applications utilizing TLS that will then be able to 265 successfully exchange cryptographic parameters without knowledge 266 of one another's code. 268 3. Extensibility: TLS seeks to provide a framework into which new 269 public key and bulk encryption methods can be incorporated as 270 necessary. This will also accomplish two sub-goals: to prevent 271 the need to create a new protocol (and risking the introduction 272 of possible new weaknesses) and to avoid the need to implement an 273 entire new security library. 275 4. Relative efficiency: Cryptographic operations tend to be highly 276 CPU intensive, particularly public key operations. For this 277 reason, the TLS protocol has incorporated an optional session 278 caching scheme to reduce the number of connections that need to 279 be established from scratch. Additionally, care has been taken to 280 reduce network activity. 282 3. Goals of this document 284 This document and the TLS protocol itself are based on the SSL 3.0 285 Protocol Specification as published by Netscape. The differences 286 between this protocol and SSL 3.0 are not dramatic, but they are 287 significant enough that TLS 1.0 and SSL 3.0 do not interoperate 288 (although TLS 1.0 does incorporate a mechanism by which a TLS 289 implementation can back down to SSL 3.0). This document is intended 290 primarily for readers who will be implementing the protocol and those 291 doing cryptographic analysis of it. The specification has been 292 written with this in mind, and it is intended to reflect the needs of 293 those two groups. For that reason, many of the algorithm-dependent 294 data structures and rules are included in the body of the text (as 295 opposed to in an appendix), providing easier access to them. 297 This document is not intended to supply any details of service 298 definition nor interface definition, although it does cover select 299 areas of policy as they are required for the maintenance of solid 300 security. 302 4. Presentation language 304 This document deals with the formatting of data in an external 305 representation. The following very basic and somewhat casually 306 defined presentation syntax will be used. The syntax draws from 307 several sources in its structure. Although it resembles the 308 programming language "C" in its syntax and XDR [XDR] in both its 309 syntax and intent, it would be risky to draw too many parallels. The 310 purpose of this presentation language is to document TLS only, not to 311 have general application beyond that particular goal. 313 4.1. Basic block size 315 The representation of all data items is explicitly specified. The 316 basic data block size is one byte (i.e. 8 bits). Multiple byte data 317 items are concatenations of bytes, from left to right, from top to 318 bottom. From the bytestream a multi-byte item (a numeric in the 319 example) is formed (using C notation) by: 321 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | 322 ... | byte[n-1]; 324 This byte ordering for multi-byte values is the commonplace network 325 byte order or big endian format. 327 4.2. Miscellaneous 329 Comments begin with "/*" and end with "*/". 331 Optional components are denoted by enclosing them in "[[ ]]" double 332 brackets. 334 Single byte entities containing uninterpreted data are of type 335 opaque. 337 4.3. Vectors 339 A vector (single dimensioned array) is a stream of homogeneous data 340 elements. The size of the vector may be specified at documentation 341 time or left unspecified until runtime. In either case the length 342 declares the number of bytes, not the number of elements, in the 343 vector. The syntax for specifying a new type T' that is a fixed 344 length vector of type T is 346 T T'[n]; 348 Here T' occupies n bytes in the data stream, where n is a multiple of 349 the size of T. The length of the vector is not included in the 350 encoded stream. 352 In the following example, Datum is defined to be three consecutive 353 bytes that the protocol does not interpret, while Data is three 354 consecutive Datum, consuming a total of nine bytes. 356 opaque Datum[3]; /* three uninterpreted bytes */ 357 Datum Data[9]; /* 3 consecutive 3 byte vectors */ 358 Variable length vectors are defined by specifying a subrange of legal 359 lengths, inclusively, using the notation . When 360 encoded, the actual length precedes the vector's contents in the byte 361 stream. The length will be in the form of a number consuming as many 362 bytes as required to hold the vector's specified maximum (ceiling) 363 length. A variable length vector with an actual length field of zero 364 is referred to as an empty vector. 366 T T'; 368 In the following example, mandatory is a vector that must contain 369 between 300 and 400 bytes of type opaque. It can never be empty. The 370 actual length field consumes two bytes, a uint16, sufficient to 371 represent the value 400 (see Section 4.4). On the other hand, longer 372 can represent up to 800 bytes of data, or 400 uint16 elements, and it 373 may be empty. Its encoding will include a two byte actual length 374 field prepended to the vector. The length of an encoded vector must 375 be an even multiple of the length of a single element (for example, a 376 17 byte vector of uint16 would be illegal). 378 opaque mandatory<300..400>; 379 /* length field is 2 bytes, cannot be empty */ 380 uint16 longer<0..800>; 381 /* zero to 400 16-bit unsigned integers */ 383 4.4. Numbers 385 The basic numeric data type is an unsigned byte (uint8). All larger 386 numeric data types are formed from fixed length series of bytes 387 concatenated as described in Section 4.1 and are also unsigned. The 388 following numeric types are predefined. 390 uint8 uint16[2]; 391 uint8 uint24[3]; 392 uint8 uint32[4]; 393 uint8 uint64[8]; 395 All values, here and elsewhere in the specification, are stored in 396 "network" or "big-endian" order; the uint32 represented by the hex 397 bytes 01 02 03 04 is equivalent to the decimal value 16909060. 399 4.5. Enumerateds 401 An additional sparse data type is available called enum. A field of 402 type enum can only assume the values declared in the definition. 403 Each definition is a different type. Only enumerateds of the same 404 type may be assigned or compared. Every element of an enumerated must 405 be assigned a value, as demonstrated in the following example. Since 406 the elements of the enumerated are not ordered, they can be assigned 407 any unique value, in any order. 409 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; 411 Enumerateds occupy as much space in the byte stream as would its 412 maximal defined ordinal value. The following definition would cause 413 one byte to be used to carry fields of type Color. 415 enum { red(3), blue(5), white(7) } Color; 417 One may optionally specify a value without its associated tag to 418 force the width definition without defining a superfluous element. 419 In the following example, Taste will consume two bytes in the data 420 stream but can only assume the values 1, 2 or 4. 422 enum { sweet(1), sour(2), bitter(4), (32000) } Taste; 424 The names of the elements of an enumeration are scoped within the 425 defined type. In the first example, a fully qualified reference to 426 the second element of the enumeration would be Color.blue. Such 427 qualification is not required if the target of the assignment is well 428 specified. 430 Color color = Color.blue; /* overspecified, legal */ 431 Color color = blue; /* correct, type implicit */ 433 For enumerateds that are never converted to external representation, 434 the numerical information may be omitted. 436 enum { low, medium, high } Amount; 438 4.6. Constructed types 440 Structure types may be constructed from primitive types for 441 convenience. Each specification declares a new, unique type. The 442 syntax for definition is much like that of C. 444 struct { 445 T1 f1; 446 T2 f2; 447 ... 448 Tn fn; 449 } [[T]]; 450 The fields within a structure may be qualified using the type's name 451 using a syntax much like that available for enumerateds. For example, 452 T.f2 refers to the second field of the previous declaration. 453 Structure definitions may be embedded. 455 4.6.1. Variants 457 Defined structures may have variants based on some knowledge that is 458 available within the environment. The selector must be an enumerated 459 type that defines the possible variants the structure defines. There 460 must be a case arm for every element of the enumeration declared in 461 the select. The body of the variant structure may be given a label 462 for reference. The mechanism by which the variant is selected at 463 runtime is not prescribed by the presentation language. 465 struct { 466 T1 f1; 467 T2 f2; 468 .... 469 Tn fn; 470 select (E) { 471 case e1: Te1; 472 case e2: Te2; 473 .... 474 case en: Ten; 475 } [[fv]]; 476 } [[Tv]]; 478 For example: 480 enum { apple, orange } VariantTag; 481 struct { 482 uint16 number; 483 opaque string<0..10>; /* variable length */ 484 } V1; 485 struct { 486 uint32 number; 487 opaque string[10]; /* fixed length */ 488 } V2; 489 struct { 490 select (VariantTag) { /* value of selector is implicit */ 491 case apple: V1; /* VariantBody, tag = apple */ 492 case orange: V2; /* VariantBody, tag = orange */ 493 } variant_body; /* optional label on variant */ 494 } VariantRecord; 496 Variant structures may be qualified (narrowed) by specifying a value 497 for the selector prior to the type. For example, a 498 orange VariantRecord 500 is a narrowed type of a VariantRecord containing a variant_body of 501 type V2. 503 4.7. Cryptographic attributes 505 The four cryptographic operations digital signing, stream cipher 506 encryption, block cipher encryption, and public key encryption are 507 designated digitally-signed, stream-ciphered, block-ciphered, and 508 public-key-encrypted, respectively. A field's cryptographic 509 processing is specified by prepending an appropriate key word 510 designation before the field's type specification. Cryptographic keys 511 are implied by the current session state (see Section 6.1). 513 In digital signing, one-way hash functions are used as input for a 514 signing algorithm. A digitally-signed element is encoded as an opaque 515 vector <0..2^16-1>, where the length is specified by the signing 516 algorithm and key. 518 In RSA signing, a 36-byte structure of two hashes (one SHA and one 519 MD5) is signed (encrypted with the private key). It is encoded with 520 PKCS #1 block type 0 or type 1 as described in [PKCS1]. 522 In DSS, the 20 bytes of the SHA hash are run directly through the 523 Digital Signing Algorithm with no additional hashing. This produces 524 two values, r and s. The DSS signature is an opaque vector, as above, 525 the contents of which are the DER encoding of: 527 Dss-Sig-Value ::= SEQUENCE { 528 r INTEGER, 529 s INTEGER 530 } 532 In stream cipher encryption, the plaintext is exclusive-ORed with an 533 identical amount of output generated from a cryptographically-secure 534 keyed pseudorandom number generator. 536 In block cipher encryption, every block of plaintext encrypts to a 537 block of ciphertext. All block cipher encryption is done in CBC 538 (Cipher Block Chaining) mode, and all items which are block-ciphered 539 will be an exact multiple of the cipher block length. 541 In public key encryption, a public key algorithm is used to encrypt 542 data in such a way that it can be decrypted only with the matching 543 private key. A public-key-encrypted element is encoded as an opaque 544 vector <0..2^16-1>, where the length is specified by the signing 545 algorithm and key. 547 An RSA encrypted value is encoded with PKCS #1 block type 2 as 548 described in [PKCS1]. 550 In the following example: 552 stream-ciphered struct { 553 uint8 field1; 554 uint8 field2; 555 digitally-signed opaque hash[20]; 556 } UserType; 558 The contents of hash are used as input for the signing algorithm, 559 then the entire structure is encrypted with a stream cipher. The 560 length of this structure, in bytes would be equal to 2 bytes for 561 field1 and field2, plus two bytes for the length of the signature, 562 plus the length of the output of the signing algorithm. This is known 563 due to the fact that the algorithm and key used for the signing are 564 known prior to encoding or decoding this structure. 566 4.8. Constants 568 Typed constants can be defined for purposes of specification by 569 declaring a symbol of the desired type and assigning values to it. 570 Under-specified types (opaque, variable length vectors, and 571 structures that contain opaque) cannot be assigned values. No fields 572 of a multi-element structure or vector may be elided. 574 For example, 576 struct { 577 uint8 f1; 578 uint8 f2; 579 } Example1; 581 Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */ 583 5. HMAC and the pseudorandom function 585 A number of operations in the TLS record and handshake layer required 586 a keyed MAC; this is a secure digest of some data protected by a 587 secret. Forging the MAC is infeasible without knowledge of the MAC 588 secret. The construction we use for this operation is known as HMAC, 589 described in [HMAC]. 591 HMAC can be used with a variety of different hash algorithms. TLS 592 uses it in the handshake with two different algorithms: MD5 and 593 SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret, 594 data). Additional hash algorithms can be defined by cipher suites and 595 used to protect record data, but MD5 and SHA-1 are hard coded into 596 the description of the handshaking for this version of the protocol. 598 In addition, a construction is required to do expansion of secrets 599 into blocks of data for the purposes of key generation or validation. 600 This pseudo-random function (PRF) takes as input a secret, a seed, 601 and an identifying label and produces an output of arbitrary length. 603 In order to make the PRF as secure as possible, it uses two hash 604 algorithms in a way which should guarantee its security if either 605 algorithm remains secure. 607 First, we define a data expansion function, P_hash(secret, data) 608 which uses a single hash function to expand a secret and seed into an 609 arbitrary quantity of output: 611 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + 612 HMAC_hash(secret, A(2) + seed) + 613 HMAC_hash(secret, A(3) + seed) + ... 615 Where + indicates concatenation. 617 A() is defined as: 618 A(0) = seed 619 A(i) = HMAC_hash(secret, A(i-1)) 621 P_hash can be iterated as many times as is necessary to produce the 622 required quantity of data. For example, if P_SHA-1 was being used to 623 create 64 bytes of data, it would have to be iterated 4 times 624 (through A(4)), creating 80 bytes of output data; the last 16 bytes 625 of the final iteration would then be discarded, leaving 64 bytes of 626 output data. 628 TLS's PRF is created by splitting the secret into two halves and 629 using one half to generate data with P_MD5 and the other half to 630 generate data with P_SHA-1, then exclusive-or'ing the outputs of 631 these two expansion functions together. 633 S1 and S2 are the two halves of the secret and each is the same 634 length. S1 is taken from the first half of the secret, S2 from the 635 second half. Their length is created by rounding up the length of the 636 overall secret divided by two; thus, if the original secret is an odd 637 number of bytes long, the last byte of S1 will be the same as the 638 first byte of S2. 640 L_S = length in bytes of secret; 641 L_S1 = L_S2 = ceil(L_S / 2); 642 The secret is partitioned into two halves (with the possibility of 643 one shared byte) as described above, S1 taking the first L_S1 bytes 644 and S2 the last L_S2 bytes. 646 The PRF is then defined as the result of mixing the two pseudorandom 647 streams by exclusive-or'ing them together. 649 PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR 650 P_SHA-1(S2, label + seed); 652 The label is an ASCII string. It should be included in the exact form 653 it is given without a length byte or trailing null character. For 654 example, the label "slithy toves" would be processed by hashing the 655 following bytes: 657 73 6C 69 74 68 79 20 74 6F 76 65 73 659 Note that because MD5 produces 16 byte outputs and SHA-1 produces 20 660 byte outputs, the boundaries of their internal iterations will not be 661 aligned; to generate a 80 byte output will involve P_MD5 being 662 iterated through A(5), while P_SHA-1 will only iterate through A(4). 664 6. The TLS Record Protocol 666 The TLS Record Protocol is a layered protocol. At each layer, 667 messages may include fields for length, description, and content. 668 The Record Protocol takes messages to be transmitted, fragments the 669 data into manageable blocks, optionally compresses the data, applies 670 a MAC, encrypts, and transmits the result. Received data is 671 decrypted, verified, decompressed, and reassembled, then delivered to 672 higher level clients. 674 Four record protocol clients are described in this document: the 675 handshake protocol, the alert protocol, the change cipher spec 676 protocol, and the application data protocol. In order to allow 677 extension of the TLS protocol, additional record types can be | 678 supported by the record protocol. Any new record types SHOULD 679 allocate type values immediately beyond the ContentType values for 680 the four record types described here (see Appendix A.2). If a TLS 681 implementation receives a record type it does not understand, it | 682 SHOULD just ignore it. Any protocol designed for use over TLS MUST be 683 carefully designed to deal with all possible attacks against it. 684 Note that because the type and length of a record are not protected | 685 by encryption, care SHOULD be taken to minimize the value of traffic 686 analysis of these values. 688 6.1. Connection states 690 A TLS connection state is the operating environment of the TLS Record 691 Protocol. It specifies a compression algorithm, encryption algorithm, 692 and MAC algorithm. In addition, the parameters for these algorithms 693 are known: the MAC secret and the bulk encryption keys for the | 694 connection in both the read and the write directions. Logically, 695 there are always four connection states outstanding: the current read 696 and write states, and the pending read and write states. All records 697 are processed under the current read and write states. The security 698 parameters for the pending states can be set by the TLS Handshake 699 Protocol, and the Handshake Protocol can selectively make either of 700 the pending states current, in which case the appropriate current 701 state is disposed of and replaced with the pending state; the pending 702 state is then reinitialized to an empty state. It is illegal to make 703 a state which has not been initialized with security parameters a 704 current state. The initial current state always specifies that no 705 encryption, compression, or MAC will be used. 707 The security parameters for a TLS Connection read and write state are 708 set by providing the following values: 710 connection end 711 Whether this entity is considered the "client" or the "server" in 712 this connection. 714 bulk encryption algorithm 715 An algorithm to be used for bulk encryption. This specification 716 includes the key size of this algorithm, how much of that key is 717 secret, whether it is a block or stream cipher, the block size of 718 the cipher (if appropriate), and whether it is considered an 719 "export" cipher. 721 MAC algorithm 722 An algorithm to be used for message authentication. This 723 specification includes the size of the hash which is returned by 724 the MAC algorithm. 726 compression algorithm 727 An algorithm to be used for data compression. This specification 728 must include all information the algorithm requires to do 729 compression. 731 master secret 732 A 48 byte secret shared between the two peers in the connection. 734 client random 735 A 32 byte value provided by the client. 737 server random 738 A 32 byte value provided by the server. 740 These parameters are defined in the presentation language as: 742 enum { server, client } ConnectionEnd; 744 enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm; 746 enum { stream, block } CipherType; 748 enum { true, false } IsExportable; 750 enum { null, md5, sha } MACAlgorithm; 752 enum { null(0), (255) } CompressionMethod; 754 /* The algorithms specified in CompressionMethod, 755 BulkCipherAlgorithm, and MACAlgorithm may be added to. */ 757 struct { 758 ConnectionEnd entity; 759 BulkCipherAlgorithm bulk_cipher_algorithm; 760 CipherType cipher_type; 761 uint8 key_size; 762 uint8 key_material_length; 763 IsExportable is_exportable; 764 MACAlgorithm mac_algorithm; 765 uint8 hash_size; 766 CompressionMethod compression_algorithm; 767 opaque master_secret[48]; 768 opaque client_random[32]; 769 opaque server_random[32]; 770 } SecurityParameters; 772 The record layer will use the security parameters to generate the | 773 following four items: 775 client write MAC secret 776 server write MAC secret 777 client write key 778 server write key 780 The client write parameters are used by the server when receiving and 781 processing records and vice-versa. The algorithm used for generating 782 these items from the security parameters is described in section 6.3. 784 Once the security parameters have been set and the keys have been 785 generated, the connection states can be instantiated by making them | 786 the current states. These current states MUST be updated for each 787 record processed. Each connection state includes the following 788 elements: 790 compression state 791 The current state of the compression algorithm. 793 cipher state 794 The current state of the encryption algorithm. This will consist | 795 of the scheduled key for that connection. For stream ciphers, | 796 this will also contain whatever the necessary state information | 797 is to allow the stream to continue to encrypt or decrypt data. 799 MAC secret 800 The MAC secret for this connection as generated above. 802 sequence number 803 Each connection state contains a sequence number, which is 804 maintained separately for read and write states. The sequence | 805 number MUST be set to zero whenever a connection state is made 806 the active state. Sequence numbers are of type uint64 and may not | 807 exceed 2^64-1. Sequence numbers do not wrap. If a TLS | 808 implementation would need to wrap a sequence number it must | 809 renegotiate instead. A sequence number is incremented after each 810 record: specifically, the first record which is transmitted under | 811 a particular connection state MUST use sequence number 0. 813 6.2. Record layer 815 The TLS Record Layer receives uninterpreted data from higher layers 816 in non-empty blocks of arbitrary size. 818 6.2.1. Fragmentation 820 The record layer fragments information blocks into TLSPlaintext 821 records carrying data in chunks of 2^14 bytes or less. Client message 822 boundaries are not preserved in the record layer (i.e., multiple | 823 client messages of the same ContentType MAY be coalesced into a | 824 single TLSPlaintext record, or a single message MAY be fragmented | 825 across several records). | 827 struct { 828 uint8 major, minor; 829 } ProtocolVersion; 831 enum { 832 change_cipher_spec(20), alert(21), handshake(22), 833 application_data(23), (255) 834 } ContentType; 836 struct { 837 ContentType type; 838 ProtocolVersion version; 839 uint16 length; 840 opaque fragment[TLSPlaintext.length]; 841 } TLSPlaintext; 843 type 844 The higher level protocol used to process the enclosed fragment. 846 version 847 The version of the protocol being employed. This document | 848 describes TLS Version 1.1, which uses the version { 3, 2 }. The | 849 version value 3.2 is historical: TLS version 1.1 is a minor | 850 modification to the TLS 1.0 protocol, which was itself a minor | 851 modification to the SSL 3.0 protocol, which bears the version 852 value 3.0. (See Appendix A.1). 854 length 855 The length (in bytes) of the following TLSPlaintext.fragment. 856 The length should not exceed 2^14. 858 fragment 859 The application data. This data is transparent and treated as an 860 independent block to be dealt with by the higher level protocol 861 specified by the type field. 863 Note: Data of different TLS Record layer content types MAY be | 864 interleaved. Application data is generally of lower precedence | 865 for transmission than other content types and therefore handshake | 866 records may be held if application data is pending. However, | 867 records MUST be delivered to the network in the same order as | 868 they are protected by the record layer. | 870 6.2.2. Record compression and decompression 872 All records are compressed using the compression algorithm defined in 873 the current session state. There is always an active compression 874 algorithm; however, initially it is defined as 875 CompressionMethod.null. The compression algorithm translates a 876 TLSPlaintext structure into a TLSCompressed structure. Compression 877 functions are initialized with default state information whenever a 878 connection state is made active. 880 Compression must be lossless and may not increase the content length 881 by more than 1024 bytes. If the decompression function encounters a 882 TLSCompressed.fragment that would decompress to a length in excess of 883 2^14 bytes, it should report a fatal decompression failure error. 885 struct { 886 ContentType type; /* same as TLSPlaintext.type */ 887 ProtocolVersion version;/* same as TLSPlaintext.version */ 888 uint16 length; 889 opaque fragment[TLSCompressed.length]; 890 } TLSCompressed; 892 length 893 The length (in bytes) of the following TLSCompressed.fragment. 894 The length should not exceed 2^14 + 1024. 896 fragment 897 The compressed form of TLSPlaintext.fragment. 899 Note: A CompressionMethod.null operation is an identity operation; no 900 fields are altered. 902 Implementation note: 903 Decompression functions are responsible for ensuring that 904 messages cannot cause internal buffer overflows. 906 6.2.3. Record payload protection 908 The encryption and MAC functions translate a TLSCompressed structure 909 into a TLSCiphertext. The decryption functions reverse the process. 910 The MAC of the record also includes a sequence number so that 911 missing, extra or repeated messages are detectable. 913 struct { 914 ContentType type; 915 ProtocolVersion version; 916 uint16 length; 917 select (CipherSpec.cipher_type) { 918 case stream: GenericStreamCipher; 919 case block: GenericBlockCipher; 920 } fragment; 921 } TLSCiphertext; 923 type 924 The type field is identical to TLSCompressed.type. 926 version 927 The version field is identical to TLSCompressed.version. 929 length 930 The length (in bytes) of the following TLSCiphertext.fragment. 931 The length may not exceed 2^14 + 2048. 933 fragment | 934 The encrypted form of TLSCompressed.fragment, with the MAC. 936 6.2.3.1. Null or standard stream cipher 938 Stream ciphers (including BulkCipherAlgorithm.null - see Appendix 939 A.6) convert TLSCompressed.fragment structures to and from stream 940 TLSCiphertext.fragment structures. 942 stream-ciphered struct { 943 opaque content[TLSCompressed.length]; 944 opaque MAC[CipherSpec.hash_size]; 945 } GenericStreamCipher; 947 The MAC is generated as: 949 HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + 950 TLSCompressed.version + TLSCompressed.length + 951 TLSCompressed.fragment)); 953 where "+" denotes concatenation. 955 seq_num 956 The sequence number for this record. 958 hash 959 The hashing algorithm specified by 960 SecurityParameters.mac_algorithm. 962 Note that the MAC is computed before encryption. The stream cipher 963 encrypts the entire block, including the MAC. For stream ciphers that 964 do not use a synchronization vector (such as RC4), the stream cipher 965 state from the end of one record is simply used on the subsequent 966 packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption 967 consists of the identity operation (i.e., the data is not encrypted 968 and the MAC size is zero implying that no MAC is used). 969 TLSCiphertext.length is TLSCompressed.length plus 970 CipherSpec.hash_size. 972 6.2.3.2. CBC block cipher 974 For block ciphers (such as RC2 or DES), the encryption and MAC 975 functions convert TLSCompressed.fragment structures to and from block 976 TLSCiphertext.fragment structures. 978 block-ciphered struct { 979 opaque IV[CipherSpec.block_length]; | 980 opaque content[TLSCompressed.length]; 981 opaque MAC[CipherSpec.hash_size]; 982 uint8 padding[GenericBlockCipher.padding_length]; 983 uint8 padding_length; 984 } GenericBlockCipher; 986 The MAC is generated as described in Section 6.2.3.1. 988 IV | 989 Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit | 990 IV in order to prevent the attacks described by [CBCATT]. | 991 We recommend the following equivalently strong procedures. | 992 For clarity we use the following notation. | 994 IV -- the transmitted value of the IV field in the | 995 GenericBlockCipher structure. | 996 CBC residue -- the last ciphertext block of the previous record | 997 mask -- the actual value which the cipher XORs with the | 998 plaintext prior to encryption of the first cipher block | 999 of the record. | 1001 In prior versions of TLS, there was no IV field and the CBC residue| 1002 and mask were one and the same. | 1004 (1) Generate a cryptographically strong random string R of | 1005 length CipherSpec.block_length. Place R | 1006 in the IV field. Set the mask to R. Thus, the first | 1007 cipher block will be encrypted as E(R XOR Data). | 1009 (2) Generate a cryptographically strong random number R of | 1010 length CipherSpec.block_length and prepend it to the plaintext| 1011 prior to encryption. In | 1012 this case either: | 1014 (a) The cipher may use a fixed mask such as zero. | 1015 (b) The CBC residue from the previous record may be used | 1016 as the mask. This preserves maximum code compatibility | 1017 with TLS 1.0 and SSL 3. It also has the advantage that | 1018 it does not require the ability to quickly reset the IV, | 1019 which is known to be a problem on some systems. | 1021 In either case, the data (R || data) is fed into the | 1022 encryption process. The first cipher block (containing | 1023 E(mask XOR R) is placed in the IV field. The first | 1024 block of content contains E(IV XOR data) | 1025 The following alternative procedure MAY be used: However, it has | 1026 not been demonstrated to be equivalently cryptographically strong | 1027 to the above procedures. The sender prepends a fixed block F to | 1028 the plaintext (or alternatively a block generated with a weak | 1029 PRNG). He then encrypts as in (2) above, using the CBC residue | 1030 from the previous block as the mask for the prepended block. Note | 1031 that in this case the mask for the first record transmitted by | 1032 the application (the Finished) MUST be generated using a | 1033 cryptographically strong PRNG. | 1035 The decryption operation for all three alternatives is the same. | 1036 The receiver decrypts the entire GenericBlockCipher structure and | 1037 then discards the first cipher block, corresponding to the IV | 1038 component. | 1040 padding 1041 Padding that is added to force the length of the plaintext to be 1042 an integral multiple of the block cipher's block length. The | 1043 padding MAY be any length up to 255 bytes long, as long as it 1044 results in the TLSCiphertext.length being an integral multiple of 1045 the block length. Lengths longer than necessary might be 1046 desirable to frustrate attacks on a protocol based on analysis of 1047 the lengths of exchanged messages. Each uint8 in the padding data | 1048 vector MUST be filled with the padding length value. The receiver | 1049 MUST check this padding and SHOULD use the bad_record_mac alert | 1050 to indicate padding errors. 1052 padding_length 1053 The padding length MUST be such that the total size of the | 1054 GenericBlockCipher structure is a multiple of the cipher's block 1055 length. Legal values range from zero to 255, inclusive. This 1056 length specifies the length of the padding field exclusive of the 1057 padding_length field itself. 1059 The encrypted data length (TLSCiphertext.length) is one more than the 1060 sum of TLSCompressed.length, CipherSpec.hash_size, and 1061 padding_length. 1063 Example: If the block length is 8 bytes, the content length 1064 (TLSCompressed.length) is 61 bytes, and the MAC length is 20 | 1065 bytes, the length before padding is 82 bytes (this does not | 1066 include the IV, which may or may not be encrypted, as | 1067 discussed above). Thus, the padding length modulo 8 must be 1068 equal to 6 in order to make the total length an even multiple 1069 of 8 bytes (the block length). The padding length can be 6, 1070 14, 22, and so on, through 254. If the padding length were the 1071 minimum necessary, 6, the padding would be 6 bytes, each 1072 containing the value 6. Thus, the last 8 octets of the 1073 GenericBlockCipher before block encryption would be xx 06 06 1074 06 06 06 06 06, where xx is the last octet of the MAC. 1076 Note: With block ciphers in CBC mode (Cipher Block Chaining), | 1077 it is critical that the entire plaintext of the record be known | 1078 before any ciphertext is transmitted. Otherwise it is possible | 1079 for the attacker to mount the attack described in [CBCATT]. | 1081 Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a | 1082 timing attack on CBC padding based on the time required to | 1083 compute the MAC. In order to defend against this attack, | 1084 implementations MUST ensure that record processing time is | 1085 essentially the same whether or not the padding is correct. In | 1086 general, the best way to to do this is to compute the MAC even if | 1087 the padding is incorrect, and only then reject the packet. For | 1088 instance, if the pad appears to be incorrect the implementation | 1089 might assume a zero-length pad and then compute the MAC. This | 1090 leaves a small timing channel, since MAC performance depends to | 1091 some extent on the size of the data fragment, but it is not | 1092 believed to be large enough to be exploitable due to the large | 1093 block size of existing MACs and the small size of the timing | 1094 signal. 1096 6.3. Key calculation 1098 The Record Protocol requires an algorithm to generate keys, and MAC | 1099 secrets from the security parameters provided by the handshake 1100 protocol. 1102 The master secret is hashed into a sequence of secure bytes, which | 1103 are assigned to the MAC secrets and keys required by the current 1104 connection state (see Appendix A.6). CipherSpecs require a client 1105 write MAC secret, a server write MAC secret, a client write key, and | 1106 a server write key, which are generated from the master secret in | 1107 that order. Unused values are empty. 1109 When generating keys and MAC secrets, the master secret is used as an 1110 entropy source, and the random values provide unencrypted salt | 1111 material for exportable ciphers. 1113 To generate the key material, compute 1115 key_block = PRF(SecurityParameters.master_secret, 1116 "key expansion", 1117 SecurityParameters.server_random + 1118 SecurityParameters.client_random); 1120 until enough output has been generated. Then the key_block is 1121 partitioned as follows: 1123 client_write_MAC_secret[SecurityParameters.hash_size] 1124 server_write_MAC_secret[SecurityParameters.hash_size] 1125 client_write_key[SecurityParameters.key_material_length] 1126 server_write_key[SecurityParameters.key_material_length] 1128 Implementation note: 1129 The cipher spec which is defined in this document which requires 1130 the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte | 1131 keys, 2 x 20 byte MAC secrets, for a total 88 bytes of key | 1132 material. 1134 Exportable encryption algorithms (for which CipherSpec.is_exportable 1135 is true) require additional processing as follows to derive their 1136 final write keys: 1138 final_client_write_key = 1139 PRF(SecurityParameters.client_write_key, 1140 "client write key", 1141 SecurityParameters.client_random + 1142 SecurityParameters.server_random); 1143 final_server_write_key = 1144 PRF(SecurityParameters.server_write_key, 1145 "server write key", 1146 SecurityParameters.client_random + 1147 SecurityParameters.server_random); 1149 6.3.1. Export key generation example 1151 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for 1152 each of the two encryption keys and 16 bytes for each of the MAC 1153 keys, for a total of 42 bytes of key material. The PRF output is 1154 stored in the key_block. The key_block is partitioned, and the write 1155 keys are salted because this is an exportable encryption algorithm. 1157 key_block = PRF(master_secret, 1158 "key expansion", 1159 server_random + 1160 client_random)[0..41] 1161 client_write_MAC_secret = key_block[0..15] 1162 server_write_MAC_secret = key_block[16..31] 1163 client_write_key = key_block[32..36] 1164 server_write_key = key_block[37..41] 1165 final_client_write_key = PRF(client_write_key, 1166 "client write key", 1167 client_random + 1168 server_random)[0..15] 1169 final_server_write_key = PRF(server_write_key, 1170 "server write key", 1171 client_random + 1172 server_random)[0..15] 1174 7. The TLS Handshake Protocol 1176 The TLS Handshake Protocol consists of a suite of three sub-protocols 1177 which are used to allow peers to agree upon security parameters for 1178 the record layer, authenticate themselves, instantiate negotiated 1179 security parameters, and report error conditions to each other. 1181 The Handshake Protocol is responsible for negotiating a session, 1182 which consists of the following items: 1184 session identifier 1185 An arbitrary byte sequence chosen by the server to identify an 1186 active or resumable session state. 1188 peer certificate 1189 X509v3 [X509] certificate of the peer. This element of the state 1190 may be null. 1192 compression method 1193 The algorithm used to compress data prior to encryption. 1195 cipher spec 1196 Specifies the bulk data encryption algorithm (such as null, DES, 1197 etc.) and a MAC algorithm (such as MD5 or SHA). It also defines 1198 cryptographic attributes such as the hash_size. (See Appendix A.6 1199 for formal definition) 1201 master secret 1202 48-byte secret shared between the client and server. 1204 is resumable 1205 A flag indicating whether the session can be used to initiate new 1206 connections. 1208 These items are then used to create security parameters for use by 1209 the Record Layer when protecting application data. Many connections 1210 can be instantiated using the same session through the resumption 1211 feature of the TLS Handshake Protocol. 1213 7.1. Change cipher spec protocol 1214 The change cipher spec protocol exists to signal transitions in 1215 ciphering strategies. The protocol consists of a single message, 1216 which is encrypted and compressed under the current (not the pending) 1217 connection state. The message consists of a single byte of value 1. 1219 struct { 1220 enum { change_cipher_spec(1), (255) } type; 1221 } ChangeCipherSpec; 1223 The change cipher spec message is sent by both the client and server 1224 to notify the receiving party that subsequent records will be 1225 protected under the newly negotiated CipherSpec and keys. Reception 1226 of this message causes the receiver to instruct the Record Layer to 1227 immediately copy the read pending state into the read current state. | 1228 Immediately after sending this message, the sender MUST instruct the 1229 record layer to make the write pending state the write active state. 1230 (See section 6.1.) The change cipher spec message is sent during the 1231 handshake after the security parameters have been agreed upon, but 1232 before the verifying finished message is sent (see section 7.4.9). 1234 7.2. Alert protocol 1236 One of the content types supported by the TLS Record layer is the 1237 alert type. Alert messages convey the severity of the message and a 1238 description of the alert. Alert messages with a level of fatal result 1239 in the immediate termination of the connection. In this case, other 1240 connections corresponding to the session may continue, but the | 1241 session identifier MUST be invalidated, preventing the failed session 1242 from being used to establish new connections. Like other messages, 1243 alert messages are encrypted and compressed, as specified by the 1244 current connection state. 1246 enum { warning(1), fatal(2), (255) } AlertLevel; 1248 enum { 1249 close_notify(0), 1250 unexpected_message(10), 1251 bad_record_mac(20), 1252 decryption_failed(21), 1253 record_overflow(22), 1254 decompression_failure(30), 1255 handshake_failure(40), 1256 no_certificate_RESERVED (41), | 1257 bad_certificate(42), 1258 unsupported_certificate(43), 1259 certificate_revoked(44), 1260 certificate_expired(45), 1261 certificate_unknown(46), 1262 illegal_parameter(47), 1263 unknown_ca(48), 1264 access_denied(49), 1265 decode_error(50), 1266 decrypt_error(51), 1267 export_restriction(60), 1268 protocol_version(70), 1269 insufficient_security(71), 1270 internal_error(80), 1271 user_canceled(90), 1272 no_renegotiation(100), 1273 (255) 1274 } AlertDescription; 1276 struct { 1277 AlertLevel level; 1278 AlertDescription description; 1279 } Alert; 1281 7.2.1. Closure alerts 1283 The client and the server must share knowledge that the connection is 1284 ending in order to avoid a truncation attack. Either party may 1285 initiate the exchange of closing messages. 1287 close_notify 1288 This message notifies the recipient that the sender will not send | 1289 any more messages on this connection. The session MUST not be | 1290 resumed if any connection is terminated without proper 1291 close_notify messages with level equal to warning. 1293 Either party may initiate a close by sending a close_notify alert. 1294 Any data received after a closure alert is ignored. 1296 Unless some other fatal alert has been transmitted, each party is | 1297 required to send a close_notify alert before closing the write side | 1298 of the connection. The other party MUST respond with a close_notify | 1299 alert of its own and close down the connection immediately, 1300 discarding any pending writes. It is not required for the initiator 1301 of the close to wait for the responding close_notify alert before 1302 closing the read side of the connection. 1304 If the application protocol using TLS provides that any data may be 1305 carried over the underlying transport after the TLS connection is 1306 closed, the TLS implementation must receive the responding 1307 close_notify alert before indicating to the application layer that 1308 the TLS connection has ended. If the application protocol will not 1309 transfer any additional data, but will only close the underlying | 1310 transport connection, then the implementation MAY choose to close the 1311 transport without waiting for the responding close_notify. No part of 1312 this standard should be taken to dictate the manner in which a usage 1313 profile for TLS manages its data transport, including when 1314 connections are opened or closed. 1316 NB: It is assumed that closing a connection reliably delivers 1317 pending data before destroying the transport. 1319 7.2.2. Error alerts 1321 Error handling in the TLS Handshake protocol is very simple. When an 1322 error is detected, the detecting party sends a message to the other 1323 party. Upon transmission or receipt of an fatal alert message, both | 1324 parties immediately close the connection. Servers and clients MUST | 1325 forget any session-identifiers, keys, and secrets associated with a 1326 failed connection. The following error alerts are defined: 1328 unexpected_message 1329 An inappropriate message was received. This alert is always fatal 1330 and should never be observed in communication between proper 1331 implementations. 1333 bad_record_mac 1334 This alert is returned if a record is received with an incorrect | 1335 MAC. This alert also SHOULD be returned if a TLSCiphertext | 1336 decrypted in an invalid way: either it wasn't an even multiple of | 1337 the block length, or its padding values, when checked, weren't | 1338 correct. This message is always fatal. 1340 decryption_failed 1341 This alert MAY be returned if a TLSCiphertext decrypted in an | 1342 invalid way: either it wasn't an even multiple of the block | 1343 length, or its padding values, when checked, weren't correct. | 1344 This message is always fatal. | 1346 NB: Differentiating between bad_record_mac and decryption_failed | 1347 alerts may permit certain attacks against CBC mode as used in TLS | 1348 [CBCATT]. It is preferable to uniformly use the bad_record_mac | 1349 alert to hide the specific type of the error. | 1351 record_overflow 1352 A TLSCiphertext record was received which had a length more than 1353 2^14+2048 bytes, or a record decrypted to a TLSCompressed record 1354 with more than 2^14+1024 bytes. This message is always fatal. 1356 decompression_failure 1357 The decompression function received improper input (e.g. data 1358 that would expand to excessive length). This message is always 1359 fatal. 1361 handshake_failure 1362 Reception of a handshake_failure alert message indicates that the 1363 sender was unable to negotiate an acceptable set of security 1364 parameters given the options available. This is a fatal error. 1366 no_certificate_RESERVED | 1367 This alert was used in SSLv3 but not in TLS. It should not be | 1368 sent by compliant implementations. | 1370 bad_certificate 1371 A certificate was corrupt, contained signatures that did not 1372 verify correctly, etc. 1374 unsupported_certificate 1375 A certificate was of an unsupported type. 1377 certificate_revoked 1378 A certificate was revoked by its signer. 1380 certificate_expired 1381 A certificate has expired or is not currently valid. 1383 certificate_unknown 1384 Some other (unspecified) issue arose in processing the 1385 certificate, rendering it unacceptable. 1387 illegal_parameter 1388 A field in the handshake was out of range or inconsistent with 1389 other fields. This is always fatal. 1391 unknown_ca 1392 A valid certificate chain or partial chain was received, but the 1393 certificate was not accepted because the CA certificate could not | 1394 be located or couldn't be matched with a known, trusted CA. This 1395 message is always fatal. 1397 access_denied 1398 A valid certificate was received, but when access control was 1399 applied, the sender decided not to proceed with negotiation. 1400 This message is always fatal. 1402 decode_error 1403 A message could not be decoded because some field was out of the 1404 specified range or the length of the message was incorrect. This 1405 message is always fatal. 1407 decrypt_error 1408 A handshake cryptographic operation failed, including being 1409 unable to correctly verify a signature, decrypt a key exchange, 1410 or validate a finished message. 1412 export_restriction 1413 A negotiation not in compliance with export restrictions was 1414 detected; for example, attempting to transfer a 1024 bit 1415 ephemeral RSA key for the RSA_EXPORT handshake method. This 1416 message is always fatal. 1418 protocol_version 1419 The protocol version the client has attempted to negotiate is 1420 recognized, but not supported. (For example, old protocol 1421 versions might be avoided for security reasons). This message is 1422 always fatal. 1424 insufficient_security 1425 Returned instead of handshake_failure when a negotiation has 1426 failed specifically because the server requires ciphers more 1427 secure than those supported by the client. This message is always 1428 fatal. 1430 internal_error 1431 An internal error unrelated to the peer or the correctness of the 1432 protocol makes it impossible to continue (such as a memory 1433 allocation failure). This message is always fatal. 1435 user_canceled 1436 This handshake is being canceled for some reason unrelated to a 1437 protocol failure. If the user cancels an operation after the 1438 handshake is complete, just closing the connection by sending a 1439 close_notify is more appropriate. This alert should be followed 1440 by a close_notify. This message is generally a warning. 1442 no_renegotiation 1443 Sent by the client in response to a hello request or by the 1444 server in response to a client hello after initial handshaking. 1445 Either of these would normally lead to renegotiation; when that 1446 is not appropriate, the recipient should respond with this alert; 1447 at that point, the original requester can decide whether to 1448 proceed with the connection. One case where this would be 1449 appropriate would be where a server has spawned a process to 1450 satisfy a request; the process might receive security parameters 1451 (key length, authentication, etc.) at startup and it might be 1452 difficult to communicate changes to these parameters after that 1453 point. This message is always a warning. 1455 For all errors where an alert level is not explicitly specified, the | 1456 sending party MAY determine at its discretion whether this is a fatal 1457 error or not; if an alert with a level of warning is received, the 1458 receiving party MAY decide at its discretion whether to treat this as | 1459 a fatal error or not. However, all messages which are transmitted | 1460 with a level of fatal MUST be treated as fatal messages. 1462 7.3. Handshake Protocol overview 1464 The cryptographic parameters of the session state are produced by the 1465 TLS Handshake Protocol, which operates on top of the TLS Record 1466 Layer. When a TLS client and server first start communicating, they 1467 agree on a protocol version, select cryptographic algorithms, 1468 optionally authenticate each other, and use public-key encryption 1469 techniques to generate shared secrets. 1471 The TLS Handshake Protocol involves the following steps: 1473 - - Exchange hello messages to agree on algorithms, exchange random 1474 values, and check for session resumption. 1476 - - Exchange the necessary cryptographic parameters to allow the 1477 client and server to agree on a premaster secret. 1479 - - Exchange certificates and cryptographic information to allow 1480 the client and server to authenticate themselves. 1482 - - Generate a master secret from the premaster secret and 1483 exchanged random values. 1485 - - Provide security parameters to the record layer. 1487 - - Allow the client and server to verify that their peer has 1488 calculated the same security parameters and that the handshake 1489 occurred without tampering by an attacker. 1491 Note that higher layers should not be overly reliant on TLS always 1492 negotiating the strongest possible connection between two peers: 1493 there are a number of ways a man in the middle attacker can attempt 1494 to make two entities drop down to the least secure method they 1495 support. The protocol has been designed to minimize this risk, but 1496 there are still attacks available: for example, an attacker could 1497 block access to the port a secure service runs on, or attempt to get 1498 the peers to negotiate an unauthenticated connection. The fundamental 1499 rule is that higher levels must be cognizant of what their security 1500 requirements are and never transmit information over a channel less 1501 secure than what they require. The TLS protocol is secure, in that 1502 any cipher suite offers its promised level of security: if you 1503 negotiate 3DES with a 1024 bit RSA key exchange with a host whose 1504 certificate you have verified, you can expect to be that secure. 1506 However, you SHOULD never send data over a link encrypted with 40 bit | 1507 security unless you feel that data is worth no more than the effort 1508 required to break that encryption. 1510 These goals are achieved by the handshake protocol, which can be 1511 summarized as follows: The client sends a client hello message to 1512 which the server must respond with a server hello message, or else a 1513 fatal error will occur and the connection will fail. The client hello 1514 and server hello are used to establish security enhancement 1515 capabilities between client and server. The client hello and server 1516 hello establish the following attributes: Protocol Version, Session 1517 ID, Cipher Suite, and Compression Method. Additionally, two random 1518 values are generated and exchanged: ClientHello.random and 1519 ServerHello.random. 1521 The actual key exchange uses up to four messages: the server 1522 certificate, the server key exchange, the client certificate, and the 1523 client key exchange. New key exchange methods can be created by 1524 specifying a format for these messages and defining the use of the 1525 messages to allow the client and server to agree upon a shared | 1526 secret. This secret MUST be quite long; currently defined key 1527 exchange methods exchange secrets which range from 48 to 128 bytes in 1528 length. 1530 Following the hello messages, the server will send its certificate, 1531 if it is to be authenticated. Additionally, a server key exchange 1532 message may be sent, if it is required (e.g. if their server has no 1533 certificate, or if its certificate is for signing only). If the 1534 server is authenticated, it may request a certificate from the 1535 client, if that is appropriate to the cipher suite selected. Now the 1536 server will send the server hello done message, indicating that the 1537 hello-message phase of the handshake is complete. The server will 1538 then wait for a client response. If the server has sent a certificate 1539 request message, the client must send the certificate message. The 1540 client key exchange message is now sent, and the content of that 1541 message will depend on the public key algorithm selected between the 1542 client hello and the server hello. If the client has sent a 1543 certificate with signing ability, a digitally-signed certificate 1544 verify message is sent to explicitly verify the certificate. 1546 At this point, a change cipher spec message is sent by the client, 1547 and the client copies the pending Cipher Spec into the current Cipher 1548 Spec. The client then immediately sends the finished message under 1549 the new algorithms, keys, and secrets. In response, the server will 1550 send its own change cipher spec message, transfer the pending to the 1551 current Cipher Spec, and send its finished message under the new 1552 Cipher Spec. At this point, the handshake is complete and the client 1553 and server may begin to exchange application layer data. (See flow 1554 chart below.) 1556 Client Server 1558 ClientHello --------> 1559 ServerHello 1560 Certificate* 1561 ServerKeyExchange* 1562 CertificateRequest* 1563 <-------- ServerHelloDone 1564 Certificate* 1565 ClientKeyExchange 1566 CertificateVerify* 1567 [ChangeCipherSpec] 1568 Finished --------> 1569 [ChangeCipherSpec] 1570 <-------- Finished 1571 Application Data <-------> Application Data 1573 Fig. 1 - Message flow for a full handshake 1575 * Indicates optional or situation-dependent messages that are not 1576 always sent. 1578 Note: To help avoid pipeline stalls, ChangeCipherSpec is an 1579 independent TLS Protocol content type, and is not actually a TLS 1580 handshake message. 1582 When the client and server decide to resume a previous session or 1583 duplicate an existing session (instead of negotiating new security 1584 parameters) the message flow is as follows: 1586 The client sends a ClientHello using the Session ID of the session to 1587 be resumed. The server then checks its session cache for a match. If 1588 a match is found, and the server is willing to re-establish the 1589 connection under the specified session state, it will send a 1590 ServerHello with the same Session ID value. At this point, both | 1591 client and server MUST send change cipher spec messages and proceed 1592 directly to finished messages. Once the re-establishment is complete, | 1593 the client and server MAY begin to exchange application layer data. 1594 (See flow chart below.) If a Session ID match is not found, the 1595 server generates a new session ID and the TLS client and server 1596 perform a full handshake. 1598 Client Server 1600 ClientHello --------> 1601 ServerHello 1602 [ChangeCipherSpec] 1603 <-------- Finished 1604 [ChangeCipherSpec] 1605 Finished --------> 1606 Application Data <-------> Application Data 1608 Fig. 2 - Message flow for an abbreviated handshake 1610 The contents and significance of each message will be presented in 1611 detail in the following sections. 1613 7.4. Handshake protocol 1615 The TLS Handshake Protocol is one of the defined higher level clients 1616 of the TLS Record Protocol. This protocol is used to negotiate the 1617 secure attributes of a session. Handshake messages are supplied to 1618 the TLS Record Layer, where they are encapsulated within one or more 1619 TLSPlaintext structures, which are processed and transmitted as 1620 specified by the current active session state. 1622 enum { 1623 hello_request(0), client_hello(1), server_hello(2), 1624 certificate(11), server_key_exchange (12), 1625 certificate_request(13), server_hello_done(14), 1626 certificate_verify(15), client_key_exchange(16), 1627 finished(20), (255) 1628 } HandshakeType; 1630 struct { 1631 HandshakeType msg_type; /* handshake type */ 1632 uint24 length; /* bytes in message */ 1633 select (HandshakeType) { 1634 case hello_request: HelloRequest; 1635 case client_hello: ClientHello; 1636 case server_hello: ServerHello; 1637 case certificate: Certificate; 1638 case server_key_exchange: ServerKeyExchange; 1639 case certificate_request: CertificateRequest; 1640 case server_hello_done: ServerHelloDone; 1641 case certificate_verify: CertificateVerify; 1642 case client_key_exchange: ClientKeyExchange; 1643 case finished: Finished; 1644 } body; 1645 } Handshake; 1646 The handshake protocol messages are presented below in the order they | 1647 MUST be sent; sending handshake messages in an unexpected order 1648 results in a fatal error. Unneeded handshake messages can be omitted, 1649 however. Note one exception to the ordering: the Certificate message 1650 is used twice in the handshake (from server to client, then from 1651 client to server), but described only in its first position. The one 1652 message which is not bound by these ordering rules is the Hello | 1653 Request message, which can be sent at any time, but which should be 1654 ignored by the client if it arrives in the middle of a handshake. 1656 7.4.1. Hello messages 1658 The hello phase messages are used to exchange security enhancement 1659 capabilities between the client and server. When a new session 1660 begins, the Record Layer's connection state encryption, hash, and 1661 compression algorithms are initialized to null. The current 1662 connection state is used for renegotiation messages. 1664 7.4.1.1. Hello request 1666 When this message will be sent: 1667 The hello request message MAY be sent by the server at any time. | 1669 Meaning of this message: 1670 Hello request is a simple notification that the client should 1671 begin the negotiation process anew by sending a client hello 1672 message when convenient. This message will be ignored by the 1673 client if the client is currently negotiating a session. This 1674 message may be ignored by the client if it does not wish to 1675 renegotiate a session, or the client may, if it wishes, respond 1676 with a no_renegotiation alert. Since handshake messages are 1677 intended to have transmission precedence over application data, 1678 it is expected that the negotiation will begin before no more 1679 than a few records are received from the client. If the server 1680 sends a hello request but does not receive a client hello in 1681 response, it may close the connection with a fatal alert. 1683 After sending a hello request, servers SHOULD not repeat the request | 1684 until the subsequent handshake negotiation is complete. 1686 Structure of this message: 1687 struct { } HelloRequest; 1689 Note: This message MUST NOT be included in the message hashes which are | 1690 maintained throughout the handshake and used in the finished 1691 messages and the certificate verify message. 1693 7.4.1.2. Client hello 1695 When this message will be sent: 1696 When a client first connects to a server it is required to send 1697 the client hello as its first message. The client can also send a 1698 client hello in response to a hello request or on its own 1699 initiative in order to renegotiate the security parameters in an 1700 existing connection. 1702 Structure of this message: 1703 The client hello message includes a random structure, which is 1704 used later in the protocol. 1706 struct { 1707 uint32 gmt_unix_time; 1708 opaque random_bytes[28]; 1709 } Random; 1711 gmt_unix_time 1712 The current time and date in standard UNIX 32-bit format (seconds 1713 since the midnight starting Jan 1, 1970, GMT) according to the 1714 sender's internal clock. Clocks are not required to be set 1715 correctly by the basic TLS Protocol; higher level or application 1716 protocols may define additional requirements. 1718 random_bytes 1719 28 bytes generated by a secure random number generator. 1721 The client hello message includes a variable length session | 1722 identifier. If not empty, the value identifies a session between the 1723 same client and server whose security parameters the client wishes to | 1724 reuse. The session identifier MAY be from an earlier connection, this 1725 connection, or another currently active connection. The second option 1726 is useful if the client only wishes to update the random structures 1727 and derived values of a connection, while the third option makes it 1728 possible to establish several independent secure connections without 1729 repeating the full handshake protocol. These independent connections 1730 may occur sequentially or simultaneously; a SessionID becomes valid 1731 when the handshake negotiating it completes with the exchange of 1732 Finished messages and persists until removed due to aging or because 1733 a fatal error was encountered on a connection associated with the 1734 session. The actual contents of the SessionID are defined by the 1735 server. 1737 opaque SessionID<0..32>; 1738 Warning: 1739 Because the SessionID is transmitted without encryption or | 1740 immediate MAC protection, servers MUST not place confidential 1741 information in session identifiers or let the contents of fake 1742 session identifiers cause any breach of security. (Note that the 1743 content of the handshake as a whole, including the SessionID, is 1744 protected by the Finished messages exchanged at the end of the 1745 handshake.) 1747 The CipherSuite list, passed from the client to the server in the | 1748 client hello message, contains the combinations of cryptographic 1749 algorithms supported by the client in order of the client's 1750 preference (favorite choice first). Each CipherSuite defines a key 1751 exchange algorithm, a bulk encryption algorithm (including secret key 1752 length) and a MAC algorithm. The server will select a cipher suite 1753 or, if no acceptable choices are presented, return a handshake 1754 failure alert and close the connection. 1756 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1758 The client hello includes a list of compression algorithms supported 1759 by the client, ordered according to the client's preference. 1761 enum { null(0), (255) } CompressionMethod; 1763 struct { 1764 ProtocolVersion client_version; 1765 Random random; 1766 SessionID session_id; 1767 CipherSuite cipher_suites<2..2^16-1>; 1768 CompressionMethod compression_methods<1..2^8-1>; 1769 } ClientHello; 1771 client_version 1772 The version of the TLS protocol by which the client wishes to | 1773 communicate during this session. This SHOULD be the latest 1774 (highest valued) version supported by the client. For this | 1775 version of the specification, the version will be 3.2 (See 1776 Appendix E for details about backward compatibility). 1778 random 1779 A client-generated random structure. 1781 session_id 1782 The ID of a session the client wishes to use for this connection. 1783 This field should be empty if no session_id is available or the 1784 client wishes to generate new security parameters. 1786 cipher_suites 1787 This is a list of the cryptographic options supported by the 1788 client, with the client's first preference first. If the 1789 session_id field is not empty (implying a session resumption | 1790 request) this vector MUST include at least the cipher_suite from 1791 that session. Values are defined in Appendix A.5. 1793 compression_methods 1794 This is a list of the compression methods supported by the 1795 client, sorted by client preference. If the session_id field is 1796 not empty (implying a session resumption request) it must include 1797 the compression_method from that session. This vector must 1798 contain, and all implementations must support, 1799 CompressionMethod.null. Thus, a client and server will always be 1800 able to agree on a compression method. 1802 After sending the client hello message, the client waits for a server 1803 hello message. Any other handshake message returned by the server 1804 except for a hello request is treated as a fatal error. 1806 Forward compatibility note: 1807 In the interests of forward compatibility, it is permitted for a 1808 client hello message to include extra data after the compression | 1809 methods. This data MUST be included in the handshake hashes, but 1810 must otherwise be ignored. This is the only handshake message for 1811 which this is legal; for all other messages, the amount of data | 1812 in the message MUST match the description of the message 1813 precisely. 1815 Note: For the intended use of trailing data in the ClientHello, see RFC | 1816 3546 [TLSEXT]. | 1818 7.4.1.3. Server hello 1820 When this message will be sent: 1821 The server will send this message in response to a client hello 1822 message when it was able to find an acceptable set of algorithms. 1823 If it cannot find such a match, it will respond with a handshake 1824 failure alert. 1826 Structure of this message: 1827 struct { 1828 ProtocolVersion server_version; 1829 Random random; 1830 SessionID session_id; 1831 CipherSuite cipher_suite; 1832 CompressionMethod compression_method; 1833 } ServerHello; 1834 server_version 1835 This field will contain the lower of that suggested by the client 1836 in the client hello and the highest supported by the server. For 1837 this version of the specification, the version is 3.2 (See | 1838 Appendix E for details about backward compatibility). 1840 random 1841 This structure is generated by the server and MUST be | 1842 independently generated from the ClientHello.random. 1844 session_id 1845 This is the identity of the session corresponding to this 1846 connection. If the ClientHello.session_id was non-empty, the 1847 server will look in its session cache for a match. If a match is 1848 found and the server is willing to establish the new connection 1849 using the specified session state, the server will respond with 1850 the same value as was supplied by the client. This indicates a 1851 resumed session and dictates that the parties must proceed 1852 directly to the finished messages. Otherwise this field will 1853 contain a different value identifying the new session. The server 1854 may return an empty session_id to indicate that the session will 1855 not be cached and therefore cannot be resumed. If a session is 1856 resumed, it must be resumed using the same cipher suite it was 1857 originally negotiated with. 1859 cipher_suite 1860 The single cipher suite selected by the server from the list in 1861 ClientHello.cipher_suites. For resumed sessions this field is the 1862 value from the state of the session being resumed. 1864 compression_method | 1865 The single compression algorithm selected by the server from the 1866 list in ClientHello.compression_methods. For resumed sessions 1867 this field is the value from the resumed session state. 1869 7.4.2. Server certificate 1871 When this message will be sent: 1872 The server MUST send a certificate whenever the agreed-upon key | 1873 exchange method is not an anonymous one. This message will always 1874 immediately follow the server hello message. 1876 Meaning of this message: 1877 The certificate type MUST be appropriate for the selected cipher | 1878 suite's key exchange algorithm, and is generally an X.509v3 | 1879 certificate. It MUST contain a key which matches the key exchange 1880 method, as follows. Unless otherwise specified, the signing 1881 algorithm for the certificate MUST be the same as the algorithm | 1882 for the certificate key. Unless otherwise specified, the public | 1883 key MAY be of any length. 1885 Key Exchange Algorithm Certificate Key Type 1887 RSA RSA public key; the certificate MUST | 1888 allow the key to be used for encryption. 1890 RSA_EXPORT RSA public key of length greater than 1891 512 bits which can be used for signing, 1892 or a key of 512 bits or shorter which 1893 can be used for encryption. | 1895 DHE_DSS DSS public key. 1897 DHE_DSS_EXPORT DSS public key. 1899 DHE_RSA RSA public key which can be used for 1900 signing. 1902 DHE_RSA_EXPORT RSA public key which can be used for 1903 signing. 1905 DH_DSS Diffie-Hellman key. The algorithm used 1906 to sign the certificate MUST be DSS. | 1908 DH_RSA Diffie-Hellman key. The algorithm used 1909 to sign the certificate MUST be RSA. | 1911 All certificate profiles, key and cryptographic formats are defined 1912 by the IETF PKIX working group [PKIX]. When a key usage extension is | 1913 present, the digitalSignature bit MUST be set for the key to be 1914 eligible for signing, as described above, and the keyEncipherment bit | 1915 MUST be present to allow encryption, as described above. The 1916 keyAgreement bit must be set on Diffie-Hellman certificates. 1918 As CipherSuites which specify new key exchange methods are specified 1919 for the TLS Protocol, they will imply certificate format and the 1920 required encoded keying information. 1922 Structure of this message: 1923 opaque ASN.1Cert<1..2^24-1>; 1925 struct { 1926 ASN.1Cert certificate_list<0..2^24-1>; 1927 } Certificate; 1928 certificate_list 1929 This is a sequence (chain) of X.509v3 certificates. The sender's 1930 certificate must come first in the list. Each following 1931 certificate must directly certify the one preceding it. Because 1932 certificate validation requires that root keys be distributed 1933 independently, the self-signed certificate which specifies the 1934 root certificate authority may optionally be omitted from the 1935 chain, under the assumption that the remote end must already 1936 possess it in order to validate it in any case. 1938 The same message type and structure will be used for the client's | 1939 response to a certificate request message. Note that a client MAY 1940 send no certificates if it does not have an appropriate certificate 1941 to send in response to the server's authentication request. 1943 Note: PKCS #7 [PKCS7] is not used as the format for the certificate 1944 vector because PKCS #6 [PKCS6] extended certificates are not 1945 used. Also PKCS #7 defines a SET rather than a SEQUENCE, making 1946 the task of parsing the list more difficult. 1948 7.4.3. Server key exchange message 1950 When this message will be sent: 1951 This message will be sent immediately after the server 1952 certificate message (or the server hello message, if this is an 1953 anonymous negotiation). 1955 The server key exchange message is sent by the server only when 1956 the server certificate message (if sent) does not contain enough 1957 data to allow the client to exchange a premaster secret. This is 1958 true for the following key exchange methods: 1960 RSA_EXPORT (if the public key in the server certificate is 1961 longer than 512 bits) 1962 DHE_DSS 1963 DHE_DSS_EXPORT 1964 DHE_RSA 1965 DHE_RSA_EXPORT 1966 DH_anon 1968 It is not legal to send the server key exchange message for the 1969 following key exchange methods: 1971 RSA 1972 RSA_EXPORT (when the public key in the server certificate is 1973 less than or equal to 512 bits in length) 1974 DH_DSS 1975 DH_RSA 1976 Meaning of this message: 1977 This message conveys cryptographic information to allow the 1978 client to communicate the premaster secret: either an RSA public 1979 key to encrypt the premaster secret with, or a Diffie-Hellman 1980 public key with which the client can complete a key exchange 1981 (with the result being the premaster secret.) 1983 As additional CipherSuites are defined for TLS which include new key | 1984 exchange algorithms, the server key exchange message will be sent if 1985 and only if the certificate type associated with the key exchange 1986 algorithm does not provide enough information for the client to 1987 exchange a premaster secret. 1989 Note: According to current US export law, RSA moduli larger than 512 1990 bits may not be used for key exchange in software exported from 1991 the US. With this message, the larger RSA keys encoded in 1992 certificates may be used to sign temporary shorter RSA keys for 1993 the RSA_EXPORT key exchange method. 1995 Structure of this message: 1996 enum { rsa, diffie_hellman } KeyExchangeAlgorithm; 1998 struct { 1999 opaque rsa_modulus<1..2^16-1>; 2000 opaque rsa_exponent<1..2^16-1>; 2001 } ServerRSAParams; 2003 rsa_modulus 2004 The modulus of the server's temporary RSA key. 2006 rsa_exponent 2007 The public exponent of the server's temporary RSA key. 2009 struct { 2010 opaque dh_p<1..2^16-1>; 2011 opaque dh_g<1..2^16-1>; 2012 opaque dh_Ys<1..2^16-1>; 2013 } ServerDHParams; /* Ephemeral DH parameters */ 2015 dh_p 2016 The prime modulus used for the Diffie-Hellman operation. 2018 dh_g 2019 The generator used for the Diffie-Hellman operation. 2021 dh_Ys 2022 The server's Diffie-Hellman public value (g^X mod p). 2024 struct { 2025 select (KeyExchangeAlgorithm) { 2026 case diffie_hellman: 2027 ServerDHParams params; 2028 Signature signed_params; 2029 case rsa: 2030 ServerRSAParams params; 2031 Signature signed_params; 2032 }; 2033 } ServerKeyExchange; 2035 struct { | 2036 select (KeyExchangeAlgorithm) { | 2037 case diffie_hellman: | 2038 ServerDHParams params; | 2039 case rsa: | 2040 ServerRSAParams params; | 2041 }; | 2042 } ServerParams; | 2044 params 2045 The server's key exchange parameters. 2047 signed_params 2048 For non-anonymous key exchanges, a hash of the corresponding 2049 params value, with the signature appropriate to that hash 2050 applied. 2052 md5_hash 2053 MD5(ClientHello.random + ServerHello.random + ServerParams); 2055 sha_hash 2056 SHA(ClientHello.random + ServerHello.random + ServerParams); 2058 enum { anonymous, rsa, dsa } SignatureAlgorithm; 2060 select (SignatureAlgorithm) | 2061 { | 2062 case anonymous: struct { }; | 2063 case rsa: 2064 digitally-signed struct { 2065 opaque md5_hash[16]; 2066 opaque sha_hash[20]; 2067 }; 2068 case dsa: 2069 digitally-signed struct { 2070 opaque sha_hash[20]; 2071 }; 2072 } Signature; 2074 7.4.4. Certificate request 2076 When this message will be sent: 2077 A non-anonymous server can optionally request a certificate from 2078 the client, if appropriate for the selected cipher suite. This 2079 message, if sent, will immediately follow the Server Key Exchange 2080 message (if it is sent; otherwise, the Server Certificate 2081 message). 2083 Structure of this message: 2084 enum { 2085 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), 2086 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), | 2087 fortezza_dms_RESERVED(20), | 2088 (255) 2089 } ClientCertificateType; 2091 opaque DistinguishedName<1..2^16-1>; 2093 struct { 2094 ClientCertificateType certificate_types<1..2^8-1>; 2095 DistinguishedName certificate_authorities<0..2^16-1>; | 2096 } CertificateRequest; 2098 certificate_types 2099 This field is a list of the types of certificates requested, | 2100 sorted in order of the server's preference. | 2102 certificate_authorities 2103 A list of the distinguished names of acceptable certificate 2104 authorities. These distinguished names may specify a desired 2105 distinguished name for a root CA or for a subordinate CA; 2106 thus, this message can be used both to describe known roots | 2107 and a desired authorization space. If the | 2108 certificate_authorities list is empty then the client MAY | 2109 send any certificate of the appropriate | 2110 ClientCertificateType, unless there is some external | 2111 arrangement to the contrary. | 2113 Note: Values listed as RESERVED may not be used. They were used in | 2114 SSLv3. 2116 Note: DistinguishedName is derived from [X509]. 2118 Note: It is a fatal handshake_failure alert for an anonymous server to 2119 request client authentication. | 2121 7.4.5. Server hello done 2123 When this message will be sent: 2124 The server hello done message is sent by the server to indicate 2125 the end of the server hello and associated messages. After 2126 sending this message the server will wait for a client response. 2128 Meaning of this message: 2129 This message means that the server is done sending messages to 2130 support the key exchange, and the client can proceed with its 2131 phase of the key exchange. 2133 Upon receipt of the server hello done message the client SHOULD | 2134 verify that the server provided a valid certificate if required 2135 and check that the server hello parameters are acceptable. 2137 Structure of this message: 2138 struct { } ServerHelloDone; 2140 7.4.6. Client certificate 2142 When this message will be sent: 2143 This is the first message the client can send after receiving a 2144 server hello done message. This message is only sent if the 2145 server requests a certificate. If no suitable certificate is 2146 available, the client should send a certificate message | 2147 containing no certificates: I.e. the certificate_list structure | 2148 should have a length of zero. If client authentication is | 2149 required by the server for the handshake to continue, it may 2150 respond with a fatal handshake failure alert. Client certificates 2151 are sent using the Certificate structure defined in Section 2152 7.4.2. 2154 Note: When using a static Diffie-Hellman based key exchange method | 2155 (DH_DSS or DH_RSA), if client authentication is requested, the 2156 Diffie-Hellman group and generator encoded in the client's 2157 certificate must match the server specified Diffie-Hellman 2158 parameters if the client's parameters are to be used for the key 2159 exchange. 2161 7.4.7. Client key exchange message 2163 When this message will be sent: 2164 This message is always sent by the client. It will immediately 2165 follow the client certificate message, if it is sent. Otherwise 2166 it will be the first message sent by the client after it receives 2167 the server hello done message. 2169 Meaning of this message: 2170 With this message, the premaster secret is set, either though 2171 direct transmission of the RSA-encrypted secret, or by the 2172 transmission of Diffie-Hellman parameters which will allow each 2173 side to agree upon the same premaster secret. When the key 2174 exchange method is DH_RSA or DH_DSS, client certification has 2175 been requested, and the client was able to respond with a 2176 certificate which contained a Diffie-Hellman public key whose 2177 parameters (group and generator) matched those specified by the | 2178 server in its certificate, this message MUST not contain any 2179 data. 2181 Structure of this message: 2182 The choice of messages depends on which key exchange method has 2183 been selected. See Section 7.4.3 for the KeyExchangeAlgorithm 2184 definition. 2186 struct { 2187 select (KeyExchangeAlgorithm) { 2188 case rsa: EncryptedPreMasterSecret; 2189 case diffie_hellman: ClientDiffieHellmanPublic; 2190 } exchange_keys; 2191 } ClientKeyExchange; 2193 7.4.7.1. RSA encrypted premaster secret message 2195 Meaning of this message: 2196 If RSA is being used for key agreement and authentication, the 2197 client generates a 48-byte premaster secret, encrypts it using 2198 the public key from the server's certificate or the temporary RSA 2199 key provided in a server key exchange message, and sends the 2200 result in an encrypted premaster secret message. This structure 2201 is a variant of the client key exchange message, not a message in 2202 itself. 2204 Structure of this message: 2205 struct { 2206 ProtocolVersion client_version; 2207 opaque random[46]; 2208 } PreMasterSecret; 2210 client_version 2211 The latest (newest) version supported by the client. This is 2212 used to detect version roll-back attacks. Upon receiving the | 2213 premaster secret, the server SHOULD check that this value 2214 matches the value transmitted by the client in the client 2215 hello message. 2217 random 2218 46 securely-generated random bytes. 2220 struct { 2221 public-key-encrypted PreMasterSecret pre_master_secret; 2222 } EncryptedPreMasterSecret; 2224 pre_master_secret | 2225 This random value is generated by the client and is used to | 2226 generate the master secret, as specified in Section 8.1. | 2228 Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used 2229 to attack a TLS server which is using PKCS#1 encoded RSA. The 2230 attack takes advantage of the fact that by failing in different 2231 ways, a TLS server can be coerced into revealing whether a 2232 particular message, when decrypted, is properly PKCS#1 formatted 2233 or not. 2235 The best way to avoid vulnerability to this attack is to treat 2236 incorrectly formatted messages in a manner indistinguishable from 2237 correctly formatted RSA blocks. Thus, when it receives an 2238 incorrectly formatted RSA block, a server should generate a 2239 random 48-byte value and proceed using it as the premaster 2240 secret. Thus, the server will act identically whether the | 2241 received RSA block is correctly encoded or not. | 2243 Implementation Note: public-key-encrypted data is represented as an | 2244 opaque vector <0..2^16-1> (see S. 4.7). Thus the RSA-encrypted | 2245 PreMaster Secret in a ClientKeyExchange is preceded by two length | 2246 bytes. These bytes are redundant in the case of RSA because the | 2247 EncryptedPreMasterSecret is the only data in the | 2248 ClientKeyExchange and its length can therefore be unambiguously | 2249 determined. The SSLv3 specification was not clear about the | 2250 encoding of public-key-encrypted data and therefore many SSLv3 | 2251 implementations do not include the the length bytes, encoding the | 2252 RSA encrypted data directly in the ClientKeyExchange message. | 2254 This specification requires correct encoding of the | 2255 EncryptedPreMasterSecret complete with length bytes. The | 2256 resulting PDU is incompatible with many SSLv3 implementations. | 2257 Implementors upgrading from SSLv3 must modify their | 2258 implementations to generate and accept the correct encoding. | 2259 Implementors who wish to be compatible with both SSLv3 and TLS | 2260 should make their implementation's behavior dependent on the | 2261 protocol version. | 2263 Implementation Note: It is now known that remote timing-based attacks | 2264 on SSL are possible, at least when the client and server are on | 2265 the same LAN. Accordingly, implementations which use static RSA | 2266 keys SHOULD use RSA blinding or some other anti-timing technique, | 2267 as described in [TIMING]. 2269 Note: The version number in the PreMasterSecret is that offered by the | 2270 client, NOT the version negotiated for the connection. This | 2271 feature is designed to prevent rollback attacks. Unfortunately, | 2272 many implementations use the negotiated version instead and | 2273 therefore checking the version number may lead to failure to | 2274 interoperate with such incorrect client implementations. Client | 2275 implementations MUST and Server implementations MAY check the | 2276 version number. In practice, since there are no significant known | 2277 security differences between TLS and SSLv3, rollback to SSLv3 is | 2278 not believed to be a serious security risk. Note that if servers | 2279 choose to to check the version number, they should randomize the | 2280 PreMasterSecret in case of error, rather than generate an alert, | 2281 in order to avoid variants on the Bleichenbacher attack. [KPR03] 2283 7.4.7.2. Client Diffie-Hellman public value 2285 Meaning of this message: 2286 This structure conveys the client's Diffie-Hellman public value 2287 (Yc) if it was not already included in the client's certificate. 2288 The encoding used for Yc is determined by the enumerated 2289 PublicValueEncoding. This structure is a variant of the client 2290 key exchange message, not a message in itself. 2292 Structure of this message: 2293 enum { implicit, explicit } PublicValueEncoding; 2295 implicit 2296 If the client certificate already contains a suitable Diffie- 2297 Hellman key, then Yc is implicit and does not need to be sent 2298 again. In this case, the Client Key Exchange message will be 2299 sent, but will be empty. 2301 explicit 2302 Yc needs to be sent. 2304 struct { 2305 select (PublicValueEncoding) { 2306 case implicit: struct { }; 2307 case explicit: opaque dh_Yc<1..2^16-1>; 2308 } dh_public; 2309 } ClientDiffieHellmanPublic; 2311 dh_Yc 2312 The client's Diffie-Hellman public value (Yc). 2314 7.4.8. Certificate verify 2316 When this message will be sent: 2317 This message is used to provide explicit verification of a client 2318 certificate. This message is only sent following a client 2319 certificate that has signing capability (i.e. all certificates 2320 except those containing fixed Diffie-Hellman parameters). When 2321 sent, it will immediately follow the client key exchange message. 2323 Structure of this message: 2324 struct { 2325 Signature signature; 2326 } CertificateVerify; 2328 The Signature type is defined in 7.4.3. 2330 CertificateVerify.signature.md5_hash 2331 MD5(handshake_messages); 2333 CertificateVerify.signature.sha_hash | 2334 SHA(handshake_messages); 2336 Here handshake_messages refers to all handshake messages sent or 2337 received starting at client hello up to but not including this 2338 message, including the type and length fields of the handshake 2339 messages. This is the concatenation of all the Handshake structures 2340 as defined in 7.4 exchanged thus far. 2342 7.4.9. Finished 2344 When this message will be sent: 2345 A finished message is always sent immediately after a change 2346 cipher spec message to verify that the key exchange and 2347 authentication processes were successful. It is essential that a 2348 change cipher spec message be received between the other 2349 handshake messages and the Finished message. 2351 Meaning of this message: 2352 The finished message is the first protected with the just- 2353 negotiated algorithms, keys, and secrets. Recipients of finished | 2354 messages MUST verify that the contents are correct. Once a side 2355 has sent its Finished message and received and validated the 2356 Finished message from its peer, it may begin to send and receive 2357 application data over the connection. 2359 struct { 2360 opaque verify_data[12]; 2361 } Finished; 2363 verify_data 2364 PRF(master_secret, finished_label, MD5(handshake_messages) + 2365 SHA-1(handshake_messages)) [0..11]; 2367 finished_label 2368 For Finished messages sent by the client, the string "client 2369 finished". For Finished messages sent by the server, the 2370 string "server finished". 2372 handshake_messages 2373 All of the data from all handshake messages up to but not 2374 including this message. This is only data visible at the 2375 handshake layer and does not include record layer headers. 2376 This is the concatenation of all the Handshake structures as 2377 defined in 7.4 exchanged thus far. 2379 It is a fatal error if a finished message is not preceded by a change 2380 cipher spec message at the appropriate point in the handshake. 2382 The value handshake_messages includes all handshake messages starting | 2383 at client hello up to, but not including, this finished message. This 2384 may be different from handshake_messages in Section 7.4.8 because it 2385 would include the certificate verify message (if sent). Also, the 2386 handshake_messages for the finished message sent by the client will 2387 be different from that for the finished message sent by the server, 2388 because the one which is sent second will include the prior one. 2390 Note: Change cipher spec messages, alerts and any other record types 2391 are not handshake messages and are not included in the hash 2392 computations. Also, Hello Request messages are omitted from 2393 handshake hashes. 2395 8. Cryptographic computations 2397 In order to begin connection protection, the TLS Record Protocol 2398 requires specification of a suite of algorithms, a master secret, and 2399 the client and server random values. The authentication, encryption, 2400 and MAC algorithms are determined by the cipher_suite selected by the 2401 server and revealed in the server hello message. The compression 2402 algorithm is negotiated in the hello messages, and the random values 2403 are exchanged in the hello messages. All that remains is to calculate 2404 the master secret. 2406 8.1. Computing the master secret 2408 For all key exchange methods, the same algorithm is used to convert 2409 the pre_master_secret into the master_secret. The pre_master_secret 2410 should be deleted from memory once the master_secret has been 2411 computed. 2413 master_secret = PRF(pre_master_secret, "master secret", 2414 ClientHello.random + ServerHello.random) 2415 [0..47]; 2417 The master secret is always exactly 48 bytes in length. The length of 2418 the premaster secret will vary depending on key exchange method. 2420 8.1.1. RSA 2422 When RSA is used for server authentication and key exchange, a 2423 48-byte pre_master_secret is generated by the client, encrypted under 2424 the server's public key, and sent to the server. The server uses its 2425 private key to decrypt the pre_master_secret. Both parties then 2426 convert the pre_master_secret into the master_secret, as specified 2427 above. 2429 RSA digital signatures are performed using PKCS #1 [PKCS1] block type 2430 1. RSA public key encryption is performed using PKCS #1 block type 2. 2432 8.1.2. Diffie-Hellman 2434 A conventional Diffie-Hellman computation is performed. The 2435 negotiated key (Z) is used as the pre_master_secret, and is converted 2436 into the master_secret, as specified above. Leading 0 bytes of Z are | 2437 stripped before it is used as the pre_master_secret. 2439 Note: Diffie-Hellman parameters are specified by the server, and may 2440 be either ephemeral or contained within the server's certificate. 2442 9. Mandatory Cipher Suites 2444 In the absence of an application profile standard specifying 2445 otherwise, a TLS compliant application MUST implement the cipher | 2446 suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. | 2448 The 40-bit cipher suites are known to be susceptible to exhaustive | 2449 search attack by commercial attackers. Implementations of this | 2450 document SHOULD disable them by default if they are supported at all. | 2451 A future version of this document may remove them entirely. 2453 10. Application data protocol 2455 Application data messages are carried by the Record Layer and are 2456 fragmented, compressed and encrypted based on the current connection 2457 state. The messages are treated as transparent data to the record 2458 layer. 2460 A. Protocol constant values 2462 This section describes protocol types and constants. 2464 A.1. Record layer 2466 struct { 2467 uint8 major, minor; 2468 } ProtocolVersion; 2470 ProtocolVersion version = { 3, 2 }; /* TLS v1.1 */ | 2472 enum { 2473 change_cipher_spec(20), alert(21), handshake(22), 2474 application_data(23), (255) 2475 } ContentType; 2477 struct { 2478 ContentType type; 2479 ProtocolVersion version; 2480 uint16 length; 2481 opaque fragment[TLSPlaintext.length]; 2482 } TLSPlaintext; 2484 struct { 2485 ContentType type; 2486 ProtocolVersion version; 2487 uint16 length; 2488 opaque fragment[TLSCompressed.length]; 2489 } TLSCompressed; 2491 struct { 2492 ContentType type; 2493 ProtocolVersion version; 2494 uint16 length; 2495 select (CipherSpec.cipher_type) { 2496 case stream: GenericStreamCipher; 2497 case block: GenericBlockCipher; 2498 } fragment; 2499 } TLSCiphertext; 2501 stream-ciphered struct { 2502 opaque content[TLSCompressed.length]; 2503 opaque MAC[CipherSpec.hash_size]; 2504 } GenericStreamCipher; 2506 block-ciphered struct { 2507 opaque IV[CipherSpec.block_length]; | 2508 opaque content[TLSCompressed.length]; 2509 opaque MAC[CipherSpec.hash_size]; 2510 uint8 padding[GenericBlockCipher.padding_length]; 2511 uint8 padding_length; 2512 } GenericBlockCipher; 2514 A.2. Change cipher specs message 2516 struct { 2517 enum { change_cipher_spec(1), (255) } type; 2518 } ChangeCipherSpec; 2520 A.3. Alert messages 2522 enum { warning(1), fatal(2), (255) } AlertLevel; 2524 enum { 2525 close_notify(0), 2526 unexpected_message(10), 2527 bad_record_mac(20), 2528 decryption_failed(21), 2529 record_overflow(22), 2530 decompression_failure(30), 2531 handshake_failure(40), 2532 no_certificate_RESERVED (41), | 2533 bad_certificate(42), 2534 unsupported_certificate(43), 2535 certificate_revoked(44), 2536 certificate_expired(45), 2537 certificate_unknown(46), 2538 illegal_parameter(47), 2539 unknown_ca(48), 2540 access_denied(49), 2541 decode_error(50), 2542 decrypt_error(51), 2543 export_restriction(60), 2544 protocol_version(70), 2545 insufficient_security(71), 2546 internal_error(80), 2547 user_canceled(90), 2548 no_renegotiation(100), 2549 (255) 2550 } AlertDescription; 2552 struct { 2553 AlertLevel level; 2554 AlertDescription description; 2555 } Alert; 2556 A.4. Handshake protocol 2558 enum { 2559 hello_request(0), client_hello(1), server_hello(2), 2560 certificate(11), server_key_exchange (12), 2561 certificate_request(13), server_hello_done(14), 2562 certificate_verify(15), client_key_exchange(16), 2563 finished(20), (255) 2564 } HandshakeType; 2566 struct { 2567 HandshakeType msg_type; 2568 uint24 length; 2569 select (HandshakeType) { 2570 case hello_request: HelloRequest; 2571 case client_hello: ClientHello; 2572 case server_hello: ServerHello; 2573 case certificate: Certificate; 2574 case server_key_exchange: ServerKeyExchange; 2575 case certificate_request: CertificateRequest; 2576 case server_hello_done: ServerHelloDone; 2577 case certificate_verify: CertificateVerify; 2578 case client_key_exchange: ClientKeyExchange; 2579 case finished: Finished; 2580 } body; 2581 } Handshake; 2583 A.4.1. Hello messages 2585 struct { } HelloRequest; 2587 struct { 2588 uint32 gmt_unix_time; 2589 opaque random_bytes[28]; 2590 } Random; 2592 opaque SessionID<0..32>; 2594 uint8 CipherSuite[2]; 2596 enum { null(0), (255) } CompressionMethod; 2598 struct { 2599 ProtocolVersion client_version; 2600 Random random; 2601 SessionID session_id; 2602 CipherSuite cipher_suites<2..2^16-1>; 2603 CompressionMethod compression_methods<1..2^8-1>; 2604 } ClientHello; 2606 struct { 2607 ProtocolVersion server_version; 2608 Random random; 2609 SessionID session_id; 2610 CipherSuite cipher_suite; 2611 CompressionMethod compression_method; 2612 } ServerHello; 2614 A.4.2. Server authentication and key exchange messages 2616 opaque ASN.1Cert<2^24-1>; 2618 struct { 2619 ASN.1Cert certificate_list<0..2^24-1>; | 2620 } Certificate; 2622 enum { rsa, diffie_hellman } KeyExchangeAlgorithm; 2624 struct { 2625 opaque RSA_modulus<1..2^16-1>; 2626 opaque RSA_exponent<1..2^16-1>; 2627 } ServerRSAParams; 2629 struct { 2630 opaque DH_p<1..2^16-1>; 2631 opaque DH_g<1..2^16-1>; 2632 opaque DH_Ys<1..2^16-1>; 2633 } ServerDHParams; 2635 struct { 2636 select (KeyExchangeAlgorithm) { 2637 case diffie_hellman: 2638 ServerDHParams params; 2639 Signature signed_params; 2640 case rsa: 2641 ServerRSAParams params; 2642 Signature signed_params; 2643 }; 2644 } ServerKeyExchange; 2646 enum { anonymous, rsa, dsa } SignatureAlgorithm; | 2648 struct { | 2649 select (KeyExchangeAlgorithm) { | 2650 case diffie_hellman: | 2651 ServerDHParams params; | 2652 case rsa: | 2653 ServerRSAParams params; | 2654 }; | 2655 } ServerParams; | 2657 select (SignatureAlgorithm) 2658 { case anonymous: struct { }; 2659 case rsa: 2660 digitally-signed struct { 2661 opaque md5_hash[16]; 2662 opaque sha_hash[20]; 2663 }; 2664 case dsa: 2665 digitally-signed struct { 2666 opaque sha_hash[20]; 2667 }; 2668 } Signature; 2670 enum { 2671 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), 2672 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), | 2673 fortezza_dms_RESERVED(20), | 2674 (255) | 2675 } ClientCertificateType; 2677 opaque DistinguishedName<1..2^16-1>; 2679 struct { 2680 ClientCertificateType certificate_types<1..2^8-1>; 2681 DistinguishedName certificate_authorities<0..2^16-1>; | 2682 } CertificateRequest; 2684 struct { } ServerHelloDone; 2686 A.4.3. Client authentication and key exchange messages 2688 struct { 2689 select (KeyExchangeAlgorithm) { 2690 case rsa: EncryptedPreMasterSecret; 2691 case diffie_hellman: DiffieHellmanClientPublicValue; 2692 } exchange_keys; 2693 } ClientKeyExchange; 2695 struct { 2696 ProtocolVersion client_version; 2697 opaque random[46]; 2698 } PreMasterSecret; 2699 struct { 2700 public-key-encrypted PreMasterSecret pre_master_secret; 2701 } EncryptedPreMasterSecret; 2703 enum { implicit, explicit } PublicValueEncoding; 2705 struct { 2706 select (PublicValueEncoding) { 2707 case implicit: struct {}; 2708 case explicit: opaque DH_Yc<1..2^16-1>; 2709 } dh_public; 2710 } ClientDiffieHellmanPublic; 2712 struct { 2713 Signature signature; 2714 } CertificateVerify; 2716 A.4.4. Handshake finalization message 2718 struct { 2719 opaque verify_data[12]; 2720 } Finished; 2722 A.5. The CipherSuite 2724 The following values define the CipherSuite codes used in the client 2725 hello and server hello messages. 2727 A CipherSuite defines a cipher specification supported in TLS Version | 2728 1.1. 2730 TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a 2731 TLS connection during the first handshake on that channel, but must 2732 not be negotiated, as it provides no more protection than an 2733 unsecured connection. 2735 CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; 2737 The following CipherSuite definitions require that the server provide 2738 an RSA certificate that can be used for key exchange. The server may 2739 request either an RSA or a DSS signature-capable certificate in the 2740 certificate request message. 2742 CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; 2743 CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; 2744 CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; 2745 CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; 2746 CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; 2747 CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; 2748 CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; 2749 CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; 2750 CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; 2751 CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; 2753 The following CipherSuite definitions are used for server- 2754 authenticated (and optionally client-authenticated) Diffie-Hellman. 2755 DH denotes cipher suites in which the server's certificate contains 2756 the Diffie-Hellman parameters signed by the certificate authority 2757 (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman 2758 parameters are signed by a DSS or RSA certificate, which has been 2759 signed by the CA. The signing algorithm used is specified after the 2760 DH or DHE parameter. The server can request an RSA or DSS signature- 2761 capable certificate from the client for client authentication or it 2762 may request a Diffie-Hellman certificate. Any Diffie-Hellman 2763 certificate provided by the client must use the parameters (group and 2764 generator) described by the server. 2766 CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; 2767 CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; 2768 CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; 2769 CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; 2770 CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; 2771 CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; 2772 CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; 2773 CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; 2774 CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; 2775 CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; 2776 CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; 2777 CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; 2779 The following cipher suites are used for completely anonymous Diffie- 2780 Hellman communications in which neither party is authenticated. Note 2781 that this mode is vulnerable to man-in-the-middle attacks and is 2782 therefore deprecated. 2784 CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; 2785 CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; 2786 CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; 2787 CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; 2788 CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; 2790 Note: All cipher suites whose first byte is 0xFF are considered 2791 private and can be used for defining local/experimental 2792 algorithms. Interoperability of such types is a local matter. 2794 Note: Additional cipher suites can be registered by publishing an RFC 2795 which specifies the cipher suites, including the necessary TLS 2796 protocol information, including message encoding, premaster 2797 secret derivation, symmetric encryption and MAC calculation and 2798 appropriate reference information for the algorithms involved. 2799 The RFC editor's office may, at its discretion, choose to publish 2800 specifications for cipher suites which are not completely 2801 described (e.g., for classified algorithms) if it finds the 2802 specification to be of technical interest and completely 2803 specified. 2805 Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are 2806 reserved to avoid collision with Fortezza-based cipher suites in 2807 SSL 3. 2809 A.6. The Security Parameters 2811 These security parameters are determined by the TLS Handshake 2812 Protocol and provided as parameters to the TLS Record Layer in order 2813 to initialize a connection state. SecurityParameters includes: 2815 enum { null(0), (255) } CompressionMethod; 2817 enum { server, client } ConnectionEnd; 2819 enum { null, rc4, rc2, des, 3des, des40, idea } 2820 BulkCipherAlgorithm; 2822 enum { stream, block } CipherType; 2824 enum { true, false } IsExportable; 2826 enum { null, md5, sha } MACAlgorithm; 2828 /* The algorithms specified in CompressionMethod, 2829 BulkCipherAlgorithm, and MACAlgorithm may be added to. */ 2831 struct { 2832 ConnectionEnd entity; 2833 BulkCipherAlgorithm bulk_cipher_algorithm; 2834 CipherType cipher_type; 2835 uint8 key_size; 2836 uint8 key_material_length; 2837 IsExportable is_exportable; 2838 MACAlgorithm mac_algorithm; 2839 uint8 hash_size; 2840 CompressionMethod compression_algorithm; 2841 opaque master_secret[48]; 2842 opaque client_random[32]; 2843 opaque server_random[32]; 2844 } SecurityParameters; 2845 B. Glossary 2847 application protocol 2848 An application protocol is a protocol that normally layers 2849 directly on top of the transport layer (e.g., TCP/IP). Examples 2850 include HTTP, TELNET, FTP, and SMTP. 2852 asymmetric cipher 2853 See public key cryptography. 2855 authentication 2856 Authentication is the ability of one entity to determine the 2857 identity of another entity. 2859 block cipher 2860 A block cipher is an algorithm that operates on plaintext in 2861 groups of bits, called blocks. 64 bits is a common block size. 2863 bulk cipher 2864 A symmetric encryption algorithm used to encrypt large quantities 2865 of data. 2867 cipher block chaining (CBC) 2868 CBC is a mode in which every plaintext block encrypted with a 2869 block cipher is first exclusive-ORed with the previous ciphertext 2870 block (or, in the case of the first block, with the 2871 initialization vector). For decryption, every block is first 2872 decrypted, then exclusive-ORed with the previous ciphertext block 2873 (or IV). 2875 certificate 2876 As part of the X.509 protocol (a.k.a. ISO Authentication 2877 framework), certificates are assigned by a trusted Certificate 2878 Authority and provide a strong binding between a party's identity 2879 or some other attributes and its public key. 2881 client 2882 The application entity that initiates a TLS connection to a 2883 server. This may or may not imply that the client initiated the 2884 underlying transport connection. The primary operational 2885 difference between the server and client is that the server is 2886 generally authenticated, while the client is only optionally 2887 authenticated. 2889 client write key 2890 The key used to encrypt data written by the client. 2892 client write MAC secret 2893 The secret data used to authenticate data written by the client. 2895 connection 2896 A connection is a transport (in the OSI layering model 2897 definition) that provides a suitable type of service. For TLS, 2898 such connections are peer to peer relationships. The connections 2899 are transient. Every connection is associated with one session. 2901 Data Encryption Standard 2902 DES is a very widely used symmetric encryption algorithm. DES is 2903 a block cipher with a 56 bit key and an 8 byte block size. Note 2904 that in TLS, for key generation purposes, DES is treated as 2905 having an 8 byte key length (64 bits), but it still only provides 2906 56 bits of protection. (The low bit of each key byte is presumed 2907 to be set to produce odd parity in that key byte.) DES can also 2908 be operated in a mode where three independent keys and three 2909 encryptions are used for each block of data; this uses 168 bits 2910 of key (24 bytes in the TLS key generation method) and provides 2911 the equivalent of 112 bits of security. [DES], [3DES] 2913 Digital Signature Standard (DSS) 2914 A standard for digital signing, including the Digital Signing 2915 Algorithm, approved by the National Institute of Standards and 2916 Technology, defined in NIST FIPS PUB 186, "Digital Signature 2917 Standard," published May, 1994 by the U.S. Dept. of Commerce. 2918 [DSS] 2920 digital signatures | 2921 Digital signatures utilize public key cryptography and one-way 2922 hash functions to produce a signature of the data that can be 2923 authenticated, and is difficult to forge or repudiate. 2925 handshake 2926 An initial negotiation between client and server that establishes 2927 the parameters of their transactions. 2929 Initialization Vector (IV) 2930 When a block cipher is used in CBC mode, the initialization 2931 vector is exclusive-ORed with the first plaintext block prior to 2932 encryption. 2934 IDEA 2935 A 64-bit block cipher designed by Xuejia Lai and James Massey. 2936 [IDEA] 2937 Message Authentication Code (MAC) 2938 A Message Authentication Code is a one-way hash computed from a 2939 message and some secret data. It is difficult to forge without 2940 knowing the secret data. Its purpose is to detect if the message 2941 has been altered. 2943 master secret 2944 Secure secret data used for generating encryption keys, MAC 2945 secrets, and IVs. 2947 MD5 2948 MD5 is a secure hashing function that converts an arbitrarily 2949 long data stream into a digest of fixed size (16 bytes). [MD5] 2951 public key cryptography 2952 A class of cryptographic techniques employing two-key ciphers. 2953 Messages encrypted with the public key can only be decrypted with 2954 the associated private key. Conversely, messages signed with the 2955 private key can be verified with the public key. 2957 one-way hash function 2958 A one-way transformation that converts an arbitrary amount of 2959 data into a fixed-length hash. It is computationally hard to 2960 reverse the transformation or to find collisions. MD5 and SHA are 2961 examples of one-way hash functions. 2963 RC2 2964 A block cipher developed by Ron Rivest at RSA Data Security, Inc. 2965 [RSADSI] described in [RC2]. 2967 RC4 2968 A stream cipher licensed by RSA Data Security [RSADSI]. A 2969 compatible cipher is described in [RC4]. 2971 RSA 2972 A very widely used public-key algorithm that can be used for 2973 either encryption or digital signing. [RSA] 2975 salt 2976 Non-secret random data used to make export encryption keys resist 2977 precomputation attacks. 2979 server 2980 The server is the application entity that responds to requests 2981 for connections from clients. See also under client. 2983 session 2984 A TLS session is an association between a client and a server. 2985 Sessions are created by the handshake protocol. Sessions define a 2986 set of cryptographic security parameters, which can be shared 2987 among multiple connections. Sessions are used to avoid the 2988 expensive negotiation of new security parameters for each 2989 connection. 2991 session identifier 2992 A session identifier is a value generated by a server that 2993 identifies a particular session. 2995 server write key 2996 The key used to encrypt data written by the server. 2998 server write MAC secret 2999 The secret data used to authenticate data written by the server. 3001 SHA 3002 The Secure Hash Algorithm is defined in FIPS PUB 180-1. It 3003 produces a 20-byte output. Note that all references to SHA 3004 actually use the modified SHA-1 algorithm. [SHA] 3006 SSL 3007 Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on 3008 SSL Version 3.0 3010 stream cipher 3011 An encryption algorithm that converts a key into a 3012 cryptographically-strong keystream, which is then exclusive-ORed 3013 with the plaintext. 3015 symmetric cipher | 3016 See bulk cipher. 3018 Transport Layer Security (TLS) 3019 This protocol; also, the Transport Layer Security working group 3020 of the Internet Engineering Task Force (IETF). See "Comments" at 3021 the end of this document. 3023 C. CipherSuite definitions 3025 CipherSuite Is Key Cipher Hash 3026 Exportable Exchange 3028 TLS_NULL_WITH_NULL_NULL * NULL NULL NULL 3029 TLS_RSA_WITH_NULL_MD5 * RSA NULL MD5 3030 TLS_RSA_WITH_NULL_SHA * RSA NULL SHA 3031 TLS_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5 3032 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 3033 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA 3034 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5 3035 TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA 3036 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA 3037 TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA 3038 TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA 3039 TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA 3040 TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA 3041 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA 3042 TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA 3043 TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA 3044 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA 3045 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA 3046 TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA 3047 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA 3048 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA 3049 TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA 3050 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA 3051 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5 3052 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 3053 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA 3054 TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA 3055 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA 3057 * Indicates IsExportable is True 3059 Key 3060 Exchange 3061 Algorithm Description Key size limit 3063 DHE_DSS Ephemeral DH with DSS signatures None 3064 DHE_DSS_EXPORT Ephemeral DH with DSS signatures DH = 512 bits 3065 DHE_RSA Ephemeral DH with RSA signatures None 3066 DHE_RSA_EXPORT Ephemeral DH with RSA signatures DH = 512 bits, 3067 RSA = none 3068 DH_anon Anonymous DH, no signatures None 3069 DH_anon_EXPORT Anonymous DH, no signatures DH = 512 bits 3070 DH_DSS DH with DSS-based certificates None 3071 DH_DSS_EXPORT DH with DSS-based certificates DH = 512 bits 3072 DH_RSA DH with RSA-based certificates None 3073 DH_RSA_EXPORT DH with RSA-based certificates DH = 512 bits, 3074 RSA = none 3075 NULL No key exchange N/A 3076 RSA RSA key exchange None 3077 RSA_EXPORT RSA key exchange RSA = 512 bits 3079 Key size limit 3080 The key size limit gives the size of the largest public key that 3081 can be legally used for encryption or key agreement in | 3082 cipher suites that are exportable. | 3084 Key Expanded Effective IV Block 3085 Cipher Type Material Key Material Key Bits Size Size 3087 NULL * Stream 0 0 0 0 N/A 3088 IDEA_CBC Block 16 16 128 8 8 3089 RC2_CBC_40 * Block 5 16 40 8 8 3090 RC4_40 * Stream 5 16 40 0 N/A 3091 RC4_128 Stream 16 16 128 0 N/A 3092 DES40_CBC * Block 5 8 40 8 8 3093 DES_CBC Block 8 8 56 8 8 3094 3DES_EDE_CBC Block 24 24 168 8 8 3096 * Indicates IsExportable is true. 3098 Type 3099 Indicates whether this is a stream cipher or a block cipher 3100 running in CBC mode. 3102 Key Material 3103 The number of bytes from the key_block that are used for 3104 generating the write keys. 3106 Expanded Key Material 3107 The number of bytes actually fed into the encryption algorithm 3109 Effective Key Bits 3110 How much entropy material is in the key material being fed into 3111 the encryption routines. 3113 IV Size 3114 How much data needs to be generated for the initialization 3115 vector. Zero for stream ciphers; equal to the block size for 3116 block ciphers. 3118 Block Size 3119 The amount of data a block cipher enciphers in one chunk; a 3120 block cipher running in CBC mode can only encrypt an even 3121 multiple of its block size. 3123 Hash Hash Padding 3124 function Size Size 3125 NULL 0 0 3126 MD5 16 48 3127 SHA 20 40 3128 D. Implementation Notes 3130 The TLS protocol cannot prevent many common security mistakes. This 3131 section provides several recommendations to assist implementors. 3133 D.1. Temporary RSA keys 3135 US Export restrictions limit RSA keys used for encryption to 512 3136 bits, but do not place any limit on lengths of RSA keys used for 3137 signing operations. Certificates often need to be larger than 512 3138 bits, since 512-bit RSA keys are not secure enough for high-value 3139 transactions or for applications requiring long-term security. Some 3140 certificates are also designated signing-only, in which case they 3141 cannot be used for key exchange. 3143 When the public key in the certificate cannot be used for encryption, 3144 the server signs a temporary RSA key, which is then exchanged. In 3145 exportable applications, the temporary RSA key should be the maximum 3146 allowable length (i.e., 512 bits). Because 512-bit RSA keys are 3147 relatively insecure, they should be changed often. For typical 3148 electronic commerce applications, it is suggested that keys be 3149 changed daily or every 500 transactions, and more often if possible. 3150 Note that while it is acceptable to use the same temporary key for 3151 multiple transactions, it must be signed each time it is used. 3153 RSA key generation is a time-consuming process. In many cases, a low- 3154 priority process can be assigned the task of key generation. 3156 Whenever a new key is completed, the existing temporary key can be 3157 replaced with the new one. 3159 D.2. Random Number Generation and Seeding 3161 TLS requires a cryptographically-secure pseudorandom number generator 3162 (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs 3163 based on secure hash operations, most notably MD5 and/or SHA, are 3164 acceptable, but cannot provide more security than the size of the 3165 random number generator state. (For example, MD5-based PRNGs usually 3166 provide 128 bits of state.) 3168 To estimate the amount of seed material being produced, add the 3169 number of bits of unpredictable information in each seed byte. For 3170 example, keystroke timing values taken from a PC compatible's 18.2 Hz 3171 timer provide 1 or 2 secure bits each, even though the total size of 3172 the counter value is 16 bits or more. To seed a 128-bit PRNG, one 3173 would thus require approximately 100 such timer values. 3175 D.3. Certificates and authentication 3176 Implementations are responsible for verifying the integrity of 3177 certificates and should generally support certificate revocation 3178 messages. Certificates should always be verified to ensure proper 3179 signing by a trusted Certificate Authority (CA). The selection and 3180 addition of trusted CAs should be done very carefully. Users should 3181 be able to view information about the certificate and root CA. 3183 D.4. CipherSuites 3185 TLS supports a range of key sizes and security levels, including some 3186 which provide no or minimal security. A proper implementation will 3187 probably not support many cipher suites. For example, 40-bit 3188 encryption is easily broken, so implementations requiring strong 3189 security should not allow 40-bit keys. Similarly, anonymous Diffie- 3190 Hellman is strongly discouraged because it cannot prevent man-in-the- 3191 middle attacks. Applications should also enforce minimum and maximum 3192 key sizes. For example, certificate chains containing 512-bit RSA 3193 keys or signatures are not appropriate for high-security 3194 applications. 3196 E. Backward Compatibility With SSL 3198 For historical reasons and in order to avoid a profligate consumption 3199 of reserved port numbers, application protocols which are secured by | 3200 TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same 3201 connection port: for example, the https protocol (HTTP secured by SSL 3202 or TLS) uses port 443 regardless of which security protocol it is 3203 using. Thus, some mechanism must be determined to distinguish and 3204 negotiate among the various protocols. 3206 TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting | 3207 both is easy. TLS clients who wish to negotiate with such older | 3208 servers SHOULD send client hello messages using the SSL 3.0 record | 3209 format and client hello structure, sending {3, 2} for the version | 3210 field to note that they support TLS 1.1. If the server supports only | 3211 TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello; | 3212 if it supports TLS 1.1 it will respond with a TLS 1.1 server hello. | 3213 The negotiation then proceeds as appropriate for the negotiated 3214 protocol. 3216 Similarly, a TLS 1.1 server which wishes to interoperate with TLS | 3217 1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages | 3218 and respond with a SSL 3.0 server hello if an SSL 3.0 client hello | 3219 with a version field of {3, 0} is received, denoting that this client | 3220 does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a | 3221 version field of {3, 1} is received, the server SHOULD respond with a | 3222 TLS 1.0 hello with a version field of {3, 1}. 3224 Whenever a client already knows the highest protocol known to a | 3225 server (for example, when resuming a session), it SHOULD initiate the 3226 connection in that native protocol. 3228 TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL | 3229 Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept 3230 either client hello format if they wish to support SSL 2.0 clients on 3231 the same connection port. The only deviations from the Version 2.0 3232 specification are the ability to specify a version with a value of 3233 three and the support for more ciphering types in the CipherSpec. 3235 Warning: The ability to send Version 2.0 client hello messages will be 3236 phased out with all due haste. Implementors SHOULD make every | 3237 effort to move forward as quickly as possible. Version 3.0 3238 provides better mechanisms for moving to newer versions. 3240 The following cipher specifications are carryovers from SSL Version 3241 2.0. These are assumed to use RSA for key exchange and 3242 authentication. 3244 V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; 3245 V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; 3246 V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; 3247 V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 3248 = { 0x04,0x00,0x80 }; 3249 V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 }; 3250 V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 }; 3251 V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; 3253 Cipher specifications native to TLS can be included in Version 2.0 3254 client hello messages using the syntax below. Any V2CipherSpec 3255 element with its first byte equal to zero will be ignored by Version | 3256 2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD 3257 also include the TLS equivalent (see Appendix A.5): 3259 V2CipherSpec (see TLS name) = { 0x00, CipherSuite }; 3261 E.1. Version 2 client hello 3263 The Version 2.0 client hello message is presented below using this 3264 document's presentation model. The true definition is still assumed | 3265 to be the SSL Version 2.0 specification. Note that this message MUST | 3266 be sent directly on the wire, not wrapped as an SSLv3 record 3268 uint8 V2CipherSpec[3]; 3270 struct { 3271 uint16 msg_length; | 3272 uint8 msg_type; 3273 Version version; 3274 uint16 cipher_spec_length; 3275 uint16 session_id_length; 3276 uint16 challenge_length; 3277 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; 3278 opaque session_id[V2ClientHello.session_id_length]; 3279 opaque challenge[V2ClientHello.challenge_length; | 3280 } V2ClientHello; 3282 msg_length | 3283 This field is the length of the following data in bytes. The high | 3284 bit MUST be 1 and is not part of the length. | 3286 msg_type 3287 This field, in conjunction with the version field, identifies a | 3288 version 2 client hello message. The value SHOULD be one (1). 3290 version 3291 The highest version of the protocol supported by the client 3292 (equals ProtocolVersion.version, see Appendix A.1). 3294 cipher_spec_length 3295 This field is the total length of the field cipher_specs. It | 3296 cannot be zero and MUST be a multiple of the V2CipherSpec length 3297 (3). 3299 session_id_length 3300 This field MUST have a value of zero. | 3302 challenge_length 3303 The length in bytes of the client's challenge to the server to | 3304 authenticate itself. When using the SSLv2 backward compatible | 3305 handshake the client MUST use a 32-byte challenge. 3307 cipher_specs 3308 This is a list of all CipherSpecs the client is willing and able | 3309 to use. There MUST be at least one CipherSpec acceptable to the 3310 server. 3312 session_id 3313 This field MUST be empty. | 3315 challenge 3316 The client challenge to the server for the server to identify 3317 itself is a (nearly) arbitrary length random. The TLS server will 3318 right justify the challenge data to become the ClientHello.random 3319 data (padded with leading zeroes, if necessary), as specified in 3320 this protocol specification. If the length of the challenge is 3321 greater than 32 bytes, only the last 32 bytes are used. It is 3322 legitimate (but not necessary) for a V3 server to reject a V2 3323 ClientHello that has fewer than 16 bytes of challenge data. 3325 Note: Requests to resume a TLS session MUST use a TLS client hello. | 3327 E.2. Avoiding man-in-the-middle version rollback 3329 When TLS clients fall back to Version 2.0 compatibility mode, they | 3330 SHOULD use special PKCS #1 block formatting. This is done so that TLS 3331 servers will reject Version 2.0 sessions with TLS-capable clients. 3333 When TLS clients are in Version 2.0 compatibility mode, they set the 3334 right-hand (least-significant) 8 random bytes of the PKCS padding 3335 (not including the terminal null of the padding) for the RSA 3336 encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY 3337 to 0x03 (the other padding bytes are random). After decrypting the | 3338 ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an 3339 error if these eight padding bytes are 0x03. Version 2.0 servers 3340 receiving blocks padded in this manner will proceed normally. 3342 F. Security analysis 3344 The TLS protocol is designed to establish a secure connection between 3345 a client and a server communicating over an insecure channel. This 3346 document makes several traditional assumptions, including that 3347 attackers have substantial computational resources and cannot obtain 3348 secret information from sources outside the protocol. Attackers are 3349 assumed to have the ability to capture, modify, delete, replay, and 3350 otherwise tamper with messages sent over the communication channel. 3351 This appendix outlines how TLS has been designed to resist a variety 3352 of attacks. 3354 F.1. Handshake protocol 3356 The handshake protocol is responsible for selecting a CipherSpec and 3357 generating a Master Secret, which together comprise the primary 3358 cryptographic parameters associated with a secure session. The 3359 handshake protocol can also optionally authenticate parties who have 3360 certificates signed by a trusted certificate authority. 3362 F.1.1. Authentication and key exchange 3364 TLS supports three authentication modes: authentication of both 3365 parties, server authentication with an unauthenticated client, and 3366 total anonymity. Whenever the server is authenticated, the channel is 3367 secure against man-in-the-middle attacks, but completely anonymous 3368 sessions are inherently vulnerable to such attacks. Anonymous 3369 servers cannot authenticate clients. If the server is authenticated, 3370 its certificate message must provide a valid certificate chain 3371 leading to an acceptable certificate authority. Similarly, 3372 authenticated clients must supply an acceptable certificate to the 3373 server. Each party is responsible for verifying that the other's 3374 certificate is valid and has not expired or been revoked. 3376 The general goal of the key exchange process is to create a 3377 pre_master_secret known to the communicating parties and not to 3378 attackers. The pre_master_secret will be used to generate the 3379 master_secret (see Section 8.1). The master_secret is required to | 3380 generate the finished messages, encryption keys, and MAC secrets (see 3381 Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished 3382 message, parties thus prove that they know the correct 3383 pre_master_secret. 3385 F.1.1.1. Anonymous key exchange 3387 Completely anonymous sessions can be established using RSA or Diffie- 3388 Hellman for key exchange. With anonymous RSA, the client encrypts a 3389 pre_master_secret with the server's uncertified public key extracted 3390 from the server key exchange message. The result is sent in a client 3391 key exchange message. Since eavesdroppers do not know the server's 3392 private key, it will be infeasible for them to decode the | 3393 pre_master_secret. | 3395 Note: No anonymous RSA Cipher Suites are defined in this document. 3397 With Diffie-Hellman, the server's public parameters are contained in 3398 the server key exchange message and the client's are sent in the 3399 client key exchange message. Eavesdroppers who do not know the 3400 private values should not be able to find the Diffie-Hellman result 3401 (i.e. the pre_master_secret). 3403 Warning: Completely anonymous connections only provide protection 3404 against passive eavesdropping. Unless an independent tamper- 3405 proof channel is used to verify that the finished messages 3406 were not replaced by an attacker, server authentication is 3407 required in environments where active man-in-the-middle 3408 attacks are a concern. 3410 F.1.1.2. RSA key exchange and authentication 3412 With RSA, key exchange and server authentication are combined. The 3413 public key may be either contained in the server's certificate or may 3414 be a temporary RSA key sent in a server key exchange message. When 3415 temporary RSA keys are used, they are signed by the server's RSA | 3416 certificate. The signature includes the current ClientHello.random, 3417 so old signatures and temporary keys cannot be replayed. Servers may 3418 use a single temporary RSA key for multiple negotiation sessions. 3420 Note: The temporary RSA key option is useful if servers need large 3421 certificates but must comply with government-imposed size limits 3422 on keys used for key exchange. 3424 Note that if ephemeral RSA is not used, compromise of the server's | 3425 static RSA key results in a loss of confidentiality for all sessions | 3426 protected under that static key. TLS users desiring Perfect Forward | 3427 Secrecy should use DHE cipher suites. The damage done by exposure of | 3428 a private key can be limited by changing one's private key (and | 3429 certificate) frequently. | 3431 After verifying the server's certificate, the client encrypts a 3432 pre_master_secret with the server's public key. By successfully 3433 decoding the pre_master_secret and producing a correct finished 3434 message, the server demonstrates that it knows the private key 3435 corresponding to the server certificate. 3437 When RSA is used for key exchange, clients are authenticated using 3438 the certificate verify message (see Section 7.4.8). The client signs 3439 a value derived from the master_secret and all preceding handshake 3440 messages. These handshake messages include the server certificate, 3441 which binds the signature to the server, and ServerHello.random, 3442 which binds the signature to the current handshake process. 3444 F.1.1.3. Diffie-Hellman key exchange with authentication 3446 When Diffie-Hellman key exchange is used, the server can either 3447 supply a certificate containing fixed Diffie-Hellman parameters or 3448 can use the server key exchange message to send a set of temporary 3449 Diffie-Hellman parameters signed with a DSS or RSA certificate. 3450 Temporary parameters are hashed with the hello.random values before 3451 signing to ensure that attackers do not replay old parameters. In 3452 either case, the client can verify the certificate or signature to 3453 ensure that the parameters belong to the server. 3455 If the client has a certificate containing fixed Diffie-Hellman 3456 parameters, its certificate contains the information required to 3457 complete the key exchange. Note that in this case the client and 3458 server will generate the same Diffie-Hellman result (i.e., 3459 pre_master_secret) every time they communicate. To prevent the 3460 pre_master_secret from staying in memory any longer than necessary, 3461 it should be converted into the master_secret as soon as possible. 3462 Client Diffie-Hellman parameters must be compatible with those 3463 supplied by the server for the key exchange to work. 3465 If the client has a standard DSS or RSA certificate or is 3466 unauthenticated, it sends a set of temporary parameters to the server 3467 in the client key exchange message, then optionally uses a 3468 certificate verify message to authenticate itself. 3470 If the same DH keypair is to be used for multiple handshakes, either | 3471 because the client or server has a certificate containing a fixed DH | 3472 keypair or because the server is reusing DH keys, care must be taken | 3473 to prevent small subgroup attacks. Implementations SHOULD follow the | 3474 guidelines found in [SUBGROUP]. | 3476 Small subgroup attacks are most easily avoided by using one of the | 3477 DHE ciphersuites and generating a fresh DH private key (X) for each | 3478 handshake. If a suitable base (such as 2) is chosen, g^X mod p can be | 3479 computed very quickly so the performance cost is minimized. | 3480 Additionally, using a fresh key for each handshake provides Perfect | 3481 Forward Secrecy. Implementations SHOULD generate a new X for each | 3482 handshake when using DHE ciphersuites. | 3484 F.1.2. Version rollback attacks 3485 Because TLS includes substantial improvements over SSL Version 2.0, 3486 attackers may try to make TLS-capable clients and servers fall back 3487 to Version 2.0. This attack can occur if (and only if) two TLS- 3488 capable parties use an SSL 2.0 handshake. 3490 Although the solution using non-random PKCS #1 block type 2 message 3491 padding is inelegant, it provides a reasonably secure way for Version 3492 3.0 servers to detect the attack. This solution is not secure against 3493 attackers who can brute force the key and substitute a new ENCRYPTED- 3494 KEY-DATA message containing the same key (but with normal padding) 3495 before the application specified wait threshold has expired. Parties 3496 concerned about attacks of this scale should not be using 40-bit 3497 encryption keys anyway. Altering the padding of the least-significant 3498 8 bytes of the PKCS padding does not impact security for the size of 3499 the signed hashes and RSA key lengths used in the protocol, since 3500 this is essentially equivalent to increasing the input block size by 3501 8 bytes. 3503 F.1.3. Detecting attacks against the handshake protocol 3505 An attacker might try to influence the handshake exchange to make the 3506 parties select different encryption algorithms than they would | 3507 normally chooses. Because many implementations will support 40-bit 3508 exportable encryption and some may even support null encryption or 3509 MAC algorithms, this attack is of particular concern. 3511 For this attack, an attacker must actively change one or more 3512 handshake messages. If this occurs, the client and server will 3513 compute different values for the handshake message hashes. As a 3514 result, the parties will not accept each others' finished messages. 3515 Without the master_secret, the attacker cannot repair the finished 3516 messages, so the attack will be discovered. 3518 F.1.4. Resuming sessions 3520 When a connection is established by resuming a session, new 3521 ClientHello.random and ServerHello.random values are hashed with the 3522 session's master_secret. Provided that the master_secret has not been 3523 compromised and that the secure hash operations used to produce the 3524 encryption keys and MAC secrets are secure, the connection should be 3525 secure and effectively independent from previous connections. 3526 Attackers cannot use known encryption keys or MAC secrets to 3527 compromise the master_secret without breaking the secure hash 3528 operations (which use both SHA and MD5). 3530 Sessions cannot be resumed unless both the client and server agree. 3531 If either party suspects that the session may have been compromised, 3532 or that certificates may have expired or been revoked, it should 3533 force a full handshake. An upper limit of 24 hours is suggested for 3534 session ID lifetimes, since an attacker who obtains a master_secret 3535 may be able to impersonate the compromised party until the 3536 corresponding session ID is retired. Applications that may be run in 3537 relatively insecure environments should not write session IDs to 3538 stable storage. 3540 F.1.5. MD5 and SHA 3542 TLS uses hash functions very conservatively. Where possible, both MD5 3543 and SHA are used in tandem to ensure that non-catastrophic flaws in 3544 one algorithm will not break the overall protocol. 3546 F.2. Protecting application data 3548 The master_secret is hashed with the ClientHello.random and 3549 ServerHello.random to produce unique data encryption keys and MAC 3550 secrets for each connection. 3552 Outgoing data is protected with a MAC before transmission. To prevent 3553 message replay or modification attacks, the MAC is computed from the 3554 MAC secret, the sequence number, the message length, the message 3555 contents, and two fixed character strings. The message type field is 3556 necessary to ensure that messages intended for one TLS Record Layer 3557 client are not redirected to another. The sequence number ensures 3558 that attempts to delete or reorder messages will be detected. Since 3559 sequence numbers are 64-bits long, they should never overflow. 3560 Messages from one party cannot be inserted into the other's output, 3561 since they use independent MAC secrets. Similarly, the server-write 3562 and client-write keys are independent so stream cipher keys are used 3563 only once. 3565 If an attacker does break an encryption key, all messages encrypted 3566 with it can be read. Similarly, compromise of a MAC key can make 3567 message modification attacks possible. Because MACs are also 3568 encrypted, message-alteration attacks generally require breaking the 3569 encryption algorithm as well as the MAC. 3571 Note: MAC secrets may be larger than encryption keys, so messages can 3572 remain tamper resistant even if encryption keys are broken. 3574 F.3. Explicit IVs | 3576 [CBCATT] describes a chosen plaintext attack on TLS that depends | 3577 on knowing the IV for a record. Previous versions of TLS [TLS1.0] | 3578 used the CBC residue of the previous record as the IV and | 3579 therefore enabled this attack. This version uses an explicit IV | 3580 in order to protect against this attack. | 3581 F.4 Security of Composite Cipher Modes | 3583 TLS secures transmitted application data via the use of symmetric | 3584 encryption and authentication functions defined in the negotiated | 3585 ciphersuite. The objective is to protect both the integrity and | 3586 confidentiality of the transmitted data from malicious actions by | 3587 active attackers in the network. It turns out that the order in | 3588 which encryption and authentication functions are applied to the | 3589 data plays an important role for achieving this goal [ENCAUTH]. | 3591 The most robust method, called encrypt-then-authenticate, first | 3592 applies encryption to the data and then applies a MAC to the | 3593 ciphertext. This method ensures that the integrity and | 3594 confidentiality goals are obtained with ANY pair of encryption | 3595 and MAC functions provided that the former is secure against | 3596 chosen plaintext attacks and the MAC is secure against chosen- | 3597 message attacks. TLS uses another method, called authenticate- | 3598 then-encrypt, in which first a MAC is computed on the plaintext | 3599 and then the concatenation of plaintext and MAC is encrypted. | 3600 This method has been proven secure for CERTAIN combinations of | 3601 encryption functions and MAC functions, but is not guaranteed to | 3602 be secure in general. In particular, it has been shown that there | 3603 exist perfectly secure encryption functions (secure even in the | 3604 information theoretic sense) that combined with any secure MAC | 3605 function fail to provide the confidentiality goal against an | 3606 active attack. Therefore, new ciphersuites and operation modes | 3607 adopted into TLS need to be analyzed under the authenticate-then- | 3608 encrypt method to verify that they achieve the stated integrity | 3609 and confidentiality goals. | 3611 Currently, the security of the authenticate-then-encrypt method | 3612 has been proven for some important cases. One is the case of | 3613 stream ciphers in which a computationally unpredictable pad of | 3614 the length of the message plus the length of the MAC tag is | 3615 produced using a pseudo-random generator and this pad is xor-ed | 3616 with the concatenation of plaintext and MAC tag. The other is | 3617 the case of CBC mode using a secure block cipher. In this case, | 3618 security can be shown if one applies one CBC encryption pass to | 3619 the concatenation of plaintext and MAC and uses a new, | 3620 independent and unpredictable, IV for each new pair of plaintext | 3621 and MAC. In previous versions of SSL, CBC mode was used properly | 3622 EXCEPT that it used a predictable IV in the form of the last | 3623 block of the previous ciphertext. This made TLS open to chosen | 3624 plaintext attacks. This verson of the protocol is immune to | 3625 those attacks. For exact details in the encryption modes proven | 3626 secure see [ENCAUTH]. | 3627 F.5 Denial of Service | 3629 TLS is susceptible to a number of denial of service (DoS) | 3630 attacks. In particular, an attacker who initiates a large number | 3631 of TCP connections can cause a server to consume large amounts of | 3632 CPU doing RSA decryption. However, because TLS is generally used | 3633 over TCP, it is difficult for the attacker to hide his point of | 3634 origin if proper TCP SYN randomization is used [SEQNUM] by the | 3635 TCP stack. | 3637 Because TLS runs over TCP, it is also susceptible to a number of | 3638 denial of service attacks on individual connections. In | 3639 particular, attackers can forge RSTs, terminating connections, or | 3640 forge partial TLS records, causing the connection to stall. | 3641 These attacks cannot in general be defended against by a TCP- | 3642 using protocol. Implementors or users who are concerned with this | 3643 class of attack should use IPsec AH [AH] or ESP [ESP]. | 3645 F.6. Final notes 3647 For TLS to be able to provide a secure connection, both the client 3648 and server systems, keys, and applications must be secure. In 3649 addition, the implementation must be free of security errors. 3651 The system is only as strong as the weakest key exchange and 3652 authentication algorithm supported, and only trustworthy 3653 cryptographic functions should be used. Short public keys, 40-bit 3654 bulk encryption keys, and anonymous servers should be used with great 3655 caution. Implementations and users must be careful when deciding 3656 which certificates and certificate authorities are acceptable; a 3657 dishonest certificate authority can do tremendous damage. 3659 G. Patent Statement 3661 Netscape Communications Corporation (now America Online) has a patent | 3662 claim on the Secure Sockets Layer (SSL) work that this standard is | 3663 based on. The Internet Standards Process as defined in RFC 2026 | 3664 requests that a statement be obtained from a Patent holder indicating | 3665 that a license will be made available to applicants under reasonable | 3666 terms and conditions. 3668 Secure Socket Layer Application Program Apparatus And Method 3669 ("SSL"), No. 5,657,390 3671 Netscape Communications has issued the following statement: 3673 Intellectual Property Rights 3675 Secure Sockets Layer 3677 The United States Patent and Trademark Office ("the PTO") 3678 recently issued U.S. Patent No. 5,657,390 ("the SSL Patent") to 3679 Netscape for inventions described as Secure Sockets Layers 3680 ("SSL"). The IETF is currently considering adopting SSL as a 3681 transport protocol with security features. Netscape encourages 3682 the royalty-free adoption and use of the SSL protocol upon the 3683 following terms and conditions: 3685 * If you already have a valid SSL Ref license today which 3686 includes source code from Netscape, an additional patent 3687 license under the SSL patent is not required. 3689 * If you don't have an SSL Ref license, you may have a royalty 3690 free license to build implementations covered by the SSL 3691 Patent Claims or the IETF TLS specification provided that you 3692 do not to assert any patent rights against Netscape or other 3693 companies for the implementation of SSL or the IETF TLS 3694 recommendation. 3696 What are "Patent Claims": 3698 Patent claims are claims in an issued foreign or domestic patent 3699 that: 3701 1) must be infringed in order to implement methods or build 3702 products according to the IETF TLS specification; or 3704 2) patent claims which require the elements of the SSL patent 3705 claims and/or their equivalents to be infringed. 3707 The Internet Society, Internet Architecture Board, Internet 3708 Engineering Steering Group and the Corporation for National Research 3709 Initiatives take no position on the validity or scope of the patents 3710 and patent applications, nor on the appropriateness of the terms of 3711 the assurance. The Internet Society and other groups mentioned above 3712 have not made any determination as to any other intellectual property 3713 rights which may apply to the practice of this standard. Any further 3714 consideration of these matters is the user's own responsibility. 3716 Security Considerations 3718 Security issues are discussed throughout this memo, especially in | 3719 Appendices D, E, and F. 3721 Normative References | 3723 [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," | 3724 IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. 3726 [DES] ANSI X3.106, "American National Standard for Information 3727 Systems-Data Link Encryption," American National Standards 3728 Institute, 1983. 3730 [DH1] W. Diffie and M. E. Hellman, "New Directions in 3731 Cryptography," IEEE Transactions on Information Theory, V. 3732 IT-22, n. 6, Jun 1977, pp. 74-84. 3734 [DSS] NIST FIPS PUB 186, "Digital Signature Standard," National 3735 Institute of Standards and Technology, U.S. Department of 3736 Commerce, May 18, 1994. 3738 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 3739 Hashing for Message Authentication," RFC 2104, February 3740 1997. 3742 [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH 3743 Series in Information Processing, v. 1, Konstanz: Hartung- 3744 Gorre Verlag, 1992. 3746 [MD2] Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319, 3747 April 1992. 3749 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 3750 April 1992. 3752 [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard," 3753 version 1.5, November 1993. 3755 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax 3756 Standard," version 1.5, November 1993. 3758 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax 3759 Standard," version 1.5, November 1993. 3761 [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 3762 Public Key Infrastructure: Part I: X.509 Certificate and CRL 3763 Profile", RFC 2459, January 1999. 3765 [RC2] Rivest, R., "A Description of the RC2(r) Encryption 3766 Algorithm", RFC 2268, January 1998. 3768 [RC4] Thayer, R. and K. Kaukonen, A Stream Cipher Encryption 3769 Algorithm, Work in Progress. 3771 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for 3772 Obtaining Digital Signatures and Public-Key Cryptosystems," 3773 Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 3774 120-126. 3776 [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National 3777 Institute of Standards and Technology, U.S. Department of 3778 Commerce, Work in Progress, May 31, 1994. 3780 [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications 3781 Corp., Feb 9, 1995. 3783 [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", 3784 Netscape Communications Corp., Nov 18, 1996. 3786 [REQ] Bradner, S., "Key words for use in RFCs to Indicate | 3787 Requirement Levels", BCP 14, RFC 2119, March 1997. 3789 [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0", | 3790 RFC 2246, January 1999. 3792 [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J., | 3793 Wright, T., "Transport Layer Security (TLS) Extensions", RFC | 3794 3546, June 2003. 3795 [X509] CCITT. Recommendation X.509: "The Directory - Authentication 3796 Framework". 1988. 3798 Informative References | 3800 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC | 3801 2402, November 1998. | 3803 [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against | 3804 Protocols Based on RSA Encryption Standard PKCS #1" in | 3805 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: | 3806 1--12, 1998. | 3808 [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: | 3809 Problems and Countermeasures", | 3810 http://www.openssl.org/~bodo/tls-cbc.txt. | 3812 [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel", | 3813 http://lasecwww.epfl.ch/memo_ssl.shtml, 2003. | 3815 [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication | 3816 for Protecting Communications (Or: How Secure is SSL?)", | 3817 Crypto 2001. | 3819 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security | 3820 Payload (ESP)", RFC 2406, November 1998. | 3822 [FTP] Postel J., and J. Reynolds, "File Transfer Protocol", STD 9, | 3823 RFC 959, October 1985. | 3825 [HTTP] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext | 3826 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | 3828 [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based | 3829 Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, | 3830 March 2003. | 3831 [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782 | 3833 [SCH] B. Schneier. Applied Cryptography: Protocols, Algorithms, | 3834 and Source Code in C, Published by John Wiley & Sons, Inc. | 3835 1994. | 3837 [SEQNUM] Bellovim. S., "Defending Against Sequence Number Attacks", | 3838 RFC 1948, May 1996. | 3840 [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup | 3841 Attacks on the Diffie-Hellman Key Agreement Method for | 3842 S/MIME", RFC 2785, March 2000. | 3844 [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, | 3845 September 1981. | 3847 [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are | 3848 practical", USENIX Security Symposium 2003. | 3850 [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External 3851 Data Representation Standard, August 1995. 3853 Credits | 3855 Working Group Chair | 3856 Win Treese 3858 EMail: treese@acm.org | 3860 Editors 3862 Tim Dierks Eric Rescorla | 3863 RTFM, Inc. | 3865 EMail: tim@dierks.org EMail: ekr@rtfm.com | 3867 Other contributors 3869 Christopher Allen (co-editor of TLS 1.0) | 3870 Alacrity Ventures | 3871 ChristopherA@AlacrityVentures.com | 3873 Martin Abadi | 3874 University of California, Santa Cruz | 3875 abadi@cs.ucsc.edu | 3877 Ran Canetti | 3878 IBM | 3879 canetti@watson.ibm.com | 3881 Taher Elgamal | 3882 taher@securify.com | 3883 Securify | 3885 Anil Gangolli | 3886 Structured Arts | 3888 Kipp Hickman | 3890 Phil Karlton (co-author of SSLv3) | 3891 Paul Kocher (co-author of SSLv3) | 3892 Cryptography Research | 3893 paul@cryptography.com | 3895 Hugo Krawczyk | 3896 Technion Israel Institute of Technology | 3897 hugo@ee.technion.ac.il | 3899 Robert Relyea | 3900 Netscape Communications | 3901 relyea@netscape.com | 3903 Jim Roskind | 3904 Netscape Communications | 3905 jar@netscape.com | 3907 Michael Sabin | 3909 Dan Simon | 3910 Microsoft, Inc. | 3911 dansimon@microsoft.com | 3913 Tom Weinstein | 3915 Comments 3917 The discussion list for the IETF TLS working group is located at the 3918 e-mail address . Information on the 3919 group and information on how to subscribe to the list is at 3920 . 3922 Archives of the list can be found at: 3923 3924 Full Copyright Statement 3926 Copyright (C) The Internet Society (1999). All Rights Reserved. 3928 This document and translations of it may be copied and furnished to 3929 others, and derivative works that comment on or otherwise explain it 3930 or assist in its implementation may be prepared, copied, published 3931 and distributed, in whole or in part, without restriction of any 3932 kind, provided that the above copyright notice and this paragraph are 3933 included on all such copies and derivative works. However, this 3934 document itself may not be modified in any way, such as by removing 3935 the copyright notice or references to the Internet Society or other 3936 Internet organizations, except as needed for the purpose of 3937 developing Internet standards in which case the procedures for 3938 copyrights defined in the Internet Standards process must be 3939 followed, or as required to translate it into languages other than 3940 English. 3942 The limited permissions granted above are perpetual and will not be 3943 revoked by the Internet Society or its successors or assigns. 3945 This document and the information contained herein is provided on an 3946 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3947 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3948 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3949 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3950 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.