| blob | 210a7c95b52aed9c4a17c2aba819b5892bfe053b |
7 INTERNET-DRAFT Tim Dierks
8 Obsoletes (if approved): RFC 3268, 4346, 4366 Independent
9 Intended status: Proposed Standard Eric Rescorla
10 Network Resonance, Inc.
11 <draft-ietf-tls-rfc4346-bis-05.txt> September 2007 (Expires March 2008)
13 The Transport Layer Security (TLS) Protocol
14 Version 1.2
16 Status of this Memo
17 By submitting this Internet-Draft, each author represents that any
18 applicable patent or other IPR claims of which he or she is aware
19 have been or will be disclosed, and any of which he or she becomes
20 aware will be disclosed, in accordance with Section 6 of BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF), its areas, and its working groups. Note that
24 other groups may also distribute working documents as Internet-
25 Drafts.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt.
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 Copyright Notice
40 Copyright (C) The IETF Trust (2007).
42 Abstract
44 This document specifies Version 1.2 of the Transport Layer Security
45 (TLS) protocol. The TLS protocol provides communications security
46 over the Internet. The protocol allows client/server applications to
47 communicate in a way that is designed to prevent eavesdropping,
48 tampering, or message forgery.
50 Table of Contents
52 1. Introduction 3
53 1.1 Requirements Terminology 5
54 1.2 Major Differences from TLS 1.1 5
58 Dierks & Rescorla Standards Track [Page 1]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
61 2. Goals 6
62 3. Goals of This Document 6
63 4. Presentation Language 7
64 4.1. Basic Block Size 7
65 4.2. Miscellaneous 7
66 4.3. Vectors 7
67 4.4. Numbers 8
68 4.5. Enumerateds 9
69 4.6. Constructed Types 10
70 4.6.1. Variants 10
71 4.7. Cryptographic Attributes 11
72 4.8. Constants 12
73 5. HMAC and the Pseudorandom Function 13
74 6. The TLS Record Protocol 14
75 6.1. Connection States 15
76 6.2. Record layer 17
77 6.2.1. Fragmentation 17
78 6.2.2. Record Compression and Decompression 19
79 6.2.3. Record Payload Protection 19
80 6.2.3.1. Null or Standard Stream Cipher 20
81 6.2.3.2. CBC Block Cipher 21
82 6.2.3.3. AEAD ciphers 22
83 6.3. Key Calculation 24
84 7. The TLS Handshaking Protocols 25
85 7.1. Change Cipher Spec Protocol 25
86 7.2. Alert Protocol 26
87 7.2.1. Closure Alerts 27
88 7.2.2. Error Alerts 28
89 7.3. Handshake Protocol Overview 31
90 7.4. Handshake Protocol 34
91 7.4.1. Hello Messages 35
92 7.4.1.1. Hello Request 35
93 7.4.1.2. Client Hello 36
94 7.4.1.3. Server Hello 39
95 7.4.1.4 Hello Extensions 41
96 7.4.1.4.1 Cert Hash Types 42
97 7.4.2. Server Certificate 42
98 7.4.3. Server Key Exchange Message 44
99 7.4.4. Certificate Request 46
100 7.4.5 Server hello done 48
101 7.4.6. Client Certificate 48
102 7.4.7. Client Key Exchange Message 49
103 7.4.7.1. RSA Encrypted Premaster Secret Message 49
104 7.4.7.2. Client Diffie-Hellman Public Value 52
105 7.4.8. Certificate verify 52
106 7.4.9. Finished 53
107 8. Cryptographic Computations 55
108 8.1. Computing the Master Secret 55
112 Dierks & Rescorla Standards Track [Page 2]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
115 8.1.1. RSA 55
116 8.1.2. Diffie-Hellman 55
117 9. Mandatory Cipher Suites 56
118 10. Application Data Protocol 56
119 11. Security Considerations 56
120 12. IANA Considerations 56
121 A. Protocol Constant Values 58
122 A.1. Record Layer 58
123 A.2. Change Cipher Specs Message 59
124 A.3. Alert Messages 59
125 A.4. Handshake Protocol 61
126 A.4.1. Hello Messages 61
127 A.4.2. Server Authentication and Key Exchange Messages 62
128 A.4.3. Client Authentication and Key Exchange Messages 64
129 A.4.4. Handshake Finalization Message 64
130 A.5. The CipherSuite 64
131 A.6. The Security Parameters 67
132 B. Glossary 68
133 C. CipherSuite Definitions 72
134 D. Implementation Notes 74
135 D.1 Random Number Generation and Seeding 74
136 D.2 Certificates and Authentication 74
137 D.3 CipherSuites 74
138 D.4 Implementation Pitfalls 74
139 E. Backward Compatibility 77
140 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 77
141 E.2 Compatibility with SSL 2.0 78
142 E.3. Avoiding Man-in-the-Middle Version Rollback 80
143 F. Security Analysis 81
144 F.1. Handshake Protocol 81
145 F.1.1. Authentication and Key Exchange 81
146 F.1.1.1. Anonymous Key Exchange 81
147 F.1.1.2. RSA Key Exchange and Authentication 82
148 F.1.1.3. Diffie-Hellman Key Exchange with Authentication 82
149 F.1.2. Version Rollback Attacks 83
150 F.1.3. Detecting Attacks Against the Handshake Protocol 84
151 F.1.4. Resuming Sessions 84
152 F.2. Protecting Application Data 85
153 F.3. Explicit IVs 85
154 F.4. Security of Composite Cipher Modes 85
155 F.5 Denial of Service 86
158 1. Introduction
160 The primary goal of the TLS Protocol is to provide privacy and data
161 integrity between two communicating applications. The protocol is
162 composed of two layers: the TLS Record Protocol and the TLS Handshake
166 Dierks & Rescorla Standards Track [Page 3]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
169 Protocol. At the lowest level, layered on top of some reliable
170 transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
171 TLS Record Protocol provides connection security that has two basic
172 properties:
174 - The connection is private. Symmetric cryptography is used for
175 data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for
176 this symmetric encryption are generated uniquely for each
177 connection and are based on a secret negotiated by another
178 protocol (such as the TLS Handshake Protocol). The Record
179 Protocol can also be used without encryption.
181 - The connection is reliable. Message transport includes a message
182 integrity check using a keyed MAC. Secure hash functions (e.g.,
183 SHA, MD5, etc.) are used for MAC computations. The Record
184 Protocol can operate without a MAC, but is generally only used in
185 this mode while another protocol is using the Record Protocol as
186 a transport for negotiating security parameters.
188 The TLS Record Protocol is used for encapsulation of various higher-
189 level protocols. One such encapsulated protocol, the TLS Handshake
190 Protocol, allows the server and client to authenticate each other and
191 to negotiate an encryption algorithm and cryptographic keys before
192 the application protocol transmits or receives its first byte of
193 data. The TLS Handshake Protocol provides connection security that
194 has three basic properties:
196 - The peer's identity can be authenticated using asymmetric, or
197 public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
198 authentication can be made optional, but is generally required
199 for at least one of the peers.
201 - The negotiation of a shared secret is secure: the negotiated
202 secret is unavailable to eavesdroppers, and for any authenticated
203 connection the secret cannot be obtained, even by an attacker who
204 can place himself in the middle of the connection.
206 - The negotiation is reliable: no attacker can modify the
207 negotiation communication without being detected by the parties
208 to the communication.
210 One advantage of TLS is that it is application protocol independent.
211 Higher-level protocols can layer on top of the TLS Protocol
212 transparently. The TLS standard, however, does not specify how
213 protocols add security with TLS; the decisions on how to initiate TLS
214 handshaking and how to interpret the authentication certificates
215 exchanged are left to the judgment of the designers and implementors
216 of protocols that run on top of TLS.
220 Dierks & Rescorla Standards Track [Page 4]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
223 1.1 Requirements Terminology
225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
227 document are to be interpreted as described in RFC 2119 [RFC2119].
229 1.2 Major Differences from TLS 1.1
230 This document is a revision of the TLS 1.1 [TLS1.1] protocol which
231 contains improved flexibility, particularly for negotiation of
232 cryptographic algorithms. The major changes are:
234 - Merged in TLS Extensions definition and AES Cipher Suites from
235 external documents [TLSEXT] and [TLSAES].
237 - Replacement of MD5/SHA-1 combination in the PRF. Addition
238 of cipher-suite specified PRFs.
240 - Replacement of MD5/SHA-1 combination in the digitally-signed
241 element.
243 - Allow the client to indicate which hash functions it supports
244 for digital signature.
246 - Allow the server to indicate which hash functions it supports
247 for digital signature.
249 - Addition of support for authenticated encryption with additional
250 data modes.
252 - Tightened up a number of requirements.
254 - The usual clarifications and editorial work.
256 - Added some guidance that DH groups should be checked.
258 - Cleaned up description of Bleichenbacher/Klima attack defenses.
260 - Tighter checking of EncryptedPreMasterSecret version numbers.
262 - Stronger language about when alerts MUST be sent.
264 - Added an Implementation Pitfalls sections
266 - Harmonized the requirement to send an empty certificate list
267 after certificate_request even when no certs are available.
269 - Made the verify_data length depend on the cipher suite.
274 Dierks & Rescorla Standards Track [Page 5]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
277 - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
278 cipher suite.
280 2. Goals
282 The goals of TLS Protocol, in order of their priority, are as
283 follows:
285 1. Cryptographic security: TLS should be used to establish a secure
286 connection between two parties.
288 2. Interoperability: Independent programmers should be able to
289 develop applications utilizing TLS that can successfully exchange
290 cryptographic parameters without knowledge of one another's code.
292 3. Extensibility: TLS seeks to provide a framework into which new
293 public key and bulk encryption methods can be incorporated as
294 necessary. This will also accomplish two sub-goals: preventing
295 the need to create a new protocol (and risking the introduction
296 of possible new weaknesses) and avoiding the need to implement an
297 entire new security library.
299 4. Relative efficiency: Cryptographic operations tend to be highly
300 CPU intensive, particularly public key operations. For this
301 reason, the TLS protocol has incorporated an optional session
302 caching scheme to reduce the number of connections that need to
303 be established from scratch. Additionally, care has been taken to
304 reduce network activity.
306 3. Goals of This Document
308 This document and the TLS protocol itself are based on the SSL 3.0
309 Protocol Specification as published by Netscape. The differences
310 between this protocol and SSL 3.0 are not dramatic, but they are
311 significant enough that the various versions of TLS and SSL 3.0 do
312 not interoperate (although each protocol incorporates a mechanism by
313 which an implementation can back down to prior versions). This
314 document is intended primarily for readers who will be implementing
315 the protocol and for those doing cryptographic analysis of it. The
316 specification has been written with this in mind, and it is intended
317 to reflect the needs of those two groups. For that reason, many of
318 the algorithm-dependent data structures and rules are included in the
319 body of the text (as opposed to in an appendix), providing easier
320 access to them.
322 This document is not intended to supply any details of service
323 definition or of interface definition, although it does cover select
324 areas of policy as they are required for the maintenance of solid
328 Dierks & Rescorla Standards Track [Page 6]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
331 security.
333 4. Presentation Language
335 This document deals with the formatting of data in an external
336 representation. The following very basic and somewhat casually
337 defined presentation syntax will be used. The syntax draws from
338 several sources in its structure. Although it resembles the
339 programming language "C" in its syntax and XDR [XDR] in both its
340 syntax and intent, it would be risky to draw too many parallels. The
341 purpose of this presentation language is to document TLS only; it has
342 no general application beyond that particular goal.
344 4.1. Basic Block Size
346 The representation of all data items is explicitly specified. The
347 basic data block size is one byte (i.e., 8 bits). Multiple byte data
348 items are concatenations of bytes, from left to right, from top to
349 bottom. From the bytestream, a multi-byte item (a numeric in the
350 example) is formed (using C notation) by:
352 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
353 ... | byte[n-1];
355 This byte ordering for multi-byte values is the commonplace network
356 byte order or big endian format.
358 4.2. Miscellaneous
360 Comments begin with "/*" and end with "*/".
362 Optional components are denoted by enclosing them in "[[ ]]" double
363 brackets.
365 Single-byte entities containing uninterpreted data are of type
366 opaque.
368 4.3. Vectors
370 A vector (single dimensioned array) is a stream of homogeneous data
371 elements. The size of the vector may be specified at documentation
372 time or left unspecified until runtime. In either case, the length
373 declares the number of bytes, not the number of elements, in the
374 vector. The syntax for specifying a new type, T', that is a fixed-
375 length vector of type T is
377 T T'[n];
382 Dierks & Rescorla Standards Track [Page 7]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
385 Here, T' occupies n bytes in the data stream, where n is a multiple
386 of the size of T. The length of the vector is not included in the
387 encoded stream.
389 In the following example, Datum is defined to be three consecutive
390 bytes that the protocol does not interpret, while Data is three
391 consecutive Datum, consuming a total of nine bytes.
393 opaque Datum[3]; /* three uninterpreted bytes */
394 Datum Data[9]; /* 3 consecutive 3 byte vectors */
396 Variable-length vectors are defined by specifying a subrange of legal
397 lengths, inclusively, using the notation <floor..ceiling>. When
398 these are encoded, the actual length precedes the vector's contents
399 in the byte stream. The length will be in the form of a number
400 consuming as many bytes as required to hold the vector's specified
401 maximum (ceiling) length. A variable-length vector with an actual
402 length field of zero is referred to as an empty vector.
404 T T'<floor..ceiling>;
406 In the following example, mandatory is a vector that must contain
407 between 300 and 400 bytes of type opaque. It can never be empty. The
408 actual length field consumes two bytes, a uint16, sufficient to
409 represent the value 400 (see Section 4.4). On the other hand, longer
410 can represent up to 800 bytes of data, or 400 uint16 elements, and it
411 may be empty. Its encoding will include a two-byte actual length
412 field prepended to the vector. The length of an encoded vector must
413 be an even multiple of the length of a single element (for example, a
414 17-byte vector of uint16 would be illegal).
416 opaque mandatory<300..400>;
417 /* length field is 2 bytes, cannot be empty */
418 uint16 longer<0..800>;
419 /* zero to 400 16-bit unsigned integers */
421 4.4. Numbers
423 The basic numeric data type is an unsigned byte (uint8). All larger
424 numeric data types are formed from fixed-length series of bytes
425 concatenated as described in Section 4.1 and are also unsigned. The
426 following numeric types are predefined.
428 uint8 uint16[2];
429 uint8 uint24[3];
430 uint8 uint32[4];
431 uint8 uint64[8];
436 Dierks & Rescorla Standards Track [Page 8]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
439 All values, here and elsewhere in the specification, are stored in
440 "network" or "big-endian" order; the uint32 represented by the hex
441 bytes 01 02 03 04 is equivalent to the decimal value 16909060.
443 Note that in some cases (e.g., DH parameters) it is necessary to
444 represent integers as opaque vectors. In such cases, they are
445 represented as unsigned integers (i.e., leading zero octets are not
446 required even if the most significant bit is set).
448 4.5. Enumerateds
450 An additional sparse data type is available called enum. A field of
451 type enum can only assume the values declared in the definition.
452 Each definition is a different type. Only enumerateds of the same
453 type may be assigned or compared. Every element of an enumerated must
454 be assigned a value, as demonstrated in the following example. Since
455 the elements of the enumerated are not ordered, they can be assigned
456 any unique value, in any order.
458 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
460 Enumerateds occupy as much space in the byte stream as would its
461 maximal defined ordinal value. The following definition would cause
462 one byte to be used to carry fields of type Color.
464 enum { red(3), blue(5), white(7) } Color;
466 One may optionally specify a value without its associated tag to
467 force the width definition without defining a superfluous element.
468 In the following example, Taste will consume two bytes in the data
469 stream but can only assume the values 1, 2, or 4.
471 enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
473 The names of the elements of an enumeration are scoped within the
474 defined type. In the first example, a fully qualified reference to
475 the second element of the enumeration would be Color.blue. Such
476 qualification is not required if the target of the assignment is well
477 specified.
479 Color color = Color.blue; /* overspecified, legal */
480 Color color = blue; /* correct, type implicit */
482 For enumerateds that are never converted to external representation,
483 the numerical information may be omitted.
485 enum { low, medium, high } Amount;
490 Dierks & Rescorla Standards Track [Page 9]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
493 4.6. Constructed Types
495 Structure types may be constructed from primitive types for
496 convenience. Each specification declares a new, unique type. The
497 syntax for definition is much like that of C.
499 struct {
500 T1 f1;
501 T2 f2;
502 ...
503 Tn fn;
504 } [[T]];
506 The fields within a structure may be qualified using the type's name,
507 with a syntax much like that available for enumerateds. For example,
508 T.f2 refers to the second field of the previous declaration.
509 Structure definitions may be embedded.
511 4.6.1. Variants
513 Defined structures may have variants based on some knowledge that is
514 available within the environment. The selector must be an enumerated
515 type that defines the possible variants the structure defines. There
516 must be a case arm for every element of the enumeration declared in
517 the select. The body of the variant structure may be given a label
518 for reference. The mechanism by which the variant is selected at
519 runtime is not prescribed by the presentation language.
521 struct {
522 T1 f1;
523 T2 f2;
524 ....
525 Tn fn;
526 select (E) {
527 case e1: Te1;
528 case e2: Te2;
529 ....
530 case en: Ten;
531 } [[fv]];
532 } [[Tv]];
534 For example:
536 enum { apple, orange } VariantTag;
537 struct {
538 uint16 number;
539 opaque string<0..10>; /* variable length */
540 } V1;
544 Dierks & Rescorla Standards Track [Page 10]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
547 struct {
548 uint32 number;
549 opaque string[10]; /* fixed length */
550 } V2;
551 struct {
552 select (VariantTag) { /* value of selector is implicit */
553 case apple: V1; /* VariantBody, tag = apple */
554 case orange: V2; /* VariantBody, tag = orange */
555 } variant_body; /* optional label on variant */
556 } VariantRecord;
558 Variant structures may be qualified (narrowed) by specifying a value
559 for the selector prior to the type. For example, an
561 orange VariantRecord
563 is a narrowed type of a VariantRecord containing a variant_body of
564 type V2.
566 4.7. Cryptographic Attributes
568 The five cryptographic operations digital signing, stream cipher
569 encryption, block cipher encryption, authenticated encryption with
570 additional data (AEAD) encryption and public key encryption are
571 designated digitally-signed, stream-ciphered, block-ciphered, aead-
572 ciphered, and public-key-encrypted, respectively. A field's
573 cryptographic processing is specified by prepending an appropriate
574 key word designation before the field's type specification.
575 Cryptographic keys are implied by the current session state (see
576 Section 6.1).
578 In digital signing, one-way hash functions are used as input for a
579 signing algorithm. A digitally-signed element is encoded as an opaque
580 vector <0..2^16-1>, where the length is specified by the signing
581 algorithm and key.
583 In RSA signing, the opaque vector contains the signature generated
584 using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As
585 discussed in [PKCS1], the DigestInfo MUST be DER encoded and for
586 digest algorithms without parameters (which include SHA-1) the
587 DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but
588 implementations MUST accept both without parameters and with NULL
589 parameters. Note that earlier versions of TLS used a different RSA
590 signature scheme which did not include a DigestInfo encoding.
592 In DSS, the 20 bytes of the SHA-1 hash are run directly through the
593 Digital Signing Algorithm with no additional hashing. This produces
594 two values, r and s. The DSS signature is an opaque vector, as above,
598 Dierks & Rescorla Standards Track [Page 11]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
601 the contents of which are the DER encoding of:
603 Dss-Sig-Value ::= SEQUENCE {
604 r INTEGER,
605 s INTEGER
606 }
608 In stream cipher encryption, the plaintext is exclusive-ORed with an
609 identical amount of output generated from a cryptographically secure
610 keyed pseudorandom number generator.
612 In block cipher encryption, every block of plaintext encrypts to a
613 block of ciphertext. All block cipher encryption is done in CBC
614 (Cipher Block Chaining) mode, and all items that are block-ciphered
615 will be an exact multiple of the cipher block length.
617 In AEAD encryption, the plaintext is simultaneously encrypted and
618 integrity protected. The input may be of any length and the output is
619 generally larger than the input in order to accomodate the integrity
620 check value.
622 In public key encryption, a public key algorithm is used to encrypt
623 data in such a way that it can be decrypted only with the matching
624 private key. A public-key-encrypted element is encoded as an opaque
625 vector <0..2^16-1>, where the length is specified by the encryption
626 algorithm and key.
628 RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
629 defined in [PKCS1].
631 In the following example
633 stream-ciphered struct {
634 uint8 field1;
635 uint8 field2;
636 digitally-signed opaque hash[20];
637 } UserType;
639 the contents of hash are used as input for the signing algorithm, and
640 then the entire structure is encrypted with a stream cipher. The
641 length of this structure, in bytes, would be equal to two bytes for
642 field1 and field2, plus two bytes for the length of the signature,
643 plus the length of the output of the signing algorithm. This is known
644 because the algorithm and key used for the signing are known prior to
645 encoding or decoding this structure.
647 4.8. Constants
652 Dierks & Rescorla Standards Track [Page 12]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
655 Typed constants can be defined for purposes of specification by
656 declaring a symbol of the desired type and assigning values to it.
657 Under-specified types (opaque, variable length vectors, and
658 structures that contain opaque) cannot be assigned values. No fields
659 of a multi-element structure or vector may be elided.
661 For example:
663 struct {
664 uint8 f1;
665 uint8 f2;
666 } Example1;
668 Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
670 5. HMAC and the Pseudorandom Function
672 The TLS record layer uses a keyed Message Authentication Code (MAC)
673 to protect message integrity. The cipher suites defined in this
674 document use a construction known as HMAC, described in [HMAC], which
675 is based on a hash function. Other cipher suites MAY define their own
676 MAC constructions, if needed.
678 In addition, a construction is required to do expansion of secrets
679 into blocks of data for the purposes of key generation or validation.
680 This pseudo-random function (PRF) takes as input a secret, a seed,
681 and an identifying label and produces an output of arbitrary length.
683 In this section, we define one PRF, based on HMAC. This PRF with the
684 SHA-256 hash function is used for all cipher suites defined in this
685 document and in TLS documents published prior to this document. New
686 cipher suites MUST explicitly specify a PRF and in general SHOULD use
687 the TLS PRF with SHA-256 or a stronger standard hash function.
689 First, we define a data expansion function, P_hash(secret, data) that
690 uses a single hash function to expand a secret and seed into an
691 arbitrary quantity of output:
693 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
694 HMAC_hash(secret, A(2) + seed) +
695 HMAC_hash(secret, A(3) + seed) + ...
697 Where + indicates concatenation.
699 A() is defined as:
700 A(0) = seed
701 A(i) = HMAC_hash(secret, A(i-1))
706 Dierks & Rescorla Standards Track [Page 13]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
709 P_hash can be iterated as many times as is necessary to produce the
710 required quantity of data. For example, if P_SHA-1 is being used to
711 create 64 bytes of data, it will have to be iterated 4 times (through
712 A(4)), creating 80 bytes of output data; the last 16 bytes of the
713 final iteration will then be discarded, leaving 64 bytes of output
714 data.
716 TLS's PRF is created by applying P_hash to the secret S as:
718 PRF(secret, label, seed) = P_<hash>(secret, label + seed)
720 The label is an ASCII string. It should be included in the exact form
721 it is given without a length byte or trailing null character. For
722 example, the label "slithy toves" would be processed by hashing the
723 following bytes:
725 73 6C 69 74 68 79 20 74 6F 76 65 73
728 6. The TLS Record Protocol
730 The TLS Record Protocol is a layered protocol. At each layer,
731 messages may include fields for length, description, and content.
732 The Record Protocol takes messages to be transmitted, fragments the
733 data into manageable blocks, optionally compresses the data, applies
734 a MAC, encrypts, and transmits the result. Received data is
735 decrypted, verified, decompressed, reassembled, and then delivered to
736 higher-level clients.
738 Four record protocol clients are described in this document: the
739 handshake protocol, the alert protocol, the change cipher spec
740 protocol, and the application data protocol. In order to allow
741 extension of the TLS protocol, additional record types can be
742 supported by the record protocol. New record type values are assigned
743 by IANA as described in Section 12.
745 Implementations MUST NOT send record types not defined in this
746 document unless negotiated by some extension. If a TLS
747 implementation receives an unexpected record type, it MUST send a
748 unexpected_message alert."
750 Any protocol designed for use over TLS MUST be carefully designed to
751 deal with all possible attacks against it. Note that because the
752 type and length of a record are not protected by encryption, care
753 SHOULD be taken to minimize the value of traffic analysis of these
754 values.
760 Dierks & Rescorla Standards Track [Page 14]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
763 6.1. Connection States
765 A TLS connection state is the operating environment of the TLS Record
766 Protocol. It specifies a compression algorithm, an encryption
767 algorithm, and a MAC algorithm. In addition, the parameters for these
768 algorithms are known: the MAC secret and the bulk encryption keys for
769 the connection in both the read and the write directions. Logically,
770 there are always four connection states outstanding: the current read
771 and write states, and the pending read and write states. All records
772 are processed under the current read and write states. The security
773 parameters for the pending states can be set by the TLS Handshake
774 Protocol, and the Change Cipher Spec can selectively make either of
775 the pending states current, in which case the appropriate current
776 state is disposed of and replaced with the pending state; the pending
777 state is then reinitialized to an empty state. It is illegal to make
778 a state that has not been initialized with security parameters a
779 current state. The initial current state always specifies that no
780 encryption, compression, or MAC will be used.
782 The security parameters for a TLS Connection read and write state are
783 set by providing the following values:
785 connection end
786 Whether this entity is considered the "client" or the "server" in
787 this connection.
789 bulk encryption algorithm
790 An algorithm to be used for bulk encryption. This specification
791 includes the key size of this algorithm, how much of that key is
792 secret, whether it is a block, stream, or AEAD cipher, and the
793 block size of the cipher (if appropriate).
795 MAC algorithm
796 An algorithm to be used for message authentication. This
797 specification includes the size of the value returned by the MAC
798 algorithm.
800 compression algorithm
801 An algorithm to be used for data compression. This specification
802 must include all information the algorithm requires to do
803 compression.
805 master secret
806 A 48-byte secret shared between the two peers in the connection.
808 client random
809 A 32-byte value provided by the client.
814 Dierks & Rescorla Standards Track [Page 15]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
817 server random
818 A 32-byte value provided by the server.
820 These parameters are defined in the presentation language as:
822 enum { server, client } ConnectionEnd;
824 enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm;
826 enum { stream, block, aead } CipherType;
828 enum { null, md5, sha, sha256, sha384, sha512} MACAlgorithm;
830 /* The use of "sha" above is historical and denotes SHA-1 */
832 enum { null(0), (255) } CompressionMethod;
834 /* The algorithms specified in CompressionMethod,
835 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
837 struct {
838 ConnectionEnd entity;
839 BulkCipherAlgorithm bulk_cipher_algorithm;
840 CipherType cipher_type;
841 uint8 enc_key_length;
842 uint8 block_length;
843 uint8 fixed_iv_length;
844 uint8 record_iv_length;
845 MACAlgorithm mac_algorithm;
846 uint8 mac_length;
847 uint8 mac_key_length;
848 uint8 verify_data_length;
849 CompressionMethod compression_algorithm;
850 opaque master_secret[48];
851 opaque client_random[32];
852 opaque server_random[32];
853 } SecurityParameters;
855 The record layer will use the security parameters to generate the
856 following four items:
858 client write MAC secret
859 server write MAC secret
860 client write key
861 server write key
863 The client write parameters are used by the server when receiving and
864 processing records and vice-versa. The algorithm used for generating
868 Dierks & Rescorla Standards Track [Page 16]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
871 these items from the security parameters is described in Section 6.3.
873 Once the security parameters have been set and the keys have been
874 generated, the connection states can be instantiated by making them
875 the current states. These current states MUST be updated for each
876 record processed. Each connection state includes the following
877 elements:
879 compression state
880 The current state of the compression algorithm.
882 cipher state
883 The current state of the encryption algorithm. This will consist
884 of the scheduled key for that connection. For stream ciphers,
885 this will also contain whatever state information is necessary to
886 allow the stream to continue to encrypt or decrypt data.
888 MAC secret
889 The MAC secret for this connection, as generated above.
891 sequence number
892 Each connection state contains a sequence number, which is
893 maintained separately for read and write states. The sequence
894 number MUST be set to zero whenever a connection state is made
895 the active state. Sequence numbers are of type uint64 and may not
896 exceed 2^64-1. Sequence numbers do not wrap. If a TLS
897 implementation would need to wrap a sequence number, it must
898 renegotiate instead. A sequence number is incremented after each
899 record: specifically, the first record transmitted under a
900 particular connection state MUST use sequence number 0.
902 6.2. Record layer
904 The TLS Record Layer receives uninterpreted data from higher layers
905 in non-empty blocks of arbitrary size.
907 6.2.1. Fragmentation
909 The record layer fragments information blocks into TLSPlaintext
910 records carrying data in chunks of 2^14 bytes or less. Client message
911 boundaries are not preserved in the record layer (i.e., multiple
912 client messages of the same ContentType MAY be coalesced into a
913 single TLSPlaintext record, or a single message MAY be fragmented
914 across several records).
917 struct {
918 uint8 major, minor;
922 Dierks & Rescorla Standards Track [Page 17]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
925 } ProtocolVersion;
927 enum {
928 change_cipher_spec(20), alert(21), handshake(22),
929 application_data(23), (255)
930 } ContentType;
932 struct {
933 ContentType type;
934 ProtocolVersion version;
935 uint16 length;
936 opaque fragment[TLSPlaintext.length];
937 } TLSPlaintext;
939 type
940 The higher-level protocol used to process the enclosed fragment.
942 version
943 The version of the protocol being employed. This document
944 describes TLS Version 1.2, which uses the version { 3, 3 }. The
945 version value 3.3 is historical, deriving from the use of 3.1 for
946 TLS 1.0. (See Appendix A.1). Note that a client that supports
947 multiple versions of TLS may not know what version will be
948 employed before it receives ServerHello. See Appendix E for
949 discussion about what record layer version number should be
950 employed for ClientHello.
952 length
953 The length (in bytes) of the following TLSPlaintext.fragment.
954 The length MUST NOT exceed 2^14.
956 fragment
957 The application data. This data is transparent and treated as an
958 independent block to be dealt with by the higher-level protocol
959 specified by the type field.
961 Implementations MUST NOT send zero-length fragments of Handshake,
962 Alert, or Change Cipher Spec content types. Zero-length fragments
963 of Application data MAY be sent as they are potentially useful as
964 a traffic analysis countermeasure.
966 Note: Data of different TLS Record layer content types MAY be
967 interleaved. Application data is generally of lower precedence
968 for transmission than other content types. However, records MUST
969 be delivered to the network in the same order as they are
970 protected by the record layer. Recipients MUST receive and
971 process interleaved application layer traffic during handshakes
972 subsequent to the first one on a connection.
976 Dierks & Rescorla Standards Track [Page 18]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
979 6.2.2. Record Compression and Decompression
981 All records are compressed using the compression algorithm defined in
982 the current session state. There is always an active compression
983 algorithm; however, initially it is defined as
984 CompressionMethod.null. The compression algorithm translates a
985 TLSPlaintext structure into a TLSCompressed structure. Compression
986 functions are initialized with default state information whenever a
987 connection state is made active.
989 Compression must be lossless and may not increase the content length
990 by more than 1024 bytes. If the decompression function encounters a
991 TLSCompressed.fragment that would decompress to a length in excess of
992 2^14 bytes, it MUST report a fatal decompression failure error.
994 struct {
995 ContentType type; /* same as TLSPlaintext.type */
996 ProtocolVersion version;/* same as TLSPlaintext.version */
997 uint16 length;
998 opaque fragment[TLSCompressed.length];
999 } TLSCompressed;
1001 length
1002 The length (in bytes) of the following TLSCompressed.fragment.
1003 The length MUST NOT exceed 2^14 + 1024.
1005 fragment
1006 The compressed form of TLSPlaintext.fragment.
1008 Note: A CompressionMethod.null operation is an identity operation; no
1009 fields are altered.
1011 Implementation note:
1012 Decompression functions are responsible for ensuring that
1013 messages cannot cause internal buffer overflows.
1015 6.2.3. Record Payload Protection
1017 The encryption and MAC functions translate a TLSCompressed structure
1018 into a TLSCiphertext. The decryption functions reverse the process.
1019 The MAC of the record also includes a sequence number so that
1020 missing, extra, or repeated messages are detectable.
1022 struct {
1023 ContentType type;
1024 ProtocolVersion version;
1025 uint16 length;
1026 select (SecurityParameters.cipher_type) {
1030 Dierks & Rescorla Standards Track [Page 19]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1033 case stream: GenericStreamCipher;
1034 case block: GenericBlockCipher;
1035 case aead: GenericAEADCipher;
1036 } fragment;
1037 } TLSCiphertext;
1039 type
1040 The type field is identical to TLSCompressed.type.
1042 version
1043 The version field is identical to TLSCompressed.version.
1045 length
1046 The length (in bytes) of the following TLSCiphertext.fragment.
1047 The length MUST NOT exceed 2^14 + 2048.
1049 fragment
1050 The encrypted form of TLSCompressed.fragment, with the MAC.
1052 6.2.3.1. Null or Standard Stream Cipher
1054 Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
1055 convert TLSCompressed.fragment structures to and from stream
1056 TLSCiphertext.fragment structures.
1058 stream-ciphered struct {
1059 opaque content[TLSCompressed.length];
1060 opaque MAC[SecurityParameters.mac_length];
1061 } GenericStreamCipher;
1063 The MAC is generated as:
1065 MAC(MAC_write_secret, seq_num + TLSCompressed.type +
1066 TLSCompressed.version + TLSCompressed.length +
1067 TLSCompressed.fragment);
1069 where "+" denotes concatenation.
1071 seq_num
1072 The sequence number for this record.
1074 hash
1075 The hashing algorithm specified by
1076 SecurityParameters.mac_algorithm.
1078 Note that the MAC is computed before encryption. The stream cipher
1079 encrypts the entire block, including the MAC. For stream ciphers that
1080 do not use a synchronization vector (such as RC4), the stream cipher
1084 Dierks & Rescorla Standards Track [Page 20]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1087 state from the end of one record is simply used on the subsequent
1088 packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
1089 consists of the identity operation (i.e., the data is not encrypted,
1090 and the MAC size is zero, implying that no MAC is used).
1091 TLSCiphertext.length is TLSCompressed.length plus
1092 SecurityParameters.mac_length.
1094 6.2.3.2. CBC Block Cipher
1096 For block ciphers (such as RC2, DES, or AES), the encryption and MAC
1097 functions convert TLSCompressed.fragment structures to and from block
1098 TLSCiphertext.fragment structures.
1100 struct {
1101 opaque IV[SecurityParameters.record_iv_length];
1102 block-ciphered struct {
1103 opaque content[TLSCompressed.length];
1104 opaque MAC[SecurityParameters.mac_length];
1105 uint8 padding[GenericBlockCipher.padding_length];
1106 uint8 padding_length;
1107 };
1108 } GenericBlockCipher;
1110 The MAC is generated as described in Section 6.2.3.1.
1112 IV
1113 The Initialization Vector (IV) SHOULD be chosen at random, and
1114 MUST be unpredictable. Note that in versions of TLS prior to 1.1,
1115 there was no IV field, and the last ciphertext block of the
1116 previous record (the "CBC residue") was used as the IV. This was
1117 changed to prevent the attacks described in [CBCATT]. For block
1118 ciphers, the IV length is of length
1119 SecurityParameters.record_iv_length which is equal to the
1120 SecurityParameters.block_size.
1122 padding
1123 Padding that is added to force the length of the plaintext to be
1124 an integral multiple of the block cipher's block length. The
1125 padding MAY be any length up to 255 bytes, as long as it results
1126 in the TLSCiphertext.length being an integral multiple of the
1127 block length. Lengths longer than necessary might be desirable to
1128 frustrate attacks on a protocol that are based on analysis of the
1129 lengths of exchanged messages. Each uint8 in the padding data
1130 vector MUST be filled with the padding length value. The receiver
1131 MUST check this padding and MUST use the bad_record_mac alert to
1132 indicate padding errors.
1134 padding_length
1138 Dierks & Rescorla Standards Track [Page 21]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1141 The padding length MUST be such that the total size of the
1142 GenericBlockCipher structure is a multiple of the cipher's block
1143 length. Legal values range from zero to 255, inclusive. This
1144 length specifies the length of the padding field exclusive of the
1145 padding_length field itself.
1147 The encrypted data length (TLSCiphertext.length) is one more than the
1148 sum of one more than the sum of SecurityParameters.block_length,
1149 TLSCompressed.length, SecurityParameters.mac_length, and
1150 padding_length.
1152 Example: If the block length is 8 bytes, the content length
1153 (TLSCompressed.length) is 61 bytes, and the MAC length is 20
1154 bytes, then the length before padding is 82 bytes (this does
1155 not include the IV. Thus, the padding length modulo 8 must be
1156 equal to 6 in order to make the total length an even multiple
1157 of 8 bytes (the block length). The padding length can be 6,
1158 14, 22, and so on, through 254. If the padding length were the
1159 minimum necessary, 6, the padding would be 6 bytes, each
1160 containing the value 6. Thus, the last 8 octets of the
1161 GenericBlockCipher before block encryption would be xx 06 06
1162 06 06 06 06 06, where xx is the last octet of the MAC.
1164 Note: With block ciphers in CBC mode (Cipher Block Chaining),
1165 it is critical that the entire plaintext of the record be known
1166 before any ciphertext is transmitted. Otherwise, it is possible
1167 for the attacker to mount the attack described in [CBCATT].
1169 Implementation Note: Canvel et al. [CBCTIME] have demonstrated a timing
1170 attack on CBC padding based on the time required to compute the
1171 MAC. In order to defend against this attack, implementations MUST
1172 ensure that record processing time is essentially the same
1173 whether or not the padding is correct. In general, the best way
1174 to do this is to compute the MAC even if the padding is
1175 incorrect, and only then reject the packet. For instance, if the
1176 pad appears to be incorrect, the implementation might assume a
1177 zero-length pad and then compute the MAC. This leaves a small
1178 timing channel, since MAC performance depends to some extent on
1179 the size of the data fragment, but it is not believed to be large
1180 enough to be exploitable, due to the large block size of existing
1181 MACs and the small size of the timing signal.
1183 6.2.3.3. AEAD ciphers
1185 For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
1186 converts TLSCompressed.fragment structures to and from AEAD
1187 TLSCiphertext.fragment structures.
1192 Dierks & Rescorla Standards Track [Page 22]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1195 struct {
1196 opaque nonce_explicit[SecurityParameters.record_iv_length];
1198 aead-ciphered struct {
1199 opaque content[TLSCompressed.length];
1200 };
1201 } GenericAEADCipher;
1203 AEAD ciphers take as input a single key, a nonce, a plaintext, and
1204 "additional data" to be included in the authentication check, as
1205 described in Section 2.1 of [AEAD]. These inputs are as follows.
1207 The key is either the client_write_key or the server_write_key. No
1208 MAC key is used.
1210 Each AEAD cipher suite has to specify how the nonce supplied to the
1211 AEAD operation is constructed, and what is the length of the
1212 GenericAEADCipher.nonce_explicit part. In many cases, it is
1213 appropriate to use the partially implicit nonce technique described
1214 in Section 3.2.1 of [AEAD]; in this case, the implicit part SHOULD be
1215 derived from key_block as client_write_iv and server_write_iv (as
1216 described in Section 6.3), and the explicit part is included in
1217 GenericAEAEDCipher.nonce_explicit.
1219 The plaintext is the TLSCompressed.fragment.
1221 The additional authenticated data, which we denote as
1222 additional_data, is defined as follows:
1224 additional_data = seq_num + TLSCompressed.type +
1225 TLSCompressed.version + TLSCompressed.length;
1227 Where "+" denotes concatenation.
1229 The aead_output consists of the ciphertext output by the AEAD
1230 encryption operation. The length will generally be larger than
1231 TLSCompressed.length, but by an amount that varies with the AEAD
1232 cipher. Since the ciphers might incorporate padding, the amount of
1233 overhead could vary with different TLSCompressed.length values. Each
1234 AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
1235 Symbolically,
1237 AEADEncrypted = AEAD-Encrypt(key, IV, plaintext,
1238 additional_data)
1241 In order to decrypt and verify, the cipher takes as input the key,
1242 IV, the "additional_data", and the AEADEncrypted value. The output is
1246 Dierks & Rescorla Standards Track [Page 23]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1249 either the plaintext or an error indicating that the decryption
1250 failed. There is no separate integrity check. I.e.,
1252 TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, AEADEncrypted,
1253 additional_data)
1256 If the decryption fails, a fatal bad_record_mac alert MUST be
1257 generated.
1259 6.3. Key Calculation
1261 The Record Protocol requires an algorithm to generate keys, and MAC
1262 secrets from the security parameters provided by the handshake
1263 protocol.
1265 The master secret is hashed into a sequence of secure bytes, which
1266 are assigned to the MAC secrets and keys required by the current
1267 connection state (see Appendix A.6). CipherSpecs require a client
1268 write MAC secret, a server write MAC secret, a client write key, and
1269 a server write key, each of which is generated from the master secret
1270 in that order. Unused values are empty.
1272 When keys and MAC secrets are generated, the master secret is used as
1273 an entropy source.
1275 To generate the key material, compute
1277 key_block = PRF(SecurityParameters.master_secret,
1278 "key expansion",
1279 SecurityParameters.server_random +
1280 SecurityParameters.client_random);
1282 until enough output has been generated. Then the key_block is
1283 partitioned as follows:
1285 client_write_MAC_secret[SecurityParameters.mac_key_length]
1286 server_write_MAC_secret[SecurityParameters.mac_key_length]
1287 client_write_key[SecurityParameters.enc_key_length]
1288 server_write_key[SecurityParameters.enc_key_length]
1289 client_write_IV[SecurityParameters.fixed_iv_length]
1290 server_write_IV[SecurityParameters.fixed_iv_length]
1292 The client_write_IV and server_write_IV are only generated for
1293 implicit nonce techniques as described in Section 3.2.1 of [AEAD].
1295 Implementation note:
1296 The currently defined cipher suite which requires the most
1300 Dierks & Rescorla Standards Track [Page 24]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1303 material is AES_256_CBC_SHA. It requires 2 x 32 byte keys and 2 x
1304 20 byte MAC secrets, for a total 104 bytes of key material.
1306 7. The TLS Handshaking Protocols
1308 TLS has three subprotocols that are used to allow peers to agree
1309 upon security parameters for the record layer, to authenticate
1310 themselves, to instantiate negotiated security parameters, and to
1311 report error conditions to each other.
1313 The Handshake Protocol is responsible for negotiating a session,
1314 which consists of the following items:
1316 session identifier
1317 An arbitrary byte sequence chosen by the server to identify an
1318 active or resumable session state.
1320 peer certificate
1321 X509v3 [PKIX] certificate of the peer. This element of the
1322 state may be null.
1324 compression method
1325 The algorithm used to compress data prior to encryption.
1327 cipher spec
1328 Specifies the bulk data encryption algorithm (such as null,
1329 DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also
1330 defines cryptographic attributes such as the mac_length. (See
1331 Appendix A.6 for formal definition.)
1333 master secret
1334 48-byte secret shared between the client and server.
1336 is resumable
1337 A flag indicating whether the session can be used to initiate
1338 new connections.
1340 These items are then used to create security parameters for use by
1341 the Record Layer when protecting application data. Many connections
1342 can be instantiated using the same session through the resumption
1343 feature of the TLS Handshake Protocol.
1345 7.1. Change Cipher Spec Protocol
1347 The change cipher spec protocol exists to signal transitions in
1348 ciphering strategies. The protocol consists of a single message,
1349 which is encrypted and compressed under the current (not the pending)
1350 connection state. The message consists of a single byte of value 1.
1354 Dierks & Rescorla Standards Track [Page 25]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1357 struct {
1358 enum { change_cipher_spec(1), (255) } type;
1359 } ChangeCipherSpec;
1361 The change cipher spec message is sent by both the client and the
1362 server to notify the receiving party that subsequent records will be
1363 protected under the newly negotiated CipherSpec and keys. Reception
1364 of this message causes the receiver to instruct the Record Layer to
1365 immediately copy the read pending state into the read current state.
1366 Immediately after sending this message, the sender MUST instruct the
1367 record layer to make the write pending state the write active state.
1368 (See Section 6.1.) The change cipher spec message is sent during the
1369 handshake after the security parameters have been agreed upon, but
1370 before the verifying finished message is sent.
1372 Note: If a rehandshake occurs while data is flowing on a connection,
1373 the communicating parties may continue to send data using the old
1374 CipherSpec. However, once the ChangeCipherSpec has been sent, the new
1375 CipherSpec MUST be used. The first side to send the ChangeCipherSpec
1376 does not know that the other side has finished computing the new
1377 keying material (e.g., if it has to perform a time consuming public
1378 key operation). Thus, a small window of time, during which the
1379 recipient must buffer the data, MAY exist. In practice, with modern
1380 machines this interval is likely to be fairly short.
1382 7.2. Alert Protocol
1384 One of the content types supported by the TLS Record layer is the
1385 alert type. Alert messages convey the severity of the message and a
1386 description of the alert. Alert messages with a level of fatal result
1387 in the immediate termination of the connection. In this case, other
1388 connections corresponding to the session may continue, but the
1389 session identifier MUST be invalidated, preventing the failed session
1390 from being used to establish new connections. Like other messages,
1391 alert messages are encrypted and compressed, as specified by the
1392 current connection state.
1394 enum { warning(1), fatal(2), (255) } AlertLevel;
1396 enum {
1397 close_notify(0),
1398 unexpected_message(10),
1399 bad_record_mac(20),
1400 decryption_failed_RESERVED(21),
1401 record_overflow(22),
1402 decompression_failure(30),
1403 handshake_failure(40),
1404 no_certificate_RESERVED(41),
1408 Dierks & Rescorla Standards Track [Page 26]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1411 bad_certificate(42),
1412 unsupported_certificate(43),
1413 certificate_revoked(44),
1414 certificate_expired(45),
1415 certificate_unknown(46),
1416 illegal_parameter(47),
1417 unknown_ca(48),
1418 access_denied(49),
1419 decode_error(50),
1420 decrypt_error(51),
1421 export_restriction_RESERVED(60),
1422 protocol_version(70),
1423 insufficient_security(71),
1424 internal_error(80),
1425 user_canceled(90),
1426 no_renegotiation(100),
1427 unsupported_extension(110),
1428 (255)
1429 } AlertDescription;
1431 struct {
1432 AlertLevel level;
1433 AlertDescription description;
1434 } Alert;
1436 7.2.1. Closure Alerts
1438 The client and the server must share knowledge that the connection is
1439 ending in order to avoid a truncation attack. Either party may
1440 initiate the exchange of closing messages.
1442 close_notify
1443 This message notifies the recipient that the sender will not send
1444 any more messages on this connection. Note that as of TLS 1.1,
1445 failure to properly close a connection no longer requires that a
1446 session not be resumed. This is a change from TLS 1.0 to conform
1447 with widespread implementation practice.
1449 Either party may initiate a close by sending a close_notify alert.
1450 Any data received after a closure alert is ignored.
1452 Unless some other fatal alert has been transmitted, each party is
1453 required to send a close_notify alert before closing the write side
1454 of the connection. The other party MUST respond with a close_notify
1455 alert of its own and close down the connection immediately,
1456 discarding any pending writes. It is not required for the initiator
1457 of the close to wait for the responding close_notify alert before
1458 closing the read side of the connection.
1462 Dierks & Rescorla Standards Track [Page 27]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1465 If the application protocol using TLS provides that any data may be
1466 carried over the underlying transport after the TLS connection is
1467 closed, the TLS implementation must receive the responding
1468 close_notify alert before indicating to the application layer that
1469 the TLS connection has ended. If the application protocol will not
1470 transfer any additional data, but will only close the underlying
1471 transport connection, then the implementation MAY choose to close the
1472 transport without waiting for the responding close_notify. No part of
1473 this standard should be taken to dictate the manner in which a usage
1474 profile for TLS manages its data transport, including when
1475 connections are opened or closed.
1477 Note: It is assumed that closing a connection reliably delivers
1478 pending data before destroying the transport.
1480 7.2.2. Error Alerts
1482 Error handling in the TLS Handshake protocol is very simple. When an
1483 error is detected, the detecting party sends a message to the other
1484 party. Upon transmission or receipt of a fatal alert message, both
1485 parties immediately close the connection. Servers and clients MUST
1486 forget any session-identifiers, keys, and secrets associated with a
1487 failed connection. Thus, any connection terminated with a fatal alert
1488 MUST NOT be resumed.
1490 Whenever an implementation encounters a condition which is defined as
1491 a fatal alert, it MUST send the appropriate alert prior to closing
1492 the connection. In cases where an implementation chooses to send an
1493 alert which MAY be a warning alert but intends to close the
1494 connection immediately afterwards, it MUST send that alert at the
1495 fatal alert level.
1497 If an alert with a level of warning is sent and received, generally
1498 the connection can continue normally. If the receiving party decides
1499 not to proceed with the connection (e.g., after having received a
1500 no_renegotiation alert that it is not willing to accept), it SHOULD
1501 send a fatal alert to terminate the connection.
1504 The following error alerts are defined:
1506 unexpected_message
1507 An inappropriate message was received. This alert is always fatal
1508 and should never be observed in communication between proper
1509 implementations.
1511 bad_record_mac
1512 This alert is returned if a record is received with an incorrect
1516 Dierks & Rescorla Standards Track [Page 28]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1519 MAC. This alert also MUST be returned if an alert is sent because
1520 a TLSCiphertext decrypted in an invalid way: either it wasn't an
1521 even multiple of the block length, or its padding values, when
1522 checked, weren't correct. This message is always fatal.
1524 decryption_failed_RESERVED
1525 This alert was used in some earlier versions of TLS, and may have
1526 permitted certain attacks against the CBC mode [CBCATT]. It MUST
1527 NOT be sent by compliant implementations.
1529 record_overflow
1530 A TLSCiphertext record was received that had a length more than
1531 2^14+2048 bytes, or a record decrypted to a TLSCompressed record
1532 with more than 2^14+1024 bytes. This message is always fatal.
1534 decompression_failure
1535 The decompression function received improper input (e.g., data
1536 that would expand to excessive length). This message is always
1537 fatal.
1539 handshake_failure
1540 Reception of a handshake_failure alert message indicates that the
1541 sender was unable to negotiate an acceptable set of security
1542 parameters given the options available. This is a fatal error.
1544 no_certificate_RESERVED
1545 This alert was used in SSLv3 but not any version of TLS. It MUST
1546 NOT be sent by compliant implementations.
1548 bad_certificate
1549 A certificate was corrupt, contained signatures that did not
1550 verify correctly, etc.
1552 unsupported_certificate
1553 A certificate was of an unsupported type.
1555 certificate_revoked
1556 A certificate was revoked by its signer.
1558 certificate_expired
1559 A certificate has expired or is not currently valid.
1561 certificate_unknown
1562 Some other (unspecified) issue arose in processing the
1563 certificate, rendering it unacceptable.
1565 illegal_parameter
1566 A field in the handshake was out of range or inconsistent with
1570 Dierks & Rescorla Standards Track [Page 29]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1573 other fields. This is always fatal.
1575 unknown_ca
1576 A valid certificate chain or partial chain was received, but the
1577 certificate was not accepted because the CA certificate could not
1578 be located or couldn't be matched with a known, trusted CA. This
1579 message is always fatal.
1581 access_denied
1582 A valid certificate was received, but when access control was
1583 applied, the sender decided not to proceed with negotiation.
1584 This message is always fatal.
1586 decode_error
1587 A message could not be decoded because some field was out of the
1588 specified range or the length of the message was incorrect. This
1589 message is always fatal.
1591 decrypt_error
1592 A handshake cryptographic operation failed, including being
1593 unable to correctly verify a signature, decrypt a key exchange,
1594 or validate a finished message.
1596 export_restriction_RESERVED
1597 This alert was used in some earlier versions of TLS. It MUST NOT
1598 be sent by compliant implementations.
1600 protocol_version
1601 The protocol version the client has attempted to negotiate is
1602 recognized but not supported. (For example, old protocol versions
1603 might be avoided for security reasons). This message is always
1604 fatal.
1606 insufficient_security
1607 Returned instead of handshake_failure when a negotiation has
1608 failed specifically because the server requires ciphers more
1609 secure than those supported by the client. This message is always
1610 fatal.
1612 internal_error
1613 An internal error unrelated to the peer or the correctness of the
1614 protocol (such as a memory allocation failure) makes it
1615 impossible to continue. This message is always fatal.
1617 user_canceled
1618 This handshake is being canceled for some reason unrelated to a
1619 protocol failure. If the user cancels an operation after the
1620 handshake is complete, just closing the connection by sending a
1624 Dierks & Rescorla Standards Track [Page 30]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1627 close_notify is more appropriate. This alert should be followed
1628 by a close_notify. This message is generally a warning.
1630 no_renegotiation
1631 Sent by the client in response to a hello request or by the
1632 server in response to a client hello after initial handshaking.
1633 Either of these would normally lead to renegotiation; when that
1634 is not appropriate, the recipient should respond with this alert.
1635 At that point, the original requester can decide whether to
1636 proceed with the connection. One case where this would be
1637 appropriate is where a server has spawned a process to satisfy a
1638 request; the process might receive security parameters (key
1639 length, authentication, etc.) at startup and it might be
1640 difficult to communicate changes to these parameters after that
1641 point. This message is always a warning.
1643 unsupported_extension
1644 sent by clients that receive an extended server hello containing
1645 an extension that they did not put in the corresponding client
1646 hello. This message is always fatal.
1648 For all errors where an alert level is not explicitly specified, the
1649 sending party MAY determine at its discretion whether this is a fatal
1650 error or not; if an alert with a level of warning is received, the
1651 receiving party MAY decide at its discretion whether to treat this as
1652 a fatal error or not. However, all messages that are transmitted
1653 with a level of fatal MUST be treated as fatal messages.
1655 New Alert values are assigned by IANA as described in Section 12.
1657 7.3. Handshake Protocol Overview
1659 The cryptographic parameters of the session state are produced by the
1660 TLS Handshake Protocol, which operates on top of the TLS Record
1661 Layer. When a TLS client and server first start communicating, they
1662 agree on a protocol version, select cryptographic algorithms,
1663 optionally authenticate each other, and use public-key encryption
1664 techniques to generate shared secrets.
1666 The TLS Handshake Protocol involves the following steps:
1668 - Exchange hello messages to agree on algorithms, exchange random
1669 values, and check for session resumption.
1671 - Exchange the necessary cryptographic parameters to allow the
1672 client and server to agree on a premaster secret.
1674 - Exchange certificates and cryptographic information to allow the
1678 Dierks & Rescorla Standards Track [Page 31]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1681 client and server to authenticate themselves.
1683 - Generate a master secret from the premaster secret and exchanged
1684 random values.
1686 - Provide security parameters to the record layer.
1688 - Allow the client and server to verify that their peer has
1689 calculated the same security parameters and that the handshake
1690 occurred without tampering by an attacker.
1692 Note that higher layers should not be overly reliant on whether TLS
1693 always negotiates the strongest possible connection between two
1694 peers. There are a number of ways in which a man in the middle
1695 attacker can attempt to make two entities drop down to the least
1696 secure method they support. The protocol has been designed to
1697 minimize this risk, but there are still attacks available: for
1698 example, an attacker could block access to the port a secure service
1699 runs on, or attempt to get the peers to negotiate an unauthenticated
1700 connection. The fundamental rule is that higher levels must be
1701 cognizant of what their security requirements are and never transmit
1702 information over a channel less secure than what they require. The
1703 TLS protocol is secure in that any cipher suite offers its promised
1704 level of security: if you negotiate 3DES with a 1024 bit RSA key
1705 exchange with a host whose certificate you have verified, you can
1706 expect to be that secure.
1708 These goals are achieved by the handshake protocol, which can be
1709 summarized as follows: The client sends a client hello message to
1710 which the server must respond with a server hello message, or else a
1711 fatal error will occur and the connection will fail. The client hello
1712 and server hello are used to establish security enhancement
1713 capabilities between client and server. The client hello and server
1714 hello establish the following attributes: Protocol Version, Session
1715 ID, Cipher Suite, and Compression Method. Additionally, two random
1716 values are generated and exchanged: ClientHello.random and
1717 ServerHello.random.
1719 The actual key exchange uses up to four messages: the server
1720 certificate, the server key exchange, the client certificate, and the
1721 client key exchange. New key exchange methods can be created by
1722 specifying a format for these messages and by defining the use of the
1723 messages to allow the client and server to agree upon a shared
1724 secret. This secret MUST be quite long; currently defined key
1725 exchange methods exchange secrets that range from 46 bytes upwards.
1727 Following the hello messages, the server will send its certificate,
1728 if it is to be authenticated. Additionally, a server key exchange
1732 Dierks & Rescorla Standards Track [Page 32]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1735 message may be sent, if it is required (e.g., if their server has no
1736 certificate, or if its certificate is for signing only). If the
1737 server is authenticated, it may request a certificate from the
1738 client, if that is appropriate to the cipher suite selected. Next,
1739 the server will send the server hello done message, indicating that
1740 the hello-message phase of the handshake is complete. The server will
1741 then wait for a client response. If the server has sent a certificate
1742 request message, the client MUST send the certificate message. The
1743 client key exchange message is now sent, and the content of that
1744 message will depend on the public key algorithm selected between the
1745 client hello and the server hello. If the client has sent a
1746 certificate with signing ability, a digitally-signed certificate
1747 verify message is sent to explicitly verify possession of the private
1748 key in the certificate.
1750 At this point, a change cipher spec message is sent by the client,
1751 and the client copies the pending Cipher Spec into the current Cipher
1752 Spec. The client then immediately sends the finished message under
1753 the new algorithms, keys, and secrets. In response, the server will
1754 send its own change cipher spec message, transfer the pending to the
1755 current Cipher Spec, and send its finished message under the new
1756 Cipher Spec. At this point, the handshake is complete, and the client
1757 and server may begin to exchange application layer data. (See flow
1758 chart below.) Application data MUST NOT be sent prior to the
1759 completion of the first handshake (before a cipher suite other than
1760 TLS_NULL_WITH_NULL_NULL is established).
1762 Client Server
1764 ClientHello -------->
1765 ServerHello
1766 Certificate*
1767 ServerKeyExchange*
1768 CertificateRequest*
1769 <-------- ServerHelloDone
1770 Certificate*
1771 ClientKeyExchange
1772 CertificateVerify*
1773 [ChangeCipherSpec]
1774 Finished -------->
1775 [ChangeCipherSpec]
1776 <-------- Finished
1777 Application Data <-------> Application Data
1779 Fig. 1. Message flow for a full handshake
1781 * Indicates optional or situation-dependent messages that are not
1782 always sent.
1786 Dierks & Rescorla Standards Track [Page 33]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1789 Note: To help avoid pipeline stalls, ChangeCipherSpec is an
1790 independent TLS Protocol content type, and is not actually a TLS
1791 handshake message.
1793 When the client and server decide to resume a previous session or
1794 duplicate an existing session (instead of negotiating new security
1795 parameters), the message flow is as follows:
1797 The client sends a ClientHello using the Session ID of the session to
1798 be resumed. The server then checks its session cache for a match. If
1799 a match is found, and the server is willing to re-establish the
1800 connection under the specified session state, it will send a
1801 ServerHello with the same Session ID value. At this point, both
1802 client and server MUST send change cipher spec messages and proceed
1803 directly to finished messages. Once the re-establishment is complete,
1804 the client and server MAY begin to exchange application layer data.
1805 (See flow chart below.) If a Session ID match is not found, the
1806 server generates a new session ID and the TLS client and server
1807 perform a full handshake.
1809 Client Server
1811 ClientHello -------->
1812 ServerHello
1813 [ChangeCipherSpec]
1814 <-------- Finished
1815 [ChangeCipherSpec]
1816 Finished -------->
1817 Application Data <-------> Application Data
1819 Fig. 2. Message flow for an abbreviated handshake
1821 The contents and significance of each message will be presented in
1822 detail in the following sections.
1824 7.4. Handshake Protocol
1826 The TLS Handshake Protocol is one of the defined higher-level clients
1827 of the TLS Record Protocol. This protocol is used to negotiate the
1828 secure attributes of a session. Handshake messages are supplied to
1829 the TLS Record Layer, where they are encapsulated within one or more
1830 TLSPlaintext structures, which are processed and transmitted as
1831 specified by the current active session state.
1833 enum {
1834 hello_request(0), client_hello(1), server_hello(2),
1835 certificate(11), server_key_exchange (12),
1836 certificate_request(13), server_hello_done(14),
1840 Dierks & Rescorla Standards Track [Page 34]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1843 certificate_verify(15), client_key_exchange(16),
1844 finished(20), (255)
1845 } HandshakeType;
1847 struct {
1848 HandshakeType msg_type; /* handshake type */
1849 uint24 length; /* bytes in message */
1850 select (HandshakeType) {
1851 case hello_request: HelloRequest;
1852 case client_hello: ClientHello;
1853 case server_hello: ServerHello;
1854 case certificate: Certificate;
1855 case server_key_exchange: ServerKeyExchange;
1856 case certificate_request: CertificateRequest;
1857 case server_hello_done: ServerHelloDone;
1858 case certificate_verify: CertificateVerify;
1859 case client_key_exchange: ClientKeyExchange;
1860 case finished: Finished;
1861 } body;
1862 } Handshake;
1864 The handshake protocol messages are presented below in the order they
1865 MUST be sent; sending handshake messages in an unexpected order
1866 results in a fatal error. Unneeded handshake messages can be omitted,
1867 however. Note one exception to the ordering: the Certificate message
1868 is used twice in the handshake (from server to client, then from
1869 client to server), but described only in its first position. The one
1870 message that is not bound by these ordering rules is the Hello
1871 Request message, which can be sent at any time, but which should be
1872 ignored by the client if it arrives in the middle of a handshake.
1874 New Handshake message types are assigned by IANA as described in
1875 Section 12.
1877 7.4.1. Hello Messages
1879 The hello phase messages are used to exchange security enhancement
1880 capabilities between the client and server. When a new session
1881 begins, the Record Layer's connection state encryption, hash, and
1882 compression algorithms are initialized to null. The current
1883 connection state is used for renegotiation messages.
1885 7.4.1.1. Hello Request
1887 When this message will be sent:
1888 The hello request message MAY be sent by the server at any time.
1890 Meaning of this message:
1894 Dierks & Rescorla Standards Track [Page 35]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1897 Hello request is a simple notification that the client should
1898 begin the negotiation process anew by sending a client hello
1899 message when convenient. This message is not intended to
1900 establish which side is the client or server but merely to
1901 initiate a new negotiation. Servers SHOULD NOT send a
1902 HelloRequest immediately upon the client's initial connection.
1903 It is the client's job to send a ClientHello at that time.
1905 This message will be ignored by the client if the client is
1906 currently negotiating a session. This message may be ignored by
1907 the client if it does not wish to renegotiate a session, or the
1908 client may, if it wishes, respond with a no_renegotiation alert.
1909 Since handshake messages are intended to have transmission
1910 precedence over application data, it is expected that the
1911 negotiation will begin before no more than a few records are
1912 received from the client. If the server sends a hello request but
1913 does not receive a client hello in response, it may close the
1914 connection with a fatal alert.
1916 After sending a hello request, servers SHOULD NOT repeat the request
1917 until the subsequent handshake negotiation is complete.
1919 Structure of this message:
1920 struct { } HelloRequest;
1922 Note: This message MUST NOT be included in the message hashes that are
1923 maintained throughout the handshake and used in the finished
1924 messages and the certificate verify message.
1926 7.4.1.2. Client Hello
1928 When this message will be sent:
1929 When a client first connects to a server it is required to send
1930 the client hello as its first message. The client can also send a
1931 client hello in response to a hello request or on its own
1932 initiative in order to renegotiate the security parameters in an
1933 existing connection.
1935 Structure of this message:
1936 The client hello message includes a random structure, which is
1937 used later in the protocol.
1939 struct {
1940 uint32 gmt_unix_time;
1941 opaque random_bytes[28];
1942 } Random;
1944 gmt_unix_time
1948 Dierks & Rescorla Standards Track [Page 36]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
1951 The current time and date in standard UNIX 32-bit format (seconds
1952 since the midnight starting Jan 1, 1970, GMT, ignoring leap
1953 seconds) according to the sender's internal clock. Clocks are not
1954 required to be set correctly by the basic TLS Protocol; higher-
1955 level or application protocols may define additional
1956 requirements.
1958 random_bytes
1959 28 bytes generated by a secure random number generator.
1961 The client hello message includes a variable-length session
1962 identifier. If not empty, the value identifies a session between the
1963 same client and server whose security parameters the client wishes to
1964 reuse. The session identifier MAY be from an earlier connection, this
1965 connection, or from another currently active connection. The second
1966 option is useful if the client only wishes to update the random
1967 structures and derived values of a connection, and the third option
1968 makes it possible to establish several independent secure connections
1969 without repeating the full handshake protocol. These independent
1970 connections may occur sequentially or simultaneously; a SessionID
1971 becomes valid when the handshake negotiating it completes with the
1972 exchange of Finished messages and persists until it is removed due to
1973 aging or because a fatal error was encountered on a connection
1974 associated with the session. The actual contents of the SessionID are
1975 defined by the server.
1977 opaque SessionID<0..32>;
1979 Warning:
1980 Because the SessionID is transmitted without encryption or
1981 immediate MAC protection, servers MUST NOT place confidential
1982 information in session identifiers or let the contents of fake
1983 session identifiers cause any breach of security. (Note that the
1984 content of the handshake as a whole, including the SessionID, is
1985 protected by the Finished messages exchanged at the end of the
1986 handshake.)
1988 The CipherSuite list, passed from the client to the server in the
1989 client hello message, contains the combinations of cryptographic
1990 algorithms supported by the client in order of the client's
1991 preference (favorite choice first). Each CipherSuite defines a key
1992 exchange algorithm, a bulk encryption algorithm (including secret key
1993 length), a MAC algorithm, and a PRF. The server will select a cipher
1994 suite or, if no acceptable choices are presented, return a handshake
1995 failure alert and close the connection.
1997 uint8 CipherSuite[2]; /* Cryptographic suite selector */
2002 Dierks & Rescorla Standards Track [Page 37]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2005 The client hello includes a list of compression algorithms supported
2006 by the client, ordered according to the client's preference.
2008 enum { null(0), (255) } CompressionMethod;
2010 struct {
2011 ProtocolVersion client_version;
2012 Random random;
2013 SessionID session_id;
2014 CipherSuite cipher_suites<2..2^16-2>;
2015 CompressionMethod compression_methods<1..2^8-1>;
2016 select (extensions_present) {
2017 case false:
2018 struct {};
2019 case true:
2020 Extension extensions<0..2^16-1>;
2021 };
2022 } ClientHello;
2024 TLS allows extensions to follow the compression_methods field in an
2025 extensions block. The presence of extensions can be detected by
2026 determining whether there are bytes following the compression_methods
2027 at the end of the ClientHello. Note that this method of detecting
2028 optional data differs from the normal TLS method of having a
2029 variable-length field but is used for compatibility with TLS before
2030 extensions were defined.
2032 client_version
2033 The version of the TLS protocol by which the client wishes to
2034 communicate during this session. This SHOULD be the latest
2035 (highest valued) version supported by the client. For this
2036 version of the specification, the version will be 3.3 (See
2037 Appendix E for details about backward compatibility).
2039 random
2040 A client-generated random structure.
2042 session_id
2043 The ID of a session the client wishes to use for this connection.
2044 This field should be empty if no session_id is available, or it
2045 the client wishes to generate new security parameters.
2047 cipher_suites
2048 This is a list of the cryptographic options supported by the
2049 client, with the client's first preference first. If the
2050 session_id field is not empty (implying a session resumption
2051 request) this vector MUST include at least the cipher_suite from
2052 that session. Values are defined in Appendix A.5.
2056 Dierks & Rescorla Standards Track [Page 38]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2059 compression_methods
2060 This is a list of the compression methods supported by the
2061 client, sorted by client preference. If the session_id field is
2062 not empty (implying a session resumption request) it MUST include
2063 the compression_method from that session. This vector MUST
2064 contain, and all implementations MUST support,
2065 CompressionMethod.null. Thus, a client and server will always be
2066 able to agree on a compression method.
2068 client_hello_extension_list
2069 Clients MAY request extended functionality from servers by
2070 sending data in the client_hello_extension_list. Here the new
2071 "client_hello_extension_list" field contains a list of
2072 extensions. The actual "Extension" format is defined in Section
2073 7.4.1.4.
2075 In the event that a client requests additional functionality using
2076 extensions, and this functionality is not supplied by the server, the
2077 client MAY abort the handshake. A server that supports the
2078 extensions mechanism MUST accept only client hello messages in either
2079 the original (TLS 1.0/TLS 1.1) ClientHello or the extended
2080 ClientHello format defined in this document, and (as for all other
2081 messages) MUST check that the amount of data in the message precisely
2082 matches one of these formats; if not then it MUST send a fatal
2083 "decode_error" alert.
2085 After sending the client hello message, the client waits for a server
2086 hello message. Any other handshake message returned by the server
2087 except for a hello request is treated as a fatal error.
2090 7.4.1.3. Server Hello
2093 When this message will be sent:
2094 The server will send this message in response to a client hello
2095 message when it was able to find an acceptable set of algorithms.
2096 If it cannot find such a match, it will respond with a handshake
2097 failure alert.
2099 Structure of this message:
2100 struct {
2101 ProtocolVersion server_version;
2102 Random random;
2103 SessionID session_id;
2104 CipherSuite cipher_suite;
2105 CompressionMethod compression_method;
2106 select (extensions_present) {
2110 Dierks & Rescorla Standards Track [Page 39]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2113 case false:
2114 struct {};
2115 case true:
2116 Extension extensions<0..2^16-1>;
2117 };
2118 } ServerHello;
2120 The presence of extensions can be detected by determining whether
2121 there are bytes following the compression_method field at the end of
2122 the ServerHello.
2124 server_version
2125 This field will contain the lower of that suggested by the client
2126 in the client hello and the highest supported by the server. For
2127 this version of the specification, the version is 3.3. (See
2128 Appendix E for details about backward compatibility.)
2130 random
2131 This structure is generated by the server and MUST be
2132 independently generated from the ClientHello.random.
2134 session_id
2135 This is the identity of the session corresponding to this
2136 connection. If the ClientHello.session_id was non-empty, the
2137 server will look in its session cache for a match. If a match is
2138 found and the server is willing to establish the new connection
2139 using the specified session state, the server will respond with
2140 the same value as was supplied by the client. This indicates a
2141 resumed session and dictates that the parties must proceed
2142 directly to the finished messages. Otherwise this field will
2143 contain a different value identifying the new session. The server
2144 may return an empty session_id to indicate that the session will
2145 not be cached and therefore cannot be resumed. If a session is
2146 resumed, it must be resumed using the same cipher suite it was
2147 originally negotiated with. Note that there is no requirement
2148 that the server resume any session even if it had formerly
2149 provided a session_id. Client MUST be prepared to do a full
2150 negotiation -- including negotiating new cipher suites -- during
2151 any handshake.
2153 cipher_suite
2154 The single cipher suite selected by the server from the list in
2155 ClientHello.cipher_suites. For resumed sessions, this field is
2156 the value from the state of the session being resumed.
2158 compression_method
2159 The single compression algorithm selected by the server from the
2160 list in ClientHello.compression_methods. For resumed sessions
2164 Dierks & Rescorla Standards Track [Page 40]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2167 this field is the value from the resumed session state.
2169 server_hello_extension_list
2170 A list of extensions. Note that only extensions offered by the
2171 client can appear in the server's list.
2173 7.4.1.4 Hello Extensions
2175 The extension format is:
2177 struct {
2178 ExtensionType extension_type;
2179 opaque extension_data<0..2^16-1>;
2180 } Extension;
2182 enum {
2183 signature_hash_types(TBD-BY-IANA), (65535)
2184 } ExtensionType;
2187 Here:
2189 - "extension_type" identifies the particular extension type.
2191 - "extension_data" contains information specific to the particular
2192 extension type.
2194 The initial set of extensions is defined in a companion document
2195 [TLSEXT]. The list of extension types is maintained by IANA as
2196 described in Section 12.
2198 There are subtle (and not so subtle) interactions that may occur in
2199 this protocol between new features and existing features which may
2200 result in a significant reduction in overall security, The following
2201 considerations should be taken into account when designing new
2202 extensions:
2204 - Some cases where a server does not agree to an extension are
2205 error
2206 conditions, and some simply a refusal to support a particular
2207 feature. In general error alerts should be used for the former,
2208 and a field in the server extension response for the latter.
2210 - Extensions should as far as possible be designed to prevent any
2211 attack that forces use (or non-use) of a particular feature by
2212 manipulation of handshake messages. This principle should be
2213 followed regardless of whether the feature is believed to cause a
2214 security problem.
2218 Dierks & Rescorla Standards Track [Page 41]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2221 Often the fact that the extension fields are included in the
2222 inputs to the Finished message hashes will be sufficient, but
2223 extreme care is needed when the extension changes the meaning of
2224 messages sent in the handshake phase. Designers and implementors
2225 should be aware of the fact that until the handshake has been
2226 authenticated, active attackers can modify messages and insert,
2227 remove, or replace extensions.
2229 - It would be technically possible to use extensions to change
2230 major aspects of the design of TLS; for example the design of
2231 cipher suite negotiation. This is not recommended; it would be
2232 more appropriate to define a new version of TLS - particularly
2233 since the TLS handshake algorithms have specific protection
2234 against version rollback attacks based on the version number, and
2235 the possibility of version rollback should be a significant
2236 consideration in any major design change.
2238 7.4.1.4.1 Cert Hash Types
2240 The client MAY use the "signature_hash_types" to indicate to the
2241 server which hash functions may be used in digital signatures.
2242 The "extension_data" field of this extension contains:
2244 enum{
2245 md5(0), sha1(1), sha256(2), sha384(3), sha512(4), (255)
2246 } HashType;
2248 struct {
2249 HashType types<1..255>;
2250 } SignatureHashTypes;
2252 These values indicate support for MD5 [MD5], SHA-1, SHA-256, SHA-384,
2253 and SHA-512 [SHA] respectively. The server MUST NOT send this
2254 extension. The values are indicated in descending order of
2255 preference.
2257 Clients SHOULD send this extension if they support any algorithm
2258 other than SHA-1. If this extension is not used, servers SHOULD
2259 assume that the client supports only SHA-1. Note: this is a change
2260 from TLS 1.1 where there are no explicit rules but as a practical
2261 matter one can assume that the peer supports MD5 and SHA-1.
2263 7.4.2. Server Certificate
2265 When this message will be sent:
2266 The server MUST send a certificate whenever the agreed-upon key
2267 exchange method uses certificates for authentication (this
2268 includes all key exchange methods defined in this document except
2272 Dierks & Rescorla Standards Track [Page 42]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2275 DH_anon). This message will always immediately follow the server
2276 hello message.
2278 Meaning of this message:
2279 The certificate type MUST be appropriate for the selected cipher
2280 suite's key exchange algorithm, and is generally an X.509v3
2281 certificate. It MUST contain a key that matches the key exchange
2282 method, as follows. Unless otherwise specified, the signing
2283 algorithm for the certificate MUST be the same as the algorithm
2284 for the certificate key. Unless otherwise specified, the public
2285 key MAY be of any length.
2287 Key Exchange Algorithm Certificate Key Type
2289 RSA RSA public key; the certificate MUST
2290 allow the key to be used for encryption.
2292 DHE_DSS DSS public key.
2294 DHE_RSA RSA public key that can be used for
2295 signing.
2297 DH_DSS Diffie-Hellman key. The algorithm used
2298 to sign the certificate MUST be DSS.
2300 DH_RSA Diffie-Hellman key. The algorithm used
2301 to sign the certificate MUST be RSA.
2303 All certificate profiles and key and cryptographic formats are
2304 defined by the IETF PKIX working group [PKIX]. When a key usage
2305 extension is present, the digitalSignature bit MUST be set for the
2306 key to be eligible for signing, as described above, and the
2307 keyEncipherment bit MUST be present to allow encryption, as described
2308 above. The keyAgreement bit must be set on Diffie-Hellman
2309 certificates.
2311 As CipherSuites that specify new key exchange methods are specified
2312 for the TLS Protocol, they will imply certificate format and the
2313 required encoded keying information.
2315 Structure of this message:
2316 opaque ASN.1Cert<1..2^24-1>;
2318 struct {
2319 ASN.1Cert certificate_list<0..2^24-1>;
2320 } Certificate;
2322 certificate_list
2326 Dierks & Rescorla Standards Track [Page 43]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2329 This is a sequence (chain) of X.509v3 certificates. The sender's
2330 certificate must come first in the list. Each following
2331 certificate must directly certify the one preceding it. Because
2332 certificate validation requires that root keys be distributed
2333 independently, the self-signed certificate that specifies the
2334 root certificate authority may optionally be omitted from the
2335 chain, under the assumption that the remote end must already
2336 possess it in order to validate it in any case.
2338 The same message type and structure will be used for the client's
2339 response to a certificate request message. Note that a client MAY
2340 send no certificates if it does not have an appropriate certificate
2341 to send in response to the server's authentication request.
2343 Note: PKCS #7 [PKCS7] is not used as the format for the certificate
2344 vector because PKCS #6 [PKCS6] extended certificates are not
2345 used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making
2346 the task of parsing the list more difficult.
2348 7.4.3. Server Key Exchange Message
2350 When this message will be sent:
2351 This message will be sent immediately after the server
2352 certificate message (or the server hello message, if this is an
2353 anonymous negotiation).
2355 The server key exchange message is sent by the server only when
2356 the server certificate message (if sent) does not contain enough
2357 data to allow the client to exchange a premaster secret. This is
2358 true for the following key exchange methods:
2360 DHE_DSS
2361 DHE_RSA
2362 DH_anon
2364 It is not legal to send the server key exchange message for the
2365 following key exchange methods:
2367 RSA
2368 DH_DSS
2369 DH_RSA
2371 Meaning of this message:
2372 This message conveys cryptographic information to allow the
2373 client to communicate the premaster secret: a Diffie-Hellman
2374 public key with which the client can complete a key exchange
2375 (with the result being the premaster secret) or a public key for
2376 some other algorithm.
2380 Dierks & Rescorla Standards Track [Page 44]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2383 As additional CipherSuites are defined for TLS that include new key
2384 exchange algorithms, the server key exchange message will be sent if
2385 and only if the certificate type associated with the key exchange
2386 algorithm does not provide enough information for the client to
2387 exchange a premaster secret.
2389 If the client has offered the SignatureHashTypes extension, the hash
2390 function MUST be one of those listed in that extension. Otherwise it
2391 MUST be assumed that only SHA-1 is supported.
2393 If the SignatureAlgorithm being used to sign the ServerKeyExchange
2394 message is DSA, the hash algorithm MUST be SHA-1. [TODO: This is
2395 incorrect. What it should say is that it must be specified in the
2396 SPKI of the cert. However, I don't believe this is actually defined.
2397 Rather, the DSA certs just say dsa. We need new certs to say
2398 dsaWithSHAXXX.]
2400 If the SignatureAlgorithm is RSA, then any hash function accepted by
2401 the client MAY be used. The selected hash function MUST be indicated
2402 in the digest_algorithm field of the signature structure.
2404 The hash algorithm is denoted Hash below. Hash.length is the length
2405 of the output of that algorithm.
2407 Structure of this message:
2408 enum { diffie_hellman, rsa} KeyExchangeAlgorithm;
2410 struct {
2411 opaque dh_p<1..2^16-1>;
2412 opaque dh_g<1..2^16-1>;
2413 opaque dh_Ys<1..2^16-1>;
2414 } ServerDHParams; /* Ephemeral DH parameters */
2416 dh_p
2417 The prime modulus used for the Diffie-Hellman operation.
2419 dh_g
2420 The generator used for the Diffie-Hellman operation.
2422 dh_Ys
2423 The server's Diffie-Hellman public value (g^X mod p).
2425 struct {
2426 select (KeyExchangeAlgorithm) {
2427 case diffie_hellman:
2428 ServerDHParams params;
2429 Signature signed_params;
2430 };
2434 Dierks & Rescorla Standards Track [Page 45]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2437 } ServerKeyExchange;
2439 struct {
2440 select (KeyExchangeAlgorithm) {
2441 case diffie_hellman:
2442 ServerDHParams params;
2443 };
2444 } ServerParams;
2446 params
2447 The server's key exchange parameters.
2449 signed_params
2450 For non-anonymous key exchanges, a hash of the corresponding
2451 params value, with the signature appropriate to that hash
2452 applied.
2454 hash
2455 Hash(ClientHello.random + ServerHello.random + ServerParams)
2457 sha_hash
2458 SHA1(ClientHello.random + ServerHello.random + ServerParams)
2460 enum { anonymous, rsa, dsa } SignatureAlgorithm;
2463 struct {
2464 select (SignatureAlgorithm) {
2465 case anonymous: struct { };
2466 case rsa:
2467 HashType digest_algorithm; // NEW
2468 digitally-signed struct {
2469 opaque hash[Hash.length];
2470 };
2471 case dsa:
2472 digitally-signed struct {
2473 opaque sha_hash[20];
2474 };
2475 };
2476 };
2477 } Signature;
2479 7.4.4. Certificate Request
2481 When this message will be sent:
2482 A non-anonymous server can optionally request a certificate from
2483 the client, if appropriate for the selected cipher suite. This
2484 message, if sent, will immediately follow the Server Key Exchange
2488 Dierks & Rescorla Standards Track [Page 46]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2491 message (if it is sent; otherwise, the Server Certificate
2492 message).
2494 Structure of this message:
2495 enum {
2496 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
2497 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
2498 fortezza_dms_RESERVED(20),
2499 (255)
2500 } ClientCertificateType;
2503 opaque DistinguishedName<1..2^16-1>;
2505 struct {
2506 ClientCertificateType certificate_types<1..2^8-1>;
2507 HashType certificate_hash<1..2^8-1>;
2508 DistinguishedName certificate_authorities<0..2^16-1>;
2509 } CertificateRequest;
2511 certificate_types
2512 This field is a list of the types of certificates requested,
2513 sorted in order of the server's preference.
2515 certificate_types
2516 A list of the types of certificate types which the client may
2517 offer.
2518 rsa_sign a certificate containing an RSA key
2519 dss_sign a certificate containing a DSS key
2520 rsa_fixed_dh a certificate signed with RSA and containing
2521 a static DH key.
2522 dss_fixed_dh a certificate signed with DSS and containing
2523 a static DH key
2525 Certificate types rsa_sign and dss_sign SHOULD contain
2526 certificates signed with the same algorithm. However, this is
2527 not required. This is a holdover from TLS 1.0 and 1.1.
2530 certificate_hash
2531 A list of acceptable hash algorithms to be used in signatures
2532 in both the client certificate and the CertificateVerify.
2533 These algorithms are listed in descending order of
2534 preference.
2537 certificate_authorities
2538 A list of the distinguished names [X501] of acceptable
2542 Dierks & Rescorla Standards Track [Page 47]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2545 certificateauthorities, represented in DER-encoded format.
2546 These distinguished names may specify a desired distinguished
2547 name for a root CA or for a subordinate CA; thus, this
2548 message can be used both to describe known roots and a
2549 desired authorization space. If the certificate_authorities
2550 list is empty then the client MAY send any certificate of the
2551 appropriate ClientCertificateType, unless there is some
2552 external arrangement to the contrary.
2554 New ClientCertificateType values are assigned by IANA as described in
2555 Section 12.
2557 Note: Values listed as RESERVED may not be used. They were
2558 used in SSLv3.
2560 Note: It is a fatal handshake_failure alert for an anonymous server to
2561 request client authentication.
2563 7.4.5 Server hello done
2565 When this message will be sent:
2566 The server hello done message is sent by the server to indicate
2567 the end of the server hello and associated messages. After
2568 sending this message, the server will wait for a client response.
2570 Meaning of this message:
2571 This message means that the server is done sending messages to
2572 support the key exchange, and the client can proceed with its
2573 phase of the key exchange.
2575 Upon receipt of the server hello done message, the client SHOULD
2576 verify that the server provided a valid certificate, if required
2577 and check that the server hello parameters are acceptable.
2579 Structure of this message:
2580 struct { } ServerHelloDone;
2582 7.4.6. Client Certificate
2584 When this message will be sent:
2585 This is the first message the client can send after receiving a
2586 server hello done message. This message is only sent if the
2587 server requests a certificate. If no suitable certificate is
2588 available, the client MUST send a certificate message containing
2589 no certificates. That is, the certificate_list structure has a
2590 length of zero. If client authentication is required by the
2591 server for the handshake to continue, it may respond with a fatal
2592 handshake failure alert. Client certificates are sent using the
2596 Dierks & Rescorla Standards Track [Page 48]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2599 Certificate structure defined in Section 7.4.2.
2602 Note: When using a static Diffie-Hellman based key exchange method
2603 (DH_DSS or DH_RSA), if client authentication is requested, the
2604 Diffie-Hellman group and generator encoded in the client's
2605 certificate MUST match the server specified Diffie-Hellman
2606 parameters if the client's parameters are to be used for the key
2607 exchange.
2609 7.4.7. Client Key Exchange Message
2611 When this message will be sent:
2612 This message is always sent by the client. It MUST immediately
2613 follow the client certificate message, if it is sent. Otherwise
2614 it MUST be the first message sent by the client after it receives
2615 the server hello done message.
2617 Meaning of this message:
2618 With this message, the premaster secret is set, either though
2619 direct transmission of the RSA-encrypted secret, or by the
2620 transmission of Diffie-Hellman parameters that will allow each
2621 side to agree upon the same premaster secret. When the key
2622 exchange method is DH_RSA or DH_DSS, client certification has
2623 been requested, and the client was able to respond with a
2624 certificate that contained a Diffie-Hellman public key whose
2625 parameters (group and generator) matched those specified by the
2626 server in its certificate, this message MUST NOT contain any
2627 data.
2629 Structure of this message:
2630 The choice of messages depends on which key exchange method has
2631 been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
2632 definition.
2634 struct {
2635 select (KeyExchangeAlgorithm) {
2636 case rsa: EncryptedPreMasterSecret;
2637 case diffie_hellman: ClientDiffieHellmanPublic;
2638 } exchange_keys;
2639 } ClientKeyExchange;
2641 7.4.7.1. RSA Encrypted Premaster Secret Message
2643 Meaning of this message:
2644 If RSA is being used for key agreement and authentication, the
2645 client generates a 48-byte premaster secret, encrypts it using
2646 the public key from the server's certificate and sends the result
2650 Dierks & Rescorla Standards Track [Page 49]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2653 in an encrypted premaster secret message. This structure is a
2654 variant of the client key exchange message and is not a message
2655 in itself.
2657 Structure of this message:
2658 struct {
2659 ProtocolVersion client_version;
2660 opaque random[46];
2661 } PreMasterSecret;
2663 client_version
2664 The latest (newest) version supported by the client. This is
2665 used to detect version roll-back attacks.
2667 random
2668 46 securely-generated random bytes.
2670 struct {
2671 public-key-encrypted PreMasterSecret pre_master_secret;
2672 } EncryptedPreMasterSecret;
2674 pre_master_secret
2675 This random value is generated by the client and is used to
2676 generate the master secret, as specified in Section 8.1.
2678 Note: The version number in the PreMasterSecret is the version offered
2679 by the client in the ClientHello.client_version, not the
2680 version negotiated for the connection. This feature is
2681 designed to prevent rollback attacks. Unfortunately, some
2682 old implementations use the negotiated version instead and
2683 therefore checking the version number may lead to failure to
2684 interoperate with such incorrect client implementations.
2686 Client implementations MUST always send the correct version
2687 number in PreMasterSecret. If ClientHello.client_version is
2688 TLS 1.1 or higher, server implementations MUST check the
2689 version number as described in the note below. If the version
2690 number is earlier than 1.0, server implementations SHOULD
2691 check the version number, but MAY have a configuration option
2692 to disable the check. Note that if the check fails, the
2693 PreMasterSecret SHOULD be randomized as described below.
2695 Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
2696 [KPR03] can be used to attack a TLS server that reveals whether a
2697 particular message, when decrypted, is properly PKCS#1 formatted,
2698 contains a valid PreMasterSecret structure, or has the correct
2699 version number.
2704 Dierks & Rescorla Standards Track [Page 50]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2707 The best way to avoid these vulnerabilities is to treat incorrectly
2708 formatted messages in a manner indistinguishable from correctly
2709 formatted RSA blocks. In other words:
2711 1. Generate a string R of 46 random bytes
2713 2. Decrypt the message M
2715 3. If the PKCS#1 padding is not correct, or the length of
2716 message M is not exactly 48 bytes:
2717 premaster secret = ClientHello.client_version || R
2718 else If ClientHello.client_version <= TLS 1.0, and
2719 version number check is explicitly disabled:
2720 premaster secret = M
2721 else:
2722 premaster secret = ClientHello.client_version || M[2..47]
2724 In any case, a TLS server MUST NOT generate an alert if processing an
2725 RSA-encrypted premaster secret message fails, or the version number
2726 is not as expected. Instead, it MUST continue the handshake with a
2727 randomly generated premaster secret. It may be useful to log the
2728 real cause of failure for troubleshooting purposes; however, care
2729 must be taken to avoid leaking the information to an attacker
2730 (though, e.g., timing, log files, or other channels.)
2732 The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
2733 against the Bleichenbacher attack. However, for maximal compatibility
2734 with earlier versions of TLS, this specification uses the RSAES-
2735 PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known
2736 to exist provided that the above recommendations are followed.
2738 Implementation Note: Public-key-encrypted data is represented as an
2739 opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
2740 PreMasterSecret in a ClientKeyExchange is preceded by two length
2741 bytes. These bytes are redundant in the case of RSA because the
2742 EncryptedPreMasterSecret is the only data in the ClientKeyExchange
2743 and its length can therefore be unambiguously determined. The SSLv3
2744 specification was not clear about the encoding of public-key-
2745 encrypted data, and therefore many SSLv3 implementations do not
2746 include the the length bytes, encoding the RSA encrypted data
2747 directly in the ClientKeyExchange message.
2749 This specification requires correct encoding of the
2750 EncryptedPreMasterSecret complete with length bytes. The resulting
2751 PDU is incompatible with many SSLv3 implementations. Implementors
2752 upgrading from SSLv3 MUST modify their implementations to generate
2753 and accept the correct encoding. Implementors who wish to be
2754 compatible with both SSLv3 and TLS should make their implementation's
2758 Dierks & Rescorla Standards Track [Page 51]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2761 behavior dependent on the protocol version.
2763 Implementation Note: It is now known that remote timing-based attacks
2764 on TLS are possible, at least when the client and server are on the
2765 same LAN. Accordingly, implementations that use static RSA keys MUST
2766 use RSA blinding or some other anti-timing technique, as described in
2767 [TIMING].
2770 7.4.7.2. Client Diffie-Hellman Public Value
2772 Meaning of this message:
2773 This structure conveys the client's Diffie-Hellman public value
2774 (Yc) if it was not already included in the client's certificate.
2775 The encoding used for Yc is determined by the enumerated
2776 PublicValueEncoding. This structure is a variant of the client
2777 key exchange message, and not a message in itself.
2779 Structure of this message:
2780 enum { implicit, explicit } PublicValueEncoding;
2782 implicit
2783 If the client certificate already contains a suitable Diffie-
2784 Hellman key, then Yc is implicit and does not need to be sent
2785 again. In this case, the client key exchange message will be
2786 sent, but it MUST be empty.
2788 explicit
2789 Yc needs to be sent.
2791 struct {
2792 select (PublicValueEncoding) {
2793 case implicit: struct { };
2794 case explicit: opaque dh_Yc<1..2^16-1>;
2795 } dh_public;
2796 } ClientDiffieHellmanPublic;
2798 dh_Yc
2799 The client's Diffie-Hellman public value (Yc).
2801 7.4.8. Certificate verify
2803 When this message will be sent:
2804 This message is used to provide explicit verification of a client
2805 certificate. This message is only sent following a client
2806 certificate that has signing capability (i.e. all certificates
2807 except those containing fixed Diffie-Hellman parameters). When
2808 sent, it MUST immediately follow the client key exchange message.
2812 Dierks & Rescorla Standards Track [Page 52]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2815 Structure of this message:
2816 struct {
2817 Signature signature;
2818 } CertificateVerify;
2820 The Signature type is defined in 7.4.3.
2823 The hash function MUST be one of the algorithms offered in the
2824 CertificateRequest message.
2826 If the SignatureAlgorithm being used to sign the ServerKeyExchange
2827 message is DSA, the hash function used MUST be SHA-1.
2828 [TODO: This is incorrect. What it should say is that it must
2829 be specified in the SPKI of the cert. However, I don't believe
2830 this is actually defined. Rather, the DSA certs just say
2831 dsa. We need new certs to say dsaWithSHAXXX]
2833 If the SignatureAlgorithm is RSA, then any of the functions offered
2834 by the server may be used. The selected hash function MUST be
2835 indicated in the digest_algorithm field of the signature structure.
2837 The hash algorithm is denoted Hash below.
2839 CertificateVerify.signature.hash
2840 Hash(handshake_messages);
2842 CertificateVerify.signature.sha_hash
2843 SHA(handshake_messages);
2845 Here handshake_messages refers to all handshake messages sent or
2846 received starting at client hello up to but not including this
2847 message, including the type and length fields of the handshake
2848 messages. This is the concatenation of all the Handshake structures
2849 as defined in 7.4 exchanged thus far.
2851 7.4.9. Finished
2853 When this message will be sent:
2854 A finished message is always sent immediately after a change
2855 cipher spec message to verify that the key exchange and
2856 authentication processes were successful. It is essential that a
2857 change cipher spec message be received between the other
2858 handshake messages and the Finished message.
2860 Meaning of this message:
2861 The finished message is the first protected with the just-
2862 negotiated algorithms, keys, and secrets. Recipients of finished
2866 Dierks & Rescorla Standards Track [Page 53]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2869 messages MUST verify that the contents are correct. Once a side
2870 has sent its Finished message and received and validated the
2871 Finished message from its peer, it may begin to send and receive
2872 application data over the connection.
2874 struct {
2875 opaque verify_data[SecurityParameters.verify_data_length];
2876 } Finished;
2878 verify_data
2879 PRF(master_secret, finished_label, Hash(handshake_messages))
2880 [0..SecurityParameters.verify_data_length-1];
2882 finished_label
2883 For Finished messages sent by the client, the string "client
2884 finished". For Finished messages sent by the server, the
2885 string "server finished".
2887 Hash denotes the negotiated hash used for the PRF. If a new
2888 PRF is defined, then this hash MUST be specified.
2890 In previous versions of TLS, the verify_data was always 12
2891 octets long. In the current version of TLS, it depends on the
2892 cipher suite. Any cipher suite which does not explicitly
2893 specify SecurityParameters.verify_data_length has a
2894 SecurityParameters.verify_data_length equal to 12. This
2895 includes all existing cipher suites. Note that this
2896 representation has the same encoding as with previous
2897 versions.
2899 Future cipher suites MAY specify other lengths but such
2900 length MUST be at least 12 bytes.
2902 handshake_messages
2903 All of the data from all messages in this handshake (not
2904 including any HelloRequest messages) up to but not including
2905 this message. This is only data visible at the handshake
2906 layer and does not include record layer headers. This is the
2907 concatenation of all the Handshake structures as defined in
2908 7.4, exchanged thus far.
2910 It is a fatal error if a finished message is not preceded by a change
2911 cipher spec message at the appropriate point in the handshake.
2913 The value handshake_messages includes all handshake messages starting
2914 at client hello up to, but not including, this finished message. This
2915 may be different from handshake_messages in Section 7.4.8 because it
2916 would include the certificate verify message (if sent). Also, the
2920 Dierks & Rescorla Standards Track [Page 54]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2923 handshake_messages for the finished message sent by the client will
2924 be different from that for the finished message sent by the server,
2925 because the one that is sent second will include the prior one.
2927 Note: Change cipher spec messages, alerts, and any other record types
2928 are not handshake messages and are not included in the hash
2929 computations. Also, Hello Request messages are omitted from
2930 handshake hashes.
2932 8. Cryptographic Computations
2934 In order to begin connection protection, the TLS Record Protocol
2935 requires specification of a suite of algorithms, a master secret, and
2936 the client and server random values. The authentication, encryption,
2937 and MAC algorithms are determined by the cipher_suite selected by the
2938 server and revealed in the server hello message. The compression
2939 algorithm is negotiated in the hello messages, and the random values
2940 are exchanged in the hello messages. All that remains is to calculate
2941 the master secret.
2943 8.1. Computing the Master Secret
2945 For all key exchange methods, the same algorithm is used to convert
2946 the pre_master_secret into the master_secret. The pre_master_secret
2947 should be deleted from memory once the master_secret has been
2948 computed.
2950 master_secret = PRF(pre_master_secret, "master secret",
2951 ClientHello.random + ServerHello.random)
2952 [0..47];
2954 The master secret is always exactly 48 bytes in length. The length of
2955 the premaster secret will vary depending on key exchange method.
2957 8.1.1. RSA
2959 When RSA is used for server authentication and key exchange, a
2960 48-byte pre_master_secret is generated by the client, encrypted under
2961 the server's public key, and sent to the server. The server uses its
2962 private key to decrypt the pre_master_secret. Both parties then
2963 convert the pre_master_secret into the master_secret, as specified
2964 above.
2966 8.1.2. Diffie-Hellman
2968 A conventional Diffie-Hellman computation is performed. The
2969 negotiated key (Z) is used as the pre_master_secret, and is converted
2970 into the master_secret, as specified above. Leading bytes of Z that
2974 Dierks & Rescorla Standards Track [Page 55]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
2977 contain all zero bits are stripped before it is used as the
2978 pre_master_secret.
2980 Note: Diffie-Hellman parameters are specified by the server and may
2981 be either ephemeral or contained within the server's certificate.
2983 9. Mandatory Cipher Suites
2985 In the absence of an application profile standard specifying
2986 otherwise, a TLS compliant application MUST implement the cipher
2987 suite TLS_RSA_WITH_AES_128_CBC_SHA.
2989 10. Application Data Protocol
2991 Application data messages are carried by the Record Layer and are
2992 fragmented, compressed, and encrypted based on the current connection
2993 state. The messages are treated as transparent data to the record
2994 layer.
2996 11. Security Considerations
2998 Security issues are discussed throughout this memo, especially in
2999 Appendices D, E, and F.
3001 12. IANA Considerations
3003 This document uses several registries that were originally created in
3004 [RFC4346]. IANA is requested to update (has updated) these to
3005 reference this document. The registries and their allocation policies
3006 (unchanged from [TLS1.1]) are listed below.
3008 o TLS ClientCertificateType Identifiers Registry: Future
3009 values in the range 0-63 (decimal) inclusive are assigned via
3010 Standards Action [RFC2434]. Values in the range 64-223
3011 (decimal) inclusive are assigned Specification Required
3012 [RFC2434]. Values from 224-255 (decimal) inclusive are
3013 reserved for Private Use [RFC2434].
3015 o TLS Cipher Suite Registry: Future values with the first byte
3016 in the range 0-191 (decimal) inclusive are assigned via
3017 Standards Action [RFC2434]. Values with the first byte in
3018 the range 192-254 (decimal) are assigned via Specification
3019 Required [RFC2434]. Values with the first byte 255 (decimal)
3020 are reserved for Private Use [RFC2434].
3022 o TLS ContentType Registry: Future values are allocated via
3023 Standards Action [RFC2434].
3028 Dierks & Rescorla Standards Track [Page 56]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3031 o TLS Alert Registry: Future values are allocated via
3032 Standards Action [RFC2434].
3034 o TLS HandshakeType Registry: Future values are allocated via
3035 Standards Action [RFC2434].
3037 This document also uses a registry originally created in [RFC4366].
3038 IANA is requested to update (has updated) it to reference this
3039 document. The registry and its allocation policy (unchanged from
3040 [RFC4366]) is listed below:.
3042 o TLS ExtensionType Registry: Future values are allocated
3043 via IETF Consensus [RFC2434]
3045 In addition, this document defines one new registry to be maintained
3046 by IANA:
3048 o TLS HashType Registry: The registry will be initially
3049 populated with the values described in Section 7.4.1.4.7.
3050 Future values in the range 0-63 (decimal) inclusive are
3051 assigned via Standards Action [RFC2434]. Values in the
3052 range 64-223 (decimal) inclusive are assigned via
3053 Specification Required [RFC2434]. Values from 224-255
3054 (decimal) inclusive are reserved for Private Use [RFC2434].
3056 This document defines one new TLS extension, cert_hash_type, which is
3057 to be (has been) allocated value TBD-BY-IANA in the TLS ExtensionType
3058 registry.
3060 This document also uses the TLS Compression Method Identifiers
3061 Registry, defined in [RFC3749]. IANA is requested to allocate value
3062 0 for the "null" compression method.
3082 Dierks & Rescorla Standards Track [Page 57]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3085 Appendix A. Protocol Constant Values
3087 This section describes protocol types and constants.
3089 A.1. Record Layer
3091 struct {
3092 uint8 major, minor;
3093 } ProtocolVersion;
3095 ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/
3097 enum {
3098 change_cipher_spec(20), alert(21), handshake(22),
3099 application_data(23), (255)
3100 } ContentType;
3102 struct {
3103 ContentType type;
3104 ProtocolVersion version;
3105 uint16 length;
3106 opaque fragment[TLSPlaintext.length];
3107 } TLSPlaintext;
3109 struct {
3110 ContentType type;
3111 ProtocolVersion version;
3112 uint16 length;
3113 opaque fragment[TLSCompressed.length];
3114 } TLSCompressed;
3116 struct {
3117 ContentType type;
3118 ProtocolVersion version;
3119 uint16 length;
3120 select (SecurityParameters.cipher_type) {
3121 case stream: GenericStreamCipher;
3122 case block: GenericBlockCipher;
3123 case aead: GenericAEADCipher;
3124 } fragment;
3125 } TLSCiphertext;
3127 stream-ciphered struct {
3128 opaque content[TLSCompressed.length];
3129 opaque MAC[SecurityParameters.mac_length];
3130 } GenericStreamCipher;
3132 struct {
3136 Dierks & Rescorla Standards Track [Page 58]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3139 opaque IV[SecurityParameters.record_iv_length];
3140 block-ciphered struct {
3141 opaque content[TLSCompressed.length];
3142 opaque MAC[SecurityParameters.mac_length];
3143 uint8 padding[GenericBlockCipher.padding_length];
3144 uint8 padding_length;
3145 };
3146 } GenericBlockCipher;
3148 aead-ciphered struct {
3149 opaque IV[SecurityParameters.iv_length];
3150 opaque aead_output[AEADEncrypted.length];
3151 } GenericAEADCipher;
3153 A.2. Change Cipher Specs Message
3155 struct {
3156 enum { change_cipher_spec(1), (255) } type;
3157 } ChangeCipherSpec;
3159 A.3. Alert Messages
3161 enum { warning(1), fatal(2), (255) } AlertLevel;
3163 enum {
3164 close_notify(0),
3165 unexpected_message(10),
3166 bad_record_mac(20),
3167 decryption_failed_RESERVED(21),
3168 record_overflow(22),
3169 decompression_failure(30),
3170 handshake_failure(40),
3171 no_certificate_RESERVED(41),
3172 bad_certificate(42),
3173 unsupported_certificate(43),
3174 certificate_revoked(44),
3175 certificate_expired(45),
3176 certificate_unknown(46),
3177 illegal_parameter(47),
3178 unknown_ca(48),
3179 access_denied(49),
3180 decode_error(50),
3181 decrypt_error(51),
3182 export_restriction_RESERVED(60),
3183 protocol_version(70),
3184 insufficient_security(71),
3185 internal_error(80),
3186 user_canceled(90),
3190 Dierks & Rescorla Standards Track [Page 59]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3193 no_renegotiation(100),
3194 unsupported_extension(110), /* new */
3195 (255)
3196 } AlertDescription;
3198 struct {
3199 AlertLevel level;
3200 AlertDescription description;
3201 } Alert;
3244 Dierks & Rescorla Standards Track [Page 60]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3247 A.4. Handshake Protocol
3249 enum {
3250 hello_request(0), client_hello(1), server_hello(2),
3251 certificate(11), server_key_exchange (12),
3252 certificate_request(13), server_hello_done(14),
3253 certificate_verify(15), client_key_exchange(16),
3254 finished(20)
3255 (255)
3256 } HandshakeType;
3258 struct {
3259 HandshakeType msg_type;
3260 uint24 length;
3261 select (HandshakeType) {
3262 case hello_request: HelloRequest;
3263 case client_hello: ClientHello;
3264 case server_hello: ServerHello;
3265 case certificate: Certificate;
3266 case server_key_exchange: ServerKeyExchange;
3267 case certificate_request: CertificateRequest;
3268 case server_hello_done: ServerHelloDone;
3269 case certificate_verify: CertificateVerify;
3270 case client_key_exchange: ClientKeyExchange;
3271 case finished: Finished;
3272 } body;
3273 } Handshake;
3275 A.4.1. Hello Messages
3277 struct { } HelloRequest;
3279 struct {
3280 uint32 gmt_unix_time;
3281 opaque random_bytes[28];
3282 } Random;
3284 opaque SessionID<0..32>;
3286 uint8 CipherSuite[2];
3288 enum { null(0), (255) } CompressionMethod;
3290 struct {
3291 ProtocolVersion client_version;
3292 Random random;
3293 SessionID session_id;
3294 CipherSuite cipher_suites<2..2^16-1>;
3298 Dierks & Rescorla Standards Track [Page 61]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3301 CompressionMethod compression_methods<1..2^8-1>;
3302 select (extensions_present) {
3303 case false:
3304 struct {};
3305 case true:
3306 Extension extensions<0..2^16-1>;
3307 };
3308 } ClientHello;
3310 struct {
3311 ProtocolVersion server_version;
3312 Random random;
3313 SessionID session_id;
3314 CipherSuite cipher_suite;
3315 CompressionMethod compression_method;
3316 select (extensions_present) {
3317 case false:
3318 struct {};
3319 case true:
3320 Extension extensions<0..2^16-1>;
3321 };
3322 } ServerHello;
3324 struct {
3325 ExtensionType extension_type;
3326 opaque extension_data<0..2^16-1>;
3327 } Extension;
3329 enum {
3330 signature_hash_types(TBD-BY-IANA), (65535)
3331 } ExtensionType;
3333 A.4.2. Server Authentication and Key Exchange Messages
3335 opaque ASN.1Cert<2^24-1>;
3337 struct {
3338 ASN.1Cert certificate_list<0..2^24-1>;
3339 } Certificate;
3341 enum { diffie_hellman } KeyExchangeAlgorithm;
3343 struct {
3344 opaque dh_p<1..2^16-1>;
3345 opaque dh_g<1..2^16-1>;
3346 opaque dh_Ys<1..2^16-1>;
3347 } ServerDHParams;
3352 Dierks & Rescorla Standards Track [Page 62]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3355 struct {
3356 select (KeyExchangeAlgorithm) {
3357 case diffie_hellman:
3358 ServerDHParams params;
3359 Signature signed_params;
3360 }
3361 } ServerKeyExchange;
3363 enum { anonymous, rsa, dsa } SignatureAlgorithm;
3365 struct {
3366 select (KeyExchangeAlgorithm) {
3367 case diffie_hellman:
3368 ServerDHParams params;
3369 };
3370 } ServerParams;
3372 struct {
3373 select (SignatureAlgorithm) {
3374 case anonymous: struct { };
3375 case rsa:
3376 HashType digest_algorithm; // NEW
3377 digitally-signed struct {
3378 opaque hash[Hash.length];
3379 };
3380 case dsa:
3381 digitally-signed struct {
3382 opaque sha_hash[20];
3383 };
3384 };
3385 };
3386 } Signature;
3388 enum {
3389 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
3390 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
3391 fortezza_dms_RESERVED(20),
3392 (255)
3393 } ClientCertificateType;
3395 opaque DistinguishedName<1..2^16-1>;
3397 struct {
3398 ClientCertificateType certificate_types<1..2^8-1>;
3399 DistinguishedName certificate_authorities<0..2^16-1>;
3400 } CertificateRequest;
3402 struct { } ServerHelloDone;
3406 Dierks & Rescorla Standards Track [Page 63]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3409 A.4.3. Client Authentication and Key Exchange Messages
3411 struct {
3412 select (KeyExchangeAlgorithm) {
3413 case rsa: EncryptedPreMasterSecret;
3414 case diffie_hellman: ClientDiffieHellmanPublic;
3415 } exchange_keys;
3416 } ClientKeyExchange;
3418 struct {
3419 ProtocolVersion client_version;
3420 opaque random[46];
3421 } PreMasterSecret;
3423 struct {
3424 public-key-encrypted PreMasterSecret pre_master_secret;
3425 } EncryptedPreMasterSecret;
3427 enum { implicit, explicit } PublicValueEncoding;
3429 struct {
3430 select (PublicValueEncoding) {
3431 case implicit: struct {};
3432 case explicit: opaque DH_Yc<1..2^16-1>;
3433 } dh_public;
3434 } ClientDiffieHellmanPublic;
3436 struct {
3437 Signature signature;
3438 } CertificateVerify;
3440 A.4.4. Handshake Finalization Message
3442 struct {
3443 opaque verify_data[SecurityParameters.verify_data_length];
3444 } Finished;
3446 A.5. The CipherSuite
3448 The following values define the CipherSuite codes used in the client
3449 hello and server hello messages.
3451 A CipherSuite defines a cipher specification supported in TLS Version
3452 1.2.
3454 TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
3455 TLS connection during the first handshake on that channel, but MUST
3456 not be negotiated, as it provides no more protection than an
3460 Dierks & Rescorla Standards Track [Page 64]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3463 unsecured connection.
3465 CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
3467 The following CipherSuite definitions require that the server provide
3468 an RSA certificate that can be used for key exchange. The server may
3469 request either an RSA or a DSS signature-capable certificate in the
3470 certificate request message.
3472 CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
3473 CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
3474 CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
3475 CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
3476 CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
3477 CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
3478 CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
3479 CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F };
3480 CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 };
3482 The following CipherSuite definitions are used for server-
3483 authenticated (and optionally client-authenticated) Diffie-Hellman.
3484 DH denotes cipher suites in which the server's certificate contains
3485 the Diffie-Hellman parameters signed by the certificate authority
3486 (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
3487 parameters are signed by a DSS or RSA certificate, which has been
3488 signed by the CA. The signing algorithm used is specified after the
3489 DH or DHE parameter. The server can request an RSA or DSS signature-
3490 capable certificate from the client for client authentication or it
3491 may request a Diffie-Hellman certificate. Any Diffie-Hellman
3492 certificate provided by the client must use the parameters (group and
3493 generator) described by the server.
3495 CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
3496 CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
3497 CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
3498 CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
3499 CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
3500 CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
3501 CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
3502 CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
3503 CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x30 };
3504 CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x31 };
3505 CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x32 };
3506 CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x33 };
3507 CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x36 };
3508 CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x37 };
3509 CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x38 };
3510 CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x39 };
3514 Dierks & Rescorla Standards Track [Page 65]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3517 The following cipher suites are used for completely anonymous Diffie-
3518 Hellman communications in which neither party is authenticated. Note
3519 that this mode is vulnerable to man-in-the-middle attacks. Using
3520 this mode therefore is of limited use: These ciphersuites MUST NOT be
3521 used by TLS 1.2 implementations unless the application layer has
3522 specifically requested to allow anonymous key exchange. (Anonymous
3523 key exchange may sometimes be acceptable, for example, to support
3524 opportunistic encryption when no set-up for authentication is in
3525 place, or when TLS is used as part of more complex security protocols
3526 that have other means to ensure authentication.)
3528 CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00, 0x18 };
3529 CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00, 0x1A };
3530 CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x1B };
3531 CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 };
3532 CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A };
3534 Note that using non-anonymous key exchange without actually verifying
3535 the key exchange is essentially equivalent to anonymous key exchange,
3536 and the same precautions apply. While non-anonymous key exchange
3537 will generally involve a higher computational and communicational
3538 cost than anonymous key exchange, it may be in the interest of
3539 interoperability not to disable non-anonymous key exchange when the
3540 application layer is allowing anonymous key exchange.
3542 When SSLv3 and TLS 1.0 were designed, the United States restricted
3543 the export of cryptographic software containing certain strong
3544 encryption algorithms. A series of cipher suites were designed to
3545 operate at reduced key lengths in order to comply with those
3546 regulations. Due to advances in computer performance, these
3547 algorithms are now unacceptably weak and export restrictions have
3548 since been loosened. TLS 1.2 implementations MUST NOT negotiate these
3549 cipher suites in TLS 1.2 mode. However, for backward compatibility
3550 they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
3551 only servers. TLS 1.2 clients MUST check that the server did not
3552 choose one of these cipher suites during the handshake. These
3553 ciphersuites are listed below for informational purposes and to
3554 reserve the numbers.
3556 CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
3557 CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
3558 CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
3559 CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
3560 CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
3561 CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
3562 CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
3563 CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
3564 CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
3568 Dierks & Rescorla Standards Track [Page 66]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3571 New cipher suite values are assigned by IANA as described in Section
3572 12.
3574 Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
3575 reserved to avoid collision with Fortezza-based cipher suites in SSL
3576 3.
3578 A.6. The Security Parameters
3580 These security parameters are determined by the TLS Handshake
3581 Protocol and provided as parameters to the TLS Record Layer in order
3582 to initialize a connection state. SecurityParameters includes:
3584 enum { null(0), (255) } CompressionMethod;
3586 enum { server, client } ConnectionEnd;
3588 enum { null, rc4, rc2, des, 3des, des40, aes, idea }
3589 BulkCipherAlgorithm;
3591 enum { stream, block, aead } CipherType;
3593 enum { null, md5, sha } MACAlgorithm;
3595 /* The algorithms specified in CompressionMethod,
3596 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
3598 struct {
3599 ConnectionEnd entity;
3600 BulkCipherAlgorithm bulk_cipher_algorithm;
3601 CipherType cipher_type;
3602 uint8 enc_key_length;
3603 uint8 block_length;
3604 uint8 fixed_iv_length;
3605 uint8 record_iv_length;
3606 MACAlgorithm mac_algorithm;
3607 uint8 mac_length;
3608 uint8 mac_key_length;
3609 uint8 verify_data_length;
3610 CompressionMethod compression_algorithm;
3611 opaque master_secret[48];
3612 opaque client_random[32];
3613 opaque server_random[32];
3614 } SecurityParameters;
3622 Dierks & Rescorla Standards Track [Page 67]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3625 Appendix B. Glossary
3627 Advanced Encryption Standard (AES)
3628 AES is a widely used symmetric encryption algorithm. AES is a
3629 block cipher with a 128, 192, or 256 bit keys and a 16 byte block
3630 size. [AES] TLS currently only supports the 128 and 256 bit key
3631 sizes.
3633 application protocol
3634 An application protocol is a protocol that normally layers
3635 directly on top of the transport layer (e.g., TCP/IP). Examples
3636 include HTTP, TELNET, FTP, and SMTP.
3638 asymmetric cipher
3639 See public key cryptography.
3641 authenticated encryption with additional data (AEAD)
3642 A symmetric encryption algorithm that simultaneously provides
3643 confidentiality and message integrity.
3645 authentication
3646 Authentication is the ability of one entity to determine the
3647 identity of another entity.
3649 block cipher
3650 A block cipher is an algorithm that operates on plaintext in
3651 groups of bits, called blocks. 64 bits is a common block size.
3653 bulk cipher
3654 A symmetric encryption algorithm used to encrypt large quantities
3655 of data.
3657 cipher block chaining (CBC)
3658 CBC is a mode in which every plaintext block encrypted with a
3659 block cipher is first exclusive-ORed with the previous ciphertext
3660 block (or, in the case of the first block, with the
3661 initialization vector). For decryption, every block is first
3662 decrypted, then exclusive-ORed with the previous ciphertext block
3663 (or IV).
3665 certificate
3666 As part of the X.509 protocol (a.k.a. ISO Authentication
3667 framework), certificates are assigned by a trusted Certificate
3668 Authority and provide a strong binding between a party's identity
3669 or some other attributes and its public key.
3671 client
3672 The application entity that initiates a TLS connection to a
3676 Dierks & Rescorla Standards Track [Page 68]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3679 server. This may or may not imply that the client initiated the
3680 underlying transport connection. The primary operational
3681 difference between the server and client is that the server is
3682 generally authenticated, while the client is only optionally
3683 authenticated.
3685 client write key
3686 The key used to encrypt data written by the client.
3688 client write MAC secret
3689 The secret data used to authenticate data written by the client.
3691 connection
3692 A connection is a transport (in the OSI layering model
3693 definition) that provides a suitable type of service. For TLS,
3694 such connections are peer-to-peer relationships. The connections
3695 are transient. Every connection is associated with one session.
3697 Data Encryption Standard
3698 DES is a very widely used symmetric encryption algorithm. DES is
3699 a block cipher with a 56 bit key and an 8 byte block size. Note
3700 that in TLS, for key generation purposes, DES is treated as
3701 having an 8 byte key length (64 bits), but it still only provides
3702 56 bits of protection. (The low bit of each key byte is presumed
3703 to be set to produce odd parity in that key byte.) DES can also
3704 be operated in a mode where three independent keys and three
3705 encryptions are used for each block of data; this uses 168 bits
3706 of key (24 bytes in the TLS key generation method) and provides
3707 the equivalent of 112 bits of security. [DES], [3DES]
3709 Digital Signature Standard (DSS)
3710 A standard for digital signing, including the Digital Signing
3711 Algorithm, approved by the National Institute of Standards and
3712 Technology, defined in NIST FIPS PUB 186, "Digital Signature
3713 Standard", published May, 1994 by the U.S. Dept. of Commerce.
3714 [DSS]
3716 digital signatures
3717 Digital signatures utilize public key cryptography and one-way
3718 hash functions to produce a signature of the data that can be
3719 authenticated, and is difficult to forge or repudiate.
3721 handshake
3722 An initial negotiation between client and server that establishes
3723 the parameters of their transactions.
3725 Initialization Vector (IV)
3726 When a block cipher is used in CBC mode, the initialization
3730 Dierks & Rescorla Standards Track [Page 69]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3733 vector is exclusive-ORed with the first plaintext block prior to
3734 encryption.
3736 IDEA
3737 A 64-bit block cipher designed by Xuejia Lai and James Massey.
3738 [IDEA]
3740 Message Authentication Code (MAC)
3741 A Message Authentication Code is a one-way hash computed from a
3742 message and some secret data. It is difficult to forge without
3743 knowing the secret data. Its purpose is to detect if the message
3744 has been altered.
3746 master secret
3747 Secure secret data used for generating encryption keys, MAC
3748 secrets, and IVs.
3750 MD5
3751 MD5 is a secure hashing function that converts an arbitrarily
3752 long data stream into a digest of fixed size (16 bytes). [MD5]
3754 public key cryptography
3755 A class of cryptographic techniques employing two-key ciphers.
3756 Messages encrypted with the public key can only be decrypted with
3757 the associated private key. Conversely, messages signed with the
3758 private key can be verified with the public key.
3760 one-way hash function
3761 A one-way transformation that converts an arbitrary amount of
3762 data into a fixed-length hash. It is computationally hard to
3763 reverse the transformation or to find collisions. MD5 and SHA are
3764 examples of one-way hash functions.
3766 RC2
3767 A block cipher developed by Ron Rivest, described in [RC2].
3769 RC4
3770 A stream cipher invented by Ron Rivest. A compatible cipher is
3771 described in [SCH].
3773 RSA
3774 A very widely used public-key algorithm that can be used for
3775 either encryption or digital signing. [RSA]
3777 server
3778 The server is the application entity that responds to requests
3779 for connections from clients. See also under client.
3784 Dierks & Rescorla Standards Track [Page 70]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3787 session
3788 A TLS session is an association between a client and a server.
3789 Sessions are created by the handshake protocol. Sessions define a
3790 set of cryptographic security parameters that can be shared among
3791 multiple connections. Sessions are used to avoid the expensive
3792 negotiation of new security parameters for each connection.
3794 session identifier
3795 A session identifier is a value generated by a server that
3796 identifies a particular session.
3798 server write key
3799 The key used to encrypt data written by the server.
3801 server write MAC secret
3802 The secret data used to authenticate data written by the server.
3804 SHA
3805 The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
3806 produces a 20-byte output. Note that all references to SHA
3807 actually use the modified SHA-1 algorithm. [SHA]
3809 SSL
3810 Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
3811 SSL Version 3.0
3813 stream cipher
3814 An encryption algorithm that converts a key into a
3815 cryptographically strong keystream, which is then exclusive-ORed
3816 with the plaintext.
3818 symmetric cipher
3819 See bulk cipher.
3821 Transport Layer Security (TLS)
3822 This protocol; also, the Transport Layer Security working group
3823 of the Internet Engineering Task Force (IETF). See "Comments" at
3824 the end of this document.
3838 Dierks & Rescorla Standards Track [Page 71]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3841 Appendix C. CipherSuite Definitions
3843 CipherSuite Key Cipher Hash
3844 Exchange
3846 TLS_NULL_WITH_NULL_NULL NULL NULL NULL
3847 TLS_RSA_WITH_NULL_MD5 RSA NULL MD5
3848 TLS_RSA_WITH_NULL_SHA RSA NULL SHA
3849 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
3850 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
3851 TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA
3852 TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA
3853 TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
3854 TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA
3855 TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA
3856 TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA
3857 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
3858 TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA
3859 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
3860 TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA
3861 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
3862 TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA
3863 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
3864 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
3865 TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA
3866 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
3867 TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA
3868 TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA
3869 TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA
3870 TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA
3871 TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA
3872 TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA
3873 TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA
3874 TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA
3875 TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA
3876 TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA
3878 Key
3879 Exchange
3880 Algorithm Description Key size limit
3882 DHE_DSS Ephemeral DH with DSS signatures None
3883 DHE_RSA Ephemeral DH with RSA signatures None
3884 DH_anon Anonymous DH, no signatures None
3885 DH_DSS DH with DSS-based certificates None
3886 DH_RSA DH with RSA-based certificates None
3887 NULL No key exchange N/A
3888 RSA RSA key exchange None
3892 Dierks & Rescorla Standards Track [Page 72]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3895 Key Expanded IV Block
3896 Cipher Type Material Key Material Size Size
3898 NULL Stream 0 0 0 N/A
3899 IDEA_CBC Block 16 16 8 8
3900 RC4_128 Stream 16 16 0 N/A
3901 DES_CBC Block 8 8 8 8
3902 3DES_EDE_CBC Block 24 24 8 8
3904 Type
3905 Indicates whether this is a stream cipher or a block cipher
3906 running in CBC mode.
3908 Key Material
3909 The number of bytes from the key_block that are used for
3910 generating the write keys.
3912 Expanded Key Material
3913 The number of bytes actually fed into the encryption algorithm.
3915 IV Size
3916 The amount of data needed to be generated for the initialization
3917 vector. Zero for stream ciphers; equal to the block size for
3918 block ciphers (this is equal to SecurityParameters.record_iv_length).
3920 Block Size
3921 The amount of data a block cipher enciphers in one chunk; a
3922 block cipher running in CBC mode can only encrypt an even
3923 multiple of its block size.
3925 Hash Hash Padding
3926 function Size Size
3927 NULL 0 0
3928 MD5 16 48
3929 SHA 20 40
3946 Dierks & Rescorla Standards Track [Page 73]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
3949 Appendix D. Implementation Notes
3951 The TLS protocol cannot prevent many common security mistakes. This
3952 section provides several recommendations to assist implementors.
3954 D.1 Random Number Generation and Seeding
3956 TLS requires a cryptographically secure pseudorandom number generator
3957 (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs
3958 based on secure hash operations, most notably SHA-1, are acceptable,
3959 but cannot provide more security than the size of the random number
3960 generator state.
3962 To estimate the amount of seed material being produced, add the
3963 number of bits of unpredictable information in each seed byte. For
3964 example, keystroke timing values taken from a PC compatible's 18.2 Hz
3965 timer provide 1 or 2 secure bits each, even though the total size of
3966 the counter value is 16 bits or more. Seeding a 128-bit PRNG would
3967 thus require approximately 100 such timer values.
3969 [RANDOM] provides guidance on the generation of random values.
3971 D.2 Certificates and Authentication
3973 Implementations are responsible for verifying the integrity of
3974 certificates and should generally support certificate revocation
3975 messages. Certificates should always be verified to ensure proper
3976 signing by a trusted Certificate Authority (CA). The selection and
3977 addition of trusted CAs should be done very carefully. Users should
3978 be able to view information about the certificate and root CA.
3980 D.3 CipherSuites
3982 TLS supports a range of key sizes and security levels, including some
3983 that provide no or minimal security. A proper implementation will
3984 probably not support many cipher suites. For instance, anonymous
3985 Diffie-Hellman is strongly discouraged because it cannot prevent man-
3986 in-the-middle attacks. Applications should also enforce minimum and
3987 maximum key sizes. For example, certificate chains containing 512-bit
3988 RSA keys or signatures are not appropriate for high-security
3989 applications.
3991 D.4 Implementation Pitfalls
3993 Implementation experience has shown that certain parts of earlier TLS
3994 specifications are not easy to understand, and have been a source of
3995 interoperability and security problems. Many of these areas have been
3996 clarified in this document, but this appendix contains a short list
4000 Dierks & Rescorla Standards Track [Page 74]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4003 of the most important things that require special attention from
4004 implementors.
4006 TLS protocol issues:
4008 o Do you correctly handle handshake messages that are fragmented
4009 to multiple TLS records (see Section 6.2.1)? Including corner
4010 cases like a ClientHello that is split to several small
4011 fragments?
4013 o Do you ignore the TLS record layer version number in all TLS
4014 records before ServerHello (see Appendix E.1)?
4016 o Do you handle TLS extensions in ClientHello correctly,
4017 including omitting the extensions field completely?
4019 o Do you support renegotiation, both client and server initiated?
4020 While renegotiation this is an optional feature, supporting
4021 it is highly recommended.
4023 o When the server has requested a client certificate, but no
4024 suitable certificate is available, do you correctly send
4025 an empty Certificate message, instead of omitting the whole
4026 message (see Section 7.4.6)?
4028 Cryptographic details:
4030 o In RSA-encrypted Premaster Secret, do you correctly send and
4031 verify the version number? When an error is encountered, do
4032 you continue the handshake to avoid the Bleichenbacher
4033 attack (see Section 7.4.7.1)?
4035 o What countermeasures do you use to prevent timing attacks against
4036 RSA decryption and signing operations (see Section 7.4.7.1)?
4038 o When verifying RSA signatures, do you accept both NULL and
4039 missing parameters (see Section 4.7)? Do you verify that the
4040 RSA padding doesn't have additional data after the hash value?
4041 [FI06]
4043 o When using Diffie-Hellman key exchange, do you correctly strip
4044 leading zero bytes from the negotiated key (see Section 8.1.2)?
4046 o Does your TLS client check that the Diffie-Hellman parameters
4047 sent by the server are acceptable (see Section F.1.1.3)?
4049 o How do you generate unpredictable IVs for CBC mode ciphers
4050 (see Section 6.2.3.2)?
4054 Dierks & Rescorla Standards Track [Page 75]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4057 o How do you address CBC mode timing attacks (Section 6.2.3.2)?
4059 o Do you use a strong and, most importantly, properly seeded
4060 random number generator (see Appendix D.1) for generating the
4061 premaster secret (for RSA key exchange), Diffie-Hellman private
4062 values, the DSA "k" parameter, and other security-critical
4063 values?
4108 Dierks & Rescorla Standards Track [Page 76]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4111 Appendix E. Backward Compatibility
4113 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
4115 Since there are various versions of TLS (1.0, 1.1, 1.2, and any
4116 future versions) and SSL (2.0 and 3.0), means are needed to negotiate
4117 the specific protocol version to use. The TLS protocol provides a
4118 built-in mechanism for version negotiation so as not to bother other
4119 protocol components with the complexities of version selection.
4121 TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
4122 compatible ClientHello messages; thus, supporting all of them is
4123 relatively easy. Similarly, servers can easily handle clients trying
4124 to use future versions of TLS as long as the ClientHello format
4125 remains compatible, and the client support the highest protocol
4126 version available in the server.
4128 A TLS 1.2 client who wishes to negotiate with such older servers will
4129 send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
4130 ClientHello.client_version. If the server does not support this
4131 version, it will respond with ServerHello containing an older version
4132 number. If the client agrees to use this version, the negotiation
4133 will proceed as appropriate for the negotiated protocol.
4135 If the version chosen by the server is not supported by the client
4136 (or not acceptable), the client MUST send a "protocol_version" alert
4137 message and close the connection.
4139 If a TLS server receives a ClientHello containing a version number
4140 greater than the highest version supported by the server, it MUST
4141 reply according to the highest version supported by the server.
4143 A TLS server can also receive a ClientHello containing version number
4144 smaller than the highest supported version. If the server wishes to
4145 negotiate with old clients, it will proceed as appropriate for the
4146 highest version supported by the server that is not greater than
4147 ClientHello.client_version. For example, if the server supports TLS
4148 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
4149 proceed with a TLS 1.0 ServerHello. If server supports (or is willing
4150 to use) only versions greater than client_version, it MUST send a
4151 "protocol_version" alert message and close the connection.
4153 Whenever a client already knows the highest protocol known to a
4154 server (for example, when resuming a session), it SHOULD initiate the
4155 connection in that native protocol.
4157 Note: some server implementations are known to implement version
4158 negotiation incorrectly. For example, there are buggy TLS 1.0 servers
4162 Dierks & Rescorla Standards Track [Page 77]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4165 that simply close the connection when the client offers a version
4166 newer than TLS 1.0. Also, it is known that some servers will refuse
4167 connection if any TLS extensions are included in ClientHello.
4168 Interoperability with such buggy servers is a complex topic beyond
4169 the scope of this document, and may require multiple connection
4170 attempts by the client.
4172 Earlier versions of the TLS specification were not fully clear on
4173 what the record layer version number (TLSPlaintext.version) should
4174 contain when sending ClientHello (i.e., before it is known which
4175 version of the protocol will be employed). Thus, TLS servers
4176 compliant with this specification MUST accept any value {03,XX} as
4177 the record layer version number for ClientHello.
4179 TLS clients that wish to negotiate with older servers MAY send any
4180 value {03,XX} as the record layer version number. Typical values
4181 would be {03,00}, the lowest version number supported by the client,
4182 and the value of ClientHello.client_version. No single value will
4183 guarantee interoperability with all old servers, but this is a
4184 complex topic beyond the scope of this document.
4186 E.2 Compatibility with SSL 2.0
4188 TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
4189 version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST
4190 contain the same version number as would be used for ordinary
4191 ClientHello, and MUST encode the supported TLS ciphersuites in the
4192 CIPHER-SPECS-DATA field as described below.
4194 Warning: The ability to send version 2.0 CLIENT-HELLO messages will be
4195 phased out with all due haste, since the newer ClientHello format
4196 provides better mechanisms for moving to newer versions and
4197 negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0.
4199 However, even TLS servers that do not support SSL 2.0 SHOULD accept
4200 version 2.0 CLIENT-HELLO messages. The message is presented below in
4201 sufficient detail for TLS server implementors; the true definition is
4202 still assumed to be [SSL2].
4204 For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
4205 way as a ClientHello with a "null" compression method and no
4206 extensions. Note that this message MUST be sent directly on the wire,
4207 not wrapped as a TLS record. For the purposes of calculating Finished
4208 and CertificateVerify, the msg_length field is not considered to be a
4209 part of the handshake message.
4211 uint8 V2CipherSpec[3];
4216 Dierks & Rescorla Standards Track [Page 78]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4219 struct {
4220 uint16 msg_length;
4221 uint8 msg_type;
4222 Version version;
4223 uint16 cipher_spec_length;
4224 uint16 session_id_length;
4225 uint16 challenge_length;
4226 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
4227 opaque session_id[V2ClientHello.session_id_length];
4228 opaque challenge[V2ClientHello.challenge_length;
4229 } V2ClientHello;
4231 msg_length
4232 The highest bit MUST be 1; the remaining bits contain the
4233 length of the following data in bytes.
4235 msg_type
4236 This field, in conjunction with the version field, identifies a
4237 version 2 client hello message. The value MUST be one (1).
4239 version
4240 Equal to ClientHello.client_version.
4242 cipher_spec_length
4243 This field is the total length of the field cipher_specs. It
4244 cannot be zero and MUST be a multiple of the V2CipherSpec length
4245 (3).
4247 session_id_length
4248 This field MUST have a value of zero for a client that claims to
4249 support TLS 1.2.
4251 challenge_length
4252 The length in bytes of the client's challenge to the server to
4253 authenticate itself. Historically, permissible values are between
4254 16 and 32 bytes inclusive. When using the SSLv2 backward
4255 compatible handshake the client SHOULD use a 32 byte challenge.
4257 cipher_specs
4258 This is a list of all CipherSpecs the client is willing and able
4259 to use. In addition to the 2.0 cipher specs defined in [SSL2],
4260 this includes the TLS cipher suites normally sent in
4261 ClientHello.cipher_suites, each cipher suite prefixed by a zero
4262 byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as
4263 {0x00,0x00,0x0A}.
4265 session_id
4266 This field MUST be empty.
4270 Dierks & Rescorla Standards Track [Page 79]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4273 challenge
4274 Corresponds to ClientHello.random. If the challenge length is
4275 less than 32, the TLS server will pad the data with leading
4276 (note: not trailing) zero bytes to make it 32 bytes long.
4278 Note: Requests to resume a TLS session MUST use a TLS client hello.
4280 E.3. Avoiding Man-in-the-Middle Version Rollback
4282 When TLS clients fall back to Version 2.0 compatibility mode, they
4283 MUST use special PKCS#1 block formatting. This is done so that TLS
4284 servers will reject Version 2.0 sessions with TLS-capable clients.
4286 When a client negotiates SSL 2.0 but also supports TLS, it MUST set
4287 the right-hand (least-significant) 8 random bytes of the PKCS padding
4288 (not including the terminal null of the padding) for the RSA
4289 encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
4290 to 0x03 (the other padding bytes are random).
4292 When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
4293 decrypting the ENCRYPTED-KEY-DATA field, check that these eight
4294 padding bytes are 0x03. If they are not, the server SHOULD generate a
4295 random value for SECRET-KEY-DATA, and continue the handshake (which
4296 will eventually fail since the keys will not match). Note that
4297 reporting the error situation to the client could make the server
4298 vulnerable to attacks described in [BLEI].
4324 Dierks & Rescorla Standards Track [Page 80]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4327 Appendix F. Security Analysis
4329 The TLS protocol is designed to establish a secure connection between
4330 a client and a server communicating over an insecure channel. This
4331 document makes several traditional assumptions, including that
4332 attackers have substantial computational resources and cannot obtain
4333 secret information from sources outside the protocol. Attackers are
4334 assumed to have the ability to capture, modify, delete, replay, and
4335 otherwise tamper with messages sent over the communication channel.
4336 This appendix outlines how TLS has been designed to resist a variety
4337 of attacks.
4339 F.1. Handshake Protocol
4341 The handshake protocol is responsible for selecting a CipherSpec and
4342 generating a Master Secret, which together comprise the primary
4343 cryptographic parameters associated with a secure session. The
4344 handshake protocol can also optionally authenticate parties who have
4345 certificates signed by a trusted certificate authority.
4347 F.1.1. Authentication and Key Exchange
4349 TLS supports three authentication modes: authentication of both
4350 parties, server authentication with an unauthenticated client, and
4351 total anonymity. Whenever the server is authenticated, the channel is
4352 secure against man-in-the-middle attacks, but completely anonymous
4353 sessions are inherently vulnerable to such attacks. Anonymous
4354 servers cannot authenticate clients. If the server is authenticated,
4355 its certificate message must provide a valid certificate chain
4356 leading to an acceptable certificate authority. Similarly,
4357 authenticated clients must supply an acceptable certificate to the
4358 server. Each party is responsible for verifying that the other's
4359 certificate is valid and has not expired or been revoked.
4361 The general goal of the key exchange process is to create a
4362 pre_master_secret known to the communicating parties and not to
4363 attackers. The pre_master_secret will be used to generate the
4364 master_secret (see Section 8.1). The master_secret is required to
4365 generate the finished messages, encryption keys, and MAC secrets (see
4366 Sections 7.4.9 and 6.3). By sending a correct finished message,
4367 parties thus prove that they know the correct pre_master_secret.
4369 F.1.1.1. Anonymous Key Exchange
4371 Completely anonymous sessions can be established using RSA or Diffie-
4372 Hellman for key exchange. With anonymous RSA, the client encrypts a
4373 pre_master_secret with the server's uncertified public key extracted
4374 from the server key exchange message. The result is sent in a client
4378 Dierks & Rescorla Standards Track [Page 81]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4381 key exchange message. Since eavesdroppers do not know the server's
4382 private key, it will be infeasible for them to decode the
4383 pre_master_secret.
4385 With Diffie-Hellman, the server's public parameters are contained in
4386 the server key exchange message and the client's are sent in the
4387 client key exchange message. Eavesdroppers who do not know the
4388 private values should not be able to find the Diffie-Hellman result
4389 (i.e. the pre_master_secret).
4391 Warning: Completely anonymous connections only provide protection
4392 against passive eavesdropping. Unless an independent tamper-
4393 proof channel is used to verify that the finished messages
4394 were not replaced by an attacker, server authentication is
4395 required in environments where active man-in-the-middle
4396 attacks are a concern.
4398 F.1.1.2. RSA Key Exchange and Authentication
4400 With RSA, key exchange and server authentication are combined. The
4401 public key is contained in the server's certificate. Note that
4402 compromise of the server's static RSA key results in a loss of
4403 confidentiality for all sessions protected under that static key. TLS
4404 users desiring Perfect Forward Secrecy should use DHE cipher suites.
4405 The damage done by exposure of a private key can be limited by
4406 changing one's private key (and certificate) frequently.
4408 After verifying the server's certificate, the client encrypts a
4409 pre_master_secret with the server's public key. By successfully
4410 decoding the pre_master_secret and producing a correct finished
4411 message, the server demonstrates that it knows the private key
4412 corresponding to the server certificate.
4414 When RSA is used for key exchange, clients are authenticated using
4415 the certificate verify message (see Section 7.4.9). The client signs
4416 a value derived from the master_secret and all preceding handshake
4417 messages. These handshake messages include the server certificate,
4418 which binds the signature to the server, and ServerHello.random,
4419 which binds the signature to the current handshake process.
4421 F.1.1.3. Diffie-Hellman Key Exchange with Authentication
4423 When Diffie-Hellman key exchange is used, the server can either
4424 supply a certificate containing fixed Diffie-Hellman parameters or
4425 use the server key exchange message to send a set of temporary
4426 Diffie-Hellman parameters signed with a DSS or RSA certificate.
4427 Temporary parameters are hashed with the hello.random values before
4428 signing to ensure that attackers do not replay old parameters. In
4432 Dierks & Rescorla Standards Track [Page 82]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4435 either case, the client can verify the certificate or signature to
4436 ensure that the parameters belong to the server.
4438 If the client has a certificate containing fixed Diffie-Hellman
4439 parameters, its certificate contains the information required to
4440 complete the key exchange. Note that in this case the client and
4441 server will generate the same Diffie-Hellman result (i.e.,
4442 pre_master_secret) every time they communicate. To prevent the
4443 pre_master_secret from staying in memory any longer than necessary,
4444 it should be converted into the master_secret as soon as possible.
4445 Client Diffie-Hellman parameters must be compatible with those
4446 supplied by the server for the key exchange to work.
4448 If the client has a standard DSS or RSA certificate or is
4449 unauthenticated, it sends a set of temporary parameters to the server
4450 in the client key exchange message, then optionally uses a
4451 certificate verify message to authenticate itself.
4453 If the same DH keypair is to be used for multiple handshakes, either
4454 because the client or server has a certificate containing a fixed DH
4455 keypair or because the server is reusing DH keys, care must be taken
4456 to prevent small subgroup attacks. Implementations SHOULD follow the
4457 guidelines found in [SUBGROUP].
4459 Small subgroup attacks are most easily avoided by using one of the
4460 DHE ciphersuites and generating a fresh DH private key (X) for each
4461 handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
4462 computed very quickly, therefore the performance cost is minimized.
4463 Additionally, using a fresh key for each handshake provides Perfect
4464 Forward Secrecy. Implementations SHOULD generate a new X for each
4465 handshake when using DHE ciphersuites.
4467 Because TLS allows the server to provide arbitrary DH groups, the
4468 client SHOULD verify the correctness of the DH group. [TODO: provide
4469 a reference to some document describing how] and that it is of
4470 suitable size as defined by local policy. The client SHOULD also
4471 verify that the DH public exponent appears to be of adequate size.
4472 The server MAY choose to assist the client by providing a known
4473 group, such as those defined in [IKEALG] or [MODP]. These can be
4474 verified by simple comparison.
4476 F.1.2. Version Rollback Attacks
4478 Because TLS includes substantial improvements over SSL Version 2.0,
4479 attackers may try to make TLS-capable clients and servers fall back
4480 to Version 2.0. This attack can occur if (and only if) two TLS-
4481 capable parties use an SSL 2.0 handshake.
4486 Dierks & Rescorla Standards Track [Page 83]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4489 Although the solution using non-random PKCS #1 block type 2 message
4490 padding is inelegant, it provides a reasonably secure way for Version
4491 3.0 servers to detect the attack. This solution is not secure against
4492 attackers who can brute force the key and substitute a new ENCRYPTED-
4493 KEY-DATA message containing the same key (but with normal padding)
4494 before the application specified wait threshold has expired. Altering
4495 the padding of the least significant 8 bytes of the PKCS padding does
4496 not impact security for the size of the signed hashes and RSA key
4497 lengths used in the protocol, since this is essentially equivalent to
4498 increasing the input block size by 8 bytes.
4500 F.1.3. Detecting Attacks Against the Handshake Protocol
4502 An attacker might try to influence the handshake exchange to make the
4503 parties select different encryption algorithms than they would
4504 normally chooses.
4506 For this attack, an attacker must actively change one or more
4507 handshake messages. If this occurs, the client and server will
4508 compute different values for the handshake message hashes. As a
4509 result, the parties will not accept each others' finished messages.
4510 Without the master_secret, the attacker cannot repair the finished
4511 messages, so the attack will be discovered.
4513 F.1.4. Resuming Sessions
4515 When a connection is established by resuming a session, new
4516 ClientHello.random and ServerHello.random values are hashed with the
4517 session's master_secret. Provided that the master_secret has not been
4518 compromised and that the secure hash operations used to produce the
4519 encryption keys and MAC secrets are secure, the connection should be
4520 secure and effectively independent from previous connections.
4521 Attackers cannot use known encryption keys or MAC secrets to
4522 compromise the master_secret without breaking the secure hash
4523 operations.
4525 Sessions cannot be resumed unless both the client and server agree.
4526 If either party suspects that the session may have been compromised,
4527 or that certificates may have expired or been revoked, it should
4528 force a full handshake. An upper limit of 24 hours is suggested for
4529 session ID lifetimes, since an attacker who obtains a master_secret
4530 may be able to impersonate the compromised party until the
4531 corresponding session ID is retired. Applications that may be run in
4532 relatively insecure environments should not write session IDs to
4533 stable storage.
4540 Dierks & Rescorla Standards Track [Page 84]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4543 F.2. Protecting Application Data
4545 The master_secret is hashed with the ClientHello.random and
4546 ServerHello.random to produce unique data encryption keys and MAC
4547 secrets for each connection.
4549 Outgoing data is protected with a MAC before transmission. To prevent
4550 message replay or modification attacks, the MAC is computed from the
4551 MAC secret, the sequence number, the message length, the message
4552 contents, and two fixed character strings. The message type field is
4553 necessary to ensure that messages intended for one TLS Record Layer
4554 client are not redirected to another. The sequence number ensures
4555 that attempts to delete or reorder messages will be detected. Since
4556 sequence numbers are 64 bits long, they should never overflow.
4557 Messages from one party cannot be inserted into the other's output,
4558 since they use independent MAC secrets. Similarly, the server-write
4559 and client-write keys are independent, so stream cipher keys are used
4560 only once.
4562 If an attacker does break an encryption key, all messages encrypted
4563 with it can be read. Similarly, compromise of a MAC key can make
4564 message modification attacks possible. Because MACs are also
4565 encrypted, message-alteration attacks generally require breaking the
4566 encryption algorithm as well as the MAC.
4568 Note: MAC secrets may be larger than encryption keys, so messages can
4569 remain tamper resistant even if encryption keys are broken.
4571 F.3. Explicit IVs
4573 [CBCATT] describes a chosen plaintext attack on TLS that depends
4574 on knowing the IV for a record. Previous versions of TLS [TLS1.0]
4575 used the CBC residue of the previous record as the IV and
4576 therefore enabled this attack. This version uses an explicit IV
4577 in order to protect against this attack.
4579 F.4. Security of Composite Cipher Modes
4581 TLS secures transmitted application data via the use of symmetric
4582 encryption and authentication functions defined in the negotiated
4583 ciphersuite. The objective is to protect both the integrity and
4584 confidentiality of the transmitted data from malicious actions by
4585 active attackers in the network. It turns out that the order in
4586 which encryption and authentication functions are applied to the
4587 data plays an important role for achieving this goal [ENCAUTH].
4589 The most robust method, called encrypt-then-authenticate, first
4590 applies encryption to the data and then applies a MAC to the
4594 Dierks & Rescorla Standards Track [Page 85]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4597 ciphertext. This method ensures that the integrity and
4598 confidentiality goals are obtained with ANY pair of encryption
4599 and MAC functions, provided that the former is secure against
4600 chosen plaintext attacks and that the MAC is secure against
4601 chosen-message attacks. TLS uses another method, called
4602 authenticate-then-encrypt, in which first a MAC is computed on
4603 the plaintext and then the concatenation of plaintext and MAC is
4604 encrypted. This method has been proven secure for CERTAIN
4605 combinations of encryption functions and MAC functions, but it is
4606 not guaranteed to be secure in general. In particular, it has
4607 been shown that there exist perfectly secure encryption functions
4608 (secure even in the information-theoretic sense) that combined
4609 with any secure MAC function, fail to provide the confidentiality
4610 goal against an active attack. Therefore, new ciphersuites and
4611 operation modes adopted into TLS need to be analyzed under the
4612 authenticate-then-encrypt method to verify that they achieve the
4613 stated integrity and confidentiality goals.
4615 Currently, the security of the authenticate-then-encrypt method
4616 has been proven for some important cases. One is the case of
4617 stream ciphers in which a computationally unpredictable pad of
4618 the length of the message, plus the length of the MAC tag, is
4619 produced using a pseudo-random generator and this pad is xor-ed
4620 with the concatenation of plaintext and MAC tag. The other is
4621 the case of CBC mode using a secure block cipher. In this case,
4622 security can be shown if one applies one CBC encryption pass to
4623 the concatenation of plaintext and MAC and uses a new,
4624 independent, and unpredictable IV for each new pair of plaintext
4625 and MAC. In previous versions of SSL, CBC mode was used properly
4626 EXCEPT that it used a predictable IV in the form of the last
4627 block of the previous ciphertext. This made TLS open to chosen
4628 plaintext attacks. This version of the protocol is immune to
4629 those attacks. For exact details in the encryption modes proven
4630 secure, see [ENCAUTH].
4632 F.5 Denial of Service
4634 TLS is susceptible to a number of denial of service (DoS) attacks.
4635 In particular, an attacker who initiates a large number of TCP
4636 connections can cause a server to consume large amounts of CPU doing
4637 RSA decryption. However, because TLS is generally used over TCP, it
4638 is difficult for the attacker to hide his point of origin if proper
4639 TCP SYN randomization is used [SEQNUM] by the TCP stack.
4641 Because TLS runs over TCP, it is also susceptible to a number of
4642 denial of service attacks on individual connections. In particular,
4643 attackers can forge RSTs, thereby terminating connections, or forge
4644 partial TLS records, thereby causing the connection to stall. These
4648 Dierks & Rescorla Standards Track [Page 86]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4651 attacks cannot in general be defended against by a TCP-using
4652 protocol. Implementors or users who are concerned with this class of
4653 attack should use IPsec AH [AH] or ESP [ESP].
4702 Dierks & Rescorla Standards Track [Page 87]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4705 Security Considerations
4707 Security issues are discussed throughout this memo, especially in
4708 Appendices D, E, and F.
4711 Changes in This Version
4713 [RFC Editor: Please delete this]
4715 - Added compression methods to the IANA considerations.
4717 - Misc. editorial changes/clarifications
4719 - Added an Implementation Pitfalls sections
4720 [Issue 26]
4722 - Harmonized the requirement to send an empty certificate list
4723 after certificate_request even when no certs are available.
4724 [Issue 48]
4726 - Made the verify_data length depend on the cipher suite
4727 [Issue 49]
4729 - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
4730 cipher suite [Issue 56]
4733 Normative References
4734 [AES] National Institute of Standards and Technology,
4735 "Specification for the Advanced Encryption Standard (AES)"
4736 FIPS 197. November 26, 2001.
4738 [3DES] National Institute of Standards and Technology,
4739 "Recommendation for the Triple Data Encryption Algorithm
4740 (TDEA) Block Cipher", NIST Special Publication 800-67, May
4741 2004.
4743 [DES] National Institute of Standards and Technology, "Data
4744 Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
4746 [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National
4747 Institute of Standards and Technology, U.S. Department of
4748 Commerce, 2000. PKI
4749 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
4750 Hashing for Message Authentication", RFC 2104, February
4751 1997.
4756 Dierks & Rescorla Standards Track [Page 88]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4759 [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
4760 Series in Information Processing, v. 1, Konstanz: Hartung-
4761 Gorre Verlag, 1992.
4763 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
4764 April 1992.
4766 [PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
4767 (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
4768 3447, February 2003.
4770 [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
4771 Public Key Infrastructure Certificate and Certificate
4772 Revocation List (CRL) Profile", RFC 3280, April 2002.
4774 [RC2] Rivest, R., "A Description of the RC2(r) Encryption
4775 Algorithm", RFC 2268, March 1998.
4777 [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
4778 and Source Code in C, 2nd ed.", Published by John Wiley &
4779 Sons, Inc. 1996.
4781 [SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National
4782 Institute of Standards and Technology, U.S. Department of
4783 Commerce., August 2001.
4785 [REQ] Bradner, S., "Key words for use in RFCs to Indicate
4786 Requirement Levels", BCP 14, RFC 2119, March 1997.
4788 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
4789 IANA Considerations Section in RFCs", BCP 25, RFC 2434,
4790 October 1998.
4792 Informative References
4794 [AEAD] Mcgrew, D., "Authenticated Encryption", February 2007,
4795 draft-mcgrew-auth-enc-02.txt.
4797 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC
4798 4302, December 2005.
4800 [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
4801 Protocols Based on RSA Encryption Standard PKCS #1" in
4802 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
4803 1-12, 1998.
4805 [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
4806 Problems and Countermeasures",
4810 Dierks & Rescorla Standards Track [Page 89]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4813 http://www.openssl.org/~bodo/tls-cbc.txt.
4815 [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
4816 "Password Interception in a SSL/TLS Channel", Advances in
4817 Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
4819 [CCM] "NIST Special Publication 800-38C: The CCM Mode for
4820 Authentication and Confidentiality",
4821 http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf
4823 [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
4824 for Protecting Communications (Or: How Secure is SSL?)",
4825 Crypto 2001.
4827 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
4828 Payload (ESP)", RFC 4303, December 2005.
4830 [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on
4831 implementation error", ietf-openpgp@imc.org mailing list, 27
4832 August 2006, http://www.imc.org/ietf-openpgp/mail-
4833 archive/msg14307.html.
4835 [GCM] "NIST Special Publication 800-38D DRAFT (June, 2007):
4836 Recommendation for Block Cipher Modes of Operation:
4837 Galois/Counter Mode (GCM) and GMAC"
4839 [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
4840 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December
4841 2005.
4843 [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
4844 Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
4845 March 2003.
4847 [MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
4848 Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
4849 3526, May 2003.
4851 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
4852 Standard," version 1.5, November 1993.
4854 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
4855 Standard," version 1.5, November 1993.
4857 [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
4858 "Randomness Requirements for Security", BCP 106, RFC 4086,
4859 June 2005.
4864 Dierks & Rescorla Standards Track [Page 90]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4867 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
4868 Compression Methods", RFC 3749, May 2004.
4870 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
4871 Wright, T., "Transport Layer Security (TLS) Extensions", RFC
4872 4366, April 2006.
4874 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
4875 Obtaining Digital Signatures and Public-Key Cryptosystems,"
4876 Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
4877 120-126.
4879 [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
4880 RFC 1948, May 1996.
4882 [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
4883 Corp., Feb 9, 1995.
4885 [SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
4886 Protocol", Netscape Communications Corp., Nov 18, 1996.
4888 [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
4889 Attacks on the Diffie-Hellman Key Agreement Method for
4890 S/MIME", RFC 2785, March 2000.
4892 [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
4893 September 1981.
4895 [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
4896 practical", USENIX Security Symposium 2003.
4898 [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
4899 for Transport Layer Security (TLS)", RFC 3268, June 2002.
4901 [TLSEXT], Eastlake, D.E., "Transport Layer Security (TLS)
4902 Extensions: Extension Definitions", July 2007, draft-ietf-
4903 tls-rfc4366-bis-00.txt.
4905 [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
4906 RFC 2246, January 1999.
4908 [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version
4909 1.1", RFC 4346, April, 2006.
4911 [X501] ITU-T Recommendation X.501: Information Technology - Open
4912 Systems Interconnection - The Directory: Models, 1993.
4914 [XDR] Srinivansan, R., Sun Microsystems, "XDR: External Data
4918 Dierks & Rescorla Standards Track [Page 91]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4921 Representation Standard", RFC 1832, August 1995.
4924 Credits
4926 Working Group Chairs
4927 Eric Rescorla
4928 EMail: ekr@networkresonance.com
4930 Pasi Eronen
4931 pasi.eronen@nokia.com
4934 Editors
4936 Tim Dierks Eric Rescorla
4937 Independent Network Resonance, Inc.
4939 EMail: tim@dierks.org EMail: ekr@networkresonance.com
4943 Other contributors
4945 Christopher Allen (co-editor of TLS 1.0)
4946 Alacrity Ventures
4947 ChristopherA@AlacrityManagement.com
4949 Martin Abadi
4950 University of California, Santa Cruz
4951 abadi@cs.ucsc.edu
4953 Steven M. Bellovin
4954 Columbia University
4955 smb@cs.columbia.edu
4957 Simon Blake-Wilson
4958 BCI
4959 EMail: sblakewilson@bcisse.com
4961 Ran Canetti
4962 IBM
4963 canetti@watson.ibm.com
4965 Pete Chown
4966 Skygate Technology Ltd
4967 pc@skygate.co.uk
4972 Dierks & Rescorla Standards Track [Page 92]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
4975 Taher Elgamal
4976 taher@securify.com
4977 Securify
4979 Anil Gangolli
4980 anil@busybuddha.org
4982 Kipp Hickman
4984 Alfred Hoenes
4986 David Hopwood
4987 Independent Consultant
4988 EMail: david.hopwood@blueyonder.co.uk
4990 Phil Karlton (co-author of SSLv3)
4992 Paul Kocher (co-author of SSLv3)
4993 Cryptography Research
4994 paul@cryptography.com
4996 Hugo Krawczyk
4997 Technion Israel Institute of Technology
4998 hugo@ee.technion.ac.il
5000 Jan Mikkelsen
5001 Transactionware
5002 EMail: janm@transactionware.com
5004 Magnus Nystrom
5005 RSA Security
5006 EMail: magnus@rsasecurity.com
5008 Robert Relyea
5009 Netscape Communications
5010 relyea@netscape.com
5012 Jim Roskind
5013 Netscape Communications
5014 jar@netscape.com
5016 Michael Sabin
5018 Dan Simon
5019 Microsoft, Inc.
5020 dansimon@microsoft.com
5022 Tom Weinstein
5026 Dierks & Rescorla Standards Track [Page 93]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
5029 Tim Wright
5030 Vodafone
5031 EMail: timothy.wright@vodafone.com
5033 Comments
5035 The discussion list for the IETF TLS working group is located at the
5036 e-mail address <tls@ietf.org>. Information on the group and
5037 information on how to subscribe to the list is at
5038 <https://www1.ietf.org/mailman/listinfo/tls>
5040 Archives of the list can be found at:
5041 <http://www.ietf.org/mail-archive/web/tls/current/index.html>
5080 Dierks & Rescorla Standards Track [Page 94]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
5083 Full Copyright Statement
5085 Copyright (C) The IETF Trust (2007).
5087 This document is subject to the rights, licenses and restrictions
5088 contained in BCP 78, and except as set forth therein, the authors
5089 retain all their rights.
5091 This document and the information contained herein are provided on an
5092 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
5093 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
5094 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
5095 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
5096 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
5097 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5100 Intellectual Property
5102 The IETF takes no position regarding the validity or scope of any
5103 Intellectual Property Rights or other rights that might be claimed to
5104 pertain to the implementation or use of the technology described in
5105 this document or the extent to which any license under such rights
5106 might or might not be available; nor does it represent that it has
5107 made any independent effort to identify any such rights. Information
5108 on the procedures with respect to rights in RFC documents can be
5109 found in BCP 78 and BCP 79.
5111 Copies of IPR disclosures made to the IETF Secretariat and any
5112 assurances of licenses to be made available, or the result of an
5113 attempt made to obtain a general license or permission for the use of
5114 such proprietary rights by implementers or users of this
5115 specification can be obtained from the IETF on-line IPR repository at
5116 http://www.ietf.org/ipr.
5118 The IETF invites any interested party to bring to its attention any
5119 copyrights, patents or patent applications, or other proprietary
5120 rights that may cover technology that may be required to implement
5121 this standard. Please address the information to the IETF at
5122 ietf-ipr@ietf.org.
5125 Acknowledgment
5127 Funding for the RFC Editor function is provided by the IETF
5128 Administrative Support Activity (IASA).
5134 Dierks & Rescorla Standards Track [Page 95]\fdraft-ietf-tls-rfc4346-bis-05.txt TLS June 2007
5188 Dierks & Rescorla Standards Track [Page 96]\f