idnits 2.17.1 draft-ietf-tls-rfc4346-bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 5068. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5045. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5052. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5058. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 146 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 702 has weird spacing: '...gorithm bul...' == Line 2244 has weird spacing: '...ensions reque...' == Line 2632 has weird spacing: '...ixed_dh a c...' == Line 2634 has weird spacing: '...ixed_dh a c...' == Line 3499 has weird spacing: '...ensions reque...' == (1 more instance...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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: 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) -- Looks like a reference, but probably isn't: '0' on line 296 -- Looks like a reference, but probably isn't: '1' on line 296 -- Looks like a reference, but probably isn't: '3' on line 4212 -- Looks like a reference, but probably isn't: '9' on line 332 -- Looks like a reference, but probably isn't: '2' on line 3397 -- Looks like a reference, but probably isn't: '4' on line 367 -- Looks like a reference, but probably isn't: '8' on line 368 -- Looks like a reference, but probably isn't: '10' on line 462 -- Looks like a reference, but probably isn't: '20' on line 3635 -- Looks like a reference, but probably isn't: '48' on line 3817 -- Looks like a reference, but probably isn't: '32' on line 3819 == Missing Reference: 'ChangeCipherSpec' is mentioned on line 1559, but not defined -- Looks like a reference, but probably isn't: '28' on line 3392 == Missing Reference: 'TLS' is mentioned on line 4515, but not defined == Missing Reference: 'IANA' is mentioned on line 3184, but not defined -- Looks like a reference, but probably isn't: '46' on line 3597 -- Looks like a reference, but probably isn't: '12' on line 3644 == Missing Reference: 'PKCS1' is mentioned on line 3100, but not defined == Missing Reference: 'RFC 2434' is mentioned on line 3172, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'RSADSI' is mentioned on line 3949, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. '3DES' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'IDEA' ** Obsolete normative reference: RFC 3490 (ref. 'IDNA') (Obsoleted by RFC 5890, RFC 5891) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 2313 (ref. 'PKCS1A') (Obsoleted by RFC 2437) ** Obsolete normative reference: RFC 3447 (ref. 'PKCS1B') (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX') (Obsoleted by RFC 5280) ** Downref: Normative reference to an Informational RFC: RFC 2268 (ref. 'RC2') -- Possible downref: Non-RFC (?) normative reference: ref. 'SCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' ** Obsolete normative reference: RFC 3268 (ref. 'TLSAES') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 3546 (ref. 'TLSEXT') (Obsoleted by RFC 4366) ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'X509-4th' -- Possible downref: Non-RFC (?) normative reference: ref. 'X509-4th-TC1' -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 1948 (ref. 'SEQNUM') (Obsoleted by RFC 6528) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1832 (ref. 'XDR') (Obsoleted by RFC 4506) Summary: 17 errors (**), 0 flaws (~~), 19 warnings (==), 37 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Tim Dierks 2 Independent 3 Eric Rescorla 4 INTERNET-DRAFT Network Resonance, Inc. 5 June 2006 (Expires December 2006) 7 The TLS Protocol 8 Version 1.2 10 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2006). 36 Abstract 38 This document specifies Version 1.2 of the Transport Layer Security 39 (TLS) protocol. The TLS protocol provides communications security 40 over the Internet. The protocol allows client/server applications to 41 communicate in a way that is designed to prevent eavesdropping, 42 tampering, or message forgery. 44 Table of Contents 46 1. Introduction 4 47 1.1 Differences from TLS 1.1 5 48 1.1 Requirements Terminology 5 49 2. Goals 5 50 3. Goals of this document 6 51 4. Presentation language 6 52 4.1. Basic block size 7 53 4.2. Miscellaneous 7 54 4.3. Vectors 7 55 4.4. Numbers 8 56 4.5. Enumerateds 8 57 4.6. Constructed types 9 58 4.6.1. Variants 10 59 4.7. Cryptographic attributes 11 60 4.8. Constants 12 61 5. HMAC and the pseudorandom function 12 62 6. The TLS Record Protocol 13 63 6.1. Connection states 14 64 6.2. Record layer 16 65 6.2.1. Fragmentation 16 66 6.2.2. Record compression and decompression 18 67 6.2.3. Record payload protection 18 68 6.2.3.1. Null or standard stream cipher 19 69 6.2.3.2. CBC block cipher 20 70 6.3. Key calculation 22 71 7. The TLS Handshaking Protocols 23 72 7.1. Change cipher spec protocol 25 73 7.2. Alert protocol 25 74 7.2.1. Closure alerts 26 75 7.2.2. Error alerts 27 76 7.3. Handshake Protocol overview 31 77 7.4. Handshake protocol 35 78 7.4.1. Hello messages 36 79 7.4.1.1. Hello request 36 80 7.4.1.2. Client hello 37 81 7.4.1.3. Server hello 40 82 7.4.1.4 Hello Extensions 41 83 7.4.1.4.1 Server Name Indication 43 84 7.4.1.4.2 Maximum Fragment Length Negotiation 44 85 7.4.1.4.3 Client Certificate URLs 46 86 7.4.1.4.4 Trusted CA Indication 46 87 7.4.1.4.5 Truncated HMAC 48 88 7.4.1.4.6 Certificate Status Request 49 89 7.4.1.4.7 Cert Hash Types 50 90 7.4.1.4.8 Procedure for Defining New Extensions 51 91 7.4.2. Server certificate 52 92 7.4.3. Server key exchange message 53 93 7.4.4. CertificateStatus 56 94 7.4.5. Certificate request 56 95 7.4.6. Server hello done 58 96 7.4.7. Client certificate 59 97 7.4.8. Client Certificate URLs 59 98 7.4.9. Client key exchange message 61 99 7.4.9.1. RSA encrypted premaster secret message 62 100 7.4.9.2. Client Diffie-Hellman public value 64 101 7.4.10. Certificate verify 65 102 7.4.10. Finished 65 103 8. Cryptographic computations 66 104 8.1. Computing the master secret 67 105 8.1.1. RSA 68 106 8.1.2. Diffie-Hellman 68 107 9. Mandatory Cipher Suites 68 108 A. Protocol constant values 72 109 A.1. Record layer 72 110 A.2. Change cipher specs message 73 111 A.3. Alert messages 73 112 A.4. Handshake protocol 75 113 A.4.1. Hello messages 75 114 A.4.2. Server authentication and key exchange messages 78 115 A.4.3. Client authentication and key exchange messages 79 116 A.4.4. Handshake finalization message 80 117 A.5. The CipherSuite 81 118 A.6. The Security Parameters 84 119 B. Glossary 85 120 C. CipherSuite definitions 89 121 D. Implementation Notes 91 122 D.1 Random Number Generation and Seeding 91 123 D.2 Certificates and authentication 91 124 D.3 CipherSuites 91 125 E. Backward Compatibility With SSL 92 126 E.1. Version 2 client hello 93 127 E.2. Avoiding man-in-the-middle version rollback 94 128 F. Security analysis 96 129 F.1. Handshake protocol 96 130 F.1.1. Authentication and key exchange 96 131 F.1.1.1. Anonymous key exchange 96 132 F.1.1.2. RSA key exchange and authentication 97 133 F.1.1.3. Diffie-Hellman key exchange with authentication 98 134 F.1.2. Version rollback attacks 98 135 F.1.3. Detecting attacks against the handshake protocol 99 136 F.1.4. Resuming sessions 99 137 F.1.5 Extensions 100 138 F.1.5.1 Security of server_name 100 139 F.1.5.2 Security of client_certificate_url 101 140 F.1.5.4. Security of trusted_ca_keys 102 141 F.1.5.5. Security of truncated_hmac 102 142 F.1.5.6. Security of status_request 103 143 F.2. Protecting application data 103 144 F.3. Explicit IVs 104 145 F.4 Security of Composite Cipher Modes 104 146 F.5 Denial of Service 105 147 F.6. Final notes 105 149 Change history 151 18-Feb-06 First draft by ekr@rtfm.com 153 1. Introduction 155 The primary goal of the TLS Protocol is to provide privacy and data 156 integrity between two communicating applications. The protocol is 157 composed of two layers: the TLS Record Protocol and the TLS Handshake 158 Protocol. At the lowest level, layered on top of some reliable 159 transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The 160 TLS Record Protocol provides connection security that has two basic 161 properties: 163 - The connection is private. Symmetric cryptography is used for 164 data encryption (e.g., DES [DES], RC4 [SCH], etc.). The keys for 165 this symmetric encryption are generated uniquely for each 166 connection and are based on a secret negotiated by another 167 protocol (such as the TLS Handshake Protocol). The Record 168 Protocol can also be used without encryption. 170 - The connection is reliable. Message transport includes a message 171 integrity check using a keyed MAC. Secure hash functions (e.g., 172 SHA, MD5, etc.) are used for MAC computations. The Record 173 Protocol can operate without a MAC, but is generally only used in 174 this mode while another protocol is using the Record Protocol as 175 a transport for negotiating security parameters. 177 The TLS Record Protocol is used for encapsulation of various higher 178 level protocols. One such encapsulated protocol, the TLS Handshake 179 Protocol, allows the server and client to authenticate each other and 180 to negotiate an encryption algorithm and cryptographic keys before 181 the application protocol transmits or receives its first byte of 182 data. The TLS Handshake Protocol provides connection security that 183 has three basic properties: 185 - The peer's identity can be authenticated using asymmetric, or 186 public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This 187 authentication can be made optional, but is generally required 188 for at least one of the peers. 190 - The negotiation of a shared secret is secure: the negotiated 191 secret is unavailable to eavesdroppers, and for any authenticated 192 connection the secret cannot be obtained, even by an attacker who 193 can place himself in the middle of the connection. 195 - The negotiation is reliable: no attacker can modify the 196 negotiation communication without being detected by the parties 197 to the communication. 199 One advantage of TLS is that it is application protocol independent. 200 Higher level protocols can layer on top of the TLS Protocol 201 transparently. The TLS standard, however, does not specify how 202 protocols add security with TLS; the decisions on how to initiate TLS 203 handshaking and how to interpret the authentication certificates 204 exchanged are left up to the judgment of the designers and 205 implementors of protocols which run on top of TLS. 207 1.1 Differences from TLS 1.1 208 This document is a revision of the TLS 1.1 [TLS1.1] protocol which 209 contains improved flexibility, particularly for negotiation of 210 cryptographic algorithms. The major changes are: 212 - Merged in TLS Extensions and AES Cipher Suites from external 213 documents. 215 - Replacement of MD5/SHA-1 combination in the PRF 217 - Replacement of MD5/SHA-1 combination in the digitally-signed 218 element. 220 - Allow the client to indicate which hash functions it supports. 222 - Allow the server to indicate which has functions it supports 224 1.1 Requirements Terminology 226 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 227 "MAY" that appear in this document are to be interpreted as described 228 in RFC 2119 [REQ]. 230 2. Goals 232 The goals of TLS Protocol, in order of their priority, are: 234 1. Cryptographic security: TLS should be used to establish a secure 235 connection between two parties. 237 2. Interoperability: Independent programmers should be able to 238 develop applications utilizing TLS that will then be able to 239 successfully exchange cryptographic parameters without knowledge 240 of one another's code. 242 3. Extensibility: TLS seeks to provide a framework into which new 243 public key and bulk encryption methods can be incorporated as 244 necessary. This will also accomplish two sub-goals: to prevent 245 the need to create a new protocol (and risking the introduction 246 of possible new weaknesses) and to avoid the need to implement an 247 entire new security library. 249 4. Relative efficiency: Cryptographic operations tend to be highly 250 CPU intensive, particularly public key operations. For this 251 reason, the TLS protocol has incorporated an optional session 252 caching scheme to reduce the number of connections that need to 253 be established from scratch. Additionally, care has been taken to 254 reduce network activity. 256 3. Goals of this document 258 This document and the TLS protocol itself are based on the SSL 3.0 259 Protocol Specification as published by Netscape. The differences 260 between this protocol and SSL 3.0 are not dramatic, but they are 261 significant enough that the various versions of TLS and SSL 3.0 do 262 not interoperate (although each protocol incorporates a mechanism by 263 which an implementation can back down prior versions. This document 264 is intended primarily for readers who will be implementing the 265 protocol and those doing cryptographic analysis of it. The 266 specification has been written with this in mind, and it is intended 267 to reflect the needs of those two groups. For that reason, many of 268 the algorithm-dependent data structures and rules are included in the 269 body of the text (as opposed to in an appendix), providing easier 270 access to them. 272 This document is not intended to supply any details of service 273 definition nor interface definition, although it does cover select 274 areas of policy as they are required for the maintenance of solid 275 security. 277 4. Presentation language 279 This document deals with the formatting of data in an external 280 representation. The following very basic and somewhat casually 281 defined presentation syntax will be used. The syntax draws from 282 several sources in its structure. Although it resembles the 283 programming language "C" in its syntax and XDR [XDR] in both its 284 syntax and intent, it would be risky to draw too many parallels. The 285 purpose of this presentation language is to document TLS only, not to 286 have general application beyond that particular goal. 288 4.1. Basic block size 290 The representation of all data items is explicitly specified. The 291 basic data block size is one byte (i.e. 8 bits). Multiple byte data 292 items are concatenations of bytes, from left to right, from top to 293 bottom. From the bytestream a multi-byte item (a numeric in the 294 example) is formed (using C notation) by: 296 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | 297 ... | byte[n-1]; 299 This byte ordering for multi-byte values is the commonplace network 300 byte order or big endian format. 302 4.2. Miscellaneous 304 Comments begin with "/*" and end with "*/". 306 Optional components are denoted by enclosing them in "[[ ]]" double 307 brackets. 309 Single byte entities containing uninterpreted data are of type 310 opaque. 312 4.3. Vectors 314 A vector (single dimensioned array) is a stream of homogeneous data 315 elements. The size of the vector may be specified at documentation 316 time or left unspecified until runtime. In either case the length 317 declares the number of bytes, not the number of elements, in the 318 vector. The syntax for specifying a new type T' that is a fixed 319 length vector of type T is 321 T T'[n]; 323 Here T' occupies n bytes in the data stream, where n is a multiple of 324 the size of T. The length of the vector is not included in the 325 encoded stream. 327 In the following example, Datum is defined to be three consecutive 328 bytes that the protocol does not interpret, while Data is three 329 consecutive Datum, consuming a total of nine bytes. 331 opaque Datum[3]; /* three uninterpreted bytes */ 332 Datum Data[9]; /* 3 consecutive 3 byte vectors */ 333 Variable length vectors are defined by specifying a subrange of legal 334 lengths, inclusively, using the notation . When 335 encoded, the actual length precedes the vector's contents in the byte 336 stream. The length will be in the form of a number consuming as many 337 bytes as required to hold the vector's specified maximum (ceiling) 338 length. A variable length vector with an actual length field of zero 339 is referred to as an empty vector. 341 T T'; 343 In the following example, mandatory is a vector that must contain 344 between 300 and 400 bytes of type opaque. It can never be empty. The 345 actual length field consumes two bytes, a uint16, sufficient to 346 represent the value 400 (see Section 4.4). On the other hand, longer 347 can represent up to 800 bytes of data, or 400 uint16 elements, and it 348 may be empty. Its encoding will include a two byte actual length 349 field prepended to the vector. The length of an encoded vector must 350 be an even multiple of the length of a single element (for example, a 351 17 byte vector of uint16 would be illegal). 353 opaque mandatory<300..400>; 354 /* length field is 2 bytes, cannot be empty */ 355 uint16 longer<0..800>; 356 /* zero to 400 16-bit unsigned integers */ 358 4.4. Numbers 360 The basic numeric data type is an unsigned byte (uint8). All larger 361 numeric data types are formed from fixed length series of bytes 362 concatenated as described in Section 4.1 and are also unsigned. The 363 following numeric types are predefined. 365 uint8 uint16[2]; 366 uint8 uint24[3]; 367 uint8 uint32[4]; 368 uint8 uint64[8]; 370 All values, here and elsewhere in the specification, are stored in 371 "network" or "big-endian" order; the uint32 represented by the hex 372 bytes 01 02 03 04 is equivalent to the decimal value 16909060. 374 4.5. Enumerateds 376 An additional sparse data type is available called enum. A field of 377 type enum can only assume the values declared in the definition. 378 Each definition is a different type. Only enumerateds of the same 379 type may be assigned or compared. Every element of an enumerated must 380 be assigned a value, as demonstrated in the following example. Since 381 the elements of the enumerated are not ordered, they can be assigned 382 any unique value, in any order. 384 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; 386 Enumerateds occupy as much space in the byte stream as would its 387 maximal defined ordinal value. The following definition would cause 388 one byte to be used to carry fields of type Color. 390 enum { red(3), blue(5), white(7) } Color; 392 One may optionally specify a value without its associated tag to 393 force the width definition without defining a superfluous element. 394 In the following example, Taste will consume two bytes in the data 395 stream but can only assume the values 1, 2 or 4. 397 enum { sweet(1), sour(2), bitter(4), (32000) } Taste; 399 The names of the elements of an enumeration are scoped within the 400 defined type. In the first example, a fully qualified reference to 401 the second element of the enumeration would be Color.blue. Such 402 qualification is not required if the target of the assignment is well 403 specified. 405 Color color = Color.blue; /* overspecified, legal */ 406 Color color = blue; /* correct, type implicit */ 408 For enumerateds that are never converted to external representation, 409 the numerical information may be omitted. 411 enum { low, medium, high } Amount; 413 4.6. Constructed types 415 Structure types may be constructed from primitive types for 416 convenience. Each specification declares a new, unique type. The 417 syntax for definition is much like that of C. 419 struct { 420 T1 f1; 421 T2 f2; 422 ... 423 Tn fn; 424 } [[T]]; 425 The fields within a structure may be qualified using the type's name 426 using a syntax much like that available for enumerateds. For example, 427 T.f2 refers to the second field of the previous declaration. 428 Structure definitions may be embedded. 430 4.6.1. Variants 432 Defined structures may have variants based on some knowledge that is 433 available within the environment. The selector must be an enumerated 434 type that defines the possible variants the structure defines. There 435 must be a case arm for every element of the enumeration declared in 436 the select. The body of the variant structure may be given a label 437 for reference. The mechanism by which the variant is selected at 438 runtime is not prescribed by the presentation language. 440 struct { 441 T1 f1; 442 T2 f2; 443 .... 444 Tn fn; 445 select (E) { 446 case e1: Te1; 447 case e2: Te2; 448 .... 449 case en: Ten; 450 } [[fv]]; 451 } [[Tv]]; 453 For example: 455 enum { apple, orange } VariantTag; 456 struct { 457 uint16 number; 458 opaque string<0..10>; /* variable length */ 459 } V1; 460 struct { 461 uint32 number; 462 opaque string[10]; /* fixed length */ 463 } V2; 464 struct { 465 select (VariantTag) { /* value of selector is implicit */ 466 case apple: V1; /* VariantBody, tag = apple */ 467 case orange: V2; /* VariantBody, tag = orange */ 468 } variant_body; /* optional label on variant */ 469 } VariantRecord; 471 Variant structures may be qualified (narrowed) by specifying a value 472 for the selector prior to the type. For example, a 473 orange VariantRecord 475 is a narrowed type of a VariantRecord containing a variant_body of 476 type V2. 478 4.7. Cryptographic attributes 480 The four cryptographic operations digital signing, stream cipher 481 encryption, block cipher encryption, and public key encryption are 482 designated digitally-signed, stream-ciphered, block-ciphered, and 483 public-key-encrypted, respectively. A field's cryptographic 484 processing is specified by prepending an appropriate key word 485 designation before the field's type specification. Cryptographic keys 486 are implied by the current session state (see Section 6.1). 488 In digital signing, one-way hash functions are used as input for a 489 signing algorithm. A digitally-signed element is encoded as an opaque 490 vector <0..2^16-1>, where the length is specified by the signing 491 algorithm and key. 493 In RSA signing, the output of the chosen hash function is encoded as 494 a PKCS #1 DigestInfo and then signed using block type 01 as described 495 in Section 8.1 as described in [PKCS1A]. 497 Note: the standard reference for PKCS#1 is now RFC 3447 [PKCS1B]. 498 However, to minimize differences with TLS 1.0 text, we are using the 499 terminology of RFC 2313 [PKCS1A]. 501 In DSS, the 20 bytes of the SHA-1 hash are run directly through the 502 Digital Signing Algorithm with no additional hashing. This produces 503 two values, r and s. The DSS signature is an opaque vector, as above, 504 the contents of which are the DER encoding of: 506 Dss-Sig-Value ::= SEQUENCE { 507 r INTEGER, 508 s INTEGER 509 } 511 In stream cipher encryption, the plaintext is exclusive-ORed with an 512 identical amount of output generated from a cryptographically-secure 513 keyed pseudorandom number generator. 515 In block cipher encryption, every block of plaintext encrypts to a 516 block of ciphertext. All block cipher encryption is done in CBC 517 (Cipher Block Chaining) mode, and all items which are block-ciphered 518 will be an exact multiple of the cipher block length. 520 In public key encryption, a public key algorithm is used to encrypt 521 data in such a way that it can be decrypted only with the matching 522 private key. A public-key-encrypted element is encoded as an opaque 523 vector <0..2^16-1>, where the length is specified by the signing 524 algorithm and key. 526 An RSA encrypted value is encoded with PKCS #1 block type 2 as 527 described in [PKCS1A]. 529 In the following example: 531 stream-ciphered struct { 532 uint8 field1; 533 uint8 field2; 534 digitally-signed opaque hash[20]; 535 } UserType; 537 The contents of hash are used as input for the signing algorithm, 538 then the entire structure is encrypted with a stream cipher. The 539 length of this structure, in bytes would be equal to 2 bytes for 540 field1 and field2, plus two bytes for the length of the signature, 541 plus the length of the output of the signing algorithm. This is known 542 due to the fact that the algorithm and key used for the signing are 543 known prior to encoding or decoding this structure. 545 4.8. Constants 547 Typed constants can be defined for purposes of specification by 548 declaring a symbol of the desired type and assigning values to it. 549 Under-specified types (opaque, variable length vectors, and 550 structures that contain opaque) cannot be assigned values. No fields 551 of a multi-element structure or vector may be elided. 553 For example, 555 struct { 556 uint8 f1; 557 uint8 f2; 558 } Example1; 560 Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */ 562 5. HMAC and the pseudorandom function 564 A number of operations in the TLS record and handshake layer required 565 a keyed MAC; this is a secure digest of some data protected by a 566 secret. Forging the MAC is infeasible without knowledge of the MAC 567 secret. The construction we use for this operation is known as HMAC, 568 described in [HMAC]. 570 In addition, a construction is required to do expansion of secrets 571 into blocks of data for the purposes of key generation or validation. 572 This pseudo-random function (PRF) takes as input a secret, a seed, 573 and an identifying label and produces an output of arbitrary length. 575 First, we define a data expansion function, P_hash(secret, data) 576 which uses a single hash function to expand a secret and seed into an 577 arbitrary quantity of output: 579 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + 580 HMAC_hash(secret, A(2) + seed) + 581 HMAC_hash(secret, A(3) + seed) + ... 583 Where + indicates concatenation. 585 A() is defined as: 586 A(0) = seed 587 A(i) = HMAC_hash(secret, A(i-1)) 589 P_hash can be iterated as many times as is necessary to produce the 590 required quantity of data. For example, if P_SHA-1 was being used to 591 create 64 bytes of data, it would have to be iterated 4 times 592 (through A(4)), creating 80 bytes of output data; the last 16 bytes 593 of the final iteration would then be discarded, leaving 64 bytes of 594 output data. 596 TLS's PRF is created by applying P_hash to the secret S. The hash 597 function used in P MUST be the same hash function selected for the 598 HMAC in the cipher suite. 600 The label is an ASCII string. It should be included in the exact form 601 it is given without a length byte or trailing null character. For 602 example, the label "slithy toves" would be processed by hashing the 603 following bytes: 605 73 6C 69 74 68 79 20 74 6F 76 65 73 607 6. The TLS Record Protocol 609 The TLS Record Protocol is a layered protocol. At each layer, 610 messages may include fields for length, description, and content. 611 The Record Protocol takes messages to be transmitted, fragments the 612 data into manageable blocks, optionally compresses the data, applies 613 a MAC, encrypts, and transmits the result. Received data is 614 decrypted, verified, decompressed, and reassembled, then delivered to 615 higher level clients. 617 Four record protocol clients are described in this document: the 618 handshake protocol, the alert protocol, the change cipher spec 619 protocol, and the application data protocol. In order to allow 620 extension of the TLS protocol, additional record types can be 621 supported by the record protocol. Any new record types SHOULD 622 allocate type values immediately beyond the ContentType values for 623 the four record types described here (see Appendix A.1). All such 624 values must be defined by RFC 2434 Standards Action. See section 11 625 for IANA Considerations for ContentType values. 627 If a TLS implementation receives a record type it does not 628 understand, it SHOULD just ignore it. Any protocol designed for use 629 over TLS MUST be carefully designed to deal with all possible attacks 630 against it. Note that because the type and length of a record are 631 not protected by encryption, care SHOULD be taken to minimize the 632 value of traffic analysis of these values. 634 6.1. Connection states 636 A TLS connection state is the operating environment of the TLS Record 637 Protocol. It specifies a compression algorithm, encryption algorithm, 638 and MAC algorithm. In addition, the parameters for these algorithms 639 are known: the MAC secret and the bulk encryption keys for the 640 connection in both the read and the write directions. Logically, 641 there are always four connection states outstanding: the current read 642 and write states, and the pending read and write states. All records 643 are processed under the current read and write states. The security 644 parameters for the pending states can be set by the TLS Handshake 645 Protocol, and the Change Cipher Spec can selectively make either of 646 the pending states current, in which case the appropriate current 647 state is disposed of and replaced with the pending state; the pending 648 state is then reinitialized to an empty state. It is illegal to make 649 a state which has not been initialized with security parameters a 650 current state. The initial current state always specifies that no 651 encryption, compression, or MAC will be used. 653 The security parameters for a TLS Connection read and write state are 654 set by providing the following values: 656 connection end 657 Whether this entity is considered the "client" or the "server" in 658 this connection. 660 bulk encryption algorithm 661 An algorithm to be used for bulk encryption. This specification 662 includes the key size of this algorithm, how much of that key is 663 secret, whether it is a block or stream cipher, the block size of 664 the cipher (if appropriate). 666 MAC algorithm 667 An algorithm to be used for message authentication. This 668 specification includes the size of the hash which is returned by 669 the MAC algorithm. 671 compression algorithm 672 An algorithm to be used for data compression. This specification 673 must include all information the algorithm requires to do 674 compression. 676 master secret 677 A 48 byte secret shared between the two peers in the connection. 679 client random 680 A 32 byte value provided by the client. 682 server random 683 A 32 byte value provided by the server. 685 These parameters are defined in the presentation language as: 687 enum { server, client } ConnectionEnd; 689 enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm; 691 enum { stream, block } CipherType; 693 enum { null, md5, sha } MACAlgorithm; 695 enum { null(0), (255) } CompressionMethod; 697 /* The algorithms specified in CompressionMethod, 698 BulkCipherAlgorithm, and MACAlgorithm may be added to. */ 700 struct { 701 ConnectionEnd entity; 702 BulkCipherAlgorithm bulk_cipher_algorithm; 703 CipherType cipher_type; 704 uint8 key_size; 705 uint8 key_material_length; 706 MACAlgorithm mac_algorithm; 707 uint8 hash_size; 708 CompressionMethod compression_algorithm; 709 opaque master_secret[48]; 710 opaque client_random[32]; 711 opaque server_random[32]; 712 } SecurityParameters; 713 The record layer will use the security parameters to generate the 714 following four items: 716 client write MAC secret 717 server write MAC secret 718 client write key 719 server write key 721 The client write parameters are used by the server when receiving and 722 processing records and vice-versa. The algorithm used for generating 723 these items from the security parameters is described in section 6.3. 725 Once the security parameters have been set and the keys have been 726 generated, the connection states can be instantiated by making them 727 the current states. These current states MUST be updated for each 728 record processed. Each connection state includes the following 729 elements: 731 compression state 732 The current state of the compression algorithm. 734 cipher state 735 The current state of the encryption algorithm. This will consist 736 of the scheduled key for that connection. For stream ciphers, 737 this will also contain whatever the necessary state information 738 is to allow the stream to continue to encrypt or decrypt data. 740 MAC secret 741 The MAC secret for this connection as generated above. 743 sequence number 744 Each connection state contains a sequence number, which is 745 maintained separately for read and write states. The sequence 746 number MUST be set to zero whenever a connection state is made 747 the active state. Sequence numbers are of type uint64 and may not 748 exceed 2^64-1. Sequence numbers do not wrap. If a TLS 749 implementation would need to wrap a sequence number it must 750 renegotiate instead. A sequence number is incremented after each 751 record: specifically, the first record which is transmitted under 752 a particular connection state MUST use sequence number 0. 754 6.2. Record layer 756 The TLS Record Layer receives uninterpreted data from higher layers 757 in non-empty blocks of arbitrary size. 759 6.2.1. Fragmentation 760 The record layer fragments information blocks into TLSPlaintext 761 records carrying data in chunks of 2^14 bytes or less. Client message 762 boundaries are not preserved in the record layer (i.e., multiple 763 client messages of the same ContentType MAY be coalesced into a 764 single TLSPlaintext record, or a single message MAY be fragmented 765 across several records). 767 struct { 768 uint8 major, minor; 769 } ProtocolVersion; 771 enum { 772 change_cipher_spec(20), alert(21), handshake(22), 773 application_data(23), (255) 774 } ContentType; 776 struct { 777 ContentType type; 778 ProtocolVersion version; 779 uint16 length; 780 opaque fragment[TLSPlaintext.length]; 781 } TLSPlaintext; 783 type 784 The higher level protocol used to process the enclosed fragment. 786 version 787 The version of the protocol being employed. This document 788 describes TLS Version 1.2, which uses the version { 3, 3 }. The 789 version value 3.3 is historical, deriving from the use of 3.1 for 790 TLS 1.0. (See Appendix A.1). 792 length 793 The length (in bytes) of the following TLSPlaintext.fragment. 794 The length should not exceed 2^14. 796 fragment 797 The application data. This data is transparent and treated as an 798 independent block to be dealt with by the higher level protocol 799 specified by the type field. 801 Note: Data of different TLS Record layer content types MAY be 802 interleaved. Application data is generally of lower precedence 803 for transmission than other content types. However, records MUST 804 be delivered to the network in the same order as they are 805 protected by the record layer. Recipients MUST receive and 806 process interleaved application layer traffic during handshakes 807 subsequent to the first one on a connection. 809 6.2.2. Record compression and decompression 811 All records are compressed using the compression algorithm defined in 812 the current session state. There is always an active compression 813 algorithm; however, initially it is defined as 814 CompressionMethod.null. The compression algorithm translates a 815 TLSPlaintext structure into a TLSCompressed structure. Compression 816 functions are initialized with default state information whenever a 817 connection state is made active. 819 Compression must be lossless and may not increase the content length 820 by more than 1024 bytes. If the decompression function encounters a 821 TLSCompressed.fragment that would decompress to a length in excess of 822 2^14 bytes, it should report a fatal decompression failure error. 824 struct { 825 ContentType type; /* same as TLSPlaintext.type */ 826 ProtocolVersion version;/* same as TLSPlaintext.version */ 827 uint16 length; 828 opaque fragment[TLSCompressed.length]; 829 } TLSCompressed; 831 length 832 The length (in bytes) of the following TLSCompressed.fragment. 833 The length should not exceed 2^14 + 1024. 835 fragment 836 The compressed form of TLSPlaintext.fragment. 838 Note: A CompressionMethod.null operation is an identity operation; no 839 fields are altered. 841 Implementation note: 842 Decompression functions are responsible for ensuring that 843 messages cannot cause internal buffer overflows. 845 6.2.3. Record payload protection 847 The encryption and MAC functions translate a TLSCompressed structure 848 into a TLSCiphertext. The decryption functions reverse the process. 849 The MAC of the record also includes a sequence number so that 850 missing, extra or repeated messages are detectable. 852 struct { 853 ContentType type; 854 ProtocolVersion version; 855 uint16 length; 856 select (CipherSpec.cipher_type) { 857 case stream: GenericStreamCipher; 858 case block: GenericBlockCipher; 859 } fragment; 860 } TLSCiphertext; 862 type 863 The type field is identical to TLSCompressed.type. 865 version 866 The version field is identical to TLSCompressed.version. 868 length 869 The length (in bytes) of the following TLSCiphertext.fragment. 870 The length may not exceed 2^14 + 2048. 872 fragment 873 The encrypted form of TLSCompressed.fragment, with the MAC. 875 6.2.3.1. Null or standard stream cipher 877 Stream ciphers (including BulkCipherAlgorithm.null - see Appendix 878 A.6) convert TLSCompressed.fragment structures to and from stream 879 TLSCiphertext.fragment structures. 881 stream-ciphered struct { 882 opaque content[TLSCompressed.length]; 883 opaque MAC[CipherSpec.hash_size]; 884 } GenericStreamCipher; 886 The MAC is generated as: 888 HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + 889 TLSCompressed.version + TLSCompressed.length + 890 TLSCompressed.fragment)); 892 where "+" denotes concatenation. 894 seq_num 895 The sequence number for this record. 897 hash 898 The hashing algorithm specified by 899 SecurityParameters.mac_algorithm. 901 Note that the MAC is computed before encryption. The stream cipher 902 encrypts the entire block, including the MAC. For stream ciphers that 903 do not use a synchronization vector (such as RC4), the stream cipher 904 state from the end of one record is simply used on the subsequent 905 packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption 906 consists of the identity operation (i.e., the data is not encrypted 907 and the MAC size is zero implying that no MAC is used). 908 TLSCiphertext.length is TLSCompressed.length plus 909 CipherSpec.hash_size. 911 6.2.3.2. CBC block cipher 913 For block ciphers (such as RC2, DES, or AES), the encryption and MAC 914 functions convert TLSCompressed.fragment structures to and from block 915 TLSCiphertext.fragment structures. 917 block-ciphered struct { 918 opaque IV[CipherSpec.block_length]; 919 opaque content[TLSCompressed.length]; 920 opaque MAC[CipherSpec.hash_size]; 921 uint8 padding[GenericBlockCipher.padding_length]; 922 uint8 padding_length; 923 } GenericBlockCipher; 925 The MAC is generated as described in Section 6.2.3.1. 927 IV 928 Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit 929 IV in order to prevent the attacks described by [CBCATT]. 930 We recommend the following equivalently strong procedures. 931 For clarity we use the following notation. 933 IV -- the transmitted value of the IV field in the 934 GenericBlockCipher structure. 935 CBC residue -- the last ciphertext block of the previous record 936 mask -- the actual value which the cipher XORs with the 937 plaintext prior to encryption of the first cipher block 938 of the record. 940 In prior versions of TLS, there was no IV field and the CBC residue 941 and mask were one and the same. See Sections 6.1, 6.2.3.2 and 6.3, 942 of [TLS1.0] for details of TLS 1.0 IV handling. 944 One of the following two algorithms SHOULD be used to generate the 945 per-record IV: 947 (1) Generate a cryptographically strong random string R of 948 length CipherSpec.block_length. Place R 949 in the IV field. Set the mask to R. Thus, the first 950 cipher block will be encrypted as E(R XOR Data). 952 (2) Generate a cryptographically strong random number R of 953 length CipherSpec.block_length and prepend it to the plaintext 954 prior to encryption. In 955 this case either: 957 (a) The cipher may use a fixed mask such as zero. 958 (b) The CBC residue from the previous record may be used 959 as the mask. This preserves maximum code compatibility 960 with TLS 1.0 and SSL 3. It also has the advantage that 961 it does not require the ability to quickly reset the IV, 962 which is known to be a problem on some systems. 964 In either 2(a) or 2(b) the data (R || data) is fed into the 965 encryption process. The first cipher block (containing 966 E(mask XOR R) is placed in the IV field. The first 967 block of content contains E(IV XOR data) 969 The following alternative procedure MAY be used: However, it has 970 not been demonstrated to be equivalently cryptographically strong 971 to the above procedures. The sender prepends a fixed block F to 972 the plaintext (or alternatively a block generated with a weak 973 PRNG). He then encrypts as in (2) above, using the CBC residue 974 from the previous block as the mask for the prepended block. Note 975 that in this case the mask for the first record transmitted by 976 the application (the Finished) MUST be generated using a 977 cryptographically strong PRNG. 979 The decryption operation for all three alternatives is the same. 980 The receiver decrypts the entire GenericBlockCipher structure and 981 then discards the first cipher block, corresponding to the IV 982 component. 984 padding 985 Padding that is added to force the length of the plaintext to be 986 an integral multiple of the block cipher's block length. The 987 padding MAY be any length up to 255 bytes long, as long as it 988 results in the TLSCiphertext.length being an integral multiple of 989 the block length. Lengths longer than necessary might be 990 desirable to frustrate attacks on a protocol based on analysis of 991 the lengths of exchanged messages. Each uint8 in the padding data 992 vector MUST be filled with the padding length value. The receiver 993 MUST check this padding and SHOULD use the bad_record_mac alert 994 to indicate padding errors. 996 padding_length 997 The padding length MUST be such that the total size of the 998 GenericBlockCipher structure is a multiple of the cipher's block 999 length. Legal values range from zero to 255, inclusive. This 1000 length specifies the length of the padding field exclusive of the 1001 padding_length field itself. 1003 The encrypted data length (TLSCiphertext.length) is one more than the 1004 sum of TLSCompressed.length, CipherSpec.hash_size, and 1005 padding_length. 1007 Example: If the block length is 8 bytes, the content length 1008 (TLSCompressed.length) is 61 bytes, and the MAC length is 20 1009 bytes, the length before padding is 82 bytes (this does not 1010 include the IV, which may or may not be encrypted, as 1011 discussed above). Thus, the padding length modulo 8 must be 1012 equal to 6 in order to make the total length an even multiple 1013 of 8 bytes (the block length). The padding length can be 6, 1014 14, 22, and so on, through 254. If the padding length were the 1015 minimum necessary, 6, the padding would be 6 bytes, each 1016 containing the value 6. Thus, the last 8 octets of the 1017 GenericBlockCipher before block encryption would be xx 06 06 1018 06 06 06 06 06, where xx is the last octet of the MAC. 1020 Note: With block ciphers in CBC mode (Cipher Block Chaining), 1021 it is critical that the entire plaintext of the record be known 1022 before any ciphertext is transmitted. Otherwise it is possible 1023 for the attacker to mount the attack described in [CBCATT]. 1025 Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a 1026 timing attack on CBC padding based on the time required to 1027 compute the MAC. In order to defend against this attack, 1028 implementations MUST ensure that record processing time is 1029 essentially the same whether or not the padding is correct. In 1030 general, the best way to to do this is to compute the MAC even if 1031 the padding is incorrect, and only then reject the packet. For 1032 instance, if the pad appears to be incorrect the implementation 1033 might assume a zero-length pad and then compute the MAC. This 1034 leaves a small timing channel, since MAC performance depends to 1035 some extent on the size of the data fragment, but it is not 1036 believed to be large enough to be exploitable due to the large 1037 block size of existing MACs and the small size of the timing 1038 signal. 1040 6.3. Key calculation 1042 The Record Protocol requires an algorithm to generate keys, and MAC 1043 secrets from the security parameters provided by the handshake 1044 protocol. 1046 The master secret is hashed into a sequence of secure bytes, which 1047 are assigned to the MAC secrets and keys required by the current 1048 connection state (see Appendix A.6). CipherSpecs require a client 1049 write MAC secret, a server write MAC secret, a client write key, and 1050 a server write key, which are generated from the master secret in 1051 that order. Unused values are empty. 1053 When generating keys and MAC secrets, the master secret is used as an 1054 entropy source. 1056 To generate the key material, compute 1058 key_block = PRF(SecurityParameters.master_secret, 1059 "key expansion", 1060 SecurityParameters.server_random + 1061 SecurityParameters.client_random); 1063 until enough output has been generated. Then the key_block is 1064 partitioned as follows: 1066 client_write_MAC_secret[SecurityParameters.hash_size] 1067 server_write_MAC_secret[SecurityParameters.hash_size] 1068 client_write_key[SecurityParameters.key_material_length] 1069 server_write_key[SecurityParameters.key_material_length] 1071 Implementation note: 1072 The currently defined which requires the most material is 1073 AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte 1074 keys and 2 x 20 byte MAC secrets, for a total 104 bytes of key 1075 material. 1077 7. The TLS Handshaking Protocols 1079 TLS has three subprotocols which are used to allow peers to agree 1080 upon security parameters for the record layer, authenticate 1081 themselves, instantiate negotiated security parameters, and 1082 report error conditions to each other. 1084 The Handshake Protocol is responsible for negotiating a session, 1085 which consists of the following items: 1087 session identifier 1088 An arbitrary byte sequence chosen by the server to identify an 1089 active or resumable session state. 1091 peer certificate 1092 X509v3 [X509] certificate of the peer. This element of the 1093 state may be null. 1095 compression method 1096 The algorithm used to compress data prior to encryption. 1098 cipher spec 1099 Specifies the bulk data encryption algorithm (such as null, 1100 DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also 1101 defines cryptographic attributes such as the hash_size. (See 1102 Appendix A.6 for formal definition) 1104 master secret 1105 48-byte secret shared between the client and server. 1107 is resumable 1108 A flag indicating whether the session can be used to initiate 1109 new connections. 1111 These items are then used to create security parameters for use by 1112 the Record Layer when protecting application data. Many connections 1113 can be instantiated using the same session through the resumption 1114 feature of the TLS Handshake Protocol. 1116 7.1. Change cipher spec protocol 1118 The change cipher spec protocol exists to signal transitions in 1119 ciphering strategies. The protocol consists of a single message, 1120 which is encrypted and compressed under the current (not the pending) 1121 connection state. The message consists of a single byte of value 1. 1123 struct { 1124 enum { change_cipher_spec(1), (255) } type; 1125 } ChangeCipherSpec; 1127 The change cipher spec message is sent by both the client and server 1128 to notify the receiving party that subsequent records will be 1129 protected under the newly negotiated CipherSpec and keys. Reception 1130 of this message causes the receiver to instruct the Record Layer to 1131 immediately copy the read pending state into the read current state. 1132 Immediately after sending this message, the sender MUST instruct the 1133 record layer to make the write pending state the write active state. 1134 (See section 6.1.) The change cipher spec message is sent during the 1135 handshake after the security parameters have been agreed upon, but 1136 before the verifying finished message is sent (see section 7.4.11 1138 Note: if a rehandshake occurs while data is flowing on a connection, 1139 the communicating parties may continue to send data using the old 1140 CipherSpec. However, once the ChangeCipherSpec has been sent, the new 1141 CipherSpec MUST be used. The first side to send the ChangeCipherSpec 1142 does not know that the other side has finished computing the new 1143 keying material (e.g. if it has to perform a time consuming public 1144 key operation). Thus, a small window of time during which the 1145 recipient must buffer the data MAY exist. In practice, with modern 1146 machines this interval is likely to be fairly short. 1148 7.2. Alert protocol 1150 One of the content types supported by the TLS Record layer is the 1151 alert type. Alert messages convey the severity of the message and a 1152 description of the alert. Alert messages with a level of fatal result 1153 in the immediate termination of the connection. In this case, other 1154 connections corresponding to the session may continue, but the 1155 session identifier MUST be invalidated, preventing the failed session 1156 from being used to establish new connections. Like other messages, 1157 alert messages are encrypted and compressed, as specified by the 1158 current connection state. 1160 enum { warning(1), fatal(2), (255) } AlertLevel; 1162 enum { 1163 close_notify(0), 1164 unexpected_message(10), 1165 bad_record_mac(20), 1166 decryption_failed(21), 1167 record_overflow(22), 1168 decompression_failure(30), 1169 handshake_failure(40), 1170 no_certificate_RESERVED (41), 1171 bad_certificate(42), 1172 unsupported_certificate(43), 1173 certificate_revoked(44), 1174 certificate_expired(45), 1175 certificate_unknown(46), 1176 illegal_parameter(47), 1177 unknown_ca(48), 1178 access_denied(49), 1179 decode_error(50), 1180 decrypt_error(51), 1181 export_restriction_RESERVED(60), 1182 protocol_version(70), 1183 insufficient_security(71), 1184 internal_error(80), 1185 user_canceled(90), 1186 no_renegotiation(100), 1187 unsupported_extension(110), /* new */ 1188 certificate_unobtainable(111), /* new */ 1189 unrecognized_name(112), /* new */ 1190 bad_certificate_status_response(113), /* new */ 1191 bad_certificate_hash_value(114), /* new */ 1192 (255) 1193 } AlertDescription; 1195 struct { 1196 AlertLevel level; 1197 AlertDescription description; 1198 } Alert; 1200 7.2.1. Closure alerts 1202 The client and the server must share knowledge that the connection is 1203 ending in order to avoid a truncation attack. Either party may 1204 initiate the exchange of closing messages. 1206 close_notify 1207 This message notifies the recipient that the sender will not send 1208 any more messages on this connection. Note that as of TLS 1.1, 1209 failure to properly close a connection no longer requires that a 1210 session not be resumed. This is a change from TLS 1.0 to conform 1211 with widespread implementation practice. 1213 Either party may initiate a close by sending a close_notify alert. 1214 Any data received after a closure alert is ignored. 1216 Unless some other fatal alert has been transmitted, each party is 1217 required to send a close_notify alert before closing the write side 1218 of the connection. The other party MUST respond with a close_notify 1219 alert of its own and close down the connection immediately, 1220 discarding any pending writes. It is not required for the initiator 1221 of the close to wait for the responding close_notify alert before 1222 closing the read side of the connection. 1224 If the application protocol using TLS provides that any data may be 1225 carried over the underlying transport after the TLS connection is 1226 closed, the TLS implementation must receive the responding 1227 close_notify alert before indicating to the application layer that 1228 the TLS connection has ended. If the application protocol will not 1229 transfer any additional data, but will only close the underlying 1230 transport connection, then the implementation MAY choose to close the 1231 transport without waiting for the responding close_notify. No part of 1232 this standard should be taken to dictate the manner in which a usage 1233 profile for TLS manages its data transport, including when 1234 connections are opened or closed. 1236 Note: It is assumed that closing a connection reliably delivers 1237 pending data before destroying the transport. 1239 7.2.2. Error alerts 1241 Error handling in the TLS Handshake protocol is very simple. When an 1242 error is detected, the detecting party sends a message to the other 1243 party. Upon transmission or receipt of an fatal alert message, both 1244 parties immediately close the connection. Servers and clients MUST 1245 forget any session-identifiers, keys, and secrets associated with a 1246 failed connection. Thus, any connection terminated with a fatal alert 1247 MUST NOT be resumed. The following error alerts are defined: 1249 unexpected_message 1250 An inappropriate message was received. This alert is always fatal 1251 and should never be observed in communication between proper 1252 implementations. 1254 bad_record_mac 1255 This alert is returned if a record is received with an incorrect 1256 MAC. This alert also MUST be returned if an alert is sent because 1257 a TLSCiphertext decrypted in an invalid way: either it wasn't an 1258 even multiple of the block length, or its padding values, when 1259 checked, weren't correct. This message is always fatal. 1261 decryption_failed 1262 This alert MAY be returned if a TLSCiphertext decrypted in an 1263 invalid way: either it wasn't an even multiple of the block 1264 length, or its padding values, when checked, weren't correct. 1265 This message is always fatal. 1267 Note: Differentiating between bad_record_mac and 1268 decryption_failed alerts may permit certain attacks against CBC 1269 mode as used in TLS [CBCATT]. It is preferable to uniformly use 1270 the bad_record_mac alert to hide the specific type of the error. 1272 record_overflow 1273 A TLSCiphertext record was received which had a length more than 1274 2^14+2048 bytes, or a record decrypted to a TLSCompressed record 1275 with more than 2^14+1024 bytes. This message is always fatal. 1277 decompression_failure 1278 The decompression function received improper input (e.g. data 1279 that would expand to excessive length). This message is always 1280 fatal. 1282 handshake_failure 1283 Reception of a handshake_failure alert message indicates that the 1284 sender was unable to negotiate an acceptable set of security 1285 parameters given the options available. This is a fatal error. 1287 no_certificate_RESERVED 1288 This alert was used in SSLv3 but not in TLS. It should not be 1289 sent by compliant implementations. 1291 bad_certificate 1292 A certificate was corrupt, contained signatures that did not 1293 verify correctly, etc. 1295 unsupported_certificate 1296 A certificate was of an unsupported type. 1298 certificate_revoked 1299 A certificate was revoked by its signer. 1301 certificate_expired 1302 A certificate has expired or is not currently valid. 1304 certificate_unknown 1305 Some other (unspecified) issue arose in processing the 1306 certificate, rendering it unacceptable. 1308 illegal_parameter 1309 A field in the handshake was out of range or inconsistent with 1310 other fields. This is always fatal. 1312 unknown_ca 1313 A valid certificate chain or partial chain was received, but the 1314 certificate was not accepted because the CA certificate could not 1315 be located or couldn't be matched with a known, trusted CA. This 1316 message is always fatal. 1318 access_denied 1319 A valid certificate was received, but when access control was 1320 applied, the sender decided not to proceed with negotiation. 1321 This message is always fatal. 1323 decode_error 1324 A message could not be decoded because some field was out of the 1325 specified range or the length of the message was incorrect. This 1326 message is always fatal. 1328 decrypt_error 1329 A handshake cryptographic operation failed, including being 1330 unable to correctly verify a signature, decrypt a key exchange, 1331 or validate a finished message. 1333 export_restriction_RESERVED 1334 This alert was used in TLS 1.0 but not TLS 1.1. 1336 protocol_version 1337 The protocol version the client has attempted to negotiate is 1338 recognized, but not supported. (For example, old protocol 1339 versions might be avoided for security reasons). This message is 1340 always fatal. 1342 insufficient_security 1343 Returned instead of handshake_failure when a negotiation has 1344 failed specifically because the server requires ciphers more 1345 secure than those supported by the client. This message is always 1346 fatal. 1348 internal_error 1349 An internal error unrelated to the peer or the correctness of the 1350 protocol makes it impossible to continue (such as a memory 1351 allocation failure). This message is always fatal. 1353 user_canceled 1354 This handshake is being canceled for some reason unrelated to a 1355 protocol failure. If the user cancels an operation after the 1356 handshake is complete, just closing the connection by sending a 1357 close_notify is more appropriate. This alert should be followed 1358 by a close_notify. This message is generally a warning. 1360 no_renegotiation 1361 Sent by the client in response to a hello request or by the 1362 server in response to a client hello after initial handshaking. 1363 Either of these would normally lead to renegotiation; when that 1364 is not appropriate, the recipient should respond with this alert; 1365 at that point, the original requester can decide whether to 1366 proceed with the connection. One case where this would be 1367 appropriate would be where a server has spawned a process to 1368 satisfy a request; the process might receive security parameters 1369 (key length, authentication, etc.) at startup and it might be 1370 difficult to communicate changes to these parameters after that 1371 point. This message is always a warning. 1373 The following error alerts apply only to the extensions described 1374 in Section XXX. To avoid "breaking" existing clients and servers, 1375 these alerts MUST NOT be sent unless the sending party has 1376 received an extended hello message from the party they are 1377 communicating with. 1379 unsupported_extension 1380 sent by clients that receive an extended server hello containing 1381 an extension that they did not put in the corresponding client 1382 hello (see Section 2.3). This message is always fatal. 1384 unrecognized_name 1385 sent by servers that receive a server_name extension request, but 1386 do not recognize the server name. This message MAY be fatal. 1388 certificate_unobtainable 1389 sent by servers who are unable to retrieve a certificate chain 1390 from the URL supplied by the client (see Section 3.3). This 1391 message MAY be fatal - for example if client authentication is 1392 required by the server for the handshake to continue and the 1393 server is unable to retrieve the certificate chain, it may send a 1394 fatal alert. 1396 bad_certificate_status_response 1397 sent by clients that receive an invalid certificate status 1398 response (see Section 3.6). This message is always fatal. 1400 bad_certificate_hash_value 1401 sent by servers when a certificate hash does not match a client 1402 provided certificate_hash. This message is always fatal. 1404 For all errors where an alert level is not explicitly specified, the 1405 sending party MAY determine at its discretion whether this is a fatal 1406 error or not; if an alert with a level of warning is received, the 1407 receiving party MAY decide at its discretion whether to treat this as 1408 a fatal error or not. However, all messages which are transmitted 1409 with a level of fatal MUST be treated as fatal messages. 1411 New alerts values MUST be defined by RFC 2434 Standards Action. See 1412 Section 11 for IANA Considerations for alert values. 1414 7.3. Handshake Protocol overview 1416 The cryptographic parameters of the session state are produced by the 1417 TLS Handshake Protocol, which operates on top of the TLS Record 1418 Layer. When a TLS client and server first start communicating, they 1419 agree on a protocol version, select cryptographic algorithms, 1420 optionally authenticate each other, and use public-key encryption 1421 techniques to generate shared secrets. 1423 The TLS Handshake Protocol involves the following steps: 1425 - Exchange hello messages to agree on algorithms, exchange random 1426 values, and check for session resumption. 1428 - Exchange the necessary cryptographic parameters to allow the 1429 client and server to agree on a premaster secret. 1431 - Exchange certificates and cryptographic information to allow the 1432 client and server to authenticate themselves. 1434 - Generate a master secret from the premaster secret and exchanged 1435 random values. 1437 - Provide security parameters to the record layer. 1439 - Allow the client and server to verify that their peer has 1440 calculated the same security parameters and that the handshake 1441 occurred without tampering by an attacker. 1443 Note that higher layers should not be overly reliant on TLS always 1444 negotiating the strongest possible connection between two peers: 1445 there are a number of ways a man in the middle attacker can attempt 1446 to make two entities drop down to the least secure method they 1447 support. The protocol has been designed to minimize this risk, but 1448 there are still attacks available: for example, an attacker could 1449 block access to the port a secure service runs on, or attempt to get 1450 the peers to negotiate an unauthenticated connection. The fundamental 1451 rule is that higher levels must be cognizant of what their security 1452 requirements are and never transmit information over a channel less 1453 secure than what they require. The TLS protocol is secure, in that 1454 any cipher suite offers its promised level of security: if you 1455 negotiate 3DES with a 1024 bit RSA key exchange with a host whose 1456 certificate you have verified, you can expect to be that secure. 1458 However, you SHOULD never send data over a link encrypted with 40 bit 1459 security unless you feel that data is worth no more than the effort 1460 required to break that encryption. 1462 These goals are achieved by the handshake protocol, which can be 1463 summarized as follows: The client sends a client hello message to 1464 which the server must respond with a server hello message, or else a 1465 fatal error will occur and the connection will fail. The client hello 1466 and server hello are used to establish security enhancement 1467 capabilities between client and server. The client hello and server 1468 hello establish the following attributes: Protocol Version, Session 1469 ID, Cipher Suite, and Compression Method. Additionally, two random 1470 values are generated and exchanged: ClientHello.random and 1471 ServerHello.random. 1473 The actual key exchange uses up to four messages: the server 1474 certificate, the server key exchange, the client certificate, and the 1475 client key exchange. New key exchange methods can be created by 1476 specifying a format for these messages and defining the use of the 1477 messages to allow the client and server to agree upon a shared 1478 secret. This secret MUST be quite long; currently defined key 1479 exchange methods exchange secrets which range from 48 to 128 bytes in 1480 length. 1482 Following the hello messages, the server will send its certificate, 1483 if it is to be authenticated. Additionally, a server key exchange 1484 message may be sent, if it is required (e.g. if their server has no 1485 certificate, or if its certificate is for signing only). If the 1486 server is authenticated, it may request a certificate from the 1487 client, if that is appropriate to the cipher suite selected. Now the 1488 server will send the server hello done message, indicating that the 1489 hello-message phase of the handshake is complete. The server will 1490 then wait for a client response. If the server has sent a certificate 1491 request message, the client must send the certificate message. The 1492 client key exchange message is now sent, and the content of that 1493 message will depend on the public key algorithm selected between the 1494 client hello and the server hello. If the client has sent a 1495 certificate with signing ability, a digitally-signed certificate 1496 verify message is sent to explicitly verify the certificate. 1498 At this point, a change cipher spec message is sent by the client, 1499 and the client copies the pending Cipher Spec into the current Cipher 1500 Spec. The client then immediately sends the finished message under 1501 the new algorithms, keys, and secrets. In response, the server will 1502 send its own change cipher spec message, transfer the pending to the 1503 current Cipher Spec, and send its finished message under the new 1504 Cipher Spec. At this point, the handshake is complete and the client 1505 and server may begin to exchange application layer data. (See flow 1506 chart below.) Application data MUST NOT be sent prior to the 1507 completion of the first handshake (before a cipher suite other 1508 TLS_NULL_WITH_NULL_NULL is established). 1509 Client Server 1511 ClientHello --------> 1512 ServerHello 1513 Certificate* 1514 CertificateStatus* 1515 ServerKeyExchange* 1516 CertificateRequest* 1517 <-------- ServerHelloDone 1518 Certificate* 1519 CertificateURL* 1520 ClientKeyExchange 1521 CertificateVerify* 1522 [ChangeCipherSpec] 1523 Finished --------> 1524 [ChangeCipherSpec] 1525 <-------- Finished 1526 Application Data <-------> Application Data 1528 Fig. 1 - Message flow for a full handshake 1530 * Indicates optional or situation-dependent messages that are not 1531 always sent. 1533 Note: To help avoid pipeline stalls, ChangeCipherSpec is an 1534 independent TLS Protocol content type, and is not actually a TLS 1535 handshake message. 1537 When the client and server decide to resume a previous session or 1538 duplicate an existing session (instead of negotiating new security 1539 parameters) the message flow is as follows: 1541 The client sends a ClientHello using the Session ID of the session to 1542 be resumed. The server then checks its session cache for a match. If 1543 a match is found, and the server is willing to re-establish the 1544 connection under the specified session state, it will send a 1545 ServerHello with the same Session ID value. At this point, both 1546 client and server MUST send change cipher spec messages and proceed 1547 directly to finished messages. Once the re-establishment is complete, 1548 the client and server MAY begin to exchange application layer data. 1549 (See flow chart below.) If a Session ID match is not found, the 1550 server generates a new session ID and the TLS client and server 1551 perform a full handshake. 1553 Client Server 1555 ClientHello --------> 1556 ServerHello 1557 [ChangeCipherSpec] 1558 <-------- Finished 1559 [ChangeCipherSpec] 1560 Finished --------> 1561 Application Data <-------> Application Data 1563 Fig. 2 - Message flow for an abbreviated handshake 1565 The contents and significance of each message will be presented in 1566 detail in the following sections. 1568 7.4. Handshake protocol 1570 The TLS Handshake Protocol is one of the defined higher level clients 1571 of the TLS Record Protocol. This protocol is used to negotiate the 1572 secure attributes of a session. Handshake messages are supplied to 1573 the TLS Record Layer, where they are encapsulated within one or more 1574 TLSPlaintext structures, which are processed and transmitted as 1575 specified by the current active session state. 1577 enum { 1578 hello_request(0), client_hello(1), server_hello(2), 1579 certificate(11), server_key_exchange (12), 1580 certificate_request(13), server_hello_done(14), 1581 certificate_verify(15), client_key_exchange(16), 1582 finished(20), certificate_url(21), certificate_status(22), 1583 (255) 1584 } HandshakeType; 1586 struct { 1587 HandshakeType msg_type; /* handshake type */ 1588 uint24 length; /* bytes in message */ 1589 select (HandshakeType) { 1590 case hello_request: HelloRequest; 1591 case client_hello: ClientHello; 1592 case server_hello: ServerHello; 1593 case certificate: Certificate; 1594 case server_key_exchange: ServerKeyExchange; 1595 case certificate_request: CertificateRequest; 1596 case server_hello_done: ServerHelloDone; 1597 case certificate_verify: CertificateVerify; 1598 case client_key_exchange: ClientKeyExchange; 1599 case finished: Finished; 1600 case certificate_url: CertificateURL; 1601 case certificate_status: CertificateStatus; 1602 } body; 1603 } Handshake; 1605 The handshake protocol messages are presented below in the order they 1606 MUST be sent; sending handshake messages in an unexpected order 1607 results in a fatal error. Unneeded handshake messages can be omitted, 1608 however. Note one exception to the ordering: the Certificate message 1609 is used twice in the handshake (from server to client, then from 1610 client to server), but described only in its first position. The one 1611 message which is not bound by these ordering rules is the Hello 1612 Request message, which can be sent at any time, but which should be 1613 ignored by the client if it arrives in the middle of a handshake. 1615 New Handshake message type values MUST be defined via RFC 2434 1616 Standards Action. See Section 11 for IANA Considerations for these 1617 values. 1619 7.4.1. Hello messages 1621 The hello phase messages are used to exchange security enhancement 1622 capabilities between the client and server. When a new session 1623 begins, the Record Layer's connection state encryption, hash, and 1624 compression algorithms are initialized to null. The current 1625 connection state is used for renegotiation messages. 1627 7.4.1.1. Hello request 1629 When this message will be sent: 1630 The hello request message MAY be sent by the server at any time. 1632 Meaning of this message: 1633 Hello request is a simple notification that the client should 1634 begin the negotiation process anew by sending a client hello 1635 message when convenient. This message will be ignored by the 1636 client if the client is currently negotiating a session. This 1637 message may be ignored by the client if it does not wish to 1638 renegotiate a session, or the client may, if it wishes, respond 1639 with a no_renegotiation alert. Since handshake messages are 1640 intended to have transmission precedence over application data, 1641 it is expected that the negotiation will begin before no more 1642 than a few records are received from the client. If the server 1643 sends a hello request but does not receive a client hello in 1644 response, it may close the connection with a fatal alert. 1646 After sending a hello request, servers SHOULD not repeat the request 1647 until the subsequent handshake negotiation is complete. 1649 Structure of this message: 1650 struct { } HelloRequest; 1652 Note: This message MUST NOT be included in the message hashes which are 1653 maintained throughout the handshake and used in the finished 1654 messages and the certificate verify message. 1656 7.4.1.2. Client hello 1658 When this message will be sent: 1659 When a client first connects to a server it is required to send 1660 the client hello as its first message. The client can also send a 1661 client hello in response to a hello request or on its own 1662 initiative in order to renegotiate the security parameters in an 1663 existing connection. 1665 Structure of this message: 1666 The client hello message includes a random structure, which is 1667 used later in the protocol. 1669 struct { 1670 uint32 gmt_unix_time; 1671 opaque random_bytes[28]; 1672 } Random; 1674 gmt_unix_time 1675 The current time and date in standard UNIX 32-bit format (seconds 1676 since the midnight starting Jan 1, 1970, GMT, ignoring leap 1677 seconds) according to the sender's internal clock. Clocks are not 1678 required to be set correctly by the basic TLS Protocol; higher 1679 level or application protocols may define additional 1680 requirements. 1682 random_bytes 1683 28 bytes generated by a secure random number generator. 1685 The client hello message includes a variable length session 1686 identifier. If not empty, the value identifies a session between the 1687 same client and server whose security parameters the client wishes to 1688 reuse. The session identifier MAY be from an earlier connection, this 1689 connection, or another currently active connection. The second option 1690 is useful if the client only wishes to update the random structures 1691 and derived values of a connection, while the third option makes it 1692 possible to establish several independent secure connections without 1693 repeating the full handshake protocol. These independent connections 1694 may occur sequentially or simultaneously; a SessionID becomes valid 1695 when the handshake negotiating it completes with the exchange of 1696 Finished messages and persists until removed due to aging or because 1697 a fatal error was encountered on a connection associated with the 1698 session. The actual contents of the SessionID are defined by the 1699 server. 1701 opaque SessionID<0..32>; 1703 Warning: 1704 Because the SessionID is transmitted without encryption or 1705 immediate MAC protection, servers MUST not place confidential 1706 information in session identifiers or let the contents of fake 1707 session identifiers cause any breach of security. (Note that the 1708 content of the handshake as a whole, including the SessionID, is 1709 protected by the Finished messages exchanged at the end of the 1710 handshake.) 1712 The CipherSuite list, passed from the client to the server in the 1713 client hello message, contains the combinations of cryptographic 1714 algorithms supported by the client in order of the client's 1715 preference (favorite choice first). Each CipherSuite defines a key 1716 exchange algorithm, a bulk encryption algorithm (including secret key 1717 length) and a MAC algorithm. The server will select a cipher suite 1718 or, if no acceptable choices are presented, return a handshake 1719 failure alert and close the connection. 1721 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1723 The client hello includes a list of compression algorithms supported 1724 by the client, ordered according to the client's preference. 1726 enum { null(0), (255) } CompressionMethod; 1728 struct { 1729 ProtocolVersion client_version; 1730 Random random; 1731 SessionID session_id; 1732 CipherSuite cipher_suites<2..2^16-1>; 1733 CompressionMethod compression_methods<1..2^8-1>; 1734 } ClientHello; 1736 If the client wishes to use extensions (see Section XXX), 1737 it may send an ExtendedClientHello: 1739 struct { 1740 ProtocolVersion client_version; 1741 Random random; 1742 SessionID session_id; 1743 CipherSuite cipher_suites<2..2^16-1>; 1744 CompressionMethod compression_methods<1..2^8-1>; 1745 Extension client_hello_extension_list<0..2^16-1>; 1746 } ExtendedClientHello; 1748 These two messages can be distinguished by determining whether there 1749 are bytes following what would be the end of the ClientHello. 1751 client_version 1752 The version of the TLS protocol by which the client wishes to 1753 communicate during this session. This SHOULD be the latest 1754 (highest valued) version supported by the client. For this 1755 version of the specification, the version will be 3.2 (See 1756 Appendix E for details about backward compatibility). 1758 random 1759 A client-generated random structure. 1761 session_id 1762 The ID of a session the client wishes to use for this connection. 1763 This field should be empty if no session_id is available or the 1764 client wishes to generate new security parameters. 1766 cipher_suites 1767 This is a list of the cryptographic options supported by the 1768 client, with the client's first preference first. If the 1769 session_id field is not empty (implying a session resumption 1770 request) this vector MUST include at least the cipher_suite from 1771 that session. Values are defined in Appendix A.5. 1773 compression_methods 1774 This is a list of the compression methods supported by the 1775 client, sorted by client preference. If the session_id field is 1776 not empty (implying a session resumption request) it must include 1777 the compression_method from that session. This vector must 1778 contain, and all implementations must support, 1779 CompressionMethod.null. Thus, a client and server will always be 1780 able to agree on a compression method. 1782 client_hello_extension_list 1783 Clients MAY request extended functionality from servers by 1784 sending data in the client_hello_extension_list. Here the new 1785 "client_hello_extension_list" field contains a list of 1786 extensions. The actual "Extension" format is defined in Section 1787 XXX. 1789 In the event that a client requests additional functionality 1790 using the extended client hello, and this functionality is not 1791 supplied by the server, the client MAY abort the handshake. 1793 A server that supports the extensions mechanism MUST accept only 1794 client hello messages in either the original or extended 1795 ClientHello ormat, and (as for all other messages) MUST check 1796 that the amount of data in the message precisely matches one of 1797 these formats; if not then it MUST send a fatal "decode_error" 1798 alert. 1800 After sending the client hello message, the client waits for a server 1801 hello message. Any other handshake message returned by the server 1802 except for a hello request is treated as a fatal error. 1804 7.4.1.3. Server hello 1806 When this message will be sent: 1807 The server will send this message in response to a client hello 1808 message when it was able to find an acceptable set of algorithms. If 1809 it cannot find such a match, it will respond with a handshake failure 1810 alert. 1812 Structure of this message: 1813 struct { 1814 ProtocolVersion server_version; 1815 Random random; 1816 SessionID session_id; 1817 CipherSuite cipher_suite; 1818 CompressionMethod compression_method; 1819 } ServerHello; 1821 If the server is sending an extension, it should use the 1822 ExtendedServerHello: 1824 struct { 1825 ProtocolVersion server_version; 1826 Random random; 1827 SessionID session_id; 1828 CipherSuite cipher_suite; 1829 CompressionMethod compression_method; 1830 Extension server_hello_extension_list<0..2^16-1>; 1831 } ExtendedServerHello; 1833 These two messages can be distinguished by determining whether there 1834 are bytes following what would be the end of the ServerHello. 1836 server_version 1837 This field will contain the lower of that suggested by the client in 1838 the client hello and the highest supported by the server. For this 1839 version of the specification, the version is 3.2 (See Appendix E for 1840 details about backward compatibility). 1842 random 1843 This structure is generated by the server and MUST be independently 1844 generated from the ClientHello.random. 1846 session_id 1847 This is the identity of the session corresponding to this connection. 1848 If the ClientHello.session_id was non-empty, the server will look in 1849 its session cache for a match. If a match is found and the server is 1850 willing to establish the new connection using the specified session 1851 state, the server will respond with the same value as was supplied by 1852 the client. This indicates a resumed session and dictates that the 1853 parties must proceed directly to the finished messages. Otherwise 1854 this field will contain a different value identifying the new 1855 session. The server may return an empty session_id to indicate that 1856 the session will not be cached and therefore cannot be resumed. If a 1857 session is resumed, it must be resumed using the same cipher suite it 1858 was originally negotiated with. 1860 cipher_suite 1861 The single cipher suite selected by the server from the list in 1862 ClientHello.cipher_suites. For resumed sessions this field is the 1863 value from the state of the session being resumed. 1865 compression_method 1866 The single compression algorithm selected by the server from the list 1867 in ClientHello.compression_methods. For resumed sessions this field 1868 is the value from the resumed session state. 1870 server_hello_extension_list 1871 A list of extensions. Note that only extensions offered by the client 1872 can appear in the server's list. 1874 7.4.1.4 Hello Extensions 1876 The extension format for extended client hellos and extended server 1877 hellos is: 1879 struct { 1880 ExtensionType extension_type; 1881 opaque extension_data<0..2^16-1>; 1882 } Extension; 1883 Here: 1885 - "extension_type" identifies the particular extension type. 1887 - "extension_data" contains information specific to the particular 1888 extension type. 1890 The extension types defined in this document are: 1892 enum { 1893 server_name(0), max_fragment_length(1), 1894 client_certificate_url(2), trusted_ca_keys(3), 1895 truncated_hmac(4), status_request(5), 1896 cert_hash_types(6), (65535) 1897 } ExtensionType; 1899 The list of defined extension types is maintained by the IANA. The 1900 current list can be found at XXX (suggest 1901 http://www.iana.org/assignments/tls-extensions). See sections XXX and 1902 YYY for more information on how new values are added. 1904 Note that for all extension types (including those defined in 1905 future), the extension type MUST NOT appear in the extended server 1906 hello unless the same extension type appeared in the corresponding 1907 client hello. Thus clients MUST abort the handshake if they receive 1908 an extension type in the extended server hello that they did not 1909 request in the associated (extended) client hello. 1911 Nonetheless "server oriented" extensions may be provided in the 1912 future within this framework - such an extension, say of type x, 1913 would require the client to first send an extension of type x in the 1914 (extended) client hello with empty extension_data to indicate that it 1915 supports the extension type. In this case the client is offering the 1916 capability to understand the extension type, and the server is taking 1917 the client up on its offer. 1919 Also note that when multiple extensions of different types are 1920 present in the extended client hello or the extended server hello, 1921 the extensions may appear in any order. There MUST NOT be more than 1922 one extension of the same type. 1924 An extended client hello may be sent both when starting a new session 1925 and when requesting session resumption. Indeed a client that 1926 requests resumption of a session does not in general know whether the 1927 server will accept this request, and therefore it SHOULD send an 1928 extended client hello if it would normally do so for a new session. 1929 In general the specification of each extension type must include a 1930 discussion of the effect of the extension both during new sessions 1931 and during resumed sessions. 1933 Note also that all the extensions defined in this document are 1934 relevant only when a session is initiated. When a client includes one 1935 or more of the defined extension types in an extended client hello 1936 while requesting session resumption: 1938 - If the resumption request is denied, the use of the extensions 1939 is negotiated as normal. 1941 - If, on the other hand, the older session is resumed, then the 1942 server MUST ignore the extensions and send a server hello 1943 containing none of the extension types; in this case the 1944 functionality of these extensions negotiated during the original 1945 session initiation is applied to the resumed session. 1947 7.4.1.4.1 Server Name Indication 1949 [TLS1.1] does not provide a mechanism for a client to tell a server 1950 the name of the server it is contacting. It may be desirable for 1951 clients to provide this information to facilitate secure connections 1952 to servers that host multiple 'virtual' servers at a single 1953 underlying network address. 1955 In order to provide the server name, clients MAY include an extension 1956 of type "server_name" in the (extended) client hello. The 1957 "extension_data" field of this extension SHALL contain 1958 "ServerNameList" where: 1960 struct { 1961 NameType name_type; 1962 select (name_type) { 1963 case host_name: HostName; 1964 } name; 1965 } ServerName; 1967 enum { 1968 host_name(0), (255) 1969 } NameType; 1971 opaque HostName<1..2^16-1>; 1973 struct { 1974 ServerName server_name_list<1..2^16-1> 1975 } ServerNameList; 1977 Currently the only server names supported are DNS hostnames, however 1978 this does not imply any dependency of TLS on DNS, and other name 1979 types may be added in the future (by an RFC that Updates this 1980 document). TLS MAY treat provided server names as opaque data and 1981 pass the names and types to the application. 1983 "HostName" contains the fully qualified DNS hostname of the server, 1984 as understood by the client. The hostname is represented as a byte 1985 string using UTF-8 encoding [UTF8], without a trailing dot. 1987 If the hostname labels contain only US-ASCII characters, then the 1988 client MUST ensure that labels are separated only by the byte 0x2E, 1989 representing the dot character U+002E (requirement 1 in section 3.1 1990 of [IDNA] notwithstanding). If the server needs to match the HostName 1991 against names that contain non-US-ASCII characters, it MUST perform 1992 the conversion operation described in section 4 of [IDNA], treating 1993 the HostName as a "query string" (i.e. the AllowUnassigned flag MUST 1994 be set). Note that IDNA allows labels to be separated by any of the 1995 Unicode characters U+002E, U+3002, U+FF0E, and U+FF61, therefore 1996 servers MUST accept any of these characters as a label separator. If 1997 the server only needs to match the HostName against names containing 1998 exclusively ASCII characters, it MUST compare ASCII names case- 1999 insensitively. 2001 Literal IPv4 and IPv6 addresses are not permitted in "HostName". It 2002 is RECOMMENDED that clients include an extension of type 2003 "server_name" in the client hello whenever they locate a server by a 2004 supported name type. 2006 A server that receives a client hello containing the "server_name" 2007 extension, MAY use the information contained in the extension to 2008 guide its selection of an appropriate certificate to return to the 2009 client, and/or other aspects of security policy. In this event, the 2010 server SHALL include an extension of type "server_name" in the 2011 (extended) server hello. The "extension_data" field of this 2012 extension SHALL be empty. 2014 If the server understood the client hello extension but does not 2015 recognize the server name, it SHOULD send an "unrecognized_name" 2016 alert (which MAY be fatal). 2018 If an application negotiates a server name using an application 2019 protocol, then upgrades to TLS, and a server_name extension is sent, 2020 then the extension SHOULD contain the same name that was negotiated 2021 in the application protocol. If the server_name is established in 2022 the TLS session handshake, the client SHOULD NOT attempt to request a 2023 different server name at the application layer. 2025 7.4.1.4.2 Maximum Fragment Length Negotiation 2026 By default, TLS uses fixed maximum plaintext fragment length of 2^14 2027 bytes. It may be desirable for constrained clients to negotiate a 2028 smaller maximum fragment length due to memory limitations or 2029 bandwidth limitations. 2031 In order to negotiate smaller maximum fragment lengths, clients MAY 2032 include an extension of type "max_fragment_length" in the (extended) 2033 client hello. The "extension_data" field of this extension SHALL 2034 contain: 2036 enum{ 2037 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) 2038 } MaxFragmentLength; 2040 whose value is the desired maximum fragment length. The allowed 2041 values for this field are: 2^9, 2^10, 2^11, and 2^12. 2043 Servers that receive an extended client hello containing a 2044 "max_fragment_length" extension, MAY accept the requested maximum 2045 fragment length by including an extension of type 2046 "max_fragment_length" in the (extended) server hello. The 2047 "extension_data" field of this extension SHALL contain 2048 "MaxFragmentLength" whose value is the same as the requested maximum 2049 fragment length. 2051 If a server receives a maximum fragment length negotiation request 2052 for a value other than the allowed values, it MUST abort the 2053 handshake with an "illegal_parameter" alert. Similarly, if a client 2054 receives a maximum fragment length negotiation response that differs 2055 from the length it requested, it MUST also abort the handshake with 2056 an "illegal_parameter" alert. 2058 Once a maximum fragment length other than 2^14 has been successfully 2059 negotiated, the client and server MUST immediately begin fragmenting 2060 messages (including handshake messages), to ensure that no fragment 2061 larger than the negotiated length is sent. Note that TLS already 2062 requires clients and servers to support fragmentation of handshake 2063 messages. 2065 The negotiated length applies for the duration of the session 2066 including session resumptions. 2068 The negotiated length limits the input that the record layer may 2069 process without fragmentation (that is, the maximum value of 2070 TLSPlaintext.length; see [TLS] section 6.2.1). Note that the output 2071 of the record layer may be larger. For example, if the negotiated 2072 length is 2^9=512, then for currently defined cipher suites and when 2073 null compression is used, the record layer output can be at most 793 2074 bytes: 5 bytes of headers, 512 bytes of application data, 256 bytes 2075 of padding, and 20 bytes of MAC. That means that in this event a TLS 2076 record layer peer receiving a TLS record layer message larger than 2077 793 bytes may discard the message and send a "record_overflow" alert, 2078 without decrypting the message. 2080 7.4.1.4.3 Client Certificate URLs 2082 Ordinarily, when client authentication is performed, client 2083 certificates are sent by clients to servers during the TLS handshake. 2084 It may be desirable for constrained clients to send certificate URLs 2085 in place of certificates, so that they do not need to store their 2086 certificates and can therefore save memory. 2088 In order to negotiate to send certificate URLs to a server, clients 2089 MAY include an extension of type "client_certificate_url" in the 2090 (extended) client hello. The "extension_data" field of this 2091 extension SHALL be empty. 2093 (Note that it is necessary to negotiate use of client certificate 2094 URLs in order to avoid "breaking" existing TLS 1.0 servers.) 2096 Servers that receive an extended client hello containing a 2097 "client_certificate_url" extension, MAY indicate that they are 2098 willing to accept certificate URLs by including an extension of type 2099 "client_certificate_url" in the (extended) server hello. The 2100 "extension_data" field of this extension SHALL be empty. 2102 After negotiation of the use of client certificate URLs has been 2103 successfully completed (by exchanging hellos including 2104 "client_certificate_url" extensions), clients MAY send a 2105 "CertificateURL" message in place of a "Certificate" message. See 2106 Section XXX. 2108 7.4.1.4.4 Trusted CA Indication 2110 Constrained clients that, due to memory limitations, possess only a 2111 small number of CA root keys, may wish to indicate to servers which 2112 root keys they possess, in order to avoid repeated handshake 2113 failures. 2115 In order to indicate which CA root keys they possess, clients MAY 2116 include an extension of type "trusted_ca_keys" in the (extended) 2117 client hello. The "extension_data" field of this extension SHALL 2118 contain "TrustedAuthorities" where: 2120 struct { 2121 TrustedAuthority trusted_authorities_list<0..2^16-1>; 2122 } TrustedAuthorities; 2124 struct { 2125 IdentifierType identifier_type; 2126 select (identifier_type) { 2127 case pre_agreed: struct {}; 2128 case key_sha1_hash: SHA1Hash; 2129 case x509_name: DistinguishedName; 2130 case cert_sha1_hash: SHA1Hash; 2131 } identifier; 2132 } TrustedAuthority; 2134 enum { 2135 pre_agreed(0), key_sha1_hash(1), x509_name(2), 2136 cert_sha1_hash(3), (255) 2137 } IdentifierType; 2139 opaque DistinguishedName<1..2^16-1>; 2141 Here "TrustedAuthorities" provides a list of CA root key identifiers 2142 that the client possesses. Each CA root key is identified via 2143 either: 2145 - "pre_agreed" - no CA root key identity supplied. 2147 - "key_sha1_hash" - contains the SHA-1 hash of the CA root key. 2148 For 2149 DSA and ECDSA keys, this is the hash of the "subjectPublicKey" 2150 value. For RSA keys, the hash is of the big-endian byte string 2151 representation of the modulus without any initial 0-valued bytes. 2152 (This copies the key hash formats deployed in other 2153 environments.) 2155 - "x509_name" - contains the DER-encoded X.509 DistinguishedName 2156 of 2157 the CA. 2159 - "cert_sha1_hash" - contains the SHA-1 hash of a DER-encoded 2160 Certificate containing the CA root key. 2162 Note that clients may include none, some, or all of the CA root keys 2163 they possess in this extension. 2165 Note also that it is possible that a key hash or a Distinguished Name 2166 alone may not uniquely identify a certificate issuer - for example if 2167 a particular CA has multiple key pairs - however here we assume this 2168 is the case following the use of Distinguished Names to identify 2169 certificate issuers in TLS. 2171 The option to include no CA root keys is included to allow the client 2172 to indicate possession of some pre-defined set of CA root keys. 2174 Servers that receive a client hello containing the "trusted_ca_keys" 2175 extension, MAY use the information contained in the extension to 2176 guide their selection of an appropriate certificate chain to return 2177 to the client. In this event, the server SHALL include an extension 2178 of type "trusted_ca_keys" in the (extended) server hello. The 2179 "extension_data" field of this extension SHALL be empty. 2181 7.4.1.4.5 Truncated HMAC 2183 Currently defined TLS cipher suites use the MAC construction HMAC 2184 with either MD5 or SHA-1 [HMAC] to authenticate record layer 2185 communications. In TLS the entire output of the hash function is 2186 used as the MAC tag. However it may be desirable in constrained 2187 environments to save bandwidth by truncating the output of the hash 2188 function to 80 bits when forming MAC tags. 2190 In order to negotiate the use of 80-bit truncated HMAC, clients MAY 2191 include an extension of type "truncated_hmac" in the extended client 2192 hello. The "extension_data" field of this extension SHALL be empty. 2194 Servers that receive an extended hello containing a "truncated_hmac" 2195 extension, MAY agree to use a truncated HMAC by including an 2196 extension of type "truncated_hmac", with empty "extension_data", in 2197 the extended server hello. 2199 Note that if new cipher suites are added that do not use HMAC, and 2200 the session negotiates one of these cipher suites, this extension 2201 will have no effect. It is strongly recommended that any new cipher 2202 suites using other MACs consider the MAC size as an integral part of 2203 the cipher suite definition, taking into account both security and 2204 bandwidth considerations. 2206 If HMAC truncation has been successfully negotiated during a TLS 2207 handshake, and the negotiated cipher suite uses HMAC, both the client 2208 and the server pass this fact to the TLS record layer along with the 2209 other negotiated security parameters. Subsequently during the 2210 session, clients and servers MUST use truncated HMACs, calculated as 2211 specified in [HMAC]. That is, CipherSpec.hash_size is 10 bytes, and 2212 only the first 10 bytes of the HMAC output are transmitted and 2213 checked. Note that this extension does not affect the calculation of 2214 the PRF as part of handshaking or key derivation. 2216 The negotiated HMAC truncation size applies for the duration of the 2217 session including session resumptions. 2219 7.4.1.4.6 Certificate Status Request 2221 Constrained clients may wish to use a certificate-status protocol 2222 such as OCSP [OCSP] to check the validity of server certificates, in 2223 order to avoid transmission of CRLs and therefore save bandwidth on 2224 constrained networks. This extension allows for such information to 2225 be sent in the TLS handshake, saving roundtrips and resources. 2227 In order to indicate their desire to receive certificate status 2228 information, clients MAY include an extension of type 2229 "status_request" in the (extended) client hello. The 2230 "extension_data" field of this extension SHALL contain 2231 "CertificateStatusRequest" where: 2233 struct { 2234 CertificateStatusType status_type; 2235 select (status_type) { 2236 case ocsp: OCSPStatusRequest; 2237 } request; 2238 } CertificateStatusRequest; 2240 enum { ocsp(1), (255) } CertificateStatusType; 2242 struct { 2243 ResponderID responder_id_list<0..2^16-1>; 2244 Extensions request_extensions; 2245 } OCSPStatusRequest; 2247 opaque ResponderID<1..2^16-1>; 2249 In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP 2250 responders that the client trusts. A zero-length "responder_id_list" 2251 sequence has the special meaning that the responders are implicitly 2252 known to the server - e.g., by prior arrangement. "Extensions" is a 2253 DER encoding of OCSP request extensions. 2255 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as 2256 defined in [OCSP]. "Extensions" is imported from [PKIX]. A zero- 2257 length "request_extensions" value means that there are no extensions 2258 (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for 2259 the "Extensions" type). 2261 In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is 2262 unclear about its encoding; for clarification, the nonce MUST be a 2263 DER-encoded OCTET STRING, which is encapsulated as another OCTET 2264 STRING (note that implementations based on an existing OCSP client 2265 will need to be checked for conformance to this requirement). 2267 Servers that receive a client hello containing the "status_request" 2268 extension, MAY return a suitable certificate status response to the 2269 client along with their certificate. If OCSP is requested, they 2270 SHOULD use the information contained in the extension when selecting 2271 an OCSP responder, and SHOULD include request_extensions in the OCSP 2272 request. 2274 Servers return a certificate response along with their certificate by 2275 sending a "CertificateStatus" message immediately after the 2276 "Certificate" message (and before any "ServerKeyExchange" or 2277 "CertificateRequest" messages). Section XXX describes the 2278 CertificateStatus message. 2280 7.4.1.4.7 Cert Hash Types 2282 The client MAY use the "cert_hash_types" to indicate to the server 2283 which hash functions may be used in the signature on the server's 2284 certificate. The "extension_data" field of this extension contains: 2286 enum{ 2287 md5(0), sha1(1), sha256(2), sha512(3), (255) 2288 } HashType; 2290 struct { 2291 HashType<255> types; 2292 } CertHashTypes; 2294 These values indicate support for MD5 [MD5], SHA-1, SHA-256, and 2295 SHA-512 [SHA] respectively. The server MUST NOT send this extension. 2297 Clients SHOULD send this extension if they support any algorithm 2298 other than SHA-1. If this extension is not used, servers SHOULD 2299 assume that the client supports only SHA-1. Note: this is a change 2300 from TLS 1.1 where there are no explicit rules but as a practical 2301 matter one can assume that the peer supports MD5 and SHA-1. 2303 HashType values are divided into three groups: 2305 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are 2306 reserved for IETF Standards Track protocols. 2308 2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive 2309 are reserved for assignment for non-Standards Track methods. 2311 3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) 2312 inclusive are reserved for private use. 2314 Additional information describing the role of IANA in the 2315 allocation of HashType code points is described 2316 in Section 11. 2318 7.4.1.4.8 Procedure for Defining New Extensions 2320 The list of extension types, as defined in Section 2.3, is 2321 maintained by the Internet Assigned Numbers Authority (IANA). Thus 2322 an application needs to be made to the IANA in order to obtain a new 2323 extension type value. Since there are subtle (and not so subtle) 2324 interactions that may occur in this protocol between new features and 2325 existing features which may result in a significant reduction in 2326 overall security, new values SHALL be defined only through the IETF 2327 Consensus process specified in [IANA]. 2329 (This means that new assignments can be made only via RFCs approved 2330 by the IESG.) 2332 The following considerations should be taken into account when 2333 designing new extensions: 2335 - All of the extensions defined in this document follow the 2336 convention that for each extension that a client requests and that 2337 the server understands, the server replies with an extension of 2338 the same type. 2340 - Some cases where a server does not agree to an extension are error 2341 conditions, and some simply a refusal to support a particular 2342 feature. In general error alerts should be used for the former, 2343 and a field in the server extension response for the latter. 2345 - Extensions should as far as possible be designed to prevent any 2346 attack that forces use (or non-use) of a particular feature by 2347 manipulation of handshake messages. This principle should be 2348 followed regardless of whether the feature is believed to cause a 2349 security problem. 2351 Often the fact that the extension fields are included in the 2352 inputs to the Finished message hashes will be sufficient, but 2353 extreme care is needed when the extension changes the meaning of 2354 messages sent in the handshake phase. Designers and implementors 2355 should be aware of the fact that until the handshake has been 2356 authenticated, active attackers can modify messages and insert, 2357 remove, or replace extensions. 2359 - It would be technically possible to use extensions to change major 2360 aspects of the design of TLS; for example the design of cipher 2361 suite negotiation. This is not recommended; it would be more 2362 appropriate to define a new version of TLS - particularly since 2363 the TLS handshake algorithms have specific protection against 2364 version rollback attacks based on the version number, and the 2365 possibility of version rollback should be a significant 2366 consideration in any major design change. 2368 7.4.2. Server certificate 2370 When this message will be sent: 2371 The server MUST send a certificate whenever the agreed-upon key 2372 exchange method is not an anonymous one. This message will 2373 always immediately follow the server hello message. 2375 Meaning of this message: 2376 The certificate type MUST be appropriate for the selected cipher 2377 suite's key exchange algorithm, and is generally an X.509v3 2378 certificate. It MUST contain a key which matches the key 2379 exchange method, as follows. Unless otherwise specified, the 2380 signing 2381 algorithm for the certificate MUST be the same as the 2382 algorithm for the certificate key. Unless otherwise specified, 2383 the public key MAY be of any length. 2385 Key Exchange Algorithm Certificate Key Type 2387 RSA RSA public key; the certificate MUST 2388 allow the key to be used for encryption. 2390 DHE_DSS DSS public key. 2392 DHE_RSA RSA public key which can be used for 2393 signing. 2395 DH_DSS Diffie-Hellman key. The algorithm used 2396 to sign the certificate MUST be DSS. 2398 DH_RSA Diffie-Hellman key. The algorithm used 2399 to sign the certificate MUST be RSA. 2401 All certificate profiles, key and cryptographic formats are defined 2402 by the IETF PKIX working group [PKIX]. When a key usage extension is 2403 present, the digitalSignature bit MUST be set for the key to be 2404 eligible for signing, as described above, and the keyEncipherment bit 2405 MUST be present to allow encryption, as described above. The 2406 keyAgreement bit must be set on Diffie-Hellman certificates. 2408 As CipherSuites which specify new key exchange methods are specified 2409 for the TLS Protocol, they will imply certificate format and the 2410 required encoded keying information. 2412 Structure of this message: 2413 opaque ASN.1Cert<1..2^24-1>; 2415 struct { 2416 ASN.1Cert certificate_list<0..2^24-1>; 2417 } Certificate; 2419 certificate_list 2420 This is a sequence (chain) of X.509v3 certificates. The sender's 2421 certificate must come first in the list. Each following 2422 certificate must directly certify the one preceding it. Because 2423 certificate validation requires that root keys be distributed 2424 independently, the self-signed certificate which specifies the 2425 root certificate authority may optionally be omitted from the 2426 chain, under the assumption that the remote end must already 2427 possess it in order to validate it in any case. 2429 The same message type and structure will be used for the client's 2430 response to a certificate request message. Note that a client MAY 2431 send no certificates if it does not have an appropriate certificate 2432 to send in response to the server's authentication request. 2434 Note: PKCS #7 [PKCS7] is not used as the format for the certificate 2435 vector because PKCS #6 [PKCS6] extended certificates are not 2436 used. Also PKCS #7 defines a SET rather than a SEQUENCE, making 2437 the task of parsing the list more difficult. 2439 7.4.3. Server key exchange message 2441 When this message will be sent: 2442 This message will be sent immediately after the server 2443 certificate message (or the server hello message, if this is an 2444 anonymous negotiation). 2446 The server key exchange message is sent by the server only when 2447 the server certificate message (if sent) does not contain enough 2448 data to allow the client to exchange a premaster secret. This is 2449 true for the following key exchange methods: 2451 DHE_DSS 2452 DHE_RSA 2453 DH_anon 2455 It is not legal to send the server key exchange message for the 2456 following key exchange methods: 2458 RSA 2459 DH_DSS 2460 DH_RSA 2462 Meaning of this message: 2463 This message conveys cryptographic information to allow the 2464 client to communicate the premaster secret: either an RSA public 2465 key to encrypt the premaster secret with, or a Diffie-Hellman 2466 public key with which the client can complete a key exchange 2467 (with the result being the premaster secret.) 2469 As additional CipherSuites are defined for TLS which include new key 2470 exchange algorithms, the server key exchange message will be sent if 2471 and only if the certificate type associated with the key exchange 2472 algorithm does not provide enough information for the client to 2473 exchange a premaster secret. 2475 If the SignatureAlgorithm being used to sign the ServerKeyExchange 2476 message is DSA, the hash function used MUST be SHA-1. If the 2477 SignatureAlgorithm it must be the same hash function used in the 2478 signature of the server's certificate (found in the Certificate) 2479 message. This algorithm is denoted Hash below. Hash.length is the 2480 length of the output of that algorithm. 2482 Structure of this message: 2483 enum { rsa, diffie_hellman } KeyExchangeAlgorithm; 2485 struct { 2486 opaque rsa_modulus<1..2^16-1>; 2487 opaque rsa_exponent<1..2^16-1>; 2488 } ServerRSAParams; 2490 rsa_modulus 2491 The modulus of the server's temporary RSA key. 2493 rsa_exponent 2494 The public exponent of the server's temporary RSA key. 2496 struct { 2497 opaque dh_p<1..2^16-1>; 2498 opaque dh_g<1..2^16-1>; 2499 opaque dh_Ys<1..2^16-1>; 2500 } ServerDHParams; /* Ephemeral DH parameters */ 2502 dh_p 2503 The prime modulus used for the Diffie-Hellman operation. 2505 dh_g 2506 The generator used for the Diffie-Hellman operation. 2508 dh_Ys 2509 The server's Diffie-Hellman public value (g^X mod p). 2511 struct { 2512 select (KeyExchangeAlgorithm) { 2513 case diffie_hellman: 2514 ServerDHParams params; 2515 Signature signed_params; 2516 case rsa: 2517 ServerRSAParams params; 2518 Signature signed_params; 2519 }; 2520 } ServerKeyExchange; 2522 struct { 2523 select (KeyExchangeAlgorithm) { 2524 case diffie_hellman: 2525 ServerDHParams params; 2526 case rsa: 2527 ServerRSAParams params; 2528 }; 2529 } ServerParams; 2531 params 2532 The server's key exchange parameters. 2534 signed_params 2535 For non-anonymous key exchanges, a hash of the corresponding 2536 params value, with the signature appropriate to that hash 2537 applied. 2539 hash 2540 Hash(ClientHello.random + ServerHello.random + ServerParams) 2542 sha_hash 2543 SHA1(ClientHello.random + ServerHello.random + ServerParams) 2545 enum { anonymous, rsa, dsa } SignatureAlgorithm; 2547 struct { 2548 select (SignatureAlgorithm) { 2549 case anonymous: struct { }; 2550 case rsa: 2551 digitally-signed struct { 2552 opaque hash[Hash.length]; 2553 }; 2554 case dsa: 2555 digitally-signed struct { 2556 opaque sha_hash[20]; 2557 }; 2558 }; 2559 }; 2560 } Signature; 2562 7.4.4. CertificateStatus 2564 If a server returns a 2565 "CertificateStatus" message, then the server MUST have included an 2566 extension of type "status_request" with empty "extension_data" in the 2567 extended server hello. 2569 struct { 2570 CertificateStatusType status_type; 2571 select (status_type) { 2572 case ocsp: OCSPResponse; 2573 } response; 2574 } CertificateStatus; 2576 opaque OCSPResponse<1..2^24-1>; 2578 An "ocsp_response" contains a complete, DER-encoded OCSP response 2579 (using the ASN.1 type OCSPResponse defined in [OCSP]). Note that 2580 only one OCSP response may be sent. 2582 The "CertificateStatus" message is conveyed using the handshake 2583 message type "certificate_status". 2585 Note that a server MAY also choose not to send a "CertificateStatus" 2586 message, even if it receives a "status_request" extension in the 2587 client hello message. 2589 Note in addition that servers MUST NOT send the "CertificateStatus" 2590 message unless it received a "status_request" extension in the client 2591 hello message. 2593 Clients requesting an OCSP response, and receiving an OCSP response 2594 in a "CertificateStatus" message MUST check the OCSP response and 2595 abort the handshake if the response is not satisfactory. 2597 7.4.5. Certificate request 2599 When this message will be sent: 2601 A non-anonymous server can optionally request a certificate from 2602 the client, if appropriate for the selected cipher suite. This 2603 message, if sent, will immediately follow the Server Key Exchange 2604 message (if it is sent; otherwise, the Server Certificate 2605 message). 2607 Structure of this message: 2608 enum { 2609 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), 2610 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), 2611 fortezza_dms_RESERVED(20), 2612 (255) 2613 } ClientCertificateType; 2615 opaque DistinguishedName<1..2^16-1>; 2617 struct { 2618 ClientCertificateType certificate_types<1..2^8-1>; 2619 HashType certificate_hash<1..2^8-1>; 2620 DistinguishedName certificate_authorities<0..2^16-1>; 2621 } CertificateRequest; 2623 certificate_types 2624 This field is a list of the types of certificates requested, 2625 sorted in order of the server's preference. 2627 certificate_types 2628 A list of the types of certificate types which the client may 2629 offer. 2630 rsa_sign a certificate containing an RSA key 2631 dss_sign a certificate containing a DSS key 2632 rsa_fixed_dh a certificate signed with RSA and containing 2633 a static DH key. 2634 dss_fixed_dh a certificate signed with DSS and containing 2635 a static DH key 2637 Certificate types rsa_sign and dss_sign SHOULD contain 2638 certificates signed with the same algorithm. However, this is 2639 not required. This is a holdover from TLS 1.0 and 1.1. 2641 certificate_hash 2642 A list of acceptable hash algorithms to be used in 2643 certificate signatures. 2645 certificate_authorities 2646 A list of the distinguished names of acceptable certificate 2647 authorities. These distinguished names may specify a desired 2648 distinguished name for a root CA or for a subordinate CA; 2649 thus, this message can be used both to describe known roots 2650 and a desired authorization space. If the 2651 certificate_authorities list is empty then the client MAY 2652 send any certificate of the appropriate 2653 ClientCertificateType, unless there is some external 2654 arrangement to the contrary. 2656 ClientCertificateType values are divided into three groups: 2658 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are 2659 reserved for IETF Standards Track protocols. 2661 2. Values from 64 decimal (0x40) through 223 decimal (0xDF) 2662 inclusive are reserved for assignment for non-Standards 2663 Track methods. 2665 3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) 2666 inclusive are reserved for private use. 2668 Additional information describing the role of IANA in the 2669 allocation of ClientCertificateType code points is described 2670 in Section 11. 2672 Note: Values listed as RESERVED may not be used. They were used in 2673 SSLv3. 2675 Note: DistinguishedName is derived from [X501]. DistinguishedNames are 2676 represented in DER-encoded format. 2678 Note: It is a fatal handshake_failure alert for an anonymous server to 2679 request client authentication. 2681 7.4.6. Server hello done 2683 When this message will be sent: 2684 The server hello done message is sent by the server to indicate 2685 the end of the server hello and associated messages. After 2686 sending this message the server will wait for a client response. 2688 Meaning of this message: 2689 This message means that the server is done sending messages to 2690 support the key exchange, and the client can proceed with its 2691 phase of the key exchange. 2693 Upon receipt of the server hello done message the client SHOULD 2694 verify that the server provided a valid certificate if required 2695 and check that the server hello parameters are acceptable. 2697 Structure of this message: 2698 struct { } ServerHelloDone; 2700 7.4.7. Client certificate 2702 When this message will be sent: 2703 This is the first message the client can send after receiving a 2704 server hello done message. This message is only sent if the 2705 server requests a certificate. If no suitable certificate is 2706 available, the client SHOULD send a certificate message 2707 containing no certificates. That is, the certificate_list 2708 structure has a length of zero. If client authentication is 2709 required by the server for the handshake to continue, it may 2710 respond with a fatal handshake failure alert. Client certificates 2711 are sent using the Certificate structure defined in Section 2712 7.4.2. 2714 Note: When using a static Diffie-Hellman based key exchange method 2715 (DH_DSS or DH_RSA), if client authentication is requested, the 2716 Diffie-Hellman group and generator encoded in the client's 2717 certificate MUST match the server specified Diffie-Hellman 2718 parameters if the client's parameters are to be used for the key 2719 exchange. 2721 7.4.8. Client Certificate URLs 2723 After negotiation of the use of client certificate URLs has been 2724 successfully completed (by exchanging hellos including 2725 "client_certificate_url" extensions), clients MAY send a 2726 "CertificateURL" message in place of a "Certificate" message. 2728 enum { 2729 individual_certs(0), pkipath(1), (255) 2730 } CertChainType; 2732 enum { 2733 false(0), true(1) 2734 } Boolean; 2736 struct { 2737 CertChainType type; 2738 URLAndOptionalHash url_and_hash_list<1..2^16-1>; 2739 } CertificateURL; 2740 struct { 2741 opaque url<1..2^16-1>; 2742 Boolean hash_present; 2743 select (hash_present) { 2744 case false: struct {}; 2745 case true: SHA1Hash; 2746 } hash; 2747 } URLAndOptionalHash; 2749 opaque SHA1Hash[20]; 2751 Here "url_and_hash_list" contains a sequence of URLs and optional 2752 hashes. 2754 When X.509 certificates are used, there are two possibilities: 2756 - if CertificateURL.type is "individual_certs", each URL refers to 2757 a single DER-encoded X.509v3 certificate, with the URL for the 2758 client's certificate first, or 2760 - if CertificateURL.type is "pkipath", the list contains a single 2761 URL referring to a DER-encoded certificate chain, using the type 2762 PkiPath described in Section 8. 2764 When any other certificate format is used, the specification that 2765 describes use of that format in TLS should define the encoding format 2766 of certificates or certificate chains, and any constraint on their 2767 ordering. 2769 The hash corresponding to each URL at the client's discretion is 2770 either not present or is the SHA-1 hash of the certificate or 2771 certificate chain (in the case of X.509 certificates, the DER-encoded 2772 certificate or the DER-encoded PkiPath). 2774 Note that when a list of URLs for X.509 certificates is used, the 2775 ordering of URLs is the same as that used in the TLS Certificate 2776 message (see [TLS] Section 7.4.2), but opposite to the order in which 2777 certificates are encoded in PkiPath. In either case, the self-signed 2778 root certificate MAY be omitted from the chain, under the assumption 2779 that the server must already possess it in order to validate it. 2781 Servers receiving "CertificateURL" SHALL attempt to retrieve the 2782 client's certificate chain from the URLs, and then process the 2783 certificate chain as usual. A cached copy of the content of any URL 2784 in the chain MAY be used, provided that a SHA-1 hash is present for 2785 that URL and it matches the hash of the cached copy. 2787 Servers that support this extension MUST support the http: URL scheme 2788 for certificate URLs, and MAY support other schemes. Use of other 2789 schemes than "http", "https", or "ftp" may create unexpected 2790 problems. 2792 If the protocol used is HTTP, then the HTTP server can be configured 2793 to use the Cache-Control and Expires directives described in [HTTP] 2794 to specify whether and for how long certificates or certificate 2795 chains should be cached. 2797 The TLS server is not required to follow HTTP redirects when 2798 retrieving the certificates or certificate chain. The URLs used in 2799 this extension SHOULD therefore be chosen not to depend on such 2800 redirects. 2802 If the protocol used to retrieve certificates or certificate chains 2803 returns a MIME formatted response (as HTTP does), then the following 2804 MIME Content-Types SHALL be used: when a single X.509v3 certificate 2805 is returned, the Content-Type is "application/pkix-cert" [PKIOP], and 2806 when a chain of X.509v3 certificates is returned, the Content-Type is 2807 "application/pkix-pkipath" (see Section XXX). 2809 If a SHA-1 hash is present for an URL, then the server MUST check 2810 that the SHA-1 hash of the contents of the object retrieved from that 2811 URL (after decoding any MIME Content-Transfer-Encoding) matches the 2812 given hash. If any retrieved object does not have the correct SHA-1 2813 hash, the server MUST abort the handshake with a 2814 "bad_certificate_hash_value" alert. 2816 Note that clients may choose to send either "Certificate" or 2817 "CertificateURL" after successfully negotiating the option to send 2818 certificate URLs. The option to send a certificate is included to 2819 provide flexibility to clients possessing multiple certificates. 2821 If a server encounters an unreasonable delay in obtaining 2822 certificates in a given CertificateURL, it SHOULD time out and signal 2823 a "certificate_unobtainable" error alert. 2825 7.4.9. Client key exchange message 2827 When this message will be sent: 2828 This message is always sent by the client. It MUST immediately follow 2829 the client certificate message, if it is sent. Otherwise it MUST be 2830 the first message sent by the client after it receives the server 2831 hello done message. 2833 Meaning of this message: 2834 With this message, the premaster secret is set, either though direct 2835 transmission of the RSA-encrypted secret, or by the transmission of 2836 Diffie-Hellman parameters which will allow each side to agree upon 2837 the same premaster secret. When the key exchange method is DH_RSA or 2838 DH_DSS, client certification has been requested, and the client was 2839 able to respond with a certificate which contained a Diffie-Hellman 2840 public key whose parameters (group and generator) matched those 2841 specified by the server in its certificate, this message MUST not 2842 contain any data. 2844 Structure of this message: 2845 The choice of messages depends on which key exchange method has been 2846 selected. See Section 7.4.3 for the KeyExchangeAlgorithm definition. 2848 struct { 2849 select (KeyExchangeAlgorithm) { 2850 case rsa: EncryptedPreMasterSecret; 2851 case diffie_hellman: ClientDiffieHellmanPublic; 2852 } exchange_keys; 2853 } ClientKeyExchange; 2855 7.4.9.1. RSA encrypted premaster secret message 2857 Meaning of this message: 2858 If RSA is being used for key agreement and authentication, the client 2859 generates a 48-byte premaster secret, encrypts it using the public 2860 key from the server's certificate or the temporary RSA key provided 2861 in a server key exchange message, and sends the result in an 2862 encrypted premaster secret message. This structure is a variant of 2863 the client key exchange message, not a message in itself. 2865 Structure of this message: 2866 struct { 2867 ProtocolVersion client_version; 2868 opaque random[46]; 2869 } PreMasterSecret; 2871 client_version 2872 The latest (newest) version supported by the client. This is 2873 used to detect version roll-back attacks. Upon receiving the 2874 premaster secret, the server SHOULD check that this value 2875 matches the value transmitted by the client in the client 2876 hello message. 2878 random 2879 46 securely-generated random bytes. 2881 struct { 2882 public-key-encrypted PreMasterSecret pre_master_secret; 2883 } EncryptedPreMasterSecret; 2884 pre_master_secret 2885 This random value is generated by the client and is used to 2886 generate the master secret, as specified in Section 8.1. 2888 Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used 2889 to attack a TLS server which is using PKCS#1 v 1.5 encoded RSA. 2890 The attack takes advantage of the fact that by failing in 2891 different ways, a TLS server can be coerced into revealing 2892 whether a particular message, when decrypted, is properly PKCS#1 2893 v1.5 formatted or not. 2895 The best way to avoid vulnerability to this attack is to treat 2896 incorrectly formatted messages in a manner indistinguishable from 2897 correctly formatted RSA blocks. Thus, when it receives an 2898 incorrectly formatted RSA block, a server should generate a 2899 random 48-byte value and proceed using it as the premaster 2900 secret. Thus, the server will act identically whether the 2901 received RSA block is correctly encoded or not. 2903 [PKCS1B] defines a newer version of PKCS#1 encoding that is more 2904 secure against the Bleichenbacher attack. However, for maximal 2905 compatibility with TLS 1.0, TLS 1.1 retains the original 2906 encoding. No variants of the Bleichenbacher attack are known to 2907 exist provided that the above recommendations are followed. 2909 Implementation Note: public-key-encrypted data is represented as an 2910 opaque vector <0..2^16-1> (see section 4.7). Thus the RSA- 2911 encrypted PreMasterSecret in a ClientKeyExchange is preceded by 2912 two length bytes. These bytes are redundant in the case of RSA 2913 because the EncryptedPreMasterSecret is the only data in the 2914 ClientKeyExchange and its length can therefore be unambiguously 2915 determined. The SSLv3 specification was not clear about the 2916 encoding of public-key-encrypted data and therefore many SSLv3 2917 implementations do not include the the length bytes, encoding the 2918 RSA encrypted data directly in the ClientKeyExchange message. 2920 This specification requires correct encoding of the 2921 EncryptedPreMasterSecret complete with length bytes. The 2922 resulting PDU is incompatible with many SSLv3 implementations. 2923 Implementors upgrading from SSLv3 must modify their 2924 implementations to generate and accept the correct encoding. 2925 Implementors who wish to be compatible with both SSLv3 and TLS 2926 should make their implementation's behavior dependent on the 2927 protocol version. 2929 Implementation Note: It is now known that remote timing-based attacks 2930 on SSL are possible, at least when the client and server are on 2931 the same LAN. Accordingly, implementations which use static RSA 2932 keys SHOULD use RSA blinding or some other anti-timing technique, 2933 as described in [TIMING]. 2935 Note: The version number in the PreMasterSecret MUST be the version 2936 offered by the client in the ClientHello, not the version 2937 negotiated for the connection. This feature is designed to 2938 prevent rollback attacks. Unfortunately, many implementations use 2939 the negotiated version instead and therefore checking the version 2940 number may lead to failure to interoperate with such incorrect 2941 client implementations. Client implementations MUST and Server 2942 implementations MAY check the version number. In practice, since 2943 the TLS handshake MACs prevent downgrade and no good attacks are 2944 known on those MACs, ambiguity is not considered a serious 2945 security risk. Note that if servers choose to to check the 2946 version number, they should randomize the PreMasterSecret in case 2947 of error, rather than generate an alert, in order to avoid 2948 variants on the Bleichenbacher attack. [KPR03] 2950 7.4.9.2. Client Diffie-Hellman public value 2952 Meaning of this message: 2953 This structure conveys the client's Diffie-Hellman public value 2954 (Yc) if it was not already included in the client's certificate. 2955 The encoding used for Yc is determined by the enumerated 2956 PublicValueEncoding. This structure is a variant of the client 2957 key exchange message, not a message in itself. 2959 Structure of this message: 2960 enum { implicit, explicit } PublicValueEncoding; 2962 implicit 2963 If the client certificate already contains a suitable Diffie- 2964 Hellman key, then Yc is implicit and does not need to be sent 2965 again. In this case, the client key exchange message will be 2966 sent, but MUST be empty. 2968 explicit 2969 Yc needs to be sent. 2971 struct { 2972 select (PublicValueEncoding) { 2973 case implicit: struct { }; 2974 case explicit: opaque dh_Yc<1..2^16-1>; 2975 } dh_public; 2976 } ClientDiffieHellmanPublic; 2978 dh_Yc 2979 The client's Diffie-Hellman public value (Yc). 2981 7.4.10. Certificate verify 2983 When this message will be sent: 2984 This message is used to provide explicit verification of a client 2985 certificate. This message is only sent following a client 2986 certificate that has signing capability (i.e. all certificates 2987 except those containing fixed Diffie-Hellman parameters). When 2988 sent, it MUST immediately follow the client key exchange message. 2990 Structure of this message: 2991 struct { 2992 Signature signature; 2993 } CertificateVerify; 2995 The Signature type is defined in 7.4.3. If the SignatureAlgorithm 2996 is DSA, then the sha_hash value must be used. If it is RSA, 2997 the same function (denoted Hash) must be used as was used to 2998 create the signature for the client's certificate. 3000 CertificateVerify.signature.hash 3001 Hash(handshake_messages); 3003 CertificateVerify.signature.sha_hash 3004 SHA(handshake_messages); 3006 Here handshake_messages refers to all handshake messages sent or 3007 received starting at client hello up to but not including this 3008 message, including the type and length fields of the handshake 3009 messages. This is the concatenation of all the Handshake structures 3010 as defined in 7.4 exchanged thus far. 3012 7.4.10. Finished 3014 When this message will be sent: 3015 A finished message is always sent immediately after a change 3016 cipher spec message to verify that the key exchange and 3017 authentication processes were successful. It is essential that a 3018 change cipher spec message be received between the other 3019 handshake messages and the Finished message. 3021 Meaning of this message: 3022 The finished message is the first protected with the just- 3023 negotiated algorithms, keys, and secrets. Recipients of finished 3024 messages MUST verify that the contents are correct. Once a side 3025 has sent its Finished message and received and validated the 3026 Finished message from its peer, it may begin to send and receive 3027 application data over the connection. 3029 struct { 3030 opaque verify_data[12]; 3031 } Finished; 3033 verify_data 3034 PRF(master_secret, finished_label, MD5(handshake_messages) + 3035 SHA-1(handshake_messages)) [0..11]; 3037 finished_label 3038 For Finished messages sent by the client, the string "client 3039 finished". For Finished messages sent by the server, the 3040 string "server finished". 3042 handshake_messages 3043 All of the data from all messages in this handshake (not 3044 including any HelloRequest messages) up to but not including 3045 this message. This is only data visible at the handshake 3046 layer and does not include record layer headers. This is the 3047 concatenation of all the Handshake structures as defined in 3048 7.4 exchanged thus far. 3050 It is a fatal error if a finished message is not preceded by a change 3051 cipher spec message at the appropriate point in the handshake. 3053 The value handshake_messages includes all handshake messages starting 3054 at client hello up to, but not including, this finished message. This 3055 may be different from handshake_messages in Section 7.4.10 because it 3056 would include the certificate verify message (if sent). Also, the 3057 handshake_messages for the finished message sent by the client will 3058 be different from that for the finished message sent by the server, 3059 because the one which is sent second will include the prior one. 3061 Note: Change cipher spec messages, alerts and any other record types 3062 are not handshake messages and are not included in the hash 3063 computations. Also, Hello Request messages are omitted from 3064 handshake hashes. 3066 8. Cryptographic computations 3068 In order to begin connection protection, the TLS Record Protocol 3069 requires specification of a suite of algorithms, a master secret, and 3070 the client and server random values. The authentication, encryption, 3071 and MAC algorithms are determined by the cipher_suite selected by the 3072 server and revealed in the server hello message. The compression 3073 algorithm is negotiated in the hello messages, and the random values 3074 are exchanged in the hello messages. All that remains is to calculate 3075 the master secret. 3077 8.1. Computing the master secret 3079 For all key exchange methods, the same algorithm is used to convert 3080 the pre_master_secret into the master_secret. The pre_master_secret 3081 should be deleted from memory once the master_secret has been 3082 computed. 3084 master_secret = PRF(pre_master_secret, "master secret", 3085 ClientHello.random + ServerHello.random) 3086 [0..47]; 3088 The master secret is always exactly 48 bytes in length. The length of 3089 the premaster secret will vary depending on key exchange method. 3091 8.1.1. RSA 3093 When RSA is used for server authentication and key exchange, a 3094 48-byte pre_master_secret is generated by the client, encrypted under 3095 the server's public key, and sent to the server. The server uses its 3096 private key to decrypt the pre_master_secret. Both parties then 3097 convert the pre_master_secret into the master_secret, as specified 3098 above. 3100 RSA digital signatures are performed using PKCS #1 [PKCS1] block type 3101 1. RSA public key encryption is performed using PKCS #1 block type 2. 3103 8.1.2. Diffie-Hellman 3105 A conventional Diffie-Hellman computation is performed. The 3106 negotiated key (Z) is used as the pre_master_secret, and is converted 3107 into the master_secret, as specified above. Leading bytes of Z that 3108 contain all zero bits are stripped before it is used as the 3109 pre_master_secret. 3111 Note: Diffie-Hellman parameters are specified by the server, and may 3112 be either ephemeral or contained within the server's certificate. 3114 9. Mandatory Cipher Suites 3116 In the absence of an application profile standard specifying 3117 otherwise, a TLS compliant application MUST implement the cipher 3118 suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. 3120 10. Application data protocol 3122 Application data messages are carried by the Record Layer and are 3123 fragmented, compressed and encrypted based on the current connection 3124 state. The messages are treated as transparent data to the record 3125 layer. 3127 11. IANA Considerations 3129 This document describes a number of new registries to be created by 3130 IANA. We recommend that they be placed as individual registries items 3131 under a common TLS category. 3133 Section 7.4.5 describes a TLS HashType Registry to be maintained by 3134 the IANA, as defining a number of such code point identifiers. 3135 HashType identifiers with values in the range 0-63 (decimal) 3136 inclusive are assigned via RFC 2434 Standards Action. Values from the 3137 range 64-223 (decimal) inclusive are assigned via [RFC 2434] 3138 Specification Required. Identifier values from 224-255 (decimal) 3139 inclusive are reserved for RFC 2434 Private Use. The registry will be 3140 initially populated with the values in this document, Section 7.4.5. 3142 Section 7.4.5 describes a TLS ClientCertificateType Registry to be 3143 maintained by the IANA, as defining a number of such code point 3144 identifiers. ClientCertificateType identifiers with values in the 3145 range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards 3146 Action. Values from the range 64-223 (decimal) inclusive are assigned 3147 via [RFC 2434] Specification Required. Identifier values from 3148 224-255 (decimal) inclusive are reserved for RFC 2434 Private Use. 3149 The registry will be initially populated with the values in this 3150 document, Section 7.4.5. 3152 Section A.5 describes a TLS Cipher Suite Registry to be maintained by 3153 the IANA, as well as defining a number of such cipher suite 3154 identifiers. Cipher suite values with the first byte in the range 3155 0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action. 3156 Values with the first byte in the range 192-254 (decimal) are 3157 assigned via RFC 2434 Specification Required. Values with the first 3158 byte 255 (decimal) are reserved for RFC 2434 Private Use. The 3159 registry will be initially populated with the values from Section A.5 3160 of this document, [TLSAES], and Section 3 of [TLSKRB]. 3162 Section 6 requires that all ContentType values be defined by RFC 2434 3163 Standards Action. IANA SHOULD create a TLS ContentType registry, 3164 initially populated with values from Section 6.2.1 of this document. 3165 Future values MUST be allocated via Standards Action as described in 3166 [RFC 2434]. 3168 Section 7.2.2 requires that all Alert values be defined by RFC 2434 3169 Standards Action. IANA SHOULD create a TLS Alert registry, initially 3170 populated with values from Section 7.2 of this document and Section 4 3171 of [TLSEXT]. Future values MUST be allocated via Standards Action as 3172 described in [RFC 2434]. 3174 Section 7.4 requires that all HandshakeType values be defined by RFC 3175 2434 Standards Action. IANA SHOULD create a TLS HandshakeType 3176 registry, initially populated with values from Section 7.4 of this 3177 document and Section 2.4 of [TLSEXT]. Future values MUST be 3178 allocated via Standards Action as described in [RFC2434]. 3180 11.1 Extensions 3182 Sections XXX and XXX describes a registry of ExtensionType values to 3183 be maintained by the IANA. ExtensionType values are to be assigned 3184 via IETF Consensus as defined in RFC 2434 [IANA]. The initial 3185 registry corresponds to the definition of "ExtensionType" in Section 3186 2.3. 3188 The MIME type "application/pkix-pkipath" has been registered by the 3189 IANA with the following template: 3191 To: ietf-types@iana.org Subject: Registration of MIME media type 3192 application/pkix-pkipath 3194 MIME media type name: application 3195 MIME subtype name: pkix-pkipath 3197 Optional parameters: version (default value is "1") 3199 Encoding considerations: 3200 This MIME type is a DER encoding of the ASN.1 type PkiPath, 3201 defined as follows: 3202 PkiPath ::= SEQUENCE OF Certificate 3203 PkiPath is used to represent a certification path. Within the 3204 sequence, the order of certificates is such that the subject of 3205 the first certificate is the issuer of the second certificate, 3206 etc. 3208 This is identical to the definition published in [X509-4th-TC1]; 3209 note that it is different from that in [X509-4th]. 3211 All Certificates MUST conform to [PKIX]. (This should be 3212 interpreted as a requirement to encode only PKIX-conformant 3213 certificates using this type. It does not necessarily require 3214 that all certificates that are not strictly PKIX-conformant must 3215 be rejected by relying parties, although the security consequences 3216 of accepting any such certificates should be considered 3217 carefully.) 3219 DER (as opposed to BER) encoding MUST be used. If this type is 3220 sent over a 7-bit transport, base64 encoding SHOULD be used. 3222 Security considerations: 3223 The security considerations of [X509-4th] and [PKIX] (or any 3224 updates to them) apply, as well as those of any protocol that uses 3225 this type (e.g., TLS). 3227 Note that this type only specifies a certificate chain that can be 3228 assessed for validity according to the relying party's existing 3229 configuration of trusted CAs; it is not intended to be used to 3230 specify any change to that configuration. 3232 Interoperability considerations: 3233 No specific interoperability problems are known with this type, 3234 but for recommendations relating to X.509 certificates in general, 3235 see [PKIX]. 3237 Published specification: this memo, and [PKIX]. 3239 Applications which use this media type: TLS. It may also be used by 3240 other protocols, or for general interchange of PKIX certificate 3242 Additional information: 3243 Magic number(s): DER-encoded ASN.1 can be easily recognized. 3244 Further parsing is required to distinguish from other ASN.1 3245 types. 3246 File extension(s): .pkipath 3247 Macintosh File Type Code(s): not specified 3249 Person & email address to contact for further information: 3250 Magnus Nystrom 3252 Intended usage: COMMON 3254 Change controller: 3255 IESG 3256 A. Protocol constant values 3258 This section describes protocol types and constants. 3260 A.1. Record layer 3262 struct { 3263 uint8 major, minor; 3264 } ProtocolVersion; 3266 ProtocolVersion version = { 3, 2 }; /* TLS v1.1 */ 3268 enum { 3269 change_cipher_spec(20), alert(21), handshake(22), 3270 application_data(23), (255) 3271 } ContentType; 3273 struct { 3274 ContentType type; 3275 ProtocolVersion version; 3276 uint16 length; 3277 opaque fragment[TLSPlaintext.length]; 3278 } TLSPlaintext; 3280 struct { 3281 ContentType type; 3282 ProtocolVersion version; 3283 uint16 length; 3284 opaque fragment[TLSCompressed.length]; 3285 } TLSCompressed; 3287 struct { 3288 ContentType type; 3289 ProtocolVersion version; 3290 uint16 length; 3291 select (CipherSpec.cipher_type) { 3292 case stream: GenericStreamCipher; 3293 case block: GenericBlockCipher; 3294 } fragment; 3295 } TLSCiphertext; 3297 stream-ciphered struct { 3298 opaque content[TLSCompressed.length]; 3299 opaque MAC[CipherSpec.hash_size]; 3300 } GenericStreamCipher; 3302 block-ciphered struct { 3303 opaque IV[CipherSpec.block_length]; 3304 opaque content[TLSCompressed.length]; 3305 opaque MAC[CipherSpec.hash_size]; 3306 uint8 padding[GenericBlockCipher.padding_length]; 3307 uint8 padding_length; 3308 } GenericBlockCipher; 3310 A.2. Change cipher specs message 3312 struct { 3313 enum { change_cipher_spec(1), (255) } type; 3314 } ChangeCipherSpec; 3316 A.3. Alert messages 3318 enum { warning(1), fatal(2), (255) } AlertLevel; 3320 enum { 3321 close_notify(0), 3322 unexpected_message(10), 3323 bad_record_mac(20), 3324 decryption_failed(21), 3325 record_overflow(22), 3326 decompression_failure(30), 3327 handshake_failure(40), 3328 no_certificate_RESERVED (41), 3329 bad_certificate(42), 3330 unsupported_certificate(43), 3331 certificate_revoked(44), 3332 certificate_expired(45), 3333 certificate_unknown(46), 3334 illegal_parameter(47), 3335 unknown_ca(48), 3336 access_denied(49), 3337 decode_error(50), 3338 decrypt_error(51), 3339 export_restriction_RESERVED(60), 3340 protocol_version(70), 3341 insufficient_security(71), 3342 internal_error(80), 3343 user_canceled(90), 3344 no_renegotiation(100), 3345 unsupported_extension(110), /* new */ 3346 certificate_unobtainable(111), /* new */ 3347 unrecognized_name(112), /* new */ 3348 bad_certificate_status_response(113), /* new */ 3349 bad_certificate_hash_value(114), /* new */ 3350 (255) 3351 } AlertDescription; 3352 struct { 3353 AlertLevel level; 3354 AlertDescription description; 3355 } Alert; 3356 A.4. Handshake protocol 3358 enum { 3359 hello_request(0), client_hello(1), server_hello(2), 3360 certificate(11), server_key_exchange (12), 3361 certificate_request(13), server_hello_done(14), 3362 certificate_verify(15), client_key_exchange(16), 3363 finished(20), certificate_url(21), certificate_status(22), 3364 (255) 3365 } HandshakeType; 3367 struct { 3368 HandshakeType msg_type; 3369 uint24 length; 3370 select (HandshakeType) { 3371 case hello_request: HelloRequest; 3372 case client_hello: ClientHello; 3373 case server_hello: ServerHello; 3374 case certificate: Certificate; 3375 case server_key_exchange: ServerKeyExchange; 3376 case certificate_request: CertificateRequest; 3377 case server_hello_done: ServerHelloDone; 3378 case certificate_verify: CertificateVerify; 3379 case client_key_exchange: ClientKeyExchange; 3380 case finished: Finished; 3381 case certificate_url: CertificateURL; 3382 case certificate_status: CertificateStatus; 3383 } body; 3384 } Handshake; 3386 A.4.1. Hello messages 3388 struct { } HelloRequest; 3390 struct { 3391 uint32 gmt_unix_time; 3392 opaque random_bytes[28]; 3393 } Random; 3395 opaque SessionID<0..32>; 3397 uint8 CipherSuite[2]; 3399 enum { null(0), (255) } CompressionMethod; 3401 struct { 3402 ProtocolVersion client_version; 3403 Random random; 3404 SessionID session_id; 3405 CipherSuite cipher_suites<2..2^16-1>; 3406 CompressionMethod compression_methods<1..2^8-1>; 3407 Extension client_hello_extension_list<0..2^16-1>; 3408 } ClientHello; 3410 struct { 3411 ProtocolVersion client_version; 3412 Random random; 3413 SessionID session_id; 3414 CipherSuite cipher_suites<2..2^16-1>; 3415 CompressionMethod compression_methods<1..2^8-1>; 3416 Extension client_hello_extension_list<0..2^16-1>; 3417 } ExtendedClientHello; 3419 struct { 3420 ProtocolVersion server_version; 3421 Random random; 3422 SessionID session_id; 3423 CipherSuite cipher_suite; 3424 CompressionMethod compression_method; 3425 } ServerHello; 3427 struct { 3428 ProtocolVersion server_version; 3429 Random random; 3430 SessionID session_id; 3431 CipherSuite cipher_suite; 3432 CompressionMethod compression_method; 3433 Extension server_hello_extension_list<0..2^16-1>; 3434 } ExtendedServerHello; 3436 struct { 3437 ExtensionType extension_type; 3438 opaque extension_data<0..2^16-1>; 3439 } Extension; 3441 enum { 3442 server_name(0), max_fragment_length(1), 3443 client_certificate_url(2), trusted_ca_keys(3), 3444 truncated_hmac(4), status_request(5), 3445 cert_hash_types(6), (65535) 3446 } ExtensionType; 3448 struct { 3449 NameType name_type; 3450 select (name_type) { 3451 case host_name: HostName; 3452 } name; 3453 } ServerName; 3455 enum { 3456 host_name(0), (255) 3457 } NameType; 3459 opaque HostName<1..2^16-1>; 3461 struct { 3462 ServerName server_name_list<1..2^16-1> 3463 } ServerNameList; 3465 enum{ 3466 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) 3467 } MaxFragmentLength; 3469 struct { 3470 TrustedAuthority trusted_authorities_list<0..2^16-1>; 3471 } TrustedAuthorities; 3473 struct { 3474 IdentifierType identifier_type; 3475 select (identifier_type) { 3476 case pre_agreed: struct {}; 3477 case key_sha1_hash: SHA1Hash; 3478 case x509_name: DistinguishedName; 3479 case cert_sha1_hash: SHA1Hash; 3480 } identifier; 3481 } TrustedAuthority; 3483 enum { 3484 pre_agreed(0), key_sha1_hash(1), x509_name(2), 3485 cert_sha1_hash(3), (255) 3486 } IdentifierType; 3488 struct { 3489 CertificateStatusType status_type; 3490 select (status_type) { 3491 case ocsp: OCSPStatusRequest; 3492 } request; 3493 } CertificateStatusRequest; 3495 enum { ocsp(1), (255) } CertificateStatusType; 3497 struct { 3498 ResponderID responder_id_list<0..2^16-1>; 3499 Extensions request_extensions; 3500 } OCSPStatusRequest; 3502 opaque ResponderID<1..2^16-1>; 3503 A.4.2. Server authentication and key exchange messages 3505 opaque ASN.1Cert<2^24-1>; 3507 struct { 3508 ASN.1Cert certificate_list<0..2^24-1>; 3509 } Certificate; 3511 struct { 3512 CertificateStatusType status_type; 3513 select (status_type) { 3514 case ocsp: OCSPResponse; 3515 } response; 3516 } CertificateStatus; 3518 opaque OCSPResponse<1..2^24-1>; 3520 enum { rsa, diffie_hellman } KeyExchangeAlgorithm; 3522 struct { 3523 opaque rsa_modulus<1..2^16-1>; 3524 opaque rsa_exponent<1..2^16-1>; 3525 } ServerRSAParams; 3527 struct { 3528 opaque dh_p<1..2^16-1>; 3529 opaque dh_g<1..2^16-1>; 3530 opaque dh_Ys<1..2^16-1>; 3531 } ServerDHParams; 3533 struct { 3534 select (KeyExchangeAlgorithm) { 3535 case diffie_hellman: 3536 ServerDHParams params; 3537 Signature signed_params; 3538 case rsa: 3539 ServerRSAParams params; 3540 Signature signed_params; 3541 }; 3542 } ServerKeyExchange; 3544 enum { anonymous, rsa, dsa } SignatureAlgorithm; 3546 struct { 3547 select (KeyExchangeAlgorithm) { 3548 case diffie_hellman: 3549 ServerDHParams params; 3550 case rsa: 3551 ServerRSAParams params; 3552 }; 3553 } ServerParams; 3555 struct { 3556 select (SignatureAlgorithm) { 3557 case anonymous: struct { }; 3558 case rsa: 3559 digitally-signed struct { 3560 opaque hash[Hash.length]; 3561 }; 3562 case dsa: 3563 digitally-signed struct { 3564 opaque sha_hash[20]; 3565 }; 3566 }; 3567 }; 3568 } Signature; 3570 enum { 3571 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), 3572 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), 3573 fortezza_dms_RESERVED(20), 3574 (255) 3575 } ClientCertificateType; 3577 opaque DistinguishedName<1..2^16-1>; 3579 struct { 3580 ClientCertificateType certificate_types<1..2^8-1>; 3581 DistinguishedName certificate_authorities<0..2^16-1>; 3582 } CertificateRequest; 3584 struct { } ServerHelloDone; 3586 A.4.3. Client authentication and key exchange messages 3588 struct { 3589 select (KeyExchangeAlgorithm) { 3590 case rsa: EncryptedPreMasterSecret; 3591 case diffie_hellman: ClientDiffieHellmanPublic; 3592 } exchange_keys; 3593 } ClientKeyExchange; 3595 struct { 3596 ProtocolVersion client_version; 3597 opaque random[46]; 3598 } PreMasterSecret; 3600 struct { 3601 public-key-encrypted PreMasterSecret pre_master_secret; 3602 } EncryptedPreMasterSecret; 3604 enum { implicit, explicit } PublicValueEncoding; 3606 struct { 3607 select (PublicValueEncoding) { 3608 case implicit: struct {}; 3609 case explicit: opaque DH_Yc<1..2^16-1>; 3610 } dh_public; 3611 } ClientDiffieHellmanPublic; 3613 enum { 3614 individual_certs(0), pkipath(1), (255) 3615 } CertChainType; 3617 enum { 3618 false(0), true(1) 3619 } Boolean; 3621 struct { 3622 CertChainType type; 3623 URLAndOptionalHash url_and_hash_list<1..2^16-1>; 3624 } CertificateURL; 3626 struct { 3627 opaque url<1..2^16-1>; 3628 Boolean hash_present; 3629 select (hash_present) { 3630 case false: struct {}; 3631 case true: SHA1Hash; 3632 } hash; 3633 } URLAndOptionalHash; 3635 opaque SHA1Hash[20]; 3637 struct { 3638 Signature signature; 3639 } CertificateVerify; 3641 A.4.4. Handshake finalization message 3643 struct { 3644 opaque verify_data[12]; 3645 } Finished; 3647 A.5. The CipherSuite 3649 The following values define the CipherSuite codes used in the client 3650 hello and server hello messages. 3652 A CipherSuite defines a cipher specification supported in TLS Version 3653 1.1. 3655 TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a 3656 TLS connection during the first handshake on that channel, but must 3657 not be negotiated, as it provides no more protection than an 3658 unsecured connection. 3660 CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; 3662 The following CipherSuite definitions require that the server provide 3663 an RSA certificate that can be used for key exchange. The server may 3664 request either an RSA or a DSS signature-capable certificate in the 3665 certificate request message. 3667 CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; 3668 CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; 3669 CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; 3670 CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; 3671 CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; 3672 CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; 3673 CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; 3674 CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F }; 3675 CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 }; 3676 The following CipherSuite definitions are used for server- 3677 authenticated (and optionally client-authenticated) Diffie-Hellman. 3678 DH denotes cipher suites in which the server's certificate contains 3679 the Diffie-Hellman parameters signed by the certificate authority 3680 (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman 3681 parameters are signed by a DSS or RSA certificate, which has been 3682 signed by the CA. The signing algorithm used is specified after the 3683 DH or DHE parameter. The server can request an RSA or DSS signature- 3684 capable certificate from the client for client authentication or it 3685 may request a Diffie-Hellman certificate. Any Diffie-Hellman 3686 certificate provided by the client must use the parameters (group and 3687 generator) described by the server. 3689 CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; 3690 CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; 3691 CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; 3692 CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; 3693 CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; 3694 CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; 3695 CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; 3696 CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; 3697 CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x30 }; 3698 CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x31 }; 3699 CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x32 }; 3700 CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x33 }; 3701 CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 }; 3702 CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x36 }; 3703 CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x37 }; 3704 CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x38 }; 3705 CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x39 }; 3706 CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A }; 3708 The following cipher suites are used for completely anonymous Diffie- 3709 Hellman communications in which neither party is authenticated. Note 3710 that this mode is vulnerable to man-in-the-middle attacks and is 3711 therefore deprecated. 3713 CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; 3714 CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; 3715 CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; 3717 When SSLv3 and TLS 1.0 were designed, the United States restricted 3718 the export of cryptographic software containing certain strong 3719 encryption algorithms. A series of cipher suites were designed to 3720 operate at reduced key lengths in order to comply with those 3721 regulations. Due to advances in computer performance, these 3722 algorithms are now unacceptably weak and export restrictions have 3723 since been loosened. TLS 1.1 implementations MUST NOT negotiate these 3724 cipher suites in TLS 1.1 mode. However, for backward compatibility 3725 they may be offered in the ClientHello for use with TLS 1.0 or SSLv3 3726 only servers. TLS 1.1 clients MUST check that the server did not 3727 choose one of these cipher suites during the handshake. These 3728 ciphersuites are listed below for informational purposes and to 3729 reserve the numbers. 3731 CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; 3732 CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; 3733 CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; 3734 CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; 3735 CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; 3736 CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; 3737 CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; 3738 CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; 3739 CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; 3740 The following cipher suites were defined in [TLSKRB] and are included 3741 here for completeness. See [TLSKRB] for details: 3743 CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E }; 3744 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F }; 3745 CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 }; 3746 CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 }; 3747 CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 }; 3748 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 }; 3749 CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 }; 3750 CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 }; 3752 The following exportable cipher suites were defined in [TLSKRB] and 3753 are included here for completeness. TLS 1.1 implementations MUST NOT 3754 negotiate these cipher suites. 3756 CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 3757 }; 3758 CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 3759 }; 3760 CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 3761 }; 3762 CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 3763 }; 3764 CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A 3765 }; 3766 CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B 3767 }; 3769 The cipher suite space is divided into three regions: 3771 1. Cipher suite values with first byte 0x00 (zero) 3772 through decimal 191 (0xBF) inclusive are reserved for the IETF 3773 Standards Track protocols. 3775 2. Cipher suite values with first byte decimal 192 (0xC0) 3776 through decimal 254 (0xFE) inclusive are reserved 3777 for assignment for non-Standards Track methods. 3779 3. Cipher suite values with first byte 0xFF are 3780 reserved for private use. 3781 Additional information describing the role of IANA in the allocation 3782 of cipher suite code points is described in Section 11. 3784 Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are 3785 reserved to avoid collision with Fortezza-based cipher suites in SSL 3786 3. 3788 A.6. The Security Parameters 3790 These security parameters are determined by the TLS Handshake 3791 Protocol and provided as parameters to the TLS Record Layer in order 3792 to initialize a connection state. SecurityParameters includes: 3794 enum { null(0), (255) } CompressionMethod; 3796 enum { server, client } ConnectionEnd; 3798 enum { null, rc4, rc2, des, 3des, des40, aes, idea } 3799 BulkCipherAlgorithm; 3801 enum { stream, block } CipherType; 3803 enum { null, md5, sha } MACAlgorithm; 3805 /* The algorithms specified in CompressionMethod, 3806 BulkCipherAlgorithm, and MACAlgorithm may be added to. */ 3808 struct { 3809 ConnectionEnd entity; 3810 BulkCipherAlgorithm bulk_cipher_algorithm; 3811 CipherType cipher_type; 3812 uint8 key_size; 3813 uint8 key_material_length; 3814 MACAlgorithm mac_algorithm; 3815 uint8 hash_size; 3816 CompressionMethod compression_algorithm; 3817 opaque master_secret[48]; 3818 opaque client_random[32]; 3819 opaque server_random[32]; 3820 } SecurityParameters; 3821 B. Glossary 3823 Advanced Encryption Standard (AES) 3824 AES is a widely used symmetric encryption algorithm. 3825 AES is 3826 a block cipher with a 128, 192, or 256 bit keys and a 16 byte 3827 block size. [AES] TLS currently only supports the 128 and 256 3828 bit key sizes. 3830 application protocol 3831 An application protocol is a protocol that normally layers 3832 directly on top of the transport layer (e.g., TCP/IP). Examples 3833 include HTTP, TELNET, FTP, and SMTP. 3835 asymmetric cipher 3836 See public key cryptography. 3838 authentication 3839 Authentication is the ability of one entity to determine the 3840 identity of another entity. 3842 block cipher 3843 A block cipher is an algorithm that operates on plaintext in 3844 groups of bits, called blocks. 64 bits is a common block size. 3846 bulk cipher 3847 A symmetric encryption algorithm used to encrypt large quantities 3848 of data. 3850 cipher block chaining (CBC) 3851 CBC is a mode in which every plaintext block encrypted with a 3852 block cipher is first exclusive-ORed with the previous ciphertext 3853 block (or, in the case of the first block, with the 3854 initialization vector). For decryption, every block is first 3855 decrypted, then exclusive-ORed with the previous ciphertext block 3856 (or IV). 3858 certificate 3859 As part of the X.509 protocol (a.k.a. ISO Authentication 3860 framework), certificates are assigned by a trusted Certificate 3861 Authority and provide a strong binding between a party's identity 3862 or some other attributes and its public key. 3864 client 3865 The application entity that initiates a TLS connection to a 3866 server. This may or may not imply that the client initiated the 3867 underlying transport connection. The primary operational 3868 difference between the server and client is that the server is 3869 generally authenticated, while the client is only optionally 3870 authenticated. 3872 client write key 3873 The key used to encrypt data written by the client. 3875 client write MAC secret 3876 The secret data used to authenticate data written by the client. 3878 connection 3879 A connection is a transport (in the OSI layering model 3880 definition) that provides a suitable type of service. For TLS, 3881 such connections are peer to peer relationships. The connections 3882 are transient. Every connection is associated with one session. 3884 Data Encryption Standard 3885 DES is a very widely used symmetric encryption algorithm. DES is 3886 a block cipher with a 56 bit key and an 8 byte block size. Note 3887 that in TLS, for key generation purposes, DES is treated as 3888 having an 8 byte key length (64 bits), but it still only provides 3889 56 bits of protection. (The low bit of each key byte is presumed 3890 to be set to produce odd parity in that key byte.) DES can also 3891 be operated in a mode where three independent keys and three 3892 encryptions are used for each block of data; this uses 168 bits 3893 of key (24 bytes in the TLS key generation method) and provides 3894 the equivalent of 112 bits of security. [DES], [3DES] 3896 Digital Signature Standard (DSS) 3897 A standard for digital signing, including the Digital Signing 3898 Algorithm, approved by the National Institute of Standards and 3899 Technology, defined in NIST FIPS PUB 186, "Digital Signature 3900 Standard," published May, 1994 by the U.S. Dept. of Commerce. 3901 [DSS] 3903 digital signatures 3904 Digital signatures utilize public key cryptography and one-way 3905 hash functions to produce a signature of the data that can be 3906 authenticated, and is difficult to forge or repudiate. 3908 handshake 3909 An initial negotiation between client and server that establishes 3910 the parameters of their transactions. 3912 Initialization Vector (IV) 3913 When a block cipher is used in CBC mode, the initialization 3914 vector is exclusive-ORed with the first plaintext block prior to 3915 encryption. 3917 IDEA 3918 A 64-bit block cipher designed by Xuejia Lai and James Massey. 3919 [IDEA] 3921 Message Authentication Code (MAC) 3922 A Message Authentication Code is a one-way hash computed from a 3923 message and some secret data. It is difficult to forge without 3924 knowing the secret data. Its purpose is to detect if the message 3925 has been altered. 3927 master secret 3928 Secure secret data used for generating encryption keys, MAC 3929 secrets, and IVs. 3931 MD5 3932 MD5 is a secure hashing function that converts an arbitrarily 3933 long data stream into a digest of fixed size (16 bytes). [MD5] 3935 public key cryptography 3936 A class of cryptographic techniques employing two-key ciphers. 3937 Messages encrypted with the public key can only be decrypted with 3938 the associated private key. Conversely, messages signed with the 3939 private key can be verified with the public key. 3941 one-way hash function 3942 A one-way transformation that converts an arbitrary amount of 3943 data into a fixed-length hash. It is computationally hard to 3944 reverse the transformation or to find collisions. MD5 and SHA are 3945 examples of one-way hash functions. 3947 RC2 3948 A block cipher developed by Ron Rivest at RSA Data Security, Inc. 3949 [RSADSI] described in [RC2]. 3951 RC4 3952 A stream cipher invented by Ron Rivest. A compatible cipher is 3953 described in [SCH]. 3955 RSA 3956 A very widely used public-key algorithm that can be used for 3957 either encryption or digital signing. [RSA] 3959 server 3960 The server is the application entity that responds to requests 3961 for connections from clients. See also under client. 3963 session 3964 A TLS session is an association between a client and a server. 3965 Sessions are created by the handshake protocol. Sessions define a 3966 set of cryptographic security parameters, which can be shared 3967 among multiple connections. Sessions are used to avoid the 3968 expensive negotiation of new security parameters for each 3969 connection. 3971 session identifier 3972 A session identifier is a value generated by a server that 3973 identifies a particular session. 3975 server write key 3976 The key used to encrypt data written by the server. 3978 server write MAC secret 3979 The secret data used to authenticate data written by the server. 3981 SHA 3982 The Secure Hash Algorithm is defined in FIPS PUB 180-2. It 3983 produces a 20-byte output. Note that all references to SHA 3984 actually use the modified SHA-1 algorithm. [SHA] 3986 SSL 3987 Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on 3988 SSL Version 3.0 3990 stream cipher 3991 An encryption algorithm that converts a key into a 3992 cryptographically-strong keystream, which is then exclusive-ORed 3993 with the plaintext. 3995 symmetric cipher 3996 See bulk cipher. 3998 Transport Layer Security (TLS) 3999 This protocol; also, the Transport Layer Security working group 4000 of the Internet Engineering Task Force (IETF). See "Comments" at 4001 the end of this document. 4003 C. CipherSuite definitions 4005 CipherSuite Key Cipher Hash 4006 Exchange 4008 TLS_NULL_WITH_NULL_NULL NULL NULL NULL 4009 TLS_RSA_WITH_NULL_MD5 RSA NULL MD5 4010 TLS_RSA_WITH_NULL_SHA RSA NULL SHA 4011 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 4012 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA 4013 TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA 4014 TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA 4015 TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA 4016 TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA 4017 TLS_RSA_WITH_AES_256_SHA RSA AES_256_CBC SHA 4018 TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA 4019 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA 4020 TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA 4021 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA 4022 TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA 4023 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA 4024 TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA 4025 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA 4026 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 4027 TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA 4028 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA 4029 TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA 4030 TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA 4031 TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA 4032 TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA 4033 TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA 4034 TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA 4035 TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA 4036 TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA 4037 TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA 4038 TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA 4040 Key 4041 Exchange 4042 Algorithm Description Key size limit 4044 DHE_DSS Ephemeral DH with DSS signatures None 4045 DHE_RSA Ephemeral DH with RSA signatures None 4046 DH_anon Anonymous DH, no signatures None 4047 DH_DSS DH with DSS-based certificates None 4048 DH_RSA DH with RSA-based certificates None 4049 RSA = none 4050 NULL No key exchange N/A 4051 RSA RSA key exchange None 4053 Key Expanded IV Block 4054 Cipher Type Material Key Material Size Size 4056 NULL Stream 0 0 0 N/A 4057 IDEA_CBC Block 16 16 8 8 4058 RC2_CBC_40 Block 5 16 8 8 4059 RC4_40 Stream 5 16 0 N/A 4060 RC4_128 Stream 16 16 0 N/A 4061 DES40_CBC Block 5 8 8 8 4062 DES_CBC Block 8 8 8 8 4063 3DES_EDE_CBC Block 24 24 8 8 4065 Type 4066 Indicates whether this is a stream cipher or a block cipher 4067 running in CBC mode. 4069 Key Material 4070 The number of bytes from the key_block that are used for 4071 generating the write keys. 4073 Expanded Key Material 4074 The number of bytes actually fed into the encryption algorithm 4076 IV Size 4077 How much data needs to be generated for the initialization 4078 vector. Zero for stream ciphers; equal to the block size for 4079 block ciphers. 4081 Block Size 4082 The amount of data a block cipher enciphers in one chunk; a 4083 block cipher running in CBC mode can only encrypt an even 4084 multiple of its block size. 4086 Hash Hash Padding 4087 function Size Size 4088 NULL 0 0 4089 MD5 16 48 4090 SHA 20 40 4091 D. Implementation Notes 4093 The TLS protocol cannot prevent many common security mistakes. This 4094 section provides several recommendations to assist implementors. 4096 D.1 Random Number Generation and Seeding 4098 TLS requires a cryptographically-secure pseudorandom number generator 4099 (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs 4100 based on secure hash operations, most notably MD5 and/or SHA, are 4101 acceptable, but cannot provide more security than the size of the 4102 random number generator state. (For example, MD5-based PRNGs usually 4103 provide 128 bits of state.) 4105 To estimate the amount of seed material being produced, add the 4106 number of bits of unpredictable information in each seed byte. For 4107 example, keystroke timing values taken from a PC compatible's 18.2 Hz 4108 timer provide 1 or 2 secure bits each, even though the total size of 4109 the counter value is 16 bits or more. To seed a 128-bit PRNG, one 4110 would thus require approximately 100 such timer values. 4112 [RANDOM] provides guidance on the generation of random values. 4114 D.2 Certificates and authentication 4116 Implementations are responsible for verifying the integrity of 4117 certificates and should generally support certificate revocation 4118 messages. Certificates should always be verified to ensure proper 4119 signing by a trusted Certificate Authority (CA). The selection and 4120 addition of trusted CAs should be done very carefully. Users should 4121 be able to view information about the certificate and root CA. 4123 D.3 CipherSuites 4125 TLS supports a range of key sizes and security levels, including some 4126 which provide no or minimal security. A proper implementation will 4127 probably not support many cipher suites. For example, 40-bit 4128 encryption is easily broken, so implementations requiring strong 4129 security should not allow 40-bit keys. Similarly, anonymous Diffie- 4130 Hellman is strongly discouraged because it cannot prevent man-in-the- 4131 middle attacks. Applications should also enforce minimum and maximum 4132 key sizes. For example, certificate chains containing 512-bit RSA 4133 keys or signatures are not appropriate for high-security 4134 applications. 4136 E. Backward Compatibility With SSL 4138 For historical reasons and in order to avoid a profligate consumption 4139 of reserved port numbers, application protocols which are secured by 4140 TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same 4141 connection port: for example, the https protocol (HTTP secured by SSL 4142 or TLS) uses port 443 regardless of which security protocol it is 4143 using. Thus, some mechanism must be determined to distinguish and 4144 negotiate among the various protocols. 4146 TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting 4147 both is easy. TLS clients who wish to negotiate with such older 4148 servers SHOULD send client hello messages using the SSL 3.0 record 4149 format and client hello structure, sending {3, 2} for the version 4150 field to note that they support TLS 1.1. If the server supports only 4151 TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello; 4152 if it supports TLS 1.1 it will respond with a TLS 1.1 server hello. 4153 The negotiation then proceeds as appropriate for the negotiated 4154 protocol. 4156 Similarly, a TLS 1.1 server which wishes to interoperate with TLS 4157 1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages 4158 and respond with a SSL 3.0 server hello if an SSL 3.0 client hello 4159 with a version field of {3, 0} is received, denoting that this client 4160 does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a 4161 version field of {3, 1} is received, the server SHOULD respond with a 4162 TLS 1.0 hello with a version field of {3, 1}. 4164 Whenever a client already knows the highest protocol known to a 4165 server (for example, when resuming a session), it SHOULD initiate the 4166 connection in that native protocol. 4168 TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL 4169 Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept 4170 either client hello format if they wish to support SSL 2.0 clients on 4171 the same connection port. The only deviations from the Version 2.0 4172 specification are the ability to specify a version with a value of 4173 three and the support for more ciphering types in the CipherSpec. 4175 Warning: The ability to send Version 2.0 client hello messages will be 4176 phased out with all due haste. Implementors SHOULD make every 4177 effort to move forward as quickly as possible. Version 3.0 4178 provides better mechanisms for moving to newer versions. 4180 The following cipher specifications are carryovers from SSL Version 4181 2.0. These are assumed to use RSA for key exchange and 4182 authentication. 4184 V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; 4185 V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; 4186 V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; 4187 V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 4188 = { 0x04,0x00,0x80 }; 4189 V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 }; 4190 V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 }; 4191 V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; 4193 Cipher specifications native to TLS can be included in Version 2.0 4194 client hello messages using the syntax below. Any V2CipherSpec 4195 element with its first byte equal to zero will be ignored by Version 4196 2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD 4197 also include the TLS equivalent (see Appendix A.5): 4199 V2CipherSpec (see TLS name) = { 0x00, CipherSuite }; 4201 Note: TLS 1.2 clients may generate the SSLv2 EXPORT cipher suites in 4202 handshakes for backward compatibility but MUST NOT negotiate them in 4203 TLS 1.2 mode. 4205 E.1. Version 2 client hello 4207 The Version 2.0 client hello message is presented below using this 4208 document's presentation model. The true definition is still assumed 4209 to be the SSL Version 2.0 specification. Note that this message MUST 4210 be sent directly on the wire, not wrapped as an SSLv3 record 4212 uint8 V2CipherSpec[3]; 4214 struct { 4215 uint16 msg_length; 4216 uint8 msg_type; 4217 Version version; 4218 uint16 cipher_spec_length; 4219 uint16 session_id_length; 4220 uint16 challenge_length; 4221 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; 4222 opaque session_id[V2ClientHello.session_id_length]; 4223 opaque challenge[V2ClientHello.challenge_length; 4224 } V2ClientHello; 4226 msg_length 4227 This field is the length of the following data in bytes. The high 4228 bit MUST be 1 and is not part of the length. 4230 msg_type 4231 This field, in conjunction with the version field, identifies a 4232 version 2 client hello message. The value SHOULD be one (1). 4234 version 4235 The highest version of the protocol supported by the client 4236 (equals ProtocolVersion.version, see Appendix A.1). 4238 cipher_spec_length 4239 This field is the total length of the field cipher_specs. It 4240 cannot be zero and MUST be a multiple of the V2CipherSpec length 4241 (3). 4243 session_id_length 4244 This field MUST have a value of zero. 4246 challenge_length 4247 The length in bytes of the client's challenge to the server to 4248 authenticate itself. When using the SSLv2 backward compatible 4249 handshake the client MUST use a 32-byte challenge. 4251 cipher_specs 4252 This is a list of all CipherSpecs the client is willing and able 4253 to use. There MUST be at least one CipherSpec acceptable to the 4254 server. 4256 session_id 4257 This field MUST be empty. 4259 challenge 4260 The client challenge to the server for the server to identify 4261 itself is a (nearly) arbitrary length random. The TLS server will 4262 right justify the challenge data to become the ClientHello.random 4263 data (padded with leading zeroes, if necessary), as specified in 4264 this protocol specification. If the length of the challenge is 4265 greater than 32 bytes, only the last 32 bytes are used. It is 4266 legitimate (but not necessary) for a V3 server to reject a V2 4267 ClientHello that has fewer than 16 bytes of challenge data. 4269 Note: Requests to resume a TLS session MUST use a TLS client hello. 4271 E.2. Avoiding man-in-the-middle version rollback 4273 When TLS clients fall back to Version 2.0 compatibility mode, they 4274 SHOULD use special PKCS #1 block formatting. This is done so that TLS 4275 servers will reject Version 2.0 sessions with TLS-capable clients. 4277 When TLS clients are in Version 2.0 compatibility mode, they set the 4278 right-hand (least-significant) 8 random bytes of the PKCS padding 4279 (not including the terminal null of the padding) for the RSA 4280 encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY 4281 to 0x03 (the other padding bytes are random). After decrypting the 4282 ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an 4283 error if these eight padding bytes are 0x03. Version 2.0 servers 4284 receiving blocks padded in this manner will proceed normally. 4286 F. Security analysis 4288 The TLS protocol is designed to establish a secure connection between 4289 a client and a server communicating over an insecure channel. This 4290 document makes several traditional assumptions, including that 4291 attackers have substantial computational resources and cannot obtain 4292 secret information from sources outside the protocol. Attackers are 4293 assumed to have the ability to capture, modify, delete, replay, and 4294 otherwise tamper with messages sent over the communication channel. 4295 This appendix outlines how TLS has been designed to resist a variety 4296 of attacks. 4298 F.1. Handshake protocol 4300 The handshake protocol is responsible for selecting a CipherSpec and 4301 generating a Master Secret, which together comprise the primary 4302 cryptographic parameters associated with a secure session. The 4303 handshake protocol can also optionally authenticate parties who have 4304 certificates signed by a trusted certificate authority. 4306 F.1.1. Authentication and key exchange 4308 TLS supports three authentication modes: authentication of both 4309 parties, server authentication with an unauthenticated client, and 4310 total anonymity. Whenever the server is authenticated, the channel is 4311 secure against man-in-the-middle attacks, but completely anonymous 4312 sessions are inherently vulnerable to such attacks. Anonymous 4313 servers cannot authenticate clients. If the server is authenticated, 4314 its certificate message must provide a valid certificate chain 4315 leading to an acceptable certificate authority. Similarly, 4316 authenticated clients must supply an acceptable certificate to the 4317 server. Each party is responsible for verifying that the other's 4318 certificate is valid and has not expired or been revoked. 4320 The general goal of the key exchange process is to create a 4321 pre_master_secret known to the communicating parties and not to 4322 attackers. The pre_master_secret will be used to generate the 4323 master_secret (see Section 8.1). The master_secret is required to 4324 generate the finished messages, encryption keys, and MAC secrets (see 4325 Sections 7.4.10, 7.4.11 and 6.3). By sending a correct finished 4326 message, parties thus prove that they know the correct 4327 pre_master_secret. 4329 F.1.1.1. Anonymous key exchange 4331 Completely anonymous sessions can be established using RSA or Diffie- 4332 Hellman for key exchange. With anonymous RSA, the client encrypts a 4333 pre_master_secret with the server's uncertified public key extracted 4334 from the server key exchange message. The result is sent in a client 4335 key exchange message. Since eavesdroppers do not know the server's 4336 private key, it will be infeasible for them to decode the 4337 pre_master_secret. 4339 Note: No anonymous RSA Cipher Suites are defined in this document. 4341 With Diffie-Hellman, the server's public parameters are contained in 4342 the server key exchange message and the client's are sent in the 4343 client key exchange message. Eavesdroppers who do not know the 4344 private values should not be able to find the Diffie-Hellman result 4345 (i.e. the pre_master_secret). 4347 Warning: Completely anonymous connections only provide protection 4348 against passive eavesdropping. Unless an independent tamper- 4349 proof channel is used to verify that the finished messages 4350 were not replaced by an attacker, server authentication is 4351 required in environments where active man-in-the-middle 4352 attacks are a concern. 4354 F.1.1.2. RSA key exchange and authentication 4356 With RSA, key exchange and server authentication are combined. The 4357 public key may be either contained in the server's certificate or may 4358 be a temporary RSA key sent in a server key exchange message. When 4359 temporary RSA keys are used, they are signed by the server's RSA 4360 certificate. The signature includes the current ClientHello.random, 4361 so old signatures and temporary keys cannot be replayed. Servers may 4362 use a single temporary RSA key for multiple negotiation sessions. 4364 Note: The temporary RSA key option is useful if servers need large 4365 certificates but must comply with government-imposed size limits 4366 on keys used for key exchange. 4368 Note that if ephemeral RSA is not used, compromise of the server's 4369 static RSA key results in a loss of confidentiality for all sessions 4370 protected under that static key. TLS users desiring Perfect Forward 4371 Secrecy should use DHE cipher suites. The damage done by exposure of 4372 a private key can be limited by changing one's private key (and 4373 certificate) frequently. 4375 After verifying the server's certificate, the client encrypts a 4376 pre_master_secret with the server's public key. By successfully 4377 decoding the pre_master_secret and producing a correct finished 4378 message, the server demonstrates that it knows the private key 4379 corresponding to the server certificate. 4381 When RSA is used for key exchange, clients are authenticated using 4382 the certificate verify message (see Section 7.4.10). The client signs 4383 a value derived from the master_secret and all preceding handshake 4384 messages. These handshake messages include the server certificate, 4385 which binds the signature to the server, and ServerHello.random, 4386 which binds the signature to the current handshake process. 4388 F.1.1.3. Diffie-Hellman key exchange with authentication 4390 When Diffie-Hellman key exchange is used, the server can either 4391 supply a certificate containing fixed Diffie-Hellman parameters or 4392 can use the server key exchange message to send a set of temporary 4393 Diffie-Hellman parameters signed with a DSS or RSA certificate. 4394 Temporary parameters are hashed with the hello.random values before 4395 signing to ensure that attackers do not replay old parameters. In 4396 either case, the client can verify the certificate or signature to 4397 ensure that the parameters belong to the server. 4399 If the client has a certificate containing fixed Diffie-Hellman 4400 parameters, its certificate contains the information required to 4401 complete the key exchange. Note that in this case the client and 4402 server will generate the same Diffie-Hellman result (i.e., 4403 pre_master_secret) every time they communicate. To prevent the 4404 pre_master_secret from staying in memory any longer than necessary, 4405 it should be converted into the master_secret as soon as possible. 4406 Client Diffie-Hellman parameters must be compatible with those 4407 supplied by the server for the key exchange to work. 4409 If the client has a standard DSS or RSA certificate or is 4410 unauthenticated, it sends a set of temporary parameters to the server 4411 in the client key exchange message, then optionally uses a 4412 certificate verify message to authenticate itself. 4414 If the same DH keypair is to be used for multiple handshakes, either 4415 because the client or server has a certificate containing a fixed DH 4416 keypair or because the server is reusing DH keys, care must be taken 4417 to prevent small subgroup attacks. Implementations SHOULD follow the 4418 guidelines found in [SUBGROUP]. 4420 Small subgroup attacks are most easily avoided by using one of the 4421 DHE ciphersuites and generating a fresh DH private key (X) for each 4422 handshake. If a suitable base (such as 2) is chosen, g^X mod p can be 4423 computed very quickly so the performance cost is minimized. 4424 Additionally, using a fresh key for each handshake provides Perfect 4425 Forward Secrecy. Implementations SHOULD generate a new X for each 4426 handshake when using DHE ciphersuites. 4428 F.1.2. Version rollback attacks 4429 Because TLS includes substantial improvements over SSL Version 2.0, 4430 attackers may try to make TLS-capable clients and servers fall back 4431 to Version 2.0. This attack can occur if (and only if) two TLS- 4432 capable parties use an SSL 2.0 handshake. 4434 Although the solution using non-random PKCS #1 block type 2 message 4435 padding is inelegant, it provides a reasonably secure way for Version 4436 3.0 servers to detect the attack. This solution is not secure against 4437 attackers who can brute force the key and substitute a new ENCRYPTED- 4438 KEY-DATA message containing the same key (but with normal padding) 4439 before the application specified wait threshold has expired. Parties 4440 concerned about attacks of this scale should not be using 40-bit 4441 encryption keys anyway. Altering the padding of the least-significant 4442 8 bytes of the PKCS padding does not impact security for the size of 4443 the signed hashes and RSA key lengths used in the protocol, since 4444 this is essentially equivalent to increasing the input block size by 4445 8 bytes. 4447 F.1.3. Detecting attacks against the handshake protocol 4449 An attacker might try to influence the handshake exchange to make the 4450 parties select different encryption algorithms than they would 4451 normally chooses. 4453 For this attack, an attacker must actively change one or more 4454 handshake messages. If this occurs, the client and server will 4455 compute different values for the handshake message hashes. As a 4456 result, the parties will not accept each others' finished messages. 4457 Without the master_secret, the attacker cannot repair the finished 4458 messages, so the attack will be discovered. 4460 F.1.4. Resuming sessions 4462 When a connection is established by resuming a session, new 4463 ClientHello.random and ServerHello.random values are hashed with the 4464 session's master_secret. Provided that the master_secret has not been 4465 compromised and that the secure hash operations used to produce the 4466 encryption keys and MAC secrets are secure, the connection should be 4467 secure and effectively independent from previous connections. 4468 Attackers cannot use known encryption keys or MAC secrets to 4469 compromise the master_secret without breaking the secure hash 4470 operations (which use both SHA and MD5). 4472 Sessions cannot be resumed unless both the client and server agree. 4473 If either party suspects that the session may have been compromised, 4474 or that certificates may have expired or been revoked, it should 4475 force a full handshake. An upper limit of 24 hours is suggested for 4476 session ID lifetimes, since an attacker who obtains a master_secret 4477 may be able to impersonate the compromised party until the 4478 corresponding session ID is retired. Applications that may be run in 4479 relatively insecure environments should not write session IDs to 4480 stable storage. 4482 F.1.5 Extensions 4484 Security considerations for the extension mechanism in general, and 4485 the design of new extensions, are described in the previous section. 4486 A security analysis of each of the extensions defined in this 4487 document is given below. 4489 In general, implementers should continue to monitor the state of the 4490 art, and address any weaknesses identified. 4492 F.1.5.1 Security of server_name 4494 If a single server hosts several domains, then clearly it is 4495 necessary for the owners of each domain to ensure that this satisfies 4496 their security needs. Apart from this, server_name does not appear 4497 to introduce significant security issues. 4499 Implementations MUST ensure that a buffer overflow does not occur 4500 whatever the values of the length fields in server_name. 4502 Although this document specifies an encoding for internationalized 4503 hostnames in the server_name extension, it does not address any 4504 security issues associated with the use of internationalized 4505 hostnames in TLS - in particular, the consequences of "spoofed" names 4506 that are indistinguishable from another name when displayed or 4507 printed. It is recommended that server certificates not be issued 4508 for internationalized hostnames unless procedures are in place to 4509 mitigate the risk of spoofed hostnames. 4511 6.2. Security of max_fragment_length 4513 The maximum fragment length takes effect immediately, including for 4514 handshake messages. However, that does not introduce any security 4515 complications that are not already present in TLS, since [TLS] 4516 requires implementations to be able to handle fragmented handshake 4517 messages. 4519 Note that as described in section XXX, once a non-null cipher suite 4520 has been activated, the effective maximum fragment length depends on 4521 the cipher suite and compression method, as well as on the negotiated 4522 max_fragment_length. This must be taken into account when sizing 4523 buffers, and checking for buffer overflow. 4525 F.1.5.2 Security of client_certificate_url 4527 There are two major issues with this extension. 4529 The first major issue is whether or not clients should include 4530 certificate hashes when they send certificate URLs. 4532 When client authentication is used *without* the 4533 client_certificate_url extension, the client certificate chain is 4534 covered by the Finished message hashes. The purpose of including 4535 hashes and checking them against the retrieved certificate chain, is 4536 to ensure that the same property holds when this extension is used - 4537 i.e., that all of the information in the certificate chain retrieved 4538 by the server is as the client intended. 4540 On the other hand, omitting certificate hashes enables functionality 4541 that is desirable in some circumstances - for example clients can be 4542 issued daily certificates that are stored at a fixed URL and need not 4543 be provided to the client. Clients that choose to omit certificate 4544 hashes should be aware of the possibility of an attack in which the 4545 attacker obtains a valid certificate on the client's key that is 4546 different from the certificate the client intended to provide. 4547 Although TLS uses both MD5 and SHA-1 hashes in several other places, 4548 this was not believed to be necessary here. The property required of 4549 SHA-1 is second pre-image resistance. 4551 The second major issue is that support for client_certificate_url 4552 involves the server acting as a client in another URL protocol. The 4553 server therefore becomes subject to many of the same security 4554 concerns that clients of the URL scheme are subject to, with the 4555 added concern that the client can attempt to prompt the server to 4556 connect to some, possibly weird-looking URL. 4558 In general this issue means that an attacker might use the server to 4559 indirectly attack another host that is vulnerable to some security 4560 flaw. It also introduces the possibility of denial of service 4561 attacks in which an attacker makes many connections to the server, 4562 each of which results in the server attempting a connection to the 4563 target of the attack. 4565 Note that the server may be behind a firewall or otherwise able to 4566 access hosts that would not be directly accessible from the public 4567 Internet; this could exacerbate the potential security and denial of 4568 service problems described above, as well as allowing the existence 4569 of internal hosts to be confirmed when they would otherwise be 4570 hidden. 4572 The detailed security concerns involved will depend on the URL 4573 schemes supported by the server. In the case of HTTP, the concerns 4574 are similar to those that apply to a publicly accessible HTTP proxy 4575 server. In the case of HTTPS, the possibility for loops and 4576 deadlocks to be created exists and should be addressed. In the case 4577 of FTP, attacks similar to FTP bounce attacks arise. 4579 As a result of this issue, it is RECOMMENDED that the 4580 client_certificate_url extension should have to be specifically 4581 enabled by a server administrator, rather than being enabled by 4582 default. It is also RECOMMENDED that URI protocols be enabled by the 4583 administrator individually, and only a minimal set of protocols be 4584 enabled, with unusual protocols offering limited security or whose 4585 security is not well-understood being avoided. 4587 As discussed in [URI], URLs that specify ports other than the default 4588 may cause problems, as may very long URLs (which are more likely to 4589 be useful in exploiting buffer overflow bugs). 4591 Also note that HTTP caching proxies are common on the Internet, and 4592 some proxies do not check for the latest version of an object 4593 correctly. If a request using HTTP (or another caching protocol) 4594 goes through a misconfigured or otherwise broken proxy, the proxy may 4595 return an out-of-date response. 4597 F.1.5.4. Security of trusted_ca_keys 4599 It is possible that which CA root keys a client possesses could be 4600 regarded as confidential information. As a result, the CA root key 4601 indication extension should be used with care. 4603 The use of the SHA-1 certificate hash alternative ensures that each 4604 certificate is specified unambiguously. As for the previous 4605 extension, it was not believed necessary to use both MD5 and SHA-1 4606 hashes. 4608 F.1.5.5. Security of truncated_hmac 4610 It is possible that truncated MACs are weaker than "un-truncated" 4611 MACs. However, no significant weaknesses are currently known or 4612 expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits. 4614 Note that the output length of a MAC need not be as long as the 4615 length of a symmetric cipher key, since forging of MAC values cannot 4616 be done off-line: in TLS, a single failed MAC guess will cause the 4617 immediate termination of the TLS session. 4619 Since the MAC algorithm only takes effect after the handshake 4620 messages have been authenticated by the hashes in the Finished 4621 messages, it is not possible for an active attacker to force 4622 negotiation of the truncated HMAC extension where it would not 4623 otherwise be used (to the extent that the handshake authentication is 4624 secure). Therefore, in the event that any security problem were 4625 found with truncated HMAC in future, if either the client or the 4626 server for a given session were updated to take into account the 4627 problem, they would be able to veto use of this extension. 4629 F.1.5.6. Security of status_request 4631 If a client requests an OCSP response, it must take into account that 4632 an attacker's server using a compromised key could (and probably 4633 would) pretend not to support the extension. A client that requires 4634 OCSP validation of certificates SHOULD either contact the OCSP server 4635 directly in this case, or abort the handshake. 4637 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may 4638 improve security against attacks that attempt to replay OCSP 4639 responses; see section 4.4.1 of [OCSP] for further details. 4641 F.2. Protecting application data 4643 The master_secret is hashed with the ClientHello.random and 4644 ServerHello.random to produce unique data encryption keys and MAC 4645 secrets for each connection. 4647 Outgoing data is protected with a MAC before transmission. To prevent 4648 message replay or modification attacks, the MAC is computed from the 4649 MAC secret, the sequence number, the message length, the message 4650 contents, and two fixed character strings. The message type field is 4651 necessary to ensure that messages intended for one TLS Record Layer 4652 client are not redirected to another. The sequence number ensures 4653 that attempts to delete or reorder messages will be detected. Since 4654 sequence numbers are 64-bits long, they should never overflow. 4655 Messages from one party cannot be inserted into the other's output, 4656 since they use independent MAC secrets. Similarly, the server-write 4657 and client-write keys are independent so stream cipher keys are used 4658 only once. 4660 If an attacker does break an encryption key, all messages encrypted 4661 with it can be read. Similarly, compromise of a MAC key can make 4662 message modification attacks possible. Because MACs are also 4663 encrypted, message-alteration attacks generally require breaking the 4664 encryption algorithm as well as the MAC. 4666 Note: MAC secrets may be larger than encryption keys, so messages can 4667 remain tamper resistant even if encryption keys are broken. 4669 F.3. Explicit IVs 4671 [CBCATT] describes a chosen plaintext attack on TLS that depends 4672 on knowing the IV for a record. Previous versions of TLS [TLS1.0] 4673 used the CBC residue of the previous record as the IV and 4674 therefore enabled this attack. This version uses an explicit IV 4675 in order to protect against this attack. 4677 F.4 Security of Composite Cipher Modes 4679 TLS secures transmitted application data via the use of symmetric 4680 encryption and authentication functions defined in the negotiated 4681 ciphersuite. The objective is to protect both the integrity and 4682 confidentiality of the transmitted data from malicious actions by 4683 active attackers in the network. It turns out that the order in 4684 which encryption and authentication functions are applied to the 4685 data plays an important role for achieving this goal [ENCAUTH]. 4687 The most robust method, called encrypt-then-authenticate, first 4688 applies encryption to the data and then applies a MAC to the 4689 ciphertext. This method ensures that the integrity and 4690 confidentiality goals are obtained with ANY pair of encryption 4691 and MAC functions provided that the former is secure against 4692 chosen plaintext attacks and the MAC is secure against chosen- 4693 message attacks. TLS uses another method, called authenticate- 4694 then-encrypt, in which first a MAC is computed on the plaintext 4695 and then the concatenation of plaintext and MAC is encrypted. 4696 This method has been proven secure for CERTAIN combinations of 4697 encryption functions and MAC functions, but is not guaranteed to 4698 be secure in general. In particular, it has been shown that there 4699 exist perfectly secure encryption functions (secure even in the 4700 information theoretic sense) that combined with any secure MAC 4701 function fail to provide the confidentiality goal against an 4702 active attack. Therefore, new ciphersuites and operation modes 4703 adopted into TLS need to be analyzed under the authenticate-then- 4704 encrypt method to verify that they achieve the stated integrity 4705 and confidentiality goals. 4707 Currently, the security of the authenticate-then-encrypt method 4708 has been proven for some important cases. One is the case of 4709 stream ciphers in which a computationally unpredictable pad of 4710 the length of the message plus the length of the MAC tag is 4711 produced using a pseudo-random generator and this pad is xor-ed 4712 with the concatenation of plaintext and MAC tag. The other is 4713 the case of CBC mode using a secure block cipher. In this case, 4714 security can be shown if one applies one CBC encryption pass to 4715 the concatenation of plaintext and MAC and uses a new, 4716 independent and unpredictable, IV for each new pair of plaintext 4717 and MAC. In previous versions of SSL, CBC mode was used properly 4718 EXCEPT that it used a predictable IV in the form of the last 4719 block of the previous ciphertext. This made TLS open to chosen 4720 plaintext attacks. This verson of the protocol is immune to 4721 those attacks. For exact details in the encryption modes proven 4722 secure see [ENCAUTH]. 4724 F.5 Denial of Service 4726 TLS is susceptible to a number of denial of service (DoS) 4727 attacks. In particular, an attacker who initiates a large number 4728 of TCP connections can cause a server to consume large amounts of 4729 CPU doing RSA decryption. However, because TLS is generally used 4730 over TCP, it is difficult for the attacker to hide his point of 4731 origin if proper TCP SYN randomization is used [SEQNUM] by the 4732 TCP stack. 4734 Because TLS runs over TCP, it is also susceptible to a number of 4735 denial of service attacks on individual connections. In 4736 particular, attackers can forge RSTs, terminating connections, or 4737 forge partial TLS records, causing the connection to stall. 4738 These attacks cannot in general be defended against by a TCP- 4739 using protocol. Implementors or users who are concerned with this 4740 class of attack should use IPsec AH [AH] or ESP [ESP]. 4742 F.6. Final notes 4744 For TLS to be able to provide a secure connection, both the client 4745 and server systems, keys, and applications must be secure. In 4746 addition, the implementation must be free of security errors. 4748 The system is only as strong as the weakest key exchange and 4749 authentication algorithm supported, and only trustworthy 4750 cryptographic functions should be used. Short public keys, 40-bit 4751 bulk encryption keys, and anonymous servers should be used with great 4752 caution. Implementations and users must be careful when deciding 4753 which certificates and certificate authorities are acceptable; a 4754 dishonest certificate authority can do tremendous damage. 4756 Security Considerations 4758 Security issues are discussed throughout this memo, especially in 4759 Appendices D, E, and F. 4761 Normative References 4762 [AES] National Institute of Standards and Technology, 4763 "Specification for the Advanced Encryption Standard (AES)" 4764 FIPS 197. November 26, 2001. 4766 [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," 4767 IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. 4769 [DES] ANSI X3.106, "American National Standard for Information 4770 Systems-Data Link Encryption," American National Standards 4771 Institute, 1983. 4773 [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National 4774 Institute of Standards and Technology, U.S. Department of 4775 Commerce, 2000. 4777 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4778 Hashing for Message Authentication," RFC 2104, February 4779 1997. 4781 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 4782 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer 4783 Protocol -- HTTP/1.1", RFC 2616, June 1999. 4785 [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH 4786 Series in Information Processing, v. 1, Konstanz: Hartung- 4787 Gorre Verlag, 1992. 4789 [IDNA] Faltstrom, P., Hoffman, P. and A. Costello, 4790 "Internationalizing Domain Names in Applications (IDNA)", 4791 RFC 3490, March 2003. 4793 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 4794 April 1992. 4796 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. 4797 Adams, "Internet X.509 Public Key Infrastructure: Online 4798 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 4800 [PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: 4801 RSA Cryptography Specifications Version 1.5", RFC 2313, 4802 March 1998. 4804 [PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards 4805 (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 4806 3447, February 2003. 4808 [PKIOP] Housley, R. and P. Hoffman, "Internet X.509 Public Key 4809 Infrastructure - Operation Protocols: FTP and HTTP", RFC 4810 2585, May 1999. 4812 [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 4813 Public Key Infrastructure: Part I: X.509 Certificate and CRL 4814 Profile", RFC 3280, April 2002. 4816 [RC2] Rivest, R., "A Description of the RC2(r) Encryption 4817 Algorithm", RFC 2268, January 1998. 4819 [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, 4820 and Source Code in C, 2ed", Published by John Wiley & Sons, 4821 Inc. 1996. 4823 [SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National 4824 Institute of Standards and Technology, U.S. Department of 4825 Commerce., August 2001. 4827 [REQ] Bradner, S., "Key words for use in RFCs to Indicate 4828 Requirement Levels", BCP 14, RFC 2119, March 1997. 4830 [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 4831 Considerations Section in RFCs", RFC 3434, October 1998. 4833 [TLSAES] Chown, P. "Advanced Encryption Standard (AES) Ciphersuites 4834 for Transport Layer Security (TLS)", RFC 3268, June 2002. 4836 [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J., 4837 Wright, T., "Transport Layer Security (TLS) Extensions", RFC 4838 3546, June 2003. 4839 [TLSKRB] A. Medvinsky, M. Hur, "Addition of Kerberos Cipher Suites to 4840 Transport Layer Security (TLS)", RFC 2712, October 1999. 4842 [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 4843 Resource Identifiers (URI): Generic Syntax", RFC 2396, 4844 August 1998. 4846 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 4847 RFC 3629, November 2003. 4849 [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- 8:2001, 4850 "Information Systems - Open Systems Interconnection - The 4851 Directory: Public key and Attribute certificate 4852 frameworks." 4854 [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | 4855 ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to 4856 ISO/IEC 9594:8:2001. 4858 Informative References 4860 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC 4861 2402, November 1998. 4863 [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against 4864 Protocols Based on RSA Encryption Standard PKCS #1" in 4865 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: 4866 1-12, 1998. 4868 [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: 4869 Problems and Countermeasures", 4870 http://www.openssl.org/~bodo/tls-cbc.txt. 4872 [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel", 4873 http://lasecwww.epfl.ch/memo_ssl.shtml, 2003. 4875 [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication 4876 for Protecting Communications (Or: How Secure is SSL?)", 4877 Crypto 2001. 4879 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security 4880 Payload (ESP)", RFC 2406, November 1998. 4882 [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based 4883 Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, 4884 March 2003. 4886 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax 4887 Standard," version 1.5, November 1993. 4889 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax 4890 Standard," version 1.5, November 1993. 4892 [RANDOM] D. Eastlake 3rd, S. Crocker, J. Schiller. "Randomness 4893 Recommendations for Security", RFC 1750, December 1994. 4895 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for 4896 Obtaining Digital Signatures and Public-Key Cryptosystems," 4897 Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 4899 120-126. 4901 [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks", 4902 RFC 1948, May 1996. 4904 [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications 4905 Corp., Feb 9, 1995. 4907 [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", 4908 Netscape Communications Corp., Nov 18, 1996. 4910 [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup 4911 Attacks on the Diffie-Hellman Key Agreement Method for 4912 S/MIME", RFC 2785, March 2000. 4914 [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, 4915 September 1981. 4917 [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are 4918 practical", USENIX Security Symposium 2003. 4920 [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0", 4921 RFC 2246, January 1999. 4923 [TLS1.1] Dierks, T., and Rescorla, E., "The TLS Protocol, Version 4924 1.1", RFC 4346, April, 2006. 4926 [X501] ITU-T Recommendation X.501: Information Technology - Open 4927 Systems Interconnection - The Directory: Models, 1993. 4929 [X509] ITU-T Recommendation X.509 (1997 E): Information Technology - 4930 Open Systems Interconnection - "The Directory - 4931 Authentication Framework". 1988. 4933 [XDR] R. Srinivansan, Sun Microsystems, "XDR: External Data 4934 Representation Standard", RFC 1832, August 1995. 4936 Credits 4938 Working Group Chairs 4939 Eric Rescorla 4940 EMail: ekr@rtfm.com 4942 Pasi Eronen 4943 pasi.eronen@nokia.com 4944 Editors 4946 Tim Dierks Eric Rescorla 4947 Independent Network Resonance, Inc. 4949 EMail: tim@dierks.org EMail: ekr@networkresonance.com 4951 Other contributors 4953 Christopher Allen (co-editor of TLS 1.0) 4954 Alacrity Ventures 4955 ChristopherA@AlacrityManagement.com 4957 Martin Abadi 4958 University of California, Santa Cruz 4959 abadi@cs.ucsc.edu 4961 Steven M. Bellovin 4962 Columbia University 4963 smb@cs.columbia.edu 4965 Simon Blake-Wilson 4966 BCI 4967 EMail: sblakewilson@bcisse.com 4969 Ran Canetti 4970 IBM 4971 canetti@watson.ibm.com 4973 Pete Chown 4974 Skygate Technology Ltd 4975 pc@skygate.co.uk 4977 Taher Elgamal 4978 taher@securify.com 4979 Securify 4981 Anil Gangolli 4982 anil@busybuddha.org 4984 Kipp Hickman 4986 David Hopwood 4987 Independent Consultant 4988 EMail: david.hopwood@blueyonder.co.uk 4989 Phil Karlton (co-author of SSLv3) 4991 Paul Kocher (co-author of SSLv3) 4992 Cryptography Research 4993 paul@cryptography.com 4995 Hugo Krawczyk 4996 Technion Israel Institute of Technology 4997 hugo@ee.technion.ac.il 4999 Jan Mikkelsen 5000 Transactionware 5001 EMail: janm@transactionware.com 5003 Magnus Nystrom 5004 RSA Security 5005 EMail: magnus@rsasecurity.com 5007 Robert Relyea 5008 Netscape Communications 5009 relyea@netscape.com 5011 Jim Roskind 5012 Netscape Communications 5013 jar@netscape.com 5015 Michael Sabin 5017 Dan Simon 5018 Microsoft, Inc. 5019 dansimon@microsoft.com 5021 Tom Weinstein 5023 Tim Wright 5024 Vodafone 5025 EMail: timothy.wright@vodafone.com 5027 Comments 5029 The discussion list for the IETF TLS working group is located at the 5030 e-mail address . Information on the group and 5031 information on how to subscribe to the list is at 5032 5034 Archives of the list can be found at: 5035 5036 Intellectual Property Statement 5038 The IETF takes no position regarding the validity or scope of any 5039 Intellectual Property Rights or other rights that might be claimed to 5040 pertain to the implementation or use of the technology described in 5041 this document or the extent to which any license under such rights 5042 might or might not be available; nor does it represent that it has 5043 made any independent effort to identify any such rights. Information 5044 on the procedures with respect to rights in RFC documents can be 5045 found in BCP 78 and BCP 79. 5047 Copies of IPR disclosures made to the IETF Secretariat and any 5048 assurances of licenses to be made available, or the result of an 5049 attempt made to obtain a general license or permission for the use of 5050 such proprietary rights by implementers or users of this 5051 specification can be obtained from the IETF on-line IPR repository at 5052 http://www.ietf.org/ipr. 5054 The IETF invites any interested party to bring to its attention any 5055 copyrights, patents or patent applications, or other proprietary 5056 rights that may cover technology that may be required to implement 5057 this standard. Please address the information to the IETF at 5058 ietf-ipr@ietf.org. 5060 Disclaimer of Validity 5062 This document and the information contained herein are provided on an 5063 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5064 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 5065 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 5066 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 5067 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5068 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5070 Copyright Statement 5072 Copyright (C) The Internet Society (2006). This document is subject 5073 to the rights, licenses and restrictions contained in BCP 78, and 5074 except as set forth therein, the authors retain all their rights. 5076 Acknowledgment 5078 Funding for the RFC Editor function is currently provided by the 5079 Internet Society.