| blob | 869c345054615778644e9e6354fa2dc0396a7161 |
7 Network Working Group T. Dierks
8 Request for Comments: 5246 Independent
9 Obsoletes: 3268, 4346, 4366 E. Rescorla
10 Updates: 4492 RTFM, Inc.
11 Category: Standards Track August 2008
14 The Transport Layer Security (TLS) Protocol
15 Version 1.2
17 Status of This Memo
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
25 Abstract
27 This document specifies Version 1.2 of the Transport Layer Security
28 (TLS) protocol. The TLS protocol provides communications security
29 over the Internet. The protocol allows client/server applications to
30 communicate in a way that is designed to prevent eavesdropping,
31 tampering, or message forgery.
33 Table of Contents
35 1. Introduction ....................................................4
36 1.1. Requirements Terminology ...................................5
37 1.2. Major Differences from TLS 1.1 .............................5
38 2. Goals ...........................................................6
39 3. Goals of This Document ..........................................7
40 4. Presentation Language ...........................................7
41 4.1. Basic Block Size ...........................................7
42 4.2. Miscellaneous ..............................................8
43 4.3. Vectors ....................................................8
44 4.4. Numbers ....................................................9
45 4.5. Enumerateds ................................................9
46 4.6. Constructed Types .........................................10
47 4.6.1. Variants ...........................................10
48 4.7. Cryptographic Attributes ..................................12
49 4.8. Constants .................................................14
50 5. HMAC and the Pseudorandom Function .............................14
51 6. The TLS Record Protocol ........................................15
52 6.1. Connection States .........................................16
53 6.2. Record Layer ..............................................19
54 6.2.1. Fragmentation ......................................19
58 Dierks & Rescorla Standards Track [Page 1]
59 \f
60 RFC 5246 TLS August 2008
63 6.2.2. Record Compression and Decompression ...............20
64 6.2.3. Record Payload Protection ..........................21
65 6.2.3.1. Null or Standard Stream Cipher ............22
66 6.2.3.2. CBC Block Cipher ..........................22
67 6.2.3.3. AEAD Ciphers ..............................24
68 6.3. Key Calculation ...........................................25
69 7. The TLS Handshaking Protocols ..................................26
70 7.1. Change Cipher Spec Protocol ...............................27
71 7.2. Alert Protocol ............................................28
72 7.2.1. Closure Alerts .....................................29
73 7.2.2. Error Alerts .......................................30
74 7.3. Handshake Protocol Overview ...............................33
75 7.4. Handshake Protocol ........................................37
76 7.4.1. Hello Messages .....................................38
77 7.4.1.1. Hello Request .............................38
78 7.4.1.2. Client Hello ..............................39
79 7.4.1.3. Server Hello ..............................42
80 7.4.1.4. Hello Extensions ..........................44
81 7.4.1.4.1. Signature Algorithms ...........45
82 7.4.2. Server Certificate .................................47
83 7.4.3. Server Key Exchange Message ........................50
84 7.4.4. Certificate Request ................................53
85 7.4.5. Server Hello Done ..................................55
86 7.4.6. Client Certificate .................................55
87 7.4.7. Client Key Exchange Message ........................57
88 7.4.7.1. RSA-Encrypted Premaster Secret Message ....58
89 7.4.7.2. Client Diffie-Hellman Public Value ........61
90 7.4.8. Certificate Verify .................................62
91 7.4.9. Finished ...........................................63
92 8. Cryptographic Computations .....................................64
93 8.1. Computing the Master Secret ...............................64
94 8.1.1. RSA ................................................65
95 8.1.2. Diffie-Hellman .....................................65
96 9. Mandatory Cipher Suites ........................................65
97 10. Application Data Protocol .....................................65
98 11. Security Considerations .......................................65
99 12. IANA Considerations ...........................................65
100 Appendix A. Protocol Data Structures and Constant Values ..........68
101 A.1. Record Layer ..............................................68
102 A.2. Change Cipher Specs Message ...............................69
103 A.3. Alert Messages ............................................69
104 A.4. Handshake Protocol ........................................70
105 A.4.1. Hello Messages .....................................71
106 A.4.2. Server Authentication and Key Exchange Messages ....72
107 A.4.3. Client Authentication and Key Exchange Messages ....74
108 A.4.4. Handshake Finalization Message .....................74
109 A.5. The Cipher Suite ..........................................75
110 A.6. The Security Parameters ...................................77
114 Dierks & Rescorla Standards Track [Page 2]
115 \f
116 RFC 5246 TLS August 2008
119 A.7. Changes to RFC 4492 .......................................78
120 Appendix B. Glossary ..............................................78
121 Appendix C. Cipher Suite Definitions ..............................83
122 Appendix D. Implementation Notes ..................................85
123 D.1. Random Number Generation and Seeding ......................85
124 D.2. Certificates and Authentication ...........................85
125 D.3. Cipher Suites .............................................85
126 D.4. Implementation Pitfalls ...................................85
127 Appendix E. Backward Compatibility ................................87
128 E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 ................87
129 E.2. Compatibility with SSL 2.0 ................................88
130 E.3. Avoiding Man-in-the-Middle Version Rollback ...............90
131 Appendix F. Security Analysis .....................................91
132 F.1. Handshake Protocol ........................................91
133 F.1.1. Authentication and Key Exchange ....................91
134 F.1.1.1. Anonymous Key Exchange ....................91
135 F.1.1.2. RSA Key Exchange and Authentication .......92
136 F.1.1.3. Diffie-Hellman Key Exchange with
137 Authentication ............................92
138 F.1.2. Version Rollback Attacks ...........................93
139 F.1.3. Detecting Attacks Against the Handshake Protocol ...94
140 F.1.4. Resuming Sessions ..................................94
141 F.2. Protecting Application Data ...............................94
142 F.3. Explicit IVs ..............................................95
143 F.4. Security of Composite Cipher Modes ........................95
144 F.5. Denial of Service .........................................96
145 F.6. Final Notes ...............................................96
146 Normative References ..............................................97
147 Informative References ............................................98
148 Working Group Information ........................................101
149 Contributors .....................................................101
170 Dierks & Rescorla Standards Track [Page 3]
171 \f
172 RFC 5246 TLS August 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.
182 The TLS Record Protocol provides connection security that has two
183 basic 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
190 Protocol 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.
226 Dierks & Rescorla Standards Track [Page 4]
227 \f
228 RFC 5246 TLS August 2008
231 One advantage of TLS is that it is application protocol independent.
232 Higher-level protocols can layer on top of the TLS protocol
233 transparently. The TLS standard, however, does not specify how
234 protocols add security with TLS; the decisions on how to initiate TLS
235 handshaking and how to interpret the authentication certificates
236 exchanged are left to the judgment of the designers and implementors
237 of protocols that run on top of TLS.
239 1.1. Requirements Terminology
241 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
242 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
243 document are to be interpreted as described in RFC 2119 [REQ].
245 1.2. Major Differences from TLS 1.1
247 This document is a revision of the TLS 1.1 [TLS1.1] protocol which
248 contains improved flexibility, particularly for negotiation of
249 cryptographic algorithms. The major changes are:
251 - The MD5/SHA-1 combination in the pseudorandom function (PRF) has
252 been replaced with cipher-suite-specified PRFs. All cipher suites
253 in this document use P_SHA256.
255 - The MD5/SHA-1 combination in the digitally-signed element has been
256 replaced with a single hash. Signed elements now include a field
257 that explicitly specifies the hash algorithm used.
259 - Substantial cleanup to the client's and server's ability to
260 specify which hash and signature algorithms they will accept.
261 Note that this also relaxes some of the constraints on signature
262 and hash algorithms from previous versions of TLS.
264 - Addition of support for authenticated encryption with additional
265 data modes.
267 - TLS Extensions definition and AES Cipher Suites were merged in
268 from external [TLSEXT] and [TLSAES].
270 - Tighter checking of EncryptedPreMasterSecret version numbers.
272 - Tightened up a number of requirements.
274 - Verify_data length now depends on the cipher suite (default is
275 still 12).
277 - Cleaned up description of Bleichenbacher/Klima attack defenses.
282 Dierks & Rescorla Standards Track [Page 5]
283 \f
284 RFC 5246 TLS August 2008
287 - Alerts MUST now be sent in many cases.
289 - After a certificate_request, if no certificates are available,
290 clients now MUST send an empty certificate list.
292 - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
293 cipher suite.
295 - Added HMAC-SHA256 cipher suites.
297 - Removed IDEA and DES cipher suites. They are now deprecated and
298 will be documented in a separate document.
300 - Support for the SSLv2 backward-compatible hello is now a MAY, not
301 a SHOULD, with sending it a SHOULD NOT. Support will probably
302 become a SHOULD NOT in the future.
304 - Added limited "fall-through" to the presentation language to allow
305 multiple case arms to have the same encoding.
307 - Added an Implementation Pitfalls sections
309 - The usual clarifications and editorial work.
311 2. Goals
313 The goals of the TLS protocol, in order of priority, are as follows:
315 1. Cryptographic security: TLS should be used to establish a secure
316 connection between two parties.
318 2. Interoperability: Independent programmers should be able to
319 develop applications utilizing TLS that can successfully exchange
320 cryptographic parameters without knowledge of one another's code.
322 3. Extensibility: TLS seeks to provide a framework into which new
323 public key and bulk encryption methods can be incorporated as
324 necessary. This will also accomplish two sub-goals: preventing
325 the need to create a new protocol (and risking the introduction of
326 possible new weaknesses) and avoiding the need to implement an
327 entire new security library.
329 4. Relative efficiency: Cryptographic operations tend to be highly
330 CPU intensive, particularly public key operations. For this
331 reason, the TLS protocol has incorporated an optional session
332 caching scheme to reduce the number of connections that need to be
333 established from scratch. Additionally, care has been taken to
334 reduce network activity.
338 Dierks & Rescorla Standards Track [Page 6]
339 \f
340 RFC 5246 TLS August 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.
364 4. Presentation Language
366 This document deals with the formatting of data in an external
367 representation. The following very basic and somewhat casually
368 defined presentation syntax will be used. The syntax draws from
369 several sources in its structure. Although it resembles the
370 programming language "C" in its syntax and XDR [XDR] in both its
371 syntax and intent, it would be risky to draw too many parallels. The
372 purpose of this presentation language is to document TLS only; it has
373 no general application beyond that particular goal.
375 4.1. Basic Block Size
377 The representation of all data items is explicitly specified. The
378 basic data block size is one byte (i.e., 8 bits). Multiple byte data
379 items are concatenations of bytes, from left to right, from top to
380 bottom. From the byte stream, a multi-byte item (a numeric in the
381 example) is formed (using C notation) by:
383 value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
384 ... | byte[n-1];
386 This byte ordering for multi-byte values is the commonplace network
387 byte order or big-endian format.
394 Dierks & Rescorla Standards Track [Page 7]
395 \f
396 RFC 5246 TLS August 2008
399 4.2. Miscellaneous
401 Comments begin with "/*" and end with "*/".
403 Optional components are denoted by enclosing them in "[[ ]]" double
404 brackets.
406 Single-byte entities containing uninterpreted data are of type
407 opaque.
409 4.3. Vectors
411 A vector (single-dimensioned array) is a stream of homogeneous data
412 elements. The size of the vector may be specified at documentation
413 time or left unspecified until runtime. In either case, the length
414 declares the number of bytes, not the number of elements, in the
415 vector. The syntax for specifying a new type, T', that is a fixed-
416 length vector of type T is
418 T T'[n];
420 Here, T' occupies n bytes in the data stream, where n is a multiple
421 of the size of T. The length of the vector is not included in the
422 encoded stream.
424 In the following example, Datum is defined to be three consecutive
425 bytes that the protocol does not interpret, while Data is three
426 consecutive Datum, consuming a total of nine bytes.
428 opaque Datum[3]; /* three uninterpreted bytes */
429 Datum Data[9]; /* 3 consecutive 3 byte vectors */
431 Variable-length vectors are defined by specifying a subrange of legal
432 lengths, inclusively, using the notation <floor..ceiling>. When
433 these are encoded, the actual length precedes the vector's contents
434 in the byte stream. The length will be in the form of a number
435 consuming as many bytes as required to hold the vector's specified
436 maximum (ceiling) length. A variable-length vector with an actual
437 length field of zero is referred to as an empty vector.
439 T T'<floor..ceiling>;
441 In the following example, mandatory is a vector that must contain
442 between 300 and 400 bytes of type opaque. It can never be empty.
443 The actual length field consumes two bytes, a uint16, which is
444 sufficient to represent the value 400 (see Section 4.4). On the
445 other hand, longer can represent up to 800 bytes of data, or 400
446 uint16 elements, and it may be empty. Its encoding will include a
450 Dierks & Rescorla Standards Track [Page 8]
451 \f
452 RFC 5246 TLS August 2008
455 two-byte actual length field prepended to the vector. The length of
456 an encoded vector must be an even multiple of the length of a single
457 element (for example, a 17-byte vector of uint16 would be illegal).
459 opaque mandatory<300..400>;
460 /* length field is 2 bytes, cannot be empty */
461 uint16 longer<0..800>;
462 /* zero to 400 16-bit unsigned integers */
464 4.4. Numbers
466 The basic numeric data type is an unsigned byte (uint8). All larger
467 numeric data types are formed from fixed-length series of bytes
468 concatenated as described in Section 4.1 and are also unsigned. The
469 following numeric types are predefined.
471 uint8 uint16[2];
472 uint8 uint24[3];
473 uint8 uint32[4];
474 uint8 uint64[8];
476 All values, here and elsewhere in the specification, are stored in
477 network byte (big-endian) order; the uint32 represented by the hex
478 bytes 01 02 03 04 is equivalent to the decimal value 16909060.
480 Note that in some cases (e.g., DH parameters) it is necessary to
481 represent integers as opaque vectors. In such cases, they are
482 represented as unsigned integers (i.e., leading zero octets are not
483 required even if the most significant bit is set).
485 4.5. Enumerateds
487 An additional sparse data type is available called enum. A field of
488 type enum can only assume the values declared in the definition.
489 Each definition is a different type. Only enumerateds of the same
490 type may be assigned or compared. Every element of an enumerated
491 must be assigned a value, as demonstrated in the following example.
492 Since the elements of the enumerated are not ordered, they can be
493 assigned any unique value, in any order.
495 enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
497 An enumerated occupies as much space in the byte stream as would its
498 maximal defined ordinal value. The following definition would cause
499 one byte to be used to carry fields of type Color.
501 enum { red(3), blue(5), white(7) } Color;
506 Dierks & Rescorla Standards Track [Page 9]
507 \f
508 RFC 5246 TLS August 2008
511 One may optionally specify a value without its associated tag to
512 force the width definition without defining a superfluous element.
514 In the following example, Taste will consume two bytes in the data
515 stream but can only assume the values 1, 2, or 4.
517 enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
519 The names of the elements of an enumeration are scoped within the
520 defined type. In the first example, a fully qualified reference to
521 the second element of the enumeration would be Color.blue. Such
522 qualification is not required if the target of the assignment is well
523 specified.
525 Color color = Color.blue; /* overspecified, legal */
526 Color color = blue; /* correct, type implicit */
528 For enumerateds that are never converted to external representation,
529 the numerical information may be omitted.
531 enum { low, medium, high } Amount;
533 4.6. Constructed Types
535 Structure types may be constructed from primitive types for
536 convenience. Each specification declares a new, unique type. The
537 syntax for definition is much like that of C.
539 struct {
540 T1 f1;
541 T2 f2;
542 ...
543 Tn fn;
544 } [[T]];
546 The fields within a structure may be qualified using the type's name,
547 with a syntax much like that available for enumerateds. For example,
548 T.f2 refers to the second field of the previous declaration.
549 Structure definitions may be embedded.
551 4.6.1. Variants
553 Defined structures may have variants based on some knowledge that is
554 available within the environment. The selector must be an enumerated
555 type that defines the possible variants the structure defines. There
556 must be a case arm for every element of the enumeration declared in
557 the select. Case arms have limited fall-through: if two case arms
558 follow in immediate succession with no fields in between, then they
562 Dierks & Rescorla Standards Track [Page 10]
563 \f
564 RFC 5246 TLS August 2008
567 both contain the same fields. Thus, in the example below, "orange"
568 and "banana" both contain V2. Note that this is a new piece of
569 syntax in TLS 1.2.
571 The body of the variant structure may be given a label for reference.
572 The mechanism by which the variant is selected at runtime is not
573 prescribed by the presentation language.
575 struct {
576 T1 f1;
577 T2 f2;
578 ....
579 Tn fn;
580 select (E) {
581 case e1: Te1;
582 case e2: Te2;
583 case e3: case e4: Te3;
584 ....
585 case en: Ten;
586 } [[fv]];
587 } [[Tv]];
589 For example:
591 enum { apple, orange, banana } VariantTag;
593 struct {
594 uint16 number;
595 opaque string<0..10>; /* variable length */
596 } V1;
598 struct {
599 uint32 number;
600 opaque string[10]; /* fixed length */
601 } V2;
603 struct {
604 select (VariantTag) { /* value of selector is implicit */
605 case apple:
606 V1; /* VariantBody, tag = apple */
607 case orange:
608 case banana:
609 V2; /* VariantBody, tag = orange or banana */
610 } variant_body; /* optional label on variant */
611 } VariantRecord;
618 Dierks & Rescorla Standards Track [Page 11]
619 \f
620 RFC 5246 TLS August 2008
623 4.7. Cryptographic Attributes
625 The five cryptographic operations -- digital signing, stream cipher
626 encryption, block cipher encryption, authenticated encryption with
627 additional data (AEAD) encryption, and public key encryption -- are
628 designated digitally-signed, stream-ciphered, block-ciphered, aead-
629 ciphered, and public-key-encrypted, respectively. A field's
630 cryptographic processing is specified by prepending an appropriate
631 key word designation before the field's type specification.
632 Cryptographic keys are implied by the current session state (see
633 Section 6.1).
635 A digitally-signed element is encoded as a struct DigitallySigned:
637 struct {
638 SignatureAndHashAlgorithm algorithm;
639 opaque signature<0..2^16-1>;
640 } DigitallySigned;
642 The algorithm field specifies the algorithm used (see Section
643 7.4.1.4.1 for the definition of this field). Note that the
644 introduction of the algorithm field is a change from previous
645 versions. The signature is a digital signature using those
646 algorithms over the contents of the element. The contents themselves
647 do not appear on the wire but are simply calculated. The length of
648 the signature is specified by the signing algorithm and key.
650 In RSA signing, the opaque vector contains the signature generated
651 using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As
652 discussed in [PKCS1], the DigestInfo MUST be DER-encoded [X680]
653 [X690]. For hash algorithms without parameters (which includes
654 SHA-1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be
655 NULL, but implementations MUST accept both without parameters and
656 with NULL parameters. Note that earlier versions of TLS used a
657 different RSA signature scheme that did not include a DigestInfo
658 encoding.
660 In DSA, the 20 bytes of the SHA-1 hash are run directly through the
661 Digital Signing Algorithm with no additional hashing. This produces
662 two values, r and s. The DSA signature is an opaque vector, as
663 above, the contents of which are the DER encoding of:
665 Dss-Sig-Value ::= SEQUENCE {
666 r INTEGER,
667 s INTEGER
668 }
674 Dierks & Rescorla Standards Track [Page 12]
675 \f
676 RFC 5246 TLS August 2008
679 Note: In current terminology, DSA refers to the Digital Signature
680 Algorithm and DSS refers to the NIST standard. In the original SSL
681 and TLS specs, "DSS" was used universally. This document uses "DSA"
682 to refer to the algorithm, "DSS" to refer to the standard, and it
683 uses "DSS" in the code point definitions for historical continuity.
685 In stream cipher encryption, the plaintext is exclusive-ORed with an
686 identical amount of output generated from a cryptographically secure
687 keyed pseudorandom number generator.
689 In block cipher encryption, every block of plaintext encrypts to a
690 block of ciphertext. All block cipher encryption is done in CBC
691 (Cipher Block Chaining) mode, and all items that are block-ciphered
692 will be an exact multiple of the cipher block length.
694 In AEAD encryption, the plaintext is simultaneously encrypted and
695 integrity protected. The input may be of any length, and aead-
696 ciphered output is generally larger than the input in order to
697 accommodate the integrity check value.
699 In public key encryption, a public key algorithm is used to encrypt
700 data in such a way that it can be decrypted only with the matching
701 private key. A public-key-encrypted element is encoded as an opaque
702 vector <0..2^16-1>, where the length is specified by the encryption
703 algorithm and key.
705 RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
706 defined in [PKCS1].
708 In the following example
710 stream-ciphered struct {
711 uint8 field1;
712 uint8 field2;
713 digitally-signed opaque {
714 uint8 field3<0..255>;
715 uint8 field4;
716 };
717 } UserType;
719 The contents of the inner struct (field3 and field4) are used as
720 input for the signature/hash algorithm, and then the entire structure
721 is encrypted with a stream cipher. The length of this structure, in
722 bytes, would be equal to two bytes for field1 and field2, plus two
723 bytes for the signature and hash algorithm, plus two bytes for the
724 length of the signature, plus the length of the output of the signing
730 Dierks & Rescorla Standards Track [Page 13]
731 \f
732 RFC 5246 TLS August 2008
735 algorithm. The length of the signature is known because the
736 algorithm and key used for the signing are known prior to encoding or
737 decoding this structure.
739 4.8. Constants
741 Typed constants can be defined for purposes of specification by
742 declaring a symbol of the desired type and assigning values to it.
744 Under-specified types (opaque, variable-length vectors, and
745 structures that contain opaque) cannot be assigned values. No fields
746 of a multi-element structure or vector may be elided.
748 For example:
750 struct {
751 uint8 f1;
752 uint8 f2;
753 } Example1;
755 Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
757 5. HMAC and the Pseudorandom Function
759 The TLS record layer uses a keyed Message Authentication Code (MAC)
760 to protect message integrity. The cipher suites defined in this
761 document use a construction known as HMAC, described in [HMAC], which
762 is based on a hash function. Other cipher suites MAY define their
763 own MAC constructions, if needed.
765 In addition, a construction is required to do expansion of secrets
766 into blocks of data for the purposes of key generation or validation.
767 This pseudorandom function (PRF) takes as input a secret, a seed, and
768 an identifying label and produces an output of arbitrary length.
770 In this section, we define one PRF, based on HMAC. This PRF with the
771 SHA-256 hash function is used for all cipher suites defined in this
772 document and in TLS documents published prior to this document when
773 TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a
774 PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a
775 stronger standard hash function.
777 First, we define a data expansion function, P_hash(secret, data),
778 that uses a single hash function to expand a secret and seed into an
779 arbitrary quantity of output:
786 Dierks & Rescorla Standards Track [Page 14]
787 \f
788 RFC 5246 TLS August 2008
791 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
792 HMAC_hash(secret, A(2) + seed) +
793 HMAC_hash(secret, A(3) + seed) + ...
795 where + indicates concatenation.
797 A() is defined as:
799 A(0) = seed
800 A(i) = HMAC_hash(secret, A(i-1))
802 P_hash can be iterated as many times as necessary to produce the
803 required quantity of data. For example, if P_SHA256 is being used to
804 create 80 bytes of data, it will have to be iterated three times
805 (through A(3)), creating 96 bytes of output data; the last 16 bytes
806 of the final iteration will then be discarded, leaving 80 bytes of
807 output data.
809 TLS's PRF is created by applying P_hash to the secret as:
811 PRF(secret, label, seed) = P_<hash>(secret, label + seed)
813 The label is an ASCII string. It should be included in the exact
814 form it is given without a length byte or trailing null character.
815 For example, the label "slithy toves" would be processed by hashing
816 the following bytes:
818 73 6C 69 74 68 79 20 74 6F 76 65 73
820 6. The TLS Record Protocol
822 The TLS Record Protocol is a layered protocol. At each layer,
823 messages may include fields for length, description, and content.
824 The Record Protocol takes messages to be transmitted, fragments the
825 data into manageable blocks, optionally compresses the data, applies
826 a MAC, encrypts, and transmits the result. Received data is
827 decrypted, verified, decompressed, reassembled, and then delivered to
828 higher-level clients.
830 Four protocols that use the record protocol are described in this
831 document: the handshake protocol, the alert protocol, the change
832 cipher spec protocol, and the application data protocol. In order to
833 allow extension of the TLS protocol, additional record content types
834 can be supported by the record protocol. New record content type
835 values are assigned by IANA in the TLS Content Type Registry as
836 described in Section 12.
842 Dierks & Rescorla Standards Track [Page 15]
843 \f
844 RFC 5246 TLS August 2008
847 Implementations MUST NOT send record types not defined in this
848 document unless negotiated by some extension. If a TLS
849 implementation receives an unexpected record type, it MUST send an
850 unexpected_message alert.
852 Any protocol designed for use over TLS must be carefully designed to
853 deal with all possible attacks against it. As a practical matter,
854 this means that the protocol designer must be aware of what security
855 properties TLS does and does not provide and cannot safely rely on
856 the latter.
858 Note in particular that type and length of a record are not protected
859 by encryption. If this information is itself sensitive, application
860 designers may wish to take steps (padding, cover traffic) to minimize
861 information leakage.
863 6.1. Connection States
865 A TLS connection state is the operating environment of the TLS Record
866 Protocol. It specifies a compression algorithm, an encryption
867 algorithm, and a MAC algorithm. In addition, the parameters for
868 these algorithms are known: the MAC key and the bulk encryption keys
869 for the connection in both the read and the write directions.
870 Logically, there are always four connection states outstanding: the
871 current read and write states, and the pending read and write states.
872 All records are processed under the current read and write states.
873 The security parameters for the pending states can be set by the TLS
874 Handshake Protocol, and the ChangeCipherSpec can selectively make
875 either of the pending states current, in which case the appropriate
876 current state is disposed of and replaced with the pending state; the
877 pending state is then reinitialized to an empty state. It is illegal
878 to make a state that has not been initialized with security
879 parameters a current state. The initial current state always
880 specifies that no encryption, compression, or MAC will be used.
882 The security parameters for a TLS Connection read and write state are
883 set by providing the following values:
885 connection end
886 Whether this entity is considered the "client" or the "server" in
887 this connection.
889 PRF algorithm
890 An algorithm used to generate keys from the master secret (see
891 Sections 5 and 6.3).
898 Dierks & Rescorla Standards Track [Page 16]
899 \f
900 RFC 5246 TLS August 2008
903 bulk encryption algorithm
904 An algorithm to be used for bulk encryption. This specification
905 includes the key size of this algorithm, whether it is a block,
906 stream, or AEAD cipher, the block size of the cipher (if
907 appropriate), and the lengths of explicit and implicit
908 initialization vectors (or nonces).
910 MAC algorithm
911 An algorithm to be used for message authentication. This
912 specification includes the size of the value returned by the MAC
913 algorithm.
915 compression algorithm
916 An algorithm to be used for data compression. This specification
917 must include all information the algorithm requires to do
918 compression.
920 master secret
921 A 48-byte secret shared between the two peers in the connection.
923 client random
924 A 32-byte value provided by the client.
926 server random
927 A 32-byte value provided by the server.
929 These parameters are defined in the presentation language as:
931 enum { server, client } ConnectionEnd;
933 enum { tls_prf_sha256 } PRFAlgorithm;
935 enum { null, rc4, 3des, aes }
936 BulkCipherAlgorithm;
938 enum { stream, block, aead } CipherType;
940 enum { null, hmac_md5, hmac_sha1, hmac_sha256,
941 hmac_sha384, hmac_sha512} MACAlgorithm;
943 enum { null(0), (255) } CompressionMethod;
945 /* The algorithms specified in CompressionMethod, PRFAlgorithm,
946 BulkCipherAlgorithm, and MACAlgorithm may be added to. */
954 Dierks & Rescorla Standards Track [Page 17]
955 \f
956 RFC 5246 TLS August 2008
959 struct {
960 ConnectionEnd entity;
961 PRFAlgorithm prf_algorithm;
962 BulkCipherAlgorithm bulk_cipher_algorithm;
963 CipherType cipher_type;
964 uint8 enc_key_length;
965 uint8 block_length;
966 uint8 fixed_iv_length;
967 uint8 record_iv_length;
968 MACAlgorithm mac_algorithm;
969 uint8 mac_length;
970 uint8 mac_key_length;
971 CompressionMethod compression_algorithm;
972 opaque master_secret[48];
973 opaque client_random[32];
974 opaque server_random[32];
975 } SecurityParameters;
977 The record layer will use the security parameters to generate the
978 following six items (some of which are not required by all ciphers,
979 and are thus empty):
981 client write MAC key
982 server write MAC key
983 client write encryption key
984 server write encryption key
985 client write IV
986 server write IV
988 The client write parameters are used by the server when receiving and
989 processing records and vice versa. The algorithm used for generating
990 these items from the security parameters is described in Section 6.3.
992 Once the security parameters have been set and the keys have been
993 generated, the connection states can be instantiated by making them
994 the current states. These current states MUST be updated for each
995 record processed. Each connection state includes the following
996 elements:
998 compression state
999 The current state of the compression algorithm.
1001 cipher state
1002 The current state of the encryption algorithm. This will consist
1003 of the scheduled key for that connection. For stream ciphers,
1004 this will also contain whatever state information is necessary to
1005 allow the stream to continue to encrypt or decrypt data.
1010 Dierks & Rescorla Standards Track [Page 18]
1011 \f
1012 RFC 5246 TLS August 2008
1015 MAC key
1016 The MAC key for this connection, as generated above.
1018 sequence number
1019 Each connection state contains a sequence number, which is
1020 maintained separately for read and write states. The sequence
1021 number MUST be set to zero whenever a connection state is made the
1022 active state. Sequence numbers are of type uint64 and may not
1023 exceed 2^64-1. Sequence numbers do not wrap. If a TLS
1024 implementation would need to wrap a sequence number, it must
1025 renegotiate instead. A sequence number is incremented after each
1026 record: specifically, the first record transmitted under a
1027 particular connection state MUST use sequence number 0.
1029 6.2. Record Layer
1031 The TLS record layer receives uninterpreted data from higher layers
1032 in non-empty blocks of arbitrary size.
1034 6.2.1. Fragmentation
1036 The record layer fragments information blocks into TLSPlaintext
1037 records carrying data in chunks of 2^14 bytes or less. Client
1038 message boundaries are not preserved in the record layer (i.e.,
1039 multiple client messages of the same ContentType MAY be coalesced
1040 into a single TLSPlaintext record, or a single message MAY be
1041 fragmented across several records).
1043 struct {
1044 uint8 major;
1045 uint8 minor;
1046 } ProtocolVersion;
1048 enum {
1049 change_cipher_spec(20), alert(21), handshake(22),
1050 application_data(23), (255)
1051 } ContentType;
1053 struct {
1054 ContentType type;
1055 ProtocolVersion version;
1056 uint16 length;
1057 opaque fragment[TLSPlaintext.length];
1058 } TLSPlaintext;
1060 type
1061 The higher-level protocol used to process the enclosed fragment.
1066 Dierks & Rescorla Standards Track [Page 19]
1067 \f
1068 RFC 5246 TLS August 2008
1071 version
1072 The version of the protocol being employed. This document
1073 describes TLS Version 1.2, which uses the version { 3, 3 }. The
1074 version value 3.3 is historical, deriving from the use of {3, 1}
1075 for TLS 1.0. (See Appendix A.1.) Note that a client that
1076 supports multiple versions of TLS may not know what version will
1077 be employed before it receives the ServerHello. See Appendix E
1078 for discussion about what record layer version number should be
1079 employed for ClientHello.
1081 length
1082 The length (in bytes) of the following TLSPlaintext.fragment. The
1083 length MUST NOT exceed 2^14.
1085 fragment
1086 The application data. This data is transparent and treated as an
1087 independent block to be dealt with by the higher-level protocol
1088 specified by the type field.
1090 Implementations MUST NOT send zero-length fragments of Handshake,
1091 Alert, or ChangeCipherSpec content types. Zero-length fragments of
1092 Application data MAY be sent as they are potentially useful as a
1093 traffic analysis countermeasure.
1095 Note: Data of different TLS record layer content types MAY be
1096 interleaved. Application data is generally of lower precedence for
1097 transmission than other content types. However, records MUST be
1098 delivered to the network in the same order as they are protected by
1099 the record layer. Recipients MUST receive and process interleaved
1100 application layer traffic during handshakes subsequent to the first
1101 one on a connection.
1103 6.2.2. Record Compression and Decompression
1105 All records are compressed using the compression algorithm defined in
1106 the current session state. There is always an active compression
1107 algorithm; however, initially it is defined as
1108 CompressionMethod.null. The compression algorithm translates a
1109 TLSPlaintext structure into a TLSCompressed structure. Compression
1110 functions are initialized with default state information whenever a
1111 connection state is made active. [RFC3749] describes compression
1112 algorithms for TLS.
1114 Compression must be lossless and may not increase the content length
1115 by more than 1024 bytes. If the decompression function encounters a
1116 TLSCompressed.fragment that would decompress to a length in excess of
1117 2^14 bytes, it MUST report a fatal decompression failure error.
1122 Dierks & Rescorla Standards Track [Page 20]
1123 \f
1124 RFC 5246 TLS August 2008
1127 struct {
1128 ContentType type; /* same as TLSPlaintext.type */
1129 ProtocolVersion version;/* same as TLSPlaintext.version */
1130 uint16 length;
1131 opaque fragment[TLSCompressed.length];
1132 } TLSCompressed;
1134 length
1135 The length (in bytes) of the following TLSCompressed.fragment.
1136 The length MUST NOT exceed 2^14 + 1024.
1138 fragment
1139 The compressed form of TLSPlaintext.fragment.
1141 Note: A CompressionMethod.null operation is an identity operation;
1142 no fields are altered.
1144 Implementation note: Decompression functions are responsible for
1145 ensuring that messages cannot cause internal buffer overflows.
1147 6.2.3. Record Payload Protection
1149 The encryption and MAC functions translate a TLSCompressed
1150 structure into a TLSCiphertext. The decryption functions reverse
1151 the process. The MAC of the record also includes a sequence
1152 number so that missing, extra, or repeated messages are
1153 detectable.
1155 struct {
1156 ContentType type;
1157 ProtocolVersion version;
1158 uint16 length;
1159 select (SecurityParameters.cipher_type) {
1160 case stream: GenericStreamCipher;
1161 case block: GenericBlockCipher;
1162 case aead: GenericAEADCipher;
1163 } fragment;
1164 } TLSCiphertext;
1166 type
1167 The type field is identical to TLSCompressed.type.
1169 version
1170 The version field is identical to TLSCompressed.version.
1172 length
1173 The length (in bytes) of the following TLSCiphertext.fragment.
1174 The length MUST NOT exceed 2^14 + 2048.
1178 Dierks & Rescorla Standards Track [Page 21]
1179 \f
1180 RFC 5246 TLS August 2008
1183 fragment
1184 The encrypted form of TLSCompressed.fragment, with the MAC.
1186 6.2.3.1. Null or Standard Stream Cipher
1188 Stream ciphers (including BulkCipherAlgorithm.null; see Appendix A.6)
1189 convert TLSCompressed.fragment structures to and from stream
1190 TLSCiphertext.fragment structures.
1192 stream-ciphered struct {
1193 opaque content[TLSCompressed.length];
1194 opaque MAC[SecurityParameters.mac_length];
1195 } GenericStreamCipher;
1197 The MAC is generated as:
1199 MAC(MAC_write_key, seq_num +
1200 TLSCompressed.type +
1201 TLSCompressed.version +
1202 TLSCompressed.length +
1203 TLSCompressed.fragment);
1205 where "+" denotes concatenation.
1207 seq_num
1208 The sequence number for this record.
1210 MAC
1211 The MAC algorithm specified by SecurityParameters.mac_algorithm.
1213 Note that the MAC is computed before encryption. The stream cipher
1214 encrypts the entire block, including the MAC. For stream ciphers
1215 that do not use a synchronization vector (such as RC4), the stream
1216 cipher state from the end of one record is simply used on the
1217 subsequent packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL,
1218 encryption consists of the identity operation (i.e., the data is not
1219 encrypted, and the MAC size is zero, implying that no MAC is used).
1220 For both null and stream ciphers, TLSCiphertext.length is
1221 TLSCompressed.length plus SecurityParameters.mac_length.
1223 6.2.3.2. CBC Block Cipher
1225 For block ciphers (such as 3DES or AES), the encryption and MAC
1226 functions convert TLSCompressed.fragment structures to and from block
1227 TLSCiphertext.fragment structures.
1234 Dierks & Rescorla Standards Track [Page 22]
1235 \f
1236 RFC 5246 TLS August 2008
1239 struct {
1240 opaque IV[SecurityParameters.record_iv_length];
1241 block-ciphered struct {
1242 opaque content[TLSCompressed.length];
1243 opaque MAC[SecurityParameters.mac_length];
1244 uint8 padding[GenericBlockCipher.padding_length];
1245 uint8 padding_length;
1246 };
1247 } GenericBlockCipher;
1249 The MAC is generated as described in Section 6.2.3.1.
1251 IV
1252 The Initialization Vector (IV) SHOULD be chosen at random, and
1253 MUST be unpredictable. Note that in versions of TLS prior to 1.1,
1254 there was no IV field, and the last ciphertext block of the
1255 previous record (the "CBC residue") was used as the IV. This was
1256 changed to prevent the attacks described in [CBCATT]. For block
1257 ciphers, the IV length is of length
1258 SecurityParameters.record_iv_length, which is equal to the
1259 SecurityParameters.block_size.
1261 padding
1262 Padding that is added to force the length of the plaintext to be
1263 an integral multiple of the block cipher's block length. The
1264 padding MAY be any length up to 255 bytes, as long as it results
1265 in the TLSCiphertext.length being an integral multiple of the
1266 block length. Lengths longer than necessary might be desirable to
1267 frustrate attacks on a protocol that are based on analysis of the
1268 lengths of exchanged messages. Each uint8 in the padding data
1269 vector MUST be filled with the padding length value. The receiver
1270 MUST check this padding and MUST use the bad_record_mac alert to
1271 indicate padding errors.
1273 padding_length
1274 The padding length MUST be such that the total size of the
1275 GenericBlockCipher structure is a multiple of the cipher's block
1276 length. Legal values range from zero to 255, inclusive. This
1277 length specifies the length of the padding field exclusive of the
1278 padding_length field itself.
1280 The encrypted data length (TLSCiphertext.length) is one more than the
1281 sum of SecurityParameters.block_length, TLSCompressed.length,
1282 SecurityParameters.mac_length, and padding_length.
1284 Example: If the block length is 8 bytes, the content length
1285 (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,
1286 then the length before padding is 82 bytes (this does not include the
1290 Dierks & Rescorla Standards Track [Page 23]
1291 \f
1292 RFC 5246 TLS August 2008
1295 IV. Thus, the padding length modulo 8 must be equal to 6 in order to
1296 make the total length an even multiple of 8 bytes (the block length).
1297 The padding length can be 6, 14, 22, and so on, through 254. If the
1298 padding length were the minimum necessary, 6, the padding would be 6
1299 bytes, each containing the value 6. Thus, the last 8 octets of the
1300 GenericBlockCipher before block encryption would be xx 06 06 06 06 06
1301 06 06, where xx is the last octet of the MAC.
1303 Note: With block ciphers in CBC mode (Cipher Block Chaining), it is
1304 critical that the entire plaintext of the record be known before any
1305 ciphertext is transmitted. Otherwise, it is possible for the
1306 attacker to mount the attack described in [CBCATT].
1308 Implementation note: Canvel et al. [CBCTIME] have demonstrated a
1309 timing attack on CBC padding based on the time required to compute
1310 the MAC. In order to defend against this attack, implementations
1311 MUST ensure that record processing time is essentially the same
1312 whether or not the padding is correct. In general, the best way to
1313 do this is to compute the MAC even if the padding is incorrect, and
1314 only then reject the packet. For instance, if the pad appears to be
1315 incorrect, the implementation might assume a zero-length pad and then
1316 compute the MAC. This leaves a small timing channel, since MAC
1317 performance depends to some extent on the size of the data fragment,
1318 but it is not believed to be large enough to be exploitable, due to
1319 the large block size of existing MACs and the small size of the
1320 timing signal.
1322 6.2.3.3. AEAD Ciphers
1324 For AEAD [AEAD] ciphers (such as [CCM] or [GCM]), the AEAD function
1325 converts TLSCompressed.fragment structures to and from AEAD
1326 TLSCiphertext.fragment structures.
1328 struct {
1329 opaque nonce_explicit[SecurityParameters.record_iv_length];
1330 aead-ciphered struct {
1331 opaque content[TLSCompressed.length];
1332 };
1333 } GenericAEADCipher;
1335 AEAD ciphers take as input a single key, a nonce, a plaintext, and
1336 "additional data" to be included in the authentication check, as
1337 described in Section 2.1 of [AEAD]. The key is either the
1338 client_write_key or the server_write_key. No MAC key is used.
1340 Each AEAD cipher suite MUST specify how the nonce supplied to the
1341 AEAD operation is constructed, and what is the length of the
1342 GenericAEADCipher.nonce_explicit part. In many cases, it is
1346 Dierks & Rescorla Standards Track [Page 24]
1347 \f
1348 RFC 5246 TLS August 2008
1351 appropriate to use the partially implicit nonce technique described
1352 in Section 3.2.1 of [AEAD]; with record_iv_length being the length of
1353 the explicit part. In this case, the implicit part SHOULD be derived
1354 from key_block as client_write_iv and server_write_iv (as described
1355 in Section 6.3), and the explicit part is included in
1356 GenericAEAEDCipher.nonce_explicit.
1358 The plaintext is the TLSCompressed.fragment.
1360 The additional authenticated data, which we denote as
1361 additional_data, is defined as follows:
1363 additional_data = seq_num + TLSCompressed.type +
1364 TLSCompressed.version + TLSCompressed.length;
1366 where "+" denotes concatenation.
1368 The aead_output consists of the ciphertext output by the AEAD
1369 encryption operation. The length will generally be larger than
1370 TLSCompressed.length, but by an amount that varies with the AEAD
1371 cipher. Since the ciphers might incorporate padding, the amount of
1372 overhead could vary with different TLSCompressed.length values. Each
1373 AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
1374 Symbolically,
1376 AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext,
1377 additional_data)
1379 In order to decrypt and verify, the cipher takes as input the key,
1380 nonce, the "additional_data", and the AEADEncrypted value. The
1381 output is either the plaintext or an error indicating that the
1382 decryption failed. There is no separate integrity check. That is:
1384 TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
1385 AEADEncrypted,
1386 additional_data)
1388 If the decryption fails, a fatal bad_record_mac alert MUST be
1389 generated.
1391 6.3. Key Calculation
1393 The Record Protocol requires an algorithm to generate keys required
1394 by the current connection state (see Appendix A.6) from the security
1395 parameters provided by the handshake protocol.
1402 Dierks & Rescorla Standards Track [Page 25]
1403 \f
1404 RFC 5246 TLS August 2008
1407 The master secret is expanded into a sequence of secure bytes, which
1408 is then split to a client write MAC key, a server write MAC key, a
1409 client write encryption key, and a server write encryption key. Each
1410 of these is generated from the byte sequence in that order. Unused
1411 values are empty. Some AEAD ciphers may additionally require a
1412 client write IV and a server write IV (see Section 6.2.3.3).
1414 When keys and MAC keys are generated, the master secret is used as an
1415 entropy source.
1417 To generate the key material, compute
1419 key_block = PRF(SecurityParameters.master_secret,
1420 "key expansion",
1421 SecurityParameters.server_random +
1422 SecurityParameters.client_random);
1424 until enough output has been generated. Then, the key_block is
1425 partitioned as follows:
1427 client_write_MAC_key[SecurityParameters.mac_key_length]
1428 server_write_MAC_key[SecurityParameters.mac_key_length]
1429 client_write_key[SecurityParameters.enc_key_length]
1430 server_write_key[SecurityParameters.enc_key_length]
1431 client_write_IV[SecurityParameters.fixed_iv_length]
1432 server_write_IV[SecurityParameters.fixed_iv_length]
1434 Currently, the client_write_IV and server_write_IV are only generated
1435 for implicit nonce techniques as described in Section 3.2.1 of
1436 [AEAD].
1438 Implementation note: The currently defined cipher suite which
1439 requires the most material is AES_256_CBC_SHA256. It requires 2 x 32
1440 byte keys and 2 x 32 byte MAC keys, for a total 128 bytes of key
1441 material.
1443 7. The TLS Handshaking Protocols
1445 TLS has three subprotocols that are used to allow peers to agree upon
1446 security parameters for the record layer, to authenticate themselves,
1447 to instantiate negotiated security parameters, and to report error
1448 conditions to each other.
1450 The Handshake Protocol is responsible for negotiating a session,
1451 which consists of the following items:
1458 Dierks & Rescorla Standards Track [Page 26]
1459 \f
1460 RFC 5246 TLS August 2008
1463 session identifier
1464 An arbitrary byte sequence chosen by the server to identify an
1465 active or resumable session state.
1467 peer certificate
1468 X509v3 [PKIX] certificate of the peer. This element of the state
1469 may be null.
1471 compression method
1472 The algorithm used to compress data prior to encryption.
1474 cipher spec
1475 Specifies the pseudorandom function (PRF) used to generate keying
1476 material, the bulk data encryption algorithm (such as null, AES,
1477 etc.) and the MAC algorithm (such as HMAC-SHA1). It also defines
1478 cryptographic attributes such as the mac_length. (See Appendix
1479 A.6 for formal definition.)
1481 master secret
1482 48-byte secret shared between the client and server.
1484 is resumable
1485 A flag indicating whether the session can be used to initiate new
1486 connections.
1488 These items are then used to create security parameters for use by
1489 the record layer when protecting application data. Many connections
1490 can be instantiated using the same session through the resumption
1491 feature of the TLS Handshake Protocol.
1493 7.1. Change Cipher Spec Protocol
1495 The change cipher spec protocol exists to signal transitions in
1496 ciphering strategies. The protocol consists of a single message,
1497 which is encrypted and compressed under the current (not the pending)
1498 connection state. The message consists of a single byte of value 1.
1500 struct {
1501 enum { change_cipher_spec(1), (255) } type;
1502 } ChangeCipherSpec;
1504 The ChangeCipherSpec message is sent by both the client and the
1505 server to notify the receiving party that subsequent records will be
1506 protected under the newly negotiated CipherSpec and keys. Reception
1507 of this message causes the receiver to instruct the record layer to
1508 immediately copy the read pending state into the read current state.
1509 Immediately after sending this message, the sender MUST instruct the
1510 record layer to make the write pending state the write active state.
1514 Dierks & Rescorla Standards Track [Page 27]
1515 \f
1516 RFC 5246 TLS August 2008
1519 (See Section 6.1.) The ChangeCipherSpec message is sent during the
1520 handshake after the security parameters have been agreed upon, but
1521 before the verifying Finished message is sent.
1523 Note: If a rehandshake occurs while data is flowing on a connection,
1524 the communicating parties may continue to send data using the old
1525 CipherSpec. However, once the ChangeCipherSpec has been sent, the
1526 new CipherSpec MUST be used. The first side to send the
1527 ChangeCipherSpec does not know that the other side has finished
1528 computing the new keying material (e.g., if it has to perform a
1529 time-consuming public key operation). Thus, a small window of time,
1530 during which the recipient must buffer the data, MAY exist. In
1531 practice, with modern machines this interval is likely to be fairly
1532 short.
1534 7.2. Alert Protocol
1536 One of the content types supported by the TLS record layer is the
1537 alert type. Alert messages convey the severity of the message
1538 (warning or fatal) and a description of the alert. Alert messages
1539 with a level of fatal result in the immediate termination of the
1540 connection. In this case, other connections corresponding to the
1541 session may continue, but the session identifier MUST be invalidated,
1542 preventing the failed session from being used to establish new
1543 connections. Like other messages, alert messages are encrypted and
1544 compressed, as specified by the current connection state.
1546 enum { warning(1), fatal(2), (255) } AlertLevel;
1548 enum {
1549 close_notify(0),
1550 unexpected_message(10),
1551 bad_record_mac(20),
1552 decryption_failed_RESERVED(21),
1553 record_overflow(22),
1554 decompression_failure(30),
1555 handshake_failure(40),
1556 no_certificate_RESERVED(41),
1557 bad_certificate(42),
1558 unsupported_certificate(43),
1559 certificate_revoked(44),
1560 certificate_expired(45),
1561 certificate_unknown(46),
1562 illegal_parameter(47),
1563 unknown_ca(48),
1564 access_denied(49),
1565 decode_error(50),
1566 decrypt_error(51),
1570 Dierks & Rescorla Standards Track [Page 28]
1571 \f
1572 RFC 5246 TLS August 2008
1575 export_restriction_RESERVED(60),
1576 protocol_version(70),
1577 insufficient_security(71),
1578 internal_error(80),
1579 user_canceled(90),
1580 no_renegotiation(100),
1581 unsupported_extension(110),
1582 (255)
1583 } AlertDescription;
1585 struct {
1586 AlertLevel level;
1587 AlertDescription description;
1588 } Alert;
1590 7.2.1. Closure Alerts
1592 The client and the server must share knowledge that the connection is
1593 ending in order to avoid a truncation attack. Either party may
1594 initiate the exchange of closing messages.
1596 close_notify
1597 This message notifies the recipient that the sender will not send
1598 any more messages on this connection. Note that as of TLS 1.1,
1599 failure to properly close a connection no longer requires that a
1600 session not be resumed. This is a change from TLS 1.0 to conform
1601 with widespread implementation practice.
1603 Either party may initiate a close by sending a close_notify alert.
1604 Any data received after a closure alert is ignored.
1606 Unless some other fatal alert has been transmitted, each party is
1607 required to send a close_notify alert before closing the write side
1608 of the connection. The other party MUST respond with a close_notify
1609 alert of its own and close down the connection immediately,
1610 discarding any pending writes. It is not required for the initiator
1611 of the close to wait for the responding close_notify alert before
1612 closing the read side of the connection.
1614 If the application protocol using TLS provides that any data may be
1615 carried over the underlying transport after the TLS connection is
1616 closed, the TLS implementation must receive the responding
1617 close_notify alert before indicating to the application layer that
1618 the TLS connection has ended. If the application protocol will not
1619 transfer any additional data, but will only close the underlying
1620 transport connection, then the implementation MAY choose to close the
1621 transport without waiting for the responding close_notify. No part
1626 Dierks & Rescorla Standards Track [Page 29]
1627 \f
1628 RFC 5246 TLS August 2008
1631 of this standard should be taken to dictate the manner in which a
1632 usage profile for TLS manages its data transport, including when
1633 connections are opened or closed.
1635 Note: It is assumed that closing a connection reliably delivers
1636 pending data before destroying the transport.
1638 7.2.2. Error Alerts
1640 Error handling in the TLS Handshake protocol is very simple. When an
1641 error is detected, the detecting party sends a message to the other
1642 party. Upon transmission or receipt of a fatal alert message, both
1643 parties immediately close the connection. Servers and clients MUST
1644 forget any session-identifiers, keys, and secrets associated with a
1645 failed connection. Thus, any connection terminated with a fatal
1646 alert MUST NOT be resumed.
1648 Whenever an implementation encounters a condition which is defined as
1649 a fatal alert, it MUST send the appropriate alert prior to closing
1650 the connection. For all errors where an alert level is not
1651 explicitly specified, the sending party MAY determine at its
1652 discretion whether to treat this as a fatal error or not. If the
1653 implementation chooses to send an alert but intends to close the
1654 connection immediately afterwards, it MUST send that alert at the
1655 fatal alert level.
1657 If an alert with a level of warning is sent and received, generally
1658 the connection can continue normally. If the receiving party decides
1659 not to proceed with the connection (e.g., after having received a
1660 no_renegotiation alert that it is not willing to accept), it SHOULD
1661 send a fatal alert to terminate the connection. Given this, the
1662 sending party cannot, in general, know how the receiving party will
1663 behave. Therefore, warning alerts are not very useful when the
1664 sending party wants to continue the connection, and thus are
1665 sometimes omitted. For example, if a peer decides to accept an
1666 expired certificate (perhaps after confirming this with the user) and
1667 wants to continue the connection, it would not generally send a
1668 certificate_expired alert.
1670 The following error alerts are defined:
1672 unexpected_message
1673 An inappropriate message was received. This alert is always fatal
1674 and should never be observed in communication between proper
1675 implementations.
1682 Dierks & Rescorla Standards Track [Page 30]
1683 \f
1684 RFC 5246 TLS August 2008
1687 bad_record_mac
1688 This alert is returned if a record is received with an incorrect
1689 MAC. This alert also MUST be returned if an alert is sent because
1690 a TLSCiphertext decrypted in an invalid way: either it wasn't an
1691 even multiple of the block length, or its padding values, when
1692 checked, weren't correct. This message is always fatal and should
1693 never be observed in communication between proper implementations
1694 (except when messages were corrupted in the network).
1696 decryption_failed_RESERVED
1697 This alert was used in some earlier versions of TLS, and may have
1698 permitted certain attacks against the CBC mode [CBCATT]. It MUST
1699 NOT be sent by compliant implementations.
1701 record_overflow
1702 A TLSCiphertext record was received that had a length more than
1703 2^14+2048 bytes, or a record decrypted to a TLSCompressed record
1704 with more than 2^14+1024 bytes. This message is always fatal and
1705 should never be observed in communication between proper
1706 implementations (except when messages were corrupted in the
1707 network).
1709 decompression_failure
1710 The decompression function received improper input (e.g., data
1711 that would expand to excessive length). This message is always
1712 fatal and should never be observed in communication between proper
1713 implementations.
1715 handshake_failure
1716 Reception of a handshake_failure alert message indicates that the
1717 sender was unable to negotiate an acceptable set of security
1718 parameters given the options available. This is a fatal error.
1720 no_certificate_RESERVED
1721 This alert was used in SSLv3 but not any version of TLS. It MUST
1722 NOT be sent by compliant implementations.
1724 bad_certificate
1725 A certificate was corrupt, contained signatures that did not
1726 verify correctly, etc.
1728 unsupported_certificate
1729 A certificate was of an unsupported type.
1731 certificate_revoked
1732 A certificate was revoked by its signer.
1738 Dierks & Rescorla Standards Track [Page 31]
1739 \f
1740 RFC 5246 TLS August 2008
1743 certificate_expired
1744 A certificate has expired or is not currently valid.
1746 certificate_unknown
1747 Some other (unspecified) issue arose in processing the
1748 certificate, rendering it unacceptable.
1750 illegal_parameter
1751 A field in the handshake was out of range or inconsistent with
1752 other fields. This message is always fatal.
1754 unknown_ca
1755 A valid certificate chain or partial chain was received, but the
1756 certificate was not accepted because the CA certificate could not
1757 be located or couldn't be matched with a known, trusted CA. This
1758 message is always fatal.
1760 access_denied
1761 A valid certificate was received, but when access control was
1762 applied, the sender decided not to proceed with negotiation. This
1763 message is always fatal.
1765 decode_error
1766 A message could not be decoded because some field was out of the
1767 specified range or the length of the message was incorrect. This
1768 message is always fatal and should never be observed in
1769 communication between proper implementations (except when messages
1770 were corrupted in the network).
1772 decrypt_error
1773 A handshake cryptographic operation failed, including being unable
1774 to correctly verify a signature or validate a Finished message.
1775 This message is always fatal.
1777 export_restriction_RESERVED
1778 This alert was used in some earlier versions of TLS. It MUST NOT
1779 be sent by compliant implementations.
1781 protocol_version
1782 The protocol version the client has attempted to negotiate is
1783 recognized but not supported. (For example, old protocol versions
1784 might be avoided for security reasons.) This message is always
1785 fatal.
1794 Dierks & Rescorla Standards Track [Page 32]
1795 \f
1796 RFC 5246 TLS August 2008
1799 insufficient_security
1800 Returned instead of handshake_failure when a negotiation has
1801 failed specifically because the server requires ciphers more
1802 secure than those supported by the client. This message is always
1803 fatal.
1805 internal_error
1806 An internal error unrelated to the peer or the correctness of the
1807 protocol (such as a memory allocation failure) makes it impossible
1808 to continue. This message is always fatal.
1810 user_canceled
1811 This handshake is being canceled for some reason unrelated to a
1812 protocol failure. If the user cancels an operation after the
1813 handshake is complete, just closing the connection by sending a
1814 close_notify is more appropriate. This alert should be followed
1815 by a close_notify. This message is generally a warning.
1817 no_renegotiation
1818 Sent by the client in response to a hello request or by the server
1819 in response to a client hello after initial handshaking. Either
1820 of these would normally lead to renegotiation; when that is not
1821 appropriate, the recipient should respond with this alert. At
1822 that point, the original requester can decide whether to proceed
1823 with the connection. One case where this would be appropriate is
1824 where a server has spawned a process to satisfy a request; the
1825 process might receive security parameters (key length,
1826 authentication, etc.) at startup, and it might be difficult to
1827 communicate changes to these parameters after that point. This
1828 message is always a warning.
1830 unsupported_extension
1831 sent by clients that receive an extended server hello containing
1832 an extension that they did not put in the corresponding client
1833 hello. This message is always fatal.
1835 New Alert values are assigned by IANA as described in Section 12.
1837 7.3. Handshake Protocol Overview
1839 The cryptographic parameters of the session state are produced by the
1840 TLS Handshake Protocol, which operates on top of the TLS record
1841 layer. When a TLS client and server first start communicating, they
1842 agree on a protocol version, select cryptographic algorithms,
1843 optionally authenticate each other, and use public-key encryption
1844 techniques to generate shared secrets.
1850 Dierks & Rescorla Standards Track [Page 33]
1851 \f
1852 RFC 5246 TLS August 2008
1855 The TLS Handshake Protocol involves the following steps:
1857 - Exchange hello messages to agree on algorithms, exchange random
1858 values, and check for session resumption.
1860 - Exchange the necessary cryptographic parameters to allow the
1861 client and server to agree on a premaster secret.
1863 - Exchange certificates and cryptographic information to allow the
1864 client and server to authenticate themselves.
1866 - Generate a master secret from the premaster secret and exchanged
1867 random values.
1869 - Provide security parameters to the record layer.
1871 - Allow the client and server to verify that their peer has
1872 calculated the same security parameters and that the handshake
1873 occurred without tampering by an attacker.
1875 Note that higher layers should not be overly reliant on whether TLS
1876 always negotiates the strongest possible connection between two
1877 peers. There are a number of ways in which a man-in-the-middle
1878 attacker can attempt to make two entities drop down to the least
1879 secure method they support. The protocol has been designed to
1880 minimize this risk, but there are still attacks available: for
1881 example, an attacker could block access to the port a secure service
1882 runs on, or attempt to get the peers to negotiate an unauthenticated
1883 connection. The fundamental rule is that higher levels must be
1884 cognizant of what their security requirements are and never transmit
1885 information over a channel less secure than what they require. The
1886 TLS protocol is secure in that any cipher suite offers its promised
1887 level of security: if you negotiate 3DES with a 1024-bit RSA key
1888 exchange with a host whose certificate you have verified, you can
1889 expect to be that secure.
1891 These goals are achieved by the handshake protocol, which can be
1892 summarized as follows: The client sends a ClientHello message to
1893 which the server must respond with a ServerHello message, or else a
1894 fatal error will occur and the connection will fail. The ClientHello
1895 and ServerHello are used to establish security enhancement
1896 capabilities between client and server. The ClientHello and
1897 ServerHello establish the following attributes: Protocol Version,
1898 Session ID, Cipher Suite, and Compression Method. Additionally, two
1899 random values are generated and exchanged: ClientHello.random and
1900 ServerHello.random.
1906 Dierks & Rescorla Standards Track [Page 34]
1907 \f
1908 RFC 5246 TLS August 2008
1911 The actual key exchange uses up to four messages: the server
1912 Certificate, the ServerKeyExchange, the client Certificate, and the
1913 ClientKeyExchange. New key exchange methods can be created by
1914 specifying a format for these messages and by defining the use of the
1915 messages to allow the client and server to agree upon a shared
1916 secret. This secret MUST be quite long; currently defined key
1917 exchange methods exchange secrets that range from 46 bytes upwards.
1919 Following the hello messages, the server will send its certificate in
1920 a Certificate message if it is to be authenticated. Additionally, a
1921 ServerKeyExchange message may be sent, if it is required (e.g., if
1922 the server has no certificate, or if its certificate is for signing
1923 only). If the server is authenticated, it may request a certificate
1924 from the client, if that is appropriate to the cipher suite selected.
1925 Next, the server will send the ServerHelloDone message, indicating
1926 that the hello-message phase of the handshake is complete. The
1927 server will then wait for a client response. If the server has sent
1928 a CertificateRequest message, the client MUST send the Certificate
1929 message. The ClientKeyExchange message is now sent, and the content
1930 of that message will depend on the public key algorithm selected
1931 between the ClientHello and the ServerHello. If the client has sent
1932 a certificate with signing ability, a digitally-signed
1933 CertificateVerify message is sent to explicitly verify possession of
1934 the private key in the certificate.
1936 At this point, a ChangeCipherSpec message is sent by the client, and
1937 the client copies the pending Cipher Spec into the current Cipher
1938 Spec. The client then immediately sends the Finished message under
1939 the new algorithms, keys, and secrets. In response, the server will
1940 send its own ChangeCipherSpec message, transfer the pending to the
1941 current Cipher Spec, and send its Finished message under the new
1942 Cipher Spec. At this point, the handshake is complete, and the
1943 client and server may begin to exchange application layer data. (See
1944 flow chart below.) Application data MUST NOT be sent prior to the
1945 completion of the first handshake (before a cipher suite other than
1946 TLS_NULL_WITH_NULL_NULL is established).
1962 Dierks & Rescorla Standards Track [Page 35]
1963 \f
1964 RFC 5246 TLS August 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 Figure 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.
1999 If 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
2004 complete, the client and server MAY begin to exchange application
2005 layer data. (See flow chart below.) If a Session ID match is not
2006 found, the server generates a new session ID, and the TLS client and
2007 server perform a full handshake.
2018 Dierks & Rescorla Standards Track [Page 36]
2019 \f
2020 RFC 5246 TLS August 2008
2023 Client Server
2025 ClientHello -------->
2026 ServerHello
2027 [ChangeCipherSpec]
2028 <-------- Finished
2029 [ChangeCipherSpec]
2030 Finished -------->
2031 Application Data <-------> Application Data
2033 Figure 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 RFC 5246 TLS August 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
2082 omitted, however. Note one exception to the ordering: the
2083 Certificate message is used twice in the handshake (from server to
2084 client, then from client to server), but described only in its first
2085 position. The one message that is not bound by these ordering rules
2086 is the HelloRequest message, which can be sent at any time, but which
2087 SHOULD be ignored by the client if it arrives in the middle of a
2088 handshake.
2090 New handshake message types are assigned by IANA as described in
2091 Section 12.
2093 7.4.1. Hello Messages
2095 The hello phase messages are used to exchange security enhancement
2096 capabilities between the client and server. When a new session
2097 begins, the record layer's connection state encryption, hash, and
2098 compression algorithms are initialized to null. The current
2099 connection state is used for renegotiation messages.
2101 7.4.1.1. Hello Request
2103 When this message will be sent:
2105 The HelloRequest message MAY be sent by the server at any time.
2107 Meaning of this message:
2109 HelloRequest is a simple notification that the client should begin
2110 the negotiation process anew. In response, the client should send
2111 a ClientHello message when convenient. This message is not
2112 intended to establish which side is the client or server but
2113 merely to initiate a new negotiation. Servers SHOULD NOT send a
2114 HelloRequest immediately upon the client's initial connection. It
2115 is the client's job to send a ClientHello at that time.
2117 This message will be ignored by the client if the client is
2118 currently negotiating a session. This message MAY be ignored by
2119 the client if it does not wish to renegotiate a session, or the
2120 client may, if it wishes, respond with a no_renegotiation alert.
2121 Since handshake messages are intended to have transmission
2122 precedence over application data, it is expected that the
2123 negotiation will begin before no more than a few records are
2124 received from the client. If the server sends a HelloRequest but
2125 does not receive a ClientHello in response, it may close the
2126 connection with a fatal alert.
2130 Dierks & Rescorla Standards Track [Page 38]
2131 \f
2132 RFC 5246 TLS August 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,
2186 Dierks & Rescorla Standards Track [Page 39]
2187 \f
2188 RFC 5246 TLS August 2008
2191 this connection, or from another currently active connection. The
2192 second option is useful if the client only wishes to update the
2193 random structures and derived values of a connection, and the third
2194 option makes it possible to establish several independent secure
2195 connections without repeating the full handshake protocol. These
2196 independent connections may occur sequentially or simultaneously; a
2197 SessionID becomes valid when the handshake negotiating it completes
2198 with the exchange of Finished messages and persists until it is
2199 removed due to aging or because a fatal error was encountered on a
2200 connection associated with the session. The actual contents of the
2201 SessionID are 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;
2242 Dierks & Rescorla Standards Track [Page 40]
2243 \f
2244 RFC 5246 TLS August 2008
2247 struct {
2248 ProtocolVersion client_version;
2249 Random random;
2250 SessionID session_id;
2251 CipherSuite cipher_suites<2..2^16-2>;
2252 CompressionMethod compression_methods<1..2^8-1>;
2253 select (extensions_present) {
2254 case false:
2255 struct {};
2256 case true:
2257 Extension extensions<0..2^16-1>;
2258 };
2259 } ClientHello;
2261 TLS allows extensions to follow the compression_methods field in an
2262 extensions block. The presence of extensions can be detected by
2263 determining whether there are bytes following the compression_methods
2264 at the end of the ClientHello. Note that this method of detecting
2265 optional data differs from the normal TLS method of having a
2266 variable-length field, but it is used for compatibility with TLS
2267 before extensions were defined.
2269 client_version
2270 The version of the TLS protocol by which the client wishes to
2271 communicate during this session. This SHOULD be the latest
2272 (highest valued) version supported by the client. For this
2273 version of the specification, the version will be 3.3 (see
2274 Appendix E for details about backward compatibility).
2276 random
2277 A client-generated random structure.
2279 session_id
2280 The ID of a session the client wishes to use for this connection.
2281 This field is empty if no session_id is available, or if the
2282 client wishes to generate new security parameters.
2284 cipher_suites
2285 This is a list of the cryptographic options supported by the
2286 client, with the client's first preference first. If the
2287 session_id field is not empty (implying a session resumption
2288 request), this vector MUST include at least the cipher_suite from
2289 that session. Values are defined in Appendix A.5.
2291 compression_methods
2292 This is a list of the compression methods supported by the client,
2293 sorted by client preference. If the session_id field is not empty
2294 (implying a session resumption request), it MUST include the
2298 Dierks & Rescorla Standards Track [Page 41]
2299 \f
2300 RFC 5246 TLS August 2008
2303 compression_method from that session. This vector MUST contain,
2304 and all implementations MUST support, CompressionMethod.null.
2305 Thus, a client and server will always be able to agree on a
2306 compression method.
2308 extensions
2309 Clients MAY request extended functionality from servers by sending
2310 data in the extensions field. The actual "Extension" format is
2311 defined in Section 7.4.1.4.
2313 In the event that a client requests additional functionality using
2314 extensions, and this functionality is not supplied by the server, the
2315 client MAY abort the handshake. A server MUST accept ClientHello
2316 messages both with and without the extensions field, and (as for all
2317 other messages) it MUST check that the amount of data in the message
2318 precisely matches one of these formats; if not, then it MUST send a
2319 fatal "decode_error" alert.
2321 After sending the ClientHello message, the client waits for a
2322 ServerHello message. Any handshake message returned by the server,
2323 except for a HelloRequest, is treated as a fatal error.
2325 7.4.1.3. Server Hello
2327 When this message will be sent:
2329 The server will send this message in response to a ClientHello
2330 message when it was able to find an acceptable set of algorithms.
2331 If it cannot find such a match, it will respond with a handshake
2332 failure alert.
2334 Structure of this message:
2336 struct {
2337 ProtocolVersion server_version;
2338 Random random;
2339 SessionID session_id;
2340 CipherSuite cipher_suite;
2341 CompressionMethod compression_method;
2342 select (extensions_present) {
2343 case false:
2344 struct {};
2345 case true:
2346 Extension extensions<0..2^16-1>;
2347 };
2348 } ServerHello;
2354 Dierks & Rescorla Standards Track [Page 42]
2355 \f
2356 RFC 5246 TLS August 2008
2359 The presence of extensions can be detected by determining whether
2360 there are bytes following the compression_method field at the end of
2361 the ServerHello.
2363 server_version
2364 This field will contain the lower of that suggested by the client
2365 in the client hello and the highest supported by the server. For
2366 this version of the specification, the version is 3.3. (See
2367 Appendix E for details about backward compatibility.)
2369 random
2370 This structure is generated by the server and MUST be
2371 independently generated from the ClientHello.random.
2373 session_id
2374 This is the identity of the session corresponding to this
2375 connection. If the ClientHello.session_id was non-empty, the
2376 server will look in its session cache for a match. If a match is
2377 found and the server is willing to establish the new connection
2378 using the specified session state, the server will respond with
2379 the same value as was supplied by the client. This indicates a
2380 resumed session and dictates that the parties must proceed
2381 directly to the Finished messages. Otherwise, this field will
2382 contain a different value identifying the new session. The server
2383 may return an empty session_id to indicate that the session will
2384 not be cached and therefore cannot be resumed. If a session is
2385 resumed, it must be resumed using the same cipher suite it was
2386 originally negotiated with. Note that there is no requirement
2387 that the server resume any session even if it had formerly
2388 provided a session_id. Clients MUST be prepared to do a full
2389 negotiation -- including negotiating new cipher suites -- during
2390 any handshake.
2392 cipher_suite
2393 The single cipher suite selected by the server from the list in
2394 ClientHello.cipher_suites. For resumed sessions, this field is
2395 the value from the state of the session being resumed.
2397 compression_method
2398 The single compression algorithm selected by the server from the
2399 list in ClientHello.compression_methods. For resumed sessions,
2400 this field is the value from the resumed session state.
2402 extensions
2403 A list of extensions. Note that only extensions offered by the
2404 client can appear in the server's list.
2410 Dierks & Rescorla Standards Track [Page 43]
2411 \f
2412 RFC 5246 TLS August 2008
2415 7.4.1.4. Hello Extensions
2417 The extension format is:
2419 struct {
2420 ExtensionType extension_type;
2421 opaque extension_data<0..2^16-1>;
2422 } Extension;
2424 enum {
2425 signature_algorithms(13), (65535)
2426 } ExtensionType;
2428 Here:
2430 - "extension_type" identifies the particular extension type.
2432 - "extension_data" contains information specific to the particular
2433 extension type.
2435 The initial set of extensions is defined in a companion document
2436 [TLSEXT]. The list of extension types is maintained by IANA as
2437 described in Section 12.
2439 An extension type MUST NOT appear in the ServerHello unless the same
2440 extension type appeared in the corresponding ClientHello. If a
2441 client receives an extension type in ServerHello that it did not
2442 request in the associated ClientHello, it MUST abort the handshake
2443 with an unsupported_extension fatal alert.
2445 Nonetheless, "server-oriented" extensions may be provided in the
2446 future within this framework. Such an extension (say, of type x)
2447 would require the client to first send an extension of type x in a
2448 ClientHello with empty extension_data to indicate that it supports
2449 the extension type. In this case, the client is offering the
2450 capability to understand the extension type, and the server is taking
2451 the client up on its offer.
2453 When multiple extensions of different types are present in the
2454 ClientHello or ServerHello messages, the extensions MAY appear in any
2455 order. There MUST NOT be more than one extension of the same type.
2457 Finally, note that extensions can be sent both when starting a new
2458 session and when requesting session resumption. Indeed, a client
2459 that requests session resumption does not in general know whether the
2460 server will accept this request, and therefore it SHOULD send the
2461 same extensions as it would send if it were not attempting
2462 resumption.
2466 Dierks & Rescorla Standards Track [Page 44]
2467 \f
2468 RFC 5246 TLS August 2008
2471 In general, the specification of each extension type needs to
2472 describe the effect of the extension both during full handshake and
2473 session resumption. Most current TLS extensions are relevant only
2474 when a session is initiated: when an older session is resumed, the
2475 server does not process these extensions in Client Hello, and does
2476 not include them in Server Hello. However, some extensions may
2477 specify different behavior during session resumption.
2479 There are subtle (and not so subtle) interactions that may occur in
2480 this protocol between new features and existing features which may
2481 result in a significant reduction in overall security. The following
2482 considerations should be taken into account when designing new
2483 extensions:
2485 - Some cases where a server does not agree to an extension are error
2486 conditions, and some are simply refusals to support particular
2487 features. In general, error alerts should be used for the former,
2488 and a field in the server extension response for the latter.
2490 - Extensions should, as far as possible, be designed to prevent any
2491 attack that forces use (or non-use) of a particular feature by
2492 manipulation of handshake messages. This principle should be
2493 followed regardless of whether the feature is believed to cause a
2494 security problem.
2496 Often the fact that the extension fields are included in the
2497 inputs to the Finished message hashes will be sufficient, but
2498 extreme care is needed when the extension changes the meaning of
2499 messages sent in the handshake phase. Designers and implementors
2500 should be aware of the fact that until the handshake has been
2501 authenticated, active attackers can modify messages and insert,
2502 remove, or replace extensions.
2504 - It would be technically possible to use extensions to change major
2505 aspects of the design of TLS; for example the design of cipher
2506 suite negotiation. This is not recommended; it would be more
2507 appropriate to define a new version of TLS -- particularly since
2508 the TLS handshake algorithms have specific protection against
2509 version rollback attacks based on the version number, and the
2510 possibility of version rollback should be a significant
2511 consideration in any major design change.
2513 7.4.1.4.1. Signature Algorithms
2515 The client uses the "signature_algorithms" extension to indicate to
2516 the server which signature/hash algorithm pairs may be used in
2517 digital signatures. The "extension_data" field of this extension
2518 contains a "supported_signature_algorithms" value.
2522 Dierks & Rescorla Standards Track [Page 45]
2523 \f
2524 RFC 5246 TLS August 2008
2527 enum {
2528 none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
2529 sha512(6), (255)
2530 } HashAlgorithm;
2532 enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
2533 SignatureAlgorithm;
2535 struct {
2536 HashAlgorithm hash;
2537 SignatureAlgorithm signature;
2538 } SignatureAndHashAlgorithm;
2540 SignatureAndHashAlgorithm
2541 supported_signature_algorithms<2..2^16-2>;
2543 Each SignatureAndHashAlgorithm value lists a single hash/signature
2544 pair that the client is willing to verify. The values are indicated
2545 in descending order of preference.
2547 Note: Because not all signature algorithms and hash algorithms may be
2548 accepted by an implementation (e.g., DSA with SHA-1, but not
2549 SHA-256), algorithms here are listed in pairs.
2551 hash
2552 This field indicates the hash algorithm which may be used. The
2553 values indicate support for unhashed data, MD5 [MD5], SHA-1,
2554 SHA-224, SHA-256, SHA-384, and SHA-512 [SHS], respectively. The
2555 "none" value is provided for future extensibility, in case of a
2556 signature algorithm which does not require hashing before signing.
2558 signature
2559 This field indicates the signature algorithm that may be used.
2560 The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
2561 [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively. The
2562 "anonymous" value is meaningless in this context but used in
2563 Section 7.4.3. It MUST NOT appear in this extension.
2565 The semantics of this extension are somewhat complicated because the
2566 cipher suite indicates permissible signature algorithms but not hash
2567 algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules.
2569 If the client supports only the default hash and signature algorithms
2570 (listed in this section), it MAY omit the signature_algorithms
2571 extension. If the client does not support the default algorithms, or
2572 supports other hash and signature algorithms (and it is willing to
2573 use them for verifying messages sent by the server, i.e., server
2574 certificates and server key exchange), it MUST send the
2578 Dierks & Rescorla Standards Track [Page 46]
2579 \f
2580 RFC 5246 TLS August 2008
2583 signature_algorithms extension, listing the algorithms it is willing
2584 to accept.
2586 If the client does not send the signature_algorithms extension, the
2587 server MUST do the following:
2589 - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
2590 DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
2591 sent the value {sha1,rsa}.
2593 - If the negotiated key exchange algorithm is one of (DHE_DSS,
2594 DH_DSS), behave as if the client had sent the value {sha1,dsa}.
2596 - If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
2597 ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
2599 Note: this is a change from TLS 1.1 where there are no explicit
2600 rules, but as a practical matter one can assume that the peer
2601 supports MD5 and SHA-1.
2603 Note: this extension is not meaningful for TLS versions prior to 1.2.
2604 Clients MUST NOT offer it if they are offering prior versions.
2605 However, even if clients do offer it, the rules specified in [TLSEXT]
2606 require servers to ignore extensions they do not understand.
2608 Servers MUST NOT send this extension. TLS servers MUST support
2609 receiving this extension.
2611 When performing session resumption, this extension is not included in
2612 Server Hello, and the server ignores the extension in Client Hello
2613 (if present).
2615 7.4.2. Server Certificate
2617 When this message will be sent:
2619 The server MUST send a Certificate message whenever the agreed-
2620 upon key exchange method uses certificates for authentication
2621 (this includes all key exchange methods defined in this document
2622 except DH_anon). This message will always immediately follow the
2623 ServerHello message.
2625 Meaning of this message:
2627 This message conveys the server's certificate chain to the client.
2629 The certificate MUST be appropriate for the negotiated cipher
2630 suite's key exchange algorithm and any negotiated extensions.
2634 Dierks & Rescorla Standards Track [Page 47]
2635 \f
2636 RFC 5246 TLS August 2008
2639 Structure of this message:
2641 opaque ASN.1Cert<1..2^24-1>;
2643 struct {
2644 ASN.1Cert certificate_list<0..2^24-1>;
2645 } Certificate;
2647 certificate_list
2648 This is a sequence (chain) of certificates. The sender's
2649 certificate MUST come first in the list. Each following
2650 certificate MUST directly certify the one preceding it. Because
2651 certificate validation requires that root keys be distributed
2652 independently, the self-signed certificate that specifies the root
2653 certificate authority MAY be omitted from the chain, under the
2654 assumption that the remote end must already possess it in order to
2655 validate it in any case.
2657 The same message type and structure will be used for the client's
2658 response to a certificate request message. Note that a client MAY
2659 send no certificates if it does not have an appropriate certificate
2660 to send in response to the server's authentication request.
2662 Note: PKCS #7 [PKCS7] is not used as the format for the certificate
2663 vector because PKCS #6 [PKCS6] extended certificates are not used.
2664 Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
2665 of parsing the list more difficult.
2667 The following rules apply to the certificates sent by the server:
2669 - The certificate type MUST be X.509v3, unless explicitly negotiated
2670 otherwise (e.g., [TLSPGP]).
2672 - The end entity certificate's public key (and associated
2673 restrictions) MUST be compatible with the selected key exchange
2674 algorithm.
2676 Key Exchange Alg. Certificate Key Type
2678 RSA RSA public key; the certificate MUST allow the
2679 RSA_PSK key to be used for encryption (the
2680 keyEncipherment bit MUST be set if the key
2681 usage extension is present).
2682 Note: RSA_PSK is defined in [TLSPSK].
2690 Dierks & Rescorla Standards Track [Page 48]
2691 \f
2692 RFC 5246 TLS August 2008
2695 DHE_RSA RSA public key; the certificate MUST allow the
2696 ECDHE_RSA key to be used for signing (the
2697 digitalSignature bit MUST be set if the key
2698 usage extension is present) with the signature
2699 scheme and hash algorithm that will be employed
2700 in the server key exchange message.
2701 Note: ECDHE_RSA is defined in [TLSECC].
2703 DHE_DSS DSA public key; the certificate MUST allow the
2704 key to be used for signing with the hash
2705 algorithm that will be employed in the server
2706 key exchange message.
2708 DH_DSS Diffie-Hellman public key; the keyAgreement bit
2709 DH_RSA MUST be set if the key usage extension is
2710 present.
2712 ECDH_ECDSA ECDH-capable public key; the public key MUST
2713 ECDH_RSA use a curve and point format supported by the
2714 client, as described in [TLSECC].
2716 ECDHE_ECDSA ECDSA-capable public key; the certificate MUST
2717 allow the key to be used for signing with the
2718 hash algorithm that will be employed in the
2719 server key exchange message. The public key
2720 MUST use a curve and point format supported by
2721 the client, as described in [TLSECC].
2723 - The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are
2724 used to guide certificate selection.
2726 If the client provided a "signature_algorithms" extension, then all
2727 certificates provided by the server MUST be signed by a
2728 hash/signature algorithm pair that appears in that extension. Note
2729 that this implies that a certificate containing a key for one
2730 signature algorithm MAY be signed using a different signature
2731 algorithm (for instance, an RSA key signed with a DSA key). This is
2732 a departure from TLS 1.1, which required that the algorithms be the
2733 same. Note that this also implies that the DH_DSS, DH_RSA,
2734 ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
2735 algorithm used to sign the certificate. Fixed DH certificates MAY be
2736 signed with any hash/signature algorithm pair appearing in the
2737 extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
2738 historical.
2746 Dierks & Rescorla Standards Track [Page 49]
2747 \f
2748 RFC 5246 TLS August 2008
2751 If the server has multiple certificates, it chooses one of them based
2752 on the above-mentioned criteria (in addition to other criteria, such
2753 as transport layer endpoint, local configuration and preferences,
2754 etc.). If the server has a single certificate, it SHOULD attempt to
2755 validate that it meets these criteria.
2757 Note that there are certificates that use algorithms and/or algorithm
2758 combinations that cannot be currently used with TLS. For example, a
2759 certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
2760 SubjectPublicKeyInfo) cannot be used because TLS defines no
2761 corresponding signature algorithm.
2763 As cipher suites that specify new key exchange methods are specified
2764 for the TLS protocol, they will imply the certificate format and the
2765 required encoded keying information.
2767 7.4.3. Server Key Exchange Message
2769 When this message will be sent:
2771 This message will be sent immediately after the server Certificate
2772 message (or the ServerHello message, if this is an anonymous
2773 negotiation).
2775 The ServerKeyExchange message is sent by the server only when the
2776 server Certificate message (if sent) does not contain enough data
2777 to allow the client to exchange a premaster secret. This is true
2778 for the following key exchange methods:
2780 DHE_DSS
2781 DHE_RSA
2782 DH_anon
2784 It is not legal to send the ServerKeyExchange message for the
2785 following key exchange methods:
2787 RSA
2788 DH_DSS
2789 DH_RSA
2791 Other key exchange algorithms, such as those defined in [TLSECC],
2792 MUST specify whether the ServerKeyExchange message is sent or not;
2793 and if the message is sent, its contents.
2802 Dierks & Rescorla Standards Track [Page 50]
2803 \f
2804 RFC 5246 TLS August 2008
2807 Meaning of this message:
2809 This message conveys cryptographic information to allow the client
2810 to communicate the premaster secret: a Diffie-Hellman public key
2811 with which the client can complete a key exchange (with the result
2812 being the premaster secret) or a public key for some other
2813 algorithm.
2815 Structure of this message:
2817 enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa
2818 /* may be extended, e.g., for ECDH -- see [TLSECC] */
2819 } KeyExchangeAlgorithm;
2821 struct {
2822 opaque dh_p<1..2^16-1>;
2823 opaque dh_g<1..2^16-1>;
2824 opaque dh_Ys<1..2^16-1>;
2825 } ServerDHParams; /* Ephemeral DH parameters */
2827 dh_p
2828 The prime modulus used for the Diffie-Hellman operation.
2830 dh_g
2831 The generator used for the Diffie-Hellman operation.
2833 dh_Ys
2834 The server's Diffie-Hellman public value (g^X mod p).
2858 Dierks & Rescorla Standards Track [Page 51]
2859 \f
2860 RFC 5246 TLS August 2008
2863 struct {
2864 select (KeyExchangeAlgorithm) {
2865 case dh_anon:
2866 ServerDHParams params;
2867 case dhe_dss:
2868 case dhe_rsa:
2869 ServerDHParams params;
2870 digitally-signed struct {
2871 opaque client_random[32];
2872 opaque server_random[32];
2873 ServerDHParams params;
2874 } signed_params;
2875 case rsa:
2876 case dh_dss:
2877 case dh_rsa:
2878 struct {} ;
2879 /* message is omitted for rsa, dh_dss, and dh_rsa */
2880 /* may be extended, e.g., for ECDH -- see [TLSECC] */
2881 };
2882 } ServerKeyExchange;
2884 params
2885 The server's key exchange parameters.
2887 signed_params
2888 For non-anonymous key exchanges, a signature over the server's
2889 key exchange parameters.
2891 If the client has offered the "signature_algorithms" extension, the
2892 signature algorithm and hash algorithm MUST be a pair listed in that
2893 extension. Note that there is a possibility for inconsistencies
2894 here. For instance, the client might offer DHE_DSS key exchange but
2895 omit any DSA pairs from its "signature_algorithms" extension. In
2896 order to negotiate correctly, the server MUST check any candidate
2897 cipher suites against the "signature_algorithms" extension before
2898 selecting them. This is somewhat inelegant but is a compromise
2899 designed to minimize changes to the original cipher suite design.
2901 In addition, the hash and signature algorithms MUST be compatible
2902 with the key in the server's end-entity certificate. RSA keys MAY be
2903 used with any permitted hash algorithm, subject to restrictions in
2904 the certificate, if any.
2906 Because DSA signatures do not contain any secure indication of hash
2907 algorithm, there is a risk of hash substitution if multiple hashes
2908 may be used with any key. Currently, DSA [DSS] may only be used with
2909 SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use
2910 of other digest algorithms with DSA, as well as guidance as to which
2914 Dierks & Rescorla Standards Track [Page 52]
2915 \f
2916 RFC 5246 TLS August 2008
2919 digest algorithms should be used with each key size. In addition,
2920 future revisions of [PKIX] may specify mechanisms for certificates to
2921 indicate which digest algorithms are to be used with DSA.
2923 As additional cipher suites are defined for TLS that include new key
2924 exchange algorithms, the server key exchange message will be sent if
2925 and only if the certificate type associated with the key exchange
2926 algorithm does not provide enough information for the client to
2927 exchange a premaster secret.
2929 7.4.4. Certificate Request
2931 When this message will be sent:
2933 A non-anonymous server can optionally request a certificate from
2934 the client, if appropriate for the selected cipher suite. This
2935 message, if sent, will immediately follow the ServerKeyExchange
2936 message (if it is sent; otherwise, this message follows the
2937 server's Certificate message).
2939 Structure of this message:
2941 enum {
2942 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
2943 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
2944 fortezza_dms_RESERVED(20), (255)
2945 } ClientCertificateType;
2947 opaque DistinguishedName<1..2^16-1>;
2949 struct {
2950 ClientCertificateType certificate_types<1..2^8-1>;
2951 SignatureAndHashAlgorithm
2952 supported_signature_algorithms<2^16-1>;
2953 DistinguishedName certificate_authorities<0..2^16-1>;
2954 } CertificateRequest;
2956 certificate_types
2957 A list of the types of certificate types that the client may
2958 offer.
2960 rsa_sign a certificate containing an RSA key
2961 dss_sign a certificate containing a DSA key
2962 rsa_fixed_dh a certificate containing a static DH key.
2963 dss_fixed_dh a certificate containing a static DH key
2970 Dierks & Rescorla Standards Track [Page 53]
2971 \f
2972 RFC 5246 TLS August 2008
2975 supported_signature_algorithms
2976 A list of the hash/signature algorithm pairs that the server is
2977 able to verify, listed in descending order of preference.
2979 certificate_authorities
2980 A list of the distinguished names [X501] of acceptable
2981 certificate_authorities, represented in DER-encoded format. These
2982 distinguished names may specify a desired distinguished name for a
2983 root CA or for a subordinate CA; thus, this message can be used to
2984 describe known roots as well as a desired authorization space. If
2985 the certificate_authorities list is empty, then the client MAY
2986 send any certificate of the appropriate ClientCertificateType,
2987 unless there is some external arrangement to the contrary.
2989 The interaction of the certificate_types and
2990 supported_signature_algorithms fields is somewhat complicated.
2991 certificate_types has been present in TLS since SSLv3, but was
2992 somewhat underspecified. Much of its functionality is superseded by
2993 supported_signature_algorithms. The following rules apply:
2995 - Any certificates provided by the client MUST be signed using a
2996 hash/signature algorithm pair found in
2997 supported_signature_algorithms.
2999 - The end-entity certificate provided by the client MUST contain a
3000 key that is compatible with certificate_types. If the key is a
3001 signature key, it MUST be usable with some hash/signature
3002 algorithm pair in supported_signature_algorithms.
3004 - For historical reasons, the names of some client certificate types
3005 include the algorithm used to sign the certificate. For example,
3006 in earlier versions of TLS, rsa_fixed_dh meant a certificate
3007 signed with RSA and containing a static DH key. In TLS 1.2, this
3008 functionality has been obsoleted by the
3009 supported_signature_algorithms, and the certificate type no longer
3010 restricts the algorithm used to sign the certificate. For
3011 example, if the server sends dss_fixed_dh certificate type and
3012 {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply
3013 with a certificate containing a static DH key, signed with RSA-
3014 SHA1.
3016 New ClientCertificateType values are assigned by IANA as described in
3017 Section 12.
3019 Note: Values listed as RESERVED may not be used. They were used in
3020 SSLv3.
3026 Dierks & Rescorla Standards Track [Page 54]
3027 \f
3028 RFC 5246 TLS August 2008
3031 Note: It is a fatal handshake_failure alert for an anonymous server
3032 to request client authentication.
3034 7.4.5. Server Hello Done
3036 When this message will be sent:
3038 The ServerHelloDone message is sent by the server to indicate the
3039 end of the ServerHello and associated messages. After sending
3040 this message, the server will wait for a client response.
3042 Meaning of this message:
3044 This message means that the server is done sending messages to
3045 support the key exchange, and the client can proceed with its
3046 phase of the key exchange.
3048 Upon receipt of the ServerHelloDone message, the client SHOULD
3049 verify that the server provided a valid certificate, if required,
3050 and check that the server hello parameters are acceptable.
3052 Structure of this message:
3054 struct { } ServerHelloDone;
3056 7.4.6. Client Certificate
3058 When this message will be sent:
3060 This is the first message the client can send after receiving a
3061 ServerHelloDone message. This message is only sent if the server
3062 requests a certificate. If no suitable certificate is available,
3063 the client MUST send a certificate message containing no
3064 certificates. That is, the certificate_list structure has a
3065 length of zero. If the client does not send any certificates, the
3066 server MAY at its discretion either continue the handshake without
3067 client authentication, or respond with a fatal handshake_failure
3068 alert. Also, if some aspect of the certificate chain was
3069 unacceptable (e.g., it was not signed by a known, trusted CA), the
3070 server MAY at its discretion either continue the handshake
3071 (considering the client unauthenticated) or send a fatal alert.
3073 Client certificates are sent using the Certificate structure
3074 defined in Section 7.4.2.
3082 Dierks & Rescorla Standards Track [Page 55]
3083 \f
3084 RFC 5246 TLS August 2008
3087 Meaning of this message:
3089 This message conveys the client's certificate chain to the server;
3090 the server will use it when verifying the CertificateVerify
3091 message (when the client authentication is based on signing) or
3092 calculating the premaster secret (for non-ephemeral Diffie-
3093 Hellman). The certificate MUST be appropriate for the negotiated
3094 cipher suite's key exchange algorithm, and any negotiated
3095 extensions.
3097 In particular:
3099 - The certificate type MUST be X.509v3, unless explicitly negotiated
3100 otherwise (e.g., [TLSPGP]).
3102 - The end-entity certificate's public key (and associated
3103 restrictions) has to be compatible with the certificate types
3104 listed in CertificateRequest:
3106 Client Cert. Type Certificate Key Type
3108 rsa_sign RSA public key; the certificate MUST allow the
3109 key to be used for signing with the signature
3110 scheme and hash algorithm that will be
3111 employed in the certificate verify message.
3113 dss_sign DSA public key; the certificate MUST allow the
3114 key to be used for signing with the hash
3115 algorithm that will be employed in the
3116 certificate verify message.
3118 ecdsa_sign ECDSA-capable public key; the certificate MUST
3119 allow the key to be used for signing with the
3120 hash algorithm that will be employed in the
3121 certificate verify message; the public key
3122 MUST use a curve and point format supported by
3123 the server.
3125 rsa_fixed_dh Diffie-Hellman public key; MUST use the same
3126 dss_fixed_dh parameters as server's key.
3128 rsa_fixed_ecdh ECDH-capable public key; MUST use the
3129 ecdsa_fixed_ecdh same curve as the server's key, and MUST use a
3130 point format supported by the server.
3132 - If the certificate_authorities list in the certificate request
3133 message was non-empty, one of the certificates in the certificate
3134 chain SHOULD be issued by one of the listed CAs.
3138 Dierks & Rescorla Standards Track [Page 56]
3139 \f
3140 RFC 5246 TLS August 2008
3143 - The certificates MUST be signed using an acceptable hash/
3144 signature algorithm pair, as described in Section 7.4.4. Note
3145 that this relaxes the constraints on certificate-signing
3146 algorithms found in prior versions of TLS.
3148 Note that, as with the server certificate, there are certificates
3149 that use algorithms/algorithm combinations that cannot be currently
3150 used with TLS.
3152 7.4.7. Client Key Exchange Message
3154 When this message will be sent:
3156 This message is always sent by the client. It MUST immediately
3157 follow the client certificate message, if it is sent. Otherwise,
3158 it MUST be the first message sent by the client after it receives
3159 the ServerHelloDone message.
3161 Meaning of this message:
3163 With this message, the premaster secret is set, either by direct
3164 transmission of the RSA-encrypted secret or by the transmission of
3165 Diffie-Hellman parameters that will allow each side to agree upon
3166 the same premaster secret.
3168 When the client is using an ephemeral Diffie-Hellman exponent,
3169 then this message contains the client's Diffie-Hellman public
3170 value. If the client is sending a certificate containing a static
3171 DH exponent (i.e., it is doing fixed_dh client authentication),
3172 then this message MUST be sent but MUST be empty.
3174 Structure of this message:
3176 The choice of messages depends on which key exchange method has
3177 been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
3178 definition.
3194 Dierks & Rescorla Standards Track [Page 57]
3195 \f
3196 RFC 5246 TLS August 2008
3199 struct {
3200 select (KeyExchangeAlgorithm) {
3201 case rsa:
3202 EncryptedPreMasterSecret;
3203 case dhe_dss:
3204 case dhe_rsa:
3205 case dh_dss:
3206 case dh_rsa:
3207 case dh_anon:
3208 ClientDiffieHellmanPublic;
3209 } exchange_keys;
3210 } ClientKeyExchange;
3212 7.4.7.1. RSA-Encrypted Premaster Secret Message
3214 Meaning of this message:
3216 If RSA is being used for key agreement and authentication, the
3217 client generates a 48-byte premaster secret, encrypts it using the
3218 public key from the server's certificate, and sends the result in
3219 an encrypted premaster secret message. This structure is a
3220 variant of the ClientKeyExchange message and is not a message in
3221 itself.
3223 Structure of this message:
3225 struct {
3226 ProtocolVersion client_version;
3227 opaque random[46];
3228 } PreMasterSecret;
3230 client_version
3231 The latest (newest) version supported by the client. This is
3232 used to detect version rollback attacks.
3234 random
3235 46 securely-generated random bytes.
3237 struct {
3238 public-key-encrypted PreMasterSecret pre_master_secret;
3239 } EncryptedPreMasterSecret;
3241 pre_master_secret
3242 This random value is generated by the client and is used to
3243 generate the master secret, as specified in Section 8.1.
3250 Dierks & Rescorla Standards Track [Page 58]
3251 \f
3252 RFC 5246 TLS August 2008
3255 Note: The version number in the PreMasterSecret is the version
3256 offered by the client in the ClientHello.client_version, not the
3257 version negotiated for the connection. This feature is designed to
3258 prevent rollback attacks. Unfortunately, some old implementations
3259 use the negotiated version instead, and therefore checking the
3260 version number may lead to failure to interoperate with such
3261 incorrect client implementations.
3263 Client implementations MUST always send the correct version number in
3264 PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher,
3265 server implementations MUST check the version number as described in
3266 the note below. If the version number is TLS 1.0 or earlier, server
3267 implementations SHOULD check the version number, but MAY have a
3268 configuration option to disable the check. Note that if the check
3269 fails, the PreMasterSecret SHOULD be randomized as described below.
3271 Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
3272 [KPR03] can be used to attack a TLS server that reveals whether a
3273 particular message, when decrypted, is properly PKCS#1 formatted,
3274 contains a valid PreMasterSecret structure, or has the correct
3275 version number.
3277 As described by Klima [KPR03], these vulnerabilities can be avoided
3278 by treating incorrectly formatted message blocks and/or mismatched
3279 version numbers in a manner indistinguishable from correctly
3280 formatted RSA blocks. In other words:
3282 1. Generate a string R of 46 random bytes
3284 2. Decrypt the message to recover the plaintext M
3286 3. If the PKCS#1 padding is not correct, or the length of message
3287 M is not exactly 48 bytes:
3288 pre_master_secret = ClientHello.client_version || R
3289 else If ClientHello.client_version <= TLS 1.0, and version
3290 number check is explicitly disabled:
3291 pre_master_secret = M
3292 else:
3293 pre_master_secret = ClientHello.client_version || M[2..47]
3295 Note that explicitly constructing the pre_master_secret with the
3296 ClientHello.client_version produces an invalid master_secret if the
3297 client has sent the wrong version in the original pre_master_secret.
3299 An alternative approach is to treat a version number mismatch as a
3300 PKCS-1 formatting error and randomize the premaster secret
3301 completely:
3306 Dierks & Rescorla Standards Track [Page 59]
3307 \f
3308 RFC 5246 TLS August 2008
3311 1. Generate a string R of 48 random bytes
3313 2. Decrypt the message to recover the plaintext M
3315 3. If the PKCS#1 padding is not correct, or the length of message
3316 M is not exactly 48 bytes:
3317 pre_master_secret = R
3318 else If ClientHello.client_version <= TLS 1.0, and version
3319 number check is explicitly disabled:
3320 premaster secret = M
3321 else If M[0..1] != ClientHello.client_version:
3322 premaster secret = R
3323 else:
3324 premaster secret = M
3326 Although no practical attacks against this construction are known,
3327 Klima et al. [KPR03] describe some theoretical attacks, and therefore
3328 the first construction described is RECOMMENDED.
3330 In any case, a TLS server MUST NOT generate an alert if processing an
3331 RSA-encrypted premaster secret message fails, or the version number
3332 is not as expected. Instead, it MUST continue the handshake with a
3333 randomly generated premaster secret. It may be useful to log the
3334 real cause of failure for troubleshooting purposes; however, care
3335 must be taken to avoid leaking the information to an attacker
3336 (through, e.g., timing, log files, or other channels.)
3338 The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
3339 against the Bleichenbacher attack. However, for maximal
3340 compatibility with earlier versions of TLS, this specification uses
3341 the RSAES-PKCS1-v1_5 scheme. No variants of the Bleichenbacher
3342 attack are known to exist provided that the above recommendations are
3343 followed.
3345 Implementation note: Public-key-encrypted data is represented as an
3346 opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
3347 PreMasterSecret in a ClientKeyExchange is preceded by two length
3348 bytes. These bytes are redundant in the case of RSA because the
3349 EncryptedPreMasterSecret is the only data in the ClientKeyExchange
3350 and its length can therefore be unambiguously determined. The SSLv3
3351 specification was not clear about the encoding of public-key-
3352 encrypted data, and therefore many SSLv3 implementations do not
3353 include the length bytes -- they encode the RSA-encrypted data
3354 directly in the ClientKeyExchange message.
3356 This specification requires correct encoding of the
3357 EncryptedPreMasterSecret complete with length bytes. The resulting
3358 PDU is incompatible with many SSLv3 implementations. Implementors
3362 Dierks & Rescorla Standards Track [Page 60]
3363 \f
3364 RFC 5246 TLS August 2008
3367 upgrading from SSLv3 MUST modify their implementations to generate
3368 and accept the correct encoding. Implementors who wish to be
3369 compatible with both SSLv3 and TLS should make their implementation's
3370 behavior dependent on the protocol version.
3372 Implementation note: It is now known that remote timing-based attacks
3373 on TLS are possible, at least when the client and server are on the
3374 same LAN. Accordingly, implementations that use static RSA keys MUST
3375 use RSA blinding or some other anti-timing technique, as described in
3376 [TIMING].
3378 7.4.7.2. Client Diffie-Hellman Public Value
3380 Meaning of this message:
3382 This structure conveys the client's Diffie-Hellman public value
3383 (Yc) if it was not already included in the client's certificate.
3384 The encoding used for Yc is determined by the enumerated
3385 PublicValueEncoding. This structure is a variant of the client
3386 key exchange message, and not a message in itself.
3388 Structure of this message:
3390 enum { implicit, explicit } PublicValueEncoding;
3392 implicit
3393 If the client has sent a certificate which contains a suitable
3394 Diffie-Hellman key (for fixed_dh client authentication), then
3395 Yc is implicit and does not need to be sent again. In this
3396 case, the client key exchange message will be sent, but it MUST
3397 be empty.
3399 explicit
3400 Yc needs to be sent.
3402 struct {
3403 select (PublicValueEncoding) {
3404 case implicit: struct { };
3405 case explicit: opaque dh_Yc<1..2^16-1>;
3406 } dh_public;
3407 } ClientDiffieHellmanPublic;
3409 dh_Yc
3410 The client's Diffie-Hellman public value (Yc).
3418 Dierks & Rescorla Standards Track [Page 61]
3419 \f
3420 RFC 5246 TLS August 2008
3423 7.4.8. Certificate Verify
3425 When this message will be sent:
3427 This message is used to provide explicit verification of a client
3428 certificate. This message is only sent following a client
3429 certificate that has signing capability (i.e., all certificates
3430 except those containing fixed Diffie-Hellman parameters). When
3431 sent, it MUST immediately follow the client key exchange message.
3433 Structure of this message:
3435 struct {
3436 digitally-signed struct {
3437 opaque handshake_messages[handshake_messages_length];
3438 }
3439 } CertificateVerify;
3441 Here handshake_messages refers to all handshake messages sent or
3442 received, starting at client hello and up to, but not including,
3443 this message, including the type and length fields of the
3444 handshake messages. This is the concatenation of all the
3445 Handshake structures (as defined in Section 7.4) exchanged thus
3446 far. Note that this requires both sides to either buffer the
3447 messages or compute running hashes for all potential hash
3448 algorithms up to the time of the CertificateVerify computation.
3449 Servers can minimize this computation cost by offering a
3450 restricted set of digest algorithms in the CertificateRequest
3451 message.
3453 The hash and signature algorithms used in the signature MUST be
3454 one of those present in the supported_signature_algorithms field
3455 of the CertificateRequest message. In addition, the hash and
3456 signature algorithms MUST be compatible with the key in the
3457 client's end-entity certificate. RSA keys MAY be used with any
3458 permitted hash algorithm, subject to restrictions in the
3459 certificate, if any.
3461 Because DSA signatures do not contain any secure indication of
3462 hash algorithm, there is a risk of hash substitution if multiple
3463 hashes may be used with any key. Currently, DSA [DSS] may only be
3464 used with SHA-1. Future revisions of DSS [DSS-3] are expected to
3465 allow the use of other digest algorithms with DSA, as well as
3466 guidance as to which digest algorithms should be used with each
3467 key size. In addition, future revisions of [PKIX] may specify
3468 mechanisms for certificates to indicate which digest algorithms
3469 are to be used with DSA.
3474 Dierks & Rescorla Standards Track [Page 62]
3475 \f
3476 RFC 5246 TLS August 2008
3479 7.4.9. Finished
3481 When this message will be sent:
3483 A Finished message is always sent immediately after a change
3484 cipher spec message to verify that the key exchange and
3485 authentication processes were successful. It is essential that a
3486 change cipher spec message be received between the other handshake
3487 messages and the Finished message.
3489 Meaning of this message:
3491 The Finished message is the first one protected with the just
3492 negotiated algorithms, keys, and secrets. Recipients of Finished
3493 messages MUST verify that the contents are correct. Once a side
3494 has sent its Finished message and received and validated the
3495 Finished message from its peer, it may begin to send and receive
3496 application data over the connection.
3498 Structure of this message:
3500 struct {
3501 opaque verify_data[verify_data_length];
3502 } Finished;
3504 verify_data
3505 PRF(master_secret, finished_label, Hash(handshake_messages))
3506 [0..verify_data_length-1];
3508 finished_label
3509 For Finished messages sent by the client, the string
3510 "client finished". For Finished messages sent by the server,
3511 the string "server finished".
3513 Hash denotes a Hash of the handshake messages. For the PRF
3514 defined in Section 5, the Hash MUST be the Hash used as the basis
3515 for the PRF. Any cipher suite which defines a different PRF MUST
3516 also define the Hash to use in the Finished computation.
3518 In previous versions of TLS, the verify_data was always 12 octets
3519 long. In the current version of TLS, it depends on the cipher
3520 suite. Any cipher suite which does not explicitly specify
3521 verify_data_length has a verify_data_length equal to 12. This
3522 includes all existing cipher suites. Note that this
3523 representation has the same encoding as with previous versions.
3524 Future cipher suites MAY specify other lengths but such length
3525 MUST be at least 12 bytes.
3530 Dierks & Rescorla Standards Track [Page 63]
3531 \f
3532 RFC 5246 TLS August 2008
3535 handshake_messages
3536 All of the data from all messages in this handshake (not
3537 including any HelloRequest messages) up to, but not including,
3538 this message. This is only data visible at the handshake layer
3539 and does not include record layer headers. This is the
3540 concatenation of all the Handshake structures as defined in
3541 Section 7.4, exchanged thus far.
3543 It is a fatal error if a Finished message is not preceded by a
3544 ChangeCipherSpec message at the appropriate point in the handshake.
3546 The value handshake_messages includes all handshake messages starting
3547 at ClientHello up to, but not including, this Finished message. This
3548 may be different from handshake_messages in Section 7.4.8 because it
3549 would include the CertificateVerify message (if sent). Also, the
3550 handshake_messages for the Finished message sent by the client will
3551 be different from that for the Finished message sent by the server,
3552 because the one that is sent second will include the prior one.
3554 Note: ChangeCipherSpec messages, alerts, and any other record types
3555 are not handshake messages and are not included in the hash
3556 computations. Also, HelloRequest messages are omitted from handshake
3557 hashes.
3559 8. Cryptographic Computations
3561 In order to begin connection protection, the TLS Record Protocol
3562 requires specification of a suite of algorithms, a master secret, and
3563 the client and server random values. The authentication, encryption,
3564 and MAC algorithms are determined by the cipher_suite selected by the
3565 server and revealed in the ServerHello message. The compression
3566 algorithm is negotiated in the hello messages, and the random values
3567 are exchanged in the hello messages. All that remains is to
3568 calculate the master secret.
3570 8.1. Computing the Master Secret
3572 For all key exchange methods, the same algorithm is used to convert
3573 the pre_master_secret into the master_secret. The pre_master_secret
3574 should be deleted from memory once the master_secret has been
3575 computed.
3577 master_secret = PRF(pre_master_secret, "master secret",
3578 ClientHello.random + ServerHello.random)
3579 [0..47];
3581 The master secret is always exactly 48 bytes in length. The length
3582 of the premaster secret will vary depending on key exchange method.
3586 Dierks & Rescorla Standards Track [Page 64]
3587 \f
3588 RFC 5246 TLS August 2008
3591 8.1.1. RSA
3593 When RSA is used for server authentication and key exchange, a 48-
3594 byte pre_master_secret is generated by the client, encrypted under
3595 the server's public key, and sent to the server. The server uses its
3596 private key to decrypt the pre_master_secret. Both parties then
3597 convert the pre_master_secret into the master_secret, as specified
3598 above.
3600 8.1.2. Diffie-Hellman
3602 A conventional Diffie-Hellman computation is performed. The
3603 negotiated key (Z) is used as the pre_master_secret, and is converted
3604 into the master_secret, as specified above. Leading bytes of Z that
3605 contain all zero bits are stripped before it is used as the
3606 pre_master_secret.
3608 Note: Diffie-Hellman parameters are specified by the server and may
3609 be either ephemeral or contained within the server's certificate.
3611 9. Mandatory Cipher Suites
3613 In the absence of an application profile standard specifying
3614 otherwise, a TLS-compliant application MUST implement the cipher
3615 suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the
3616 definition).
3618 10. Application Data Protocol
3620 Application data messages are carried by the record layer and are
3621 fragmented, compressed, and encrypted based on the current connection
3622 state. The messages are treated as transparent data to the record
3623 layer.
3625 11. Security Considerations
3627 Security issues are discussed throughout this memo, especially in
3628 Appendices D, E, and F.
3630 12. IANA Considerations
3632 This document uses several registries that were originally created in
3633 [TLS1.1]. IANA has updated these to reference this document. The
3634 registries and their allocation policies (unchanged from [TLS1.1])
3635 are listed below.
3642 Dierks & Rescorla Standards Track [Page 65]
3643 \f
3644 RFC 5246 TLS August 2008
3647 - TLS ClientCertificateType Identifiers Registry: Future values in
3648 the range 0-63 (decimal) inclusive are assigned via Standards
3649 Action [RFC2434]. Values in the range 64-223 (decimal) inclusive
3650 are assigned via Specification Required [RFC2434]. Values from
3651 224-255 (decimal) inclusive are reserved for Private Use
3652 [RFC2434].
3654 - TLS Cipher Suite Registry: Future values with the first byte in
3655 the range 0-191 (decimal) inclusive are assigned via Standards
3656 Action [RFC2434]. Values with the first byte in the range 192-254
3657 (decimal) are assigned via Specification Required [RFC2434].
3658 Values with the first byte 255 (decimal) are reserved for Private
3659 Use [RFC2434].
3661 - This document defines several new HMAC-SHA256-based cipher suites,
3662 whose values (in Appendix A.5) have been allocated from the TLS
3663 Cipher Suite registry.
3665 - TLS ContentType Registry: Future values are allocated via
3666 Standards Action [RFC2434].
3668 - TLS Alert Registry: Future values are allocated via Standards
3669 Action [RFC2434].
3671 - TLS HandshakeType Registry: Future values are allocated via
3672 Standards Action [RFC2434].
3674 This document also uses a registry originally created in [RFC4366].
3675 IANA has updated it to reference this document. The registry and its
3676 allocation policy (unchanged from [RFC4366]) is listed below:
3678 - TLS ExtensionType Registry: Future values are allocated via IETF
3679 Consensus [RFC2434]. IANA has updated this registry to include
3680 the signature_algorithms extension and its corresponding value
3681 (see Section 7.4.1.4).
3683 In addition, this document defines two new registries to be
3684 maintained by IANA:
3686 - TLS SignatureAlgorithm Registry: The registry has been initially
3687 populated with the values described in Section 7.4.1.4.1. Future
3688 values in the range 0-63 (decimal) inclusive are assigned via
3689 Standards Action [RFC2434]. Values in the range 64-223 (decimal)
3690 inclusive are assigned via Specification Required [RFC2434].
3691 Values from 224-255 (decimal) inclusive are reserved for Private
3692 Use [RFC2434].
3698 Dierks & Rescorla Standards Track [Page 66]
3699 \f
3700 RFC 5246 TLS August 2008
3703 - TLS HashAlgorithm Registry: The registry has been initially
3704 populated with the values described in Section 7.4.1.4.1. Future
3705 values in the range 0-63 (decimal) inclusive are assigned via
3706 Standards Action [RFC2434]. Values in the range 64-223 (decimal)
3707 inclusive are assigned via Specification Required [RFC2434].
3708 Values from 224-255 (decimal) inclusive are reserved for Private
3709 Use [RFC2434].
3711 This document also uses the TLS Compression Method Identifiers
3712 Registry, defined in [RFC3749]. IANA has allocated value 0 for
3713 the "null" compression method.
3754 Dierks & Rescorla Standards Track [Page 67]
3755 \f
3756 RFC 5246 TLS August 2008
3759 Appendix A. Protocol Data Structures and Constant Values
3761 This section describes protocol types and constants.
3763 A.1. Record Layer
3765 struct {
3766 uint8 major;
3767 uint8 minor;
3768 } ProtocolVersion;
3770 ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/
3772 enum {
3773 change_cipher_spec(20), alert(21), handshake(22),
3774 application_data(23), (255)
3775 } ContentType;
3777 struct {
3778 ContentType type;
3779 ProtocolVersion version;
3780 uint16 length;
3781 opaque fragment[TLSPlaintext.length];
3782 } TLSPlaintext;
3784 struct {
3785 ContentType type;
3786 ProtocolVersion version;
3787 uint16 length;
3788 opaque fragment[TLSCompressed.length];
3789 } TLSCompressed;
3791 struct {
3792 ContentType type;
3793 ProtocolVersion version;
3794 uint16 length;
3795 select (SecurityParameters.cipher_type) {
3796 case stream: GenericStreamCipher;
3797 case block: GenericBlockCipher;
3798 case aead: GenericAEADCipher;
3799 } fragment;
3800 } TLSCiphertext;
3802 stream-ciphered struct {
3803 opaque content[TLSCompressed.length];
3804 opaque MAC[SecurityParameters.mac_length];
3805 } GenericStreamCipher;
3810 Dierks & Rescorla Standards Track [Page 68]
3811 \f
3812 RFC 5246 TLS August 2008
3815 struct {
3816 opaque IV[SecurityParameters.record_iv_length];
3817 block-ciphered struct {
3818 opaque content[TLSCompressed.length];
3819 opaque MAC[SecurityParameters.mac_length];
3820 uint8 padding[GenericBlockCipher.padding_length];
3821 uint8 padding_length;
3822 };
3823 } GenericBlockCipher;
3825 struct {
3826 opaque nonce_explicit[SecurityParameters.record_iv_length];
3827 aead-ciphered struct {
3828 opaque content[TLSCompressed.length];
3829 };
3830 } GenericAEADCipher;
3832 A.2. Change Cipher Specs Message
3834 struct {
3835 enum { change_cipher_spec(1), (255) } type;
3836 } ChangeCipherSpec;
3838 A.3. Alert Messages
3840 enum { warning(1), fatal(2), (255) } AlertLevel;
3842 enum {
3843 close_notify(0),
3844 unexpected_message(10),
3845 bad_record_mac(20),
3846 decryption_failed_RESERVED(21),
3847 record_overflow(22),
3848 decompression_failure(30),
3849 handshake_failure(40),
3850 no_certificate_RESERVED(41),
3851 bad_certificate(42),
3852 unsupported_certificate(43),
3853 certificate_revoked(44),
3854 certificate_expired(45),
3855 certificate_unknown(46),
3856 illegal_parameter(47),
3857 unknown_ca(48),
3858 access_denied(49),
3859 decode_error(50),
3860 decrypt_error(51),
3861 export_restriction_RESERVED(60),
3862 protocol_version(70),
3866 Dierks & Rescorla Standards Track [Page 69]
3867 \f
3868 RFC 5246 TLS August 2008
3871 insufficient_security(71),
3872 internal_error(80),
3873 user_canceled(90),
3874 no_renegotiation(100),
3875 unsupported_extension(110), /* new */
3876 (255)
3877 } AlertDescription;
3879 struct {
3880 AlertLevel level;
3881 AlertDescription description;
3882 } Alert;
3884 A.4. Handshake Protocol
3886 enum {
3887 hello_request(0), client_hello(1), server_hello(2),
3888 certificate(11), server_key_exchange (12),
3889 certificate_request(13), server_hello_done(14),
3890 certificate_verify(15), client_key_exchange(16),
3891 finished(20)
3892 (255)
3893 } HandshakeType;
3895 struct {
3896 HandshakeType msg_type;
3897 uint24 length;
3898 select (HandshakeType) {
3899 case hello_request: HelloRequest;
3900 case client_hello: ClientHello;
3901 case server_hello: ServerHello;
3902 case certificate: Certificate;
3903 case server_key_exchange: ServerKeyExchange;
3904 case certificate_request: CertificateRequest;
3905 case server_hello_done: ServerHelloDone;
3906 case certificate_verify: CertificateVerify;
3907 case client_key_exchange: ClientKeyExchange;
3908 case finished: Finished;
3909 } body;
3910 } Handshake;
3922 Dierks & Rescorla Standards Track [Page 70]
3923 \f
3924 RFC 5246 TLS August 2008
3927 A.4.1. Hello Messages
3929 struct { } HelloRequest;
3931 struct {
3932 uint32 gmt_unix_time;
3933 opaque random_bytes[28];
3934 } Random;
3936 opaque SessionID<0..32>;
3938 uint8 CipherSuite[2];
3940 enum { null(0), (255) } CompressionMethod;
3942 struct {
3943 ProtocolVersion client_version;
3944 Random random;
3945 SessionID session_id;
3946 CipherSuite cipher_suites<2..2^16-2>;
3947 CompressionMethod compression_methods<1..2^8-1>;
3948 select (extensions_present) {
3949 case false:
3950 struct {};
3951 case true:
3952 Extension extensions<0..2^16-1>;
3953 };
3954 } ClientHello;
3956 struct {
3957 ProtocolVersion server_version;
3958 Random random;
3959 SessionID session_id;
3960 CipherSuite cipher_suite;
3961 CompressionMethod compression_method;
3962 select (extensions_present) {
3963 case false:
3964 struct {};
3965 case true:
3966 Extension extensions<0..2^16-1>;
3967 };
3968 } ServerHello;
3970 struct {
3971 ExtensionType extension_type;
3972 opaque extension_data<0..2^16-1>;
3973 } Extension;
3978 Dierks & Rescorla Standards Track [Page 71]
3979 \f
3980 RFC 5246 TLS August 2008
3983 enum {
3984 signature_algorithms(13), (65535)
3985 } ExtensionType;
3987 enum{
3988 none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
3989 sha512(6), (255)
3990 } HashAlgorithm;
3991 enum {
3992 anonymous(0), rsa(1), dsa(2), ecdsa(3), (255)
3993 } SignatureAlgorithm;
3995 struct {
3996 HashAlgorithm hash;
3997 SignatureAlgorithm signature;
3998 } SignatureAndHashAlgorithm;
4000 SignatureAndHashAlgorithm
4001 supported_signature_algorithms<2..2^16-1>;
4003 A.4.2. Server Authentication and Key Exchange Messages
4005 opaque ASN.1Cert<2^24-1>;
4007 struct {
4008 ASN.1Cert certificate_list<0..2^24-1>;
4009 } Certificate;
4011 enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa
4012 /* may be extended, e.g., for ECDH -- see [TLSECC] */
4013 } KeyExchangeAlgorithm;
4015 struct {
4016 opaque dh_p<1..2^16-1>;
4017 opaque dh_g<1..2^16-1>;
4018 opaque dh_Ys<1..2^16-1>;
4019 } ServerDHParams; /* Ephemeral DH parameters */
4034 Dierks & Rescorla Standards Track [Page 72]
4035 \f
4036 RFC 5246 TLS August 2008
4039 struct {
4040 select (KeyExchangeAlgorithm) {
4041 case dh_anon:
4042 ServerDHParams params;
4043 case dhe_dss:
4044 case dhe_rsa:
4045 ServerDHParams params;
4046 digitally-signed struct {
4047 opaque client_random[32];
4048 opaque server_random[32];
4049 ServerDHParams params;
4050 } signed_params;
4051 case rsa:
4052 case dh_dss:
4053 case dh_rsa:
4054 struct {} ;
4055 /* message is omitted for rsa, dh_dss, and dh_rsa */
4056 /* may be extended, e.g., for ECDH -- see [TLSECC] */
4057 } ServerKeyExchange;
4059 enum {
4060 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
4061 rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
4062 fortezza_dms_RESERVED(20),
4063 (255)
4064 } ClientCertificateType;
4066 opaque DistinguishedName<1..2^16-1>;
4068 struct {
4069 ClientCertificateType certificate_types<1..2^8-1>;
4070 DistinguishedName certificate_authorities<0..2^16-1>;
4071 } CertificateRequest;
4073 struct { } ServerHelloDone;
4090 Dierks & Rescorla Standards Track [Page 73]
4091 \f
4092 RFC 5246 TLS August 2008
4095 A.4.3. Client Authentication and Key Exchange Messages
4097 struct {
4098 select (KeyExchangeAlgorithm) {
4099 case rsa:
4100 EncryptedPreMasterSecret;
4101 case dhe_dss:
4102 case dhe_rsa:
4103 case dh_dss:
4104 case dh_rsa:
4105 case dh_anon:
4106 ClientDiffieHellmanPublic;
4107 } exchange_keys;
4108 } ClientKeyExchange;
4110 struct {
4111 ProtocolVersion client_version;
4112 opaque random[46];
4113 } PreMasterSecret;
4115 struct {
4116 public-key-encrypted PreMasterSecret pre_master_secret;
4117 } EncryptedPreMasterSecret;
4119 enum { implicit, explicit } PublicValueEncoding;
4121 struct {
4122 select (PublicValueEncoding) {
4123 case implicit: struct {};
4124 case explicit: opaque DH_Yc<1..2^16-1>;
4125 } dh_public;
4126 } ClientDiffieHellmanPublic;
4128 struct {
4129 digitally-signed struct {
4130 opaque handshake_messages[handshake_messages_length];
4131 }
4132 } CertificateVerify;
4134 A.4.4. Handshake Finalization Message
4136 struct {
4137 opaque verify_data[verify_data_length];
4138 } Finished;
4146 Dierks & Rescorla Standards Track [Page 74]
4147 \f
4148 RFC 5246 TLS August 2008
4151 A.5. The Cipher Suite
4153 The following values define the cipher suite codes used in the
4154 ClientHello and ServerHello messages.
4156 A cipher suite defines a cipher specification supported in TLS
4157 Version 1.2.
4159 TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
4160 TLS connection during the first handshake on that channel, but MUST
4161 NOT be negotiated, as it provides no more protection than an
4162 unsecured connection.
4164 CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
4166 The following CipherSuite definitions require that the server provide
4167 an RSA certificate that can be used for key exchange. The server may
4168 request any signature-capable certificate in the certificate request
4169 message.
4171 CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
4172 CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
4173 CipherSuite TLS_RSA_WITH_NULL_SHA256 = { 0x00,0x3B };
4174 CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
4175 CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
4176 CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
4177 CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F };
4178 CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
4179 CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3C };
4180 CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
4182 The following cipher suite definitions are used for server-
4183 authenticated (and optionally client-authenticated) Diffie-Hellman.
4184 DH denotes cipher suites in which the server's certificate contains
4185 the Diffie-Hellman parameters signed by the certificate authority
4186 (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
4187 parameters are signed by a signature-capable certificate, which has
4188 been signed by the CA. The signing algorithm used by the server is
4189 specified after the DHE component of the CipherSuite name. The
4190 server can request any signature-capable certificate from the client
4191 for client authentication, or it may request a Diffie-Hellman
4192 certificate. Any Diffie-Hellman certificate provided by the client
4193 must use the parameters (group and generator) described by the
4194 server.
4202 Dierks & Rescorla Standards Track [Page 75]
4203 \f
4204 RFC 5246 TLS August 2008
4207 CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
4208 CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
4209 CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
4210 CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
4211 CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 };
4212 CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 };
4213 CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 };
4214 CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 };
4215 CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 };
4216 CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 };
4217 CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 };
4218 CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 };
4219 CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x3E };
4220 CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3F };
4221 CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x40 };
4222 CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x67 };
4223 CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x68 };
4224 CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x69 };
4225 CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x6A };
4226 CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x6B };
4228 The following cipher suites are used for completely anonymous
4229 Diffie-Hellman communications in which neither party is
4230 authenticated. Note that this mode is vulnerable to man-in-the-
4231 middle attacks. Using this mode therefore is of limited use: These
4232 cipher suites MUST NOT be used by TLS 1.2 implementations unless the
4233 application layer has specifically requested to allow anonymous key
4234 exchange. (Anonymous key exchange may sometimes be acceptable, for
4235 example, to support opportunistic encryption when no set-up for
4236 authentication is in place, or when TLS is used as part of more
4237 complex security protocols that have other means to ensure
4238 authentication.)
4240 CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
4241 CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
4242 CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 };
4243 CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A };
4244 CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,0x6C };
4245 CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,0x6D };
4247 Note that using non-anonymous key exchange without actually verifying
4248 the key exchange is essentially equivalent to anonymous key exchange,
4249 and the same precautions apply. While non-anonymous key exchange
4250 will generally involve a higher computational and communicational
4251 cost than anonymous key exchange, it may be in the interest of
4252 interoperability not to disable non-anonymous key exchange when the
4253 application layer is allowing anonymous key exchange.
4258 Dierks & Rescorla Standards Track [Page 76]
4259 \f
4260 RFC 5246 TLS August 2008
4263 New cipher suite values have been assigned by IANA as described in
4264 Section 12.
4266 Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
4267 reserved to avoid collision with Fortezza-based cipher suites in
4268 SSL 3.
4270 A.6. The Security Parameters
4272 These security parameters are determined by the TLS Handshake
4273 Protocol and provided as parameters to the TLS record layer in order
4274 to initialize a connection state. SecurityParameters includes:
4276 enum { null(0), (255) } CompressionMethod;
4278 enum { server, client } ConnectionEnd;
4280 enum { tls_prf_sha256 } PRFAlgorithm;
4282 enum { null, rc4, 3des, aes } BulkCipherAlgorithm;
4284 enum { stream, block, aead } CipherType;
4286 enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384,
4287 hmac_sha512} MACAlgorithm;
4289 /* Other values may be added to the algorithms specified in
4290 CompressionMethod, PRFAlgorithm, BulkCipherAlgorithm, and
4291 MACAlgorithm. */
4293 struct {
4294 ConnectionEnd entity;
4295 PRFAlgorithm prf_algorithm;
4296 BulkCipherAlgorithm bulk_cipher_algorithm;
4297 CipherType cipher_type;
4298 uint8 enc_key_length;
4299 uint8 block_length;
4300 uint8 fixed_iv_length;
4301 uint8 record_iv_length;
4302 MACAlgorithm mac_algorithm;
4303 uint8 mac_length;
4304 uint8 mac_key_length;
4305 CompressionMethod compression_algorithm;
4306 opaque master_secret[48];
4307 opaque client_random[32];
4308 opaque server_random[32];
4309 } SecurityParameters;
4314 Dierks & Rescorla Standards Track [Page 77]
4315 \f
4316 RFC 5246 TLS August 2008
4319 A.7. Changes to RFC 4492
4321 RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This
4322 document changes some of the structures used in that document. This
4323 section details the required changes for implementors of both RFC
4324 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing
4325 RFC 4492 do not need to read this section.
4327 This document adds a "signature_algorithm" field to the digitally-
4328 signed element in order to identify the signature and digest
4329 algorithms used to create a signature. This change applies to
4330 digital signatures formed using ECDSA as well, thus allowing ECDSA
4331 signatures to be used with digest algorithms other than SHA-1,
4332 provided such use is compatible with the certificate and any
4333 restrictions imposed by future revisions of [PKIX].
4335 As described in Sections 7.4.2 and 7.4.6, the restrictions on the
4336 signature algorithms used to sign certificates are no longer tied to
4337 the cipher suite (when used by the server) or the
4338 ClientCertificateType (when used by the client). Thus, the
4339 restrictions on the algorithm used to sign certificates specified in
4340 Sections 2 and 3 of RFC 4492 are also relaxed. As in this document,
4341 the restrictions on the keys in the end-entity certificate remain.
4343 Appendix B. Glossary
4345 Advanced Encryption Standard (AES)
4346 AES [AES] is a widely used symmetric encryption algorithm. AES is
4347 a block cipher with a 128-, 192-, or 256-bit keys and a 16-byte
4348 block size. TLS currently only supports the 128- and 256-bit key
4349 sizes.
4351 application protocol
4352 An application protocol is a protocol that normally layers
4353 directly on top of the transport layer (e.g., TCP/IP). Examples
4354 include HTTP, TELNET, FTP, and SMTP.
4356 asymmetric cipher
4357 See public key cryptography.
4359 authenticated encryption with additional data (AEAD)
4360 A symmetric encryption algorithm that simultaneously provides
4361 confidentiality and message integrity.
4363 authentication
4364 Authentication is the ability of one entity to determine the
4365 identity of another entity.
4370 Dierks & Rescorla Standards Track [Page 78]
4371 \f
4372 RFC 5246 TLS August 2008
4375 block cipher
4376 A block cipher is an algorithm that operates on plaintext in
4377 groups of bits, called blocks. 64 bits was, and 128 bits is, a
4378 common block size.
4380 bulk cipher
4381 A symmetric encryption algorithm used to encrypt large quantities
4382 of data.
4384 cipher block chaining (CBC)
4385 CBC is a mode in which every plaintext block encrypted with a
4386 block cipher is first exclusive-ORed with the previous ciphertext
4387 block (or, in the case of the first block, with the initialization
4388 vector). For decryption, every block is first decrypted, then
4389 exclusive-ORed with the previous ciphertext block (or IV).
4391 certificate
4392 As part of the X.509 protocol (a.k.a. ISO Authentication
4393 framework), certificates are assigned by a trusted Certificate
4394 Authority and provide a strong binding between a party's identity
4395 or some other attributes and its public key.
4397 client
4398 The application entity that initiates a TLS connection to a
4399 server. This may or may not imply that the client initiated the
4400 underlying transport connection. The primary operational
4401 difference between the server and client is that the server is
4402 generally authenticated, while the client is only optionally
4403 authenticated.
4405 client write key
4406 The key used to encrypt data written by the client.
4408 client write MAC key
4409 The secret data used to authenticate data written by the client.
4411 connection
4412 A connection is a transport (in the OSI layering model definition)
4413 that provides a suitable type of service. For TLS, such
4414 connections are peer-to-peer relationships. The connections are
4415 transient. Every connection is associated with one session.
4417 Data Encryption Standard
4418 DES [DES] still is a very widely used symmetric encryption
4419 algorithm although it is considered as rather weak now. DES is a
4420 block cipher with a 56-bit key and an 8-byte block size. Note
4421 that in TLS, for key generation purposes, DES is treated as having
4422 an 8-byte key length (64 bits), but it still only provides 56 bits
4426 Dierks & Rescorla Standards Track [Page 79]
4427 \f
4428 RFC 5246 TLS August 2008
4431 of protection. (The low bit of each key byte is presumed to be
4432 set to produce odd parity in that key byte.) DES can also be
4433 operated in a mode [3DES] where three independent keys and three
4434 encryptions are used for each block of data; this uses 168 bits of
4435 key (24 bytes in the TLS key generation method) and provides the
4436 equivalent of 112 bits of security.
4438 Digital Signature Standard (DSS)
4439 A standard for digital signing, including the Digital Signing
4440 Algorithm, approved by the National Institute of Standards and
4441 Technology, defined in NIST FIPS PUB 186-2, "Digital Signature
4442 Standard", published January 2000 by the U.S. Department of
4443 Commerce [DSS]. A significant update [DSS-3] has been drafted and
4444 was published in March 2006.
4446 digital signatures
4447 Digital signatures utilize public key cryptography and one-way
4448 hash functions to produce a signature of the data that can be
4449 authenticated, and is difficult to forge or repudiate.
4451 handshake An initial negotiation between client and server that
4452 establishes the parameters of their transactions.
4454 Initialization Vector (IV)
4455 When a block cipher is used in CBC mode, the initialization vector
4456 is exclusive-ORed with the first plaintext block prior to
4457 encryption.
4459 Message Authentication Code (MAC)
4460 A Message Authentication Code is a one-way hash computed from a
4461 message and some secret data. It is difficult to forge without
4462 knowing the secret data. Its purpose is to detect if the message
4463 has been altered.
4465 master secret
4466 Secure secret data used for generating encryption keys, MAC
4467 secrets, and IVs.
4469 MD5
4470 MD5 [MD5] is a hashing function that converts an arbitrarily long
4471 data stream into a hash of fixed size (16 bytes). Due to
4472 significant progress in cryptanalysis, at the time of publication
4473 of this document, MD5 no longer can be considered a 'secure'
4474 hashing function.
4482 Dierks & Rescorla Standards Track [Page 80]
4483 \f
4484 RFC 5246 TLS August 2008
4487 public key cryptography
4488 A class of cryptographic techniques employing two-key ciphers.
4489 Messages encrypted with the public key can only be decrypted with
4490 the associated private key. Conversely, messages signed with the
4491 private key can be verified with the public key.
4493 one-way hash function
4494 A one-way transformation that converts an arbitrary amount of data
4495 into a fixed-length hash. It is computationally hard to reverse
4496 the transformation or to find collisions. MD5 and SHA are
4497 examples of one-way hash functions.
4499 RC4
4500 A stream cipher invented by Ron Rivest. A compatible cipher is
4501 described in [SCH].
4503 RSA
4504 A very widely used public key algorithm that can be used for
4505 either encryption or digital signing. [RSA]
4507 server
4508 The server is the application entity that responds to requests for
4509 connections from clients. See also "client".
4511 session
4512 A TLS session is an association between a client and a server.
4513 Sessions are created by the handshake protocol. Sessions define a
4514 set of cryptographic security parameters that can be shared among
4515 multiple connections. Sessions are used to avoid the expensive
4516 negotiation of new security parameters for each connection.
4518 session identifier
4519 A session identifier is a value generated by a server that
4520 identifies a particular session.
4522 server write key
4523 The key used to encrypt data written by the server.
4525 server write MAC key
4526 The secret data used to authenticate data written by the server.
4528 SHA
4529 The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2. It
4530 produces a 20-byte output. Note that all references to SHA
4531 (without a numerical suffix) actually use the modified SHA-1
4532 algorithm.
4538 Dierks & Rescorla Standards Track [Page 81]
4539 \f
4540 RFC 5246 TLS August 2008
4543 SHA-256
4544 The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2.
4545 It produces a 32-byte output.
4547 SSL
4548 Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
4549 SSL Version 3.0.
4551 stream cipher
4552 An encryption algorithm that converts a key into a
4553 cryptographically strong keystream, which is then exclusive-ORed
4554 with the plaintext.
4556 symmetric cipher
4557 See bulk cipher.
4559 Transport Layer Security (TLS)
4560 This protocol; also, the Transport Layer Security working group of
4561 the Internet Engineering Task Force (IETF). See "Working Group
4562 Information" at the end of this document (see page 99).
4594 Dierks & Rescorla Standards Track [Page 82]
4595 \f
4596 RFC 5246 TLS August 2008
4599 Appendix C. Cipher Suite Definitions
4601 Cipher Suite Key Cipher Mac
4602 Exchange
4604 TLS_NULL_WITH_NULL_NULL NULL NULL NULL
4605 TLS_RSA_WITH_NULL_MD5 RSA NULL MD5
4606 TLS_RSA_WITH_NULL_SHA RSA NULL SHA
4607 TLS_RSA_WITH_NULL_SHA256 RSA NULL SHA256
4608 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
4609 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
4610 TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
4611 TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA
4612 TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA
4613 TLS_RSA_WITH_AES_128_CBC_SHA256 RSA AES_128_CBC SHA256
4614 TLS_RSA_WITH_AES_256_CBC_SHA256 RSA AES_256_CBC SHA256
4615 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
4616 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
4617 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
4618 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
4619 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
4620 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
4621 TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA
4622 TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA
4623 TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA
4624 TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA
4625 TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA
4626 TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA
4627 TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA
4628 TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA
4629 TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA
4630 TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA
4631 TLS_DH_DSS_WITH_AES_128_CBC_SHA256 DH_DSS AES_128_CBC SHA256
4632 TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256
4633 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256
4634 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256
4635 TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256
4636 TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256
4637 TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256
4638 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256
4639 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256
4640 TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256
4650 Dierks & Rescorla Standards Track [Page 83]
4651 \f
4652 RFC 5246 TLS August 2008
4655 Key IV Block
4656 Cipher Type Material Size Size
4657 ------------ ------ -------- ---- -----
4658 NULL Stream 0 0 N/A
4659 RC4_128 Stream 16 0 N/A
4660 3DES_EDE_CBC Block 24 8 8
4661 AES_128_CBC Block 16 16 16
4662 AES_256_CBC Block 32 16 16
4665 MAC Algorithm mac_length mac_key_length
4666 -------- ----------- ---------- --------------
4667 NULL N/A 0 0
4668 MD5 HMAC-MD5 16 16
4669 SHA HMAC-SHA1 20 20
4670 SHA256 HMAC-SHA256 32 32
4672 Type
4673 Indicates whether this is a stream cipher or a block cipher
4674 running in CBC mode.
4676 Key Material
4677 The number of bytes from the key_block that are used for
4678 generating the write keys.
4680 IV Size
4681 The amount of data needed to be generated for the initialization
4682 vector. Zero for stream ciphers; equal to the block size for
4683 block ciphers (this is equal to
4684 SecurityParameters.record_iv_length).
4686 Block Size
4687 The amount of data a block cipher enciphers in one chunk; a block
4688 cipher running in CBC mode can only encrypt an even multiple of
4689 its block size.
4706 Dierks & Rescorla Standards Track [Page 84]
4707 \f
4708 RFC 5246 TLS August 2008
4711 Appendix D. Implementation Notes
4713 The TLS protocol cannot prevent many common security mistakes. This
4714 section provides several recommendations to assist implementors.
4716 D.1. Random Number Generation and Seeding
4718 TLS requires a cryptographically secure pseudorandom number generator
4719 (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs
4720 based on secure hash operations, most notably SHA-1, are acceptable,
4721 but cannot provide more security than the size of the random number
4722 generator state.
4724 To estimate the amount of seed material being produced, add the
4725 number of bits of unpredictable information in each seed byte. For
4726 example, keystroke timing values taken from a PC compatible's 18.2 Hz
4727 timer provide 1 or 2 secure bits each, even though the total size of
4728 the counter value is 16 bits or more. Seeding a 128-bit PRNG would
4729 thus require approximately 100 such timer values.
4731 [RANDOM] provides guidance on the generation of random values.
4733 D.2. Certificates and Authentication
4735 Implementations are responsible for verifying the integrity of
4736 certificates and should generally support certificate revocation
4737 messages. Certificates should always be verified to ensure proper
4738 signing by a trusted Certificate Authority (CA). The selection and
4739 addition of trusted CAs should be done very carefully. Users should
4740 be able to view information about the certificate and root CA.
4742 D.3. Cipher Suites
4744 TLS supports a range of key sizes and security levels, including some
4745 that provide no or minimal security. A proper implementation will
4746 probably not support many cipher suites. For instance, anonymous
4747 Diffie-Hellman is strongly discouraged because it cannot prevent man-
4748 in-the-middle attacks. Applications should also enforce minimum and
4749 maximum key sizes. For example, certificate chains containing 512-
4750 bit RSA keys or signatures are not appropriate for high-security
4751 applications.
4753 D.4. Implementation Pitfalls
4755 Implementation experience has shown that certain parts of earlier TLS
4756 specifications are not easy to understand, and have been a source of
4757 interoperability and security problems. Many of these areas have
4762 Dierks & Rescorla Standards Track [Page 85]
4763 \f
4764 RFC 5246 TLS August 2008
4767 been clarified in this document, but this appendix contains a short
4768 list of the most important things that require special attention from
4769 implementors.
4771 TLS protocol issues:
4773 - Do you correctly handle handshake messages that are fragmented to
4774 multiple TLS records (see Section 6.2.1)? Including corner cases
4775 like a ClientHello that is split to several small fragments? Do
4776 you fragment handshake messages that exceed the maximum fragment
4777 size? In particular, the certificate and certificate request
4778 handshake messages can be large enough to require fragmentation.
4780 - Do you ignore the TLS record layer version number in all TLS
4781 records before ServerHello (see Appendix E.1)?
4783 - Do you handle TLS extensions in ClientHello correctly, including
4784 omitting the extensions field completely?
4786 - Do you support renegotiation, both client and server initiated?
4787 While renegotiation is an optional feature, supporting it is
4788 highly recommended.
4790 - When the server has requested a client certificate, but no
4791 suitable certificate is available, do you correctly send an empty
4792 Certificate message, instead of omitting the whole message (see
4793 Section 7.4.6)?
4795 Cryptographic details:
4797 - In the RSA-encrypted Premaster Secret, do you correctly send and
4798 verify the version number? When an error is encountered, do you
4799 continue the handshake to avoid the Bleichenbacher attack (see
4800 Section 7.4.7.1)?
4802 - What countermeasures do you use to prevent timing attacks against
4803 RSA decryption and signing operations (see Section 7.4.7.1)?
4805 - When verifying RSA signatures, do you accept both NULL and missing
4806 parameters (see Section 4.7)? Do you verify that the RSA padding
4807 doesn't have additional data after the hash value? [FI06]
4809 - When using Diffie-Hellman key exchange, do you correctly strip
4810 leading zero bytes from the negotiated key (see Section 8.1.2)?
4812 - Does your TLS client check that the Diffie-Hellman parameters sent
4813 by the server are acceptable (see Section F.1.1.3)?
4818 Dierks & Rescorla Standards Track [Page 86]
4819 \f
4820 RFC 5246 TLS August 2008
4823 - How do you generate unpredictable IVs for CBC mode ciphers (see
4824 Section 6.2.3.2)?
4826 - Do you accept long CBC mode padding (up to 255 bytes; see Section
4827 6.2.3.2)?
4829 - How do you address CBC mode timing attacks (Section 6.2.3.2)?
4831 - Do you use a strong and, most importantly, properly seeded random
4832 number generator (see Appendix D.1) for generating the premaster
4833 secret (for RSA key exchange), Diffie-Hellman private values, the
4834 DSA "k" parameter, and other security-critical values?
4836 Appendix E. Backward Compatibility
4838 E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0
4840 Since there are various versions of TLS (1.0, 1.1, 1.2, and any
4841 future versions) and SSL (2.0 and 3.0), means are needed to negotiate
4842 the specific protocol version to use. The TLS protocol provides a
4843 built-in mechanism for version negotiation so as not to bother other
4844 protocol components with the complexities of version selection.
4846 TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
4847 compatible ClientHello messages; thus, supporting all of them is
4848 relatively easy. Similarly, servers can easily handle clients trying
4849 to use future versions of TLS as long as the ClientHello format
4850 remains compatible, and the client supports the highest protocol
4851 version available in the server.
4853 A TLS 1.2 client who wishes to negotiate with such older servers will
4854 send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
4855 ClientHello.client_version. If the server does not support this
4856 version, it will respond with a ServerHello containing an older
4857 version number. If the client agrees to use this version, the
4858 negotiation will proceed as appropriate for the negotiated protocol.
4860 If the version chosen by the server is not supported by the client
4861 (or not acceptable), the client MUST send a "protocol_version" alert
4862 message and close the connection.
4864 If a TLS server receives a ClientHello containing a version number
4865 greater than the highest version supported by the server, it MUST
4866 reply according to the highest version supported by the server.
4868 A TLS server can also receive a ClientHello containing a version
4869 number smaller than the highest supported version. If the server
4870 wishes to negotiate with old clients, it will proceed as appropriate
4874 Dierks & Rescorla Standards Track [Page 87]
4875 \f
4876 RFC 5246 TLS August 2008
4879 for the highest version supported by the server that is not greater
4880 than ClientHello.client_version. For example, if the server supports
4881 TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
4882 proceed with a TLS 1.0 ServerHello. If server supports (or is
4883 willing to use) only versions greater than client_version, it MUST
4884 send a "protocol_version" alert message and close the connection.
4886 Whenever a client already knows the highest protocol version known to
4887 a server (for example, when resuming a session), it SHOULD initiate
4888 the connection in that native protocol.
4890 Note: some server implementations are known to implement version
4891 negotiation incorrectly. For example, there are buggy TLS 1.0
4892 servers that simply close the connection when the client offers a
4893 version newer than TLS 1.0. Also, it is known that some servers will
4894 refuse the connection if any TLS extensions are included in
4895 ClientHello. Interoperability with such buggy servers is a complex
4896 topic beyond the scope of this document, and may require multiple
4897 connection attempts by the client.
4899 Earlier versions of the TLS specification were not fully clear on
4900 what the record layer version number (TLSPlaintext.version) should
4901 contain when sending ClientHello (i.e., before it is known which
4902 version of the protocol will be employed). Thus, TLS servers
4903 compliant with this specification MUST accept any value {03,XX} as
4904 the record layer version number for ClientHello.
4906 TLS clients that wish to negotiate with older servers MAY send any
4907 value {03,XX} as the record layer version number. Typical values
4908 would be {03,00}, the lowest version number supported by the client,
4909 and the value of ClientHello.client_version. No single value will
4910 guarantee interoperability with all old servers, but this is a
4911 complex topic beyond the scope of this document.
4913 E.2. Compatibility with SSL 2.0
4915 TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
4916 version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message
4917 MUST contain the same version number as would be used for ordinary
4918 ClientHello, and MUST encode the supported TLS cipher suites in the
4919 CIPHER-SPECS-DATA field as described below.
4921 Warning: The ability to send version 2.0 CLIENT-HELLO messages will
4922 be phased out with all due haste, since the newer ClientHello format
4923 provides better mechanisms for moving to newer versions and
4924 negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0.
4930 Dierks & Rescorla Standards Track [Page 88]
4931 \f
4932 RFC 5246 TLS August 2008
4935 However, even TLS servers that do not support SSL 2.0 MAY accept
4936 version 2.0 CLIENT-HELLO messages. The message is presented below in
4937 sufficient detail for TLS server implementors; the true definition is
4938 still assumed to be [SSL2].
4940 For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
4941 way as a ClientHello with a "null" compression method and no
4942 extensions. Note that this message MUST be sent directly on the
4943 wire, not wrapped as a TLS record. For the purposes of calculating
4944 Finished and CertificateVerify, the msg_length field is not
4945 considered to be a part of the handshake message.
4947 uint8 V2CipherSpec[3];
4948 struct {
4949 uint16 msg_length;
4950 uint8 msg_type;
4951 Version version;
4952 uint16 cipher_spec_length;
4953 uint16 session_id_length;
4954 uint16 challenge_length;
4955 V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
4956 opaque session_id[V2ClientHello.session_id_length];
4957 opaque challenge[V2ClientHello.challenge_length;
4958 } V2ClientHello;
4960 msg_length
4961 The highest bit MUST be 1; the remaining bits contain the length
4962 of the following data in bytes.
4964 msg_type
4965 This field, in conjunction with the version field, identifies a
4966 version 2 ClientHello message. The value MUST be 1.
4968 version
4969 Equal to ClientHello.client_version.
4971 cipher_spec_length
4972 This field is the total length of the field cipher_specs. It
4973 cannot be zero and MUST be a multiple of the V2CipherSpec length
4974 (3).
4976 session_id_length
4977 This field MUST have a value of zero for a client that claims to
4978 support TLS 1.2.
4986 Dierks & Rescorla Standards Track [Page 89]
4987 \f
4988 RFC 5246 TLS August 2008
4991 challenge_length
4992 The length in bytes of the client's challenge to the server to
4993 authenticate itself. Historically, permissible values are between
4994 16 and 32 bytes inclusive. When using the SSLv2 backward-
4995 compatible handshake the client SHOULD use a 32-byte challenge.
4997 cipher_specs
4998 This is a list of all CipherSpecs the client is willing and able
4999 to use. In addition to the 2.0 cipher specs defined in [SSL2],
5000 this includes the TLS cipher suites normally sent in
5001 ClientHello.cipher_suites, with each cipher suite prefixed by a
5002 zero byte. For example, the TLS cipher suite {0x00,0x0A} would be
5003 sent as {0x00,0x00,0x0A}.
5005 session_id
5006 This field MUST be empty.
5008 challenge
5009 Corresponds to ClientHello.random. If the challenge length is
5010 less than 32, the TLS server will pad the data with leading (note:
5011 not trailing) zero bytes to make it 32 bytes long.
5013 Note: Requests to resume a TLS session MUST use a TLS client hello.
5015 E.3. Avoiding Man-in-the-Middle Version Rollback
5017 When TLS clients fall back to Version 2.0 compatibility mode, they
5018 MUST use special PKCS#1 block formatting. This is done so that TLS
5019 servers will reject Version 2.0 sessions with TLS-capable clients.
5021 When a client negotiates SSL 2.0 but also supports TLS, it MUST set
5022 the right-hand (least-significant) 8 random bytes of the PKCS padding
5023 (not including the terminal null of the padding) for the RSA
5024 encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
5025 to 0x03 (the other padding bytes are random).
5027 When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
5028 decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding
5029 bytes are 0x03. If they are not, the server SHOULD generate a random
5030 value for SECRET-KEY-DATA, and continue the handshake (which will
5031 eventually fail since the keys will not match). Note that reporting
5032 the error situation to the client could make the server vulnerable to
5033 attacks described in [BLEI].
5042 Dierks & Rescorla Standards Track [Page 90]
5043 \f
5044 RFC 5246 TLS August 2008
5047 Appendix F. Security Analysis
5049 The TLS protocol is designed to establish a secure connection between
5050 a client and a server communicating over an insecure channel. This
5051 document makes several traditional assumptions, including that
5052 attackers have substantial computational resources and cannot obtain
5053 secret information from sources outside the protocol. Attackers are
5054 assumed to have the ability to capture, modify, delete, replay, and
5055 otherwise tamper with messages sent over the communication channel.
5056 This appendix outlines how TLS has been designed to resist a variety
5057 of attacks.
5059 F.1. Handshake Protocol
5061 The handshake protocol is responsible for selecting a cipher spec and
5062 generating a master secret, which together comprise the primary
5063 cryptographic parameters associated with a secure session. The
5064 handshake protocol can also optionally authenticate parties who have
5065 certificates signed by a trusted certificate authority.
5067 F.1.1. Authentication and Key Exchange
5069 TLS supports three authentication modes: authentication of both
5070 parties, server authentication with an unauthenticated client, and
5071 total anonymity. Whenever the server is authenticated, the channel
5072 is secure against man-in-the-middle attacks, but completely anonymous
5073 sessions are inherently vulnerable to such attacks. Anonymous
5074 servers cannot authenticate clients. If the server is authenticated,
5075 its certificate message must provide a valid certificate chain
5076 leading to an acceptable certificate authority. Similarly,
5077 authenticated clients must supply an acceptable certificate to the
5078 server. Each party is responsible for verifying that the other's
5079 certificate is valid and has not expired or been revoked.
5081 The general goal of the key exchange process is to create a
5082 pre_master_secret known to the communicating parties and not to
5083 attackers. The pre_master_secret will be used to generate the
5084 master_secret (see Section 8.1). The master_secret is required to
5085 generate the Finished messages, encryption keys, and MAC keys (see
5086 Sections 7.4.9 and 6.3). By sending a correct Finished message,
5087 parties thus prove that they know the correct pre_master_secret.
5089 F.1.1.1. Anonymous Key Exchange
5091 Completely anonymous sessions can be established using Diffie-Hellman
5092 for key exchange. The server's public parameters are contained in
5093 the server key exchange message, and the client's are sent in the
5098 Dierks & Rescorla Standards Track [Page 91]
5099 \f
5100 RFC 5246 TLS August 2008
5103 client key exchange message. Eavesdroppers who do not know the
5104 private values should not be able to find the Diffie-Hellman result
5105 (i.e., the pre_master_secret).
5107 Warning: Completely anonymous connections only provide protection
5108 against passive eavesdropping. Unless an independent tamper-proof
5109 channel is used to verify that the Finished messages were not
5110 replaced by an attacker, server authentication is required in
5111 environments where active man-in-the-middle attacks are a concern.
5113 F.1.1.2. RSA Key Exchange and Authentication
5115 With RSA, key exchange and server authentication are combined. The
5116 public key is contained in the server's certificate. Note that
5117 compromise of the server's static RSA key results in a loss of
5118 confidentiality for all sessions protected under that static key.
5119 TLS users desiring Perfect Forward Secrecy should use DHE cipher
5120 suites. The damage done by exposure of a private key can be limited
5121 by changing one's private key (and certificate) frequently.
5123 After verifying the server's certificate, the client encrypts a
5124 pre_master_secret with the server's public key. By successfully
5125 decoding the pre_master_secret and producing a correct Finished
5126 message, the server demonstrates that it knows the private key
5127 corresponding to the server certificate.
5129 When RSA is used for key exchange, clients are authenticated using
5130 the certificate verify message (see Section 7.4.8). The client signs
5131 a value derived from all preceding handshake messages. These
5132 handshake messages include the server certificate, which binds the
5133 signature to the server, and ServerHello.random, which binds the
5134 signature to the current handshake process.
5136 F.1.1.3. Diffie-Hellman Key Exchange with Authentication
5138 When Diffie-Hellman key exchange is used, the server can either
5139 supply a certificate containing fixed Diffie-Hellman parameters or
5140 use the server key exchange message to send a set of temporary
5141 Diffie-Hellman parameters signed with a DSA or RSA certificate.
5142 Temporary parameters are hashed with the hello.random values before
5143 signing to ensure that attackers do not replay old parameters. In
5144 either case, the client can verify the certificate or signature to
5145 ensure that the parameters belong to the server.
5147 If the client has a certificate containing fixed Diffie-Hellman
5148 parameters, its certificate contains the information required to
5149 complete the key exchange. Note that in this case the client and
5150 server will generate the same Diffie-Hellman result (i.e.,
5154 Dierks & Rescorla Standards Track [Page 92]
5155 \f
5156 RFC 5246 TLS August 2008
5159 pre_master_secret) every time they communicate. To prevent the
5160 pre_master_secret from staying in memory any longer than necessary,
5161 it should be converted into the master_secret as soon as possible.
5162 Client Diffie-Hellman parameters must be compatible with those
5163 supplied by the server for the key exchange to work.
5165 If the client has a standard DSA or RSA certificate or is
5166 unauthenticated, it sends a set of temporary parameters to the server
5167 in the client key exchange message, then optionally uses a
5168 certificate verify message to authenticate itself.
5170 If the same DH keypair is to be used for multiple handshakes, either
5171 because the client or server has a certificate containing a fixed DH
5172 keypair or because the server is reusing DH keys, care must be taken
5173 to prevent small subgroup attacks. Implementations SHOULD follow the
5174 guidelines found in [SUBGROUP].
5176 Small subgroup attacks are most easily avoided by using one of the
5177 DHE cipher suites and generating a fresh DH private key (X) for each
5178 handshake. If a suitable base (such as 2) is chosen, g^X mod p can
5179 be computed very quickly; therefore, the performance cost is
5180 minimized. Additionally, using a fresh key for each handshake
5181 provides Perfect Forward Secrecy. Implementations SHOULD generate a
5182 new X for each handshake when using DHE cipher suites.
5184 Because TLS allows the server to provide arbitrary DH groups, the
5185 client should verify that the DH group is of suitable size as defined
5186 by local policy. The client SHOULD also verify that the DH public
5187 exponent appears to be of adequate size. [KEYSIZ] provides a useful
5188 guide to the strength of various group sizes. The server MAY choose
5189 to assist the client by providing a known group, such as those
5190 defined in [IKEALG] or [MODP]. These can be verified by simple
5191 comparison.
5193 F.1.2. Version Rollback Attacks
5195 Because TLS includes substantial improvements over SSL Version 2.0,
5196 attackers may try to make TLS-capable clients and servers fall back
5197 to Version 2.0. This attack can occur if (and only if) two TLS-
5198 capable parties use an SSL 2.0 handshake.
5200 Although the solution using non-random PKCS #1 block type 2 message
5201 padding is inelegant, it provides a reasonably secure way for Version
5202 3.0 servers to detect the attack. This solution is not secure
5203 against attackers who can brute-force the key and substitute a new
5204 ENCRYPTED-KEY-DATA message containing the same key (but with normal
5205 padding) before the application-specified wait threshold has expired.
5206 Altering the padding of the least-significant 8 bytes of the PKCS
5210 Dierks & Rescorla Standards Track [Page 93]
5211 \f
5212 RFC 5246 TLS August 2008
5215 padding does not impact security for the size of the signed hashes
5216 and RSA key lengths used in the protocol, since this is essentially
5217 equivalent to increasing the input block size by 8 bytes.
5219 F.1.3. Detecting Attacks Against the Handshake Protocol
5221 An attacker might try to influence the handshake exchange to make the
5222 parties select different encryption algorithms than they would
5223 normally choose.
5225 For this attack, an attacker must actively change one or more
5226 handshake messages. If this occurs, the client and server will
5227 compute different values for the handshake message hashes. As a
5228 result, the parties will not accept each others' Finished messages.
5229 Without the master_secret, the attacker cannot repair the Finished
5230 messages, so the attack will be discovered.
5232 F.1.4. Resuming Sessions
5234 When a connection is established by resuming a session, new
5235 ClientHello.random and ServerHello.random values are hashed with the
5236 session's master_secret. Provided that the master_secret has not
5237 been compromised and that the secure hash operations used to produce
5238 the encryption keys and MAC keys are secure, the connection should be
5239 secure and effectively independent from previous connections.
5240 Attackers cannot use known encryption keys or MAC secrets to
5241 compromise the master_secret without breaking the secure hash
5242 operations.
5244 Sessions cannot be resumed unless both the client and server agree.
5245 If either party suspects that the session may have been compromised,
5246 or that certificates may have expired or been revoked, it should
5247 force a full handshake. An upper limit of 24 hours is suggested for
5248 session ID lifetimes, since an attacker who obtains a master_secret
5249 may be able to impersonate the compromised party until the
5250 corresponding session ID is retired. Applications that may be run in
5251 relatively insecure environments should not write session IDs to
5252 stable storage.
5254 F.2. Protecting Application Data
5256 The master_secret is hashed with the ClientHello.random and
5257 ServerHello.random to produce unique data encryption keys and MAC
5258 secrets for each connection.
5260 Outgoing data is protected with a MAC before transmission. To
5261 prevent message replay or modification attacks, the MAC is computed
5262 from the MAC key, the sequence number, the message length, the
5266 Dierks & Rescorla Standards Track [Page 94]
5267 \f
5268 RFC 5246 TLS August 2008
5271 message contents, and two fixed character strings. The message type
5272 field is necessary to ensure that messages intended for one TLS
5273 record layer client are not redirected to another. The sequence
5274 number ensures that attempts to delete or reorder messages will be
5275 detected. Since sequence numbers are 64 bits long, they should never
5276 overflow. Messages from one party cannot be inserted into the
5277 other's output, since they use independent MAC keys. Similarly, the
5278 server write and client write keys are independent, so stream cipher
5279 keys are used only once.
5281 If an attacker does break an encryption key, all messages encrypted
5282 with it can be read. Similarly, compromise of a MAC key can make
5283 message-modification attacks possible. Because MACs are also
5284 encrypted, message-alteration attacks generally require breaking the
5285 encryption algorithm as well as the MAC.
5287 Note: MAC keys may be larger than encryption keys, so messages can
5288 remain tamper resistant even if encryption keys are broken.
5290 F.3. Explicit IVs
5292 [CBCATT] describes a chosen plaintext attack on TLS that depends on
5293 knowing the IV for a record. Previous versions of TLS [TLS1.0] used
5294 the CBC residue of the previous record as the IV and therefore
5295 enabled this attack. This version uses an explicit IV in order to
5296 protect against this attack.
5298 F.4. Security of Composite Cipher Modes
5300 TLS secures transmitted application data via the use of symmetric
5301 encryption and authentication functions defined in the negotiated
5302 cipher suite. The objective is to protect both the integrity and
5303 confidentiality of the transmitted data from malicious actions by
5304 active attackers in the network. It turns out that the order in
5305 which encryption and authentication functions are applied to the data
5306 plays an important role for achieving this goal [ENCAUTH].
5308 The most robust method, called encrypt-then-authenticate, first
5309 applies encryption to the data and then applies a MAC to the
5310 ciphertext. This method ensures that the integrity and
5311 confidentiality goals are obtained with ANY pair of encryption and
5312 MAC functions, provided that the former is secure against chosen
5313 plaintext attacks and that the MAC is secure against chosen-message
5314 attacks. TLS uses another method, called authenticate-then-encrypt,
5315 in which first a MAC is computed on the plaintext and then the
5316 concatenation of plaintext and MAC is encrypted. This method has
5317 been proven secure for CERTAIN combinations of encryption functions
5318 and MAC functions, but it is not guaranteed to be secure in general.
5322 Dierks & Rescorla Standards Track [Page 95]
5323 \f
5324 RFC 5246 TLS August 2008
5327 In particular, it has been shown that there exist perfectly secure
5328 encryption functions (secure even in the information-theoretic sense)
5329 that combined with any secure MAC function, fail to provide the
5330 confidentiality goal against an active attack. Therefore, new cipher
5331 suites and operation modes adopted into TLS need to be analyzed under
5332 the authenticate-then-encrypt method to verify that they achieve the
5333 stated integrity and confidentiality goals.
5335 Currently, the security of the authenticate-then-encrypt method has
5336 been proven for some important cases. One is the case of stream
5337 ciphers in which a computationally unpredictable pad of the length of
5338 the message, plus the length of the MAC tag, is produced using a
5339 pseudorandom generator and this pad is exclusive-ORed with the
5340 concatenation of plaintext and MAC tag. The other is the case of CBC
5341 mode using a secure block cipher. In this case, security can be
5342 shown if one applies one CBC encryption pass to the concatenation of
5343 plaintext and MAC and uses a new, independent, and unpredictable IV
5344 for each new pair of plaintext and MAC. In versions of TLS prior to
5345 1.1, CBC mode was used properly EXCEPT that it used a predictable IV
5346 in the form of the last block of the previous ciphertext. This made
5347 TLS open to chosen plaintext attacks. This version of the protocol
5348 is immune to those attacks. For exact details in the encryption
5349 modes proven secure, see [ENCAUTH].
5351 F.5. Denial of Service
5353 TLS is susceptible to a number of denial-of-service (DoS) attacks.
5354 In particular, an attacker who initiates a large number of TCP
5355 connections can cause a server to consume large amounts of CPU for
5356 doing RSA decryption. However, because TLS is generally used over
5357 TCP, it is difficult for the attacker to hide his point of origin if
5358 proper TCP SYN randomization is used [SEQNUM] by the TCP stack.
5360 Because TLS runs over TCP, it is also susceptible to a number of DoS
5361 attacks on individual connections. In particular, attackers can
5362 forge RSTs, thereby terminating connections, or forge partial TLS
5363 records, thereby causing the connection to stall. These attacks
5364 cannot in general be defended against by a TCP-using protocol.
5365 Implementors or users who are concerned with this class of attack
5366 should use IPsec AH [AH] or ESP [ESP].
5368 F.6. Final Notes
5370 For TLS to be able to provide a secure connection, both the client
5371 and server systems, keys, and applications must be secure. In
5372 addition, the implementation must be free of security errors.
5378 Dierks & Rescorla Standards Track [Page 96]
5379 \f
5380 RFC 5246 TLS August 2008
5383 The system is only as strong as the weakest key exchange and
5384 authentication algorithm supported, and only trustworthy
5385 cryptographic functions should be used. Short public keys and
5386 anonymous servers should be used with great caution. Implementations
5387 and users must be careful when deciding which certificates and
5388 certificate authorities are acceptable; a dishonest certificate
5389 authority can do tremendous damage.
5391 Normative References
5393 [AES] National Institute of Standards and Technology,
5394 "Specification for the Advanced Encryption Standard (AES)"
5395 FIPS 197. November 26, 2001.
5397 [3DES] National Institute of Standards and Technology,
5398 "Recommendation for the Triple Data Encryption Algorithm
5399 (TDEA) Block Cipher", NIST Special Publication 800-67, May
5400 2004.
5402 [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard",
5403 National Institute of Standards and Technology, U.S.
5404 Department of Commerce, 2000.
5406 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
5407 Hashing for Message Authentication", RFC 2104, February
5408 1997.
5410 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
5411 April 1992.
5413 [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
5414 Standards (PKCS) #1: RSA Cryptography Specifications
5415 Version 2.1", RFC 3447, February 2003.
5417 [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
5418 X.509 Public Key Infrastructure Certificate and
5419 Certificate Revocation List (CRL) Profile", RFC 3280,
5420 April 2002.
5422 [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
5423 and Source Code in C, 2nd ed.", Published by John Wiley &
5424 Sons, Inc. 1996.
5426 [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National
5427 Institute of Standards and Technology, U.S. Department of
5428 Commerce, August 2002.
5434 Dierks & Rescorla Standards Track [Page 97]
5435 \f
5436 RFC 5246 TLS August 2008
5439 [REQ] Bradner, S., "Key words for use in RFCs to Indicate
5440 Requirement Levels", BCP 14, RFC 2119, March 1997.
5442 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
5443 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
5444 October 1998.
5446 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
5447 Information technology - Abstract Syntax Notation One
5448 (ASN.1): Specification of basic notation.
5450 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
5451 Information technology - ASN.1 encoding Rules:
5452 Specification of Basic Encoding Rules (BER), Canonical
5453 Encoding Rules (CER) and Distinguished Encoding Rules
5454 (DER).
5456 Informative References
5458 [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated
5459 Encryption", RFC 5116, January 2008.
5461 [AH] Kent, S., "IP Authentication Header", RFC 4302, December
5462 2005.
5464 [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
5465 Protocols Based on RSA Encryption Standard PKCS #1" in
5466 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462,
5467 pages: 1-12, 1998.
5469 [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
5470 Problems and Countermeasures",
5471 http://www.openssl.org/~bodo/tls-cbc.txt.
5473 [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
5474 "Password Interception in a SSL/TLS Channel", Advances in
5475 Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
5477 [CCM] "NIST Special Publication 800-38C: The CCM Mode for
5478 Authentication and Confidentiality",
5479 http://csrc.nist.gov/publications/nistpubs/800-38C/
5480 SP800-38C.pdf
5482 [DES] National Institute of Standards and Technology, "Data
5483 Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
5490 Dierks & Rescorla Standards Track [Page 98]
5491 \f
5492 RFC 5246 TLS August 2008
5495 [DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard",
5496 National Institute of Standards and Technology, U.S.
5497 Department of Commerce, 2006.
5499 [ECDSA] American National Standards Institute, "Public Key
5500 Cryptography for the Financial Services Industry: The
5501 Elliptic Curve Digital Signature Algorithm (ECDSA)", ANS
5502 X9.62-2005, November 2005.
5504 [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
5505 for Protecting Communications (Or: How Secure is SSL?)",
5506 Crypto 2001.
5508 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
5509 4303, December 2005.
5511 [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based
5512 on implementation error", ietf-openpgp@imc.org mailing
5513 list, 27 August 2006, http://www.imc.org/ietf-openpgp/
5514 mail-archive/msg14307.html.
5516 [GCM] Dworkin, M., NIST Special Publication 800-38D,
5517 "Recommendation for Block Cipher Modes of Operation:
5518 Galois/Counter Mode (GCM) and GMAC", November 2007.
5520 [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
5521 Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
5522 December 2005.
5524 [KEYSIZ] Orman, H. and P. Hoffman, "Determining Strengths For
5525 Public Keys Used For Exchanging Symmetric Keys", BCP 86,
5526 RFC 3766, April 2004.
5528 [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
5529 Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
5530 March 2003.
5532 [MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
5533 Diffie-Hellman groups for Internet Key Exchange (IKE)",
5534 RFC 3526, May 2003.
5536 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate
5537 Syntax Standard", version 1.5, November 1993.
5539 [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message
5540 Syntax Standard", version 1.5, November 1993.
5546 Dierks & Rescorla Standards Track [Page 99]
5547 \f
5548 RFC 5246 TLS August 2008
5551 [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
5552 "Randomness Requirements for Security", BCP 106, RFC 4086,
5553 June 2005.
5555 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
5556 Compression Methods", RFC 3749, May 2004.
5558 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
5559 and T. Wright, "Transport Layer Security (TLS)
5560 Extensions", RFC 4366, April 2006.
5562 [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
5563 Obtaining Digital Signatures and Public-Key
5564 Cryptosystems", Communications of the ACM, v. 21, n. 2,
5565 Feb 1978, pp. 120-126.
5567 [SEQNUM] Bellovin, S., "Defending Against Sequence Number Attacks",
5568 RFC 1948, May 1996.
5570 [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
5571 Corp., Feb 9, 1995.
5573 [SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
5574 Protocol", Netscape Communications Corp., Nov 18, 1996.
5576 [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
5577 Attacks on the Diffie-Hellman Key Agreement Method for
5578 S/MIME", RFC 2785, March 2000.
5580 [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
5581 793, September 1981.
5583 [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
5584 practical", USENIX Security Symposium 2003.
5586 [TLSAES] Chown, P., "Advanced Encryption Standard (AES)
5587 Ciphersuites for Transport Layer Security (TLS)", RFC
5588 3268, June 2002.
5590 [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
5591 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
5592 for Transport Layer Security (TLS)", RFC 4492, May 2006.
5594 [TLSEXT] Eastlake, D., 3rd, "Transport Layer Security (TLS)
5595 Extensions: Extension Definitions", Work in Progress,
5596 February 2008.
5602 Dierks & Rescorla Standards Track [Page 100]
5603 \f
5604 RFC 5246 TLS August 2008
5607 [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
5608 Layer Security (TLS) Authentication", RFC 5081, November
5609 2007.
5611 [TLSPSK] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key
5612 Ciphersuites for Transport Layer Security (TLS)", RFC
5613 4279, December 2005.
5615 [TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
5616 RFC 2246, January 1999.
5618 [TLS1.1] Dierks, T. and E. Rescorla, "The Transport Layer Security
5619 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
5621 [X501] ITU-T Recommendation X.501: Information Technology - Open
5622 Systems Interconnection - The Directory: Models, 1993.
5624 [XDR] Eisler, M., Ed., "XDR: External Data Representation
5625 Standard", STD 67, RFC 4506, May 2006.
5627 Working Group Information
5629 The discussion list for the IETF TLS working group is located at the
5630 e-mail address <tls@ietf.org>. Information on the group and
5631 information on how to subscribe to the list is at
5632 <https://www1.ietf.org/mailman/listinfo/tls>
5634 Archives of the list can be found at:
5635 <http://www.ietf.org/mail-archive/web/tls/current/index.html>
5637 Contributors
5639 Christopher Allen (co-editor of TLS 1.0)
5640 Alacrity Ventures
5641 ChristopherA@AlacrityManagement.com
5643 Martin Abadi
5644 University of California, Santa Cruz
5645 abadi@cs.ucsc.edu
5647 Steven M. Bellovin
5648 Columbia University
5649 smb@cs.columbia.edu
5651 Simon Blake-Wilson
5652 BCI
5653 sblakewilson@bcisse.com
5658 Dierks & Rescorla Standards Track [Page 101]
5659 \f
5660 RFC 5246 TLS August 2008
5663 Ran Canetti
5664 IBM
5665 canetti@watson.ibm.com
5667 Pete Chown
5668 Skygate Technology Ltd
5669 pc@skygate.co.uk
5671 Taher Elgamal
5672 taher@securify.com
5673 Securify
5675 Pasi Eronen
5676 pasi.eronen@nokia.com
5677 Nokia
5679 Anil Gangolli
5680 anil@busybuddha.org
5682 Kipp Hickman
5684 Alfred Hoenes
5686 David Hopwood
5687 Independent Consultant
5688 david.hopwood@blueyonder.co.uk
5690 Phil Karlton (co-author of SSLv3)
5692 Paul Kocher (co-author of SSLv3)
5693 Cryptography Research
5694 paul@cryptography.com
5696 Hugo Krawczyk
5697 IBM
5698 hugo@ee.technion.ac.il
5700 Jan Mikkelsen
5701 Transactionware
5702 janm@transactionware.com
5704 Magnus Nystrom
5705 RSA Security
5706 magnus@rsasecurity.com
5708 Robert Relyea
5709 Netscape Communications
5710 relyea@netscape.com
5714 Dierks & Rescorla Standards Track [Page 102]
5715 \f
5716 RFC 5246 TLS August 2008
5719 Jim Roskind
5720 Netscape Communications
5721 jar@netscape.com
5723 Michael Sabin
5725 Dan Simon
5726 Microsoft, Inc.
5727 dansimon@microsoft.com
5729 Tom Weinstein
5731 Tim Wright
5732 Vodafone
5733 timothy.wright@vodafone.com
5735 Editors' Addresses
5737 Tim Dierks
5738 Independent
5739 EMail: tim@dierks.org
5741 Eric Rescorla
5742 RTFM, Inc.
5743 EMail: ekr@rtfm.com
5770 Dierks & Rescorla Standards Track [Page 103]
5771 \f
5772 RFC 5246 TLS August 2008
5775 Full Copyright Statement
5777 Copyright (C) The IETF Trust (2008).
5779 This document is subject to the rights, licenses and restrictions
5780 contained in BCP 78, and except as set forth therein, the authors
5781 retain all their rights.
5783 This document and the information contained herein are provided on an
5784 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
5785 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
5786 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
5787 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
5788 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
5789 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5791 Intellectual Property
5793 The IETF takes no position regarding the validity or scope of any
5794 Intellectual Property Rights or other rights that might be claimed to
5795 pertain to the implementation or use of the technology described in
5796 this document or the extent to which any license under such rights
5797 might or might not be available; nor does it represent that it has
5798 made any independent effort to identify any such rights. Information
5799 on the procedures with respect to rights in RFC documents can be
5800 found in BCP 78 and BCP 79.
5802 Copies of IPR disclosures made to the IETF Secretariat and any
5803 assurances of licenses to be made available, or the result of an
5804 attempt made to obtain a general license or permission for the use of
5805 such proprietary rights by implementers or users of this
5806 specification can be obtained from the IETF on-line IPR repository at
5807 http://www.ietf.org/ipr.
5809 The IETF invites any interested party to bring to its attention any
5810 copyrights, patents or patent applications, or other proprietary
5811 rights that may cover technology that may be required to implement
5812 this standard. Please address the information to the IETF at
5813 ietf-ipr@ietf.org.
5826 Dierks & Rescorla Standards Track [Page 104]
5827 \f