idnits 2.17.00 (12 Aug 2021) /tmp/idnits9340/draft-ietf-tls-rfc4346-bis-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4552. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 763 has weird spacing: '...gorithm bul...' == Line 2360 has weird spacing: '...ixed_dh a c...' == Line 2361 has weird spacing: '...ixed_dh a c...' == Line 2490 has weird spacing: '...ed_ecdh the...' == Line 3383 has weird spacing: '...gorithm bul...' == 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: TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS connection during the first handshake on that channel, but MUST not be negotiated, as it provides no more protection than an unsecured connection. -- 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 316 -- Looks like a reference, but probably isn't: '1' on line 316 -- Looks like a reference, but probably isn't: '3' on line 3837 -- Looks like a reference, but probably isn't: '9' on line 352 -- Looks like a reference, but probably isn't: '2' on line 3071 -- Looks like a reference, but probably isn't: '4' on line 388 -- Looks like a reference, but probably isn't: '8' on line 389 -- Looks like a reference, but probably isn't: '10' on line 489 -- Looks like a reference, but probably isn't: '20' on line 575 -- Looks like a reference, but probably isn't: '48' on line 3393 -- Looks like a reference, but probably isn't: '32' on line 3395 == Missing Reference: 'ChangeCipherSpec' is mentioned on line 1629, but not defined -- Looks like a reference, but probably isn't: '28' on line 3067 == Missing Reference: '4366bis' is mentioned on line 2165, but not defined -- Looks like a reference, but probably isn't: '46' on line 3202 -- 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') -- Possible downref: Non-RFC (?) normative reference: ref. 'IDEA' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 3447 (ref. 'PKCS1') (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 2434 (Obsoleted by RFC 5226) == Outdated reference: draft-mcgrew-auth-enc has been published as RFC 5116 -- Obsolete informational reference (is this intentional?): RFC 4307 (ref. 'IKEALG') (Obsoleted by RFC 8247) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 1948 (ref. 'SEQNUM') (Obsoleted by RFC 6528) -- Obsolete informational reference (is this intentional?): RFC 3268 (ref. 'TLSAES') (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4492 (ref. 'TLSECC') (Obsoleted by RFC 8422) == Outdated reference: draft-ietf-tls-rfc4366-bis has been published as RFC 6066 == Outdated reference: draft-ietf-tls-openpgp-keys has been published as RFC 5081 Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 33 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Tim Dierks 3 Obsoletes (if approved): RFC 3268, 4346, 4366 Independent 4 Intended status: Proposed Standard Eric Rescorla 5 Network Resonance, Inc. 6 November 2007 (Expires May 2008) 8 The Transport Layer Security (TLS) Protocol 9 Version 1.2 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document specifies Version 1.2 of the Transport Layer Security 41 (TLS) protocol. The TLS protocol provides communications security 42 over the Internet. The protocol allows client/server applications to 43 communicate in a way that is designed to prevent eavesdropping, 44 tampering, or message forgery. 46 Table of Contents 48 1. Introduction 4 49 1.1. Requirements Terminology 5 50 1.2. Major Differences from TLS 1.1 5 51 2. Goals 6 52 3. Goals of This Document 6 53 4. Presentation Language 7 54 4.1. Basic Block Size 7 55 4.2. Miscellaneous 7 56 4.3. Vectors 8 57 4.4. Numbers 9 58 4.5. Enumerateds 9 59 4.6. Constructed Types 10 60 4.6.1. Variants 10 61 4.7. Cryptographic Attributes 11 62 4.8. Constants 13 63 5. HMAC and the Pseudorandom Function 13 64 6. The TLS Record Protocol 14 65 6.1. Connection States 15 66 6.2. Record layer 18 67 6.2.1. Fragmentation 18 68 6.2.2. Record Compression and Decompression 19 69 6.2.3. Record Payload Protection 20 70 6.2.3.1. Null or Standard Stream Cipher 21 71 6.2.3.2. CBC Block Cipher 21 72 6.2.3.3. AEAD ciphers 23 73 6.3. Key Calculation 24 74 7. The TLS Handshaking Protocols 25 75 7.1. Change Cipher Spec Protocol 26 76 7.2. Alert Protocol 27 77 7.2.1. Closure Alerts 28 78 7.2.2. Error Alerts 29 79 7.3. Handshake Protocol Overview 32 80 7.4. Handshake Protocol 35 81 7.4.1. Hello Messages 36 82 7.4.1.1. Hello Request 36 83 7.4.1.2. Client Hello 37 84 7.4.1.3. Server Hello 40 85 7.4.1.4 Hello Extensions 42 86 7.4.1.4.1 Signature Algorithms 43 87 7.4.2. Server Certificate 44 88 7.4.3. Server Key Exchange Message 47 89 7.4.4. Certificate Request 49 90 7.4.5 Server hello done 51 91 7.4.6. Client Certificate 52 92 7.4.7. Client Key Exchange Message 53 93 7.4.7.1. RSA Encrypted Premaster Secret Message 54 94 7.4.7.2. Client Diffie-Hellman Public Value 56 95 7.4.8. Certificate verify 57 96 7.4.9. Finished 58 97 8. Cryptographic Computations 59 98 8.1. Computing the Master Secret 60 99 8.1.1. RSA 60 100 8.1.2. Diffie-Hellman 60 101 9. Mandatory Cipher Suites 60 102 10. Application Data Protocol 60 103 11. Security Considerations 60 104 12. IANA Considerations 61 105 A. Protocol Constant Values 63 106 A.1. Record Layer 63 107 A.2. Change Cipher Specs Message 64 108 A.3. Alert Messages 64 109 A.4. Handshake Protocol 65 110 A.4.1. Hello Messages 65 111 A.4.2. Server Authentication and Key Exchange Messages 67 112 A.4.3. Client Authentication and Key Exchange Messages 68 113 A.4.4. Handshake Finalization Message 69 114 A.5. The CipherSuite 69 115 A.6. The Security Parameters 72 116 B. Glossary 73 117 C. CipherSuite Definitions 77 118 D. Implementation Notes 79 119 D.1 Random Number Generation and Seeding 79 120 D.2 Certificates and Authentication 79 121 D.3 CipherSuites 79 122 D.4 Implementation Pitfalls 79 123 E. Backward Compatibility 82 124 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 82 125 E.2 Compatibility with SSL 2.0 83 126 E.3. Avoiding Man-in-the-Middle Version Rollback 85 127 F. Security Analysis 86 128 F.1. Handshake Protocol 86 129 F.1.1. Authentication and Key Exchange 86 130 F.1.1.1. Anonymous Key Exchange 86 131 F.1.1.2. RSA Key Exchange and Authentication 87 132 F.1.1.3. Diffie-Hellman Key Exchange with Authentication 87 133 F.1.2. Version Rollback Attacks 88 134 F.1.3. Detecting Attacks Against the Handshake Protocol 89 135 F.1.4. Resuming Sessions 89 136 F.2. Protecting Application Data 89 137 F.3. Explicit IVs 90 138 F.4. Security of Composite Cipher Modes 90 139 F.5 Denial of Service 91 140 F.6 Final Notes 91 142 1. Introduction 144 The primary goal of the TLS Protocol is to provide privacy and data 145 integrity between two communicating applications. The protocol is 146 composed of two layers: the TLS Record Protocol and the TLS Handshake 147 Protocol. At the lowest level, layered on top of some reliable 148 transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The 149 TLS Record Protocol provides connection security that has two basic 150 properties: 152 - The connection is private. Symmetric cryptography is used for 153 data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for 154 this symmetric encryption are generated uniquely for each 155 connection and are based on a secret negotiated by another 156 protocol (such as the TLS Handshake Protocol). The Record Protocol 157 can also be used without encryption. 159 - The connection is reliable. Message transport includes a message 160 integrity check using a keyed MAC. Secure hash functions (e.g., 161 SHA, MD5, etc.) are used for MAC computations. The Record Protocol 162 can operate without a MAC, but is generally only used in this mode 163 while another protocol is using the Record Protocol as a transport 164 for negotiating security parameters. 166 The TLS Record Protocol is used for encapsulation of various higher- 167 level protocols. One such encapsulated protocol, the TLS Handshake 168 Protocol, allows the server and client to authenticate each other and 169 to negotiate an encryption algorithm and cryptographic keys before 170 the application protocol transmits or receives its first byte of 171 data. The TLS Handshake Protocol provides connection security that 172 has three basic properties: 174 - The peer's identity can be authenticated using asymmetric, or 175 public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This 176 authentication can be made optional, but is generally required for 177 at least one of the peers. 179 - The negotiation of a shared secret is secure: the negotiated 180 secret is unavailable to eavesdroppers, and for any authenticated 181 connection the secret cannot be obtained, even by an attacker who 182 can place himself in the middle of the connection. 184 - The negotiation is reliable: no attacker can modify the 185 negotiation communication without being detected by the parties to 186 the communication. 188 One advantage of TLS is that it is application protocol independent. 189 Higher-level protocols can layer on top of the TLS Protocol 190 transparently. The TLS standard, however, does not specify how 191 protocols add security with TLS; the decisions on how to initiate TLS 192 handshaking and how to interpret the authentication certificates 193 exchanged are left to the judgment of the designers and implementors 194 of protocols that run on top of TLS. 196 1.1. Requirements Terminology 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in RFC 2119 [REQ]. 202 1.2. Major Differences from TLS 1.1 204 This document is a revision of the TLS 1.1 [TLS1.1] protocol which 205 contains improved flexibility, particularly for negotiation of 206 cryptographic algorithms. The major changes are: 208 - The MD5/SHA-1 combination in the PRF has been replaced with cipher 209 suite specified PRFs. All cipher suites in this document use 210 P_SHA256. 212 - The MD5/SHA-1 combination in the digitally-signed element has been 213 replaced with a single hash. 215 - Substantial cleanup to the clients and servers ability to specify 216 which hash and signature algorithms they will accept. Note that 217 this also relaxes some of the constraints on signature and hash 218 algorithms from previous versions of TLS. 220 - Addition of support for authenticated encryption with additional 221 data modes. 223 - TLS Extensions definition and AES Cipher Suites were merged in 224 from external [TLSEXT] and [TLSAES]. 226 - Tighter checking of EncryptedPreMasterSecret version numbers. 228 - Tightened up a number of requirements. 230 - Verify_data length now depends on the cipher suite (default is 231 still 12). 233 - Cleaned up description of Bleichenbacher/Klima attack defenses. 235 - Alerts MUST now be sent in many cases. 236 - After a certificate_request, if no certificates are available, 237 clients now MUST send an empty certificate list. 239 - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement 240 cipher suite. 242 - IDEE and DES are now deprecated. 244 - Support for the SSLv2 backward-compatible hello is now a MAY, not 245 a SHOULD. This will probably become a SHOULD NOT in the future. 247 - Added an Implementation Pitfalls sections 249 - The usual clarifications and editorial work. 250 2. Goals 252 The goals of TLS Protocol, in order of their priority, are as 253 follows: 255 1. Cryptographic security: TLS should be used to establish a secure 256 connection between two parties. 258 2. Interoperability: Independent programmers should be able to 259 develop applications utilizing TLS that can successfully exchange 260 cryptographic parameters without knowledge of one another's code. 262 3. Extensibility: TLS seeks to provide a framework into which new 263 public key and bulk encryption methods can be incorporated as 264 necessary. This will also accomplish two sub-goals: preventing the 265 need to create a new protocol (and risking the introduction of 266 possible new weaknesses) and avoiding the need to implement an 267 entire new security library. 269 4. Relative efficiency: Cryptographic operations tend to be highly 270 CPU intensive, particularly public key operations. For this 271 reason, the TLS protocol has incorporated an optional session 272 caching scheme to reduce the number of connections that need to be 273 established from scratch. Additionally, care has been taken to 274 reduce network activity. 276 3. Goals of This Document 278 This document and the TLS protocol itself are based on the SSL 3.0 279 Protocol Specification as published by Netscape. The differences 280 between this protocol and SSL 3.0 are not dramatic, but they are 281 significant enough that the various versions of TLS and SSL 3.0 do 282 not interoperate (although each protocol incorporates a mechanism by 283 which an implementation can back down to prior versions). This 284 document is intended primarily for readers who will be implementing 285 the protocol and for those doing cryptographic analysis of it. The 286 specification has been written with this in mind, and it is intended 287 to reflect the needs of those two groups. For that reason, many of 288 the algorithm-dependent data structures and rules are included in the 289 body of the text (as opposed to in an appendix), providing easier 290 access to them. 292 This document is not intended to supply any details of service 293 definition or of interface definition, although it does cover select 294 areas of policy as they are required for the maintenance of solid 295 security. 297 4. Presentation Language 299 This document deals with the formatting of data in an external 300 representation. The following very basic and somewhat casually 301 defined presentation syntax will be used. The syntax draws from 302 several sources in its structure. Although it resembles the 303 programming language "C" in its syntax and XDR [XDR] in both its 304 syntax and intent, it would be risky to draw too many parallels. The 305 purpose of this presentation language is to document TLS only; it has 306 no general application beyond that particular goal. 308 4.1. Basic Block Size 310 The representation of all data items is explicitly specified. The 311 basic data block size is one byte (i.e., 8 bits). Multiple byte data 312 items are concatenations of bytes, from left to right, from top to 313 bottom. From the bytestream, a multi-byte item (a numeric in the 314 example) is formed (using C notation) by: 316 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | 317 ... | byte[n-1]; 319 This byte ordering for multi-byte values is the commonplace network 320 byte order or big endian format. 322 4.2. Miscellaneous 324 Comments begin with "/*" and end with "*/". 326 Optional components are denoted by enclosing them in "[[ ]]" double 327 brackets. 329 Single-byte entities containing uninterpreted data are of type 330 opaque. 332 4.3. Vectors 334 A vector (single dimensioned array) is a stream of homogeneous data 335 elements. The size of the vector may be specified at documentation 336 time or left unspecified until runtime. In either case, the length 337 declares the number of bytes, not the number of elements, in the 338 vector. The syntax for specifying a new type, T', that is a fixed- 339 length vector of type T is 341 T T'[n]; 343 Here, T' occupies n bytes in the data stream, where n is a multiple 344 of the size of T. The length of the vector is not included in the 345 encoded stream. 347 In the following example, Datum is defined to be three consecutive 348 bytes that the protocol does not interpret, while Data is three 349 consecutive Datum, consuming a total of nine bytes. 351 opaque Datum[3]; /* three uninterpreted bytes */ 352 Datum Data[9]; /* 3 consecutive 3 byte vectors */ 354 Variable-length vectors are defined by specifying a subrange of legal 355 lengths, inclusively, using the notation . When 356 these are encoded, the actual length precedes the vector's contents 357 in the byte stream. The length will be in the form of a number 358 consuming as many bytes as required to hold the vector's specified 359 maximum (ceiling) length. A variable-length vector with an actual 360 length field of zero is referred to as an empty vector. 362 T T'; 364 In the following example, mandatory is a vector that must contain 365 between 300 and 400 bytes of type opaque. It can never be empty. The 366 actual length field consumes two bytes, a uint16, sufficient to 367 represent the value 400 (see Section 4.4). On the other hand, longer 368 can represent up to 800 bytes of data, or 400 uint16 elements, and it 369 may be empty. Its encoding will include a two-byte actual length 370 field prepended to the vector. The length of an encoded vector must 371 be an even multiple of the length of a single element (for example, a 372 17-byte vector of uint16 would be illegal). 374 opaque mandatory<300..400>; 375 /* length field is 2 bytes, cannot be empty */ 376 uint16 longer<0..800>; 377 /* zero to 400 16-bit unsigned integers */ 379 4.4. Numbers 381 The basic numeric data type is an unsigned byte (uint8). All larger 382 numeric data types are formed from fixed-length series of bytes 383 concatenated as described in Section 4.1 and are also unsigned. The 384 following numeric types are predefined. 386 uint8 uint16[2]; 387 uint8 uint24[3]; 388 uint8 uint32[4]; 389 uint8 uint64[8]; 391 All values, here and elsewhere in the specification, are stored in 392 "network" or "big-endian" order; the uint32 represented by the hex 393 bytes 01 02 03 04 is equivalent to the decimal value 16909060. 395 Note that in some cases (e.g., DH parameters) it is necessary to 396 represent integers as opaque vectors. In such cases, they are 397 represented as unsigned integers (i.e., leading zero octets are not 398 required even if the most significant bit is set). 400 4.5. Enumerateds 402 An additional sparse data type is available called enum. A field of 403 type enum can only assume the values declared in the definition. 404 Each definition is a different type. Only enumerateds of the same 405 type may be assigned or compared. Every element of an enumerated must 406 be assigned a value, as demonstrated in the following example. Since 407 the elements of the enumerated are not ordered, they can be assigned 408 any unique value, in any order. 410 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; 412 Enumerateds occupy as much space in the byte stream as would its 413 maximal defined ordinal value. The following definition would cause 414 one byte to be used to carry fields of type Color. 416 enum { red(3), blue(5), white(7) } Color; 418 One may optionally specify a value without its associated tag to 419 force the width definition without defining a superfluous element. 420 In the following example, Taste will consume two bytes in the data 421 stream but can only assume the values 1, 2, or 4. 423 enum { sweet(1), sour(2), bitter(4), (32000) } Taste; 425 The names of the elements of an enumeration are scoped within the 426 defined type. In the first example, a fully qualified reference to 427 the second element of the enumeration would be Color.blue. Such 428 qualification is not required if the target of the assignment is well 429 specified. 431 Color color = Color.blue; /* overspecified, legal */ 432 Color color = blue; /* correct, type implicit */ 434 For enumerateds that are never converted to external representation, 435 the numerical information may be omitted. 437 enum { low, medium, high } Amount; 439 4.6. Constructed Types 441 Structure types may be constructed from primitive types for 442 convenience. Each specification declares a new, unique type. The 443 syntax for definition is much like that of C. 445 struct { 446 T1 f1; 447 T2 f2; 448 ... 449 Tn fn; 450 } [[T]]; 452 The fields within a structure may be qualified using the type's name, 453 with a syntax much like that available for enumerateds. For example, 454 T.f2 refers to the second field of the previous declaration. 455 Structure definitions may be embedded. 457 4.6.1. Variants 459 Defined structures may have variants based on some knowledge that is 460 available within the environment. The selector must be an enumerated 461 type that defines the possible variants the structure defines. There 462 must be a case arm for every element of the enumeration declared in 463 the select. The body of the variant structure may be given a label 464 for reference. The mechanism by which the variant is selected at 465 runtime is not prescribed by the presentation language. 467 struct { 468 T1 f1; 469 T2 f2; 470 .... 471 Tn fn; 472 select (E) { 473 case e1: Te1; 474 case e2: Te2; 475 .... 476 case en: Ten; 477 } [[fv]]; 478 } [[Tv]]; 480 For example: 482 enum { apple, orange } VariantTag; 483 struct { 484 uint16 number; 485 opaque string<0..10>; /* variable length */ 486 } V1; 487 struct { 488 uint32 number; 489 opaque string[10]; /* fixed length */ 490 } V2; 491 struct { 492 select (VariantTag) { /* value of selector is implicit */ 493 case apple: V1; /* VariantBody, tag = apple */ 494 case orange: V2; /* VariantBody, tag = orange */ 495 } variant_body; /* optional label on variant */ 496 } VariantRecord; 498 Variant structures may be qualified (narrowed) by specifying a value 499 for the selector prior to the type. For example, an 501 orange VariantRecord 503 is a narrowed type of a VariantRecord containing a variant_body of 504 type V2. 506 4.7. Cryptographic Attributes 508 The five cryptographic operations digital signing, stream cipher 509 encryption, block cipher encryption, authenticated encryption with 510 additional data (AEAD) encryption and public key encryption are 511 designated digitally-signed, stream-ciphered, block-ciphered, aead- 512 ciphered, and public-key-encrypted, respectively. A field's 513 cryptographic processing is specified by prepending an appropriate 514 key word designation before the field's type specification. 515 Cryptographic keys are implied by the current session state (see 516 Section 6.1). 518 In digital signing, one-way hash functions are used as input for a 519 signing algorithm. A digitally-signed element is encoded as an opaque 520 vector <0..2^16-1>, where the length is specified by the signing 521 algorithm and key. 523 In RSA signing, the opaque vector contains the signature generated 524 using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As 525 discussed in [PKCS1], the DigestInfo MUST be DER encoded and for hash 526 algorithms without parameters (which include SHA-1) the 527 DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but 528 implementations MUST accept both without parameters and with NULL 529 parameters. Note that earlier versions of TLS used a different RSA 530 signature scheme which did not include a DigestInfo encoding. 532 In DSS, the 20 bytes of the SHA-1 hash are run directly through the 533 Digital Signing Algorithm with no additional hashing. This produces 534 two values, r and s. The DSS signature is an opaque vector, as above, 535 the contents of which are the DER encoding of: 537 Dss-Sig-Value ::= SEQUENCE { 538 r INTEGER, 539 s INTEGER 540 } 542 Note: In current terminology, DSA refers to the Digital Signature 543 Algorithm and DSS refers to the NIST standard. For historical 544 reasons, this document uses DSS and DSA interchangeably 545 to refer to the DSA algorithm, as was done in SSLv3. 547 In stream cipher encryption, the plaintext is exclusive-ORed with an 548 identical amount of output generated from a cryptographically secure 549 keyed pseudorandom number generator. 551 In block cipher encryption, every block of plaintext encrypts to a 552 block of ciphertext. All block cipher encryption is done in CBC 553 (Cipher Block Chaining) mode, and all items that are block-ciphered 554 will be an exact multiple of the cipher block length. 556 In AEAD encryption, the plaintext is simultaneously encrypted and 557 integrity protected. The input may be of any length and aead-ciphered 558 output is generally larger than the input in order to accomodate the 559 integrity check value. 561 In public key encryption, a public key algorithm is used to encrypt 562 data in such a way that it can be decrypted only with the matching 563 private key. A public-key-encrypted element is encoded as an opaque 564 vector <0..2^16-1>, where the length is specified by the encryption 565 algorithm and key. 567 RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme 568 defined in [PKCS1]. 570 In the following example 572 stream-ciphered struct { 573 uint8 field1; 574 uint8 field2; 575 digitally-signed opaque hash[20]; 576 } UserType; 578 the contents of hash are used as input for the signing algorithm, and 579 then the entire structure is encrypted with a stream cipher. The 580 length of this structure, in bytes, would be equal to two bytes for 581 field1 and field2, plus two bytes for the length of the signature, 582 plus the length of the output of the signing algorithm. This is known 583 because the algorithm and key used for the signing are known prior to 584 encoding or decoding this structure. 586 4.8. Constants 588 Typed constants can be defined for purposes of specification by 589 declaring a symbol of the desired type and assigning values to it. 590 Under-specified types (opaque, variable length vectors, and 591 structures that contain opaque) cannot be assigned values. No fields 592 of a multi-element structure or vector may be elided. 594 For example: 596 struct { 597 uint8 f1; 598 uint8 f2; 599 } Example1; 601 Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */ 603 5. HMAC and the Pseudorandom Function 605 The TLS record layer uses a keyed Message Authentication Code (MAC) 606 to protect message integrity. The cipher suites defined in this 607 document use a construction known as HMAC, described in [HMAC], which 608 is based on a hash function. Other cipher suites MAY define their own 609 MAC constructions, if needed. 611 In addition, a construction is required to do expansion of secrets 612 into blocks of data for the purposes of key generation or validation. 613 This pseudo-random function (PRF) takes as input a secret, a seed, 614 and an identifying label and produces an output of arbitrary length. 616 In this section, we define one PRF, based on HMAC. This PRF with the 617 SHA-256 hash function is used for all cipher suites defined in this 618 document and in TLS documents published prior to this document when 619 TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a 620 PRF and in general SHOULD use the TLS PRF with SHA-256 or a stronger 621 standard hash function. 623 First, we define a data expansion function, P_hash(secret, data) that 624 uses a single hash function to expand a secret and seed into an 625 arbitrary quantity of output: 627 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + 628 HMAC_hash(secret, A(2) + seed) + 629 HMAC_hash(secret, A(3) + seed) + ... 631 Where + indicates concatenation. 633 A() is defined as: 635 A(0) = seed 636 A(i) = HMAC_hash(secret, A(i-1)) 638 P_hash can be iterated as many times as is necessary to produce the 639 required quantity of data. For example, if P_SHA-1 is being used to 640 create 64 bytes of data, it will have to be iterated 4 times (through 641 A(4)), creating 80 bytes of output data; the last 16 bytes of the 642 final iteration will then be discarded, leaving 64 bytes of output 643 data. 645 TLS's PRF is created by applying P_hash to the secret as: 647 PRF(secret, label, seed) = P_(secret, label + seed) 649 The label is an ASCII string. It should be included in the exact form 650 it is given without a length byte or trailing null character. For 651 example, the label "slithy toves" would be processed by hashing the 652 following bytes: 654 73 6C 69 74 68 79 20 74 6F 76 65 73 656 6. The TLS Record Protocol 658 The TLS Record Protocol is a layered protocol. At each layer, 659 messages may include fields for length, description, and content. 660 The Record Protocol takes messages to be transmitted, fragments the 661 data into manageable blocks, optionally compresses the data, applies 662 a MAC, encrypts, and transmits the result. Received data is 663 decrypted, verified, decompressed, reassembled, and then delivered to 664 higher-level clients. 666 Four record protocol clients are described in this document: the 667 handshake protocol, the alert protocol, the change cipher spec 668 protocol, and the application data protocol. In order to allow 669 extension of the TLS protocol, additional record types can be 670 supported by the record protocol. New record type values are assigned 671 by IANA as described in Section 12. 673 Implementations MUST NOT send record types not defined in this 674 document unless negotiated by some extension. If a TLS 675 implementation receives an unexpected record type, it MUST send an 676 unexpected_message alert. 678 Any protocol designed for use over TLS MUST be carefully designed to 679 deal with all possible attacks against it. Note that because the 680 type and length of a record are not protected by encryption, care 681 SHOULD be taken to minimize the value of traffic analysis of these 682 values. 684 6.1. Connection States 686 A TLS connection state is the operating environment of the TLS Record 687 Protocol. It specifies a compression algorithm, an encryption 688 algorithm, and a MAC algorithm. In addition, the parameters for these 689 algorithms are known: the MAC key and the bulk encryption keys for 690 the connection in both the read and the write directions. Logically, 691 there are always four connection states outstanding: the current read 692 and write states, and the pending read and write states. All records 693 are processed under the current read and write states. The security 694 parameters for the pending states can be set by the TLS Handshake 695 Protocol, and the Change Cipher Spec can selectively make either of 696 the pending states current, in which case the appropriate current 697 state is disposed of and replaced with the pending state; the pending 698 state is then reinitialized to an empty state. It is illegal to make 699 a state that has not been initialized with security parameters a 700 current state. The initial current state always specifies that no 701 encryption, compression, or MAC will be used. 703 The security parameters for a TLS Connection read and write state are 704 set by providing the following values: 706 connection end 707 Whether this entity is considered the "client" or the "server" in 708 this connection. 710 PRF algorithm 711 An algorithm used to generate keys from the master secret (see 712 Sections 5 and 6.3). 714 bulk encryption algorithm 715 An algorithm to be used for bulk encryption. This specification 716 includes the key size of this algorithm, whether it is a block, 717 stream, or AEAD cipher, the block size of the cipher (if 718 appropriate), and the lengths of explicit and implicit 719 initialization vectors (or nonces). 721 MAC algorithm 722 An algorithm to be used for message authentication. This 723 specification includes the size of the value returned by the MAC 724 algorithm. 726 compression algorithm 727 An algorithm to be used for data compression. This specification 728 must include all information the algorithm requires to do 729 compression. 731 master secret 732 A 48-byte secret shared between the two peers in the connection. 734 client random 735 A 32-byte value provided by the client. 737 server random 738 A 32-byte value provided by the server. 740 These parameters are defined in the presentation language as: 742 enum { server, client } ConnectionEnd; 744 enum { tls_prf_sha256 } PRFAlgorithm; 746 enum { null, rc4, 3des, aes } 747 BulkCipherAlgorithm; 749 enum { stream, block, aead } CipherType; 751 enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384, 752 hmac_sha512} MACAlgorithm; 754 /* The use of "sha" above is historical and denotes SHA-1 */ 756 enum { null(0), (255) } CompressionMethod; 757 /* The algorithms specified in CompressionMethod, 758 BulkCipherAlgorithm, and MACAlgorithm may be added to. */ 760 struct { 761 ConnectionEnd entity; 762 PRFAlgorithm prf_algorithm; 763 BulkCipherAlgorithm bulk_cipher_algorithm; 764 CipherType cipher_type; 765 uint8 enc_key_length; 766 uint8 block_length; 767 uint8 fixed_iv_length; 768 uint8 record_iv_length; 769 MACAlgorithm mac_algorithm; 770 uint8 mac_length; 771 uint8 mac_key_length; 772 CompressionMethod compression_algorithm; 773 opaque master_secret[48]; 774 opaque client_random[32]; 775 opaque server_random[32]; 776 } SecurityParameters; 778 The record layer will use the security parameters to generate the 779 following six items (some of which are not required by all ciphers, 780 and are thus empty): 782 client write MAC key 783 server write MAC key 784 client write encryption key 785 server write encryption key 786 client write IV 787 server write IV 789 The client write parameters are used by the server when receiving and 790 processing records and vice-versa. The algorithm used for generating 791 these items from the security parameters is described in Section 6.3. 793 Once the security parameters have been set and the keys have been 794 generated, the connection states can be instantiated by making them 795 the current states. These current states MUST be updated for each 796 record processed. Each connection state includes the following 797 elements: 799 compression state 800 The current state of the compression algorithm. 802 cipher state 803 The current state of the encryption algorithm. This will consist 804 of the scheduled key for that connection. For stream ciphers, this 805 will also contain whatever state information is necessary to allow 806 the stream to continue to encrypt or decrypt data. 808 MAC key 809 The MAC key for this connection, as generated above. 811 sequence number 812 Each connection state contains a sequence number, which is 813 maintained separately for read and write states. The sequence 814 number MUST be set to zero whenever a connection state is made the 815 active state. Sequence numbers are of type uint64 and may not 816 exceed 2^64-1. Sequence numbers do not wrap. If a TLS 817 implementation would need to wrap a sequence number, it must 818 renegotiate instead. A sequence number is incremented after each 819 record: specifically, the first record transmitted under a 820 particular connection state MUST use sequence number 0. 822 6.2. Record layer 824 The TLS Record Layer receives uninterpreted data from higher layers 825 in non-empty blocks of arbitrary size. 827 6.2.1. Fragmentation 829 The record layer fragments information blocks into TLSPlaintext 830 records carrying data in chunks of 2^14 bytes or less. Client message 831 boundaries are not preserved in the record layer (i.e., multiple 832 client messages of the same ContentType MAY be coalesced into a 833 single TLSPlaintext record, or a single message MAY be fragmented 834 across several records). 836 struct { 837 uint8 major, minor; 838 } ProtocolVersion; 840 enum { 841 change_cipher_spec(20), alert(21), handshake(22), 842 application_data(23), (255) 843 } ContentType; 845 struct { 846 ContentType type; 847 ProtocolVersion version; 848 uint16 length; 849 opaque fragment[TLSPlaintext.length]; 850 } TLSPlaintext; 852 type 853 The higher-level protocol used to process the enclosed fragment. 855 version 856 The version of the protocol being employed. This document 857 describes TLS Version 1.2, which uses the version { 3, 3 }. The 858 version value 3.3 is historical, deriving from the use of 3.1 for 859 TLS 1.0. (See Appendix A.1). Note that a client that supports 860 multiple versions of TLS may not know what version will be 861 employed before it receives ServerHello. See Appendix E for 862 discussion about what record layer version number should be 863 employed for ClientHello. 865 length 866 The length (in bytes) of the following TLSPlaintext.fragment. The 867 length MUST NOT exceed 2^14. 869 fragment 870 The application data. This data is transparent and treated as an 871 independent block to be dealt with by the higher-level protocol 872 specified by the type field. 874 Implementations MUST NOT send zero-length fragments of Handshake, 875 Alert, or Change Cipher Spec content types. Zero-length fragments of 876 Application data MAY be sent as they are potentially useful as a 877 traffic analysis countermeasure. 879 Note: Data of different TLS Record layer content types MAY be 880 interleaved. Application data is generally of lower precedence for 881 transmission than other content types. However, records MUST be 882 delivered to the network in the same order as they are protected by 883 the record layer. Recipients MUST receive and process interleaved 884 application layer traffic during handshakes subsequent to the first 885 one on a connection. 887 6.2.2. Record Compression and Decompression 889 All records are compressed using the compression algorithm defined in 890 the current session state. There is always an active compression 891 algorithm; however, initially it is defined as 892 CompressionMethod.null. The compression algorithm translates a 893 TLSPlaintext structure into a TLSCompressed structure. Compression 894 functions are initialized with default state information whenever a 895 connection state is made active. 897 Compression must be lossless and may not increase the content length 898 by more than 1024 bytes. If the decompression function encounters a 899 TLSCompressed.fragment that would decompress to a length in excess of 900 2^14 bytes, it MUST report a fatal decompression failure error. 902 struct { 903 ContentType type; /* same as TLSPlaintext.type */ 904 ProtocolVersion version;/* same as TLSPlaintext.version */ 905 uint16 length; 906 opaque fragment[TLSCompressed.length]; 907 } TLSCompressed; 909 length 910 The length (in bytes) of the following TLSCompressed.fragment. 911 The length MUST NOT exceed 2^14 + 1024. 913 fragment 914 The compressed form of TLSPlaintext.fragment. 916 Note: A CompressionMethod.null operation is an identity operation; no 917 fields are altered. 919 Implementation note: Decompression functions are responsible for 920 ensuring that messages cannot cause internal buffer overflows. 922 6.2.3. Record Payload Protection 924 The encryption and MAC functions translate a TLSCompressed structure 925 into a TLSCiphertext. The decryption functions reverse the process. 926 The MAC of the record also includes a sequence number so that 927 missing, extra, or repeated messages are detectable. 929 struct { 930 ContentType type; 931 ProtocolVersion version; 932 uint16 length; 933 select (SecurityParameters.cipher_type) { 934 case stream: GenericStreamCipher; 935 case block: GenericBlockCipher; 936 case aead: GenericAEADCipher; 937 } fragment; 938 } TLSCiphertext; 940 type 941 The type field is identical to TLSCompressed.type. 943 version 944 The version field is identical to TLSCompressed.version. 946 length 947 The length (in bytes) of the following TLSCiphertext.fragment. 948 The length MUST NOT exceed 2^14 + 2048. 950 fragment 951 The encrypted form of TLSCompressed.fragment, with the MAC. 953 6.2.3.1. Null or Standard Stream Cipher 955 Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6) 956 convert TLSCompressed.fragment structures to and from stream 957 TLSCiphertext.fragment structures. 959 stream-ciphered struct { 960 opaque content[TLSCompressed.length]; 961 opaque MAC[SecurityParameters.mac_length]; 962 } GenericStreamCipher; 964 The MAC is generated as: 966 MAC(MAC_write_secret, seq_num + 967 TLSCompressed.type + 968 TLSCompressed.version + 969 TLSCompressed.length + 970 TLSCompressed.fragment); 972 where "+" denotes concatenation. 974 seq_num 975 The sequence number for this record. 977 MAC 978 The MAC algorithm specified by SecurityParameters.mac_algorithm. 980 Note that the MAC is computed before encryption. The stream cipher 981 encrypts the entire block, including the MAC. For stream ciphers that 982 do not use a synchronization vector (such as RC4), the stream cipher 983 state from the end of one record is simply used on the subsequent 984 packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption 985 consists of the identity operation (i.e., the data is not encrypted, 986 and the MAC size is zero, implying that no MAC is used). 987 TLSCiphertext.length is TLSCompressed.length plus 988 SecurityParameters.mac_length. 990 6.2.3.2. CBC Block Cipher 992 For block ciphers (such as 3DES, or AES), the encryption and MAC 993 functions convert TLSCompressed.fragment structures to and from block 994 TLSCiphertext.fragment structures. 996 struct { 997 opaque IV[SecurityParameters.record_iv_length]; 998 block-ciphered struct { 999 opaque content[TLSCompressed.length]; 1000 opaque MAC[SecurityParameters.mac_length]; 1001 uint8 padding[GenericBlockCipher.padding_length]; 1002 uint8 padding_length; 1003 }; 1004 } GenericBlockCipher; 1006 The MAC is generated as described in Section 6.2.3.1. 1008 IV 1009 The Initialization Vector (IV) SHOULD be chosen at random, and 1010 MUST be unpredictable. Note that in versions of TLS prior to 1.1, 1011 there was no IV field, and the last ciphertext block of the 1012 previous record (the "CBC residue") was used as the IV. This was 1013 changed to prevent the attacks described in [CBCATT]. For block 1014 ciphers, the IV length is of length 1015 SecurityParameters.record_iv_length which is equal to the 1016 SecurityParameters.block_size. 1018 padding 1019 Padding that is added to force the length of the plaintext to be 1020 an integral multiple of the block cipher's block length. The 1021 padding MAY be any length up to 255 bytes, as long as it results 1022 in the TLSCiphertext.length being an integral multiple of the 1023 block length. Lengths longer than necessary might be desirable to 1024 frustrate attacks on a protocol that are based on analysis of the 1025 lengths of exchanged messages. Each uint8 in the padding data 1026 vector MUST be filled with the padding length value. The receiver 1027 MUST check this padding and MUST use the bad_record_mac alert to 1028 indicate padding errors. 1030 padding_length 1031 The padding length MUST be such that the total size of the 1032 GenericBlockCipher structure is a multiple of the cipher's block 1033 length. Legal values range from zero to 255, inclusive. This 1034 length specifies the length of the padding field exclusive of the 1035 padding_length field itself. 1037 The encrypted data length (TLSCiphertext.length) is one more than the 1038 sum of SecurityParameters.block_length, TLSCompressed.length, 1039 SecurityParameters.mac_length, and padding_length. 1041 Example: If the block length is 8 bytes, the content length 1042 (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, 1043 then the length before padding is 82 bytes (this does not include the 1044 IV. Thus, the padding length modulo 8 must be equal to 6 in order to 1045 make the total length an even multiple of 8 bytes (the block length). 1046 The padding length can be 6, 14, 22, and so on, through 254. If the 1047 padding length were the minimum necessary, 6, the padding would be 6 1048 bytes, each containing the value 6. Thus, the last 8 octets of the 1049 GenericBlockCipher before block encryption would be xx 06 06 06 06 06 1050 06 06, where xx is the last octet of the MAC. 1052 Note: With block ciphers in CBC mode (Cipher Block Chaining), it is 1053 critical that the entire plaintext of the record be known before any 1054 ciphertext is transmitted. Otherwise, it is possible for the attacker 1055 to mount the attack described in [CBCATT]. 1057 Implementation Note: Canvel et al. [CBCTIME] have demonstrated a 1058 timing attack on CBC padding based on the time required to compute 1059 the MAC. In order to defend against this attack, implementations MUST 1060 ensure that record processing time is essentially the same whether or 1061 not the padding is correct. In general, the best way to do this is 1062 to compute the MAC even if the padding is incorrect, and only then 1063 reject the packet. For instance, if the pad appears to be incorrect, 1064 the implementation might assume a zero-length pad and then compute 1065 the MAC. This leaves a small timing channel, since MAC performance 1066 depends to some extent on the size of the data fragment, but it is 1067 not believed to be large enough to be exploitable, due to the large 1068 block size of existing MACs and the small size of the timing signal. 1070 6.2.3.3. AEAD ciphers 1072 For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function 1073 converts TLSCompressed.fragment structures to and from AEAD 1074 TLSCiphertext.fragment structures. 1076 struct { 1077 opaque nonce_explicit[SecurityParameters.record_iv_length]; 1078 aead-ciphered struct { 1079 opaque content[TLSCompressed.length]; 1080 }; 1081 } GenericAEADCipher; 1083 AEAD ciphers take as input a single key, a nonce, a plaintext, and 1084 "additional data" to be included in the authentication check, as 1085 described in Section 2.1 of [AEAD]. The key is either the 1086 client_write_key or the server_write_key. No MAC key is used. 1088 Each AEAD cipher suite MUST specify how the nonce supplied to the 1089 AEAD operation is constructed, and what is the length of the 1090 GenericAEADCipher.nonce_explicit part. In many cases, it is 1091 appropriate to use the partially implicit nonce technique described 1092 in Section 3.2.1 of [AEAD]; with record_iv_length being the length of 1093 the explicit part. In this case, the implicit part SHOULD be derived 1094 from key_block as client_write_iv and server_write_iv (as described 1095 in Section 6.3), and the explicit part is included in 1096 GenericAEAEDCipher.nonce_explicit. 1098 The plaintext is the TLSCompressed.fragment. 1100 The additional authenticated data, which we denote as 1101 additional_data, is defined as follows: 1103 additional_data = seq_num + TLSCompressed.type + 1104 TLSCompressed.version + TLSCompressed.length; 1106 Where "+" denotes concatenation. 1108 The aead_output consists of the ciphertext output by the AEAD 1109 encryption operation. The length will generally be larger than 1110 TLSCompressed.length, but by an amount that varies with the AEAD 1111 cipher. Since the ciphers might incorporate padding, the amount of 1112 overhead could vary with different TLSCompressed.length values. Each 1113 AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. 1114 Symbolically, 1116 AEADEncrypted = AEAD-Encrypt(key, IV, plaintext, 1117 additional_data) 1119 In order to decrypt and verify, the cipher takes as input the key, 1120 IV, the "additional_data", and the AEADEncrypted value. The output is 1121 either the plaintext or an error indicating that the decryption 1122 failed. There is no separate integrity check. I.e., 1124 TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, 1125 AEADEncrypted, 1126 additional_data) 1128 If the decryption fails, a fatal bad_record_mac alert MUST be 1129 generated. 1131 6.3. Key Calculation 1133 The Record Protocol requires an algorithm to generates keys required 1134 by the current connection state (see Appendix A.6) from the security 1135 parameters provided by the handshake protocol. 1137 The master secret is expanded into a sequence of secure bytes, which 1138 is then split to a client write MAC key, a server write MAC key, a 1139 client write encryption key, and a server write encryption key. Each 1140 of these is generated from the byte sequence in that order. Unused 1141 values are empty. Some AEAD ciphers may additionally require a 1142 client write IV and a server write IV (see Section 6.2.3.3). 1144 When keys and MAC keys are generated, the master secret is used as an 1145 entropy source. 1147 To generate the key material, compute 1149 key_block = PRF(SecurityParameters.master_secret, 1150 "key expansion", 1151 SecurityParameters.server_random + 1152 SecurityParameters.client_random); 1154 until enough output has been generated. Then the key_block is 1155 partitioned as follows: 1157 client_write_MAC_key[SecurityParameters.mac_key_length] 1158 server_write_MAC_key[SecurityParameters.mac_key_length] 1159 client_write_key[SecurityParameters.enc_key_length] 1160 server_write_key[SecurityParameters.enc_key_length] 1161 client_write_IV[SecurityParameters.fixed_iv_length] 1162 server_write_IV[SecurityParameters.fixed_iv_length] 1164 The client_write_IV and server_write_IV are only generated for 1165 implicit nonce techniques as described in Section 3.2.1 of [AEAD]. 1167 Implementation note: The currently defined cipher suite which 1168 requires the most material is AES_256_CBC_SHA. It requires 2 x 32 1169 byte keys and 2 x 20 byte MAC keys, for a total 104 bytes of key 1170 material. 1172 7. The TLS Handshaking Protocols 1174 TLS has three subprotocols that are used to allow peers to agree upon 1175 security parameters for the record layer, to authenticate themselves, 1176 to instantiate negotiated security parameters, and to report error 1177 conditions to each other. 1179 The Handshake Protocol is responsible for negotiating a session, 1180 which consists of the following items: 1182 session identifier 1183 An arbitrary byte sequence chosen by the server to identify an 1184 active or resumable session state. 1186 peer certificate 1187 X509v3 [PKIX] certificate of the peer. This element of the state 1188 may be null. 1190 compression method 1191 The algorithm used to compress data prior to encryption. 1193 cipher spec 1194 Specifies the bulk data encryption algorithm (such as null, DES, 1195 etc.) and a MAC algorithm (such as MD5 or SHA). It also defines 1196 cryptographic attributes such as the mac_length. (See Appendix A.6 1197 for formal definition.) 1199 master secret 1200 48-byte secret shared between the client and server. 1202 is resumable 1203 A flag indicating whether the session can be used to initiate new 1204 connections. 1206 These items are then used to create security parameters for use by 1207 the Record Layer when protecting application data. Many connections 1208 can be instantiated using the same session through the resumption 1209 feature of the TLS Handshake Protocol. 1211 7.1. Change Cipher Spec Protocol 1213 The change cipher spec protocol exists to signal transitions in 1214 ciphering strategies. The protocol consists of a single message, 1215 which is encrypted and compressed under the current (not the pending) 1216 connection state. The message consists of a single byte of value 1. 1218 struct { 1219 enum { change_cipher_spec(1), (255) } type; 1220 } ChangeCipherSpec; 1222 The change cipher spec message is sent by both the client and the 1223 server to notify the receiving party that subsequent records will be 1224 protected under the newly negotiated CipherSpec and keys. Reception 1225 of this message causes the receiver to instruct the Record Layer to 1226 immediately copy the read pending state into the read current state. 1227 Immediately after sending this message, the sender MUST instruct the 1228 record layer to make the write pending state the write active state. 1229 (See Section 6.1.) The change cipher spec message is sent during the 1230 handshake after the security parameters have been agreed upon, but 1231 before the verifying finished message is sent. 1233 Note: If a rehandshake occurs while data is flowing on a connection, 1234 the communicating parties may continue to send data using the old 1235 CipherSpec. However, once the ChangeCipherSpec has been sent, the new 1236 CipherSpec MUST be used. The first side to send the ChangeCipherSpec 1237 does not know that the other side has finished computing the new 1238 keying material (e.g., if it has to perform a time consuming public 1239 key operation). Thus, a small window of time, during which the 1240 recipient must buffer the data, MAY exist. In practice, with modern 1241 machines this interval is likely to be fairly short. 1243 7.2. Alert Protocol 1245 One of the content types supported by the TLS Record layer is the 1246 alert type. Alert messages convey the severity of the message and a 1247 description of the alert. Alert messages with a level of fatal result 1248 in the immediate termination of the connection. In this case, other 1249 connections corresponding to the session may continue, but the 1250 session identifier MUST be invalidated, preventing the failed session 1251 from being used to establish new connections. Like other messages, 1252 alert messages are encrypted and compressed, as specified by the 1253 current connection state. 1255 enum { warning(1), fatal(2), (255) } AlertLevel; 1257 enum { 1258 close_notify(0), 1259 unexpected_message(10), 1260 bad_record_mac(20), 1261 decryption_failed_RESERVED(21), 1262 record_overflow(22), 1263 decompression_failure(30), 1264 handshake_failure(40), 1265 no_certificate_RESERVED(41), 1266 bad_certificate(42), 1267 unsupported_certificate(43), 1268 certificate_revoked(44), 1269 certificate_expired(45), 1270 certificate_unknown(46), 1271 illegal_parameter(47), 1272 unknown_ca(48), 1273 access_denied(49), 1274 decode_error(50), 1275 decrypt_error(51), 1276 export_restriction_RESERVED(60), 1277 protocol_version(70), 1278 insufficient_security(71), 1279 internal_error(80), 1280 user_canceled(90), 1281 no_renegotiation(100), 1282 unsupported_extension(110), 1283 (255) 1284 } AlertDescription; 1286 struct { 1287 AlertLevel level; 1288 AlertDescription description; 1289 } Alert; 1291 7.2.1. Closure Alerts 1293 The client and the server must share knowledge that the connection is 1294 ending in order to avoid a truncation attack. Either party may 1295 initiate the exchange of closing messages. 1297 close_notify 1298 This message notifies the recipient that the sender will not send 1299 any more messages on this connection. Note that as of TLS 1.1, 1300 failure to properly close a connection no longer requires that a 1301 session not be resumed. This is a change from TLS 1.0 to conform 1302 with widespread implementation practice. 1304 Either party may initiate a close by sending a close_notify alert. 1305 Any data received after a closure alert is ignored. 1307 Unless some other fatal alert has been transmitted, each party is 1308 required to send a close_notify alert before closing the write side 1309 of the connection. The other party MUST respond with a close_notify 1310 alert of its own and close down the connection immediately, 1311 discarding any pending writes. It is not required for the initiator 1312 of the close to wait for the responding close_notify alert before 1313 closing the read side of the connection. 1315 If the application protocol using TLS provides that any data may be 1316 carried over the underlying transport after the TLS connection is 1317 closed, the TLS implementation must receive the responding 1318 close_notify alert before indicating to the application layer that 1319 the TLS connection has ended. If the application protocol will not 1320 transfer any additional data, but will only close the underlying 1321 transport connection, then the implementation MAY choose to close the 1322 transport without waiting for the responding close_notify. No part of 1323 this standard should be taken to dictate the manner in which a usage 1324 profile for TLS manages its data transport, including when 1325 connections are opened or closed. 1327 Note: It is assumed that closing a connection reliably delivers 1328 pending data before destroying the transport. 1330 7.2.2. Error Alerts 1332 Error handling in the TLS Handshake protocol is very simple. When an 1333 error is detected, the detecting party sends a message to the other 1334 party. Upon transmission or receipt of a fatal alert message, both 1335 parties immediately close the connection. Servers and clients MUST 1336 forget any session-identifiers, keys, and secrets associated with a 1337 failed connection. Thus, any connection terminated with a fatal alert 1338 MUST NOT be resumed. 1340 Whenever an implementation encounters a condition which is defined as 1341 a fatal alert, it MUST send the appropriate alert prior to closing 1342 the connection. In cases where an implementation chooses to send an 1343 alert which may be a warning alert but intends to close the 1344 connection immediately afterwards, it MUST send that alert at the 1345 fatal alert level. 1347 If an alert with a level of warning is sent and received, generally 1348 the connection can continue normally. If the receiving party decides 1349 not to proceed with the connection (e.g., after having received a 1350 no_renegotiation alert that it is not willing to accept), it SHOULD 1351 send a fatal alert to terminate the connection. 1353 The following error alerts are defined: 1355 unexpected_message 1356 An inappropriate message was received. This alert is always fatal 1357 and should never be observed in communication between proper 1358 implementations. 1360 bad_record_mac 1361 This alert is returned if a record is received with an incorrect 1362 MAC. This alert also MUST be returned if an alert is sent because 1363 a TLSCiphertext decrypted in an invalid way: either it wasn't an 1364 even multiple of the block length, or its padding values, when 1365 checked, weren't correct. This message is always fatal. 1367 decryption_failed_RESERVED 1368 This alert was used in some earlier versions of TLS, and may have 1369 permitted certain attacks against the CBC mode [CBCATT]. It MUST 1370 NOT be sent by compliant implementations. 1372 record_overflow 1373 A TLSCiphertext record was received that had a length more than 1374 2^14+2048 bytes, or a record decrypted to a TLSCompressed record 1375 with more than 2^14+1024 bytes. This message is always fatal. 1377 decompression_failure 1378 The decompression function received improper input (e.g., data 1379 that would expand to excessive length). This message is always 1380 fatal. 1382 handshake_failure 1383 Reception of a handshake_failure alert message indicates that the 1384 sender was unable to negotiate an acceptable set of security 1385 parameters given the options available. This is a fatal error. 1387 no_certificate_RESERVED 1388 This alert was used in SSLv3 but not any version of TLS. It MUST 1389 NOT be sent by compliant implementations. 1391 bad_certificate 1392 A certificate was corrupt, contained signatures that did not 1393 verify correctly, etc. 1395 unsupported_certificate 1396 A certificate was of an unsupported type. 1398 certificate_revoked 1399 A certificate was revoked by its signer. 1401 certificate_expired 1402 A certificate has expired or is not currently valid. 1404 certificate_unknown 1405 Some other (unspecified) issue arose in processing the 1406 certificate, rendering it unacceptable. 1408 illegal_parameter 1409 A field in the handshake was out of range or inconsistent with 1410 other fields. This message is always fatal. 1412 unknown_ca 1413 A valid certificate chain or partial chain was received, but the 1414 certificate was not accepted because the CA certificate could not 1415 be located or couldn't be matched with a known, trusted CA. This 1416 message is always fatal. 1418 access_denied 1419 A valid certificate was received, but when access control was 1420 applied, the sender decided not to proceed with negotiation. This 1421 message is always fatal. 1423 decode_error 1424 A message could not be decoded because some field was out of the 1425 specified range or the length of the message was incorrect. This 1426 message is always fatal. 1428 decrypt_error 1429 A handshake cryptographic operation failed, including being unable 1430 to correctly verify a signature, decrypt a key exchange, or 1431 validate a finished message. 1433 export_restriction_RESERVED 1434 This alert was used in some earlier versions of TLS. It MUST NOT 1435 be sent by compliant implementations. 1437 protocol_version 1438 The protocol version the client has attempted to negotiate is 1439 recognized but not supported. (For example, old protocol versions 1440 might be avoided for security reasons). This message is always 1441 fatal. 1443 insufficient_security 1444 Returned instead of handshake_failure when a negotiation has 1445 failed specifically because the server requires ciphers more 1446 secure than those supported by the client. This message is always 1447 fatal. 1449 internal_error 1450 An internal error unrelated to the peer or the correctness of the 1451 protocol (such as a memory allocation failure) makes it impossible 1452 to continue. This message is always fatal. 1454 user_canceled 1455 This handshake is being canceled for some reason unrelated to a 1456 protocol failure. If the user cancels an operation after the 1457 handshake is complete, just closing the connection by sending a 1458 close_notify is more appropriate. This alert should be followed by 1459 a close_notify. This message is generally a warning. 1461 no_renegotiation 1462 Sent by the client in response to a hello request or by the server 1463 in response to a client hello after initial handshaking. Either 1464 of these would normally lead to renegotiation; when that is not 1465 appropriate, the recipient should respond with this alert. At 1466 that point, the original requester can decide whether to proceed 1467 with the connection. One case where this would be appropriate is 1468 where a server has spawned a process to satisfy a request; the 1469 process might receive security parameters (key length, 1470 authentication, etc.) at startup and it might be difficult to 1471 communicate changes to these parameters after that point. This 1472 message is always a warning. 1474 unsupported_extension 1475 sent by clients that receive an extended server hello containing 1476 an extension that they did not put in the corresponding client 1477 hello. This message is always fatal. 1479 For all errors where an alert level is not explicitly specified, the 1480 sending party MAY determine at its discretion whether this is a fatal 1481 error or not; if an alert with a level of warning is received, the 1482 receiving party MAY decide at its discretion whether to treat this as 1483 a fatal error or not. However, all messages that are transmitted 1484 with a level of fatal MUST be treated as fatal messages. 1486 New Alert values are assigned by IANA as described in Section 12. 1488 7.3. Handshake Protocol Overview 1490 The cryptographic parameters of the session state are produced by the 1491 TLS Handshake Protocol, which operates on top of the TLS Record 1492 Layer. When a TLS client and server first start communicating, they 1493 agree on a protocol version, select cryptographic algorithms, 1494 optionally authenticate each other, and use public-key encryption 1495 techniques to generate shared secrets. 1497 The TLS Handshake Protocol involves the following steps: 1499 - Exchange hello messages to agree on algorithms, exchange random 1500 values, and check for session resumption. 1502 - Exchange the necessary cryptographic parameters to allow the 1503 client and server to agree on a premaster secret. 1505 - Exchange certificates and cryptographic information to allow the 1506 client and server to authenticate themselves. 1508 - Generate a master secret from the premaster secret and exchanged 1509 random values. 1511 - Provide security parameters to the record layer. 1513 - Allow the client and server to verify that their peer has 1514 calculated the same security parameters and that the handshake 1515 occurred without tampering by an attacker. 1517 Note that higher layers should not be overly reliant on whether TLS 1518 always negotiates the strongest possible connection between two 1519 peers. There are a number of ways in which a man in the middle 1520 attacker can attempt to make two entities drop down to the least 1521 secure method they support. The protocol has been designed to 1522 minimize this risk, but there are still attacks available: for 1523 example, an attacker could block access to the port a secure service 1524 runs on, or attempt to get the peers to negotiate an unauthenticated 1525 connection. The fundamental rule is that higher levels must be 1526 cognizant of what their security requirements are and never transmit 1527 information over a channel less secure than what they require. The 1528 TLS protocol is secure in that any cipher suite offers its promised 1529 level of security: if you negotiate 3DES with a 1024 bit RSA key 1530 exchange with a host whose certificate you have verified, you can 1531 expect to be that secure. 1533 These goals are achieved by the handshake protocol, which can be 1534 summarized as follows: The client sends a client hello message to 1535 which the server must respond with a server hello message, or else a 1536 fatal error will occur and the connection will fail. The client hello 1537 and server hello are used to establish security enhancement 1538 capabilities between client and server. The client hello and server 1539 hello establish the following attributes: Protocol Version, Session 1540 ID, Cipher Suite, and Compression Method. Additionally, two random 1541 values are generated and exchanged: ClientHello.random and 1542 ServerHello.random. 1544 The actual key exchange uses up to four messages: the server 1545 certificate, the server key exchange, the client certificate, and the 1546 client key exchange. New key exchange methods can be created by 1547 specifying a format for these messages and by defining the use of the 1548 messages to allow the client and server to agree upon a shared 1549 secret. This secret MUST be quite long; currently defined key 1550 exchange methods exchange secrets that range from 46 bytes upwards. 1552 Following the hello messages, the server will send its certificate, 1553 if it is to be authenticated. Additionally, a server key exchange 1554 message may be sent, if it is required (e.g., if their server has no 1555 certificate, or if its certificate is for signing only). If the 1556 server is authenticated, it may request a certificate from the 1557 client, if that is appropriate to the cipher suite selected. Next, 1558 the server will send the server hello done message, indicating that 1559 the hello-message phase of the handshake is complete. The server will 1560 then wait for a client response. If the server has sent a certificate 1561 request message, the client MUST send the certificate message. The 1562 client key exchange message is now sent, and the content of that 1563 message will depend on the public key algorithm selected between the 1564 client hello and the server hello. If the client has sent a 1565 certificate with signing ability, a digitally-signed certificate 1566 verify message is sent to explicitly verify possession of the private 1567 key in the certificate. 1569 At this point, a change cipher spec message is sent by the client, 1570 and the client copies the pending Cipher Spec into the current Cipher 1571 Spec. The client then immediately sends the finished message under 1572 the new algorithms, keys, and secrets. In response, the server will 1573 send its own change cipher spec message, transfer the pending to the 1574 current Cipher Spec, and send its finished message under the new 1575 Cipher Spec. At this point, the handshake is complete, and the client 1576 and server may begin to exchange application layer data. (See flow 1577 chart below.) Application data MUST NOT be sent prior to the 1578 completion of the first handshake (before a cipher suite other than 1579 TLS_NULL_WITH_NULL_NULL is established). 1581 Client Server 1583 ClientHello --------> 1584 ServerHello 1585 Certificate* 1586 ServerKeyExchange* 1587 CertificateRequest* 1588 <-------- ServerHelloDone 1589 Certificate* 1590 ClientKeyExchange 1591 CertificateVerify* 1592 [ChangeCipherSpec] 1593 Finished --------> 1594 [ChangeCipherSpec] 1595 <-------- Finished 1596 Application Data <-------> Application Data 1598 Fig. 1. Message flow for a full handshake 1600 * Indicates optional or situation-dependent messages that are not 1601 always sent. 1603 Note: To help avoid pipeline stalls, ChangeCipherSpec is an 1604 independent TLS Protocol content type, and is not actually a TLS 1605 handshake message. 1607 When the client and server decide to resume a previous session or 1608 duplicate an existing session (instead of negotiating new security 1609 parameters), the message flow is as follows: 1611 The client sends a ClientHello using the Session ID of the session to 1612 be resumed. The server then checks its session cache for a match. If 1613 a match is found, and the server is willing to re-establish the 1614 connection under the specified session state, it will send a 1615 ServerHello with the same Session ID value. At this point, both 1616 client and server MUST send change cipher spec messages and proceed 1617 directly to finished messages. Once the re-establishment is complete, 1618 the client and server MAY begin to exchange application layer data. 1619 (See flow chart below.) If a Session ID match is not found, the 1620 server generates a new session ID and the TLS client and server 1621 perform a full handshake. 1623 Client Server 1625 ClientHello --------> 1626 ServerHello 1627 [ChangeCipherSpec] 1628 <-------- Finished 1629 [ChangeCipherSpec] 1630 Finished --------> 1631 Application Data <-------> Application Data 1633 Fig. 2. Message flow for an abbreviated handshake 1635 The contents and significance of each message will be presented in 1636 detail in the following sections. 1638 7.4. Handshake Protocol 1640 The TLS Handshake Protocol is one of the defined higher-level clients 1641 of the TLS Record Protocol. This protocol is used to negotiate the 1642 secure attributes of a session. Handshake messages are supplied to 1643 the TLS Record Layer, where they are encapsulated within one or more 1644 TLSPlaintext structures, which are processed and transmitted as 1645 specified by the current active session state. 1647 enum { 1648 hello_request(0), client_hello(1), server_hello(2), 1649 certificate(11), server_key_exchange (12), 1650 certificate_request(13), server_hello_done(14), 1651 certificate_verify(15), client_key_exchange(16), 1652 finished(20), (255) 1653 } HandshakeType; 1655 struct { 1656 HandshakeType msg_type; /* handshake type */ 1657 uint24 length; /* bytes in message */ 1658 select (HandshakeType) { 1659 case hello_request: HelloRequest; 1660 case client_hello: ClientHello; 1661 case server_hello: ServerHello; 1662 case certificate: Certificate; 1663 case server_key_exchange: ServerKeyExchange; 1664 case certificate_request: CertificateRequest; 1665 case server_hello_done: ServerHelloDone; 1666 case certificate_verify: CertificateVerify; 1667 case client_key_exchange: ClientKeyExchange; 1668 case finished: Finished; 1669 } body; 1670 } Handshake; 1672 The handshake protocol messages are presented below in the order they 1673 MUST be sent; sending handshake messages in an unexpected order 1674 results in a fatal error. Unneeded handshake messages can be omitted, 1675 however. Note one exception to the ordering: the Certificate message 1676 is used twice in the handshake (from server to client, then from 1677 client to server), but described only in its first position. The one 1678 message that is not bound by these ordering rules is the Hello 1679 Request message, which can be sent at any time, but which SHOULD be 1680 ignored by the client if it arrives in the middle of a handshake. 1682 New Handshake message types are assigned by IANA as described in 1683 Section 12. 1685 7.4.1. Hello Messages 1687 The hello phase messages are used to exchange security enhancement 1688 capabilities between the client and server. When a new session 1689 begins, the Record Layer's connection state encryption, hash, and 1690 compression algorithms are initialized to null. The current 1691 connection state is used for renegotiation messages. 1693 7.4.1.1. Hello Request 1695 When this message will be sent: 1697 The hello request message MAY be sent by the server at any time. 1699 Meaning of this message: 1701 Hello request is a simple notification that the client should 1702 begin the negotiation process anew by sending a client hello 1703 message when convenient. This message is not intended to establish 1704 which side is the client or server but merely to initiate a new 1705 negotiation. Servers SHOULD NOT send a HelloRequest immediately 1706 upon the client's initial connection. It is the client's job to 1707 send a ClientHello at that time. 1709 This message will be ignored by the client if the client is 1710 currently negotiating a session. This message may be ignored by 1711 the client if it does not wish to renegotiate a session, or the 1712 client may, if it wishes, respond with a no_renegotiation alert. 1713 Since handshake messages are intended to have transmission 1714 precedence over application data, it is expected that the 1715 negotiation will begin before no more than a few records are 1716 received from the client. If the server sends a hello request but 1717 does not receive a client hello in response, it may close the 1718 connection with a fatal alert. 1720 After sending a hello request, servers SHOULD NOT repeat the 1721 request until the subsequent handshake negotiation is complete. 1723 Structure of this message: 1725 struct { } HelloRequest; 1727 Note: This message MUST NOT be included in the message hashes that 1728 are maintained throughout the handshake and used in the finished 1729 messages and the certificate verify message. 1731 7.4.1.2. Client Hello 1733 When this message will be sent: 1735 When a client first connects to a server it is required to send 1736 the client hello as its first message. The client can also send a 1737 client hello in response to a hello request or on its own 1738 initiative in order to renegotiate the security parameters in an 1739 existing connection. 1741 Structure of this message: 1743 The client hello message includes a random structure, which is 1744 used later in the protocol. 1746 struct { 1747 uint32 gmt_unix_time; 1748 opaque random_bytes[28]; 1749 } Random; 1751 gmt_unix_time 1752 The current time and date in standard UNIX 32-bit format 1753 (seconds since the midnight starting Jan 1, 1970, GMT, ignoring 1754 leap seconds) according to the sender's internal clock. Clocks 1755 are not required to be set correctly by the basic TLS Protocol; 1756 higher-level or application protocols may define additional 1757 requirements. 1759 random_bytes 1760 28 bytes generated by a secure random number generator. 1762 The client hello message includes a variable-length session 1763 identifier. If not empty, the value identifies a session between the 1764 same client and server whose security parameters the client wishes to 1765 reuse. The session identifier MAY be from an earlier connection, this 1766 connection, or from another currently active connection. The second 1767 option is useful if the client only wishes to update the random 1768 structures and derived values of a connection, and the third option 1769 makes it possible to establish several independent secure connections 1770 without repeating the full handshake protocol. These independent 1771 connections may occur sequentially or simultaneously; a SessionID 1772 becomes valid when the handshake negotiating it completes with the 1773 exchange of Finished messages and persists until it is removed due to 1774 aging or because a fatal error was encountered on a connection 1775 associated with the session. The actual contents of the SessionID are 1776 defined by the server. 1778 opaque SessionID<0..32>; 1780 Warning: Because the SessionID is transmitted without encryption or 1781 immediate MAC protection, servers MUST NOT place confidential 1782 information in session identifiers or let the contents of fake 1783 session identifiers cause any breach of security. (Note that the 1784 content of the handshake as a whole, including the SessionID, is 1785 protected by the Finished messages exchanged at the end of the 1786 handshake.) 1788 The CipherSuite list, passed from the client to the server in the 1789 client hello message, contains the combinations of cryptographic 1790 algorithms supported by the client in order of the client's 1791 preference (favorite choice first). Each CipherSuite defines a key 1792 exchange algorithm, a bulk encryption algorithm (including secret key 1793 length), a MAC algorithm, and a PRF. The server will select a cipher 1794 suite or, if no acceptable choices are presented, return a handshake 1795 failure alert and close the connection. 1797 uint8 CipherSuite[2]; /* Cryptographic suite selector */ 1799 The client hello includes a list of compression algorithms supported 1800 by the client, ordered according to the client's preference. 1802 enum { null(0), (255) } CompressionMethod; 1804 struct { 1805 ProtocolVersion client_version; 1806 Random random; 1807 SessionID session_id; 1808 CipherSuite cipher_suites<2..2^16-2>; 1809 CompressionMethod compression_methods<1..2^8-1>; 1810 select (extensions_present) { 1811 case false: 1812 struct {}; 1813 case true: 1814 Extension extensions<0..2^16-1>; 1815 }; 1816 } ClientHello; 1818 TLS allows extensions to follow the compression_methods field in an 1819 extensions block. The presence of extensions can be detected by 1820 determining whether there are bytes following the compression_methods 1821 at the end of the ClientHello. Note that this method of detecting 1822 optional data differs from the normal TLS method of having a 1823 variable-length field but is used for compatibility with TLS before 1824 extensions were defined. 1826 client_version 1827 The version of the TLS protocol by which the client wishes to 1828 communicate during this session. This SHOULD be the latest 1829 (highest valued) version supported by the client. For this version 1830 of the specification, the version will be 3.3 (See Appendix E for 1831 details about backward compatibility). 1833 random 1834 A client-generated random structure. 1836 session_id 1837 The ID of a session the client wishes to use for this connection. 1838 This field is empty if no session_id is available, or it the 1839 client wishes to generate new security parameters. 1841 cipher_suites 1842 This is a list of the cryptographic options supported by the 1843 client, with the client's first preference first. If the 1844 session_id field is not empty (implying a session resumption 1845 request) this vector MUST include at least the cipher_suite from 1846 that session. Values are defined in Appendix A.5. 1848 compression_methods 1849 This is a list of the compression methods supported by the client, 1850 sorted by client preference. If the session_id field is not empty 1851 (implying a session resumption request) it MUST include the 1852 compression_method from that session. This vector MUST contain, 1853 and all implementations MUST support, CompressionMethod.null. 1854 Thus, a client and server will always be able to agree on a 1855 compression method. 1857 client_hello_extension_list 1858 Clients MAY request extended functionality from servers by sending 1859 data in the client_hello_extension_list. Here the new 1860 "client_hello_extension_list" field contains a list of extensions. 1861 The actual "Extension" format is defined in Section 7.4.1.4. 1863 In the event that a client requests additional functionality using 1864 extensions, and this functionality is not supplied by the server, the 1865 client MAY abort the handshake. A server that supports the 1866 extensions mechanism MUST accept client hello messages in either the 1867 original (TLS 1.0/TLS 1.1) ClientHello or the extended ClientHello 1868 format defined in this document, and (as for all other messages) MUST 1869 check that the amount of data in the message precisely matches one of 1870 these formats; if not then it MUST send a fatal "decode_error" alert. 1872 After sending the client hello message, the client waits for a server 1873 hello message. Any other handshake message returned by the server 1874 except for a hello request is treated as a fatal error. 1876 7.4.1.3. Server Hello 1878 When this message will be sent: 1880 The server will send this message in response to a client hello 1881 message when it was able to find an acceptable set of algorithms. 1882 If it cannot find such a match, it will respond with a handshake 1883 failure alert. 1885 Structure of this message: 1887 struct { 1888 ProtocolVersion server_version; 1889 Random random; 1890 SessionID session_id; 1891 CipherSuite cipher_suite; 1892 CompressionMethod compression_method; 1893 select (extensions_present) { 1894 case false: 1895 struct {}; 1896 case true: 1897 Extension extensions<0..2^16-1>; 1898 }; 1899 } ServerHello; 1901 The presence of extensions can be detected by determining whether 1902 there are bytes following the compression_method field at the end of 1903 the ServerHello. 1905 server_version 1906 This field will contain the lower of that suggested by the client 1907 in the client hello and the highest supported by the server. For 1908 this version of the specification, the version is 3.3. (See 1909 Appendix E for details about backward compatibility.) 1911 random 1912 This structure is generated by the server and MUST be 1913 independently generated from the ClientHello.random. 1915 session_id 1916 This is the identity of the session corresponding to this 1917 connection. If the ClientHello.session_id was non-empty, the 1918 server will look in its session cache for a match. If a match is 1919 found and the server is willing to establish the new connection 1920 using the specified session state, the server will respond with 1921 the same value as was supplied by the client. This indicates a 1922 resumed session and dictates that the parties must proceed 1923 directly to the finished messages. Otherwise this field will 1924 contain a different value identifying the new session. The server 1925 may return an empty session_id to indicate that the session will 1926 not be cached and therefore cannot be resumed. If a session is 1927 resumed, it must be resumed using the same cipher suite it was 1928 originally negotiated with. Note that there is no requirement that 1929 the server resume any session even if it had formerly provided a 1930 session_id. Client MUST be prepared to do a full negotiation -- 1931 including negotiating new cipher suites -- during any handshake. 1933 cipher_suite 1934 The single cipher suite selected by the server from the list in 1935 ClientHello.cipher_suites. For resumed sessions, this field is the 1936 value from the state of the session being resumed. 1938 compression_method 1939 The single compression algorithm selected by the server from the 1940 list in ClientHello.compression_methods. For resumed sessions this 1941 field is the value from the resumed session state. 1943 server_hello_extension_list 1944 A list of extensions. Note that only extensions offered by the 1945 client can appear in the server's list. 1947 7.4.1.4 Hello Extensions 1949 The extension format is: 1951 struct { 1952 ExtensionType extension_type; 1953 opaque extension_data<0..2^16-1>; 1954 } Extension; 1956 enum { 1957 signature_algorithms(TBD-BY-IANA), (65535) 1958 } ExtensionType; 1960 Here: 1962 - "extension_type" identifies the particular extension type. 1964 - "extension_data" contains information specific to the particular 1965 extension type. 1967 The initial set of extensions is defined in a companion document 1968 [TLSEXT]. The list of extension types is maintained by IANA as 1969 described in Section 12. 1971 There are subtle (and not so subtle) interactions that may occur in 1972 this protocol between new features and existing features which may 1973 result in a significant reduction in overall security, The following 1974 considerations should be taken into account when designing new 1975 extensions: 1977 - Some cases where a server does not agree to an extension are error 1978 conditions, and some simply a refusal to support a particular 1979 feature. In general error alerts should be used for the former, 1980 and a field in the server extension response for the latter. 1982 - Extensions should as far as possible be designed to prevent any 1983 attack that forces use (or non-use) of a particular feature by 1984 manipulation of handshake messages. This principle should be 1985 followed regardless of whether the feature is believed to cause a 1986 security problem. 1988 Often the fact that the extension fields are included in the 1989 inputs to the Finished message hashes will be sufficient, but 1990 extreme care is needed when the extension changes the meaning of 1991 messages sent in the handshake phase. Designers and implementors 1992 should be aware of the fact that until the handshake has been 1993 authenticated, active attackers can modify messages and insert, 1994 remove, or replace extensions. 1996 - It would be technically possible to use extensions to change major 1997 aspects of the design of TLS; for example the design of cipher 1998 suite negotiation. This is not recommended; it would be more 1999 appropriate to define a new version of TLS - particularly since 2000 the TLS handshake algorithms have specific protection against 2001 version rollback attacks based on the version number, and the 2002 possibility of version rollback should be a significant 2003 consideration in any major design change. 2005 7.4.1.4.1 Signature Algorithms 2007 The client MAY use the "signature_algorithms" extension to indicate 2008 to the server which signature/hash algorithm pairs may be used in 2009 digital signatures. The "extension_data" field of this extension 2010 contains a "supported_signature_algorithms" value. 2012 enum { 2013 none(0), md5(1), sha1(2), sha256(3), sha384(4), 2014 sha512(5), (255) 2015 } HashAlgorithm; 2017 enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } 2018 SignatureAlgorithm; 2020 struct { 2021 HashAlgorithm hash; 2022 SignatureAlgorithm signature; 2023 } SignatureAndHashAlgorithm; 2025 SignatureAndHashAlgorithm 2026 supported_signature_algorithms<2..2^16-1>; 2028 Each SignatureAndHashAlgorithm value lists a single hash/signature 2029 pair which the client is willing to verify. The values are indicated 2030 in descending order of preference. 2032 Note: Because not all signature algorithms and hash algorithms may be 2033 accepted by an implementation (e.g., DSA with SHA-1, but not 2034 SHA-256), algorithms here are listed in pairs. 2036 hash 2037 This field indicates the hash algorithm which may be used. The 2038 values indicate support for unhashed data, MD5 [MD5], SHA-1, 2039 SHA-256, SHA-384, and SHA-512 [SHA] respectively. The "none" value 2040 is provided for future extensibility, in case of a signature 2041 algorithm which does not require hashing before signing. 2043 signature 2044 This field indicates the signature algorithm which may be used. 2045 The values indicate anonymous signatures, RSA [PKCS1] and DSA 2046 [DSS] respectively. The "anonymous" value is meaningless in this 2047 context but used later in the specification. It MUST NOT appear in 2048 this extension. 2050 The semantics of this extension are somewhat complicated because the 2051 cipher suite indicates permissible signature algorithms but not hash 2052 algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate rules. 2054 Clients SHOULD send this extension if they support any hash algorithm 2055 other than SHA-1. 2057 If the client does not send the signature_algorithms extension, the 2058 server SHOULD assume the following: 2060 - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, 2061 DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent 2062 the value (sha1,rsa). 2064 - If the negotiated key exchange algorithm is one of (DHE_DSS, 2065 DH_DSS), behave as if the client had sent the value (sha1,dsa). 2067 - If the negotiated key exchnage algorithm is one of (ECDH_ECDSA, 2068 ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa). 2070 Note: this is a change from TLS 1.1 where there are no explicit rules 2071 but as a practical matter one can assume that the peer supports MD5 2072 and SHA-1. 2074 Servers MUST NOT send this extension. 2076 7.4.2. Server Certificate 2078 When this message will be sent: 2080 The server MUST send a certificate whenever the agreed-upon key 2081 exchange method uses certificates for authentication (this 2082 includes all key exchange methods defined in this document except 2083 DH_anon). This message will always immediately follow the server 2084 hello message. 2086 Meaning of this message: 2088 This message conveys the server's certificate to the client. The 2089 certificate MUST be appropriate for the negotiated cipher suite's 2090 key exchange algorithm, and any negotiated extensions. 2092 Structure of this message: 2094 opaque ASN.1Cert<1..2^24-1>; 2096 struct { 2097 ASN.1Cert certificate_list<0..2^24-1>; 2098 } Certificate; 2100 certificate_list 2101 This is a sequence (chain) of certificates. The sender's 2102 certificate MUST come first in the list. Each following 2103 certificate MUST directly certify the one preceding it. Because 2104 certificate validation requires that root keys be distributed 2105 independently, the self-signed certificate that specifies the root 2106 certificate authority MAY optionally be omitted from the chain, 2107 under the assumption that the remote end must already possess it 2108 in order to validate it in any case. 2110 The same message type and structure will be used for the client's 2111 response to a certificate request message. Note that a client MAY 2112 send no certificates if it does not have an appropriate certificate 2113 to send in response to the server's authentication request. 2115 Note: PKCS #7 [PKCS7] is not used as the format for the certificate 2116 vector because PKCS #6 [PKCS6] extended certificates are not used. 2117 Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task 2118 of parsing the list more difficult. 2120 The following rules apply to the certificates sent by the server: 2122 - The certificate type MUST be X.509v3, unless explicitly negotiated 2123 otherwise (e.g., [TLSPGP]). 2125 - The certificate's public key (and associated restrictions) MUST be 2126 compatible with the selected key exchange algorithm. 2128 Key Exchange Alg. Certificate Key Type 2130 RSA RSA public key; the certificate MUST 2131 RSA_PSK allow the key to be used for encryption 2132 (the keyEncipherment bit MUST be set 2133 if the key usage extension is present). 2134 Note: RSA_PSK is defined in [TLSPSK]. 2136 DHE_RSA RSA public key; the certificate MUST 2137 ECDHE_RSA allow the key to be used for signing 2138 (the digitalSignature bit MUST be set 2139 if the key usage extension is present) 2140 with the signature scheme and hash 2141 algorithm that will be employed in the 2142 server key exchange message. 2144 DHE_DSS DSA public key; the certificate MUST 2145 allow the key to be used for signing with 2146 the hash algorithm that will be employed 2147 in the server key exchange message. 2149 DH_DSS Diffie-Hellman public key; the 2150 DH_RSA keyAgreement bit MUST be set if the 2151 key usage extension is present. 2153 ECDH_ECDSA ECDH-capable public key; the public key 2154 ECDH_RSA MUST use a curve and point format supported 2155 by the client, as described in [TLSECC]. 2157 ECDHE_ECDSA ECDSA-capable public key; the certificate 2158 MUST allow the key to be used for signing 2159 with the hash algorithm that will be 2160 employed in the server key exchange 2161 message. The public key MUST use a curve 2162 and point format supported by the client, 2163 as described in [TLSECC]. 2165 - The "server_name" and "trusted_ca_keys" extensions [4366bis] are 2166 used to guide certificate selection. 2168 If the client provided a "signature_algorithms" extension, then all 2169 certificates provided by the server MUST be signed by a 2170 hash/signature algorithm pair that appears in that extension. Note 2171 that this implies that a certificate containing a key for one 2172 signature algorithm MAY be signed using a different signature 2173 algorithm (for instance, an RSA key signed with a DSA key.) This is a 2174 departure from TLS 1.1, which required that the algorithms be the 2175 same. Note that this also implies that the DH_DSS, DH_RSA, 2176 ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the 2177 algorithm used to sign the certificate. Fixed DH certificates MAY be 2178 signed with any hash/signature algorithm pair appearing in the 2179 extension. The naming is historical. 2181 If the server has multiple certificates, it chooses one of them based 2182 on the above-mentioned criteria (in addition to other criteria, such 2183 as transport layer endpoint, local configuration and preferences, 2184 etc.). 2186 Note that there are certificates that use algorithms and/or algorithm 2187 combinations that cannot be currently used with TLS. For example, a 2188 certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in 2189 SubjectPublicKeyInfo) cannot be used because TLS defines no 2190 corresponding signature algorithm. 2192 As CipherSuites that specify new key exchange methods are specified 2193 for the TLS Protocol, they will imply certificate format and the 2194 required encoded keying information. 2196 7.4.3. Server Key Exchange Message 2198 When this message will be sent: 2200 This message will be sent immediately after the server certificate 2201 message (or the server hello message, if this is an anonymous 2202 negotiation). 2204 The server key exchange message is sent by the server only when 2205 the server certificate message (if sent) does not contain enough 2206 data to allow the client to exchange a premaster secret. This is 2207 true for the following key exchange methods: 2209 DHE_DSS 2210 DHE_RSA 2211 DH_anon 2213 It is not legal to send the server key exchange message for the 2214 following key exchange methods: 2216 RSA 2217 DH_DSS 2218 DH_RSA 2220 Meaning of this message: 2222 This message conveys cryptographic information to allow the client 2223 to communicate the premaster secret: a Diffie-Hellman public key 2224 with which the client can complete a key exchange (with the result 2225 being the premaster secret) or a public key for some other 2226 algorithm. 2228 Structure of this message: 2230 enum { diffie_hellman, rsa } KeyExchangeAlgorithm; 2232 struct { 2233 opaque dh_p<1..2^16-1>; 2234 opaque dh_g<1..2^16-1>; 2235 opaque dh_Ys<1..2^16-1>; 2237 } ServerDHParams; /* Ephemeral DH parameters */ 2239 dh_p 2240 The prime modulus used for the Diffie-Hellman operation. 2242 dh_g 2243 The generator used for the Diffie-Hellman operation. 2245 dh_Ys 2246 The server's Diffie-Hellman public value (g^X mod p). 2248 struct { 2249 select (KeyExchangeAlgorithm) { 2250 case diffie_hellman: 2251 ServerDHParams params; 2252 Signature signed_params; 2253 }; 2254 } ServerKeyExchange; 2256 struct { 2257 select (KeyExchangeAlgorithm) { 2258 case diffie_hellman: 2259 ServerDHParams params; 2260 }; 2261 } ServerParams; 2263 params 2264 The server's key exchange parameters. 2266 signed_params 2267 For non-anonymous key exchanges, a hash of the corresponding 2268 params value, with the signature appropriate to that hash 2269 applied. 2271 hash 2272 Hash(ClientHello.random + ServerHello.random + ServerParams) 2273 where Hash is the chosen hash value and Hash.length is 2274 its output. 2276 struct { 2277 select (SignatureAlgorithm) { 2278 case anonymous: struct { }; 2279 case rsa: 2280 SignatureAndHashAlgorithm signature_algorithm; /*NEW*/ 2281 digitally-signed struct { 2282 opaque hash[Hash.length]; 2283 }; 2285 case dsa: 2286 SignatureAndHashAlgorithm signature_algorithm; /*NEW*/ 2287 digitally-signed struct { 2288 opaque hash[Hash.length]; 2289 }; 2290 }; 2291 }; 2292 } Signature; 2294 If the client has offered the "signature_algorithms" extension, the 2295 signature algorithm and hash algorithm MUST be a pair listed in that 2296 extension. Note that there is a possibility for inconsistencies here. 2297 For instance, the client might offer DHE_DSS key exchange but omit 2298 any DSS pairs from its "signature_algorithms" extension. In order to 2299 negotiate correctly, the server MUST check any candidate cipher 2300 suites against the "signature_algorithms" extension before selecting 2301 them. This is somewhat inelegant but is a compromise designed to 2302 minimize changes to the original cipher suite design. 2304 If no "signature_algorithms" extension is present, the server MUST 2305 use SHA-1 as the hash algorithm. 2307 In addition, the hash and signature algorithms MUST be compatible 2308 with the key in the server's end-entity certificate. RSA keys MAY be 2309 used with any permitted hash algorithm, subject to restrictions in 2310 the certificate, if any. 2312 Because DSA signatures do not contain any secure indication of hash 2313 algorithm, there is a risk of hash substitution if multiple hashes 2314 may be used with any key. Currently, DSS [DSS] may only be used with 2315 SHA-1. Future revisions of DSS [DSS-3] are expected to allow other 2316 digest algorithms, as well as guidance as to which digest algorithms 2317 should be used with each key size. In addition, future revisions of 2318 [PKIX] may specify mechanisms for certificates to indicate which 2319 digest algorithms are to be used with DSA. 2321 As additional CipherSuites are defined for TLS that include new key 2322 exchange algorithms, the server key exchange message will be sent if 2323 and only if the certificate type associated with the key exchange 2324 algorithm does not provide enough information for the client to 2325 exchange a premaster secret. 2327 7.4.4. Certificate Request 2329 When this message will be sent: 2331 A non-anonymous server can optionally request a certificate from 2332 the client, if appropriate for the selected cipher suite. This 2333 message, if sent, will immediately follow the Server Key Exchange 2334 message (if it is sent; otherwise, the Server Certificate 2335 message). 2337 Structure of this message: 2339 enum { 2340 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), 2341 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), 2342 fortezza_dms_RESERVED(20), (255) 2343 } ClientCertificateType; 2345 opaque DistinguishedName<1..2^16-1>; 2347 struct { 2348 ClientCertificateType certificate_types<1..2^8-1>; 2349 SignatureAndHashAlgorithm 2350 supported_signature_algorithms<2^16-1>; 2351 DistinguishedName certificate_authorities<0..2^16-1>; 2352 } CertificateRequest; 2354 certificate_types 2355 A list of the types of certificate types which the client may 2356 offer. 2358 rsa_sign a certificate containing an RSA key 2359 dss_sign a certificate containing a DSS key 2360 rsa_fixed_dh a certificate containing a static DH key. 2361 dss_fixed_dh a certificate containing a static DH key 2363 supported_signature_algorithms 2364 A list of the hash/signature algorithm pairs that the server is 2365 able to verify, listed in descending order of preference. 2367 certificate_authorities 2368 A list of the distinguished names [X501] of acceptable 2369 certificate_authorities, represented in DER-encoded format. These 2370 distinguished names may specify a desired distinguished name for a 2371 root CA or for a subordinate CA; thus, this message can be used 2372 both to describe known roots and a desired authorization space. If 2373 the certificate_authorities list is empty then the client MAY send 2374 any certificate of the appropriate ClientCertificateType, unless 2375 there is some external arrangement to the contrary. 2377 The interaction of the certificate_types and 2378 supported_signature_algorithms fields is somewhat complicated. 2379 certificate_types has been present in TLS since SSLv3, but was 2380 somewhat underspecified. Much of its functionality is superseded by 2381 supported_signature_algorithms. The following rules apply: 2383 - Any certificates provided by the client MUST be signed using a 2384 hash/signature algorithm pair found in supported_signature_types. 2386 - The end-entity certificate provided by the client MUST contain a 2387 key which is compatible with certificate_types. If the key is a 2388 signature key, it MUST be usable with some hash/signature 2389 algorithm pair in supported_signature_types. 2391 - For historical reasons, the names of some client certificate types 2392 include the algorithm used to sign the certificate. For example, 2393 in earlier versions of TLS, rsa_fixed_dh meant a certificate 2394 signed with RSA and containing a static DH key. In TLS 1.2, this 2395 functionality has been obsoleted by the signature_types field, and 2396 the certificate type no longer restricts the algorithm used to 2397 sign the certificate. For example, if the server sends 2398 dss_fixed_dh certificate type and {dss_sha1, rsa_sha1} signature 2399 types, the client MAY to reply with a certificate containing a 2400 static DH key, signed with RSA-SHA1. 2402 New ClientCertificateType values are assigned by IANA as described in 2403 Section 12. 2405 Note: Values listed as RESERVED may not be used. They were used in 2406 SSLv3. 2408 Note: It is a fatal handshake_failure alert for an anonymous server 2409 to request client authentication. 2411 7.4.5 Server hello done 2413 When this message will be sent: 2415 The server hello done message is sent by the server to indicate 2416 the end of the server hello and associated messages. After sending 2417 this message, the server will wait for a client response. 2419 Meaning of this message: 2421 This message means that the server is done sending messages to 2422 support the key exchange, and the client can proceed with its 2423 phase of the key exchange. 2425 Upon receipt of the server hello done message, the client SHOULD 2426 verify that the server provided a valid certificate, if required 2427 and check that the server hello parameters are acceptable. 2429 Structure of this message: 2431 struct { } ServerHelloDone; 2433 7.4.6. Client Certificate 2435 When this message will be sent: 2437 This is the first message the client can send after receiving a 2438 server hello done message. This message is only sent if the server 2439 requests a certificate. If no suitable certificate is available, 2440 the client MUST send a certificate message containing no 2441 certificates. That is, the certificate_list structure has a length 2442 of zero. If client authentication is required by the server for 2443 the handshake to continue, it may respond with a fatal handshake 2444 failure alert. Client certificates are sent using the Certificate 2445 structure defined in Section 7.4.2. 2447 Meaning of this message: 2449 This message conveys the client's certificate to the server; the 2450 server will use it when verifying the certificate verify message 2451 (when the client authentication is based on signing), or calculate 2452 the premaster secret (for non-ephemeral Diffie-Hellman). The 2453 certificate MUST be appropriate for the negotiated cipher suite's 2454 key exchange algorithm, and any negotiated extensions. 2456 In particular: 2458 - The certificate type MUST be X.509v3, unless explicitly negotiated 2459 otherwise (e.g. [TLSPGP]). 2461 - The certificate's public key (and associated restrictions) has to 2462 be compatible with the certificate types listed in 2463 CertificateRequest: 2465 Client Cert. Type Certificate Key Type 2467 rsa_sign RSA public key; the certificate MUST allow 2468 the key to be used for signing with the 2469 signature scheme and hash algorithm that 2470 will be employed in the certificate verify 2471 message. 2473 dss_sign DSA public key; the certificate MUST allow 2474 the key to be used for signing with the 2475 hash algorithm that will be employed in 2476 the certificate verify message. 2478 ecdsa_sign ECDSA-capable public key; the certificate 2479 MUST allow the key to be used for signing 2480 with the hash algorithm that will be 2481 employed in the certificate verify 2482 message; the public key MUST use a 2483 curve and point format supported by the 2484 server. 2486 rsa_fixed_dh Diffie-Hellman public key; MUST use 2487 dss_fixed_dh the same parameters as server's key. 2489 rsa_fixed_ecdh ECDH-capable public key; MUST use 2490 ecdsa_fixed_ecdh the same curve as server's key, and 2491 MUST use a point format supported by 2493 - If the certificate_authorities list in the certificate request 2494 message was non-empty, the certificate SHOULD be issued by one of 2495 the listed CAs. 2497 - The certificates MUST be signed using an acceptable hash/ 2498 signature algorithm pair, as described in Section 7.4.4. Note that 2499 this relaxes the constraints on certificate signing algorithms 2500 found in prior versions of TLS. 2502 Note that as with the server certificate, there are certificates that 2503 use algorithms/algorithm combinations that cannot be currently used 2504 with TLS. 2506 7.4.7. Client Key Exchange Message 2508 When this message will be sent: 2510 This message is always sent by the client. It MUST immediately 2511 follow the client certificate message, if it is sent. Otherwise it 2512 MUST be the first message sent by the client after it receives the 2513 server hello done message. 2515 Meaning of this message: 2517 With this message, the premaster secret is set, either though 2518 direct transmission of the RSA-encrypted secret, or by the 2519 transmission of Diffie-Hellman parameters that will allow each 2520 side to agree upon the same premaster secret. 2522 When the client is using an ephemeral Diffie-Hellman exponent, 2523 then this message contains the client's Diffie-Hellman public 2524 value. If the client is sending a certificate containing a static 2525 DH exponent (i.e., it is doing fixed_dh client authentication) 2526 then this message MUST be sent but MUST be empty. 2528 Structure of this message: 2530 The choice of messages depends on which key exchange method has 2531 been selected. See Section 7.4.3 for the KeyExchangeAlgorithm 2532 definition. 2534 struct { 2535 select (KeyExchangeAlgorithm) { 2536 case rsa: EncryptedPreMasterSecret; 2537 case diffie_hellman: ClientDiffieHellmanPublic; 2538 } exchange_keys; 2539 } ClientKeyExchange; 2541 7.4.7.1. RSA Encrypted Premaster Secret Message 2543 Meaning of this message: 2545 If RSA is being used for key agreement and authentication, the 2546 client generates a 48-byte premaster secret, encrypts it using the 2547 public key from the server's certificate and sends the result in 2548 an encrypted premaster secret message. This structure is a variant 2549 of the client key exchange message and is not a message in itself. 2551 Structure of this message: 2553 struct { 2554 ProtocolVersion client_version; 2555 opaque random[46]; 2556 } PreMasterSecret; 2558 client_version 2559 The latest (newest) version supported by the client. This is 2560 used to detect version roll-back attacks. 2562 random 2563 46 securely-generated random bytes. 2565 struct { 2566 public-key-encrypted PreMasterSecret pre_master_secret; 2567 } EncryptedPreMasterSecret; 2569 pre_master_secret 2570 This random value is generated by the client and is used to 2571 generate the master secret, as specified in Section 8.1. 2573 Note: The version number in the PreMasterSecret is the version 2574 offered by the client in the ClientHello.client_version, not the 2575 version negotiated for the connection. This feature is designed to 2576 prevent rollback attacks. Unfortunately, some old implementations 2577 use the negotiated version instead and therefore checking the version 2578 number may lead to failure to interoperate with such incorrect client 2579 implementations. 2581 Client implementations MUST always send the correct version number in 2582 PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, 2583 server implementations MUST check the version number as described in 2584 the note below. If the version number is earlier than 1.0, server 2585 implementations SHOULD check the version number, but MAY have a 2586 configuration option to disable the check. Note that if the check 2587 fails, the PreMasterSecret SHOULD be randomized as described below. 2589 Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. 2590 [KPR03] can be used to attack a TLS server that reveals whether a 2591 particular message, when decrypted, is properly PKCS#1 formatted, 2592 contains a valid PreMasterSecret structure, or has the correct 2593 version number. 2595 The best way to avoid these vulnerabilities is to treat incorrectly 2596 formatted messages in a manner indistinguishable from correctly 2597 formatted RSA blocks. In other words: 2599 1. Generate a string R of 46 random bytes 2601 2. Decrypt the message M 2603 3. If the PKCS#1 padding is not correct, or the length of 2604 message M is not exactly 48 bytes: 2605 premaster secret = ClientHello.client_version || R 2606 else If ClientHello.client_version <= TLS 1.0, and 2607 version number check is explicitly disabled: 2608 premaster secret = M 2609 else: 2610 premaster secret = ClientHello.client_version || M[2..47] 2612 In any case, a TLS server MUST NOT generate an alert if processing an 2613 RSA-encrypted premaster secret message fails, or the version number 2614 is not as expected. Instead, it MUST continue the handshake with a 2615 randomly generated premaster secret. It may be useful to log the 2616 real cause of failure for troubleshooting purposes; however, care 2617 must be taken to avoid leaking the information to an attacker 2618 (though, e.g., timing, log files, or other channels.) 2620 The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure 2621 against the Bleichenbacher attack. However, for maximal compatibility 2622 with earlier versions of TLS, this specification uses the RSAES- 2623 PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known 2624 to exist provided that the above recommendations are followed. 2626 Implementation Note: Public-key-encrypted data is represented as an 2627 opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted 2628 PreMasterSecret in a ClientKeyExchange is preceded by two length 2629 bytes. These bytes are redundant in the case of RSA because the 2630 EncryptedPreMasterSecret is the only data in the ClientKeyExchange 2631 and its length can therefore be unambiguously determined. The SSLv3 2632 specification was not clear about the encoding of public-key- 2633 encrypted data, and therefore many SSLv3 implementations do not 2634 include the the length bytes, encoding the RSA encrypted data 2635 directly in the ClientKeyExchange message. 2637 This specification requires correct encoding of the 2638 EncryptedPreMasterSecret complete with length bytes. The resulting 2639 PDU is incompatible with many SSLv3 implementations. Implementors 2640 upgrading from SSLv3 MUST modify their implementations to generate 2641 and accept the correct encoding. Implementors who wish to be 2642 compatible with both SSLv3 and TLS should make their implementation's 2643 behavior dependent on the protocol version. 2645 Implementation Note: It is now known that remote timing-based attacks 2646 on TLS are possible, at least when the client and server are on the 2647 same LAN. Accordingly, implementations that use static RSA keys MUST 2648 use RSA blinding or some other anti-timing technique, as described in 2649 [TIMING]. 2651 7.4.7.2. Client Diffie-Hellman Public Value 2653 Meaning of this message: 2655 This structure conveys the client's Diffie-Hellman public value 2656 (Yc) if it was not already included in the client's certificate. 2657 The encoding used for Yc is determined by the enumerated 2658 PublicValueEncoding. This structure is a variant of the client key 2659 exchange message, and not a message in itself. 2661 Structure of this message: 2663 enum { implicit, explicit } PublicValueEncoding; 2665 implicit 2666 If the client has sent a certificate which contains a suitable 2667 Diffie-Hellman key (for fixed_dh client authentication) then Yc 2668 is implicit and does not need to be sent again. In this case, 2669 the client key exchange message will be sent, but it MUST be 2670 empty. 2672 explicit 2673 Yc needs to be sent. 2675 struct { 2676 select (PublicValueEncoding) { 2677 case implicit: struct { }; 2678 case explicit: opaque dh_Yc<1..2^16-1>; 2679 } dh_public; 2680 } ClientDiffieHellmanPublic; 2682 dh_Yc 2683 The client's Diffie-Hellman public value (Yc). 2685 7.4.8. Certificate verify 2687 When this message will be sent: 2689 This message is used to provide explicit verification of a client 2690 certificate. This message is only sent following a client 2691 certificate that has signing capability (i.e. all certificates 2692 except those containing fixed Diffie-Hellman parameters). When 2693 sent, it MUST immediately follow the client key exchange message. 2695 Structure of this message: 2697 struct { 2698 Signature signature; 2699 } CertificateVerify; 2701 The Signature type is defined in 7.4.3. 2703 The hash algorithm is denoted Hash below. 2705 CertificateVerify.signature.hash = Hash(handshake_messages); 2707 The hash and signature algorithms MUST be one of those present in the 2708 supported_signature_algorithms field of the CertificateRequest 2709 message. In addition, the hash and signature algorithms MUST be 2710 compatible with the key in the client's end-entity certificate. RSA 2711 keys MAY be used with any permitted hash algorith, subject to 2712 restrictions in the certificate, if any. 2714 Because DSA signatures do not contain any secure indication of hash 2715 algorithm, there is a risk of hash substitution if multiple hashes 2716 may be used with any key. Currently, DSS [DSS] may only be used with 2717 SHA-1. Future revisions of DSS [DSS-3] are expected to allow other 2718 digest algorithms, as well as guidance as to which digest algorithms 2719 should be used with each key size. In addition, future revisions of 2720 [PKIX] may specify mechanisms for certificates to indicate which 2721 digest algorithms are to be used with DSA. 2723 Here handshake_messages refers to all handshake messages sent or 2724 received starting at client hello up to but not including this 2725 message, including the type and length fields of the handshake 2726 messages. This is the concatenation of all the Handshake structures 2727 as defined in 7.4 exchanged thus far. 2729 7.4.9. Finished 2731 When this message will be sent: 2733 A finished message is always sent immediately after a change 2734 cipher spec message to verify that the key exchange and 2735 authentication processes were successful. It is essential that a 2736 change cipher spec message be received between the other handshake 2737 messages and the Finished message. 2739 Meaning of this message: 2741 The finished message is the first protected with the just- 2742 negotiated algorithms, keys, and secrets. Recipients of finished 2743 messages MUST verify that the contents are correct. Once a side 2744 has sent its Finished message and received and validated the 2745 Finished message from its peer, it may begin to send and receive 2746 application data over the connection. 2748 Structure of this message: 2750 struct { 2751 opaque verify_data[verify_data_length]; 2752 } Finished; 2754 verify_data 2755 PRF(master_secret, finished_label, Hash(handshake_messages)) 2756 [0..verify_data_length-1]; 2758 finished_label 2759 For Finished messages sent by the client, the string "client 2760 finished". For Finished messages sent by the server, the string 2761 "server finished". 2763 Hash denotes a Hash of the handshake messages. For the PRF defined 2764 in Section 5, the Hash MUST be the Hash used as the basis for the 2765 PRF. Any cipher suite which defines a different PRF MUST also 2766 define the Hash to use in the Finished computation. 2768 In previous versions of TLS, the verify_data was always 12 octets 2769 long. In the current version of TLS, it depends on the cipher 2770 suite. Any cipher suite which does not explicitly specify 2771 verify_data_length has a verify_data_length equal to 12. This 2772 includes all existing cipher suites. Note that this 2773 representation has the same encoding as with previous versions. 2774 Future cipher suites MAY specify other lengths but such length 2775 MUST be at least 12 bytes. 2777 handshake_messages 2778 All of the data from all messages in this handshake (not 2779 including any HelloRequest messages) up to but not including 2780 this message. This is only data visible at the handshake layer 2781 and does not include record layer headers. This is the 2782 concatenation of all the Handshake structures as defined in 2783 7.4, exchanged thus far. 2785 It is a fatal error if a finished message is not preceded by a change 2786 cipher spec message at the appropriate point in the handshake. 2788 The value handshake_messages includes all handshake messages starting 2789 at client hello up to, but not including, this finished message. This 2790 may be different from handshake_messages in Section 7.4.8 because it 2791 would include the certificate verify message (if sent). Also, the 2792 handshake_messages for the finished message sent by the client will 2793 be different from that for the finished message sent by the server, 2794 because the one that is sent second will include the prior one. 2796 Note: Change cipher spec messages, alerts, and any other record types 2797 are not handshake messages and are not included in the hash 2798 computations. Also, Hello Request messages are omitted from handshake 2799 hashes. 2801 8. Cryptographic Computations 2803 In order to begin connection protection, the TLS Record Protocol 2804 requires specification of a suite of algorithms, a master secret, and 2805 the client and server random values. The authentication, encryption, 2806 and MAC algorithms are determined by the cipher_suite selected by the 2807 server and revealed in the server hello message. The compression 2808 algorithm is negotiated in the hello messages, and the random values 2809 are exchanged in the hello messages. All that remains is to calculate 2810 the master secret. 2812 8.1. Computing the Master Secret 2814 For all key exchange methods, the same algorithm is used to convert 2815 the pre_master_secret into the master_secret. The pre_master_secret 2816 should be deleted from memory once the master_secret has been 2817 computed. 2819 master_secret = PRF(pre_master_secret, "master secret", 2820 ClientHello.random + ServerHello.random) 2821 [0..47]; 2823 The master secret is always exactly 48 bytes in length. The length of 2824 the premaster secret will vary depending on key exchange method. 2826 8.1.1. RSA 2828 When RSA is used for server authentication and key exchange, a 2829 48-byte pre_master_secret is generated by the client, encrypted under 2830 the server's public key, and sent to the server. The server uses its 2831 private key to decrypt the pre_master_secret. Both parties then 2832 convert the pre_master_secret into the master_secret, as specified 2833 above. 2835 8.1.2. Diffie-Hellman 2837 A conventional Diffie-Hellman computation is performed. The 2838 negotiated key (Z) is used as the pre_master_secret, and is converted 2839 into the master_secret, as specified above. Leading bytes of Z that 2840 contain all zero bits are stripped before it is used as the 2841 pre_master_secret. 2843 Note: Diffie-Hellman parameters are specified by the server and may 2844 be either ephemeral or contained within the server's certificate. 2846 9. Mandatory Cipher Suites 2848 In the absence of an application profile standard specifying 2849 otherwise, a TLS compliant application MUST implement the cipher 2850 suite TLS_RSA_WITH_AES_128_CBC_SHA. 2852 10. Application Data Protocol 2854 Application data messages are carried by the Record Layer and are 2855 fragmented, compressed, and encrypted based on the current connection 2856 state. The messages are treated as transparent data to the record 2857 layer. 2859 11. Security Considerations 2860 Security issues are discussed throughout this memo, especially in 2861 Appendices D, E, and F. 2863 12. IANA Considerations 2865 This document uses several registries that were originally created in 2866 [TLS1.1]. IANA is requested to update (has updated) these to 2867 reference this document. The registries and their allocation policies 2868 (unchanged from [TLS1.1]) are listed below. 2870 - TLS ClientCertificateType Identifiers Registry: Future values in 2871 the range 0-63 (decimal) inclusive are assigned via Standards 2872 Action [RFC2434]. Values in the range 64-223 (decimal) inclusive 2873 are assigned Specification Required [RFC2434]. Values from 224-255 2874 (decimal) inclusive are reserved for Private Use [RFC2434]. 2876 - TLS Cipher Suite Registry: Future values with the first byte in 2877 the range 0-191 (decimal) inclusive are assigned via Standards 2878 Action [RFC2434]. Values with the first byte in the range 192-254 2879 (decimal) are assigned via Specification Required [RFC2434]. 2880 Values with the first byte 255 (decimal) are reserved for Private 2881 Use [RFC2434]. 2883 - TLS ContentType Registry: Future values are allocated via 2884 Standards Action [RFC2434]. 2886 - TLS Alert Registry: Future values are allocated via Standards 2887 Action [RFC2434]. 2889 - TLS HandshakeType Registry: Future values are allocated via 2890 Standards Action [RFC2434]. 2892 This document also uses a registry originally created in [RFC4366]. 2893 IANA is requested to update (has updated) it to reference this 2894 document. The registry and its allocation policy (unchanged from 2895 [RFC4366]) is listed below: 2897 - TLS ExtensionType Registry: Future values are allocated via IETF 2898 Consensus [RFC2434] 2900 In addition, this document defines two new registries to be 2901 maintained by IANA: 2903 - TLS SignatureAlgorithm Registry: The registry will be initially 2904 populated with the values described in Section 7.4.1.4.1. Future 2905 values in the range 0-63 (decimal) inclusive are assigned via 2906 Standards Action [RFC2434]. Values in the range 64-223 (decimal) 2907 inclusive are assigned via Specification Required [RFC2434]. 2909 Values from 224-255 (decimal) inclusive are reserved for Private 2910 Use [RFC2434]. 2912 - TLS HashAlgorithm Registry: The registry will be initially 2913 populated with the values described in Section 7.4.1.4.1. Future 2914 values in the range 0-63 (decimal) inclusive are assigned via 2915 Standards Action [RFC2434]. Values in the range 64-223 (decimal) 2916 inclusive are assigned via Specification Required [RFC2434]. 2917 Values from 224-255 (decimal) inclusive are reserved for Private 2918 Use [RFC2434]. 2920 This document defines one new TLS extension, signature_algorithms, 2921 which is to be (has been) allocated value TBD-BY-IANA in the TLS 2922 ExtensionType registry. 2924 This document also uses the TLS Compression Method Identifiers 2925 Registry, defined in [RFC3749]. IANA is requested to allocate value 2926 0 for the "null" compression method. 2928 Appendix A. Protocol Constant Values 2930 This section describes protocol types and constants. 2932 A.1. Record Layer 2934 struct { 2935 uint8 major, minor; 2936 } ProtocolVersion; 2938 ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/ 2940 enum { 2941 change_cipher_spec(20), alert(21), handshake(22), 2942 application_data(23), (255) 2943 } ContentType; 2945 struct { 2946 ContentType type; 2947 ProtocolVersion version; 2948 uint16 length; 2949 opaque fragment[TLSPlaintext.length]; 2950 } TLSPlaintext; 2952 struct { 2953 ContentType type; 2954 ProtocolVersion version; 2955 uint16 length; 2956 opaque fragment[TLSCompressed.length]; 2957 } TLSCompressed; 2959 struct { 2960 ContentType type; 2961 ProtocolVersion version; 2962 uint16 length; 2963 select (SecurityParameters.cipher_type) { 2964 case stream: GenericStreamCipher; 2965 case block: GenericBlockCipher; 2966 case aead: GenericAEADCipher; 2967 } fragment; 2968 } TLSCiphertext; 2970 stream-ciphered struct { 2971 opaque content[TLSCompressed.length]; 2972 opaque MAC[SecurityParameters.mac_length]; 2973 } GenericStreamCipher; 2974 struct { 2975 opaque IV[SecurityParameters.record_iv_length]; 2976 block-ciphered struct { 2977 opaque content[TLSCompressed.length]; 2978 opaque MAC[SecurityParameters.mac_length]; 2979 uint8 padding[GenericBlockCipher.padding_length]; 2980 uint8 padding_length; 2981 }; 2982 } GenericBlockCipher; 2984 aead-ciphered struct { 2985 opaque IV[SecurityParameters.record_iv_length]; 2986 opaque aead_output[AEADEncrypted.length]; 2987 } GenericAEADCipher; 2989 A.2. Change Cipher Specs Message 2991 struct { 2992 enum { change_cipher_spec(1), (255) } type; 2993 } ChangeCipherSpec; 2995 A.3. Alert Messages 2997 enum { warning(1), fatal(2), (255) } AlertLevel; 2999 enum { 3000 close_notify(0), 3001 unexpected_message(10), 3002 bad_record_mac(20), 3003 decryption_failed_RESERVED(21), 3004 record_overflow(22), 3005 decompression_failure(30), 3006 handshake_failure(40), 3007 no_certificate_RESERVED(41), 3008 bad_certificate(42), 3009 unsupported_certificate(43), 3010 certificate_revoked(44), 3011 certificate_expired(45), 3012 certificate_unknown(46), 3013 illegal_parameter(47), 3014 unknown_ca(48), 3015 access_denied(49), 3016 decode_error(50), 3017 decrypt_error(51), 3018 export_restriction_RESERVED(60), 3019 protocol_version(70), 3020 insufficient_security(71), 3021 internal_error(80), 3022 user_canceled(90), 3023 no_renegotiation(100), 3024 unsupported_extension(110), /* new */ 3025 (255) 3026 } AlertDescription; 3028 struct { 3029 AlertLevel level; 3030 AlertDescription description; 3031 } Alert; 3033 A.4. Handshake Protocol 3035 enum { 3036 hello_request(0), client_hello(1), server_hello(2), 3037 certificate(11), server_key_exchange (12), 3038 certificate_request(13), server_hello_done(14), 3039 certificate_verify(15), client_key_exchange(16), 3040 finished(20) 3041 (255) 3042 } HandshakeType; 3044 struct { 3045 HandshakeType msg_type; 3046 uint24 length; 3047 select (HandshakeType) { 3048 case hello_request: HelloRequest; 3049 case client_hello: ClientHello; 3050 case server_hello: ServerHello; 3051 case certificate: Certificate; 3052 case server_key_exchange: ServerKeyExchange; 3053 case certificate_request: CertificateRequest; 3054 case server_hello_done: ServerHelloDone; 3055 case certificate_verify: CertificateVerify; 3056 case client_key_exchange: ClientKeyExchange; 3057 case finished: Finished; 3058 } body; 3059 } Handshake; 3061 A.4.1. Hello Messages 3063 struct { } HelloRequest; 3065 struct { 3066 uint32 gmt_unix_time; 3067 opaque random_bytes[28]; 3068 } Random; 3069 opaque SessionID<0..32>; 3071 uint8 CipherSuite[2]; 3073 enum { null(0), (255) } CompressionMethod; 3075 struct { 3076 ProtocolVersion client_version; 3077 Random random; 3078 SessionID session_id; 3079 CipherSuite cipher_suites<2..2^16-2>; 3080 CompressionMethod compression_methods<1..2^8-1>; 3081 select (extensions_present) { 3082 case false: 3083 struct {}; 3084 case true: 3085 Extension extensions<0..2^16-1>; 3086 }; 3087 } ClientHello; 3089 struct { 3090 ProtocolVersion server_version; 3091 Random random; 3092 SessionID session_id; 3093 CipherSuite cipher_suite; 3094 CompressionMethod compression_method; 3095 select (extensions_present) { 3096 case false: 3097 struct {}; 3098 case true: 3099 Extension extensions<0..2^16-1>; 3100 }; 3101 } ServerHello; 3103 struct { 3104 ExtensionType extension_type; 3105 opaque extension_data<0..2^16-1>; 3106 } Extension; 3108 enum { 3109 signature_algorithms(TBD-BY-IANA), (65535) 3110 } ExtensionType; 3112 enum{ 3113 none(0), md5(1), sha1(2), sha256(3), sha384(4), 3114 sha512(5), (255) 3115 } HashAlgorithm; 3116 enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm; 3118 struct { 3119 HashAlgorithm hash; 3120 SignatureAlgorithm signature; 3121 } SignatureAndHashAlgorithm; 3123 SignatureAndHashAlgorithm 3124 supported_signature_algorithms<2..2^16-1>; 3126 A.4.2. Server Authentication and Key Exchange Messages 3128 opaque ASN.1Cert<2^24-1>; 3130 struct { 3131 ASN.1Cert certificate_list<0..2^24-1>; 3132 } Certificate; 3134 enum { rsa, diffie_hellman } KeyExchangeAlgorithm; 3136 struct { 3137 opaque dh_p<1..2^16-1>; 3138 opaque dh_g<1..2^16-1>; 3139 opaque dh_Ys<1..2^16-1>; 3140 } ServerDHParams; 3142 struct { 3143 select (KeyExchangeAlgorithm) { 3144 case diffie_hellman: 3145 ServerDHParams params; 3146 Signature signed_params; 3147 } 3148 } ServerKeyExchange; 3150 struct { 3151 select (KeyExchangeAlgorithm) { 3152 case diffie_hellman: 3153 ServerDHParams params; 3154 }; 3155 } ServerParams; 3157 struct { 3158 select (SignatureAlgorithm) { 3159 case anonymous: struct { }; 3160 case rsa: 3161 SignatureAndHashAlgorithm signature_algorithm; /*NEW*/ 3162 digitally-signed struct { 3163 opaque hash[Hash.length]; 3165 }; 3166 case dsa: 3167 SignatureAndHashAlgorithm signature_algorithm; /*NEW*/ 3168 digitally-signed struct { 3169 opaque hash[Hash.length]; 3170 }; 3171 }; 3172 }; 3173 } Signature; 3175 enum { 3176 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), 3177 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), 3178 fortezza_dms_RESERVED(20), 3179 (255) 3180 } ClientCertificateType; 3182 opaque DistinguishedName<1..2^16-1>; 3184 struct { 3185 ClientCertificateType certificate_types<1..2^8-1>; 3186 DistinguishedName certificate_authorities<0..2^16-1>; 3187 } CertificateRequest; 3189 struct { } ServerHelloDone; 3191 A.4.3. Client Authentication and Key Exchange Messages 3193 struct { 3194 select (KeyExchangeAlgorithm) { 3195 case rsa: EncryptedPreMasterSecret; 3196 case diffie_hellman: ClientDiffieHellmanPublic; 3197 } exchange_keys; 3198 } ClientKeyExchange; 3200 struct { 3201 ProtocolVersion client_version; 3202 opaque random[46]; 3203 } PreMasterSecret; 3205 struct { 3206 public-key-encrypted PreMasterSecret pre_master_secret; 3207 } EncryptedPreMasterSecret; 3209 enum { implicit, explicit } PublicValueEncoding; 3211 struct { 3212 select (PublicValueEncoding) { 3213 case implicit: struct {}; 3214 case explicit: opaque DH_Yc<1..2^16-1>; 3215 } dh_public; 3216 } ClientDiffieHellmanPublic; 3218 struct { 3219 Signature signature; 3220 } CertificateVerify; 3222 A.4.4. Handshake Finalization Message 3224 struct { 3225 opaque verify_data[verify_data_length]; 3226 } Finished; 3228 A.5. The CipherSuite 3230 The following values define the CipherSuite codes used in the client 3231 hello and server hello messages. 3233 A CipherSuite defines a cipher specification supported in TLS Version 3234 1.2. 3236 TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a 3237 TLS connection during the first handshake on that channel, but MUST 3238 not be negotiated, as it provides no more protection than an 3239 unsecured connection. 3241 CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; 3243 The following CipherSuite definitions require that the server provide 3244 an RSA certificate that can be used for key exchange. The server may 3245 request either any signature-capable certificate in the certificate 3246 request message. 3248 CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; 3249 CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; 3250 CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; 3251 CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; 3252 CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; 3253 CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F }; 3254 CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 }; 3256 The following CipherSuite definitions are used for server- 3257 authenticated (and optionally client-authenticated) Diffie-Hellman. 3258 DH denotes cipher suites in which the server's certificate contains 3259 the Diffie-Hellman parameters signed by the certificate authority 3260 (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman 3261 parameters are signed by a a signature-capable certificate, which has 3262 been signed by the CA. The signing algorithm used is specified after 3263 the DH or DHE parameter. The server can request any signature-capable 3264 certificate from the client for client authentication or it may 3265 request a Diffie-Hellman certificate. Any Diffie-Hellman certificate 3266 provided by the client must use the parameters (group and generator) 3267 described by the server. 3269 CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; 3270 CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; 3271 CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; 3272 CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; 3273 CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 }; 3274 CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 }; 3275 CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 }; 3276 CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 }; 3277 CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 }; 3278 CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 }; 3279 CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 }; 3280 CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 }; 3282 The following cipher suites are used for completely anonymous Diffie- 3283 Hellman communications in which neither party is authenticated. Note 3284 that this mode is vulnerable to man-in-the-middle attacks. Using 3285 this mode therefore is of limited use: These ciphersuites MUST NOT be 3286 used by TLS 1.2 implementations unless the application layer has 3287 specifically requested to allow anonymous key exchange. (Anonymous 3288 key exchange may sometimes be acceptable, for example, to support 3289 opportunistic encryption when no set-up for authentication is in 3290 place, or when TLS is used as part of more complex security protocols 3291 that have other means to ensure authentication.) 3293 CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; 3294 CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; 3295 CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; 3296 CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; 3298 Note that using non-anonymous key exchange without actually verifying 3299 the key exchange is essentially equivalent to anonymous key exchange, 3300 and the same precautions apply. While non-anonymous key exchange 3301 will generally involve a higher computational and communicational 3302 cost than anonymous key exchange, it may be in the interest of 3303 interoperability not to disable non-anonymous key exchange when the 3304 application layer is allowing anonymous key exchange. 3306 SSLv3, TLS 1.0, and TLS 1.1 supported DES and IDEA. DES had a 56-bit 3307 key which is too weak for modern use. Triple-DES (3DES) has an 3308 effective key strength of 112 bits and is still acceptable. IDEA and 3309 is no longer in wide use. Cipher suites using RC2, DES, and IDEA are 3310 hereby deprecated for TLS 1.2. TLS 1.2 implementations MUST NOT 3311 negotiate these cipher suites in TLS 1.2 mode. However, for backward 3312 compatibility they may be offered in the ClientHello for use with TLS 3313 1.0 or SSLv3 only servers. TLS 1.2 clients MUST check that the server 3314 did not choose one of these cipher suites during the handshake. These 3315 ciphersuites are listed below for informational purposes and to 3316 reserve the numbers. 3318 CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; 3319 CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; 3320 CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; 3321 CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; 3322 CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; 3323 CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; 3324 CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; 3326 When SSLv3 and TLS 1.0 were designed, the United States restricted 3327 the export of cryptographic software containing certain strong 3328 encryption algorithms. A series of cipher suites were designed to 3329 operate at reduced key lengths in order to comply with those 3330 regulations. Due to advances in computer performance, these 3331 algorithms are now unacceptably weak and export restrictions have 3332 since been loosened. TLS 1.2 implementations MUST NOT negotiate these 3333 cipher suites in TLS 1.2 mode. However, for backward compatibility 3334 they may be offered in the ClientHello for use with TLS 1.0 or SSLv3 3335 only servers. TLS 1.2 clients MUST check that the server did not 3336 choose one of these cipher suites during the handshake. These 3337 ciphersuites are listed below for informational purposes and to 3338 reserve the numbers. 3340 CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; 3341 CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; 3342 CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; 3343 CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; 3344 CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; 3345 CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; 3346 CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; 3347 CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; 3348 CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; 3350 New cipher suite values are assigned by IANA as described in Section 3351 12. 3353 Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are 3354 reserved to avoid collision with Fortezza-based cipher suites in SSL 3355 3. 3357 A.6. The Security Parameters 3359 These security parameters are determined by the TLS Handshake 3360 Protocol and provided as parameters to the TLS Record Layer in order 3361 to initialize a connection state. SecurityParameters includes: 3363 enum { null(0), (255) } CompressionMethod; 3365 enum { server, client } ConnectionEnd; 3367 enum { tls_prf_sha256 } PRFAlgorithm; 3369 enum { null, rc4, 3des, aes } 3370 BulkCipherAlgorithm; 3372 enum { stream, block, aead } CipherType; 3374 enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384, 3375 hmac_sha512} MACAlgorithm; 3377 /* The algorithms specified in CompressionMethod, 3378 BulkCipherAlgorithm, and MACAlgorithm may be added to. */ 3380 struct { 3381 ConnectionEnd entity; 3382 PRFAlgorithm prf_algorithm; 3383 BulkCipherAlgorithm bulk_cipher_algorithm; 3384 CipherType cipher_type; 3385 uint8 enc_key_length; 3386 uint8 block_length; 3387 uint8 fixed_iv_length; 3388 uint8 record_iv_length; 3389 MACAlgorithm mac_algorithm; 3390 uint8 mac_length; 3391 uint8 mac_key_length; 3392 CompressionMethod compression_algorithm; 3393 opaque master_secret[48]; 3394 opaque client_random[32]; 3395 opaque server_random[32]; 3396 } SecurityParameters; 3398 Appendix B. Glossary 3400 Advanced Encryption Standard (AES) 3401 AES is a widely used symmetric encryption algorithm. AES is a 3402 block cipher with a 128, 192, or 256 bit keys and a 16 byte block 3403 size. [AES] TLS currently only supports the 128 and 256 bit key 3404 sizes. 3406 application protocol 3407 An application protocol is a protocol that normally layers 3408 directly on top of the transport layer (e.g., TCP/IP). Examples 3409 include HTTP, TELNET, FTP, and SMTP. 3411 asymmetric cipher 3412 See public key cryptography. 3414 authenticated encryption with additional data (AEAD) 3415 A symmetric encryption algorithm that simultaneously provides 3416 confidentiality and message integrity. 3418 authentication 3419 Authentication is the ability of one entity to determine the 3420 identity of another entity. 3422 block cipher 3423 A block cipher is an algorithm that operates on plaintext in 3424 groups of bits, called blocks. 64 bits is a common block size. 3426 bulk cipher 3427 A symmetric encryption algorithm used to encrypt large quantities 3428 of data. 3430 cipher block chaining (CBC) 3431 CBC is a mode in which every plaintext block encrypted with a 3432 block cipher is first exclusive-ORed with the previous ciphertext 3433 block (or, in the case of the first block, with the initialization 3434 vector). For decryption, every block is first decrypted, then 3435 exclusive-ORed with the previous ciphertext block (or IV). 3437 certificate 3438 As part of the X.509 protocol (a.k.a. ISO Authentication 3439 framework), certificates are assigned by a trusted Certificate 3440 Authority and provide a strong binding between a party's identity 3441 or some other attributes and its public key. 3443 client 3444 The application entity that initiates a TLS connection to a 3445 server. This may or may not imply that the client initiated the 3446 underlying transport connection. The primary operational 3447 difference between the server and client is that the server is 3448 generally authenticated, while the client is only optionally 3449 authenticated. 3451 client write key 3452 The key used to encrypt data written by the client. 3454 client write MAC key 3455 The secret data used to authenticate data written by the client. 3457 connection 3458 A connection is a transport (in the OSI layering model definition) 3459 that provides a suitable type of service. For TLS, such 3460 connections are peer-to-peer relationships. The connections are 3461 transient. Every connection is associated with one session. 3463 Data Encryption Standard 3464 DES is a very widely used symmetric encryption algorithm. DES is a 3465 block cipher with a 56 bit key and an 8 byte block size. Note that 3466 in TLS, for key generation purposes, DES is treated as having an 8 3467 byte key length (64 bits), but it still only provides 56 bits of 3468 protection. (The low bit of each key byte is presumed to be set to 3469 produce odd parity in that key byte.) DES can also be operated in 3470 a mode where three independent keys and three encryptions are used 3471 for each block of data; this uses 168 bits of key (24 bytes in the 3472 TLS key generation method) and provides the equivalent of 112 bits 3473 of security. [DES], [3DES] 3475 Digital Signature Standard (DSS) 3476 A standard for digital signing, including the Digital Signing 3477 Algorithm, approved by the National Institute of Standards and 3478 Technology, defined in NIST FIPS PUB 186, "Digital Signature 3479 Standard", published May, 1994 by the U.S. Dept. of Commerce. 3480 [DSS] 3482 digital signatures 3483 Digital signatures utilize public key cryptography and one-way 3484 hash functions to produce a signature of the data that can be 3485 authenticated, and is difficult to forge or repudiate. 3487 handshake 3488 An initial negotiation between client and server that establishes 3489 the parameters of their transactions. 3491 Initialization Vector (IV) 3492 When a block cipher is used in CBC mode, the initialization vector 3493 is exclusive-ORed with the first plaintext block prior to 3494 encryption. 3496 IDEA 3497 A 64-bit block cipher designed by Xuejia Lai and James Massey. 3498 [IDEA] 3500 Message Authentication Code (MAC) 3501 A Message Authentication Code is a one-way hash computed from a 3502 message and some secret data. It is difficult to forge without 3503 knowing the secret data. Its purpose is to detect if the message 3504 has been altered. 3506 master secret 3507 Secure secret data used for generating encryption keys, MAC 3508 secrets, and IVs. 3510 MD5 3511 MD5 is a secure hashing function that converts an arbitrarily long 3512 data stream into a hash of fixed size (16 bytes). [MD5] 3514 public key cryptography 3515 A class of cryptographic techniques employing two-key ciphers. 3516 Messages encrypted with the public key can only be decrypted with 3517 the associated private key. Conversely, messages signed with the 3518 private key can be verified with the public key. 3520 one-way hash function 3521 A one-way transformation that converts an arbitrary amount of data 3522 into a fixed-length hash. It is computationally hard to reverse 3523 the transformation or to find collisions. MD5 and SHA are examples 3524 of one-way hash functions. 3526 RC2 3527 A block cipher developed by Ron Rivest, described in [RC2]. 3529 RC4 3530 A stream cipher invented by Ron Rivest. A compatible cipher is 3531 described in [SCH]. 3533 RSA 3534 A very widely used public-key algorithm that can be used for 3535 either encryption or digital signing. [RSA] 3537 server 3538 The server is the application entity that responds to requests for 3539 connections from clients. See also under client. 3541 session 3542 A TLS session is an association between a client and a server. 3543 Sessions are created by the handshake protocol. Sessions define a 3544 set of cryptographic security parameters that can be shared among 3545 multiple connections. Sessions are used to avoid the expensive 3546 negotiation of new security parameters for each connection. 3548 session identifier 3549 A session identifier is a value generated by a server that 3550 identifies a particular session. 3552 server write key 3553 The key used to encrypt data written by the server. 3555 server write MAC key 3556 The secret data used to authenticate data written by the server. 3558 SHA 3559 The Secure Hash Algorithm is defined in FIPS PUB 180-2. It 3560 produces a 20-byte output. Note that all references to SHA 3561 actually use the modified SHA-1 algorithm. [SHA] 3563 SSL 3564 Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on 3565 SSL Version 3.0 3567 stream cipher 3568 An encryption algorithm that converts a key into a 3569 cryptographically strong keystream, which is then exclusive-ORed 3570 with the plaintext. 3572 symmetric cipher 3573 See bulk cipher. 3575 Transport Layer Security (TLS) 3576 This protocol; also, the Transport Layer Security working group of 3577 the Internet Engineering Task Force (IETF). See "Comments" at the 3578 end of this document. 3580 Appendix C. CipherSuite Definitions 3582 CipherSuite Key Cipher Hash 3583 Exchange 3585 TLS_NULL_WITH_NULL_NULL NULL NULL NULL 3586 TLS_RSA_WITH_NULL_MD5 RSA NULL MD5 3587 TLS_RSA_WITH_NULL_SHA RSA NULL SHA 3588 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 3589 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA 3590 TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA 3591 TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA 3592 TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA 3593 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA 3594 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA 3595 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA 3596 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA 3597 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 3598 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA 3599 TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA 3600 TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA 3601 TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA 3602 TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA 3603 TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA 3604 TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA 3605 TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA 3606 TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA 3607 TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA 3608 TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA 3610 Key Expanded IV Block 3611 Cipher Type Material Key Material Size Size 3613 NULL Stream 0 0 0 N/A 3614 RC4_128 Stream 16 16 0 N/A 3615 3DES_EDE_CBC Block 24 24 8 8 3617 Type 3618 Indicates whether this is a stream cipher or a block cipher 3619 running in CBC mode. 3621 Key Material 3622 The number of bytes from the key_block that are used for 3623 generating the write keys. 3625 Expanded Key Material 3626 The number of bytes actually fed into the encryption algorithm. 3628 IV Size 3629 The amount of data needed to be generated for the initialization 3630 vector. Zero for stream ciphers; equal to the block size for block 3631 ciphers (this is equal to SecurityParameters.record_iv_length). 3633 Block Size 3634 The amount of data a block cipher enciphers in one chunk; a block 3635 cipher running in CBC mode can only encrypt an even multiple of 3636 its block size. 3638 Appendix D. Implementation Notes 3640 The TLS protocol cannot prevent many common security mistakes. This 3641 section provides several recommendations to assist implementors. 3643 D.1 Random Number Generation and Seeding 3645 TLS requires a cryptographically secure pseudorandom number generator 3646 (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs 3647 based on secure hash operations, most notably SHA-1, are acceptable, 3648 but cannot provide more security than the size of the random number 3649 generator state. 3651 To estimate the amount of seed material being produced, add the 3652 number of bits of unpredictable information in each seed byte. For 3653 example, keystroke timing values taken from a PC compatible's 18.2 Hz 3654 timer provide 1 or 2 secure bits each, even though the total size of 3655 the counter value is 16 bits or more. Seeding a 128-bit PRNG would 3656 thus require approximately 100 such timer values. 3658 [RANDOM] provides guidance on the generation of random values. 3660 D.2 Certificates and Authentication 3662 Implementations are responsible for verifying the integrity of 3663 certificates and should generally support certificate revocation 3664 messages. Certificates should always be verified to ensure proper 3665 signing by a trusted Certificate Authority (CA). The selection and 3666 addition of trusted CAs should be done very carefully. Users should 3667 be able to view information about the certificate and root CA. 3669 D.3 CipherSuites 3671 TLS supports a range of key sizes and security levels, including some 3672 that provide no or minimal security. A proper implementation will 3673 probably not support many cipher suites. For instance, anonymous 3674 Diffie-Hellman is strongly discouraged because it cannot prevent man- 3675 in-the-middle attacks. Applications should also enforce minimum and 3676 maximum key sizes. For example, certificate chains containing 512-bit 3677 RSA keys or signatures are not appropriate for high-security 3678 applications. 3680 D.4 Implementation Pitfalls 3682 Implementation experience has shown that certain parts of earlier TLS 3683 specifications are not easy to understand, and have been a source of 3684 interoperability and security problems. Many of these areas have been 3685 clarified in this document, but this appendix contains a short list 3686 of the most important things that require special attention from 3687 implementors. 3689 TLS protocol issues: 3691 - Do you correctly handle handshake messages that are fragmented 3692 to multiple TLS records (see Section 6.2.1)? Including corner 3693 cases like a ClientHello that is split to several small 3694 fragments? 3696 - Do you ignore the TLS record layer version number in all TLS 3697 records before ServerHello (see Appendix E.1)? 3699 - Do you handle TLS extensions in ClientHello correctly, 3700 including omitting the extensions field completely? 3702 - Do you support renegotiation, both client and server initiated? 3703 While renegotiation is an optional feature, supporting 3704 it is highly recommended. 3706 - When the server has requested a client certificate, but no 3707 suitable certificate is available, do you correctly send 3708 an empty Certificate message, instead of omitting the whole 3709 message (see Section 7.4.6)? 3711 Cryptographic details: 3713 - In RSA-encrypted Premaster Secret, do you correctly send and 3714 verify the version number? When an error is encountered, do 3715 you continue the handshake to avoid the Bleichenbacher 3716 attack (see Section 7.4.7.1)? 3718 - What countermeasures do you use to prevent timing attacks against 3719 RSA decryption and signing operations (see Section 7.4.7.1)? 3721 - When verifying RSA signatures, do you accept both NULL and 3722 missing parameters (see Section 4.7)? Do you verify that the 3723 RSA padding doesn't have additional data after the hash value? 3724 [FI06] 3726 - When using Diffie-Hellman key exchange, do you correctly strip 3727 leading zero bytes from the negotiated key (see Section 8.1.2)? 3729 - Does your TLS client check that the Diffie-Hellman parameters 3730 sent by the server are acceptable (see Section F.1.1.3)? 3732 - How do you generate unpredictable IVs for CBC mode ciphers 3733 (see Section 6.2.3.2)? 3735 - How do you address CBC mode timing attacks (Section 6.2.3.2)? 3737 - Do you use a strong and, most importantly, properly seeded 3738 random number generator (see Appendix D.1) for generating the 3739 premaster secret (for RSA key exchange), Diffie-Hellman private 3740 values, the DSA "k" parameter, and other security-critical 3741 values? 3743 Appendix E. Backward Compatibility 3745 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 3747 Since there are various versions of TLS (1.0, 1.1, 1.2, and any 3748 future versions) and SSL (2.0 and 3.0), means are needed to negotiate 3749 the specific protocol version to use. The TLS protocol provides a 3750 built-in mechanism for version negotiation so as not to bother other 3751 protocol components with the complexities of version selection. 3753 TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use 3754 compatible ClientHello messages; thus, supporting all of them is 3755 relatively easy. Similarly, servers can easily handle clients trying 3756 to use future versions of TLS as long as the ClientHello format 3757 remains compatible, and the client support the highest protocol 3758 version available in the server. 3760 A TLS 1.2 client who wishes to negotiate with such older servers will 3761 send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in 3762 ClientHello.client_version. If the server does not support this 3763 version, it will respond with ServerHello containing an older version 3764 number. If the client agrees to use this version, the negotiation 3765 will proceed as appropriate for the negotiated protocol. 3767 If the version chosen by the server is not supported by the client 3768 (or not acceptable), the client MUST send a "protocol_version" alert 3769 message and close the connection. 3771 If a TLS server receives a ClientHello containing a version number 3772 greater than the highest version supported by the server, it MUST 3773 reply according to the highest version supported by the server. 3775 A TLS server can also receive a ClientHello containing version number 3776 smaller than the highest supported version. If the server wishes to 3777 negotiate with old clients, it will proceed as appropriate for the 3778 highest version supported by the server that is not greater than 3779 ClientHello.client_version. For example, if the server supports TLS 3780 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will 3781 proceed with a TLS 1.0 ServerHello. If server supports (or is willing 3782 to use) only versions greater than client_version, it MUST send a 3783 "protocol_version" alert message and close the connection. 3785 Whenever a client already knows the highest protocol known to a 3786 server (for example, when resuming a session), it SHOULD initiate the 3787 connection in that native protocol. 3789 Note: some server implementations are known to implement version 3790 negotiation incorrectly. For example, there are buggy TLS 1.0 servers 3791 that simply close the connection when the client offers a version 3792 newer than TLS 1.0. Also, it is known that some servers will refuse 3793 connection if any TLS extensions are included in ClientHello. 3794 Interoperability with such buggy servers is a complex topic beyond 3795 the scope of this document, and may require multiple connection 3796 attempts by the client. 3798 Earlier versions of the TLS specification were not fully clear on 3799 what the record layer version number (TLSPlaintext.version) should 3800 contain when sending ClientHello (i.e., before it is known which 3801 version of the protocol will be employed). Thus, TLS servers 3802 compliant with this specification MUST accept any value {03,XX} as 3803 the record layer version number for ClientHello. 3805 TLS clients that wish to negotiate with older servers MAY send any 3806 value {03,XX} as the record layer version number. Typical values 3807 would be {03,00}, the lowest version number supported by the client, 3808 and the value of ClientHello.client_version. No single value will 3809 guarantee interoperability with all old servers, but this is a 3810 complex topic beyond the scope of this document. 3812 E.2 Compatibility with SSL 2.0 3814 TLS 1.2 clients that wish to support SSL 2.0 servers MUST send 3815 version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST 3816 contain the same version number as would be used for ordinary 3817 ClientHello, and MUST encode the supported TLS ciphersuites in the 3818 CIPHER-SPECS-DATA field as described below. 3820 Warning: The ability to send version 2.0 CLIENT-HELLO messages will 3821 be phased out with all due haste, since the newer ClientHello format 3822 provides better mechanisms for moving to newer versions and 3823 negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0. 3825 However, even TLS servers that do not support SSL 2.0 MAY accept 3826 version 2.0 CLIENT-HELLO messages. The message is presented below in 3827 sufficient detail for TLS server implementors; the true definition is 3828 still assumed to be [SSL2]. 3830 For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same 3831 way as a ClientHello with a "null" compression method and no 3832 extensions. Note that this message MUST be sent directly on the wire, 3833 not wrapped as a TLS record. For the purposes of calculating Finished 3834 and CertificateVerify, the msg_length field is not considered to be a 3835 part of the handshake message. 3837 uint8 V2CipherSpec[3]; 3838 struct { 3839 uint16 msg_length; 3840 uint8 msg_type; 3841 Version version; 3842 uint16 cipher_spec_length; 3843 uint16 session_id_length; 3844 uint16 challenge_length; 3845 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; 3846 opaque session_id[V2ClientHello.session_id_length]; 3847 opaque challenge[V2ClientHello.challenge_length; 3848 } V2ClientHello; 3850 msg_length 3851 The highest bit MUST be 1; the remaining bits contain the length 3852 of the following data in bytes. 3854 msg_type 3855 This field, in conjunction with the version field, identifies a 3856 version 2 client hello message. The value MUST be one (1). 3858 version 3859 Equal to ClientHello.client_version. 3861 cipher_spec_length 3862 This field is the total length of the field cipher_specs. It 3863 cannot be zero and MUST be a multiple of the V2CipherSpec length 3864 (3). 3866 session_id_length 3867 This field MUST have a value of zero for a client that claims to 3868 support TLS 1.2. 3870 challenge_length 3871 The length in bytes of the client's challenge to the server to 3872 authenticate itself. Historically, permissible values are between 3873 16 and 32 bytes inclusive. When using the SSLv2 backward 3874 compatible handshake the client SHOULD use a 32 byte challenge. 3876 cipher_specs 3877 This is a list of all CipherSpecs the client is willing and able 3878 to use. In addition to the 2.0 cipher specs defined in [SSL2], 3879 this includes the TLS cipher suites normally sent in 3880 ClientHello.cipher_suites, each cipher suite prefixed by a zero 3881 byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as 3882 {0x00,0x00,0x0A}. 3884 session_id 3885 This field MUST be empty. 3887 challenge 3888 Corresponds to ClientHello.random. If the challenge length is less 3889 than 32, the TLS server will pad the data with leading (note: not 3890 trailing) zero bytes to make it 32 bytes long. 3892 Note: Requests to resume a TLS session MUST use a TLS client hello. 3894 E.3. Avoiding Man-in-the-Middle Version Rollback 3896 When TLS clients fall back to Version 2.0 compatibility mode, they 3897 MUST use special PKCS#1 block formatting. This is done so that TLS 3898 servers will reject Version 2.0 sessions with TLS-capable clients. 3900 When a client negotiates SSL 2.0 but also supports TLS, it MUST set 3901 the right-hand (least-significant) 8 random bytes of the PKCS padding 3902 (not including the terminal null of the padding) for the RSA 3903 encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY 3904 to 0x03 (the other padding bytes are random). 3906 When a TLS-capable server negotiates SSL 2.0 it SHOULD, after 3907 decrypting the ENCRYPTED-KEY-DATA field, check that these eight 3908 padding bytes are 0x03. If they are not, the server SHOULD generate a 3909 random value for SECRET-KEY-DATA, and continue the handshake (which 3910 will eventually fail since the keys will not match). Note that 3911 reporting the error situation to the client could make the server 3912 vulnerable to attacks described in [BLEI]. 3914 Appendix F. Security Analysis 3916 The TLS protocol is designed to establish a secure connection between 3917 a client and a server communicating over an insecure channel. This 3918 document makes several traditional assumptions, including that 3919 attackers have substantial computational resources and cannot obtain 3920 secret information from sources outside the protocol. Attackers are 3921 assumed to have the ability to capture, modify, delete, replay, and 3922 otherwise tamper with messages sent over the communication channel. 3923 This appendix outlines how TLS has been designed to resist a variety 3924 of attacks. 3926 F.1. Handshake Protocol 3928 The handshake protocol is responsible for selecting a CipherSpec and 3929 generating a Master Secret, which together comprise the primary 3930 cryptographic parameters associated with a secure session. The 3931 handshake protocol can also optionally authenticate parties who have 3932 certificates signed by a trusted certificate authority. 3934 F.1.1. Authentication and Key Exchange 3936 TLS supports three authentication modes: authentication of both 3937 parties, server authentication with an unauthenticated client, and 3938 total anonymity. Whenever the server is authenticated, the channel is 3939 secure against man-in-the-middle attacks, but completely anonymous 3940 sessions are inherently vulnerable to such attacks. Anonymous 3941 servers cannot authenticate clients. If the server is authenticated, 3942 its certificate message must provide a valid certificate chain 3943 leading to an acceptable certificate authority. Similarly, 3944 authenticated clients must supply an acceptable certificate to the 3945 server. Each party is responsible for verifying that the other's 3946 certificate is valid and has not expired or been revoked. 3948 The general goal of the key exchange process is to create a 3949 pre_master_secret known to the communicating parties and not to 3950 attackers. The pre_master_secret will be used to generate the 3951 master_secret (see Section 8.1). The master_secret is required to 3952 generate the finished messages, encryption keys, and MAC keys (see 3953 Sections 7.4.9 and 6.3). By sending a correct finished message, 3954 parties thus prove that they know the correct pre_master_secret. 3956 F.1.1.1. Anonymous Key Exchange 3958 Completely anonymous sessions can be established using Diffie-Hellman 3959 for key exchange. The server's public parameters are contained in the 3960 server key exchange message and the client's are sent in the client 3961 key exchange message. Eavesdroppers who do not know the private 3962 values should not be able to find the Diffie-Hellman result (i.e. the 3963 pre_master_secret). 3965 Warning: Completely anonymous connections only provide protection 3966 against passive eavesdropping. Unless an independent tamper-proof 3967 channel is used to verify that the finished messages were not 3968 replaced by an attacker, server authentication is required in 3969 environments where active man-in-the-middle attacks are a concern. 3971 F.1.1.2. RSA Key Exchange and Authentication 3973 With RSA, key exchange and server authentication are combined. The 3974 public key is contained in the server's certificate. Note that 3975 compromise of the server's static RSA key results in a loss of 3976 confidentiality for all sessions protected under that static key. TLS 3977 users desiring Perfect Forward Secrecy should use DHE cipher suites. 3978 The damage done by exposure of a private key can be limited by 3979 changing one's private key (and certificate) frequently. 3981 After verifying the server's certificate, the client encrypts a 3982 pre_master_secret with the server's public key. By successfully 3983 decoding the pre_master_secret and producing a correct finished 3984 message, the server demonstrates that it knows the private key 3985 corresponding to the server certificate. 3987 When RSA is used for key exchange, clients are authenticated using 3988 the certificate verify message (see Section 7.4.8). The client signs 3989 a value derived from all preceding handshake messages. These 3990 handshake messages include the server certificate, which binds the 3991 signature to the server, and ServerHello.random, which binds the 3992 signature to the current handshake process. 3994 F.1.1.3. Diffie-Hellman Key Exchange with Authentication 3996 When Diffie-Hellman key exchange is used, the server can either 3997 supply a certificate containing fixed Diffie-Hellman parameters or 3998 use the server key exchange message to send a set of temporary 3999 Diffie-Hellman parameters signed with a DSS or RSA certificate. 4000 Temporary parameters are hashed with the hello.random values before 4001 signing to ensure that attackers do not replay old parameters. In 4002 either case, the client can verify the certificate or signature to 4003 ensure that the parameters belong to the server. 4005 If the client has a certificate containing fixed Diffie-Hellman 4006 parameters, its certificate contains the information required to 4007 complete the key exchange. Note that in this case the client and 4008 server will generate the same Diffie-Hellman result (i.e., 4009 pre_master_secret) every time they communicate. To prevent the 4010 pre_master_secret from staying in memory any longer than necessary, 4011 it should be converted into the master_secret as soon as possible. 4012 Client Diffie-Hellman parameters must be compatible with those 4013 supplied by the server for the key exchange to work. 4015 If the client has a standard DSS or RSA certificate or is 4016 unauthenticated, it sends a set of temporary parameters to the server 4017 in the client key exchange message, then optionally uses a 4018 certificate verify message to authenticate itself. 4020 If the same DH keypair is to be used for multiple handshakes, either 4021 because the client or server has a certificate containing a fixed DH 4022 keypair or because the server is reusing DH keys, care must be taken 4023 to prevent small subgroup attacks. Implementations SHOULD follow the 4024 guidelines found in [SUBGROUP]. 4026 Small subgroup attacks are most easily avoided by using one of the 4027 DHE ciphersuites and generating a fresh DH private key (X) for each 4028 handshake. If a suitable base (such as 2) is chosen, g^X mod p can be 4029 computed very quickly, therefore the performance cost is minimized. 4030 Additionally, using a fresh key for each handshake provides Perfect 4031 Forward Secrecy. Implementations SHOULD generate a new X for each 4032 handshake when using DHE ciphersuites. 4034 Because TLS allows the server to provide arbitrary DH groups, the 4035 client should verify that the DH group is of suitable size as defined 4036 by local policy. The client SHOULD also verify that the DH public 4037 exponent appears to be of adequate size. [KEYSIZ] provides a useful 4038 guide to the strength of various group sizes. The server MAY choose 4039 to assist the client by providing a known group, such as those 4040 defined in [IKEALG] or [MODP]. These can be verified by simple 4041 comparison. 4043 F.1.2. Version Rollback Attacks 4045 Because TLS includes substantial improvements over SSL Version 2.0, 4046 attackers may try to make TLS-capable clients and servers fall back 4047 to Version 2.0. This attack can occur if (and only if) two TLS- 4048 capable parties use an SSL 2.0 handshake. 4050 Although the solution using non-random PKCS #1 block type 2 message 4051 padding is inelegant, it provides a reasonably secure way for Version 4052 3.0 servers to detect the attack. This solution is not secure against 4053 attackers who can brute force the key and substitute a new ENCRYPTED- 4054 KEY-DATA message containing the same key (but with normal padding) 4055 before the application specified wait threshold has expired. Altering 4056 the padding of the least significant 8 bytes of the PKCS padding does 4057 not impact security for the size of the signed hashes and RSA key 4058 lengths used in the protocol, since this is essentially equivalent to 4059 increasing the input block size by 8 bytes. 4061 F.1.3. Detecting Attacks Against the Handshake Protocol 4063 An attacker might try to influence the handshake exchange to make the 4064 parties select different encryption algorithms than they would 4065 normally chooses. 4067 For this attack, an attacker must actively change one or more 4068 handshake messages. If this occurs, the client and server will 4069 compute different values for the handshake message hashes. As a 4070 result, the parties will not accept each others' finished messages. 4071 Without the master_secret, the attacker cannot repair the finished 4072 messages, so the attack will be discovered. 4074 F.1.4. Resuming Sessions 4076 When a connection is established by resuming a session, new 4077 ClientHello.random and ServerHello.random values are hashed with the 4078 session's master_secret. Provided that the master_secret has not been 4079 compromised and that the secure hash operations used to produce the 4080 encryption keys and MAC keys are secure, the connection should be 4081 secure and effectively independent from previous connections. 4082 Attackers cannot use known encryption keys or MAC secrets to 4083 compromise the master_secret without breaking the secure hash 4084 operations. 4086 Sessions cannot be resumed unless both the client and server agree. 4087 If either party suspects that the session may have been compromised, 4088 or that certificates may have expired or been revoked, it should 4089 force a full handshake. An upper limit of 24 hours is suggested for 4090 session ID lifetimes, since an attacker who obtains a master_secret 4091 may be able to impersonate the compromised party until the 4092 corresponding session ID is retired. Applications that may be run in 4093 relatively insecure environments should not write session IDs to 4094 stable storage. 4096 F.2. Protecting Application Data 4098 The master_secret is hashed with the ClientHello.random and 4099 ServerHello.random to produce unique data encryption keys and MAC 4100 secrets for each connection. 4102 Outgoing data is protected with a MAC before transmission. To prevent 4103 message replay or modification attacks, the MAC is computed from the 4104 MAC key, the sequence number, the message length, the message 4105 contents, and two fixed character strings. The message type field is 4106 necessary to ensure that messages intended for one TLS Record Layer 4107 client are not redirected to another. The sequence number ensures 4108 that attempts to delete or reorder messages will be detected. Since 4109 sequence numbers are 64 bits long, they should never overflow. 4110 Messages from one party cannot be inserted into the other's output, 4111 since they use independent MAC keys. Similarly, the server-write and 4112 client-write keys are independent, so stream cipher keys are used 4113 only once. 4115 If an attacker does break an encryption key, all messages encrypted 4116 with it can be read. Similarly, compromise of a MAC key can make 4117 message modification attacks possible. Because MACs are also 4118 encrypted, message-alteration attacks generally require breaking the 4119 encryption algorithm as well as the MAC. 4121 Note: MAC keys may be larger than encryption keys, so messages can 4122 remain tamper resistant even if encryption keys are broken. 4124 F.3. Explicit IVs 4126 [CBCATT] describes a chosen plaintext attack on TLS that depends on 4127 knowing the IV for a record. Previous versions of TLS [TLS1.0] used 4128 the CBC residue of the previous record as the IV and therefore 4129 enabled this attack. This version uses an explicit IV in order to 4130 protect against this attack. 4132 F.4. Security of Composite Cipher Modes 4134 TLS secures transmitted application data via the use of symmetric 4135 encryption and authentication functions defined in the negotiated 4136 ciphersuite. The objective is to protect both the integrity and 4137 confidentiality of the transmitted data from malicious actions by 4138 active attackers in the network. It turns out that the order in 4139 which encryption and authentication functions are applied to the data 4140 plays an important role for achieving this goal [ENCAUTH]. 4142 The most robust method, called encrypt-then-authenticate, first 4143 applies encryption to the data and then applies a MAC to the 4144 ciphertext. This method ensures that the integrity and 4145 confidentiality goals are obtained with ANY pair of encryption and 4146 MAC functions, provided that the former is secure against chosen 4147 plaintext attacks and that the MAC is secure against chosen-message 4148 attacks. TLS uses another method, called authenticate-then-encrypt, 4149 in which first a MAC is computed on the plaintext and then the 4150 concatenation of plaintext and MAC is encrypted. This method has 4151 been proven secure for CERTAIN combinations of encryption functions 4152 and MAC functions, but it is not guaranteed to be secure in general. 4153 In particular, it has been shown that there exist perfectly secure 4154 encryption functions (secure even in the information-theoretic sense) 4155 that combined with any secure MAC function, fail to provide the 4156 confidentiality goal against an active attack. Therefore, new 4157 ciphersuites and operation modes adopted into TLS need to be analyzed 4158 under the authenticate-then-encrypt method to verify that they 4159 achieve the stated integrity and confidentiality goals. 4161 Currently, the security of the authenticate-then-encrypt method has 4162 been proven for some important cases. One is the case of stream 4163 ciphers in which a computationally unpredictable pad of the length of 4164 the message, plus the length of the MAC tag, is produced using a 4165 pseudo-random generator and this pad is xor-ed with the concatenation 4166 of plaintext and MAC tag. The other is the case of CBC mode using a 4167 secure block cipher. In this case, security can be shown if one 4168 applies one CBC encryption pass to the concatenation of plaintext and 4169 MAC and uses a new, independent, and unpredictable IV for each new 4170 pair of plaintext and MAC. In versions of TLS prior to 1.1, CBC mode 4171 was used properly EXCEPT that it used a predictable IV in the form of 4172 the last block of the previous ciphertext. This made TLS open to 4173 chosen plaintext attacks. This version of the protocol is immune to 4174 those attacks. For exact details in the encryption modes proven 4175 secure, see [ENCAUTH]. 4177 F.5 Denial of Service 4179 TLS is susceptible to a number of denial of service (DoS) attacks. 4180 In particular, an attacker who initiates a large number of TCP 4181 connections can cause a server to consume large amounts of CPU doing 4182 RSA decryption. However, because TLS is generally used over TCP, it 4183 is difficult for the attacker to hide his point of origin if proper 4184 TCP SYN randomization is used [SEQNUM] by the TCP stack. 4186 Because TLS runs over TCP, it is also susceptible to a number of 4187 denial of service attacks on individual connections. In particular, 4188 attackers can forge RSTs, thereby terminating connections, or forge 4189 partial TLS records, thereby causing the connection to stall. These 4190 attacks cannot in general be defended against by a TCP-using 4191 protocol. Implementors or users who are concerned with this class of 4192 attack should use IPsec AH [AH] or ESP [ESP]. 4194 F.6 Final Notes 4196 For TLS to be able to provide a secure connection, both the client 4197 and server systems, keys, and applications must be secure. In 4198 addition, the implementation must be free of security errors. 4200 The system is only as strong as the weakest key exchange and 4201 authentication algorithm supported, and only trustworthy 4202 cryptographic functions should be used. Short public keys and 4203 anonymous servers should be used with great caution. Implementations 4204 and users must be careful when deciding which certificates and 4205 certificate authorities are acceptable; a dishonest certificate 4206 authority can do tremendous damage. 4208 Changes in This Version 4210 [RFC Editor: Please delete this] 4212 - SSLv2 backward compatibility downgraded to MAY 4214 - Altered DSA hash rules to more closely match FIPS186-3 and 4215 PKIX, plus remove OID restriction. 4217 - verify_length no longer in SecurityParameters 4219 - Moved/cleaned up cert selection text for server cert 4220 when signature_algorithms is not specified. 4222 - Other editorial changes. 4224 Normative References 4226 [AES] National Institute of Standards and Technology, 4227 "Specification for the Advanced Encryption Standard (AES)" 4228 FIPS 197. November 26, 2001. 4230 [3DES] National Institute of Standards and Technology, 4231 "Recommendation for the Triple Data Encryption Algorithm 4232 (TDEA) Block Cipher", NIST Special Publication 800-67, May 4233 2004. 4235 [DES] National Institute of Standards and Technology, "Data 4236 Encryption Standard (DES)", FIPS PUB 46-3, October 1999. 4238 [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National 4239 Institute of Standards and Technology, U.S. Department of 4240 Commerce, 2000. 4242 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4243 Hashing for Message Authentication", RFC 2104, February 4244 1997. 4246 [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH 4247 Series in Information Processing, v. 1, Konstanz: Hartung- 4248 Gorre Verlag, 1992. 4250 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, 4251 April 1992. 4253 [PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards 4254 (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 4255 3447, February 2003. 4257 [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 4258 Public Key Infrastructure Certificate and Certificate 4259 Revocation List (CRL) Profile", RFC 3280, April 2002. 4261 [RC2] Rivest, R., "A Description of the RC2(r) Encryption 4262 Algorithm", RFC 2268, March 1998. 4264 [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, 4265 and Source Code in C, 2nd ed.", Published by John Wiley & 4266 Sons, Inc. 1996. 4268 [SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National 4269 Institute of Standards and Technology, U.S. Department of 4270 Commerce., August 2001. 4272 [REQ] Bradner, S., "Key words for use in RFCs to Indicate 4273 Requirement Levels", BCP 14, RFC 2119, March 1997. 4275 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 4276 IANA Considerations Section in RFCs", BCP 25, RFC 2434, 4277 October 1998. 4279 Informative References 4281 [AEAD] Mcgrew, D., "Authenticated Encryption", February 2007, 4282 draft-mcgrew-auth-enc-02.txt. 4284 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC 4285 4302, December 2005. 4287 [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against 4288 Protocols Based on RSA Encryption Standard PKCS #1" in 4289 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: 4290 1-12, 1998. 4292 [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: 4293 Problems and Countermeasures", 4294 http://www.openssl.org/~bodo/tls-cbc.txt. 4296 [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, 4297 "Password Interception in a SSL/TLS Channel", Advances in 4298 Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003. 4300 [CCM] "NIST Special Publication 800-38C: The CCM Mode for 4301 Authentication and Confidentiality", 4302 http://csrc.nist.gov/publications/nistpubs/800-38C/ 4303 SP800-38C.pdf 4305 [DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard," 4306 National Institute of Standards and Technology, U.S. 4307 Department of Commerce, 2006. 4309 [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication 4310 for Protecting Communications (Or: How Secure is SSL?)", 4311 Crypto 2001. 4313 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security 4314 Payload (ESP)", RFC 4303, December 2005. 4316 [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on 4317 implementation error", ietf-openpgp@imc.org mailing list, 27 4318 August 2006, http://www.imc.org/ietf-openpgp/mail- 4319 archive/msg14307.html. 4321 [GCM] "NIST Special Publication 800-38D DRAFT (June, 2007): 4322 Recommendation for Block Cipher Modes of Operation: 4323 Galois/Counter Mode (GCM) and GMAC" 4325 [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the 4326 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 4327 2005. 4329 [KEYSIZ] Orman, H., and Hoffman, P., "Determining Strengths For 4330 Public Keys Used For Exchanging Symmetric Keys" RFC 3766, 4331 April 2004. 4333 [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based 4334 Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, 4335 March 2003. 4337 [MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 4338 Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 4339 3526, May 2003. 4341 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax 4342 Standard," version 1.5, November 1993. 4344 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax 4345 Standard," version 1.5, November 1993. 4347 [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness 4348 Requirements for Security", BCP 106, RFC 4086, June 2005. 4350 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol 4351 Compression Methods", RFC 3749, May 2004. 4353 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 4354 Wright, T., "Transport Layer Security (TLS) Extensions", RFC 4355 4366, April 2006. 4357 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for 4358 Obtaining Digital Signatures and Public-Key Cryptosystems," 4359 Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 4360 120-126. 4362 [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks", 4363 RFC 1948, May 1996. 4365 [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications 4366 Corp., Feb 9, 1995. 4368 [SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0 4369 Protocol", Netscape Communications Corp., Nov 18, 1996. 4371 [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" 4372 Attacks on the Diffie-Hellman Key Agreement Method for 4373 S/MIME", RFC 2785, March 2000. 4375 [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, 4376 September 1981. 4378 [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are 4379 practical", USENIX Security Symposium 2003. 4381 [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites 4382 for Transport Layer Security (TLS)", RFC 3268, June 2002. 4384 [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and 4385 Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher 4386 Suites for Transport Layer Security (TLS)", RFC 4492, May 4387 2006. 4389 [TLSEXT] Eastlake, D.E., "Transport Layer Security (TLS) Extensions: 4390 Extension Definitions", July 2007, draft-ietf-tls- 4391 rfc4366-bis-00.txt. 4393 [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS 4394 authentication", draft-ietf-tls-openpgp-keys-11, July 2006. 4396 [TLSPSK] Eronen, P., Tschofenig, H., "Pre-Shared Key Ciphersuites for 4397 Transport Layer Security (TLS)", RFC 4279, December 2005. 4399 [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0", 4400 RFC 2246, January 1999. 4402 [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version 4403 1.1", RFC 4346, April, 2006. 4405 [X501] ITU-T Recommendation X.501: Information Technology - Open 4406 Systems Interconnection - The Directory: Models, 1993. 4408 [XDR] Eisler, M., "External Data Representation Standard", RFC 4409 4506, May 2006. 4411 Credits 4413 Working Group Chairs 4415 Eric Rescorla 4416 EMail: ekr@networkresonance.com 4418 Pasi Eronen 4419 pasi.eronen@nokia.com 4421 Editors 4423 Tim Dierks Eric Rescorla 4424 Independent Network Resonance, Inc. 4425 EMail: tim@dierks.org EMail: ekr@networkresonance.com 4427 Other contributors 4429 Christopher Allen (co-editor of TLS 1.0) 4430 Alacrity Ventures 4431 ChristopherA@AlacrityManagement.com 4433 Martin Abadi 4434 University of California, Santa Cruz 4435 abadi@cs.ucsc.edu 4437 Steven M. Bellovin 4438 Columbia University 4439 smb@cs.columbia.edu 4440 Simon Blake-Wilson 4441 BCI 4442 EMail: sblakewilson@bcisse.com 4444 Ran Canetti 4445 IBM 4446 canetti@watson.ibm.com 4448 Pete Chown 4449 Skygate Technology Ltd 4450 pc@skygate.co.uk 4452 Taher Elgamal 4453 taher@securify.com 4454 Securify 4456 Anil Gangolli 4457 anil@busybuddha.org 4459 Kipp Hickman 4461 Alfred Hoenes 4463 David Hopwood 4464 Independent Consultant 4465 EMail: david.hopwood@blueyonder.co.uk 4467 Phil Karlton (co-author of SSLv3) 4469 Paul Kocher (co-author of SSLv3) 4470 Cryptography Research 4471 paul@cryptography.com 4473 Hugo Krawczyk 4474 IBM 4475 hugo@ee.technion.ac.il 4477 Jan Mikkelsen 4478 Transactionware 4479 EMail: janm@transactionware.com 4481 Magnus Nystrom 4482 RSA Security 4483 EMail: magnus@rsasecurity.com 4485 Robert Relyea 4486 Netscape Communications 4487 relyea@netscape.com 4488 Jim Roskind 4489 Netscape Communications 4490 jar@netscape.com 4492 Michael Sabin 4494 Dan Simon 4495 Microsoft, Inc. 4496 dansimon@microsoft.com 4498 Tom Weinstein 4500 Tim Wright 4501 Vodafone 4502 EMail: timothy.wright@vodafone.com 4504 Comments 4506 The discussion list for the IETF TLS working group is located at the 4507 e-mail address . Information on the group and 4508 information on how to subscribe to the list is at 4509 4511 Archives of the list can be found at: 4512 4514 Full Copyright Statement 4516 Copyright (C) The IETF Trust (2007). 4518 This document is subject to the rights, licenses and restrictions 4519 contained in BCP 78, and except as set forth therein, the authors 4520 retain all their rights. 4522 This document and the information contained herein are provided on an 4523 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4524 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4525 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4526 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4527 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4528 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4530 Intellectual Property 4532 The IETF takes no position regarding the validity or scope of any 4533 Intellectual Property Rights or other rights that might be claimed to 4534 pertain to the implementation or use of the technology described in 4535 this document or the extent to which any license under such rights 4536 might or might not be available; nor does it represent that it has 4537 made any independent effort to identify any such rights. Information 4538 on the procedures with respect to rights in RFC documents can be 4539 found in BCP 78 and BCP 79. 4541 Copies of IPR disclosures made to the IETF Secretariat and any 4542 assurances of licenses to be made available, or the result of an 4543 attempt made to obtain a general license or permission for the use of 4544 such proprietary rights by implementers or users of this 4545 specification can be obtained from the IETF on-line IPR repository at 4546 http://www.ietf.org/ipr. 4548 The IETF invites any interested party to bring to its attention any 4549 copyrights, patents or patent applications, or other proprietary 4550 rights that may cover technology that may be required to implement 4551 this standard. Please address the information to the IETF at 4552 ietf-ipr@ietf.org. 4554 Acknowledgment 4556 Funding for the RFC Editor function is provided by the IETF 4557 Administrative Support Activity (IASA).