| blob | 8911c2549b691bd85d53575cc471909f27d0cc43 |
7 INTERNET-DRAFT Tim Dierks
8 Obsoletes (if approved): RFC 3268, 4346, 4366 Independent
9 Updates (if approved): RFC 4492 Eric Rescorla
10 Intended status: Proposed Standard Network Resonance, Inc.
11 <draft-ietf-tls-rfc4346-bis-10.txt> March 2008 (Expires September 2008)
14 The Transport Layer Security (TLS) Protocol
15 Version 1.2
17 Status of this Memo
19 By submitting this Internet-Draft, each author represents that any
20 applicable patent or other IPR claims of which he or she is aware
21 have been or will be disclosed, and any of which he or she becomes
22 aware will be disclosed, in accordance with Section 6 of BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF), its areas, and its working groups. Note that
26 other groups may also distribute working documents as Internet-
27 Drafts.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/ietf/1id-abstracts.txt.
37 The list of Internet-Draft Shadow Directories can be accessed at
38 http://www.ietf.org/shadow.html.
40 Copyright Notice
42 Copyright (C) The IETF Trust (2008).
44 Abstract
46 This document specifies Version 1.2 of the Transport Layer Security
47 (TLS) protocol. The TLS protocol provides communications security
48 over the Internet. The protocol allows client/server applications to
49 communicate in a way that is designed to prevent eavesdropping,
50 tampering, or message forgery.
58 Dierks & Rescorla Standards Track [Page 1]
59 \f
60 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
63 Table of Contents
65 1. Introduction 4
66 1.1. Requirements Terminology 5
67 1.2. Major Differences from TLS 1.1 5
68 2. Goals 6
69 3. Goals of This Document 7
70 4. Presentation Language 7
71 4.1. Basic Block Size 7
72 4.2. Miscellaneous 7
73 4.3. Vectors 8
74 4.4. Numbers 9
75 4.5. Enumerateds 9
76 4.6. Constructed Types 10
77 4.6.1. Variants 10
78 4.7. Cryptographic Attributes 11
79 4.8. Constants 13
80 5. HMAC and the Pseudorandom Function 14
81 6. The TLS Record Protocol 15
82 6.1. Connection States 16
83 6.2. Record layer 18
84 6.2.1. Fragmentation 19
85 6.2.2. Record Compression and Decompression 20
86 6.2.3. Record Payload Protection 21
87 6.2.3.1. Null or Standard Stream Cipher 21
88 6.2.3.2. CBC Block Cipher 22
89 6.2.3.3. AEAD ciphers 24
90 6.3. Key Calculation 25
91 7. The TLS Handshaking Protocols 26
92 7.1. Change Cipher Spec Protocol 27
93 7.2. Alert Protocol 27
94 7.2.1. Closure Alerts 28
95 7.2.2. Error Alerts 29
96 7.3. Handshake Protocol Overview 33
97 7.4. Handshake Protocol 37
98 7.4.1. Hello Messages 38
99 7.4.1.1. Hello Request 38
100 7.4.1.2. Client Hello 39
101 7.4.1.3. Server Hello 42
102 7.4.1.4 Hello Extensions 43
103 7.4.1.4.1 Signature Algorithms 45
104 7.4.2. Server Certificate 46
105 7.4.3. Server Key Exchange Message 49
106 7.4.4. Certificate Request 51
107 7.4.5 Server Hello Done 53
108 7.4.6. Client Certificate 53
109 7.4.7. Client Key Exchange Message 55
110 7.4.7.1. RSA Encrypted Premaster Secret Message 56
114 Dierks & Rescorla Standards Track [Page 2]
115 \f
116 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
119 7.4.7.2. Client Diffie-Hellman Public Value 58
120 7.4.8. Certificate verify 59
121 7.4.9. Finished 60
122 8. Cryptographic Computations 62
123 8.1. Computing the Master Secret 62
124 8.1.1. RSA 62
125 8.1.2. Diffie-Hellman 62
126 9. Mandatory Cipher Suites 63
127 10. Application Data Protocol 63
128 11. Security Considerations 63
129 12. IANA Considerations 63
130 A. Protocol Data Structures and Constant Values 65
131 A.1. Record Layer 65
132 A.2. Change Cipher Specs Message 66
133 A.3. Alert Messages 66
134 A.4. Handshake Protocol 67
135 A.4.1. Hello Messages 67
136 A.4.2. Server Authentication and Key Exchange Messages 69
137 A.4.3. Client Authentication and Key Exchange Messages 70
138 A.4.4. Handshake Finalization Message 71
139 A.5. The Cipher Suite 71
140 A.6. The Security Parameters 73
141 A.7. Changes to RFC 4492 74
142 B. Glossary 74
143 C. Cipher Suite Definitions 79
144 D. Implementation Notes 81
145 D.1 Random Number Generation and Seeding 81
146 D.2 Certificates and Authentication 81
147 D.3 Cipher Suites 81
148 D.4 Implementation Pitfalls 81
149 E. Backward Compatibility 84
150 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 84
151 E.2 Compatibility with SSL 2.0 85
152 E.3. Avoiding Man-in-the-Middle Version Rollback 87
153 F. Security Analysis 88
154 F.1. Handshake Protocol 88
155 F.1.1. Authentication and Key Exchange 88
156 F.1.1.1. Anonymous Key Exchange 88
157 F.1.1.2. RSA Key Exchange and Authentication 89
158 F.1.1.3. Diffie-Hellman Key Exchange with Authentication 89
159 F.1.2. Version Rollback Attacks 90
160 F.1.3. Detecting Attacks Against the Handshake Protocol 91
161 F.1.4. Resuming Sessions 91
162 F.2. Protecting Application Data 91
163 F.3. Explicit IVs 92
164 F.4. Security of Composite Cipher Modes 92
165 F.5 Denial of Service 93
166 F.6 Final Notes 93
170 Dierks & Rescorla Standards Track [Page 3]
171 \f
172 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
175 1. Introduction
177 The primary goal of the TLS Protocol is to provide privacy and data
178 integrity between two communicating applications. The protocol is
179 composed of two layers: the TLS Record Protocol and the TLS Handshake
180 Protocol. At the lowest level, layered on top of some reliable
181 transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
182 TLS Record Protocol provides connection security that has two basic
183 properties:
185 - The connection is private. Symmetric cryptography is used for
186 data encryption (e.g., AES [AES], RC4 [SCH] etc.). The keys for
187 this symmetric encryption are generated uniquely for each
188 connection and are based on a secret negotiated by another
189 protocol (such as the TLS Handshake Protocol). The Record Protocol
190 can also be used without encryption.
192 - The connection is reliable. Message transport includes a message
193 integrity check using a keyed MAC. Secure hash functions (e.g.,
194 SHA-1, etc.) are used for MAC computations. The Record Protocol
195 can operate without a MAC, but is generally only used in this mode
196 while another protocol is using the Record Protocol as a transport
197 for negotiating security parameters.
199 The TLS Record Protocol is used for encapsulation of various higher-
200 level protocols. One such encapsulated protocol, the TLS Handshake
201 Protocol, allows the server and client to authenticate each other and
202 to negotiate an encryption algorithm and cryptographic keys before
203 the application protocol transmits or receives its first byte of
204 data. The TLS Handshake Protocol provides connection security that
205 has three basic properties:
207 - The peer's identity can be authenticated using asymmetric, or
208 public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.). This
209 authentication can be made optional, but is generally required for
210 at least one of the peers.
212 - The negotiation of a shared secret is secure: the negotiated
213 secret is unavailable to eavesdroppers, and for any authenticated
214 connection the secret cannot be obtained, even by an attacker who
215 can place himself in the middle of the connection.
217 - The negotiation is reliable: no attacker can modify the
218 negotiation communication without being detected by the parties to
219 the communication.
221 One advantage of TLS is that it is application protocol independent.
222 Higher-level protocols can layer on top of the TLS Protocol
226 Dierks & Rescorla Standards Track [Page 4]
227 \f
228 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
231 transparently. The TLS standard, however, does not specify how
232 protocols add security with TLS; the decisions on how to initiate TLS
233 handshaking and how to interpret the authentication certificates
234 exchanged are left to the judgment of the designers and implementors
235 of protocols that run on top of TLS.
237 1.1. Requirements Terminology
239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
241 document are to be interpreted as described in RFC 2119 [REQ].
243 1.2. Major Differences from TLS 1.1
245 This document is a revision of the TLS 1.1 [TLS1.1] protocol which
246 contains improved flexibility, particularly for negotiation of
247 cryptographic algorithms. The major changes are:
249 - The MD5/SHA-1 combination in the pseudorandom function (PRF) has
250 been replaced with cipher suite specified PRFs. All cipher suites
251 in this document use P_SHA256.
253 - The MD5/SHA-1 combination in the digitally-signed element has been
254 replaced with a single hash. Signed elements now include a field
255 that explicitly specifies the hash algorithm used.
257 - Substantial cleanup to the client's and server's ability to
258 specify which hash and signature algorithms they will accept. Note
259 that this also relaxes some of the constraints on signature and
260 hash algorithms from previous versions of TLS.
262 - Addition of support for authenticated encryption with additional
263 data modes.
265 - TLS Extensions definition and AES Cipher Suites were merged in
266 from external [TLSEXT] and [TLSAES].
268 - Tighter checking of EncryptedPreMasterSecret version numbers.
270 - Tightened up a number of requirements.
272 - Verify_data length now depends on the cipher suite (default is
273 still 12).
275 - Cleaned up description of Bleichenbacher/Klima attack defenses.
277 - Alerts MUST now be sent in many cases.
282 Dierks & Rescorla Standards Track [Page 5]
283 \f
284 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
287 - After a certificate_request, if no certificates are available,
288 clients now MUST send an empty certificate list.
290 - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
291 cipher suite.
293 - Added HMAC-SHA256 cipher suites
295 - Removed IDEA and DES cipher suites. They are now deprecated and
296 will be documented in a separate document.
298 - Support for the SSLv2 backward-compatible hello is now a MAY, not
299 a SHOULD, with sending it a SHOULD NOT. Support will probably
300 become a SHOULD NOT in the future.
302 - Added limited "fall-through" to the presentation language to allow
303 multiple case arms to have the same encoding.
305 - Added an Implementation Pitfalls sections
307 - The usual clarifications and editorial work.
309 2. Goals
311 The goals of TLS Protocol, in order of their priority, are as
312 follows:
314 1. Cryptographic security: TLS should be used to establish a secure
315 connection between two parties.
317 2. Interoperability: Independent programmers should be able to
318 develop applications utilizing TLS that can successfully exchange
319 cryptographic parameters without knowledge of one another's code.
321 3. Extensibility: TLS seeks to provide a framework into which new
322 public key and bulk encryption methods can be incorporated as
323 necessary. This will also accomplish two sub-goals: preventing the
324 need to create a new protocol (and risking the introduction of
325 possible new weaknesses) and avoiding the need to implement an
326 entire new security library.
328 4. Relative efficiency: Cryptographic operations tend to be highly
329 CPU intensive, particularly public key operations. For this
330 reason, the TLS protocol has incorporated an optional session
331 caching scheme to reduce the number of connections that need to be
332 established from scratch. Additionally, care has been taken to
333 reduce network activity.
338 Dierks & Rescorla Standards Track [Page 6]
339 \f
340 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
343 3. Goals of This Document
345 This document and the TLS protocol itself are based on the SSL 3.0
346 Protocol Specification as published by Netscape. The differences
347 between this protocol and SSL 3.0 are not dramatic, but they are
348 significant enough that the various versions of TLS and SSL 3.0 do
349 not interoperate (although each protocol incorporates a mechanism by
350 which an implementation can back down to prior versions). This
351 document is intended primarily for readers who will be implementing
352 the protocol and for those doing cryptographic analysis of it. The
353 specification has been written with this in mind, and it is intended
354 to reflect the needs of those two groups. For that reason, many of
355 the algorithm-dependent data structures and rules are included in the
356 body of the text (as opposed to in an appendix), providing easier
357 access to them.
359 This document is not intended to supply any details of service
360 definition or of interface definition, although it does cover select
361 areas of policy as they are required for the maintenance of solid
362 security.
365 4. Presentation Language
367 This document deals with the formatting of data in an external
368 representation. The following very basic and somewhat casually
369 defined presentation syntax will be used. The syntax draws from
370 several sources in its structure. Although it resembles the
371 programming language "C" in its syntax and XDR [XDR] in both its
372 syntax and intent, it would be risky to draw too many parallels. The
373 purpose of this presentation language is to document TLS only; it has
374 no general application beyond that particular goal.
376 4.1. Basic Block Size
378 The representation of all data items is explicitly specified. The
379 basic data block size is one byte (i.e., 8 bits). Multiple byte data
380 items are concatenations of bytes, from left to right, from top to
381 bottom. From the bytestream, a multi-byte item (a numeric in the
382 example) is formed (using C notation) by:
384 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
385 ... | byte[n-1];
387 This byte ordering for multi-byte values is the commonplace network
388 byte order or big endian format.
390 4.2. Miscellaneous
394 Dierks & Rescorla Standards Track [Page 7]
395 \f
396 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
399 Comments begin with "/*" and end with "*/".
401 Optional components are denoted by enclosing them in "[[ ]]" double
402 brackets.
404 Single-byte entities containing uninterpreted data are of type
405 opaque.
407 4.3. Vectors
409 A vector (single dimensioned array) is a stream of homogeneous data
410 elements. The size of the vector may be specified at documentation
411 time or left unspecified until runtime. In either case, the length
412 declares the number of bytes, not the number of elements, in the
413 vector. The syntax for specifying a new type, T', that is a fixed-
414 length vector of type T is
416 T T'[n];
418 Here, T' occupies n bytes in the data stream, where n is a multiple
419 of the size of T. The length of the vector is not included in the
420 encoded stream.
422 In the following example, Datum is defined to be three consecutive
423 bytes that the protocol does not interpret, while Data is three
424 consecutive Datum, consuming a total of nine bytes.
426 opaque Datum[3]; /* three uninterpreted bytes */
427 Datum Data[9]; /* 3 consecutive 3 byte vectors */
429 Variable-length vectors are defined by specifying a subrange of legal
430 lengths, inclusively, using the notation <floor..ceiling>. When
431 these are encoded, the actual length precedes the vector's contents
432 in the byte stream. The length will be in the form of a number
433 consuming as many bytes as required to hold the vector's specified
434 maximum (ceiling) length. A variable-length vector with an actual
435 length field of zero is referred to as an empty vector.
437 T T'<floor..ceiling>;
439 In the following example, mandatory is a vector that must contain
440 between 300 and 400 bytes of type opaque. It can never be empty. The
441 actual length field consumes two bytes, a uint16, sufficient to
442 represent the value 400 (see Section 4.4). On the other hand, longer
443 can represent up to 800 bytes of data, or 400 uint16 elements, and it
444 may be empty. Its encoding will include a two-byte actual length
445 field prepended to the vector. The length of an encoded vector must
446 be an even multiple of the length of a single element (for example, a
450 Dierks & Rescorla Standards Track [Page 8]
451 \f
452 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
455 17-byte vector of uint16 would be illegal).
457 opaque mandatory<300..400>;
458 /* length field is 2 bytes, cannot be empty */
459 uint16 longer<0..800>;
460 /* zero to 400 16-bit unsigned integers */
462 4.4. Numbers
464 The basic numeric data type is an unsigned byte (uint8). All larger
465 numeric data types are formed from fixed-length series of bytes
466 concatenated as described in Section 4.1 and are also unsigned. The
467 following numeric types are predefined.
469 uint8 uint16[2];
470 uint8 uint24[3];
471 uint8 uint32[4];
472 uint8 uint64[8];
474 All values, here and elsewhere in the specification, are stored in
475 "network" or "big-endian" order; the uint32 represented by the hex
476 bytes 01 02 03 04 is equivalent to the decimal value 16909060.
478 Note that in some cases (e.g., DH parameters) it is necessary to
479 represent integers as opaque vectors. In such cases, they are
480 represented as unsigned integers (i.e., leading zero octets are not
481 required even if the most significant bit is set).
483 4.5. Enumerateds
485 An additional sparse data type is available called enum. A field of
486 type enum can only assume the values declared in the definition.
487 Each definition is a different type. Only enumerateds of the same
488 type may be assigned or compared. Every element of an enumerated must
489 be assigned a value, as demonstrated in the following example. Since
490 the elements of the enumerated are not ordered, they can be assigned
491 any unique value, in any order.
493 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
495 Enumerateds occupy as much space in the byte stream as would its
496 maximal defined ordinal value. The following definition would cause
497 one byte to be used to carry fields of type Color.
499 enum { red(3), blue(5), white(7) } Color;
501 One may optionally specify a value without its associated tag to
502 force the width definition without defining a superfluous element.
506 Dierks & Rescorla Standards Track [Page 9]
507 \f
508 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
511 In the following example, Taste will consume two bytes in the data
512 stream but can only assume the values 1, 2, or 4.
514 enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
516 The names of the elements of an enumeration are scoped within the
517 defined type. In the first example, a fully qualified reference to
518 the second element of the enumeration would be Color.blue. Such
519 qualification is not required if the target of the assignment is well
520 specified.
522 Color color = Color.blue; /* overspecified, legal */
523 Color color = blue; /* correct, type implicit */
525 For enumerateds that are never converted to external representation,
526 the numerical information may be omitted.
528 enum { low, medium, high } Amount;
530 4.6. Constructed Types
532 Structure types may be constructed from primitive types for
533 convenience. Each specification declares a new, unique type. The
534 syntax for definition is much like that of C.
536 struct {
537 T1 f1;
538 T2 f2;
539 ...
540 Tn fn;
541 } [[T]];
543 The fields within a structure may be qualified using the type's name,
544 with a syntax much like that available for enumerateds. For example,
545 T.f2 refers to the second field of the previous declaration.
546 Structure definitions may be embedded.
548 4.6.1. Variants
550 Defined structures may have variants based on some knowledge that is
551 available within the environment. The selector must be an enumerated
552 type that defines the possible variants the structure defines. There
553 must be a case arm for every element of the enumeration declared in
554 the select. Case arms have limited fall-through: if two case arms
555 follow in immediate succession with no fields in between, then they
556 both contain the same fields. Thus, in the example below, "orange"
557 and "banana" both contain V2. Note that this is a new piece of syntax
558 in TLS 1.2.
562 Dierks & Rescorla Standards Track [Page 10]
563 \f
564 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
567 The body of the variant structure may be given a label for reference.
568 The mechanism by which the variant is selected at runtime is not
569 prescribed by the presentation language.
571 struct {
572 T1 f1;
573 T2 f2;
574 ....
575 Tn fn;
576 select (E) {
577 case e1: Te1;
578 case e2: Te2;
579 case e3: case e4: Te3;
580 ....
581 case en: Ten;
582 } [[fv]];
583 } [[Tv]];
585 For example:
587 enum { apple, orange, banana } VariantTag;
589 struct {
590 uint16 number;
591 opaque string<0..10>; /* variable length */
592 } V1;
594 struct {
595 uint32 number;
596 opaque string[10]; /* fixed length */
597 } V2;
599 struct {
600 select (VariantTag) { /* value of selector is implicit */
601 case apple:
602 V1; /* VariantBody, tag = apple */
603 case orange:
604 case banana:
605 V2; /* VariantBody, tag = orange or banana */
606 } variant_body; /* optional label on variant */
607 } VariantRecord;
610 4.7. Cryptographic Attributes
612 The five cryptographic operations digital signing, stream cipher
613 encryption, block cipher encryption, authenticated encryption with
614 additional data (AEAD) encryption and public key encryption are
618 Dierks & Rescorla Standards Track [Page 11]
619 \f
620 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
623 designated digitally-signed, stream-ciphered, block-ciphered, aead-
624 ciphered, and public-key-encrypted, respectively. A field's
625 cryptographic processing is specified by prepending an appropriate
626 key word designation before the field's type specification.
627 Cryptographic keys are implied by the current session state (see
628 Section 6.1).
630 A digitally-signed element is encoded as a struct DigitallySigned:
632 struct {
633 SignatureAndHashAlgorithm algorithm;
634 opaque signature<0..2^16-1>;
635 } DigitallySigned;
637 The algorithm field specifies the algorithm used (see Section
638 7.4.1.4.1 for the definition of this field.) Note that the
639 introduction of the algorithm field is a change from previous
640 versions. The signature is a digital signature using those
641 algorithms over the contents of the element. The contents themselves
642 do not appear on the wire but are simply calculated. The length of
643 the signature is specified by the signing algorithm and key.
645 In RSA signing, the opaque vector contains the signature generated
646 using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As
647 discussed in [PKCS1], the DigestInfo MUST be DER [X680] [X690]
648 encoded and for hash algorithms without parameters (which include
649 SHA-1) the DigestInfo.AlgorithmIdentifier.parameters field MUST be
650 NULL but implementations MUST accept both without parameters and with
651 NULL parameters. Note that earlier versions of TLS used a different
652 RSA signature scheme which did not include a DigestInfo encoding.
654 In DSA, the 20 bytes of the SHA-1 hash are run directly through the
655 Digital Signing Algorithm with no additional hashing. This produces
656 two values, r and s. The DSA signature is an opaque vector, as above,
657 the contents of which are the DER encoding of:
659 Dss-Sig-Value ::= SEQUENCE {
660 r INTEGER,
661 s INTEGER
662 }
664 Note: In current terminology, DSA refers to the Digital Signature
665 Algorithm and DSS refers to the NIST standard. In the original
666 SSL and TLS specs, "DSS" was used universally. This document
667 uses "DSA" to refer to the algorithm, "DSS" to refer to the
668 standard, and uses "DSS" in the code point definitions for
669 historical continuity.
674 Dierks & Rescorla Standards Track [Page 12]
675 \f
676 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
679 In stream cipher encryption, the plaintext is exclusive-ORed with an
680 identical amount of output generated from a cryptographically secure
681 keyed pseudorandom number generator.
683 In block cipher encryption, every block of plaintext encrypts to a
684 block of ciphertext. All block cipher encryption is done in CBC
685 (Cipher Block Chaining) mode, and all items that are block-ciphered
686 will be an exact multiple of the cipher block length.
688 In AEAD encryption, the plaintext is simultaneously encrypted and
689 integrity protected. The input may be of any length and aead-ciphered
690 output is generally larger than the input in order to accomodate the
691 integrity check value.
693 In public key encryption, a public key algorithm is used to encrypt
694 data in such a way that it can be decrypted only with the matching
695 private key. A public-key-encrypted element is encoded as an opaque
696 vector <0..2^16-1>, where the length is specified by the encryption
697 algorithm and key.
699 RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
700 defined in [PKCS1].
702 In the following example
704 stream-ciphered struct {
705 uint8 field1;
706 uint8 field2;
707 digitally-signed opaque {
708 uint8 field3<0..255>;
709 uint8 field4;
710 };
711 } UserType;
714 The contents of the inner struct (field3 and field4) are used as
715 input for the signature/hash algorithm, and then the entire structure
716 is encrypted with a stream cipher. The length of this structure, in
717 bytes, would be equal to two bytes for field1 and field2, plus two
718 bytes for the signature and hash algorithm, plus two bytes for the
719 length of the signature, plus the length of the output of the signing
720 algorithm. This is known because the algorithm and key used for the
721 signing are known prior to encoding or decoding this structure.
723 4.8. Constants
725 Typed constants can be defined for purposes of specification by
726 declaring a symbol of the desired type and assigning values to it.
730 Dierks & Rescorla Standards Track [Page 13]
731 \f
732 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
735 Under-specified types (opaque, variable length vectors, and
736 structures that contain opaque) cannot be assigned values. No fields
737 of a multi-element structure or vector may be elided.
739 For example:
741 struct {
742 uint8 f1;
743 uint8 f2;
744 } Example1;
746 Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
749 5. HMAC and the Pseudorandom Function
751 The TLS record layer uses a keyed Message Authentication Code (MAC)
752 to protect message integrity. The cipher suites defined in this
753 document use a construction known as HMAC, described in [HMAC], which
754 is based on a hash function. Other cipher suites MAY define their own
755 MAC constructions, if needed.
757 In addition, a construction is required to do expansion of secrets
758 into blocks of data for the purposes of key generation or validation.
759 This pseudo-random function (PRF) takes as input a secret, a seed,
760 and an identifying label and produces an output of arbitrary length.
762 In this section, we define one PRF, based on HMAC. This PRF with the
763 SHA-256 hash function is used for all cipher suites defined in this
764 document and in TLS documents published prior to this document when
765 TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a
766 PRF and in general SHOULD use the TLS PRF with SHA-256 or a stronger
767 standard hash function.
769 First, we define a data expansion function, P_hash(secret, data) that
770 uses a single hash function to expand a secret and seed into an
771 arbitrary quantity of output:
773 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
774 HMAC_hash(secret, A(2) + seed) +
775 HMAC_hash(secret, A(3) + seed) + ...
777 Where + indicates concatenation.
779 A() is defined as:
781 A(0) = seed
782 A(i) = HMAC_hash(secret, A(i-1))
786 Dierks & Rescorla Standards Track [Page 14]
787 \f
788 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
791 P_hash can be iterated as many times as is necessary to produce the
792 required quantity of data. For example, if P_SHA256 is being used to
793 create 80 bytes of data, it will have to be iterated three times
794 (through A(3)), creating 96 bytes of output data; the last 16 bytes
795 of the final iteration will then be discarded, leaving 80 bytes of
796 output data.
798 TLS's PRF is created by applying P_hash to the secret as:
800 PRF(secret, label, seed) = P_<hash>(secret, label + seed)
802 The label is an ASCII string. It should be included in the exact form
803 it is given without a length byte or trailing null character. For
804 example, the label "slithy toves" would be processed by hashing the
805 following bytes:
807 73 6C 69 74 68 79 20 74 6F 76 65 73
810 6. The TLS Record Protocol
812 The TLS Record Protocol is a layered protocol. At each layer,
813 messages may include fields for length, description, and content.
814 The Record Protocol takes messages to be transmitted, fragments the
815 data into manageable blocks, optionally compresses the data, applies
816 a MAC, encrypts, and transmits the result. Received data is
817 decrypted, verified, decompressed, reassembled, and then delivered to
818 higher-level clients.
820 Four protocols that use the record protocol are described in this
821 document: the handshake protocol, the alert protocol, the change
822 cipher spec protocol, and the application data protocol. In order to
823 allow extension of the TLS protocol, additional record content types
824 can be supported by the record protocol. New record content type
825 values are assigned by IANA in the TLS Content Type Registry as
826 described in Section 12.
828 Implementations MUST NOT send record types not defined in this
829 document unless negotiated by some extension. If a TLS
830 implementation receives an unexpected record type, it MUST send an
831 unexpected_message alert.
833 Any protocol designed for use over TLS must be carefully designed to
834 deal with all possible attacks against it. As a practical matter,
835 this means that the protocol designer must be aware of what security
836 properties TLS does and does not provide and cannot safely rely on
837 the latter.
842 Dierks & Rescorla Standards Track [Page 15]
843 \f
844 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
847 Note in particular that type and length of a record are not protected
848 by encryption. If this information is itself sensitive, application
849 designers may wish to take steps (padding, cover traffic) to minimize
850 information leakage.
852 6.1. Connection States
854 A TLS connection state is the operating environment of the TLS Record
855 Protocol. It specifies a compression algorithm, an encryption
856 algorithm, and a MAC algorithm. In addition, the parameters for these
857 algorithms are known: the MAC key and the bulk encryption keys for
858 the connection in both the read and the write directions. Logically,
859 there are always four connection states outstanding: the current read
860 and write states, and the pending read and write states. All records
861 are processed under the current read and write states. The security
862 parameters for the pending states can be set by the TLS Handshake
863 Protocol, and the ChangeCipherSpec can selectively make either of the
864 pending states current, in which case the appropriate current state
865 is disposed of and replaced with the pending state; the pending state
866 is then reinitialized to an empty state. It is illegal to make a
867 state that has not been initialized with security parameters a
868 current state. The initial current state always specifies that no
869 encryption, compression, or MAC will be used.
871 The security parameters for a TLS Connection read and write state are
872 set by providing the following values:
874 connection end
875 Whether this entity is considered the "client" or the "server" in
876 this connection.
878 PRF algorithm
879 An algorithm used to generate keys from the master secret (see
880 Sections 5 and 6.3).
882 bulk encryption algorithm
883 An algorithm to be used for bulk encryption. This specification
884 includes the key size of this algorithm, whether it is a block,
885 stream, or AEAD cipher, the block size of the cipher (if
886 appropriate), and the lengths of explicit and implicit
887 initialization vectors (or nonces).
889 MAC algorithm
890 An algorithm to be used for message authentication. This
891 specification includes the size of the value returned by the MAC
892 algorithm.
894 compression algorithm
898 Dierks & Rescorla Standards Track [Page 16]
899 \f
900 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
903 An algorithm to be used for data compression. This specification
904 must include all information the algorithm requires to do
905 compression.
907 master secret
908 A 48-byte secret shared between the two peers in the connection.
910 client random
911 A 32-byte value provided by the client.
913 server random
914 A 32-byte value provided by the server.
916 These parameters are defined in the presentation language as:
918 enum { server, client } ConnectionEnd;
920 enum { tls_prf_sha256 } PRFAlgorithm;
922 enum { null, rc4, 3des, aes }
923 BulkCipherAlgorithm;
925 enum { stream, block, aead } CipherType;
927 enum { null, hmac_md5, hmac_sha1, hmac_sha256,
928 hmac_sha384, hmac_sha512} MACAlgorithm;
930 enum { null(0), (255) } CompressionMethod;
932 /* The algorithms specified in CompressionMethod, PRFAlgorithm
933 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
935 struct {
936 ConnectionEnd entity;
937 PRFAlgorithm prf_algorithm;
938 BulkCipherAlgorithm bulk_cipher_algorithm;
939 CipherType cipher_type;
940 uint8 enc_key_length;
941 uint8 block_length;
942 uint8 fixed_iv_length;
943 uint8 record_iv_length;
944 MACAlgorithm mac_algorithm;
945 uint8 mac_length;
946 uint8 mac_key_length;
947 CompressionMethod compression_algorithm;
948 opaque master_secret[48];
949 opaque client_random[32];
950 opaque server_random[32];
954 Dierks & Rescorla Standards Track [Page 17]
955 \f
956 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
959 } SecurityParameters;
961 The record layer will use the security parameters to generate the
962 following six items (some of which are not required by all ciphers,
963 and are thus empty):
965 client write MAC key
966 server write MAC key
967 client write encryption key
968 server write encryption key
969 client write IV
970 server write IV
972 The client write parameters are used by the server when receiving and
973 processing records and vice-versa. The algorithm used for generating
974 these items from the security parameters is described in Section 6.3.
976 Once the security parameters have been set and the keys have been
977 generated, the connection states can be instantiated by making them
978 the current states. These current states MUST be updated for each
979 record processed. Each connection state includes the following
980 elements:
982 compression state
983 The current state of the compression algorithm.
985 cipher state
986 The current state of the encryption algorithm. This will consist
987 of the scheduled key for that connection. For stream ciphers, this
988 will also contain whatever state information is necessary to allow
989 the stream to continue to encrypt or decrypt data.
991 MAC key
992 The MAC key for this connection, as generated above.
994 sequence number
995 Each connection state contains a sequence number, which is
996 maintained separately for read and write states. The sequence
997 number MUST be set to zero whenever a connection state is made the
998 active state. Sequence numbers are of type uint64 and may not
999 exceed 2^64-1. Sequence numbers do not wrap. If a TLS
1000 implementation would need to wrap a sequence number, it must
1001 renegotiate instead. A sequence number is incremented after each
1002 record: specifically, the first record transmitted under a
1003 particular connection state MUST use sequence number 0.
1005 6.2. Record layer
1010 Dierks & Rescorla Standards Track [Page 18]
1011 \f
1012 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1015 The TLS Record Layer receives uninterpreted data from higher layers
1016 in non-empty blocks of arbitrary size.
1018 6.2.1. Fragmentation
1020 The record layer fragments information blocks into TLSPlaintext
1021 records carrying data in chunks of 2^14 bytes or less. Client message
1022 boundaries are not preserved in the record layer (i.e., multiple
1023 client messages of the same ContentType MAY be coalesced into a
1024 single TLSPlaintext record, or a single message MAY be fragmented
1025 across several records).
1027 struct {
1028 uint8 major;
1029 uint8 minor;
1030 } ProtocolVersion;
1032 enum {
1033 change_cipher_spec(20), alert(21), handshake(22),
1034 application_data(23), (255)
1035 } ContentType;
1037 struct {
1038 ContentType type;
1039 ProtocolVersion version;
1040 uint16 length;
1041 opaque fragment[TLSPlaintext.length];
1042 } TLSPlaintext;
1044 type
1045 The higher-level protocol used to process the enclosed fragment.
1047 version
1048 The version of the protocol being employed. This document
1049 describes TLS Version 1.2, which uses the version { 3, 3 }. The
1050 version value 3.3 is historical, deriving from the use of {3, 1}
1051 for TLS 1.0. (See Appendix A.1). Note that a client that supports
1052 multiple versions of TLS may not know what version will be
1053 employed before it receives the ServerHello. See Appendix E for
1054 discussion about what record layer version number should be
1055 employed for ClientHello.
1057 length
1058 The length (in bytes) of the following TLSPlaintext.fragment. The
1059 length MUST NOT exceed 2^14.
1061 fragment
1062 The application data. This data is transparent and treated as an
1066 Dierks & Rescorla Standards Track [Page 19]
1067 \f
1068 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1071 independent block to be dealt with by the higher-level protocol
1072 specified by the type field.
1074 Implementations MUST NOT send zero-length fragments of Handshake,
1075 Alert, or ChangeCipherSpec content types. Zero-length fragments of
1076 Application data MAY be sent as they are potentially useful as a
1077 traffic analysis countermeasure.
1079 Note: Data of different TLS Record layer content types MAY be
1080 interleaved. Application data is generally of lower precedence for
1081 transmission than other content types. However, records MUST be
1082 delivered to the network in the same order as they are protected by
1083 the record layer. Recipients MUST receive and process interleaved
1084 application layer traffic during handshakes subsequent to the first
1085 one on a connection.
1087 6.2.2. Record Compression and Decompression
1089 All records are compressed using the compression algorithm defined in
1090 the current session state. There is always an active compression
1091 algorithm; however, initially it is defined as
1092 CompressionMethod.null. The compression algorithm translates a
1093 TLSPlaintext structure into a TLSCompressed structure. Compression
1094 functions are initialized with default state information whenever a
1095 connection state is made active. [RFC3749] describes compression
1096 algorithms for TLS.
1098 Compression must be lossless and may not increase the content length
1099 by more than 1024 bytes. If the decompression function encounters a
1100 TLSCompressed.fragment that would decompress to a length in excess of
1101 2^14 bytes, it MUST report a fatal decompression failure error.
1103 struct {
1104 ContentType type; /* same as TLSPlaintext.type */
1105 ProtocolVersion version;/* same as TLSPlaintext.version */
1106 uint16 length;
1107 opaque fragment[TLSCompressed.length];
1108 } TLSCompressed;
1110 length
1111 The length (in bytes) of the following TLSCompressed.fragment.
1112 The length MUST NOT exceed 2^14 + 1024.
1114 fragment
1115 The compressed form of TLSPlaintext.fragment.
1117 Note: A CompressionMethod.null operation is an identity operation; no
1118 fields are altered.
1122 Dierks & Rescorla Standards Track [Page 20]
1123 \f
1124 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1127 Implementation note: Decompression functions are responsible for
1128 ensuring that messages cannot cause internal buffer overflows.
1130 6.2.3. Record Payload Protection
1132 The encryption and MAC functions translate a TLSCompressed structure
1133 into a TLSCiphertext. The decryption functions reverse the process.
1134 The MAC of the record also includes a sequence number so that
1135 missing, extra, or repeated messages are detectable.
1137 struct {
1138 ContentType type;
1139 ProtocolVersion version;
1140 uint16 length;
1141 select (SecurityParameters.cipher_type) {
1142 case stream: GenericStreamCipher;
1143 case block: GenericBlockCipher;
1144 case aead: GenericAEADCipher;
1145 } fragment;
1146 } TLSCiphertext;
1148 type
1149 The type field is identical to TLSCompressed.type.
1151 version
1152 The version field is identical to TLSCompressed.version.
1154 length
1155 The length (in bytes) of the following TLSCiphertext.fragment.
1156 The length MUST NOT exceed 2^14 + 2048.
1158 fragment
1159 The encrypted form of TLSCompressed.fragment, with the MAC.
1161 6.2.3.1. Null or Standard Stream Cipher
1163 Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
1164 convert TLSCompressed.fragment structures to and from stream
1165 TLSCiphertext.fragment structures.
1167 stream-ciphered struct {
1168 opaque content[TLSCompressed.length];
1169 opaque MAC[SecurityParameters.mac_length];
1170 } GenericStreamCipher;
1172 The MAC is generated as:
1174 MAC(MAC_write_key, seq_num +
1178 Dierks & Rescorla Standards Track [Page 21]
1179 \f
1180 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1183 TLSCompressed.type +
1184 TLSCompressed.version +
1185 TLSCompressed.length +
1186 TLSCompressed.fragment);
1188 where "+" denotes concatenation.
1190 seq_num
1191 The sequence number for this record.
1193 MAC
1194 The MAC algorithm specified by SecurityParameters.mac_algorithm.
1196 Note that the MAC is computed before encryption. The stream cipher
1197 encrypts the entire block, including the MAC. For stream ciphers that
1198 do not use a synchronization vector (such as RC4), the stream cipher
1199 state from the end of one record is simply used on the subsequent
1200 packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, encryption
1201 consists of the identity operation (i.e., the data is not encrypted,
1202 and the MAC size is zero, implying that no MAC is used). For both
1203 null and stream ciphers, TLSCiphertext.length is TLSCompressed.length
1204 plus SecurityParameters.mac_length.
1206 6.2.3.2. CBC Block Cipher
1208 For block ciphers (such as 3DES, or AES), the encryption and MAC
1209 functions convert TLSCompressed.fragment structures to and from block
1210 TLSCiphertext.fragment structures.
1212 struct {
1213 opaque IV[SecurityParameters.record_iv_length];
1214 block-ciphered struct {
1215 opaque content[TLSCompressed.length];
1216 opaque MAC[SecurityParameters.mac_length];
1217 uint8 padding[GenericBlockCipher.padding_length];
1218 uint8 padding_length;
1219 };
1220 } GenericBlockCipher;
1222 The MAC is generated as described in Section 6.2.3.1.
1224 IV
1225 The Initialization Vector (IV) SHOULD be chosen at random, and
1226 MUST be unpredictable. Note that in versions of TLS prior to 1.1,
1227 there was no IV field, and the last ciphertext block of the
1228 previous record (the "CBC residue") was used as the IV. This was
1229 changed to prevent the attacks described in [CBCATT]. For block
1230 ciphers, the IV length is of length
1234 Dierks & Rescorla Standards Track [Page 22]
1235 \f
1236 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1239 SecurityParameters.record_iv_length which is equal to the
1240 SecurityParameters.block_size.
1242 padding
1243 Padding that is added to force the length of the plaintext to be
1244 an integral multiple of the block cipher's block length. The
1245 padding MAY be any length up to 255 bytes, as long as it results
1246 in the TLSCiphertext.length being an integral multiple of the
1247 block length. Lengths longer than necessary might be desirable to
1248 frustrate attacks on a protocol that are based on analysis of the
1249 lengths of exchanged messages. Each uint8 in the padding data
1250 vector MUST be filled with the padding length value. The receiver
1251 MUST check this padding and MUST use the bad_record_mac alert to
1252 indicate padding errors.
1254 padding_length
1255 The padding length MUST be such that the total size of the
1256 GenericBlockCipher structure is a multiple of the cipher's block
1257 length. Legal values range from zero to 255, inclusive. This
1258 length specifies the length of the padding field exclusive of the
1259 padding_length field itself.
1261 The encrypted data length (TLSCiphertext.length) is one more than the
1262 sum of SecurityParameters.block_length, TLSCompressed.length,
1263 SecurityParameters.mac_length, and padding_length.
1265 Example: If the block length is 8 bytes, the content length
1266 (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,
1267 then the length before padding is 82 bytes (this does not include the
1268 IV. Thus, the padding length modulo 8 must be equal to 6 in order to
1269 make the total length an even multiple of 8 bytes (the block length).
1270 The padding length can be 6, 14, 22, and so on, through 254. If the
1271 padding length were the minimum necessary, 6, the padding would be 6
1272 bytes, each containing the value 6. Thus, the last 8 octets of the
1273 GenericBlockCipher before block encryption would be xx 06 06 06 06 06
1274 06 06, where xx is the last octet of the MAC.
1276 Note: With block ciphers in CBC mode (Cipher Block Chaining), it is
1277 critical that the entire plaintext of the record be known before any
1278 ciphertext is transmitted. Otherwise, it is possible for the attacker
1279 to mount the attack described in [CBCATT].
1281 Implementation Note: Canvel et al. [CBCTIME] have demonstrated a
1282 timing attack on CBC padding based on the time required to compute
1283 the MAC. In order to defend against this attack, implementations MUST
1284 ensure that record processing time is essentially the same whether or
1285 not the padding is correct. In general, the best way to do this is
1286 to compute the MAC even if the padding is incorrect, and only then
1290 Dierks & Rescorla Standards Track [Page 23]
1291 \f
1292 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1295 reject the packet. For instance, if the pad appears to be incorrect,
1296 the implementation might assume a zero-length pad and then compute
1297 the MAC. This leaves a small timing channel, since MAC performance
1298 depends to some extent on the size of the data fragment, but it is
1299 not believed to be large enough to be exploitable, due to the large
1300 block size of existing MACs and the small size of the timing signal.
1302 6.2.3.3. AEAD ciphers
1304 For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
1305 converts TLSCompressed.fragment structures to and from AEAD
1306 TLSCiphertext.fragment structures.
1308 struct {
1309 opaque nonce_explicit[SecurityParameters.record_iv_length];
1310 aead-ciphered struct {
1311 opaque content[TLSCompressed.length];
1312 };
1313 } GenericAEADCipher;
1315 AEAD ciphers take as input a single key, a nonce, a plaintext, and
1316 "additional data" to be included in the authentication check, as
1317 described in Section 2.1 of [AEAD]. The key is either the
1318 client_write_key or the server_write_key. No MAC key is used.
1320 Each AEAD cipher suite MUST specify how the nonce supplied to the
1321 AEAD operation is constructed, and what is the length of the
1322 GenericAEADCipher.nonce_explicit part. In many cases, it is
1323 appropriate to use the partially implicit nonce technique described
1324 in Section 3.2.1 of [AEAD]; with record_iv_length being the length of
1325 the explicit part. In this case, the implicit part SHOULD be derived
1326 from key_block as client_write_iv and server_write_iv (as described
1327 in Section 6.3), and the explicit part is included in
1328 GenericAEAEDCipher.nonce_explicit.
1330 The plaintext is the TLSCompressed.fragment.
1332 The additional authenticated data, which we denote as
1333 additional_data, is defined as follows:
1335 additional_data = seq_num + TLSCompressed.type +
1336 TLSCompressed.version + TLSCompressed.length;
1338 Where "+" denotes concatenation.
1340 The aead_output consists of the ciphertext output by the AEAD
1341 encryption operation. The length will generally be larger than
1342 TLSCompressed.length, but by an amount that varies with the AEAD
1346 Dierks & Rescorla Standards Track [Page 24]
1347 \f
1348 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1351 cipher. Since the ciphers might incorporate padding, the amount of
1352 overhead could vary with different TLSCompressed.length values. Each
1353 AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
1354 Symbolically,
1356 AEADEncrypted = AEAD-Encrypt(key, nonce, plaintext,
1357 additional_data)
1359 In order to decrypt and verify, the cipher takes as input the key,
1360 nonce, the "additional_data", and the AEADEncrypted value. The output
1361 is either the plaintext or an error indicating that the decryption
1362 failed. There is no separate integrity check. I.e.,
1364 TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
1365 AEADEncrypted,
1366 additional_data)
1369 If the decryption fails, a fatal bad_record_mac alert MUST be
1370 generated.
1372 6.3. Key Calculation
1374 The Record Protocol requires an algorithm to generate keys required
1375 by the current connection state (see Appendix A.6) from the security
1376 parameters provided by the handshake protocol.
1378 The master secret is expanded into a sequence of secure bytes, which
1379 is then split to a client write MAC key, a server write MAC key, a
1380 client write encryption key, and a server write encryption key. Each
1381 of these is generated from the byte sequence in that order. Unused
1382 values are empty. Some AEAD ciphers may additionally require a
1383 client write IV and a server write IV (see Section 6.2.3.3).
1385 When keys and MAC keys are generated, the master secret is used as an
1386 entropy source.
1388 To generate the key material, compute
1390 key_block = PRF(SecurityParameters.master_secret,
1391 "key expansion",
1392 SecurityParameters.server_random +
1393 SecurityParameters.client_random);
1395 until enough output has been generated. Then the key_block is
1396 partitioned as follows:
1398 client_write_MAC_key[SecurityParameters.mac_key_length]
1402 Dierks & Rescorla Standards Track [Page 25]
1403 \f
1404 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1407 server_write_MAC_key[SecurityParameters.mac_key_length]
1408 client_write_key[SecurityParameters.enc_key_length]
1409 server_write_key[SecurityParameters.enc_key_length]
1410 client_write_IV[SecurityParameters.fixed_iv_length]
1411 server_write_IV[SecurityParameters.fixed_iv_length]
1413 Currently, the client_write_IV and server_write_IV are only generated
1414 for implicit nonce techniques as described in Section 3.2.1 of
1415 [AEAD].
1417 Implementation note: The currently defined cipher suite which
1418 requires the most material is AES_256_CBC_SHA256. It requires 2 x 32
1419 byte keys and 2 x 32 byte MAC keys, for a total 128 bytes of key
1420 material.
1422 7. The TLS Handshaking Protocols
1424 TLS has three subprotocols that are used to allow peers to agree upon
1425 security parameters for the record layer, to authenticate themselves,
1426 to instantiate negotiated security parameters, and to report error
1427 conditions to each other.
1429 The Handshake Protocol is responsible for negotiating a session,
1430 which consists of the following items:
1432 session identifier
1433 An arbitrary byte sequence chosen by the server to identify an
1434 active or resumable session state.
1436 peer certificate
1437 X509v3 [PKIX] certificate of the peer. This element of the state
1438 may be null.
1440 compression method
1441 The algorithm used to compress data prior to encryption.
1443 cipher spec
1444 Specifies the pseudorandom function (PRF) used to generate keying
1445 material, the bulk data encryption algorithm (such as null, AES,
1446 etc.) and a MAC algorithm (such as HMAC-SHA1). It also defines
1447 cryptographic attributes such as the mac_length. (See Appendix A.6
1448 for formal definition.)
1450 master secret
1451 48-byte secret shared between the client and server.
1453 is resumable
1454 A flag indicating whether the session can be used to initiate new
1458 Dierks & Rescorla Standards Track [Page 26]
1459 \f
1460 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1463 connections.
1465 These items are then used to create security parameters for use by
1466 the Record Layer when protecting application data. Many connections
1467 can be instantiated using the same session through the resumption
1468 feature of the TLS Handshake Protocol.
1470 7.1. Change Cipher Spec Protocol
1472 The change cipher spec protocol exists to signal transitions in
1473 ciphering strategies. The protocol consists of a single message,
1474 which is encrypted and compressed under the current (not the pending)
1475 connection state. The message consists of a single byte of value 1.
1477 struct {
1478 enum { change_cipher_spec(1), (255) } type;
1479 } ChangeCipherSpec;
1481 The ChangeCipherSpec message is sent by both the client and the
1482 server to notify the receiving party that subsequent records will be
1483 protected under the newly negotiated CipherSpec and keys. Reception
1484 of this message causes the receiver to instruct the Record Layer to
1485 immediately copy the read pending state into the read current state.
1486 Immediately after sending this message, the sender MUST instruct the
1487 record layer to make the write pending state the write active state.
1488 (See Section 6.1.) The change cipher spec message is sent during the
1489 handshake after the security parameters have been agreed upon, but
1490 before the verifying finished message is sent.
1492 Note: If a rehandshake occurs while data is flowing on a connection,
1493 the communicating parties may continue to send data using the old
1494 CipherSpec. However, once the ChangeCipherSpec has been sent, the new
1495 CipherSpec MUST be used. The first side to send the ChangeCipherSpec
1496 does not know that the other side has finished computing the new
1497 keying material (e.g., if it has to perform a time consuming public
1498 key operation). Thus, a small window of time, during which the
1499 recipient must buffer the data, MAY exist. In practice, with modern
1500 machines this interval is likely to be fairly short.
1502 7.2. Alert Protocol
1504 One of the content types supported by the TLS Record layer is the
1505 alert type. Alert messages convey the severity of the message
1506 (warning or fatal) and a description of the alert. Alert messages
1507 with a level of fatal result in the immediate termination of the
1508 connection. In this case, other connections corresponding to the
1509 session may continue, but the session identifier MUST be invalidated,
1510 preventing the failed session from being used to establish new
1514 Dierks & Rescorla Standards Track [Page 27]
1515 \f
1516 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1519 connections. Like other messages, alert messages are encrypted and
1520 compressed, as specified by the current connection state.
1522 enum { warning(1), fatal(2), (255) } AlertLevel;
1524 enum {
1525 close_notify(0),
1526 unexpected_message(10),
1527 bad_record_mac(20),
1528 decryption_failed_RESERVED(21),
1529 record_overflow(22),
1530 decompression_failure(30),
1531 handshake_failure(40),
1532 no_certificate_RESERVED(41),
1533 bad_certificate(42),
1534 unsupported_certificate(43),
1535 certificate_revoked(44),
1536 certificate_expired(45),
1537 certificate_unknown(46),
1538 illegal_parameter(47),
1539 unknown_ca(48),
1540 access_denied(49),
1541 decode_error(50),
1542 decrypt_error(51),
1543 export_restriction_RESERVED(60),
1544 protocol_version(70),
1545 insufficient_security(71),
1546 internal_error(80),
1547 user_canceled(90),
1548 no_renegotiation(100),
1549 unsupported_extension(110),
1550 (255)
1551 } AlertDescription;
1553 struct {
1554 AlertLevel level;
1555 AlertDescription description;
1556 } Alert;
1558 7.2.1. Closure Alerts
1560 The client and the server must share knowledge that the connection is
1561 ending in order to avoid a truncation attack. Either party may
1562 initiate the exchange of closing messages.
1564 close_notify
1565 This message notifies the recipient that the sender will not send
1566 any more messages on this connection. Note that as of TLS 1.1,
1570 Dierks & Rescorla Standards Track [Page 28]
1571 \f
1572 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1575 failure to properly close a connection no longer requires that a
1576 session not be resumed. This is a change from TLS 1.0 to conform
1577 with widespread implementation practice.
1579 Either party may initiate a close by sending a close_notify alert.
1580 Any data received after a closure alert is ignored.
1582 Unless some other fatal alert has been transmitted, each party is
1583 required to send a close_notify alert before closing the write side
1584 of the connection. The other party MUST respond with a close_notify
1585 alert of its own and close down the connection immediately,
1586 discarding any pending writes. It is not required for the initiator
1587 of the close to wait for the responding close_notify alert before
1588 closing the read side of the connection.
1590 If the application protocol using TLS provides that any data may be
1591 carried over the underlying transport after the TLS connection is
1592 closed, the TLS implementation must receive the responding
1593 close_notify alert before indicating to the application layer that
1594 the TLS connection has ended. If the application protocol will not
1595 transfer any additional data, but will only close the underlying
1596 transport connection, then the implementation MAY choose to close the
1597 transport without waiting for the responding close_notify. No part of
1598 this standard should be taken to dictate the manner in which a usage
1599 profile for TLS manages its data transport, including when
1600 connections are opened or closed.
1602 Note: It is assumed that closing a connection reliably delivers
1603 pending data before destroying the transport.
1605 7.2.2. Error Alerts
1607 Error handling in the TLS Handshake protocol is very simple. When an
1608 error is detected, the detecting party sends a message to the other
1609 party. Upon transmission or receipt of a fatal alert message, both
1610 parties immediately close the connection. Servers and clients MUST
1611 forget any session-identifiers, keys, and secrets associated with a
1612 failed connection. Thus, any connection terminated with a fatal alert
1613 MUST NOT be resumed.
1615 Whenever an implementation encounters a condition which is defined as
1616 a fatal alert, it MUST send the appropriate alert prior to closing
1617 the connection. For all errors where an alert level is not explicitly
1618 specified, the sending party MAY determine at its discretion whether
1619 to treat this as a fatal error or not. If the implementation chooses
1620 to send an alert but intends to close the connection immediately
1621 afterwards, it MUST send that alert at the fatal alert level.
1626 Dierks & Rescorla Standards Track [Page 29]
1627 \f
1628 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1631 If an alert with a level of warning is sent and received, generally
1632 the connection can continue normally. If the receiving party decides
1633 not to proceed with the connection (e.g., after having received a
1634 no_renegotiation alert that it is not willing to accept), it SHOULD
1635 send a fatal alert to terminate the connection. Given this, the
1636 sending party cannot, in general, know how the receiving party will
1637 behave. Therefore, warning alerts are not very useful when the
1638 sending party wants to continue the connection, and thus are
1639 sometimes omitted. For example, if a peer decides to accept an
1640 expired certificate (perhaps after confirming this with the user) and
1641 wants to continue the connection, it would not generally send a
1642 certificate_expired alert.
1644 The following error alerts are defined:
1646 unexpected_message
1647 An inappropriate message was received. This alert is always fatal
1648 and should never be observed in communication between proper
1649 implementations.
1651 bad_record_mac
1652 This alert is returned if a record is received with an incorrect
1653 MAC. This alert also MUST be returned if an alert is sent because
1654 a TLSCiphertext decrypted in an invalid way: either it wasn't an
1655 even multiple of the block length, or its padding values, when
1656 checked, weren't correct. This message is always fatal and should
1657 never be observed in communication between proper implementations
1658 (except when messages were corrupted in the network).
1660 decryption_failed_RESERVED
1661 This alert was used in some earlier versions of TLS, and may have
1662 permitted certain attacks against the CBC mode [CBCATT]. It MUST
1663 NOT be sent by compliant implementations.
1665 record_overflow
1666 A TLSCiphertext record was received that had a length more than
1667 2^14+2048 bytes, or a record decrypted to a TLSCompressed record
1668 with more than 2^14+1024 bytes. This message is always fatal and
1669 should never be observed in communication between proper
1670 implementations (except when messages were corrupted in the
1671 network).
1673 decompression_failure
1674 The decompression function received improper input (e.g., data
1675 that would expand to excessive length). This message is always
1676 fatal and should never be observed in communication between proper
1677 implementations.
1682 Dierks & Rescorla Standards Track [Page 30]
1683 \f
1684 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1687 handshake_failure
1688 Reception of a handshake_failure alert message indicates that the
1689 sender was unable to negotiate an acceptable set of security
1690 parameters given the options available. This is a fatal error.
1692 no_certificate_RESERVED
1693 This alert was used in SSLv3 but not any version of TLS. It MUST
1694 NOT be sent by compliant implementations.
1696 bad_certificate
1697 A certificate was corrupt, contained signatures that did not
1698 verify correctly, etc.
1700 unsupported_certificate
1701 A certificate was of an unsupported type.
1703 certificate_revoked
1704 A certificate was revoked by its signer.
1706 certificate_expired
1707 A certificate has expired or is not currently valid.
1709 certificate_unknown
1710 Some other (unspecified) issue arose in processing the
1711 certificate, rendering it unacceptable.
1713 illegal_parameter
1714 A field in the handshake was out of range or inconsistent with
1715 other fields. This message is always fatal.
1717 unknown_ca
1718 A valid certificate chain or partial chain was received, but the
1719 certificate was not accepted because the CA certificate could not
1720 be located or couldn't be matched with a known, trusted CA. This
1721 message is always fatal.
1723 access_denied
1724 A valid certificate was received, but when access control was
1725 applied, the sender decided not to proceed with negotiation. This
1726 message is always fatal.
1728 decode_error
1729 A message could not be decoded because some field was out of the
1730 specified range or the length of the message was incorrect. This
1731 message is always fatal and should never be observed in
1732 communication between proper implementations (except when messages
1733 were corrupted in the network).
1738 Dierks & Rescorla Standards Track [Page 31]
1739 \f
1740 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1743 decrypt_error
1744 A handshake cryptographic operation failed, including being unable
1745 to correctly verify a signature or validate a finished message.
1746 This message is always fatal.
1748 export_restriction_RESERVED
1749 This alert was used in some earlier versions of TLS. It MUST NOT
1750 be sent by compliant implementations.
1752 protocol_version
1753 The protocol version the client has attempted to negotiate is
1754 recognized but not supported. (For example, old protocol versions
1755 might be avoided for security reasons). This message is always
1756 fatal.
1758 insufficient_security
1759 Returned instead of handshake_failure when a negotiation has
1760 failed specifically because the server requires ciphers more
1761 secure than those supported by the client. This message is always
1762 fatal.
1764 internal_error
1765 An internal error unrelated to the peer or the correctness of the
1766 protocol (such as a memory allocation failure) makes it impossible
1767 to continue. This message is always fatal.
1769 user_canceled
1770 This handshake is being canceled for some reason unrelated to a
1771 protocol failure. If the user cancels an operation after the
1772 handshake is complete, just closing the connection by sending a
1773 close_notify is more appropriate. This alert should be followed by
1774 a close_notify. This message is generally a warning.
1776 no_renegotiation
1777 Sent by the client in response to a hello request or by the server
1778 in response to a client hello after initial handshaking. Either
1779 of these would normally lead to renegotiation; when that is not
1780 appropriate, the recipient should respond with this alert. At
1781 that point, the original requester can decide whether to proceed
1782 with the connection. One case where this would be appropriate is
1783 where a server has spawned a process to satisfy a request; the
1784 process might receive security parameters (key length,
1785 authentication, etc.) at startup and it might be difficult to
1786 communicate changes to these parameters after that point. This
1787 message is always a warning.
1789 unsupported_extension
1790 sent by clients that receive an extended server hello containing
1794 Dierks & Rescorla Standards Track [Page 32]
1795 \f
1796 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1799 an extension that they did not put in the corresponding client
1800 hello. This message is always fatal.
1802 New Alert values are assigned by IANA as described in Section 12.
1804 7.3. Handshake Protocol Overview
1806 The cryptographic parameters of the session state are produced by the
1807 TLS Handshake Protocol, which operates on top of the TLS Record
1808 Layer. When a TLS client and server first start communicating, they
1809 agree on a protocol version, select cryptographic algorithms,
1810 optionally authenticate each other, and use public-key encryption
1811 techniques to generate shared secrets.
1813 The TLS Handshake Protocol involves the following steps:
1815 - Exchange hello messages to agree on algorithms, exchange random
1816 values, and check for session resumption.
1818 - Exchange the necessary cryptographic parameters to allow the
1819 client and server to agree on a premaster secret.
1821 - Exchange certificates and cryptographic information to allow the
1822 client and server to authenticate themselves.
1824 - Generate a master secret from the premaster secret and exchanged
1825 random values.
1827 - Provide security parameters to the record layer.
1829 - Allow the client and server to verify that their peer has
1830 calculated the same security parameters and that the handshake
1831 occurred without tampering by an attacker.
1833 Note that higher layers should not be overly reliant on whether TLS
1834 always negotiates the strongest possible connection between two
1835 peers. There are a number of ways in which a man in the middle
1836 attacker can attempt to make two entities drop down to the least
1837 secure method they support. The protocol has been designed to
1838 minimize this risk, but there are still attacks available: for
1839 example, an attacker could block access to the port a secure service
1840 runs on, or attempt to get the peers to negotiate an unauthenticated
1841 connection. The fundamental rule is that higher levels must be
1842 cognizant of what their security requirements are and never transmit
1843 information over a channel less secure than what they require. The
1844 TLS protocol is secure in that any cipher suite offers its promised
1845 level of security: if you negotiate 3DES with a 1024 bit RSA key
1846 exchange with a host whose certificate you have verified, you can
1850 Dierks & Rescorla Standards Track [Page 33]
1851 \f
1852 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1855 expect to be that secure.
1857 These goals are achieved by the handshake protocol, which can be
1858 summarized as follows: The client sends a client hello message to
1859 which the server must respond with a server hello message, or else a
1860 fatal error will occur and the connection will fail. The client hello
1861 and server hello are used to establish security enhancement
1862 capabilities between client and server. The client hello and server
1863 hello establish the following attributes: Protocol Version, Session
1864 ID, Cipher Suite, and Compression Method. Additionally, two random
1865 values are generated and exchanged: ClientHello.random and
1866 ServerHello.random.
1868 The actual key exchange uses up to four messages: the server
1869 Certificate, the ServerKeyExchange, the client Certificate, and the
1870 ClientKeyExchange. New key exchange methods can be created by
1871 specifying a format for these messages and by defining the use of the
1872 messages to allow the client and server to agree upon a shared
1873 secret. This secret MUST be quite long; currently defined key
1874 exchange methods exchange secrets that range from 46 bytes upwards.
1876 Following the hello messages, the server will send its certificate in
1877 a Certificate message if it is to be authenticated. Additionally, a
1878 ServerKeyExchange message may be sent, if it is required (e.g., if
1879 the server has no certificate, or if its certificate is for signing
1880 only). If the server is authenticated, it may request a certificate
1881 from the client, if that is appropriate to the cipher suite selected.
1882 Next, the server will send the ServerHelloDone message, indicating
1883 that the hello-message phase of the handshake is complete. The server
1884 will then wait for a client response. If the server has sent a
1885 CertificateRequest message, the client MUST send the Certificate
1886 message. The ClientKeyExchange message is now sent, and the content
1887 of that message will depend on the public key algorithm selected
1888 between the client hello and the server hello. If the client has sent
1889 a certificate with signing ability, a digitally-signed
1890 CertificateVerify message is sent to explicitly verify possession of
1891 the private key in the certificate.
1893 At this point, a ChangeCipherSpec message is sent by the client, and
1894 the client copies the pending Cipher Spec into the current Cipher
1895 Spec. The client then immediately sends the Finished message under
1896 the new algorithms, keys, and secrets. In response, the server will
1897 send its own ChangeCipherSpec message, transfer the pending to the
1898 current Cipher Spec, and send its Finished message under the new
1899 Cipher Spec. At this point, the handshake is complete, and the client
1900 and server may begin to exchange application layer data. (See flow
1901 chart below.) Application data MUST NOT be sent prior to the
1902 completion of the first handshake (before a cipher suite other than
1906 Dierks & Rescorla Standards Track [Page 34]
1907 \f
1908 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1911 TLS_NULL_WITH_NULL_NULL is established).
1962 Dierks & Rescorla Standards Track [Page 35]
1963 \f
1964 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
1967 Client Server
1969 ClientHello -------->
1970 ServerHello
1971 Certificate*
1972 ServerKeyExchange*
1973 CertificateRequest*
1974 <-------- ServerHelloDone
1975 Certificate*
1976 ClientKeyExchange
1977 CertificateVerify*
1978 [ChangeCipherSpec]
1979 Finished -------->
1980 [ChangeCipherSpec]
1981 <-------- Finished
1982 Application Data <-------> Application Data
1984 Fig. 1. Message flow for a full handshake
1986 * Indicates optional or situation-dependent messages that are not
1987 always sent.
1989 Note: To help avoid pipeline stalls, ChangeCipherSpec is an
1990 independent TLS Protocol content type, and is not actually a TLS
1991 handshake message.
1993 When the client and server decide to resume a previous session or
1994 duplicate an existing session (instead of negotiating new security
1995 parameters), the message flow is as follows:
1997 The client sends a ClientHello using the Session ID of the session to
1998 be resumed. The server then checks its session cache for a match. If
1999 a match is found, and the server is willing to re-establish the
2000 connection under the specified session state, it will send a
2001 ServerHello with the same Session ID value. At this point, both
2002 client and server MUST send ChangeCipherSpec messages and proceed
2003 directly to Finished messages. Once the re-establishment is complete,
2004 the client and server MAY begin to exchange application layer data.
2005 (See flow chart below.) If a Session ID match is not found, the
2006 server generates a new session ID and the TLS client and server
2007 perform a full handshake.
2018 Dierks & Rescorla Standards Track [Page 36]
2019 \f
2020 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2023 Client Server
2025 ClientHello -------->
2026 ServerHello
2027 [ChangeCipherSpec]
2028 <-------- Finished
2029 [ChangeCipherSpec]
2030 Finished -------->
2031 Application Data <-------> Application Data
2033 Fig. 2. Message flow for an abbreviated handshake
2035 The contents and significance of each message will be presented in
2036 detail in the following sections.
2038 7.4. Handshake Protocol
2040 The TLS Handshake Protocol is one of the defined higher-level clients
2041 of the TLS Record Protocol. This protocol is used to negotiate the
2042 secure attributes of a session. Handshake messages are supplied to
2043 the TLS Record Layer, where they are encapsulated within one or more
2044 TLSPlaintext structures, which are processed and transmitted as
2045 specified by the current active session state.
2047 enum {
2048 hello_request(0), client_hello(1), server_hello(2),
2049 certificate(11), server_key_exchange (12),
2050 certificate_request(13), server_hello_done(14),
2051 certificate_verify(15), client_key_exchange(16),
2052 finished(20), (255)
2053 } HandshakeType;
2055 struct {
2056 HandshakeType msg_type; /* handshake type */
2057 uint24 length; /* bytes in message */
2058 select (HandshakeType) {
2059 case hello_request: HelloRequest;
2060 case client_hello: ClientHello;
2061 case server_hello: ServerHello;
2062 case certificate: Certificate;
2063 case server_key_exchange: ServerKeyExchange;
2064 case certificate_request: CertificateRequest;
2065 case server_hello_done: ServerHelloDone;
2066 case certificate_verify: CertificateVerify;
2067 case client_key_exchange: ClientKeyExchange;
2068 case finished: Finished;
2069 } body;
2070 } Handshake;
2074 Dierks & Rescorla Standards Track [Page 37]
2075 \f
2076 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2079 The handshake protocol messages are presented below in the order they
2080 MUST be sent; sending handshake messages in an unexpected order
2081 results in a fatal error. Unneeded handshake messages can be omitted,
2082 however. Note one exception to the ordering: the Certificate message
2083 is used twice in the handshake (from server to client, then from
2084 client to server), but described only in its first position. The one
2085 message that is not bound by these ordering rules is the HelloRequest
2086 message, which can be sent at any time, but which SHOULD be ignored
2087 by the client if it arrives in the middle of a handshake.
2089 New Handshake message types are assigned by IANA as described in
2090 Section 12.
2092 7.4.1. Hello Messages
2094 The hello phase messages are used to exchange security enhancement
2095 capabilities between the client and server. When a new session
2096 begins, the Record Layer's connection state encryption, hash, and
2097 compression algorithms are initialized to null. The current
2098 connection state is used for renegotiation messages.
2100 7.4.1.1. Hello Request
2102 When this message will be sent:
2104 The HelloRequest message MAY be sent by the server at any time.
2106 Meaning of this message:
2108 HelloRequest is a simple notification that the client should begin
2109 the negotiation process anew. In response, the client should a
2110 ClientHello message when convenient. This message is not intended
2111 to establish which side is the client or server but merely to
2112 initiate a new negotiation. Servers SHOULD NOT send a HelloRequest
2113 immediately upon the client's initial connection. It is the
2114 client's job to send a ClientHello at that time.
2116 This message will be ignored by the client if the client is
2117 currently negotiating a session. This message MAY be ignored by
2118 the client if it does not wish to renegotiate a session, or the
2119 client may, if it wishes, respond with a no_renegotiation alert.
2120 Since handshake messages are intended to have transmission
2121 precedence over application data, it is expected that the
2122 negotiation will begin before no more than a few records are
2123 received from the client. If the server sends a HelloRequest but
2124 does not receive a ClientHello in response, it may close the
2125 connection with a fatal alert.
2130 Dierks & Rescorla Standards Track [Page 38]
2131 \f
2132 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2135 After sending a HelloRequest, servers SHOULD NOT repeat the
2136 request until the subsequent handshake negotiation is complete.
2138 Structure of this message:
2140 struct { } HelloRequest;
2142 This message MUST NOT be included in the message hashes that are
2143 maintained throughout the handshake and used in the finished messages
2144 and the certificate verify message.
2146 7.4.1.2. Client Hello
2148 When this message will be sent:
2150 When a client first connects to a server it is required to send
2151 the ClientHello as its first message. The client can also send a
2152 ClientHello in response to a HelloRequest or on its own initiative
2153 in order to renegotiate the security parameters in an existing
2154 connection.
2156 Structure of this message:
2158 The ClientHello message includes a random structure, which is used
2159 later in the protocol.
2161 struct {
2162 uint32 gmt_unix_time;
2163 opaque random_bytes[28];
2164 } Random;
2166 gmt_unix_time
2167 The current time and date in standard UNIX 32-bit format
2168 (seconds since the midnight starting Jan 1, 1970, UTC, ignoring
2169 leap seconds) according to the sender's internal clock. Clocks
2170 are not required to be set correctly by the basic TLS Protocol;
2171 higher-level or application protocols may define additional
2172 requirements. Note that, for historical reasons, the data
2173 element is named using GMT, the predecessor of the current
2174 worldwide time base, UTC.
2176 random_bytes
2177 28 bytes generated by a secure random number generator.
2179 The ClientHello message includes a variable-length session
2180 identifier. If not empty, the value identifies a session between the
2181 same client and server whose security parameters the client wishes to
2182 reuse. The session identifier MAY be from an earlier connection, this
2186 Dierks & Rescorla Standards Track [Page 39]
2187 \f
2188 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2191 connection, or from another currently active connection. The second
2192 option is useful if the client only wishes to update the random
2193 structures and derived values of a connection, and the third option
2194 makes it possible to establish several independent secure connections
2195 without repeating the full handshake protocol. These independent
2196 connections may occur sequentially or simultaneously; a SessionID
2197 becomes valid when the handshake negotiating it completes with the
2198 exchange of Finished messages and persists until it is removed due to
2199 aging or because a fatal error was encountered on a connection
2200 associated with the session. The actual contents of the SessionID are
2201 defined by the server.
2203 opaque SessionID<0..32>;
2205 Warning: Because the SessionID is transmitted without encryption or
2206 immediate MAC protection, servers MUST NOT place confidential
2207 information in session identifiers or let the contents of fake
2208 session identifiers cause any breach of security. (Note that the
2209 content of the handshake as a whole, including the SessionID, is
2210 protected by the Finished messages exchanged at the end of the
2211 handshake.)
2213 The cipher suite list, passed from the client to the server in the
2214 ClientHello message, contains the combinations of cryptographic
2215 algorithms supported by the client in order of the client's
2216 preference (favorite choice first). Each cipher suite defines a key
2217 exchange algorithm, a bulk encryption algorithm (including secret key
2218 length), a MAC algorithm, and a PRF. The server will select a cipher
2219 suite or, if no acceptable choices are presented, return a handshake
2220 failure alert and close the connection. If the list contains cipher
2221 suites the server does not recognize, support, or wish to use, the
2222 server MUST ignore those cipher suites, and process the remaining
2223 ones as usual.
2225 uint8 CipherSuite[2]; /* Cryptographic suite selector */
2227 The ClientHello includes a list of compression algorithms supported
2228 by the client, ordered according to the client's preference.
2230 enum { null(0), (255) } CompressionMethod;
2232 struct {
2233 ProtocolVersion client_version;
2234 Random random;
2235 SessionID session_id;
2236 CipherSuite cipher_suites<2..2^16-2>;
2237 CompressionMethod compression_methods<1..2^8-1>;
2238 select (extensions_present) {
2242 Dierks & Rescorla Standards Track [Page 40]
2243 \f
2244 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2247 case false:
2248 struct {};
2249 case true:
2250 Extension extensions<0..2^16-1>;
2251 };
2252 } ClientHello;
2254 TLS allows extensions to follow the compression_methods field in an
2255 extensions block. The presence of extensions can be detected by
2256 determining whether there are bytes following the compression_methods
2257 at the end of the ClientHello. Note that this method of detecting
2258 optional data differs from the normal TLS method of having a
2259 variable-length field but is used for compatibility with TLS before
2260 extensions were defined.
2262 client_version
2263 The version of the TLS protocol by which the client wishes to
2264 communicate during this session. This SHOULD be the latest
2265 (highest valued) version supported by the client. For this version
2266 of the specification, the version will be 3.3 (See Appendix E for
2267 details about backward compatibility).
2269 random
2270 A client-generated random structure.
2272 session_id
2273 The ID of a session the client wishes to use for this connection.
2274 This field is empty if no session_id is available, or if the
2275 client wishes to generate new security parameters.
2277 cipher_suites
2278 This is a list of the cryptographic options supported by the
2279 client, with the client's first preference first. If the
2280 session_id field is not empty (implying a session resumption
2281 request), this vector MUST include at least the cipher_suite from
2282 that session. Values are defined in Appendix A.5.
2284 compression_methods
2285 This is a list of the compression methods supported by the client,
2286 sorted by client preference. If the session_id field is not empty
2287 (implying a session resumption request), it MUST include the
2288 compression_method from that session. This vector MUST contain,
2289 and all implementations MUST support, CompressionMethod.null.
2290 Thus, a client and server will always be able to agree on a
2291 compression method.
2293 extensions
2294 Clients MAY request extended functionality from servers by sending
2298 Dierks & Rescorla Standards Track [Page 41]
2299 \f
2300 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2303 data in the extensions field. The actual "Extension" format is
2304 defined in Section 7.4.1.4.
2306 In the event that a client requests additional functionality using
2307 extensions, and this functionality is not supplied by the server, the
2308 client MAY abort the handshake. A server MUST accept client hello
2309 messages both with and without the extensions field, and (as for all
2310 other messages) MUST check that the amount of data in the message
2311 precisely matches one of these formats; if not, then it MUST send a
2312 fatal "decode_error" alert.
2314 After sending the client hello message, the client waits for a
2315 ServerHello message. Any other handshake message returned by the
2316 server except for a HelloRequest is treated as a fatal error.
2318 7.4.1.3. Server Hello
2320 When this message will be sent:
2322 The server will send this message in response to a ClientHello
2323 message when it was able to find an acceptable set of algorithms.
2324 If it cannot find such a match, it will respond with a handshake
2325 failure alert.
2327 Structure of this message:
2329 struct {
2330 ProtocolVersion server_version;
2331 Random random;
2332 SessionID session_id;
2333 CipherSuite cipher_suite;
2334 CompressionMethod compression_method;
2335 select (extensions_present) {
2336 case false:
2337 struct {};
2338 case true:
2339 Extension extensions<0..2^16-1>;
2340 };
2341 } ServerHello;
2343 The presence of extensions can be detected by determining whether
2344 there are bytes following the compression_method field at the end of
2345 the ServerHello.
2347 server_version
2348 This field will contain the lower of that suggested by the client
2349 in the client hello and the highest supported by the server. For
2350 this version of the specification, the version is 3.3. (See
2354 Dierks & Rescorla Standards Track [Page 42]
2355 \f
2356 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2359 Appendix E for details about backward compatibility.)
2361 random
2362 This structure is generated by the server and MUST be
2363 independently generated from the ClientHello.random.
2365 session_id
2366 This is the identity of the session corresponding to this
2367 connection. If the ClientHello.session_id was non-empty, the
2368 server will look in its session cache for a match. If a match is
2369 found and the server is willing to establish the new connection
2370 using the specified session state, the server will respond with
2371 the same value as was supplied by the client. This indicates a
2372 resumed session and dictates that the parties must proceed
2373 directly to the finished messages. Otherwise this field will
2374 contain a different value identifying the new session. The server
2375 may return an empty session_id to indicate that the session will
2376 not be cached and therefore cannot be resumed. If a session is
2377 resumed, it must be resumed using the same cipher suite it was
2378 originally negotiated with. Note that there is no requirement that
2379 the server resume any session even if it had formerly provided a
2380 session_id. Clients MUST be prepared to do a full negotiation --
2381 including negotiating new cipher suites -- during any handshake.
2383 cipher_suite
2384 The single cipher suite selected by the server from the list in
2385 ClientHello.cipher_suites. For resumed sessions, this field is the
2386 value from the state of the session being resumed.
2388 compression_method
2389 The single compression algorithm selected by the server from the
2390 list in ClientHello.compression_methods. For resumed sessions this
2391 field is the value from the resumed session state.
2393 extensions
2394 A list of extensions. Note that only extensions offered by the
2395 client can appear in the server's list.
2397 7.4.1.4 Hello Extensions
2399 The extension format is:
2401 struct {
2402 ExtensionType extension_type;
2403 opaque extension_data<0..2^16-1>;
2404 } Extension;
2406 enum {
2410 Dierks & Rescorla Standards Track [Page 43]
2411 \f
2412 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2415 signature_algorithms(TBD-BY-IANA), (65535)
2416 } ExtensionType;
2418 Here:
2420 - "extension_type" identifies the particular extension type.
2422 - "extension_data" contains information specific to the particular
2423 extension type.
2425 The initial set of extensions is defined in a companion document
2426 [TLSEXT]. The list of extension types is maintained by IANA as
2427 described in Section 12.
2429 There are subtle (and not so subtle) interactions that may occur in
2430 this protocol between new features and existing features which may
2431 result in a significant reduction in overall security. The following
2432 considerations should be taken into account when designing new
2433 extensions:
2435 - Some cases where a server does not agree to an extension are error
2436 conditions, and some simply a refusal to support a particular
2437 feature. In general error alerts should be used for the former,
2438 and a field in the server extension response for the latter.
2440 - Extensions should as far as possible be designed to prevent any
2441 attack that forces use (or non-use) of a particular feature by
2442 manipulation of handshake messages. This principle should be
2443 followed regardless of whether the feature is believed to cause a
2444 security problem.
2446 Often the fact that the extension fields are included in the
2447 inputs to the Finished message hashes will be sufficient, but
2448 extreme care is needed when the extension changes the meaning of
2449 messages sent in the handshake phase. Designers and implementors
2450 should be aware of the fact that until the handshake has been
2451 authenticated, active attackers can modify messages and insert,
2452 remove, or replace extensions.
2454 - It would be technically possible to use extensions to change major
2455 aspects of the design of TLS; for example the design of cipher
2456 suite negotiation. This is not recommended; it would be more
2457 appropriate to define a new version of TLS - particularly since
2458 the TLS handshake algorithms have specific protection against
2459 version rollback attacks based on the version number, and the
2460 possibility of version rollback should be a significant
2461 consideration in any major design change.
2466 Dierks & Rescorla Standards Track [Page 44]
2467 \f
2468 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2471 7.4.1.4.1 Signature Algorithms
2473 The client uses the "signature_algorithms" extension to indicate to
2474 the server which signature/hash algorithm pairs may be used in
2475 digital signatures. The "extension_data" field of this extension
2476 contains a "supported_signature_algorithms" value.
2478 enum {
2479 none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
2480 sha512(6), (255)
2481 } HashAlgorithm;
2483 enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
2484 SignatureAlgorithm;
2486 struct {
2487 HashAlgorithm hash;
2488 SignatureAlgorithm signature;
2489 } SignatureAndHashAlgorithm;
2491 SignatureAndHashAlgorithm
2492 supported_signature_algorithms<2..2^16-2>;
2494 Each SignatureAndHashAlgorithm value lists a single hash/signature
2495 pair which the client is willing to verify. The values are indicated
2496 in descending order of preference.
2498 Note: Because not all signature algorithms and hash algorithms may be
2499 accepted by an implementation (e.g., DSA with SHA-1, but not
2500 SHA-256), algorithms here are listed in pairs.
2502 hash
2503 This field indicates the hash algorithm which may be used. The
2504 values indicate support for unhashed data, MD5 [MD5], SHA-1,
2505 SHA-224, SHA-256, SHA-384, and SHA-512 [SHS] respectively. The
2506 "none" value is provided for future extensibility, in case of a
2507 signature algorithm which does not require hashing before signing.
2509 signature
2510 This field indicates the signature algorithm which may be used.
2511 The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
2512 [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively. The
2513 "anonymous" value is meaningless in this context but used in
2514 Section 7.4.3. It MUST NOT appear in this extension.
2516 The semantics of this extension are somewhat complicated because the
2517 cipher suite indicates permissible signature algorithms but not hash
2518 algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules.
2522 Dierks & Rescorla Standards Track [Page 45]
2523 \f
2524 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2527 If the client supports only the default hash and signature algorithms
2528 (listed in this section), it MAY omit the signature_algorithms
2529 extension. If the client does not support the default algorithms, or
2530 supports other hash and signature algorithms (and it is willing to
2531 use them for verifying messages sent by the server, i.e., server
2532 certificates and server key exchange), it MUST send the
2533 signature_algorithms extension, listing the algorithms it is willing
2534 to accept.
2536 If the client does not send the signature_algorithms extension, the
2537 server MUST assume the following:
2539 - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
2540 DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent
2541 the value {sha1,rsa}.
2543 - If the negotiated key exchange algorithm is one of (DHE_DSS,
2544 DH_DSS), behave as if the client had sent the value {sha1,dsa}.
2546 - If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
2547 ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
2549 Note: this is a change from TLS 1.1 where there are no explicit rules
2550 but as a practical matter one can assume that the peer supports MD5
2551 and SHA-1.
2553 Note: this extension is not meaningful for TLS versions prior to 1.2.
2554 Clients MUST NOT offer it if they are offering prior versions.
2555 However, even if clients do offer it, the rules specified in [TLSEXT]
2556 require servers to ignore extensions they do not understand.
2558 Servers MUST NOT send this extension. TLS servers MUST support
2559 receiving this extension.
2562 7.4.2. Server Certificate
2564 When this message will be sent:
2566 The server MUST send a Certificate message whenever the agreed-
2567 upon key exchange method uses certificates for authentication
2568 (this includes all key exchange methods defined in this document
2569 except DH_anon). This message will always immediately follow the
2570 server hello message.
2572 Meaning of this message:
2574 This message conveys the server's certificate chain to the client.
2578 Dierks & Rescorla Standards Track [Page 46]
2579 \f
2580 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2583 The certificate MUST be appropriate for the negotiated cipher
2584 suite's key exchange algorithm, and any negotiated extensions.
2586 Structure of this message:
2588 opaque ASN.1Cert<1..2^24-1>;
2590 struct {
2591 ASN.1Cert certificate_list<0..2^24-1>;
2592 } Certificate;
2594 certificate_list
2595 This is a sequence (chain) of certificates. The sender's
2596 certificate MUST come first in the list. Each following
2597 certificate MUST directly certify the one preceding it. Because
2598 certificate validation requires that root keys be distributed
2599 independently, the self-signed certificate that specifies the root
2600 certificate authority MAY be omitted from the chain, under the
2601 assumption that the remote end must already possess it in order to
2602 validate it in any case.
2604 The same message type and structure will be used for the client's
2605 response to a certificate request message. Note that a client MAY
2606 send no certificates if it does not have an appropriate certificate
2607 to send in response to the server's authentication request.
2609 Note: PKCS #7 [PKCS7] is not used as the format for the certificate
2610 vector because PKCS #6 [PKCS6] extended certificates are not used.
2611 Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
2612 of parsing the list more difficult.
2614 The following rules apply to the certificates sent by the server:
2616 - The certificate type MUST be X.509v3, unless explicitly negotiated
2617 otherwise (e.g., [TLSPGP]).
2619 - The end entity certificate's public key (and associated
2620 restrictions) MUST be compatible with the selected key exchange
2621 algorithm.
2623 Key Exchange Alg. Certificate Key Type
2625 RSA RSA public key; the certificate MUST
2626 RSA_PSK allow the key to be used for encryption
2627 (the keyEncipherment bit MUST be set
2628 if the key usage extension is present).
2629 Note: RSA_PSK is defined in [TLSPSK].
2634 Dierks & Rescorla Standards Track [Page 47]
2635 \f
2636 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2639 DHE_RSA RSA public key; the certificate MUST
2640 ECDHE_RSA allow the key to be used for signing
2641 (the digitalSignature bit MUST be set
2642 if the key usage extension is present)
2643 with the signature scheme and hash
2644 algorithm that will be employed in the
2645 server key exchange message.
2646 Note: ECDHE_RSA is defined in [TLSECC].
2648 DHE_DSS DSA public key; the certificate MUST
2649 allow the key to be used for signing with
2650 the hash algorithm that will be employed
2651 in the server key exchange message.
2653 DH_DSS Diffie-Hellman public key; the
2654 DH_RSA keyAgreement bit MUST be set if the
2655 key usage extension is present.
2657 ECDH_ECDSA ECDH-capable public key; the public key
2658 ECDH_RSA MUST use a curve and point format supported
2659 by the client, as described in [TLSECC].
2661 ECDHE_ECDSA ECDSA-capable public key; the certificate
2662 MUST allow the key to be used for signing
2663 with the hash algorithm that will be
2664 employed in the server key exchange
2665 message. The public key MUST use a curve
2666 and point format supported by the client,
2667 as described in [TLSECC].
2669 - The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are
2670 used to guide certificate selection.
2672 If the client provided a "signature_algorithms" extension, then all
2673 certificates provided by the server MUST be signed by a
2674 hash/signature algorithm pair that appears in that extension. Note
2675 that this implies that a certificate containing a key for one
2676 signature algorithm MAY be signed using a different signature
2677 algorithm (for instance, an RSA key signed with a DSA key.) This is a
2678 departure from TLS 1.1, which required that the algorithms be the
2679 same. Note that this also implies that the DH_DSS, DH_RSA,
2680 ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
2681 algorithm used to sign the certificate. Fixed DH certificates MAY be
2682 signed with any hash/signature algorithm pair appearing in the
2683 extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
2684 historical.
2686 If the server has multiple certificates, it chooses one of them based
2690 Dierks & Rescorla Standards Track [Page 48]
2691 \f
2692 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2695 on the above-mentioned criteria (in addition to other criteria, such
2696 as transport layer endpoint, local configuration and preferences,
2697 etc.). If the server has a single certificate it SHOULD attempt to
2698 validate that it meets these criteria.
2700 Note that there are certificates that use algorithms and/or algorithm
2701 combinations that cannot be currently used with TLS. For example, a
2702 certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
2703 SubjectPublicKeyInfo) cannot be used because TLS defines no
2704 corresponding signature algorithm.
2706 As cipher suites that specify new key exchange methods are specified
2707 for the TLS Protocol, they will the imply certificate format and the
2708 required encoded keying information.
2710 7.4.3. Server Key Exchange Message
2712 When this message will be sent:
2714 This message will be sent immediately after the server Certificate
2715 message (or the ServerHello message, if this is an anonymous
2716 negotiation).
2718 The ServerKeyExchange message is sent by the server only when the
2719 server Certificate message (if sent) does not contain enough data
2720 to allow the client to exchange a premaster secret. This is true
2721 for the following key exchange methods:
2723 DHE_DSS
2724 DHE_RSA
2725 DH_anon
2727 It is not legal to send the ServerKeyExchange message for the
2728 following key exchange methods:
2730 RSA
2731 DH_DSS
2732 DH_RSA
2734 Other key exchange algorithms, such as those defined in
2735 [TLSECC], MUST specify whether the ServerKeyExchange message is
2736 sent or not; and if the message is sent, its contents.
2738 Meaning of this message:
2740 This message conveys cryptographic information to allow the client
2741 to communicate the premaster secret: a Diffie-Hellman public key
2742 with which the client can complete a key exchange (with the result
2746 Dierks & Rescorla Standards Track [Page 49]
2747 \f
2748 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2751 being the premaster secret) or a public key for some other
2752 algorithm.
2754 Structure of this message:
2756 enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa
2757 /* may be extended, e.g. for ECDH -- see [TLSECC] */
2758 } KeyExchangeAlgorithm;
2760 struct {
2761 opaque dh_p<1..2^16-1>;
2762 opaque dh_g<1..2^16-1>;
2763 opaque dh_Ys<1..2^16-1>;
2764 } ServerDHParams; /* Ephemeral DH parameters */
2766 dh_p
2767 The prime modulus used for the Diffie-Hellman operation.
2769 dh_g
2770 The generator used for the Diffie-Hellman operation.
2772 dh_Ys
2773 The server's Diffie-Hellman public value (g^X mod p).
2776 struct {
2777 select (KeyExchangeAlgorithm) {
2778 case dh_anon:
2779 ServerDHParams params;
2780 case dhe_dss:
2781 case dhe_rsa:
2782 ServerDHParams params;
2783 digitally-signed struct {
2784 opaque client_random[32];
2785 opaque server_random[32];
2786 ServerDHParams params;
2787 } signed_params;
2788 case rsa:
2789 case dh_dss:
2790 case dh_rsa:
2791 struct {} ;
2792 /* message is omitted for rsa, dh_dss, and dh_rsa */
2793 /* may be extended, e.g. for ECDH -- see [TLSECC] */
2794 };
2795 } ServerKeyExchange;
2797 params
2798 The server's key exchange parameters.
2802 Dierks & Rescorla Standards Track [Page 50]
2803 \f
2804 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2807 signed_params
2808 For non-anonymous key exchanges, a signature over the
2809 server's key exchange parameters.
2811 If the client has offered the "signature_algorithms" extension, the
2812 signature algorithm and hash algorithm MUST be a pair listed in that
2813 extension. Note that there is a possibility for inconsistencies here.
2814 For instance, the client might offer DHE_DSS key exchange but omit
2815 any DSA pairs from its "signature_algorithms" extension. In order to
2816 negotiate correctly, the server MUST check any candidate cipher
2817 suites against the "signature_algorithms" extension before selecting
2818 them. This is somewhat inelegant but is a compromise designed to
2819 minimize changes to the original cipher suite design.
2821 In addition, the hash and signature algorithms MUST be compatible
2822 with the key in the server's end-entity certificate. RSA keys MAY be
2823 used with any permitted hash algorithm, subject to restrictions in
2824 the certificate, if any.
2826 Because DSA signatures do not contain any secure indication of hash
2827 algorithm, there is a risk of hash substitution if multiple hashes
2828 may be used with any key. Currently, DSA [DSS] may only be used with
2829 SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use
2830 of other digest algorithms with DSA, as well as guidance as to which
2831 digest algorithms should be used with each key size. In addition,
2832 future revisions of [PKIX] may specify mechanisms for certificates to
2833 indicate which digest algorithms are to be used with DSA.
2835 As additional cipher suites are defined for TLS that include new key
2836 exchange algorithms, the server key exchange message will be sent if
2837 and only if the certificate type associated with the key exchange
2838 algorithm does not provide enough information for the client to
2839 exchange a premaster secret.
2841 7.4.4. Certificate Request
2843 When this message will be sent:
2845 A non-anonymous server can optionally request a certificate from
2846 the client, if appropriate for the selected cipher suite. This
2847 message, if sent, will immediately follow the ServerKeyExchange
2848 message (if it is sent; otherwise, the server's Certificate
2849 message).
2851 Structure of this message:
2853 enum {
2854 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
2858 Dierks & Rescorla Standards Track [Page 51]
2859 \f
2860 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2863 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
2864 fortezza_dms_RESERVED(20), (255)
2865 } ClientCertificateType;
2867 opaque DistinguishedName<1..2^16-1>;
2869 struct {
2870 ClientCertificateType certificate_types<1..2^8-1>;
2871 SignatureAndHashAlgorithm
2872 supported_signature_algorithms<2^16-1>;
2873 DistinguishedName certificate_authorities<0..2^16-1>;
2874 } CertificateRequest;
2876 certificate_types
2877 A list of the types of certificate types which the client may
2878 offer.
2880 rsa_sign a certificate containing an RSA key
2881 dss_sign a certificate containing a DSA key
2882 rsa_fixed_dh a certificate containing a static DH key.
2883 dss_fixed_dh a certificate containing a static DH key
2885 supported_signature_algorithms
2886 A list of the hash/signature algorithm pairs that the server is
2887 able to verify, listed in descending order of preference.
2889 certificate_authorities
2890 A list of the distinguished names [X501] of acceptable
2891 certificate_authorities, represented in DER-encoded format. These
2892 distinguished names may specify a desired distinguished name for a
2893 root CA or for a subordinate CA; thus, this message can be used
2894 both to describe known roots and a desired authorization space. If
2895 the certificate_authorities list is empty then the client MAY send
2896 any certificate of the appropriate ClientCertificateType, unless
2897 there is some external arrangement to the contrary.
2899 The interaction of the certificate_types and
2900 supported_signature_algorithms fields is somewhat complicated.
2901 certificate_types has been present in TLS since SSLv3, but was
2902 somewhat underspecified. Much of its functionality is superseded by
2903 supported_signature_algorithms. The following rules apply:
2905 - Any certificates provided by the client MUST be signed using a
2906 hash/signature algorithm pair found in
2907 supported_signature_algorithms.
2909 - The end-entity certificate provided by the client MUST contain a
2910 key which is compatible with certificate_types. If the key is a
2914 Dierks & Rescorla Standards Track [Page 52]
2915 \f
2916 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2919 signature key, it MUST be usable with some hash/signature
2920 algorithm pair in supported_signature_algorithms.
2922 - For historical reasons, the names of some client certificate types
2923 include the algorithm used to sign the certificate. For example,
2924 in earlier versions of TLS, rsa_fixed_dh meant a certificate
2925 signed with RSA and containing a static DH key. In TLS 1.2, this
2926 functionality has been obsoleted by the
2927 supported_signature_algorithms, and the certificate type no longer
2928 restricts the algorithm used to sign the certificate. For
2929 example, if the server sends dss_fixed_dh certificate type and
2930 {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply
2931 with a certificate containing a static DH key, signed with RSA-
2932 SHA1.
2934 New ClientCertificateType values are assigned by IANA as described in
2935 Section 12.
2937 Note: Values listed as RESERVED may not be used. They were used in
2938 SSLv3.
2940 Note: It is a fatal handshake_failure alert for an anonymous server
2941 to request client authentication.
2943 7.4.5 Server Hello Done
2945 When this message will be sent:
2947 The ServerHelloDone message is sent by the server to indicate the
2948 end of the ServerHello and associated messages. After sending this
2949 message, the server will wait for a client response.
2951 Meaning of this message:
2953 This message means that the server is done sending messages to
2954 support the key exchange, and the client can proceed with its
2955 phase of the key exchange.
2957 Upon receipt of the ServerHelloDone message, the client SHOULD
2958 verify that the server provided a valid certificate, if required,
2959 and check that the server hello parameters are acceptable.
2961 Structure of this message:
2963 struct { } ServerHelloDone;
2965 7.4.6. Client Certificate
2970 Dierks & Rescorla Standards Track [Page 53]
2971 \f
2972 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
2975 When this message will be sent:
2977 This is the first message the client can send after receiving a
2978 server hello done message. This message is only sent if the server
2979 requests a certificate. If no suitable certificate is available,
2980 the client MUST send a certificate message containing no
2981 certificates. That is, the certificate_list structure has a length
2982 of zero. If the client does not send any certificates, the server
2983 MAY at its discretion either continue the handshake without client
2984 authentication, or respond with a fatal handshake_failure alert.
2985 Also, if some aspect of the certificate chain was unacceptable
2986 (e.g., it was not signed by a known, trusted CA), the server MAY
2987 at its discretion either continue the handshake (considering the
2988 client unauthenticated) or send a fatal alert.
2990 Client certificates are sent using the Certificate structure
2991 defined in Section 7.4.2.
2993 Meaning of this message:
2995 This message conveys the client's certificate chain to the server;
2996 the server will use it when verifying the CertificateVerify
2997 message (when the client authentication is based on signing) or
2998 calculating the premaster secret (for non-ephemeral Diffie-
2999 Hellman). The certificate MUST be appropriate for the negotiated
3000 cipher suite's key exchange algorithm, and any negotiated
3001 extensions.
3003 In particular:
3005 - The certificate type MUST be X.509v3, unless explicitly negotiated
3006 otherwise (e.g. [TLSPGP]).
3008 - The end-entity certificate's public key (and associated
3009 restrictions) has to be compatible with the certificate types
3010 listed in CertificateRequest:
3012 Client Cert. Type Certificate Key Type
3014 rsa_sign RSA public key; the certificate MUST allow
3015 the key to be used for signing with the
3016 signature scheme and hash algorithm that
3017 will be employed in the certificate verify
3018 message.
3020 dss_sign DSA public key; the certificate MUST allow
3021 the key to be used for signing with the
3022 hash algorithm that will be employed in
3026 Dierks & Rescorla Standards Track [Page 54]
3027 \f
3028 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3031 the certificate verify message.
3033 ecdsa_sign ECDSA-capable public key; the certificate
3034 MUST allow the key to be used for signing
3035 with the hash algorithm that will be
3036 employed in the certificate verify
3037 message; the public key MUST use a
3038 curve and point format supported by the
3039 server.
3041 rsa_fixed_dh Diffie-Hellman public key; MUST use
3042 dss_fixed_dh the same parameters as server's key.
3044 rsa_fixed_ecdh ECDH-capable public key; MUST use the
3045 ecdsa_fixed_ecdh same curve as the server's key, and
3046 MUST use a point format supported by
3047 the server.
3049 - If the certificate_authorities list in the certificate request
3050 message was non-empty, one of the certificates in the certificate
3051 chain SHOULD be issued by one of the listed CAs.
3053 - The certificates MUST be signed using an acceptable hash/
3054 signature algorithm pair, as described in Section 7.4.4. Note that
3055 this relaxes the constraints on certificate signing algorithms
3056 found in prior versions of TLS.
3058 Note that as with the server certificate, there are certificates that
3059 use algorithms/algorithm combinations that cannot be currently used
3060 with TLS.
3062 7.4.7. Client Key Exchange Message
3064 When this message will be sent:
3066 This message is always sent by the client. It MUST immediately
3067 follow the client certificate message, if it is sent. Otherwise it
3068 MUST be the first message sent by the client after it receives the
3069 server hello done message.
3071 Meaning of this message:
3073 With this message, the premaster secret is set, either through
3074 direct transmission of the RSA-encrypted secret, or by the
3075 transmission of Diffie-Hellman parameters that will allow each
3076 side to agree upon the same premaster secret.
3078 When the client is using an ephemeral Diffie-Hellman exponent,
3082 Dierks & Rescorla Standards Track [Page 55]
3083 \f
3084 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3087 then this message contains the client's Diffie-Hellman public
3088 value. If the client is sending a certificate containing a static
3089 DH exponent (i.e., it is doing fixed_dh client authentication)
3090 then this message MUST be sent but MUST be empty.
3093 Structure of this message:
3095 The choice of messages depends on which key exchange method has
3096 been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
3097 definition.
3099 struct {
3100 select (KeyExchangeAlgorithm) {
3101 case rsa:
3102 EncryptedPreMasterSecret;
3103 case dhe_dss:
3104 case dhe_rsa:
3105 case dh_dss:
3106 case dh_rsa:
3107 case dh_anon:
3108 ClientDiffieHellmanPublic;
3109 } exchange_keys;
3110 } ClientKeyExchange;
3112 7.4.7.1. RSA Encrypted Premaster Secret Message
3114 Meaning of this message:
3116 If RSA is being used for key agreement and authentication, the
3117 client generates a 48-byte premaster secret, encrypts it using the
3118 public key from the server's certificate and sends the result in
3119 an encrypted premaster secret message. This structure is a variant
3120 of the ClientKeyExchange message and is not a message in itself.
3122 Structure of this message:
3124 struct {
3125 ProtocolVersion client_version;
3126 opaque random[46];
3127 } PreMasterSecret;
3129 client_version
3130 The latest (newest) version supported by the client. This is
3131 used to detect version roll-back attacks.
3133 random
3134 46 securely-generated random bytes.
3138 Dierks & Rescorla Standards Track [Page 56]
3139 \f
3140 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3143 struct {
3144 public-key-encrypted PreMasterSecret pre_master_secret;
3145 } EncryptedPreMasterSecret;
3147 pre_master_secret
3148 This random value is generated by the client and is used to
3149 generate the master secret, as specified in Section 8.1.
3151 Note: The version number in the PreMasterSecret is the version
3152 offered by the client in the ClientHello.client_version, not the
3153 version negotiated for the connection. This feature is designed to
3154 prevent rollback attacks. Unfortunately, some old implementations
3155 use the negotiated version instead and therefore checking the version
3156 number may lead to failure to interoperate with such incorrect client
3157 implementations.
3159 Client implementations MUST always send the correct version number in
3160 PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher,
3161 server implementations MUST check the version number as described in
3162 the note below. If the version number is TLS 1.0 or earlier, server
3163 implementations SHOULD check the version number, but MAY have a
3164 configuration option to disable the check. Note that if the check
3165 fails, the PreMasterSecret SHOULD be randomized as described below.
3167 Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
3168 [KPR03] can be used to attack a TLS server that reveals whether a
3169 particular message, when decrypted, is properly PKCS#1 formatted,
3170 contains a valid PreMasterSecret structure, or has the correct
3171 version number.
3173 The best way to avoid these vulnerabilities is to treat incorrectly
3174 formatted messages in a manner indistinguishable from correctly
3175 formatted RSA blocks. In other words:
3177 1. Generate a string R of 46 random bytes
3179 2. Decrypt the message to recover the plaintext M
3181 3. If the PKCS#1 padding is not correct, or the length of
3182 message M is not exactly 48 bytes:
3183 premaster secret = ClientHello.client_version || R
3184 else If ClientHello.client_version <= TLS 1.0, and
3185 version number check is explicitly disabled:
3186 premaster secret = M
3187 else:
3188 premaster secret = ClientHello.client_version || M[2..47]
3190 Note that explicitly constructing the premaster_secret with the
3194 Dierks & Rescorla Standards Track [Page 57]
3195 \f
3196 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3199 ClientHello.client_version produces an invalid master_secret if the
3200 client has sent the wrong version in the original premaster_secret.
3202 In any case, a TLS server MUST NOT generate an alert if processing an
3203 RSA-encrypted premaster secret message fails, or the version number
3204 is not as expected. Instead, it MUST continue the handshake with a
3205 randomly generated premaster secret. It may be useful to log the
3206 real cause of failure for troubleshooting purposes; however, care
3207 must be taken to avoid leaking the information to an attacker
3208 (through, e.g., timing, log files, or other channels.)
3210 The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
3211 against the Bleichenbacher attack. However, for maximal compatibility
3212 with earlier versions of TLS, this specification uses the RSAES-
3213 PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known
3214 to exist provided that the above recommendations are followed.
3216 Implementation Note: Public-key-encrypted data is represented as an
3217 opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
3218 PreMasterSecret in a ClientKeyExchange is preceded by two length
3219 bytes. These bytes are redundant in the case of RSA because the
3220 EncryptedPreMasterSecret is the only data in the ClientKeyExchange
3221 and its length can therefore be unambiguously determined. The SSLv3
3222 specification was not clear about the encoding of public-key-
3223 encrypted data, and therefore many SSLv3 implementations do not
3224 include the length bytes, encoding the RSA encrypted data directly in
3225 the ClientKeyExchange message.
3227 This specification requires correct encoding of the
3228 EncryptedPreMasterSecret complete with length bytes. The resulting
3229 PDU is incompatible with many SSLv3 implementations. Implementors
3230 upgrading from SSLv3 MUST modify their implementations to generate
3231 and accept the correct encoding. Implementors who wish to be
3232 compatible with both SSLv3 and TLS should make their implementation's
3233 behavior dependent on the protocol version.
3235 Implementation Note: It is now known that remote timing-based attacks
3236 on TLS are possible, at least when the client and server are on the
3237 same LAN. Accordingly, implementations that use static RSA keys MUST
3238 use RSA blinding or some other anti-timing technique, as described in
3239 [TIMING].
3242 7.4.7.2. Client Diffie-Hellman Public Value
3244 Meaning of this message:
3246 This structure conveys the client's Diffie-Hellman public value
3250 Dierks & Rescorla Standards Track [Page 58]
3251 \f
3252 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3255 (Yc) if it was not already included in the client's certificate.
3256 The encoding used for Yc is determined by the enumerated
3257 PublicValueEncoding. This structure is a variant of the client key
3258 exchange message, and not a message in itself.
3260 Structure of this message:
3262 enum { implicit, explicit } PublicValueEncoding;
3264 implicit
3265 If the client has sent a certificate which contains a suitable
3266 Diffie-Hellman key (for fixed_dh client authentication) then Yc
3267 is implicit and does not need to be sent again. In this case,
3268 the client key exchange message will be sent, but it MUST be
3269 empty.
3271 explicit
3272 Yc needs to be sent.
3274 struct {
3275 select (PublicValueEncoding) {
3276 case implicit: struct { };
3277 case explicit: opaque dh_Yc<1..2^16-1>;
3278 } dh_public;
3279 } ClientDiffieHellmanPublic;
3281 dh_Yc
3282 The client's Diffie-Hellman public value (Yc).
3284 7.4.8. Certificate verify
3286 When this message will be sent:
3288 This message is used to provide explicit verification of a client
3289 certificate. This message is only sent following a client
3290 certificate that has signing capability (i.e. all certificates
3291 except those containing fixed Diffie-Hellman parameters). When
3292 sent, it MUST immediately follow the client key exchange message.
3294 Structure of this message:
3296 struct {
3297 digitally-signed struct {
3298 opaque handshake_messages[handshake_messages_length];
3299 }
3300 } CertificateVerify;
3302 Here handshake_messages refers to all handshake messages sent or
3306 Dierks & Rescorla Standards Track [Page 59]
3307 \f
3308 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3311 received starting at client hello up to but not including this
3312 message, including the type and length fields of the handshake
3313 messages. This is the concatenation of all the Handshake
3314 structures as defined in 7.4 exchanged thus far. Note that this
3315 requires both sides to either buffer the messages or compute
3316 running hashes for all potential hash algorithms up to the time of
3317 the CertificateVerify computation. Servers can minimize this
3318 computation cost by offering a restricted set of digest algorithms
3319 in the CertificateRequest message.
3321 The hash and signature algorithms used in the signature MUST be
3322 one of those present in the supported_signature_algorithms field
3323 of the CertificateRequest message. In addition, the hash and
3324 signature algorithms MUST be compatible with the key in the
3325 client's end-entity certificate. RSA keys MAY be used with any
3326 permitted hash algorithm, subject to restrictions in the
3327 certificate, if any.
3329 Because DSA signatures do not contain any secure indication of
3330 hash algorithm, there is a risk of hash substitution if multiple
3331 hashes may be used with any key. Currently, DSA [DSS] may only be
3332 used with SHA-1. Future revisions of DSS [DSS-3] are expected to
3333 allow the use of other digest algorithms with DSA, as well as
3334 guidance as to which digest algorithms should be used with each
3335 key size. In addition, future revisions of [PKIX] may specify
3336 mechanisms for certificates to indicate which digest algorithms
3337 are to be used with DSA.
3340 7.4.9. Finished
3342 When this message will be sent:
3344 A Finished message is always sent immediately after a change
3345 cipher spec message to verify that the key exchange and
3346 authentication processes were successful. It is essential that a
3347 change cipher spec message be received between the other handshake
3348 messages and the Finished message.
3350 Meaning of this message:
3352 The finished message is the first one protected with the just
3353 negotiated algorithms, keys, and secrets. Recipients of finished
3354 messages MUST verify that the contents are correct. Once a side
3355 has sent its Finished message and received and validated the
3356 Finished message from its peer, it may begin to send and receive
3357 application data over the connection.
3362 Dierks & Rescorla Standards Track [Page 60]
3363 \f
3364 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3367 Structure of this message:
3369 struct {
3370 opaque verify_data[verify_data_length];
3371 } Finished;
3373 verify_data
3374 PRF(master_secret, finished_label, Hash(handshake_messages))
3375 [0..verify_data_length-1];
3377 finished_label
3378 For Finished messages sent by the client, the string "client
3379 finished". For Finished messages sent by the server, the string
3380 "server finished".
3382 Hash denotes a Hash of the handshake messages. For the PRF defined
3383 in Section 5, the Hash MUST be the Hash used as the basis for the
3384 PRF. Any cipher suite which defines a different PRF MUST also
3385 define the Hash to use in the Finished computation.
3387 In previous versions of TLS, the verify_data was always 12 octets
3388 long. In the current version of TLS, it depends on the cipher
3389 suite. Any cipher suite which does not explicitly specify
3390 verify_data_length has a verify_data_length equal to 12. This
3391 includes all existing cipher suites. Note that this
3392 representation has the same encoding as with previous versions.
3393 Future cipher suites MAY specify other lengths but such length
3394 MUST be at least 12 bytes.
3396 handshake_messages
3397 All of the data from all messages in this handshake (not
3398 including any HelloRequest messages) up to but not including
3399 this message. This is only data visible at the handshake layer
3400 and does not include record layer headers. This is the
3401 concatenation of all the Handshake structures as defined in
3402 7.4, exchanged thus far.
3404 It is a fatal error if a finished message is not preceded by a
3405 ChangeCipherSpec message at the appropriate point in the handshake.
3407 The value handshake_messages includes all handshake messages starting
3408 at ClientHello up to, but not including, this Finished message. This
3409 may be different from handshake_messages in Section 7.4.8 because it
3410 would include the CertificateVerify message (if sent). Also, the
3411 handshake_messages for the Finished message sent by the client will
3412 be different from that for the Finished message sent by the server,
3413 because the one that is sent second will include the prior one.
3418 Dierks & Rescorla Standards Track [Page 61]
3419 \f
3420 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3423 Note: ChangeCipherSpec messages, alerts, and any other record types
3424 are not handshake messages and are not included in the hash
3425 computations. Also, HelloRequest messages are omitted from handshake
3426 hashes.
3428 8. Cryptographic Computations
3430 In order to begin connection protection, the TLS Record Protocol
3431 requires specification of a suite of algorithms, a master secret, and
3432 the client and server random values. The authentication, encryption,
3433 and MAC algorithms are determined by the cipher_suite selected by the
3434 server and revealed in the server hello message. The compression
3435 algorithm is negotiated in the hello messages, and the random values
3436 are exchanged in the hello messages. All that remains is to calculate
3437 the master secret.
3439 8.1. Computing the Master Secret
3441 For all key exchange methods, the same algorithm is used to convert
3442 the pre_master_secret into the master_secret. The pre_master_secret
3443 should be deleted from memory once the master_secret has been
3444 computed.
3446 master_secret = PRF(pre_master_secret, "master secret",
3447 ClientHello.random + ServerHello.random)
3448 [0..47];
3450 The master secret is always exactly 48 bytes in length. The length of
3451 the premaster secret will vary depending on key exchange method.
3453 8.1.1. RSA
3455 When RSA is used for server authentication and key exchange, a
3456 48-byte pre_master_secret is generated by the client, encrypted under
3457 the server's public key, and sent to the server. The server uses its
3458 private key to decrypt the pre_master_secret. Both parties then
3459 convert the pre_master_secret into the master_secret, as specified
3460 above.
3462 8.1.2. Diffie-Hellman
3464 A conventional Diffie-Hellman computation is performed. The
3465 negotiated key (Z) is used as the pre_master_secret, and is converted
3466 into the master_secret, as specified above. Leading bytes of Z that
3467 contain all zero bits are stripped before it is used as the
3468 pre_master_secret.
3470 Note: Diffie-Hellman parameters are specified by the server and may
3474 Dierks & Rescorla Standards Track [Page 62]
3475 \f
3476 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3479 be either ephemeral or contained within the server's certificate.
3481 9. Mandatory Cipher Suites
3483 In the absence of an application profile standard specifying
3484 otherwise, a TLS compliant application MUST implement the cipher
3485 suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the
3486 definition).
3488 10. Application Data Protocol
3490 Application data messages are carried by the Record Layer and are
3491 fragmented, compressed, and encrypted based on the current connection
3492 state. The messages are treated as transparent data to the record
3493 layer.
3495 11. Security Considerations
3497 Security issues are discussed throughout this memo, especially in
3498 Appendices D, E, and F.
3500 12. IANA Considerations
3502 This document uses several registries that were originally created in
3503 [TLS1.1]. IANA is requested to update (has updated) these to
3504 reference this document. The registries and their allocation policies
3505 (unchanged from [TLS1.1]) are listed below.
3507 - TLS ClientCertificateType Identifiers Registry: Future values in
3508 the range 0-63 (decimal) inclusive are assigned via Standards
3509 Action [RFC2434]. Values in the range 64-223 (decimal) inclusive
3510 are assigned Specification Required [RFC2434]. Values from 224-255
3511 (decimal) inclusive are reserved for Private Use [RFC2434].
3513 - TLS Cipher Suite Registry: Future values with the first byte in
3514 the range 0-191 (decimal) inclusive are assigned via Standards
3515 Action [RFC2434]. Values with the first byte in the range 192-254
3516 (decimal) are assigned via Specification Required [RFC2434].
3517 Values with the first byte 255 (decimal) are reserved for Private
3518 Use [RFC2434].
3520 - This document defines several new HMAC-SHA256 based cipher suites,
3521 whose values (in Appendix A.5) are to be (have been) allocated
3522 from the TLS Cipher Suite registry.
3524 - TLS ContentType Registry: Future values are allocated via
3525 Standards Action [RFC2434].
3530 Dierks & Rescorla Standards Track [Page 63]
3531 \f
3532 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3535 - TLS Alert Registry: Future values are allocated via Standards
3536 Action [RFC2434].
3538 - TLS HandshakeType Registry: Future values are allocated via
3539 Standards Action [RFC2434].
3541 This document also uses a registry originally created in [RFC4366].
3542 IANA is requested to update (has updated) it to reference this
3543 document. The registry and its allocation policy (unchanged from
3544 [RFC4366]) is listed below:
3546 - TLS ExtensionType Registry: Future values are allocated via IETF
3547 Consensus [RFC2434]. IANA is requested to update this registry to
3548 include the signature_algorithms extension and fill in the
3549 appropriate value in Section 7.4.1.4.
3551 In addition, this document defines two new registries to be
3552 maintained by IANA:
3554 - TLS SignatureAlgorithm Registry: The registry will be initially
3555 populated with the values described in Section 7.4.1.4.1. Future
3556 values in the range 0-63 (decimal) inclusive are assigned via
3557 Standards Action [RFC2434]. Values in the range 64-223 (decimal)
3558 inclusive are assigned via Specification Required [RFC2434].
3559 Values from 224-255 (decimal) inclusive are reserved for Private
3560 Use [RFC2434].
3562 - TLS HashAlgorithm Registry: The registry will be initially
3563 populated with the values described in Section 7.4.1.4.1. Future
3564 values in the range 0-63 (decimal) inclusive are assigned via
3565 Standards Action [RFC2434]. Values in the range 64-223 (decimal)
3566 inclusive are assigned via Specification Required [RFC2434].
3567 Values from 224-255 (decimal) inclusive are reserved for Private
3568 Use [RFC2434].
3570 This document also uses the TLS Compression Method Identifiers
3571 Registry, defined in [RFC3749]. IANA is requested to allocate
3572 value 0 for the "null" compression method.
3586 Dierks & Rescorla Standards Track [Page 64]
3587 \f
3588 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3591 Appendix A. Protocol Data Structures and Constant Values
3593 This section describes protocol types and constants.
3595 A.1. Record Layer
3597 struct {
3598 uint8 major;
3599 uint8 minor;
3600 } ProtocolVersion;
3602 ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/
3604 enum {
3605 change_cipher_spec(20), alert(21), handshake(22),
3606 application_data(23), (255)
3607 } ContentType;
3609 struct {
3610 ContentType type;
3611 ProtocolVersion version;
3612 uint16 length;
3613 opaque fragment[TLSPlaintext.length];
3614 } TLSPlaintext;
3616 struct {
3617 ContentType type;
3618 ProtocolVersion version;
3619 uint16 length;
3620 opaque fragment[TLSCompressed.length];
3621 } TLSCompressed;
3623 struct {
3624 ContentType type;
3625 ProtocolVersion version;
3626 uint16 length;
3627 select (SecurityParameters.cipher_type) {
3628 case stream: GenericStreamCipher;
3629 case block: GenericBlockCipher;
3630 case aead: GenericAEADCipher;
3631 } fragment;
3632 } TLSCiphertext;
3634 stream-ciphered struct {
3635 opaque content[TLSCompressed.length];
3636 opaque MAC[SecurityParameters.mac_length];
3637 } GenericStreamCipher;
3642 Dierks & Rescorla Standards Track [Page 65]
3643 \f
3644 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3647 struct {
3648 opaque IV[SecurityParameters.record_iv_length];
3649 block-ciphered struct {
3650 opaque content[TLSCompressed.length];
3651 opaque MAC[SecurityParameters.mac_length];
3652 uint8 padding[GenericBlockCipher.padding_length];
3653 uint8 padding_length;
3654 };
3655 } GenericBlockCipher;
3657 struct {
3658 opaque nonce_explicit[SecurityParameters.record_iv_length];
3659 aead-ciphered struct {
3660 opaque content[TLSCompressed.length];
3661 };
3662 } GenericAEADCipher;
3663 A.2. Change Cipher Specs Message
3665 struct {
3666 enum { change_cipher_spec(1), (255) } type;
3667 } ChangeCipherSpec;
3669 A.3. Alert Messages
3671 enum { warning(1), fatal(2), (255) } AlertLevel;
3673 enum {
3674 close_notify(0),
3675 unexpected_message(10),
3676 bad_record_mac(20),
3677 decryption_failed_RESERVED(21),
3678 record_overflow(22),
3679 decompression_failure(30),
3680 handshake_failure(40),
3681 no_certificate_RESERVED(41),
3682 bad_certificate(42),
3683 unsupported_certificate(43),
3684 certificate_revoked(44),
3685 certificate_expired(45),
3686 certificate_unknown(46),
3687 illegal_parameter(47),
3688 unknown_ca(48),
3689 access_denied(49),
3690 decode_error(50),
3691 decrypt_error(51),
3692 export_restriction_RESERVED(60),
3693 protocol_version(70),
3694 insufficient_security(71),
3698 Dierks & Rescorla Standards Track [Page 66]
3699 \f
3700 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3703 internal_error(80),
3704 user_canceled(90),
3705 no_renegotiation(100),
3706 unsupported_extension(110), /* new */
3707 (255)
3708 } AlertDescription;
3710 struct {
3711 AlertLevel level;
3712 AlertDescription description;
3713 } Alert;
3715 A.4. Handshake Protocol
3717 enum {
3718 hello_request(0), client_hello(1), server_hello(2),
3719 certificate(11), server_key_exchange (12),
3720 certificate_request(13), server_hello_done(14),
3721 certificate_verify(15), client_key_exchange(16),
3722 finished(20)
3723 (255)
3724 } HandshakeType;
3726 struct {
3727 HandshakeType msg_type;
3728 uint24 length;
3729 select (HandshakeType) {
3730 case hello_request: HelloRequest;
3731 case client_hello: ClientHello;
3732 case server_hello: ServerHello;
3733 case certificate: Certificate;
3734 case server_key_exchange: ServerKeyExchange;
3735 case certificate_request: CertificateRequest;
3736 case server_hello_done: ServerHelloDone;
3737 case certificate_verify: CertificateVerify;
3738 case client_key_exchange: ClientKeyExchange;
3739 case finished: Finished;
3740 } body;
3741 } Handshake;
3743 A.4.1. Hello Messages
3745 struct { } HelloRequest;
3747 struct {
3748 uint32 gmt_unix_time;
3749 opaque random_bytes[28];
3750 } Random;
3754 Dierks & Rescorla Standards Track [Page 67]
3755 \f
3756 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3759 opaque SessionID<0..32>;
3761 uint8 CipherSuite[2];
3763 enum { null(0), (255) } CompressionMethod;
3765 struct {
3766 ProtocolVersion client_version;
3767 Random random;
3768 SessionID session_id;
3769 CipherSuite cipher_suites<2..2^16-2>;
3770 CompressionMethod compression_methods<1..2^8-1>;
3771 select (extensions_present) {
3772 case false:
3773 struct {};
3774 case true:
3775 Extension extensions<0..2^16-1>;
3776 };
3777 } ClientHello;
3779 struct {
3780 ProtocolVersion server_version;
3781 Random random;
3782 SessionID session_id;
3783 CipherSuite cipher_suite;
3784 CompressionMethod compression_method;
3785 select (extensions_present) {
3786 case false:
3787 struct {};
3788 case true:
3789 Extension extensions<0..2^16-1>;
3790 };
3791 } ServerHello;
3793 struct {
3794 ExtensionType extension_type;
3795 opaque extension_data<0..2^16-1>;
3796 } Extension;
3798 enum {
3799 signature_algorithms(TBD-BY-IANA), (65535)
3800 } ExtensionType;
3802 enum{
3803 none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
3804 sha512(6), (255)
3805 } HashAlgorithm;
3810 Dierks & Rescorla Standards Track [Page 68]
3811 \f
3812 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3815 enum {
3816 anonymous(0), rsa(1), dsa(2), ecdsa(3), (255)
3817 } SignatureAlgorithm;
3819 struct {
3820 HashAlgorithm hash;
3821 SignatureAlgorithm signature;
3822 } SignatureAndHashAlgorithm;
3824 SignatureAndHashAlgorithm
3825 supported_signature_algorithms<2..2^16-1>;
3827 A.4.2. Server Authentication and Key Exchange Messages
3829 opaque ASN.1Cert<2^24-1>;
3831 struct {
3832 ASN.1Cert certificate_list<0..2^24-1>;
3833 } Certificate;
3835 enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa
3836 /* may be extended, e.g. for ECDH -- see [TLSECC] */
3837 } KeyExchangeAlgorithm;
3839 struct {
3840 opaque dh_p<1..2^16-1>;
3841 opaque dh_g<1..2^16-1>;
3842 opaque dh_Ys<1..2^16-1>;
3843 } ServerDHParams; /* Ephemeral DH parameters */
3845 struct {
3846 select (KeyExchangeAlgorithm) {
3847 case dh_anon:
3848 ServerDHParams params;
3849 case dhe_dss:
3850 case dhe_rsa:
3851 ServerDHParams params;
3852 digitally-signed struct {
3853 opaque client_random[32];
3854 opaque server_random[32];
3855 ServerDHParams params;
3856 } signed_params;
3857 case rsa:
3858 case dh_dss:
3859 case dh_rsa:
3860 struct {} ;
3861 /* message is omitted for rsa, dh_dss, and dh_rsa */
3862 /* may be extended, e.g. for ECDH -- see [TLSECC] */
3866 Dierks & Rescorla Standards Track [Page 69]
3867 \f
3868 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3871 } ServerKeyExchange;
3874 enum {
3875 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
3876 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
3877 fortezza_dms_RESERVED(20),
3878 (255)
3879 } ClientCertificateType;
3881 opaque DistinguishedName<1..2^16-1>;
3883 struct {
3884 ClientCertificateType certificate_types<1..2^8-1>;
3885 DistinguishedName certificate_authorities<0..2^16-1>;
3886 } CertificateRequest;
3888 struct { } ServerHelloDone;
3890 A.4.3. Client Authentication and Key Exchange Messages
3892 struct {
3893 select (KeyExchangeAlgorithm) {
3894 case rsa:
3895 EncryptedPreMasterSecret;
3896 case dhe_dss:
3897 case dhe_rsa:
3898 case dh_dss:
3899 case dh_rsa:
3900 case dh_anon:
3901 ClientDiffieHellmanPublic;
3902 } exchange_keys;
3903 } ClientKeyExchange;
3905 struct {
3906 ProtocolVersion client_version;
3907 opaque random[46];
3908 } PreMasterSecret;
3910 struct {
3911 public-key-encrypted PreMasterSecret pre_master_secret;
3912 } EncryptedPreMasterSecret;
3914 enum { implicit, explicit } PublicValueEncoding;
3916 struct {
3917 select (PublicValueEncoding) {
3918 case implicit: struct {};
3922 Dierks & Rescorla Standards Track [Page 70]
3923 \f
3924 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3927 case explicit: opaque DH_Yc<1..2^16-1>;
3928 } dh_public;
3929 } ClientDiffieHellmanPublic;
3931 struct {
3932 digitally-signed struct {
3933 opaque handshake_messages[handshake_messages_length];
3934 }
3935 } CertificateVerify;
3937 A.4.4. Handshake Finalization Message
3939 struct {
3940 opaque verify_data[verify_data_length];
3941 } Finished;
3943 A.5. The Cipher Suite
3945 The following values define the cipher suite codes used in the client
3946 hello and server hello messages.
3948 A cipher suite defines a cipher specification supported in TLS
3949 Version 1.2.
3951 TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
3952 TLS connection during the first handshake on that channel, but MUST
3953 NOT be negotiated, as it provides no more protection than an
3954 unsecured connection.
3956 CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
3958 The following CipherSuite definitions require that the server provide
3959 an RSA certificate that can be used for key exchange. The server may
3960 request any signature-capable certificate in the certificate request
3961 message.
3963 CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
3964 CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
3965 CipherSuite TLS_RSA_WITH_NULL_SHA256 = { 0x00,TBD1 };
3966 CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
3967 CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
3968 CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
3969 CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F };
3970 CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
3971 CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD2 };
3972 CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBD3 };
3978 Dierks & Rescorla Standards Track [Page 71]
3979 \f
3980 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
3983 The following cipher suite definitions are used for server-
3984 authenticated (and optionally client-authenticated) Diffie-Hellman.
3985 DH denotes cipher suites in which the server's certificate contains
3986 the Diffie-Hellman parameters signed by the certificate authority
3987 (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
3988 parameters are signed by a signature-capable certificate, which has
3989 been signed by the CA. The signing algorithm used by the server is
3990 specified after the DHE component of the CipherSuite name. The server
3991 can request any signature-capable certificate from the client for
3992 client authentication or it may request a Diffie-Hellman certificate.
3993 Any Diffie-Hellman certificate provided by the client must use the
3994 parameters (group and generator) described by the server.
3997 CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
3998 CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
3999 CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
4000 CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
4001 CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 };
4002 CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 };
4003 CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 };
4004 CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 };
4005 CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 };
4006 CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 };
4007 CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 };
4008 CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 };
4009 CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,TBD4 };
4010 CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD5 };
4011 CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,TBD6 };
4012 CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD7 };
4013 CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,TBD8 };
4014 CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBD9 };
4015 CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,TBDA };
4016 CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBDB };
4018 The following cipher suites are used for completely anonymous Diffie-
4019 Hellman communications in which neither party is authenticated. Note
4020 that this mode is vulnerable to man-in-the-middle attacks. Using
4021 this mode therefore is of limited use: These cipher suites MUST NOT
4022 be used by TLS 1.2 implementations unless the application layer has
4023 specifically requested to allow anonymous key exchange. (Anonymous
4024 key exchange may sometimes be acceptable, for example, to support
4025 opportunistic encryption when no set-up for authentication is in
4026 place, or when TLS is used as part of more complex security protocols
4027 that have other means to ensure authentication.)
4029 CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
4030 CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
4034 Dierks & Rescorla Standards Track [Page 72]
4035 \f
4036 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4039 CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 };
4040 CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A };
4041 CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,TBDC};
4042 CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,TBDD};
4044 Note that using non-anonymous key exchange without actually verifying
4045 the key exchange is essentially equivalent to anonymous key exchange,
4046 and the same precautions apply. While non-anonymous key exchange
4047 will generally involve a higher computational and communicational
4048 cost than anonymous key exchange, it may be in the interest of
4049 interoperability not to disable non-anonymous key exchange when the
4050 application layer is allowing anonymous key exchange.
4052 New cipher suite values are assigned by IANA as described in Section
4053 12.
4055 Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
4056 reserved to avoid collision with Fortezza-based cipher suites in SSL
4057 3.
4059 A.6. The Security Parameters
4061 These security parameters are determined by the TLS Handshake
4062 Protocol and provided as parameters to the TLS Record Layer in order
4063 to initialize a connection state. SecurityParameters includes:
4065 enum { null(0), (255) } CompressionMethod;
4067 enum { server, client } ConnectionEnd;
4069 enum { tls_prf_sha256 } PRFAlgorithm;
4071 enum { null, rc4, 3des, aes }
4072 BulkCipherAlgorithm;
4074 enum { stream, block, aead } CipherType;
4076 enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384,
4077 hmac_sha512} MACAlgorithm;
4079 /* The algorithms specified in CompressionMethod, PRFAlgorithm
4080 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
4082 struct {
4083 ConnectionEnd entity;
4084 PRFAlgorithm prf_algorithm;
4085 BulkCipherAlgorithm bulk_cipher_algorithm;
4086 CipherType cipher_type;
4090 Dierks & Rescorla Standards Track [Page 73]
4091 \f
4092 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4095 uint8 enc_key_length;
4096 uint8 block_length;
4097 uint8 fixed_iv_length;
4098 uint8 record_iv_length;
4099 MACAlgorithm mac_algorithm;
4100 uint8 mac_length;
4101 uint8 mac_key_length;
4102 CompressionMethod compression_algorithm;
4103 opaque master_secret[48];
4104 opaque client_random[32];
4105 opaque server_random[32];
4106 } SecurityParameters;
4108 A.7. Changes to RFC 4492
4110 RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This
4111 document changes some of the structures used in that document. This
4112 section details the required changes for implementors of both RFC
4113 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing
4114 RFC 4492 do not need to read this section.
4116 This document adds a "signature_algorithm" field to the digitally-
4117 signed element in order to identify the signature and digest
4118 algorithms used to create a signature. This change applies to digital
4119 signatures formed using ECDSA as well, thus allowing ECDSA signatures
4120 to be used with digest algorithms other than SHA-1, provided such use
4121 is compatible with the certificate and any restrictions imposed by
4122 future revisions of [PKIX].
4124 As described in Sections 7.4.2 and 7.4.6, the restrictions on the
4125 signature algorithms used to sign certificates are no longer tied to
4126 the cipher suite (when used by the server) or the
4127 ClientCertificateType (when used by the client). Thus, the
4128 restrictions on the algorithm used to sign certificates specified in
4129 Sections 2 and 3 of RFC 4492 are also relaxed. As in this document
4130 the restrictions on the keys in the end-entity certificate remain.
4132 Appendix B. Glossary
4134 Advanced Encryption Standard (AES)
4135 AES [AES] is a widely used symmetric encryption algorithm. AES is
4136 a block cipher with a 128, 192, or 256 bit keys and a 16 byte
4137 block size. TLS currently only supports the 128 and 256 bit key
4138 sizes.
4140 application protocol
4141 An application protocol is a protocol that normally layers
4142 directly on top of the transport layer (e.g., TCP/IP). Examples
4146 Dierks & Rescorla Standards Track [Page 74]
4147 \f
4148 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4151 include HTTP, TELNET, FTP, and SMTP.
4153 asymmetric cipher
4154 See public key cryptography.
4156 authenticated encryption with additional data (AEAD)
4157 A symmetric encryption algorithm that simultaneously provides
4158 confidentiality and message integrity.
4160 authentication
4161 Authentication is the ability of one entity to determine the
4162 identity of another entity.
4164 block cipher
4165 A block cipher is an algorithm that operates on plaintext in
4166 groups of bits, called blocks. 64 bits was, and 128 bits, is a
4167 common block size.
4169 bulk cipher
4170 A symmetric encryption algorithm used to encrypt large quantities
4171 of data.
4173 cipher block chaining (CBC)
4174 CBC is a mode in which every plaintext block encrypted with a
4175 block cipher is first exclusive-ORed with the previous ciphertext
4176 block (or, in the case of the first block, with the initialization
4177 vector). For decryption, every block is first decrypted, then
4178 exclusive-ORed with the previous ciphertext block (or IV).
4180 certificate
4181 As part of the X.509 protocol (a.k.a. ISO Authentication
4182 framework), certificates are assigned by a trusted Certificate
4183 Authority and provide a strong binding between a party's identity
4184 or some other attributes and its public key.
4186 client
4187 The application entity that initiates a TLS connection to a
4188 server. This may or may not imply that the client initiated the
4189 underlying transport connection. The primary operational
4190 difference between the server and client is that the server is
4191 generally authenticated, while the client is only optionally
4192 authenticated.
4194 client write key
4195 The key used to encrypt data written by the client.
4197 client write MAC key
4198 The secret data used to authenticate data written by the client.
4202 Dierks & Rescorla Standards Track [Page 75]
4203 \f
4204 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4207 connection
4208 A connection is a transport (in the OSI layering model definition)
4209 that provides a suitable type of service. For TLS, such
4210 connections are peer-to-peer relationships. The connections are
4211 transient. Every connection is associated with one session.
4213 Data Encryption Standard
4214 DES [DES] still is a very widely used symmetric encryption
4215 algorithm although it is considered as rather weak now. DES is a
4216 block cipher with a 56-bit key and an 8-byte block size. Note that
4217 in TLS, for key generation purposes, DES is treated as having an
4218 8-byte key length (64 bits), but it still only provides 56 bits of
4219 protection. (The low bit of each key byte is presumed to be set to
4220 produce odd parity in that key byte.) DES can also be operated in
4221 a mode [3DES] where three independent keys and three encryptions
4222 are used for each block of data; this uses 168 bits of key (24
4223 bytes in the TLS key generation method) and provides the
4224 equivalent of 112 bits of security.
4226 Digital Signature Standard (DSS)
4227 A standard for digital signing, including the Digital Signing
4228 Algorithm, approved by the National Institute of Standards and
4229 Technology, defined in NIST FIPS PUB 186-2, "Digital Signature
4230 Standard", published January 2000 by the U.S. Dept. of Commerce
4231 [DSS]. A significant update [DSS-3] has been drafted and
4232 published in March 2006.
4235 digital signatures
4236 Digital signatures utilize public key cryptography and one-way
4237 hash functions to produce a signature of the data that can be
4238 authenticated, and is difficult to forge or repudiate.
4240 handshake
4241 An initial negotiation between client and server that establishes
4242 the parameters of their transactions.
4244 Initialization Vector (IV)
4245 When a block cipher is used in CBC mode, the initialization vector
4246 is exclusive-ORed with the first plaintext block prior to
4247 encryption.
4249 Message Authentication Code (MAC)
4250 A Message Authentication Code is a one-way hash computed from a
4251 message and some secret data. It is difficult to forge without
4252 knowing the secret data. Its purpose is to detect if the message
4253 has been altered.
4258 Dierks & Rescorla Standards Track [Page 76]
4259 \f
4260 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4263 master secret
4264 Secure secret data used for generating encryption keys, MAC
4265 secrets, and IVs.
4267 MD5
4268 MD5 [MD5] is a hashing function that converts an arbitrarily long
4269 data stream into a hash of fixed size (16 bytes). Due to
4270 significant progresses in cryptanalysis, at the time of
4271 publication of this document, MD5 no longer can be considered a
4272 'secure' hashing function.
4274 public key cryptography
4275 A class of cryptographic techniques employing two-key ciphers.
4276 Messages encrypted with the public key can only be decrypted with
4277 the associated private key. Conversely, messages signed with the
4278 private key can be verified with the public key.
4280 one-way hash function
4281 A one-way transformation that converts an arbitrary amount of data
4282 into a fixed-length hash. It is computationally hard to reverse
4283 the transformation or to find collisions. MD5 and SHA are examples
4284 of one-way hash functions.
4286 RC4
4287 A stream cipher invented by Ron Rivest. A compatible cipher is
4288 described in [SCH].
4290 RSA
4291 A very widely used public-key algorithm that can be used for
4292 either encryption or digital signing. [RSA]
4294 server
4295 The server is the application entity that responds to requests for
4296 connections from clients. See also under client.
4298 session
4299 A TLS session is an association between a client and a server.
4300 Sessions are created by the handshake protocol. Sessions define a
4301 set of cryptographic security parameters that can be shared among
4302 multiple connections. Sessions are used to avoid the expensive
4303 negotiation of new security parameters for each connection.
4305 session identifier
4306 A session identifier is a value generated by a server that
4307 identifies a particular session.
4309 server write key
4310 The key used to encrypt data written by the server.
4314 Dierks & Rescorla Standards Track [Page 77]
4315 \f
4316 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4319 server write MAC key
4320 The secret data used to authenticate data written by the server.
4322 SHA
4323 The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2. It
4324 produces a 20-byte output. Note that all references to SHA
4325 (without a numerical suffix) actually use the modified SHA-1
4326 algorithm.
4328 SHA-256
4329 The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. It
4330 produces a 32-byte output.
4332 SSL
4333 Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
4334 SSL Version 3.0
4336 stream cipher
4337 An encryption algorithm that converts a key into a
4338 cryptographically strong keystream, which is then exclusive-ORed
4339 with the plaintext.
4341 symmetric cipher
4342 See bulk cipher.
4344 Transport Layer Security (TLS)
4345 This protocol; also, the Transport Layer Security working group of
4346 the Internet Engineering Task Force (IETF). See "Comments" at the
4347 end of this document.
4370 Dierks & Rescorla Standards Track [Page 78]
4371 \f
4372 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4375 Appendix C. Cipher Suite Definitions
4377 Cipher Suite Key Cipher Mac
4378 Exchange
4380 TLS_NULL_WITH_NULL_NULL NULL NULL NULL
4381 TLS_RSA_WITH_NULL_MD5 RSA NULL MD5
4382 TLS_RSA_WITH_NULL_SHA RSA NULL SHA
4383 TLS_RSA_WITH_NULL_SHA256 RSA NULL SHA256
4384 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
4385 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
4386 TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
4387 TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA
4388 TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA
4389 TLS_RSA_WITH_AES_128_CBC_SHA256 RSA AES_128_CBC SHA256
4390 TLS_RSA_WITH_AES_256_CBC_SHA256 RSA AES_256_CBC SHA256
4391 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
4392 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
4393 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
4394 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
4395 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
4396 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
4397 TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA
4398 TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA
4399 TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA
4400 TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA
4401 TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA
4402 TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA
4403 TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA
4404 TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA
4405 TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA
4406 TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA
4407 TLS_DH_DSS_WITH_AES_128_CBC_SHA256 DH_DSS AES_128_CBC SHA256
4408 TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256
4409 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256
4410 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256
4411 TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256
4412 TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256
4413 TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256
4414 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256
4415 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256
4416 TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256
4419 Key IV Block
4420 Cipher Type Material Size Size
4421 ------------ ------ -------- ---- -----
4422 NULL Stream 0 0 N/A
4426 Dierks & Rescorla Standards Track [Page 79]
4427 \f
4428 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4431 RC4_128 Stream 16 0 N/A
4432 3DES_EDE_CBC Block 24 8 8
4433 AES_128_CBC Block 16 16 16
4434 AES_256_CBC Block 32 16 16
4437 MAC Algorithm mac_length mac_key_length
4438 -------- ----------- ---------- --------------
4439 NULL N/A 0 0
4440 MD5 HMAC-MD5 16 16
4441 SHA HMAC-SHA1 20 20
4442 SHA256 HMAC-SHA256 32 32
4444 Type
4445 Indicates whether this is a stream cipher or a block cipher
4446 running in CBC mode.
4448 Key Material
4449 The number of bytes from the key_block that are used for
4450 generating the write keys.
4452 Expanded Key Material
4453 The number of bytes actually fed into the encryption algorithm.
4455 IV Size
4456 The amount of data needed to be generated for the initialization
4457 vector. Zero for stream ciphers; equal to the block size for block
4458 ciphers (this is equal to SecurityParameters.record_iv_length).
4460 Block Size
4461 The amount of data a block cipher enciphers in one chunk; a block
4462 cipher running in CBC mode can only encrypt an even multiple of
4463 its block size.
4482 Dierks & Rescorla Standards Track [Page 80]
4483 \f
4484 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4487 Appendix D. Implementation Notes
4489 The TLS protocol cannot prevent many common security mistakes. This
4490 section provides several recommendations to assist implementors.
4492 D.1 Random Number Generation and Seeding
4494 TLS requires a cryptographically secure pseudorandom number generator
4495 (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs
4496 based on secure hash operations, most notably SHA-1, are acceptable,
4497 but cannot provide more security than the size of the random number
4498 generator state.
4500 To estimate the amount of seed material being produced, add the
4501 number of bits of unpredictable information in each seed byte. For
4502 example, keystroke timing values taken from a PC compatible's 18.2 Hz
4503 timer provide 1 or 2 secure bits each, even though the total size of
4504 the counter value is 16 bits or more. Seeding a 128-bit PRNG would
4505 thus require approximately 100 such timer values.
4507 [RANDOM] provides guidance on the generation of random values.
4509 D.2 Certificates and Authentication
4511 Implementations are responsible for verifying the integrity of
4512 certificates and should generally support certificate revocation
4513 messages. Certificates should always be verified to ensure proper
4514 signing by a trusted Certificate Authority (CA). The selection and
4515 addition of trusted CAs should be done very carefully. Users should
4516 be able to view information about the certificate and root CA.
4518 D.3 Cipher Suites
4520 TLS supports a range of key sizes and security levels, including some
4521 that provide no or minimal security. A proper implementation will
4522 probably not support many cipher suites. For instance, anonymous
4523 Diffie-Hellman is strongly discouraged because it cannot prevent man-
4524 in-the-middle attacks. Applications should also enforce minimum and
4525 maximum key sizes. For example, certificate chains containing 512-bit
4526 RSA keys or signatures are not appropriate for high-security
4527 applications.
4529 D.4 Implementation Pitfalls
4531 Implementation experience has shown that certain parts of earlier TLS
4532 specifications are not easy to understand, and have been a source of
4533 interoperability and security problems. Many of these areas have been
4534 clarified in this document, but this appendix contains a short list
4538 Dierks & Rescorla Standards Track [Page 81]
4539 \f
4540 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4543 of the most important things that require special attention from
4544 implementors.
4546 TLS protocol issues:
4548 - Do you correctly handle handshake messages that are fragmented
4549 to multiple TLS records (see Section 6.2.1)? Including corner
4550 cases like a ClientHello that is split to several small
4551 fragments? Do you fragment handshake messages that exceed the
4552 maximum fragment size? In particular, the certificate and
4553 certificate request handshake messages can be large enough to
4554 require fragmentation.
4556 - Do you ignore the TLS record layer version number in all TLS
4557 records before ServerHello (see Appendix E.1)?
4559 - Do you handle TLS extensions in ClientHello correctly,
4560 including omitting the extensions field completely?
4562 - Do you support renegotiation, both client and server initiated?
4563 While renegotiation is an optional feature, supporting
4564 it is highly recommended.
4566 - When the server has requested a client certificate, but no
4567 suitable certificate is available, do you correctly send
4568 an empty Certificate message, instead of omitting the whole
4569 message (see Section 7.4.6)?
4571 Cryptographic details:
4573 - In RSA-encrypted Premaster Secret, do you correctly send and
4574 verify the version number? When an error is encountered, do
4575 you continue the handshake to avoid the Bleichenbacher
4576 attack (see Section 7.4.7.1)?
4578 - What countermeasures do you use to prevent timing attacks against
4579 RSA decryption and signing operations (see Section 7.4.7.1)?
4581 - When verifying RSA signatures, do you accept both NULL and
4582 missing parameters (see Section 4.7)? Do you verify that the
4583 RSA padding doesn't have additional data after the hash value?
4584 [FI06]
4586 - When using Diffie-Hellman key exchange, do you correctly strip
4587 leading zero bytes from the negotiated key (see Section 8.1.2)?
4589 - Does your TLS client check that the Diffie-Hellman parameters
4590 sent by the server are acceptable (see Section F.1.1.3)?
4594 Dierks & Rescorla Standards Track [Page 82]
4595 \f
4596 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4599 - How do you generate unpredictable IVs for CBC mode ciphers
4600 (see Section 6.2.3.2)?
4602 - Do you accept long CBC mode padding (up to 255 bytes; see
4603 Section 6.2.3.2)?
4605 - How do you address CBC mode timing attacks (Section 6.2.3.2)?
4607 - Do you use a strong and, most importantly, properly seeded
4608 random number generator (see Appendix D.1) for generating the
4609 premaster secret (for RSA key exchange), Diffie-Hellman private
4610 values, the DSA "k" parameter, and other security-critical
4611 values?
4650 Dierks & Rescorla Standards Track [Page 83]
4651 \f
4652 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4655 Appendix E. Backward Compatibility
4657 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
4659 Since there are various versions of TLS (1.0, 1.1, 1.2, and any
4660 future versions) and SSL (2.0 and 3.0), means are needed to negotiate
4661 the specific protocol version to use. The TLS protocol provides a
4662 built-in mechanism for version negotiation so as not to bother other
4663 protocol components with the complexities of version selection.
4665 TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
4666 compatible ClientHello messages; thus, supporting all of them is
4667 relatively easy. Similarly, servers can easily handle clients trying
4668 to use future versions of TLS as long as the ClientHello format
4669 remains compatible, and the client supports the highest protocol
4670 version available in the server.
4672 A TLS 1.2 client who wishes to negotiate with such older servers will
4673 send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
4674 ClientHello.client_version. If the server does not support this
4675 version, it will respond with ServerHello containing an older version
4676 number. If the client agrees to use this version, the negotiation
4677 will proceed as appropriate for the negotiated protocol.
4679 If the version chosen by the server is not supported by the client
4680 (or not acceptable), the client MUST send a "protocol_version" alert
4681 message and close the connection.
4683 If a TLS server receives a ClientHello containing a version number
4684 greater than the highest version supported by the server, it MUST
4685 reply according to the highest version supported by the server.
4687 A TLS server can also receive a ClientHello containing a version
4688 number smaller than the highest supported version. If the server
4689 wishes to negotiate with old clients, it will proceed as appropriate
4690 for the highest version supported by the server that is not greater
4691 than ClientHello.client_version. For example, if the server supports
4692 TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
4693 proceed with a TLS 1.0 ServerHello. If server supports (or is willing
4694 to use) only versions greater than client_version, it MUST send a
4695 "protocol_version" alert message and close the connection.
4697 Whenever a client already knows the highest protocol version known to
4698 a server (for example, when resuming a session), it SHOULD initiate
4699 the connection in that native protocol.
4701 Note: some server implementations are known to implement version
4702 negotiation incorrectly. For example, there are buggy TLS 1.0 servers
4706 Dierks & Rescorla Standards Track [Page 84]
4707 \f
4708 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4711 that simply close the connection when the client offers a version
4712 newer than TLS 1.0. Also, it is known that some servers will refuse
4713 the connection if any TLS extensions are included in ClientHello.
4714 Interoperability with such buggy servers is a complex topic beyond
4715 the scope of this document, and may require multiple connection
4716 attempts by the client.
4718 Earlier versions of the TLS specification were not fully clear on
4719 what the record layer version number (TLSPlaintext.version) should
4720 contain when sending ClientHello (i.e., before it is known which
4721 version of the protocol will be employed). Thus, TLS servers
4722 compliant with this specification MUST accept any value {03,XX} as
4723 the record layer version number for ClientHello.
4725 TLS clients that wish to negotiate with older servers MAY send any
4726 value {03,XX} as the record layer version number. Typical values
4727 would be {03,00}, the lowest version number supported by the client,
4728 and the value of ClientHello.client_version. No single value will
4729 guarantee interoperability with all old servers, but this is a
4730 complex topic beyond the scope of this document.
4732 E.2 Compatibility with SSL 2.0
4734 TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
4735 version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST
4736 contain the same version number as would be used for ordinary
4737 ClientHello, and MUST encode the supported TLS cipher suites in the
4738 CIPHER-SPECS-DATA field as described below.
4740 Warning: The ability to send version 2.0 CLIENT-HELLO messages will
4741 be phased out with all due haste, since the newer ClientHello format
4742 provides better mechanisms for moving to newer versions and
4743 negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0.
4745 However, even TLS servers that do not support SSL 2.0 MAY accept
4746 version 2.0 CLIENT-HELLO messages. The message is presented below in
4747 sufficient detail for TLS server implementors; the true definition is
4748 still assumed to be [SSL2].
4750 For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
4751 way as a ClientHello with a "null" compression method and no
4752 extensions. Note that this message MUST be sent directly on the wire,
4753 not wrapped as a TLS record. For the purposes of calculating Finished
4754 and CertificateVerify, the msg_length field is not considered to be a
4755 part of the handshake message.
4757 uint8 V2CipherSpec[3];
4762 Dierks & Rescorla Standards Track [Page 85]
4763 \f
4764 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4767 struct {
4768 uint16 msg_length;
4769 uint8 msg_type;
4770 Version version;
4771 uint16 cipher_spec_length;
4772 uint16 session_id_length;
4773 uint16 challenge_length;
4774 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
4775 opaque session_id[V2ClientHello.session_id_length];
4776 opaque challenge[V2ClientHello.challenge_length;
4777 } V2ClientHello;
4779 msg_length
4780 The highest bit MUST be 1; the remaining bits contain the length
4781 of the following data in bytes.
4783 msg_type
4784 This field, in conjunction with the version field, identifies a
4785 version 2 client hello message. The value MUST be one (1).
4787 version
4788 Equal to ClientHello.client_version.
4790 cipher_spec_length
4791 This field is the total length of the field cipher_specs. It
4792 cannot be zero and MUST be a multiple of the V2CipherSpec length
4793 (3).
4795 session_id_length
4796 This field MUST have a value of zero for a client that claims to
4797 support TLS 1.2.
4799 challenge_length
4800 The length in bytes of the client's challenge to the server to
4801 authenticate itself. Historically, permissible values are between
4802 16 and 32 bytes inclusive. When using the SSLv2 backward
4803 compatible handshake the client SHOULD use a 32 byte challenge.
4805 cipher_specs
4806 This is a list of all CipherSpecs the client is willing and able
4807 to use. In addition to the 2.0 cipher specs defined in [SSL2],
4808 this includes the TLS cipher suites normally sent in
4809 ClientHello.cipher_suites, each cipher suite prefixed by a zero
4810 byte. For example, TLS cipher suite {0x00,0x0A} would be sent as
4811 {0x00,0x00,0x0A}.
4813 session_id
4814 This field MUST be empty.
4818 Dierks & Rescorla Standards Track [Page 86]
4819 \f
4820 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4823 challenge
4824 Corresponds to ClientHello.random. If the challenge length is less
4825 than 32, the TLS server will pad the data with leading (note: not
4826 trailing) zero bytes to make it 32 bytes long.
4828 Note: Requests to resume a TLS session MUST use a TLS client hello.
4830 E.3. Avoiding Man-in-the-Middle Version Rollback
4832 When TLS clients fall back to Version 2.0 compatibility mode, they
4833 MUST use special PKCS#1 block formatting. This is done so that TLS
4834 servers will reject Version 2.0 sessions with TLS-capable clients.
4836 When a client negotiates SSL 2.0 but also supports TLS, it MUST set
4837 the right-hand (least-significant) 8 random bytes of the PKCS padding
4838 (not including the terminal null of the padding) for the RSA
4839 encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
4840 to 0x03 (the other padding bytes are random).
4842 When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
4843 decrypting the ENCRYPTED-KEY-DATA field, check that these eight
4844 padding bytes are 0x03. If they are not, the server SHOULD generate a
4845 random value for SECRET-KEY-DATA, and continue the handshake (which
4846 will eventually fail since the keys will not match). Note that
4847 reporting the error situation to the client could make the server
4848 vulnerable to attacks described in [BLEI].
4874 Dierks & Rescorla Standards Track [Page 87]
4875 \f
4876 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4879 Appendix F. Security Analysis
4881 The TLS protocol is designed to establish a secure connection between
4882 a client and a server communicating over an insecure channel. This
4883 document makes several traditional assumptions, including that
4884 attackers have substantial computational resources and cannot obtain
4885 secret information from sources outside the protocol. Attackers are
4886 assumed to have the ability to capture, modify, delete, replay, and
4887 otherwise tamper with messages sent over the communication channel.
4888 This appendix outlines how TLS has been designed to resist a variety
4889 of attacks.
4891 F.1. Handshake Protocol
4893 The handshake protocol is responsible for selecting a CipherSpec and
4894 generating a Master Secret, which together comprise the primary
4895 cryptographic parameters associated with a secure session. The
4896 handshake protocol can also optionally authenticate parties who have
4897 certificates signed by a trusted certificate authority.
4899 F.1.1. Authentication and Key Exchange
4901 TLS supports three authentication modes: authentication of both
4902 parties, server authentication with an unauthenticated client, and
4903 total anonymity. Whenever the server is authenticated, the channel is
4904 secure against man-in-the-middle attacks, but completely anonymous
4905 sessions are inherently vulnerable to such attacks. Anonymous
4906 servers cannot authenticate clients. If the server is authenticated,
4907 its certificate message must provide a valid certificate chain
4908 leading to an acceptable certificate authority. Similarly,
4909 authenticated clients must supply an acceptable certificate to the
4910 server. Each party is responsible for verifying that the other's
4911 certificate is valid and has not expired or been revoked.
4913 The general goal of the key exchange process is to create a
4914 pre_master_secret known to the communicating parties and not to
4915 attackers. The pre_master_secret will be used to generate the
4916 master_secret (see Section 8.1). The master_secret is required to
4917 generate the finished messages, encryption keys, and MAC keys (see
4918 Sections 7.4.9 and 6.3). By sending a correct finished message,
4919 parties thus prove that they know the correct pre_master_secret.
4921 F.1.1.1. Anonymous Key Exchange
4923 Completely anonymous sessions can be established using Diffie-Hellman
4924 for key exchange. The server's public parameters are contained in the
4925 server key exchange message and the client's are sent in the client
4926 key exchange message. Eavesdroppers who do not know the private
4930 Dierks & Rescorla Standards Track [Page 88]
4931 \f
4932 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4935 values should not be able to find the Diffie-Hellman result (i.e. the
4936 pre_master_secret).
4938 Warning: Completely anonymous connections only provide protection
4939 against passive eavesdropping. Unless an independent tamper-proof
4940 channel is used to verify that the finished messages were not
4941 replaced by an attacker, server authentication is required in
4942 environments where active man-in-the-middle attacks are a concern.
4944 F.1.1.2. RSA Key Exchange and Authentication
4946 With RSA, key exchange and server authentication are combined. The
4947 public key is contained in the server's certificate. Note that
4948 compromise of the server's static RSA key results in a loss of
4949 confidentiality for all sessions protected under that static key. TLS
4950 users desiring Perfect Forward Secrecy should use DHE cipher suites.
4951 The damage done by exposure of a private key can be limited by
4952 changing one's private key (and certificate) frequently.
4954 After verifying the server's certificate, the client encrypts a
4955 pre_master_secret with the server's public key. By successfully
4956 decoding the pre_master_secret and producing a correct finished
4957 message, the server demonstrates that it knows the private key
4958 corresponding to the server certificate.
4960 When RSA is used for key exchange, clients are authenticated using
4961 the certificate verify message (see Section 7.4.8). The client signs
4962 a value derived from all preceding handshake messages. These
4963 handshake messages include the server certificate, which binds the
4964 signature to the server, and ServerHello.random, which binds the
4965 signature to the current handshake process.
4967 F.1.1.3. Diffie-Hellman Key Exchange with Authentication
4969 When Diffie-Hellman key exchange is used, the server can either
4970 supply a certificate containing fixed Diffie-Hellman parameters or
4971 use the server key exchange message to send a set of temporary
4972 Diffie-Hellman parameters signed with a DSA or RSA certificate.
4973 Temporary parameters are hashed with the hello.random values before
4974 signing to ensure that attackers do not replay old parameters. In
4975 either case, the client can verify the certificate or signature to
4976 ensure that the parameters belong to the server.
4978 If the client has a certificate containing fixed Diffie-Hellman
4979 parameters, its certificate contains the information required to
4980 complete the key exchange. Note that in this case the client and
4981 server will generate the same Diffie-Hellman result (i.e.,
4982 pre_master_secret) every time they communicate. To prevent the
4986 Dierks & Rescorla Standards Track [Page 89]
4987 \f
4988 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
4991 pre_master_secret from staying in memory any longer than necessary,
4992 it should be converted into the master_secret as soon as possible.
4993 Client Diffie-Hellman parameters must be compatible with those
4994 supplied by the server for the key exchange to work.
4996 If the client has a standard DSA or RSA certificate or is
4997 unauthenticated, it sends a set of temporary parameters to the server
4998 in the client key exchange message, then optionally uses a
4999 certificate verify message to authenticate itself.
5001 If the same DH keypair is to be used for multiple handshakes, either
5002 because the client or server has a certificate containing a fixed DH
5003 keypair or because the server is reusing DH keys, care must be taken
5004 to prevent small subgroup attacks. Implementations SHOULD follow the
5005 guidelines found in [SUBGROUP].
5007 Small subgroup attacks are most easily avoided by using one of the
5008 DHE cipher suites and generating a fresh DH private key (X) for each
5009 handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
5010 computed very quickly, therefore the performance cost is minimized.
5011 Additionally, using a fresh key for each handshake provides Perfect
5012 Forward Secrecy. Implementations SHOULD generate a new X for each
5013 handshake when using DHE cipher suites.
5015 Because TLS allows the server to provide arbitrary DH groups, the
5016 client should verify that the DH group is of suitable size as defined
5017 by local policy. The client SHOULD also verify that the DH public
5018 exponent appears to be of adequate size. [KEYSIZ] provides a useful
5019 guide to the strength of various group sizes. The server MAY choose
5020 to assist the client by providing a known group, such as those
5021 defined in [IKEALG] or [MODP]. These can be verified by simple
5022 comparison.
5024 F.1.2. Version Rollback Attacks
5026 Because TLS includes substantial improvements over SSL Version 2.0,
5027 attackers may try to make TLS-capable clients and servers fall back
5028 to Version 2.0. This attack can occur if (and only if) two TLS-
5029 capable parties use an SSL 2.0 handshake.
5031 Although the solution using non-random PKCS #1 block type 2 message
5032 padding is inelegant, it provides a reasonably secure way for Version
5033 3.0 servers to detect the attack. This solution is not secure against
5034 attackers who can brute force the key and substitute a new ENCRYPTED-
5035 KEY-DATA message containing the same key (but with normal padding)
5036 before the application specified wait threshold has expired. Altering
5037 the padding of the least significant 8 bytes of the PKCS padding does
5038 not impact security for the size of the signed hashes and RSA key
5042 Dierks & Rescorla Standards Track [Page 90]
5043 \f
5044 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
5047 lengths used in the protocol, since this is essentially equivalent to
5048 increasing the input block size by 8 bytes.
5050 F.1.3. Detecting Attacks Against the Handshake Protocol
5052 An attacker might try to influence the handshake exchange to make the
5053 parties select different encryption algorithms than they would
5054 normally chooses.
5056 For this attack, an attacker must actively change one or more
5057 handshake messages. If this occurs, the client and server will
5058 compute different values for the handshake message hashes. As a
5059 result, the parties will not accept each others' finished messages.
5060 Without the master_secret, the attacker cannot repair the finished
5061 messages, so the attack will be discovered.
5063 F.1.4. Resuming Sessions
5065 When a connection is established by resuming a session, new
5066 ClientHello.random and ServerHello.random values are hashed with the
5067 session's master_secret. Provided that the master_secret has not been
5068 compromised and that the secure hash operations used to produce the
5069 encryption keys and MAC keys are secure, the connection should be
5070 secure and effectively independent from previous connections.
5071 Attackers cannot use known encryption keys or MAC secrets to
5072 compromise the master_secret without breaking the secure hash
5073 operations.
5075 Sessions cannot be resumed unless both the client and server agree.
5076 If either party suspects that the session may have been compromised,
5077 or that certificates may have expired or been revoked, it should
5078 force a full handshake. An upper limit of 24 hours is suggested for
5079 session ID lifetimes, since an attacker who obtains a master_secret
5080 may be able to impersonate the compromised party until the
5081 corresponding session ID is retired. Applications that may be run in
5082 relatively insecure environments should not write session IDs to
5083 stable storage.
5085 F.2. Protecting Application Data
5087 The master_secret is hashed with the ClientHello.random and
5088 ServerHello.random to produce unique data encryption keys and MAC
5089 secrets for each connection.
5091 Outgoing data is protected with a MAC before transmission. To prevent
5092 message replay or modification attacks, the MAC is computed from the
5093 MAC key, the sequence number, the message length, the message
5094 contents, and two fixed character strings. The message type field is
5098 Dierks & Rescorla Standards Track [Page 91]
5099 \f
5100 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
5103 necessary to ensure that messages intended for one TLS Record Layer
5104 client are not redirected to another. The sequence number ensures
5105 that attempts to delete or reorder messages will be detected. Since
5106 sequence numbers are 64 bits long, they should never overflow.
5107 Messages from one party cannot be inserted into the other's output,
5108 since they use independent MAC keys. Similarly, the server-write and
5109 client-write keys are independent, so stream cipher keys are used
5110 only once.
5112 If an attacker does break an encryption key, all messages encrypted
5113 with it can be read. Similarly, compromise of a MAC key can make
5114 message modification attacks possible. Because MACs are also
5115 encrypted, message-alteration attacks generally require breaking the
5116 encryption algorithm as well as the MAC.
5118 Note: MAC keys may be larger than encryption keys, so messages can
5119 remain tamper resistant even if encryption keys are broken.
5121 F.3. Explicit IVs
5123 [CBCATT] describes a chosen plaintext attack on TLS that depends on
5124 knowing the IV for a record. Previous versions of TLS [TLS1.0] used
5125 the CBC residue of the previous record as the IV and therefore
5126 enabled this attack. This version uses an explicit IV in order to
5127 protect against this attack.
5129 F.4. Security of Composite Cipher Modes
5131 TLS secures transmitted application data via the use of symmetric
5132 encryption and authentication functions defined in the negotiated
5133 cipher suite. The objective is to protect both the integrity and
5134 confidentiality of the transmitted data from malicious actions by
5135 active attackers in the network. It turns out that the order in
5136 which encryption and authentication functions are applied to the data
5137 plays an important role for achieving this goal [ENCAUTH].
5139 The most robust method, called encrypt-then-authenticate, first
5140 applies encryption to the data and then applies a MAC to the
5141 ciphertext. This method ensures that the integrity and
5142 confidentiality goals are obtained with ANY pair of encryption and
5143 MAC functions, provided that the former is secure against chosen
5144 plaintext attacks and that the MAC is secure against chosen-message
5145 attacks. TLS uses another method, called authenticate-then-encrypt,
5146 in which first a MAC is computed on the plaintext and then the
5147 concatenation of plaintext and MAC is encrypted. This method has
5148 been proven secure for CERTAIN combinations of encryption functions
5149 and MAC functions, but it is not guaranteed to be secure in general.
5150 In particular, it has been shown that there exist perfectly secure
5154 Dierks & Rescorla Standards Track [Page 92]
5155 \f
5156 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
5159 encryption functions (secure even in the information-theoretic sense)
5160 that combined with any secure MAC function, fail to provide the
5161 confidentiality goal against an active attack. Therefore, new cipher
5162 suites and operation modes adopted into TLS need to be analyzed under
5163 the authenticate-then-encrypt method to verify that they achieve the
5164 stated integrity and confidentiality goals.
5166 Currently, the security of the authenticate-then-encrypt method has
5167 been proven for some important cases. One is the case of stream
5168 ciphers in which a computationally unpredictable pad of the length of
5169 the message, plus the length of the MAC tag, is produced using a
5170 pseudo-random generator and this pad is xor-ed with the concatenation
5171 of plaintext and MAC tag. The other is the case of CBC mode using a
5172 secure block cipher. In this case, security can be shown if one
5173 applies one CBC encryption pass to the concatenation of plaintext and
5174 MAC and uses a new, independent, and unpredictable IV for each new
5175 pair of plaintext and MAC. In versions of TLS prior to 1.1, CBC mode
5176 was used properly EXCEPT that it used a predictable IV in the form of
5177 the last block of the previous ciphertext. This made TLS open to
5178 chosen plaintext attacks. This version of the protocol is immune to
5179 those attacks. For exact details in the encryption modes proven
5180 secure, see [ENCAUTH].
5182 F.5 Denial of Service
5184 TLS is susceptible to a number of denial of service (DoS) attacks.
5185 In particular, an attacker who initiates a large number of TCP
5186 connections can cause a server to consume large amounts of CPU doing
5187 RSA decryption. However, because TLS is generally used over TCP, it
5188 is difficult for the attacker to hide his point of origin if proper
5189 TCP SYN randomization is used [SEQNUM] by the TCP stack.
5191 Because TLS runs over TCP, it is also susceptible to a number of
5192 denial of service attacks on individual connections. In particular,
5193 attackers can forge RSTs, thereby terminating connections, or forge
5194 partial TLS records, thereby causing the connection to stall. These
5195 attacks cannot in general be defended against by a TCP-using
5196 protocol. Implementors or users who are concerned with this class of
5197 attack should use IPsec AH [AH] or ESP [ESP].
5199 F.6 Final Notes
5201 For TLS to be able to provide a secure connection, both the client
5202 and server systems, keys, and applications must be secure. In
5203 addition, the implementation must be free of security errors.
5205 The system is only as strong as the weakest key exchange and
5206 authentication algorithm supported, and only trustworthy
5210 Dierks & Rescorla Standards Track [Page 93]
5211 \f
5212 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
5215 cryptographic functions should be used. Short public keys and
5216 anonymous servers should be used with great caution. Implementations
5217 and users must be careful when deciding which certificates and
5218 certificate authorities are acceptable; a dishonest certificate
5219 authority can do tremendous damage.
5221 Changes in This Version
5222 [RFC Editor: Please delete this]
5224 Clarified traffic analysis considerations
5226 Added support for SHA-224 for signatures (though not for HMAC).
5228 Consistent use of camelback style for references to messages (e.g.,
5229 ServerHelloDone) in the text.
5231 Changed "DSS" to "DSA" where we are referring to the algorithm.
5233 Extensive editorial revisions from Alfred Hoenes.
5235 Normative References
5237 [AES] National Institute of Standards and Technology,
5238 "Specification for the Advanced Encryption Standard (AES)"
5239 FIPS 197. November 26, 2001.
5241 [3DES] National Institute of Standards and Technology,
5242 "Recommendation for the Triple Data Encryption Algorithm
5243 (TDEA) Block Cipher", NIST Special Publication 800-67, May
5244 2004.
5246 [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard", National
5247 Institute of Standards and Technology, U.S. Department of
5248 Commerce, 2000.
5250 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
5251 Hashing for Message Authentication", RFC 2104, February
5252 1997.
5254 [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
5255 April 1992.
5257 [PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
5258 (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
5259 3447, February 2003.
5261 [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
5262 Public Key Infrastructure Certificate and Certificate
5266 Dierks & Rescorla Standards Track [Page 94]
5267 \f
5268 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
5271 Revocation List (CRL) Profile", RFC 3280, April 2002.
5274 [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
5275 and Source Code in C, 2nd ed.", Published by John Wiley &
5276 Sons, Inc. 1996.
5278 [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National
5279 Institute of Standards and Technology, U.S. Department of
5280 Commerce, August 2002.
5282 [REQ] Bradner, S., "Key words for use in RFCs to Indicate
5283 Requirement Levels", BCP 14, RFC 2119, March 1997.
5285 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
5286 IANA Considerations Section in RFCs", BCP 25, RFC 2434,
5287 October 1998.
5289 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
5290 Information technology - Abstract Syntax Notation One
5291 (ASN.1): Specification of basic notation.
5293 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
5294 Information technology - ASN.1 encoding Rules: Specification
5295 of Basic Encoding Rules (BER), Canonical Encoding Rules
5296 (CER) and Distinguished Encoding Rules (DER).
5298 Informative References
5300 [AEAD] Mcgrew, D., "An Interface and Algorithms for Authenticated
5301 Encryption", RFC 5116, January 2008.
5303 [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC
5304 4302, December 2005.
5306 [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
5307 Protocols Based on RSA Encryption Standard PKCS #1" in
5308 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
5309 1-12, 1998.
5311 [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
5312 Problems and Countermeasures",
5313 http://www.openssl.org/~bodo/tls-cbc.txt.
5315 [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
5316 "Password Interception in a SSL/TLS Channel", Advances in
5317 Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
5322 Dierks & Rescorla Standards Track [Page 95]
5323 \f
5324 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
5327 [CCM] "NIST Special Publication 800-38C: The CCM Mode for
5328 Authentication and Confidentiality",
5329 http://csrc.nist.gov/publications/nistpubs/800-38C/
5330 SP800-38C.pdf
5332 [DES] National Institute of Standards and Technology, "Data
5333 Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
5335 [DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard",
5336 National Institute of Standards and Technology, U.S.
5337 Department of Commerce, 2006.
5339 [ECSDSA] American National Standards Institute, "Public Key
5340 Cryptography for the Financial Services Industry: The
5341 Elliptic Curve Digital Signature Algorithm (ECDSA)", ANS
5342 X9.62-2005, November 2005.
5344 [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
5345 for Protecting Communications (Or: How Secure is SSL?)",
5346 Crypto 2001.
5348 [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
5349 Payload (ESP)", RFC 4303, December 2005.
5351 [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on
5352 implementation error", ietf-openpgp@imc.org mailing list, 27
5353 August 2006, http://www.imc.org/ietf-openpgp/mail-
5354 archive/msg14307.html.
5356 [GCM] "NIST Special Publication 800-38D DRAFT (June, 2007):
5357 Recommendation for Block Cipher Modes of Operation:
5358 Galois/Counter Mode (GCM) and GMAC"
5360 [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
5361 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December
5362 2005.
5364 [KEYSIZ] Orman, H., and Hoffman, P., "Determining Strengths For
5365 Public Keys Used For Exchanging Symmetric Keys" RFC 3766,
5366 April 2004.
5368 [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
5369 Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
5370 March 2003.
5372 [MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
5373 Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
5374 3526, May 2003.
5378 Dierks & Rescorla Standards Track [Page 96]
5379 \f
5380 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
5383 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
5384 Standard", version 1.5, November 1993.
5386 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
5387 Standard", version 1.5, November 1993.
5389 [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
5390 Requirements for Security", BCP 106, RFC 4086, June 2005.
5392 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
5393 Compression Methods", RFC 3749, May 2004.
5395 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
5396 Wright, T., "Transport Layer Security (TLS) Extensions", RFC
5397 4366, April 2006.
5399 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
5400 Obtaining Digital Signatures and Public-Key Cryptosystems",
5401 Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
5402 120-126.
5404 [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
5405 RFC 1948, May 1996.
5407 [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
5408 Corp., Feb 9, 1995.
5410 [SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
5411 Protocol", Netscape Communications Corp., Nov 18, 1996.
5413 [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
5414 Attacks on the Diffie-Hellman Key Agreement Method for
5415 S/MIME", RFC 2785, March 2000.
5417 [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
5418 September 1981.
5420 [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
5421 practical", USENIX Security Symposium 2003.
5423 [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
5424 for Transport Layer Security (TLS)", RFC 3268, June 2002.
5426 [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
5427 Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
5428 Suites for Transport Layer Security (TLS)", RFC 4492, May
5429 2006.
5434 Dierks & Rescorla Standards Track [Page 97]
5435 \f
5436 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
5439 [TLSEXT] Eastlake, D.E., "Transport Layer Security (TLS) Extensions:
5440 Extension Definitions", January 2008, draft-ietf-tls-
5441 rfc4366-bis-01.txt.
5443 [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS
5444 authentication", RFC 5081, November 2007.
5446 [TLSPSK] Eronen, P., Tschofenig, H., "Pre-Shared Key Ciphersuites for
5447 Transport Layer Security (TLS)", RFC 4279, December 2005.
5449 [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
5450 RFC 2246, January 1999.
5452 [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version
5453 1.1", RFC 4346, April, 2006.
5455 [X501] ITU-T Recommendation X.501: Information Technology - Open
5456 Systems Interconnection - The Directory: Models, 1993.
5458 [XDR] Eisler, M., "External Data Representation Standard", STD 67,
5459 RFC 4506, May 2006.
5461 Credits
5463 Working Group Chairs
5465 Eric Rescorla
5466 EMail: ekr@networkresonance.com
5468 Pasi Eronen
5469 pasi.eronen@nokia.com
5472 Editors
5474 Tim Dierks Eric Rescorla
5475 Independent Network Resonance, Inc.
5476 EMail: tim@dierks.org EMail: ekr@networkresonance.com
5479 Other contributors
5481 Christopher Allen (co-editor of TLS 1.0)
5482 Alacrity Ventures
5483 ChristopherA@AlacrityManagement.com
5485 Martin Abadi
5486 University of California, Santa Cruz
5490 Dierks & Rescorla Standards Track [Page 98]
5491 \f
5492 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
5495 abadi@cs.ucsc.edu
5497 Steven M. Bellovin
5498 Columbia University
5499 smb@cs.columbia.edu
5501 Simon Blake-Wilson
5502 BCI
5503 EMail: sblakewilson@bcisse.com
5505 Ran Canetti
5506 IBM
5507 canetti@watson.ibm.com
5509 Pete Chown
5510 Skygate Technology Ltd
5511 pc@skygate.co.uk
5513 Taher Elgamal
5514 taher@securify.com
5515 Securify
5517 Pasi Eronen
5518 pasi.eronen@nokia.com
5519 Nokia
5521 Anil Gangolli
5522 anil@busybuddha.org
5524 Kipp Hickman
5526 Alfred Hoenes
5528 David Hopwood
5529 Independent Consultant
5530 EMail: david.hopwood@blueyonder.co.uk
5532 Phil Karlton (co-author of SSLv3)
5534 Paul Kocher (co-author of SSLv3)
5535 Cryptography Research
5536 paul@cryptography.com
5538 Hugo Krawczyk
5539 IBM
5540 hugo@ee.technion.ac.il
5542 Jan Mikkelsen
5546 Dierks & Rescorla Standards Track [Page 99]
5547 \f
5548 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
5551 Transactionware
5552 EMail: janm@transactionware.com
5554 Magnus Nystrom
5555 RSA Security
5556 EMail: magnus@rsasecurity.com
5558 Robert Relyea
5559 Netscape Communications
5560 relyea@netscape.com
5562 Jim Roskind
5563 Netscape Communications
5564 jar@netscape.com
5566 Michael Sabin
5568 Dan Simon
5569 Microsoft, Inc.
5570 dansimon@microsoft.com
5572 Tom Weinstein
5574 Tim Wright
5575 Vodafone
5576 EMail: timothy.wright@vodafone.com
5578 Comments
5580 The discussion list for the IETF TLS working group is located at the
5581 e-mail address <tls@ietf.org>. Information on the group and
5582 information on how to subscribe to the list is at
5583 <https://www1.ietf.org/mailman/listinfo/tls>
5585 Archives of the list can be found at:
5586 <http://www.ietf.org/mail-archive/web/tls/current/index.html>
5602 Dierks & Rescorla Standards Track [Page 100]
5603 \f
5604 draft-ietf-tls-rfc4346-bis-10.txt TLS March, 2008
5607 Full Copyright Statement
5609 Copyright (C) The IETF Trust (2008).
5611 This document is subject to the rights, licenses and restrictions
5612 contained in BCP 78, and except as set forth therein, the authors
5613 retain all their rights.
5615 This document and the information contained herein are provided on an
5616 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
5617 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
5618 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
5619 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
5620 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
5621 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5624 Intellectual Property
5626 The IETF takes no position regarding the validity or scope of any
5627 Intellectual Property Rights or other rights that might be claimed to
5628 pertain to the implementation or use of the technology described in
5629 this document or the extent to which any license under such rights
5630 might or might not be available; nor does it represent that it has
5631 made any independent effort to identify any such rights. Information
5632 on the procedures with respect to rights in RFC documents can be
5633 found in BCP 78 and BCP 79.
5635 Copies of IPR disclosures made to the IETF Secretariat and any
5636 assurances of licenses to be made available, or the result of an
5637 attempt made to obtain a general license or permission for the use of
5638 such proprietary rights by implementers or users of this
5639 specification can be obtained from the IETF on-line IPR repository at
5640 http://www.ietf.org/ipr.
5642 The IETF invites any interested party to bring to its attention any
5643 copyrights, patents or patent applications, or other proprietary
5644 rights that may cover technology that may be required to implement
5645 this standard. Please address the information to the IETF at
5646 ietf-ipr@ietf.org.
5649 Acknowledgment
5651 Funding for the RFC Editor function is provided by the IETF
5652 Administrative Support Activity (IASA).
5658 Dierks & Rescorla Standards Track [Page 101]
5659 \f