| blob | ff8164bc5e1d44ed3cf286c911b0734fbf85e651 |
3 INTERNET-DRAFT Tim Dierks
4 Obsoletes (if approved): RFC 3268, 4346, 4366 Independent
5 Intended status: Proposed Standard Eric Rescorla
6 Network Resonance, Inc.
7 <draft-ietf-tls-rfc4346-bis-07.txt> November 2007 (Expires May 2008)
10 The Transport Layer Security (TLS) Protocol
11 Version 1.2
13 Status of this Memo
15 By submitting this Internet-Draft, each author represents that any
16 applicable patent or other IPR claims of which he or she is aware
17 have been or will be disclosed, and any of which he or she becomes
18 aware will be disclosed, in accordance with Section 6 of BCP 79.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
23 Drafts.
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 Copyright Notice
38 Copyright (C) The IETF Trust (2007).
40 Abstract
42 This document specifies Version 1.2 of the Transport Layer Security
43 (TLS) protocol. The TLS protocol provides communications security
44 over the Internet. The protocol allows client/server applications to
45 communicate in a way that is designed to prevent eavesdropping,
46 tampering, or message forgery.
54 Dierks & Rescorla Standards Track [Page 1]
55 \f
56 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
59 Table of Contents
61 1. Introduction 4
62 1.1. Requirements Terminology 5
63 1.2. Major Differences from TLS 1.1 5
64 2. Goals 6
65 3. Goals of This Document 6
66 4. Presentation Language 7
67 4.1. Basic Block Size 7
68 4.2. Miscellaneous 7
69 4.3. Vectors 8
70 4.4. Numbers 9
71 4.5. Enumerateds 9
72 4.6. Constructed Types 10
73 4.6.1. Variants 10
74 4.7. Cryptographic Attributes 11
75 4.8. Constants 13
76 5. HMAC and the Pseudorandom Function 13
77 6. The TLS Record Protocol 14
78 6.1. Connection States 15
79 6.2. Record layer 18
80 6.2.1. Fragmentation 18
81 6.2.2. Record Compression and Decompression 19
82 6.2.3. Record Payload Protection 20
83 6.2.3.1. Null or Standard Stream Cipher 21
84 6.2.3.2. CBC Block Cipher 21
85 6.2.3.3. AEAD ciphers 23
86 6.3. Key Calculation 24
87 7. The TLS Handshaking Protocols 25
88 7.1. Change Cipher Spec Protocol 26
89 7.2. Alert Protocol 27
90 7.2.1. Closure Alerts 28
91 7.2.2. Error Alerts 29
92 7.3. Handshake Protocol Overview 32
93 7.4. Handshake Protocol 35
94 7.4.1. Hello Messages 36
95 7.4.1.1. Hello Request 36
96 7.4.1.2. Client Hello 37
97 7.4.1.3. Server Hello 40
98 7.4.1.4 Hello Extensions 42
99 7.4.1.4.1 Signature Algorithms 43
100 7.4.2. Server Certificate 44
101 7.4.3. Server Key Exchange Message 47
102 7.4.4. Certificate Request 49
103 7.4.5 Server hello done 51
104 7.4.6. Client Certificate 52
105 7.4.7. Client Key Exchange Message 53
106 7.4.7.1. RSA Encrypted Premaster Secret Message 54
110 Dierks & Rescorla Standards Track [Page 2]
111 \f
112 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
115 7.4.7.2. Client Diffie-Hellman Public Value 56
116 7.4.8. Certificate verify 57
117 7.4.9. Finished 58
118 8. Cryptographic Computations 59
119 8.1. Computing the Master Secret 60
120 8.1.1. RSA 60
121 8.1.2. Diffie-Hellman 60
122 9. Mandatory Cipher Suites 60
123 10. Application Data Protocol 60
124 11. Security Considerations 60
125 12. IANA Considerations 61
126 A. Protocol Constant Values 63
127 A.1. Record Layer 63
128 A.2. Change Cipher Specs Message 64
129 A.3. Alert Messages 64
130 A.4. Handshake Protocol 65
131 A.4.1. Hello Messages 65
132 A.4.2. Server Authentication and Key Exchange Messages 67
133 A.4.3. Client Authentication and Key Exchange Messages 68
134 A.4.4. Handshake Finalization Message 69
135 A.5. The CipherSuite 69
136 A.6. The Security Parameters 72
137 B. Glossary 73
138 C. CipherSuite Definitions 77
139 D. Implementation Notes 79
140 D.1 Random Number Generation and Seeding 79
141 D.2 Certificates and Authentication 79
142 D.3 CipherSuites 79
143 D.4 Implementation Pitfalls 79
144 E. Backward Compatibility 82
145 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 82
146 E.2 Compatibility with SSL 2.0 83
147 E.3. Avoiding Man-in-the-Middle Version Rollback 85
148 F. Security Analysis 86
149 F.1. Handshake Protocol 86
150 F.1.1. Authentication and Key Exchange 86
151 F.1.1.1. Anonymous Key Exchange 86
152 F.1.1.2. RSA Key Exchange and Authentication 87
153 F.1.1.3. Diffie-Hellman Key Exchange with Authentication 87
154 F.1.2. Version Rollback Attacks 88
155 F.1.3. Detecting Attacks Against the Handshake Protocol 89
156 F.1.4. Resuming Sessions 89
157 F.2. Protecting Application Data 89
158 F.3. Explicit IVs 90
159 F.4. Security of Composite Cipher Modes 90
160 F.5 Denial of Service 91
161 F.6 Final Notes 91
166 Dierks & Rescorla Standards Track [Page 3]
167 \f
168 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
171 1. Introduction
173 The primary goal of the TLS Protocol is to provide privacy and data
174 integrity between two communicating applications. The protocol is
175 composed of two layers: the TLS Record Protocol and the TLS Handshake
176 Protocol. At the lowest level, layered on top of some reliable
177 transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
178 TLS Record Protocol provides connection security that has two basic
179 properties:
181 - The connection is private. Symmetric cryptography is used for
182 data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for
183 this symmetric encryption are generated uniquely for each
184 connection and are based on a secret negotiated by another
185 protocol (such as the TLS Handshake Protocol). The Record Protocol
186 can also be used without encryption.
188 - The connection is reliable. Message transport includes a message
189 integrity check using a keyed MAC. Secure hash functions (e.g.,
190 SHA, MD5, etc.) are used for MAC computations. The Record Protocol
191 can operate without a MAC, but is generally only used in this mode
192 while another protocol is using the Record Protocol as a transport
193 for negotiating security parameters.
195 The TLS Record Protocol is used for encapsulation of various higher-
196 level protocols. One such encapsulated protocol, the TLS Handshake
197 Protocol, allows the server and client to authenticate each other and
198 to negotiate an encryption algorithm and cryptographic keys before
199 the application protocol transmits or receives its first byte of
200 data. The TLS Handshake Protocol provides connection security that
201 has three basic properties:
203 - The peer's identity can be authenticated using asymmetric, or
204 public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
205 authentication can be made optional, but is generally required for
206 at least one of the peers.
208 - The negotiation of a shared secret is secure: the negotiated
209 secret is unavailable to eavesdroppers, and for any authenticated
210 connection the secret cannot be obtained, even by an attacker who
211 can place himself in the middle of the connection.
213 - The negotiation is reliable: no attacker can modify the
214 negotiation communication without being detected by the parties to
215 the communication.
217 One advantage of TLS is that it is application protocol independent.
218 Higher-level protocols can layer on top of the TLS Protocol
222 Dierks & Rescorla Standards Track [Page 4]
223 \f
224 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
227 transparently. The TLS standard, however, does not specify how
228 protocols add security with TLS; the decisions on how to initiate TLS
229 handshaking and how to interpret the authentication certificates
230 exchanged are left to the judgment of the designers and implementors
231 of protocols that run on top of TLS.
233 1.1. Requirements Terminology
235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
237 document are to be interpreted as described in RFC 2119 [REQ].
239 1.2. Major Differences from TLS 1.1
241 This document is a revision of the TLS 1.1 [TLS1.1] protocol which
242 contains improved flexibility, particularly for negotiation of
243 cryptographic algorithms. The major changes are:
245 - The MD5/SHA-1 combination in the PRF has been replaced with cipher
246 suite specified PRFs. All cipher suites in this document use
247 P_SHA256.
249 - The MD5/SHA-1 combination in the digitally-signed element has been
250 replaced with a single hash.
252 - Substantial cleanup to the clients and servers ability to specify
253 which hash and signature algorithms they will accept. Note that
254 this also relaxes some of the constraints on signature and hash
255 algorithms from previous versions of TLS.
257 - Addition of support for authenticated encryption with additional
258 data modes.
260 - TLS Extensions definition and AES Cipher Suites were merged in
261 from external [TLSEXT] and [TLSAES].
263 - Tighter checking of EncryptedPreMasterSecret version numbers.
265 - Tightened up a number of requirements.
267 - Verify_data length now depends on the cipher suite (default is
268 still 12).
270 - Cleaned up description of Bleichenbacher/Klima attack defenses.
272 - Alerts MUST now be sent in many cases.
273 - After a certificate_request, if no certificates are available,
274 clients now MUST send an empty certificate list.
278 Dierks & Rescorla Standards Track [Page 5]
279 \f
280 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
283 - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
284 cipher suite.
286 - IDEE and DES are now deprecated.
288 - Support for the SSLv2 backward-compatible hello is now a MAY, not
289 a SHOULD. This will probably become a SHOULD NOT in the future.
291 - Added an Implementation Pitfalls sections
293 - The usual clarifications and editorial work.
294 2. Goals
296 The goals of TLS Protocol, in order of their priority, are as
297 follows:
299 1. Cryptographic security: TLS should be used to establish a secure
300 connection between two parties.
302 2. Interoperability: Independent programmers should be able to
303 develop applications utilizing TLS that can successfully exchange
304 cryptographic parameters without knowledge of one another's code.
306 3. Extensibility: TLS seeks to provide a framework into which new
307 public key and bulk encryption methods can be incorporated as
308 necessary. This will also accomplish two sub-goals: preventing the
309 need to create a new protocol (and risking the introduction of
310 possible new weaknesses) and avoiding the need to implement an
311 entire new security library.
313 4. Relative efficiency: Cryptographic operations tend to be highly
314 CPU intensive, particularly public key operations. For this
315 reason, the TLS protocol has incorporated an optional session
316 caching scheme to reduce the number of connections that need to be
317 established from scratch. Additionally, care has been taken to
318 reduce network activity.
321 3. Goals of This Document
323 This document and the TLS protocol itself are based on the SSL 3.0
324 Protocol Specification as published by Netscape. The differences
325 between this protocol and SSL 3.0 are not dramatic, but they are
326 significant enough that the various versions of TLS and SSL 3.0 do
327 not interoperate (although each protocol incorporates a mechanism by
328 which an implementation can back down to prior versions). This
329 document is intended primarily for readers who will be implementing
330 the protocol and for those doing cryptographic analysis of it. The
334 Dierks & Rescorla Standards Track [Page 6]
335 \f
336 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
339 specification has been written with this in mind, and it is intended
340 to reflect the needs of those two groups. For that reason, many of
341 the algorithm-dependent data structures and rules are included in the
342 body of the text (as opposed to in an appendix), providing easier
343 access to them.
345 This document is not intended to supply any details of service
346 definition or of interface definition, although it does cover select
347 areas of policy as they are required for the maintenance of solid
348 security.
351 4. Presentation Language
353 This document deals with the formatting of data in an external
354 representation. The following very basic and somewhat casually
355 defined presentation syntax will be used. The syntax draws from
356 several sources in its structure. Although it resembles the
357 programming language "C" in its syntax and XDR [XDR] in both its
358 syntax and intent, it would be risky to draw too many parallels. The
359 purpose of this presentation language is to document TLS only; it has
360 no general application beyond that particular goal.
362 4.1. Basic Block Size
364 The representation of all data items is explicitly specified. The
365 basic data block size is one byte (i.e., 8 bits). Multiple byte data
366 items are concatenations of bytes, from left to right, from top to
367 bottom. From the bytestream, a multi-byte item (a numeric in the
368 example) is formed (using C notation) by:
370 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
371 ... | byte[n-1];
373 This byte ordering for multi-byte values is the commonplace network
374 byte order or big endian format.
376 4.2. Miscellaneous
378 Comments begin with "/*" and end with "*/".
380 Optional components are denoted by enclosing them in "[[ ]]" double
381 brackets.
383 Single-byte entities containing uninterpreted data are of type
384 opaque.
390 Dierks & Rescorla Standards Track [Page 7]
391 \f
392 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
395 4.3. Vectors
397 A vector (single dimensioned array) is a stream of homogeneous data
398 elements. The size of the vector may be specified at documentation
399 time or left unspecified until runtime. In either case, the length
400 declares the number of bytes, not the number of elements, in the
401 vector. The syntax for specifying a new type, T', that is a fixed-
402 length vector of type T is
404 T T'[n];
406 Here, T' occupies n bytes in the data stream, where n is a multiple
407 of the size of T. The length of the vector is not included in the
408 encoded stream.
410 In the following example, Datum is defined to be three consecutive
411 bytes that the protocol does not interpret, while Data is three
412 consecutive Datum, consuming a total of nine bytes.
414 opaque Datum[3]; /* three uninterpreted bytes */
415 Datum Data[9]; /* 3 consecutive 3 byte vectors */
417 Variable-length vectors are defined by specifying a subrange of legal
418 lengths, inclusively, using the notation <floor..ceiling>. When
419 these are encoded, the actual length precedes the vector's contents
420 in the byte stream. The length will be in the form of a number
421 consuming as many bytes as required to hold the vector's specified
422 maximum (ceiling) length. A variable-length vector with an actual
423 length field of zero is referred to as an empty vector.
425 T T'<floor..ceiling>;
427 In the following example, mandatory is a vector that must contain
428 between 300 and 400 bytes of type opaque. It can never be empty. The
429 actual length field consumes two bytes, a uint16, sufficient to
430 represent the value 400 (see Section 4.4). On the other hand, longer
431 can represent up to 800 bytes of data, or 400 uint16 elements, and it
432 may be empty. Its encoding will include a two-byte actual length
433 field prepended to the vector. The length of an encoded vector must
434 be an even multiple of the length of a single element (for example, a
435 17-byte vector of uint16 would be illegal).
437 opaque mandatory<300..400>;
438 /* length field is 2 bytes, cannot be empty */
439 uint16 longer<0..800>;
440 /* zero to 400 16-bit unsigned integers */
446 Dierks & Rescorla Standards Track [Page 8]
447 \f
448 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
451 4.4. Numbers
453 The basic numeric data type is an unsigned byte (uint8). All larger
454 numeric data types are formed from fixed-length series of bytes
455 concatenated as described in Section 4.1 and are also unsigned. The
456 following numeric types are predefined.
458 uint8 uint16[2];
459 uint8 uint24[3];
460 uint8 uint32[4];
461 uint8 uint64[8];
463 All values, here and elsewhere in the specification, are stored in
464 "network" or "big-endian" order; the uint32 represented by the hex
465 bytes 01 02 03 04 is equivalent to the decimal value 16909060.
467 Note that in some cases (e.g., DH parameters) it is necessary to
468 represent integers as opaque vectors. In such cases, they are
469 represented as unsigned integers (i.e., leading zero octets are not
470 required even if the most significant bit is set).
472 4.5. Enumerateds
474 An additional sparse data type is available called enum. A field of
475 type enum can only assume the values declared in the definition.
476 Each definition is a different type. Only enumerateds of the same
477 type may be assigned or compared. Every element of an enumerated must
478 be assigned a value, as demonstrated in the following example. Since
479 the elements of the enumerated are not ordered, they can be assigned
480 any unique value, in any order.
482 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
484 Enumerateds occupy as much space in the byte stream as would its
485 maximal defined ordinal value. The following definition would cause
486 one byte to be used to carry fields of type Color.
488 enum { red(3), blue(5), white(7) } Color;
490 One may optionally specify a value without its associated tag to
491 force the width definition without defining a superfluous element.
492 In the following example, Taste will consume two bytes in the data
493 stream but can only assume the values 1, 2, or 4.
495 enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
497 The names of the elements of an enumeration are scoped within the
498 defined type. In the first example, a fully qualified reference to
502 Dierks & Rescorla Standards Track [Page 9]
503 \f
504 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
507 the second element of the enumeration would be Color.blue. Such
508 qualification is not required if the target of the assignment is well
509 specified.
511 Color color = Color.blue; /* overspecified, legal */
512 Color color = blue; /* correct, type implicit */
514 For enumerateds that are never converted to external representation,
515 the numerical information may be omitted.
517 enum { low, medium, high } Amount;
519 4.6. Constructed Types
521 Structure types may be constructed from primitive types for
522 convenience. Each specification declares a new, unique type. The
523 syntax for definition is much like that of C.
525 struct {
526 T1 f1;
527 T2 f2;
528 ...
529 Tn fn;
530 } [[T]];
532 The fields within a structure may be qualified using the type's name,
533 with a syntax much like that available for enumerateds. For example,
534 T.f2 refers to the second field of the previous declaration.
535 Structure definitions may be embedded.
537 4.6.1. Variants
539 Defined structures may have variants based on some knowledge that is
540 available within the environment. The selector must be an enumerated
541 type that defines the possible variants the structure defines. There
542 must be a case arm for every element of the enumeration declared in
543 the select. The body of the variant structure may be given a label
544 for reference. The mechanism by which the variant is selected at
545 runtime is not prescribed by the presentation language.
547 struct {
548 T1 f1;
549 T2 f2;
550 ....
551 Tn fn;
552 select (E) {
553 case e1: Te1;
554 case e2: Te2;
558 Dierks & Rescorla Standards Track [Page 10]
559 \f
560 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
563 ....
564 case en: Ten;
565 } [[fv]];
566 } [[Tv]];
568 For example:
570 enum { apple, orange } VariantTag;
571 struct {
572 uint16 number;
573 opaque string<0..10>; /* variable length */
574 } V1;
575 struct {
576 uint32 number;
577 opaque string[10]; /* fixed length */
578 } V2;
579 struct {
580 select (VariantTag) { /* value of selector is implicit */
581 case apple: V1; /* VariantBody, tag = apple */
582 case orange: V2; /* VariantBody, tag = orange */
583 } variant_body; /* optional label on variant */
584 } VariantRecord;
586 Variant structures may be qualified (narrowed) by specifying a value
587 for the selector prior to the type. For example, an
589 orange VariantRecord
591 is a narrowed type of a VariantRecord containing a variant_body of
592 type V2.
594 4.7. Cryptographic Attributes
596 The five cryptographic operations digital signing, stream cipher
597 encryption, block cipher encryption, authenticated encryption with
598 additional data (AEAD) encryption and public key encryption are
599 designated digitally-signed, stream-ciphered, block-ciphered, aead-
600 ciphered, and public-key-encrypted, respectively. A field's
601 cryptographic processing is specified by prepending an appropriate
602 key word designation before the field's type specification.
603 Cryptographic keys are implied by the current session state (see
604 Section 6.1).
606 In digital signing, one-way hash functions are used as input for a
607 signing algorithm. A digitally-signed element is encoded as an opaque
608 vector <0..2^16-1>, where the length is specified by the signing
609 algorithm and key.
614 Dierks & Rescorla Standards Track [Page 11]
615 \f
616 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
619 In RSA signing, the opaque vector contains the signature generated
620 using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As
621 discussed in [PKCS1], the DigestInfo MUST be DER encoded and for hash
622 algorithms without parameters (which include SHA-1) the
623 DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but
624 implementations MUST accept both without parameters and with NULL
625 parameters. Note that earlier versions of TLS used a different RSA
626 signature scheme which did not include a DigestInfo encoding.
628 In DSS, the 20 bytes of the SHA-1 hash are run directly through the
629 Digital Signing Algorithm with no additional hashing. This produces
630 two values, r and s. The DSS signature is an opaque vector, as above,
631 the contents of which are the DER encoding of:
633 Dss-Sig-Value ::= SEQUENCE {
634 r INTEGER,
635 s INTEGER
636 }
638 Note: In current terminology, DSA refers to the Digital Signature
639 Algorithm and DSS refers to the NIST standard. For historical
640 reasons, this document uses DSS and DSA interchangeably
641 to refer to the DSA algorithm, as was done in SSLv3.
643 In stream cipher encryption, the plaintext is exclusive-ORed with an
644 identical amount of output generated from a cryptographically secure
645 keyed pseudorandom number generator.
647 In block cipher encryption, every block of plaintext encrypts to a
648 block of ciphertext. All block cipher encryption is done in CBC
649 (Cipher Block Chaining) mode, and all items that are block-ciphered
650 will be an exact multiple of the cipher block length.
652 In AEAD encryption, the plaintext is simultaneously encrypted and
653 integrity protected. The input may be of any length and aead-ciphered
654 output is generally larger than the input in order to accomodate the
655 integrity check value.
657 In public key encryption, a public key algorithm is used to encrypt
658 data in such a way that it can be decrypted only with the matching
659 private key. A public-key-encrypted element is encoded as an opaque
660 vector <0..2^16-1>, where the length is specified by the encryption
661 algorithm and key.
663 RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
664 defined in [PKCS1].
670 Dierks & Rescorla Standards Track [Page 12]
671 \f
672 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
675 In the following example
677 stream-ciphered struct {
678 uint8 field1;
679 uint8 field2;
680 digitally-signed opaque hash[20];
681 } UserType;
683 the contents of hash are used as input for the signing algorithm, and
684 then the entire structure is encrypted with a stream cipher. The
685 length of this structure, in bytes, would be equal to two bytes for
686 field1 and field2, plus two bytes for the length of the signature,
687 plus the length of the output of the signing algorithm. This is known
688 because the algorithm and key used for the signing are known prior to
689 encoding or decoding this structure.
691 4.8. Constants
693 Typed constants can be defined for purposes of specification by
694 declaring a symbol of the desired type and assigning values to it.
695 Under-specified types (opaque, variable length vectors, and
696 structures that contain opaque) cannot be assigned values. No fields
697 of a multi-element structure or vector may be elided.
699 For example:
701 struct {
702 uint8 f1;
703 uint8 f2;
704 } Example1;
706 Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
709 5. HMAC and the Pseudorandom Function
711 The TLS record layer uses a keyed Message Authentication Code (MAC)
712 to protect message integrity. The cipher suites defined in this
713 document use a construction known as HMAC, described in [HMAC], which
714 is based on a hash function. Other cipher suites MAY define their own
715 MAC constructions, if needed.
717 In addition, a construction is required to do expansion of secrets
718 into blocks of data for the purposes of key generation or validation.
719 This pseudo-random function (PRF) takes as input a secret, a seed,
720 and an identifying label and produces an output of arbitrary length.
722 In this section, we define one PRF, based on HMAC. This PRF with the
726 Dierks & Rescorla Standards Track [Page 13]
727 \f
728 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
731 SHA-256 hash function is used for all cipher suites defined in this
732 document and in TLS documents published prior to this document when
733 TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a
734 PRF and in general SHOULD use the TLS PRF with SHA-256 or a stronger
735 standard hash function.
737 First, we define a data expansion function, P_hash(secret, data) that
738 uses a single hash function to expand a secret and seed into an
739 arbitrary quantity of output:
741 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
742 HMAC_hash(secret, A(2) + seed) +
743 HMAC_hash(secret, A(3) + seed) + ...
745 Where + indicates concatenation.
747 A() is defined as:
749 A(0) = seed
750 A(i) = HMAC_hash(secret, A(i-1))
752 P_hash can be iterated as many times as is necessary to produce the
753 required quantity of data. For example, if P_SHA-1 is being used to
754 create 64 bytes of data, it will have to be iterated 4 times (through
755 A(4)), creating 80 bytes of output data; the last 16 bytes of the
756 final iteration will then be discarded, leaving 64 bytes of output
757 data.
759 TLS's PRF is created by applying P_hash to the secret as:
761 PRF(secret, label, seed) = P_<hash>(secret, label + seed)
763 The label is an ASCII string. It should be included in the exact form
764 it is given without a length byte or trailing null character. For
765 example, the label "slithy toves" would be processed by hashing the
766 following bytes:
768 73 6C 69 74 68 79 20 74 6F 76 65 73
771 6. The TLS Record Protocol
773 The TLS Record Protocol is a layered protocol. At each layer,
774 messages may include fields for length, description, and content.
775 The Record Protocol takes messages to be transmitted, fragments the
776 data into manageable blocks, optionally compresses the data, applies
777 a MAC, encrypts, and transmits the result. Received data is
778 decrypted, verified, decompressed, reassembled, and then delivered to
782 Dierks & Rescorla Standards Track [Page 14]
783 \f
784 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
787 higher-level clients.
789 Four record protocol clients are described in this document: the
790 handshake protocol, the alert protocol, the change cipher spec
791 protocol, and the application data protocol. In order to allow
792 extension of the TLS protocol, additional record types can be
793 supported by the record protocol. New record type values are assigned
794 by IANA as described in Section 12.
796 Implementations MUST NOT send record types not defined in this
797 document unless negotiated by some extension. If a TLS
798 implementation receives an unexpected record type, it MUST send an
799 unexpected_message alert.
801 Any protocol designed for use over TLS MUST be carefully designed to
802 deal with all possible attacks against it. Note that because the
803 type and length of a record are not protected by encryption, care
804 SHOULD be taken to minimize the value of traffic analysis of these
805 values.
807 6.1. Connection States
809 A TLS connection state is the operating environment of the TLS Record
810 Protocol. It specifies a compression algorithm, an encryption
811 algorithm, and a MAC algorithm. In addition, the parameters for these
812 algorithms are known: the MAC key and the bulk encryption keys for
813 the connection in both the read and the write directions. Logically,
814 there are always four connection states outstanding: the current read
815 and write states, and the pending read and write states. All records
816 are processed under the current read and write states. The security
817 parameters for the pending states can be set by the TLS Handshake
818 Protocol, and the Change Cipher Spec can selectively make either of
819 the pending states current, in which case the appropriate current
820 state is disposed of and replaced with the pending state; the pending
821 state is then reinitialized to an empty state. It is illegal to make
822 a state that has not been initialized with security parameters a
823 current state. The initial current state always specifies that no
824 encryption, compression, or MAC will be used.
826 The security parameters for a TLS Connection read and write state are
827 set by providing the following values:
829 connection end
830 Whether this entity is considered the "client" or the "server" in
831 this connection.
838 Dierks & Rescorla Standards Track [Page 15]
839 \f
840 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
843 PRF algorithm
844 An algorithm used to generate keys from the master secret (see
845 Sections 5 and 6.3).
847 bulk encryption algorithm
848 An algorithm to be used for bulk encryption. This specification
849 includes the key size of this algorithm, whether it is a block,
850 stream, or AEAD cipher, the block size of the cipher (if
851 appropriate), and the lengths of explicit and implicit
852 initialization vectors (or nonces).
854 MAC algorithm
855 An algorithm to be used for message authentication. This
856 specification includes the size of the value returned by the MAC
857 algorithm.
859 compression algorithm
860 An algorithm to be used for data compression. This specification
861 must include all information the algorithm requires to do
862 compression.
864 master secret
865 A 48-byte secret shared between the two peers in the connection.
867 client random
868 A 32-byte value provided by the client.
870 server random
871 A 32-byte value provided by the server.
873 These parameters are defined in the presentation language as:
875 enum { server, client } ConnectionEnd;
877 enum { tls_prf_sha256 } PRFAlgorithm;
879 enum { null, rc4, 3des, aes }
880 BulkCipherAlgorithm;
882 enum { stream, block, aead } CipherType;
884 enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384,
885 hmac_sha512} MACAlgorithm;
887 /* The use of "sha" above is historical and denotes SHA-1 */
889 enum { null(0), (255) } CompressionMethod;
894 Dierks & Rescorla Standards Track [Page 16]
895 \f
896 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
899 /* The algorithms specified in CompressionMethod,
900 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
902 struct {
903 ConnectionEnd entity;
904 PRFAlgorithm prf_algorithm;
905 BulkCipherAlgorithm bulk_cipher_algorithm;
906 CipherType cipher_type;
907 uint8 enc_key_length;
908 uint8 block_length;
909 uint8 fixed_iv_length;
910 uint8 record_iv_length;
911 MACAlgorithm mac_algorithm;
912 uint8 mac_length;
913 uint8 mac_key_length;
914 CompressionMethod compression_algorithm;
915 opaque master_secret[48];
916 opaque client_random[32];
917 opaque server_random[32];
918 } SecurityParameters;
920 The record layer will use the security parameters to generate the
921 following six items (some of which are not required by all ciphers,
922 and are thus empty):
924 client write MAC key
925 server write MAC key
926 client write encryption key
927 server write encryption key
928 client write IV
929 server write IV
931 The client write parameters are used by the server when receiving and
932 processing records and vice-versa. The algorithm used for generating
933 these items from the security parameters is described in Section 6.3.
935 Once the security parameters have been set and the keys have been
936 generated, the connection states can be instantiated by making them
937 the current states. These current states MUST be updated for each
938 record processed. Each connection state includes the following
939 elements:
941 compression state
942 The current state of the compression algorithm.
944 cipher state
945 The current state of the encryption algorithm. This will consist
946 of the scheduled key for that connection. For stream ciphers, this
950 Dierks & Rescorla Standards Track [Page 17]
951 \f
952 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
955 will also contain whatever state information is necessary to allow
956 the stream to continue to encrypt or decrypt data.
958 MAC key
959 The MAC key for this connection, as generated above.
961 sequence number
962 Each connection state contains a sequence number, which is
963 maintained separately for read and write states. The sequence
964 number MUST be set to zero whenever a connection state is made the
965 active state. Sequence numbers are of type uint64 and may not
966 exceed 2^64-1. Sequence numbers do not wrap. If a TLS
967 implementation would need to wrap a sequence number, it must
968 renegotiate instead. A sequence number is incremented after each
969 record: specifically, the first record transmitted under a
970 particular connection state MUST use sequence number 0.
972 6.2. Record layer
974 The TLS Record Layer receives uninterpreted data from higher layers
975 in non-empty blocks of arbitrary size.
977 6.2.1. Fragmentation
979 The record layer fragments information blocks into TLSPlaintext
980 records carrying data in chunks of 2^14 bytes or less. Client message
981 boundaries are not preserved in the record layer (i.e., multiple
982 client messages of the same ContentType MAY be coalesced into a
983 single TLSPlaintext record, or a single message MAY be fragmented
984 across several records).
986 struct {
987 uint8 major, minor;
988 } ProtocolVersion;
990 enum {
991 change_cipher_spec(20), alert(21), handshake(22),
992 application_data(23), (255)
993 } ContentType;
995 struct {
996 ContentType type;
997 ProtocolVersion version;
998 uint16 length;
999 opaque fragment[TLSPlaintext.length];
1000 } TLSPlaintext;
1002 type
1006 Dierks & Rescorla Standards Track [Page 18]
1007 \f
1008 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1011 The higher-level protocol used to process the enclosed fragment.
1013 version
1014 The version of the protocol being employed. This document
1015 describes TLS Version 1.2, which uses the version { 3, 3 }. The
1016 version value 3.3 is historical, deriving from the use of 3.1 for
1017 TLS 1.0. (See Appendix A.1). Note that a client that supports
1018 multiple versions of TLS may not know what version will be
1019 employed before it receives ServerHello. See Appendix E for
1020 discussion about what record layer version number should be
1021 employed for ClientHello.
1023 length
1024 The length (in bytes) of the following TLSPlaintext.fragment. The
1025 length MUST NOT exceed 2^14.
1027 fragment
1028 The application data. This data is transparent and treated as an
1029 independent block to be dealt with by the higher-level protocol
1030 specified by the type field.
1032 Implementations MUST NOT send zero-length fragments of Handshake,
1033 Alert, or Change Cipher Spec content types. Zero-length fragments of
1034 Application data MAY be sent as they are potentially useful as a
1035 traffic analysis countermeasure.
1037 Note: Data of different TLS Record layer content types MAY be
1038 interleaved. Application data is generally of lower precedence for
1039 transmission than other content types. However, records MUST be
1040 delivered to the network in the same order as they are protected by
1041 the record layer. Recipients MUST receive and process interleaved
1042 application layer traffic during handshakes subsequent to the first
1043 one on a connection.
1045 6.2.2. Record Compression and Decompression
1047 All records are compressed using the compression algorithm defined in
1048 the current session state. There is always an active compression
1049 algorithm; however, initially it is defined as
1050 CompressionMethod.null. The compression algorithm translates a
1051 TLSPlaintext structure into a TLSCompressed structure. Compression
1052 functions are initialized with default state information whenever a
1053 connection state is made active.
1055 Compression must be lossless and may not increase the content length
1056 by more than 1024 bytes. If the decompression function encounters a
1057 TLSCompressed.fragment that would decompress to a length in excess of
1058 2^14 bytes, it MUST report a fatal decompression failure error.
1062 Dierks & Rescorla Standards Track [Page 19]
1063 \f
1064 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1067 struct {
1068 ContentType type; /* same as TLSPlaintext.type */
1069 ProtocolVersion version;/* same as TLSPlaintext.version */
1070 uint16 length;
1071 opaque fragment[TLSCompressed.length];
1072 } TLSCompressed;
1074 length
1075 The length (in bytes) of the following TLSCompressed.fragment.
1076 The length MUST NOT exceed 2^14 + 1024.
1078 fragment
1079 The compressed form of TLSPlaintext.fragment.
1081 Note: A CompressionMethod.null operation is an identity operation; no
1082 fields are altered.
1084 Implementation note: Decompression functions are responsible for
1085 ensuring that messages cannot cause internal buffer overflows.
1087 6.2.3. Record Payload Protection
1089 The encryption and MAC functions translate a TLSCompressed structure
1090 into a TLSCiphertext. The decryption functions reverse the process.
1091 The MAC of the record also includes a sequence number so that
1092 missing, extra, or repeated messages are detectable.
1094 struct {
1095 ContentType type;
1096 ProtocolVersion version;
1097 uint16 length;
1098 select (SecurityParameters.cipher_type) {
1099 case stream: GenericStreamCipher;
1100 case block: GenericBlockCipher;
1101 case aead: GenericAEADCipher;
1102 } fragment;
1103 } TLSCiphertext;
1105 type
1106 The type field is identical to TLSCompressed.type.
1108 version
1109 The version field is identical to TLSCompressed.version.
1111 length
1112 The length (in bytes) of the following TLSCiphertext.fragment.
1113 The length MUST NOT exceed 2^14 + 2048.
1118 Dierks & Rescorla Standards Track [Page 20]
1119 \f
1120 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1123 fragment
1124 The encrypted form of TLSCompressed.fragment, with the MAC.
1126 6.2.3.1. Null or Standard Stream Cipher
1128 Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
1129 convert TLSCompressed.fragment structures to and from stream
1130 TLSCiphertext.fragment structures.
1132 stream-ciphered struct {
1133 opaque content[TLSCompressed.length];
1134 opaque MAC[SecurityParameters.mac_length];
1135 } GenericStreamCipher;
1137 The MAC is generated as:
1139 MAC(MAC_write_secret, seq_num +
1140 TLSCompressed.type +
1141 TLSCompressed.version +
1142 TLSCompressed.length +
1143 TLSCompressed.fragment);
1145 where "+" denotes concatenation.
1147 seq_num
1148 The sequence number for this record.
1150 MAC
1151 The MAC algorithm specified by SecurityParameters.mac_algorithm.
1153 Note that the MAC is computed before encryption. The stream cipher
1154 encrypts the entire block, including the MAC. For stream ciphers that
1155 do not use a synchronization vector (such as RC4), the stream cipher
1156 state from the end of one record is simply used on the subsequent
1157 packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
1158 consists of the identity operation (i.e., the data is not encrypted,
1159 and the MAC size is zero, implying that no MAC is used).
1160 TLSCiphertext.length is TLSCompressed.length plus
1161 SecurityParameters.mac_length.
1163 6.2.3.2. CBC Block Cipher
1165 For block ciphers (such as 3DES, or AES), the encryption and MAC
1166 functions convert TLSCompressed.fragment structures to and from block
1167 TLSCiphertext.fragment structures.
1174 Dierks & Rescorla Standards Track [Page 21]
1175 \f
1176 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1179 struct {
1180 opaque IV[SecurityParameters.record_iv_length];
1181 block-ciphered struct {
1182 opaque content[TLSCompressed.length];
1183 opaque MAC[SecurityParameters.mac_length];
1184 uint8 padding[GenericBlockCipher.padding_length];
1185 uint8 padding_length;
1186 };
1187 } GenericBlockCipher;
1189 The MAC is generated as described in Section 6.2.3.1.
1191 IV
1192 The Initialization Vector (IV) SHOULD be chosen at random, and
1193 MUST be unpredictable. Note that in versions of TLS prior to 1.1,
1194 there was no IV field, and the last ciphertext block of the
1195 previous record (the "CBC residue") was used as the IV. This was
1196 changed to prevent the attacks described in [CBCATT]. For block
1197 ciphers, the IV length is of length
1198 SecurityParameters.record_iv_length which is equal to the
1199 SecurityParameters.block_size.
1201 padding
1202 Padding that is added to force the length of the plaintext to be
1203 an integral multiple of the block cipher's block length. The
1204 padding MAY be any length up to 255 bytes, as long as it results
1205 in the TLSCiphertext.length being an integral multiple of the
1206 block length. Lengths longer than necessary might be desirable to
1207 frustrate attacks on a protocol that are based on analysis of the
1208 lengths of exchanged messages. Each uint8 in the padding data
1209 vector MUST be filled with the padding length value. The receiver
1210 MUST check this padding and MUST use the bad_record_mac alert to
1211 indicate padding errors.
1213 padding_length
1214 The padding length MUST be such that the total size of the
1215 GenericBlockCipher structure is a multiple of the cipher's block
1216 length. Legal values range from zero to 255, inclusive. This
1217 length specifies the length of the padding field exclusive of the
1218 padding_length field itself.
1220 The encrypted data length (TLSCiphertext.length) is one more than the
1221 sum of SecurityParameters.block_length, TLSCompressed.length,
1222 SecurityParameters.mac_length, and padding_length.
1224 Example: If the block length is 8 bytes, the content length
1225 (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,
1226 then the length before padding is 82 bytes (this does not include the
1230 Dierks & Rescorla Standards Track [Page 22]
1231 \f
1232 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1235 IV. Thus, the padding length modulo 8 must be equal to 6 in order to
1236 make the total length an even multiple of 8 bytes (the block length).
1237 The padding length can be 6, 14, 22, and so on, through 254. If the
1238 padding length were the minimum necessary, 6, the padding would be 6
1239 bytes, each containing the value 6. Thus, the last 8 octets of the
1240 GenericBlockCipher before block encryption would be xx 06 06 06 06 06
1241 06 06, where xx is the last octet of the MAC.
1243 Note: With block ciphers in CBC mode (Cipher Block Chaining), it is
1244 critical that the entire plaintext of the record be known before any
1245 ciphertext is transmitted. Otherwise, it is possible for the attacker
1246 to mount the attack described in [CBCATT].
1248 Implementation Note: Canvel et al. [CBCTIME] have demonstrated a
1249 timing attack on CBC padding based on the time required to compute
1250 the MAC. In order to defend against this attack, implementations MUST
1251 ensure that record processing time is essentially the same whether or
1252 not the padding is correct. In general, the best way to do this is
1253 to compute the MAC even if the padding is incorrect, and only then
1254 reject the packet. For instance, if the pad appears to be incorrect,
1255 the implementation might assume a zero-length pad and then compute
1256 the MAC. This leaves a small timing channel, since MAC performance
1257 depends to some extent on the size of the data fragment, but it is
1258 not believed to be large enough to be exploitable, due to the large
1259 block size of existing MACs and the small size of the timing signal.
1261 6.2.3.3. AEAD ciphers
1263 For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
1264 converts TLSCompressed.fragment structures to and from AEAD
1265 TLSCiphertext.fragment structures.
1267 struct {
1268 opaque nonce_explicit[SecurityParameters.record_iv_length];
1269 aead-ciphered struct {
1270 opaque content[TLSCompressed.length];
1271 };
1272 } GenericAEADCipher;
1274 AEAD ciphers take as input a single key, a nonce, a plaintext, and
1275 "additional data" to be included in the authentication check, as
1276 described in Section 2.1 of [AEAD]. The key is either the
1277 client_write_key or the server_write_key. No MAC key is used.
1279 Each AEAD cipher suite MUST specify how the nonce supplied to the
1280 AEAD operation is constructed, and what is the length of the
1281 GenericAEADCipher.nonce_explicit part. In many cases, it is
1282 appropriate to use the partially implicit nonce technique described
1286 Dierks & Rescorla Standards Track [Page 23]
1287 \f
1288 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1291 in Section 3.2.1 of [AEAD]; with record_iv_length being the length of
1292 the explicit part. In this case, the implicit part SHOULD be derived
1293 from key_block as client_write_iv and server_write_iv (as described
1294 in Section 6.3), and the explicit part is included in
1295 GenericAEAEDCipher.nonce_explicit.
1297 The plaintext is the TLSCompressed.fragment.
1299 The additional authenticated data, which we denote as
1300 additional_data, is defined as follows:
1302 additional_data = seq_num + TLSCompressed.type +
1303 TLSCompressed.version + TLSCompressed.length;
1305 Where "+" denotes concatenation.
1307 The aead_output consists of the ciphertext output by the AEAD
1308 encryption operation. The length will generally be larger than
1309 TLSCompressed.length, but by an amount that varies with the AEAD
1310 cipher. Since the ciphers might incorporate padding, the amount of
1311 overhead could vary with different TLSCompressed.length values. Each
1312 AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
1313 Symbolically,
1315 AEADEncrypted = AEAD-Encrypt(key, IV, plaintext,
1316 additional_data)
1318 In order to decrypt and verify, the cipher takes as input the key,
1319 IV, the "additional_data", and the AEADEncrypted value. The output is
1320 either the plaintext or an error indicating that the decryption
1321 failed. There is no separate integrity check. I.e.,
1323 TLSCompressed.fragment = AEAD-Decrypt(write_key, IV,
1324 AEADEncrypted,
1325 additional_data)
1328 If the decryption fails, a fatal bad_record_mac alert MUST be
1329 generated.
1331 6.3. Key Calculation
1333 The Record Protocol requires an algorithm to generates keys required
1334 by the current connection state (see Appendix A.6) from the security
1335 parameters provided by the handshake protocol.
1337 The master secret is expanded into a sequence of secure bytes, which
1338 is then split to a client write MAC key, a server write MAC key, a
1342 Dierks & Rescorla Standards Track [Page 24]
1343 \f
1344 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1347 client write encryption key, and a server write encryption key. Each
1348 of these is generated from the byte sequence in that order. Unused
1349 values are empty. Some AEAD ciphers may additionally require a
1350 client write IV and a server write IV (see Section 6.2.3.3).
1352 When keys and MAC keys are generated, the master secret is used as an
1353 entropy source.
1355 To generate the key material, compute
1357 key_block = PRF(SecurityParameters.master_secret,
1358 "key expansion",
1359 SecurityParameters.server_random +
1360 SecurityParameters.client_random);
1362 until enough output has been generated. Then the key_block is
1363 partitioned as follows:
1365 client_write_MAC_key[SecurityParameters.mac_key_length]
1366 server_write_MAC_key[SecurityParameters.mac_key_length]
1367 client_write_key[SecurityParameters.enc_key_length]
1368 server_write_key[SecurityParameters.enc_key_length]
1369 client_write_IV[SecurityParameters.fixed_iv_length]
1370 server_write_IV[SecurityParameters.fixed_iv_length]
1372 The client_write_IV and server_write_IV are only generated for
1373 implicit nonce techniques as described in Section 3.2.1 of [AEAD].
1375 Implementation note: The currently defined cipher suite which
1376 requires the most material is AES_256_CBC_SHA. It requires 2 x 32
1377 byte keys and 2 x 20 byte MAC keys, for a total 104 bytes of key
1378 material.
1380 7. The TLS Handshaking Protocols
1382 TLS has three subprotocols that are used to allow peers to agree upon
1383 security parameters for the record layer, to authenticate themselves,
1384 to instantiate negotiated security parameters, and to report error
1385 conditions to each other.
1387 The Handshake Protocol is responsible for negotiating a session,
1388 which consists of the following items:
1390 session identifier
1391 An arbitrary byte sequence chosen by the server to identify an
1392 active or resumable session state.
1398 Dierks & Rescorla Standards Track [Page 25]
1399 \f
1400 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1403 peer certificate
1404 X509v3 [PKIX] certificate of the peer. This element of the state
1405 may be null.
1407 compression method
1408 The algorithm used to compress data prior to encryption.
1410 cipher spec
1411 Specifies the bulk data encryption algorithm (such as null, DES,
1412 etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
1413 cryptographic attributes such as the mac_length. (See Appendix A.6
1414 for formal definition.)
1416 master secret
1417 48-byte secret shared between the client and server.
1419 is resumable
1420 A flag indicating whether the session can be used to initiate new
1421 connections.
1423 These items are then used to create security parameters for use by
1424 the Record Layer when protecting application data. Many connections
1425 can be instantiated using the same session through the resumption
1426 feature of the TLS Handshake Protocol.
1428 7.1. Change Cipher Spec Protocol
1430 The change cipher spec protocol exists to signal transitions in
1431 ciphering strategies. The protocol consists of a single message,
1432 which is encrypted and compressed under the current (not the pending)
1433 connection state. The message consists of a single byte of value 1.
1435 struct {
1436 enum { change_cipher_spec(1), (255) } type;
1437 } ChangeCipherSpec;
1439 The change cipher spec message is sent by both the client and the
1440 server to notify the receiving party that subsequent records will be
1441 protected under the newly negotiated CipherSpec and keys. Reception
1442 of this message causes the receiver to instruct the Record Layer to
1443 immediately copy the read pending state into the read current state.
1444 Immediately after sending this message, the sender MUST instruct the
1445 record layer to make the write pending state the write active state.
1446 (See Section 6.1.) The change cipher spec message is sent during the
1447 handshake after the security parameters have been agreed upon, but
1448 before the verifying finished message is sent.
1454 Dierks & Rescorla Standards Track [Page 26]
1455 \f
1456 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1459 Note: If a rehandshake occurs while data is flowing on a connection,
1460 the communicating parties may continue to send data using the old
1461 CipherSpec. However, once the ChangeCipherSpec has been sent, the new
1462 CipherSpec MUST be used. The first side to send the ChangeCipherSpec
1463 does not know that the other side has finished computing the new
1464 keying material (e.g., if it has to perform a time consuming public
1465 key operation). Thus, a small window of time, during which the
1466 recipient must buffer the data, MAY exist. In practice, with modern
1467 machines this interval is likely to be fairly short.
1469 7.2. Alert Protocol
1471 One of the content types supported by the TLS Record layer is the
1472 alert type. Alert messages convey the severity of the message and a
1473 description of the alert. Alert messages with a level of fatal result
1474 in the immediate termination of the connection. In this case, other
1475 connections corresponding to the session may continue, but the
1476 session identifier MUST be invalidated, preventing the failed session
1477 from being used to establish new connections. Like other messages,
1478 alert messages are encrypted and compressed, as specified by the
1479 current connection state.
1481 enum { warning(1), fatal(2), (255) } AlertLevel;
1483 enum {
1484 close_notify(0),
1485 unexpected_message(10),
1486 bad_record_mac(20),
1487 decryption_failed_RESERVED(21),
1488 record_overflow(22),
1489 decompression_failure(30),
1490 handshake_failure(40),
1491 no_certificate_RESERVED(41),
1492 bad_certificate(42),
1493 unsupported_certificate(43),
1494 certificate_revoked(44),
1495 certificate_expired(45),
1496 certificate_unknown(46),
1497 illegal_parameter(47),
1498 unknown_ca(48),
1499 access_denied(49),
1500 decode_error(50),
1501 decrypt_error(51),
1502 export_restriction_RESERVED(60),
1503 protocol_version(70),
1504 insufficient_security(71),
1505 internal_error(80),
1506 user_canceled(90),
1510 Dierks & Rescorla Standards Track [Page 27]
1511 \f
1512 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1515 no_renegotiation(100),
1516 unsupported_extension(110),
1517 (255)
1518 } AlertDescription;
1520 struct {
1521 AlertLevel level;
1522 AlertDescription description;
1523 } Alert;
1525 7.2.1. Closure Alerts
1527 The client and the server must share knowledge that the connection is
1528 ending in order to avoid a truncation attack. Either party may
1529 initiate the exchange of closing messages.
1531 close_notify
1532 This message notifies the recipient that the sender will not send
1533 any more messages on this connection. Note that as of TLS 1.1,
1534 failure to properly close a connection no longer requires that a
1535 session not be resumed. This is a change from TLS 1.0 to conform
1536 with widespread implementation practice.
1538 Either party may initiate a close by sending a close_notify alert.
1539 Any data received after a closure alert is ignored.
1541 Unless some other fatal alert has been transmitted, each party is
1542 required to send a close_notify alert before closing the write side
1543 of the connection. The other party MUST respond with a close_notify
1544 alert of its own and close down the connection immediately,
1545 discarding any pending writes. It is not required for the initiator
1546 of the close to wait for the responding close_notify alert before
1547 closing the read side of the connection.
1549 If the application protocol using TLS provides that any data may be
1550 carried over the underlying transport after the TLS connection is
1551 closed, the TLS implementation must receive the responding
1552 close_notify alert before indicating to the application layer that
1553 the TLS connection has ended. If the application protocol will not
1554 transfer any additional data, but will only close the underlying
1555 transport connection, then the implementation MAY choose to close the
1556 transport without waiting for the responding close_notify. No part of
1557 this standard should be taken to dictate the manner in which a usage
1558 profile for TLS manages its data transport, including when
1559 connections are opened or closed.
1561 Note: It is assumed that closing a connection reliably delivers
1562 pending data before destroying the transport.
1566 Dierks & Rescorla Standards Track [Page 28]
1567 \f
1568 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1571 7.2.2. Error Alerts
1573 Error handling in the TLS Handshake protocol is very simple. When an
1574 error is detected, the detecting party sends a message to the other
1575 party. Upon transmission or receipt of a fatal alert message, both
1576 parties immediately close the connection. Servers and clients MUST
1577 forget any session-identifiers, keys, and secrets associated with a
1578 failed connection. Thus, any connection terminated with a fatal alert
1579 MUST NOT be resumed.
1581 Whenever an implementation encounters a condition which is defined as
1582 a fatal alert, it MUST send the appropriate alert prior to closing
1583 the connection. In cases where an implementation chooses to send an
1584 alert which may be a warning alert but intends to close the
1585 connection immediately afterwards, it MUST send that alert at the
1586 fatal alert level.
1588 If an alert with a level of warning is sent and received, generally
1589 the connection can continue normally. If the receiving party decides
1590 not to proceed with the connection (e.g., after having received a
1591 no_renegotiation alert that it is not willing to accept), it SHOULD
1592 send a fatal alert to terminate the connection.
1595 The following error alerts are defined:
1597 unexpected_message
1598 An inappropriate message was received. This alert is always fatal
1599 and should never be observed in communication between proper
1600 implementations.
1602 bad_record_mac
1603 This alert is returned if a record is received with an incorrect
1604 MAC. This alert also MUST be returned if an alert is sent because
1605 a TLSCiphertext decrypted in an invalid way: either it wasn't an
1606 even multiple of the block length, or its padding values, when
1607 checked, weren't correct. This message is always fatal.
1609 decryption_failed_RESERVED
1610 This alert was used in some earlier versions of TLS, and may have
1611 permitted certain attacks against the CBC mode [CBCATT]. It MUST
1612 NOT be sent by compliant implementations.
1614 record_overflow
1615 A TLSCiphertext record was received that had a length more than
1616 2^14+2048 bytes, or a record decrypted to a TLSCompressed record
1617 with more than 2^14+1024 bytes. This message is always fatal.
1622 Dierks & Rescorla Standards Track [Page 29]
1623 \f
1624 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1627 decompression_failure
1628 The decompression function received improper input (e.g., data
1629 that would expand to excessive length). This message is always
1630 fatal.
1632 handshake_failure
1633 Reception of a handshake_failure alert message indicates that the
1634 sender was unable to negotiate an acceptable set of security
1635 parameters given the options available. This is a fatal error.
1637 no_certificate_RESERVED
1638 This alert was used in SSLv3 but not any version of TLS. It MUST
1639 NOT be sent by compliant implementations.
1641 bad_certificate
1642 A certificate was corrupt, contained signatures that did not
1643 verify correctly, etc.
1645 unsupported_certificate
1646 A certificate was of an unsupported type.
1648 certificate_revoked
1649 A certificate was revoked by its signer.
1651 certificate_expired
1652 A certificate has expired or is not currently valid.
1654 certificate_unknown
1655 Some other (unspecified) issue arose in processing the
1656 certificate, rendering it unacceptable.
1658 illegal_parameter
1659 A field in the handshake was out of range or inconsistent with
1660 other fields. This message is always fatal.
1662 unknown_ca
1663 A valid certificate chain or partial chain was received, but the
1664 certificate was not accepted because the CA certificate could not
1665 be located or couldn't be matched with a known, trusted CA. This
1666 message is always fatal.
1668 access_denied
1669 A valid certificate was received, but when access control was
1670 applied, the sender decided not to proceed with negotiation. This
1671 message is always fatal.
1673 decode_error
1674 A message could not be decoded because some field was out of the
1678 Dierks & Rescorla Standards Track [Page 30]
1679 \f
1680 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1683 specified range or the length of the message was incorrect. This
1684 message is always fatal.
1686 decrypt_error
1687 A handshake cryptographic operation failed, including being unable
1688 to correctly verify a signature, decrypt a key exchange, or
1689 validate a finished message.
1691 export_restriction_RESERVED
1692 This alert was used in some earlier versions of TLS. It MUST NOT
1693 be sent by compliant implementations.
1695 protocol_version
1696 The protocol version the client has attempted to negotiate is
1697 recognized but not supported. (For example, old protocol versions
1698 might be avoided for security reasons). This message is always
1699 fatal.
1701 insufficient_security
1702 Returned instead of handshake_failure when a negotiation has
1703 failed specifically because the server requires ciphers more
1704 secure than those supported by the client. This message is always
1705 fatal.
1707 internal_error
1708 An internal error unrelated to the peer or the correctness of the
1709 protocol (such as a memory allocation failure) makes it impossible
1710 to continue. This message is always fatal.
1712 user_canceled
1713 This handshake is being canceled for some reason unrelated to a
1714 protocol failure. If the user cancels an operation after the
1715 handshake is complete, just closing the connection by sending a
1716 close_notify is more appropriate. This alert should be followed by
1717 a close_notify. This message is generally a warning.
1719 no_renegotiation
1720 Sent by the client in response to a hello request or by the server
1721 in response to a client hello after initial handshaking. Either
1722 of these would normally lead to renegotiation; when that is not
1723 appropriate, the recipient should respond with this alert. At
1724 that point, the original requester can decide whether to proceed
1725 with the connection. One case where this would be appropriate is
1726 where a server has spawned a process to satisfy a request; the
1727 process might receive security parameters (key length,
1728 authentication, etc.) at startup and it might be difficult to
1729 communicate changes to these parameters after that point. This
1730 message is always a warning.
1734 Dierks & Rescorla Standards Track [Page 31]
1735 \f
1736 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1739 unsupported_extension
1740 sent by clients that receive an extended server hello containing
1741 an extension that they did not put in the corresponding client
1742 hello. This message is always fatal.
1744 For all errors where an alert level is not explicitly specified, the
1745 sending party MAY determine at its discretion whether this is a fatal
1746 error or not; if an alert with a level of warning is received, the
1747 receiving party MAY decide at its discretion whether to treat this as
1748 a fatal error or not. However, all messages that are transmitted
1749 with a level of fatal MUST be treated as fatal messages.
1751 New Alert values are assigned by IANA as described in Section 12.
1753 7.3. Handshake Protocol Overview
1755 The cryptographic parameters of the session state are produced by the
1756 TLS Handshake Protocol, which operates on top of the TLS Record
1757 Layer. When a TLS client and server first start communicating, they
1758 agree on a protocol version, select cryptographic algorithms,
1759 optionally authenticate each other, and use public-key encryption
1760 techniques to generate shared secrets.
1762 The TLS Handshake Protocol involves the following steps:
1764 - Exchange hello messages to agree on algorithms, exchange random
1765 values, and check for session resumption.
1767 - Exchange the necessary cryptographic parameters to allow the
1768 client and server to agree on a premaster secret.
1770 - Exchange certificates and cryptographic information to allow the
1771 client and server to authenticate themselves.
1773 - Generate a master secret from the premaster secret and exchanged
1774 random values.
1776 - Provide security parameters to the record layer.
1778 - Allow the client and server to verify that their peer has
1779 calculated the same security parameters and that the handshake
1780 occurred without tampering by an attacker.
1782 Note that higher layers should not be overly reliant on whether TLS
1783 always negotiates the strongest possible connection between two
1784 peers. There are a number of ways in which a man in the middle
1785 attacker can attempt to make two entities drop down to the least
1786 secure method they support. The protocol has been designed to
1790 Dierks & Rescorla Standards Track [Page 32]
1791 \f
1792 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1795 minimize this risk, but there are still attacks available: for
1796 example, an attacker could block access to the port a secure service
1797 runs on, or attempt to get the peers to negotiate an unauthenticated
1798 connection. The fundamental rule is that higher levels must be
1799 cognizant of what their security requirements are and never transmit
1800 information over a channel less secure than what they require. The
1801 TLS protocol is secure in that any cipher suite offers its promised
1802 level of security: if you negotiate 3DES with a 1024 bit RSA key
1803 exchange with a host whose certificate you have verified, you can
1804 expect to be that secure.
1806 These goals are achieved by the handshake protocol, which can be
1807 summarized as follows: The client sends a client hello message to
1808 which the server must respond with a server hello message, or else a
1809 fatal error will occur and the connection will fail. The client hello
1810 and server hello are used to establish security enhancement
1811 capabilities between client and server. The client hello and server
1812 hello establish the following attributes: Protocol Version, Session
1813 ID, Cipher Suite, and Compression Method. Additionally, two random
1814 values are generated and exchanged: ClientHello.random and
1815 ServerHello.random.
1817 The actual key exchange uses up to four messages: the server
1818 certificate, the server key exchange, the client certificate, and the
1819 client key exchange. New key exchange methods can be created by
1820 specifying a format for these messages and by defining the use of the
1821 messages to allow the client and server to agree upon a shared
1822 secret. This secret MUST be quite long; currently defined key
1823 exchange methods exchange secrets that range from 46 bytes upwards.
1825 Following the hello messages, the server will send its certificate,
1826 if it is to be authenticated. Additionally, a server key exchange
1827 message may be sent, if it is required (e.g., if their server has no
1828 certificate, or if its certificate is for signing only). If the
1829 server is authenticated, it may request a certificate from the
1830 client, if that is appropriate to the cipher suite selected. Next,
1831 the server will send the server hello done message, indicating that
1832 the hello-message phase of the handshake is complete. The server will
1833 then wait for a client response. If the server has sent a certificate
1834 request message, the client MUST send the certificate message. The
1835 client key exchange message is now sent, and the content of that
1836 message will depend on the public key algorithm selected between the
1837 client hello and the server hello. If the client has sent a
1838 certificate with signing ability, a digitally-signed certificate
1839 verify message is sent to explicitly verify possession of the private
1840 key in the certificate.
1842 At this point, a change cipher spec message is sent by the client,
1846 Dierks & Rescorla Standards Track [Page 33]
1847 \f
1848 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1851 and the client copies the pending Cipher Spec into the current Cipher
1852 Spec. The client then immediately sends the finished message under
1853 the new algorithms, keys, and secrets. In response, the server will
1854 send its own change cipher spec message, transfer the pending to the
1855 current Cipher Spec, and send its finished message under the new
1856 Cipher Spec. At this point, the handshake is complete, and the client
1857 and server may begin to exchange application layer data. (See flow
1858 chart below.) Application data MUST NOT be sent prior to the
1859 completion of the first handshake (before a cipher suite other than
1860 TLS_NULL_WITH_NULL_NULL is established).
1862 Client Server
1864 ClientHello -------->
1865 ServerHello
1866 Certificate*
1867 ServerKeyExchange*
1868 CertificateRequest*
1869 <-------- ServerHelloDone
1870 Certificate*
1871 ClientKeyExchange
1872 CertificateVerify*
1873 [ChangeCipherSpec]
1874 Finished -------->
1875 [ChangeCipherSpec]
1876 <-------- Finished
1877 Application Data <-------> Application Data
1879 Fig. 1. Message flow for a full handshake
1881 * Indicates optional or situation-dependent messages that are not
1882 always sent.
1884 Note: To help avoid pipeline stalls, ChangeCipherSpec is an
1885 independent TLS Protocol content type, and is not actually a TLS
1886 handshake message.
1888 When the client and server decide to resume a previous session or
1889 duplicate an existing session (instead of negotiating new security
1890 parameters), the message flow is as follows:
1892 The client sends a ClientHello using the Session ID of the session to
1893 be resumed. The server then checks its session cache for a match. If
1894 a match is found, and the server is willing to re-establish the
1895 connection under the specified session state, it will send a
1896 ServerHello with the same Session ID value. At this point, both
1897 client and server MUST send change cipher spec messages and proceed
1898 directly to finished messages. Once the re-establishment is complete,
1902 Dierks & Rescorla Standards Track [Page 34]
1903 \f
1904 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1907 the client and server MAY begin to exchange application layer data.
1908 (See flow chart below.) If a Session ID match is not found, the
1909 server generates a new session ID and the TLS client and server
1910 perform a full handshake.
1912 Client Server
1914 ClientHello -------->
1915 ServerHello
1916 [ChangeCipherSpec]
1917 <-------- Finished
1918 [ChangeCipherSpec]
1919 Finished -------->
1920 Application Data <-------> Application Data
1922 Fig. 2. Message flow for an abbreviated handshake
1924 The contents and significance of each message will be presented in
1925 detail in the following sections.
1927 7.4. Handshake Protocol
1929 The TLS Handshake Protocol is one of the defined higher-level clients
1930 of the TLS Record Protocol. This protocol is used to negotiate the
1931 secure attributes of a session. Handshake messages are supplied to
1932 the TLS Record Layer, where they are encapsulated within one or more
1933 TLSPlaintext structures, which are processed and transmitted as
1934 specified by the current active session state.
1936 enum {
1937 hello_request(0), client_hello(1), server_hello(2),
1938 certificate(11), server_key_exchange (12),
1939 certificate_request(13), server_hello_done(14),
1940 certificate_verify(15), client_key_exchange(16),
1941 finished(20), (255)
1942 } HandshakeType;
1944 struct {
1945 HandshakeType msg_type; /* handshake type */
1946 uint24 length; /* bytes in message */
1947 select (HandshakeType) {
1948 case hello_request: HelloRequest;
1949 case client_hello: ClientHello;
1950 case server_hello: ServerHello;
1951 case certificate: Certificate;
1952 case server_key_exchange: ServerKeyExchange;
1953 case certificate_request: CertificateRequest;
1954 case server_hello_done: ServerHelloDone;
1958 Dierks & Rescorla Standards Track [Page 35]
1959 \f
1960 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
1963 case certificate_verify: CertificateVerify;
1964 case client_key_exchange: ClientKeyExchange;
1965 case finished: Finished;
1966 } body;
1967 } Handshake;
1969 The handshake protocol messages are presented below in the order they
1970 MUST be sent; sending handshake messages in an unexpected order
1971 results in a fatal error. Unneeded handshake messages can be omitted,
1972 however. Note one exception to the ordering: the Certificate message
1973 is used twice in the handshake (from server to client, then from
1974 client to server), but described only in its first position. The one
1975 message that is not bound by these ordering rules is the Hello
1976 Request message, which can be sent at any time, but which SHOULD be
1977 ignored by the client if it arrives in the middle of a handshake.
1979 New Handshake message types are assigned by IANA as described in
1980 Section 12.
1982 7.4.1. Hello Messages
1984 The hello phase messages are used to exchange security enhancement
1985 capabilities between the client and server. When a new session
1986 begins, the Record Layer's connection state encryption, hash, and
1987 compression algorithms are initialized to null. The current
1988 connection state is used for renegotiation messages.
1990 7.4.1.1. Hello Request
1992 When this message will be sent:
1994 The hello request message MAY be sent by the server at any time.
1996 Meaning of this message:
1998 Hello request is a simple notification that the client should
1999 begin the negotiation process anew by sending a client hello
2000 message when convenient. This message is not intended to establish
2001 which side is the client or server but merely to initiate a new
2002 negotiation. Servers SHOULD NOT send a HelloRequest immediately
2003 upon the client's initial connection. It is the client's job to
2004 send a ClientHello at that time.
2006 This message will be ignored by the client if the client is
2007 currently negotiating a session. This message may be ignored by
2008 the client if it does not wish to renegotiate a session, or the
2009 client may, if it wishes, respond with a no_renegotiation alert.
2010 Since handshake messages are intended to have transmission
2014 Dierks & Rescorla Standards Track [Page 36]
2015 \f
2016 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2019 precedence over application data, it is expected that the
2020 negotiation will begin before no more than a few records are
2021 received from the client. If the server sends a hello request but
2022 does not receive a client hello in response, it may close the
2023 connection with a fatal alert.
2025 After sending a hello request, servers SHOULD NOT repeat the
2026 request until the subsequent handshake negotiation is complete.
2028 Structure of this message:
2030 struct { } HelloRequest;
2032 Note: This message MUST NOT be included in the message hashes that
2033 are maintained throughout the handshake and used in the finished
2034 messages and the certificate verify message.
2036 7.4.1.2. Client Hello
2038 When this message will be sent:
2040 When a client first connects to a server it is required to send
2041 the client hello as its first message. The client can also send a
2042 client hello in response to a hello request or on its own
2043 initiative in order to renegotiate the security parameters in an
2044 existing connection.
2046 Structure of this message:
2048 The client hello message includes a random structure, which is
2049 used later in the protocol.
2051 struct {
2052 uint32 gmt_unix_time;
2053 opaque random_bytes[28];
2054 } Random;
2056 gmt_unix_time
2057 The current time and date in standard UNIX 32-bit format
2058 (seconds since the midnight starting Jan 1, 1970, GMT, ignoring
2059 leap seconds) according to the sender's internal clock. Clocks
2060 are not required to be set correctly by the basic TLS Protocol;
2061 higher-level or application protocols may define additional
2062 requirements.
2064 random_bytes
2065 28 bytes generated by a secure random number generator.
2070 Dierks & Rescorla Standards Track [Page 37]
2071 \f
2072 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2075 The client hello message includes a variable-length session
2076 identifier. If not empty, the value identifies a session between the
2077 same client and server whose security parameters the client wishes to
2078 reuse. The session identifier MAY be from an earlier connection, this
2079 connection, or from another currently active connection. The second
2080 option is useful if the client only wishes to update the random
2081 structures and derived values of a connection, and the third option
2082 makes it possible to establish several independent secure connections
2083 without repeating the full handshake protocol. These independent
2084 connections may occur sequentially or simultaneously; a SessionID
2085 becomes valid when the handshake negotiating it completes with the
2086 exchange of Finished messages and persists until it is removed due to
2087 aging or because a fatal error was encountered on a connection
2088 associated with the session. The actual contents of the SessionID are
2089 defined by the server.
2091 opaque SessionID<0..32>;
2093 Warning: Because the SessionID is transmitted without encryption or
2094 immediate MAC protection, servers MUST NOT place confidential
2095 information in session identifiers or let the contents of fake
2096 session identifiers cause any breach of security. (Note that the
2097 content of the handshake as a whole, including the SessionID, is
2098 protected by the Finished messages exchanged at the end of the
2099 handshake.)
2101 The CipherSuite list, passed from the client to the server in the
2102 client hello message, contains the combinations of cryptographic
2103 algorithms supported by the client in order of the client's
2104 preference (favorite choice first). Each CipherSuite defines a key
2105 exchange algorithm, a bulk encryption algorithm (including secret key
2106 length), a MAC algorithm, and a PRF. The server will select a cipher
2107 suite or, if no acceptable choices are presented, return a handshake
2108 failure alert and close the connection.
2110 uint8 CipherSuite[2]; /* Cryptographic suite selector */
2112 The client hello includes a list of compression algorithms supported
2113 by the client, ordered according to the client's preference.
2115 enum { null(0), (255) } CompressionMethod;
2117 struct {
2118 ProtocolVersion client_version;
2119 Random random;
2120 SessionID session_id;
2121 CipherSuite cipher_suites<2..2^16-2>;
2122 CompressionMethod compression_methods<1..2^8-1>;
2126 Dierks & Rescorla Standards Track [Page 38]
2127 \f
2128 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2131 select (extensions_present) {
2132 case false:
2133 struct {};
2134 case true:
2135 Extension extensions<0..2^16-1>;
2136 };
2137 } ClientHello;
2139 TLS allows extensions to follow the compression_methods field in an
2140 extensions block. The presence of extensions can be detected by
2141 determining whether there are bytes following the compression_methods
2142 at the end of the ClientHello. Note that this method of detecting
2143 optional data differs from the normal TLS method of having a
2144 variable-length field but is used for compatibility with TLS before
2145 extensions were defined.
2147 client_version
2148 The version of the TLS protocol by which the client wishes to
2149 communicate during this session. This SHOULD be the latest
2150 (highest valued) version supported by the client. For this version
2151 of the specification, the version will be 3.3 (See Appendix E for
2152 details about backward compatibility).
2154 random
2155 A client-generated random structure.
2157 session_id
2158 The ID of a session the client wishes to use for this connection.
2159 This field is empty if no session_id is available, or it the
2160 client wishes to generate new security parameters.
2162 cipher_suites
2163 This is a list of the cryptographic options supported by the
2164 client, with the client's first preference first. If the
2165 session_id field is not empty (implying a session resumption
2166 request) this vector MUST include at least the cipher_suite from
2167 that session. Values are defined in Appendix A.5.
2169 compression_methods
2170 This is a list of the compression methods supported by the client,
2171 sorted by client preference. If the session_id field is not empty
2172 (implying a session resumption request) it MUST include the
2173 compression_method from that session. This vector MUST contain,
2174 and all implementations MUST support, CompressionMethod.null.
2175 Thus, a client and server will always be able to agree on a
2176 compression method.
2182 Dierks & Rescorla Standards Track [Page 39]
2183 \f
2184 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2187 client_hello_extension_list
2188 Clients MAY request extended functionality from servers by sending
2189 data in the client_hello_extension_list. Here the new
2190 "client_hello_extension_list" field contains a list of extensions.
2191 The actual "Extension" format is defined in Section 7.4.1.4.
2193 In the event that a client requests additional functionality using
2194 extensions, and this functionality is not supplied by the server, the
2195 client MAY abort the handshake. A server that supports the
2196 extensions mechanism MUST accept client hello messages in either the
2197 original (TLS 1.0/TLS 1.1) ClientHello or the extended ClientHello
2198 format defined in this document, and (as for all other messages) MUST
2199 check that the amount of data in the message precisely matches one of
2200 these formats; if not then it MUST send a fatal "decode_error" alert.
2202 After sending the client hello message, the client waits for a server
2203 hello message. Any other handshake message returned by the server
2204 except for a hello request is treated as a fatal error.
2206 7.4.1.3. Server Hello
2208 When this message will be sent:
2210 The server will send this message in response to a client hello
2211 message when it was able to find an acceptable set of algorithms.
2212 If it cannot find such a match, it will respond with a handshake
2213 failure alert.
2215 Structure of this message:
2217 struct {
2218 ProtocolVersion server_version;
2219 Random random;
2220 SessionID session_id;
2221 CipherSuite cipher_suite;
2222 CompressionMethod compression_method;
2223 select (extensions_present) {
2224 case false:
2225 struct {};
2226 case true:
2227 Extension extensions<0..2^16-1>;
2228 };
2229 } ServerHello;
2231 The presence of extensions can be detected by determining whether
2232 there are bytes following the compression_method field at the end of
2233 the ServerHello.
2238 Dierks & Rescorla Standards Track [Page 40]
2239 \f
2240 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2243 server_version
2244 This field will contain the lower of that suggested by the client
2245 in the client hello and the highest supported by the server. For
2246 this version of the specification, the version is 3.3. (See
2247 Appendix E for details about backward compatibility.)
2249 random
2250 This structure is generated by the server and MUST be
2251 independently generated from the ClientHello.random.
2253 session_id
2254 This is the identity of the session corresponding to this
2255 connection. If the ClientHello.session_id was non-empty, the
2256 server will look in its session cache for a match. If a match is
2257 found and the server is willing to establish the new connection
2258 using the specified session state, the server will respond with
2259 the same value as was supplied by the client. This indicates a
2260 resumed session and dictates that the parties must proceed
2261 directly to the finished messages. Otherwise this field will
2262 contain a different value identifying the new session. The server
2263 may return an empty session_id to indicate that the session will
2264 not be cached and therefore cannot be resumed. If a session is
2265 resumed, it must be resumed using the same cipher suite it was
2266 originally negotiated with. Note that there is no requirement that
2267 the server resume any session even if it had formerly provided a
2268 session_id. Client MUST be prepared to do a full negotiation --
2269 including negotiating new cipher suites -- during any handshake.
2271 cipher_suite
2272 The single cipher suite selected by the server from the list in
2273 ClientHello.cipher_suites. For resumed sessions, this field is the
2274 value from the state of the session being resumed.
2276 compression_method
2277 The single compression algorithm selected by the server from the
2278 list in ClientHello.compression_methods. For resumed sessions this
2279 field is the value from the resumed session state.
2281 server_hello_extension_list
2282 A list of extensions. Note that only extensions offered by the
2283 client can appear in the server's list.
2294 Dierks & Rescorla Standards Track [Page 41]
2295 \f
2296 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2299 7.4.1.4 Hello Extensions
2301 The extension format is:
2303 struct {
2304 ExtensionType extension_type;
2305 opaque extension_data<0..2^16-1>;
2306 } Extension;
2308 enum {
2309 signature_algorithms(TBD-BY-IANA), (65535)
2310 } ExtensionType;
2312 Here:
2314 - "extension_type" identifies the particular extension type.
2316 - "extension_data" contains information specific to the particular
2317 extension type.
2319 The initial set of extensions is defined in a companion document
2320 [TLSEXT]. The list of extension types is maintained by IANA as
2321 described in Section 12.
2323 There are subtle (and not so subtle) interactions that may occur in
2324 this protocol between new features and existing features which may
2325 result in a significant reduction in overall security, The following
2326 considerations should be taken into account when designing new
2327 extensions:
2329 - Some cases where a server does not agree to an extension are error
2330 conditions, and some simply a refusal to support a particular
2331 feature. In general error alerts should be used for the former,
2332 and a field in the server extension response for the latter.
2334 - Extensions should as far as possible be designed to prevent any
2335 attack that forces use (or non-use) of a particular feature by
2336 manipulation of handshake messages. This principle should be
2337 followed regardless of whether the feature is believed to cause a
2338 security problem.
2340 Often the fact that the extension fields are included in the
2341 inputs to the Finished message hashes will be sufficient, but
2342 extreme care is needed when the extension changes the meaning of
2343 messages sent in the handshake phase. Designers and implementors
2344 should be aware of the fact that until the handshake has been
2345 authenticated, active attackers can modify messages and insert,
2346 remove, or replace extensions.
2350 Dierks & Rescorla Standards Track [Page 42]
2351 \f
2352 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2355 - It would be technically possible to use extensions to change major
2356 aspects of the design of TLS; for example the design of cipher
2357 suite negotiation. This is not recommended; it would be more
2358 appropriate to define a new version of TLS - particularly since
2359 the TLS handshake algorithms have specific protection against
2360 version rollback attacks based on the version number, and the
2361 possibility of version rollback should be a significant
2362 consideration in any major design change.
2364 7.4.1.4.1 Signature Algorithms
2366 The client MAY use the "signature_algorithms" extension to indicate
2367 to the server which signature/hash algorithm pairs may be used in
2368 digital signatures. The "extension_data" field of this extension
2369 contains a "supported_signature_algorithms" value.
2371 enum {
2372 none(0), md5(1), sha1(2), sha256(3), sha384(4),
2373 sha512(5), (255)
2374 } HashAlgorithm;
2376 enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
2377 SignatureAlgorithm;
2379 struct {
2380 HashAlgorithm hash;
2381 SignatureAlgorithm signature;
2382 } SignatureAndHashAlgorithm;
2384 SignatureAndHashAlgorithm
2385 supported_signature_algorithms<2..2^16-1>;
2387 Each SignatureAndHashAlgorithm value lists a single hash/signature
2388 pair which the client is willing to verify. The values are indicated
2389 in descending order of preference.
2391 Note: Because not all signature algorithms and hash algorithms may be
2392 accepted by an implementation (e.g., DSA with SHA-1, but not
2393 SHA-256), algorithms here are listed in pairs.
2395 hash
2396 This field indicates the hash algorithm which may be used. The
2397 values indicate support for unhashed data, MD5 [MD5], SHA-1,
2398 SHA-256, SHA-384, and SHA-512 [SHA] respectively. The "none" value
2399 is provided for future extensibility, in case of a signature
2400 algorithm which does not require hashing before signing.
2402 signature
2406 Dierks & Rescorla Standards Track [Page 43]
2407 \f
2408 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2411 This field indicates the signature algorithm which may be used.
2412 The values indicate anonymous signatures, RSA [PKCS1] and DSA
2413 [DSS] respectively. The "anonymous" value is meaningless in this
2414 context but used later in the specification. It MUST NOT appear in
2415 this extension.
2417 The semantics of this extension are somewhat complicated because the
2418 cipher suite indicates permissible signature algorithms but not hash
2419 algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate rules.
2421 Clients SHOULD send this extension if they support any hash algorithm
2422 other than SHA-1.
2424 If the client does not send the signature_algorithms extension, the
2425 server SHOULD assume the following:
2427 - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
2428 DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent
2429 the value (sha1,rsa).
2431 - If the negotiated key exchange algorithm is one of (DHE_DSS,
2432 DH_DSS), behave as if the client had sent the value (sha1,dsa).
2434 - If the negotiated key exchnage algorithm is one of (ECDH_ECDSA,
2435 ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa).
2437 Note: this is a change from TLS 1.1 where there are no explicit rules
2438 but as a practical matter one can assume that the peer supports MD5
2439 and SHA-1.
2441 Servers MUST NOT send this extension.
2443 7.4.2. Server Certificate
2445 When this message will be sent:
2447 The server MUST send a certificate whenever the agreed-upon key
2448 exchange method uses certificates for authentication (this
2449 includes all key exchange methods defined in this document except
2450 DH_anon). This message will always immediately follow the server
2451 hello message.
2453 Meaning of this message:
2455 This message conveys the server's certificate to the client. The
2456 certificate MUST be appropriate for the negotiated cipher suite's
2457 key exchange algorithm, and any negotiated extensions.
2462 Dierks & Rescorla Standards Track [Page 44]
2463 \f
2464 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2467 Structure of this message:
2469 opaque ASN.1Cert<1..2^24-1>;
2471 struct {
2472 ASN.1Cert certificate_list<0..2^24-1>;
2473 } Certificate;
2475 certificate_list
2476 This is a sequence (chain) of certificates. The sender's
2477 certificate MUST come first in the list. Each following
2478 certificate MUST directly certify the one preceding it. Because
2479 certificate validation requires that root keys be distributed
2480 independently, the self-signed certificate that specifies the root
2481 certificate authority MAY optionally be omitted from the chain,
2482 under the assumption that the remote end must already possess it
2483 in order to validate it in any case.
2485 The same message type and structure will be used for the client's
2486 response to a certificate request message. Note that a client MAY
2487 send no certificates if it does not have an appropriate certificate
2488 to send in response to the server's authentication request.
2490 Note: PKCS #7 [PKCS7] is not used as the format for the certificate
2491 vector because PKCS #6 [PKCS6] extended certificates are not used.
2492 Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
2493 of parsing the list more difficult.
2495 The following rules apply to the certificates sent by the server:
2497 - The certificate type MUST be X.509v3, unless explicitly negotiated
2498 otherwise (e.g., [TLSPGP]).
2500 - The certificate's public key (and associated restrictions) MUST be
2501 compatible with the selected key exchange algorithm.
2503 Key Exchange Alg. Certificate Key Type
2505 RSA RSA public key; the certificate MUST
2506 RSA_PSK allow the key to be used for encryption
2507 (the keyEncipherment bit MUST be set
2508 if the key usage extension is present).
2509 Note: RSA_PSK is defined in [TLSPSK].
2511 DHE_RSA RSA public key; the certificate MUST
2512 ECDHE_RSA allow the key to be used for signing
2513 (the digitalSignature bit MUST be set
2514 if the key usage extension is present)
2518 Dierks & Rescorla Standards Track [Page 45]
2519 \f
2520 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2523 with the signature scheme and hash
2524 algorithm that will be employed in the
2525 server key exchange message.
2527 DHE_DSS DSA public key; the certificate MUST
2528 allow the key to be used for signing with
2529 the hash algorithm that will be employed
2530 in the server key exchange message.
2532 DH_DSS Diffie-Hellman public key; the
2533 DH_RSA keyAgreement bit MUST be set if the
2534 key usage extension is present.
2536 ECDH_ECDSA ECDH-capable public key; the public key
2537 ECDH_RSA MUST use a curve and point format supported
2538 by the client, as described in [TLSECC].
2540 ECDHE_ECDSA ECDSA-capable public key; the certificate
2541 MUST allow the key to be used for signing
2542 with the hash algorithm that will be
2543 employed in the server key exchange
2544 message. The public key MUST use a curve
2545 and point format supported by the client,
2546 as described in [TLSECC].
2548 - The "server_name" and "trusted_ca_keys" extensions [4366bis] are
2549 used to guide certificate selection.
2551 If the client provided a "signature_algorithms" extension, then all
2552 certificates provided by the server MUST be signed by a
2553 hash/signature algorithm pair that appears in that extension. Note
2554 that this implies that a certificate containing a key for one
2555 signature algorithm MAY be signed using a different signature
2556 algorithm (for instance, an RSA key signed with a DSA key.) This is a
2557 departure from TLS 1.1, which required that the algorithms be the
2558 same. Note that this also implies that the DH_DSS, DH_RSA,
2559 ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
2560 algorithm used to sign the certificate. Fixed DH certificates MAY be
2561 signed with any hash/signature algorithm pair appearing in the
2562 extension. The naming is historical.
2564 If the server has multiple certificates, it chooses one of them based
2565 on the above-mentioned criteria (in addition to other criteria, such
2566 as transport layer endpoint, local configuration and preferences,
2567 etc.).
2569 Note that there are certificates that use algorithms and/or algorithm
2570 combinations that cannot be currently used with TLS. For example, a
2574 Dierks & Rescorla Standards Track [Page 46]
2575 \f
2576 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2579 certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
2580 SubjectPublicKeyInfo) cannot be used because TLS defines no
2581 corresponding signature algorithm.
2583 As CipherSuites that specify new key exchange methods are specified
2584 for the TLS Protocol, they will imply certificate format and the
2585 required encoded keying information.
2587 7.4.3. Server Key Exchange Message
2589 When this message will be sent:
2591 This message will be sent immediately after the server certificate
2592 message (or the server hello message, if this is an anonymous
2593 negotiation).
2595 The server key exchange message is sent by the server only when
2596 the server certificate message (if sent) does not contain enough
2597 data to allow the client to exchange a premaster secret. This is
2598 true for the following key exchange methods:
2600 DHE_DSS
2601 DHE_RSA
2602 DH_anon
2604 It is not legal to send the server key exchange message for the
2605 following key exchange methods:
2607 RSA
2608 DH_DSS
2609 DH_RSA
2611 Meaning of this message:
2613 This message conveys cryptographic information to allow the client
2614 to communicate the premaster secret: a Diffie-Hellman public key
2615 with which the client can complete a key exchange (with the result
2616 being the premaster secret) or a public key for some other
2617 algorithm.
2619 Structure of this message:
2621 enum { diffie_hellman, rsa } KeyExchangeAlgorithm;
2623 struct {
2624 opaque dh_p<1..2^16-1>;
2625 opaque dh_g<1..2^16-1>;
2626 opaque dh_Ys<1..2^16-1>;
2630 Dierks & Rescorla Standards Track [Page 47]
2631 \f
2632 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2635 } ServerDHParams; /* Ephemeral DH parameters */
2637 dh_p
2638 The prime modulus used for the Diffie-Hellman operation.
2640 dh_g
2641 The generator used for the Diffie-Hellman operation.
2643 dh_Ys
2644 The server's Diffie-Hellman public value (g^X mod p).
2646 struct {
2647 select (KeyExchangeAlgorithm) {
2648 case diffie_hellman:
2649 ServerDHParams params;
2650 Signature signed_params;
2651 };
2652 } ServerKeyExchange;
2654 struct {
2655 select (KeyExchangeAlgorithm) {
2656 case diffie_hellman:
2657 ServerDHParams params;
2658 };
2659 } ServerParams;
2662 params
2663 The server's key exchange parameters.
2665 signed_params
2666 For non-anonymous key exchanges, a hash of the corresponding
2667 params value, with the signature appropriate to that hash
2668 applied.
2670 hash
2671 Hash(ClientHello.random + ServerHello.random + ServerParams)
2672 where Hash is the chosen hash value and Hash.length is
2673 its output.
2675 struct {
2676 select (SignatureAlgorithm) {
2677 case anonymous: struct { };
2678 case rsa:
2679 SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
2680 digitally-signed struct {
2681 opaque hash[Hash.length];
2682 };
2686 Dierks & Rescorla Standards Track [Page 48]
2687 \f
2688 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2691 case dsa:
2692 SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
2693 digitally-signed struct {
2694 opaque hash[Hash.length];
2695 };
2696 };
2697 };
2698 } Signature;
2700 If the client has offered the "signature_algorithms" extension, the
2701 signature algorithm and hash algorithm MUST be a pair listed in that
2702 extension. Note that there is a possibility for inconsistencies here.
2703 For instance, the client might offer DHE_DSS key exchange but omit
2704 any DSS pairs from its "signature_algorithms" extension. In order to
2705 negotiate correctly, the server MUST check any candidate cipher
2706 suites against the "signature_algorithms" extension before selecting
2707 them. This is somewhat inelegant but is a compromise designed to
2708 minimize changes to the original cipher suite design.
2710 If no "signature_algorithms" extension is present, the server MUST
2711 use SHA-1 as the hash algorithm.
2713 In addition, the hash and signature algorithms MUST be compatible
2714 with the key in the server's end-entity certificate. RSA keys MAY be
2715 used with any permitted hash algorithm, subject to restrictions in
2716 the certificate, if any.
2718 Because DSA signatures do not contain any secure indication of hash
2719 algorithm, there is a risk of hash substitution if multiple hashes
2720 may be used with any key. Currently, DSS [DSS] may only be used with
2721 SHA-1. Future revisions of DSS [DSS-3] are expected to allow other
2722 digest algorithms, as well as guidance as to which digest algorithms
2723 should be used with each key size. In addition, future revisions of
2724 [PKIX] may specify mechanisms for certificates to indicate which
2725 digest algorithms are to be used with DSA.
2727 As additional CipherSuites are defined for TLS that include new key
2728 exchange algorithms, the server key exchange message will be sent if
2729 and only if the certificate type associated with the key exchange
2730 algorithm does not provide enough information for the client to
2731 exchange a premaster secret.
2733 7.4.4. Certificate Request
2735 When this message will be sent:
2737 A non-anonymous server can optionally request a certificate from
2738 the client, if appropriate for the selected cipher suite. This
2742 Dierks & Rescorla Standards Track [Page 49]
2743 \f
2744 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2747 message, if sent, will immediately follow the Server Key Exchange
2748 message (if it is sent; otherwise, the Server Certificate
2749 message).
2751 Structure of this message:
2753 enum {
2754 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
2755 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
2756 fortezza_dms_RESERVED(20), (255)
2757 } ClientCertificateType;
2759 opaque DistinguishedName<1..2^16-1>;
2761 struct {
2762 ClientCertificateType certificate_types<1..2^8-1>;
2763 SignatureAndHashAlgorithm
2764 supported_signature_algorithms<2^16-1>;
2765 DistinguishedName certificate_authorities<0..2^16-1>;
2766 } CertificateRequest;
2768 certificate_types
2769 A list of the types of certificate types which the client may
2770 offer.
2772 rsa_sign a certificate containing an RSA key
2773 dss_sign a certificate containing a DSS key
2774 rsa_fixed_dh a certificate containing a static DH key.
2775 dss_fixed_dh a certificate containing a static DH key
2777 supported_signature_algorithms
2778 A list of the hash/signature algorithm pairs that the server is
2779 able to verify, listed in descending order of preference.
2781 certificate_authorities
2782 A list of the distinguished names [X501] of acceptable
2783 certificate_authorities, represented in DER-encoded format. These
2784 distinguished names may specify a desired distinguished name for a
2785 root CA or for a subordinate CA; thus, this message can be used
2786 both to describe known roots and a desired authorization space. If
2787 the certificate_authorities list is empty then the client MAY send
2788 any certificate of the appropriate ClientCertificateType, unless
2789 there is some external arrangement to the contrary.
2791 The interaction of the certificate_types and
2792 supported_signature_algorithms fields is somewhat complicated.
2793 certificate_types has been present in TLS since SSLv3, but was
2794 somewhat underspecified. Much of its functionality is superseded by
2798 Dierks & Rescorla Standards Track [Page 50]
2799 \f
2800 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2803 supported_signature_algorithms. The following rules apply:
2805 - Any certificates provided by the client MUST be signed using a
2806 hash/signature algorithm pair found in supported_signature_types.
2808 - The end-entity certificate provided by the client MUST contain a
2809 key which is compatible with certificate_types. If the key is a
2810 signature key, it MUST be usable with some hash/signature
2811 algorithm pair in supported_signature_types.
2813 - For historical reasons, the names of some client certificate types
2814 include the algorithm used to sign the certificate. For example,
2815 in earlier versions of TLS, rsa_fixed_dh meant a certificate
2816 signed with RSA and containing a static DH key. In TLS 1.2, this
2817 functionality has been obsoleted by the signature_types field, and
2818 the certificate type no longer restricts the algorithm used to
2819 sign the certificate. For example, if the server sends
2820 dss_fixed_dh certificate type and {dss_sha1, rsa_sha1} signature
2821 types, the client MAY to reply with a certificate containing a
2822 static DH key, signed with RSA-SHA1.
2824 New ClientCertificateType values are assigned by IANA as described in
2825 Section 12.
2827 Note: Values listed as RESERVED may not be used. They were used in
2828 SSLv3.
2830 Note: It is a fatal handshake_failure alert for an anonymous server
2831 to request client authentication.
2833 7.4.5 Server hello done
2835 When this message will be sent:
2837 The server hello done message is sent by the server to indicate
2838 the end of the server hello and associated messages. After sending
2839 this message, the server will wait for a client response.
2841 Meaning of this message:
2843 This message means that the server is done sending messages to
2844 support the key exchange, and the client can proceed with its
2845 phase of the key exchange.
2847 Upon receipt of the server hello done message, the client SHOULD
2848 verify that the server provided a valid certificate, if required
2849 and check that the server hello parameters are acceptable.
2854 Dierks & Rescorla Standards Track [Page 51]
2855 \f
2856 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2859 Structure of this message:
2861 struct { } ServerHelloDone;
2863 7.4.6. Client Certificate
2865 When this message will be sent:
2867 This is the first message the client can send after receiving a
2868 server hello done message. This message is only sent if the server
2869 requests a certificate. If no suitable certificate is available,
2870 the client MUST send a certificate message containing no
2871 certificates. That is, the certificate_list structure has a length
2872 of zero. If client authentication is required by the server for
2873 the handshake to continue, it may respond with a fatal handshake
2874 failure alert. Client certificates are sent using the Certificate
2875 structure defined in Section 7.4.2.
2877 Meaning of this message:
2879 This message conveys the client's certificate to the server; the
2880 server will use it when verifying the certificate verify message
2881 (when the client authentication is based on signing), or calculate
2882 the premaster secret (for non-ephemeral Diffie-Hellman). The
2883 certificate MUST be appropriate for the negotiated cipher suite's
2884 key exchange algorithm, and any negotiated extensions.
2886 In particular:
2888 - The certificate type MUST be X.509v3, unless explicitly negotiated
2889 otherwise (e.g. [TLSPGP]).
2891 - The certificate's public key (and associated restrictions) has to
2892 be compatible with the certificate types listed in
2893 CertificateRequest:
2895 Client Cert. Type Certificate Key Type
2897 rsa_sign RSA public key; the certificate MUST allow
2898 the key to be used for signing with the
2899 signature scheme and hash algorithm that
2900 will be employed in the certificate verify
2901 message.
2903 dss_sign DSA public key; the certificate MUST allow
2904 the key to be used for signing with the
2905 hash algorithm that will be employed in
2906 the certificate verify message.
2910 Dierks & Rescorla Standards Track [Page 52]
2911 \f
2912 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2915 ecdsa_sign ECDSA-capable public key; the certificate
2916 MUST allow the key to be used for signing
2917 with the hash algorithm that will be
2918 employed in the certificate verify
2919 message; the public key MUST use a
2920 curve and point format supported by the
2921 server.
2923 rsa_fixed_dh Diffie-Hellman public key; MUST use
2924 dss_fixed_dh the same parameters as server's key.
2926 rsa_fixed_ecdh ECDH-capable public key; MUST use
2927 ecdsa_fixed_ecdh the same curve as server's key, and
2928 MUST use a point format supported by
2930 - If the certificate_authorities list in the certificate request
2931 message was non-empty, the certificate SHOULD be issued by one of
2932 the listed CAs.
2934 - The certificates MUST be signed using an acceptable hash/
2935 signature algorithm pair, as described in Section 7.4.4. Note that
2936 this relaxes the constraints on certificate signing algorithms
2937 found in prior versions of TLS.
2939 Note that as with the server certificate, there are certificates that
2940 use algorithms/algorithm combinations that cannot be currently used
2941 with TLS.
2943 7.4.7. Client Key Exchange Message
2945 When this message will be sent:
2947 This message is always sent by the client. It MUST immediately
2948 follow the client certificate message, if it is sent. Otherwise it
2949 MUST be the first message sent by the client after it receives the
2950 server hello done message.
2952 Meaning of this message:
2954 With this message, the premaster secret is set, either though
2955 direct transmission of the RSA-encrypted secret, or by the
2956 transmission of Diffie-Hellman parameters that will allow each
2957 side to agree upon the same premaster secret.
2959 When the client is using an ephemeral Diffie-Hellman exponent,
2960 then this message contains the client's Diffie-Hellman public
2961 value. If the client is sending a certificate containing a static
2962 DH exponent (i.e., it is doing fixed_dh client authentication)
2966 Dierks & Rescorla Standards Track [Page 53]
2967 \f
2968 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
2971 then this message MUST be sent but MUST be empty.
2974 Structure of this message:
2976 The choice of messages depends on which key exchange method has
2977 been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
2978 definition.
2980 struct {
2981 select (KeyExchangeAlgorithm) {
2982 case rsa: EncryptedPreMasterSecret;
2983 case diffie_hellman: ClientDiffieHellmanPublic;
2984 } exchange_keys;
2985 } ClientKeyExchange;
2987 7.4.7.1. RSA Encrypted Premaster Secret Message
2989 Meaning of this message:
2991 If RSA is being used for key agreement and authentication, the
2992 client generates a 48-byte premaster secret, encrypts it using the
2993 public key from the server's certificate and sends the result in
2994 an encrypted premaster secret message. This structure is a variant
2995 of the client key exchange message and is not a message in itself.
2997 Structure of this message:
2999 struct {
3000 ProtocolVersion client_version;
3001 opaque random[46];
3002 } PreMasterSecret;
3004 client_version
3005 The latest (newest) version supported by the client. This is
3006 used to detect version roll-back attacks.
3008 random
3009 46 securely-generated random bytes.
3011 struct {
3012 public-key-encrypted PreMasterSecret pre_master_secret;
3013 } EncryptedPreMasterSecret;
3015 pre_master_secret
3016 This random value is generated by the client and is used to
3017 generate the master secret, as specified in Section 8.1.
3022 Dierks & Rescorla Standards Track [Page 54]
3023 \f
3024 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3027 Note: The version number in the PreMasterSecret is the version
3028 offered by the client in the ClientHello.client_version, not the
3029 version negotiated for the connection. This feature is designed to
3030 prevent rollback attacks. Unfortunately, some old implementations
3031 use the negotiated version instead and therefore checking the version
3032 number may lead to failure to interoperate with such incorrect client
3033 implementations.
3035 Client implementations MUST always send the correct version number in
3036 PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher,
3037 server implementations MUST check the version number as described in
3038 the note below. If the version number is earlier than 1.0, server
3039 implementations SHOULD check the version number, but MAY have a
3040 configuration option to disable the check. Note that if the check
3041 fails, the PreMasterSecret SHOULD be randomized as described below.
3043 Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
3044 [KPR03] can be used to attack a TLS server that reveals whether a
3045 particular message, when decrypted, is properly PKCS#1 formatted,
3046 contains a valid PreMasterSecret structure, or has the correct
3047 version number.
3049 The best way to avoid these vulnerabilities is to treat incorrectly
3050 formatted messages in a manner indistinguishable from correctly
3051 formatted RSA blocks. In other words:
3053 1. Generate a string R of 46 random bytes
3055 2. Decrypt the message M
3057 3. If the PKCS#1 padding is not correct, or the length of
3058 message M is not exactly 48 bytes:
3059 premaster secret = ClientHello.client_version || R
3060 else If ClientHello.client_version <= TLS 1.0, and
3061 version number check is explicitly disabled:
3062 premaster secret = M
3063 else:
3064 premaster secret = ClientHello.client_version || M[2..47]
3066 In any case, a TLS server MUST NOT generate an alert if processing an
3067 RSA-encrypted premaster secret message fails, or the version number
3068 is not as expected. Instead, it MUST continue the handshake with a
3069 randomly generated premaster secret. It may be useful to log the
3070 real cause of failure for troubleshooting purposes; however, care
3071 must be taken to avoid leaking the information to an attacker
3072 (though, e.g., timing, log files, or other channels.)
3074 The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
3078 Dierks & Rescorla Standards Track [Page 55]
3079 \f
3080 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3083 against the Bleichenbacher attack. However, for maximal compatibility
3084 with earlier versions of TLS, this specification uses the RSAES-
3085 PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known
3086 to exist provided that the above recommendations are followed.
3088 Implementation Note: Public-key-encrypted data is represented as an
3089 opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
3090 PreMasterSecret in a ClientKeyExchange is preceded by two length
3091 bytes. These bytes are redundant in the case of RSA because the
3092 EncryptedPreMasterSecret is the only data in the ClientKeyExchange
3093 and its length can therefore be unambiguously determined. The SSLv3
3094 specification was not clear about the encoding of public-key-
3095 encrypted data, and therefore many SSLv3 implementations do not
3096 include the the length bytes, encoding the RSA encrypted data
3097 directly in the ClientKeyExchange message.
3099 This specification requires correct encoding of the
3100 EncryptedPreMasterSecret complete with length bytes. The resulting
3101 PDU is incompatible with many SSLv3 implementations. Implementors
3102 upgrading from SSLv3 MUST modify their implementations to generate
3103 and accept the correct encoding. Implementors who wish to be
3104 compatible with both SSLv3 and TLS should make their implementation's
3105 behavior dependent on the protocol version.
3107 Implementation Note: It is now known that remote timing-based attacks
3108 on TLS are possible, at least when the client and server are on the
3109 same LAN. Accordingly, implementations that use static RSA keys MUST
3110 use RSA blinding or some other anti-timing technique, as described in
3111 [TIMING].
3114 7.4.7.2. Client Diffie-Hellman Public Value
3116 Meaning of this message:
3118 This structure conveys the client's Diffie-Hellman public value
3119 (Yc) if it was not already included in the client's certificate.
3120 The encoding used for Yc is determined by the enumerated
3121 PublicValueEncoding. This structure is a variant of the client key
3122 exchange message, and not a message in itself.
3124 Structure of this message:
3126 enum { implicit, explicit } PublicValueEncoding;
3128 implicit
3129 If the client has sent a certificate which contains a suitable
3130 Diffie-Hellman key (for fixed_dh client authentication) then Yc
3134 Dierks & Rescorla Standards Track [Page 56]
3135 \f
3136 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3139 is implicit and does not need to be sent again. In this case,
3140 the client key exchange message will be sent, but it MUST be
3141 empty.
3143 explicit
3144 Yc needs to be sent.
3146 struct {
3147 select (PublicValueEncoding) {
3148 case implicit: struct { };
3149 case explicit: opaque dh_Yc<1..2^16-1>;
3150 } dh_public;
3151 } ClientDiffieHellmanPublic;
3153 dh_Yc
3154 The client's Diffie-Hellman public value (Yc).
3156 7.4.8. Certificate verify
3158 When this message will be sent:
3160 This message is used to provide explicit verification of a client
3161 certificate. This message is only sent following a client
3162 certificate that has signing capability (i.e. all certificates
3163 except those containing fixed Diffie-Hellman parameters). When
3164 sent, it MUST immediately follow the client key exchange message.
3166 Structure of this message:
3168 struct {
3169 Signature signature;
3170 } CertificateVerify;
3172 The Signature type is defined in 7.4.3.
3174 The hash algorithm is denoted Hash below.
3176 CertificateVerify.signature.hash = Hash(handshake_messages);
3178 The hash and signature algorithms MUST be one of those present in the
3179 supported_signature_algorithms field of the CertificateRequest
3180 message. In addition, the hash and signature algorithms MUST be
3181 compatible with the key in the client's end-entity certificate. RSA
3182 keys MAY be used with any permitted hash algorith, subject to
3183 restrictions in the certificate, if any.
3185 Because DSA signatures do not contain any secure indication of hash
3186 algorithm, there is a risk of hash substitution if multiple hashes
3190 Dierks & Rescorla Standards Track [Page 57]
3191 \f
3192 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3195 may be used with any key. Currently, DSS [DSS] may only be used with
3196 SHA-1. Future revisions of DSS [DSS-3] are expected to allow other
3197 digest algorithms, as well as guidance as to which digest algorithms
3198 should be used with each key size. In addition, future revisions of
3199 [PKIX] may specify mechanisms for certificates to indicate which
3200 digest algorithms are to be used with DSA.
3202 Here handshake_messages refers to all handshake messages sent or
3203 received starting at client hello up to but not including this
3204 message, including the type and length fields of the handshake
3205 messages. This is the concatenation of all the Handshake structures
3206 as defined in 7.4 exchanged thus far.
3208 7.4.9. Finished
3210 When this message will be sent:
3212 A finished message is always sent immediately after a change
3213 cipher spec message to verify that the key exchange and
3214 authentication processes were successful. It is essential that a
3215 change cipher spec message be received between the other handshake
3216 messages and the Finished message.
3218 Meaning of this message:
3220 The finished message is the first protected with the just-
3221 negotiated algorithms, keys, and secrets. Recipients of finished
3222 messages MUST verify that the contents are correct. Once a side
3223 has sent its Finished message and received and validated the
3224 Finished message from its peer, it may begin to send and receive
3225 application data over the connection.
3227 Structure of this message:
3229 struct {
3230 opaque verify_data[verify_data_length];
3231 } Finished;
3233 verify_data
3234 PRF(master_secret, finished_label, Hash(handshake_messages))
3235 [0..verify_data_length-1];
3237 finished_label
3238 For Finished messages sent by the client, the string "client
3239 finished". For Finished messages sent by the server, the string
3240 "server finished".
3242 Hash denotes a Hash of the handshake messages. For the PRF defined
3246 Dierks & Rescorla Standards Track [Page 58]
3247 \f
3248 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3251 in Section 5, the Hash MUST be the Hash used as the basis for the
3252 PRF. Any cipher suite which defines a different PRF MUST also
3253 define the Hash to use in the Finished computation.
3255 In previous versions of TLS, the verify_data was always 12 octets
3256 long. In the current version of TLS, it depends on the cipher
3257 suite. Any cipher suite which does not explicitly specify
3258 verify_data_length has a verify_data_length equal to 12. This
3259 includes all existing cipher suites. Note that this
3260 representation has the same encoding as with previous versions.
3261 Future cipher suites MAY specify other lengths but such length
3262 MUST be at least 12 bytes.
3264 handshake_messages
3265 All of the data from all messages in this handshake (not
3266 including any HelloRequest messages) up to but not including
3267 this message. This is only data visible at the handshake layer
3268 and does not include record layer headers. This is the
3269 concatenation of all the Handshake structures as defined in
3270 7.4, exchanged thus far.
3272 It is a fatal error if a finished message is not preceded by a change
3273 cipher spec message at the appropriate point in the handshake.
3275 The value handshake_messages includes all handshake messages starting
3276 at client hello up to, but not including, this finished message. This
3277 may be different from handshake_messages in Section 7.4.8 because it
3278 would include the certificate verify message (if sent). Also, the
3279 handshake_messages for the finished message sent by the client will
3280 be different from that for the finished message sent by the server,
3281 because the one that is sent second will include the prior one.
3283 Note: Change cipher spec messages, alerts, and any other record types
3284 are not handshake messages and are not included in the hash
3285 computations. Also, Hello Request messages are omitted from handshake
3286 hashes.
3288 8. Cryptographic Computations
3290 In order to begin connection protection, the TLS Record Protocol
3291 requires specification of a suite of algorithms, a master secret, and
3292 the client and server random values. The authentication, encryption,
3293 and MAC algorithms are determined by the cipher_suite selected by the
3294 server and revealed in the server hello message. The compression
3295 algorithm is negotiated in the hello messages, and the random values
3296 are exchanged in the hello messages. All that remains is to calculate
3297 the master secret.
3302 Dierks & Rescorla Standards Track [Page 59]
3303 \f
3304 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3307 8.1. Computing the Master Secret
3309 For all key exchange methods, the same algorithm is used to convert
3310 the pre_master_secret into the master_secret. The pre_master_secret
3311 should be deleted from memory once the master_secret has been
3312 computed.
3314 master_secret = PRF(pre_master_secret, "master secret",
3315 ClientHello.random + ServerHello.random)
3316 [0..47];
3318 The master secret is always exactly 48 bytes in length. The length of
3319 the premaster secret will vary depending on key exchange method.
3321 8.1.1. RSA
3323 When RSA is used for server authentication and key exchange, a
3324 48-byte pre_master_secret is generated by the client, encrypted under
3325 the server's public key, and sent to the server. The server uses its
3326 private key to decrypt the pre_master_secret. Both parties then
3327 convert the pre_master_secret into the master_secret, as specified
3328 above.
3330 8.1.2. Diffie-Hellman
3332 A conventional Diffie-Hellman computation is performed. The
3333 negotiated key (Z) is used as the pre_master_secret, and is converted
3334 into the master_secret, as specified above. Leading bytes of Z that
3335 contain all zero bits are stripped before it is used as the
3336 pre_master_secret.
3338 Note: Diffie-Hellman parameters are specified by the server and may
3339 be either ephemeral or contained within the server's certificate.
3341 9. Mandatory Cipher Suites
3343 In the absence of an application profile standard specifying
3344 otherwise, a TLS compliant application MUST implement the cipher
3345 suite TLS_RSA_WITH_AES_128_CBC_SHA.
3347 10. Application Data Protocol
3349 Application data messages are carried by the Record Layer and are
3350 fragmented, compressed, and encrypted based on the current connection
3351 state. The messages are treated as transparent data to the record
3352 layer.
3354 11. Security Considerations
3358 Dierks & Rescorla Standards Track [Page 60]
3359 \f
3360 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3363 Security issues are discussed throughout this memo, especially in
3364 Appendices D, E, and F.
3366 12. IANA Considerations
3368 This document uses several registries that were originally created in
3369 [TLS1.1]. IANA is requested to update (has updated) these to
3370 reference this document. The registries and their allocation policies
3371 (unchanged from [TLS1.1]) are listed below.
3373 - TLS ClientCertificateType Identifiers Registry: Future values in
3374 the range 0-63 (decimal) inclusive are assigned via Standards
3375 Action [RFC2434]. Values in the range 64-223 (decimal) inclusive
3376 are assigned Specification Required [RFC2434]. Values from 224-255
3377 (decimal) inclusive are reserved for Private Use [RFC2434].
3379 - TLS Cipher Suite Registry: Future values with the first byte in
3380 the range 0-191 (decimal) inclusive are assigned via Standards
3381 Action [RFC2434]. Values with the first byte in the range 192-254
3382 (decimal) are assigned via Specification Required [RFC2434].
3383 Values with the first byte 255 (decimal) are reserved for Private
3384 Use [RFC2434].
3386 - TLS ContentType Registry: Future values are allocated via
3387 Standards Action [RFC2434].
3389 - TLS Alert Registry: Future values are allocated via Standards
3390 Action [RFC2434].
3392 - TLS HandshakeType Registry: Future values are allocated via
3393 Standards Action [RFC2434].
3395 This document also uses a registry originally created in [RFC4366].
3396 IANA is requested to update (has updated) it to reference this
3397 document. The registry and its allocation policy (unchanged from
3398 [RFC4366]) is listed below:
3400 - TLS ExtensionType Registry: Future values are allocated via IETF
3401 Consensus [RFC2434]
3403 In addition, this document defines two new registries to be
3404 maintained by IANA:
3406 - TLS SignatureAlgorithm Registry: The registry will be initially
3407 populated with the values described in Section 7.4.1.4.1. Future
3408 values in the range 0-63 (decimal) inclusive are assigned via
3409 Standards Action [RFC2434]. Values in the range 64-223 (decimal)
3410 inclusive are assigned via Specification Required [RFC2434].
3414 Dierks & Rescorla Standards Track [Page 61]
3415 \f
3416 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3419 Values from 224-255 (decimal) inclusive are reserved for Private
3420 Use [RFC2434].
3422 - TLS HashAlgorithm Registry: The registry will be initially
3423 populated with the values described in Section 7.4.1.4.1. Future
3424 values in the range 0-63 (decimal) inclusive are assigned via
3425 Standards Action [RFC2434]. Values in the range 64-223 (decimal)
3426 inclusive are assigned via Specification Required [RFC2434].
3427 Values from 224-255 (decimal) inclusive are reserved for Private
3428 Use [RFC2434].
3430 This document defines one new TLS extension, signature_algorithms,
3431 which is to be (has been) allocated value TBD-BY-IANA in the TLS
3432 ExtensionType registry.
3434 This document also uses the TLS Compression Method Identifiers
3435 Registry, defined in [RFC3749]. IANA is requested to allocate value
3436 0 for the "null" compression method.
3470 Dierks & Rescorla Standards Track [Page 62]
3471 \f
3472 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3475 Appendix A. Protocol Constant Values
3477 This section describes protocol types and constants.
3479 A.1. Record Layer
3481 struct {
3482 uint8 major, minor;
3483 } ProtocolVersion;
3485 ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/
3487 enum {
3488 change_cipher_spec(20), alert(21), handshake(22),
3489 application_data(23), (255)
3490 } ContentType;
3492 struct {
3493 ContentType type;
3494 ProtocolVersion version;
3495 uint16 length;
3496 opaque fragment[TLSPlaintext.length];
3497 } TLSPlaintext;
3499 struct {
3500 ContentType type;
3501 ProtocolVersion version;
3502 uint16 length;
3503 opaque fragment[TLSCompressed.length];
3504 } TLSCompressed;
3506 struct {
3507 ContentType type;
3508 ProtocolVersion version;
3509 uint16 length;
3510 select (SecurityParameters.cipher_type) {
3511 case stream: GenericStreamCipher;
3512 case block: GenericBlockCipher;
3513 case aead: GenericAEADCipher;
3514 } fragment;
3515 } TLSCiphertext;
3517 stream-ciphered struct {
3518 opaque content[TLSCompressed.length];
3519 opaque MAC[SecurityParameters.mac_length];
3520 } GenericStreamCipher;
3526 Dierks & Rescorla Standards Track [Page 63]
3527 \f
3528 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3531 struct {
3532 opaque IV[SecurityParameters.record_iv_length];
3533 block-ciphered struct {
3534 opaque content[TLSCompressed.length];
3535 opaque MAC[SecurityParameters.mac_length];
3536 uint8 padding[GenericBlockCipher.padding_length];
3537 uint8 padding_length;
3538 };
3539 } GenericBlockCipher;
3541 aead-ciphered struct {
3542 opaque IV[SecurityParameters.record_iv_length];
3543 opaque aead_output[AEADEncrypted.length];
3544 } GenericAEADCipher;
3546 A.2. Change Cipher Specs Message
3548 struct {
3549 enum { change_cipher_spec(1), (255) } type;
3550 } ChangeCipherSpec;
3552 A.3. Alert Messages
3554 enum { warning(1), fatal(2), (255) } AlertLevel;
3556 enum {
3557 close_notify(0),
3558 unexpected_message(10),
3559 bad_record_mac(20),
3560 decryption_failed_RESERVED(21),
3561 record_overflow(22),
3562 decompression_failure(30),
3563 handshake_failure(40),
3564 no_certificate_RESERVED(41),
3565 bad_certificate(42),
3566 unsupported_certificate(43),
3567 certificate_revoked(44),
3568 certificate_expired(45),
3569 certificate_unknown(46),
3570 illegal_parameter(47),
3571 unknown_ca(48),
3572 access_denied(49),
3573 decode_error(50),
3574 decrypt_error(51),
3575 export_restriction_RESERVED(60),
3576 protocol_version(70),
3577 insufficient_security(71),
3578 internal_error(80),
3582 Dierks & Rescorla Standards Track [Page 64]
3583 \f
3584 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3587 user_canceled(90),
3588 no_renegotiation(100),
3589 unsupported_extension(110), /* new */
3590 (255)
3591 } AlertDescription;
3593 struct {
3594 AlertLevel level;
3595 AlertDescription description;
3596 } Alert;
3598 A.4. Handshake Protocol
3600 enum {
3601 hello_request(0), client_hello(1), server_hello(2),
3602 certificate(11), server_key_exchange (12),
3603 certificate_request(13), server_hello_done(14),
3604 certificate_verify(15), client_key_exchange(16),
3605 finished(20)
3606 (255)
3607 } HandshakeType;
3609 struct {
3610 HandshakeType msg_type;
3611 uint24 length;
3612 select (HandshakeType) {
3613 case hello_request: HelloRequest;
3614 case client_hello: ClientHello;
3615 case server_hello: ServerHello;
3616 case certificate: Certificate;
3617 case server_key_exchange: ServerKeyExchange;
3618 case certificate_request: CertificateRequest;
3619 case server_hello_done: ServerHelloDone;
3620 case certificate_verify: CertificateVerify;
3621 case client_key_exchange: ClientKeyExchange;
3622 case finished: Finished;
3623 } body;
3624 } Handshake;
3626 A.4.1. Hello Messages
3628 struct { } HelloRequest;
3630 struct {
3631 uint32 gmt_unix_time;
3632 opaque random_bytes[28];
3633 } Random;
3638 Dierks & Rescorla Standards Track [Page 65]
3639 \f
3640 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3643 opaque SessionID<0..32>;
3645 uint8 CipherSuite[2];
3647 enum { null(0), (255) } CompressionMethod;
3649 struct {
3650 ProtocolVersion client_version;
3651 Random random;
3652 SessionID session_id;
3653 CipherSuite cipher_suites<2..2^16-2>;
3654 CompressionMethod compression_methods<1..2^8-1>;
3655 select (extensions_present) {
3656 case false:
3657 struct {};
3658 case true:
3659 Extension extensions<0..2^16-1>;
3660 };
3661 } ClientHello;
3663 struct {
3664 ProtocolVersion server_version;
3665 Random random;
3666 SessionID session_id;
3667 CipherSuite cipher_suite;
3668 CompressionMethod compression_method;
3669 select (extensions_present) {
3670 case false:
3671 struct {};
3672 case true:
3673 Extension extensions<0..2^16-1>;
3674 };
3675 } ServerHello;
3677 struct {
3678 ExtensionType extension_type;
3679 opaque extension_data<0..2^16-1>;
3680 } Extension;
3682 enum {
3683 signature_algorithms(TBD-BY-IANA), (65535)
3684 } ExtensionType;
3686 enum{
3687 none(0), md5(1), sha1(2), sha256(3), sha384(4),
3688 sha512(5), (255)
3689 } HashAlgorithm;
3694 Dierks & Rescorla Standards Track [Page 66]
3695 \f
3696 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3699 enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm;
3701 struct {
3702 HashAlgorithm hash;
3703 SignatureAlgorithm signature;
3704 } SignatureAndHashAlgorithm;
3706 SignatureAndHashAlgorithm
3707 supported_signature_algorithms<2..2^16-1>;
3709 A.4.2. Server Authentication and Key Exchange Messages
3711 opaque ASN.1Cert<2^24-1>;
3713 struct {
3714 ASN.1Cert certificate_list<0..2^24-1>;
3715 } Certificate;
3717 enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
3719 struct {
3720 opaque dh_p<1..2^16-1>;
3721 opaque dh_g<1..2^16-1>;
3722 opaque dh_Ys<1..2^16-1>;
3723 } ServerDHParams;
3725 struct {
3726 select (KeyExchangeAlgorithm) {
3727 case diffie_hellman:
3728 ServerDHParams params;
3729 Signature signed_params;
3730 }
3731 } ServerKeyExchange;
3733 struct {
3734 select (KeyExchangeAlgorithm) {
3735 case diffie_hellman:
3736 ServerDHParams params;
3737 };
3738 } ServerParams;
3740 struct {
3741 select (SignatureAlgorithm) {
3742 case anonymous: struct { };
3743 case rsa:
3744 SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
3745 digitally-signed struct {
3746 opaque hash[Hash.length];
3750 Dierks & Rescorla Standards Track [Page 67]
3751 \f
3752 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3755 };
3756 case dsa:
3757 SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
3758 digitally-signed struct {
3759 opaque hash[Hash.length];
3760 };
3761 };
3762 };
3763 } Signature;
3765 enum {
3766 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
3767 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
3768 fortezza_dms_RESERVED(20),
3769 (255)
3770 } ClientCertificateType;
3772 opaque DistinguishedName<1..2^16-1>;
3774 struct {
3775 ClientCertificateType certificate_types<1..2^8-1>;
3776 DistinguishedName certificate_authorities<0..2^16-1>;
3777 } CertificateRequest;
3779 struct { } ServerHelloDone;
3781 A.4.3. Client Authentication and Key Exchange Messages
3783 struct {
3784 select (KeyExchangeAlgorithm) {
3785 case rsa: EncryptedPreMasterSecret;
3786 case diffie_hellman: ClientDiffieHellmanPublic;
3787 } exchange_keys;
3788 } ClientKeyExchange;
3790 struct {
3791 ProtocolVersion client_version;
3792 opaque random[46];
3793 } PreMasterSecret;
3795 struct {
3796 public-key-encrypted PreMasterSecret pre_master_secret;
3797 } EncryptedPreMasterSecret;
3799 enum { implicit, explicit } PublicValueEncoding;
3801 struct {
3802 select (PublicValueEncoding) {
3806 Dierks & Rescorla Standards Track [Page 68]
3807 \f
3808 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3811 case implicit: struct {};
3812 case explicit: opaque DH_Yc<1..2^16-1>;
3813 } dh_public;
3814 } ClientDiffieHellmanPublic;
3816 struct {
3817 Signature signature;
3818 } CertificateVerify;
3820 A.4.4. Handshake Finalization Message
3822 struct {
3823 opaque verify_data[verify_data_length];
3824 } Finished;
3826 A.5. The CipherSuite
3828 The following values define the CipherSuite codes used in the client
3829 hello and server hello messages.
3831 A CipherSuite defines a cipher specification supported in TLS Version
3832 1.2.
3834 TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
3835 TLS connection during the first handshake on that channel, but MUST
3836 not be negotiated, as it provides no more protection than an
3837 unsecured connection.
3839 CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
3841 The following CipherSuite definitions require that the server provide
3842 an RSA certificate that can be used for key exchange. The server may
3843 request either any signature-capable certificate in the certificate
3844 request message.
3846 CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
3847 CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
3848 CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
3849 CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
3850 CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
3851 CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F };
3852 CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
3854 The following CipherSuite definitions are used for server-
3855 authenticated (and optionally client-authenticated) Diffie-Hellman.
3856 DH denotes cipher suites in which the server's certificate contains
3857 the Diffie-Hellman parameters signed by the certificate authority
3858 (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
3862 Dierks & Rescorla Standards Track [Page 69]
3863 \f
3864 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3867 parameters are signed by a a signature-capable certificate, which has
3868 been signed by the CA. The signing algorithm used is specified after
3869 the DH or DHE parameter. The server can request any signature-capable
3870 certificate from the client for client authentication or it may
3871 request a Diffie-Hellman certificate. Any Diffie-Hellman certificate
3872 provided by the client must use the parameters (group and generator)
3873 described by the server.
3876 CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
3877 CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
3878 CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
3879 CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
3880 CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 };
3881 CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 };
3882 CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 };
3883 CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 };
3884 CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 };
3885 CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 };
3886 CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 };
3887 CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 };
3889 The following cipher suites are used for completely anonymous Diffie-
3890 Hellman communications in which neither party is authenticated. Note
3891 that this mode is vulnerable to man-in-the-middle attacks. Using
3892 this mode therefore is of limited use: These ciphersuites MUST NOT be
3893 used by TLS 1.2 implementations unless the application layer has
3894 specifically requested to allow anonymous key exchange. (Anonymous
3895 key exchange may sometimes be acceptable, for example, to support
3896 opportunistic encryption when no set-up for authentication is in
3897 place, or when TLS is used as part of more complex security protocols
3898 that have other means to ensure authentication.)
3900 CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
3901 CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
3902 CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 };
3903 CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A };
3905 Note that using non-anonymous key exchange without actually verifying
3906 the key exchange is essentially equivalent to anonymous key exchange,
3907 and the same precautions apply. While non-anonymous key exchange
3908 will generally involve a higher computational and communicational
3909 cost than anonymous key exchange, it may be in the interest of
3910 interoperability not to disable non-anonymous key exchange when the
3911 application layer is allowing anonymous key exchange.
3913 SSLv3, TLS 1.0, and TLS 1.1 supported DES and IDEA. DES had a 56-bit
3914 key which is too weak for modern use. Triple-DES (3DES) has an
3918 Dierks & Rescorla Standards Track [Page 70]
3919 \f
3920 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3923 effective key strength of 112 bits and is still acceptable. IDEA and
3924 is no longer in wide use. Cipher suites using RC2, DES, and IDEA are
3925 hereby deprecated for TLS 1.2. TLS 1.2 implementations MUST NOT
3926 negotiate these cipher suites in TLS 1.2 mode. However, for backward
3927 compatibility they may be offered in the ClientHello for use with TLS
3928 1.0 or SSLv3 only servers. TLS 1.2 clients MUST check that the server
3929 did not choose one of these cipher suites during the handshake. These
3930 ciphersuites are listed below for informational purposes and to
3931 reserve the numbers.
3933 CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
3934 CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
3935 CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
3936 CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
3937 CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
3938 CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
3939 CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
3942 When SSLv3 and TLS 1.0 were designed, the United States restricted
3943 the export of cryptographic software containing certain strong
3944 encryption algorithms. A series of cipher suites were designed to
3945 operate at reduced key lengths in order to comply with those
3946 regulations. Due to advances in computer performance, these
3947 algorithms are now unacceptably weak and export restrictions have
3948 since been loosened. TLS 1.2 implementations MUST NOT negotiate these
3949 cipher suites in TLS 1.2 mode. However, for backward compatibility
3950 they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
3951 only servers. TLS 1.2 clients MUST check that the server did not
3952 choose one of these cipher suites during the handshake. These
3953 ciphersuites are listed below for informational purposes and to
3954 reserve the numbers.
3956 CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
3957 CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
3958 CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
3959 CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
3960 CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
3961 CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
3962 CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
3963 CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
3964 CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
3966 New cipher suite values are assigned by IANA as described in Section
3967 12.
3969 Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
3970 reserved to avoid collision with Fortezza-based cipher suites in SSL
3974 Dierks & Rescorla Standards Track [Page 71]
3975 \f
3976 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
3979 3.
3981 A.6. The Security Parameters
3983 These security parameters are determined by the TLS Handshake
3984 Protocol and provided as parameters to the TLS Record Layer in order
3985 to initialize a connection state. SecurityParameters includes:
3987 enum { null(0), (255) } CompressionMethod;
3989 enum { server, client } ConnectionEnd;
3991 enum { tls_prf_sha256 } PRFAlgorithm;
3993 enum { null, rc4, 3des, aes }
3994 BulkCipherAlgorithm;
3996 enum { stream, block, aead } CipherType;
3998 enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384,
3999 hmac_sha512} MACAlgorithm;
4001 /* The algorithms specified in CompressionMethod,
4002 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
4004 struct {
4005 ConnectionEnd entity;
4006 PRFAlgorithm prf_algorithm;
4007 BulkCipherAlgorithm bulk_cipher_algorithm;
4008 CipherType cipher_type;
4009 uint8 enc_key_length;
4010 uint8 block_length;
4011 uint8 fixed_iv_length;
4012 uint8 record_iv_length;
4013 MACAlgorithm mac_algorithm;
4014 uint8 mac_length;
4015 uint8 mac_key_length;
4016 CompressionMethod compression_algorithm;
4017 opaque master_secret[48];
4018 opaque client_random[32];
4019 opaque server_random[32];
4020 } SecurityParameters;
4030 Dierks & Rescorla Standards Track [Page 72]
4031 \f
4032 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4035 Appendix B. Glossary
4037 Advanced Encryption Standard (AES)
4038 AES is a widely used symmetric encryption algorithm. AES is a
4039 block cipher with a 128, 192, or 256 bit keys and a 16 byte block
4040 size. [AES] TLS currently only supports the 128 and 256 bit key
4041 sizes.
4043 application protocol
4044 An application protocol is a protocol that normally layers
4045 directly on top of the transport layer (e.g., TCP/IP). Examples
4046 include HTTP, TELNET, FTP, and SMTP.
4048 asymmetric cipher
4049 See public key cryptography.
4051 authenticated encryption with additional data (AEAD)
4052 A symmetric encryption algorithm that simultaneously provides
4053 confidentiality and message integrity.
4055 authentication
4056 Authentication is the ability of one entity to determine the
4057 identity of another entity.
4059 block cipher
4060 A block cipher is an algorithm that operates on plaintext in
4061 groups of bits, called blocks. 64 bits is a common block size.
4063 bulk cipher
4064 A symmetric encryption algorithm used to encrypt large quantities
4065 of data.
4067 cipher block chaining (CBC)
4068 CBC is a mode in which every plaintext block encrypted with a
4069 block cipher is first exclusive-ORed with the previous ciphertext
4070 block (or, in the case of the first block, with the initialization
4071 vector). For decryption, every block is first decrypted, then
4072 exclusive-ORed with the previous ciphertext block (or IV).
4074 certificate
4075 As part of the X.509 protocol (a.k.a. ISO Authentication
4076 framework), certificates are assigned by a trusted Certificate
4077 Authority and provide a strong binding between a party's identity
4078 or some other attributes and its public key.
4080 client
4081 The application entity that initiates a TLS connection to a
4082 server. This may or may not imply that the client initiated the
4086 Dierks & Rescorla Standards Track [Page 73]
4087 \f
4088 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4091 underlying transport connection. The primary operational
4092 difference between the server and client is that the server is
4093 generally authenticated, while the client is only optionally
4094 authenticated.
4096 client write key
4097 The key used to encrypt data written by the client.
4099 client write MAC key
4100 The secret data used to authenticate data written by the client.
4102 connection
4103 A connection is a transport (in the OSI layering model definition)
4104 that provides a suitable type of service. For TLS, such
4105 connections are peer-to-peer relationships. The connections are
4106 transient. Every connection is associated with one session.
4108 Data Encryption Standard
4109 DES is a very widely used symmetric encryption algorithm. DES is a
4110 block cipher with a 56 bit key and an 8 byte block size. Note that
4111 in TLS, for key generation purposes, DES is treated as having an 8
4112 byte key length (64 bits), but it still only provides 56 bits of
4113 protection. (The low bit of each key byte is presumed to be set to
4114 produce odd parity in that key byte.) DES can also be operated in
4115 a mode where three independent keys and three encryptions are used
4116 for each block of data; this uses 168 bits of key (24 bytes in the
4117 TLS key generation method) and provides the equivalent of 112 bits
4118 of security. [DES], [3DES]
4120 Digital Signature Standard (DSS)
4121 A standard for digital signing, including the Digital Signing
4122 Algorithm, approved by the National Institute of Standards and
4123 Technology, defined in NIST FIPS PUB 186, "Digital Signature
4124 Standard", published May, 1994 by the U.S. Dept. of Commerce.
4125 [DSS]
4127 digital signatures
4128 Digital signatures utilize public key cryptography and one-way
4129 hash functions to produce a signature of the data that can be
4130 authenticated, and is difficult to forge or repudiate.
4132 handshake
4133 An initial negotiation between client and server that establishes
4134 the parameters of their transactions.
4136 Initialization Vector (IV)
4137 When a block cipher is used in CBC mode, the initialization vector
4138 is exclusive-ORed with the first plaintext block prior to
4142 Dierks & Rescorla Standards Track [Page 74]
4143 \f
4144 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4147 encryption.
4149 IDEA
4150 A 64-bit block cipher designed by Xuejia Lai and James Massey.
4151 [IDEA]
4153 Message Authentication Code (MAC)
4154 A Message Authentication Code is a one-way hash computed from a
4155 message and some secret data. It is difficult to forge without
4156 knowing the secret data. Its purpose is to detect if the message
4157 has been altered.
4159 master secret
4160 Secure secret data used for generating encryption keys, MAC
4161 secrets, and IVs.
4163 MD5
4164 MD5 is a secure hashing function that converts an arbitrarily long
4165 data stream into a hash of fixed size (16 bytes). [MD5]
4167 public key cryptography
4168 A class of cryptographic techniques employing two-key ciphers.
4169 Messages encrypted with the public key can only be decrypted with
4170 the associated private key. Conversely, messages signed with the
4171 private key can be verified with the public key.
4173 one-way hash function
4174 A one-way transformation that converts an arbitrary amount of data
4175 into a fixed-length hash. It is computationally hard to reverse
4176 the transformation or to find collisions. MD5 and SHA are examples
4177 of one-way hash functions.
4179 RC2
4180 A block cipher developed by Ron Rivest, described in [RC2].
4182 RC4
4183 A stream cipher invented by Ron Rivest. A compatible cipher is
4184 described in [SCH].
4186 RSA
4187 A very widely used public-key algorithm that can be used for
4188 either encryption or digital signing. [RSA]
4190 server
4191 The server is the application entity that responds to requests for
4192 connections from clients. See also under client.
4198 Dierks & Rescorla Standards Track [Page 75]
4199 \f
4200 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4203 session
4204 A TLS session is an association between a client and a server.
4205 Sessions are created by the handshake protocol. Sessions define a
4206 set of cryptographic security parameters that can be shared among
4207 multiple connections. Sessions are used to avoid the expensive
4208 negotiation of new security parameters for each connection.
4210 session identifier
4211 A session identifier is a value generated by a server that
4212 identifies a particular session.
4214 server write key
4215 The key used to encrypt data written by the server.
4217 server write MAC key
4218 The secret data used to authenticate data written by the server.
4220 SHA
4221 The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
4222 produces a 20-byte output. Note that all references to SHA
4223 actually use the modified SHA-1 algorithm. [SHA]
4225 SSL
4226 Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
4227 SSL Version 3.0
4229 stream cipher
4230 An encryption algorithm that converts a key into a
4231 cryptographically strong keystream, which is then exclusive-ORed
4232 with the plaintext.
4234 symmetric cipher
4235 See bulk cipher.
4237 Transport Layer Security (TLS)
4238 This protocol; also, the Transport Layer Security working group of
4239 the Internet Engineering Task Force (IETF). See "Comments" at the
4240 end of this document.
4254 Dierks & Rescorla Standards Track [Page 76]
4255 \f
4256 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4259 Appendix C. CipherSuite Definitions
4261 CipherSuite Key Cipher Hash
4262 Exchange
4264 TLS_NULL_WITH_NULL_NULL NULL NULL NULL
4265 TLS_RSA_WITH_NULL_MD5 RSA NULL MD5
4266 TLS_RSA_WITH_NULL_SHA RSA NULL SHA
4267 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
4268 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
4269 TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
4270 TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA
4271 TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA
4272 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
4273 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
4274 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
4275 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
4276 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
4277 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
4278 TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA
4279 TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA
4280 TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA
4281 TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA
4282 TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA
4283 TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA
4284 TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA
4285 TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA
4286 TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA
4287 TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA
4290 Key Expanded IV Block
4291 Cipher Type Material Key Material Size Size
4293 NULL Stream 0 0 0 N/A
4294 RC4_128 Stream 16 16 0 N/A
4295 3DES_EDE_CBC Block 24 24 8 8
4297 Type
4298 Indicates whether this is a stream cipher or a block cipher
4299 running in CBC mode.
4301 Key Material
4302 The number of bytes from the key_block that are used for
4303 generating the write keys.
4305 Expanded Key Material
4306 The number of bytes actually fed into the encryption algorithm.
4310 Dierks & Rescorla Standards Track [Page 77]
4311 \f
4312 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4315 IV Size
4316 The amount of data needed to be generated for the initialization
4317 vector. Zero for stream ciphers; equal to the block size for block
4318 ciphers (this is equal to SecurityParameters.record_iv_length).
4320 Block Size
4321 The amount of data a block cipher enciphers in one chunk; a block
4322 cipher running in CBC mode can only encrypt an even multiple of
4323 its block size.
4366 Dierks & Rescorla Standards Track [Page 78]
4367 \f
4368 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4371 Appendix D. Implementation Notes
4373 The TLS protocol cannot prevent many common security mistakes. This
4374 section provides several recommendations to assist implementors.
4376 D.1 Random Number Generation and Seeding
4378 TLS requires a cryptographically secure pseudorandom number generator
4379 (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs
4380 based on secure hash operations, most notably SHA-1, are acceptable,
4381 but cannot provide more security than the size of the random number
4382 generator state.
4384 To estimate the amount of seed material being produced, add the
4385 number of bits of unpredictable information in each seed byte. For
4386 example, keystroke timing values taken from a PC compatible's 18.2 Hz
4387 timer provide 1 or 2 secure bits each, even though the total size of
4388 the counter value is 16 bits or more. Seeding a 128-bit PRNG would
4389 thus require approximately 100 such timer values.
4391 [RANDOM] provides guidance on the generation of random values.
4393 D.2 Certificates and Authentication
4395 Implementations are responsible for verifying the integrity of
4396 certificates and should generally support certificate revocation
4397 messages. Certificates should always be verified to ensure proper
4398 signing by a trusted Certificate Authority (CA). The selection and
4399 addition of trusted CAs should be done very carefully. Users should
4400 be able to view information about the certificate and root CA.
4402 D.3 CipherSuites
4404 TLS supports a range of key sizes and security levels, including some
4405 that provide no or minimal security. A proper implementation will
4406 probably not support many cipher suites. For instance, anonymous
4407 Diffie-Hellman is strongly discouraged because it cannot prevent man-
4408 in-the-middle attacks. Applications should also enforce minimum and
4409 maximum key sizes. For example, certificate chains containing 512-bit
4410 RSA keys or signatures are not appropriate for high-security
4411 applications.
4413 D.4 Implementation Pitfalls
4415 Implementation experience has shown that certain parts of earlier TLS
4416 specifications are not easy to understand, and have been a source of
4417 interoperability and security problems. Many of these areas have been
4418 clarified in this document, but this appendix contains a short list
4422 Dierks & Rescorla Standards Track [Page 79]
4423 \f
4424 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4427 of the most important things that require special attention from
4428 implementors.
4430 TLS protocol issues:
4432 - Do you correctly handle handshake messages that are fragmented
4433 to multiple TLS records (see Section 6.2.1)? Including corner
4434 cases like a ClientHello that is split to several small
4435 fragments?
4437 - Do you ignore the TLS record layer version number in all TLS
4438 records before ServerHello (see Appendix E.1)?
4440 - Do you handle TLS extensions in ClientHello correctly,
4441 including omitting the extensions field completely?
4443 - Do you support renegotiation, both client and server initiated?
4444 While renegotiation is an optional feature, supporting
4445 it is highly recommended.
4447 - When the server has requested a client certificate, but no
4448 suitable certificate is available, do you correctly send
4449 an empty Certificate message, instead of omitting the whole
4450 message (see Section 7.4.6)?
4452 Cryptographic details:
4454 - In RSA-encrypted Premaster Secret, do you correctly send and
4455 verify the version number? When an error is encountered, do
4456 you continue the handshake to avoid the Bleichenbacher
4457 attack (see Section 7.4.7.1)?
4459 - What countermeasures do you use to prevent timing attacks against
4460 RSA decryption and signing operations (see Section 7.4.7.1)?
4462 - When verifying RSA signatures, do you accept both NULL and
4463 missing parameters (see Section 4.7)? Do you verify that the
4464 RSA padding doesn't have additional data after the hash value?
4465 [FI06]
4467 - When using Diffie-Hellman key exchange, do you correctly strip
4468 leading zero bytes from the negotiated key (see Section 8.1.2)?
4470 - Does your TLS client check that the Diffie-Hellman parameters
4471 sent by the server are acceptable (see Section F.1.1.3)?
4473 - How do you generate unpredictable IVs for CBC mode ciphers
4474 (see Section 6.2.3.2)?
4478 Dierks & Rescorla Standards Track [Page 80]
4479 \f
4480 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4483 - How do you address CBC mode timing attacks (Section 6.2.3.2)?
4485 - Do you use a strong and, most importantly, properly seeded
4486 random number generator (see Appendix D.1) for generating the
4487 premaster secret (for RSA key exchange), Diffie-Hellman private
4488 values, the DSA "k" parameter, and other security-critical
4489 values?
4534 Dierks & Rescorla Standards Track [Page 81]
4535 \f
4536 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4539 Appendix E. Backward Compatibility
4541 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
4543 Since there are various versions of TLS (1.0, 1.1, 1.2, and any
4544 future versions) and SSL (2.0 and 3.0), means are needed to negotiate
4545 the specific protocol version to use. The TLS protocol provides a
4546 built-in mechanism for version negotiation so as not to bother other
4547 protocol components with the complexities of version selection.
4549 TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
4550 compatible ClientHello messages; thus, supporting all of them is
4551 relatively easy. Similarly, servers can easily handle clients trying
4552 to use future versions of TLS as long as the ClientHello format
4553 remains compatible, and the client support the highest protocol
4554 version available in the server.
4556 A TLS 1.2 client who wishes to negotiate with such older servers will
4557 send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
4558 ClientHello.client_version. If the server does not support this
4559 version, it will respond with ServerHello containing an older version
4560 number. If the client agrees to use this version, the negotiation
4561 will proceed as appropriate for the negotiated protocol.
4563 If the version chosen by the server is not supported by the client
4564 (or not acceptable), the client MUST send a "protocol_version" alert
4565 message and close the connection.
4567 If a TLS server receives a ClientHello containing a version number
4568 greater than the highest version supported by the server, it MUST
4569 reply according to the highest version supported by the server.
4571 A TLS server can also receive a ClientHello containing version number
4572 smaller than the highest supported version. If the server wishes to
4573 negotiate with old clients, it will proceed as appropriate for the
4574 highest version supported by the server that is not greater than
4575 ClientHello.client_version. For example, if the server supports TLS
4576 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
4577 proceed with a TLS 1.0 ServerHello. If server supports (or is willing
4578 to use) only versions greater than client_version, it MUST send a
4579 "protocol_version" alert message and close the connection.
4581 Whenever a client already knows the highest protocol known to a
4582 server (for example, when resuming a session), it SHOULD initiate the
4583 connection in that native protocol.
4585 Note: some server implementations are known to implement version
4586 negotiation incorrectly. For example, there are buggy TLS 1.0 servers
4590 Dierks & Rescorla Standards Track [Page 82]
4591 \f
4592 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4595 that simply close the connection when the client offers a version
4596 newer than TLS 1.0. Also, it is known that some servers will refuse
4597 connection if any TLS extensions are included in ClientHello.
4598 Interoperability with such buggy servers is a complex topic beyond
4599 the scope of this document, and may require multiple connection
4600 attempts by the client.
4602 Earlier versions of the TLS specification were not fully clear on
4603 what the record layer version number (TLSPlaintext.version) should
4604 contain when sending ClientHello (i.e., before it is known which
4605 version of the protocol will be employed). Thus, TLS servers
4606 compliant with this specification MUST accept any value {03,XX} as
4607 the record layer version number for ClientHello.
4609 TLS clients that wish to negotiate with older servers MAY send any
4610 value {03,XX} as the record layer version number. Typical values
4611 would be {03,00}, the lowest version number supported by the client,
4612 and the value of ClientHello.client_version. No single value will
4613 guarantee interoperability with all old servers, but this is a
4614 complex topic beyond the scope of this document.
4616 E.2 Compatibility with SSL 2.0
4618 TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
4619 version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST
4620 contain the same version number as would be used for ordinary
4621 ClientHello, and MUST encode the supported TLS ciphersuites in the
4622 CIPHER-SPECS-DATA field as described below.
4624 Warning: The ability to send version 2.0 CLIENT-HELLO messages will
4625 be phased out with all due haste, since the newer ClientHello format
4626 provides better mechanisms for moving to newer versions and
4627 negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0.
4629 However, even TLS servers that do not support SSL 2.0 MAY accept
4630 version 2.0 CLIENT-HELLO messages. The message is presented below in
4631 sufficient detail for TLS server implementors; the true definition is
4632 still assumed to be [SSL2].
4634 For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
4635 way as a ClientHello with a "null" compression method and no
4636 extensions. Note that this message MUST be sent directly on the wire,
4637 not wrapped as a TLS record. For the purposes of calculating Finished
4638 and CertificateVerify, the msg_length field is not considered to be a
4639 part of the handshake message.
4641 uint8 V2CipherSpec[3];
4646 Dierks & Rescorla Standards Track [Page 83]
4647 \f
4648 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4651 struct {
4652 uint16 msg_length;
4653 uint8 msg_type;
4654 Version version;
4655 uint16 cipher_spec_length;
4656 uint16 session_id_length;
4657 uint16 challenge_length;
4658 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
4659 opaque session_id[V2ClientHello.session_id_length];
4660 opaque challenge[V2ClientHello.challenge_length;
4661 } V2ClientHello;
4663 msg_length
4664 The highest bit MUST be 1; the remaining bits contain the length
4665 of the following data in bytes.
4667 msg_type
4668 This field, in conjunction with the version field, identifies a
4669 version 2 client hello message. The value MUST be one (1).
4671 version
4672 Equal to ClientHello.client_version.
4674 cipher_spec_length
4675 This field is the total length of the field cipher_specs. It
4676 cannot be zero and MUST be a multiple of the V2CipherSpec length
4677 (3).
4679 session_id_length
4680 This field MUST have a value of zero for a client that claims to
4681 support TLS 1.2.
4683 challenge_length
4684 The length in bytes of the client's challenge to the server to
4685 authenticate itself. Historically, permissible values are between
4686 16 and 32 bytes inclusive. When using the SSLv2 backward
4687 compatible handshake the client SHOULD use a 32 byte challenge.
4689 cipher_specs
4690 This is a list of all CipherSpecs the client is willing and able
4691 to use. In addition to the 2.0 cipher specs defined in [SSL2],
4692 this includes the TLS cipher suites normally sent in
4693 ClientHello.cipher_suites, each cipher suite prefixed by a zero
4694 byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as
4695 {0x00,0x00,0x0A}.
4697 session_id
4698 This field MUST be empty.
4702 Dierks & Rescorla Standards Track [Page 84]
4703 \f
4704 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4707 challenge
4708 Corresponds to ClientHello.random. If the challenge length is less
4709 than 32, the TLS server will pad the data with leading (note: not
4710 trailing) zero bytes to make it 32 bytes long.
4712 Note: Requests to resume a TLS session MUST use a TLS client hello.
4714 E.3. Avoiding Man-in-the-Middle Version Rollback
4716 When TLS clients fall back to Version 2.0 compatibility mode, they
4717 MUST use special PKCS#1 block formatting. This is done so that TLS
4718 servers will reject Version 2.0 sessions with TLS-capable clients.
4720 When a client negotiates SSL 2.0 but also supports TLS, it MUST set
4721 the right-hand (least-significant) 8 random bytes of the PKCS padding
4722 (not including the terminal null of the padding) for the RSA
4723 encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
4724 to 0x03 (the other padding bytes are random).
4726 When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
4727 decrypting the ENCRYPTED-KEY-DATA field, check that these eight
4728 padding bytes are 0x03. If they are not, the server SHOULD generate a
4729 random value for SECRET-KEY-DATA, and continue the handshake (which
4730 will eventually fail since the keys will not match). Note that
4731 reporting the error situation to the client could make the server
4732 vulnerable to attacks described in [BLEI].
4758 Dierks & Rescorla Standards Track [Page 85]
4759 \f
4760 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4763 Appendix F. Security Analysis
4765 The TLS protocol is designed to establish a secure connection between
4766 a client and a server communicating over an insecure channel. This
4767 document makes several traditional assumptions, including that
4768 attackers have substantial computational resources and cannot obtain
4769 secret information from sources outside the protocol. Attackers are
4770 assumed to have the ability to capture, modify, delete, replay, and
4771 otherwise tamper with messages sent over the communication channel.
4772 This appendix outlines how TLS has been designed to resist a variety
4773 of attacks.
4775 F.1. Handshake Protocol
4777 The handshake protocol is responsible for selecting a CipherSpec and
4778 generating a Master Secret, which together comprise the primary
4779 cryptographic parameters associated with a secure session. The
4780 handshake protocol can also optionally authenticate parties who have
4781 certificates signed by a trusted certificate authority.
4783 F.1.1. Authentication and Key Exchange
4785 TLS supports three authentication modes: authentication of both
4786 parties, server authentication with an unauthenticated client, and
4787 total anonymity. Whenever the server is authenticated, the channel is
4788 secure against man-in-the-middle attacks, but completely anonymous
4789 sessions are inherently vulnerable to such attacks. Anonymous
4790 servers cannot authenticate clients. If the server is authenticated,
4791 its certificate message must provide a valid certificate chain
4792 leading to an acceptable certificate authority. Similarly,
4793 authenticated clients must supply an acceptable certificate to the
4794 server. Each party is responsible for verifying that the other's
4795 certificate is valid and has not expired or been revoked.
4797 The general goal of the key exchange process is to create a
4798 pre_master_secret known to the communicating parties and not to
4799 attackers. The pre_master_secret will be used to generate the
4800 master_secret (see Section 8.1). The master_secret is required to
4801 generate the finished messages, encryption keys, and MAC keys (see
4802 Sections 7.4.9 and 6.3). By sending a correct finished message,
4803 parties thus prove that they know the correct pre_master_secret.
4805 F.1.1.1. Anonymous Key Exchange
4807 Completely anonymous sessions can be established using Diffie-Hellman
4808 for key exchange. The server's public parameters are contained in the
4809 server key exchange message and the client's are sent in the client
4810 key exchange message. Eavesdroppers who do not know the private
4814 Dierks & Rescorla Standards Track [Page 86]
4815 \f
4816 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4819 values should not be able to find the Diffie-Hellman result (i.e. the
4820 pre_master_secret).
4822 Warning: Completely anonymous connections only provide protection
4823 against passive eavesdropping. Unless an independent tamper-proof
4824 channel is used to verify that the finished messages were not
4825 replaced by an attacker, server authentication is required in
4826 environments where active man-in-the-middle attacks are a concern.
4828 F.1.1.2. RSA Key Exchange and Authentication
4830 With RSA, key exchange and server authentication are combined. The
4831 public key is contained in the server's certificate. Note that
4832 compromise of the server's static RSA key results in a loss of
4833 confidentiality for all sessions protected under that static key. TLS
4834 users desiring Perfect Forward Secrecy should use DHE cipher suites.
4835 The damage done by exposure of a private key can be limited by
4836 changing one's private key (and certificate) frequently.
4838 After verifying the server's certificate, the client encrypts a
4839 pre_master_secret with the server's public key. By successfully
4840 decoding the pre_master_secret and producing a correct finished
4841 message, the server demonstrates that it knows the private key
4842 corresponding to the server certificate.
4844 When RSA is used for key exchange, clients are authenticated using
4845 the certificate verify message (see Section 7.4.8). The client signs
4846 a value derived from all preceding handshake messages. These
4847 handshake messages include the server certificate, which binds the
4848 signature to the server, and ServerHello.random, which binds the
4849 signature to the current handshake process.
4851 F.1.1.3. Diffie-Hellman Key Exchange with Authentication
4853 When Diffie-Hellman key exchange is used, the server can either
4854 supply a certificate containing fixed Diffie-Hellman parameters or
4855 use the server key exchange message to send a set of temporary
4856 Diffie-Hellman parameters signed with a DSS or RSA certificate.
4857 Temporary parameters are hashed with the hello.random values before
4858 signing to ensure that attackers do not replay old parameters. In
4859 either case, the client can verify the certificate or signature to
4860 ensure that the parameters belong to the server.
4862 If the client has a certificate containing fixed Diffie-Hellman
4863 parameters, its certificate contains the information required to
4864 complete the key exchange. Note that in this case the client and
4865 server will generate the same Diffie-Hellman result (i.e.,
4866 pre_master_secret) every time they communicate. To prevent the
4870 Dierks & Rescorla Standards Track [Page 87]
4871 \f
4872 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4875 pre_master_secret from staying in memory any longer than necessary,
4876 it should be converted into the master_secret as soon as possible.
4877 Client Diffie-Hellman parameters must be compatible with those
4878 supplied by the server for the key exchange to work.
4880 If the client has a standard DSS or RSA certificate or is
4881 unauthenticated, it sends a set of temporary parameters to the server
4882 in the client key exchange message, then optionally uses a
4883 certificate verify message to authenticate itself.
4885 If the same DH keypair is to be used for multiple handshakes, either
4886 because the client or server has a certificate containing a fixed DH
4887 keypair or because the server is reusing DH keys, care must be taken
4888 to prevent small subgroup attacks. Implementations SHOULD follow the
4889 guidelines found in [SUBGROUP].
4891 Small subgroup attacks are most easily avoided by using one of the
4892 DHE ciphersuites and generating a fresh DH private key (X) for each
4893 handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
4894 computed very quickly, therefore the performance cost is minimized.
4895 Additionally, using a fresh key for each handshake provides Perfect
4896 Forward Secrecy. Implementations SHOULD generate a new X for each
4897 handshake when using DHE ciphersuites.
4899 Because TLS allows the server to provide arbitrary DH groups, the
4900 client should verify that the DH group is of suitable size as defined
4901 by local policy. The client SHOULD also verify that the DH public
4902 exponent appears to be of adequate size. [KEYSIZ] provides a useful
4903 guide to the strength of various group sizes. The server MAY choose
4904 to assist the client by providing a known group, such as those
4905 defined in [IKEALG] or [MODP]. These can be verified by simple
4906 comparison.
4908 F.1.2. Version Rollback Attacks
4910 Because TLS includes substantial improvements over SSL Version 2.0,
4911 attackers may try to make TLS-capable clients and servers fall back
4912 to Version 2.0. This attack can occur if (and only if) two TLS-
4913 capable parties use an SSL 2.0 handshake.
4915 Although the solution using non-random PKCS #1 block type 2 message
4916 padding is inelegant, it provides a reasonably secure way for Version
4917 3.0 servers to detect the attack. This solution is not secure against
4918 attackers who can brute force the key and substitute a new ENCRYPTED-
4919 KEY-DATA message containing the same key (but with normal padding)
4920 before the application specified wait threshold has expired. Altering
4921 the padding of the least significant 8 bytes of the PKCS padding does
4922 not impact security for the size of the signed hashes and RSA key
4926 Dierks & Rescorla Standards Track [Page 88]
4927 \f
4928 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4931 lengths used in the protocol, since this is essentially equivalent to
4932 increasing the input block size by 8 bytes.
4934 F.1.3. Detecting Attacks Against the Handshake Protocol
4936 An attacker might try to influence the handshake exchange to make the
4937 parties select different encryption algorithms than they would
4938 normally chooses.
4940 For this attack, an attacker must actively change one or more
4941 handshake messages. If this occurs, the client and server will
4942 compute different values for the handshake message hashes. As a
4943 result, the parties will not accept each others' finished messages.
4944 Without the master_secret, the attacker cannot repair the finished
4945 messages, so the attack will be discovered.
4947 F.1.4. Resuming Sessions
4949 When a connection is established by resuming a session, new
4950 ClientHello.random and ServerHello.random values are hashed with the
4951 session's master_secret. Provided that the master_secret has not been
4952 compromised and that the secure hash operations used to produce the
4953 encryption keys and MAC keys are secure, the connection should be
4954 secure and effectively independent from previous connections.
4955 Attackers cannot use known encryption keys or MAC secrets to
4956 compromise the master_secret without breaking the secure hash
4957 operations.
4959 Sessions cannot be resumed unless both the client and server agree.
4960 If either party suspects that the session may have been compromised,
4961 or that certificates may have expired or been revoked, it should
4962 force a full handshake. An upper limit of 24 hours is suggested for
4963 session ID lifetimes, since an attacker who obtains a master_secret
4964 may be able to impersonate the compromised party until the
4965 corresponding session ID is retired. Applications that may be run in
4966 relatively insecure environments should not write session IDs to
4967 stable storage.
4969 F.2. Protecting Application Data
4971 The master_secret is hashed with the ClientHello.random and
4972 ServerHello.random to produce unique data encryption keys and MAC
4973 secrets for each connection.
4975 Outgoing data is protected with a MAC before transmission. To prevent
4976 message replay or modification attacks, the MAC is computed from the
4977 MAC key, the sequence number, the message length, the message
4978 contents, and two fixed character strings. The message type field is
4982 Dierks & Rescorla Standards Track [Page 89]
4983 \f
4984 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
4987 necessary to ensure that messages intended for one TLS Record Layer
4988 client are not redirected to another. The sequence number ensures
4989 that attempts to delete or reorder messages will be detected. Since
4990 sequence numbers are 64 bits long, they should never overflow.
4991 Messages from one party cannot be inserted into the other's output,
4992 since they use independent MAC keys. Similarly, the server-write and
4993 client-write keys are independent, so stream cipher keys are used
4994 only once.
4996 If an attacker does break an encryption key, all messages encrypted
4997 with it can be read. Similarly, compromise of a MAC key can make
4998 message modification attacks possible. Because MACs are also
4999 encrypted, message-alteration attacks generally require breaking the
5000 encryption algorithm as well as the MAC.
5002 Note: MAC keys may be larger than encryption keys, so messages can
5003 remain tamper resistant even if encryption keys are broken.
5005 F.3. Explicit IVs
5007 [CBCATT] describes a chosen plaintext attack on TLS that depends on
5008 knowing the IV for a record. Previous versions of TLS [TLS1.0] used
5009 the CBC residue of the previous record as the IV and therefore
5010 enabled this attack. This version uses an explicit IV in order to
5011 protect against this attack.
5013 F.4. Security of Composite Cipher Modes
5015 TLS secures transmitted application data via the use of symmetric
5016 encryption and authentication functions defined in the negotiated
5017 ciphersuite. The objective is to protect both the integrity and
5018 confidentiality of the transmitted data from malicious actions by
5019 active attackers in the network. It turns out that the order in
5020 which encryption and authentication functions are applied to the data
5021 plays an important role for achieving this goal [ENCAUTH].
5023 The most robust method, called encrypt-then-authenticate, first
5024 applies encryption to the data and then applies a MAC to the
5025 ciphertext. This method ensures that the integrity and
5026 confidentiality goals are obtained with ANY pair of encryption and
5027 MAC functions, provided that the former is secure against chosen
5028 plaintext attacks and that the MAC is secure against chosen-message
5029 attacks. TLS uses another method, called authenticate-then-encrypt,
5030 in which first a MAC is computed on the plaintext and then the
5031 concatenation of plaintext and MAC is encrypted. This method has
5032 been proven secure for CERTAIN combinations of encryption functions
5033 and MAC functions, but it is not guaranteed to be secure in general.
5034 In particular, it has been shown that there exist perfectly secure
5038 Dierks & Rescorla Standards Track [Page 90]
5039 \f
5040 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
5043 encryption functions (secure even in the information-theoretic sense)
5044 that combined with any secure MAC function, fail to provide the
5045 confidentiality goal against an active attack. Therefore, new
5046 ciphersuites and operation modes adopted into TLS need to be analyzed
5047 under the authenticate-then-encrypt method to verify that they
5048 achieve the stated integrity and confidentiality goals.
5050 Currently, the security of the authenticate-then-encrypt method has
5051 been proven for some important cases. One is the case of stream
5052 ciphers in which a computationally unpredictable pad of the length of
5053 the message, plus the length of the MAC tag, is produced using a
5054 pseudo-random generator and this pad is xor-ed with the concatenation
5055 of plaintext and MAC tag. The other is the case of CBC mode using a
5056 secure block cipher. In this case, security can be shown if one
5057 applies one CBC encryption pass to the concatenation of plaintext and
5058 MAC and uses a new, independent, and unpredictable IV for each new
5059 pair of plaintext and MAC. In versions of TLS prior to 1.1, CBC mode
5060 was used properly EXCEPT that it used a predictable IV in the form of
5061 the last block of the previous ciphertext. This made TLS open to
5062 chosen plaintext attacks. This version of the protocol is immune to
5063 those attacks. For exact details in the encryption modes proven
5064 secure, see [ENCAUTH].
5066 F.5 Denial of Service
5068 TLS is susceptible to a number of denial of service (DoS) attacks.
5069 In particular, an attacker who initiates a large number of TCP
5070 connections can cause a server to consume large amounts of CPU doing
5071 RSA decryption. However, because TLS is generally used over TCP, it
5072 is difficult for the attacker to hide his point of origin if proper
5073 TCP SYN randomization is used [SEQNUM] by the TCP stack.
5075 Because TLS runs over TCP, it is also susceptible to a number of
5076 denial of service attacks on individual connections. In particular,
5077 attackers can forge RSTs, thereby terminating connections, or forge
5078 partial TLS records, thereby causing the connection to stall. These
5079 attacks cannot in general be defended against by a TCP-using
5080 protocol. Implementors or users who are concerned with this class of
5081 attack should use IPsec AH [AH] or ESP [ESP].
5083 F.6 Final Notes
5085 For TLS to be able to provide a secure connection, both the client
5086 and server systems, keys, and applications must be secure. In
5087 addition, the implementation must be free of security errors.
5089 The system is only as strong as the weakest key exchange and
5090 authentication algorithm supported, and only trustworthy
5094 Dierks & Rescorla Standards Track [Page 91]
5095 \f
5096 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
5099 cryptographic functions should be used. Short public keys and
5100 anonymous servers should be used with great caution. Implementations
5101 and users must be careful when deciding which certificates and
5102 certificate authorities are acceptable; a dishonest certificate
5103 authority can do tremendous damage.
5105 Changes in This Version
5107 [RFC Editor: Please delete this]
5109 - SSLv2 backward compatibility downgraded to MAY
5111 - Altered DSA hash rules to more closely match FIPS186-3 and
5112 PKIX, plus remove OID restriction.
5114 - verify_length no longer in SecurityParameters
5116 - Moved/cleaned up cert selection text for server cert
5117 when signature_algorithms is not specified.
5119 - Other editorial changes.
5121 Normative References
5123 [AES] National Institute of Standards and Technology,
5124 "Specification for the Advanced Encryption Standard (AES)"
5125 FIPS 197. November 26, 2001.
5127 [3DES] National Institute of Standards and Technology,
5128 "Recommendation for the Triple Data Encryption Algorithm
5129 (TDEA) Block Cipher", NIST Special Publication 800-67, May
5130 2004.
5132 [DES] National Institute of Standards and Technology, "Data
5133 Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
5135 [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National
5136 Institute of Standards and Technology, U.S. Department of
5137 Commerce, 2000.
5139 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
5140 Hashing for Message Authentication", RFC 2104, February
5141 1997.
5143 [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
5144 Series in Information Processing, v. 1, Konstanz: Hartung-
5145 Gorre Verlag, 1992.
5150 Dierks & Rescorla Standards Track [Page 92]
5151 \f
5152 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
5155 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
5156 April 1992.
5158 [PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
5159 (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
5160 3447, February 2003.
5162 [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
5163 Public Key Infrastructure Certificate and Certificate
5164 Revocation List (CRL) Profile", RFC 3280, April 2002.
5166 [RC2] Rivest, R., "A Description of the RC2(r) Encryption
5167 Algorithm", RFC 2268, March 1998.
5169 [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
5170 and Source Code in C, 2nd ed.", Published by John Wiley &
5171 Sons, Inc. 1996.
5173 [SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National
5174 Institute of Standards and Technology, U.S. Department of
5175 Commerce., August 2001.
5177 [REQ] Bradner, S., "Key words for use in RFCs to Indicate
5178 Requirement Levels", BCP 14, RFC 2119, March 1997.
5180 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
5181 IANA Considerations Section in RFCs", BCP 25, RFC 2434,
5182 October 1998.
5184 Informative References
5186 [AEAD] Mcgrew, D., "Authenticated Encryption", February 2007,
5187 draft-mcgrew-auth-enc-02.txt.
5189 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC
5190 4302, December 2005.
5192 [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
5193 Protocols Based on RSA Encryption Standard PKCS #1" in
5194 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
5195 1-12, 1998.
5197 [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
5198 Problems and Countermeasures",
5199 http://www.openssl.org/~bodo/tls-cbc.txt.
5201 [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
5202 "Password Interception in a SSL/TLS Channel", Advances in
5206 Dierks & Rescorla Standards Track [Page 93]
5207 \f
5208 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
5211 Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
5213 [CCM] "NIST Special Publication 800-38C: The CCM Mode for
5214 Authentication and Confidentiality",
5215 http://csrc.nist.gov/publications/nistpubs/800-38C/
5216 SP800-38C.pdf
5218 [DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard,"
5219 National Institute of Standards and Technology, U.S.
5220 Department of Commerce, 2006.
5222 [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
5223 for Protecting Communications (Or: How Secure is SSL?)",
5224 Crypto 2001.
5226 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
5227 Payload (ESP)", RFC 4303, December 2005.
5229 [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on
5230 implementation error", ietf-openpgp@imc.org mailing list, 27
5231 August 2006, http://www.imc.org/ietf-openpgp/mail-
5232 archive/msg14307.html.
5234 [GCM] "NIST Special Publication 800-38D DRAFT (June, 2007):
5235 Recommendation for Block Cipher Modes of Operation:
5236 Galois/Counter Mode (GCM) and GMAC"
5238 [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
5239 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December
5240 2005.
5242 [KEYSIZ] Orman, H., and Hoffman, P., "Determining Strengths For
5243 Public Keys Used For Exchanging Symmetric Keys" RFC 3766,
5244 April 2004.
5246 [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
5247 Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
5248 March 2003.
5250 [MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
5251 Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
5252 3526, May 2003.
5254 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
5255 Standard," version 1.5, November 1993.
5257 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
5258 Standard," version 1.5, November 1993.
5262 Dierks & Rescorla Standards Track [Page 94]
5263 \f
5264 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
5267 [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
5268 Requirements for Security", BCP 106, RFC 4086, June 2005.
5270 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
5271 Compression Methods", RFC 3749, May 2004.
5273 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
5274 Wright, T., "Transport Layer Security (TLS) Extensions", RFC
5275 4366, April 2006.
5277 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
5278 Obtaining Digital Signatures and Public-Key Cryptosystems,"
5279 Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
5280 120-126.
5282 [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
5283 RFC 1948, May 1996.
5285 [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
5286 Corp., Feb 9, 1995.
5288 [SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
5289 Protocol", Netscape Communications Corp., Nov 18, 1996.
5291 [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
5292 Attacks on the Diffie-Hellman Key Agreement Method for
5293 S/MIME", RFC 2785, March 2000.
5295 [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
5296 September 1981.
5298 [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
5299 practical", USENIX Security Symposium 2003.
5301 [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
5302 for Transport Layer Security (TLS)", RFC 3268, June 2002.
5304 [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
5305 Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
5306 Suites for Transport Layer Security (TLS)", RFC 4492, May
5307 2006.
5309 [TLSEXT] Eastlake, D.E., "Transport Layer Security (TLS) Extensions:
5310 Extension Definitions", July 2007, draft-ietf-tls-
5311 rfc4366-bis-00.txt.
5313 [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS
5314 authentication", draft-ietf-tls-openpgp-keys-11, July 2006.
5318 Dierks & Rescorla Standards Track [Page 95]
5319 \f
5320 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
5323 [TLSPSK] Eronen, P., Tschofenig, H., "Pre-Shared Key Ciphersuites for
5324 Transport Layer Security (TLS)", RFC 4279, December 2005.
5326 [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
5327 RFC 2246, January 1999.
5329 [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version
5330 1.1", RFC 4346, April, 2006.
5332 [X501] ITU-T Recommendation X.501: Information Technology - Open
5333 Systems Interconnection - The Directory: Models, 1993.
5335 [XDR] Eisler, M., "External Data Representation Standard", RFC
5336 4506, May 2006.
5339 Credits
5341 Working Group Chairs
5343 Eric Rescorla
5344 EMail: ekr@networkresonance.com
5346 Pasi Eronen
5347 pasi.eronen@nokia.com
5350 Editors
5352 Tim Dierks Eric Rescorla
5353 Independent Network Resonance, Inc.
5354 EMail: tim@dierks.org EMail: ekr@networkresonance.com
5357 Other contributors
5359 Christopher Allen (co-editor of TLS 1.0)
5360 Alacrity Ventures
5361 ChristopherA@AlacrityManagement.com
5363 Martin Abadi
5364 University of California, Santa Cruz
5365 abadi@cs.ucsc.edu
5367 Steven M. Bellovin
5368 Columbia University
5369 smb@cs.columbia.edu
5374 Dierks & Rescorla Standards Track [Page 96]
5375 \f
5376 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
5379 Simon Blake-Wilson
5380 BCI
5381 EMail: sblakewilson@bcisse.com
5383 Ran Canetti
5384 IBM
5385 canetti@watson.ibm.com
5387 Pete Chown
5388 Skygate Technology Ltd
5389 pc@skygate.co.uk
5391 Taher Elgamal
5392 taher@securify.com
5393 Securify
5395 Anil Gangolli
5396 anil@busybuddha.org
5398 Kipp Hickman
5400 Alfred Hoenes
5402 David Hopwood
5403 Independent Consultant
5404 EMail: david.hopwood@blueyonder.co.uk
5406 Phil Karlton (co-author of SSLv3)
5408 Paul Kocher (co-author of SSLv3)
5409 Cryptography Research
5410 paul@cryptography.com
5412 Hugo Krawczyk
5413 IBM
5414 hugo@ee.technion.ac.il
5416 Jan Mikkelsen
5417 Transactionware
5418 EMail: janm@transactionware.com
5420 Magnus Nystrom
5421 RSA Security
5422 EMail: magnus@rsasecurity.com
5424 Robert Relyea
5425 Netscape Communications
5426 relyea@netscape.com
5430 Dierks & Rescorla Standards Track [Page 97]
5431 \f
5432 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
5435 Jim Roskind
5436 Netscape Communications
5437 jar@netscape.com
5439 Michael Sabin
5441 Dan Simon
5442 Microsoft, Inc.
5443 dansimon@microsoft.com
5445 Tom Weinstein
5447 Tim Wright
5448 Vodafone
5449 EMail: timothy.wright@vodafone.com
5451 Comments
5453 The discussion list for the IETF TLS working group is located at the
5454 e-mail address <tls@ietf.org>. Information on the group and
5455 information on how to subscribe to the list is at
5456 <https://www1.ietf.org/mailman/listinfo/tls>
5458 Archives of the list can be found at:
5459 <http://www.ietf.org/mail-archive/web/tls/current/index.html>
5486 Dierks & Rescorla Standards Track [Page 98]
5487 \f
5488 draft-ietf-tls-rfc4346-bis-07.txt TLS November 2007
5491 Full Copyright Statement
5493 Copyright (C) The IETF Trust (2007).
5495 This document is subject to the rights, licenses and restrictions
5496 contained in BCP 78, and except as set forth therein, the authors
5497 retain all their rights.
5499 This document and the information contained herein are provided on an
5500 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
5501 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
5502 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
5503 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
5504 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
5505 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5508 Intellectual Property
5510 The IETF takes no position regarding the validity or scope of any
5511 Intellectual Property Rights or other rights that might be claimed to
5512 pertain to the implementation or use of the technology described in
5513 this document or the extent to which any license under such rights
5514 might or might not be available; nor does it represent that it has
5515 made any independent effort to identify any such rights. Information
5516 on the procedures with respect to rights in RFC documents can be
5517 found in BCP 78 and BCP 79.
5519 Copies of IPR disclosures made to the IETF Secretariat and any
5520 assurances of licenses to be made available, or the result of an
5521 attempt made to obtain a general license or permission for the use of
5522 such proprietary rights by implementers or users of this
5523 specification can be obtained from the IETF on-line IPR repository at
5524 http://www.ietf.org/ipr.
5526 The IETF invites any interested party to bring to its attention any
5527 copyrights, patents or patent applications, or other proprietary
5528 rights that may cover technology that may be required to implement
5529 this standard. Please address the information to the IETF at
5530 ietf-ipr@ietf.org.
5533 Acknowledgment
5535 Funding for the RFC Editor function is provided by the IETF
5536 Administrative Support Activity (IASA).
5542 Dierks & Rescorla Standards Track [Page 99]
5543 \f