< draft-ietf-tls-rfc4346-bis-03.txt   draft-ietf-tls-rfc4346-bis-04.txt >
Tim Dierks INTERNET-DRAFT Tim Dierks
Independent Obsoletes (if approved): 4346 Independent
Eric Rescorla Intended status: Proposed Standard Eric Rescorla
INTERNET-DRAFT Network Resonance, Inc. Network Resonance, Inc.
<draft-ietf-tls-rfc4346-bis-03.txt> March 2007 (Expires September 2007) <draft-ietf-tls-rfc4346-bis-04.txt> July 2007 (Expires January 2008)
The TLS Protocol The 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.
skipping to change at page 96, line ? skipping to change at page 96, line ?
This document specifies Version 1.2 of the Transport Layer Security This document specifies Version 1.2 of the Transport Layer Security
(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 4 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 5
3. Goals of This Document 6 3. Goals of This Document 6
4. Presentation Language 6 4. Presentation Language 6
4.1. Basic Block Size 6 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 8 4.5. Enumerateds 9
4.6. Constructed Types 9 4.6. Constructed Types 9
4.6.1. Variants 9 4.6.1. Variants 10
4.7. Cryptographic Attributes 10 4.7. Cryptographic Attributes 11
4.8. Constants 12 4.8. Constants 12
5. HMAC and the Pseudorandom fFunction 12 5. HMAC and the Pseudorandom fFunction 13
6. The TLS Record Protocol 14 6. The TLS Record Protocol 14
6.1. Connection States 14 6.1. Connection States 14
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 18
6.2.3. Record Payload Protection 19 6.2.3. Record Payload Protection 19
6.2.3.1. Null or Standard Stream Cipher 19 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 20
6.2.3.3. AEAD ciphers 22 6.2.3.3. AEAD ciphers 22
6.3. Key Calculation 23 6.3. Key Calculation 23
7. The TLS Handshaking Protocols 24 7. The TLS Handshaking Protocols 24
7.1. Change Cipher Spec Protocol 25 7.1. Change Cipher Spec Protocol 25
7.2. Alert Protocol 25 7.2. Alert Protocol 26
7.2.1. Closure Alerts 26 7.2.1. Closure Alerts 27
7.2.2. Error Alerts 27 7.2.2. Error Alerts 27
7.3. Handshake Protocol Overview 30 7.3. Handshake Protocol Overview 31
7.4. Handshake Protocol 34 7.4. Handshake Protocol 35
7.4.1. Hello Messages 35 7.4.1. Hello Messages 36
7.4.1.1. Hello Request 35 7.4.1.1. Hello Request 36
7.4.1.2. Client Hello 36 7.4.1.2. Client Hello 37
7.4.1.3. Server Hello 39 7.4.1.3. Server Hello 40
7.4.1.4 Hello Extensions 40 7.4.1.4 Hello Extensions 41
7.4.1.4.1 Cert Hash Types 42 7.4.1.4.1 Cert Hash Types 43
7.4.2. Server Certificate 42 7.4.2. Server Certificate 43
7.4.3. Server Key Exchange Message 44 7.4.3. Server Key Exchange Message 45
7.4.4. Certificate Request 46 7.4.4. Certificate Request 47
7.4.5 Server hello done 47 7.4.5 Server hello done 49
7.4.6. Client Certificate 48 7.4.6. Client Certificate 49
7.4.7. Client Key Exchange Message 48 7.4.7. Client Key Exchange Message 49
7.4.7.1. RSA Encrypted Premaster Secret Message 49 7.4.7.1. RSA Encrypted Premaster Secret Message 50
7.4.7.1. Client Diffie-Hellman Public Value 51 7.4.7.1. Client Diffie-Hellman Public Value 53
7.4.8. Certificate verify 52 7.4.8. Certificate verify 53
7.4.9. Finished 52 7.4.9. Finished 54
8. Cryptographic Computations 53 8. Cryptographic Computations 55
8.1. Computing the Master Secret 54 8.1. Computing the Master Secret 55
8.1.1. RSA 54 8.1.1. RSA 56
8.1.2. Diffie-Hellman 54 8.1.2. Diffie-Hellman 56
9. Mandatory Cipher Suites 54 9. Mandatory Cipher Suites 56
A. Protocol Constant Values 58 10. Application Data Protocol 56
A.1. Record Layer 58 11. Security Considerations 56
A.2. Change Cipher Specs Message 59 12. IANA Considerations 57
A.3. Alert Messages 59 A. Protocol Constant Values 59
A.4. Handshake Protocol 61 A.1. Record Layer 59
A.4.1. Hello Messages 61 A.2. Change Cipher Specs Message 60
A.4.2. Server Authentication and Key Exchange Messages 62 A.3. Alert Messages 60
A.4.3. Client Authentication and Key Exchange Messages 63 A.4. Handshake Protocol 62
A.4.4. Handshake Finalization Message 64 A.4.1. Hello Messages 62
A.5. The CipherSuite 64 A.4.2. Server Authentication and Key Exchange Messages 63
A.6. The Security Parameters 67 A.4.3. Client Authentication and Key Exchange Messages 65
B. Glossary 69 A.4.4. Handshake Finalization Message 65
C. CipherSuite Definitions 73 A.5. The CipherSuite 65
D. Implementation Notes 75 A.6. The Security Parameters 68
D.1 Random Number Generation and Seeding 75 B. Glossary 70
D.2 Certificates and Authentication 75 C. CipherSuite Definitions 74
D.3 CipherSuites 75 D. Implementation Notes 76
E. Backward Compatibility 76 D.1 Random Number Generation and Seeding 76
E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 76 D.2 Certificates and Authentication 76
E.2 Compatibility with SSL 2.0 77 D.3 CipherSuites 76
E.2. Avoiding Man-in-the-Middle Version Rollback 79 E. Backward Compatibility 77
F. Security Analysis 80 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 77
F.1. Handshake Protocol 80 E.2 Compatibility with SSL 2.0 78
F.1.1. Authentication and Key Exchange 80 E.2. Avoiding Man-in-the-Middle Version Rollback 80
F.1.1.1. Anonymous Key Exchange 80 F. Security Analysis 81
F.1.1.2. RSA Key Exchange and Authentication 81 F.1. Handshake Protocol 81
F.1.1.3. Diffie-Hellman Key Exchange with Authentication 81 F.1.1. Authentication and Key Exchange 81
F.1.2. Version Rollback Attacks 82 F.1.1.1. Anonymous Key Exchange 81
F.1.3. Detecting Attacks Against the Handshake Protocol 83 F.1.1.2. RSA Key Exchange and Authentication 82
F.1.4. Resuming Sessions 83 F.1.1.3. Diffie-Hellman Key Exchange with Authentication 82
F.1.5 Extensions 83 F.1.2. Version Rollback Attacks 83
F.2. Protecting Application Data 84 F.1.3. Detecting Attacks Against the Handshake Protocol 84
F.3. Explicit IVs 84 F.1.4. Resuming Sessions 84
F.4. Security of Composite Cipher Modes 84 F.1.5 Extensions 85
F.5 Denial of Service 85 F.2. Protecting Application Data 85
F.6. Final Notes 86 F.3. Explicit IVs 85
F.4. Security of Composite Cipher Modes 86
F.5 Denial of Service 87
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 ?
protocol (such as the TLS Handshake Protocol). The Record protocol (such as the TLS Handshake Protocol). The Record
Protocol can also be used without encryption. Protocol can also be used without encryption.
- The connection is reliable. Message transport includes a message - The connection is reliable. Message transport includes a message
integrity check using a keyed MAC. Secure hash functions (e.g., integrity check using a keyed MAC. Secure hash functions (e.g.,
SHA, MD5, etc.) are used for MAC computations. The Record SHA, MD5, etc.) are used for MAC computations. The Record
Protocol can operate without a MAC, but is generally only used in Protocol can operate without a MAC, but is generally only used in
this mode while another protocol is using the Record Protocol as this mode while another protocol is using the Record Protocol as
a transport for negotiating security parameters. a transport for negotiating security parameters.
The TLS Record Protocol is used for encapsulation of various higher The TLS Record Protocol is used for encapsulation of various higher-
level protocols. One such encapsulated protocol, the TLS Handshake level protocols. One such encapsulated protocol, the TLS Handshake
Protocol, allows the server and client to authenticate each other and Protocol, allows the server and client to authenticate each other and
to negotiate an encryption algorithm and cryptographic keys before to negotiate an encryption algorithm and cryptographic keys before
the application protocol transmits or receives its first byte of the application protocol transmits or receives its first byte of
data. The TLS Handshake Protocol provides connection security that data. The TLS Handshake Protocol provides connection security that
has three basic properties: has three basic properties:
- The peer's identity can be authenticated using asymmetric, or - The peer's identity can be authenticated using asymmetric, or
public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
authentication can be made optional, but is generally required authentication can be made optional, but is generally required
skipping to change at page 96, line ? skipping to change at page 96, line ?
- The negotiation is reliable: no attacker can modify the - The negotiation is reliable: no attacker can modify the
negotiation communication without being detected by the parties negotiation communication without being detected by the parties
to the communication. to the communication.
One advantage of TLS is that it is application protocol independent. One advantage of TLS is that it is application protocol independent.
Higher-level protocols can layer on top of the TLS Protocol Higher-level protocols can layer on top of the TLS Protocol
transparently. The TLS standard, however, does not specify how transparently. The TLS standard, however, does not specify how
protocols add security with TLS; the decisions on how to initiate TLS protocols add security with TLS; the decisions on how to initiate TLS
handshaking and how to interpret the authentication certificates handshaking and how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors exchanged are left to the judgment of the designers and implementors
of protocols which run on top of TLS. of protocols that run on top of TLS.
1.1 Requirements Terminology 1.1 Requirements Terminology
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
skipping to change at page 96, line ? skipping to change at page 96, line ?
- Allow the server to indicate which hash functions it supports - Allow the server to indicate which hash functions it supports
for digital signature. for digital signature.
- Addition of support for authenticated encryption with additional - Addition of support for authenticated encryption with additional
data modes. data modes.
- Tightened up a number of requirements. - Tightened up a number of requirements.
- The usual clarifications and editorial work. - The usual clarifications and editorial work.
- Added some guidance that DH groups should be checked.
- Cleaned up description of Bleichenbacher/Klima attack defenses.
- Tighter checking of EncryptedPreMasterSecret version numbers.
- Stronger language about when alerts MUST be sent.
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 ?
4. Presentation Language 4. Presentation Language
This document deals with the formatting of data in an external This document deals with the formatting of data in an external
representation. The following very basic and somewhat casually representation. The following very basic and somewhat casually
defined presentation syntax will be used. The syntax draws from defined presentation syntax will be used. The syntax draws from
several sources in its structure. Although it resembles the several sources in its structure. Although it resembles the
programming language "C" in its syntax and XDR [XDR] in both its programming language "C" in its syntax and XDR [XDR] in both its
syntax and intent, it would be risky to draw too many parallels. The syntax and intent, it would be risky to draw too many parallels. The
purpose of this presentation language is to document TLS only; it has purpose of this presentation language is to document TLS only; it has
no have general application beyond that particular goal. no general application beyond that particular goal.
4.1. Basic Block Size 4.1. Basic Block Size
The representation of all data items is explicitly specified. The The representation of all data items is explicitly specified. The
basic data block size is one byte (i.e., 8 bits). Multiple byte data basic data block size is one byte (i.e., 8 bits). Multiple byte data
items are concatenations of bytes, from left to right, from top to items are concatenations of bytes, from left to right, from top to
bottom. From the bytestream, a multi-byte item (a numeric in the bottom. From the bytestream, a multi-byte item (a numeric in the
example) is formed (using C notation) by: example) is formed (using C notation) by:
value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
skipping to change at page 96, line ? skipping to change at page 96, line ?
Single-byte entities containing uninterpreted data are of type Single-byte entities containing uninterpreted data are of type
opaque. opaque.
4.3. Vectors 4.3. Vectors
A vector (single dimensioned array) is a stream of homogeneous data A vector (single dimensioned array) is a stream of homogeneous data
elements. The size of the vector may be specified at documentation elements. The size of the vector may be specified at documentation
time or left unspecified until runtime. In either case, the length time or left unspecified until runtime. In either case, the length
declares the number of bytes, not the number of elements, in the declares the number of bytes, not the number of elements, in the
vector. The syntax for specifying a new type, T' that is a fixed- vector. The syntax for specifying a new type, T', that is a fixed-
length vector of type T is length vector of type T is
T T'[n]; T T'[n];
Here, T' occupies n bytes in the data stream, where n is a multiple Here, T' occupies n bytes in the data stream, where n is a multiple
of the size of T. The length of the vector is not included in the of the size of T. The length of the vector is not included in the
encoded stream. encoded stream.
In the following example, Datum is defined to be three consecutive In the following example, Datum is defined to be three consecutive
bytes that the protocol does not interpret, while Data is three bytes that the protocol does not interpret, while Data is three
skipping to change at page 96, line ? skipping to change at page 96, line ?
opaque string[10]; /* fixed length */ opaque string[10]; /* fixed length */
} V2; } V2;
struct { struct {
select (VariantTag) { /* value of selector is implicit */ select (VariantTag) { /* value of selector is implicit */
case apple: V1; /* VariantBody, tag = apple */ case apple: V1; /* VariantBody, tag = apple */
case orange: V2; /* VariantBody, tag = orange */ case orange: V2; /* VariantBody, tag = orange */
} variant_body; /* optional label on variant */ } variant_body; /* optional label on variant */
} VariantRecord; } VariantRecord;
Variant structures may be qualified (narrowed) by specifying a value Variant structures may be qualified (narrowed) by specifying a value
for the selector prior to the type. For example, a for the selector prior to the type. For example, an
orange VariantRecord orange VariantRecord
is a narrowed type of a VariantRecord containing a variant_body of is a narrowed type of a VariantRecord containing a variant_body of
type V2. type V2.
4.7. Cryptographic Attributes 4.7. Cryptographic Attributes
The five cryptographic operations digital signing, stream cipher The five cryptographic operations digital signing, stream cipher
encryption, block cipher encryption, authenticated encryption with encryption, block cipher encryption, authenticated encryption with
additional data (AEAD) encryption and public key encryption are additional data (AEAD) encryption and public key encryption are
designated digitally-signed, stream-ciphered, block-ciphered, aead- designated digitally-signed, stream-ciphered, block-ciphered, aead-
ciphered, and public-key-encrypted, respectively. A field's ciphered, and public-key-encrypted, respectively. A field's
cryptographic processing is specified by prepending an appropriate cryptographic processing is specified by prepending an appropriate
key word designation before the field's type specification. key word designation before the field's type specification.
Cryptographic keys are implied by the current session state (see Cryptographic keys are implied by the current session state (see
Section 6.1). Section 6.1).
In digital signing, one-way hash functions are used as input for a In digital signing, one-way hash functions are used as input for a
signing algorithm. A digitally-signed element is encoded as an opaque signing algorithm. A digitally-signed 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 signing
algorithm and key. algorithm and key.
In RSA signing, the opaque vector contains the signature generated In RSA signing, the opaque vector contains the signature generated
using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1B]. As using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As
discussed in [PKCS1B], the DigestInfo MUST be DER encoded and for discussed in [PKCS1], the DigestInfo MUST be DER encoded and for
digest algorithms without parameters (which include SHA-1) the digest algorithms without parameters (which include SHA-1) the
DigestInfo.AlgorithmIdentifier.parameters field SHOULD be omitted but DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but
implementations MUST accept both without parameters and with NULL implementations MUST accept both without parameters and with NULL
parameters. Note that earlier versions of TLS used a different RSA parameters. Note that earlier versions of TLS used a different RSA
signature scheme which did not include a DigestInfo encoding. signature scheme which did not include a DigestInfo encoding.
In DSS, the 20 bytes of the SHA-1 hash are run directly through the In DSS, the 20 bytes of the SHA-1 hash are run directly through the
Digital Signing Algorithm with no additional hashing. This produces Digital Signing Algorithm with no additional hashing. This produces
two values, r and s. The DSS signature is an opaque vector, as above, two values, r and s. The DSS signature is an opaque vector, as above,
the contents of which are the DER encoding of: the contents of which are the DER encoding of:
Dss-Sig-Value ::= SEQUENCE { Dss-Sig-Value ::= SEQUENCE {
skipping to change at page 96, line ? skipping to change at page 96, line ?
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 signing
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 [PKCS1B]. 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;
digitally-signed opaque hash[20]; digitally-signed opaque hash[20];
} UserType; } UserType;
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
skipping to change at page 96, line ? skipping to change at page 96, line ?
prior to this document MUST use SHA-256 as the basis for their PRF. 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 New cipher suites MUST specify a PRF and in general SHOULD use the
TLS PRF with SHA-256 or a stronger standard hash function. 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,
messages may include fields for length, description, and content. messages may include fields for length, description, and content.
The Record Protocol takes messages to be transmitted, fragments the The Record Protocol takes messages to be transmitted, fragments the
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, and reassembled, and then decrypted, verified, decompressed, reassembled, and then delivered to
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 11.
If a TLS implementation receives a record type it does not If a TLS implementation receives a record type it does not
understand, it SHOULD just ignore it. Any protocol designed for use understand, it SHOULD just ignore it. Any protocol designed for use
over TLS MUST be carefully designed to deal with all possible attacks over TLS MUST be carefully designed to deal with all possible attacks
against it. Note that because the type and length of a record are against it. Note that because the type and length of a record are
not protected by encryption, care SHOULD be taken to minimize the not protected by encryption, care SHOULD be taken to minimize the
value of traffic analysis of these values. Implementations MUST not value of traffic analysis of these values. Implementations MUST not
send record types not defined in this document unless negotiated by send record types not defined in this document unless negotiated by
some extension. some extension.
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, encryption algorithm, Protocol. It specifies a compression algorithm, an encryption
and MAC algorithm. In addition, the parameters for these algorithms algorithm, and MAC algorithm. In addition, the parameters for these
are known: the MAC secret and the bulk encryption keys for the algorithms are known: the MAC secret and the bulk encryption keys for
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
a state that has not been initialized with security parameters a a state that has not been initialized with security parameters a
current state. The initial current state always specifies that no current state. The initial current state always specifies that no
skipping to change at page 96, line ? skipping to change at page 96, line ?
this connection. this connection.
bulk encryption algorithm bulk encryption algorithm
An algorithm to be used for bulk encryption. This specification An algorithm to be used for bulk encryption. This specification
includes the key size of this algorithm, how much of that key is includes the key size of this algorithm, how much of that key is
secret, whether it is a block, stream, or AEAD cipher, and the secret, whether it is a block, stream, or AEAD cipher, and the
block size of the cipher (if appropriate). block size of the cipher (if appropriate).
MAC algorithm MAC algorithm
An algorithm to be used for message authentication. This An algorithm to be used for message authentication. This
specification includes the size of the hash that is returned by specification includes the size of the value returned by the MAC
the MAC algorithm. algorithm.
compression algorithm compression algorithm
An algorithm to be used for data compression. This specification An algorithm to be used for data compression. This specification
must include all information the algorithm requires to do must include all information the algorithm requires to do
compression. compression.
master secret master secret
A 48-byte secret shared between the two peers in the connection. A 48-byte secret shared between the two peers in the connection.
client random client random
skipping to change at page 96, line ? skipping to change at page 96, line ?
be unpredictable. In order to decrypt, thereceiver decrypts the be unpredictable. In order to decrypt, thereceiver decrypts the
entire GenericBlockCipher structure and then discards the first entire GenericBlockCipher structure and then discards the first
cipher block, corresponding to the IV component. cipher block, corresponding to the IV component.
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 based on analysis of the lengths frustrate attacks on a protocol that are based on analysis of the
of exchanged messages. Each uint8 in the padding data vector MUST lengths of exchanged messages. Each uint8 in the padding data
be filled with the padding length value. The receiver MUST check vector MUST be filled with the padding length value. The receiver
this padding and SHOULD use the bad_record_mac alert to indicate MUST check this padding and SHOULD use the bad_record_mac alert
padding errors. to 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 TLSCompressed.length, SecurityParameters.mac_length, and
skipping to change at page 96, line ? skipping to change at page 96, line ?
peer certificate peer certificate
X509v3 [X509] certificate of the peer. This element of the X509v3 [X509] 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 hash_size. (See defines cryptographic attributes such as the mac_length. (See
Appendix A.6 for formal definition,) Appendix A.6 for formal definition.)
master secret master secret
48-byte secret shared between the client and server. 48-byte secret shared between the client and server.
is resumable is resumable
A flag indicating whether the session can be used to initiate A flag indicating whether the session can be used to initiate
new connections. new connections.
These items are then used to create security parameters for use by These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections the Record Layer when protecting application data. Many connections
skipping to change at page 96, line ? skipping to change at page 96, line ?
transport connection, then the implementation MAY choose to close the transport connection, then the implementation MAY choose to close the
transport without waiting for the responding close_notify. No part of transport without waiting for the responding close_notify. No part of
this standard should be taken to dictate the manner in which a usage this standard should be taken to dictate the manner in which a usage
profile for TLS manages its data transport, including when profile for TLS manages its data transport, including when
connections are opened or closed. connections are opened or closed.
Note: It is assumed that closing a connection reliably delivers Note: It is assumed that closing a connection reliably delivers
pending data before destroying the transport. pending data before destroying the transport.
7.2.2. Error Alerts 7.2.2. Error Alerts
Error handling in the TLS Handshake protocol is very simple. When an Error handling in the TLS Handshake protocol is very simple. When an
error is detected, the detecting party sends a message to the other error is detected, the detecting party sends a message to the other
party. Upon transmission or receipt of a fatal alert message, both party. Upon transmission or receipt of a fatal alert message, both
parties immediately close the connection. Servers and clients MUST parties immediately close the connection. Servers and clients MUST
forget any session-identifiers, keys, and secrets associated with a forget any session-identifiers, keys, and secrets associated with a
failed connection. Thus, any connection terminated with a fatal alert failed connection. Thus, any connection terminated with a fatal alert
MUST NOT be resumed. The following error alerts are defined: MUST NOT be resumed.
Whenever an implementation encounters a condition which is defined as
a fatal alert, it MUST send the appropriate alert prior to closing
the connection. In cases where an implementation chooses to send an
alert which MAY be a warning alert but intends to close the
connection immediately afterwards, it MUST send that alert at the
fatal alert level.
If an alert with a level of warning is sent and received, generally
the connection can continue normally. If the receiving party decides
not to proceed with the connection (e.g., after having received a
no_renegotiation alert that it is not willing to accept), it SHOULD
send a fatal alert to terminate the connection.
The following error alerts are defined:
unexpected_message unexpected_message
An inappropriate message was received. This alert is always fatal An inappropriate message was received. This alert is always fatal
and should never be observed in communication between proper and should never be observed in communication between proper
implementations. implementations.
bad_record_mac bad_record_mac
This alert is returned if a record is received with an incorrect This alert is returned if a record is received with an incorrect
MAC. This alert also MUST be returned if an alert is sent because MAC. This alert also MUST be returned if an alert is sent because
a TLSCiphertext decrypted in an invalid way: either it wasn't an a TLSCiphertext decrypted in an invalid way: either it wasn't an
skipping to change at page 96, line ? skipping to change at page 96, line ?
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 (see Section 2.3). 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 which 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 11.
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,
skipping to change at page 96, line ? skipping to change at page 96, line ?
Client Server Client Server
ClientHello --------> ClientHello -------->
ServerHello ServerHello
Certificate* Certificate*
CertificateStatus* CertificateStatus*
ServerKeyExchange* ServerKeyExchange*
CertificateRequest* CertificateRequest*
<-------- ServerHelloDone <-------- ServerHelloDone
Certificate* Certificate*
CertificateURL*
ClientKeyExchange ClientKeyExchange
CertificateVerify* CertificateVerify*
[ChangeCipherSpec] [ChangeCipherSpec]
Finished --------> Finished -------->
[ChangeCipherSpec] [ChangeCipherSpec]
<-------- Finished <-------- Finished
Application Data <-------> Application Data Application Data <-------> Application Data
Fig. 1. Message flow for a full handshake Fig. 1. Message flow for a full handshake
skipping to change at page 96, line ? skipping to change at page 96, line ?
} }
} 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.2. (See this version of the specification, the version is 3.3. (See
Appendix E for details about backward compatibility.) Appendix E for details about backward compatibility.)
random random
This structure is generated by the server and MUST be This structure is generated by the server and MUST be
independently generated from the ClientHello.random. independently generated from the ClientHello.random.
session_id session_id
This is the identity of the session corresponding to this This is the identity of the session corresponding to this
connection. If the ClientHello.session_id was non-empty, the connection. If the ClientHello.session_id was non-empty, the
server will look in its session cache for a match. If a match is server will look in its session cache for a match. If a match is
found and the server is willing to establish the new connection found and the server is willing to establish the new connection
using the specified session state, the server will respond with using the specified session state, the server will respond with
skipping to change at page 96, line ? skipping to change at page 96, line ?
7.4.1.4 Hello Extensions 7.4.1.4 Hello Extensions
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 {
cert_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 list of extension types, as defined in Section 2.3, is maintained
by the Internet Assigned Numbers Authority (IANA). Thus an by the Internet Assigned Numbers Authority (IANA). Thus an
application needs to be made to the IANA in order to obtain a new application needs to be made to the IANA in order to obtain a new
skipping to change at page 96, line ? skipping to change at page 96, line ?
major aspects of the design of TLS; for example the design of major aspects of the design of TLS; for example the design of
cipher suite negotiation. This is not recommended; it would be cipher suite negotiation. This is not recommended; it would be
more appropriate to define a new version of TLS - particularly more appropriate to define a new version of TLS - particularly
since the TLS handshake algorithms have specific protection since the TLS handshake algorithms have specific protection
against version rollback attacks based on the version number, and against version rollback attacks based on the version number, and
the possibility of version rollback should be a significant the possibility of version rollback should be a significant
consideration in any major design change. consideration in any major design change.
7.4.1.4.1 Cert Hash Types 7.4.1.4.1 Cert Hash Types
The client MAY use the "cert_hash_types" to indicate to the The client MAY use the "signature_hash_types" to indicate to the
server which hash functions may be used in the signature on the server which hash functions may be used in digital signatures.
server's certificate. The "extension_data" field of this The "extension_data" field of this extension contains:
extension contains:
enum{ enum{
md5(0), sha1(1), sha256(2), sha384(3), sha512(4), (255) md5(0), sha1(1), sha256(2), sha384(3), sha512(4), (255)
} HashType; } HashType;
struct { struct {
HashType types<255>; HashType types<1..255>;
} CertHashTypes; } SignatureHashTypes;
These values indicate support for MD5 [MD5], SHA-1, SHA-256, SHA-384, These values indicate support for MD5 [MD5], SHA-1, SHA-256, SHA-384,
and SHA-512 [SHA] respectively. The server MUST NOT send this and SHA-512 [SHA] respectively. The server MUST NOT send this
extension. extension. The values are indicated in descending order of
preference.
Clients SHOULD send this extension if they support any algorithm Clients SHOULD send this extension if they support any algorithm
other than SHA-1. If this extension is not used, servers SHOULD other than SHA-1. If this extension is not used, servers SHOULD
assume that the client supports only SHA-1. Note: this is a change assume that the client supports only SHA-1. Note: this is a change
from TLS 1.1 where there are no explicit rules but as a practical from TLS 1.1 where there are no explicit rules but as a practical
matter one can assume that the peer supports MD5 and SHA-1. matter one can assume that the peer supports MD5 and SHA-1.
7.4.2. Server Certificate 7.4.2. Server Certificate
When this message will be sent: When this message will be sent:
skipping to change at page 96, line ? skipping to change at page 96, line ?
DHE_RSA RSA public key that can be used for DHE_RSA RSA public key that can be used for
signing. signing.
DH_DSS Diffie-Hellman key. The algorithm used DH_DSS Diffie-Hellman key. The algorithm used
to sign the certificate MUST be DSS. to sign the certificate MUST be DSS.
DH_RSA Diffie-Hellman key. The algorithm used DH_RSA Diffie-Hellman key. The algorithm used
to sign the certificate MUST be RSA. to sign the certificate MUST be RSA.
All certificate profiles, and key and cryptographic formats are All certificate profiles and key and cryptographic formats are
defined by the IETF PKIX working group [PKIX]. When a key usage defined by the IETF PKIX working group [PKIX]. When a key usage
extension is present, the digitalSignature bit MUST be set for the extension is present, the digitalSignature bit MUST be set for the
key to be eligible for signing, as described above, and the key to be eligible for signing, as described above, and the
keyEncipherment bit MUST be present to allow encryption, as described keyEncipherment bit MUST be present to allow encryption, as described
above. The keyAgreement bit must be set on Diffie-Hellman above. The keyAgreement bit must be set on Diffie-Hellman
certificates. certificates.
As CipherSuites that specify new key exchange methods are specified As CipherSuites that specify new key exchange methods are specified
for the TLS Protocol, they will imply certificate format and the for the TLS Protocol, they will imply certificate format and the
required encoded keying information. required encoded keying information.
skipping to change at page 96, line ? skipping to change at page 96, line ?
public key with which the client can complete a key exchange public key with which the client can complete a key exchange
(with the result being the premaster secret) or a public key for (with the result being the premaster secret) or a public key for
some other algorithm. some other algorithm.
As additional CipherSuites are defined for TLS that include new key As additional CipherSuites are defined for TLS that include new key
exchange algorithms, the server key exchange message will be sent if exchange algorithms, the server key exchange message will be sent if
and only if the certificate type associated with the key exchange and only if the certificate type associated with the key exchange
algorithm does not provide enough information for the client to algorithm does not provide enough information for the client to
exchange a premaster secret. exchange a premaster secret.
If the client has offered the SignatureHashTypes extension, the hash
function MUST be one of those listed in that extension. Otherwise it
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 function used MUST be SHA-1. If the message is DSA, the hash algorithm MUST be SHA-1. [TODO: This is
SignatureAlgorithm it must be the same hash function used in the incorrect. What it should say is that it must be specified in the
signature of the server's certificate (found in the Certificate) SPKI of the cert. However, I don't believe this is actually defined.
message. This algorithm is denoted Hash below. Hash.length is the
length of the output of that algorithm. Rather, the DSA certs just say dsa. We need new certs to say
dsaWithSHAXXX.]
If the SignatureAlgorithm is RSA, then any hash function accepted by
the client MAY be used. The selected hash function MUST be indicated
in the digest_algorithm field of the signature structure.
The hash algorithm is denoted Hash below. Hash.length is the length
of the output of that algorithm.
Structure of this message: Structure of this message:
enum { diffie_hellman } KeyExchangeAlgorithm; enum { diffie_hellman } 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 */
skipping to change at page 96, line ? skipping to change at page 96, line ?
signed_params signed_params
For non-anonymous key exchanges, a hash of the corresponding For non-anonymous key exchanges, a hash of the corresponding
params value, with the signature appropriate to that hash params value, with the signature appropriate to that hash
applied. applied.
hash hash
Hash(ClientHello.random + ServerHello.random + ServerParams) Hash(ClientHello.random + ServerHello.random + ServerParams)
sha_hash sha_hash
SHA1(ClientHello.random + ServerHello.random + ServerParams) SHA1(ClientHello.random + ServerHello.random + ServerParams)
enum { anonymous, rsa, dsa } SignatureAlgorithm; enum { anonymous, rsa, dsa } SignatureAlgorithm;
struct { struct {
select (SignatureAlgorithm) { select (SignatureAlgorithm) {
case anonymous: struct { }; case anonymous: struct { };
case rsa: case rsa:
HashType digest_algorithm; // NEW
digitally-signed struct { digitally-signed struct {
opaque hash[Hash.length]; opaque hash[Hash.length];
}; };
case dsa: case dsa:
digitally-signed struct { digitally-signed struct {
opaque sha_hash[20]; opaque sha_hash[20];
}; };
}; };
}; };
} Signature; } Signature;
skipping to change at page 96, line ? skipping to change at page 96, line ?
rsa_fixed_dh a certificate signed with RSA and containing rsa_fixed_dh a certificate signed with RSA and containing
a static DH key. a static DH key.
dss_fixed_dh a certificate signed with DSS and containing dss_fixed_dh a certificate signed with DSS and containing
a static DH key a static DH key
Certificate types rsa_sign and dss_sign SHOULD contain Certificate types rsa_sign and dss_sign SHOULD contain
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 A list of acceptable hash algorithms to be used in signatures
certificate signatures. in both the client certificate and the CertificateVerify.
These algorithms are listed in descending order of
preference.
certificate_authorities certificate_authorities
A list of the distinguished names of acceptable certificate A list of the distinguished names of acceptable certificate
authorities. These distinguished names may specify a desired authorities. These distinguished names may specify a desired
distinguished name for a root CA or for a subordinate CA; distinguished name for a root CA or for a subordinate CA;
thus, this message can be used both to describe known roots thus, this message can be used both to describe known roots
and a desired authorization space. If the and a desired authorization space. If the
certificate_authorities list is empty then the client MAY certificate_authorities list is empty then the client MAY
send any certificate of the appropriate send any certificate of the appropriate
ClientCertificateType, unless there is some external ClientCertificateType, unless there is some external
skipping to change at page 96, line ? skipping to change at page 96, line ?
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
generate the master secret, as specified in Section 8.1. generate the master secret, as specified in Section 8.1.
An attack discovered by Daniel Bleichenbacher [BLEI] can be used to Note: The version number in the PreMasterSecret is the version offered
attack a TLS server which is using PKCS#1 v 1.5 encoded RSA. The by the client in the ClientHello.client_version, not the
attack takes advantage of the fact that by failing in different ways, version negotiated for the connection. This feature is
a TLS server can be coerced into revealing whether a particular designed to prevent rollback attacks. Unfortunately, some
message, when decrypted, is properly PKCS#1 v1.5 formatted or not. old implementations use the negotiated version instead and
therefore checking the version number may lead to failure to
interoperate with such incorrect client implementations.
In order to avoid this vulnerability, implementations MUST treat Client implementations MUST always send the correct version
incorrectly formatted messages in a manner indistinguishable from number in PreMasterSecret. If ClientHello.client_version is
correctly formatted RSA blocks. Thus, when it receives an incorrectly TLS 1.1 or higher, server implementations MUST check the
formatted RSA block, a server should generate a random 48-byte value version number as described in the note below. If the version
and proceed using it as the premaster secret. Thus, the server will number is earlier than 1.0, server implementations SHOULD
act identically whether the received RSA block is correctly encoded check the version number, but MAY have a configuration option
or not. to disable the check. Note that if the check fails, the
PreMasterSecret SHOULD be randomized as described below.
[PKCS1B] defines a newer version of PKCS#1 encoding that is more Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
secure against the Bleichenbacher attack. However, for maximal [KPR03] can be used to attack a TLS server that reveals whether a
compatibility with TLS 1.0, TLS 1.1 retains the original encoding. No particular message, when decrypted, is properly PKCS#1 formatted,
variants of the Bleichenbacher attack are known to exist provided contains a valid PreMasterSecret structure, or has the correct
that the above recommendations are followed. version number.
The best way to avoid these vulnerabilities is to treat incorrectly
formatted messages in a manner indistinguishable from correctly
formatted RSA blocks. In other words:
1. Generate a string R of 46 random bytes
2. Decrypt the message M
3. If the PKCS#1 padding is not correct, or the length of
message M is not exactly 48 bytes:
premaster secret = ClientHello.client_version || R
else If ClientHello.client_version <= TLS 1.0, and
version number check is explicitly disabled:
premaster secret = M
else:
premaster secret = ClientHello.client_version || M[2..47]
In any case, a TLS server MUST NOT generate an alert if processing an
RSA-encrypted premaster secret message fails, or the version number
is not as expected. Instead, it MUST continue the handshake with a
randomly generated premaster secret. It may be useful to log the
real cause of failure for troubleshooting purposes; however, care
must be taken to avoid leaking the information to an attacker
(though, e.g., timing, log files, or other channels.
The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
against the Bleichenbacher attack. However, for maximal compatibility
with earlier versions of TLS, this specification uses the RSAES-
PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known
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
bytes. These bytes are redundant in the case of RSA because the bytes. These bytes are redundant in the case of RSA because the
EncryptedPreMasterSecret is the only data in the ClientKeyExchange EncryptedPreMasterSecret is the only data in the ClientKeyExchange
and its length can therefore be unambiguously determined. The SSLv3 and its length can therefore be unambiguously determined. The SSLv3
specification was not clear about the encoding of public-key- specification was not clear about the encoding of public-key-
encrypted data, and therefore many SSLv3 implementations do not encrypted data, and therefore many SSLv3 implementations do not
include the the length bytes, encoding the RSA encrypted data include the the length bytes, encoding the RSA encrypted data
skipping to change at page 96, line ? skipping to change at page 96, line ?
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 SSL 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].
Note: The version number in the PreMasterSecret MUST be the version
offered by the client in the ClientHello.version, not the version
negotiated for the connection. This feature is designed to prevent
rollback attacks. Unfortunately, many implementations use the
negotiated version instead and therefore checking the version number
may lead to failure to interoperate with such incorrect client
implementations. Client implementations MUST and Server
implementations MAY check the version number. In practice, since the
TLS handshake MACs prevent downgrade and no good attacks are known on
those MACs, ambiguity is not considered a serious security risk.
Note that if servers choose to to check the version number, they MUST
randomize the PreMasterSecret in case of error, rather than generate
an alert, in order to avoid variants on the Bleichenbacher attack.
[KPR03]
7.4.7.1. Client Diffie-Hellman Public Value 7.4.7.1. 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:
skipping to change at page 96, line ? skipping to change at page 96, line ?
certificate. This message is only sent following a client certificate. This message is only sent following a client
certificate that has signing capability (i.e. all certificates certificate that has signing capability (i.e. all certificates
except those containing fixed Diffie-Hellman parameters). When except those containing fixed Diffie-Hellman parameters). When
sent, it MUST immediately follow the client key exchange message. sent, it MUST immediately follow the client key exchange message.
Structure of this message: Structure of this message:
struct { struct {
Signature signature; Signature signature;
} CertificateVerify; } CertificateVerify;
The Signature type is defined in 7.4.3. If the SignatureAlgorithm The Signature type is defined in 7.4.3.
is DSA, then the sha_hash value must be used. If it is RSA,
the same function (denoted Hash) must be used as was used to The hash function MUST be one of the algorithms offered in the
create the signature for the client's certificate. CertificateRequest message.
If the SignatureAlgorithm being used to sign the ServerKeyExchange
message is DSA, the hash function used MUST be SHA-1.
[TODO: This is 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. Rather, the DSA certs just say
dsa. We need new certs to say dsaWithSHAXXX]
If the SignatureAlgorithm is RSA, then any of the functions offered
by the server may be used. The selected hash function MUST be
indicated in the digest_algorithm field of the signature structure.
The hash algorithm is denoted Hash below.
CertificateVerify.signature.hash CertificateVerify.signature.hash
Hash(handshake_messages); Hash(handshake_messages);
CertificateVerify.signature.sha_hash CertificateVerify.signature.sha_hash
SHA(handshake_messages); SHA(handshake_messages);
Here handshake_messages refers to all handshake messages sent or Here handshake_messages refers to all handshake messages sent or
received starting at client hello up to but not including this received starting at client hello up to but not including this
message, including the type and length fields of the handshake message, including the type and length fields of the handshake
skipping to change at page 96, line ? skipping to change at page 96, line ?
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_3DES_EDE_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 throughoutthis memo, especially in
Appendices D, E, and F. Appendices D, E, and F.
12. IANA Considerations 12. IANA Considerations
skipping to change at page 96, line ? skipping to change at page 96, line ?
[RFC4366]) is listed below:. [RFC4366]) is listed below:.
o TLS ExtensionType Registry: Future values are allocated o TLS ExtensionType Registry: Future values are allocated
via IETF Consensus [RFC2434] via IETF Consensus [RFC2434]
In addition, this document defines one new registry to be maintained In addition, this document defines one new registry to be maintained
by IANA: by IANA:
o TLS HashType Registry: The registry will be initially o TLS HashType Registry: The registry will be initially
populated with the values described in Section 7.4.1.4.7. populated with the values described in Section 7.4.1.4.7.
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.
12.1 Extensions
Section 11 describes a registry of ExtensionType values to be
maintained by the IANA. ExtensionType values are to be assigned via
IETF Consensus as defined in RFC 2434 [IANA]. The initial registry
corresponds to the definition of "ExtensionType" in Section 2.3.
The MIME type "application/pkix-pkipath" has been registered by the
IANA with the following template:
To: ietf-types@iana.org Subject: Registration of MIME media type
application/pkix-pkipath
MIME media type name: application
MIME subtype name: pkix-pkipath
Optional parameters: version (default value is "1")
Encoding considerations:
This MIME type is a DER encoding of the ASN.1 type PkiPath,
defined as follows:
PkiPath ::= SEQUENCE OF Certificate
PkiPath is used to represent a certification path. Within the
sequence, the order of certificates is such that the subject of
the first certificate is the issuer of the second certificate,
etc.
This is identical to the definition published in [X509-4th-TC1];
note that it is different from that in [X509-4th].
All Certificates MUST conform to [PKIX]. (This should be
interpreted as a requirement to encode only PKIX-conformant
certificates using this type. It does not necessarily require
that all certificates that are not strictly PKIX-conformant must
be rejected by relying parties, although the security consequences
of accepting any such certificates should be considered
carefully.)
DER (as opposed to BER) encoding MUST be used. If this type is
sent over a 7-bit transport, base64 encoding SHOULD be used.
Security considerations:
The security considerations of [X509-4th] and [PKIX] (or any
updates to them) apply, as well as those of any protocol that uses
this type (e.g., TLS).
Note that this type only specifies a certificate chain that can be
assessed for validity according to the relying party's existing
configuration of trusted CAs; it is not intended to be used to
specify any change to that configuration.
Interoperability considerations:
No specific interoperability problems are known with this type,
but for recommendations relating to X.509 certificates in general,
see [PKIX].
Published specification: this memo, and [PKIX].
Applications which use this media type: TLS. It may also be used by
other protocols, or for general interchange of PKIX certificate
Additional information:
Magic number(s): DER-encoded ASN.1 can be easily recognized.
Further parsing is required to distinguish from other ASN.1
types.
File extension(s): .pkipath
Macintosh File Type Code(s): not specified
Person & email address to contact for further information:
Magnus Nystrom <magnus@rsasecurity.com>
Intended usage: COMMON
Change controller:
IESG <iesg@ietf.org>
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 ?
} ChangeCipherSpec; } ChangeCipherSpec;
A.3. Alert Messages A.3. Alert Messages
enum { warning(1), fatal(2), (255) } AlertLevel; enum { warning(1), fatal(2), (255) } AlertLevel;
enum { enum {
close_notify(0), close_notify(0),
unexpected_message(10), unexpected_message(10),
bad_record_mac(20), bad_record_mac(20),
decryption_failed(21), decryption_failed_RESERVED(21),
record_overflow(22), record_overflow(22),
decompression_failure(30), decompression_failure(30),
handshake_failure(40), handshake_failure(40),
no_certificate_RESERVED (41), no_certificate_RESERVED(41),
bad_certificate(42), bad_certificate(42),
unsupported_certificate(43), unsupported_certificate(43),
certificate_revoked(44), certificate_revoked(44),
certificate_expired(45), certificate_expired(45),
certificate_unknown(46), certificate_unknown(46),
illegal_parameter(47), illegal_parameter(47),
unknown_ca(48), unknown_ca(48),
access_denied(49), access_denied(49),
decode_error(50), decode_error(50),
decrypt_error(51), decrypt_error(51),
skipping to change at page 96, line ? skipping to change at page 96, line ?
uint8 CipherSuite[2]; uint8 CipherSuite[2];
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-1>;
CompressionMethod compression_methods<1..2^8-1>; CompressionMethod compression_methods<1..2^8-1>;
Extension client_hello_extension_list<0..2^16-1>; select (extensions_present) {
case false:
struct {};
case true:
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) {
case false:
struct {};
case true:
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 {
cert_hash_types(TBD-BY-IANA), (65535) signature_hash_types(TBD-BY-IANA), (65535)
} ExtensionType; } ExtensionType;
A.4.2. Server Authentication and Key Exchange Messages A.4.2. Server Authentication and Key Exchange Messages
opaque ASN.1Cert<2^24-1>; opaque ASN.1Cert<2^24-1>;
struct { struct {
ASN.1Cert certificate_list<0..2^24-1>; ASN.1Cert certificate_list<0..2^24-1>;
} Certificate; } Certificate;
struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPResponse;
} response;
} CertificateStatus;
opaque OCSPResponse<1..2^24-1>;
enum { diffie_hellman } KeyExchangeAlgorithm; enum { diffie_hellman } 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; } 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;
struct { struct {
select (SignatureAlgorithm) { select (SignatureAlgorithm) {
case anonymous: struct { }; case anonymous: struct { };
case rsa: case rsa:
HashType digest_algorithm; // NEW
digitally-signed struct { digitally-signed struct {
opaque hash[Hash.length]; opaque hash[Hash.length];
}; };
case dsa: case dsa:
digitally-signed struct { digitally-signed struct {
opaque sha_hash[20]; opaque sha_hash[20];
}; };
}; };
}; };
} Signature; } Signature;
skipping to change at page 96, line ? skipping to change at page 96, line ?
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:
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
enum { server, client } ConnectionEnd; enum { server, client } ConnectionEnd;
enum { null, rc4, rc2, des, 3des, des40, aes, idea } enum { null, rc4, rc2, des, 3des, des40, aes, idea }
BulkCipherAlgorithm; BulkCipherAlgorithm;
enum { stream, block } CipherType; enum { stream, block, aead } CipherType;
enum { null, md5, sha } MACAlgorithm; enum { null, md5, sha } MACAlgorithm;
/* 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;
skipping to change at page 96, line ? skipping to change at page 96, line ?
(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 MD5 and/or SHA, are
acceptable, but cannot provide more security than the size of the acceptable, but cannot provide more security than the size of the
random number generator state. (For example, MD5-based PRNGs usually random number generator state. (For example, MD5-based PRNGs usually
provide 128 bits of 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, one the counter value is 16 bits or more. Seeding a 128-bit PRNG would
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.
D.2 Certificates and Authentication D.2 Certificates and Authentication
Implementations are responsible for verifying the integrity of Implementations are responsible for verifying the integrity of
certificates and should generally support certificate revocation certificates and should generally support certificate revocation
messages. Certificates should always be verified to ensure proper messages. Certificates should always be verified to ensure proper
signing by a trusted Certificate Authority (CA). The selection and signing by a trusted Certificate Authority (CA). The selection and
addition of trusted CAs should be done very carefully. Users should addition of trusted CAs should be done very carefully. Users should
skipping to change at page 96, line ? skipping to change at page 96, line ?
opaque session_id[V2ClientHello.session_id_length]; opaque session_id[V2ClientHello.session_id_length];
opaque challenge[V2ClientHello.challenge_length; opaque challenge[V2ClientHello.challenge_length;
} V2ClientHello; } V2ClientHello;
msg_length msg_length
The highest bit MUST be 1; the remaining bits contain the The highest bit MUST be 1; the remaining bits contain the
length of the following data in bytes. length of the following data in bytes.
msg_type msg_type
This field, in conjunction with the version field, identifies a This field, in conjunction with the version field, identifies a
version 2 client hello message. The value SHOULD be one (1). version 2 client hello message. The value MUST be one (1).
version version
Equal to ClientHello.client_version. Equal to ClientHello.client_version.
cipher_spec_length cipher_spec_length
This field is the total length of the field cipher_specs. It This field is the total length of the field cipher_specs. It
cannot be zero and MUST be a multiple of the V2CipherSpec length cannot be zero and MUST be a multiple of the V2CipherSpec length
(3). (3).
session_id_length session_id_length
This field MUST have a value of zero. MUST be zero for a client This field MUST have a value of zero for a client that claims to
that claims to support TLS 1.2. support TLS 1.2.
challenge_length challenge_length
The length in bytes of the client's challenge to the server to The length in bytes of the client's challenge to the server to
authenticate itself. Historically, permissible values are between authenticate itself. Historically, permissible values are between
16 and 32 bytes inclusive. When using the SSLv2 backward 16 and 32 bytes inclusive. When using the SSLv2 backward
compatible handshake the client MUST use a 32-byte challenge. compatible handshake the client SHOULD use a 32 byte challenge.
cipher_specs cipher_specs
This is a list of all CipherSpecs the client is willing and able This is a list of all CipherSpecs the client is willing and able
to use. In addition to the 2.0 cipher specs defined in [SSL2], to use. In addition to the 2.0 cipher specs defined in [SSL2],
this includes the TLS cipher suites normally sent in this includes the TLS cipher suites normally sent in
ClientHello.cipher_suites, each cipher suite prefixed by a zero ClientHello.cipher_suites, each cipher suite prefixed by a zero
byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as
{0x00,0x00,0x0A}. {0x00,0x00,0x0A}.
session_id session_id
skipping to change at page 96, line ? skipping to change at page 96, line ?
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.2. 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
SHOULD 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 TLS clients are in Version 2.0 compatibility mode, they set the When a client negotiates SSL 2.0 but also supports TLS, it MUST set
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). After decrypting the to 0x03 (the other padding bytes are random).
ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
error if these eight padding bytes are 0x03. Version 2.0 servers When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
receiving blocks padded in this manner will proceed normally. decrypting the ENCRYPTED-KEY-DATA field, check that these eight
padding bytes are 0x03. If they are not, the server SHOULD generate a
random value for SECRET-KEY-DATA, and continue the handshake (which
will eventually fail since the keys will not match). Note that
reporting the error situation to the client could make the server
vulnerable to attacks described in [BLEI].
Appendix F. Security Analysis Appendix F. Security Analysis
The TLS protocol is designed to establish a secure connection between The TLS protocol is designed to establish a secure connection between
a client and a server communicating over an insecure channel. This a client and a server communicating over an insecure channel. This
document makes several traditional assumptions, including that document makes several traditional assumptions, including that
attackers have substantial computational resources and cannot obtain attackers have substantial computational resources and cannot obtain
secret information from sources outside the protocol. Attackers are secret information from sources outside the protocol. Attackers are
assumed to have the ability to capture, modify, delete, replay, and assumed to have the ability to capture, modify, delete, replay, and
otherwise tamper with messages sent over the communication channel. otherwise tamper with messages sent over the communication channel.
skipping to change at page 96, line ? skipping to change at page 96, line ?
guidelines found in [SUBGROUP]. guidelines found in [SUBGROUP].
Small subgroup attacks are most easily avoided by using one of the Small subgroup attacks are most easily avoided by using one of the
DHE ciphersuites and generating a fresh DH private key (X) for each DHE ciphersuites and generating a fresh DH private key (X) for each
handshake. If a suitable base (such as 2) is chosen, g^X mod p can be handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
computed very quickly, therefore the performance cost is minimized. computed very quickly, therefore the performance cost is minimized.
Additionally, using a fresh key for each handshake provides Perfect Additionally, using a fresh key for each handshake provides Perfect
Forward Secrecy. Implementations SHOULD generate a new X for each Forward Secrecy. Implementations SHOULD generate a new X for each
handshake when using DHE ciphersuites. handshake when using DHE ciphersuites.
Because TLS allows the server to provide arbitrary DH groups, the
client SHOULD verify the correctness of the DH group. [TODO: provide
a reference to some document describing how] and that it is of
suitable size as defined by local policy. The client SHOULD also
verify that the DH public exponent appears to be of adequate size.
The server MAY choose to assist the client by providing a known
group, such as those defined in [IKEALG] or [MODP]. These can be
verified by simple comparison.
F.1.2. Version Rollback Attacks F.1.2. Version Rollback Attacks
Because TLS includes substantial improvements over SSL Version 2.0, Because TLS includes substantial improvements over SSL Version 2.0,
attackers may try to make TLS-capable clients and servers fall back attackers may try to make TLS-capable clients and servers fall back
to Version 2.0. This attack can occur if (and only if) two TLS- to Version 2.0. This attack can occur if (and only if) two TLS-
capable parties use an SSL 2.0 handshake. capable parties use an SSL 2.0 handshake.
Although the solution using non-random PKCS #1 block type 2 message Although the solution using non-random PKCS #1 block type 2 message
padding is inelegant, it provides a reasonably secure way for Version padding is inelegant, it provides a reasonably secure way for Version
3.0 servers to detect the attack. This solution is not secure against 3.0 servers to detect the attack. This solution is not secure against
skipping to change at page 96, line ? skipping to change at page 96, line ?
confidentiality of the transmitted data from malicious actions by confidentiality of the transmitted data from malicious actions by
active attackers in the network. It turns out that the order in active attackers in the network. It turns out that the order in
which encryption and authentication functions are applied to the which encryption and authentication functions are applied to the
data plays an important role for achieving this goal [ENCAUTH]. data plays an important role for achieving this goal [ENCAUTH].
The most robust method, called encrypt-then-authenticate, first The most robust method, called encrypt-then-authenticate, first
applies encryption to the data and then applies a MAC to the applies encryption to the data and then applies a MAC to the
ciphertext. This method ensures that the integrity and ciphertext. This method ensures that the integrity and
confidentiality goals are obtained with ANY pair of encryption confidentiality goals are obtained with ANY pair of encryption
and MAC functions, provided that the former is secure against and MAC functions, provided that the former is secure against
chosen plaintext attacks and the MAC is secure against chosen- chosen plaintext attacks and that the MAC is secure against
message attacks. TLS uses another method, called authenticate- chosen-message attacks. TLS uses another method, called
then-encrypt, in which first a MAC is computed on the plaintext authenticate-then-encrypt, in which first a MAC is computed on
and then the concatenation of plaintext and MAC is encrypted. the plaintext and then the concatenation of plaintext and MAC is
This method has been proven secure for CERTAIN combinations of encrypted. This method has been proven secure for CERTAIN
encryption functions and MAC functions, but is not guaranteed to combinations of encryption functions and MAC functions, but it is
be secure in general. In particular, it has been shown that there not guaranteed to be secure in general. In particular, it has
exist perfectly secure encryption functions (secure even in the been shown that there exist perfectly secure encryption functions
information-theoretic sense) that combined with any secure MAC (secure even in the information-theoretic sense) that combined
function, fail to provide the confidentiality goal against an with any secure MAC function, fail to provide the confidentiality
active attack. Therefore, new ciphersuites and operation modes goal against an active attack. Therefore, new ciphersuites and
adopted into TLS need to be analyzed under the authenticate-then- operation modes adopted into TLS need to be analyzed under the
encrypt method to verify that they achieve the stated integrity authenticate-then-encrypt method to verify that they achieve the
and confidentiality goals. stated integrity and confidentiality goals.
Currently, the security of the authenticate-then-encrypt method Currently, the security of the authenticate-then-encrypt method
has been proven for some important cases. One is the case of has been proven for some important cases. One is the case of
stream ciphers in which a computationally unpredictable pad of stream ciphers in which a computationally unpredictable pad of
the length of the message, plus the length of the MAC tag, is the length of the message, plus the length of the MAC tag, is
produced using a pseudo-random generator and this pad is xor-ed produced using a pseudo-random generator and this pad is xor-ed
with the concatenation of plaintext and MAC tag. The other is with the concatenation of plaintext and MAC tag. The other is
the case of CBC mode using a secure block cipher. In this case, the case of CBC mode using a secure block cipher. In this case,
security can be shown if one applies one CBC encryption pass to security can be shown if one applies one CBC encryption pass to
the concatenation of plaintext and MAC and uses a new, the concatenation of plaintext and MAC and uses a new,
independent, and unpredictable, IV for each new pair of plaintext independent, and unpredictable IV for each new pair of plaintext
and MAC. In previous versions of SSL, CBC mode was used properly and MAC. In previous versions of SSL, CBC mode was used properly
EXCEPT that it used a predictable IV in the form of the last EXCEPT that it used a predictable IV in the form of the last
block of the previous ciphertext. This made TLS open to chosen block of the previous ciphertext. This made TLS open to chosen
plaintext attacks. This verson of the protocol is immune to plaintext attacks. This version of the protocol is immune to
those attacks. For exact details in the encryption modes proven those attacks. For exact details in the encryption modes proven
secure see [ENCAUTH]. secure, see [ENCAUTH].
F.5 Denial of Service F.5 Denial of Service
TLS is susceptible to a number of denial of service (DoS) attacks. TLS is susceptible to a number of denial of service (DoS) attacks.
In particular, an attacker who initiates a large number of TCP In particular, an attacker who initiates a large number of TCP
connections can cause a server to consume large amounts of CPU doing connections can cause a server to consume large amounts of CPU doing
RSA decryption. However, because TLS is generally used over TCP, it RSA decryption. However, because TLS is generally used over TCP, it
is difficult for the attacker to hide his point of origin if proper is difficult for the attacker to hide his point of origin if proper
TCP SYN randomization is used [SEQNUM] by the TCP stack. TCP SYN randomization is used [SEQNUM] by the TCP stack.
skipping to change at page 96, line ? skipping to change at page 96, line ?
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]
- Forbid decryption_failed [issue 5] - Added some guidance about checking DH groups and exponents.
[Issues 15 and 43]
- Fix CertHashTypes declaration [issue 20]
- Fix client_version in 7.4.1.2 [issue 19]
- Require Bleichenbacher and timing attack protection [issues 17
and
12].
- Merged RFC-editor changes back in.
- Editorial changes from NIST [issue 8]
- Clarified the meaning of HelloRequest [issue 39]
- Editorial nits from Peter Williams [issue 35]
- Made maximum fragment size a MUST [issue 9]
- Clarified that resumption is not mandatory and servers may
refuse [issue 37]
- Fixed identifier for cert_hash_types [issue 38]
- Forbid sending unknown record types [issue 11]
- Clarify that DH parameters and other integers are unsigned [issue
28]
- Clarify when a server Certificate is sent [isssue 29]
- Prohibit zero-length fragments [issue 10]
- Fix reference for DES/3DES [issue 18]
- Clean up some notes on deprecated alerts [issue 6]
- Remove ephemeral RSA [issue 3]
- Stripped out discussion of how to generate the IV and replaced it - DigestInfo now MUST be NULL but must be accepted either way
with a randomness/unpredictability requirement [issue 7] per discussion in Prague [Issue 22]
- Replaced the PKCS#1 text with references to PKCS#1 v2. This also - Improved versions of Bleichenbacher/Klima/Version number
includes DigestInfo encoding [issues 1 and 22] text for the EPMS (due to Eronen) [Issue 17]
- Removed extension definitions and merged the ExtendedHello - Cleaned up SSLv2 backward compatibility text [Issue 25]
definitions [issues 31 and 32]
- Replaced CipherSpec references with SecurityParameters references - Improvements to signature hash agility text [Issue 41].
[issue 2] Still not completely fixed.
- Cleaned up IANA text [issues 33 and 34] - Changed cert_hash_types to signature hash types and indicated a
preference order.
- Cleaned up backward compatibility text [issue 25] - Strengthened language about when alerts are required. Note
that it is still legal under some circumstances to close
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 Tecnology,
"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.
skipping to change at page 96, line ? skipping to change at page 96, line ?
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.
[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.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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.
[IDNA] Faltstrom, P., Hoffman, P. and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
April 1992. April 1992.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. [PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
Adams, "Internet X.509 Public Key Infrastructure: Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[PKCS1B] 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.
[PKIOP] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure - Operation Protocols: FTP and HTTP", RFC
2585, May 1999.
[PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
Public Key Infrastructure: Part I: X.509 Certificate and CRL Public Key Infrastructure: Part I: X.509 Certificate and CRL
Profile", RFC 3280, April 2002. 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, 2ed", Published by John Wiley & Sons,
Inc. 1996. Inc. 1996.
skipping to change at page 96, line ? skipping to change at page 96, line ?
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.
[TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
for Transport Layer Security (TLS)", RFC 3268, June 2002.
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
Wright, T., "Transport Layer Security (TLS) Extensions", RFC
3546, June 2003.
[TLSKRB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712, October
1999.
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003.
[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- 8:2001, [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- 8:2001,
"Information Systems - Open Systems Interconnection - The "Information Systems - Open Systems Interconnection - The
Directory: Public key and Attribute certificate Directory: Public key and Attribute certificate
frameworks." frameworks."
[X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | [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/Cor.1:2002, Technical Corrigendum 1 to
ISO/IEC 9594:8:2001. ISO/IEC 9594:8:2001.
Informative References Informative References
[AEAD] Mcgrew, D., "Authenticated Encryption", July 2006, draft- [AEAD] Mcgrew, D., "Authenticated Encryption", February 2007,
mcgrew-auth-enc-00.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:
skipping to change at page 96, line ? skipping to change at page 96, line ?
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 [GCM] "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/SP800-38C.pdf.
[IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December
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)
Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
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, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
skipping to change at page 96, line ? skipping to change at page 96, line ?
[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
for Transport Layer Security (TLS)", RFC 3268, June 2002.
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
Wright, T., "Transport Layer Security (TLS) Extensions", RFC
3546, June 2003.
[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 - [X509] ITU-T Recommendation X.509 (1997 E): Information Technology -
 End of changes. 90 change blocks. 
358 lines changed or deleted 330 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/