| blob | 1bf30d4cc895dcc47b6c8506ffe676523544d841 |
2 Tim Dierks
3 Independent
4 Eric Rescorla
5 INTERNET-DRAFT Network Resonance, Inc.
6 <draft-ietf-tls-rfc4346-bis-01.txt> June 2006 (Expires December 2006)
8 The TLS Protocol
9 Version 1.2
11 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 Copyright Notice
35 Copyright (C) The Internet Society (2006).
37 Abstract
39 This document specifies Version 1.2 of the Transport Layer Security
40 (TLS) protocol. The TLS protocol provides communications security
41 over the Internet. The protocol allows client/server applications to
42 communicate in a way that is designed to prevent eavesdropping,
43 tampering, or message forgery.
45 Table of Contents
47 1. Introduction 4
48 1.1 Differences from TLS 1.1 5
49 1.1 Requirements Terminology 5
53 Dierks & Rescorla Standards Track [Page 1]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
56 2. Goals 5
57 3. Goals of this document 6
58 4. Presentation language 6
59 4.1. Basic block size 7
60 4.2. Miscellaneous 7
61 4.3. Vectors 7
62 4.4. Numbers 8
63 4.5. Enumerateds 8
64 4.6. Constructed types 9
65 4.6.1. Variants 10
66 4.7. Cryptographic attributes 11
67 4.8. Constants 12
68 5. HMAC and the pseudorandom function 12
69 6. The TLS Record Protocol 13
70 6.1. Connection states 14
71 6.2. Record layer 16
72 6.2.1. Fragmentation 16
73 6.2.2. Record compression and decompression 18
74 6.2.3. Record payload protection 18
75 6.2.3.1. Null or standard stream cipher 19
76 6.2.3.2. CBC block cipher 20
77 6.3. Key calculation 22
78 7. The TLS Handshaking Protocols 23
79 7.1. Change cipher spec protocol 25
80 7.2. Alert protocol 25
81 7.2.1. Closure alerts 26
82 7.2.2. Error alerts 27
83 7.3. Handshake Protocol overview 31
84 7.4. Handshake protocol 35
85 7.4.1. Hello messages 36
86 7.4.1.1. Hello request 36
87 7.4.1.2. Client hello 37
88 7.4.1.3. Server hello 40
89 7.4.1.4 Hello Extensions 41
90 7.4.1.4.1 Server Name Indication 43
91 7.4.1.4.2 Maximum Fragment Length Negotiation 44
92 7.4.1.4.3 Client Certificate URLs 46
93 7.4.1.4.4 Trusted CA Indication 46
94 7.4.1.4.5 Truncated HMAC 48
95 7.4.1.4.6 Certificate Status Request 49
96 7.4.1.4.7 Cert Hash Types 50
97 7.4.1.4.8 Procedure for Defining New Extensions 51
98 7.4.2. Server certificate 52
99 7.4.3. Server key exchange message 53
100 7.4.4. CertificateStatus 56
101 7.4.5. Certificate request 56
102 7.4.6. Server hello done 58
103 7.4.7. Client certificate 59
107 Dierks & Rescorla Standards Track [Page 2]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
110 7.4.8. Client Certificate URLs 59
111 7.4.9. Client key exchange message 61
112 7.4.9.1. RSA encrypted premaster secret message 62
113 7.4.9.2. Client Diffie-Hellman public value 64
114 7.4.10. Certificate verify 65
115 7.4.10. Finished 65
116 8. Cryptographic computations 66
117 8.1. Computing the master secret 67
118 8.1.1. RSA 68
119 8.1.2. Diffie-Hellman 68
120 9. Mandatory Cipher Suites 68
121 A. Protocol constant values 72
122 A.1. Record layer 72
123 A.2. Change cipher specs message 73
124 A.3. Alert messages 73
125 A.4. Handshake protocol 75
126 A.4.1. Hello messages 75
127 A.4.2. Server authentication and key exchange messages 78
128 A.4.3. Client authentication and key exchange messages 79
129 A.4.4. Handshake finalization message 80
130 A.5. The CipherSuite 81
131 A.6. The Security Parameters 84
132 B. Glossary 85
133 C. CipherSuite definitions 89
134 D. Implementation Notes 91
135 D.1 Random Number Generation and Seeding 91
136 D.2 Certificates and authentication 91
137 D.3 CipherSuites 91
138 E. Backward Compatibility With SSL 92
139 E.1. Version 2 client hello 93
140 E.2. Avoiding man-in-the-middle version rollback 94
141 F. Security analysis 96
142 F.1. Handshake protocol 96
143 F.1.1. Authentication and key exchange 96
144 F.1.1.1. Anonymous key exchange 96
145 F.1.1.2. RSA key exchange and authentication 97
146 F.1.1.3. Diffie-Hellman key exchange with authentication 98
147 F.1.2. Version rollback attacks 98
148 F.1.3. Detecting attacks against the handshake protocol 99
149 F.1.4. Resuming sessions 99
150 F.1.5 Extensions 100
151 F.1.5.1 Security of server_name 100
152 F.1.5.2 Security of client_certificate_url 101
153 F.1.5.4. Security of trusted_ca_keys 102
154 F.1.5.5. Security of truncated_hmac 102
155 F.1.5.6. Security of status_request 103
156 F.2. Protecting application data 103
157 F.3. Explicit IVs 104
161 Dierks & Rescorla Standards Track [Page 3]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
164 F.4 Security of Composite Cipher Modes 104
165 F.5 Denial of Service 105
166 F.6. Final notes 105
169 Change history
171 18-Feb-06 First draft by ekr@rtfm.com
174 1. Introduction
176 The primary goal of the TLS Protocol is to provide privacy and data
177 integrity between two communicating applications. The protocol is
178 composed of two layers: the TLS Record Protocol and the TLS Handshake
179 Protocol. At the lowest level, layered on top of some reliable
180 transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
181 TLS Record Protocol provides connection security that has two basic
182 properties:
184 - The connection is private. Symmetric cryptography is used for
185 data encryption (e.g., DES [DES], RC4 [SCH], etc.). The keys for
186 this symmetric encryption are generated uniquely for each
187 connection and are based on a secret negotiated by another
188 protocol (such as the TLS Handshake Protocol). The Record
189 Protocol can also be used without encryption.
191 - The connection is reliable. Message transport includes a message
192 integrity check using a keyed MAC. Secure hash functions (e.g.,
193 SHA, MD5, etc.) are used for MAC computations. The Record
194 Protocol can operate without a MAC, but is generally only used in
195 this mode while another protocol is using the Record Protocol as
196 a transport for negotiating security parameters.
198 The TLS Record Protocol is used for encapsulation of various higher
199 level protocols. One such encapsulated protocol, the TLS Handshake
200 Protocol, allows the server and client to authenticate each other and
201 to negotiate an encryption algorithm and cryptographic keys before
202 the application protocol transmits or receives its first byte of
203 data. The TLS Handshake Protocol provides connection security that
204 has three basic properties:
206 - The peer's identity can be authenticated using asymmetric, or
207 public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
208 authentication can be made optional, but is generally required
209 for at least one of the peers.
211 - The negotiation of a shared secret is secure: the negotiated
215 Dierks & Rescorla Standards Track [Page 4]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
218 secret is unavailable to eavesdroppers, and for any authenticated
219 connection the secret cannot be obtained, even by an attacker who
220 can place himself in the middle of the connection.
222 - The negotiation is reliable: no attacker can modify the
223 negotiation communication without being detected by the parties
224 to the communication.
226 One advantage of TLS is that it is application protocol independent.
227 Higher level protocols can layer on top of the TLS Protocol
228 transparently. The TLS standard, however, does not specify how
229 protocols add security with TLS; the decisions on how to initiate TLS
230 handshaking and how to interpret the authentication certificates
231 exchanged are left up to the judgment of the designers and
232 implementors of protocols which run on top of TLS.
234 1.1 Differences from TLS 1.1
235 This document is a revision of the TLS 1.1 [TLS1.1] protocol which
236 contains improved flexibility, particularly for negotiation of
237 cryptographic algorithms. The major changes are:
239 - Merged in TLS Extensions and AES Cipher Suites from external
240 documents.
242 - Replacement of MD5/SHA-1 combination in the PRF
244 - Replacement of MD5/SHA-1 combination in the digitally-signed
245 element.
247 - Allow the client to indicate which hash functions it supports.
249 - Allow the server to indicate which has functions it supports
251 1.1 Requirements Terminology
253 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
254 "MAY" that appear in this document are to be interpreted as described
255 in RFC 2119 [REQ].
257 2. Goals
259 The goals of TLS Protocol, in order of their priority, are:
261 1. Cryptographic security: TLS should be used to establish a secure
262 connection between two parties.
264 2. Interoperability: Independent programmers should be able to
265 develop applications utilizing TLS that will then be able to
269 Dierks & Rescorla Standards Track [Page 5]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
272 successfully exchange cryptographic parameters without knowledge
273 of one another's code.
275 3. Extensibility: TLS seeks to provide a framework into which new
276 public key and bulk encryption methods can be incorporated as
277 necessary. This will also accomplish two sub-goals: to prevent
278 the need to create a new protocol (and risking the introduction
279 of possible new weaknesses) and to avoid the need to implement an
280 entire new security library.
282 4. Relative efficiency: Cryptographic operations tend to be highly
283 CPU intensive, particularly public key operations. For this
284 reason, the TLS protocol has incorporated an optional session
285 caching scheme to reduce the number of connections that need to
286 be established from scratch. Additionally, care has been taken to
287 reduce network activity.
289 3. Goals of this document
291 This document and the TLS protocol itself are based on the SSL 3.0
292 Protocol Specification as published by Netscape. The differences
293 between this protocol and SSL 3.0 are not dramatic, but they are
294 significant enough that the various versions of TLS and SSL 3.0 do
295 not interoperate (although each protocol incorporates a mechanism by
296 which an implementation can back down prior versions. This document
297 is intended primarily for readers who will be implementing the
298 protocol and those doing cryptographic analysis of it. The
299 specification has been written with this in mind, and it is intended
300 to reflect the needs of those two groups. For that reason, many of
301 the algorithm-dependent data structures and rules are included in the
302 body of the text (as opposed to in an appendix), providing easier
303 access to them.
305 This document is not intended to supply any details of service
306 definition nor interface definition, although it does cover select
307 areas of policy as they are required for the maintenance of solid
308 security.
310 4. Presentation language
312 This document deals with the formatting of data in an external
313 representation. The following very basic and somewhat casually
314 defined presentation syntax will be used. The syntax draws from
315 several sources in its structure. Although it resembles the
316 programming language "C" in its syntax and XDR [XDR] in both its
317 syntax and intent, it would be risky to draw too many parallels. The
318 purpose of this presentation language is to document TLS only, not to
319 have general application beyond that particular goal.
323 Dierks & Rescorla Standards Track [Page 6]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
326 4.1. Basic block size
328 The representation of all data items is explicitly specified. The
329 basic data block size is one byte (i.e. 8 bits). Multiple byte data
330 items are concatenations of bytes, from left to right, from top to
331 bottom. From the bytestream a multi-byte item (a numeric in the
332 example) is formed (using C notation) by:
334 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
335 ... | byte[n-1];
337 This byte ordering for multi-byte values is the commonplace network
338 byte order or big endian format.
340 4.2. Miscellaneous
342 Comments begin with "/*" and end with "*/".
344 Optional components are denoted by enclosing them in "[[ ]]" double
345 brackets.
347 Single byte entities containing uninterpreted data are of type
348 opaque.
350 4.3. Vectors
352 A vector (single dimensioned array) is a stream of homogeneous data
353 elements. The size of the vector may be specified at documentation
354 time or left unspecified until runtime. In either case the length
355 declares the number of bytes, not the number of elements, in the
356 vector. The syntax for specifying a new type T' that is a fixed
357 length vector of type T is
359 T T'[n];
361 Here T' occupies n bytes in the data stream, where n is a multiple of
362 the size of T. The length of the vector is not included in the
363 encoded stream.
365 In the following example, Datum is defined to be three consecutive
366 bytes that the protocol does not interpret, while Data is three
367 consecutive Datum, consuming a total of nine bytes.
369 opaque Datum[3]; /* three uninterpreted bytes */
370 Datum Data[9]; /* 3 consecutive 3 byte vectors */
377 Dierks & Rescorla Standards Track [Page 7]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
380 Variable length vectors are defined by specifying a subrange of legal
381 lengths, inclusively, using the notation <floor..ceiling>. When
382 encoded, the actual length precedes the vector's contents in the byte
383 stream. The length will be in the form of a number consuming as many
384 bytes as required to hold the vector's specified maximum (ceiling)
385 length. A variable length vector with an actual length field of zero
386 is referred to as an empty vector.
388 T T'<floor..ceiling>;
390 In the following example, mandatory is a vector that must contain
391 between 300 and 400 bytes of type opaque. It can never be empty. The
392 actual length field consumes two bytes, a uint16, sufficient to
393 represent the value 400 (see Section 4.4). On the other hand, longer
394 can represent up to 800 bytes of data, or 400 uint16 elements, and it
395 may be empty. Its encoding will include a two byte actual length
396 field prepended to the vector. The length of an encoded vector must
397 be an even multiple of the length of a single element (for example, a
398 17 byte vector of uint16 would be illegal).
400 opaque mandatory<300..400>;
401 /* length field is 2 bytes, cannot be empty */
402 uint16 longer<0..800>;
403 /* zero to 400 16-bit unsigned integers */
405 4.4. Numbers
407 The basic numeric data type is an unsigned byte (uint8). All larger
408 numeric data types are formed from fixed length series of bytes
409 concatenated as described in Section 4.1 and are also unsigned. The
410 following numeric types are predefined.
412 uint8 uint16[2];
413 uint8 uint24[3];
414 uint8 uint32[4];
415 uint8 uint64[8];
417 All values, here and elsewhere in the specification, are stored in
418 "network" or "big-endian" order; the uint32 represented by the hex
419 bytes 01 02 03 04 is equivalent to the decimal value 16909060.
421 4.5. Enumerateds
423 An additional sparse data type is available called enum. A field of
424 type enum can only assume the values declared in the definition.
425 Each definition is a different type. Only enumerateds of the same
426 type may be assigned or compared. Every element of an enumerated must
431 Dierks & Rescorla Standards Track [Page 8]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
434 be assigned a value, as demonstrated in the following example. Since
435 the elements of the enumerated are not ordered, they can be assigned
436 any unique value, in any order.
438 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
440 Enumerateds occupy as much space in the byte stream as would its
441 maximal defined ordinal value. The following definition would cause
442 one byte to be used to carry fields of type Color.
444 enum { red(3), blue(5), white(7) } Color;
446 One may optionally specify a value without its associated tag to
447 force the width definition without defining a superfluous element.
448 In the following example, Taste will consume two bytes in the data
449 stream but can only assume the values 1, 2 or 4.
451 enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
453 The names of the elements of an enumeration are scoped within the
454 defined type. In the first example, a fully qualified reference to
455 the second element of the enumeration would be Color.blue. Such
456 qualification is not required if the target of the assignment is well
457 specified.
459 Color color = Color.blue; /* overspecified, legal */
460 Color color = blue; /* correct, type implicit */
462 For enumerateds that are never converted to external representation,
463 the numerical information may be omitted.
465 enum { low, medium, high } Amount;
467 4.6. Constructed types
469 Structure types may be constructed from primitive types for
470 convenience. Each specification declares a new, unique type. The
471 syntax for definition is much like that of C.
473 struct {
474 T1 f1;
475 T2 f2;
476 ...
477 Tn fn;
478 } [[T]];
485 Dierks & Rescorla Standards Track [Page 9]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
488 The fields within a structure may be qualified using the type's name
489 using a syntax much like that available for enumerateds. For example,
490 T.f2 refers to the second field of the previous declaration.
491 Structure definitions may be embedded.
493 4.6.1. Variants
495 Defined structures may have variants based on some knowledge that is
496 available within the environment. The selector must be an enumerated
497 type that defines the possible variants the structure defines. There
498 must be a case arm for every element of the enumeration declared in
499 the select. The body of the variant structure may be given a label
500 for reference. The mechanism by which the variant is selected at
501 runtime is not prescribed by the presentation language.
503 struct {
504 T1 f1;
505 T2 f2;
506 ....
507 Tn fn;
508 select (E) {
509 case e1: Te1;
510 case e2: Te2;
511 ....
512 case en: Ten;
513 } [[fv]];
514 } [[Tv]];
516 For example:
518 enum { apple, orange } VariantTag;
519 struct {
520 uint16 number;
521 opaque string<0..10>; /* variable length */
522 } V1;
523 struct {
524 uint32 number;
525 opaque string[10]; /* fixed length */
526 } V2;
527 struct {
528 select (VariantTag) { /* value of selector is implicit */
529 case apple: V1; /* VariantBody, tag = apple */
530 case orange: V2; /* VariantBody, tag = orange */
531 } variant_body; /* optional label on variant */
532 } VariantRecord;
534 Variant structures may be qualified (narrowed) by specifying a value
535 for the selector prior to the type. For example, a
539 Dierks & Rescorla Standards Track [Page 10]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
542 orange VariantRecord
544 is a narrowed type of a VariantRecord containing a variant_body of
545 type V2.
547 4.7. Cryptographic attributes
549 The four cryptographic operations digital signing, stream cipher
550 encryption, block cipher encryption, and public key encryption are
551 designated digitally-signed, stream-ciphered, block-ciphered, and
552 public-key-encrypted, respectively. A field's cryptographic
553 processing is specified by prepending an appropriate key word
554 designation before the field's type specification. Cryptographic keys
555 are implied by the current session state (see Section 6.1).
557 In digital signing, one-way hash functions are used as input for a
558 signing algorithm. A digitally-signed element is encoded as an opaque
559 vector <0..2^16-1>, where the length is specified by the signing
560 algorithm and key.
562 In RSA signing, the output of the chosen hash function is encoded as
563 a PKCS #1 DigestInfo and then signed using block type 01 as described
564 in Section 8.1 as described in [PKCS1A].
566 Note: the standard reference for PKCS#1 is now RFC 3447 [PKCS1B].
567 However, to minimize differences with TLS 1.0 text, we are using the
568 terminology of RFC 2313 [PKCS1A].
570 In DSS, the 20 bytes of the SHA-1 hash are run directly through the
571 Digital Signing Algorithm with no additional hashing. This produces
572 two values, r and s. The DSS signature is an opaque vector, as above,
573 the contents of which are the DER encoding of:
575 Dss-Sig-Value ::= SEQUENCE {
576 r INTEGER,
577 s INTEGER
578 }
580 In stream cipher encryption, the plaintext is exclusive-ORed with an
581 identical amount of output generated from a cryptographically-secure
582 keyed pseudorandom number generator.
584 In block cipher encryption, every block of plaintext encrypts to a
585 block of ciphertext. All block cipher encryption is done in CBC
586 (Cipher Block Chaining) mode, and all items which are block-ciphered
587 will be an exact multiple of the cipher block length.
589 In public key encryption, a public key algorithm is used to encrypt
593 Dierks & Rescorla Standards Track [Page 11]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
596 data in such a way that it can be decrypted only with the matching
597 private key. A public-key-encrypted element is encoded as an opaque
598 vector <0..2^16-1>, where the length is specified by the signing
599 algorithm and key.
601 An RSA encrypted value is encoded with PKCS #1 block type 2 as
602 described in [PKCS1A].
604 In the following example:
606 stream-ciphered struct {
607 uint8 field1;
608 uint8 field2;
609 digitally-signed opaque hash[20];
610 } UserType;
612 The contents of hash are used as input for the signing algorithm,
613 then the entire structure is encrypted with a stream cipher. The
614 length of this structure, in bytes would be equal to 2 bytes for
615 field1 and field2, plus two bytes for the length of the signature,
616 plus the length of the output of the signing algorithm. This is known
617 due to the fact that the algorithm and key used for the signing are
618 known prior to encoding or decoding this structure.
620 4.8. Constants
622 Typed constants can be defined for purposes of specification by
623 declaring a symbol of the desired type and assigning values to it.
624 Under-specified types (opaque, variable length vectors, and
625 structures that contain opaque) cannot be assigned values. No fields
626 of a multi-element structure or vector may be elided.
628 For example,
630 struct {
631 uint8 f1;
632 uint8 f2;
633 } Example1;
635 Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
637 5. HMAC and the pseudorandom function
639 A number of operations in the TLS record and handshake layer required
640 a keyed MAC; this is a secure digest of some data protected by a
641 secret. Forging the MAC is infeasible without knowledge of the MAC
642 secret. The construction we use for this operation is known as HMAC,
643 described in [HMAC].
647 Dierks & Rescorla Standards Track [Page 12]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
650 In addition, a construction is required to do expansion of secrets
651 into blocks of data for the purposes of key generation or validation.
652 This pseudo-random function (PRF) takes as input a secret, a seed,
653 and an identifying label and produces an output of arbitrary length.
655 First, we define a data expansion function, P_hash(secret, data)
656 which uses a single hash function to expand a secret and seed into an
657 arbitrary quantity of output:
659 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
660 HMAC_hash(secret, A(2) + seed) +
661 HMAC_hash(secret, A(3) + seed) + ...
663 Where + indicates concatenation.
665 A() is defined as:
666 A(0) = seed
667 A(i) = HMAC_hash(secret, A(i-1))
669 P_hash can be iterated as many times as is necessary to produce the
670 required quantity of data. For example, if P_SHA-1 was being used to
671 create 64 bytes of data, it would have to be iterated 4 times
672 (through A(4)), creating 80 bytes of output data; the last 16 bytes
673 of the final iteration would then be discarded, leaving 64 bytes of
674 output data.
676 TLS's PRF is created by applying P_hash to the secret S. The hash
677 function used in P MUST be the same hash function selected for the
678 HMAC in the cipher suite.
680 The label is an ASCII string. It should be included in the exact form
681 it is given without a length byte or trailing null character. For
682 example, the label "slithy toves" would be processed by hashing the
683 following bytes:
685 73 6C 69 74 68 79 20 74 6F 76 65 73
688 6. The TLS Record Protocol
690 The TLS Record Protocol is a layered protocol. At each layer,
691 messages may include fields for length, description, and content.
692 The Record Protocol takes messages to be transmitted, fragments the
693 data into manageable blocks, optionally compresses the data, applies
694 a MAC, encrypts, and transmits the result. Received data is
695 decrypted, verified, decompressed, and reassembled, then delivered to
696 higher level clients.
701 Dierks & Rescorla Standards Track [Page 13]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
704 Four record protocol clients are described in this document: the
705 handshake protocol, the alert protocol, the change cipher spec
706 protocol, and the application data protocol. In order to allow
707 extension of the TLS protocol, additional record types can be
708 supported by the record protocol. Any new record types SHOULD
709 allocate type values immediately beyond the ContentType values for
710 the four record types described here (see Appendix A.1). All such
711 values must be defined by RFC 2434 Standards Action. See section 11
712 for IANA Considerations for ContentType values.
714 If a TLS implementation receives a record type it does not
715 understand, it SHOULD just ignore it. Any protocol designed for use
716 over TLS MUST be carefully designed to deal with all possible attacks
717 against it. Note that because the type and length of a record are
718 not protected by encryption, care SHOULD be taken to minimize the
719 value of traffic analysis of these values.
721 6.1. Connection states
723 A TLS connection state is the operating environment of the TLS Record
724 Protocol. It specifies a compression algorithm, encryption algorithm,
725 and MAC algorithm. In addition, the parameters for these algorithms
726 are known: the MAC secret and the bulk encryption keys for the
727 connection in both the read and the write directions. Logically,
728 there are always four connection states outstanding: the current read
729 and write states, and the pending read and write states. All records
730 are processed under the current read and write states. The security
731 parameters for the pending states can be set by the TLS Handshake
732 Protocol, and the Change Cipher Spec can selectively make either of
733 the pending states current, in which case the appropriate current
734 state is disposed of and replaced with the pending state; the pending
735 state is then reinitialized to an empty state. It is illegal to make
736 a state which has not been initialized with security parameters a
737 current state. The initial current state always specifies that no
738 encryption, compression, or MAC will be used.
740 The security parameters for a TLS Connection read and write state are
741 set by providing the following values:
743 connection end
744 Whether this entity is considered the "client" or the "server" in
745 this connection.
747 bulk encryption algorithm
748 An algorithm to be used for bulk encryption. This specification
749 includes the key size of this algorithm, how much of that key is
750 secret, whether it is a block or stream cipher, the block size of
751 the cipher (if appropriate).
755 Dierks & Rescorla Standards Track [Page 14]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
758 MAC algorithm
759 An algorithm to be used for message authentication. This
760 specification includes the size of the hash which is returned by
761 the MAC algorithm.
763 compression algorithm
764 An algorithm to be used for data compression. This specification
765 must include all information the algorithm requires to do
766 compression.
768 master secret
769 A 48 byte secret shared between the two peers in the connection.
771 client random
772 A 32 byte value provided by the client.
774 server random
775 A 32 byte value provided by the server.
777 These parameters are defined in the presentation language as:
779 enum { server, client } ConnectionEnd;
781 enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm;
783 enum { stream, block } CipherType;
785 enum { null, md5, sha } MACAlgorithm;
787 enum { null(0), (255) } CompressionMethod;
789 /* The algorithms specified in CompressionMethod,
790 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
792 struct {
793 ConnectionEnd entity;
794 BulkCipherAlgorithm bulk_cipher_algorithm;
795 CipherType cipher_type;
796 uint8 key_size;
797 uint8 key_material_length;
798 MACAlgorithm mac_algorithm;
799 uint8 hash_size;
800 CompressionMethod compression_algorithm;
801 opaque master_secret[48];
802 opaque client_random[32];
803 opaque server_random[32];
804 } SecurityParameters;
809 Dierks & Rescorla Standards Track [Page 15]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
812 The record layer will use the security parameters to generate the
813 following four items:
815 client write MAC secret
816 server write MAC secret
817 client write key
818 server write key
820 The client write parameters are used by the server when receiving and
821 processing records and vice-versa. The algorithm used for generating
822 these items from the security parameters is described in section 6.3.
824 Once the security parameters have been set and the keys have been
825 generated, the connection states can be instantiated by making them
826 the current states. These current states MUST be updated for each
827 record processed. Each connection state includes the following
828 elements:
830 compression state
831 The current state of the compression algorithm.
833 cipher state
834 The current state of the encryption algorithm. This will consist
835 of the scheduled key for that connection. For stream ciphers,
836 this will also contain whatever the necessary state information
837 is to allow the stream to continue to encrypt or decrypt data.
839 MAC secret
840 The MAC secret for this connection as generated above.
842 sequence number
843 Each connection state contains a sequence number, which is
844 maintained separately for read and write states. The sequence
845 number MUST be set to zero whenever a connection state is made
846 the active state. Sequence numbers are of type uint64 and may not
847 exceed 2^64-1. Sequence numbers do not wrap. If a TLS
848 implementation would need to wrap a sequence number it must
849 renegotiate instead. A sequence number is incremented after each
850 record: specifically, the first record which is transmitted under
851 a particular connection state MUST use sequence number 0.
853 6.2. Record layer
855 The TLS Record Layer receives uninterpreted data from higher layers
856 in non-empty blocks of arbitrary size.
858 6.2.1. Fragmentation
863 Dierks & Rescorla Standards Track [Page 16]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
866 The record layer fragments information blocks into TLSPlaintext
867 records carrying data in chunks of 2^14 bytes or less. Client message
868 boundaries are not preserved in the record layer (i.e., multiple
869 client messages of the same ContentType MAY be coalesced into a
870 single TLSPlaintext record, or a single message MAY be fragmented
871 across several records).
874 struct {
875 uint8 major, minor;
876 } ProtocolVersion;
878 enum {
879 change_cipher_spec(20), alert(21), handshake(22),
880 application_data(23), (255)
881 } ContentType;
883 struct {
884 ContentType type;
885 ProtocolVersion version;
886 uint16 length;
887 opaque fragment[TLSPlaintext.length];
888 } TLSPlaintext;
890 type
891 The higher level protocol used to process the enclosed fragment.
893 version
894 The version of the protocol being employed. This document
895 describes TLS Version 1.2, which uses the version { 3, 3 }. The
896 version value 3.3 is historical, deriving from the use of 3.1 for
897 TLS 1.0. (See Appendix A.1).
899 length
900 The length (in bytes) of the following TLSPlaintext.fragment.
901 The length should not exceed 2^14.
903 fragment
904 The application data. This data is transparent and treated as an
905 independent block to be dealt with by the higher level protocol
906 specified by the type field.
908 Note: Data of different TLS Record layer content types MAY be
909 interleaved. Application data is generally of lower precedence
910 for transmission than other content types. However, records MUST
911 be delivered to the network in the same order as they are
912 protected by the record layer. Recipients MUST receive and
913 process interleaved application layer traffic during handshakes
917 Dierks & Rescorla Standards Track [Page 17]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
920 subsequent to the first one on a connection.
923 6.2.2. Record compression and decompression
925 All records are compressed using the compression algorithm defined in
926 the current session state. There is always an active compression
927 algorithm; however, initially it is defined as
928 CompressionMethod.null. The compression algorithm translates a
929 TLSPlaintext structure into a TLSCompressed structure. Compression
930 functions are initialized with default state information whenever a
931 connection state is made active.
933 Compression must be lossless and may not increase the content length
934 by more than 1024 bytes. If the decompression function encounters a
935 TLSCompressed.fragment that would decompress to a length in excess of
936 2^14 bytes, it should report a fatal decompression failure error.
938 struct {
939 ContentType type; /* same as TLSPlaintext.type */
940 ProtocolVersion version;/* same as TLSPlaintext.version */
941 uint16 length;
942 opaque fragment[TLSCompressed.length];
943 } TLSCompressed;
945 length
946 The length (in bytes) of the following TLSCompressed.fragment.
947 The length should not exceed 2^14 + 1024.
949 fragment
950 The compressed form of TLSPlaintext.fragment.
952 Note: A CompressionMethod.null operation is an identity operation; no
953 fields are altered.
955 Implementation note:
956 Decompression functions are responsible for ensuring that
957 messages cannot cause internal buffer overflows.
959 6.2.3. Record payload protection
961 The encryption and MAC functions translate a TLSCompressed structure
962 into a TLSCiphertext. The decryption functions reverse the process.
963 The MAC of the record also includes a sequence number so that
964 missing, extra or repeated messages are detectable.
966 struct {
967 ContentType type;
971 Dierks & Rescorla Standards Track [Page 18]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
974 ProtocolVersion version;
975 uint16 length;
976 select (CipherSpec.cipher_type) {
977 case stream: GenericStreamCipher;
978 case block: GenericBlockCipher;
979 } fragment;
980 } TLSCiphertext;
982 type
983 The type field is identical to TLSCompressed.type.
985 version
986 The version field is identical to TLSCompressed.version.
988 length
989 The length (in bytes) of the following TLSCiphertext.fragment.
990 The length may not exceed 2^14 + 2048.
992 fragment
993 The encrypted form of TLSCompressed.fragment, with the MAC.
995 6.2.3.1. Null or standard stream cipher
997 Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
998 A.6) convert TLSCompressed.fragment structures to and from stream
999 TLSCiphertext.fragment structures.
1001 stream-ciphered struct {
1002 opaque content[TLSCompressed.length];
1003 opaque MAC[CipherSpec.hash_size];
1004 } GenericStreamCipher;
1006 The MAC is generated as:
1008 HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
1009 TLSCompressed.version + TLSCompressed.length +
1010 TLSCompressed.fragment));
1012 where "+" denotes concatenation.
1014 seq_num
1015 The sequence number for this record.
1017 hash
1018 The hashing algorithm specified by
1019 SecurityParameters.mac_algorithm.
1021 Note that the MAC is computed before encryption. The stream cipher
1025 Dierks & Rescorla Standards Track [Page 19]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1028 encrypts the entire block, including the MAC. For stream ciphers that
1029 do not use a synchronization vector (such as RC4), the stream cipher
1030 state from the end of one record is simply used on the subsequent
1031 packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
1032 consists of the identity operation (i.e., the data is not encrypted
1033 and the MAC size is zero implying that no MAC is used).
1034 TLSCiphertext.length is TLSCompressed.length plus
1035 CipherSpec.hash_size.
1037 6.2.3.2. CBC block cipher
1039 For block ciphers (such as RC2, DES, or AES), the encryption and MAC
1040 functions convert TLSCompressed.fragment structures to and from block
1041 TLSCiphertext.fragment structures.
1043 block-ciphered struct {
1044 opaque IV[CipherSpec.block_length];
1045 opaque content[TLSCompressed.length];
1046 opaque MAC[CipherSpec.hash_size];
1047 uint8 padding[GenericBlockCipher.padding_length];
1048 uint8 padding_length;
1049 } GenericBlockCipher;
1051 The MAC is generated as described in Section 6.2.3.1.
1053 IV
1054 Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit
1055 IV in order to prevent the attacks described by [CBCATT].
1056 We recommend the following equivalently strong procedures.
1057 For clarity we use the following notation.
1059 IV -- the transmitted value of the IV field in the
1060 GenericBlockCipher structure.
1061 CBC residue -- the last ciphertext block of the previous record
1062 mask -- the actual value which the cipher XORs with the
1063 plaintext prior to encryption of the first cipher block
1064 of the record.
1066 In prior versions of TLS, there was no IV field and the CBC residue
1067 and mask were one and the same. See Sections 6.1, 6.2.3.2 and 6.3,
1068 of [TLS1.0] for details of TLS 1.0 IV handling.
1070 One of the following two algorithms SHOULD be used to generate the
1071 per-record IV:
1073 (1) Generate a cryptographically strong random string R of
1074 length CipherSpec.block_length. Place R
1075 in the IV field. Set the mask to R. Thus, the first
1079 Dierks & Rescorla Standards Track [Page 20]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1082 cipher block will be encrypted as E(R XOR Data).
1084 (2) Generate a cryptographically strong random number R of
1085 length CipherSpec.block_length and prepend it to the plaintext
1086 prior to encryption. In
1087 this case either:
1089 (a) The cipher may use a fixed mask such as zero.
1090 (b) The CBC residue from the previous record may be used
1091 as the mask. This preserves maximum code compatibility
1092 with TLS 1.0 and SSL 3. It also has the advantage that
1093 it does not require the ability to quickly reset the IV,
1094 which is known to be a problem on some systems.
1096 In either 2(a) or 2(b) the data (R || data) is fed into the
1097 encryption process. The first cipher block (containing
1098 E(mask XOR R) is placed in the IV field. The first
1099 block of content contains E(IV XOR data)
1101 The following alternative procedure MAY be used: However, it has
1102 not been demonstrated to be equivalently cryptographically strong
1103 to the above procedures. The sender prepends a fixed block F to
1104 the plaintext (or alternatively a block generated with a weak
1105 PRNG). He then encrypts as in (2) above, using the CBC residue
1106 from the previous block as the mask for the prepended block. Note
1107 that in this case the mask for the first record transmitted by
1108 the application (the Finished) MUST be generated using a
1109 cryptographically strong PRNG.
1111 The decryption operation for all three alternatives is the same.
1112 The receiver decrypts the entire GenericBlockCipher structure and
1113 then discards the first cipher block, corresponding to the IV
1114 component.
1116 padding
1117 Padding that is added to force the length of the plaintext to be
1118 an integral multiple of the block cipher's block length. The
1119 padding MAY be any length up to 255 bytes long, as long as it
1120 results in the TLSCiphertext.length being an integral multiple of
1121 the block length. Lengths longer than necessary might be
1122 desirable to frustrate attacks on a protocol based on analysis of
1123 the lengths of exchanged messages. Each uint8 in the padding data
1124 vector MUST be filled with the padding length value. The receiver
1125 MUST check this padding and SHOULD use the bad_record_mac alert
1126 to indicate padding errors.
1128 padding_length
1129 The padding length MUST be such that the total size of the
1133 Dierks & Rescorla Standards Track [Page 21]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1136 GenericBlockCipher structure is a multiple of the cipher's block
1137 length. Legal values range from zero to 255, inclusive. This
1138 length specifies the length of the padding field exclusive of the
1139 padding_length field itself.
1141 The encrypted data length (TLSCiphertext.length) is one more than the
1142 sum of TLSCompressed.length, CipherSpec.hash_size, and
1143 padding_length.
1145 Example: If the block length is 8 bytes, the content length
1146 (TLSCompressed.length) is 61 bytes, and the MAC length is 20
1147 bytes, the length before padding is 82 bytes (this does not
1148 include the IV, which may or may not be encrypted, as
1149 discussed above). Thus, the padding length modulo 8 must be
1150 equal to 6 in order to make the total length an even multiple
1151 of 8 bytes (the block length). The padding length can be 6,
1152 14, 22, and so on, through 254. If the padding length were the
1153 minimum necessary, 6, the padding would be 6 bytes, each
1154 containing the value 6. Thus, the last 8 octets of the
1155 GenericBlockCipher before block encryption would be xx 06 06
1156 06 06 06 06 06, where xx is the last octet of the MAC.
1158 Note: With block ciphers in CBC mode (Cipher Block Chaining),
1159 it is critical that the entire plaintext of the record be known
1160 before any ciphertext is transmitted. Otherwise it is possible
1161 for the attacker to mount the attack described in [CBCATT].
1163 Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a
1164 timing attack on CBC padding based on the time required to
1165 compute the MAC. In order to defend against this attack,
1166 implementations MUST ensure that record processing time is
1167 essentially the same whether or not the padding is correct. In
1168 general, the best way to to do this is to compute the MAC even if
1169 the padding is incorrect, and only then reject the packet. For
1170 instance, if the pad appears to be incorrect the implementation
1171 might assume a zero-length pad and then compute the MAC. This
1172 leaves a small timing channel, since MAC performance depends to
1173 some extent on the size of the data fragment, but it is not
1174 believed to be large enough to be exploitable due to the large
1175 block size of existing MACs and the small size of the timing
1176 signal.
1178 6.3. Key calculation
1180 The Record Protocol requires an algorithm to generate keys, and MAC
1181 secrets from the security parameters provided by the handshake
1182 protocol.
1187 Dierks & Rescorla Standards Track [Page 22]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1190 The master secret is hashed into a sequence of secure bytes, which
1191 are assigned to the MAC secrets and keys required by the current
1192 connection state (see Appendix A.6). CipherSpecs require a client
1193 write MAC secret, a server write MAC secret, a client write key, and
1194 a server write key, which are generated from the master secret in
1195 that order. Unused values are empty.
1197 When generating keys and MAC secrets, the master secret is used as an
1198 entropy source.
1200 To generate the key material, compute
1202 key_block = PRF(SecurityParameters.master_secret,
1203 "key expansion",
1204 SecurityParameters.server_random +
1205 SecurityParameters.client_random);
1207 until enough output has been generated. Then the key_block is
1208 partitioned as follows:
1210 client_write_MAC_secret[SecurityParameters.hash_size]
1211 server_write_MAC_secret[SecurityParameters.hash_size]
1212 client_write_key[SecurityParameters.key_material_length]
1213 server_write_key[SecurityParameters.key_material_length]
1216 Implementation note:
1217 The currently defined which requires the most material is
1218 AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte
1219 keys and 2 x 20 byte MAC secrets, for a total 104 bytes of key
1220 material.
1222 7. The TLS Handshaking Protocols
1224 TLS has three subprotocols which are used to allow peers to agree
1225 upon security parameters for the record layer, authenticate
1226 themselves, instantiate negotiated security parameters, and
1227 report error conditions to each other.
1229 The Handshake Protocol is responsible for negotiating a session,
1230 which consists of the following items:
1232 session identifier
1233 An arbitrary byte sequence chosen by the server to identify an
1234 active or resumable session state.
1236 peer certificate
1237 X509v3 [X509] certificate of the peer. This element of the
1241 Dierks & Rescorla Standards Track [Page 23]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1244 state may be null.
1246 compression method
1247 The algorithm used to compress data prior to encryption.
1249 cipher spec
1250 Specifies the bulk data encryption algorithm (such as null,
1251 DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also
1252 defines cryptographic attributes such as the hash_size. (See
1253 Appendix A.6 for formal definition)
1255 master secret
1256 48-byte secret shared between the client and server.
1258 is resumable
1259 A flag indicating whether the session can be used to initiate
1260 new connections.
1262 These items are then used to create security parameters for use by
1263 the Record Layer when protecting application data. Many connections
1264 can be instantiated using the same session through the resumption
1265 feature of the TLS Handshake Protocol.
1267 7.1. Change cipher spec protocol
1269 The change cipher spec protocol exists to signal transitions in
1270 ciphering strategies. The protocol consists of a single message,
1271 which is encrypted and compressed under the current (not the pending)
1272 connection state. The message consists of a single byte of value 1.
1274 struct {
1275 enum { change_cipher_spec(1), (255) } type;
1276 } ChangeCipherSpec;
1278 The change cipher spec message is sent by both the client and server
1279 to notify the receiving party that subsequent records will be
1280 protected under the newly negotiated CipherSpec and keys. Reception
1281 of this message causes the receiver to instruct the Record Layer to
1282 immediately copy the read pending state into the read current state.
1283 Immediately after sending this message, the sender MUST instruct the
1284 record layer to make the write pending state the write active state.
1285 (See section 6.1.) The change cipher spec message is sent during the
1286 handshake after the security parameters have been agreed upon, but
1287 before the verifying finished message is sent (see section 7.4.11
1289 Note: if a rehandshake occurs while data is flowing on a connection,
1290 the communicating parties may continue to send data using the old
1291 CipherSpec. However, once the ChangeCipherSpec has been sent, the new
1295 Dierks & Rescorla Standards Track [Page 24]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1298 CipherSpec MUST be used. The first side to send the ChangeCipherSpec
1299 does not know that the other side has finished computing the new
1300 keying material (e.g. if it has to perform a time consuming public
1301 key operation). Thus, a small window of time during which the
1302 recipient must buffer the data MAY exist. In practice, with modern
1303 machines this interval is likely to be fairly short.
1305 7.2. Alert protocol
1307 One of the content types supported by the TLS Record layer is the
1308 alert type. Alert messages convey the severity of the message and a
1309 description of the alert. Alert messages with a level of fatal result
1310 in the immediate termination of the connection. In this case, other
1311 connections corresponding to the session may continue, but the
1312 session identifier MUST be invalidated, preventing the failed session
1313 from being used to establish new connections. Like other messages,
1314 alert messages are encrypted and compressed, as specified by the
1315 current connection state.
1317 enum { warning(1), fatal(2), (255) } AlertLevel;
1319 enum {
1320 close_notify(0),
1321 unexpected_message(10),
1322 bad_record_mac(20),
1323 decryption_failed(21),
1324 record_overflow(22),
1325 decompression_failure(30),
1326 handshake_failure(40),
1327 no_certificate_RESERVED (41),
1328 bad_certificate(42),
1329 unsupported_certificate(43),
1330 certificate_revoked(44),
1331 certificate_expired(45),
1332 certificate_unknown(46),
1333 illegal_parameter(47),
1334 unknown_ca(48),
1335 access_denied(49),
1336 decode_error(50),
1337 decrypt_error(51),
1338 export_restriction_RESERVED(60),
1339 protocol_version(70),
1340 insufficient_security(71),
1341 internal_error(80),
1342 user_canceled(90),
1343 no_renegotiation(100),
1344 unsupported_extension(110), /* new */
1345 certificate_unobtainable(111), /* new */
1349 Dierks & Rescorla Standards Track [Page 25]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1352 unrecognized_name(112), /* new */
1353 bad_certificate_status_response(113), /* new */
1354 bad_certificate_hash_value(114), /* new */
1355 (255)
1356 } AlertDescription;
1358 struct {
1359 AlertLevel level;
1360 AlertDescription description;
1361 } Alert;
1363 7.2.1. Closure alerts
1365 The client and the server must share knowledge that the connection is
1366 ending in order to avoid a truncation attack. Either party may
1367 initiate the exchange of closing messages.
1369 close_notify
1370 This message notifies the recipient that the sender will not send
1371 any more messages on this connection. Note that as of TLS 1.1,
1372 failure to properly close a connection no longer requires that a
1373 session not be resumed. This is a change from TLS 1.0 to conform
1374 with widespread implementation practice.
1376 Either party may initiate a close by sending a close_notify alert.
1377 Any data received after a closure alert is ignored.
1379 Unless some other fatal alert has been transmitted, each party is
1380 required to send a close_notify alert before closing the write side
1381 of the connection. The other party MUST respond with a close_notify
1382 alert of its own and close down the connection immediately,
1383 discarding any pending writes. It is not required for the initiator
1384 of the close to wait for the responding close_notify alert before
1385 closing the read side of the connection.
1387 If the application protocol using TLS provides that any data may be
1388 carried over the underlying transport after the TLS connection is
1389 closed, the TLS implementation must receive the responding
1390 close_notify alert before indicating to the application layer that
1391 the TLS connection has ended. If the application protocol will not
1392 transfer any additional data, but will only close the underlying
1393 transport connection, then the implementation MAY choose to close the
1394 transport without waiting for the responding close_notify. No part of
1395 this standard should be taken to dictate the manner in which a usage
1396 profile for TLS manages its data transport, including when
1397 connections are opened or closed.
1399 Note: It is assumed that closing a connection reliably delivers
1403 Dierks & Rescorla Standards Track [Page 26]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1406 pending data before destroying the transport.
1408 7.2.2. Error alerts
1410 Error handling in the TLS Handshake protocol is very simple. When an
1411 error is detected, the detecting party sends a message to the other
1412 party. Upon transmission or receipt of an fatal alert message, both
1413 parties immediately close the connection. Servers and clients MUST
1414 forget any session-identifiers, keys, and secrets associated with a
1415 failed connection. Thus, any connection terminated with a fatal alert
1416 MUST NOT be resumed. The following error alerts are defined:
1418 unexpected_message
1419 An inappropriate message was received. This alert is always fatal
1420 and should never be observed in communication between proper
1421 implementations.
1423 bad_record_mac
1424 This alert is returned if a record is received with an incorrect
1425 MAC. This alert also MUST be returned if an alert is sent because
1426 a TLSCiphertext decrypted in an invalid way: either it wasn't an
1427 even multiple of the block length, or its padding values, when
1428 checked, weren't correct. This message is always fatal.
1430 decryption_failed
1431 This alert MAY be returned if a TLSCiphertext decrypted in an
1432 invalid way: either it wasn't an even multiple of the block
1433 length, or its padding values, when checked, weren't correct.
1434 This message is always fatal.
1436 Note: Differentiating between bad_record_mac and
1437 decryption_failed alerts may permit certain attacks against CBC
1438 mode as used in TLS [CBCATT]. It is preferable to uniformly use
1439 the bad_record_mac alert to hide the specific type of the error.
1442 record_overflow
1443 A TLSCiphertext record was received which had a length more than
1444 2^14+2048 bytes, or a record decrypted to a TLSCompressed record
1445 with more than 2^14+1024 bytes. This message is always fatal.
1447 decompression_failure
1448 The decompression function received improper input (e.g. data
1449 that would expand to excessive length). This message is always
1450 fatal.
1452 handshake_failure
1453 Reception of a handshake_failure alert message indicates that the
1457 Dierks & Rescorla Standards Track [Page 27]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1460 sender was unable to negotiate an acceptable set of security
1461 parameters given the options available. This is a fatal error.
1463 no_certificate_RESERVED
1464 This alert was used in SSLv3 but not in TLS. It should not be
1465 sent by compliant implementations.
1467 bad_certificate
1468 A certificate was corrupt, contained signatures that did not
1469 verify correctly, etc.
1471 unsupported_certificate
1472 A certificate was of an unsupported type.
1474 certificate_revoked
1475 A certificate was revoked by its signer.
1477 certificate_expired
1478 A certificate has expired or is not currently valid.
1480 certificate_unknown
1481 Some other (unspecified) issue arose in processing the
1482 certificate, rendering it unacceptable.
1484 illegal_parameter
1485 A field in the handshake was out of range or inconsistent with
1486 other fields. This is always fatal.
1488 unknown_ca
1489 A valid certificate chain or partial chain was received, but the
1490 certificate was not accepted because the CA certificate could not
1491 be located or couldn't be matched with a known, trusted CA. This
1492 message is always fatal.
1494 access_denied
1495 A valid certificate was received, but when access control was
1496 applied, the sender decided not to proceed with negotiation.
1497 This message is always fatal.
1499 decode_error
1500 A message could not be decoded because some field was out of the
1501 specified range or the length of the message was incorrect. This
1502 message is always fatal.
1504 decrypt_error
1505 A handshake cryptographic operation failed, including being
1506 unable to correctly verify a signature, decrypt a key exchange,
1507 or validate a finished message.
1511 Dierks & Rescorla Standards Track [Page 28]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1514 export_restriction_RESERVED
1515 This alert was used in TLS 1.0 but not TLS 1.1.
1517 protocol_version
1518 The protocol version the client has attempted to negotiate is
1519 recognized, but not supported. (For example, old protocol
1520 versions might be avoided for security reasons). This message is
1521 always fatal.
1523 insufficient_security
1524 Returned instead of handshake_failure when a negotiation has
1525 failed specifically because the server requires ciphers more
1526 secure than those supported by the client. This message is always
1527 fatal.
1529 internal_error
1530 An internal error unrelated to the peer or the correctness of the
1531 protocol makes it impossible to continue (such as a memory
1532 allocation failure). This message is always fatal.
1534 user_canceled
1535 This handshake is being canceled for some reason unrelated to a
1536 protocol failure. If the user cancels an operation after the
1537 handshake is complete, just closing the connection by sending a
1538 close_notify is more appropriate. This alert should be followed
1539 by a close_notify. This message is generally a warning.
1541 no_renegotiation
1542 Sent by the client in response to a hello request or by the
1543 server in response to a client hello after initial handshaking.
1544 Either of these would normally lead to renegotiation; when that
1545 is not appropriate, the recipient should respond with this alert;
1546 at that point, the original requester can decide whether to
1547 proceed with the connection. One case where this would be
1548 appropriate would be where a server has spawned a process to
1549 satisfy a request; the process might receive security parameters
1550 (key length, authentication, etc.) at startup and it might be
1551 difficult to communicate changes to these parameters after that
1552 point. This message is always a warning.
1554 The following error alerts apply only to the extensions described
1555 in Section XXX. To avoid "breaking" existing clients and servers,
1556 these alerts MUST NOT be sent unless the sending party has
1557 received an extended hello message from the party they are
1558 communicating with.
1560 unsupported_extension
1561 sent by clients that receive an extended server hello containing
1565 Dierks & Rescorla Standards Track [Page 29]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1568 an extension that they did not put in the corresponding client
1569 hello (see Section 2.3). This message is always fatal.
1571 unrecognized_name
1572 sent by servers that receive a server_name extension request, but
1573 do not recognize the server name. This message MAY be fatal.
1575 certificate_unobtainable
1576 sent by servers who are unable to retrieve a certificate chain
1577 from the URL supplied by the client (see Section 3.3). This
1578 message MAY be fatal - for example if client authentication is
1579 required by the server for the handshake to continue and the
1580 server is unable to retrieve the certificate chain, it may send a
1581 fatal alert.
1583 bad_certificate_status_response
1584 sent by clients that receive an invalid certificate status
1585 response (see Section 3.6). This message is always fatal.
1587 bad_certificate_hash_value
1588 sent by servers when a certificate hash does not match a client
1589 provided certificate_hash. This message is always fatal.
1591 For all errors where an alert level is not explicitly specified, the
1592 sending party MAY determine at its discretion whether this is a fatal
1593 error or not; if an alert with a level of warning is received, the
1594 receiving party MAY decide at its discretion whether to treat this as
1595 a fatal error or not. However, all messages which are transmitted
1596 with a level of fatal MUST be treated as fatal messages.
1598 New alerts values MUST be defined by RFC 2434 Standards Action. See
1599 Section 11 for IANA Considerations for alert values.
1601 7.3. Handshake Protocol overview
1603 The cryptographic parameters of the session state are produced by the
1604 TLS Handshake Protocol, which operates on top of the TLS Record
1605 Layer. When a TLS client and server first start communicating, they
1606 agree on a protocol version, select cryptographic algorithms,
1607 optionally authenticate each other, and use public-key encryption
1608 techniques to generate shared secrets.
1610 The TLS Handshake Protocol involves the following steps:
1612 - Exchange hello messages to agree on algorithms, exchange random
1613 values, and check for session resumption.
1615 - Exchange the necessary cryptographic parameters to allow the
1619 Dierks & Rescorla Standards Track [Page 30]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1622 client and server to agree on a premaster secret.
1624 - Exchange certificates and cryptographic information to allow the
1625 client and server to authenticate themselves.
1627 - Generate a master secret from the premaster secret and exchanged
1628 random values.
1630 - Provide security parameters to the record layer.
1632 - Allow the client and server to verify that their peer has
1633 calculated the same security parameters and that the handshake
1634 occurred without tampering by an attacker.
1636 Note that higher layers should not be overly reliant on TLS always
1637 negotiating the strongest possible connection between two peers:
1638 there are a number of ways a man in the middle attacker can attempt
1639 to make two entities drop down to the least secure method they
1640 support. The protocol has been designed to minimize this risk, but
1641 there are still attacks available: for example, an attacker could
1642 block access to the port a secure service runs on, or attempt to get
1643 the peers to negotiate an unauthenticated connection. The fundamental
1644 rule is that higher levels must be cognizant of what their security
1645 requirements are and never transmit information over a channel less
1646 secure than what they require. The TLS protocol is secure, in that
1647 any cipher suite offers its promised level of security: if you
1648 negotiate 3DES with a 1024 bit RSA key exchange with a host whose
1649 certificate you have verified, you can expect to be that secure.
1673 Dierks & Rescorla Standards Track [Page 31]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1676 However, you SHOULD never send data over a link encrypted with 40 bit
1677 security unless you feel that data is worth no more than the effort
1678 required to break that encryption.
1680 These goals are achieved by the handshake protocol, which can be
1681 summarized as follows: The client sends a client hello message to
1682 which the server must respond with a server hello message, or else a
1683 fatal error will occur and the connection will fail. The client hello
1684 and server hello are used to establish security enhancement
1685 capabilities between client and server. The client hello and server
1686 hello establish the following attributes: Protocol Version, Session
1687 ID, Cipher Suite, and Compression Method. Additionally, two random
1688 values are generated and exchanged: ClientHello.random and
1689 ServerHello.random.
1691 The actual key exchange uses up to four messages: the server
1692 certificate, the server key exchange, the client certificate, and the
1693 client key exchange. New key exchange methods can be created by
1694 specifying a format for these messages and defining the use of the
1695 messages to allow the client and server to agree upon a shared
1696 secret. This secret MUST be quite long; currently defined key
1697 exchange methods exchange secrets which range from 48 to 128 bytes in
1698 length.
1700 Following the hello messages, the server will send its certificate,
1701 if it is to be authenticated. Additionally, a server key exchange
1702 message may be sent, if it is required (e.g. if their server has no
1703 certificate, or if its certificate is for signing only). If the
1704 server is authenticated, it may request a certificate from the
1705 client, if that is appropriate to the cipher suite selected. Now the
1706 server will send the server hello done message, indicating that the
1707 hello-message phase of the handshake is complete. The server will
1708 then wait for a client response. If the server has sent a certificate
1709 request message, the client must send the certificate message. The
1710 client key exchange message is now sent, and the content of that
1711 message will depend on the public key algorithm selected between the
1712 client hello and the server hello. If the client has sent a
1713 certificate with signing ability, a digitally-signed certificate
1714 verify message is sent to explicitly verify the certificate.
1716 At this point, a change cipher spec message is sent by the client,
1717 and the client copies the pending Cipher Spec into the current Cipher
1718 Spec. The client then immediately sends the finished message under
1719 the new algorithms, keys, and secrets. In response, the server will
1720 send its own change cipher spec message, transfer the pending to the
1721 current Cipher Spec, and send its finished message under the new
1727 Dierks & Rescorla Standards Track [Page 32]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1730 Cipher Spec. At this point, the handshake is complete and the client
1731 and server may begin to exchange application layer data. (See flow
1732 chart below.) Application data MUST NOT be sent prior to the
1733 completion of the first handshake (before a cipher suite other
1734 TLS_NULL_WITH_NULL_NULL is established).
1735 Client Server
1737 ClientHello -------->
1738 ServerHello
1739 Certificate*
1740 CertificateStatus*
1741 ServerKeyExchange*
1742 CertificateRequest*
1743 <-------- ServerHelloDone
1744 Certificate*
1745 CertificateURL*
1746 ClientKeyExchange
1747 CertificateVerify*
1748 [ChangeCipherSpec]
1749 Finished -------->
1750 [ChangeCipherSpec]
1751 <-------- Finished
1752 Application Data <-------> Application Data
1754 Fig. 1 - Message flow for a full handshake
1756 * Indicates optional or situation-dependent messages that are not
1757 always sent.
1759 Note: To help avoid pipeline stalls, ChangeCipherSpec is an
1760 independent TLS Protocol content type, and is not actually a TLS
1761 handshake message.
1763 When the client and server decide to resume a previous session or
1764 duplicate an existing session (instead of negotiating new security
1765 parameters) the message flow is as follows:
1767 The client sends a ClientHello using the Session ID of the session to
1768 be resumed. The server then checks its session cache for a match. If
1769 a match is found, and the server is willing to re-establish the
1770 connection under the specified session state, it will send a
1771 ServerHello with the same Session ID value. At this point, both
1772 client and server MUST send change cipher spec messages and proceed
1773 directly to finished messages. Once the re-establishment is complete,
1774 the client and server MAY begin to exchange application layer data.
1775 (See flow chart below.) If a Session ID match is not found, the
1776 server generates a new session ID and the TLS client and server
1777 perform a full handshake.
1781 Dierks & Rescorla Standards Track [Page 33]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1784 Client Server
1786 ClientHello -------->
1787 ServerHello
1788 [ChangeCipherSpec]
1789 <-------- Finished
1790 [ChangeCipherSpec]
1791 Finished -------->
1792 Application Data <-------> Application Data
1794 Fig. 2 - Message flow for an abbreviated handshake
1796 The contents and significance of each message will be presented in
1797 detail in the following sections.
1799 7.4. Handshake protocol
1801 The TLS Handshake Protocol is one of the defined higher level clients
1802 of the TLS Record Protocol. This protocol is used to negotiate the
1803 secure attributes of a session. Handshake messages are supplied to
1804 the TLS Record Layer, where they are encapsulated within one or more
1805 TLSPlaintext structures, which are processed and transmitted as
1806 specified by the current active session state.
1808 enum {
1809 hello_request(0), client_hello(1), server_hello(2),
1810 certificate(11), server_key_exchange (12),
1811 certificate_request(13), server_hello_done(14),
1812 certificate_verify(15), client_key_exchange(16),
1813 finished(20), certificate_url(21), certificate_status(22),
1814 (255)
1815 } HandshakeType;
1817 struct {
1818 HandshakeType msg_type; /* handshake type */
1819 uint24 length; /* bytes in message */
1820 select (HandshakeType) {
1821 case hello_request: HelloRequest;
1822 case client_hello: ClientHello;
1823 case server_hello: ServerHello;
1824 case certificate: Certificate;
1825 case server_key_exchange: ServerKeyExchange;
1826 case certificate_request: CertificateRequest;
1827 case server_hello_done: ServerHelloDone;
1828 case certificate_verify: CertificateVerify;
1829 case client_key_exchange: ClientKeyExchange;
1830 case finished: Finished;
1831 case certificate_url: CertificateURL;
1835 Dierks & Rescorla Standards Track [Page 34]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1838 case certificate_status: CertificateStatus;
1839 } body;
1840 } Handshake;
1842 The handshake protocol messages are presented below in the order they
1843 MUST be sent; sending handshake messages in an unexpected order
1844 results in a fatal error. Unneeded handshake messages can be omitted,
1845 however. Note one exception to the ordering: the Certificate message
1846 is used twice in the handshake (from server to client, then from
1847 client to server), but described only in its first position. The one
1848 message which is not bound by these ordering rules is the Hello
1849 Request message, which can be sent at any time, but which should be
1850 ignored by the client if it arrives in the middle of a handshake.
1852 New Handshake message type values MUST be defined via RFC 2434
1853 Standards Action. See Section 11 for IANA Considerations for these
1854 values.
1856 7.4.1. Hello messages
1858 The hello phase messages are used to exchange security enhancement
1859 capabilities between the client and server. When a new session
1860 begins, the Record Layer's connection state encryption, hash, and
1861 compression algorithms are initialized to null. The current
1862 connection state is used for renegotiation messages.
1864 7.4.1.1. Hello request
1866 When this message will be sent:
1867 The hello request message MAY be sent by the server at any time.
1869 Meaning of this message:
1870 Hello request is a simple notification that the client should
1871 begin the negotiation process anew by sending a client hello
1872 message when convenient. This message will be ignored by the
1873 client if the client is currently negotiating a session. This
1874 message may be ignored by the client if it does not wish to
1875 renegotiate a session, or the client may, if it wishes, respond
1876 with a no_renegotiation alert. Since handshake messages are
1877 intended to have transmission precedence over application data,
1878 it is expected that the negotiation will begin before no more
1879 than a few records are received from the client. If the server
1880 sends a hello request but does not receive a client hello in
1881 response, it may close the connection with a fatal alert.
1883 After sending a hello request, servers SHOULD not repeat the request
1884 until the subsequent handshake negotiation is complete.
1889 Dierks & Rescorla Standards Track [Page 35]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1892 Structure of this message:
1893 struct { } HelloRequest;
1895 Note: This message MUST NOT be included in the message hashes which are
1896 maintained throughout the handshake and used in the finished
1897 messages and the certificate verify message.
1899 7.4.1.2. Client hello
1901 When this message will be sent:
1902 When a client first connects to a server it is required to send
1903 the client hello as its first message. The client can also send a
1904 client hello in response to a hello request or on its own
1905 initiative in order to renegotiate the security parameters in an
1906 existing connection.
1908 Structure of this message:
1909 The client hello message includes a random structure, which is
1910 used later in the protocol.
1912 struct {
1913 uint32 gmt_unix_time;
1914 opaque random_bytes[28];
1915 } Random;
1917 gmt_unix_time
1918 The current time and date in standard UNIX 32-bit format (seconds
1919 since the midnight starting Jan 1, 1970, GMT, ignoring leap
1920 seconds) according to the sender's internal clock. Clocks are not
1921 required to be set correctly by the basic TLS Protocol; higher
1922 level or application protocols may define additional
1923 requirements.
1925 random_bytes
1926 28 bytes generated by a secure random number generator.
1928 The client hello message includes a variable length session
1929 identifier. If not empty, the value identifies a session between the
1930 same client and server whose security parameters the client wishes to
1931 reuse. The session identifier MAY be from an earlier connection, this
1932 connection, or another currently active connection. The second option
1933 is useful if the client only wishes to update the random structures
1934 and derived values of a connection, while the third option makes it
1935 possible to establish several independent secure connections without
1936 repeating the full handshake protocol. These independent connections
1937 may occur sequentially or simultaneously; a SessionID becomes valid
1938 when the handshake negotiating it completes with the exchange of
1939 Finished messages and persists until removed due to aging or because
1943 Dierks & Rescorla Standards Track [Page 36]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
1946 a fatal error was encountered on a connection associated with the
1947 session. The actual contents of the SessionID are defined by the
1948 server.
1950 opaque SessionID<0..32>;
1952 Warning:
1953 Because the SessionID is transmitted without encryption or
1954 immediate MAC protection, servers MUST not place confidential
1955 information in session identifiers or let the contents of fake
1956 session identifiers cause any breach of security. (Note that the
1957 content of the handshake as a whole, including the SessionID, is
1958 protected by the Finished messages exchanged at the end of the
1959 handshake.)
1961 The CipherSuite list, passed from the client to the server in the
1962 client hello message, contains the combinations of cryptographic
1963 algorithms supported by the client in order of the client's
1964 preference (favorite choice first). Each CipherSuite defines a key
1965 exchange algorithm, a bulk encryption algorithm (including secret key
1966 length) and a MAC algorithm. The server will select a cipher suite
1967 or, if no acceptable choices are presented, return a handshake
1968 failure alert and close the connection.
1970 uint8 CipherSuite[2]; /* Cryptographic suite selector */
1972 The client hello includes a list of compression algorithms supported
1973 by the client, ordered according to the client's preference.
1975 enum { null(0), (255) } CompressionMethod;
1977 struct {
1978 ProtocolVersion client_version;
1979 Random random;
1980 SessionID session_id;
1981 CipherSuite cipher_suites<2..2^16-1>;
1982 CompressionMethod compression_methods<1..2^8-1>;
1983 } ClientHello;
1985 If the client wishes to use extensions (see Section XXX),
1986 it may send an ExtendedClientHello:
1988 struct {
1989 ProtocolVersion client_version;
1990 Random random;
1991 SessionID session_id;
1992 CipherSuite cipher_suites<2..2^16-1>;
1993 CompressionMethod compression_methods<1..2^8-1>;
1997 Dierks & Rescorla Standards Track [Page 37]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2000 Extension client_hello_extension_list<0..2^16-1>;
2001 } ExtendedClientHello;
2003 These two messages can be distinguished by determining whether there
2004 are bytes following what would be the end of the ClientHello.
2007 client_version
2008 The version of the TLS protocol by which the client wishes to
2009 communicate during this session. This SHOULD be the latest
2010 (highest valued) version supported by the client. For this
2011 version of the specification, the version will be 3.2 (See
2012 Appendix E for details about backward compatibility).
2014 random
2015 A client-generated random structure.
2017 session_id
2018 The ID of a session the client wishes to use for this connection.
2019 This field should be empty if no session_id is available or the
2020 client wishes to generate new security parameters.
2022 cipher_suites
2023 This is a list of the cryptographic options supported by the
2024 client, with the client's first preference first. If the
2025 session_id field is not empty (implying a session resumption
2026 request) this vector MUST include at least the cipher_suite from
2027 that session. Values are defined in Appendix A.5.
2029 compression_methods
2030 This is a list of the compression methods supported by the
2031 client, sorted by client preference. If the session_id field is
2032 not empty (implying a session resumption request) it must include
2033 the compression_method from that session. This vector must
2034 contain, and all implementations must support,
2035 CompressionMethod.null. Thus, a client and server will always be
2036 able to agree on a compression method.
2038 client_hello_extension_list
2039 Clients MAY request extended functionality from servers by
2040 sending data in the client_hello_extension_list. Here the new
2041 "client_hello_extension_list" field contains a list of
2042 extensions. The actual "Extension" format is defined in Section
2043 XXX.
2045 In the event that a client requests additional functionality
2046 using the extended client hello, and this functionality is not
2047 supplied by the server, the client MAY abort the handshake.
2051 Dierks & Rescorla Standards Track [Page 38]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2054 A server that supports the extensions mechanism MUST accept only
2055 client hello messages in either the original or extended
2056 ClientHello ormat, and (as for all other messages) MUST check
2057 that the amount of data in the message precisely matches one of
2058 these formats; if not then it MUST send a fatal "decode_error"
2059 alert.
2062 After sending the client hello message, the client waits for a server
2063 hello message. Any other handshake message returned by the server
2064 except for a hello request is treated as a fatal error.
2067 7.4.1.3. Server hello
2069 When this message will be sent:
2070 The server will send this message in response to a client hello
2071 message when it was able to find an acceptable set of algorithms. If
2072 it cannot find such a match, it will respond with a handshake failure
2073 alert.
2075 Structure of this message:
2076 struct {
2077 ProtocolVersion server_version;
2078 Random random;
2079 SessionID session_id;
2080 CipherSuite cipher_suite;
2081 CompressionMethod compression_method;
2082 } ServerHello;
2084 If the server is sending an extension, it should use the
2085 ExtendedServerHello:
2087 struct {
2088 ProtocolVersion server_version;
2089 Random random;
2090 SessionID session_id;
2091 CipherSuite cipher_suite;
2092 CompressionMethod compression_method;
2093 Extension server_hello_extension_list<0..2^16-1>;
2094 } ExtendedServerHello;
2096 These two messages can be distinguished by determining whether there
2097 are bytes following what would be the end of the ServerHello.
2105 Dierks & Rescorla Standards Track [Page 39]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2108 server_version
2109 This field will contain the lower of that suggested by the client in
2110 the client hello and the highest supported by the server. For this
2111 version of the specification, the version is 3.2 (See Appendix E for
2112 details about backward compatibility).
2114 random
2115 This structure is generated by the server and MUST be independently
2116 generated from the ClientHello.random.
2118 session_id
2119 This is the identity of the session corresponding to this connection.
2120 If the ClientHello.session_id was non-empty, the server will look in
2121 its session cache for a match. If a match is found and the server is
2122 willing to establish the new connection using the specified session
2123 state, the server will respond with the same value as was supplied by
2124 the client. This indicates a resumed session and dictates that the
2125 parties must proceed directly to the finished messages. Otherwise
2126 this field will contain a different value identifying the new
2127 session. The server may return an empty session_id to indicate that
2128 the session will not be cached and therefore cannot be resumed. If a
2129 session is resumed, it must be resumed using the same cipher suite it
2130 was originally negotiated with.
2132 cipher_suite
2133 The single cipher suite selected by the server from the list in
2134 ClientHello.cipher_suites. For resumed sessions this field is the
2135 value from the state of the session being resumed.
2137 compression_method
2138 The single compression algorithm selected by the server from the list
2139 in ClientHello.compression_methods. For resumed sessions this field
2140 is the value from the resumed session state.
2142 server_hello_extension_list
2143 A list of extensions. Note that only extensions offered by the client
2144 can appear in the server's list.
2146 7.4.1.4 Hello Extensions
2148 The extension format for extended client hellos and extended server
2149 hellos is:
2151 struct {
2152 ExtensionType extension_type;
2153 opaque extension_data<0..2^16-1>;
2154 } Extension;
2159 Dierks & Rescorla Standards Track [Page 40]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2162 Here:
2164 - "extension_type" identifies the particular extension type.
2166 - "extension_data" contains information specific to the particular
2167 extension type.
2169 The extension types defined in this document are:
2171 enum {
2172 server_name(0), max_fragment_length(1),
2173 client_certificate_url(2), trusted_ca_keys(3),
2174 truncated_hmac(4), status_request(5),
2175 cert_hash_types(6), (65535)
2176 } ExtensionType;
2178 The list of defined extension types is maintained by the IANA. The
2179 current list can be found at XXX (suggest
2180 http://www.iana.org/assignments/tls-extensions). See sections XXX and
2181 YYY for more information on how new values are added.
2184 Note that for all extension types (including those defined in
2185 future), the extension type MUST NOT appear in the extended server
2186 hello unless the same extension type appeared in the corresponding
2187 client hello. Thus clients MUST abort the handshake if they receive
2188 an extension type in the extended server hello that they did not
2189 request in the associated (extended) client hello.
2191 Nonetheless "server oriented" extensions may be provided in the
2192 future within this framework - such an extension, say of type x,
2193 would require the client to first send an extension of type x in the
2194 (extended) client hello with empty extension_data to indicate that it
2195 supports the extension type. In this case the client is offering the
2196 capability to understand the extension type, and the server is taking
2197 the client up on its offer.
2199 Also note that when multiple extensions of different types are
2200 present in the extended client hello or the extended server hello,
2201 the extensions may appear in any order. There MUST NOT be more than
2202 one extension of the same type.
2204 An extended client hello may be sent both when starting a new session
2205 and when requesting session resumption. Indeed a client that
2206 requests resumption of a session does not in general know whether the
2207 server will accept this request, and therefore it SHOULD send an
2208 extended client hello if it would normally do so for a new session.
2209 In general the specification of each extension type must include a
2213 Dierks & Rescorla Standards Track [Page 41]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2216 discussion of the effect of the extension both during new sessions
2217 and during resumed sessions.
2219 Note also that all the extensions defined in this document are
2220 relevant only when a session is initiated. When a client includes one
2221 or more of the defined extension types in an extended client hello
2222 while requesting session resumption:
2224 - If the resumption request is denied, the use of the extensions
2225 is negotiated as normal.
2227 - If, on the other hand, the older session is resumed, then the
2228 server MUST ignore the extensions and send a server hello
2229 containing none of the extension types; in this case the
2230 functionality of these extensions negotiated during the original
2231 session initiation is applied to the resumed session.
2233 7.4.1.4.1 Server Name Indication
2235 [TLS1.1] does not provide a mechanism for a client to tell a server
2236 the name of the server it is contacting. It may be desirable for
2237 clients to provide this information to facilitate secure connections
2238 to servers that host multiple 'virtual' servers at a single
2239 underlying network address.
2241 In order to provide the server name, clients MAY include an extension
2242 of type "server_name" in the (extended) client hello. The
2243 "extension_data" field of this extension SHALL contain
2244 "ServerNameList" where:
2246 struct {
2247 NameType name_type;
2248 select (name_type) {
2249 case host_name: HostName;
2250 } name;
2251 } ServerName;
2253 enum {
2254 host_name(0), (255)
2255 } NameType;
2257 opaque HostName<1..2^16-1>;
2259 struct {
2260 ServerName server_name_list<1..2^16-1>
2261 } ServerNameList;
2263 Currently the only server names supported are DNS hostnames, however
2267 Dierks & Rescorla Standards Track [Page 42]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2270 this does not imply any dependency of TLS on DNS, and other name
2271 types may be added in the future (by an RFC that Updates this
2272 document). TLS MAY treat provided server names as opaque data and
2273 pass the names and types to the application.
2275 "HostName" contains the fully qualified DNS hostname of the server,
2276 as understood by the client. The hostname is represented as a byte
2277 string using UTF-8 encoding [UTF8], without a trailing dot.
2279 If the hostname labels contain only US-ASCII characters, then the
2280 client MUST ensure that labels are separated only by the byte 0x2E,
2281 representing the dot character U+002E (requirement 1 in section 3.1
2282 of [IDNA] notwithstanding). If the server needs to match the HostName
2283 against names that contain non-US-ASCII characters, it MUST perform
2284 the conversion operation described in section 4 of [IDNA], treating
2285 the HostName as a "query string" (i.e. the AllowUnassigned flag MUST
2286 be set). Note that IDNA allows labels to be separated by any of the
2287 Unicode characters U+002E, U+3002, U+FF0E, and U+FF61, therefore
2288 servers MUST accept any of these characters as a label separator. If
2289 the server only needs to match the HostName against names containing
2290 exclusively ASCII characters, it MUST compare ASCII names case-
2291 insensitively.
2293 Literal IPv4 and IPv6 addresses are not permitted in "HostName". It
2294 is RECOMMENDED that clients include an extension of type
2295 "server_name" in the client hello whenever they locate a server by a
2296 supported name type.
2298 A server that receives a client hello containing the "server_name"
2299 extension, MAY use the information contained in the extension to
2300 guide its selection of an appropriate certificate to return to the
2301 client, and/or other aspects of security policy. In this event, the
2302 server SHALL include an extension of type "server_name" in the
2303 (extended) server hello. The "extension_data" field of this
2304 extension SHALL be empty.
2306 If the server understood the client hello extension but does not
2307 recognize the server name, it SHOULD send an "unrecognized_name"
2308 alert (which MAY be fatal).
2310 If an application negotiates a server name using an application
2311 protocol, then upgrades to TLS, and a server_name extension is sent,
2312 then the extension SHOULD contain the same name that was negotiated
2313 in the application protocol. If the server_name is established in
2314 the TLS session handshake, the client SHOULD NOT attempt to request a
2315 different server name at the application layer.
2317 7.4.1.4.2 Maximum Fragment Length Negotiation
2321 Dierks & Rescorla Standards Track [Page 43]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2324 By default, TLS uses fixed maximum plaintext fragment length of 2^14
2325 bytes. It may be desirable for constrained clients to negotiate a
2326 smaller maximum fragment length due to memory limitations or
2327 bandwidth limitations.
2329 In order to negotiate smaller maximum fragment lengths, clients MAY
2330 include an extension of type "max_fragment_length" in the (extended)
2331 client hello. The "extension_data" field of this extension SHALL
2332 contain:
2334 enum{
2335 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
2336 } MaxFragmentLength;
2338 whose value is the desired maximum fragment length. The allowed
2339 values for this field are: 2^9, 2^10, 2^11, and 2^12.
2341 Servers that receive an extended client hello containing a
2342 "max_fragment_length" extension, MAY accept the requested maximum
2343 fragment length by including an extension of type
2344 "max_fragment_length" in the (extended) server hello. The
2345 "extension_data" field of this extension SHALL contain
2346 "MaxFragmentLength" whose value is the same as the requested maximum
2347 fragment length.
2349 If a server receives a maximum fragment length negotiation request
2350 for a value other than the allowed values, it MUST abort the
2351 handshake with an "illegal_parameter" alert. Similarly, if a client
2352 receives a maximum fragment length negotiation response that differs
2353 from the length it requested, it MUST also abort the handshake with
2354 an "illegal_parameter" alert.
2356 Once a maximum fragment length other than 2^14 has been successfully
2357 negotiated, the client and server MUST immediately begin fragmenting
2358 messages (including handshake messages), to ensure that no fragment
2359 larger than the negotiated length is sent. Note that TLS already
2360 requires clients and servers to support fragmentation of handshake
2361 messages.
2363 The negotiated length applies for the duration of the session
2364 including session resumptions.
2366 The negotiated length limits the input that the record layer may
2367 process without fragmentation (that is, the maximum value of
2368 TLSPlaintext.length; see [TLS] section 6.2.1). Note that the output
2369 of the record layer may be larger. For example, if the negotiated
2370 length is 2^9=512, then for currently defined cipher suites and when
2371 null compression is used, the record layer output can be at most 793
2375 Dierks & Rescorla Standards Track [Page 44]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2378 bytes: 5 bytes of headers, 512 bytes of application data, 256 bytes
2379 of padding, and 20 bytes of MAC. That means that in this event a TLS
2380 record layer peer receiving a TLS record layer message larger than
2381 793 bytes may discard the message and send a "record_overflow" alert,
2382 without decrypting the message.
2384 7.4.1.4.3 Client Certificate URLs
2386 Ordinarily, when client authentication is performed, client
2387 certificates are sent by clients to servers during the TLS handshake.
2388 It may be desirable for constrained clients to send certificate URLs
2389 in place of certificates, so that they do not need to store their
2390 certificates and can therefore save memory.
2392 In order to negotiate to send certificate URLs to a server, clients
2393 MAY include an extension of type "client_certificate_url" in the
2394 (extended) client hello. The "extension_data" field of this
2395 extension SHALL be empty.
2397 (Note that it is necessary to negotiate use of client certificate
2398 URLs in order to avoid "breaking" existing TLS 1.0 servers.)
2400 Servers that receive an extended client hello containing a
2401 "client_certificate_url" extension, MAY indicate that they are
2402 willing to accept certificate URLs by including an extension of type
2403 "client_certificate_url" in the (extended) server hello. The
2404 "extension_data" field of this extension SHALL be empty.
2406 After negotiation of the use of client certificate URLs has been
2407 successfully completed (by exchanging hellos including
2408 "client_certificate_url" extensions), clients MAY send a
2409 "CertificateURL" message in place of a "Certificate" message. See
2410 Section XXX.
2412 7.4.1.4.4 Trusted CA Indication
2414 Constrained clients that, due to memory limitations, possess only a
2415 small number of CA root keys, may wish to indicate to servers which
2416 root keys they possess, in order to avoid repeated handshake
2417 failures.
2419 In order to indicate which CA root keys they possess, clients MAY
2420 include an extension of type "trusted_ca_keys" in the (extended)
2421 client hello. The "extension_data" field of this extension SHALL
2422 contain "TrustedAuthorities" where:
2424 struct {
2425 TrustedAuthority trusted_authorities_list<0..2^16-1>;
2429 Dierks & Rescorla Standards Track [Page 45]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2432 } TrustedAuthorities;
2434 struct {
2435 IdentifierType identifier_type;
2436 select (identifier_type) {
2437 case pre_agreed: struct {};
2438 case key_sha1_hash: SHA1Hash;
2439 case x509_name: DistinguishedName;
2440 case cert_sha1_hash: SHA1Hash;
2441 } identifier;
2442 } TrustedAuthority;
2444 enum {
2445 pre_agreed(0), key_sha1_hash(1), x509_name(2),
2446 cert_sha1_hash(3), (255)
2447 } IdentifierType;
2449 opaque DistinguishedName<1..2^16-1>;
2451 Here "TrustedAuthorities" provides a list of CA root key identifiers
2452 that the client possesses. Each CA root key is identified via
2453 either:
2455 - "pre_agreed" - no CA root key identity supplied.
2457 - "key_sha1_hash" - contains the SHA-1 hash of the CA root key.
2458 For
2459 DSA and ECDSA keys, this is the hash of the "subjectPublicKey"
2460 value. For RSA keys, the hash is of the big-endian byte string
2461 representation of the modulus without any initial 0-valued bytes.
2462 (This copies the key hash formats deployed in other
2463 environments.)
2465 - "x509_name" - contains the DER-encoded X.509 DistinguishedName
2466 of
2467 the CA.
2469 - "cert_sha1_hash" - contains the SHA-1 hash of a DER-encoded
2470 Certificate containing the CA root key.
2472 Note that clients may include none, some, or all of the CA root keys
2473 they possess in this extension.
2475 Note also that it is possible that a key hash or a Distinguished Name
2476 alone may not uniquely identify a certificate issuer - for example if
2477 a particular CA has multiple key pairs - however here we assume this
2478 is the case following the use of Distinguished Names to identify
2479 certificate issuers in TLS.
2483 Dierks & Rescorla Standards Track [Page 46]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2486 The option to include no CA root keys is included to allow the client
2487 to indicate possession of some pre-defined set of CA root keys.
2489 Servers that receive a client hello containing the "trusted_ca_keys"
2490 extension, MAY use the information contained in the extension to
2491 guide their selection of an appropriate certificate chain to return
2492 to the client. In this event, the server SHALL include an extension
2493 of type "trusted_ca_keys" in the (extended) server hello. The
2494 "extension_data" field of this extension SHALL be empty.
2496 7.4.1.4.5 Truncated HMAC
2498 Currently defined TLS cipher suites use the MAC construction HMAC
2499 with either MD5 or SHA-1 [HMAC] to authenticate record layer
2500 communications. In TLS the entire output of the hash function is
2501 used as the MAC tag. However it may be desirable in constrained
2502 environments to save bandwidth by truncating the output of the hash
2503 function to 80 bits when forming MAC tags.
2505 In order to negotiate the use of 80-bit truncated HMAC, clients MAY
2506 include an extension of type "truncated_hmac" in the extended client
2507 hello. The "extension_data" field of this extension SHALL be empty.
2509 Servers that receive an extended hello containing a "truncated_hmac"
2510 extension, MAY agree to use a truncated HMAC by including an
2511 extension of type "truncated_hmac", with empty "extension_data", in
2512 the extended server hello.
2514 Note that if new cipher suites are added that do not use HMAC, and
2515 the session negotiates one of these cipher suites, this extension
2516 will have no effect. It is strongly recommended that any new cipher
2517 suites using other MACs consider the MAC size as an integral part of
2518 the cipher suite definition, taking into account both security and
2519 bandwidth considerations.
2521 If HMAC truncation has been successfully negotiated during a TLS
2522 handshake, and the negotiated cipher suite uses HMAC, both the client
2523 and the server pass this fact to the TLS record layer along with the
2524 other negotiated security parameters. Subsequently during the
2525 session, clients and servers MUST use truncated HMACs, calculated as
2526 specified in [HMAC]. That is, CipherSpec.hash_size is 10 bytes, and
2527 only the first 10 bytes of the HMAC output are transmitted and
2528 checked. Note that this extension does not affect the calculation of
2529 the PRF as part of handshaking or key derivation.
2531 The negotiated HMAC truncation size applies for the duration of the
2532 session including session resumptions.
2537 Dierks & Rescorla Standards Track [Page 47]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2540 7.4.1.4.6 Certificate Status Request
2542 Constrained clients may wish to use a certificate-status protocol
2543 such as OCSP [OCSP] to check the validity of server certificates, in
2544 order to avoid transmission of CRLs and therefore save bandwidth on
2545 constrained networks. This extension allows for such information to
2546 be sent in the TLS handshake, saving roundtrips and resources.
2548 In order to indicate their desire to receive certificate status
2549 information, clients MAY include an extension of type
2550 "status_request" in the (extended) client hello. The
2551 "extension_data" field of this extension SHALL contain
2552 "CertificateStatusRequest" where:
2554 struct {
2555 CertificateStatusType status_type;
2556 select (status_type) {
2557 case ocsp: OCSPStatusRequest;
2558 } request;
2559 } CertificateStatusRequest;
2561 enum { ocsp(1), (255) } CertificateStatusType;
2563 struct {
2564 ResponderID responder_id_list<0..2^16-1>;
2565 Extensions request_extensions;
2566 } OCSPStatusRequest;
2568 opaque ResponderID<1..2^16-1>;
2570 In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
2571 responders that the client trusts. A zero-length "responder_id_list"
2572 sequence has the special meaning that the responders are implicitly
2573 known to the server - e.g., by prior arrangement. "Extensions" is a
2574 DER encoding of OCSP request extensions.
2576 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
2577 defined in [OCSP]. "Extensions" is imported from [PKIX]. A zero-
2578 length "request_extensions" value means that there are no extensions
2579 (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for
2580 the "Extensions" type).
2582 In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is
2583 unclear about its encoding; for clarification, the nonce MUST be a
2584 DER-encoded OCTET STRING, which is encapsulated as another OCTET
2585 STRING (note that implementations based on an existing OCSP client
2586 will need to be checked for conformance to this requirement).
2591 Dierks & Rescorla Standards Track [Page 48]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2594 Servers that receive a client hello containing the "status_request"
2595 extension, MAY return a suitable certificate status response to the
2596 client along with their certificate. If OCSP is requested, they
2597 SHOULD use the information contained in the extension when selecting
2598 an OCSP responder, and SHOULD include request_extensions in the OCSP
2599 request.
2601 Servers return a certificate response along with their certificate by
2602 sending a "CertificateStatus" message immediately after the
2603 "Certificate" message (and before any "ServerKeyExchange" or
2604 "CertificateRequest" messages). Section XXX describes the
2605 CertificateStatus message.
2607 7.4.1.4.7 Cert Hash Types
2609 The client MAY use the "cert_hash_types" to indicate to the server
2610 which hash functions may be used in the signature on the server's
2611 certificate. The "extension_data" field of this extension contains:
2613 enum{
2614 md5(0), sha1(1), sha256(2), sha512(3), (255)
2615 } HashType;
2617 struct {
2618 HashType<255> types;
2619 } CertHashTypes;
2621 These values indicate support for MD5 [MD5], SHA-1, SHA-256, and
2622 SHA-512 [SHA] respectively. The server MUST NOT send this extension.
2624 Clients SHOULD send this extension if they support any algorithm
2625 other than SHA-1. If this extension is not used, servers SHOULD
2626 assume that the client supports only SHA-1. Note: this is a change
2627 from TLS 1.1 where there are no explicit rules but as a practical
2628 matter one can assume that the peer supports MD5 and SHA-1.
2630 HashType values are divided into three groups:
2632 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
2633 reserved for IETF Standards Track protocols.
2635 2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive
2636 are reserved for assignment for non-Standards Track methods.
2638 3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
2639 inclusive are reserved for private use.
2641 Additional information describing the role of IANA in the
2645 Dierks & Rescorla Standards Track [Page 49]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2648 allocation of HashType code points is described
2649 in Section 11.
2652 7.4.1.4.8 Procedure for Defining New Extensions
2654 The list of extension types, as defined in Section 2.3, is
2655 maintained by the Internet Assigned Numbers Authority (IANA). Thus
2656 an application needs to be made to the IANA in order to obtain a new
2657 extension type value. Since there are subtle (and not so subtle)
2658 interactions that may occur in this protocol between new features and
2659 existing features which may result in a significant reduction in
2660 overall security, new values SHALL be defined only through the IETF
2661 Consensus process specified in [IANA].
2663 (This means that new assignments can be made only via RFCs approved
2664 by the IESG.)
2666 The following considerations should be taken into account when
2667 designing new extensions:
2669 - All of the extensions defined in this document follow the
2670 convention that for each extension that a client requests and that
2671 the server understands, the server replies with an extension of
2672 the same type.
2674 - Some cases where a server does not agree to an extension are error
2675 conditions, and some simply a refusal to support a particular
2676 feature. In general error alerts should be used for the former,
2677 and a field in the server extension response for the latter.
2679 - Extensions should as far as possible be designed to prevent any
2680 attack that forces use (or non-use) of a particular feature by
2681 manipulation of handshake messages. This principle should be
2682 followed regardless of whether the feature is believed to cause a
2683 security problem.
2685 Often the fact that the extension fields are included in the
2686 inputs to the Finished message hashes will be sufficient, but
2687 extreme care is needed when the extension changes the meaning of
2688 messages sent in the handshake phase. Designers and implementors
2689 should be aware of the fact that until the handshake has been
2690 authenticated, active attackers can modify messages and insert,
2691 remove, or replace extensions.
2693 - It would be technically possible to use extensions to change major
2694 aspects of the design of TLS; for example the design of cipher
2695 suite negotiation. This is not recommended; it would be more
2699 Dierks & Rescorla Standards Track [Page 50]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2702 appropriate to define a new version of TLS - particularly since
2703 the TLS handshake algorithms have specific protection against
2704 version rollback attacks based on the version number, and the
2705 possibility of version rollback should be a significant
2706 consideration in any major design change.
2709 7.4.2. Server certificate
2711 When this message will be sent:
2712 The server MUST send a certificate whenever the agreed-upon key
2713 exchange method is not an anonymous one. This message will
2714 always immediately follow the server hello message.
2716 Meaning of this message:
2717 The certificate type MUST be appropriate for the selected cipher
2718 suite's key exchange algorithm, and is generally an X.509v3
2719 certificate. It MUST contain a key which matches the key
2720 exchange method, as follows. Unless otherwise specified, the
2721 signing
2722 algorithm for the certificate MUST be the same as the
2723 algorithm for the certificate key. Unless otherwise specified,
2724 the public key MAY be of any length.
2726 Key Exchange Algorithm Certificate Key Type
2728 RSA RSA public key; the certificate MUST
2729 allow the key to be used for encryption.
2731 DHE_DSS DSS public key.
2733 DHE_RSA RSA public key which can be used for
2734 signing.
2736 DH_DSS Diffie-Hellman key. The algorithm used
2737 to sign the certificate MUST be DSS.
2739 DH_RSA Diffie-Hellman key. The algorithm used
2740 to sign the certificate MUST be RSA.
2742 All certificate profiles, key and cryptographic formats are defined
2743 by the IETF PKIX working group [PKIX]. When a key usage extension is
2744 present, the digitalSignature bit MUST be set for the key to be
2745 eligible for signing, as described above, and the keyEncipherment bit
2746 MUST be present to allow encryption, as described above. The
2747 keyAgreement bit must be set on Diffie-Hellman certificates.
2749 As CipherSuites which specify new key exchange methods are specified
2753 Dierks & Rescorla Standards Track [Page 51]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2756 for the TLS Protocol, they will imply certificate format and the
2757 required encoded keying information.
2759 Structure of this message:
2760 opaque ASN.1Cert<1..2^24-1>;
2762 struct {
2763 ASN.1Cert certificate_list<0..2^24-1>;
2764 } Certificate;
2766 certificate_list
2767 This is a sequence (chain) of X.509v3 certificates. The sender's
2768 certificate must come first in the list. Each following
2769 certificate must directly certify the one preceding it. Because
2770 certificate validation requires that root keys be distributed
2771 independently, the self-signed certificate which specifies the
2772 root certificate authority may optionally be omitted from the
2773 chain, under the assumption that the remote end must already
2774 possess it in order to validate it in any case.
2776 The same message type and structure will be used for the client's
2777 response to a certificate request message. Note that a client MAY
2778 send no certificates if it does not have an appropriate certificate
2779 to send in response to the server's authentication request.
2781 Note: PKCS #7 [PKCS7] is not used as the format for the certificate
2782 vector because PKCS #6 [PKCS6] extended certificates are not
2783 used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
2784 the task of parsing the list more difficult.
2786 7.4.3. Server key exchange message
2788 When this message will be sent:
2789 This message will be sent immediately after the server
2790 certificate message (or the server hello message, if this is an
2791 anonymous negotiation).
2793 The server key exchange message is sent by the server only when
2794 the server certificate message (if sent) does not contain enough
2795 data to allow the client to exchange a premaster secret. This is
2796 true for the following key exchange methods:
2798 DHE_DSS
2799 DHE_RSA
2800 DH_anon
2802 It is not legal to send the server key exchange message for the
2803 following key exchange methods:
2807 Dierks & Rescorla Standards Track [Page 52]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2810 RSA
2811 DH_DSS
2812 DH_RSA
2814 Meaning of this message:
2815 This message conveys cryptographic information to allow the
2816 client to communicate the premaster secret: either an RSA public
2817 key to encrypt the premaster secret with, or a Diffie-Hellman
2818 public key with which the client can complete a key exchange
2819 (with the result being the premaster secret.)
2821 As additional CipherSuites are defined for TLS which include new key
2822 exchange algorithms, the server key exchange message will be sent if
2823 and only if the certificate type associated with the key exchange
2824 algorithm does not provide enough information for the client to
2825 exchange a premaster secret.
2827 If the SignatureAlgorithm being used to sign the ServerKeyExchange
2828 message is DSA, the hash function used MUST be SHA-1. If the
2829 SignatureAlgorithm it must be the same hash function used in the
2830 signature of the server's certificate (found in the Certificate)
2831 message. This algorithm is denoted Hash below. Hash.length is the
2832 length of the output of that algorithm.
2834 Structure of this message:
2835 enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
2837 struct {
2838 opaque rsa_modulus<1..2^16-1>;
2839 opaque rsa_exponent<1..2^16-1>;
2840 } ServerRSAParams;
2842 rsa_modulus
2843 The modulus of the server's temporary RSA key.
2845 rsa_exponent
2846 The public exponent of the server's temporary RSA key.
2848 struct {
2849 opaque dh_p<1..2^16-1>;
2850 opaque dh_g<1..2^16-1>;
2851 opaque dh_Ys<1..2^16-1>;
2852 } ServerDHParams; /* Ephemeral DH parameters */
2854 dh_p
2855 The prime modulus used for the Diffie-Hellman operation.
2857 dh_g
2861 Dierks & Rescorla Standards Track [Page 53]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2864 The generator used for the Diffie-Hellman operation.
2866 dh_Ys
2867 The server's Diffie-Hellman public value (g^X mod p).
2869 struct {
2870 select (KeyExchangeAlgorithm) {
2871 case diffie_hellman:
2872 ServerDHParams params;
2873 Signature signed_params;
2874 case rsa:
2875 ServerRSAParams params;
2876 Signature signed_params;
2877 };
2878 } ServerKeyExchange;
2880 struct {
2881 select (KeyExchangeAlgorithm) {
2882 case diffie_hellman:
2883 ServerDHParams params;
2884 case rsa:
2885 ServerRSAParams params;
2886 };
2887 } ServerParams;
2889 params
2890 The server's key exchange parameters.
2892 signed_params
2893 For non-anonymous key exchanges, a hash of the corresponding
2894 params value, with the signature appropriate to that hash
2895 applied.
2897 hash
2898 Hash(ClientHello.random + ServerHello.random + ServerParams)
2900 sha_hash
2901 SHA1(ClientHello.random + ServerHello.random + ServerParams)
2903 enum { anonymous, rsa, dsa } SignatureAlgorithm;
2906 struct {
2907 select (SignatureAlgorithm) {
2908 case anonymous: struct { };
2909 case rsa:
2910 digitally-signed struct {
2911 opaque hash[Hash.length];
2915 Dierks & Rescorla Standards Track [Page 54]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2918 };
2919 case dsa:
2920 digitally-signed struct {
2921 opaque sha_hash[20];
2922 };
2923 };
2924 };
2925 } Signature;
2927 7.4.4. CertificateStatus
2929 If a server returns a
2930 "CertificateStatus" message, then the server MUST have included an
2931 extension of type "status_request" with empty "extension_data" in the
2932 extended server hello.
2934 struct {
2935 CertificateStatusType status_type;
2936 select (status_type) {
2937 case ocsp: OCSPResponse;
2938 } response;
2939 } CertificateStatus;
2941 opaque OCSPResponse<1..2^24-1>;
2943 An "ocsp_response" contains a complete, DER-encoded OCSP response
2944 (using the ASN.1 type OCSPResponse defined in [OCSP]). Note that
2945 only one OCSP response may be sent.
2947 The "CertificateStatus" message is conveyed using the handshake
2948 message type "certificate_status".
2950 Note that a server MAY also choose not to send a "CertificateStatus"
2951 message, even if it receives a "status_request" extension in the
2952 client hello message.
2954 Note in addition that servers MUST NOT send the "CertificateStatus"
2955 message unless it received a "status_request" extension in the client
2956 hello message.
2958 Clients requesting an OCSP response, and receiving an OCSP response
2959 in a "CertificateStatus" message MUST check the OCSP response and
2960 abort the handshake if the response is not satisfactory.
2963 7.4.5. Certificate request
2965 When this message will be sent:
2969 Dierks & Rescorla Standards Track [Page 55]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
2972 A non-anonymous server can optionally request a certificate from
2973 the client, if appropriate for the selected cipher suite. This
2974 message, if sent, will immediately follow the Server Key Exchange
2975 message (if it is sent; otherwise, the Server Certificate
2976 message).
2978 Structure of this message:
2979 enum {
2980 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
2981 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
2982 fortezza_dms_RESERVED(20),
2983 (255)
2984 } ClientCertificateType;
2987 opaque DistinguishedName<1..2^16-1>;
2989 struct {
2990 ClientCertificateType certificate_types<1..2^8-1>;
2991 HashType certificate_hash<1..2^8-1>;
2992 DistinguishedName certificate_authorities<0..2^16-1>;
2993 } CertificateRequest;
2995 certificate_types
2996 This field is a list of the types of certificates requested,
2997 sorted in order of the server's preference.
2999 certificate_types
3000 A list of the types of certificate types which the client may
3001 offer.
3002 rsa_sign a certificate containing an RSA key
3003 dss_sign a certificate containing a DSS key
3004 rsa_fixed_dh a certificate signed with RSA and containing
3005 a static DH key.
3006 dss_fixed_dh a certificate signed with DSS and containing
3007 a static DH key
3009 Certificate types rsa_sign and dss_sign SHOULD contain
3010 certificates signed with the same algorithm. However, this is
3011 not required. This is a holdover from TLS 1.0 and 1.1.
3014 certificate_hash
3015 A list of acceptable hash algorithms to be used in
3016 certificate signatures.
3018 certificate_authorities
3019 A list of the distinguished names of acceptable certificate
3023 Dierks & Rescorla Standards Track [Page 56]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3026 authorities. These distinguished names may specify a desired
3027 distinguished name for a root CA or for a subordinate CA;
3028 thus, this message can be used both to describe known roots
3029 and a desired authorization space. If the
3030 certificate_authorities list is empty then the client MAY
3031 send any certificate of the appropriate
3032 ClientCertificateType, unless there is some external
3033 arrangement to the contrary.
3036 ClientCertificateType values are divided into three groups:
3038 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
3039 reserved for IETF Standards Track protocols.
3041 2. Values from 64 decimal (0x40) through 223 decimal (0xDF)
3042 inclusive are reserved for assignment for non-Standards
3043 Track methods.
3045 3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
3046 inclusive are reserved for private use.
3048 Additional information describing the role of IANA in the
3049 allocation of ClientCertificateType code points is described
3050 in Section 11.
3052 Note: Values listed as RESERVED may not be used. They were used in
3053 SSLv3.
3056 Note: DistinguishedName is derived from [X501]. DistinguishedNames are
3057 represented in DER-encoded format.
3059 Note: It is a fatal handshake_failure alert for an anonymous server to
3060 request client authentication.
3062 7.4.6. Server hello done
3064 When this message will be sent:
3065 The server hello done message is sent by the server to indicate
3066 the end of the server hello and associated messages. After
3067 sending this message the server will wait for a client response.
3069 Meaning of this message:
3070 This message means that the server is done sending messages to
3071 support the key exchange, and the client can proceed with its
3072 phase of the key exchange.
3077 Dierks & Rescorla Standards Track [Page 57]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3080 Upon receipt of the server hello done message the client SHOULD
3081 verify that the server provided a valid certificate if required
3082 and check that the server hello parameters are acceptable.
3084 Structure of this message:
3085 struct { } ServerHelloDone;
3087 7.4.7. Client certificate
3089 When this message will be sent:
3090 This is the first message the client can send after receiving a
3091 server hello done message. This message is only sent if the
3092 server requests a certificate. If no suitable certificate is
3093 available, the client SHOULD send a certificate message
3094 containing no certificates. That is, the certificate_list
3095 structure has a length of zero. If client authentication is
3096 required by the server for the handshake to continue, it may
3097 respond with a fatal handshake failure alert. Client certificates
3098 are sent using the Certificate structure defined in Section
3099 7.4.2.
3102 Note: When using a static Diffie-Hellman based key exchange method
3103 (DH_DSS or DH_RSA), if client authentication is requested, the
3104 Diffie-Hellman group and generator encoded in the client's
3105 certificate MUST match the server specified Diffie-Hellman
3106 parameters if the client's parameters are to be used for the key
3107 exchange.
3109 7.4.8. Client Certificate URLs
3111 After negotiation of the use of client certificate URLs has been
3112 successfully completed (by exchanging hellos including
3113 "client_certificate_url" extensions), clients MAY send a
3114 "CertificateURL" message in place of a "Certificate" message.
3116 enum {
3117 individual_certs(0), pkipath(1), (255)
3118 } CertChainType;
3120 enum {
3121 false(0), true(1)
3122 } Boolean;
3124 struct {
3125 CertChainType type;
3126 URLAndOptionalHash url_and_hash_list<1..2^16-1>;
3127 } CertificateURL;
3131 Dierks & Rescorla Standards Track [Page 58]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3134 struct {
3135 opaque url<1..2^16-1>;
3136 Boolean hash_present;
3137 select (hash_present) {
3138 case false: struct {};
3139 case true: SHA1Hash;
3140 } hash;
3141 } URLAndOptionalHash;
3143 opaque SHA1Hash[20];
3145 Here "url_and_hash_list" contains a sequence of URLs and optional
3146 hashes.
3148 When X.509 certificates are used, there are two possibilities:
3150 - if CertificateURL.type is "individual_certs", each URL refers to
3151 a single DER-encoded X.509v3 certificate, with the URL for the
3152 client's certificate first, or
3154 - if CertificateURL.type is "pkipath", the list contains a single
3155 URL referring to a DER-encoded certificate chain, using the type
3156 PkiPath described in Section 8.
3158 When any other certificate format is used, the specification that
3159 describes use of that format in TLS should define the encoding format
3160 of certificates or certificate chains, and any constraint on their
3161 ordering.
3163 The hash corresponding to each URL at the client's discretion is
3164 either not present or is the SHA-1 hash of the certificate or
3165 certificate chain (in the case of X.509 certificates, the DER-encoded
3166 certificate or the DER-encoded PkiPath).
3168 Note that when a list of URLs for X.509 certificates is used, the
3169 ordering of URLs is the same as that used in the TLS Certificate
3170 message (see [TLS] Section 7.4.2), but opposite to the order in which
3171 certificates are encoded in PkiPath. In either case, the self-signed
3172 root certificate MAY be omitted from the chain, under the assumption
3173 that the server must already possess it in order to validate it.
3175 Servers receiving "CertificateURL" SHALL attempt to retrieve the
3176 client's certificate chain from the URLs, and then process the
3177 certificate chain as usual. A cached copy of the content of any URL
3178 in the chain MAY be used, provided that a SHA-1 hash is present for
3179 that URL and it matches the hash of the cached copy.
3181 Servers that support this extension MUST support the http: URL scheme
3185 Dierks & Rescorla Standards Track [Page 59]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3188 for certificate URLs, and MAY support other schemes. Use of other
3189 schemes than "http", "https", or "ftp" may create unexpected
3190 problems.
3192 If the protocol used is HTTP, then the HTTP server can be configured
3193 to use the Cache-Control and Expires directives described in [HTTP]
3194 to specify whether and for how long certificates or certificate
3195 chains should be cached.
3197 The TLS server is not required to follow HTTP redirects when
3198 retrieving the certificates or certificate chain. The URLs used in
3199 this extension SHOULD therefore be chosen not to depend on such
3200 redirects.
3202 If the protocol used to retrieve certificates or certificate chains
3203 returns a MIME formatted response (as HTTP does), then the following
3204 MIME Content-Types SHALL be used: when a single X.509v3 certificate
3205 is returned, the Content-Type is "application/pkix-cert" [PKIOP], and
3206 when a chain of X.509v3 certificates is returned, the Content-Type is
3207 "application/pkix-pkipath" (see Section XXX).
3209 If a SHA-1 hash is present for an URL, then the server MUST check
3210 that the SHA-1 hash of the contents of the object retrieved from that
3211 URL (after decoding any MIME Content-Transfer-Encoding) matches the
3212 given hash. If any retrieved object does not have the correct SHA-1
3213 hash, the server MUST abort the handshake with a
3214 "bad_certificate_hash_value" alert.
3216 Note that clients may choose to send either "Certificate" or
3217 "CertificateURL" after successfully negotiating the option to send
3218 certificate URLs. The option to send a certificate is included to
3219 provide flexibility to clients possessing multiple certificates.
3221 If a server encounters an unreasonable delay in obtaining
3222 certificates in a given CertificateURL, it SHOULD time out and signal
3223 a "certificate_unobtainable" error alert.
3225 7.4.9. Client key exchange message
3227 When this message will be sent:
3228 This message is always sent by the client. It MUST immediately follow
3229 the client certificate message, if it is sent. Otherwise it MUST be
3230 the first message sent by the client after it receives the server
3231 hello done message.
3233 Meaning of this message:
3234 With this message, the premaster secret is set, either though direct
3235 transmission of the RSA-encrypted secret, or by the transmission of
3239 Dierks & Rescorla Standards Track [Page 60]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3242 Diffie-Hellman parameters which will allow each side to agree upon
3243 the same premaster secret. When the key exchange method is DH_RSA or
3244 DH_DSS, client certification has been requested, and the client was
3245 able to respond with a certificate which contained a Diffie-Hellman
3246 public key whose parameters (group and generator) matched those
3247 specified by the server in its certificate, this message MUST not
3248 contain any data.
3250 Structure of this message:
3251 The choice of messages depends on which key exchange method has been
3252 selected. See Section 7.4.3 for the KeyExchangeAlgorithm definition.
3254 struct {
3255 select (KeyExchangeAlgorithm) {
3256 case rsa: EncryptedPreMasterSecret;
3257 case diffie_hellman: ClientDiffieHellmanPublic;
3258 } exchange_keys;
3259 } ClientKeyExchange;
3261 7.4.9.1. RSA encrypted premaster secret message
3263 Meaning of this message:
3264 If RSA is being used for key agreement and authentication, the client
3265 generates a 48-byte premaster secret, encrypts it using the public
3266 key from the server's certificate or the temporary RSA key provided
3267 in a server key exchange message, and sends the result in an
3268 encrypted premaster secret message. This structure is a variant of
3269 the client key exchange message, not a message in itself.
3271 Structure of this message:
3272 struct {
3273 ProtocolVersion client_version;
3274 opaque random[46];
3275 } PreMasterSecret;
3277 client_version
3278 The latest (newest) version supported by the client. This is
3279 used to detect version roll-back attacks. Upon receiving the
3280 premaster secret, the server SHOULD check that this value
3281 matches the value transmitted by the client in the client
3282 hello message.
3284 random
3285 46 securely-generated random bytes.
3287 struct {
3288 public-key-encrypted PreMasterSecret pre_master_secret;
3289 } EncryptedPreMasterSecret;
3293 Dierks & Rescorla Standards Track [Page 61]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3296 pre_master_secret
3297 This random value is generated by the client and is used to
3298 generate the master secret, as specified in Section 8.1.
3300 Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
3301 to attack a TLS server which is using PKCS#1 v 1.5 encoded RSA.
3302 The attack takes advantage of the fact that by failing in
3303 different ways, a TLS server can be coerced into revealing
3304 whether a particular message, when decrypted, is properly PKCS#1
3305 v1.5 formatted or not.
3307 The best way to avoid vulnerability to this attack is to treat
3308 incorrectly formatted messages in a manner indistinguishable from
3309 correctly formatted RSA blocks. Thus, when it receives an
3310 incorrectly formatted RSA block, a server should generate a
3311 random 48-byte value and proceed using it as the premaster
3312 secret. Thus, the server will act identically whether the
3313 received RSA block is correctly encoded or not.
3315 [PKCS1B] defines a newer version of PKCS#1 encoding that is more
3316 secure against the Bleichenbacher attack. However, for maximal
3317 compatibility with TLS 1.0, TLS 1.1 retains the original
3318 encoding. No variants of the Bleichenbacher attack are known to
3319 exist provided that the above recommendations are followed.
3321 Implementation Note: public-key-encrypted data is represented as an
3322 opaque vector <0..2^16-1> (see section 4.7). Thus the RSA-
3323 encrypted PreMasterSecret in a ClientKeyExchange is preceded by
3324 two length bytes. These bytes are redundant in the case of RSA
3325 because the EncryptedPreMasterSecret is the only data in the
3326 ClientKeyExchange and its length can therefore be unambiguously
3327 determined. The SSLv3 specification was not clear about the
3328 encoding of public-key-encrypted data and therefore many SSLv3
3329 implementations do not include the the length bytes, encoding the
3330 RSA encrypted data directly in the ClientKeyExchange message.
3332 This specification requires correct encoding of the
3333 EncryptedPreMasterSecret complete with length bytes. The
3334 resulting PDU is incompatible with many SSLv3 implementations.
3335 Implementors upgrading from SSLv3 must modify their
3336 implementations to generate and accept the correct encoding.
3337 Implementors who wish to be compatible with both SSLv3 and TLS
3338 should make their implementation's behavior dependent on the
3339 protocol version.
3341 Implementation Note: It is now known that remote timing-based attacks
3342 on SSL are possible, at least when the client and server are on
3343 the same LAN. Accordingly, implementations which use static RSA
3347 Dierks & Rescorla Standards Track [Page 62]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3350 keys SHOULD use RSA blinding or some other anti-timing technique,
3351 as described in [TIMING].
3353 Note: The version number in the PreMasterSecret MUST be the version
3354 offered by the client in the ClientHello, not the version
3355 negotiated for the connection. This feature is designed to
3356 prevent rollback attacks. Unfortunately, many implementations use
3357 the negotiated version instead and therefore checking the version
3358 number may lead to failure to interoperate with such incorrect
3359 client implementations. Client implementations MUST and Server
3360 implementations MAY check the version number. In practice, since
3361 the TLS handshake MACs prevent downgrade and no good attacks are
3362 known on those MACs, ambiguity is not considered a serious
3363 security risk. Note that if servers choose to to check the
3364 version number, they should randomize the PreMasterSecret in case
3365 of error, rather than generate an alert, in order to avoid
3366 variants on the Bleichenbacher attack. [KPR03]
3368 7.4.9.2. Client Diffie-Hellman public value
3370 Meaning of this message:
3371 This structure conveys the client's Diffie-Hellman public value
3372 (Yc) if it was not already included in the client's certificate.
3373 The encoding used for Yc is determined by the enumerated
3374 PublicValueEncoding. This structure is a variant of the client
3375 key exchange message, not a message in itself.
3377 Structure of this message:
3378 enum { implicit, explicit } PublicValueEncoding;
3380 implicit
3381 If the client certificate already contains a suitable Diffie-
3382 Hellman key, then Yc is implicit and does not need to be sent
3383 again. In this case, the client key exchange message will be
3384 sent, but MUST be empty.
3386 explicit
3387 Yc needs to be sent.
3389 struct {
3390 select (PublicValueEncoding) {
3391 case implicit: struct { };
3392 case explicit: opaque dh_Yc<1..2^16-1>;
3393 } dh_public;
3394 } ClientDiffieHellmanPublic;
3396 dh_Yc
3397 The client's Diffie-Hellman public value (Yc).
3401 Dierks & Rescorla Standards Track [Page 63]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3404 7.4.10. Certificate verify
3406 When this message will be sent:
3407 This message is used to provide explicit verification of a client
3408 certificate. This message is only sent following a client
3409 certificate that has signing capability (i.e. all certificates
3410 except those containing fixed Diffie-Hellman parameters). When
3411 sent, it MUST immediately follow the client key exchange message.
3413 Structure of this message:
3414 struct {
3415 Signature signature;
3416 } CertificateVerify;
3418 The Signature type is defined in 7.4.3. If the SignatureAlgorithm
3419 is DSA, then the sha_hash value must be used. If it is RSA,
3420 the same function (denoted Hash) must be used as was used to
3421 create the signature for the client's certificate.
3423 CertificateVerify.signature.hash
3424 Hash(handshake_messages);
3426 CertificateVerify.signature.sha_hash
3427 SHA(handshake_messages);
3429 Here handshake_messages refers to all handshake messages sent or
3430 received starting at client hello up to but not including this
3431 message, including the type and length fields of the handshake
3432 messages. This is the concatenation of all the Handshake structures
3433 as defined in 7.4 exchanged thus far.
3435 7.4.10. Finished
3437 When this message will be sent:
3438 A finished message is always sent immediately after a change
3439 cipher spec message to verify that the key exchange and
3440 authentication processes were successful. It is essential that a
3441 change cipher spec message be received between the other
3442 handshake messages and the Finished message.
3444 Meaning of this message:
3445 The finished message is the first protected with the just-
3446 negotiated algorithms, keys, and secrets. Recipients of finished
3447 messages MUST verify that the contents are correct. Once a side
3448 has sent its Finished message and received and validated the
3449 Finished message from its peer, it may begin to send and receive
3450 application data over the connection.
3455 Dierks & Rescorla Standards Track [Page 64]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3458 struct {
3459 opaque verify_data[12];
3460 } Finished;
3462 verify_data
3463 PRF(master_secret, finished_label, MD5(handshake_messages) +
3464 SHA-1(handshake_messages)) [0..11];
3466 finished_label
3467 For Finished messages sent by the client, the string "client
3468 finished". For Finished messages sent by the server, the
3469 string "server finished".
3471 handshake_messages
3472 All of the data from all messages in this handshake (not
3473 including any HelloRequest messages) up to but not including
3474 this message. This is only data visible at the handshake
3475 layer and does not include record layer headers. This is the
3476 concatenation of all the Handshake structures as defined in
3477 7.4 exchanged thus far.
3479 It is a fatal error if a finished message is not preceded by a change
3480 cipher spec message at the appropriate point in the handshake.
3482 The value handshake_messages includes all handshake messages starting
3483 at client hello up to, but not including, this finished message. This
3484 may be different from handshake_messages in Section 7.4.10 because it
3485 would include the certificate verify message (if sent). Also, the
3486 handshake_messages for the finished message sent by the client will
3487 be different from that for the finished message sent by the server,
3488 because the one which is sent second will include the prior one.
3490 Note: Change cipher spec messages, alerts and any other record types
3491 are not handshake messages and are not included in the hash
3492 computations. Also, Hello Request messages are omitted from
3493 handshake hashes.
3495 8. Cryptographic computations
3497 In order to begin connection protection, the TLS Record Protocol
3498 requires specification of a suite of algorithms, a master secret, and
3499 the client and server random values. The authentication, encryption,
3500 and MAC algorithms are determined by the cipher_suite selected by the
3501 server and revealed in the server hello message. The compression
3502 algorithm is negotiated in the hello messages, and the random values
3503 are exchanged in the hello messages. All that remains is to calculate
3504 the master secret.
3509 Dierks & Rescorla Standards Track [Page 65]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3512 8.1. Computing the master secret
3514 For all key exchange methods, the same algorithm is used to convert
3515 the pre_master_secret into the master_secret. The pre_master_secret
3516 should be deleted from memory once the master_secret has been
3517 computed.
3519 master_secret = PRF(pre_master_secret, "master secret",
3520 ClientHello.random + ServerHello.random)
3521 [0..47];
3523 The master secret is always exactly 48 bytes in length. The length of
3524 the premaster secret will vary depending on key exchange method.
3563 Dierks & Rescorla Standards Track [Page 66]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3566 8.1.1. RSA
3568 When RSA is used for server authentication and key exchange, a
3569 48-byte pre_master_secret is generated by the client, encrypted under
3570 the server's public key, and sent to the server. The server uses its
3571 private key to decrypt the pre_master_secret. Both parties then
3572 convert the pre_master_secret into the master_secret, as specified
3573 above.
3575 RSA digital signatures are performed using PKCS #1 [PKCS1] block type
3576 1. RSA public key encryption is performed using PKCS #1 block type 2.
3578 8.1.2. Diffie-Hellman
3580 A conventional Diffie-Hellman computation is performed. The
3581 negotiated key (Z) is used as the pre_master_secret, and is converted
3582 into the master_secret, as specified above. Leading bytes of Z that
3583 contain all zero bits are stripped before it is used as the
3584 pre_master_secret.
3586 Note: Diffie-Hellman parameters are specified by the server, and may
3587 be either ephemeral or contained within the server's certificate.
3589 9. Mandatory Cipher Suites
3591 In the absence of an application profile standard specifying
3592 otherwise, a TLS compliant application MUST implement the cipher
3593 suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
3595 10. Application data protocol
3597 Application data messages are carried by the Record Layer and are
3598 fragmented, compressed and encrypted based on the current connection
3599 state. The messages are treated as transparent data to the record
3600 layer.
3602 11. IANA Considerations
3604 This document describes a number of new registries to be created by
3605 IANA. We recommend that they be placed as individual registries items
3606 under a common TLS category.
3608 Section 7.4.5 describes a TLS HashType Registry to be maintained by
3609 the IANA, as defining a number of such code point identifiers.
3610 HashType identifiers with values in the range 0-63 (decimal)
3611 inclusive are assigned via RFC 2434 Standards Action. Values from the
3612 range 64-223 (decimal) inclusive are assigned via [RFC 2434]
3613 Specification Required. Identifier values from 224-255 (decimal)
3617 Dierks & Rescorla Standards Track [Page 67]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3620 inclusive are reserved for RFC 2434 Private Use. The registry will be
3621 initially populated with the values in this document, Section 7.4.5.
3623 Section 7.4.5 describes a TLS ClientCertificateType Registry to be
3624 maintained by the IANA, as defining a number of such code point
3625 identifiers. ClientCertificateType identifiers with values in the
3626 range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards
3627 Action. Values from the range 64-223 (decimal) inclusive are assigned
3628 via [RFC 2434] Specification Required. Identifier values from
3629 224-255 (decimal) inclusive are reserved for RFC 2434 Private Use.
3630 The registry will be initially populated with the values in this
3631 document, Section 7.4.5.
3633 Section A.5 describes a TLS Cipher Suite Registry to be maintained by
3634 the IANA, as well as defining a number of such cipher suite
3635 identifiers. Cipher suite values with the first byte in the range
3636 0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action.
3637 Values with the first byte in the range 192-254 (decimal) are
3638 assigned via RFC 2434 Specification Required. Values with the first
3639 byte 255 (decimal) are reserved for RFC 2434 Private Use. The
3640 registry will be initially populated with the values from Section A.5
3641 of this document, [TLSAES], and Section 3 of [TLSKRB].
3643 Section 6 requires that all ContentType values be defined by RFC 2434
3644 Standards Action. IANA SHOULD create a TLS ContentType registry,
3645 initially populated with values from Section 6.2.1 of this document.
3646 Future values MUST be allocated via Standards Action as described in
3647 [RFC 2434].
3649 Section 7.2.2 requires that all Alert values be defined by RFC 2434
3650 Standards Action. IANA SHOULD create a TLS Alert registry, initially
3651 populated with values from Section 7.2 of this document and Section 4
3652 of [TLSEXT]. Future values MUST be allocated via Standards Action as
3653 described in [RFC 2434].
3655 Section 7.4 requires that all HandshakeType values be defined by RFC
3656 2434 Standards Action. IANA SHOULD create a TLS HandshakeType
3657 registry, initially populated with values from Section 7.4 of this
3658 document and Section 2.4 of [TLSEXT]. Future values MUST be
3659 allocated via Standards Action as described in [RFC2434].
3662 11.1 Extensions
3664 Sections XXX and XXX describes a registry of ExtensionType values to
3665 be maintained by the IANA. ExtensionType values are to be assigned
3666 via IETF Consensus as defined in RFC 2434 [IANA]. The initial
3667 registry corresponds to the definition of "ExtensionType" in Section
3671 Dierks & Rescorla Standards Track [Page 68]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3674 2.3.
3676 The MIME type "application/pkix-pkipath" has been registered by the
3677 IANA with the following template:
3679 To: ietf-types@iana.org Subject: Registration of MIME media type
3680 application/pkix-pkipath
3682 MIME media type name: application
3683 MIME subtype name: pkix-pkipath
3685 Optional parameters: version (default value is "1")
3687 Encoding considerations:
3688 This MIME type is a DER encoding of the ASN.1 type PkiPath,
3689 defined as follows:
3690 PkiPath ::= SEQUENCE OF Certificate
3691 PkiPath is used to represent a certification path. Within the
3692 sequence, the order of certificates is such that the subject of
3693 the first certificate is the issuer of the second certificate,
3694 etc.
3696 This is identical to the definition published in [X509-4th-TC1];
3697 note that it is different from that in [X509-4th].
3699 All Certificates MUST conform to [PKIX]. (This should be
3700 interpreted as a requirement to encode only PKIX-conformant
3701 certificates using this type. It does not necessarily require
3702 that all certificates that are not strictly PKIX-conformant must
3703 be rejected by relying parties, although the security consequences
3704 of accepting any such certificates should be considered
3705 carefully.)
3707 DER (as opposed to BER) encoding MUST be used. If this type is
3708 sent over a 7-bit transport, base64 encoding SHOULD be used.
3710 Security considerations:
3711 The security considerations of [X509-4th] and [PKIX] (or any
3712 updates to them) apply, as well as those of any protocol that uses
3713 this type (e.g., TLS).
3715 Note that this type only specifies a certificate chain that can be
3716 assessed for validity according to the relying party's existing
3717 configuration of trusted CAs; it is not intended to be used to
3718 specify any change to that configuration.
3720 Interoperability considerations:
3721 No specific interoperability problems are known with this type,
3725 Dierks & Rescorla Standards Track [Page 69]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3728 but for recommendations relating to X.509 certificates in general,
3729 see [PKIX].
3731 Published specification: this memo, and [PKIX].
3733 Applications which use this media type: TLS. It may also be used by
3734 other protocols, or for general interchange of PKIX certificate
3736 Additional information:
3737 Magic number(s): DER-encoded ASN.1 can be easily recognized.
3738 Further parsing is required to distinguish from other ASN.1
3739 types.
3740 File extension(s): .pkipath
3741 Macintosh File Type Code(s): not specified
3743 Person & email address to contact for further information:
3744 Magnus Nystrom <magnus@rsasecurity.com>
3746 Intended usage: COMMON
3748 Change controller:
3749 IESG <iesg@ietf.org>
3779 Dierks & Rescorla Standards Track [Page 70]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3782 A. Protocol constant values
3784 This section describes protocol types and constants.
3786 A.1. Record layer
3788 struct {
3789 uint8 major, minor;
3790 } ProtocolVersion;
3792 ProtocolVersion version = { 3, 2 }; /* TLS v1.1 */
3794 enum {
3795 change_cipher_spec(20), alert(21), handshake(22),
3796 application_data(23), (255)
3797 } ContentType;
3799 struct {
3800 ContentType type;
3801 ProtocolVersion version;
3802 uint16 length;
3803 opaque fragment[TLSPlaintext.length];
3804 } TLSPlaintext;
3806 struct {
3807 ContentType type;
3808 ProtocolVersion version;
3809 uint16 length;
3810 opaque fragment[TLSCompressed.length];
3811 } TLSCompressed;
3813 struct {
3814 ContentType type;
3815 ProtocolVersion version;
3816 uint16 length;
3817 select (CipherSpec.cipher_type) {
3818 case stream: GenericStreamCipher;
3819 case block: GenericBlockCipher;
3820 } fragment;
3821 } TLSCiphertext;
3823 stream-ciphered struct {
3824 opaque content[TLSCompressed.length];
3825 opaque MAC[CipherSpec.hash_size];
3826 } GenericStreamCipher;
3828 block-ciphered struct {
3829 opaque IV[CipherSpec.block_length];
3833 Dierks & Rescorla Standards Track [Page 71]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3836 opaque content[TLSCompressed.length];
3837 opaque MAC[CipherSpec.hash_size];
3838 uint8 padding[GenericBlockCipher.padding_length];
3839 uint8 padding_length;
3840 } GenericBlockCipher;
3842 A.2. Change cipher specs message
3844 struct {
3845 enum { change_cipher_spec(1), (255) } type;
3846 } ChangeCipherSpec;
3848 A.3. Alert messages
3850 enum { warning(1), fatal(2), (255) } AlertLevel;
3852 enum {
3853 close_notify(0),
3854 unexpected_message(10),
3855 bad_record_mac(20),
3856 decryption_failed(21),
3857 record_overflow(22),
3858 decompression_failure(30),
3859 handshake_failure(40),
3860 no_certificate_RESERVED (41),
3861 bad_certificate(42),
3862 unsupported_certificate(43),
3863 certificate_revoked(44),
3864 certificate_expired(45),
3865 certificate_unknown(46),
3866 illegal_parameter(47),
3867 unknown_ca(48),
3868 access_denied(49),
3869 decode_error(50),
3870 decrypt_error(51),
3871 export_restriction_RESERVED(60),
3872 protocol_version(70),
3873 insufficient_security(71),
3874 internal_error(80),
3875 user_canceled(90),
3876 no_renegotiation(100),
3877 unsupported_extension(110), /* new */
3878 certificate_unobtainable(111), /* new */
3879 unrecognized_name(112), /* new */
3880 bad_certificate_status_response(113), /* new */
3881 bad_certificate_hash_value(114), /* new */
3882 (255)
3883 } AlertDescription;
3887 Dierks & Rescorla Standards Track [Page 72]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3890 struct {
3891 AlertLevel level;
3892 AlertDescription description;
3893 } Alert;
3941 Dierks & Rescorla Standards Track [Page 73]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3944 A.4. Handshake protocol
3946 enum {
3947 hello_request(0), client_hello(1), server_hello(2),
3948 certificate(11), server_key_exchange (12),
3949 certificate_request(13), server_hello_done(14),
3950 certificate_verify(15), client_key_exchange(16),
3951 finished(20), certificate_url(21), certificate_status(22),
3952 (255)
3953 } HandshakeType;
3955 struct {
3956 HandshakeType msg_type;
3957 uint24 length;
3958 select (HandshakeType) {
3959 case hello_request: HelloRequest;
3960 case client_hello: ClientHello;
3961 case server_hello: ServerHello;
3962 case certificate: Certificate;
3963 case server_key_exchange: ServerKeyExchange;
3964 case certificate_request: CertificateRequest;
3965 case server_hello_done: ServerHelloDone;
3966 case certificate_verify: CertificateVerify;
3967 case client_key_exchange: ClientKeyExchange;
3968 case finished: Finished;
3969 case certificate_url: CertificateURL;
3970 case certificate_status: CertificateStatus;
3971 } body;
3972 } Handshake;
3974 A.4.1. Hello messages
3976 struct { } HelloRequest;
3978 struct {
3979 uint32 gmt_unix_time;
3980 opaque random_bytes[28];
3981 } Random;
3983 opaque SessionID<0..32>;
3985 uint8 CipherSuite[2];
3987 enum { null(0), (255) } CompressionMethod;
3989 struct {
3990 ProtocolVersion client_version;
3991 Random random;
3995 Dierks & Rescorla Standards Track [Page 74]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
3998 SessionID session_id;
3999 CipherSuite cipher_suites<2..2^16-1>;
4000 CompressionMethod compression_methods<1..2^8-1>;
4001 Extension client_hello_extension_list<0..2^16-1>;
4002 } ClientHello;
4004 struct {
4005 ProtocolVersion client_version;
4006 Random random;
4007 SessionID session_id;
4008 CipherSuite cipher_suites<2..2^16-1>;
4009 CompressionMethod compression_methods<1..2^8-1>;
4010 Extension client_hello_extension_list<0..2^16-1>;
4011 } ExtendedClientHello;
4013 struct {
4014 ProtocolVersion server_version;
4015 Random random;
4016 SessionID session_id;
4017 CipherSuite cipher_suite;
4018 CompressionMethod compression_method;
4019 } ServerHello;
4021 struct {
4022 ProtocolVersion server_version;
4023 Random random;
4024 SessionID session_id;
4025 CipherSuite cipher_suite;
4026 CompressionMethod compression_method;
4027 Extension server_hello_extension_list<0..2^16-1>;
4028 } ExtendedServerHello;
4030 struct {
4031 ExtensionType extension_type;
4032 opaque extension_data<0..2^16-1>;
4033 } Extension;
4035 enum {
4036 server_name(0), max_fragment_length(1),
4037 client_certificate_url(2), trusted_ca_keys(3),
4038 truncated_hmac(4), status_request(5),
4039 cert_hash_types(6), (65535)
4040 } ExtensionType;
4042 struct {
4043 NameType name_type;
4044 select (name_type) {
4045 case host_name: HostName;
4049 Dierks & Rescorla Standards Track [Page 75]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4052 } name;
4053 } ServerName;
4055 enum {
4056 host_name(0), (255)
4057 } NameType;
4059 opaque HostName<1..2^16-1>;
4061 struct {
4062 ServerName server_name_list<1..2^16-1>
4063 } ServerNameList;
4065 enum{
4066 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
4067 } MaxFragmentLength;
4069 struct {
4070 TrustedAuthority trusted_authorities_list<0..2^16-1>;
4071 } TrustedAuthorities;
4073 struct {
4074 IdentifierType identifier_type;
4075 select (identifier_type) {
4076 case pre_agreed: struct {};
4077 case key_sha1_hash: SHA1Hash;
4078 case x509_name: DistinguishedName;
4079 case cert_sha1_hash: SHA1Hash;
4080 } identifier;
4081 } TrustedAuthority;
4083 enum {
4084 pre_agreed(0), key_sha1_hash(1), x509_name(2),
4085 cert_sha1_hash(3), (255)
4086 } IdentifierType;
4088 struct {
4089 CertificateStatusType status_type;
4090 select (status_type) {
4091 case ocsp: OCSPStatusRequest;
4092 } request;
4093 } CertificateStatusRequest;
4095 enum { ocsp(1), (255) } CertificateStatusType;
4097 struct {
4098 ResponderID responder_id_list<0..2^16-1>;
4099 Extensions request_extensions;
4103 Dierks & Rescorla Standards Track [Page 76]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4106 } OCSPStatusRequest;
4108 opaque ResponderID<1..2^16-1>;
4109 A.4.2. Server authentication and key exchange messages
4111 opaque ASN.1Cert<2^24-1>;
4113 struct {
4114 ASN.1Cert certificate_list<0..2^24-1>;
4115 } Certificate;
4117 struct {
4118 CertificateStatusType status_type;
4119 select (status_type) {
4120 case ocsp: OCSPResponse;
4121 } response;
4122 } CertificateStatus;
4124 opaque OCSPResponse<1..2^24-1>;
4126 enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
4128 struct {
4129 opaque rsa_modulus<1..2^16-1>;
4130 opaque rsa_exponent<1..2^16-1>;
4131 } ServerRSAParams;
4133 struct {
4134 opaque dh_p<1..2^16-1>;
4135 opaque dh_g<1..2^16-1>;
4136 opaque dh_Ys<1..2^16-1>;
4137 } ServerDHParams;
4139 struct {
4140 select (KeyExchangeAlgorithm) {
4141 case diffie_hellman:
4142 ServerDHParams params;
4143 Signature signed_params;
4144 case rsa:
4145 ServerRSAParams params;
4146 Signature signed_params;
4147 };
4148 } ServerKeyExchange;
4150 enum { anonymous, rsa, dsa } SignatureAlgorithm;
4152 struct {
4153 select (KeyExchangeAlgorithm) {
4157 Dierks & Rescorla Standards Track [Page 77]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4160 case diffie_hellman:
4161 ServerDHParams params;
4162 case rsa:
4163 ServerRSAParams params;
4164 };
4165 } ServerParams;
4167 struct {
4168 select (SignatureAlgorithm) {
4169 case anonymous: struct { };
4170 case rsa:
4171 digitally-signed struct {
4172 opaque hash[Hash.length];
4173 };
4174 case dsa:
4175 digitally-signed struct {
4176 opaque sha_hash[20];
4177 };
4178 };
4179 };
4180 } Signature;
4182 enum {
4183 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
4184 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
4185 fortezza_dms_RESERVED(20),
4186 (255)
4187 } ClientCertificateType;
4189 opaque DistinguishedName<1..2^16-1>;
4191 struct {
4192 ClientCertificateType certificate_types<1..2^8-1>;
4193 DistinguishedName certificate_authorities<0..2^16-1>;
4194 } CertificateRequest;
4196 struct { } ServerHelloDone;
4198 A.4.3. Client authentication and key exchange messages
4200 struct {
4201 select (KeyExchangeAlgorithm) {
4202 case rsa: EncryptedPreMasterSecret;
4203 case diffie_hellman: ClientDiffieHellmanPublic;
4204 } exchange_keys;
4205 } ClientKeyExchange;
4207 struct {
4211 Dierks & Rescorla Standards Track [Page 78]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4214 ProtocolVersion client_version;
4215 opaque random[46];
4216 } PreMasterSecret;
4218 struct {
4219 public-key-encrypted PreMasterSecret pre_master_secret;
4220 } EncryptedPreMasterSecret;
4222 enum { implicit, explicit } PublicValueEncoding;
4224 struct {
4225 select (PublicValueEncoding) {
4226 case implicit: struct {};
4227 case explicit: opaque DH_Yc<1..2^16-1>;
4228 } dh_public;
4229 } ClientDiffieHellmanPublic;
4231 enum {
4232 individual_certs(0), pkipath(1), (255)
4233 } CertChainType;
4235 enum {
4236 false(0), true(1)
4237 } Boolean;
4239 struct {
4240 CertChainType type;
4241 URLAndOptionalHash url_and_hash_list<1..2^16-1>;
4242 } CertificateURL;
4244 struct {
4245 opaque url<1..2^16-1>;
4246 Boolean hash_present;
4247 select (hash_present) {
4248 case false: struct {};
4249 case true: SHA1Hash;
4250 } hash;
4251 } URLAndOptionalHash;
4253 opaque SHA1Hash[20];
4255 struct {
4256 Signature signature;
4257 } CertificateVerify;
4259 A.4.4. Handshake finalization message
4261 struct {
4265 Dierks & Rescorla Standards Track [Page 79]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4268 opaque verify_data[12];
4269 } Finished;
4271 A.5. The CipherSuite
4273 The following values define the CipherSuite codes used in the client
4274 hello and server hello messages.
4276 A CipherSuite defines a cipher specification supported in TLS Version
4277 1.1.
4279 TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
4280 TLS connection during the first handshake on that channel, but must
4281 not be negotiated, as it provides no more protection than an
4282 unsecured connection.
4284 CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
4286 The following CipherSuite definitions require that the server provide
4287 an RSA certificate that can be used for key exchange. The server may
4288 request either an RSA or a DSS signature-capable certificate in the
4289 certificate request message.
4291 CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
4292 CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
4293 CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
4294 CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
4295 CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
4296 CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
4297 CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
4298 CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F };
4299 CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 };
4300 The following CipherSuite definitions are used for server-
4301 authenticated (and optionally client-authenticated) Diffie-Hellman.
4302 DH denotes cipher suites in which the server's certificate contains
4303 the Diffie-Hellman parameters signed by the certificate authority
4304 (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
4305 parameters are signed by a DSS or RSA certificate, which has been
4306 signed by the CA. The signing algorithm used is specified after the
4307 DH or DHE parameter. The server can request an RSA or DSS signature-
4308 capable certificate from the client for client authentication or it
4309 may request a Diffie-Hellman certificate. Any Diffie-Hellman
4310 certificate provided by the client must use the parameters (group and
4311 generator) described by the server.
4313 CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
4314 CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
4315 CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
4319 Dierks & Rescorla Standards Track [Page 80]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4322 CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
4323 CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
4324 CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
4325 CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
4326 CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
4327 CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x30 };
4328 CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x31 };
4329 CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x32 };
4330 CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x33 };
4331 CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 };
4332 CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x36 };
4333 CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x37 };
4334 CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x38 };
4335 CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x39 };
4336 CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A };
4338 The following cipher suites are used for completely anonymous Diffie-
4339 Hellman communications in which neither party is authenticated. Note
4340 that this mode is vulnerable to man-in-the-middle attacks and is
4341 therefore deprecated.
4343 CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
4344 CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
4345 CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
4347 When SSLv3 and TLS 1.0 were designed, the United States restricted
4348 the export of cryptographic software containing certain strong
4349 encryption algorithms. A series of cipher suites were designed to
4350 operate at reduced key lengths in order to comply with those
4351 regulations. Due to advances in computer performance, these
4352 algorithms are now unacceptably weak and export restrictions have
4353 since been loosened. TLS 1.1 implementations MUST NOT negotiate these
4354 cipher suites in TLS 1.1 mode. However, for backward compatibility
4355 they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
4356 only servers. TLS 1.1 clients MUST check that the server did not
4357 choose one of these cipher suites during the handshake. These
4358 ciphersuites are listed below for informational purposes and to
4359 reserve the numbers.
4361 CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
4362 CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
4363 CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
4364 CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
4365 CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
4366 CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
4367 CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
4368 CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
4369 CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
4373 Dierks & Rescorla Standards Track [Page 81]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4376 The following cipher suites were defined in [TLSKRB] and are included
4377 here for completeness. See [TLSKRB] for details:
4379 CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E };
4380 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
4381 CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
4382 CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
4383 CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
4384 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
4385 CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
4386 CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
4388 The following exportable cipher suites were defined in [TLSKRB] and
4389 are included here for completeness. TLS 1.1 implementations MUST NOT
4390 negotiate these cipher suites.
4392 CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26
4393 };
4394 CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27
4395 };
4396 CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28
4397 };
4398 CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29
4399 };
4400 CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A
4401 };
4402 CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B
4403 };
4406 The cipher suite space is divided into three regions:
4408 1. Cipher suite values with first byte 0x00 (zero)
4409 through decimal 191 (0xBF) inclusive are reserved for the IETF
4410 Standards Track protocols.
4412 2. Cipher suite values with first byte decimal 192 (0xC0)
4413 through decimal 254 (0xFE) inclusive are reserved
4414 for assignment for non-Standards Track methods.
4416 3. Cipher suite values with first byte 0xFF are
4417 reserved for private use.
4418 Additional information describing the role of IANA in the allocation
4419 of cipher suite code points is described in Section 11.
4421 Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
4422 reserved to avoid collision with Fortezza-based cipher suites in SSL
4423 3.
4427 Dierks & Rescorla Standards Track [Page 82]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4430 A.6. The Security Parameters
4432 These security parameters are determined by the TLS Handshake
4433 Protocol and provided as parameters to the TLS Record Layer in order
4434 to initialize a connection state. SecurityParameters includes:
4436 enum { null(0), (255) } CompressionMethod;
4438 enum { server, client } ConnectionEnd;
4440 enum { null, rc4, rc2, des, 3des, des40, aes, idea }
4441 BulkCipherAlgorithm;
4443 enum { stream, block } CipherType;
4445 enum { null, md5, sha } MACAlgorithm;
4447 /* The algorithms specified in CompressionMethod,
4448 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
4450 struct {
4451 ConnectionEnd entity;
4452 BulkCipherAlgorithm bulk_cipher_algorithm;
4453 CipherType cipher_type;
4454 uint8 key_size;
4455 uint8 key_material_length;
4456 MACAlgorithm mac_algorithm;
4457 uint8 hash_size;
4458 CompressionMethod compression_algorithm;
4459 opaque master_secret[48];
4460 opaque client_random[32];
4461 opaque server_random[32];
4462 } SecurityParameters;
4481 Dierks & Rescorla Standards Track [Page 83]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4484 B. Glossary
4486 Advanced Encryption Standard (AES)
4487 AES is a widely used symmetric encryption algorithm.
4488 AES is
4489 a block cipher with a 128, 192, or 256 bit keys and a 16 byte
4490 block size. [AES] TLS currently only supports the 128 and 256
4491 bit key sizes.
4493 application protocol
4494 An application protocol is a protocol that normally layers
4495 directly on top of the transport layer (e.g., TCP/IP). Examples
4496 include HTTP, TELNET, FTP, and SMTP.
4498 asymmetric cipher
4499 See public key cryptography.
4501 authentication
4502 Authentication is the ability of one entity to determine the
4503 identity of another entity.
4505 block cipher
4506 A block cipher is an algorithm that operates on plaintext in
4507 groups of bits, called blocks. 64 bits is a common block size.
4509 bulk cipher
4510 A symmetric encryption algorithm used to encrypt large quantities
4511 of data.
4513 cipher block chaining (CBC)
4514 CBC is a mode in which every plaintext block encrypted with a
4515 block cipher is first exclusive-ORed with the previous ciphertext
4516 block (or, in the case of the first block, with the
4517 initialization vector). For decryption, every block is first
4518 decrypted, then exclusive-ORed with the previous ciphertext block
4519 (or IV).
4521 certificate
4522 As part of the X.509 protocol (a.k.a. ISO Authentication
4523 framework), certificates are assigned by a trusted Certificate
4524 Authority and provide a strong binding between a party's identity
4525 or some other attributes and its public key.
4527 client
4528 The application entity that initiates a TLS connection to a
4529 server. This may or may not imply that the client initiated the
4530 underlying transport connection. The primary operational
4531 difference between the server and client is that the server is
4535 Dierks & Rescorla Standards Track [Page 84]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4538 generally authenticated, while the client is only optionally
4539 authenticated.
4541 client write key
4542 The key used to encrypt data written by the client.
4544 client write MAC secret
4545 The secret data used to authenticate data written by the client.
4547 connection
4548 A connection is a transport (in the OSI layering model
4549 definition) that provides a suitable type of service. For TLS,
4550 such connections are peer to peer relationships. The connections
4551 are transient. Every connection is associated with one session.
4553 Data Encryption Standard
4554 DES is a very widely used symmetric encryption algorithm. DES is
4555 a block cipher with a 56 bit key and an 8 byte block size. Note
4556 that in TLS, for key generation purposes, DES is treated as
4557 having an 8 byte key length (64 bits), but it still only provides
4558 56 bits of protection. (The low bit of each key byte is presumed
4559 to be set to produce odd parity in that key byte.) DES can also
4560 be operated in a mode where three independent keys and three
4561 encryptions are used for each block of data; this uses 168 bits
4562 of key (24 bytes in the TLS key generation method) and provides
4563 the equivalent of 112 bits of security. [DES], [3DES]
4565 Digital Signature Standard (DSS)
4566 A standard for digital signing, including the Digital Signing
4567 Algorithm, approved by the National Institute of Standards and
4568 Technology, defined in NIST FIPS PUB 186, "Digital Signature
4569 Standard," published May, 1994 by the U.S. Dept. of Commerce.
4570 [DSS]
4572 digital signatures
4573 Digital signatures utilize public key cryptography and one-way
4574 hash functions to produce a signature of the data that can be
4575 authenticated, and is difficult to forge or repudiate.
4577 handshake
4578 An initial negotiation between client and server that establishes
4579 the parameters of their transactions.
4581 Initialization Vector (IV)
4582 When a block cipher is used in CBC mode, the initialization
4583 vector is exclusive-ORed with the first plaintext block prior to
4584 encryption.
4589 Dierks & Rescorla Standards Track [Page 85]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4592 IDEA
4593 A 64-bit block cipher designed by Xuejia Lai and James Massey.
4594 [IDEA]
4596 Message Authentication Code (MAC)
4597 A Message Authentication Code is a one-way hash computed from a
4598 message and some secret data. It is difficult to forge without
4599 knowing the secret data. Its purpose is to detect if the message
4600 has been altered.
4602 master secret
4603 Secure secret data used for generating encryption keys, MAC
4604 secrets, and IVs.
4606 MD5
4607 MD5 is a secure hashing function that converts an arbitrarily
4608 long data stream into a digest of fixed size (16 bytes). [MD5]
4610 public key cryptography
4611 A class of cryptographic techniques employing two-key ciphers.
4612 Messages encrypted with the public key can only be decrypted with
4613 the associated private key. Conversely, messages signed with the
4614 private key can be verified with the public key.
4616 one-way hash function
4617 A one-way transformation that converts an arbitrary amount of
4618 data into a fixed-length hash. It is computationally hard to
4619 reverse the transformation or to find collisions. MD5 and SHA are
4620 examples of one-way hash functions.
4622 RC2
4623 A block cipher developed by Ron Rivest at RSA Data Security, Inc.
4624 [RSADSI] described in [RC2].
4626 RC4
4627 A stream cipher invented by Ron Rivest. A compatible cipher is
4628 described in [SCH].
4630 RSA
4631 A very widely used public-key algorithm that can be used for
4632 either encryption or digital signing. [RSA]
4634 server
4635 The server is the application entity that responds to requests
4636 for connections from clients. See also under client.
4643 Dierks & Rescorla Standards Track [Page 86]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4646 session
4647 A TLS session is an association between a client and a server.
4648 Sessions are created by the handshake protocol. Sessions define a
4649 set of cryptographic security parameters, which can be shared
4650 among multiple connections. Sessions are used to avoid the
4651 expensive negotiation of new security parameters for each
4652 connection.
4654 session identifier
4655 A session identifier is a value generated by a server that
4656 identifies a particular session.
4658 server write key
4659 The key used to encrypt data written by the server.
4661 server write MAC secret
4662 The secret data used to authenticate data written by the server.
4664 SHA
4665 The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
4666 produces a 20-byte output. Note that all references to SHA
4667 actually use the modified SHA-1 algorithm. [SHA]
4669 SSL
4670 Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
4671 SSL Version 3.0
4673 stream cipher
4674 An encryption algorithm that converts a key into a
4675 cryptographically-strong keystream, which is then exclusive-ORed
4676 with the plaintext.
4678 symmetric cipher
4679 See bulk cipher.
4681 Transport Layer Security (TLS)
4682 This protocol; also, the Transport Layer Security working group
4683 of the Internet Engineering Task Force (IETF). See "Comments" at
4684 the end of this document.
4697 Dierks & Rescorla Standards Track [Page 87]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4700 C. CipherSuite definitions
4702 CipherSuite Key Cipher Hash
4703 Exchange
4705 TLS_NULL_WITH_NULL_NULL NULL NULL NULL
4706 TLS_RSA_WITH_NULL_MD5 RSA NULL MD5
4707 TLS_RSA_WITH_NULL_SHA RSA NULL SHA
4708 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
4709 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
4710 TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA
4711 TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA
4712 TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
4713 TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA
4714 TLS_RSA_WITH_AES_256_SHA RSA AES_256_CBC SHA
4715 TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA
4716 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
4717 TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA
4718 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
4719 TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA
4720 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
4721 TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA
4722 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
4723 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
4724 TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA
4725 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
4726 TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA
4727 TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA
4728 TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA
4729 TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA
4730 TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA
4731 TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA
4732 TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA
4733 TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA
4734 TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA
4735 TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA
4737 Key
4738 Exchange
4739 Algorithm Description Key size limit
4741 DHE_DSS Ephemeral DH with DSS signatures None
4742 DHE_RSA Ephemeral DH with RSA signatures None
4743 DH_anon Anonymous DH, no signatures None
4744 DH_DSS DH with DSS-based certificates None
4745 DH_RSA DH with RSA-based certificates None
4746 RSA = none
4747 NULL No key exchange N/A
4751 Dierks & Rescorla Standards Track [Page 88]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4754 RSA RSA key exchange None
4756 Key Expanded IV Block
4757 Cipher Type Material Key Material Size Size
4759 NULL Stream 0 0 0 N/A
4760 IDEA_CBC Block 16 16 8 8
4761 RC2_CBC_40 Block 5 16 8 8
4762 RC4_40 Stream 5 16 0 N/A
4763 RC4_128 Stream 16 16 0 N/A
4764 DES40_CBC Block 5 8 8 8
4765 DES_CBC Block 8 8 8 8
4766 3DES_EDE_CBC Block 24 24 8 8
4768 Type
4769 Indicates whether this is a stream cipher or a block cipher
4770 running in CBC mode.
4772 Key Material
4773 The number of bytes from the key_block that are used for
4774 generating the write keys.
4776 Expanded Key Material
4777 The number of bytes actually fed into the encryption algorithm
4779 IV Size
4780 How much data needs to be generated for the initialization
4781 vector. Zero for stream ciphers; equal to the block size for
4782 block ciphers.
4784 Block Size
4785 The amount of data a block cipher enciphers in one chunk; a
4786 block cipher running in CBC mode can only encrypt an even
4787 multiple of its block size.
4789 Hash Hash Padding
4790 function Size Size
4791 NULL 0 0
4792 MD5 16 48
4793 SHA 20 40
4805 Dierks & Rescorla Standards Track [Page 89]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4808 D. Implementation Notes
4810 The TLS protocol cannot prevent many common security mistakes. This
4811 section provides several recommendations to assist implementors.
4813 D.1 Random Number Generation and Seeding
4815 TLS requires a cryptographically-secure pseudorandom number generator
4816 (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs
4817 based on secure hash operations, most notably MD5 and/or SHA, are
4818 acceptable, but cannot provide more security than the size of the
4819 random number generator state. (For example, MD5-based PRNGs usually
4820 provide 128 bits of state.)
4822 To estimate the amount of seed material being produced, add the
4823 number of bits of unpredictable information in each seed byte. For
4824 example, keystroke timing values taken from a PC compatible's 18.2 Hz
4825 timer provide 1 or 2 secure bits each, even though the total size of
4826 the counter value is 16 bits or more. To seed a 128-bit PRNG, one
4827 would thus require approximately 100 such timer values.
4829 [RANDOM] provides guidance on the generation of random values.
4831 D.2 Certificates and authentication
4833 Implementations are responsible for verifying the integrity of
4834 certificates and should generally support certificate revocation
4835 messages. Certificates should always be verified to ensure proper
4836 signing by a trusted Certificate Authority (CA). The selection and
4837 addition of trusted CAs should be done very carefully. Users should
4838 be able to view information about the certificate and root CA.
4840 D.3 CipherSuites
4842 TLS supports a range of key sizes and security levels, including some
4843 which provide no or minimal security. A proper implementation will
4844 probably not support many cipher suites. For example, 40-bit
4845 encryption is easily broken, so implementations requiring strong
4846 security should not allow 40-bit keys. Similarly, anonymous Diffie-
4847 Hellman is strongly discouraged because it cannot prevent man-in-the-
4848 middle attacks. Applications should also enforce minimum and maximum
4849 key sizes. For example, certificate chains containing 512-bit RSA
4850 keys or signatures are not appropriate for high-security
4851 applications.
4859 Dierks & Rescorla Standards Track [Page 90]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4862 E. Backward Compatibility With SSL
4864 For historical reasons and in order to avoid a profligate consumption
4865 of reserved port numbers, application protocols which are secured by
4866 TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
4867 connection port: for example, the https protocol (HTTP secured by SSL
4868 or TLS) uses port 443 regardless of which security protocol it is
4869 using. Thus, some mechanism must be determined to distinguish and
4870 negotiate among the various protocols.
4872 TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting
4873 both is easy. TLS clients who wish to negotiate with such older
4874 servers SHOULD send client hello messages using the SSL 3.0 record
4875 format and client hello structure, sending {3, 2} for the version
4876 field to note that they support TLS 1.1. If the server supports only
4877 TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello;
4878 if it supports TLS 1.1 it will respond with a TLS 1.1 server hello.
4879 The negotiation then proceeds as appropriate for the negotiated
4880 protocol.
4882 Similarly, a TLS 1.1 server which wishes to interoperate with TLS
4883 1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages
4884 and respond with a SSL 3.0 server hello if an SSL 3.0 client hello
4885 with a version field of {3, 0} is received, denoting that this client
4886 does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a
4887 version field of {3, 1} is received, the server SHOULD respond with a
4888 TLS 1.0 hello with a version field of {3, 1}.
4890 Whenever a client already knows the highest protocol known to a
4891 server (for example, when resuming a session), it SHOULD initiate the
4892 connection in that native protocol.
4894 TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL
4895 Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept
4896 either client hello format if they wish to support SSL 2.0 clients on
4897 the same connection port. The only deviations from the Version 2.0
4898 specification are the ability to specify a version with a value of
4899 three and the support for more ciphering types in the CipherSpec.
4901 Warning: The ability to send Version 2.0 client hello messages will be
4902 phased out with all due haste. Implementors SHOULD make every
4903 effort to move forward as quickly as possible. Version 3.0
4904 provides better mechanisms for moving to newer versions.
4906 The following cipher specifications are carryovers from SSL Version
4907 2.0. These are assumed to use RSA for key exchange and
4908 authentication.
4913 Dierks & Rescorla Standards Track [Page 91]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4916 V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
4917 V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
4918 V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
4919 V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
4920 = { 0x04,0x00,0x80 };
4921 V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
4922 V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
4923 V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
4925 Cipher specifications native to TLS can be included in Version 2.0
4926 client hello messages using the syntax below. Any V2CipherSpec
4927 element with its first byte equal to zero will be ignored by Version
4928 2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD
4929 also include the TLS equivalent (see Appendix A.5):
4931 V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
4933 Note: TLS 1.2 clients may generate the SSLv2 EXPORT cipher suites in
4934 handshakes for backward compatibility but MUST NOT negotiate them in
4935 TLS 1.2 mode.
4937 E.1. Version 2 client hello
4939 The Version 2.0 client hello message is presented below using this
4940 document's presentation model. The true definition is still assumed
4941 to be the SSL Version 2.0 specification. Note that this message MUST
4942 be sent directly on the wire, not wrapped as an SSLv3 record
4944 uint8 V2CipherSpec[3];
4946 struct {
4947 uint16 msg_length;
4948 uint8 msg_type;
4949 Version version;
4950 uint16 cipher_spec_length;
4951 uint16 session_id_length;
4952 uint16 challenge_length;
4953 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
4954 opaque session_id[V2ClientHello.session_id_length];
4955 opaque challenge[V2ClientHello.challenge_length;
4956 } V2ClientHello;
4958 msg_length
4959 This field is the length of the following data in bytes. The high
4960 bit MUST be 1 and is not part of the length.
4962 msg_type
4963 This field, in conjunction with the version field, identifies a
4967 Dierks & Rescorla Standards Track [Page 92]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
4970 version 2 client hello message. The value SHOULD be one (1).
4972 version
4973 The highest version of the protocol supported by the client
4974 (equals ProtocolVersion.version, see Appendix A.1).
4976 cipher_spec_length
4977 This field is the total length of the field cipher_specs. It
4978 cannot be zero and MUST be a multiple of the V2CipherSpec length
4979 (3).
4981 session_id_length
4982 This field MUST have a value of zero.
4984 challenge_length
4985 The length in bytes of the client's challenge to the server to
4986 authenticate itself. When using the SSLv2 backward compatible
4987 handshake the client MUST use a 32-byte challenge.
4989 cipher_specs
4990 This is a list of all CipherSpecs the client is willing and able
4991 to use. There MUST be at least one CipherSpec acceptable to the
4992 server.
4994 session_id
4995 This field MUST be empty.
4997 challenge
4998 The client challenge to the server for the server to identify
4999 itself is a (nearly) arbitrary length random. The TLS server will
5000 right justify the challenge data to become the ClientHello.random
5001 data (padded with leading zeroes, if necessary), as specified in
5002 this protocol specification. If the length of the challenge is
5003 greater than 32 bytes, only the last 32 bytes are used. It is
5004 legitimate (but not necessary) for a V3 server to reject a V2
5005 ClientHello that has fewer than 16 bytes of challenge data.
5007 Note: Requests to resume a TLS session MUST use a TLS client hello.
5009 E.2. Avoiding man-in-the-middle version rollback
5011 When TLS clients fall back to Version 2.0 compatibility mode, they
5012 SHOULD use special PKCS #1 block formatting. This is done so that TLS
5013 servers will reject Version 2.0 sessions with TLS-capable clients.
5015 When TLS clients are in Version 2.0 compatibility mode, they set the
5016 right-hand (least-significant) 8 random bytes of the PKCS padding
5017 (not including the terminal null of the padding) for the RSA
5021 Dierks & Rescorla Standards Track [Page 93]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5024 encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
5025 to 0x03 (the other padding bytes are random). After decrypting the
5026 ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
5027 error if these eight padding bytes are 0x03. Version 2.0 servers
5028 receiving blocks padded in this manner will proceed normally.
5075 Dierks & Rescorla Standards Track [Page 94]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5078 F. Security analysis
5080 The TLS protocol is designed to establish a secure connection between
5081 a client and a server communicating over an insecure channel. This
5082 document makes several traditional assumptions, including that
5083 attackers have substantial computational resources and cannot obtain
5084 secret information from sources outside the protocol. Attackers are
5085 assumed to have the ability to capture, modify, delete, replay, and
5086 otherwise tamper with messages sent over the communication channel.
5087 This appendix outlines how TLS has been designed to resist a variety
5088 of attacks.
5090 F.1. Handshake protocol
5092 The handshake protocol is responsible for selecting a CipherSpec and
5093 generating a Master Secret, which together comprise the primary
5094 cryptographic parameters associated with a secure session. The
5095 handshake protocol can also optionally authenticate parties who have
5096 certificates signed by a trusted certificate authority.
5098 F.1.1. Authentication and key exchange
5100 TLS supports three authentication modes: authentication of both
5101 parties, server authentication with an unauthenticated client, and
5102 total anonymity. Whenever the server is authenticated, the channel is
5103 secure against man-in-the-middle attacks, but completely anonymous
5104 sessions are inherently vulnerable to such attacks. Anonymous
5105 servers cannot authenticate clients. If the server is authenticated,
5106 its certificate message must provide a valid certificate chain
5107 leading to an acceptable certificate authority. Similarly,
5108 authenticated clients must supply an acceptable certificate to the
5109 server. Each party is responsible for verifying that the other's
5110 certificate is valid and has not expired or been revoked.
5112 The general goal of the key exchange process is to create a
5113 pre_master_secret known to the communicating parties and not to
5114 attackers. The pre_master_secret will be used to generate the
5115 master_secret (see Section 8.1). The master_secret is required to
5116 generate the finished messages, encryption keys, and MAC secrets (see
5117 Sections 7.4.10, 7.4.11 and 6.3). By sending a correct finished
5118 message, parties thus prove that they know the correct
5119 pre_master_secret.
5121 F.1.1.1. Anonymous key exchange
5123 Completely anonymous sessions can be established using RSA or Diffie-
5124 Hellman for key exchange. With anonymous RSA, the client encrypts a
5125 pre_master_secret with the server's uncertified public key extracted
5129 Dierks & Rescorla Standards Track [Page 95]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5132 from the server key exchange message. The result is sent in a client
5133 key exchange message. Since eavesdroppers do not know the server's
5134 private key, it will be infeasible for them to decode the
5135 pre_master_secret.
5137 Note: No anonymous RSA Cipher Suites are defined in this document.
5139 With Diffie-Hellman, the server's public parameters are contained in
5140 the server key exchange message and the client's are sent in the
5141 client key exchange message. Eavesdroppers who do not know the
5142 private values should not be able to find the Diffie-Hellman result
5143 (i.e. the pre_master_secret).
5145 Warning: Completely anonymous connections only provide protection
5146 against passive eavesdropping. Unless an independent tamper-
5147 proof channel is used to verify that the finished messages
5148 were not replaced by an attacker, server authentication is
5149 required in environments where active man-in-the-middle
5150 attacks are a concern.
5152 F.1.1.2. RSA key exchange and authentication
5154 With RSA, key exchange and server authentication are combined. The
5155 public key may be either contained in the server's certificate or may
5156 be a temporary RSA key sent in a server key exchange message. When
5157 temporary RSA keys are used, they are signed by the server's RSA
5158 certificate. The signature includes the current ClientHello.random,
5159 so old signatures and temporary keys cannot be replayed. Servers may
5160 use a single temporary RSA key for multiple negotiation sessions.
5162 Note: The temporary RSA key option is useful if servers need large
5163 certificates but must comply with government-imposed size limits
5164 on keys used for key exchange.
5166 Note that if ephemeral RSA is not used, compromise of the server's
5167 static RSA key results in a loss of confidentiality for all sessions
5168 protected under that static key. TLS users desiring Perfect Forward
5169 Secrecy should use DHE cipher suites. The damage done by exposure of
5170 a private key can be limited by changing one's private key (and
5171 certificate) frequently.
5173 After verifying the server's certificate, the client encrypts a
5174 pre_master_secret with the server's public key. By successfully
5175 decoding the pre_master_secret and producing a correct finished
5176 message, the server demonstrates that it knows the private key
5177 corresponding to the server certificate.
5179 When RSA is used for key exchange, clients are authenticated using
5183 Dierks & Rescorla Standards Track [Page 96]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5186 the certificate verify message (see Section 7.4.10). The client signs
5187 a value derived from the master_secret and all preceding handshake
5188 messages. These handshake messages include the server certificate,
5189 which binds the signature to the server, and ServerHello.random,
5190 which binds the signature to the current handshake process.
5192 F.1.1.3. Diffie-Hellman key exchange with authentication
5194 When Diffie-Hellman key exchange is used, the server can either
5195 supply a certificate containing fixed Diffie-Hellman parameters or
5196 can use the server key exchange message to send a set of temporary
5197 Diffie-Hellman parameters signed with a DSS or RSA certificate.
5198 Temporary parameters are hashed with the hello.random values before
5199 signing to ensure that attackers do not replay old parameters. In
5200 either case, the client can verify the certificate or signature to
5201 ensure that the parameters belong to the server.
5203 If the client has a certificate containing fixed Diffie-Hellman
5204 parameters, its certificate contains the information required to
5205 complete the key exchange. Note that in this case the client and
5206 server will generate the same Diffie-Hellman result (i.e.,
5207 pre_master_secret) every time they communicate. To prevent the
5208 pre_master_secret from staying in memory any longer than necessary,
5209 it should be converted into the master_secret as soon as possible.
5210 Client Diffie-Hellman parameters must be compatible with those
5211 supplied by the server for the key exchange to work.
5213 If the client has a standard DSS or RSA certificate or is
5214 unauthenticated, it sends a set of temporary parameters to the server
5215 in the client key exchange message, then optionally uses a
5216 certificate verify message to authenticate itself.
5218 If the same DH keypair is to be used for multiple handshakes, either
5219 because the client or server has a certificate containing a fixed DH
5220 keypair or because the server is reusing DH keys, care must be taken
5221 to prevent small subgroup attacks. Implementations SHOULD follow the
5222 guidelines found in [SUBGROUP].
5224 Small subgroup attacks are most easily avoided by using one of the
5225 DHE ciphersuites and generating a fresh DH private key (X) for each
5226 handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
5227 computed very quickly so the performance cost is minimized.
5228 Additionally, using a fresh key for each handshake provides Perfect
5229 Forward Secrecy. Implementations SHOULD generate a new X for each
5230 handshake when using DHE ciphersuites.
5232 F.1.2. Version rollback attacks
5237 Dierks & Rescorla Standards Track [Page 97]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5240 Because TLS includes substantial improvements over SSL Version 2.0,
5241 attackers may try to make TLS-capable clients and servers fall back
5242 to Version 2.0. This attack can occur if (and only if) two TLS-
5243 capable parties use an SSL 2.0 handshake.
5245 Although the solution using non-random PKCS #1 block type 2 message
5246 padding is inelegant, it provides a reasonably secure way for Version
5247 3.0 servers to detect the attack. This solution is not secure against
5248 attackers who can brute force the key and substitute a new ENCRYPTED-
5249 KEY-DATA message containing the same key (but with normal padding)
5250 before the application specified wait threshold has expired. Parties
5251 concerned about attacks of this scale should not be using 40-bit
5252 encryption keys anyway. Altering the padding of the least-significant
5253 8 bytes of the PKCS padding does not impact security for the size of
5254 the signed hashes and RSA key lengths used in the protocol, since
5255 this is essentially equivalent to increasing the input block size by
5256 8 bytes.
5258 F.1.3. Detecting attacks against the handshake protocol
5260 An attacker might try to influence the handshake exchange to make the
5261 parties select different encryption algorithms than they would
5262 normally chooses.
5264 For this attack, an attacker must actively change one or more
5265 handshake messages. If this occurs, the client and server will
5266 compute different values for the handshake message hashes. As a
5267 result, the parties will not accept each others' finished messages.
5268 Without the master_secret, the attacker cannot repair the finished
5269 messages, so the attack will be discovered.
5271 F.1.4. Resuming sessions
5273 When a connection is established by resuming a session, new
5274 ClientHello.random and ServerHello.random values are hashed with the
5275 session's master_secret. Provided that the master_secret has not been
5276 compromised and that the secure hash operations used to produce the
5277 encryption keys and MAC secrets are secure, the connection should be
5278 secure and effectively independent from previous connections.
5279 Attackers cannot use known encryption keys or MAC secrets to
5280 compromise the master_secret without breaking the secure hash
5281 operations (which use both SHA and MD5).
5283 Sessions cannot be resumed unless both the client and server agree.
5284 If either party suspects that the session may have been compromised,
5285 or that certificates may have expired or been revoked, it should
5286 force a full handshake. An upper limit of 24 hours is suggested for
5287 session ID lifetimes, since an attacker who obtains a master_secret
5291 Dierks & Rescorla Standards Track [Page 98]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5294 may be able to impersonate the compromised party until the
5295 corresponding session ID is retired. Applications that may be run in
5296 relatively insecure environments should not write session IDs to
5297 stable storage.
5299 F.1.5 Extensions
5301 Security considerations for the extension mechanism in general, and
5302 the design of new extensions, are described in the previous section.
5303 A security analysis of each of the extensions defined in this
5304 document is given below.
5306 In general, implementers should continue to monitor the state of the
5307 art, and address any weaknesses identified.
5310 F.1.5.1 Security of server_name
5312 If a single server hosts several domains, then clearly it is
5313 necessary for the owners of each domain to ensure that this satisfies
5314 their security needs. Apart from this, server_name does not appear
5315 to introduce significant security issues.
5317 Implementations MUST ensure that a buffer overflow does not occur
5318 whatever the values of the length fields in server_name.
5320 Although this document specifies an encoding for internationalized
5321 hostnames in the server_name extension, it does not address any
5322 security issues associated with the use of internationalized
5323 hostnames in TLS - in particular, the consequences of "spoofed" names
5324 that are indistinguishable from another name when displayed or
5325 printed. It is recommended that server certificates not be issued
5326 for internationalized hostnames unless procedures are in place to
5327 mitigate the risk of spoofed hostnames.
5329 6.2. Security of max_fragment_length
5331 The maximum fragment length takes effect immediately, including for
5332 handshake messages. However, that does not introduce any security
5333 complications that are not already present in TLS, since [TLS]
5334 requires implementations to be able to handle fragmented handshake
5335 messages.
5337 Note that as described in section XXX, once a non-null cipher suite
5338 has been activated, the effective maximum fragment length depends on
5339 the cipher suite and compression method, as well as on the negotiated
5340 max_fragment_length. This must be taken into account when sizing
5341 buffers, and checking for buffer overflow.
5345 Dierks & Rescorla Standards Track [Page 99]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5348 F.1.5.2 Security of client_certificate_url
5350 There are two major issues with this extension.
5352 The first major issue is whether or not clients should include
5353 certificate hashes when they send certificate URLs.
5355 When client authentication is used *without* the
5356 client_certificate_url extension, the client certificate chain is
5357 covered by the Finished message hashes. The purpose of including
5358 hashes and checking them against the retrieved certificate chain, is
5359 to ensure that the same property holds when this extension is used -
5360 i.e., that all of the information in the certificate chain retrieved
5361 by the server is as the client intended.
5363 On the other hand, omitting certificate hashes enables functionality
5364 that is desirable in some circumstances - for example clients can be
5365 issued daily certificates that are stored at a fixed URL and need not
5366 be provided to the client. Clients that choose to omit certificate
5367 hashes should be aware of the possibility of an attack in which the
5368 attacker obtains a valid certificate on the client's key that is
5369 different from the certificate the client intended to provide.
5370 Although TLS uses both MD5 and SHA-1 hashes in several other places,
5371 this was not believed to be necessary here. The property required of
5372 SHA-1 is second pre-image resistance.
5374 The second major issue is that support for client_certificate_url
5375 involves the server acting as a client in another URL protocol. The
5376 server therefore becomes subject to many of the same security
5377 concerns that clients of the URL scheme are subject to, with the
5378 added concern that the client can attempt to prompt the server to
5379 connect to some, possibly weird-looking URL.
5381 In general this issue means that an attacker might use the server to
5382 indirectly attack another host that is vulnerable to some security
5383 flaw. It also introduces the possibility of denial of service
5384 attacks in which an attacker makes many connections to the server,
5385 each of which results in the server attempting a connection to the
5386 target of the attack.
5388 Note that the server may be behind a firewall or otherwise able to
5389 access hosts that would not be directly accessible from the public
5390 Internet; this could exacerbate the potential security and denial of
5391 service problems described above, as well as allowing the existence
5392 of internal hosts to be confirmed when they would otherwise be
5393 hidden.
5395 The detailed security concerns involved will depend on the URL
5399 Dierks & Rescorla Standards Track [Page 100]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5402 schemes supported by the server. In the case of HTTP, the concerns
5403 are similar to those that apply to a publicly accessible HTTP proxy
5404 server. In the case of HTTPS, the possibility for loops and
5405 deadlocks to be created exists and should be addressed. In the case
5406 of FTP, attacks similar to FTP bounce attacks arise.
5408 As a result of this issue, it is RECOMMENDED that the
5409 client_certificate_url extension should have to be specifically
5410 enabled by a server administrator, rather than being enabled by
5411 default. It is also RECOMMENDED that URI protocols be enabled by the
5412 administrator individually, and only a minimal set of protocols be
5413 enabled, with unusual protocols offering limited security or whose
5414 security is not well-understood being avoided.
5416 As discussed in [URI], URLs that specify ports other than the default
5417 may cause problems, as may very long URLs (which are more likely to
5418 be useful in exploiting buffer overflow bugs).
5420 Also note that HTTP caching proxies are common on the Internet, and
5421 some proxies do not check for the latest version of an object
5422 correctly. If a request using HTTP (or another caching protocol)
5423 goes through a misconfigured or otherwise broken proxy, the proxy may
5424 return an out-of-date response.
5426 F.1.5.4. Security of trusted_ca_keys
5428 It is possible that which CA root keys a client possesses could be
5429 regarded as confidential information. As a result, the CA root key
5430 indication extension should be used with care.
5432 The use of the SHA-1 certificate hash alternative ensures that each
5433 certificate is specified unambiguously. As for the previous
5434 extension, it was not believed necessary to use both MD5 and SHA-1
5435 hashes.
5437 F.1.5.5. Security of truncated_hmac
5439 It is possible that truncated MACs are weaker than "un-truncated"
5440 MACs. However, no significant weaknesses are currently known or
5441 expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
5443 Note that the output length of a MAC need not be as long as the
5444 length of a symmetric cipher key, since forging of MAC values cannot
5445 be done off-line: in TLS, a single failed MAC guess will cause the
5446 immediate termination of the TLS session.
5448 Since the MAC algorithm only takes effect after the handshake
5449 messages have been authenticated by the hashes in the Finished
5453 Dierks & Rescorla Standards Track [Page 101]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5456 messages, it is not possible for an active attacker to force
5457 negotiation of the truncated HMAC extension where it would not
5458 otherwise be used (to the extent that the handshake authentication is
5459 secure). Therefore, in the event that any security problem were
5460 found with truncated HMAC in future, if either the client or the
5461 server for a given session were updated to take into account the
5462 problem, they would be able to veto use of this extension.
5464 F.1.5.6. Security of status_request
5466 If a client requests an OCSP response, it must take into account that
5467 an attacker's server using a compromised key could (and probably
5468 would) pretend not to support the extension. A client that requires
5469 OCSP validation of certificates SHOULD either contact the OCSP server
5470 directly in this case, or abort the handshake.
5472 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
5473 improve security against attacks that attempt to replay OCSP
5474 responses; see section 4.4.1 of [OCSP] for further details.
5477 F.2. Protecting application data
5479 The master_secret is hashed with the ClientHello.random and
5480 ServerHello.random to produce unique data encryption keys and MAC
5481 secrets for each connection.
5483 Outgoing data is protected with a MAC before transmission. To prevent
5484 message replay or modification attacks, the MAC is computed from the
5485 MAC secret, the sequence number, the message length, the message
5486 contents, and two fixed character strings. The message type field is
5487 necessary to ensure that messages intended for one TLS Record Layer
5488 client are not redirected to another. The sequence number ensures
5489 that attempts to delete or reorder messages will be detected. Since
5490 sequence numbers are 64-bits long, they should never overflow.
5491 Messages from one party cannot be inserted into the other's output,
5492 since they use independent MAC secrets. Similarly, the server-write
5493 and client-write keys are independent so stream cipher keys are used
5494 only once.
5496 If an attacker does break an encryption key, all messages encrypted
5497 with it can be read. Similarly, compromise of a MAC key can make
5498 message modification attacks possible. Because MACs are also
5499 encrypted, message-alteration attacks generally require breaking the
5500 encryption algorithm as well as the MAC.
5502 Note: MAC secrets may be larger than encryption keys, so messages can
5503 remain tamper resistant even if encryption keys are broken.
5507 Dierks & Rescorla Standards Track [Page 102]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5510 F.3. Explicit IVs
5512 [CBCATT] describes a chosen plaintext attack on TLS that depends
5513 on knowing the IV for a record. Previous versions of TLS [TLS1.0]
5514 used the CBC residue of the previous record as the IV and
5515 therefore enabled this attack. This version uses an explicit IV
5516 in order to protect against this attack.
5518 F.4 Security of Composite Cipher Modes
5520 TLS secures transmitted application data via the use of symmetric
5521 encryption and authentication functions defined in the negotiated
5522 ciphersuite. The objective is to protect both the integrity and
5523 confidentiality of the transmitted data from malicious actions by
5524 active attackers in the network. It turns out that the order in
5525 which encryption and authentication functions are applied to the
5526 data plays an important role for achieving this goal [ENCAUTH].
5528 The most robust method, called encrypt-then-authenticate, first
5529 applies encryption to the data and then applies a MAC to the
5530 ciphertext. This method ensures that the integrity and
5531 confidentiality goals are obtained with ANY pair of encryption
5532 and MAC functions provided that the former is secure against
5533 chosen plaintext attacks and the MAC is secure against chosen-
5534 message attacks. TLS uses another method, called authenticate-
5535 then-encrypt, in which first a MAC is computed on the plaintext
5536 and then the concatenation of plaintext and MAC is encrypted.
5537 This method has been proven secure for CERTAIN combinations of
5538 encryption functions and MAC functions, but is not guaranteed to
5539 be secure in general. In particular, it has been shown that there
5540 exist perfectly secure encryption functions (secure even in the
5541 information theoretic sense) that combined with any secure MAC
5542 function fail to provide the confidentiality goal against an
5543 active attack. Therefore, new ciphersuites and operation modes
5544 adopted into TLS need to be analyzed under the authenticate-then-
5545 encrypt method to verify that they achieve the stated integrity
5546 and confidentiality goals.
5548 Currently, the security of the authenticate-then-encrypt method
5549 has been proven for some important cases. One is the case of
5550 stream ciphers in which a computationally unpredictable pad of
5551 the length of the message plus the length of the MAC tag is
5552 produced using a pseudo-random generator and this pad is xor-ed
5553 with the concatenation of plaintext and MAC tag. The other is
5554 the case of CBC mode using a secure block cipher. In this case,
5555 security can be shown if one applies one CBC encryption pass to
5556 the concatenation of plaintext and MAC and uses a new,
5557 independent and unpredictable, IV for each new pair of plaintext
5561 Dierks & Rescorla Standards Track [Page 103]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5564 and MAC. In previous versions of SSL, CBC mode was used properly
5565 EXCEPT that it used a predictable IV in the form of the last
5566 block of the previous ciphertext. This made TLS open to chosen
5567 plaintext attacks. This verson of the protocol is immune to
5568 those attacks. For exact details in the encryption modes proven
5569 secure see [ENCAUTH].
5571 F.5 Denial of Service
5573 TLS is susceptible to a number of denial of service (DoS)
5574 attacks. In particular, an attacker who initiates a large number
5575 of TCP connections can cause a server to consume large amounts of
5576 CPU doing RSA decryption. However, because TLS is generally used
5577 over TCP, it is difficult for the attacker to hide his point of
5578 origin if proper TCP SYN randomization is used [SEQNUM] by the
5579 TCP stack.
5581 Because TLS runs over TCP, it is also susceptible to a number of
5582 denial of service attacks on individual connections. In
5583 particular, attackers can forge RSTs, terminating connections, or
5584 forge partial TLS records, causing the connection to stall.
5585 These attacks cannot in general be defended against by a TCP-
5586 using protocol. Implementors or users who are concerned with this
5587 class of attack should use IPsec AH [AH] or ESP [ESP].
5589 F.6. Final notes
5591 For TLS to be able to provide a secure connection, both the client
5592 and server systems, keys, and applications must be secure. In
5593 addition, the implementation must be free of security errors.
5595 The system is only as strong as the weakest key exchange and
5596 authentication algorithm supported, and only trustworthy
5597 cryptographic functions should be used. Short public keys, 40-bit
5598 bulk encryption keys, and anonymous servers should be used with great
5599 caution. Implementations and users must be careful when deciding
5600 which certificates and certificate authorities are acceptable; a
5601 dishonest certificate authority can do tremendous damage.
5615 Dierks & Rescorla Standards Track [Page 104]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5618 Security Considerations
5620 Security issues are discussed throughout this memo, especially in
5621 Appendices D, E, and F.
5623 Normative References
5624 [AES] National Institute of Standards and Technology,
5625 "Specification for the Advanced Encryption Standard (AES)"
5626 FIPS 197. November 26, 2001.
5628 [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
5629 IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
5631 [DES] ANSI X3.106, "American National Standard for Information
5632 Systems-Data Link Encryption," American National Standards
5633 Institute, 1983.
5635 [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National
5636 Institute of Standards and Technology, U.S. Department of
5637 Commerce, 2000.
5640 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
5641 Hashing for Message Authentication," RFC 2104, February
5642 1997.
5644 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
5645 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
5646 Protocol -- HTTP/1.1", RFC 2616, June 1999.
5648 [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
5649 Series in Information Processing, v. 1, Konstanz: Hartung-
5650 Gorre Verlag, 1992.
5652 [IDNA] Faltstrom, P., Hoffman, P. and A. Costello,
5653 "Internationalizing Domain Names in Applications (IDNA)",
5654 RFC 3490, March 2003.
5656 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
5657 April 1992.
5659 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
5660 Adams, "Internet X.509 Public Key Infrastructure: Online
5661 Certificate Status Protocol - OCSP", RFC 2560, June 1999.
5663 [PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
5664 RSA Cryptography Specifications Version 1.5", RFC 2313,
5665 March 1998.
5669 Dierks & Rescorla Standards Track [Page 105]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5672 [PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
5673 (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
5674 3447, February 2003.
5676 [PKIOP] Housley, R. and P. Hoffman, "Internet X.509 Public Key
5677 Infrastructure - Operation Protocols: FTP and HTTP", RFC
5678 2585, May 1999.
5681 [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
5682 Public Key Infrastructure: Part I: X.509 Certificate and CRL
5683 Profile", RFC 3280, April 2002.
5685 [RC2] Rivest, R., "A Description of the RC2(r) Encryption
5686 Algorithm", RFC 2268, January 1998.
5688 [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
5689 and Source Code in C, 2ed", Published by John Wiley & Sons,
5690 Inc. 1996.
5692 [SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National
5693 Institute of Standards and Technology, U.S. Department of
5694 Commerce., August 2001.
5696 [REQ] Bradner, S., "Key words for use in RFCs to Indicate
5697 Requirement Levels", BCP 14, RFC 2119, March 1997.
5699 [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
5700 Considerations Section in RFCs", RFC 3434, October 1998.
5702 [TLSAES] Chown, P. "Advanced Encryption Standard (AES) Ciphersuites
5703 for Transport Layer Security (TLS)", RFC 3268, June 2002.
5705 [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J.,
5706 Wright, T., "Transport Layer Security (TLS) Extensions", RFC
5707 3546, June 2003.
5708 [TLSKRB] A. Medvinsky, M. Hur, "Addition of Kerberos Cipher Suites to
5709 Transport Layer Security (TLS)", RFC 2712, October 1999.
5712 [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
5713 Resource Identifiers (URI): Generic Syntax", RFC 2396,
5714 August 1998.
5716 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
5717 RFC 3629, November 2003.
5719 [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- 8:2001,
5723 Dierks & Rescorla Standards Track [Page 106]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5726 "Information Systems - Open Systems Interconnection - The
5727 Directory: Public key and Attribute certificate
5728 frameworks."
5730 [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
5731 ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to
5732 ISO/IEC 9594:8:2001.
5734 Informative References
5736 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC
5737 2402, November 1998.
5739 [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
5740 Protocols Based on RSA Encryption Standard PKCS #1" in
5741 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
5742 1-12, 1998.
5744 [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
5745 Problems and Countermeasures",
5746 http://www.openssl.org/~bodo/tls-cbc.txt.
5748 [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
5749 http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
5751 [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
5752 for Protecting Communications (Or: How Secure is SSL?)",
5753 Crypto 2001.
5755 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
5756 Payload (ESP)", RFC 2406, November 1998.
5758 [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
5759 Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
5760 March 2003.
5762 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
5763 Standard," version 1.5, November 1993.
5765 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
5766 Standard," version 1.5, November 1993.
5768 [RANDOM] D. Eastlake 3rd, S. Crocker, J. Schiller. "Randomness
5769 Recommendations for Security", RFC 1750, December 1994.
5771 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
5772 Obtaining Digital Signatures and Public-Key Cryptosystems,"
5773 Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
5777 Dierks & Rescorla Standards Track [Page 107]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5780 120-126.
5782 [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
5783 RFC 1948, May 1996.
5785 [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
5786 Corp., Feb 9, 1995.
5788 [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
5789 Netscape Communications Corp., Nov 18, 1996.
5791 [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup
5792 Attacks on the Diffie-Hellman Key Agreement Method for
5793 S/MIME", RFC 2785, March 2000.
5795 [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
5796 September 1981.
5798 [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
5799 practical", USENIX Security Symposium 2003.
5801 [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0",
5802 RFC 2246, January 1999.
5804 [TLS1.1] Dierks, T., and Rescorla, E., "The TLS Protocol, Version
5805 1.1", RFC 4346, April, 2006.
5807 [X501] ITU-T Recommendation X.501: Information Technology - Open
5808 Systems Interconnection - The Directory: Models, 1993.
5810 [X509] ITU-T Recommendation X.509 (1997 E): Information Technology -
5811 Open Systems Interconnection - "The Directory -
5812 Authentication Framework". 1988.
5814 [XDR] R. Srinivansan, Sun Microsystems, "XDR: External Data
5815 Representation Standard", RFC 1832, August 1995.
5818 Credits
5820 Working Group Chairs
5821 Eric Rescorla
5822 EMail: ekr@rtfm.com
5824 Pasi Eronen
5825 pasi.eronen@nokia.com
5831 Dierks & Rescorla Standards Track [Page 108]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5834 Editors
5836 Tim Dierks Eric Rescorla
5837 Independent Network Resonance, Inc.
5839 EMail: tim@dierks.org EMail: ekr@networkresonance.com
5843 Other contributors
5845 Christopher Allen (co-editor of TLS 1.0)
5846 Alacrity Ventures
5847 ChristopherA@AlacrityManagement.com
5849 Martin Abadi
5850 University of California, Santa Cruz
5851 abadi@cs.ucsc.edu
5853 Steven M. Bellovin
5854 Columbia University
5855 smb@cs.columbia.edu
5857 Simon Blake-Wilson
5858 BCI
5859 EMail: sblakewilson@bcisse.com
5861 Ran Canetti
5862 IBM
5863 canetti@watson.ibm.com
5865 Pete Chown
5866 Skygate Technology Ltd
5867 pc@skygate.co.uk
5869 Taher Elgamal
5870 taher@securify.com
5871 Securify
5873 Anil Gangolli
5874 anil@busybuddha.org
5876 Kipp Hickman
5878 David Hopwood
5879 Independent Consultant
5880 EMail: david.hopwood@blueyonder.co.uk
5885 Dierks & Rescorla Standards Track [Page 109]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5888 Phil Karlton (co-author of SSLv3)
5890 Paul Kocher (co-author of SSLv3)
5891 Cryptography Research
5892 paul@cryptography.com
5894 Hugo Krawczyk
5895 Technion Israel Institute of Technology
5896 hugo@ee.technion.ac.il
5898 Jan Mikkelsen
5899 Transactionware
5900 EMail: janm@transactionware.com
5902 Magnus Nystrom
5903 RSA Security
5904 EMail: magnus@rsasecurity.com
5906 Robert Relyea
5907 Netscape Communications
5908 relyea@netscape.com
5910 Jim Roskind
5911 Netscape Communications
5912 jar@netscape.com
5914 Michael Sabin
5916 Dan Simon
5917 Microsoft, Inc.
5918 dansimon@microsoft.com
5920 Tom Weinstein
5922 Tim Wright
5923 Vodafone
5924 EMail: timothy.wright@vodafone.com
5926 Comments
5928 The discussion list for the IETF TLS working group is located at the
5929 e-mail address <tls@ietf.org>. Information on the group and
5930 information on how to subscribe to the list is at
5931 <https://www1.ietf.org/mailman/listinfo/tls>
5933 Archives of the list can be found at:
5934 <http://www.ietf.org/mail-archive/web/tls/current/index.html>
5939 Dierks & Rescorla Standards Track [Page 110]\fdraft-ietf-tls-rfc4346-bis-01.txt TLS June 2006
5942 Intellectual Property Statement
5944 The IETF takes no position regarding the validity or scope of any
5945 Intellectual Property Rights or other rights that might be claimed to
5946 pertain to the implementation or use of the technology described in
5947 this document or the extent to which any license under such rights
5948 might or might not be available; nor does it represent that it has
5949 made any independent effort to identify any such rights. Information
5950 on the procedures with respect to rights in RFC documents can be
5951 found in BCP 78 and BCP 79.
5953 Copies of IPR disclosures made to the IETF Secretariat and any
5954 assurances of licenses to be made available, or the result of an
5955 attempt made to obtain a general license or permission for the use of
5956 such proprietary rights by implementers or users of this
5957 specification can be obtained from the IETF on-line IPR repository at
5958 http://www.ietf.org/ipr.
5960 The IETF invites any interested party to bring to its attention any
5961 copyrights, patents or patent applications, or other proprietary
5962 rights that may cover technology that may be required to implement
5963 this standard. Please address the information to the IETF at
5964 ietf-ipr@ietf.org.
5967 Disclaimer of Validity
5969 This document and the information contained herein are provided on an
5970 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
5971 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
5972 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
5973 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
5974 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
5975 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5978 Copyright Statement
5980 Copyright (C) The Internet Society (2006). This document is subject
5981 to the rights, licenses and restrictions contained in BCP 78, and
5982 except as set forth therein, the authors retain all their rights.
5985 Acknowledgment
5987 Funding for the RFC Editor function is currently provided by the
5988 Internet Society.
5993 Dierks & Rescorla Standards Track [Page 111]\f