draft-ietf-tls-rfc4346-bis-09.txt   draft-ietf-tls-rfc4346-bis-10.txt 
INTERNET-DRAFT Tim Dierks INTERNET-DRAFT Tim Dierks
Obsoletes (if approved): RFC 3268, 4346, 4366 Independent Obsoletes (if approved): RFC 3268, 4346, 4366 Independent
Updates (if approved): RFC 4492 Eric Rescorla Updates (if approved): RFC 4492 Eric Rescorla
Intended status: Proposed Standard Network Resonance, Inc. Intended status: Proposed Standard Network Resonance, Inc.
<draft-ietf-tls-rfc4346-bis-09.txt> February 2008 (Expires August 2008) <draft-ietf-tls-rfc4346-bis-10.txt> March 2008 (Expires September 2008)
The Transport Layer Security (TLS) Protocol The Transport Layer Security (TLS) Protocol
Version 1.2 Version 1.2
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 2, line 39 skipping to change at page 2, line 39
6.2.3.1. Null or Standard Stream Cipher 21 6.2.3.1. Null or Standard Stream Cipher 21
6.2.3.2. CBC Block Cipher 22 6.2.3.2. CBC Block Cipher 22
6.2.3.3. AEAD ciphers 24 6.2.3.3. AEAD ciphers 24
6.3. Key Calculation 25 6.3. Key Calculation 25
7. The TLS Handshaking Protocols 26 7. The TLS Handshaking Protocols 26
7.1. Change Cipher Spec Protocol 27 7.1. Change Cipher Spec Protocol 27
7.2. Alert Protocol 27 7.2. Alert Protocol 27
7.2.1. Closure Alerts 28 7.2.1. Closure Alerts 28
7.2.2. Error Alerts 29 7.2.2. Error Alerts 29
7.3. Handshake Protocol Overview 33 7.3. Handshake Protocol Overview 33
7.4. Handshake Protocol 36 7.4. Handshake Protocol 37
7.4.1. Hello Messages 37 7.4.1. Hello Messages 38
7.4.1.1. Hello Request 37 7.4.1.1. Hello Request 38
7.4.1.2. Client Hello 38 7.4.1.2. Client Hello 39
7.4.1.3. Server Hello 41 7.4.1.3. Server Hello 42
7.4.1.4 Hello Extensions 42 7.4.1.4 Hello Extensions 43
7.4.1.4.1 Signature Algorithms 43 7.4.1.4.1 Signature Algorithms 45
7.4.2. Server Certificate 45 7.4.2. Server Certificate 46
7.4.3. Server Key Exchange Message 47 7.4.3. Server Key Exchange Message 49
7.4.4. Certificate Request 50 7.4.4. Certificate Request 51
7.4.5 Server hello done 51 7.4.5 Server Hello Done 53
7.4.6. Client Certificate 52 7.4.6. Client Certificate 53
7.4.7. Client Key Exchange Message 54 7.4.7. Client Key Exchange Message 55
7.4.7.1. RSA Encrypted Premaster Secret Message 54 7.4.7.1. RSA Encrypted Premaster Secret Message 56
7.4.7.2. Client Diffie-Hellman Public Value 57 7.4.7.2. Client Diffie-Hellman Public Value 58
7.4.8. Certificate verify 58 7.4.8. Certificate verify 59
7.4.9. Finished 58 7.4.9. Finished 60
8. Cryptographic Computations 60 8. Cryptographic Computations 62
8.1. Computing the Master Secret 60 8.1. Computing the Master Secret 62
8.1.1. RSA 61 8.1.1. RSA 62
8.1.2. Diffie-Hellman 61 8.1.2. Diffie-Hellman 62
9. Mandatory Cipher Suites 61 9. Mandatory Cipher Suites 63
10. Application Data Protocol 61 10. Application Data Protocol 63
11. Security Considerations 61 11. Security Considerations 63
12. IANA Considerations 61 12. IANA Considerations 63
A. Protocol Constant Values 64 A. Protocol Data Structures and Constant Values 65
A.1. Record Layer 64 A.1. Record Layer 65
A.2. Change Cipher Specs Message 65 A.2. Change Cipher Specs Message 66
A.3. Alert Messages 65 A.3. Alert Messages 66
A.4. Handshake Protocol 66 A.4. Handshake Protocol 67
A.4.1. Hello Messages 66 A.4.1. Hello Messages 67
A.4.2. Server Authentication and Key Exchange Messages 68 A.4.2. Server Authentication and Key Exchange Messages 69
A.4.3. Client Authentication and Key Exchange Messages 69 A.4.3. Client Authentication and Key Exchange Messages 70
A.4.4. Handshake Finalization Message 70 A.4.4. Handshake Finalization Message 71
A.5. The Cipher Suite 70 A.5. The Cipher Suite 71
A.6. The Security Parameters 72 A.6. The Security Parameters 73
A.7. Changes to RFC 4492 73 A.7. Changes to RFC 4492 74
B. Glossary 73 B. Glossary 74
C. Cipher Suite Definitions 78 C. Cipher Suite Definitions 79
D. Implementation Notes 80 D. Implementation Notes 81
D.1 Random Number Generation and Seeding 80 D.1 Random Number Generation and Seeding 81
D.2 Certificates and Authentication 80 D.2 Certificates and Authentication 81
D.3 Cipher Suites 80 D.3 Cipher Suites 81
D.4 Implementation Pitfalls 80 D.4 Implementation Pitfalls 81
E. Backward Compatibility 83 E. Backward Compatibility 84
E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 83 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 84
E.2 Compatibility with SSL 2.0 84 E.2 Compatibility with SSL 2.0 85
E.3. Avoiding Man-in-the-Middle Version Rollback 86 E.3. Avoiding Man-in-the-Middle Version Rollback 87
F. Security Analysis 87 F. Security Analysis 88
F.1. Handshake Protocol 87 F.1. Handshake Protocol 88
F.1.1. Authentication and Key Exchange 87 F.1.1. Authentication and Key Exchange 88
F.1.1.1. Anonymous Key Exchange 87 F.1.1.1. Anonymous Key Exchange 88
F.1.1.2. RSA Key Exchange and Authentication 88 F.1.1.2. RSA Key Exchange and Authentication 89
F.1.1.3. Diffie-Hellman Key Exchange with Authentication 88 F.1.1.3. Diffie-Hellman Key Exchange with Authentication 89
F.1.2. Version Rollback Attacks 89 F.1.2. Version Rollback Attacks 90
F.1.3. Detecting Attacks Against the Handshake Protocol 90 F.1.3. Detecting Attacks Against the Handshake Protocol 91
F.1.4. Resuming Sessions 90 F.1.4. Resuming Sessions 91
F.2. Protecting Application Data 90 F.2. Protecting Application Data 91
F.3. Explicit IVs 91 F.3. Explicit IVs 92
F.4. Security of Composite Cipher Modes 91 F.4. Security of Composite Cipher Modes 92
F.5 Denial of Service 92 F.5 Denial of Service 93
F.6 Final Notes 92 F.6 Final Notes 93
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:
- The connection is private. Symmetric cryptography is used for - The connection is private. Symmetric cryptography is used for
data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for data encryption (e.g., AES [AES], RC4 [SCH] etc.). The keys for
this symmetric encryption are generated uniquely for each this symmetric encryption are generated uniquely for each
connection and are based on a secret negotiated by another connection and are based on a secret negotiated by another
protocol (such as the TLS Handshake Protocol). The Record Protocol protocol (such as the TLS Handshake Protocol). The Record Protocol
can also be used without encryption. 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 Protocol SHA-1, etc.) are used for MAC computations. The Record Protocol
can operate without a MAC, but is generally only used in this mode can operate without a MAC, but is generally only used in this mode
while another protocol is using the Record Protocol as a transport while another protocol is using the Record Protocol as a transport
for negotiating security parameters. 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], DSA [DSS], etc.). This
authentication can be made optional, but is generally required for authentication can be made optional, but is generally required for
at least one of the peers. at least one of the peers.
- The negotiation of a shared secret is secure: the negotiated - The negotiation of a shared secret is secure: the negotiated
secret is unavailable to eavesdroppers, and for any authenticated secret is unavailable to eavesdroppers, and for any authenticated
connection the secret cannot be obtained, even by an attacker who connection the secret cannot be obtained, even by an attacker who
can place himself in the middle of the connection. can place himself in the middle of the connection.
- 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 to negotiation communication without being detected by the parties to
skipping to change at page 5, line 22 skipping to change at page 5, line 22
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 [REQ]. document are to be interpreted as described in RFC 2119 [REQ].
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:
- The MD5/SHA-1 combination in the PRF has been replaced with cipher - The MD5/SHA-1 combination in the pseudorandom function (PRF) has
suite specified PRFs. All cipher suites in this document use been replaced with cipher suite specified PRFs. All cipher suites
P_SHA256. in this document use P_SHA256.
- The MD5/SHA-1 combination in the digitally-signed element has been - The MD5/SHA-1 combination in the digitally-signed element has been
replaced with a single hash. Signed elements now include a field replaced with a single hash. Signed elements now include a field
that explicitly specifies the hash algorithm used. that explicitly specifies the hash algorithm used.
- Substantial cleanup to the clients and servers ability to specify - Substantial cleanup to the client's and server's ability to
which hash and signature algorithms they will accept. Note that specify which hash and signature algorithms they will accept. Note
this also relaxes some of the constraints on signature and hash that this also relaxes some of the constraints on signature and
algorithms from previous versions of TLS. hash algorithms from previous versions of TLS.
- Addition of support for authenticated encryption with additional - Addition of support for authenticated encryption with additional
data modes. data modes.
- TLS Extensions definition and AES Cipher Suites were merged in - TLS Extensions definition and AES Cipher Suites were merged in
from external [TLSEXT] and [TLSAES]. from external [TLSEXT] and [TLSAES].
- Tighter checking of EncryptedPreMasterSecret version numbers. - Tighter checking of EncryptedPreMasterSecret version numbers.
- Tightened up a number of requirements. - Tightened up a number of requirements.
skipping to change at page 6, line 17 skipping to change at page 6, line 17
- TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
cipher suite. cipher suite.
- Added HMAC-SHA256 cipher suites - Added HMAC-SHA256 cipher suites
- Removed IDEA and DES cipher suites. They are now deprecated and - Removed IDEA and DES cipher suites. They are now deprecated and
will be documented in a separate document. will be documented in a separate document.
- Support for the SSLv2 backward-compatible hello is now a MAY, not - Support for the SSLv2 backward-compatible hello is now a MAY, not
a SHOULD, with sending it a SHOULD not. Support will probably a SHOULD, with sending it a SHOULD NOT. Support will probably
become a SHOULD NOT in the future. become a SHOULD NOT in the future.
- Added limited "fall-through" to the presentation language to allow - Added limited "fall-through" to the presentation language to allow
multiple case arms to have the same encoding. multiple case arms to have the same encoding.
- Added an Implementation Pitfalls sections - Added an Implementation Pitfalls sections
- The usual clarifications and editorial work. - The usual clarifications and editorial work.
2. Goals 2. Goals
skipping to change at page 11, line 42 skipping to change at page 11, line 42
struct { struct {
uint32 number; uint32 number;
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: case apple:
V1; /* VariantBody, tag = apple */ V1; /* VariantBody, tag = apple */
case orange: case orange:
case banana: case banana:
V2; /* VariantBody, tag = orange or banana */ V2; /* VariantBody, tag = orange or banana */
} variant_body; /* optional label on variant */ } variant_body; /* optional label on variant */
} VariantRecord; } VariantRecord;
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-
skipping to change at page 12, line 28 skipping to change at page 12, line 28
The algorithm field specifies the algorithm used (see Section The algorithm field specifies the algorithm used (see Section
7.4.1.4.1 for the definition of this field.) Note that the 7.4.1.4.1 for the definition of this field.) Note that the
introduction of the algorithm field is a change from previous introduction of the algorithm field is a change from previous
versions. The signature is a digital signature using those versions. The signature is a digital signature using those
algorithms over the contents of the element. The contents themselves algorithms over the contents of the element. The contents themselves
do not appear on the wire but are simply calculated. The length of do not appear on the wire but are simply calculated. The length of
the signature is specified by the signing algorithm and key. the signature is specified by the signing 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 [PKCS1]. As using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As
discussed in [PKCS1], the DigestInfo MUST be DER encoded and for hash discussed in [PKCS1], the DigestInfo MUST be DER [X680] [X690]
algorithms without parameters (which include SHA-1) the encoded and for hash algorithms without parameters (which include
DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but SHA-1) the DigestInfo.AlgorithmIdentifier.parameters field MUST be
implementations MUST accept both without parameters and with NULL NULL but implementations MUST accept both without parameters and with
parameters. Note that earlier versions of TLS used a different RSA NULL parameters. Note that earlier versions of TLS used a different
signature scheme which did not include a DigestInfo encoding. RSA 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 DSA, 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 DSA 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 {
r INTEGER, r INTEGER,
s INTEGER s INTEGER
} }
Note: In current terminology, DSA refers to the Digital Signature Note: In current terminology, DSA refers to the Digital Signature
Algorithm and DSS refers to the NIST standard. For historical Algorithm and DSS refers to the NIST standard. In the original
reasons, this document uses DSS and DSA interchangeably SSL and TLS specs, "DSS" was used universally. This document
to refer to the DSA algorithm, as was done in SSLv3. uses "DSA" to refer to the algorithm, "DSS" to refer to the
standard, and uses "DSS" in the code point definitions for
historical continuity.
In stream cipher encryption, the plaintext is exclusive-ORed with an In stream cipher encryption, the plaintext is exclusive-ORed with an
identical amount of output generated from a cryptographically secure identical amount of output generated from a cryptographically secure
keyed pseudorandom number generator. keyed pseudorandom number generator.
In block cipher encryption, every block of plaintext encrypts to a In block cipher encryption, every block of plaintext encrypts to a
block of ciphertext. All block cipher encryption is done in CBC block of ciphertext. All block cipher encryption is done in CBC
(Cipher Block Chaining) mode, and all items that are block-ciphered (Cipher Block Chaining) mode, and all items that are block-ciphered
will be an exact multiple of the cipher block length. will be an exact multiple of the cipher block length.
skipping to change at page 15, line 31 skipping to change at page 15, line 33
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, reassembled, and then delivered to decrypted, verified, decompressed, reassembled, and then delivered to
higher-level clients. higher-level clients.
Four record protocol clients are described in this document: the Four protocols that use the record protocol are described in this
handshake protocol, the alert protocol, the change cipher spec document: the handshake protocol, the alert protocol, the change
protocol, and the application data protocol. In order to allow cipher spec protocol, and the application data protocol. In order to
extension of the TLS protocol, additional record types can be allow extension of the TLS protocol, additional record content types
supported by the record protocol. New record type values are assigned can be supported by the record protocol. New record content type
by IANA as described in Section 12. values are assigned by IANA in the TLS Content Type Registry as
described in Section 12.
Implementations MUST NOT send record types not defined in this Implementations MUST NOT send record types not defined in this
document unless negotiated by some extension. If a TLS document unless negotiated by some extension. If a TLS
implementation receives an unexpected record type, it MUST send an implementation receives an unexpected record type, it MUST send an
unexpected_message alert. unexpected_message alert.
Any protocol designed for use over TLS MUST be carefully designed to Any protocol designed for use over TLS must be carefully designed to
deal with all possible attacks against it. Note that because the deal with all possible attacks against it. As a practical matter,
type and length of a record are not protected by encryption, care this means that the protocol designer must be aware of what security
SHOULD be taken to minimize the value of traffic analysis of these properties TLS does and does not provide and cannot safely rely on
values. the latter.
Note in particular that type and length of a record are not protected
by encryption. If this information is itself sensitive, application
designers may wish to take steps (padding, cover traffic) to minimize
information leakage.
6.1. Connection States 6.1. Connection States
A TLS connection state is the operating environment of the TLS Record A TLS connection state is the operating environment of the TLS Record
Protocol. It specifies a compression algorithm, an encryption Protocol. It specifies a compression algorithm, an encryption
algorithm, and a MAC algorithm. In addition, the parameters for these algorithm, and a MAC algorithm. In addition, the parameters for these
algorithms are known: the MAC key and the bulk encryption keys for algorithms are known: the MAC key and the bulk encryption keys for
the connection in both the read and the write directions. Logically, the connection in both the read and the write directions. Logically,
there are always four connection states outstanding: the current read there are always four connection states outstanding: the current read
and write states, and the pending read and write states. All records and write states, and the pending read and write states. All records
are processed under the current read and write states. The security are processed under the current read and write states. The security
parameters for the pending states can be set by the TLS Handshake parameters for the pending states can be set by the TLS Handshake
Protocol, and the Change Cipher Spec can selectively make either of Protocol, and the ChangeCipherSpec can selectively make either of the
the pending states current, in which case the appropriate current pending states current, in which case the appropriate current state
state is disposed of and replaced with the pending state; the pending is disposed of and replaced with the pending state; the pending state
state is then reinitialized to an empty state. It is illegal to make is then reinitialized to an empty state. It is illegal to make a
a state that has not been initialized with security parameters 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
encryption, compression, or MAC will be used. encryption, compression, or MAC will be used.
The security parameters for a TLS Connection read and write state are The security parameters for a TLS Connection read and write state are
set by providing the following values: set by providing the following values:
connection end connection end
Whether this entity is considered the "client" or the "server" in Whether this entity is considered the "client" or the "server" in
this connection. this connection.
skipping to change at page 17, line 23 skipping to change at page 17, line 28
enum { server, client } ConnectionEnd; enum { server, client } ConnectionEnd;
enum { tls_prf_sha256 } PRFAlgorithm; enum { tls_prf_sha256 } PRFAlgorithm;
enum { null, rc4, 3des, aes } enum { null, rc4, 3des, aes }
BulkCipherAlgorithm; BulkCipherAlgorithm;
enum { stream, block, aead } CipherType; enum { stream, block, aead } CipherType;
enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384, enum { null, hmac_md5, hmac_sha1, hmac_sha256,
hmac_sha512} MACAlgorithm; hmac_sha384, hmac_sha512} MACAlgorithm;
/* The use of "sha" above is historical and denotes SHA-1 */
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
/* The algorithms specified in CompressionMethod, /* The algorithms specified in CompressionMethod, PRFAlgorithm
BulkCipherAlgorithm, and MACAlgorithm may be added to. */ BulkCipherAlgorithm, and MACAlgorithm may be added to. */
struct { struct {
ConnectionEnd entity; ConnectionEnd entity;
PRFAlgorithm prf_algorithm; PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm; BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type; CipherType cipher_type;
uint8 enc_key_length; uint8 enc_key_length;
uint8 block_length; uint8 block_length;
uint8 fixed_iv_length; uint8 fixed_iv_length;
skipping to change at page 19, line 37 skipping to change at page 19, line 39
uint16 length; uint16 length;
opaque fragment[TLSPlaintext.length]; opaque fragment[TLSPlaintext.length];
} TLSPlaintext; } TLSPlaintext;
type type
The higher-level protocol used to process the enclosed fragment. The higher-level protocol used to process the enclosed fragment.
version version
The version of the protocol being employed. This document The version of the protocol being employed. This document
describes TLS Version 1.2, which uses the version { 3, 3 }. The describes TLS Version 1.2, which uses the version { 3, 3 }. The
version value 3.3 is historical, deriving from the use of 3.1 for version value 3.3 is historical, deriving from the use of {3, 1}
TLS 1.0. (See Appendix A.1). Note that a client that supports for TLS 1.0. (See Appendix A.1). Note that a client that supports
multiple versions of TLS may not know what version will be multiple versions of TLS may not know what version will be
employed before it receives the ServerHello. See Appendix E for employed before it receives the ServerHello. See Appendix E for
discussion about what record layer version number should be discussion about what record layer version number should be
employed for ClientHello. employed for ClientHello.
length length
The length (in bytes) of the following TLSPlaintext.fragment. The The length (in bytes) of the following TLSPlaintext.fragment. The
length MUST NOT exceed 2^14. length MUST NOT exceed 2^14.
fragment fragment
The application data. This data is transparent and treated as an The application data. This data is transparent and treated as an
independent block to be dealt with by the higher-level protocol independent block to be dealt with by the higher-level protocol
specified by the type field. specified by the type field.
Implementations MUST NOT send zero-length fragments of Handshake, Implementations MUST NOT send zero-length fragments of Handshake,
Alert, or Change Cipher Spec content types. Zero-length fragments of Alert, or ChangeCipherSpec content types. Zero-length fragments of
Application data MAY be sent as they are potentially useful as a Application data MAY be sent as they are potentially useful as a
traffic analysis countermeasure. traffic analysis countermeasure.
Note: Data of different TLS Record layer content types MAY be Note: Data of different TLS Record layer content types MAY be
interleaved. Application data is generally of lower precedence for interleaved. Application data is generally of lower precedence for
transmission than other content types. However, records MUST be transmission than other content types. However, records MUST be
delivered to the network in the same order as they are protected by delivered to the network in the same order as they are protected by
the record layer. Recipients MUST receive and process interleaved the record layer. Recipients MUST receive and process interleaved
application layer traffic during handshakes subsequent to the first application layer traffic during handshakes subsequent to the first
one on a connection. one on a connection.
6.2.2. Record Compression and Decompression 6.2.2. Record Compression and Decompression
All records are compressed using the compression algorithm defined in All records are compressed using the compression algorithm defined in
the current session state. There is always an active compression the current session state. There is always an active compression
algorithm; however, initially it is defined as algorithm; however, initially it is defined as
CompressionMethod.null. The compression algorithm translates a CompressionMethod.null. The compression algorithm translates a
TLSPlaintext structure into a TLSCompressed structure. Compression TLSPlaintext structure into a TLSCompressed structure. Compression
functions are initialized with default state information whenever a functions are initialized with default state information whenever a
connection state is made active. connection state is made active. [RFC3749] describes compression
algorithms for TLS.
Compression must be lossless and may not increase the content length Compression must be lossless and may not increase the content length
by more than 1024 bytes. If the decompression function encounters a by more than 1024 bytes. If the decompression function encounters a
TLSCompressed.fragment that would decompress to a length in excess of TLSCompressed.fragment that would decompress to a length in excess of
2^14 bytes, it MUST report a fatal decompression failure error. 2^14 bytes, it MUST report a fatal decompression failure error.
struct { struct {
ContentType type; /* same as TLSPlaintext.type */ ContentType type; /* same as TLSPlaintext.type */
ProtocolVersion version;/* same as TLSPlaintext.version */ ProtocolVersion version;/* same as TLSPlaintext.version */
uint16 length; uint16 length;
skipping to change at page 22, line 20 skipping to change at page 22, line 23
MAC MAC
The MAC algorithm specified by SecurityParameters.mac_algorithm. The MAC algorithm specified by SecurityParameters.mac_algorithm.
Note that the MAC is computed before encryption. The stream cipher Note that the MAC is computed before encryption. The stream cipher
encrypts the entire block, including the MAC. For stream ciphers that encrypts the entire block, including the MAC. For stream ciphers that
do not use a synchronization vector (such as RC4), the stream cipher do not use a synchronization vector (such as RC4), the stream cipher
state from the end of one record is simply used on the subsequent state from the end of one record is simply used on the subsequent
packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, encryption packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, encryption
consists of the identity operation (i.e., the data is not encrypted, consists of the identity operation (i.e., the data is not encrypted,
and the MAC size is zero, implying that no MAC is used). and the MAC size is zero, implying that no MAC is used). For both
TLSCiphertext.length is TLSCompressed.length plus null and stream ciphers, TLSCiphertext.length is TLSCompressed.length
SecurityParameters.mac_length. plus SecurityParameters.mac_length.
6.2.3.2. CBC Block Cipher 6.2.3.2. CBC Block Cipher
For block ciphers (such as 3DES, or AES), the encryption and MAC For block ciphers (such as 3DES, or AES), the encryption and MAC
functions convert TLSCompressed.fragment structures to and from block functions convert TLSCompressed.fragment structures to and from block
TLSCiphertext.fragment structures. TLSCiphertext.fragment structures.
struct { struct {
opaque IV[SecurityParameters.record_iv_length]; opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct { block-ciphered struct {
skipping to change at page 25, line 4 skipping to change at page 25, line 7
TLSCompressed.version + TLSCompressed.length; TLSCompressed.version + TLSCompressed.length;
Where "+" denotes concatenation. Where "+" denotes concatenation.
The aead_output consists of the ciphertext output by the AEAD The aead_output consists of the ciphertext output by the AEAD
encryption operation. The length will generally be larger than encryption operation. The length will generally be larger than
TLSCompressed.length, but by an amount that varies with the AEAD TLSCompressed.length, but by an amount that varies with the AEAD
cipher. Since the ciphers might incorporate padding, the amount of cipher. Since the ciphers might incorporate padding, the amount of
overhead could vary with different TLSCompressed.length values. Each overhead could vary with different TLSCompressed.length values. Each
AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
Symbolically, Symbolically,
AEADEncrypted = AEAD-Encrypt(key, nonce, plaintext, AEADEncrypted = AEAD-Encrypt(key, nonce, plaintext,
additional_data) additional_data)
In order to decrypt and verify, the cipher takes as input the key, In order to decrypt and verify, the cipher takes as input the key,
nonce, the "additional_data", and the AEADEncrypted value. The output nonce, the "additional_data", and the AEADEncrypted value. The output
is either the plaintext or an error indicating that the decryption is either the plaintext or an error indicating that the decryption
failed. There is no separate integrity check. I.e., failed. There is no separate integrity check. I.e.,
TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce, TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
AEADEncrypted, AEADEncrypted,
additional_data) additional_data)
If the decryption fails, a fatal bad_record_mac alert MUST be If the decryption fails, a fatal bad_record_mac alert MUST be
generated. generated.
6.3. Key Calculation 6.3. Key Calculation
The Record Protocol requires an algorithm to generates keys required The Record Protocol requires an algorithm to generate keys required
by the current connection state (see Appendix A.6) from the security by the current connection state (see Appendix A.6) from the security
parameters provided by the handshake protocol. parameters provided by the handshake protocol.
The master secret is expanded into a sequence of secure bytes, which The master secret is expanded into a sequence of secure bytes, which
is then split to a client write MAC key, a server write MAC key, a is then split to a client write MAC key, a server write MAC key, a
client write encryption key, and a server write encryption key. Each client write encryption key, and a server write encryption key. Each
of these is generated from the byte sequence in that order. Unused of these is generated from the byte sequence in that order. Unused
values are empty. Some AEAD ciphers may additionally require a values are empty. Some AEAD ciphers may additionally require a
client write IV and a server write IV (see Section 6.2.3.3). client write IV and a server write IV (see Section 6.2.3.3).
skipping to change at page 26, line 38 skipping to change at page 26, line 41
active or resumable session state. active or resumable session state.
peer certificate peer certificate
X509v3 [PKIX] certificate of the peer. This element of the state X509v3 [PKIX] certificate of the peer. This element of the state
may be null. 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, DES, Specifies the pseudorandom function (PRF) used to generate keying
etc.) and a MAC algorithm (such as MD5 or SHA). It also defines material, the bulk data encryption algorithm (such as null, AES,
etc.) and a MAC algorithm (such as HMAC-SHA1). It also defines
cryptographic attributes such as the mac_length. (See Appendix A.6 cryptographic attributes such as the mac_length. (See Appendix A.6
for formal definition.) 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 new A flag indicating whether the session can be used to initiate new
connections. connections.
skipping to change at page 27, line 18 skipping to change at page 27, line 22
The change cipher spec protocol exists to signal transitions in The change cipher spec protocol exists to signal transitions in
ciphering strategies. The protocol consists of a single message, ciphering strategies. The protocol consists of a single message,
which is encrypted and compressed under the current (not the pending) which is encrypted and compressed under the current (not the pending)
connection state. The message consists of a single byte of value 1. connection state. The message consists of a single byte of value 1.
struct { struct {
enum { change_cipher_spec(1), (255) } type; enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec; } ChangeCipherSpec;
The change cipher spec message is sent by both the client and the The ChangeCipherSpec message is sent by both the client and the
server to notify the receiving party that subsequent records will be server to notify the receiving party that subsequent records will be
protected under the newly negotiated CipherSpec and keys. Reception protected under the newly negotiated CipherSpec and keys. Reception
of this message causes the receiver to instruct the Record Layer to of this message causes the receiver to instruct the Record Layer to
immediately copy the read pending state into the read current state. immediately copy the read pending state into the read current state.
Immediately after sending this message, the sender MUST instruct the Immediately after sending this message, the sender MUST instruct the
record layer to make the write pending state the write active state. record layer to make the write pending state the write active state.
(See Section 6.1.) The change cipher spec message is sent during the (See Section 6.1.) The change cipher spec message is sent during the
handshake after the security parameters have been agreed upon, but handshake after the security parameters have been agreed upon, but
before the verifying finished message is sent. before the verifying finished message is sent.
skipping to change at page 27, line 42 skipping to change at page 27, line 46
CipherSpec MUST be used. The first side to send the ChangeCipherSpec CipherSpec MUST be used. The first side to send the ChangeCipherSpec
does not know that the other side has finished computing the new does not know that the other side has finished computing the new
keying material (e.g., if it has to perform a time consuming public keying material (e.g., if it has to perform a time consuming public
key operation). Thus, a small window of time, during which the key operation). Thus, a small window of time, during which the
recipient must buffer the data, MAY exist. In practice, with modern recipient must buffer the data, MAY exist. In practice, with modern
machines this interval is likely to be fairly short. machines this interval is likely to be fairly short.
7.2. Alert Protocol 7.2. Alert Protocol
One of the content types supported by the TLS Record layer is the One of the content types supported by the TLS Record layer is the
alert type. Alert messages convey the severity of the message and a alert type. Alert messages convey the severity of the message
description of the alert. Alert messages with a level of fatal result (warning or fatal) and a description of the alert. Alert messages
in the immediate termination of the connection. In this case, other with a level of fatal result in the immediate termination of the
connections corresponding to the session may continue, but the connection. In this case, other connections corresponding to the
session identifier MUST be invalidated, preventing the failed session session may continue, but the session identifier MUST be invalidated,
from being used to establish new connections. Like other messages, preventing the failed session from being used to establish new
alert messages are encrypted and compressed, as specified by the connections. Like other messages, alert messages are encrypted and
current connection state. compressed, as specified by the current connection state.
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_RESERVED(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),
skipping to change at page 34, line 13 skipping to change at page 34, line 18
which the server must respond with a server hello message, or else a which the server must respond with a server hello message, or else a
fatal error will occur and the connection will fail. The client hello fatal error will occur and the connection will fail. The client hello
and server hello are used to establish security enhancement and server hello are used to establish security enhancement
capabilities between client and server. The client hello and server capabilities between client and server. The client hello and server
hello establish the following attributes: Protocol Version, Session hello establish the following attributes: Protocol Version, Session
ID, Cipher Suite, and Compression Method. Additionally, two random ID, Cipher Suite, and Compression Method. Additionally, two random
values are generated and exchanged: ClientHello.random and values are generated and exchanged: ClientHello.random and
ServerHello.random. ServerHello.random.
The actual key exchange uses up to four messages: the server The actual key exchange uses up to four messages: the server
certificate, the server key exchange, the client certificate, and the Certificate, the ServerKeyExchange, the client Certificate, and the
client key exchange. New key exchange methods can be created by ClientKeyExchange. New key exchange methods can be created by
specifying a format for these messages and by defining the use of the specifying a format for these messages and by defining the use of the
messages to allow the client and server to agree upon a shared messages to allow the client and server to agree upon a shared
secret. This secret MUST be quite long; currently defined key secret. This secret MUST be quite long; currently defined key
exchange methods exchange secrets that range from 46 bytes upwards. exchange methods exchange secrets that range from 46 bytes upwards.
Following the hello messages, the server will send its certificate, Following the hello messages, the server will send its certificate in
if it is to be authenticated. Additionally, a server key exchange a Certificate message if it is to be authenticated. Additionally, a
message may be sent, if it is required (e.g., if their server has no ServerKeyExchange message may be sent, if it is required (e.g., if
certificate, or if its certificate is for signing only). If the the server has no certificate, or if its certificate is for signing
server is authenticated, it may request a certificate from the only). If the server is authenticated, it may request a certificate
client, if that is appropriate to the cipher suite selected. Next, from the client, if that is appropriate to the cipher suite selected.
the server will send the server hello done message, indicating that Next, the server will send the ServerHelloDone message, indicating
the hello-message phase of the handshake is complete. The server will that the hello-message phase of the handshake is complete. The server
then wait for a client response. If the server has sent a certificate will then wait for a client response. If the server has sent a
request message, the client MUST send the certificate message. The CertificateRequest message, the client MUST send the Certificate
client key exchange message is now sent, and the content of that message. The ClientKeyExchange message is now sent, and the content
message will depend on the public key algorithm selected between the of that message will depend on the public key algorithm selected
client hello and the server hello. If the client has sent a between the client hello and the server hello. If the client has sent
certificate with signing ability, a digitally-signed certificate a certificate with signing ability, a digitally-signed
verify message is sent to explicitly verify possession of the private CertificateVerify message is sent to explicitly verify possession of
key in the certificate. the private key in the certificate.
At this point, a change cipher spec message is sent by the client, At this point, a ChangeCipherSpec message is sent by the client, and
and the client copies the pending Cipher Spec into the current Cipher the client copies the pending Cipher Spec into the current Cipher
Spec. The client then immediately sends the finished message under Spec. The client then immediately sends the Finished message under
the new algorithms, keys, and secrets. In response, the server will the new algorithms, keys, and secrets. In response, the server will
send its own change cipher spec message, transfer the pending to the send its own ChangeCipherSpec message, transfer the pending to the
current Cipher Spec, and send its finished message under the new current Cipher Spec, and send its Finished message under the new
Cipher Spec. At this point, the handshake is complete, and the client Cipher Spec. At this point, the handshake is complete, and the client
and server may begin to exchange application layer data. (See flow and server may begin to exchange application layer data. (See flow
chart below.) Application data MUST NOT be sent prior to the chart below.) Application data MUST NOT be sent prior to the
completion of the first handshake (before a cipher suite other than completion of the first handshake (before a cipher suite other than
TLS_NULL_WITH_NULL_NULL is established). TLS_NULL_WITH_NULL_NULL is established).
Client Server Client Server
ClientHello --------> ClientHello -------->
ServerHello ServerHello
skipping to change at page 35, line 36 skipping to change at page 36, line 40
When the client and server decide to resume a previous session or When the client and server decide to resume a previous session or
duplicate an existing session (instead of negotiating new security duplicate an existing session (instead of negotiating new security
parameters), the message flow is as follows: parameters), the message flow is as follows:
The client sends a ClientHello using the Session ID of the session to The client sends a ClientHello using the Session ID of the session to
be resumed. The server then checks its session cache for a match. If be resumed. The server then checks its session cache for a match. If
a match is found, and the server is willing to re-establish the a match is found, and the server is willing to re-establish the
connection under the specified session state, it will send a connection under the specified session state, it will send a
ServerHello with the same Session ID value. At this point, both ServerHello with the same Session ID value. At this point, both
client and server MUST send change cipher spec messages and proceed client and server MUST send ChangeCipherSpec messages and proceed
directly to finished messages. Once the re-establishment is complete, directly to Finished messages. Once the re-establishment is complete,
the client and server MAY begin to exchange application layer data. the client and server MAY begin to exchange application layer data.
(See flow chart below.) If a Session ID match is not found, the (See flow chart below.) If a Session ID match is not found, the
server generates a new session ID and the TLS client and server server generates a new session ID and the TLS client and server
perform a full handshake. perform a full handshake.
Client Server Client Server
ClientHello --------> ClientHello -------->
ServerHello ServerHello
[ChangeCipherSpec] [ChangeCipherSpec]
skipping to change at page 36, line 49 skipping to change at page 38, line 11
case finished: Finished; case finished: Finished;
} body; } body;
} Handshake; } Handshake;
The handshake protocol messages are presented below in the order they The handshake protocol messages are presented below in the order they
MUST be sent; sending handshake messages in an unexpected order MUST be sent; sending handshake messages in an unexpected order
results in a fatal error. Unneeded handshake messages can be omitted, results in a fatal error. Unneeded handshake messages can be omitted,
however. Note one exception to the ordering: the Certificate message however. Note one exception to the ordering: the Certificate message
is used twice in the handshake (from server to client, then from is used twice in the handshake (from server to client, then from
client to server), but described only in its first position. The one client to server), but described only in its first position. The one
message that is not bound by these ordering rules is the Hello message that is not bound by these ordering rules is the HelloRequest
Request message, which can be sent at any time, but which SHOULD be message, which can be sent at any time, but which SHOULD be ignored
ignored by the client if it arrives in the middle of a handshake. by the client if it arrives in the middle of a handshake.
New Handshake message types are assigned by IANA as described in New Handshake message types are assigned by IANA as described in
Section 12. Section 12.
7.4.1. Hello Messages 7.4.1. Hello Messages
The hello phase messages are used to exchange security enhancement The hello phase messages are used to exchange security enhancement
capabilities between the client and server. When a new session capabilities between the client and server. When a new session
begins, the Record Layer's connection state encryption, hash, and begins, the Record Layer's connection state encryption, hash, and
compression algorithms are initialized to null. The current compression algorithms are initialized to null. The current
connection state is used for renegotiation messages. connection state is used for renegotiation messages.
7.4.1.1. Hello Request 7.4.1.1. Hello Request
When this message will be sent: When this message will be sent:
The hello request message MAY be sent by the server at any time. The HelloRequest message MAY be sent by the server at any time.
Meaning of this message: Meaning of this message:
Hello request is a simple notification that the client should HelloRequest is a simple notification that the client should begin
begin the negotiation process anew by sending a client hello the negotiation process anew. In response, the client should a
message when convenient. This message is not intended to establish ClientHello message when convenient. This message is not intended
which side is the client or server but merely to initiate a new to establish which side is the client or server but merely to
negotiation. Servers SHOULD NOT send a HelloRequest immediately initiate a new negotiation. Servers SHOULD NOT send a HelloRequest
upon the client's initial connection. It is the client's job to immediately upon the client's initial connection. It is the
send a ClientHello at that time. client's job to send a ClientHello at that time.
This message will be ignored by the client if the client is This message will be ignored by the client if the client is
currently negotiating a session. This message may be ignored by currently negotiating a session. This message MAY be ignored by
the client if it does not wish to renegotiate a session, or the the client if it does not wish to renegotiate a session, or the
client may, if it wishes, respond with a no_renegotiation alert. client may, if it wishes, respond with a no_renegotiation alert.
Since handshake messages are intended to have transmission Since handshake messages are intended to have transmission
precedence over application data, it is expected that the precedence over application data, it is expected that the
negotiation will begin before no more than a few records are negotiation will begin before no more than a few records are
received from the client. If the server sends a hello request but received from the client. If the server sends a HelloRequest but
does not receive a client hello in response, it may close the does not receive a ClientHello in response, it may close the
connection with a fatal alert. connection with a fatal alert.
After sending a hello request, servers SHOULD NOT repeat the After sending a HelloRequest, servers SHOULD NOT repeat the
request until the subsequent handshake negotiation is complete. request until the subsequent handshake negotiation is complete.
Structure of this message: Structure of this message:
struct { } HelloRequest; struct { } HelloRequest;
Note: This message MUST NOT be included in the message hashes that This message MUST NOT be included in the message hashes that are
are maintained throughout the handshake and used in the finished maintained throughout the handshake and used in the finished messages
messages and the certificate verify message. and the certificate verify message.
7.4.1.2. Client Hello 7.4.1.2. Client Hello
When this message will be sent: When this message will be sent:
When a client first connects to a server it is required to send When a client first connects to a server it is required to send
the client hello as its first message. The client can also send a the ClientHello as its first message. The client can also send a
client hello in response to a hello request or on its own ClientHello in response to a HelloRequest or on its own initiative
initiative in order to renegotiate the security parameters in an in order to renegotiate the security parameters in an existing
existing connection. connection.
Structure of this message: Structure of this message:
The client hello message includes a random structure, which is The ClientHello message includes a random structure, which is used
used later in the protocol. later in the protocol.
struct { struct {
uint32 gmt_unix_time; uint32 gmt_unix_time;
opaque random_bytes[28]; opaque random_bytes[28];
} Random; } Random;
gmt_unix_time gmt_unix_time
The current time and date in standard UNIX 32-bit format The current time and date in standard UNIX 32-bit format
(seconds since the midnight starting Jan 1, 1970, GMT, ignoring (seconds since the midnight starting Jan 1, 1970, UTC, ignoring
leap seconds) according to the sender's internal clock. Clocks leap seconds) according to the sender's internal clock. Clocks
are not required to be set correctly by the basic TLS Protocol; are not required to be set correctly by the basic TLS Protocol;
higher-level or application protocols may define additional higher-level or application protocols may define additional
requirements. requirements. Note that, for historical reasons, the data
element is named using GMT, the predecessor of the current
worldwide time base, UTC.
random_bytes random_bytes
28 bytes generated by a secure random number generator. 28 bytes generated by a secure random number generator.
The client hello message includes a variable-length session The ClientHello message includes a variable-length session
identifier. If not empty, the value identifies a session between the identifier. If not empty, the value identifies a session between the
same client and server whose security parameters the client wishes to same client and server whose security parameters the client wishes to
reuse. The session identifier MAY be from an earlier connection, this reuse. The session identifier MAY be from an earlier connection, this
connection, or from another currently active connection. The second connection, or from another currently active connection. The second
option is useful if the client only wishes to update the random option is useful if the client only wishes to update the random
structures and derived values of a connection, and the third option structures and derived values of a connection, and the third option
makes it possible to establish several independent secure connections makes it possible to establish several independent secure connections
without repeating the full handshake protocol. These independent without repeating the full handshake protocol. These independent
connections may occur sequentially or simultaneously; a SessionID connections may occur sequentially or simultaneously; a SessionID
becomes valid when the handshake negotiating it completes with the becomes valid when the handshake negotiating it completes with the
skipping to change at page 39, line 14 skipping to change at page 40, line 27
Warning: Because the SessionID is transmitted without encryption or Warning: Because the SessionID is transmitted without encryption or
immediate MAC protection, servers MUST NOT place confidential immediate MAC protection, servers MUST NOT place confidential
information in session identifiers or let the contents of fake information in session identifiers or let the contents of fake
session identifiers cause any breach of security. (Note that the session identifiers cause any breach of security. (Note that the
content of the handshake as a whole, including the SessionID, is content of the handshake as a whole, including the SessionID, is
protected by the Finished messages exchanged at the end of the protected by the Finished messages exchanged at the end of the
handshake.) handshake.)
The cipher suite list, passed from the client to the server in the The cipher suite list, passed from the client to the server in the
client hello message, contains the combinations of cryptographic ClientHello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's algorithms supported by the client in order of the client's
preference (favorite choice first). Each cipher suite defines a key preference (favorite choice first). Each cipher suite defines a key
exchange algorithm, a bulk encryption algorithm (including secret key exchange algorithm, a bulk encryption algorithm (including secret key
length), a MAC algorithm, and a PRF. The server will select a cipher length), a MAC algorithm, and a PRF. The server will select a cipher
suite or, if no acceptable choices are presented, return a handshake suite or, if no acceptable choices are presented, return a handshake
failure alert and close the connection. If the list contains cipher failure alert and close the connection. If the list contains cipher
suites the server does not recognize, support, or wish to use, the suites the server does not recognize, support, or wish to use, the
server MUST ignore those cipher suites, and process the remaining server MUST ignore those cipher suites, and process the remaining
ones as usual. ones as usual.
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
The client hello includes a list of compression algorithms supported The ClientHello includes a list of compression algorithms supported
by the client, ordered according to the client's preference. by the client, ordered according to the client's preference.
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>; CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>; CompressionMethod compression_methods<1..2^8-1>;
skipping to change at page 40, line 17 skipping to change at page 41, line 31
communicate during this session. This SHOULD be the latest communicate during this session. This SHOULD be the latest
(highest valued) version supported by the client. For this version (highest valued) version supported by the client. For this version
of the specification, the version will be 3.3 (See Appendix E for of the specification, the version will be 3.3 (See Appendix E for
details about backward compatibility). details about backward compatibility).
random random
A client-generated random structure. A client-generated random structure.
session_id session_id
The ID of a session the client wishes to use for this connection. The ID of a session the client wishes to use for this connection.
This field is empty if no session_id is available, or it the This field is empty if no session_id is available, or if the
client wishes to generate new security parameters. client wishes to generate new security parameters.
cipher_suites cipher_suites
This is a list of the cryptographic options supported by the This is a list of the cryptographic options supported by the
client, with the client's first preference first. If the client, with the client's first preference first. If the
session_id field is not empty (implying a session resumption session_id field is not empty (implying a session resumption
request) this vector MUST include at least the cipher_suite from request), this vector MUST include at least the cipher_suite from
that session. Values are defined in Appendix A.5. that session. Values are defined in Appendix A.5.
compression_methods compression_methods
This is a list of the compression methods supported by the client, This is a list of the compression methods supported by the client,
sorted by client preference. If the session_id field is not empty sorted by client preference. If the session_id field is not empty
(implying a session resumption request) it MUST include the (implying a session resumption request), it MUST include the
compression_method from that session. This vector MUST contain, compression_method from that session. This vector MUST contain,
and all implementations MUST support, CompressionMethod.null. and all implementations MUST support, CompressionMethod.null.
Thus, a client and server will always be able to agree on a Thus, a client and server will always be able to agree on a
compression method. compression method.
extensions extensions
Clients MAY request extended functionality from servers by sending Clients MAY request extended functionality from servers by sending
data in the extensions Here the new "extensions" field contains a data in the extensions field. The actual "Extension" format is
list of extensions. The actual "Extension" format is defined in defined in Section 7.4.1.4.
Section 7.4.1.4.
In the event that a client requests additional functionality using In the event that a client requests additional functionality using
extensions, and this functionality is not supplied by the server, the extensions, and this functionality is not supplied by the server, the
client MAY abort the handshake. A server MUST accept client hello client MAY abort the handshake. A server MUST accept client hello
messages both with and without the extensions field, and (as for all messages both with and without the extensions field, and (as for all
other messages) MUST check that the amount of data in the message other messages) MUST check that the amount of data in the message
precisely matches one of these formats; if not, then it MUST send a precisely matches one of these formats; if not, then it MUST send a
fatal "decode_error" alert. fatal "decode_error" alert.
After sending the client hello message, the client waits for a server After sending the client hello message, the client waits for a
hello message. Any other handshake message returned by the server ServerHello message. Any other handshake message returned by the
except for a hello request is treated as a fatal error. server except for a HelloRequest is treated as a fatal error.
7.4.1.3. Server Hello 7.4.1.3. Server Hello
When this message will be sent: When this message will be sent:
The server will send this message in response to a client hello The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms. message when it was able to find an acceptable set of algorithms.
If it cannot find such a match, it will respond with a handshake If it cannot find such a match, it will respond with a handshake
failure alert. failure alert.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
Random random; Random random;
SessionID session_id; SessionID session_id;
skipping to change at page 42, line 10 skipping to change at page 43, line 25
using the specified session state, the server will respond with using the specified session state, the server will respond with
the same value as was supplied by the client. This indicates a the same value as was supplied by the client. This indicates a
resumed session and dictates that the parties must proceed resumed session and dictates that the parties must proceed
directly to the finished messages. Otherwise this field will directly to the finished messages. Otherwise this field will
contain a different value identifying the new session. The server contain a different value identifying the new session. The server
may return an empty session_id to indicate that the session will may return an empty session_id to indicate that the session will
not be cached and therefore cannot be resumed. If a session is not be cached and therefore cannot be resumed. If a session is
resumed, it must be resumed using the same cipher suite it was resumed, it must be resumed using the same cipher suite it was
originally negotiated with. Note that there is no requirement that originally negotiated with. Note that there is no requirement that
the server resume any session even if it had formerly provided a the server resume any session even if it had formerly provided a
session_id. Client MUST be prepared to do a full negotiation -- session_id. Clients MUST be prepared to do a full negotiation --
including negotiating new cipher suites -- during any handshake. including negotiating new cipher suites -- during any handshake.
cipher_suite cipher_suite
The single cipher suite selected by the server from the list in The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions, this field is the ClientHello.cipher_suites. For resumed sessions, this field is the
value from the state of the session being resumed. value from the state of the session being resumed.
compression_method compression_method
The single compression algorithm selected by the server from the The single compression algorithm selected by the server from the
list in ClientHello.compression_methods. For resumed sessions this list in ClientHello.compression_methods. For resumed sessions this
skipping to change at page 43, line 5 skipping to change at page 44, line 20
- "extension_data" contains information specific to the particular - "extension_data" contains information specific to the particular
extension type. extension type.
The initial set of extensions is defined in a companion document The initial set of extensions is defined in a companion document
[TLSEXT]. The list of extension types is maintained by IANA as [TLSEXT]. The list of extension types is maintained by IANA as
described in Section 12. described in Section 12.
There are subtle (and not so subtle) interactions that may occur in There are subtle (and not so subtle) interactions that may occur in
this protocol between new features and existing features which may this protocol between new features and existing features which may
result in a significant reduction in overall security, The following result in a significant reduction in overall security. The following
considerations should be taken into account when designing new considerations should be taken into account when designing new
extensions: extensions:
- Some cases where a server does not agree to an extension are error - Some cases where a server does not agree to an extension are error
conditions, and some simply a refusal to support a particular conditions, and some simply a refusal to support a particular
feature. In general error alerts should be used for the former, feature. In general error alerts should be used for the former,
and a field in the server extension response for the latter. and a field in the server extension response for the latter.
- Extensions should as far as possible be designed to prevent any - Extensions should as far as possible be designed to prevent any
attack that forces use (or non-use) of a particular feature by attack that forces use (or non-use) of a particular feature by
skipping to change at page 43, line 45 skipping to change at page 45, line 13
consideration in any major design change. consideration in any major design change.
7.4.1.4.1 Signature Algorithms 7.4.1.4.1 Signature Algorithms
The client uses the "signature_algorithms" extension to indicate to The client uses the "signature_algorithms" extension to indicate to
the server which signature/hash algorithm pairs may be used in the server which signature/hash algorithm pairs may be used in
digital signatures. The "extension_data" field of this extension digital signatures. The "extension_data" field of this extension
contains a "supported_signature_algorithms" value. contains a "supported_signature_algorithms" value.
enum { enum {
none(0), md5(1), sha1(2), sha256(3), sha384(4), none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(5), (255) sha512(6), (255)
} HashAlgorithm; } HashAlgorithm;
enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
SignatureAlgorithm; SignatureAlgorithm;
struct { struct {
HashAlgorithm hash; HashAlgorithm hash;
SignatureAlgorithm signature; SignatureAlgorithm signature;
} SignatureAndHashAlgorithm; } SignatureAndHashAlgorithm;
skipping to change at page 44, line 24 skipping to change at page 45, line 39
pair which the client is willing to verify. The values are indicated pair which the client is willing to verify. The values are indicated
in descending order of preference. in descending order of preference.
Note: Because not all signature algorithms and hash algorithms may be Note: Because not all signature algorithms and hash algorithms may be
accepted by an implementation (e.g., DSA with SHA-1, but not accepted by an implementation (e.g., DSA with SHA-1, but not
SHA-256), algorithms here are listed in pairs. SHA-256), algorithms here are listed in pairs.
hash hash
This field indicates the hash algorithm which may be used. The This field indicates the hash algorithm which may be used. The
values indicate support for unhashed data, MD5 [MD5], SHA-1, values indicate support for unhashed data, MD5 [MD5], SHA-1,
SHA-256, SHA-384, and SHA-512 [SHA] respectively. The "none" value SHA-224, SHA-256, SHA-384, and SHA-512 [SHS] respectively. The
is provided for future extensibility, in case of a signature "none" value is provided for future extensibility, in case of a
algorithm which does not require hashing before signing. signature algorithm which does not require hashing before signing.
signature signature
This field indicates the signature algorithm which may be used. This field indicates the signature algorithm which may be used.
The values indicate anonymous signatures, RSASSA-PKCS1-v1_5 The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
[PKCS1] and DSA [DSS] respectively. The "anonymous" value is [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively. The
meaningless in this context but used in Section 7.4.3. It MUST NOT "anonymous" value is meaningless in this context but used in
appear in this extension. Section 7.4.3. It MUST NOT appear in this extension.
The semantics of this extension are somewhat complicated because the The semantics of this extension are somewhat complicated because the
cipher suite indicates permissible signature algorithms but not hash cipher suite indicates permissible signature algorithms but not hash
algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate rules. algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules.
If the client supports only the default hash and signature algorithms If the client supports only the default hash and signature algorithms
(listed in this section), it MAY omit the signature_algorithms (listed in this section), it MAY omit the signature_algorithms
extension. If the client does not support the default algorithms, or extension. If the client does not support the default algorithms, or
supports other hash and signature algorithms (and it is willing to supports other hash and signature algorithms (and it is willing to
use them for verifying messages sent by server; server certificates use them for verifying messages sent by the server, i.e., server
and server key exchange), it MUST send the signature_algorithms certificates and server key exchange), it MUST send the
extension listing the algorithms it is willing to accept. signature_algorithms extension, listing the algorithms it is willing
to accept.
If the client does not send the signature_algorithms extension, the If the client does not send the signature_algorithms extension, the
server MUST assume the following: server MUST assume the following:
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent
the value (sha1,rsa). the value {sha1,rsa}.
- If the negotiated key exchange algorithm is one of (DHE_DSS, - If the negotiated key exchange algorithm is one of (DHE_DSS,
DH_DSS), behave as if the client had sent the value (sha1,dsa). DH_DSS), behave as if the client had sent the value {sha1,dsa}.
- If the negotiated key exchange algorithm is one of (ECDH_ECDSA, - If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa). ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
Note: this is a change from TLS 1.1 where there are no explicit rules Note: this is a change from TLS 1.1 where there are no explicit rules
but as a practical matter one can assume that the peer supports MD5 but as a practical matter one can assume that the peer supports MD5
and SHA-1. and SHA-1.
Note: this extension is not meaningful for TLS versions prior to 1.2. Note: this extension is not meaningful for TLS versions prior to 1.2.
Clients MUST NOT offer it if they are offering prior versions. Clients MUST NOT offer it if they are offering prior versions.
However, even if clients do offer it, the rules specified in [TLSEXT] However, even if clients do offer it, the rules specified in [TLSEXT]
require servers to ignore extensions they do not understand. require servers to ignore extensions they do not understand.
Servers MUST NOT send this extension. TLS servers MUST support Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension. receiving this extension.
7.4.2. Server Certificate 7.4.2. Server Certificate
When this message will be sent: When this message will be sent:
The server MUST send a certificate whenever the agreed-upon key The server MUST send a Certificate message whenever the agreed-
exchange method uses certificates for authentication (this upon key exchange method uses certificates for authentication
includes all key exchange methods defined in this document except (this includes all key exchange methods defined in this document
DH_anon). This message will always immediately follow the server except DH_anon). This message will always immediately follow the
hello message. server hello message.
Meaning of this message: Meaning of this message:
This message conveys the server's certificate chain to the client. This message conveys the server's certificate chain to the client.
The certificate MUST be appropriate for the negotiated cipher The certificate MUST be appropriate for the negotiated cipher
suite's key exchange algorithm, and any negotiated extensions. suite's key exchange algorithm, and any negotiated extensions.
Structure of this message: Structure of this message:
opaque ASN.1Cert<1..2^24-1>; opaque ASN.1Cert<1..2^24-1>;
struct { struct {
ASN.1Cert certificate_list<0..2^24-1>; ASN.1Cert certificate_list<0..2^24-1>;
} Certificate; } Certificate;
certificate_list certificate_list
This is a sequence (chain) of certificates. The sender's This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root independently, the self-signed certificate that specifies the root
certificate authority MAY optionally be omitted from the chain, certificate authority MAY be omitted from the chain, under the
under the assumption that the remote end must already possess it assumption that the remote end must already possess it in order to
in order to validate it in any case. validate it in any case.
The same message type and structure will be used for the client's The same message type and structure will be used for the client's
response to a certificate request message. Note that a client MAY response to a certificate request message. Note that a client MAY
send no certificates if it does not have an appropriate certificate send no certificates if it does not have an appropriate certificate
to send in response to the server's authentication request. to send in response to the server's authentication request.
Note: PKCS #7 [PKCS7] is not used as the format for the certificate Note: PKCS #7 [PKCS7] is not used as the format for the certificate
vector because PKCS #6 [PKCS6] extended certificates are not used. vector because PKCS #6 [PKCS6] extended certificates are not used.
Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
of parsing the list more difficult. of parsing the list more difficult.
skipping to change at page 46, line 43 skipping to change at page 48, line 12
if the key usage extension is present). if the key usage extension is present).
Note: RSA_PSK is defined in [TLSPSK]. Note: RSA_PSK is defined in [TLSPSK].
DHE_RSA RSA public key; the certificate MUST DHE_RSA RSA public key; the certificate MUST
ECDHE_RSA allow the key to be used for signing ECDHE_RSA allow the key to be used for signing
(the digitalSignature bit MUST be set (the digitalSignature bit MUST be set
if the key usage extension is present) if the key usage extension is present)
with the signature scheme and hash with the signature scheme and hash
algorithm that will be employed in the algorithm that will be employed in the
server key exchange message. server key exchange message.
Note: ECDHE_RSA is defined in [TLSECC].
DHE_DSS DSA public key; the certificate MUST DHE_DSS DSA public key; the certificate MUST
allow the key to be used for signing with allow the key to be used for signing with
the hash algorithm that will be employed the hash algorithm that will be employed
in the server key exchange message. in the server key exchange message.
DH_DSS Diffie-Hellman public key; the DH_DSS Diffie-Hellman public key; the
DH_RSA keyAgreement bit MUST be set if the DH_RSA keyAgreement bit MUST be set if the
key usage extension is present. key usage extension is present.
skipping to change at page 47, line 31 skipping to change at page 48, line 49
certificates provided by the server MUST be signed by a certificates provided by the server MUST be signed by a
hash/signature algorithm pair that appears in that extension. Note hash/signature algorithm pair that appears in that extension. Note
that this implies that a certificate containing a key for one that this implies that a certificate containing a key for one
signature algorithm MAY be signed using a different signature signature algorithm MAY be signed using a different signature
algorithm (for instance, an RSA key signed with a DSA key.) This is a algorithm (for instance, an RSA key signed with a DSA key.) This is a
departure from TLS 1.1, which required that the algorithms be the departure from TLS 1.1, which required that the algorithms be the
same. Note that this also implies that the DH_DSS, DH_RSA, same. Note that this also implies that the DH_DSS, DH_RSA,
ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
algorithm used to sign the certificate. Fixed DH certificates MAY be algorithm used to sign the certificate. Fixed DH certificates MAY be
signed with any hash/signature algorithm pair appearing in the signed with any hash/signature algorithm pair appearing in the
extension. The naming is historical. extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
historical.
If the server has multiple certificates, it chooses one of them based If the server has multiple certificates, it chooses one of them based
on the above-mentioned criteria (in addition to other criteria, such on the above-mentioned criteria (in addition to other criteria, such
as transport layer endpoint, local configuration and preferences, as transport layer endpoint, local configuration and preferences,
etc.). If the server has a single certificate it SHOULD attempt to etc.). If the server has a single certificate it SHOULD attempt to
validate that it meets these criteria. validate that it meets these criteria.
Note that there are certificates that use algorithms and/or algorithm Note that there are certificates that use algorithms and/or algorithm
combinations that cannot be currently used with TLS. For example, a combinations that cannot be currently used with TLS. For example, a
certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
SubjectPublicKeyInfo) cannot be used because TLS defines no SubjectPublicKeyInfo) cannot be used because TLS defines no
corresponding signature algorithm. corresponding signature algorithm.
As cipher suites that specify new key exchange methods are specified As cipher suites 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 the imply certificate format and the
required encoded keying information. required encoded keying information.
7.4.3. Server Key Exchange Message 7.4.3. Server Key Exchange Message
When this message will be sent: When this message will be sent:
This message will be sent immediately after the server certificate This message will be sent immediately after the server Certificate
message (or the server hello message, if this is an anonymous message (or the ServerHello message, if this is an anonymous
negotiation). negotiation).
The server key exchange message is sent by the server only when The ServerKeyExchange message is sent by the server only when the
the server certificate message (if sent) does not contain enough server Certificate message (if sent) does not contain enough data
data to allow the client to exchange a premaster secret. This is to allow the client to exchange a premaster secret. This is true
true for the following key exchange methods: for the following key exchange methods:
DHE_DSS DHE_DSS
DHE_RSA DHE_RSA
DH_anon DH_anon
It is not legal to send the server key exchange message for the It is not legal to send the ServerKeyExchange message for the
following key exchange methods: following key exchange methods:
RSA RSA
DH_DSS DH_DSS
DH_RSA DH_RSA
Other key exchange algorithms, such as those defined in
[TLSECC], MUST specify whether the ServerKeyExchange message is
sent or not; and if the message is sent, its contents.
Meaning of this message: Meaning of this message:
This message conveys cryptographic information to allow the client This message conveys cryptographic information to allow the client
to communicate the premaster secret: a Diffie-Hellman public key to communicate the premaster secret: a Diffie-Hellman public key
with which the client can complete a key exchange (with the result with which the client can complete a key exchange (with the result
being the premaster secret) or a public key for some other being the premaster secret) or a public key for some other
algorithm. algorithm.
Structure of this message: Structure of this message:
enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa } enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa
KeyExchangeAlgorithm; /* may be extended, e.g. for ECDH -- see [TLSECC] */
} KeyExchangeAlgorithm;
struct { struct {
opaque dh_p<1..2^16-1>; opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>; opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>; opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */ } ServerDHParams; /* Ephemeral DH parameters */
dh_p dh_p
The prime modulus used for the Diffie-Hellman operation. The prime modulus used for the Diffie-Hellman operation.
skipping to change at page 49, line 22 skipping to change at page 50, line 45
digitally-signed struct { digitally-signed struct {
opaque client_random[32]; opaque client_random[32];
opaque server_random[32]; opaque server_random[32];
ServerDHParams params; ServerDHParams params;
} signed_params; } signed_params;
case rsa: case rsa:
case dh_dss: case dh_dss:
case dh_rsa: case dh_rsa:
struct {} ; struct {} ;
/* message is omitted for rsa, dh_dss, and dh_rsa */ /* message is omitted for rsa, dh_dss, and dh_rsa */
/* may be extended, e.g. for ECDH -- see [TLSECC] */
}; };
} ServerKeyExchange; } ServerKeyExchange;
params params
The server's key exchange parameters. The server's key exchange parameters.
signed_params signed_params
For non-anonymous key exchanges, a signature over the For non-anonymous key exchanges, a signature over the
server's key exchange parameters. server's key exchange parameters.
If the client has offered the "signature_algorithms" extension, the If the client has offered the "signature_algorithms" extension, the
signature algorithm and hash algorithm MUST be a pair listed in that signature algorithm and hash algorithm MUST be a pair listed in that
extension. Note that there is a possibility for inconsistencies here. extension. Note that there is a possibility for inconsistencies here.
For instance, the client might offer DHE_DSS key exchange but omit For instance, the client might offer DHE_DSS key exchange but omit
any DSS pairs from its "signature_algorithms" extension. In order to any DSA pairs from its "signature_algorithms" extension. In order to
negotiate correctly, the server MUST check any candidate cipher negotiate correctly, the server MUST check any candidate cipher
suites against the "signature_algorithms" extension before selecting suites against the "signature_algorithms" extension before selecting
them. This is somewhat inelegant but is a compromise designed to them. This is somewhat inelegant but is a compromise designed to
minimize changes to the original cipher suite design. minimize changes to the original cipher suite design.
In addition, the hash and signature algorithms MUST be compatible In addition, the hash and signature algorithms MUST be compatible
with the key in the server's end-entity certificate. RSA keys MAY be with the key in the server's end-entity certificate. RSA keys MAY be
used with any permitted hash algorithm, subject to restrictions in used with any permitted hash algorithm, subject to restrictions in
the certificate, if any. the certificate, if any.
Because DSA signatures do not contain any secure indication of hash Because DSA signatures do not contain any secure indication of hash
algorithm, there is a risk of hash substitution if multiple hashes algorithm, there is a risk of hash substitution if multiple hashes
may be used with any key. Currently, DSS [DSS] may only be used with may be used with any key. Currently, DSA [DSS] may only be used with
SHA-1. Future revisions of DSS [DSS-3] are expected to allow other SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use
digest algorithms, as well as guidance as to which digest algorithms of other digest algorithms with DSA, as well as guidance as to which
should be used with each key size. In addition, future revisions of digest algorithms should be used with each key size. In addition,
future revisions of [PKIX] may specify mechanisms for certificates to
[PKIX] may specify mechanisms for certificates to indicate which indicate which digest algorithms are to be used with DSA.
digest algorithms are to be used with DSA.
As additional cipher suites are defined for TLS that include new key As additional cipher suites 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.
7.4.4. Certificate Request 7.4.4. Certificate Request
When this message will be sent: When this message will be sent:
A non-anonymous server can optionally request a certificate from A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite. This the client, if appropriate for the selected cipher suite. This
message, if sent, will immediately follow the Server Key Exchange message, if sent, will immediately follow the ServerKeyExchange
message (if it is sent; otherwise, the Server Certificate message (if it is sent; otherwise, the server's Certificate
message). message).
Structure of this message: Structure of this message:
enum { enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20), (255) fortezza_dms_RESERVED(20), (255)
} ClientCertificateType; } ClientCertificateType;
skipping to change at page 50, line 46 skipping to change at page 52, line 22
SignatureAndHashAlgorithm SignatureAndHashAlgorithm
supported_signature_algorithms<2^16-1>; supported_signature_algorithms<2^16-1>;
DistinguishedName certificate_authorities<0..2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest; } CertificateRequest;
certificate_types certificate_types
A list of the types of certificate types which the client may A list of the types of certificate types which the client may
offer. offer.
rsa_sign a certificate containing an RSA key rsa_sign a certificate containing an RSA key
dss_sign a certificate containing a DSS key dss_sign a certificate containing a DSA key
rsa_fixed_dh a certificate containing a static DH key. rsa_fixed_dh a certificate containing a static DH key.
dss_fixed_dh a certificate containing a static DH key dss_fixed_dh a certificate containing a static DH key
supported_signature_algorithms supported_signature_algorithms
A list of the hash/signature algorithm pairs that the server is A list of the hash/signature algorithm pairs that the server is
able to verify, listed in descending order of preference. able to verify, listed in descending order of preference.
certificate_authorities certificate_authorities
A list of the distinguished names [X501] of acceptable A list of the distinguished names [X501] of acceptable
certificate_authorities, represented in DER-encoded format. These certificate_authorities, represented in DER-encoded format. These
skipping to change at page 51, line 51 skipping to change at page 53, line 28
New ClientCertificateType values are assigned by IANA as described in New ClientCertificateType values are assigned by IANA as described in
Section 12. Section 12.
Note: Values listed as RESERVED may not be used. They were used in Note: Values listed as RESERVED may not be used. They were used in
SSLv3. SSLv3.
Note: It is a fatal handshake_failure alert for an anonymous server Note: It is a fatal handshake_failure alert for an anonymous server
to request client authentication. to request client authentication.
7.4.5 Server hello done 7.4.5 Server Hello Done
When this message will be sent: When this message will be sent:
The server hello done message is sent by the server to indicate The ServerHelloDone message is sent by the server to indicate the
the end of the server hello and associated messages. After sending end of the ServerHello and associated messages. After sending this
this message, the server will wait for a client response. message, the server will wait for a client response.
Meaning of this message: Meaning of this message:
This message means that the server is done sending messages to This message means that the server is done sending messages to
support the key exchange, and the client can proceed with its support the key exchange, and the client can proceed with its
phase of the key exchange. phase of the key exchange.
Upon receipt of the server hello done message, the client SHOULD Upon receipt of the ServerHelloDone message, the client SHOULD
verify that the server provided a valid certificate, if required verify that the server provided a valid certificate, if required,
and check that the server hello parameters are acceptable. and check that the server hello parameters are acceptable.
Structure of this message: Structure of this message:
struct { } ServerHelloDone; struct { } ServerHelloDone;
7.4.6. Client Certificate 7.4.6. Client Certificate
When this message will be sent: When this message will be sent:
This is the first message the client can send after receiving a This is the first message the client can send after receiving a
server hello done message. This message is only sent if the server server hello done message. This message is only sent if the server
requests a certificate. If no suitable certificate is available, requests a certificate. If no suitable certificate is available,
the client MUST send a certificate message containing no the client MUST send a certificate message containing no
certificates. That is, the certificate_list structure has a length certificates. That is, the certificate_list structure has a length
of zero. If the client does not send any certificates, the server of zero. If the client does not send any certificates, the server
MAY at its discretion either continue the handshake without client MAY at its discretion either continue the handshake without client
authentication, or respond with a fatal handshake_failure alert. authentication, or respond with a fatal handshake_failure alert.
skipping to change at page 52, line 47 skipping to change at page 54, line 25
(e.g., it was not signed by a known, trusted CA), the server MAY (e.g., it was not signed by a known, trusted CA), the server MAY
at its discretion either continue the handshake (considering the at its discretion either continue the handshake (considering the
client unauthenticated) or send a fatal alert. client unauthenticated) or send a fatal alert.
Client certificates are sent using the Certificate structure Client certificates are sent using the Certificate structure
defined in Section 7.4.2. defined in Section 7.4.2.
Meaning of this message: Meaning of this message:
This message conveys the client's certificate chain to the server; This message conveys the client's certificate chain to the server;
the server will use it when verifying the certificate verify the server will use it when verifying the CertificateVerify
message (when the client authentication is based on signing), or message (when the client authentication is based on signing) or
calculate the premaster secret (for non-ephemeral Diffie-Hellman). calculating the premaster secret (for non-ephemeral Diffie-
The certificate MUST be appropriate for the negotiated cipher Hellman). The certificate MUST be appropriate for the negotiated
suite's key exchange algorithm, and any negotiated extensions. cipher suite's key exchange algorithm, and any negotiated
extensions.
In particular: In particular:
- The certificate type MUST be X.509v3, unless explicitly negotiated - The certificate type MUST be X.509v3, unless explicitly negotiated
otherwise (e.g. [TLSPGP]). otherwise (e.g. [TLSPGP]).
- The end-entity certificate's public key (and associated - The end-entity certificate's public key (and associated
restrictions) has to be compatible with the certificate types restrictions) has to be compatible with the certificate types
listed in CertificateRequest: listed in CertificateRequest:
skipping to change at page 53, line 38 skipping to change at page 55, line 17
MUST allow the key to be used for signing MUST allow the key to be used for signing
with the hash algorithm that will be with the hash algorithm that will be
employed in the certificate verify employed in the certificate verify
message; the public key MUST use a message; the public key MUST use a
curve and point format supported by the curve and point format supported by the
server. server.
rsa_fixed_dh Diffie-Hellman public key; MUST use rsa_fixed_dh Diffie-Hellman public key; MUST use
dss_fixed_dh the same parameters as server's key. dss_fixed_dh the same parameters as server's key.
rsa_fixed_ecdh ECDH-capable public key; MUST use rsa_fixed_ecdh ECDH-capable public key; MUST use the
ecdsa_fixed_ecdh the same curve as server's key, and ecdsa_fixed_ecdh same curve as the server's key, and
MUST use a point format supported by MUST use a point format supported by
the server. the server.
- If the certificate_authorities list in the certificate request - If the certificate_authorities list in the certificate request
message was non-empty, one of the certificates in the certificate message was non-empty, one of the certificates in the certificate
chain SHOULD be issued by one of the listed CAs. chain SHOULD be issued by one of the listed CAs.
- The certificates MUST be signed using an acceptable hash/ - The certificates MUST be signed using an acceptable hash/
signature algorithm pair, as described in Section 7.4.4. Note that signature algorithm pair, as described in Section 7.4.4. Note that
this relaxes the constraints on certificate signing algorithms this relaxes the constraints on certificate signing algorithms
skipping to change at page 54, line 18 skipping to change at page 55, line 46
When this message will be sent: When this message will be sent:
This message is always sent by the client. It MUST immediately This message is always sent by the client. It MUST immediately
follow the client certificate message, if it is sent. Otherwise it follow the client certificate message, if it is sent. Otherwise it
MUST be the first message sent by the client after it receives the MUST be the first message sent by the client after it receives the
server hello done message. server hello done message.
Meaning of this message: Meaning of this message:
With this message, the premaster secret is set, either though With this message, the premaster secret is set, either through
direct transmission of the RSA-encrypted secret, or by the direct transmission of the RSA-encrypted secret, or by the
transmission of Diffie-Hellman parameters that will allow each transmission of Diffie-Hellman parameters that will allow each
side to agree upon the same premaster secret. side to agree upon the same premaster secret.
When the client is using an ephemeral Diffie-Hellman exponent, When the client is using an ephemeral Diffie-Hellman exponent,
then this message contains the client's Diffie-Hellman public then this message contains the client's Diffie-Hellman public
value. If the client is sending a certificate containing a static value. If the client is sending a certificate containing a static
DH exponent (i.e., it is doing fixed_dh client authentication) DH exponent (i.e., it is doing fixed_dh client authentication)
then this message MUST be sent but MUST be empty. then this message MUST be sent but MUST be empty.
skipping to change at page 55, line 9 skipping to change at page 56, line 36
} ClientKeyExchange; } ClientKeyExchange;
7.4.7.1. RSA Encrypted Premaster Secret Message 7.4.7.1. RSA Encrypted Premaster Secret Message
Meaning of this message: Meaning of this message:
If RSA is being used for key agreement and authentication, the If RSA is being used for key agreement and authentication, the
client generates a 48-byte premaster secret, encrypts it using the client generates a 48-byte premaster secret, encrypts it using the
public key from the server's certificate and sends the result in public key from the server's certificate and sends the result in
an encrypted premaster secret message. This structure is a variant an encrypted premaster secret message. This structure is a variant
of the client key exchange message and is not a message in itself. of the ClientKeyExchange message and is not a message in itself.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
opaque random[46]; opaque random[46];
} PreMasterSecret; } PreMasterSecret;
client_version client_version
The latest (newest) version supported by the client. This is The latest (newest) version supported by the client. This is
skipping to change at page 55, line 44 skipping to change at page 57, line 24
offered by the client in the ClientHello.client_version, not the offered by the client in the ClientHello.client_version, not the
version negotiated for the connection. This feature is designed to version negotiated for the connection. This feature is designed to
prevent rollback attacks. Unfortunately, some old implementations prevent rollback attacks. Unfortunately, some old implementations
use the negotiated version instead and therefore checking the version use the negotiated version instead and therefore checking the version
number may lead to failure to interoperate with such incorrect client number may lead to failure to interoperate with such incorrect client
implementations. implementations.
Client implementations MUST always send the correct version number in Client implementations MUST always send the correct version number in
PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher,
server implementations MUST check the version number as described in server implementations MUST check the version number as described in
the note below. If the version number is 1.0 or earlier, server the note below. If the version number is TLS 1.0 or earlier, server
implementations SHOULD check the version number, but MAY have a implementations SHOULD check the version number, but MAY have a
configuration option to disable the check. Note that if the check configuration option to disable the check. Note that if the check
fails, the PreMasterSecret SHOULD be randomized as described below. fails, the PreMasterSecret SHOULD be randomized as described below.
Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
[KPR03] can be used to attack a TLS server that reveals whether a [KPR03] can be used to attack a TLS server that reveals whether a
particular message, when decrypted, is properly PKCS#1 formatted, particular message, when decrypted, is properly PKCS#1 formatted,
contains a valid PreMasterSecret structure, or has the correct contains a valid PreMasterSecret structure, or has the correct
version number. version number.
The best way to avoid these vulnerabilities is to treat incorrectly The best way to avoid these vulnerabilities is to treat incorrectly
formatted messages in a manner indistinguishable from correctly formatted messages in a manner indistinguishable from correctly
formatted RSA blocks. In other words: formatted RSA blocks. In other words:
1. Generate a string R of 46 random bytes 1. Generate a string R of 46 random bytes
2. Decrypt the message M 2. Decrypt the message to recover the plaintext M
3. If the PKCS#1 padding is not correct, or the length of 3. If the PKCS#1 padding is not correct, or the length of
message M is not exactly 48 bytes: message M is not exactly 48 bytes:
premaster secret = ClientHello.client_version || R premaster secret = ClientHello.client_version || R
else If ClientHello.client_version <= TLS 1.0, and else If ClientHello.client_version <= TLS 1.0, and
version number check is explicitly disabled: version number check is explicitly disabled:
premaster secret = M premaster secret = M
else: else:
premaster secret = ClientHello.client_version || M[2..47] premaster secret = ClientHello.client_version || M[2..47]
skipping to change at page 56, line 49 skipping to change at page 58, line 29
to exist provided that the above recommendations are followed. to exist provided that the above recommendations are followed.
Implementation Note: Public-key-encrypted data is represented as an Implementation Note: Public-key-encrypted data is represented as an
opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
PreMasterSecret in a ClientKeyExchange is preceded by two length PreMasterSecret in a ClientKeyExchange is preceded by two length
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 length bytes, encoding the RSA encrypted data directly in
directly in the ClientKeyExchange message. the ClientKeyExchange message.
This specification requires correct encoding of the This specification requires correct encoding of the
EncryptedPreMasterSecret complete with length bytes. The resulting EncryptedPreMasterSecret complete with length bytes. The resulting
PDU is incompatible with many SSLv3 implementations. Implementors PDU is incompatible with many SSLv3 implementations. Implementors
upgrading from SSLv3 MUST modify their implementations to generate upgrading from SSLv3 MUST modify their implementations to generate
and accept the correct encoding. Implementors who wish to be and accept the correct encoding. Implementors who wish to be
compatible with both SSLv3 and TLS should make their implementation's compatible with both SSLv3 and TLS should make their implementation's
behavior dependent on the protocol version. behavior dependent on the protocol version.
Implementation Note: It is now known that remote timing-based attacks Implementation Note: It is now known that remote timing-based attacks
skipping to change at page 58, line 39 skipping to change at page 60, line 19
running hashes for all potential hash algorithms up to the time of running hashes for all potential hash algorithms up to the time of
the CertificateVerify computation. Servers can minimize this the CertificateVerify computation. Servers can minimize this
computation cost by offering a restricted set of digest algorithms computation cost by offering a restricted set of digest algorithms
in the CertificateRequest message. in the CertificateRequest message.
The hash and signature algorithms used in the signature MUST be The hash and signature algorithms used in the signature MUST be
one of those present in the supported_signature_algorithms field one of those present in the supported_signature_algorithms field
of the CertificateRequest message. In addition, the hash and of the CertificateRequest message. In addition, the hash and
signature algorithms MUST be compatible with the key in the signature algorithms MUST be compatible with the key in the
client's end-entity certificate. RSA keys MAY be used with any client's end-entity certificate. RSA keys MAY be used with any
permitted hash algorith, subject to restrictions in the permitted hash algorithm, subject to restrictions in the
certificate, if any. certificate, if any.
Because DSA signatures do not contain any secure indication of Because DSA signatures do not contain any secure indication of
hash algorithm, there is a risk of hash substitution if multiple hash algorithm, there is a risk of hash substitution if multiple
hashes may be used with any key. Currently, DSS [DSS] may only be hashes may be used with any key. Currently, DSA [DSS] may only be
used with SHA-1. Future revisions of DSS [DSS-3] are expected to used with SHA-1. Future revisions of DSS [DSS-3] are expected to
allow other digest algorithms, as well as guidance as to which allow the use of other digest algorithms with DSA, as well as
digest algorithms should be used with each key size. In addition, guidance as to which digest algorithms should be used with each
future revisions of [PKIX] may specify mechanisms for certificates key size. In addition, future revisions of [PKIX] may specify
to indicate which digest algorithms are to be used with DSA. mechanisms for certificates to indicate which digest algorithms
are to be used with DSA.
7.4.9. Finished 7.4.9. Finished
When this message will be sent: When this message will be sent:
A finished message is always sent immediately after a change A Finished message is always sent immediately after a change
cipher spec message to verify that the key exchange and cipher spec message to verify that the key exchange and
authentication processes were successful. It is essential that a authentication processes were successful. It is essential that a
change cipher spec message be received between the other handshake change cipher spec message be received between the other handshake
messages and the Finished message. messages and the Finished message.
Meaning of this message: Meaning of this message:
The finished message is the first protected with the just- The finished message is the first one protected with the just
negotiated algorithms, keys, and secrets. Recipients of finished negotiated algorithms, keys, and secrets. Recipients of finished
messages MUST verify that the contents are correct. Once a side messages MUST verify that the contents are correct. Once a side
has sent its Finished message and received and validated the has sent its Finished message and received and validated the
Finished message from its peer, it may begin to send and receive Finished message from its peer, it may begin to send and receive
application data over the connection. application data over the connection.
Structure of this message: Structure of this message:
struct { struct {
opaque verify_data[verify_data_length]; opaque verify_data[verify_data_length];
skipping to change at page 60, line 10 skipping to change at page 61, line 42
MUST be at least 12 bytes. MUST be at least 12 bytes.
handshake_messages handshake_messages
All of the data from all messages in this handshake (not All of the data from all messages in this handshake (not
including any HelloRequest messages) up to but not including including any HelloRequest messages) up to but not including
this message. This is only data visible at the handshake layer this message. This is only data visible at the handshake layer
and does not include record layer headers. This is the and does not include record layer headers. This is the
concatenation of all the Handshake structures as defined in concatenation of all the Handshake structures as defined in
7.4, exchanged thus far. 7.4, exchanged thus far.
It is a fatal error if a finished message is not preceded by a change It is a fatal error if a finished message is not preceded by a
cipher spec message at the appropriate point in the handshake. ChangeCipherSpec message at the appropriate point in the handshake.
The value handshake_messages includes all handshake messages starting The value handshake_messages includes all handshake messages starting
at client hello up to, but not including, this finished message. This at ClientHello up to, but not including, this Finished message. This
may be different from handshake_messages in Section 7.4.8 because it may be different from handshake_messages in Section 7.4.8 because it
would include the certificate verify message (if sent). Also, the would include the CertificateVerify message (if sent). Also, the
handshake_messages for the finished message sent by the client will handshake_messages for the Finished message sent by the client will
be different from that for the finished message sent by the server, be different from that for the Finished message sent by the server,
because the one that is sent second will include the prior one. because the one that is sent second will include the prior one.
Note: Change cipher spec messages, alerts, and any other record types Note: ChangeCipherSpec messages, alerts, and any other record types
are not handshake messages and are not included in the hash are not handshake messages and are not included in the hash
computations. Also, Hello Request messages are omitted from handshake computations. Also, HelloRequest messages are omitted from handshake
hashes. hashes.
8. Cryptographic Computations 8. Cryptographic Computations
In order to begin connection protection, the TLS Record Protocol In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and requires specification of a suite of algorithms, a master secret, and
the client and server random values. The authentication, encryption, the client and server random values. The authentication, encryption,
and MAC algorithms are determined by the cipher_suite selected by the and MAC algorithms are determined by the cipher_suite selected by the
server and revealed in the server hello message. The compression server and revealed in the server hello message. The compression
algorithm is negotiated in the hello messages, and the random values algorithm is negotiated in the hello messages, and the random values
skipping to change at page 61, line 29 skipping to change at page 63, line 10
contain all zero bits are stripped before it is used as the contain all zero bits are stripped before it is used as the
pre_master_secret. pre_master_secret.
Note: Diffie-Hellman parameters are specified by the server and may Note: Diffie-Hellman parameters are specified by the server and may
be either ephemeral or contained within the server's certificate. be either ephemeral or contained within the server's certificate.
9. Mandatory Cipher Suites 9. Mandatory Cipher Suites
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise, a TLS compliant application MUST implement the cipher otherwise, a TLS compliant application MUST implement the cipher
suite TLS_RSA_WITH_AES_128_CBC_SHA. suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the
definition).
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
skipping to change at page 62, line 33 skipping to change at page 64, line 17
- TLS HandshakeType Registry: Future values are allocated via - TLS HandshakeType Registry: Future values are allocated via
Standards Action [RFC2434]. Standards Action [RFC2434].
This document also uses a registry originally created in [RFC4366]. This document also uses a registry originally created in [RFC4366].
IANA is requested to update (has updated) it to reference this IANA is requested to update (has updated) it to reference this
document. The registry and its allocation policy (unchanged from document. The registry and its allocation policy (unchanged from
[RFC4366]) is listed below: [RFC4366]) is listed below:
- TLS ExtensionType Registry: Future values are allocated via IETF - TLS ExtensionType Registry: Future values are allocated via IETF
Consensus [RFC2434] Consensus [RFC2434]. IANA is requested to update this registry to
include the signature_algorithms extension and fill in the
appropriate value in Section 7.4.1.4.
In addition, this document defines two new registries to be In addition, this document defines two new registries to be
maintained by IANA: maintained by IANA:
- TLS SignatureAlgorithm Registry: The registry will be initially - TLS SignatureAlgorithm Registry: The registry will be initially
populated with the values described in Section 7.4.1.4.1. Future populated with the values described in Section 7.4.1.4.1. Future
values in the range 0-63 (decimal) inclusive are assigned via values in the range 0-63 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values in the range 64-223 (decimal) Standards Action [RFC2434]. Values in the range 64-223 (decimal)
inclusive are assigned via Specification Required [RFC2434]. inclusive are assigned via Specification Required [RFC2434].
Values from 224-255 (decimal) inclusive are reserved for Private Values from 224-255 (decimal) inclusive are reserved for Private
Use [RFC2434]. Use [RFC2434].
- TLS HashAlgorithm Registry: The registry will be initially - TLS HashAlgorithm Registry: The registry will be initially
populated with the values described in Section 7.4.1.4.1. Future populated with the values described in Section 7.4.1.4.1. Future
values in the range 0-63 (decimal) inclusive are assigned via values in the range 0-63 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values in the range 64-223 (decimal) Standards Action [RFC2434]. Values in the range 64-223 (decimal)
inclusive are assigned via Specification Required [RFC2434]. inclusive are assigned via Specification Required [RFC2434].
Values from 224-255 (decimal) inclusive are reserved for Private Values from 224-255 (decimal) inclusive are reserved for Private
Use [RFC2434]. Use [RFC2434].
This document defines one new TLS extension, signature_algorithms, This document also uses the TLS Compression Method Identifiers
which is to be (has been) allocated value TBD-BY-IANA in the TLS Registry, defined in [RFC3749]. IANA is requested to allocate
ExtensionType registry. value 0 for the "null" compression method.
This document also uses the TLS Compression Method Identifiers
Registry, defined in [RFC3749]. IANA is requested to allocate value
0 for the "null" compression method.
Appendix A. Protocol Constant Values Appendix A. Protocol Data Structures and 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; uint8 major;
uint8 minor; uint8 minor;
} ProtocolVersion; } ProtocolVersion;
ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/ ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/
skipping to change at page 65, line 14 skipping to change at page 66, line 14
struct { struct {
opaque IV[SecurityParameters.record_iv_length]; opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct { block-ciphered struct {
opaque content[TLSCompressed.length]; opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length]; opaque MAC[SecurityParameters.mac_length];
uint8 padding[GenericBlockCipher.padding_length]; uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length; uint8 padding_length;
}; };
} GenericBlockCipher; } GenericBlockCipher;
aead-ciphered struct { struct {
opaque IV[SecurityParameters.record_iv_length]; opaque nonce_explicit[SecurityParameters.record_iv_length];
opaque aead_output[AEADEncrypted.length]; aead-ciphered struct {
opaque content[TLSCompressed.length];
};
} GenericAEADCipher; } GenericAEADCipher;
A.2. Change Cipher Specs Message A.2. Change Cipher Specs Message
struct { struct {
enum { change_cipher_spec(1), (255) } type; enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec; } ChangeCipherSpec;
A.3. Alert Messages A.3. Alert Messages
enum { warning(1), fatal(2), (255) } AlertLevel; enum { warning(1), fatal(2), (255) } AlertLevel;
skipping to change at page 67, line 48 skipping to change at page 68, line 48
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
enum { enum {
signature_algorithms(TBD-BY-IANA), (65535) signature_algorithms(TBD-BY-IANA), (65535)
} ExtensionType; } ExtensionType;
enum{ enum{
none(0), md5(1), sha1(2), sha256(3), sha384(4), none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(5), (255) sha512(6), (255)
} HashAlgorithm; } HashAlgorithm;
enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm; enum {
anonymous(0), rsa(1), dsa(2), ecdsa(3), (255)
} SignatureAlgorithm;
struct { struct {
HashAlgorithm hash; HashAlgorithm hash;
SignatureAlgorithm signature; SignatureAlgorithm signature;
} SignatureAndHashAlgorithm; } SignatureAndHashAlgorithm;
SignatureAndHashAlgorithm SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-1>; supported_signature_algorithms<2..2^16-1>;
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;
enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa} enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa
KeyExchangeAlgorithm; /* may be extended, e.g. for ECDH -- see [TLSECC] */
} 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 */
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case dh_anon: case dh_anon:
skipping to change at page 68, line 48 skipping to change at page 69, line 51
digitally-signed struct { digitally-signed struct {
opaque client_random[32]; opaque client_random[32];
opaque server_random[32]; opaque server_random[32];
ServerDHParams params; ServerDHParams params;
} signed_params; } signed_params;
case rsa: case rsa:
case dh_dss: case dh_dss:
case dh_rsa: case dh_rsa:
struct {} ; struct {} ;
/* message is omitted for rsa, dh_dss, and dh_rsa */ /* message is omitted for rsa, dh_dss, and dh_rsa */
}; /* may be extended, e.g. for ECDH -- see [TLSECC] */
} ServerKeyExchange; } ServerKeyExchange;
enum { enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20), fortezza_dms_RESERVED(20),
(255) (255)
} ClientCertificateType; } ClientCertificateType;
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
skipping to change at page 71, line 5 skipping to change at page 72, line 10
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F }; CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 }; CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD2 }; CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD2 };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBD3 }; CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBD3 };
The following cipher suite definitions are used for server- The following cipher suite definitions are used for server-
authenticated (and optionally client-authenticated) Diffie-Hellman. authenticated (and optionally client-authenticated) Diffie-Hellman.
DH denotes cipher suites in which the server's certificate contains DH denotes cipher suites in which the server's certificate contains
the Diffie-Hellman parameters signed by the certificate authority the Diffie-Hellman parameters signed by the certificate authority
(CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
parameters are signed by a a signature-capable certificate, which has parameters are signed by a signature-capable certificate, which has
been signed by the CA. The signing algorithm used by the server is been signed by the CA. The signing algorithm used by the server is
specified after the DHE parameter. The server can request any specified after the DHE component of the CipherSuite name. The server
signature-capable certificate from the client for client can request any signature-capable certificate from the client for
authentication or it may request a Diffie-Hellman certificate. Any client authentication or it may request a Diffie-Hellman certificate.
Diffie-Hellman certificate provided by the client must use the Any Diffie-Hellman certificate provided by the client must use the
parameters (group and generator) described by the server. parameters (group and generator) described by the server.
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 }; CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 }; CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 }; CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 }; CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 }; CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 }; CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 }; CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 }; CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD4}; CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,TBD4 };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD5}; CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD5 };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD6}; CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,TBD6 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD7}; CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD7 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBD8}; CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,TBD8 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBD9}; CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBD9 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBDA}; CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,TBDA };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBDB}; CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBDB };
The following cipher suites are used for completely anonymous Diffie- The following cipher suites are used for completely anonymous Diffie-
Hellman communications in which neither party is authenticated. Note Hellman communications in which neither party is authenticated. Note
that this mode is vulnerable to man-in-the-middle attacks. Using that this mode is vulnerable to man-in-the-middle attacks. Using
this mode therefore is of limited use: These cipher suites MUST NOT this mode therefore is of limited use: These cipher suites MUST NOT
be used by TLS 1.2 implementations unless the application layer has be used by TLS 1.2 implementations unless the application layer has
specifically requested to allow anonymous key exchange. (Anonymous specifically requested to allow anonymous key exchange. (Anonymous
key exchange may sometimes be acceptable, for example, to support key exchange may sometimes be acceptable, for example, to support
opportunistic encryption when no set-up for authentication is in opportunistic encryption when no set-up for authentication is in
place, or when TLS is used as part of more complex security protocols place, or when TLS is used as part of more complex security protocols
that have other means to ensure authentication.) that have other means to ensure authentication.)
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00, TBDC}; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,TBDC};
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00, TBDD}; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,TBDD};
Note that using non-anonymous key exchange without actually verifying Note that using non-anonymous key exchange without actually verifying
the key exchange is essentially equivalent to anonymous key exchange, the key exchange is essentially equivalent to anonymous key exchange,
and the same precautions apply. While non-anonymous key exchange and the same precautions apply. While non-anonymous key exchange
will generally involve a higher computational and communicational will generally involve a higher computational and communicational
cost than anonymous key exchange, it may be in the interest of cost than anonymous key exchange, it may be in the interest of
interoperability not to disable non-anonymous key exchange when the interoperability not to disable non-anonymous key exchange when the
application layer is allowing anonymous key exchange. application layer is allowing anonymous key exchange.
New cipher suite values are assigned by IANA as described in Section New cipher suite values are assigned by IANA as described in Section
skipping to change at page 72, line 37 skipping to change at page 73, line 41
enum { server, client } ConnectionEnd; enum { server, client } ConnectionEnd;
enum { tls_prf_sha256 } PRFAlgorithm; enum { tls_prf_sha256 } PRFAlgorithm;
enum { null, rc4, 3des, aes } enum { null, rc4, 3des, aes }
BulkCipherAlgorithm; BulkCipherAlgorithm;
enum { stream, block, aead } CipherType; enum { stream, block, aead } CipherType;
enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384, enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384,
hmac_sha512} MACAlgorithm; hmac_sha512} MACAlgorithm;
/* The algorithms specified in CompressionMethod, /* The algorithms specified in CompressionMethod, PRFAlgorithm
BulkCipherAlgorithm, and MACAlgorithm may be added to. */ BulkCipherAlgorithm, and MACAlgorithm may be added to. */
struct { struct {
ConnectionEnd entity; ConnectionEnd entity;
PRFAlgorithm prf_algorithm; PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm; BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type; CipherType cipher_type;
uint8 enc_key_length; uint8 enc_key_length;
uint8 block_length; uint8 block_length;
uint8 fixed_iv_length; uint8 fixed_iv_length;
skipping to change at page 73, line 24 skipping to change at page 74, line 29
RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This
document changes some of the structures used in that document. This document changes some of the structures used in that document. This
section details the required changes for implementors of both RFC section details the required changes for implementors of both RFC
4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing
RFC 4492 do not need to read this section. RFC 4492 do not need to read this section.
This document adds a "signature_algorithm" field to the digitally- This document adds a "signature_algorithm" field to the digitally-
signed element in order to identify the signature and digest signed element in order to identify the signature and digest
algorithms used to create a signature. This change applies to digital algorithms used to create a signature. This change applies to digital
signatures formed using ECDSA as well, thus allowing ECDSA signatures signatures formed using ECDSA as well, thus allowing ECDSA signatures
to be used and digest algorithms other than SHA-1, provided such use to be used with digest algorithms other than SHA-1, provided such use
is compatible with the certificate and any restrictions imposed by is compatible with the certificate and any restrictions imposed by
future revisions of [PKIX]. future revisions of [PKIX].
As described in Sections 7.4.2 and 7.4.6, the restrictions on the As described in Sections 7.4.2 and 7.4.6, the restrictions on the
signature algorithms used to sign certificates are no longer tied to signature algorithms used to sign certificates are no longer tied to
the cipher suite (when used by the server) or the the cipher suite (when used by the server) or the
ClientCertificateType (when used by the client). Thus, the ClientCertificateType (when used by the client). Thus, the
restrictions on the algorithm used to sign certificates specified in restrictions on the algorithm used to sign certificates specified in
Sections 2 and 3 of RFC 4492 are also relaxed. As in this document Sections 2 and 3 of RFC 4492 are also relaxed. As in this document
the restrictions on the keys in the end-entity certificate remain. the restrictions on the keys in the end-entity certificate remain.
Appendix B. Glossary Appendix B. Glossary
Advanced Encryption Standard (AES) Advanced Encryption Standard (AES)
AES is a widely used symmetric encryption algorithm. AES is a AES [AES] is a widely used symmetric encryption algorithm. AES is
block cipher with a 128, 192, or 256 bit keys and a 16 byte block a block cipher with a 128, 192, or 256 bit keys and a 16 byte
size. [AES] TLS currently only supports the 128 and 256 bit key block size. TLS currently only supports the 128 and 256 bit key
sizes. sizes.
application protocol application protocol
An application protocol is a protocol that normally layers An application protocol is a protocol that normally layers
directly on top of the transport layer (e.g., TCP/IP). Examples directly on top of the transport layer (e.g., TCP/IP). Examples
include HTTP, TELNET, FTP, and SMTP. include HTTP, TELNET, FTP, and SMTP.
asymmetric cipher asymmetric cipher
See public key cryptography. See public key cryptography.
authenticated encryption with additional data (AEAD) authenticated encryption with additional data (AEAD)
A symmetric encryption algorithm that simultaneously provides A symmetric encryption algorithm that simultaneously provides
confidentiality and message integrity. confidentiality and message integrity.
authentication authentication
Authentication is the ability of one entity to determine the Authentication is the ability of one entity to determine the
identity of another entity. identity of another entity.
block cipher block cipher
A block cipher is an algorithm that operates on plaintext in A block cipher is an algorithm that operates on plaintext in
groups of bits, called blocks. 64 bits is a common block size. groups of bits, called blocks. 64 bits was, and 128 bits, is a
common block size.
bulk cipher bulk cipher
A symmetric encryption algorithm used to encrypt large quantities A symmetric encryption algorithm used to encrypt large quantities
of data. of data.
cipher block chaining (CBC) cipher block chaining (CBC)
CBC is a mode in which every plaintext block encrypted with a CBC is a mode in which every plaintext block encrypted with a
block cipher is first exclusive-ORed with the previous ciphertext block cipher is first exclusive-ORed with the previous ciphertext
block (or, in the case of the first block, with the initialization block (or, in the case of the first block, with the initialization
vector). For decryption, every block is first decrypted, then vector). For decryption, every block is first decrypted, then
skipping to change at page 75, line 6 skipping to change at page 76, line 12
client write MAC key client write MAC key
The secret data used to authenticate data written by the client. The secret data used to authenticate data written by the client.
connection connection
A connection is a transport (in the OSI layering model definition) A connection is a transport (in the OSI layering model definition)
that provides a suitable type of service. For TLS, such that provides a suitable type of service. For TLS, such
connections are peer-to-peer relationships. The connections are connections are peer-to-peer relationships. The connections are
transient. Every connection is associated with one session. transient. Every connection is associated with one session.
Data Encryption Standard Data Encryption Standard
DES is a very widely used symmetric encryption algorithm. DES is a DES [DES] still is a very widely used symmetric encryption
block cipher with a 56 bit key and an 8 byte block size. Note that algorithm although it is considered as rather weak now. DES is a
in TLS, for key generation purposes, DES is treated as having an 8 block cipher with a 56-bit key and an 8-byte block size. Note that
byte key length (64 bits), but it still only provides 56 bits of in TLS, for key generation purposes, DES is treated as having an
8-byte key length (64 bits), but it still only provides 56 bits of
protection. (The low bit of each key byte is presumed to be set to protection. (The low bit of each key byte is presumed to be set to
produce odd parity in that key byte.) DES can also be operated in produce odd parity in that key byte.) DES can also be operated in
a mode where three independent keys and three encryptions are used a mode [3DES] where three independent keys and three encryptions
for each block of data; this uses 168 bits of key (24 bytes in the are used for each block of data; this uses 168 bits of key (24
TLS key generation method) and provides the equivalent of 112 bits bytes in the TLS key generation method) and provides the
of security. [DES], [3DES] equivalent of 112 bits of security.
Digital Signature Standard (DSS) Digital Signature Standard (DSS)
A standard for digital signing, including the Digital Signing A standard for digital signing, including the Digital Signing
Algorithm, approved by the National Institute of Standards and Algorithm, approved by the National Institute of Standards and
Technology, defined in NIST FIPS PUB 186, "Digital Signature Technology, defined in NIST FIPS PUB 186-2, "Digital Signature
Standard", published May, 1994 by the U.S. Dept. of Commerce. Standard", published January 2000 by the U.S. Dept. of Commerce
[DSS] [DSS]. A significant update [DSS-3] has been drafted and
published in March 2006.
digital signatures digital signatures
Digital signatures utilize public key cryptography and one-way Digital signatures utilize public key cryptography and one-way
hash functions to produce a signature of the data that can be hash functions to produce a signature of the data that can be
authenticated, and is difficult to forge or repudiate. authenticated, and is difficult to forge or repudiate.
handshake handshake
An initial negotiation between client and server that establishes An initial negotiation between client and server that establishes
the parameters of their transactions. the parameters of their transactions.
skipping to change at page 75, line 49 skipping to change at page 77, line 10
A Message Authentication Code is a one-way hash computed from a A Message Authentication Code is a one-way hash computed from a
message and some secret data. It is difficult to forge without message and some secret data. It is difficult to forge without
knowing the secret data. Its purpose is to detect if the message knowing the secret data. Its purpose is to detect if the message
has been altered. has been altered.
master secret master secret
Secure secret data used for generating encryption keys, MAC Secure secret data used for generating encryption keys, MAC
secrets, and IVs. secrets, and IVs.
MD5 MD5
MD5 is a secure hashing function that converts an arbitrarily long MD5 [MD5] is a hashing function that converts an arbitrarily long
data stream into a hash of fixed size (16 bytes). [MD5] data stream into a hash of fixed size (16 bytes). Due to
significant progresses in cryptanalysis, at the time of
publication of this document, MD5 no longer can be considered a
'secure' hashing function.
public key cryptography public key cryptography
A class of cryptographic techniques employing two-key ciphers. A class of cryptographic techniques employing two-key ciphers.
Messages encrypted with the public key can only be decrypted with Messages encrypted with the public key can only be decrypted with
the associated private key. Conversely, messages signed with the the associated private key. Conversely, messages signed with the
private key can be verified with the public key. private key can be verified with the public key.
one-way hash function one-way hash function
A one-way transformation that converts an arbitrary amount of data A one-way transformation that converts an arbitrary amount of data
into a fixed-length hash. It is computationally hard to reverse into a fixed-length hash. It is computationally hard to reverse
skipping to change at page 76, line 45 skipping to change at page 78, line 9
A session identifier is a value generated by a server that A session identifier is a value generated by a server that
identifies a particular session. identifies a particular session.
server write key server write key
The key used to encrypt data written by the server. The key used to encrypt data written by the server.
server write MAC key server write MAC key
The secret data used to authenticate data written by the server. The secret data used to authenticate data written by the server.
SHA SHA
The Secure Hash Algorithm is defined in FIPS PUB 180-2. It The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2. It
produces a 20-byte output. Note that all references to SHA produces a 20-byte output. Note that all references to SHA
actually use the modified SHA-1 algorithm. [SHA] (without a numerical suffix) actually use the modified SHA-1
algorithm.
SHA-256 SHA-256
The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. It The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. It
produces a 32-byte output. produces a 32-byte output.
SSL SSL
Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
SSL Version 3.0 SSL Version 3.0
stream cipher stream cipher
skipping to change at page 78, line 48 skipping to change at page 79, line 48
TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256 TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256 TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256 TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256 TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256 TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256
Key Expanded IV Block Key IV Block
Cipher Type Material Key Material Size Size Cipher Type Material Size Size
------------ ------ -------- ---- -----
NULL Stream 0 0 0 N/A NULL Stream 0 0 N/A
RC4_128 Stream 16 16 0 N/A RC4_128 Stream 16 0 N/A
3DES_EDE_CBC Block 24 24 8 8 3DES_EDE_CBC Block 24 8 8
AES_128_CBC Block 16 16 16 16 AES_128_CBC Block 16 16 16
AES_256_CBC Block 32 32 16 16 AES_256_CBC Block 32 16 16
MAC Algorithm mac_length mac_key_length MAC Algorithm mac_length mac_key_length
-------- ----------- ---------- --------------
NULL N/A 0 0 NULL N/A 0 0
MD5 HMAC-MD5 16 16 MD5 HMAC-MD5 16 16
SHA HMAC-SHA1 20 20 SHA HMAC-SHA1 20 20
SHA256 HMAC-SHA256 32 32 SHA256 HMAC-SHA256 32 32
Type Type
Indicates whether this is a stream cipher or a block cipher Indicates whether this is a stream cipher or a block cipher
running in CBC mode. running in CBC mode.
Key Material Key Material
The number of bytes from the key_block that are used for The number of bytes from the key_block that are used for
generating the write keys. generating the write keys.
Expanded Key Material Expanded Key Material
skipping to change at page 83, line 19 skipping to change at page 84, line 19
Since there are various versions of TLS (1.0, 1.1, 1.2, and any Since there are various versions of TLS (1.0, 1.1, 1.2, and any
future versions) and SSL (2.0 and 3.0), means are needed to negotiate future versions) and SSL (2.0 and 3.0), means are needed to negotiate
the specific protocol version to use. The TLS protocol provides a the specific protocol version to use. The TLS protocol provides a
built-in mechanism for version negotiation so as not to bother other built-in mechanism for version negotiation so as not to bother other
protocol components with the complexities of version selection. protocol components with the complexities of version selection.
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
compatible ClientHello messages; thus, supporting all of them is compatible ClientHello messages; thus, supporting all of them is
relatively easy. Similarly, servers can easily handle clients trying relatively easy. Similarly, servers can easily handle clients trying
to use future versions of TLS as long as the ClientHello format to use future versions of TLS as long as the ClientHello format
remains compatible, and the client support the highest protocol remains compatible, and the client supports the highest protocol
version available in the server. version available in the server.
A TLS 1.2 client who wishes to negotiate with such older servers will A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this ClientHello.client_version. If the server does not support this
version, it will respond with ServerHello containing an older version version, it will respond with ServerHello containing an older version
number. If the client agrees to use this version, the negotiation number. If the client agrees to use this version, the negotiation
will proceed as appropriate for the negotiated protocol. will proceed as appropriate for the negotiated protocol.
If the version chosen by the server is not supported by the client If the version chosen by the server is not supported by the client
(or not acceptable), the client MUST send a "protocol_version" alert (or not acceptable), the client MUST send a "protocol_version" alert
message and close the connection. message and close the connection.
If a TLS server receives a ClientHello containing a version number If a TLS server receives a ClientHello containing a version number
greater than the highest version supported by the server, it MUST greater than the highest version supported by the server, it MUST
reply according to the highest version supported by the server. reply according to the highest version supported by the server.
A TLS server can also receive a ClientHello containing version number A TLS server can also receive a ClientHello containing a version
smaller than the highest supported version. If the server wishes to number smaller than the highest supported version. If the server
negotiate with old clients, it will proceed as appropriate for the wishes to negotiate with old clients, it will proceed as appropriate
highest version supported by the server that is not greater than for the highest version supported by the server that is not greater
ClientHello.client_version. For example, if the server supports TLS than ClientHello.client_version. For example, if the server supports
1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
proceed with a TLS 1.0 ServerHello. If server supports (or is willing proceed with a TLS 1.0 ServerHello. If server supports (or is willing
to use) only versions greater than client_version, it MUST send a to use) only versions greater than client_version, it MUST send a
"protocol_version" alert message and close the connection. "protocol_version" alert message and close the connection.
Whenever a client already knows the highest protocol known to a Whenever a client already knows the highest protocol version known to
server (for example, when resuming a session), it SHOULD initiate the a server (for example, when resuming a session), it SHOULD initiate
connection in that native protocol. the connection in that native protocol.
Note: some server implementations are known to implement version Note: some server implementations are known to implement version
negotiation incorrectly. For example, there are buggy TLS 1.0 servers negotiation incorrectly. For example, there are buggy TLS 1.0 servers
that simply close the connection when the client offers a version that simply close the connection when the client offers a version
newer than TLS 1.0. Also, it is known that some servers will refuse newer than TLS 1.0. Also, it is known that some servers will refuse
connection if any TLS extensions are included in ClientHello. the connection if any TLS extensions are included in ClientHello.
Interoperability with such buggy servers is a complex topic beyond Interoperability with such buggy servers is a complex topic beyond
the scope of this document, and may require multiple connection the scope of this document, and may require multiple connection
attempts by the client. attempts by the client.
Earlier versions of the TLS specification were not fully clear on Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello. the record layer version number for ClientHello.
skipping to change at page 88, line 41 skipping to change at page 89, line 41
a value derived from all preceding handshake messages. These a value derived from all preceding handshake messages. These
handshake messages include the server certificate, which binds the handshake messages include the server certificate, which binds the
signature to the server, and ServerHello.random, which binds the signature to the server, and ServerHello.random, which binds the
signature to the current handshake process. signature to the current handshake process.
F.1.1.3. Diffie-Hellman Key Exchange with Authentication F.1.1.3. Diffie-Hellman Key Exchange with Authentication
When Diffie-Hellman key exchange is used, the server can either When Diffie-Hellman key exchange is used, the server can either
supply a certificate containing fixed Diffie-Hellman parameters or supply a certificate containing fixed Diffie-Hellman parameters or
use the server key exchange message to send a set of temporary use the server key exchange message to send a set of temporary
Diffie-Hellman parameters signed with a DSS or RSA certificate. Diffie-Hellman parameters signed with a DSA or RSA certificate.
Temporary parameters are hashed with the hello.random values before Temporary parameters are hashed with the hello.random values before
signing to ensure that attackers do not replay old parameters. In signing to ensure that attackers do not replay old parameters. In
either case, the client can verify the certificate or signature to either case, the client can verify the certificate or signature to
ensure that the parameters belong to the server. ensure that the parameters belong to the server.
If the client has a certificate containing fixed Diffie-Hellman If the client has a certificate containing fixed Diffie-Hellman
parameters, its certificate contains the information required to parameters, its certificate contains the information required to
complete the key exchange. Note that in this case the client and complete the key exchange. Note that in this case the client and
server will generate the same Diffie-Hellman result (i.e., server will generate the same Diffie-Hellman result (i.e.,
pre_master_secret) every time they communicate. To prevent the pre_master_secret) every time they communicate. To prevent the
pre_master_secret from staying in memory any longer than necessary, pre_master_secret from staying in memory any longer than necessary,
it should be converted into the master_secret as soon as possible. it should be converted into the master_secret as soon as possible.
Client Diffie-Hellman parameters must be compatible with those Client Diffie-Hellman parameters must be compatible with those
supplied by the server for the key exchange to work. supplied by the server for the key exchange to work.
If the client has a standard DSS or RSA certificate or is If the client has a standard DSA or RSA certificate or is
unauthenticated, it sends a set of temporary parameters to the server unauthenticated, it sends a set of temporary parameters to the server
in the client key exchange message, then optionally uses a in the client key exchange message, then optionally uses a
certificate verify message to authenticate itself. certificate verify message to authenticate itself.
If the same DH keypair is to be used for multiple handshakes, either If the same DH keypair is to be used for multiple handshakes, either
because the client or server has a certificate containing a fixed DH because the client or server has a certificate containing a fixed DH
keypair or because the server is reusing DH keys, care must be taken keypair or because the server is reusing DH keys, care must be taken
to prevent small subgroup attacks. Implementations SHOULD follow the to prevent small subgroup attacks. Implementations SHOULD follow the
guidelines found in [SUBGROUP]. guidelines found in [SUBGROUP].
skipping to change at page 93, line 13 skipping to change at page 94, line 13
authentication algorithm supported, and only trustworthy authentication algorithm supported, and only trustworthy
cryptographic functions should be used. Short public keys and cryptographic functions should be used. Short public keys and
anonymous servers should be used with great caution. Implementations anonymous servers should be used with great caution. Implementations
and users must be careful when deciding which certificates and and users must be careful when deciding which certificates and
certificate authorities are acceptable; a dishonest certificate certificate authorities are acceptable; a dishonest certificate
authority can do tremendous damage. authority can do tremendous damage.
Changes in This Version Changes in This Version
[RFC Editor: Please delete this] [RFC Editor: Please delete this]
- Added a new pitfall about fragmenting messages when necessary Clarified traffic analysis considerations
[Issue #71]
- Added Updates: RFC 4492 [Issue #83]
- Long CBC padding pitfall [Issue #73]
- Fixed ProtocolVersion structure [Issue #79]
- Cleaned up extensions text [Issue #78]
- Clarified alerts some [Issue #85]
- Added AES to the table in Appendix C [Issue #72]
- Tightened up when signature_algorithms is used
(it is now a MUST if you support other than SHA-1)
and the interpretation when it is absent is also a MUST
[Issue #67]
- Cleaned up "cipher suite" so it's always two words outside
of when it refers to the syntactic type [Issue #68]
- Misc editorial.
- Added support for SHA256 cipher suites
- Clarified warning alert behavior and client certificate omission
behavior [Issue #84]
- Removed IDEA and DES entirely for documentation in a separate doc
[Issue #64]
- Changed the presentation language to allow fall-through to simplify Added support for SHA-224 for signatures (though not for HMAC).
some of the PDUs.
- Cleaned up KeyExchangeAlgorithm ClientKeyExchange to use values Consistent use of camelback style for references to messages (e.g.,
that match Appendix C. ServerHelloDone) in the text.
- Changed digitally-signed to include SignatureAndHashAlgorithm Changed "DSS" to "DSA" where we are referring to the algorithm.
(another simplification)
- Considerations for RFC 4492 Extensive editorial revisions from Alfred Hoenes.
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 Technology, [3DES] National Institute of Standards and Technology,
"Recommendation for the Triple Data Encryption Algorithm "Recommendation for the Triple Data Encryption Algorithm
(TDEA) Block Cipher", NIST Special Publication 800-67, May (TDEA) Block Cipher", NIST Special Publication 800-67, May
2004. 2004.
[DES] National Institute of Standards and Technology, "Data [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard", National
Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
[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.
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
April 1992. April 1992.
skipping to change at page 94, line 47 skipping to change at page 95, line 10
3447, February 2003. 3447, February 2003.
[PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002. Revocation List (CRL) Profile", RFC 3280, April 2002.
[SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
and Source Code in C, 2nd ed.", Published by John Wiley & and Source Code in C, 2nd ed.", Published by John Wiley &
Sons, Inc. 1996. Sons, Inc. 1996.
[SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National
Institute of Standards and Technology, U.S. Department of Institute of Standards and Technology, U.S. Department of
Commerce., August 2001. Commerce, August 2002.
[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.
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation.
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding Rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules
(CER) and Distinguished Encoding Rules (DER).
Informative References Informative References
[AEAD] Mcgrew, D., "Authenticated Encryption", July 2007, draft- [AEAD] Mcgrew, D., "An Interface and Algorithms for Authenticated
mcgrew-auth-enc-05.txt. Encryption", RFC 5116, January 2008.
[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 95, line 36 skipping to change at page 96, line 10
[CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
"Password Interception in a SSL/TLS Channel", Advances in "Password Interception in a SSL/TLS Channel", Advances in
Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003. Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
[CCM] "NIST Special Publication 800-38C: The CCM Mode for [CCM] "NIST Special Publication 800-38C: The CCM Mode for
Authentication and Confidentiality", Authentication and Confidentiality",
http://csrc.nist.gov/publications/nistpubs/800-38C/ http://csrc.nist.gov/publications/nistpubs/800-38C/
SP800-38C.pdf SP800-38C.pdf
[DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard," [DES] National Institute of Standards and Technology, "Data
Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
[DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard",
National Institute of Standards and Technology, U.S. National Institute of Standards and Technology, U.S.
Department of Commerce, 2006. Department of Commerce, 2006.
[ECSDSA] American National Standards Institute, "Public Key
Cryptography for the Financial Services Industry: The
Elliptic Curve Digital Signature Algorithm (ECDSA)", ANS
X9.62-2005, November 2005.
[ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
for Protecting Communications (Or: How Secure is SSL?)", for Protecting Communications (Or: How Secure is SSL?)",
Crypto 2001. Crypto 2001.
[ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
Payload (ESP)", RFC 4303, December 2005. Payload (ESP)", RFC 4303, December 2005.
[FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on
implementation error", ietf-openpgp@imc.org mailing list, 27 implementation error", ietf-openpgp@imc.org mailing list, 27
August 2006, http://www.imc.org/ietf-openpgp/mail- August 2006, http://www.imc.org/ietf-openpgp/mail-
skipping to change at page 96, line 26 skipping to change at page 97, line 6
[KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
March 2003. March 2003.
[MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) [MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
3526, May 2003. 3526, May 2003.
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
Standard," version 1.5, November 1993. Standard", version 1.5, November 1993.
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
Standard," version 1.5, November 1993. Standard", version 1.5, November 1993.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
Compression Methods", RFC 3749, May 2004. Compression Methods", RFC 3749, May 2004.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
Wright, T., "Transport Layer Security (TLS) Extensions", RFC Wright, T., "Transport Layer Security (TLS) Extensions", RFC
4366, April 2006. 4366, April 2006.
[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems," Obtaining Digital Signatures and Public-Key Cryptosystems",
Communications of the ACM, v. 21, n. 2, Feb 1978, pp. Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
120-126. 120-126.
[SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks", [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996. RFC 1948, May 1996.
[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
Corp., Feb 9, 1995. Corp., Feb 9, 1995.
[SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0 [SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
Protocol", Netscape Communications Corp., Nov 18, 1996. Protocol", Netscape Communications Corp., Nov 18, 1996.
[SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for Attacks on the Diffie-Hellman Key Agreement Method for
S/MIME", RFC 2785, March 2000. S/MIME", RFC 2785, March 2000.
[TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
practical", USENIX Security Symposium 2003. practical", USENIX Security Symposium 2003.
[TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
for Transport Layer Security (TLS)", RFC 3268, June 2002. for Transport Layer Security (TLS)", RFC 3268, June 2002.
[TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
skipping to change at page 97, line 43 skipping to change at page 98, line 24
[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.
[XDR] Eisler, M., "External Data Representation Standard", RFC [XDR] Eisler, M., "External Data Representation Standard", STD 67,
4506, May 2006. RFC 4506, May 2006.
Credits Credits
Working Group Chairs Working Group Chairs
Eric Rescorla Eric Rescorla
EMail: ekr@networkresonance.com EMail: ekr@networkresonance.com
Pasi Eronen Pasi Eronen
pasi.eronen@nokia.com pasi.eronen@nokia.com
 End of changes. 154 change blocks. 
412 lines changed or deleted 427 lines changed or added

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