< draft-ietf-tls-rfc4346-bis-04.txt   draft-ietf-tls-rfc4346-bis-05.txt >
INTERNET-DRAFT Tim Dierks INTERNET-DRAFT Tim Dierks
Obsoletes (if approved): 4346 Independent Obsoletes (if approved): RFC 3268, 4346, 4366 Independent
Intended status: Proposed Standard Eric Rescorla Intended status: Proposed Standard Eric Rescorla
Network Resonance, Inc. Network Resonance, Inc.
<draft-ietf-tls-rfc4346-bis-04.txt> July 2007 (Expires January 2008) <draft-ietf-tls-rfc4346-bis-05.txt> September 2007 (Expires March 2008)
The TLS Protocol The Transport Layer Security (TLS) Protocol
Version 1.2 Version 1.2
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 96, line ? skipping to change at page 96, line ?
(TLS) protocol. The TLS protocol provides communications security (TLS) protocol. The TLS protocol provides communications security
over the Internet. The protocol allows client/server applications to over the Internet. The protocol allows client/server applications to
communicate in a way that is designed to prevent eavesdropping, communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery. tampering, or message forgery.
Table of Contents Table of Contents
1. Introduction 3 1. Introduction 3
1.1 Requirements Terminology 5 1.1 Requirements Terminology 5
1.2 Major Differences from TLS 1.1 5 1.2 Major Differences from TLS 1.1 5
2. Goals 5 2. Goals 6
3. Goals of This Document 6 3. Goals of This Document 6
4. Presentation Language 6 4. Presentation Language 7
4.1. Basic Block Size 7 4.1. Basic Block Size 7
4.2. Miscellaneous 7 4.2. Miscellaneous 7
4.3. Vectors 7 4.3. Vectors 7
4.4. Numbers 8 4.4. Numbers 8
4.5. Enumerateds 9 4.5. Enumerateds 9
4.6. Constructed Types 9 4.6. Constructed Types 10
4.6.1. Variants 10 4.6.1. Variants 10
4.7. Cryptographic Attributes 11 4.7. Cryptographic Attributes 11
4.8. Constants 12 4.8. Constants 12
5. HMAC and the Pseudorandom fFunction 13 5. HMAC and the Pseudorandom Function 13
6. The TLS Record Protocol 14 6. The TLS Record Protocol 14
6.1. Connection States 14 6.1. Connection States 15
6.2. Record layer 17 6.2. Record layer 17
6.2.1. Fragmentation 17 6.2.1. Fragmentation 17
6.2.2. Record Compression and Decompression 18 6.2.2. Record Compression and Decompression 19
6.2.3. Record Payload Protection 19 6.2.3. Record Payload Protection 19
6.2.3.1. Null or Standard Stream Cipher 20 6.2.3.1. Null or Standard Stream Cipher 20
6.2.3.2. CBC Block Cipher 20 6.2.3.2. CBC Block Cipher 21
6.2.3.3. AEAD ciphers 22 6.2.3.3. AEAD ciphers 22
6.3. Key Calculation 23 6.3. Key Calculation 24
7. The TLS Handshaking Protocols 24 7. The TLS Handshaking Protocols 25
7.1. Change Cipher Spec Protocol 25 7.1. Change Cipher Spec Protocol 25
7.2. Alert Protocol 26 7.2. Alert Protocol 26
7.2.1. Closure Alerts 27 7.2.1. Closure Alerts 27
7.2.2. Error Alerts 27 7.2.2. Error Alerts 28
7.3. Handshake Protocol Overview 31 7.3. Handshake Protocol Overview 31
7.4. Handshake Protocol 35 7.4. Handshake Protocol 34
7.4.1. Hello Messages 36 7.4.1. Hello Messages 35
7.4.1.1. Hello Request 36 7.4.1.1. Hello Request 35
7.4.1.2. Client Hello 37 7.4.1.2. Client Hello 36
7.4.1.3. Server Hello 40 7.4.1.3. Server Hello 39
7.4.1.4 Hello Extensions 41 7.4.1.4 Hello Extensions 41
7.4.1.4.1 Cert Hash Types 43 7.4.1.4.1 Cert Hash Types 42
7.4.2. Server Certificate 43 7.4.2. Server Certificate 42
7.4.3. Server Key Exchange Message 45 7.4.3. Server Key Exchange Message 44
7.4.4. Certificate Request 47 7.4.4. Certificate Request 46
7.4.5 Server hello done 49 7.4.5 Server hello done 48
7.4.6. Client Certificate 49 7.4.6. Client Certificate 48
7.4.7. Client Key Exchange Message 49 7.4.7. Client Key Exchange Message 49
7.4.7.1. RSA Encrypted Premaster Secret Message 50 7.4.7.1. RSA Encrypted Premaster Secret Message 49
7.4.7.1. Client Diffie-Hellman Public Value 53 7.4.7.2. Client Diffie-Hellman Public Value 52
7.4.8. Certificate verify 53 7.4.8. Certificate verify 52
7.4.9. Finished 54 7.4.9. Finished 53
8. Cryptographic Computations 55 8. Cryptographic Computations 55
8.1. Computing the Master Secret 55 8.1. Computing the Master Secret 55
8.1.1. RSA 56 8.1.1. RSA 55
8.1.2. Diffie-Hellman 56 8.1.2. Diffie-Hellman 55
9. Mandatory Cipher Suites 56 9. Mandatory Cipher Suites 56
10. Application Data Protocol 56 10. Application Data Protocol 56
11. Security Considerations 56 11. Security Considerations 56
12. IANA Considerations 57 12. IANA Considerations 56
A. Protocol Constant Values 59 A. Protocol Constant Values 58
A.1. Record Layer 59 A.1. Record Layer 58
A.2. Change Cipher Specs Message 60 A.2. Change Cipher Specs Message 59
A.3. Alert Messages 60 A.3. Alert Messages 59
A.4. Handshake Protocol 62 A.4. Handshake Protocol 61
A.4.1. Hello Messages 62 A.4.1. Hello Messages 61
A.4.2. Server Authentication and Key Exchange Messages 63 A.4.2. Server Authentication and Key Exchange Messages 62
A.4.3. Client Authentication and Key Exchange Messages 65 A.4.3. Client Authentication and Key Exchange Messages 64
A.4.4. Handshake Finalization Message 65 A.4.4. Handshake Finalization Message 64
A.5. The CipherSuite 65 A.5. The CipherSuite 64
A.6. The Security Parameters 68 A.6. The Security Parameters 67
B. Glossary 70 B. Glossary 68
C. CipherSuite Definitions 74 C. CipherSuite Definitions 72
D. Implementation Notes 76 D. Implementation Notes 74
D.1 Random Number Generation and Seeding 76 D.1 Random Number Generation and Seeding 74
D.2 Certificates and Authentication 76 D.2 Certificates and Authentication 74
D.3 CipherSuites 76 D.3 CipherSuites 74
D.4 Implementation Pitfalls 74
E. Backward Compatibility 77 E. Backward Compatibility 77
E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 77 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 77
E.2 Compatibility with SSL 2.0 78 E.2 Compatibility with SSL 2.0 78
E.2. Avoiding Man-in-the-Middle Version Rollback 80 E.3. Avoiding Man-in-the-Middle Version Rollback 80
F. Security Analysis 81 F. Security Analysis 81
F.1. Handshake Protocol 81 F.1. Handshake Protocol 81
F.1.1. Authentication and Key Exchange 81 F.1.1. Authentication and Key Exchange 81
F.1.1.1. Anonymous Key Exchange 81 F.1.1.1. Anonymous Key Exchange 81
F.1.1.2. RSA Key Exchange and Authentication 82 F.1.1.2. RSA Key Exchange and Authentication 82
F.1.1.3. Diffie-Hellman Key Exchange with Authentication 82 F.1.1.3. Diffie-Hellman Key Exchange with Authentication 82
F.1.2. Version Rollback Attacks 83 F.1.2. Version Rollback Attacks 83
F.1.3. Detecting Attacks Against the Handshake Protocol 84 F.1.3. Detecting Attacks Against the Handshake Protocol 84
F.1.4. Resuming Sessions 84 F.1.4. Resuming Sessions 84
F.1.5 Extensions 85
F.2. Protecting Application Data 85 F.2. Protecting Application Data 85
F.3. Explicit IVs 85 F.3. Explicit IVs 85
F.4. Security of Composite Cipher Modes 86 F.4. Security of Composite Cipher Modes 85
F.5 Denial of Service 87 F.5 Denial of Service 86
F.6. Final Notes 87
1. Introduction 1. Introduction
The primary goal of the TLS Protocol is to provide privacy and data The primary goal of the TLS Protocol is to provide privacy and data
integrity between two communicating applications. The protocol is integrity between two communicating applications. The protocol is
composed of two layers: the TLS Record Protocol and the TLS Handshake composed of two layers: the TLS Record Protocol and the TLS Handshake
Protocol. At the lowest level, layered on top of some reliable Protocol. At the lowest level, layered on top of some reliable
transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
TLS Record Protocol provides connection security that has two basic TLS Record Protocol provides connection security that has two basic
properties: properties:
skipping to change at page 96, line ? skipping to change at page 96, line ?
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2 Major Differences from TLS 1.1 1.2 Major Differences from TLS 1.1
This document is a revision of the TLS 1.1 [TLS1.1] protocol which This document is a revision of the TLS 1.1 [TLS1.1] protocol which
contains improved flexibility, particularly for negotiation of contains improved flexibility, particularly for negotiation of
cryptographic algorithms. The major changes are: cryptographic algorithms. The major changes are:
- Merged in TLS Extensions definition and AES Cipher Suites from - Merged in TLS Extensions definition and AES Cipher Suites from
external documents. external documents [TLSEXT] and [TLSAES].
- Replacement of MD5/SHA-1 combination in the PRF. Addition - Replacement of MD5/SHA-1 combination in the PRF. Addition
of cipher-suite specified PRFs. of cipher-suite specified PRFs.
- Replacement of MD5/SHA-1 combination in the digitally-signed - Replacement of MD5/SHA-1 combination in the digitally-signed
element. element.
- Allow the client to indicate which hash functions it supports - Allow the client to indicate which hash functions it supports
for digital signature. for digital signature.
skipping to change at page 96, line ? skipping to change at page 96, line ?
- The usual clarifications and editorial work. - The usual clarifications and editorial work.
- Added some guidance that DH groups should be checked. - Added some guidance that DH groups should be checked.
- Cleaned up description of Bleichenbacher/Klima attack defenses. - Cleaned up description of Bleichenbacher/Klima attack defenses.
- Tighter checking of EncryptedPreMasterSecret version numbers. - Tighter checking of EncryptedPreMasterSecret version numbers.
- Stronger language about when alerts MUST be sent. - Stronger language about when alerts MUST be sent.
- Added an Implementation Pitfalls sections
- Harmonized the requirement to send an empty certificate list
after certificate_request even when no certs are available.
- Made the verify_data length depend on the cipher suite.
- TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
cipher suite.
2. Goals 2. Goals
The goals of TLS Protocol, in order of their priority, are as The goals of TLS Protocol, in order of their priority, are as
follows: follows:
1. Cryptographic security: TLS should be used to establish a secure 1. Cryptographic security: TLS should be used to establish a secure
connection between two parties. connection between two parties.
2. Interoperability: Independent programmers should be able to 2. Interoperability: Independent programmers should be able to
develop applications utilizing TLS that can successfully exchange develop applications utilizing TLS that can successfully exchange
skipping to change at page 96, line ? skipping to change at page 96, line ?
will be an exact multiple of the cipher block length. will be an exact multiple of the cipher block length.
In AEAD encryption, the plaintext is simultaneously encrypted and In AEAD encryption, the plaintext is simultaneously encrypted and
integrity protected. The input may be of any length and the output is integrity protected. The input may be of any length and the output is
generally larger than the input in order to accomodate the integrity generally larger than the input in order to accomodate the integrity
check value. check value.
In public key encryption, a public key algorithm is used to encrypt In public key encryption, a public key algorithm is used to encrypt
data in such a way that it can be decrypted only with the matching data in such a way that it can be decrypted only with the matching
private key. A public-key-encrypted element is encoded as an opaque private key. A public-key-encrypted element is encoded as an opaque
vector <0..2^16-1>, where the length is specified by the signing vector <0..2^16-1>, where the length is specified by the encryption
algorithm and key. algorithm and key.
RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
defined in [PKCS1]. defined in [PKCS1].
In the following example In the following example
stream-ciphered struct { stream-ciphered struct {
uint8 field1; uint8 field1;
uint8 field2; uint8 field2;
skipping to change at page 96, line ? skipping to change at page 96, line ?
the contents of hash are used as input for the signing algorithm, and the contents of hash are used as input for the signing algorithm, and
then the entire structure is encrypted with a stream cipher. The then the entire structure is encrypted with a stream cipher. The
length of this structure, in bytes, would be equal to two bytes for length of this structure, in bytes, would be equal to two bytes for
field1 and field2, plus two bytes for the length of the signature, field1 and field2, plus two bytes for the length of the signature,
plus the length of the output of the signing algorithm. This is known plus the length of the output of the signing algorithm. This is known
because the algorithm and key used for the signing are known prior to because the algorithm and key used for the signing are known prior to
encoding or decoding this structure. encoding or decoding this structure.
4.8. Constants 4.8. Constants
Typed constants can be defined for purposes of specification by Typed constants can be defined for purposes of specification by
declaring a symbol of the desired type and assigning values to it. declaring a symbol of the desired type and assigning values to it.
Under-specified types (opaque, variable length vectors, and Under-specified types (opaque, variable length vectors, and
structures that contain opaque) cannot be assigned values. No fields structures that contain opaque) cannot be assigned values. No fields
of a multi-element structure or vector may be elided. of a multi-element structure or vector may be elided.
For example: For example:
struct { struct {
uint8 f1; uint8 f1;
uint8 f2; uint8 f2;
} Example1; } Example1;
Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */ Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
5. HMAC and the Pseudorandom fFunction 5. HMAC and the Pseudorandom Function
A number of operations in the TLS record and handshake layer requires The TLS record layer uses a keyed Message Authentication Code (MAC)
a keyed MAC; this is a secure digest of some data protected by a to protect message integrity. The cipher suites defined in this
secret. Forging the MAC is infeasible without knowledge of the MAC document use a construction known as HMAC, described in [HMAC], which
secret. The construction TLS provides for this operation is known as is based on a hash function. Other cipher suites MAY define their own
HMAC and is described in [HMAC]. Cipher suites MAY define their own MAC constructions, if needed.
MACs.
In addition, a construction is required to do expansion of secrets In addition, a construction is required to do expansion of secrets
into blocks of data for the purposes of key generation or validation. into blocks of data for the purposes of key generation or validation.
This pseudo-random function (PRF) takes as input a secret, a seed, This pseudo-random function (PRF) takes as input a secret, a seed,
and an identifying label and produces an output of arbitrary length. and an identifying label and produces an output of arbitrary length.
We define one PRF, based on HMAC, which is used for all cipher suites
in this document. Cipher suites MAY define their own PRFs. In this section, we define one PRF, based on HMAC. This PRF with the
SHA-256 hash function is used for all cipher suites defined in this
document and in TLS documents published prior to this document. New
cipher suites MUST explicitly specify a PRF and in general SHOULD use
the TLS PRF with SHA-256 or a stronger standard hash function.
First, we define a data expansion function, P_hash(secret, data) that First, we define a data expansion function, P_hash(secret, data) that
uses a single hash function to expand a secret and seed into an uses a single hash function to expand a secret and seed into an
arbitrary quantity of output: arbitrary quantity of output:
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + ... HMAC_hash(secret, A(3) + seed) + ...
Where + indicates concatenation. Where + indicates concatenation.
skipping to change at page 96, line ? skipping to change at page 96, line ?
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + ... HMAC_hash(secret, A(3) + seed) + ...
Where + indicates concatenation. Where + indicates concatenation.
A() is defined as: A() is defined as:
A(0) = seed A(0) = seed
A(i) = HMAC_hash(secret, A(i-1)) A(i) = HMAC_hash(secret, A(i-1))
P_hash can be iterated as many times as is necessary to produce the P_hash can be iterated as many times as is necessary to produce the
required quantity of data. For example, if P_SHA-1 is being used to required quantity of data. For example, if P_SHA-1 is being used to
create 64 bytes of data, it will have to be iterated 4 times (through create 64 bytes of data, it will have to be iterated 4 times (through
A(4)), creating 80 bytes of output data; the last 16 bytes of the A(4)), creating 80 bytes of output data; the last 16 bytes of the
final iteration will then be discarded, leaving 64 bytes of output final iteration will then be discarded, leaving 64 bytes of output
data. data.
TLS's PRF is created by applying P_hash to the secret S as: TLS's PRF is created by applying P_hash to the secret S as:
PRF(secret, label, seed) = P_<hash>(secret, label + seed) PRF(secret, label, seed) = P_<hash>(secret, label + seed)
All the cipher suites defined in this document and in TLS documents
prior to this document MUST use SHA-256 as the basis for their PRF.
New cipher suites MUST specify a PRF and in general SHOULD use the
TLS PRF with SHA-256 or a stronger standard hash function.
The label is an ASCII string. It should be included in the exact form The label is an ASCII string. It should be included in the exact form
it is given without a length byte or trailing null character. For it is given without a length byte or trailing null character. For
example, the label "slithy toves" would be processed by hashing the example, the label "slithy toves" would be processed by hashing the
following bytes: following bytes:
73 6C 69 74 68 79 20 74 6F 76 65 73 73 6C 69 74 68 79 20 74 6F 76 65 73
6. The TLS Record Protocol 6. The TLS Record Protocol
The TLS Record Protocol is a layered protocol. At each layer, The TLS Record Protocol is a layered protocol. At each layer,
skipping to change at page 96, line ? skipping to change at page 96, line ?
data into manageable blocks, optionally compresses the data, applies data into manageable blocks, optionally compresses the data, applies
a MAC, encrypts, and transmits the result. Received data is a MAC, encrypts, and transmits the result. Received data is
decrypted, verified, decompressed, reassembled, and then delivered to decrypted, verified, decompressed, reassembled, and then delivered to
higher-level clients. higher-level clients.
Four record protocol clients are described in this document: the Four record protocol clients are described in this document: the
handshake protocol, the alert protocol, the change cipher spec handshake protocol, the alert protocol, the change cipher spec
protocol, and the application data protocol. In order to allow protocol, and the application data protocol. In order to allow
extension of the TLS protocol, additional record types can be extension of the TLS protocol, additional record types can be
supported by the record protocol. New record type values are assigned supported by the record protocol. New record type values are assigned
by IANA as described in Section 11. by IANA as described in Section 12.
If a TLS implementation receives a record type it does not Implementations MUST NOT send record types not defined in this
understand, it SHOULD just ignore it. Any protocol designed for use document unless negotiated by some extension. If a TLS
over TLS MUST be carefully designed to deal with all possible attacks implementation receives an unexpected record type, it MUST send a
against it. Note that because the type and length of a record are unexpected_message alert."
not protected by encryption, care SHOULD be taken to minimize the
value of traffic analysis of these values. Implementations MUST not Any protocol designed for use over TLS MUST be carefully designed to
send record types not defined in this document unless negotiated by deal with all possible attacks against it. Note that because the
some extension. type and length of a record are not protected by encryption, care
SHOULD be taken to minimize the value of traffic analysis of these
values.
6.1. Connection States 6.1. Connection States
A TLS connection state is the operating environment of the TLS Record A TLS connection state is the operating environment of the TLS Record
Protocol. It specifies a compression algorithm, an encryption Protocol. It specifies a compression algorithm, an encryption
algorithm, and MAC algorithm. In addition, the parameters for these algorithm, and a MAC algorithm. In addition, the parameters for these
algorithms are known: the MAC secret and the bulk encryption keys for algorithms are known: the MAC secret and the bulk encryption keys for
the connection in both the read and the write directions. Logically, the connection in both the read and the write directions. Logically,
there are always four connection states outstanding: the current read there are always four connection states outstanding: the current read
and write states, and the pending read and write states. All records and write states, and the pending read and write states. All records
are processed under the current read and write states. The security are processed under the current read and write states. The security
parameters for the pending states can be set by the TLS Handshake parameters for the pending states can be set by the TLS Handshake
Protocol, and the Change Cipher Spec can selectively make either of Protocol, and the Change Cipher Spec can selectively make either of
the pending states current, in which case the appropriate current the pending states current, in which case the appropriate current
state is disposed of and replaced with the pending state; the pending state is disposed of and replaced with the pending state; the pending
state is then reinitialized to an empty state. It is illegal to make state is then reinitialized to an empty state. It is illegal to make
skipping to change at page 96, line ? skipping to change at page 96, line ?
A 32-byte value provided by the client. A 32-byte value provided by the client.
server random server random
A 32-byte value provided by the server. A 32-byte value provided by the server.
These parameters are defined in the presentation language as: These parameters are defined in the presentation language as:
enum { server, client } ConnectionEnd; enum { server, client } ConnectionEnd;
enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm; enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm;
enum { stream, block, aead } CipherType; enum { stream, block, aead } CipherType;
enum { null, md5, sha, sha256, sha384, sha512} MACAlgorithm; enum { null, md5, sha, sha256, sha384, sha512} MACAlgorithm;
/* The use of "sha" above is historical and denotes SHA-1 */ /* The use of "sha" above is historical and denotes SHA-1 */
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
/* The algorithms specified in CompressionMethod, /* The algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */ BulkCipherAlgorithm, and MACAlgorithm may be added to. */
struct { struct {
ConnectionEnd entity; ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm; BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type; CipherType cipher_type;
uint8 enc_key_length; uint8 enc_key_length;
uint8 block_length; uint8 block_length;
uint8 iv_length; uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm; MACAlgorithm mac_algorithm;
uint8 mac_length; uint8 mac_length;
uint8 mac_key_length; uint8 mac_key_length;
uint8 verify_data_length;
CompressionMethod compression_algorithm; CompressionMethod compression_algorithm;
opaque master_secret[48]; opaque master_secret[48];
opaque client_random[32]; opaque client_random[32];
opaque server_random[32]; opaque server_random[32];
} SecurityParameters; } SecurityParameters;
The record layer will use the security parameters to generate the The record layer will use the security parameters to generate the
following four items: following four items:
client write MAC secret client write MAC secret
skipping to change at page 96, line ? skipping to change at page 96, line ?
describes TLS Version 1.2, which uses the version { 3, 3 }. The describes TLS Version 1.2, which uses the version { 3, 3 }. The
version value 3.3 is historical, deriving from the use of 3.1 for version value 3.3 is historical, deriving from the use of 3.1 for
TLS 1.0. (See Appendix A.1). Note that a client that supports TLS 1.0. (See Appendix A.1). Note that a client that supports
multiple versions of TLS may not know what version will be multiple versions of TLS may not know what version will be
employed before it receives ServerHello. See Appendix E for employed before it receives ServerHello. See Appendix E for
discussion about what record layer version number should be discussion about what record layer version number should be
employed for ClientHello. employed for ClientHello.
length length
The length (in bytes) of the following TLSPlaintext.fragment. The length (in bytes) of the following TLSPlaintext.fragment.
The length MUST not exceed 2^14. The length MUST NOT exceed 2^14.
fragment fragment
The application data. This data is transparent and treated as an The application data. This data is transparent and treated as an
independent block to be dealt with by the higher-level protocol independent block to be dealt with by the higher-level protocol
specified by the type field. specified by the type field.
Implementations MUST not send zero-length fragments of Handshake, Implementations MUST NOT send zero-length fragments of Handshake,
Alert, or Change Cipher Spec content types. Zero-length fragments Alert, or Change Cipher Spec content types. Zero-length fragments
of Application data MAY be sent as they are potentially useful as of Application data MAY be sent as they are potentially useful as
a traffic analysis countermeasure. a traffic analysis countermeasure.
Note: Data of different TLS Record layer content types MAY be Note: Data of different TLS Record layer content types MAY be
interleaved. Application data is generally of lower precedence interleaved. Application data is generally of lower precedence
for transmission than other content types. However, records MUST for transmission than other content types. However, records MUST
be delivered to the network in the same order as they are be delivered to the network in the same order as they are
protected by the record layer. Recipients MUST receive and protected by the record layer. Recipients MUST receive and
process interleaved application layer traffic during handshakes process interleaved application layer traffic during handshakes
skipping to change at page 96, line ? skipping to change at page 96, line ?
struct { struct {
ContentType type; /* same as TLSPlaintext.type */ ContentType type; /* same as TLSPlaintext.type */
ProtocolVersion version;/* same as TLSPlaintext.version */ ProtocolVersion version;/* same as TLSPlaintext.version */
uint16 length; uint16 length;
opaque fragment[TLSCompressed.length]; opaque fragment[TLSCompressed.length];
} TLSCompressed; } TLSCompressed;
length length
The length (in bytes) of the following TLSCompressed.fragment. The length (in bytes) of the following TLSCompressed.fragment.
The length should not exceed 2^14 + 1024. The length MUST NOT exceed 2^14 + 1024.
fragment fragment
The compressed form of TLSPlaintext.fragment. The compressed form of TLSPlaintext.fragment.
Note: A CompressionMethod.null operation is an identity operation; no Note: A CompressionMethod.null operation is an identity operation; no
fields are altered. fields are altered.
Implementation note: Implementation note:
Decompression functions are responsible for ensuring that Decompression functions are responsible for ensuring that
messages cannot cause internal buffer overflows. messages cannot cause internal buffer overflows.
skipping to change at page 96, line ? skipping to change at page 96, line ?
} TLSCiphertext; } TLSCiphertext;
type type
The type field is identical to TLSCompressed.type. The type field is identical to TLSCompressed.type.
version version
The version field is identical to TLSCompressed.version. The version field is identical to TLSCompressed.version.
length length
The length (in bytes) of the following TLSCiphertext.fragment. The length (in bytes) of the following TLSCiphertext.fragment.
The length may not exceed 2^14 + 2048. The length MUST NOT exceed 2^14 + 2048.
fragment fragment
The encrypted form of TLSCompressed.fragment, with the MAC. The encrypted form of TLSCompressed.fragment, with the MAC.
6.2.3.1. Null or Standard Stream Cipher 6.2.3.1. Null or Standard Stream Cipher
Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6) Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
convert TLSCompressed.fragment structures to and from stream convert TLSCompressed.fragment structures to and from stream
TLSCiphertext.fragment structures. TLSCiphertext.fragment structures.
stream-ciphered struct { stream-ciphered struct {
opaque content[TLSCompressed.length]; opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length]; opaque MAC[SecurityParameters.mac_length];
} GenericStreamCipher; } GenericStreamCipher;
The MAC is generated as: The MAC is generated as:
HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + MAC(MAC_write_secret, seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length + TLSCompressed.version + TLSCompressed.length +
TLSCompressed.fragment)); TLSCompressed.fragment);
where "+" denotes concatenation. where "+" denotes concatenation.
seq_num seq_num
The sequence number for this record. The sequence number for this record.
hash hash
The hashing algorithm specified by The hashing algorithm specified by
SecurityParameters.mac_algorithm. SecurityParameters.mac_algorithm.
skipping to change at page 96, line ? skipping to change at page 96, line ?
encrypts the entire block, including the MAC. For stream ciphers that encrypts the entire block, including the MAC. For stream ciphers that
do not use a synchronization vector (such as RC4), the stream cipher do not use a synchronization vector (such as RC4), the stream cipher
state from the end of one record is simply used on the subsequent state from the end of one record is simply used on the subsequent
packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
consists of the identity operation (i.e., the data is not encrypted, consists of the identity operation (i.e., the data is not encrypted,
and the MAC size is zero, implying that no MAC is used). and the MAC size is zero, implying that no MAC is used).
TLSCiphertext.length is TLSCompressed.length plus TLSCiphertext.length is TLSCompressed.length plus
SecurityParameters.mac_length. SecurityParameters.mac_length.
6.2.3.2. CBC Block Cipher 6.2.3.2. CBC Block Cipher
For block ciphers (such as RC2, DES, or AES), the encryption and MAC For block ciphers (such as RC2, DES, or AES), the encryption and MAC
functions convert TLSCompressed.fragment structures to and from block functions convert TLSCompressed.fragment structures to and from block
TLSCiphertext.fragment structures. TLSCiphertext.fragment structures.
struct {
opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct { block-ciphered struct {
opaque IV[SecurityParameters.block_length];
opaque content[TLSCompressed.length]; opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length]; opaque MAC[SecurityParameters.mac_length];
uint8 padding[GenericBlockCipher.padding_length]; uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length; uint8 padding_length;
} GenericBlockCipher; };
} GenericBlockCipher;
The MAC is generated as described in Section 6.2.3.1. The MAC is generated as described in Section 6.2.3.1.
IV IV
TLS 1.2 uses an explicit IV in order to prevent the attacks The Initialization Vector (IV) SHOULD be chosen at random, and
described by [CBCATT]. The IV SHOULD be chosen at random and MUST MUST be unpredictable. Note that in versions of TLS prior to 1.1,
be unpredictable. In order to decrypt, thereceiver decrypts the there was no IV field, and the last ciphertext block of the
entire GenericBlockCipher structure and then discards the first previous record (the "CBC residue") was used as the IV. This was
cipher block, corresponding to the IV component. changed to prevent the attacks described in [CBCATT]. For block
ciphers, the IV length is of length
SecurityParameters.record_iv_length which is equal to the
SecurityParameters.block_size.
padding padding
Padding that is added to force the length of the plaintext to be Padding that is added to force the length of the plaintext to be
an integral multiple of the block cipher's block length. The an integral multiple of the block cipher's block length. The
padding MAY be any length up to 255 bytes, as long as it results padding MAY be any length up to 255 bytes, as long as it results
in the TLSCiphertext.length being an integral multiple of the in the TLSCiphertext.length being an integral multiple of the
block length. Lengths longer than necessary might be desirable to block length. Lengths longer than necessary might be desirable to
frustrate attacks on a protocol that are based on analysis of the frustrate attacks on a protocol that are based on analysis of the
lengths of exchanged messages. Each uint8 in the padding data lengths of exchanged messages. Each uint8 in the padding data
vector MUST be filled with the padding length value. The receiver vector MUST be filled with the padding length value. The receiver
MUST check this padding and SHOULD use the bad_record_mac alert MUST check this padding and MUST use the bad_record_mac alert to
to indicate padding errors. indicate padding errors.
padding_length padding_length
The padding length MUST be such that the total size of the The padding length MUST be such that the total size of the
GenericBlockCipher structure is a multiple of the cipher's block GenericBlockCipher structure is a multiple of the cipher's block
length. Legal values range from zero to 255, inclusive. This length. Legal values range from zero to 255, inclusive. This
length specifies the length of the padding field exclusive of the length specifies the length of the padding field exclusive of the
padding_length field itself. padding_length field itself.
The encrypted data length (TLSCiphertext.length) is one more than the The encrypted data length (TLSCiphertext.length) is one more than the
sum of TLSCompressed.length, SecurityParameters.mac_length, and sum of one more than the sum of SecurityParameters.block_length,
TLSCompressed.length, SecurityParameters.mac_length, and
padding_length. padding_length.
Example: If the block length is 8 bytes, the content length Example: If the block length is 8 bytes, the content length
(TLSCompressed.length) is 61 bytes, and the MAC length is 20 (TLSCompressed.length) is 61 bytes, and the MAC length is 20
bytes, then the length before padding is 82 bytes (this does bytes, then the length before padding is 82 bytes (this does
not include the IV, which may or may not be encrypted, as not include the IV. Thus, the padding length modulo 8 must be
discussed above). Thus, the padding length modulo 8 must be
equal to 6 in order to make the total length an even multiple equal to 6 in order to make the total length an even multiple
of 8 bytes (the block length). The padding length can be 6, of 8 bytes (the block length). The padding length can be 6,
14, 22, and so on, through 254. If the padding length were the 14, 22, and so on, through 254. If the padding length were the
minimum necessary, 6, the padding would be 6 bytes, each minimum necessary, 6, the padding would be 6 bytes, each
containing the value 6. Thus, the last 8 octets of the containing the value 6. Thus, the last 8 octets of the
GenericBlockCipher before block encryption would be xx 06 06 GenericBlockCipher before block encryption would be xx 06 06
06 06 06 06 06, where xx is the last octet of the MAC. 06 06 06 06 06, where xx is the last octet of the MAC.
Note: With block ciphers in CBC mode (Cipher Block Chaining), Note: With block ciphers in CBC mode (Cipher Block Chaining),
it is critical that the entire plaintext of the record be known it is critical that the entire plaintext of the record be known
skipping to change at page 96, line ? skipping to change at page 96, line ?
the size of the data fragment, but it is not believed to be large the size of the data fragment, but it is not believed to be large
enough to be exploitable, due to the large block size of existing enough to be exploitable, due to the large block size of existing
MACs and the small size of the timing signal. MACs and the small size of the timing signal.
6.2.3.3. AEAD ciphers 6.2.3.3. AEAD ciphers
For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
converts TLSCompressed.fragment structures to and from AEAD converts TLSCompressed.fragment structures to and from AEAD
TLSCiphertext.fragment structures. TLSCiphertext.fragment structures.
aead-ciphered struct { struct {
opaque IV[SecurityParameters.iv_length]; opaque nonce_explicit[SecurityParameters.record_iv_length];
opaque aead_output[AEADEncrypted.length];
} GenericAEADCipher; aead-ciphered struct {
opaque content[TLSCompressed.length];
};
} GenericAEADCipher;
AEAD ciphers take as input a single key, a nonce, a plaintext, and AEAD ciphers take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as "additional data" to be included in the authentication check, as
described in Section 2.1 of [AEAD]. These inputs are as follows. described in Section 2.1 of [AEAD]. These inputs are as follows.
The key is either the client_write_key or the server_write_key. The The key is either the client_write_key or the server_write_key. No
MAC key will be of length zero. MAC key is used.
The nonce supplied to the AEAD operations is determined by the IV in Each AEAD cipher suite has to specify how the nonce supplied to the
aead-ciphered struct. Each IV used in distinct invocations of the AEAD operation is constructed, and what is the length of the
AEAD encryption operation MUST be distinct, for any fixed value of GenericAEADCipher.nonce_explicit part. In many cases, it is
the key. Implementations SHOULD use the recommended nonce formation appropriate to use the partially implicit nonce technique described
method of [AEAD] to generate IVs, and MAY use any other method that in Section 3.2.1 of [AEAD]; in this case, the implicit part SHOULD be
meets this requirement. The length of the IV depends on the AEAD derived from key_block as client_write_iv and server_write_iv (as
cipher; that length MAY be zero. Note that in many cases it is described in Section 6.3), and the explicit part is included in
appropriate to use the partially implicit nonce technique of S 3.2.1 GenericAEAEDCipher.nonce_explicit.
of AEAD, in which case the client_write_iv and server_write_iv should
be used as the "fixed-common".
The plaintext is the TLSCompressed.fragment. The plaintext is the TLSCompressed.fragment.
The additional authenticated data, which we denote as The additional authenticated data, which we denote as
additional_data, is defined as follows: additional_data, is defined as follows:
additional_data = seq_num + TLSCompressed.type + additional_data = seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length; TLSCompressed.version + TLSCompressed.length;
Where "+" denotes concatenation.
The aead_output consists of the ciphertext output by the AEAD The aead_output consists of the ciphertext output by the AEAD
encryption operation. AEADEncrypted.length will generally be larger encryption operation. The length will generally be larger than
than TLSCompressed.length, but by an amount that varies with the AEAD TLSCompressed.length, but by an amount that varies with the AEAD
cipher. Since the ciphers might incorporate padding, the amount of cipher. Since the ciphers might incorporate padding, the amount of
overhead could vary with different TLSCompressed.length values. Each overhead could vary with different TLSCompressed.length values. Each
AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
Symbolically, Symbolically,
AEADEncrypted = AEAD-Encrypt(key, IV, plaintext, AEADEncrypted = AEAD-Encrypt(key, IV, plaintext,
additional_data) additional_data)
Where "+" denotes concatenation.
In order to decrypt and verify, the cipher takes as input the key, In order to decrypt and verify, the cipher takes as input the key,
IV, the "additional_data", and the AEADEncrypted value. The output is IV, the "additional_data", and the AEADEncrypted value. The output is
either the plaintext or an error indicating that the decryption either the plaintext or an error indicating that the decryption
failed. There is no separate integrity check. I.e., failed. There is no separate integrity check. I.e.,
TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, AEADEncrypted, TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, AEADEncrypted,
TLSCiphertext.type + TLSCiphertext.version + additional_data)
TLSCiphertext.length);
If the decryption fails, a fatal bad_record_mac alert MUST be If the decryption fails, a fatal bad_record_mac alert MUST be
generated. generated.
6.3. Key Calculation 6.3. Key Calculation
The Record Protocol requires an algorithm to generate keys, and MAC The Record Protocol requires an algorithm to generate keys, and MAC
secrets from the security parameters provided by the handshake secrets from the security parameters provided by the handshake
protocol. protocol.
skipping to change at page 96, line ? skipping to change at page 96, line ?
SecurityParameters.server_random + SecurityParameters.server_random +
SecurityParameters.client_random); SecurityParameters.client_random);
until enough output has been generated. Then the key_block is until enough output has been generated. Then the key_block is
partitioned as follows: partitioned as follows:
client_write_MAC_secret[SecurityParameters.mac_key_length] client_write_MAC_secret[SecurityParameters.mac_key_length]
server_write_MAC_secret[SecurityParameters.mac_key_length] server_write_MAC_secret[SecurityParameters.mac_key_length]
client_write_key[SecurityParameters.enc_key_length] client_write_key[SecurityParameters.enc_key_length]
server_write_key[SecurityParameters.enc_key_length] server_write_key[SecurityParameters.enc_key_length]
client_write_IV[SecurityParameters.fixed_iv_length]
server_write_IV[SecurityParameters.fixed_iv_length]
The client_write_IV and server_write_IV are only generated for
implicit nonce techniques as described in Section 3.2.1 of [AEAD].
Implementation note: Implementation note:
The currently defined cipher suite which requires the most The currently defined cipher suite which requires the most
material is AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x material is AES_256_CBC_SHA. It requires 2 x 32 byte keys and 2 x
32 byte keys and 2 x 20 byte MAC secrets, for a total 104 bytes 20 byte MAC secrets, for a total 104 bytes of key material.
of key material.
7. The TLS Handshaking Protocols 7. The TLS Handshaking Protocols
TLS has three subprotocols that are used to allow peers to agree TLS has three subprotocols that are used to allow peers to agree
upon security parameters for the record layer, to authenticate upon security parameters for the record layer, to authenticate
themselves, to instantiate negotiated security parameters, and to themselves, to instantiate negotiated security parameters, and to
report error conditions to each other. report error conditions to each other.
The Handshake Protocol is responsible for negotiating a session, The Handshake Protocol is responsible for negotiating a session,
which consists of the following items: which consists of the following items:
session identifier session identifier
An arbitrary byte sequence chosen by the server to identify an An arbitrary byte sequence chosen by the server to identify an
active or resumable session state. active or resumable session state.
peer certificate peer certificate
X509v3 [X509] certificate of the peer. This element of the X509v3 [PKIX] certificate of the peer. This element of the
state may be null. state may be null.
compression method compression method
The algorithm used to compress data prior to encryption. The algorithm used to compress data prior to encryption.
cipher spec cipher spec
Specifies the bulk data encryption algorithm (such as null, Specifies the bulk data encryption algorithm (such as null,
DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also
defines cryptographic attributes such as the mac_length. (See defines cryptographic attributes such as the mac_length. (See
Appendix A.6 for formal definition.) Appendix A.6 for formal definition.)
skipping to change at page 96, line ? skipping to change at page 96, line ?
The change cipher spec message is sent by both the client and the The change cipher spec message is sent by both the client and the
server to notify the receiving party that subsequent records will be server to notify the receiving party that subsequent records will be
protected under the newly negotiated CipherSpec and keys. Reception protected under the newly negotiated CipherSpec and keys. Reception
of this message causes the receiver to instruct the Record Layer to of this message causes the receiver to instruct the Record Layer to
immediately copy the read pending state into the read current state. immediately copy the read pending state into the read current state.
Immediately after sending this message, the sender MUST instruct the Immediately after sending this message, the sender MUST instruct the
record layer to make the write pending state the write active state. record layer to make the write pending state the write active state.
(See Section 6.1.) The change cipher spec message is sent during the (See Section 6.1.) The change cipher spec message is sent during the
handshake after the security parameters have been agreed upon, but handshake after the security parameters have been agreed upon, but
before the verifying finished message is sent (see Section 7.4.11 before the verifying finished message is sent.
Note: If a rehandshake occurs while data is flowing on a connection, Note: If a rehandshake occurs while data is flowing on a connection,
the communicating parties may continue to send data using the old the communicating parties may continue to send data using the old
CipherSpec. However, once the ChangeCipherSpec has been sent, the new CipherSpec. However, once the ChangeCipherSpec has been sent, the new
CipherSpec MUST be used. The first side to send the ChangeCipherSpec CipherSpec MUST be used. The first side to send the ChangeCipherSpec
does not know that the other side has finished computing the new does not know that the other side has finished computing the new
keying material (e.g., if it has to perform a time consuming public keying material (e.g., if it has to perform a time consuming public
key operation). Thus, a small window of time, during which the key operation). Thus, a small window of time, during which the
recipient must buffer the data, MAY exist. In practice, with modern recipient must buffer the data, MAY exist. In practice, with modern
machines this interval is likely to be fairly short. machines this interval is likely to be fairly short.
skipping to change at page 96, line ? skipping to change at page 96, line ?
unknown_ca(48), unknown_ca(48),
access_denied(49), access_denied(49),
decode_error(50), decode_error(50),
decrypt_error(51), decrypt_error(51),
export_restriction_RESERVED(60), export_restriction_RESERVED(60),
protocol_version(70), protocol_version(70),
insufficient_security(71), insufficient_security(71),
internal_error(80), internal_error(80),
user_canceled(90), user_canceled(90),
no_renegotiation(100), no_renegotiation(100),
unsupported_extension(110), /* new */ unsupported_extension(110),
(255) (255)
} AlertDescription; } AlertDescription;
struct { struct {
AlertLevel level; AlertLevel level;
AlertDescription description; AlertDescription description;
} Alert; } Alert;
7.2.1. Closure Alerts 7.2.1. Closure Alerts
skipping to change at page 96, line ? skipping to change at page 96, line ?
proceed with the connection. One case where this would be proceed with the connection. One case where this would be
appropriate is where a server has spawned a process to satisfy a appropriate is where a server has spawned a process to satisfy a
request; the process might receive security parameters (key request; the process might receive security parameters (key
length, authentication, etc.) at startup and it might be length, authentication, etc.) at startup and it might be
difficult to communicate changes to these parameters after that difficult to communicate changes to these parameters after that
point. This message is always a warning. point. This message is always a warning.
unsupported_extension unsupported_extension
sent by clients that receive an extended server hello containing sent by clients that receive an extended server hello containing
an extension that they did not put in the corresponding client an extension that they did not put in the corresponding client
hello (see Section 2.3). This message is always fatal. hello. This message is always fatal.
For all errors where an alert level is not explicitly specified, the For all errors where an alert level is not explicitly specified, the
sending party MAY determine at its discretion whether this is a fatal sending party MAY determine at its discretion whether this is a fatal
error or not; if an alert with a level of warning is received, the error or not; if an alert with a level of warning is received, the
receiving party MAY decide at its discretion whether to treat this as receiving party MAY decide at its discretion whether to treat this as
a fatal error or not. However, all messages that are transmitted a fatal error or not. However, all messages that are transmitted
with a level of fatal MUST be treated as fatal messages. with a level of fatal MUST be treated as fatal messages.
New Alert values are assigned by IANA as described in Section 11. New Alert values are assigned by IANA as described in Section 12.
7.3. Handshake Protocol Overview 7.3. Handshake Protocol Overview
The cryptographic parameters of the session state are produced by the The cryptographic parameters of the session state are produced by the
TLS Handshake Protocol, which operates on top of the TLS Record TLS Handshake Protocol, which operates on top of the TLS Record
Layer. When a TLS client and server first start communicating, they Layer. When a TLS client and server first start communicating, they
agree on a protocol version, select cryptographic algorithms, agree on a protocol version, select cryptographic algorithms,
optionally authenticate each other, and use public-key encryption optionally authenticate each other, and use public-key encryption
techniques to generate shared secrets. techniques to generate shared secrets.
skipping to change at page 96, line ? skipping to change at page 96, line ?
ID, Cipher Suite, and Compression Method. Additionally, two random ID, Cipher Suite, and Compression Method. Additionally, two random
values are generated and exchanged: ClientHello.random and values are generated and exchanged: ClientHello.random and
ServerHello.random. ServerHello.random.
The actual key exchange uses up to four messages: the server The actual key exchange uses up to four messages: the server
certificate, the server key exchange, the client certificate, and the certificate, the server key exchange, the client certificate, and the
client key exchange. New key exchange methods can be created by client key exchange. New key exchange methods can be created by
specifying a format for these messages and by defining the use of the specifying a format for these messages and by defining the use of the
messages to allow the client and server to agree upon a shared messages to allow the client and server to agree upon a shared
secret. This secret MUST be quite long; currently defined key secret. This secret MUST be quite long; currently defined key
exchange methods exchange secrets that range from 48 to 128 bytes in exchange methods exchange secrets that range from 46 bytes upwards.
length.
Following the hello messages, the server will send its certificate, Following the hello messages, the server will send its certificate,
if it is to be authenticated. Additionally, a server key exchange if it is to be authenticated. Additionally, a server key exchange
message may be sent, if it is required (e.g., if their server has no message may be sent, if it is required (e.g., if their server has no
certificate, or if its certificate is for signing only). If the certificate, or if its certificate is for signing only). If the
server is authenticated, it may request a certificate from the server is authenticated, it may request a certificate from the
client, if that is appropriate to the cipher suite selected. Next, client, if that is appropriate to the cipher suite selected. Next,
the server will send the server hello done message, indicating that the server will send the server hello done message, indicating that
the hello-message phase of the handshake is complete. The server will the hello-message phase of the handshake is complete. The server will
then wait for a client response. If the server has sent a certificate then wait for a client response. If the server has sent a certificate
request message, the client must send the certificate message. The request message, the client MUST send the certificate message. The
client key exchange message is now sent, and the content of that client key exchange message is now sent, and the content of that
message will depend on the public key algorithm selected between the message will depend on the public key algorithm selected between the
client hello and the server hello. If the client has sent a client hello and the server hello. If the client has sent a
certificate with signing ability, a digitally-signed certificate certificate with signing ability, a digitally-signed certificate
verify message is sent to explicitly verify possession of the private verify message is sent to explicitly verify possession of the private
key in the certificate. key in the certificate.
At this point, a change cipher spec message is sent by the client, At this point, a change cipher spec message is sent by the client,
and the client copies the pending Cipher Spec into the current Cipher and the client copies the pending Cipher Spec into the current Cipher
Spec. The client then immediately sends the finished message under Spec. The client then immediately sends the finished message under
the new algorithms, keys, and secrets. In response, the server will the new algorithms, keys, and secrets. In response, the server will
send its own change cipher spec message, transfer the pending to the send its own change cipher spec message, transfer the pending to the
current Cipher Spec, and send its finished message under the new current Cipher Spec, and send its finished message under the new
Cipher Spec. At this point, the handshake is complete, and the client Cipher Spec. At this point, the handshake is complete, and the client
and server may begin to exchange application layer data. (See flow and server may begin to exchange application layer data. (See flow
chart below.) Application data MUST NOT be sent prior to the chart below.) Application data MUST NOT be sent prior to the
completion of the first handshake (before a cipher suite other completion of the first handshake (before a cipher suite other than
TLS_NULL_WITH_NULL_NULL is established). TLS_NULL_WITH_NULL_NULL is established).
Client Server Client Server
ClientHello --------> ClientHello -------->
ServerHello ServerHello
Certificate* Certificate*
CertificateStatus*
ServerKeyExchange* ServerKeyExchange*
CertificateRequest* CertificateRequest*
<-------- ServerHelloDone <-------- ServerHelloDone
Certificate* Certificate*
ClientKeyExchange ClientKeyExchange
CertificateVerify* CertificateVerify*
[ChangeCipherSpec] [ChangeCipherSpec]
Finished --------> Finished -------->
[ChangeCipherSpec] [ChangeCipherSpec]
<-------- Finished <-------- Finished
skipping to change at page 96, line ? skipping to change at page 96, line ?
secure attributes of a session. Handshake messages are supplied to secure attributes of a session. Handshake messages are supplied to
the TLS Record Layer, where they are encapsulated within one or more the TLS Record Layer, where they are encapsulated within one or more
TLSPlaintext structures, which are processed and transmitted as TLSPlaintext structures, which are processed and transmitted as
specified by the current active session state. specified by the current active session state.
enum { enum {
hello_request(0), client_hello(1), server_hello(2), hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12), certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14), certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16), certificate_verify(15), client_key_exchange(16),
finished(20) finished(20), (255)
(255)
} HandshakeType; } HandshakeType;
struct { struct {
HandshakeType msg_type; /* handshake type */ HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */ uint24 length; /* bytes in message */
select (HandshakeType) { select (HandshakeType) {
case hello_request: HelloRequest; case hello_request: HelloRequest;
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case certificate: Certificate; case certificate: Certificate;
skipping to change at page 96, line ? skipping to change at page 96, line ?
MUST be sent; sending handshake messages in an unexpected order MUST be sent; sending handshake messages in an unexpected order
results in a fatal error. Unneeded handshake messages can be omitted, results in a fatal error. Unneeded handshake messages can be omitted,
however. Note one exception to the ordering: the Certificate message however. Note one exception to the ordering: the Certificate message
is used twice in the handshake (from server to client, then from is used twice in the handshake (from server to client, then from
client to server), but described only in its first position. The one client to server), but described only in its first position. The one
message that is not bound by these ordering rules is the Hello message that is not bound by these ordering rules is the Hello
Request message, which can be sent at any time, but which should be Request message, which can be sent at any time, but which should be
ignored by the client if it arrives in the middle of a handshake. ignored by the client if it arrives in the middle of a handshake.
New Handshake message types are assigned by IANA as described in New Handshake message types are assigned by IANA as described in
Section 11. Section 12.
7.4.1. Hello Messages 7.4.1. Hello Messages
The hello phase messages are used to exchange security enhancement The hello phase messages are used to exchange security enhancement
capabilities between the client and server. When a new session capabilities between the client and server. When a new session
begins, the Record Layer's connection state encryption, hash, and begins, the Record Layer's connection state encryption, hash, and
compression algorithms are initialized to null. The current compression algorithms are initialized to null. The current
connection state is used for renegotiation messages. connection state is used for renegotiation messages.
7.4.1.1. Hello Request 7.4.1.1. Hello Request
skipping to change at page 96, line ? skipping to change at page 96, line ?
begins, the Record Layer's connection state encryption, hash, and begins, the Record Layer's connection state encryption, hash, and
compression algorithms are initialized to null. The current compression algorithms are initialized to null. The current
connection state is used for renegotiation messages. connection state is used for renegotiation messages.
7.4.1.1. Hello Request 7.4.1.1. Hello Request
When this message will be sent: When this message will be sent:
The hello request message MAY be sent by the server at any time. The hello request message MAY be sent by the server at any time.
Meaning of this message: Meaning of this message:
Hello request is a simple notification that the client should Hello request is a simple notification that the client should
begin the negotiation process anew by sending a client hello begin the negotiation process anew by sending a client hello
message when convenient. This message is not intended to message when convenient. This message is not intended to
establish which side is the client or server but merely to establish which side is the client or server but merely to
initiate a new negotiation. Servers SHOULD not send a initiate a new negotiation. Servers SHOULD NOT send a
HelloRequest immediately upon the client's initial connection. HelloRequest immediately upon the client's initial connection.
It is the client's job to send a ClientHello at that time. It is the client's job to send a ClientHello at that time.
This message will be ignored by the client if the client is This message will be ignored by the client if the client is
currently negotiating a session. This message may be ignored by currently negotiating a session. This message may be ignored by
the client if it does not wish to renegotiate a session, or the the client if it does not wish to renegotiate a session, or the
client may, if it wishes, respond with a no_renegotiation alert. client may, if it wishes, respond with a no_renegotiation alert.
Since handshake messages are intended to have transmission Since handshake messages are intended to have transmission
precedence over application data, it is expected that the precedence over application data, it is expected that the
negotiation will begin before no more than a few records are negotiation will begin before no more than a few records are
received from the client. If the server sends a hello request but received from the client. If the server sends a hello request but
does not receive a client hello in response, it may close the does not receive a client hello in response, it may close the
connection with a fatal alert. connection with a fatal alert.
After sending a hello request, servers SHOULD not repeat the request After sending a hello request, servers SHOULD NOT repeat the request
until the subsequent handshake negotiation is complete. until the subsequent handshake negotiation is complete.
Structure of this message: Structure of this message:
struct { } HelloRequest; struct { } HelloRequest;
Note: This message MUST NOT be included in the message hashes that are Note: This message MUST NOT be included in the message hashes that are
maintained throughout the handshake and used in the finished maintained throughout the handshake and used in the finished
messages and the certificate verify message. messages and the certificate verify message.
7.4.1.2. Client Hello 7.4.1.2. Client Hello
skipping to change at page 96, line ? skipping to change at page 96, line ?
becomes valid when the handshake negotiating it completes with the becomes valid when the handshake negotiating it completes with the
exchange of Finished messages and persists until it is removed due to exchange of Finished messages and persists until it is removed due to
aging or because a fatal error was encountered on a connection aging or because a fatal error was encountered on a connection
associated with the session. The actual contents of the SessionID are associated with the session. The actual contents of the SessionID are
defined by the server. defined by the server.
opaque SessionID<0..32>; opaque SessionID<0..32>;
Warning: Warning:
Because the SessionID is transmitted without encryption or Because the SessionID is transmitted without encryption or
immediate MAC protection, servers MUST not place confidential immediate MAC protection, servers MUST NOT place confidential
information in session identifiers or let the contents of fake information in session identifiers or let the contents of fake
session identifiers cause any breach of security. (Note that the session identifiers cause any breach of security. (Note that the
content of the handshake as a whole, including the SessionID, is content of the handshake as a whole, including the SessionID, is
protected by the Finished messages exchanged at the end of the protected by the Finished messages exchanged at the end of the
handshake.) handshake.)
The CipherSuite list, passed from the client to the server in the The CipherSuite list, passed from the client to the server in the
client hello message, contains the combinations of cryptographic client hello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's algorithms supported by the client in order of the client's
preference (favorite choice first). Each CipherSuite defines a key preference (favorite choice first). Each CipherSuite defines a key
skipping to change at page 96, line ? skipping to change at page 96, line ?
The CipherSuite list, passed from the client to the server in the The CipherSuite list, passed from the client to the server in the
client hello message, contains the combinations of cryptographic client hello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's algorithms supported by the client in order of the client's
preference (favorite choice first). Each CipherSuite defines a key preference (favorite choice first). Each CipherSuite defines a key
exchange algorithm, a bulk encryption algorithm (including secret key exchange algorithm, a bulk encryption algorithm (including secret key
length), a MAC algorithm, and a PRF. The server will select a cipher length), a MAC algorithm, and a PRF. The server will select a cipher
suite or, if no acceptable choices are presented, return a handshake suite or, if no acceptable choices are presented, return a handshake
failure alert and close the connection. failure alert and close the connection.
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
The client hello includes a list of compression algorithms supported The client hello includes a list of compression algorithms supported
by the client, ordered according to the client's preference. by the client, ordered according to the client's preference.
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>; CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>; CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) { select (extensions_present) {
case false: case false:
struct {}; struct {};
case true: case true:
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} };
} ClientHello; } ClientHello;
TLS allows extensions to follow the compression_methods field in an TLS allows extensions to follow the compression_methods field in an
extensions block. The presence of extensions can be detected by extensions block. The presence of extensions can be detected by
determining whether there are bytes following the compression_methods determining whether there are bytes following the compression_methods
at the end of the ClientHello. Note that this method of detecting at the end of the ClientHello. Note that this method of detecting
optional data differs from the normal TLS method of having a optional data differs from the normal TLS method of having a
variable-length field but is used for compatibility with TLS before variable-length field but is used for compatibility with TLS before
extensions were defined. extensions were defined.
client_version client_version
The version of the TLS protocol by which the client wishes to The version of the TLS protocol by which the client wishes to
skipping to change at page 96, line ? skipping to change at page 96, line ?
ProtocolVersion server_version; ProtocolVersion server_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suite; CipherSuite cipher_suite;
CompressionMethod compression_method; CompressionMethod compression_method;
select (extensions_present) { select (extensions_present) {
case false: case false:
struct {}; struct {};
case true: case true:
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} };
} ServerHello; } ServerHello;
The presence of extensions can be detected by determining whether The presence of extensions can be detected by determining whether
there are bytes following the compression_method field at the end of there are bytes following the compression_method field at the end of
the ServerHello. the ServerHello.
server_version server_version
This field will contain the lower of that suggested by the client This field will contain the lower of that suggested by the client
in the client hello and the highest supported by the server. For in the client hello and the highest supported by the server. For
this version of the specification, the version is 3.3. (See this version of the specification, the version is 3.3. (See
skipping to change at page 96, line ? skipping to change at page 96, line ?
The extension format is: The extension format is:
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
enum { enum {
signature_hash_types(TBD-BY-IANA), (65535) signature_hash_types(TBD-BY-IANA), (65535)
} ExtensionType; } ExtensionType;
Here: Here:
- "extension_type" identifies the particular extension type. - "extension_type" identifies the particular extension type.
- "extension_data" contains information specific to the particular - "extension_data" contains information specific to the particular
extension type. extension type.
The list of extension types, as defined in Section 2.3, is maintained The initial set of extensions is defined in a companion document
by the Internet Assigned Numbers Authority (IANA). Thus an [TLSEXT]. The list of extension types is maintained by IANA as
application needs to be made to the IANA in order to obtain a new described in Section 12.
extension type value. Since there are subtle (and not so subtle)
interactions that may occur in this protocol between new features and
existing features which may result in a significant reduction in
overall security, new values SHALL be defined only through the IETF
Consensus process specified in [IANA]. (This means that new
assignments can be made only via RFCs approved by the IESG.) The
initial set of extensions is defined in a companion document [TBD].
The following considerations should be taken into account when There are subtle (and not so subtle) interactions that may occur in
designing new extensions: this protocol between new features and existing features which may
result in a significant reduction in overall security, The following
considerations should be taken into account when designing new
extensions:
- Some cases where a server does not agree to an extension are - Some cases where a server does not agree to an extension are
error error
conditions, and some simply a refusal to support a particular conditions, and some simply a refusal to support a particular
feature. In general error alerts should be used for the former, feature. In general error alerts should be used for the former,
and a field in the server extension response for the latter. and a field in the server extension response for the latter.
- Extensions should as far as possible be designed to prevent any - Extensions should as far as possible be designed to prevent any
attack that forces use (or non-use) of a particular feature by attack that forces use (or non-use) of a particular feature by
manipulation of handshake messages. This principle should be manipulation of handshake messages. This principle should be
skipping to change at page 96, line ? skipping to change at page 96, line ?
exchange a premaster secret. exchange a premaster secret.
If the client has offered the SignatureHashTypes extension, the hash If the client has offered the SignatureHashTypes extension, the hash
function MUST be one of those listed in that extension. Otherwise it function MUST be one of those listed in that extension. Otherwise it
MUST be assumed that only SHA-1 is supported. MUST be assumed that only SHA-1 is supported.
If the SignatureAlgorithm being used to sign the ServerKeyExchange If the SignatureAlgorithm being used to sign the ServerKeyExchange
message is DSA, the hash algorithm MUST be SHA-1. [TODO: This is message is DSA, the hash algorithm MUST be SHA-1. [TODO: This is
incorrect. What it should say is that it must be specified in the incorrect. What it should say is that it must be specified in the
SPKI of the cert. However, I don't believe this is actually defined. SPKI of the cert. However, I don't believe this is actually defined.
Rather, the DSA certs just say dsa. We need new certs to say Rather, the DSA certs just say dsa. We need new certs to say
dsaWithSHAXXX.] dsaWithSHAXXX.]
If the SignatureAlgorithm is RSA, then any hash function accepted by If the SignatureAlgorithm is RSA, then any hash function accepted by
the client MAY be used. The selected hash function MUST be indicated the client MAY be used. The selected hash function MUST be indicated
in the digest_algorithm field of the signature structure. in the digest_algorithm field of the signature structure.
The hash algorithm is denoted Hash below. Hash.length is the length The hash algorithm is denoted Hash below. Hash.length is the length
of the output of that algorithm. of the output of that algorithm.
Structure of this message: Structure of this message:
enum { diffie_hellman } KeyExchangeAlgorithm; enum { diffie_hellman, rsa} KeyExchangeAlgorithm;
struct { struct {
opaque dh_p<1..2^16-1>; opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>; opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>; opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */ } ServerDHParams; /* Ephemeral DH parameters */
dh_p dh_p
The prime modulus used for the Diffie-Hellman operation. The prime modulus used for the Diffie-Hellman operation.
skipping to change at page 96, line ? skipping to change at page 96, line ?
certificates signed with the same algorithm. However, this is certificates signed with the same algorithm. However, this is
not required. This is a holdover from TLS 1.0 and 1.1. not required. This is a holdover from TLS 1.0 and 1.1.
certificate_hash certificate_hash
A list of acceptable hash algorithms to be used in signatures A list of acceptable hash algorithms to be used in signatures
in both the client certificate and the CertificateVerify. in both the client certificate and the CertificateVerify.
These algorithms are listed in descending order of These algorithms are listed in descending order of
preference. preference.
certificate_authorities certificate_authorities
A list of the distinguished names of acceptable certificate A list of the distinguished names [X501] of acceptable
authorities. These distinguished names may specify a desired certificateauthorities, represented in DER-encoded format.
distinguished name for a root CA or for a subordinate CA; These distinguished names may specify a desired distinguished
thus, this message can be used both to describe known roots name for a root CA or for a subordinate CA; thus, this
and a desired authorization space. If the message can be used both to describe known roots and a
certificate_authorities list is empty then the client MAY desired authorization space. If the certificate_authorities
send any certificate of the appropriate list is empty then the client MAY send any certificate of the
ClientCertificateType, unless there is some external appropriate ClientCertificateType, unless there is some
arrangement to the contrary. external arrangement to the contrary.
New ClientCertificateType values are assigned by IANA as described in New ClientCertificateType values are assigned by IANA as described in
Section 11. Section 12.
Note: Values listed as RESERVED may not be used. They were Note: Values listed as RESERVED may not be used. They were
used in SSLv3. used in SSLv3.
Note: DistinguishedName is derived from [X501]. DistinguishedNames are
represented in DER-encoded format.
Note: It is a fatal handshake_failure alert for an anonymous server to Note: It is a fatal handshake_failure alert for an anonymous server to
request client authentication. request client authentication.
7.4.5 Server hello done 7.4.5 Server hello done
When this message will be sent: When this message will be sent:
The server hello done message is sent by the server to indicate The server hello done message is sent by the server to indicate
the end of the server hello and associated messages. After the end of the server hello and associated messages. After
sending this message, the server will wait for a client response. sending this message, the server will wait for a client response.
skipping to change at page 96, line ? skipping to change at page 96, line ?
Structure of this message: Structure of this message:
struct { } ServerHelloDone; struct { } ServerHelloDone;
7.4.6. Client Certificate 7.4.6. Client Certificate
When this message will be sent: When this message will be sent:
This is the first message the client can send after receiving a This is the first message the client can send after receiving a
server hello done message. This message is only sent if the server hello done message. This message is only sent if the
server requests a certificate. If no suitable certificate is server requests a certificate. If no suitable certificate is
available, the client SHOULD send a certificate message available, the client MUST send a certificate message containing
containing no certificates. That is, the certificate_list no certificates. That is, the certificate_list structure has a
structure has a length of zero. If client authentication is length of zero. If client authentication is required by the
required by the server for the handshake to continue, it may server for the handshake to continue, it may respond with a fatal
respond with a fatal handshake failure alert. Client certificates handshake failure alert. Client certificates are sent using the
are sent using the Certificate structure defined in Section Certificate structure defined in Section 7.4.2.
7.4.2.
Note: When using a static Diffie-Hellman based key exchange method Note: When using a static Diffie-Hellman based key exchange method
(DH_DSS or DH_RSA), if client authentication is requested, the (DH_DSS or DH_RSA), if client authentication is requested, the
Diffie-Hellman group and generator encoded in the client's Diffie-Hellman group and generator encoded in the client's
certificate MUST match the server specified Diffie-Hellman certificate MUST match the server specified Diffie-Hellman
parameters if the client's parameters are to be used for the key parameters if the client's parameters are to be used for the key
exchange. exchange.
7.4.7. Client Key Exchange Message 7.4.7. Client Key Exchange Message
When this message will be sent: When this message will be sent:
This message is always sent by the client. It MUST immediately This message is always sent by the client. It MUST immediately
follow the client certificate message, if it is sent. Otherwise follow the client certificate message, if it is sent. Otherwise
it MUST be the first message sent by the client after it receives it MUST be the first message sent by the client after it receives
the server hello done message. the server hello done message.
Meaning of this message: Meaning of this message:
With this message, the premaster secret is set, either though With this message, the premaster secret is set, either though
direct transmission of the RSA-encrypted secret, or by the direct transmission of the RSA-encrypted secret, or by the
transmission of Diffie-Hellman parameters that will allow each transmission of Diffie-Hellman parameters that will allow each
side to agree upon the same premaster secret. When the key side to agree upon the same premaster secret. When the key
exchange method is DH_RSA or DH_DSS, client certification has exchange method is DH_RSA or DH_DSS, client certification has
been requested, and the client was able to respond with a been requested, and the client was able to respond with a
certificate that contained a Diffie-Hellman public key whose certificate that contained a Diffie-Hellman public key whose
parameters (group and generator) matched those specified by the parameters (group and generator) matched those specified by the
server in its certificate, this message MUST not contain any server in its certificate, this message MUST NOT contain any
data. data.
Structure of this message: Structure of this message:
The choice of messages depends on which key exchange method has The choice of messages depends on which key exchange method has
been selected. See Section 7.4.3 for the KeyExchangeAlgorithm been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
definition. definition.
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret; case rsa: EncryptedPreMasterSecret;
skipping to change at page 96, line ? skipping to change at page 96, line ?
in itself. in itself.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
opaque random[46]; opaque random[46];
} PreMasterSecret; } PreMasterSecret;
client_version client_version
The latest (newest) version supported by the client. This is The latest (newest) version supported by the client. This is
used to detect version roll-back attacks. Upon receiving the used to detect version roll-back attacks.
premaster secret, the server SHOULD check that this value
matches the value transmitted by the client in the client
hello message.
random random
46 securely-generated random bytes. 46 securely-generated random bytes.
struct { struct {
public-key-encrypted PreMasterSecret pre_master_secret; public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret; } EncryptedPreMasterSecret;
pre_master_secret pre_master_secret
This random value is generated by the client and is used to This random value is generated by the client and is used to
skipping to change at page 96, line ? skipping to change at page 96, line ?
premaster secret = M premaster secret = M
else: else:
premaster secret = ClientHello.client_version || M[2..47] premaster secret = ClientHello.client_version || M[2..47]
In any case, a TLS server MUST NOT generate an alert if processing an In any case, a TLS server MUST NOT generate an alert if processing an
RSA-encrypted premaster secret message fails, or the version number RSA-encrypted premaster secret message fails, or the version number
is not as expected. Instead, it MUST continue the handshake with a is not as expected. Instead, it MUST continue the handshake with a
randomly generated premaster secret. It may be useful to log the randomly generated premaster secret. It may be useful to log the
real cause of failure for troubleshooting purposes; however, care real cause of failure for troubleshooting purposes; however, care
must be taken to avoid leaking the information to an attacker must be taken to avoid leaking the information to an attacker
(though, e.g., timing, log files, or other channels. (though, e.g., timing, log files, or other channels.)
The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
against the Bleichenbacher attack. However, for maximal compatibility against the Bleichenbacher attack. However, for maximal compatibility
with earlier versions of TLS, this specification uses the RSAES- with earlier versions of TLS, this specification uses the RSAES-
PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known
to exist provided that the above recommendations are followed. to exist provided that the above recommendations are followed.
Implementation Note: Public-key-encrypted data is represented as an Implementation Note: Public-key-encrypted data is represented as an
opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
PreMasterSecret in a ClientKeyExchange is preceded by two length PreMasterSecret in a ClientKeyExchange is preceded by two length
skipping to change at page 96, line ? skipping to change at page 96, line ?
This specification requires correct encoding of the This specification requires correct encoding of the
EncryptedPreMasterSecret complete with length bytes. The resulting EncryptedPreMasterSecret complete with length bytes. The resulting
PDU is incompatible with many SSLv3 implementations. Implementors PDU is incompatible with many SSLv3 implementations. Implementors
upgrading from SSLv3 MUST modify their implementations to generate upgrading from SSLv3 MUST modify their implementations to generate
and accept the correct encoding. Implementors who wish to be and accept the correct encoding. Implementors who wish to be
compatible with both SSLv3 and TLS should make their implementation's compatible with both SSLv3 and TLS should make their implementation's
behavior dependent on the protocol version. behavior dependent on the protocol version.
Implementation Note: It is now known that remote timing-based attacks Implementation Note: It is now known that remote timing-based attacks
on SSL are possible, at least when the client and server are on the on TLS are possible, at least when the client and server are on the
same LAN. Accordingly, implementations that use static RSA keys MUST same LAN. Accordingly, implementations that use static RSA keys MUST
use RSA blinding or some other anti-timing technique, as described in use RSA blinding or some other anti-timing technique, as described in
[TIMING]. [TIMING].
7.4.7.1. Client Diffie-Hellman Public Value 7.4.7.2. Client Diffie-Hellman Public Value
Meaning of this message: Meaning of this message:
This structure conveys the client's Diffie-Hellman public value This structure conveys the client's Diffie-Hellman public value
(Yc) if it was not already included in the client's certificate. (Yc) if it was not already included in the client's certificate.
The encoding used for Yc is determined by the enumerated The encoding used for Yc is determined by the enumerated
PublicValueEncoding. This structure is a variant of the client PublicValueEncoding. This structure is a variant of the client
key exchange message, and not a message in itself. key exchange message, and not a message in itself.
Structure of this message: Structure of this message:
enum { implicit, explicit } PublicValueEncoding; enum { implicit, explicit } PublicValueEncoding;
skipping to change at page 96, line ? skipping to change at page 96, line ?
Meaning of this message: Meaning of this message:
The finished message is the first protected with the just- The finished message is the first protected with the just-
negotiated algorithms, keys, and secrets. Recipients of finished negotiated algorithms, keys, and secrets. Recipients of finished
messages MUST verify that the contents are correct. Once a side messages MUST verify that the contents are correct. Once a side
has sent its Finished message and received and validated the has sent its Finished message and received and validated the
Finished message from its peer, it may begin to send and receive Finished message from its peer, it may begin to send and receive
application data over the connection. application data over the connection.
struct { struct {
opaque verify_data[12]; opaque verify_data[SecurityParameters.verify_data_length];
} Finished; } Finished;
verify_data verify_data
PRF(master_secret, finished_label, Hash(handshake_messages))[0..11]; PRF(master_secret, finished_label, Hash(handshake_messages))
[0..SecurityParameters.verify_data_length-1];
finished_label finished_label
For Finished messages sent by the client, the string "client For Finished messages sent by the client, the string "client
finished". For Finished messages sent by the server, the finished". For Finished messages sent by the server, the
string "server finished". string "server finished".
Hash denotes the negotiated hash used for the PRF. If a new Hash denotes the negotiated hash used for the PRF. If a new
PRF is defined, then this hash MUST be specified. PRF is defined, then this hash MUST be specified.
In previous versions of TLS, the verify_data was always 12
octets long. In the current version of TLS, it depends on the
cipher suite. Any cipher suite which does not explicitly
specify SecurityParameters.verify_data_length has a
SecurityParameters.verify_data_length equal to 12. This
includes all existing cipher suites. Note that this
representation has the same encoding as with previous
versions.
Future cipher suites MAY specify other lengths but such
length MUST be at least 12 bytes.
handshake_messages handshake_messages
All of the data from all messages in this handshake (not All of the data from all messages in this handshake (not
including any HelloRequest messages) up to but not including including any HelloRequest messages) up to but not including
this message. This is only data visible at the handshake this message. This is only data visible at the handshake
layer and does not include record layer headers. This is the layer and does not include record layer headers. This is the
concatenation of all the Handshake structures as defined in concatenation of all the Handshake structures as defined in
7.4, exchanged thus far. 7.4, exchanged thus far.
It is a fatal error if a finished message is not preceded by a change It is a fatal error if a finished message is not preceded by a change
cipher spec message at the appropriate point in the handshake. cipher spec message at the appropriate point in the handshake.
The value handshake_messages includes all handshake messages starting The value handshake_messages includes all handshake messages starting
at client hello up to, but not including, this finished message. This at client hello up to, but not including, this finished message. This
may be different from handshake_messages in Section 7.4.9 because it may be different from handshake_messages in Section 7.4.8 because it
would include the certificate verify message (if sent). Also, the would include the certificate verify message (if sent). Also, the
handshake_messages for the finished message sent by the client will handshake_messages for the finished message sent by the client will
be different from that for the finished message sent by the server, be different from that for the finished message sent by the server,
because the one that is sent second will include the prior one. because the one that is sent second will include the prior one.
Note: Change cipher spec messages, alerts and, any other record types Note: Change cipher spec messages, alerts, and any other record types
are not handshake messages and are not included in the hash are not handshake messages and are not included in the hash
computations. Also, Hello Request messages are omitted from computations. Also, Hello Request messages are omitted from
handshake hashes. handshake hashes.
8. Cryptographic Computations 8. Cryptographic Computations
In order to begin connection protection, the TLS Record Protocol In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and requires specification of a suite of algorithms, a master secret, and
the client and server random values. The authentication, encryption, the client and server random values. The authentication, encryption,
and MAC algorithms are determined by the cipher_suite selected by the and MAC algorithms are determined by the cipher_suite selected by the
skipping to change at page 96, line ? skipping to change at page 96, line ?
contain all zero bits are stripped before it is used as the contain all zero bits are stripped before it is used as the
pre_master_secret. pre_master_secret.
Note: Diffie-Hellman parameters are specified by the server and may Note: Diffie-Hellman parameters are specified by the server and may
be either ephemeral or contained within the server's certificate. be either ephemeral or contained within the server's certificate.
9. Mandatory Cipher Suites 9. Mandatory Cipher Suites
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise, a TLS compliant application MUST implement the cipher otherwise, a TLS compliant application MUST implement the cipher
suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. suite TLS_RSA_WITH_AES_128_CBC_SHA.
10. Application Data Protocol 10. Application Data Protocol
Application data messages are carried by the Record Layer and are Application data messages are carried by the Record Layer and are
fragmented, compressed, and encrypted based on the current connection fragmented, compressed, and encrypted based on the current connection
state. The messages are treated as transparent data to the record state. The messages are treated as transparent data to the record
layer. layer.
11. Security Considerations 11. Security Considerations
Security issues are discussed throughoutthis memo, especially in Security issues are discussed throughout this memo, especially in
Appendices D, E, and F. Appendices D, E, and F.
12. IANA Considerations 12. IANA Considerations
This document uses several registries that were originally created in This document uses several registries that were originally created in
[RFC4346]. IANA is requested to update (has updated) these to [RFC4346]. IANA is requested to update (has updated) these to
reference this document. The registries and their allocation policies reference this document. The registries and their allocation policies
(unchanged from [RFC4346]) are listed below. (unchanged from [TLS1.1]) are listed below.
o TLS ClientCertificateType Identifiers Registry: Future o TLS ClientCertificateType Identifiers Registry: Future
values in the range 0-63 (decimal) inclusive are assigned via values in the range 0-63 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values in the range 64-223 Standards Action [RFC2434]. Values in the range 64-223
(decimal) inclusive are assigned Specification Required (decimal) inclusive are assigned Specification Required
[RFC2434]. Values from 224-255 (decimal) inclusive are [RFC2434]. Values from 224-255 (decimal) inclusive are
reserved for Private Use [RFC2434]. reserved for Private Use [RFC2434].
o TLS Cipher Suite Registry: Future values with the first byte o TLS Cipher Suite Registry: Future values with the first byte
in the range 0-191 (decimal) inclusive are assigned via in the range 0-191 (decimal) inclusive are assigned via
skipping to change at page 96, line ? skipping to change at page 96, line ?
Future values in the range 0-63 (decimal) inclusive are Future values in the range 0-63 (decimal) inclusive are
assigned via Standards Action [RFC2434]. Values in the assigned via Standards Action [RFC2434]. Values in the
range 64-223 (decimal) inclusive are assigned via range 64-223 (decimal) inclusive are assigned via
Specification Required [RFC2434]. Values from 224-255 Specification Required [RFC2434]. Values from 224-255
(decimal) inclusive are reserved for Private Use [RFC2434]. (decimal) inclusive are reserved for Private Use [RFC2434].
This document defines one new TLS extension, cert_hash_type, which is This document defines one new TLS extension, cert_hash_type, which is
to be (has been) allocated value TBD-BY-IANA in the TLS ExtensionType to be (has been) allocated value TBD-BY-IANA in the TLS ExtensionType
registry. registry.
This document also uses the TLS Compression Method Identifiers
Registry, defined in [RFC3749]. IANA is requested to allocate value
0 for the "null" compression method.
Appendix A. Protocol Constant Values Appendix A. Protocol Constant Values
This section describes protocol types and constants. This section describes protocol types and constants.
A.1. Record Layer A.1. Record Layer
struct { struct {
uint8 major, minor; uint8 major, minor;
} ProtocolVersion; } ProtocolVersion;
skipping to change at page 96, line ? skipping to change at page 96, line ?
case block: GenericBlockCipher; case block: GenericBlockCipher;
case aead: GenericAEADCipher; case aead: GenericAEADCipher;
} fragment; } fragment;
} TLSCiphertext; } TLSCiphertext;
stream-ciphered struct { stream-ciphered struct {
opaque content[TLSCompressed.length]; opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length]; opaque MAC[SecurityParameters.mac_length];
} GenericStreamCipher; } GenericStreamCipher;
block-ciphered struct { struct {
opaque IV[SecurityParameters.block_length]; opaque IV[SecurityParameters.record_iv_length];
opaque content[TLSCompressed.length]; block-ciphered struct {
opaque MAC[SecurityParameters.mac_length]; opaque content[TLSCompressed.length];
uint8 padding[GenericBlockCipher.padding_length]; opaque MAC[SecurityParameters.mac_length];
uint8 padding_length; uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
};
} GenericBlockCipher; } GenericBlockCipher;
aead-ciphered struct { aead-ciphered struct {
opaque IV[SecurityParameters.iv_length]; opaque IV[SecurityParameters.iv_length];
opaque aead_output[AEADEncrypted.length]; opaque aead_output[AEADEncrypted.length];
} GenericAEADCipher; } GenericAEADCipher;
A.2. Change Cipher Specs Message A.2. Change Cipher Specs Message
struct { struct {
skipping to change at page 96, line ? skipping to change at page 96, line ?
ProtocolVersion client_version; ProtocolVersion client_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>; CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>; CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) { select (extensions_present) {
case false: case false:
struct {}; struct {};
case true: case true:
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} };
} ClientHello; } ClientHello;
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suite; CipherSuite cipher_suite;
CompressionMethod compression_method; CompressionMethod compression_method;
select (extensions_present) { select (extensions_present) {
case false: case false:
struct {}; struct {};
case true: case true:
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} };
} ServerHello; } ServerHello;
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
enum { enum {
signature_hash_types(TBD-BY-IANA), (65535) signature_hash_types(TBD-BY-IANA), (65535)
} ExtensionType; } ExtensionType;
skipping to change at page 96, line ? skipping to change at page 96, line ?
struct { struct {
opaque dh_p<1..2^16-1>; opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>; opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>; opaque dh_Ys<1..2^16-1>;
} ServerDHParams; } ServerDHParams;
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case diffie_hellman: case diffie_hellman:
ServerDHParams params; ServerDHParams params;
Signature signed_params; Signature signed_params;
}
} ServerKeyExchange; } ServerKeyExchange;
enum { anonymous, rsa, dsa } SignatureAlgorithm; enum { anonymous, rsa, dsa } SignatureAlgorithm;
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case diffie_hellman: case diffie_hellman:
ServerDHParams params; ServerDHParams params;
}; };
} ServerParams; } ServerParams;
skipping to change at page 96, line ? skipping to change at page 96, line ?
} dh_public; } dh_public;
} ClientDiffieHellmanPublic; } ClientDiffieHellmanPublic;
struct { struct {
Signature signature; Signature signature;
} CertificateVerify; } CertificateVerify;
A.4.4. Handshake Finalization Message A.4.4. Handshake Finalization Message
struct { struct {
opaque verify_data[12]; opaque verify_data[SecurityParameters.verify_data_length];
} Finished; } Finished;
A.5. The CipherSuite A.5. The CipherSuite
The following values define the CipherSuite codes used in the client The following values define the CipherSuite codes used in the client
hello and server hello messages. hello and server hello messages.
A CipherSuite defines a cipher specification supported in TLS Version A CipherSuite defines a cipher specification supported in TLS Version
1.1. 1.2.
TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
TLS connection during the first handshake on that channel, but MUST TLS connection during the first handshake on that channel, but MUST
not be negotiated, as it provides no more protection than an not be negotiated, as it provides no more protection than an
unsecured connection. unsecured connection.
CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
The following CipherSuite definitions require that the server provide The following CipherSuite definitions require that the server provide
an RSA certificate that can be used for key exchange. The server may an RSA certificate that can be used for key exchange. The server may
skipping to change at page 96, line ? skipping to change at page 96, line ?
CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
The following cipher suites were defined in [TLSKRB] and are included
here for completeness. See [TLSKRB] for details:
CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
The following exportable cipher suites were defined in [TLSKRB] and
are included here for completeness. TLS 1.2 implementations MUST NOT
negotiate these cipher suites.
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26
};
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27
};
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28
};
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29
};
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A
};
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B
};
New cipher suite values are assigned by IANA as described in Section New cipher suite values are assigned by IANA as described in Section
11. 12.
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
reserved to avoid collision with Fortezza-based cipher suites in SSL reserved to avoid collision with Fortezza-based cipher suites in SSL
3. 3.
A.6. The Security Parameters A.6. The Security Parameters
These security parameters are determined by the TLS Handshake These security parameters are determined by the TLS Handshake
Protocol and provided as parameters to the TLS Record Layer in order Protocol and provided as parameters to the TLS Record Layer in order
to initialize a connection state. SecurityParameters includes: to initialize a connection state. SecurityParameters includes:
skipping to change at page 96, line ? skipping to change at page 96, line ?
/* The algorithms specified in CompressionMethod, /* The algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */ BulkCipherAlgorithm, and MACAlgorithm may be added to. */
struct { struct {
ConnectionEnd entity; ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm; BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type; CipherType cipher_type;
uint8 enc_key_length; uint8 enc_key_length;
uint8 block_length; uint8 block_length;
uint8 iv_length; uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm; MACAlgorithm mac_algorithm;
uint8 mac_length; uint8 mac_length;
uint8 mac_key_length; uint8 mac_key_length;
uint8 verify_data_length;
CompressionMethod compression_algorithm; CompressionMethod compression_algorithm;
opaque master_secret[48]; opaque master_secret[48];
opaque client_random[32]; opaque client_random[32];
opaque server_random[32]; opaque server_random[32];
} SecurityParameters; } SecurityParameters;
Appendix B. Glossary Appendix B. Glossary
Advanced Encryption Standard (AES) Advanced Encryption Standard (AES)
AES is a widely used symmetric encryption algorithm. AES is a AES is a widely used symmetric encryption algorithm. AES is a
block cipher with a 128, 192, or 256 bit keys and a 16 byte block block cipher with a 128, 192, or 256 bit keys and a 16 byte block
skipping to change at page 96, line ? skipping to change at page 96, line ?
the associated private key. Conversely, messages signed with the the associated private key. Conversely, messages signed with the
private key can be verified with the public key. private key can be verified with the public key.
one-way hash function one-way hash function
A one-way transformation that converts an arbitrary amount of A one-way transformation that converts an arbitrary amount of
data into a fixed-length hash. It is computationally hard to data into a fixed-length hash. It is computationally hard to
reverse the transformation or to find collisions. MD5 and SHA are reverse the transformation or to find collisions. MD5 and SHA are
examples of one-way hash functions. examples of one-way hash functions.
RC2 RC2
A block cipher developed by Ron Rivest at RSA Data Security, Inc. A block cipher developed by Ron Rivest, described in [RC2].
[RSADSI] described in [RC2].
RC4 RC4
A stream cipher invented by Ron Rivest. A compatible cipher is A stream cipher invented by Ron Rivest. A compatible cipher is
described in [SCH]. described in [SCH].
RSA RSA
A very widely used public-key algorithm that can be used for A very widely used public-key algorithm that can be used for
either encryption or digital signing. [RSA] either encryption or digital signing. [RSA]
server server
skipping to change at page 96, line ? skipping to change at page 96, line ?
TLS_NULL_WITH_NULL_NULL NULL NULL NULL TLS_NULL_WITH_NULL_NULL NULL NULL NULL
TLS_RSA_WITH_NULL_MD5 RSA NULL MD5 TLS_RSA_WITH_NULL_MD5 RSA NULL MD5
TLS_RSA_WITH_NULL_SHA RSA NULL SHA TLS_RSA_WITH_NULL_SHA RSA NULL SHA
TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA
TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA
TLS_RSA_WITH_AES_256_SHA RSA AES_256_CBC SHA TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA
TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA
skipping to change at page 96, line ? skipping to change at page 96, line ?
Key Key
Exchange Exchange
Algorithm Description Key size limit Algorithm Description Key size limit
DHE_DSS Ephemeral DH with DSS signatures None DHE_DSS Ephemeral DH with DSS signatures None
DHE_RSA Ephemeral DH with RSA signatures None DHE_RSA Ephemeral DH with RSA signatures None
DH_anon Anonymous DH, no signatures None DH_anon Anonymous DH, no signatures None
DH_DSS DH with DSS-based certificates None DH_DSS DH with DSS-based certificates None
DH_RSA DH with RSA-based certificates None DH_RSA DH with RSA-based certificates None
RSA = none
NULL No key exchange N/A NULL No key exchange N/A
RSA RSA key exchange None RSA RSA key exchange None
Key Expanded IV Block Key Expanded IV Block
Cipher Type Material Key Material Size Size Cipher Type Material Key Material Size Size
NULL Stream 0 0 0 N/A NULL Stream 0 0 0 N/A
IDEA_CBC Block 16 16 8 8 IDEA_CBC Block 16 16 8 8
RC2_CBC_40 Block 5 16 8 8
RC4_40 Stream 5 16 0 N/A
RC4_128 Stream 16 16 0 N/A RC4_128 Stream 16 16 0 N/A
DES40_CBC Block 5 8 8 8
DES_CBC Block 8 8 8 8 DES_CBC Block 8 8 8 8
3DES_EDE_CBC Block 24 24 8 8 3DES_EDE_CBC Block 24 24 8 8
Type Type
Indicates whether this is a stream cipher or a block cipher Indicates whether this is a stream cipher or a block cipher
running in CBC mode. running in CBC mode.
Key Material Key Material
The number of bytes from the key_block that are used for The number of bytes from the key_block that are used for
generating the write keys. generating the write keys.
Expanded Key Material Expanded Key Material
The number of bytes actually fed into the encryption algorithm. The number of bytes actually fed into the encryption algorithm.
IV Size IV Size
The amount of data needed to be generated for the initialization The amount of data needed to be generated for the initialization
vector. Zero for stream ciphers; equal to the block size for vector. Zero for stream ciphers; equal to the block size for
block ciphers. block ciphers (this is equal to SecurityParameters.record_iv_length).
Block Size Block Size
The amount of data a block cipher enciphers in one chunk; a The amount of data a block cipher enciphers in one chunk; a
block cipher running in CBC mode can only encrypt an even block cipher running in CBC mode can only encrypt an even
multiple of its block size. multiple of its block size.
Hash Hash Padding Hash Hash Padding
function Size Size function Size Size
NULL 0 0 NULL 0 0
MD5 16 48 MD5 16 48
SHA 20 40 SHA 20 40
Appendix D. Implementation Notes Appendix D. Implementation Notes
The TLS protocol cannot prevent many common security mistakes. This The TLS protocol cannot prevent many common security mistakes. This
section provides several recommendations to assist implementors. section provides several recommendations to assist implementors.
D.1 Random Number Generation and Seeding D.1 Random Number Generation and Seeding
TLS requires a cryptographically secure pseudorandom number generator TLS requires a cryptographically secure pseudorandom number generator
(PRNG). Care must be taken in designing and seeding PRNGs. PRNGs (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs
based on secure hash operations, most notably MD5 and/or SHA, are based on secure hash operations, most notably SHA-1, are acceptable,
acceptable, but cannot provide more security than the size of the but cannot provide more security than the size of the random number
random number generator state. (For example, MD5-based PRNGs usually generator state.
provide 128 bits of state.)
To estimate the amount of seed material being produced, add the To estimate the amount of seed material being produced, add the
number of bits of unpredictable information in each seed byte. For number of bits of unpredictable information in each seed byte. For
example, keystroke timing values taken from a PC compatible's 18.2 Hz example, keystroke timing values taken from a PC compatible's 18.2 Hz
timer provide 1 or 2 secure bits each, even though the total size of timer provide 1 or 2 secure bits each, even though the total size of
the counter value is 16 bits or more. Seeding a 128-bit PRNG would the counter value is 16 bits or more. Seeding a 128-bit PRNG would
thus require approximately 100 such timer values. thus require approximately 100 such timer values.
[RANDOM] provides guidance on the generation of random values. [RANDOM] provides guidance on the generation of random values.
skipping to change at page 96, line ? skipping to change at page 96, line ?
TLS supports a range of key sizes and security levels, including some TLS supports a range of key sizes and security levels, including some
that provide no or minimal security. A proper implementation will that provide no or minimal security. A proper implementation will
probably not support many cipher suites. For instance, anonymous probably not support many cipher suites. For instance, anonymous
Diffie-Hellman is strongly discouraged because it cannot prevent man- Diffie-Hellman is strongly discouraged because it cannot prevent man-
in-the-middle attacks. Applications should also enforce minimum and in-the-middle attacks. Applications should also enforce minimum and
maximum key sizes. For example, certificate chains containing 512-bit maximum key sizes. For example, certificate chains containing 512-bit
RSA keys or signatures are not appropriate for high-security RSA keys or signatures are not appropriate for high-security
applications. applications.
D.4 Implementation Pitfalls
Implementation experience has shown that certain parts of earlier TLS
specifications are not easy to understand, and have been a source of
interoperability and security problems. Many of these areas have been
clarified in this document, but this appendix contains a short list
of the most important things that require special attention from
implementors.
TLS protocol issues:
o Do you correctly handle handshake messages that are fragmented
to multiple TLS records (see Section 6.2.1)? Including corner
cases like a ClientHello that is split to several small
fragments?
o Do you ignore the TLS record layer version number in all TLS
records before ServerHello (see Appendix E.1)?
o Do you handle TLS extensions in ClientHello correctly,
including omitting the extensions field completely?
o Do you support renegotiation, both client and server initiated?
While renegotiation this is an optional feature, supporting
it is highly recommended.
o When the server has requested a client certificate, but no
suitable certificate is available, do you correctly send
an empty Certificate message, instead of omitting the whole
message (see Section 7.4.6)?
Cryptographic details:
o In RSA-encrypted Premaster Secret, do you correctly send and
verify the version number? When an error is encountered, do
you continue the handshake to avoid the Bleichenbacher
attack (see Section 7.4.7.1)?
o What countermeasures do you use to prevent timing attacks against
RSA decryption and signing operations (see Section 7.4.7.1)?
o When verifying RSA signatures, do you accept both NULL and
missing parameters (see Section 4.7)? Do you verify that the
RSA padding doesn't have additional data after the hash value?
[FI06]
o When using Diffie-Hellman key exchange, do you correctly strip
leading zero bytes from the negotiated key (see Section 8.1.2)?
o Does your TLS client check that the Diffie-Hellman parameters
sent by the server are acceptable (see Section F.1.1.3)?
o How do you generate unpredictable IVs for CBC mode ciphers
(see Section 6.2.3.2)?
o How do you address CBC mode timing attacks (Section 6.2.3.2)?
o Do you use a strong and, most importantly, properly seeded
random number generator (see Appendix D.1) for generating the
premaster secret (for RSA key exchange), Diffie-Hellman private
values, the DSA "k" parameter, and other security-critical
values?
Appendix E. Backward Compatibility Appendix E. Backward Compatibility
E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
Since there are various versions of TLS (1.0, 1.1, 1.2, and any Since there are various versions of TLS (1.0, 1.1, 1.2, and any
future versions) and SSL (2.0 and 3.0), means are needed to negotiate future versions) and SSL (2.0 and 3.0), means are needed to negotiate
the specific protocol version to use. The TLS protocol provides a the specific protocol version to use. The TLS protocol provides a
built-in mechanism for version negotiation so as not to bother other built-in mechanism for version negotiation so as not to bother other
protocol components with the complexities of version selection. protocol components with the complexities of version selection.
skipping to change at page 96, line ? skipping to change at page 96, line ?
session_id session_id
This field MUST be empty. This field MUST be empty.
challenge challenge
Corresponds to ClientHello.random. If the challenge length is Corresponds to ClientHello.random. If the challenge length is
less than 32, the TLS server will pad the data with leading less than 32, the TLS server will pad the data with leading
(note: not trailing) zero bytes to make it 32 bytes long. (note: not trailing) zero bytes to make it 32 bytes long.
Note: Requests to resume a TLS session MUST use a TLS client hello. Note: Requests to resume a TLS session MUST use a TLS client hello.
E.2. Avoiding Man-in-the-Middle Version Rollback E.3. Avoiding Man-in-the-Middle Version Rollback
When TLS clients fall back to Version 2.0 compatibility mode, they When TLS clients fall back to Version 2.0 compatibility mode, they
MUST use special PKCS#1 block formatting. This is done so that TLS MUST use special PKCS#1 block formatting. This is done so that TLS
servers will reject Version 2.0 sessions with TLS-capable clients. servers will reject Version 2.0 sessions with TLS-capable clients.
When a client negotiates SSL 2.0 but also supports TLS, it MUST set When a client negotiates SSL 2.0 but also supports TLS, it MUST set
the right-hand (least-significant) 8 random bytes of the PKCS padding the right-hand (least-significant) 8 random bytes of the PKCS padding
(not including the terminal null of the padding) for the RSA (not including the terminal null of the padding) for the RSA
encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
to 0x03 (the other padding bytes are random). to 0x03 (the other padding bytes are random).
skipping to change at page 96, line ? skipping to change at page 96, line ?
F.1.1.1. Anonymous Key Exchange F.1.1.1. Anonymous Key Exchange
Completely anonymous sessions can be established using RSA or Diffie- Completely anonymous sessions can be established using RSA or Diffie-
Hellman for key exchange. With anonymous RSA, the client encrypts a Hellman for key exchange. With anonymous RSA, the client encrypts a
pre_master_secret with the server's uncertified public key extracted pre_master_secret with the server's uncertified public key extracted
from the server key exchange message. The result is sent in a client from the server key exchange message. The result is sent in a client
key exchange message. Since eavesdroppers do not know the server's key exchange message. Since eavesdroppers do not know the server's
private key, it will be infeasible for them to decode the private key, it will be infeasible for them to decode the
pre_master_secret. pre_master_secret.
Note: No anonymous RSA Cipher Suites are defined in this document.
With Diffie-Hellman, the server's public parameters are contained in With Diffie-Hellman, the server's public parameters are contained in
the server key exchange message and the client's are sent in the the server key exchange message and the client's are sent in the
client key exchange message. Eavesdroppers who do not know the client key exchange message. Eavesdroppers who do not know the
private values should not be able to find the Diffie-Hellman result private values should not be able to find the Diffie-Hellman result
(i.e. the pre_master_secret). (i.e. the pre_master_secret).
Warning: Completely anonymous connections only provide protection Warning: Completely anonymous connections only provide protection
against passive eavesdropping. Unless an independent tamper- against passive eavesdropping. Unless an independent tamper-
proof channel is used to verify that the finished messages proof channel is used to verify that the finished messages
were not replaced by an attacker, server authentication is were not replaced by an attacker, server authentication is
skipping to change at page 96, line ? skipping to change at page 96, line ?
F.1.4. Resuming Sessions F.1.4. Resuming Sessions
When a connection is established by resuming a session, new When a connection is established by resuming a session, new
ClientHello.random and ServerHello.random values are hashed with the ClientHello.random and ServerHello.random values are hashed with the
session's master_secret. Provided that the master_secret has not been session's master_secret. Provided that the master_secret has not been
compromised and that the secure hash operations used to produce the compromised and that the secure hash operations used to produce the
encryption keys and MAC secrets are secure, the connection should be encryption keys and MAC secrets are secure, the connection should be
secure and effectively independent from previous connections. secure and effectively independent from previous connections.
Attackers cannot use known encryption keys or MAC secrets to Attackers cannot use known encryption keys or MAC secrets to
compromise the master_secret without breaking the secure hash compromise the master_secret without breaking the secure hash
operations (which use both SHA and MD5). operations.
Sessions cannot be resumed unless both the client and server agree. Sessions cannot be resumed unless both the client and server agree.
If either party suspects that the session may have been compromised, If either party suspects that the session may have been compromised,
or that certificates may have expired or been revoked, it should or that certificates may have expired or been revoked, it should
force a full handshake. An upper limit of 24 hours is suggested for force a full handshake. An upper limit of 24 hours is suggested for
session ID lifetimes, since an attacker who obtains a master_secret session ID lifetimes, since an attacker who obtains a master_secret
may be able to impersonate the compromised party until the may be able to impersonate the compromised party until the
corresponding session ID is retired. Applications that may be run in corresponding session ID is retired. Applications that may be run in
relatively insecure environments should not write session IDs to relatively insecure environments should not write session IDs to
stable storage. stable storage.
F.1.5 Extensions
Security considerations for the extension mechanism in general, and
the design of new extensions, are described in the previous section.
A security analysis of each of the extensions defined in this
document is given below.
In general, implementers should continue to monitor the state of the
art, and address any weaknesses identified.
F.2. Protecting Application Data F.2. Protecting Application Data
The master_secret is hashed with the ClientHello.random and The master_secret is hashed with the ClientHello.random and
ServerHello.random to produce unique data encryption keys and MAC ServerHello.random to produce unique data encryption keys and MAC
secrets for each connection. secrets for each connection.
Outgoing data is protected with a MAC before transmission. To prevent Outgoing data is protected with a MAC before transmission. To prevent
message replay or modification attacks, the MAC is computed from the message replay or modification attacks, the MAC is computed from the
MAC secret, the sequence number, the message length, the message MAC secret, the sequence number, the message length, the message
contents, and two fixed character strings. The message type field is contents, and two fixed character strings. The message type field is
skipping to change at page 96, line ? skipping to change at page 96, line ?
TCP SYN randomization is used [SEQNUM] by the TCP stack. TCP SYN randomization is used [SEQNUM] by the TCP stack.
Because TLS runs over TCP, it is also susceptible to a number of Because TLS runs over TCP, it is also susceptible to a number of
denial of service attacks on individual connections. In particular, denial of service attacks on individual connections. In particular,
attackers can forge RSTs, thereby terminating connections, or forge attackers can forge RSTs, thereby terminating connections, or forge
partial TLS records, thereby causing the connection to stall. These partial TLS records, thereby causing the connection to stall. These
attacks cannot in general be defended against by a TCP-using attacks cannot in general be defended against by a TCP-using
protocol. Implementors or users who are concerned with this class of protocol. Implementors or users who are concerned with this class of
attack should use IPsec AH [AH] or ESP [ESP]. attack should use IPsec AH [AH] or ESP [ESP].
F.6. Final Notes
For TLS to be able to provide a secure connection, both the client
and server systems, keys, and applications must be secure. In
addition, the implementation must be free of security errors.
The system is only as strong as the weakest key exchange and
authentication algorithm supported, and only trustworthy
cryptographic functions should be used. Short public keys and
anonymous servers should be used with great caution. Implementations
and users must be careful when deciding which certificates and
certificate authorities are acceptable; a dishonest certificate
authority can do tremendous damage.
Security Considerations Security Considerations
Security issues are discussed throughout this memo, especially in Security issues are discussed throughout this memo, especially in
Appendices D, E, and F. Appendices D, E, and F.
Changes in This Version Changes in This Version
[RFC Editor: Please delete this] [RFC Editor: Please delete this]
- Added some guidance about checking DH groups and exponents. - Added compression methods to the IANA considerations.
[Issues 15 and 43]
- DigestInfo now MUST be NULL but must be accepted either way
per discussion in Prague [Issue 22]
- Improved versions of Bleichenbacher/Klima/Version number - Misc. editorial changes/clarifications
text for the EPMS (due to Eronen) [Issue 17]
- Cleaned up SSLv2 backward compatibility text [Issue 25] - Added an Implementation Pitfalls sections
[Issue 26]
- Improvements to signature hash agility text [Issue 41]. - Harmonized the requirement to send an empty certificate list
Still not completely fixed. after certificate_request even when no certs are available.
[Issue 48]
- Changed cert_hash_types to signature hash types and indicated a - Made the verify_data length depend on the cipher suite
preference order. [Issue 49]
- Strengthened language about when alerts are required. Note - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
that it is still legal under some circumstances to close cipher suite [Issue 56]
a connection with no alert.
Normative References Normative References
[AES] National Institute of Standards and Technology, [AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard (AES)" "Specification for the Advanced Encryption Standard (AES)"
FIPS 197. November 26, 2001. FIPS 197. November 26, 2001.
[3DES] National Institute of Standards and Tecnology, [3DES] National Institute of Standards and Technology,
"Recommendation for the Triple Data Encryption Algorithm "Recommendation for the Triple Data Encryption Algorithm
(TDEA) Block Cipher", NIST Special Publication 800-67, May (TDEA) Block Cipher", NIST Special Publication 800-67, May
2004. 2004.
[DES] National Institute of Standards and Technology, "Data [DES] National Institute of Standards and Technology, "Data
Encryption Standard (DES)", FIPS PUB 46-3, October 1999. Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
[DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National
Institute of Standards and Technology, U.S. Department of Institute of Standards and Technology, U.S. Department of
Commerce, 2000. Commerce, 2000. PKI
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February Hashing for Message Authentication", RFC 2104, February
1997. 1997.
[IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
Series in Information Processing, v. 1, Konstanz: Hartung- Series in Information Processing, v. 1, Konstanz: Hartung-
Gorre Verlag, 1992. Gorre Verlag, 1992.
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
April 1992. April 1992.
[PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards [PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
(PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
3447, February 2003. 3447, February 2003.
[PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
Public Key Infrastructure: Part I: X.509 Certificate and CRL Public Key Infrastructure Certificate and Certificate
Profile", RFC 3280, April 2002. Revocation List (CRL) Profile", RFC 3280, April 2002.
[RC2] Rivest, R., "A Description of the RC2(r) Encryption [RC2] Rivest, R., "A Description of the RC2(r) Encryption
Algorithm", RFC 2268, March 1998. Algorithm", RFC 2268, March 1998.
[SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
and Source Code in C, 2ed", Published by John Wiley & Sons, and Source Code in C, 2nd ed.", Published by John Wiley &
Inc. 1996. Sons, Inc. 1996.
[SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National [SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of Institute of Standards and Technology, U.S. Department of
Commerce., August 2001. Commerce., August 2001.
[REQ] Bradner, S., "Key words for use in RFCs to Indicate [REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 25, RFC 2434, IANA Considerations Section in RFCs", BCP 25, RFC 2434,
October 1998. October 1998.
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- 8:2001,
"Information Systems - Open Systems Interconnection - The
Directory: Public key and Attribute certificate
frameworks."
[X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to
ISO/IEC 9594:8:2001.
Informative References Informative References
[AEAD] Mcgrew, D., "Authenticated Encryption", February 2007, [AEAD] Mcgrew, D., "Authenticated Encryption", February 2007,
draft-mcgrew-auth-enc-02.txt. draft-mcgrew-auth-enc-02.txt.
[AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC
4302, December 2005. 4302, December 2005.
[BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS #1" in Protocols Based on RSA Encryption Standard PKCS #1" in
Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
1-12, 1998. 1-12, 1998.
[CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
Problems and Countermeasures", Problems and Countermeasures",
http://www.openssl.org/~bodo/tls-cbc.txt. http://www.openssl.org/~bodo/tls-cbc.txt.
[CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel", [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
http://lasecwww.epfl.ch/memo_ssl.shtml, 2003. "Password Interception in a SSL/TLS Channel", Advances in
Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
[CCM] "NIST Special Publication 800-38C: The CCM Mode for [CCM] "NIST Special Publication 800-38C: The CCM Mode for
Authentication and Confidentiality", Authentication and Confidentiality",
http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf. http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf
[ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
for Protecting Communications (Or: How Secure is SSL?)", for Protecting Communications (Or: How Secure is SSL?)",
Crypto 2001. Crypto 2001.
[ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
Payload (ESP)", RFC 4303, December 2005. Payload (ESP)", RFC 4303, December 2005.
[GCM] "NIST Special Publication 800-38C: The CCM Mode for [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on
Authentication and Confidentiality", implementation error", ietf-openpgp@imc.org mailing list, 27
http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf. August 2006, http://www.imc.org/ietf-openpgp/mail-
archive/msg14307.html.
[GCM] "NIST Special Publication 800-38D DRAFT (June, 2007):
Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC"
[IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December
2005. 2005.
[KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
March 2003. March 2003.
[MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) [MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
3526, May 2003. 3526, May 2003.
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
Standard," version 1.5, November 1993. Standard," version 1.5, November 1993.
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
Standard," version 1.5, November 1993. Standard," version 1.5, November 1993.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
Requirements for Security", BCP 106, RFC 4086, June 2005. "Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
Compression Methods", RFC 3749, May 2004.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
Wright, T., "Transport Layer Security (TLS) Extensions", RFC
4366, April 2006.
[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems," Obtaining Digital Signatures and Public-Key Cryptosystems,"
Communications of the ACM, v. 21, n. 2, Feb 1978, pp. Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
120-126. 120-126.
[SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks", [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996. RFC 1948, May 1996.
[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
Corp., Feb 9, 1995. Corp., Feb 9, 1995.
[SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", [SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
Netscape Communications Corp., Nov 18, 1996. Protocol", Netscape Communications Corp., Nov 18, 1996.
[SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for Attacks on the Diffie-Hellman Key Agreement Method for
S/MIME", RFC 2785, March 2000. S/MIME", RFC 2785, March 2000.
[TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
September 1981. September 1981.
[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
practical", USENIX Security Symposium 2003. practical", USENIX Security Symposium 2003.
[TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
for Transport Layer Security (TLS)", RFC 3268, June 2002. for Transport Layer Security (TLS)", RFC 3268, June 2002.
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [TLSEXT], Eastlake, D.E., "Transport Layer Security (TLS)
Wright, T., "Transport Layer Security (TLS) Extensions", RFC Extensions: Extension Definitions", July 2007, draft-ietf-
3546, June 2003. tls-rfc4366-bis-00.txt.
[TLSKRB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712, October
1999.
[TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0", [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version
1.1", RFC 4346, April, 2006. 1.1", RFC 4346, April, 2006.
[X501] ITU-T Recommendation X.501: Information Technology - Open [X501] ITU-T Recommendation X.501: Information Technology - Open
Systems Interconnection - The Directory: Models, 1993. Systems Interconnection - The Directory: Models, 1993.
[X509] ITU-T Recommendation X.509 (1997 E): Information Technology -
Open Systems Interconnection - "The Directory -
Authentication Framework". 1988.
[XDR] Srinivansan, R., Sun Microsystems, "XDR: External Data [XDR] Srinivansan, R., Sun Microsystems, "XDR: External Data
Representation Standard", RFC 1832, August 1995. Representation Standard", RFC 1832, August 1995.
Credits Credits
Working Group Chairs Working Group Chairs
Eric Rescorla Eric Rescorla
EMail: ekr@networkresonance.com EMail: ekr@networkresonance.com
Pasi Eronen Pasi Eronen
skipping to change at page 96, line ? skipping to change at page 96, line ?
BCI BCI
EMail: sblakewilson@bcisse.com EMail: sblakewilson@bcisse.com
Ran Canetti Ran Canetti
IBM IBM
canetti@watson.ibm.com canetti@watson.ibm.com
Pete Chown Pete Chown
Skygate Technology Ltd Skygate Technology Ltd
pc@skygate.co.uk pc@skygate.co.uk
Taher Elgamal Taher Elgamal
taher@securify.com taher@securify.com
Securify Securify
Anil Gangolli Anil Gangolli
anil@busybuddha.org anil@busybuddha.org
Kipp Hickman Kipp Hickman
Alfred Hoenes
David Hopwood David Hopwood
Independent Consultant Independent Consultant
EMail: david.hopwood@blueyonder.co.uk EMail: david.hopwood@blueyonder.co.uk
Phil Karlton (co-author of SSLv3) Phil Karlton (co-author of SSLv3)
Paul Kocher (co-author of SSLv3) Paul Kocher (co-author of SSLv3)
Cryptography Research Cryptography Research
paul@cryptography.com paul@cryptography.com
 End of changes. 146 change blocks. 
335 lines changed or deleted 354 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/