< draft-ietf-tls-rfc4346-bis-05.txt   draft-ietf-tls-rfc4346-bis-06.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
Intended status: Proposed Standard Eric Rescorla Intended status: Proposed Standard Eric Rescorla
Network Resonance, Inc. Network Resonance, Inc.
<draft-ietf-tls-rfc4346-bis-05.txt> September 2007 (Expires March 2008) <draft-ietf-tls-rfc4346-bis-06.txt> October 2007 (Expires April 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 96, line ? skipping to change at page 99, line ?
Abstract Abstract
This document specifies Version 1.2 of the Transport Layer Security This document specifies Version 1.2 of the Transport Layer Security
(TLS) protocol. The TLS protocol provides communications security (TLS) protocol. The TLS protocol provides communications security
over the Internet. The protocol allows client/server applications to over the Internet. The protocol allows client/server applications to
communicate in a way that is designed to prevent eavesdropping, communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery. tampering, or message forgery.
Table of Contents Table of Contents
1. Introduction 3 1. Introduction 3
1.1 Requirements Terminology 5 1.1 Requirements Terminology 5
1.2 Major Differences from TLS 1.1 5 1.2 Major Differences from TLS 1.1 5
2. Goals 6 2. Goals 6
3. Goals of This Document 6 3. Goals of This Document 6
4. Presentation Language 7 4. Presentation Language 7
4.1. Basic Block Size 7 4.1. Basic Block Size 7
4.2. Miscellaneous 7 4.2. Miscellaneous 7
4.3. Vectors 7 4.3. Vectors 7
4.4. Numbers 8 4.4. Numbers 8
4.5. Enumerateds 9 4.5. Enumerateds 9
4.6. Constructed Types 10 4.6. Constructed Types 10
4.6.1. Variants 10 4.6.1. Variants 10
4.7. Cryptographic Attributes 11 4.7. Cryptographic Attributes 11
4.8. Constants 12 4.8. Constants 13
5. HMAC and the Pseudorandom Function 13 5. HMAC and the Pseudorandom Function 13
6. The TLS Record Protocol 14 6. The TLS Record Protocol 14
6.1. Connection States 15 6.1. Connection States 15
6.2. Record layer 17 6.2. Record layer 17
6.2.1. Fragmentation 17 6.2.1. Fragmentation 17
6.2.2. Record Compression and Decompression 19 6.2.2. Record Compression and Decompression 19
6.2.3. Record Payload Protection 19 6.2.3. Record Payload Protection 19
6.2.3.1. Null or Standard Stream Cipher 20 6.2.3.1. Null or Standard Stream Cipher 20
6.2.3.2. CBC Block Cipher 21 6.2.3.2. CBC Block Cipher 21
6.2.3.3. AEAD ciphers 22 6.2.3.3. AEAD ciphers 23
6.3. Key Calculation 24 6.3. Key Calculation 24
7. The TLS Handshaking Protocols 25 7. The TLS Handshaking Protocols 25
7.1. Change Cipher Spec Protocol 25 7.1. Change Cipher Spec Protocol 25
7.2. Alert Protocol 26 7.2. Alert Protocol 26
7.2.1. Closure Alerts 27 7.2.1. Closure Alerts 27
7.2.2. Error Alerts 28 7.2.2. Error Alerts 28
7.3. Handshake Protocol Overview 31 7.3. Handshake Protocol Overview 31
7.4. Handshake Protocol 34 7.4. Handshake Protocol 34
7.4.1. Hello Messages 35 7.4.1. Hello Messages 35
7.4.1.1. Hello Request 35 7.4.1.1. Hello Request 36
7.4.1.2. Client Hello 36 7.4.1.2. Client Hello 36
7.4.1.3. Server Hello 39 7.4.1.3. Server Hello 39
7.4.1.4 Hello Extensions 41 7.4.1.4 Hello Extensions 41
7.4.1.4.1 Cert Hash Types 42 7.4.1.4.1 Signature Hash Algorithms 42
7.4.2. Server Certificate 42 7.4.2. Server Certificate 43
7.4.3. Server Key Exchange Message 44 7.4.3. Server Key Exchange Message 46
7.4.4. Certificate Request 46 7.4.4. Certificate Request 49
7.4.5 Server hello done 48 7.4.5 Server hello done 50
7.4.6. Client Certificate 48 7.4.6. Client Certificate 51
7.4.7. Client Key Exchange Message 49 7.4.7. Client Key Exchange Message 52
7.4.7.1. RSA Encrypted Premaster Secret Message 49 7.4.7.1. RSA Encrypted Premaster Secret Message 53
7.4.7.2. Client Diffie-Hellman Public Value 52 7.4.7.2. Client Diffie-Hellman Public Value 55
7.4.8. Certificate verify 52 7.4.8. Certificate verify 56
7.4.9. Finished 53 7.4.9. Finished 57
8. Cryptographic Computations 55 8. Cryptographic Computations 58
8.1. Computing the Master Secret 55 8.1. Computing the Master Secret 58
8.1.1. RSA 55 8.1.1. RSA 59
8.1.2. Diffie-Hellman 55 8.1.2. Diffie-Hellman 59
9. Mandatory Cipher Suites 56 9. Mandatory Cipher Suites 59
10. Application Data Protocol 56 10. Application Data Protocol 59
11. Security Considerations 56 11. Security Considerations 59
12. IANA Considerations 56 12. IANA Considerations 59
A. Protocol Constant Values 58 A. Protocol Constant Values 62
A.1. Record Layer 58 A.1. Record Layer 62
A.2. Change Cipher Specs Message 59 A.2. Change Cipher Specs Message 63
A.3. Alert Messages 59 A.3. Alert Messages 63
A.4. Handshake Protocol 61 A.4. Handshake Protocol 65
A.4.1. Hello Messages 61 A.4.1. Hello Messages 65
A.4.2. Server Authentication and Key Exchange Messages 62 A.4.2. Server Authentication and Key Exchange Messages 67
A.4.3. Client Authentication and Key Exchange Messages 64 A.4.3. Client Authentication and Key Exchange Messages 68
A.4.4. Handshake Finalization Message 64 A.4.4. Handshake Finalization Message 68
A.5. The CipherSuite 64 A.5. The CipherSuite 69
A.6. The Security Parameters 67 A.6. The Security Parameters 71
B. Glossary 68 B. Glossary 73
C. CipherSuite Definitions 72 C. CipherSuite Definitions 77
D. Implementation Notes 74 D. Implementation Notes 79
D.1 Random Number Generation and Seeding 74 D.1 Random Number Generation and Seeding 79
D.2 Certificates and Authentication 74 D.2 Certificates and Authentication 79
D.3 CipherSuites 74 D.3 CipherSuites 79
D.4 Implementation Pitfalls 74 D.4 Implementation Pitfalls 79
E. Backward Compatibility 77 E. Backward Compatibility 82
E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 77 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 82
E.2 Compatibility with SSL 2.0 78 E.2 Compatibility with SSL 2.0 83
E.3. Avoiding Man-in-the-Middle Version Rollback 80 E.3. Avoiding Man-in-the-Middle Version Rollback 85
F. Security Analysis 81 F. Security Analysis 86
F.1. Handshake Protocol 81 F.1. Handshake Protocol 86
F.1.1. Authentication and Key Exchange 81 F.1.1. Authentication and Key Exchange 86
F.1.1.1. Anonymous Key Exchange 81 F.1.1.1. Anonymous Key Exchange 86
F.1.1.2. RSA Key Exchange and Authentication 82 F.1.1.2. RSA Key Exchange and Authentication 87
F.1.1.3. Diffie-Hellman Key Exchange with Authentication 82 F.1.1.3. Diffie-Hellman Key Exchange with Authentication 87
F.1.2. Version Rollback Attacks 83 F.1.2. Version Rollback Attacks 88
F.1.3. Detecting Attacks Against the Handshake Protocol 84 F.1.3. Detecting Attacks Against the Handshake Protocol 89
F.1.4. Resuming Sessions 84 F.1.4. Resuming Sessions 89
F.2. Protecting Application Data 85 F.2. Protecting Application Data 89
F.3. Explicit IVs 85 F.3. Explicit IVs 90
F.4. Security of Composite Cipher Modes 85 F.4. Security of Composite Cipher Modes 90
F.5 Denial of Service 86 F.5 Denial of Service 91
F.6 Final Notes 92
1. Introduction 1. Introduction
The primary goal of the TLS Protocol is to provide privacy and data The primary goal of the TLS Protocol is to provide privacy and data
integrity between two communicating applications. The protocol is integrity between two communicating applications. The protocol is
composed of two layers: the TLS Record Protocol and the TLS Handshake composed of two layers: the TLS Record Protocol and the TLS Handshake
Protocol. At the lowest level, layered on top of some reliable Protocol. At the lowest level, layered on top of some reliable
transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
TLS Record Protocol provides connection security that has two basic TLS Record Protocol provides connection security that has two basic
properties: properties:
skipping to change at page 96, line ? skipping to change at page 99, line ?
transparently. The TLS standard, however, does not specify how transparently. The TLS standard, however, does not specify how
protocols add security with TLS; the decisions on how to initiate TLS protocols add security with TLS; the decisions on how to initiate TLS
handshaking and how to interpret the authentication certificates handshaking and how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors exchanged are left to the judgment of the designers and implementors
of protocols that run on top of TLS. of protocols that run on top of TLS.
1.1 Requirements Terminology 1.1 Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [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:
- Merged in TLS Extensions definition and AES Cipher Suites from - Merged in TLS Extensions definition and AES Cipher Suites from
external documents [TLSEXT] and [TLSAES]. external documents [TLSEXT] and [TLSAES].
- Replacement of MD5/SHA-1 combination in the PRF. Addition - Replacement of MD5/SHA-1 combination in the PRF. Addition
of cipher-suite specified PRFs. of cipher-suite specified PRFs.
- Replacement of MD5/SHA-1 combination in the digitally-signed - Replacement of MD5/SHA-1 combination in the digitally-signed
element. element.
- Allow the client to indicate which hash functions it supports - Substantial cleanup to the clients and servers ability to
for digital signature. specify which digest and signature algorithms they will
accept. Note that this also relaxes some of the constraints
- Allow the server to indicate which hash functions it supports on signature and digest algorithms from previous versions of
for digital signature. TLS.
- Addition of support for authenticated encryption with additional - Addition of support for authenticated encryption with additional
data modes. data modes.
- Tightened up a number of requirements. - Tightened up a number of requirements.
- The usual clarifications and editorial work. - Added some guidance that DH groups should be checked for size.
- Added some guidance that DH groups should be checked.
- Cleaned up description of Bleichenbacher/Klima attack defenses. - Cleaned up description of Bleichenbacher/Klima attack defenses.
- Tighter checking of EncryptedPreMasterSecret version numbers. - Tighter checking of EncryptedPreMasterSecret version numbers.
- Stronger language about when alerts MUST be sent. - Stronger language about when alerts MUST be sent.
- Added an Implementation Pitfalls sections - Added an Implementation Pitfalls sections
- Harmonized the requirement to send an empty certificate list - Harmonized the requirement to send an empty certificate list
after certificate_request even when no certs are available. after certificate_request even when no certs are available.
- Made the verify_data length depend on the cipher suite. - Made the verify_data length depend on the cipher suite.
- 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.
- The usual clarifications and editorial work.
2. Goals 2. Goals
The goals of TLS Protocol, in order of their priority, are as The goals of TLS Protocol, in order of their priority, are as
follows: follows:
1. Cryptographic security: TLS should be used to establish a secure 1. Cryptographic security: TLS should be used to establish a secure
connection between two parties. connection between two parties.
2. Interoperability: Independent programmers should be able to 2. Interoperability: Independent programmers should be able to
develop applications utilizing TLS that can successfully exchange develop applications utilizing TLS that can successfully exchange
skipping to change at page 96, line ? skipping to change at page 99, line ?
In DSS, the 20 bytes of the SHA-1 hash are run directly through the In DSS, the 20 bytes of the SHA-1 hash are run directly through the
Digital Signing Algorithm with no additional hashing. This produces Digital Signing Algorithm with no additional hashing. This produces
two values, r and s. The DSS signature is an opaque vector, as above, two values, r and s. The DSS signature is an opaque vector, as above,
the contents of which are the DER encoding of: the contents of which are the DER encoding of:
Dss-Sig-Value ::= SEQUENCE { Dss-Sig-Value ::= SEQUENCE {
r INTEGER, r INTEGER,
s INTEGER s INTEGER
} }
Note: In current terminology, DSA refers to the Digital Signature
Algorithm and DSS refers to the NIST standard. For historical
reasons, this document uses DSS and DSA interchangeably
to refer to the DSA algorithm, as was done in SSLv3.
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.
In AEAD encryption, the plaintext is simultaneously encrypted and In AEAD encryption, the plaintext is simultaneously encrypted and
skipping to change at page 96, line ? skipping to change at page 99, line ?
is based on a hash function. Other cipher suites MAY define their own is based on a hash function. Other cipher suites MAY define their own
MAC constructions, if needed. MAC constructions, if needed.
In addition, a construction is required to do expansion of secrets In addition, a construction is required to do expansion of secrets
into blocks of data for the purposes of key generation or validation. into blocks of data for the purposes of key generation or validation.
This pseudo-random function (PRF) takes as input a secret, a seed, This pseudo-random function (PRF) takes as input a secret, a seed,
and an identifying label and produces an output of arbitrary length. and an identifying label and produces an output of arbitrary length.
In this section, we define one PRF, based on HMAC. This PRF with the In this section, we define one PRF, based on HMAC. This PRF with the
SHA-256 hash function is used for all cipher suites defined in this SHA-256 hash function is used for all cipher suites defined in this
document and in TLS documents published prior to this document. New document and in TLS documents published prior to this document when
cipher suites MUST explicitly specify a PRF and in general SHOULD use TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a
the TLS PRF with SHA-256 or a stronger standard hash function. PRF and in general SHOULD use the TLS PRF with SHA-256 or a stronger
standard hash function.
First, we define a data expansion function, P_hash(secret, data) that First, we define a data expansion function, P_hash(secret, data) that
uses a single hash function to expand a secret and seed into an uses a single hash function to expand a secret and seed into an
arbitrary quantity of output: arbitrary quantity of output:
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + ... HMAC_hash(secret, A(3) + seed) + ...
Where + indicates concatenation. Where + indicates concatenation.
skipping to change at page 96, line ? skipping to change at page 99, line ?
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + ... HMAC_hash(secret, A(3) + seed) + ...
Where + indicates concatenation. Where + indicates concatenation.
A() is defined as: A() is defined as:
A(0) = seed A(0) = seed
A(i) = HMAC_hash(secret, A(i-1)) A(i) = HMAC_hash(secret, A(i-1))
P_hash can be iterated as many times as is necessary to produce the P_hash can be iterated as many times as is necessary to produce the
required quantity of data. For example, if P_SHA-1 is being used to required quantity of data. For example, if P_SHA-1 is being used to
create 64 bytes of data, it will have to be iterated 4 times (through create 64 bytes of data, it will have to be iterated 4 times (through
A(4)), creating 80 bytes of output data; the last 16 bytes of the A(4)), creating 80 bytes of output data; the last 16 bytes of the
final iteration will then be discarded, leaving 64 bytes of output final iteration will then be discarded, leaving 64 bytes of output
data. data.
TLS's PRF is created by applying P_hash to the secret S as: TLS's PRF is created by applying P_hash to the secret as:
PRF(secret, label, seed) = P_<hash>(secret, label + seed) PRF(secret, label, seed) = P_<hash>(secret, label + seed)
The label is an ASCII string. It should be included in the exact form The label is an ASCII string. It should be included in the exact form
it is given without a length byte or trailing null character. For it is given without a length byte or trailing null character. For
example, the label "slithy toves" would be processed by hashing the example, the label "slithy toves" would be processed by hashing the
following bytes: following bytes:
73 6C 69 74 68 79 20 74 6F 76 65 73 73 6C 69 74 68 79 20 74 6F 76 65 73
skipping to change at page 96, line ? skipping to change at page 99, line ?
Four record protocol clients are described in this document: the Four record protocol clients are described in this document: the
handshake protocol, the alert protocol, the change cipher spec handshake protocol, the alert protocol, the change cipher spec
protocol, and the application data protocol. In order to allow protocol, and the application data protocol. In order to allow
extension of the TLS protocol, additional record types can be extension of the TLS protocol, additional record types can be
supported by the record protocol. New record type values are assigned supported by the record protocol. New record type values are assigned
by IANA as described in Section 12. by IANA 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 a 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. Note that because the
type and length of a record are not protected by encryption, care type and length of a record are not protected by encryption, care
SHOULD be taken to minimize the value of traffic analysis of these SHOULD be taken to minimize the value of traffic analysis of these
values. values.
6.1. Connection States 6.1. Connection States
A TLS connection state is the operating environment of the TLS Record A TLS connection state is the operating environment of the TLS Record
skipping to change at page 96, line ? skipping to change at page 99, line ?
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.
bulk encryption algorithm bulk encryption algorithm
An algorithm to be used for bulk encryption. This specification An algorithm to be used for bulk encryption. This specification
includes the key size of this algorithm, how much of that key is includes the key size of this algorithm, how much of that key is
secret, whether it is a block, stream, or AEAD cipher, and the secret, whether it is a block, stream, or AEAD cipher, and the
block size of the cipher (if appropriate). block size and fixed initialization vector size of the cipher (if
appropriate).
MAC algorithm MAC algorithm
An algorithm to be used for message authentication. This An algorithm to be used for message authentication. This
specification includes the size of the value returned by the MAC specification includes the size of the value returned by the MAC
algorithm. algorithm.
compression algorithm compression algorithm
An algorithm to be used for data compression. This specification An algorithm to be used for data compression. This specification
must include all information the algorithm requires to do must include all information the algorithm requires to do
compression. compression.
skipping to change at page 96, line ? skipping to change at page 99, line ?
client random client random
A 32-byte value provided by the client. A 32-byte value provided by the client.
server random server random
A 32-byte value provided by the server. A 32-byte value provided by the server.
These parameters are defined in the presentation language as: These parameters are defined in the presentation language as:
enum { server, client } ConnectionEnd; enum { server, client } ConnectionEnd;
enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm; enum { null, rc4, rc2, des, 3des, idea, aes }
BulkCipherAlgorithm;
enum { stream, block, aead } CipherType; enum { stream, block, aead } CipherType;
enum { null, md5, sha, sha256, sha384, sha512} MACAlgorithm; enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384,
hmac_sha512} MACAlgorithm;
/* The use of "sha" above is historical and denotes SHA-1 */ /* The use of "sha" above is historical and denotes SHA-1 */
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
/* The algorithms specified in CompressionMethod, /* The algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */ BulkCipherAlgorithm, and MACAlgorithm may be added to. */
struct { struct {
ConnectionEnd entity; ConnectionEnd entity;
skipping to change at page 96, line ? skipping to change at page 99, line ?
uint8 mac_length; uint8 mac_length;
uint8 mac_key_length; uint8 mac_key_length;
uint8 verify_data_length; uint8 verify_data_length;
CompressionMethod compression_algorithm; CompressionMethod compression_algorithm;
opaque master_secret[48]; opaque master_secret[48];
opaque client_random[32]; opaque client_random[32];
opaque server_random[32]; opaque server_random[32];
} SecurityParameters; } SecurityParameters;
The record layer will use the security parameters to generate the The record layer will use the security parameters to generate the
following four items: following six items:
client write MAC secret client write MAC secret
server write MAC secret server write MAC secret
client write key client write key
server write key server write key
client write IV
server write IV
The client write parameters are used by the server when receiving and The client write parameters are used by the server when receiving and
processing records and vice-versa. The algorithm used for generating processing records and vice-versa. The algorithm used for generating
these items from the security parameters is described in Section 6.3. these items from the security parameters is described in Section 6.3.
Once the security parameters have been set and the keys have been Once the security parameters have been set and the keys have been
generated, the connection states can be instantiated by making them generated, the connection states can be instantiated by making them
the current states. These current states MUST be updated for each the current states. These current states MUST be updated for each
record processed. Each connection state includes the following record processed. Each connection state includes the following
elements: elements:
skipping to change at page 96, line ? skipping to change at page 99, line ?
MAC(MAC_write_secret, seq_num + TLSCompressed.type + MAC(MAC_write_secret, seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length + TLSCompressed.version + TLSCompressed.length +
TLSCompressed.fragment); TLSCompressed.fragment);
where "+" denotes concatenation. where "+" denotes concatenation.
seq_num seq_num
The sequence number for this record. The sequence number for this record.
hash MAC
The hashing algorithm specified by The MAC algorithm specified by SecurityParameters.mac_algorithm.
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 CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
consists of the identity operation (i.e., the data is not encrypted, consists of the identity operation (i.e., the data is not encrypted,
and the MAC size is zero, implying that no MAC is used). and the MAC size is zero, implying that no MAC is used).
TLSCiphertext.length is TLSCompressed.length plus TLSCiphertext.length is TLSCompressed.length plus
SecurityParameters.mac_length. SecurityParameters.mac_length.
skipping to change at page 96, line ? skipping to change at page 99, line ?
indicate padding errors. indicate padding errors.
padding_length padding_length
The padding length MUST be such that the total size of the The padding length MUST be such that the total size of the
GenericBlockCipher structure is a multiple of the cipher's block GenericBlockCipher structure is a multiple of the cipher's block
length. Legal values range from zero to 255, inclusive. This length. Legal values range from zero to 255, inclusive. This
length specifies the length of the padding field exclusive of the length specifies the length of the padding field exclusive of the
padding_length field itself. padding_length field itself.
The encrypted data length (TLSCiphertext.length) is one more than the The encrypted data length (TLSCiphertext.length) is one more than the
sum of one more than the sum of SecurityParameters.block_length, sum of SecurityParameters.block_length, TLSCompressed.length,
TLSCompressed.length, SecurityParameters.mac_length, and SecurityParameters.mac_length, and padding_length.
padding_length.
Example: If the block length is 8 bytes, the content length Example: If the block length is 8 bytes, the content length
(TLSCompressed.length) is 61 bytes, and the MAC length is 20 (TLSCompressed.length) is 61 bytes, and the MAC length is 20
bytes, then the length before padding is 82 bytes (this does bytes, then the length before padding is 82 bytes (this does
not include the IV. Thus, the padding length modulo 8 must be not include the IV. Thus, the padding length modulo 8 must be
equal to 6 in order to make the total length an even multiple equal to 6 in order to make the total length an even multiple
of 8 bytes (the block length). The padding length can be 6, of 8 bytes (the block length). The padding length can be 6,
14, 22, and so on, through 254. If the padding length were the 14, 22, and so on, through 254. If the padding length were the
minimum necessary, 6, the padding would be 6 bytes, each minimum necessary, 6, the padding would be 6 bytes, each
containing the value 6. Thus, the last 8 octets of the containing the value 6. Thus, the last 8 octets of the
skipping to change at page 96, line ? skipping to change at page 99, line ?
struct { struct {
opaque nonce_explicit[SecurityParameters.record_iv_length]; opaque nonce_explicit[SecurityParameters.record_iv_length];
aead-ciphered struct { aead-ciphered struct {
opaque content[TLSCompressed.length]; opaque content[TLSCompressed.length];
}; };
} GenericAEADCipher; } GenericAEADCipher;
AEAD ciphers take as input a single key, a nonce, a plaintext, and AEAD ciphers take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as "additional data" to be included in the authentication check, as
described in Section 2.1 of [AEAD]. These inputs are as follows. described in Section 2.1 of [AEAD]. The key is either the
client_write_key or the server_write_key. No MAC key is used.
The key is either the client_write_key or the server_write_key. No
MAC key is used.
Each AEAD cipher suite has to specify how the nonce supplied to the Each AEAD cipher suite has to specify how the nonce supplied to the
AEAD operation is constructed, and what is the length of the AEAD operation is constructed, and what is the length of the
GenericAEADCipher.nonce_explicit part. In many cases, it is GenericAEADCipher.nonce_explicit part. In many cases, it is
appropriate to use the partially implicit nonce technique described appropriate to use the partially implicit nonce technique described
in Section 3.2.1 of [AEAD]; in this case, the implicit part SHOULD be in Section 3.2.1 of [AEAD]; in this case, the implicit part SHOULD be
derived from key_block as client_write_iv and server_write_iv (as derived from key_block as client_write_iv and server_write_iv (as
described in Section 6.3), and the explicit part is included in described in Section 6.3), and the explicit part is included in
GenericAEAEDCipher.nonce_explicit. GenericAEAEDCipher.nonce_explicit.
skipping to change at page 96, line ? skipping to change at page 99, line ?
error is detected, the detecting party sends a message to the other error is detected, the detecting party sends a message to the other
party. Upon transmission or receipt of a fatal alert message, both party. Upon transmission or receipt of a fatal alert message, both
parties immediately close the connection. Servers and clients MUST parties immediately close the connection. Servers and clients MUST
forget any session-identifiers, keys, and secrets associated with a forget any session-identifiers, keys, and secrets associated with a
failed connection. Thus, any connection terminated with a fatal alert failed connection. Thus, any connection terminated with a fatal alert
MUST NOT be resumed. MUST NOT be resumed.
Whenever an implementation encounters a condition which is defined as Whenever an implementation encounters a condition which is defined as
a fatal alert, it MUST send the appropriate alert prior to closing a fatal alert, it MUST send the appropriate alert prior to closing
the connection. In cases where an implementation chooses to send an the connection. In cases where an implementation chooses to send an
alert which MAY be a warning alert but intends to close the alert which may be a warning alert but intends to close the
connection immediately afterwards, it MUST send that alert at the connection immediately afterwards, it MUST send that alert at the
fatal alert level. fatal alert level.
If an alert with a level of warning is sent and received, generally If an alert with a level of warning is sent and received, generally
the connection can continue normally. If the receiving party decides the connection can continue normally. If the receiving party decides
not to proceed with the connection (e.g., after having received a not to proceed with the connection (e.g., after having received a
no_renegotiation alert that it is not willing to accept), it SHOULD no_renegotiation alert that it is not willing to accept), it SHOULD
send a fatal alert to terminate the connection. send a fatal alert to terminate the connection.
The following error alerts are defined: The following error alerts are defined:
skipping to change at page 96, line ? skipping to change at page 99, line ?
certificate_expired certificate_expired
A certificate has expired or is not currently valid. A certificate has expired or is not currently valid.
certificate_unknown certificate_unknown
Some other (unspecified) issue arose in processing the Some other (unspecified) issue arose in processing the
certificate, rendering it unacceptable. certificate, rendering it unacceptable.
illegal_parameter illegal_parameter
A field in the handshake was out of range or inconsistent with A field in the handshake was out of range or inconsistent with
other fields. This is always fatal. other fields. This message is always fatal.
unknown_ca unknown_ca
A valid certificate chain or partial chain was received, but the A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not certificate was not accepted because the CA certificate could not
be located or couldn't be matched with a known, trusted CA. This be located or couldn't be matched with a known, trusted CA. This
message is always fatal. message is always fatal.
access_denied access_denied
A valid certificate was received, but when access control was A valid certificate was received, but when access control was
applied, the sender decided not to proceed with negotiation. applied, the sender decided not to proceed with negotiation.
skipping to change at page 96, line ? skipping to change at page 99, line ?
} 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 Hello
Request message, which can be sent at any time, but which should be Request message, which can be sent at any time, but which SHOULD be
ignored by the client if it arrives in the middle of a handshake. ignored by the client if it arrives in the middle of a handshake.
New Handshake message types are assigned by IANA as described in New Handshake message types are assigned by IANA as described in
Section 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
skipping to change at page 96, line ? skipping to change at page 99, line ?
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 (highest valued) version supported by the client. For this
version of the specification, the version will be 3.3 (See version of the specification, the version will be 3.3 (See
Appendix E for details about backward compatibility). Appendix E for 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 should be empty if no session_id is available, or it This field is empty if no session_id is available, or it the
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 This is a list of the compression methods supported by the
skipping to change at page 96, line ? skipping to change at page 99, line ?
client_hello_extension_list client_hello_extension_list
Clients MAY request extended functionality from servers by Clients MAY request extended functionality from servers by
sending data in the client_hello_extension_list. Here the new sending data in the client_hello_extension_list. Here the new
"client_hello_extension_list" field contains a list of "client_hello_extension_list" field contains a list of
extensions. The actual "Extension" format is defined in Section extensions. The actual "Extension" format is defined in Section
7.4.1.4. 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 that supports the client MAY abort the handshake. A server that supports the
extensions mechanism MUST accept only client hello messages in either extensions mechanism MUST accept client hello messages in either the
the original (TLS 1.0/TLS 1.1) ClientHello or the extended original (TLS 1.0/TLS 1.1) ClientHello or the extended ClientHello
ClientHello format defined in this document, and (as for all other format defined in this document, and (as for all other messages) MUST
messages) MUST check that the amount of data in the message precisely check that the amount of data in the message precisely matches one of
matches one of these formats; if not then it MUST send a fatal these formats; if not then it MUST send a fatal "decode_error" alert.
"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 server
hello message. Any other handshake message returned by the server hello message. Any other handshake message returned by the server
except for a hello request is treated as a fatal error. except for a hello request 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 client hello
message when it was able to find an acceptable set of algorithms. message when it was able to find an acceptable set of algorithms.
skipping to change at page 96, line ? skipping to change at page 99, line ?
7.4.1.4 Hello Extensions 7.4.1.4 Hello Extensions
The extension format is: The extension format is:
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
enum { enum {
signature_hash_types(TBD-BY-IANA), (65535) signature_hash_algorithms(TBD-BY-IANA), (65535)
} ExtensionType; } ExtensionType;
Here: Here:
- "extension_type" identifies the particular extension type. - "extension_type" identifies the particular extension type.
- "extension_data" contains information specific to the particular - "extension_data" contains information specific to the particular
extension type. extension type.
The 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 - Some cases where a server does not agree to an extension are
error error conditions, and some simply a refusal to support a
conditions, and some simply a refusal to support a particular particular feature. In general error alerts should be used for
feature. In general error alerts should be used for the former, the former, and a field in the server extension response for the
and a field in the server extension response for the latter. latter.
- Extensions should as far as possible be designed to prevent any - Extensions should as far as possible be designed to prevent any
attack that forces use (or non-use) of a particular feature by attack that forces use (or non-use) of a particular feature by
manipulation of handshake messages. This principle should be manipulation of handshake messages. This principle should be
followed regardless of whether the feature is believed to cause a followed regardless of whether the feature is believed to cause a
security problem. security problem.
Often the fact that the extension fields are included in the Often the fact that the extension fields are included in the
inputs to the Finished message hashes will be sufficient, but inputs to the Finished message hashes will be sufficient, but
extreme care is needed when the extension changes the meaning of extreme care is needed when the extension changes the meaning of
skipping to change at page 96, line ? skipping to change at page 99, line ?
- It would be technically possible to use extensions to change - It would be technically possible to use extensions to change
major aspects of the design of TLS; for example the design of major aspects of the design of TLS; for example the design of
cipher suite negotiation. This is not recommended; it would be cipher suite negotiation. This is not recommended; it would be
more appropriate to define a new version of TLS - particularly more appropriate to define a new version of TLS - particularly
since the TLS handshake algorithms have specific protection since the TLS handshake algorithms have specific protection
against version rollback attacks based on the version number, and against version rollback attacks based on the version number, and
the possibility of version rollback should be a significant the possibility of version rollback should be a significant
consideration in any major design change. consideration in any major design change.
7.4.1.4.1 Cert Hash Types 7.4.1.4.1 Signature Hash Algorithms
The client MAY use the "signature_hash_types" to indicate to the The client MAY use the "signature_hash_algorithms" to indicate to the
server which hash functions may be used in digital signatures. server which signature/hash algorithm pairs may be used in digital
The "extension_data" field of this extension contains: signatures. The "extension_data" field of this extension contains a
"supported_signature_algorithms" value.
enum{ enum{
md5(0), sha1(1), sha256(2), sha384(3), sha512(4), (255) none(0), md5(1), sha1(2), sha256(3), sha384(4),
} HashType; sha512(5), (255)
} HashAlgorithm;
struct { enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm;
HashType types<1..255>;
} SignatureHashTypes;
These values indicate support for MD5 [MD5], SHA-1, SHA-256, SHA-384, struct {
and SHA-512 [SHA] respectively. The server MUST NOT send this HashAlgorithm hash;
extension. The values are indicated in descending order of SignatureAlgorithm signature;
preference. } SignatureAndHashAlgorithm;
Clients SHOULD send this extension if they support any algorithm SignatureAndHashAlgorithm
other than SHA-1. If this extension is not used, servers SHOULD supported_signature_algorithms<2..2^16-1>;
assume that the client supports only SHA-1. Note: this is a change
from TLS 1.1 where there are no explicit rules but as a practical Each SignatureAndHashAlgorithm value lists a single digest/signature
matter one can assume that the peer supports MD5 and SHA-1. pair which the client is willing to verify. The values are indicated
in descending order of preference.
Note: Because not all signature algorithms and hash algorithms may be
accepted by an implementation (e.g., DSA with SHA-1, but not
SHA-256), algorithms here are listed in pairs.
hash
This field indicates the hash algorithm which may be used. The
values indicate support for undigested data, MD5 [MD5], SHA-1,
SHA-256, SHA-384, and SHA-512 [SHA] respectively. The "none"
value is provided for future extensibility, in case of a
signature algorithm which does not require hashing before
signing.
signature
This field indicates the signature algorithm which may be used.
The values indicate anonymous signatures, RSA [PKCS1] and DSA
[DSS] respectively. The "anonymous" value is meaningless in this
context but used later in the specification. It MUST NOT appear
in this extension.
The semantics of this extension are somewhat complicated because the
cipher suite indicates permissible signature algorithms but not
digest algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate
rules.
Clients SHOULD send this extension if they support any digest
algorithm other than SHA-1. If this extension is not used, servers
SHOULD assume that the client supports only SHA-1. Note: this is a
change from TLS 1.1 where there are no explicit rules but as a
practical matter one can assume that the peer supports MD5 and SHA-1.
Servers MUST NOT send 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 whenever the agreed-upon key
exchange method uses certificates for authentication (this exchange method uses certificates for authentication (this
includes all key exchange methods defined in this document except includes all key exchange methods defined in this document except
DH_anon). This message will always immediately follow the server DH_anon). This message will always immediately follow the server
hello message. hello message.
Meaning of this message: Meaning of this message:
The certificate type MUST be appropriate for the selected cipher This message conveys the server's certificate to the client. The
suite's key exchange algorithm, and is generally an X.509v3 certificate MUST be appropriate for the negotiated cipher suite's
certificate. It MUST contain a key that matches the key exchange key exchange algorithm, and any negotiated extensions.
method, as follows. Unless otherwise specified, the signing
algorithm for the certificate MUST be the same as the algorithm
for the certificate key. Unless otherwise specified, the public
key MAY be of any length.
Key Exchange Algorithm Certificate Key Type
RSA RSA public key; the certificate MUST
allow the key to be used for encryption.
DHE_DSS DSS public key.
DHE_RSA RSA public key that can be used for
signing.
DH_DSS Diffie-Hellman key. The algorithm used
to sign the certificate MUST be DSS.
DH_RSA Diffie-Hellman key. The algorithm used
to sign the certificate MUST be RSA.
All certificate profiles and key and cryptographic formats are
defined by the IETF PKIX working group [PKIX]. When a key usage
extension is present, the digitalSignature bit MUST be set for the
key to be eligible for signing, as described above, and the
keyEncipherment bit MUST be present to allow encryption, as described
above. The keyAgreement bit must be set on Diffie-Hellman
certificates.
As CipherSuites that specify new key exchange methods are specified
for the TLS Protocol, they will imply certificate format and the
required encoded keying information.
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 X.509v3 certificates. The sender's
certificate must come first in the list. Each following This is a sequence (chain) of certificates. The sender's
certificate must directly certify the one preceding it. Because certificate MUST come first in the list. Each following
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 independently, the self-signed certificate that specifies the
root certificate authority may optionally be omitted from the root certificate authority MAY optionally be omitted from the
chain, under the assumption that the remote end must already chain, under the assumption that the remote end must already
possess it in order to validate it in any case. possess it in order to 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 vector because PKCS #6 [PKCS6] extended certificates are not
used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making
the task of parsing the list more difficult. the task of parsing the list more difficult.
The following rules apply to the certificates sent by the server:
- The certificate type MUST be X.509v3, unless explicitly
negotiated otherwise (e.g., [TLSPGP]).
- The certificate's public key (and associated restrictions)
MUST be compatible with the selected key exchange
algorithm.
Key Exchange Alg. Certificate Key Type
RSA RSA public key; the certificate MUST
RSA_PSK allow the key to be used for encryption
(the keyEncipherment bit MUST be set
if the key usage extension is present).
Note: RSA_PSK is defined in [TLSPSK].
DHE_RSA RSA public key; the certificate MUST
ECDHE_RSA allow the key to be used for signing
(the digitalSignature bit MUST be set
if the key usage extension is present)
with the signature scheme and hash
algorithm that will be employed in the
server key exchange message.
DHE_DSS DSA public key; the certificate MUST
allow the key to be used for signing with
the hash algorithm that will be employed
in the server key exchange message.
DH_DSS Diffie-Hellman public key; the
DH_RSA keyAgreement bit MUST be set if the
key usage extension is present.
ECDH_ECDSA ECDH-capable public key; the public key
ECDH_RSA MUST use a curve and point format supported
by the client, as described in [TLSECC].
ECDHE_ECDSA ECDSA-capable public key; the certificate
MUST allow the key to be used for signing
with the hash algorithm that will be
employed in the server key exchange
message. The public key MUST use a curve
and point format supported by the client,
as described in [TLSECC].
- The "server_name" and "trusted_ca_keys" extensions
[4366bis] are used to guide certificate selection.
If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a
digest/signature algorithm pair that appears in that extension. Note
that this implies that a certificate containing a key for one
signature algorithm MAY be signed using a different signature
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
same. Note that this also implies that the DH_DS, DH_RSA,
ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
algorithm used to sign the certificate. Fixed DH certificates MAY be
signed with any digest/signature algorithm pair appearing in the
extension. The naming is historical.
If no "signature_algorithms" extension is present, the end-entity
certificate MUST be signed as follows:
Key Exchange Alg. Signature Algorithm Used by Issuer
RSA RSA (RSASSA-PKCS1-v1_5)
DHE_RSA
DH_RSA
RSA_PSK
ECDH_RSA
ECDHE_RSA
DHE_DSS DSA
DH_DSS
ECDH_ECDSA ECDSA
ECDHE_ECDSA
If the server has multiple certificates, it chooses one of them based
on the above-mentioned criteria (in addition to other criteria, such
as transport layer endpoint, local configuration and preferences,
etc.).
Note that there are certificates that use algorithms and/or algorithm
combinations that cannot be currently used with TLS. For example, a
certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
SubjectPublicKeyInfo) cannot be used because TLS defines no
corresponding signature algorithm.
As CipherSuites that specify new key exchange methods are specified
for the TLS Protocol, they will imply certificate format and the
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 This message will be sent immediately after the server
certificate message (or the server hello message, if this is an certificate message (or the server hello message, if this is an
anonymous negotiation). anonymous negotiation).
The server key exchange message is sent by the server only when The server key exchange message is sent by the server only when
the server certificate message (if sent) does not contain enough the server certificate message (if sent) does not contain enough
data to allow the client to exchange a premaster secret. This is data to allow the client to exchange a premaster secret. This is
skipping to change at page 96, line ? skipping to change at page 99, line ?
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 server key exchange message for the
following key exchange methods: following key exchange methods:
RSA RSA
DH_DSS DH_DSS
DH_RSA DH_RSA
Meaning of this message: Meaning of this message:
This message conveys cryptographic information to allow the This message conveys cryptographic information to allow the
client to communicate the premaster secret: a Diffie-Hellman client to communicate the premaster secret: a Diffie-Hellman
public key with which the client can complete a key exchange public key with which the client can complete a key exchange
(with the result being the premaster secret) or a public key for (with the result being the premaster secret) or a public key for
some other algorithm. some other algorithm.
As additional CipherSuites are defined for TLS that include new key
exchange algorithms, the server key exchange message will be sent if
and only if the certificate type associated with the key exchange
algorithm does not provide enough information for the client to
exchange a premaster secret.
If the client has offered the SignatureHashTypes extension, the hash
function MUST be one of those listed in that extension. Otherwise it
MUST be assumed that only SHA-1 is supported.
If the SignatureAlgorithm being used to sign the ServerKeyExchange
message is DSA, the hash algorithm MUST be SHA-1. [TODO: This is
incorrect. What it should say is that it must be specified in the
SPKI of the cert. However, I don't believe this is actually defined.
Rather, the DSA certs just say dsa. We need new certs to say
dsaWithSHAXXX.]
If the SignatureAlgorithm is RSA, then any hash function accepted by
the client MAY be used. The selected hash function MUST be indicated
in the digest_algorithm field of the signature structure.
The hash algorithm is denoted Hash below. Hash.length is the length
of the output of that algorithm.
Structure of this message: Structure of this message:
enum { diffie_hellman, rsa} KeyExchangeAlgorithm; enum { diffie_hellman, rsa} KeyExchangeAlgorithm;
struct { struct {
opaque dh_p<1..2^16-1>; opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>; opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>; opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */ } ServerDHParams; /* Ephemeral DH parameters */
dh_p dh_p
skipping to change at page 96, line ? skipping to change at page 99, line ?
The server's key exchange parameters. The server's key exchange parameters.
signed_params signed_params
For non-anonymous key exchanges, a hash of the corresponding For non-anonymous key exchanges, a hash of the corresponding
params value, with the signature appropriate to that hash params value, with the signature appropriate to that hash
applied. applied.
hash hash
Hash(ClientHello.random + ServerHello.random + ServerParams) Hash(ClientHello.random + ServerHello.random + ServerParams)
sha_hash
SHA1(ClientHello.random + ServerHello.random + ServerParams)
enum { anonymous, rsa, dsa } SignatureAlgorithm;
struct { struct {
select (SignatureAlgorithm) { select (SignatureAlgorithm) {
case anonymous: struct { }; case anonymous: struct { };
case rsa: case rsa:
HashType digest_algorithm; // NEW SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
digitally-signed struct { digitally-signed struct {
opaque hash[Hash.length]; opaque hash[Hash.length];
}; };
case dsa: case dsa:
digitally-signed struct { SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
opaque sha_hash[20]; digitally-signed struct {
}; opaque hash[Hash.length];
};
}; };
}; };
} Signature; } Signature;
If the client has offered the "signature_algorithms" extension, the
signature algorithm and digest algorithm MUST be a pair listed in
that extension. Note that there is a possibility for inconsistencies
here. For instance, the client might offer DHE_DSS key exchange but
omit any DSS pairs from its "signature_algorithms" extension. In
order to negotiate correctly, the server MUST check any candidate
cipher suites against the "signature_algorithms" extension before
selecting them. This is somewhat inelegant but is a compromise
designed to minimize changes to the original cipher suite design.
If no "signature_algorithms" extension is present, the server MUST
use SHA-1 as the hash algorithm.
In addition, the digest and signature algorithms MUST be compatible
with the key in the client's end-entity certificate. RSA keys MAY be
used with any permitted digest algorithm.
Because DSA signatures do not contain any secure indication of digest
algorithm, it must be unambiguous which digest algorithm is to be
used with any key. DSA keys specified with Object Identifier
1 2 840 10040 4 1 MUST only be used with SHA-1. Future revisions of
[PKIX] MAY define new object identifiers for DSA with other digest
algorithms.
The hash algorithm is denoted Hash below. Hash.length is the length
of the output of that algorithm.
As additional CipherSuites are defined for TLS that include new key
exchange algorithms, the server key exchange message will be sent if
and only if the certificate type associated with the key exchange
algorithm does not provide enough information for the client to
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 Server Key Exchange
message (if it is sent; otherwise, the Server Certificate message (if it is sent; otherwise, the Server 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), fortezza_dms_RESERVED(20), (255)
(255)
} ClientCertificateType; } ClientCertificateType;
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
ClientCertificateType certificate_types<1..2^8-1>; ClientCertificateType certificate_types<1..2^8-1>;
HashType certificate_hash<1..2^8-1>; SignatureAndHashAlgorithm
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
This field is a list of the types of certificates requested, A list of the types of certificate types which the client may
sorted in order of the server's preference. offer.
rsa_sign a certificate containing an RSA key
dss_sign a certificate containing a DSS key
rsa_fixed_dh a certificate containing a static DH key.
dss_fixed_dh a certificate containing a static DH key
certificate_types supported_signature_algorithms
A list of the types of certificate types which the client may A list of the digest/signature algorithm pairs that the server is
offer. able to verify, listed in descending order of preference.
rsa_sign a certificate containing an RSA key
dss_sign a certificate containing a DSS key
rsa_fixed_dh a certificate signed with RSA and containing
a static DH key.
dss_fixed_dh a certificate signed with DSS and containing
a static DH key
Certificate types rsa_sign and dss_sign SHOULD contain certificate_authorities
certificates signed with the same algorithm. However, this is A list of the distinguished names [X501] of acceptable
not required. This is a holdover from TLS 1.0 and 1.1. certificate_authorities, represented in DER-encoded format. These
distinguished names may specify a desired distinguished name for
a root CA or for a subordinate CA; thus, this message can be used
both to describe known roots and a desired authorization space.
If the certificate_authorities list is empty then the client MAY
send any certificate of the appropriate ClientCertificateType,
unless there is some external arrangement to the contrary.
certificate_hash The interaction of the certificate_types and
A list of acceptable hash algorithms to be used in signatures supported_signature_algorithms fields is somewhat complicated.
in both the client certificate and the CertificateVerify. certificate_types has been present in TLS since SSLv3, but was
These algorithms are listed in descending order of somewhat underspecified. Much of its functionality is superseded by
preference. supported_signature_algorithms. The following rules apply:
certificate_authorities - Any certificates provided by the client MUST be signed using
A list of the distinguished names [X501] of acceptable a digest/signature algorithm pair found in
certificateauthorities, represented in DER-encoded format. supported_signature_types.
These distinguished names may specify a desired distinguished
name for a root CA or for a subordinate CA; thus, this
message can be used both to describe known roots and a
desired authorization space. If the certificate_authorities
list is empty then the client MAY send any certificate of the
appropriate ClientCertificateType, unless there is some
external arrangement to the contrary.
New ClientCertificateType values are assigned by IANA as described in - The end-entity certificate provided by the client MUST contain a
Section 12. key which is compatible with certificate_types. If the key is a
signature key, it MUST be usable with some digest/signature
algorithm pair in supported_signature_types.
Note: Values listed as RESERVED may not be used. They were - For historical reasons, the names of some client certificate
used in SSLv3. types include the algorithm used to sign the certificate. For
example, in earlier versions of TLS, rsa_fixed_dh meant a
certificate signed with RSA and containing a static DH key. In
TLS 1.2, this functionality has been obsoleted by the
signature_types field, and the certificate type no longer
restricts the algorithm used to sign the certificate. For
example, if the server sends dss_fixed_dh certificate type and
{dss_sha1, rsa_sha1} signature types, the client MAY to reply
with a certificate containing a static DH key, signed with RSA-
SHA1.
New ClientCertificateType values are assigned by IANA as described in
Section 12.
Note: Values listed as RESERVED may not be used. They were used in
SSLv3.
Note: It is a fatal handshake_failure alert for an anonymous server to Note: It is a fatal handshake_failure alert for an anonymous server to
request client authentication. request client authentication.
7.4.5 Server hello done 7.4.5 Server hello done
When this message will be sent: When this message will be sent:
The server hello done message is sent by the server to indicate The server hello done message is sent by the server to indicate
the end of the server hello and associated messages. After the end of the server hello and associated messages. After
sending this message, the server will wait for a client response. sending this message, the server will wait for a client response.
skipping to change at page 96, line ? skipping to change at page 99, line ?
Structure of this message: Structure of this message:
struct { } ServerHelloDone; struct { } ServerHelloDone;
7.4.6. Client Certificate 7.4.6. Client Certificate
When this message will be sent: When this message will be sent:
This is the first message the client can send after receiving a This is the first message the client can send after receiving a
server hello done message. This message is only sent if the server hello done message. This message is only sent if the
server requests a certificate. If no suitable certificate is server requests a certificate. If no suitable certificate is
available, the client MUST send a certificate message containing available, the client SHOULD send a certificate message
no certificates. That is, the certificate_list structure has a containing no certificates. That is, the certificate_list
length of zero. If client authentication is required by the structure has a length of zero. If client authentication is
server for the handshake to continue, it may respond with a fatal required by the server for the handshake to continue, it may
handshake failure alert. Client certificates are sent using the respond with a fatal handshake failure alert. Client certificates
Certificate structure defined in Section 7.4.2. are sent using the Certificate structure defined in Section
7.4.2.
Note: When using a static Diffie-Hellman based key exchange method Meaning of this message:
(DH_DSS or DH_RSA), if client authentication is requested, the This message conveys the client's certificate to the server; the
Diffie-Hellman group and generator encoded in the client's server will use it when verifying the certificate verify message
certificate MUST match the server specified Diffie-Hellman (when the client authentication is based on signing), or
parameters if the client's parameters are to be used for the key calculate the premaster secret (for non-ephemeral Diffie-
exchange. Hellman). The certificate MUST be appropriate for the negotiated
cipher suite's key exchange algorithm, and any negotiated
extensions.
In particular:
- The certificate type MUST be X.509v3, unless explicitly
negotiated otherwise (e.g. [TLSPGP]).
- The certificate's public key (and associated restrictions)
has to be compatible with the certificate types listed in
CertificateRequest:
Client Cert. Type Certificate Key Type
rsa_sign RSA public key; the certificate MUST allow
the key to be used for signing with the
signature scheme and hash algorithm that
will be employed in the certificate verify
message.
dss_sign DSA public key; the certificate MUST allow
the key to be used for signing with the
hash algorithm that will be employed in
the certificate verify message.
ecdsa_sign ECDSA-capable public key; the certificate
MUST allow the key to be used for signing
with the hash algorithm that will be
employed in the certificate verify
message; the public key MUST use a
curve and point format supported by the
server.
rsa_fixed_dh Diffie-Hellman public key; MUST use
dss_fixed_dh the same parameters as server's key.
rsa_fixed_ecdh ECDH-capable public key; MUST use
ecdsa_fixed_ecdh the same curve as server's key, and
MUST use a point format supported by
- If the certificate_authorities list in the certificate
request message was non-empty, the certificate SHOULD be
issued by one of the listed CAs.
- The certificates MUST be signed using an acceptable digest/
signature algorithm pair, as described in Section 7.4.4. Note
that this relaxes the constraints on certificate signing
algorithms found in prior versions of TLS.
Note that as with the server certificate, there are certificates that
use algorithms/algorithm combinations that cannot be currently used
with TLS.
7.4.7. Client Key Exchange Message 7.4.7. Client Key Exchange Message
When this message will be sent: When this message will be sent:
This message is always sent by the client. It MUST immediately This message is always sent by the client. It MUST immediately follow
follow the client certificate message, if it is sent. Otherwise the client certificate message, if it is sent. Otherwise it MUST be
it MUST be the first message sent by the client after it receives the first message sent by the client after it receives the server
the server hello done message. hello done message.
Meaning of this message: Meaning of this message:
With this message, the premaster secret is set, either though
direct transmission of the RSA-encrypted secret, or by the With this message, the premaster secret is set, either though direct
transmission of Diffie-Hellman parameters that will allow each transmission of the RSA-encrypted secret, or by the transmission of
side to agree upon the same premaster secret. When the key Diffie-Hellman parameters that will allow each side to agree upon the
exchange method is DH_RSA or DH_DSS, client certification has same premaster secret. When the key exchange method is DH_RSA or
been requested, and the client was able to respond with a DH_DSS, client certification has been requested, and the client was
certificate that contained a Diffie-Hellman public key whose able to respond with a certificate that contained a Diffie-Hellman
parameters (group and generator) matched those specified by the public key whose parameters (group and generator) matched those
server in its certificate, this message MUST NOT contain any specified by the server in its certificate, this message MUST NOT
data. contain any data.
Structure of this message: Structure of this message:
The choice of messages depends on which key exchange method has The choice of messages depends on which key exchange method has been
been selected. See Section 7.4.3 for the KeyExchangeAlgorithm selected. See Section 7.4.3 for the KeyExchangeAlgorithm definition.
definition.
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret; case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic; case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys; } exchange_keys;
} 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
client generates a 48-byte premaster secret, encrypts it using generates a 48-byte premaster secret, encrypts it using the public
the public key from the server's certificate and sends the result key from the server's certificate and sends the result in an
in an encrypted premaster secret message. This structure is a encrypted premaster secret message. This structure is a variant of
variant of the client key exchange message and is not a message the client key exchange message and is not a message in itself.
in itself.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
opaque random[46]; opaque random[46];
} PreMasterSecret; } PreMasterSecret;
client_version client_version
The latest (newest) version supported by the client. This is
used to detect version roll-back attacks.
random The latest (newest) version supported by the client. This is
46 securely-generated random bytes. used to detect version roll-back attacks.
random
46 securely-generated random bytes.
struct { struct {
public-key-encrypted PreMasterSecret pre_master_secret; public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret; } EncryptedPreMasterSecret;
pre_master_secret
pre_master_secret This random value is generated by the client and is used to
This random value is generated by the client and is used to generate the master secret, as specified in Section 8.1.
generate the master secret, as specified in Section 8.1.
Note: The version number in the PreMasterSecret is the version offered Note: The version number in the PreMasterSecret is the version
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 version negotiated for the connection. This feature is designed
designed to prevent rollback attacks. Unfortunately, some to prevent rollback attacks. Unfortunately, some old
old implementations use the negotiated version instead and implementations use the negotiated version instead and therefore
therefore checking the version number may lead to failure to checking the version number may lead to failure to interoperate
interoperate with such incorrect client implementations. with such incorrect client implementations.
Client implementations MUST always send the correct version Client implementations MUST always send the correct version
number in PreMasterSecret. If ClientHello.client_version is number in PreMasterSecret. If ClientHello.client_version is TLS
TLS 1.1 or higher, server implementations MUST check the 1.1 or higher, server implementations MUST check the version
version number as described in the note below. If the version number as described in the note below. If the version number is
number is earlier than 1.0, server implementations SHOULD earlier than 1.0, server implementations SHOULD check the version
check the version number, but MAY have a configuration option number, but MAY have a configuration option to disable the check.
to disable the check. Note that if the check fails, the Note that if the check fails, the PreMasterSecret SHOULD be
PreMasterSecret SHOULD be randomized as described below. 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:
skipping to change at page 96, line ? skipping to change at page 99, line ?
except those containing fixed Diffie-Hellman parameters). When except those containing fixed Diffie-Hellman parameters). When
sent, it MUST immediately follow the client key exchange message. sent, it MUST immediately follow the client key exchange message.
Structure of this message: Structure of this message:
struct { struct {
Signature signature; Signature signature;
} CertificateVerify; } CertificateVerify;
The Signature type is defined in 7.4.3. The Signature type is defined in 7.4.3.
The hash function MUST be one of the algorithms offered in the
CertificateRequest message.
If the SignatureAlgorithm being used to sign the ServerKeyExchange
message is DSA, the hash function used MUST be SHA-1.
[TODO: This is incorrect. What it should say is that it must
be specified in the SPKI of the cert. However, I don't believe
this is actually defined. Rather, the DSA certs just say
dsa. We need new certs to say dsaWithSHAXXX]
If the SignatureAlgorithm is RSA, then any of the functions offered
by the server may be used. The selected hash function MUST be
indicated in the digest_algorithm field of the signature structure.
The hash algorithm is denoted Hash below. The hash algorithm is denoted Hash below.
CertificateVerify.signature.hash CertificateVerify.signature.hash = Hash(handshake_messages);
Hash(handshake_messages);
CertificateVerify.signature.sha_hash The digest and signature algorithms MUST be one of those present
SHA(handshake_messages); in the supported_signature_algorithms field of the
CertificateRequest message. In addition, the digest and signature
algorithms MUST be compatible with the key in the client's end-
entity certificate. RSA keys MAY be used with any permitted
digest algorithm.
Because DSA signatures do not contain any secure indication of
digest algorithm, it must be unambiguous which digest algorithm
is to be used with any key. DSA keys specified with Object
Identifier 1 2 840 10040 4 1 MUST only be used with SHA-1.
Future revisions of [PKIX] MAY define new object identifiers for
DSA with other digest algorithms.
Here handshake_messages refers to all handshake messages sent or Here handshake_messages refers to all handshake messages sent or
received starting at client hello up to but not including this received starting at client hello up to but not including this
message, including the type and length fields of the handshake message, including the type and length fields of the handshake
messages. This is the concatenation of all the Handshake structures messages. This is the concatenation of all the Handshake structures
as defined in 7.4 exchanged thus far. as defined in 7.4 exchanged thus far.
7.4.9. Finished 7.4.9. Finished
When this message will be sent: When this message will be sent:
skipping to change at page 96, line ? skipping to change at page 99, line ?
Hash denotes the negotiated hash used for the PRF. If a new Hash denotes the negotiated hash used for the PRF. If a new
PRF is defined, then this hash MUST be specified. PRF is defined, then this hash MUST be specified.
In previous versions of TLS, the verify_data was always 12 In previous versions of TLS, the verify_data was always 12
octets long. In the current version of TLS, it depends on the octets long. In the current version of TLS, it depends on the
cipher suite. Any cipher suite which does not explicitly cipher suite. Any cipher suite which does not explicitly
specify SecurityParameters.verify_data_length has a specify SecurityParameters.verify_data_length has a
SecurityParameters.verify_data_length equal to 12. This SecurityParameters.verify_data_length equal to 12. This
includes all existing cipher suites. Note that this includes all existing cipher suites. Note that this
representation has the same encoding as with previous representation has the same encoding as with previous
versions. versions. Future cipher suites MAY specify other lengths but
such length MUST be at least 12 bytes.
Future cipher suites MAY specify other lengths but such
length MUST be at least 12 bytes.
handshake_messages handshake_messages
All of the data from all messages in this handshake (not All of the data from all messages in this handshake (not
including any HelloRequest messages) up to but not including including any HelloRequest messages) up to but not including
this message. This is only data visible at the handshake this message. This is only data visible at the handshake
layer and does not include record layer headers. This is the layer and does not include record layer headers. This is the
concatenation of all the Handshake structures as defined in concatenation of all the Handshake structures as defined in
7.4, exchanged thus far. 7.4, exchanged thus far.
It is a fatal error if a finished message is not preceded by a change It is a fatal error if a finished message is not preceded by a change
skipping to change at page 96, line ? skipping to change at page 99, line ?
layer. layer.
11. Security Considerations 11. Security Considerations
Security issues are discussed throughout this memo, especially in Security issues are discussed throughout this memo, especially in
Appendices D, E, and F. Appendices D, E, and F.
12. IANA Considerations 12. IANA Considerations
This document uses several registries that were originally created in This document uses several registries that were originally created in
[RFC4346]. IANA is requested to update (has updated) these to
[TLS1.1]. IANA is requested to update (has updated) these to
reference this document. The registries and their allocation policies reference this document. The registries and their allocation policies
(unchanged from [TLS1.1]) are listed below. (unchanged from [TLS1.1]) are listed below.
o TLS ClientCertificateType Identifiers Registry: Future - TLS ClientCertificateType Identifiers Registry: Future
values in the range 0-63 (decimal) inclusive are assigned via values in the range 0-63 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values in the range 64-223 Standards Action [RFC2434]. Values in the range 64-223
(decimal) inclusive are assigned Specification Required (decimal) inclusive are assigned Specification Required
[RFC2434]. Values from 224-255 (decimal) inclusive are [RFC2434]. Values from 224-255 (decimal) inclusive are
reserved for Private Use [RFC2434]. reserved for Private Use [RFC2434].
o TLS Cipher Suite Registry: Future values with the first byte - TLS Cipher Suite Registry: Future values with the first byte
in the range 0-191 (decimal) inclusive are assigned via in the range 0-191 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values with the first byte in Standards Action [RFC2434]. Values with the first byte in
the range 192-254 (decimal) are assigned via Specification the range 192-254 (decimal) are assigned via Specification
Required [RFC2434]. Values with the first byte 255 (decimal) Required [RFC2434]. Values with the first byte 255 (decimal)
are reserved for Private Use [RFC2434]. are reserved for Private Use [RFC2434].
o TLS ContentType Registry: Future values are allocated via - TLS ContentType Registry: Future values are allocated via
Standards Action [RFC2434]. Standards Action [RFC2434].
o TLS Alert Registry: Future values are allocated via - TLS Alert Registry: Future values are allocated via
Standards Action [RFC2434]. Standards Action [RFC2434].
o 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:.
o TLS ExtensionType Registry: Future values are allocated - TLS ExtensionType Registry: Future values are allocated
via IETF Consensus [RFC2434] via IETF Consensus [RFC2434]
In addition, this document defines one new registry to be maintained In addition, this document defines one new registry to be maintained
by IANA: by IANA:
o TLS HashType Registry: The registry will be initially - TLS SignatureAlgorithm Registry: The registry will be initially
populated with the values described in Section 7.4.1.4.7. populated with the values described in Section 7.4.1.4.1.
Future values in the range 0-63 (decimal) inclusive are
assigned via Standards Action [RFC2434]. Values in the
range 64-223 (decimal) inclusive are assigned via
Specification Required [RFC2434]. Values from 224-255
(decimal) inclusive are reserved for Private Use [RFC2434].
- TLS HashAlgorithm Registry: The registry will be initially
populated with the values described in Section 7.4.1.4.1.
Future values in the range 0-63 (decimal) inclusive are Future values in the range 0-63 (decimal) inclusive are
assigned via Standards Action [RFC2434]. Values in the assigned via Standards Action [RFC2434]. Values in the
range 64-223 (decimal) inclusive are assigned via range 64-223 (decimal) inclusive are assigned via
Specification Required [RFC2434]. Values from 224-255 Specification Required [RFC2434]. Values from 224-255
(decimal) inclusive are reserved for Private Use [RFC2434]. (decimal) inclusive are reserved for Private Use [RFC2434].
This document defines one new TLS extension, cert_hash_type, which is This document defines one new TLS extension, cert_hash_type, which is
to be (has been) allocated value TBD-BY-IANA in the TLS ExtensionType to be (has been) allocated value TBD-BY-IANA in the TLS ExtensionType
registry. registry.
skipping to change at page 96, line ? skipping to change at page 99, line ?
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 { aead-ciphered struct {
opaque IV[SecurityParameters.iv_length]; opaque IV[SecurityParameters.record_iv_length];
opaque aead_output[AEADEncrypted.length]; opaque aead_output[AEADEncrypted.length];
} GenericAEADCipher; } GenericAEADCipher;
A.2. Change Cipher Specs Message A.2. Change Cipher Specs Message
struct { struct {
enum { change_cipher_spec(1), (255) } type; enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec; } ChangeCipherSpec;
A.3. Alert Messages A.3. Alert Messages
skipping to change at page 96, line ? skipping to change at page 99, line ?
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
}; };
} ServerHello; } ServerHello;
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
enum { enum {
signature_hash_types(TBD-BY-IANA), (65535) signature_hash_algorithms(TBD-BY-IANA), (65535)
} ExtensionType; } ExtensionType;
enum{
none(0), md5(1), sha1(2), sha256(3), sha384(4),
sha512(5), (255)
} HashAlgorithm;
enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm;
struct {
HashAlgorithm hash;
SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
SignatureAndHashAlgorithm
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 { diffie_hellman } KeyExchangeAlgorithm; enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
struct { struct {
opaque dh_p<1..2^16-1>; opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>; opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>; opaque dh_Ys<1..2^16-1>;
} ServerDHParams; } ServerDHParams;
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case diffie_hellman: case diffie_hellman:
ServerDHParams params; ServerDHParams params;
Signature signed_params; Signature signed_params;
} }
} ServerKeyExchange; } ServerKeyExchange;
enum { anonymous, rsa, dsa } SignatureAlgorithm;
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case diffie_hellman: case diffie_hellman:
ServerDHParams params; ServerDHParams params;
}; };
} ServerParams; } ServerParams;
struct { struct {
select (SignatureAlgorithm) { select (SignatureAlgorithm) {
case anonymous: struct { }; case anonymous: struct { };
case rsa: case rsa:
HashType digest_algorithm; // NEW SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
digitally-signed struct { digitally-signed struct {
opaque hash[Hash.length]; opaque hash[Hash.length];
}; };
case dsa: case dsa:
SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
digitally-signed struct { digitally-signed struct {
opaque sha_hash[20]; opaque hash[Hash.length];
}; };
}; };
}; };
} Signature; } Signature;
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 {
ClientCertificateType certificate_types<1..2^8-1>; ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest; } CertificateRequest;
skipping to change at page 96, line ? skipping to change at page 99, line ?
CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
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 };
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 ciphersuites MUST NOT be this mode therefore is of limited use: These ciphersuites MUST NOT be
used by TLS 1.2 implementations unless the application layer has 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_DES_CBC_SHA = { 0x00, 0x1A }; CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00, 0x1A };
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 };
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.
When SSLv3 and TLS 1.0 were designed, the United States restricted When SSLv3 and TLS 1.0 were designed, the United States restricted
skipping to change at page 96, line ? skipping to change at page 99, line ?
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
enum { server, client } ConnectionEnd; enum { server, client } ConnectionEnd;
enum { null, rc4, rc2, des, 3des, des40, aes, idea } enum { null, rc4, rc2, des, 3des, des40, aes, idea }
BulkCipherAlgorithm; BulkCipherAlgorithm;
enum { stream, block, aead } CipherType; enum { stream, block, aead } CipherType;
enum { null, md5, sha } MACAlgorithm; enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384,
hmac_sha512} MACAlgorithm;
/* The algorithms specified in CompressionMethod, /* The algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */ BulkCipherAlgorithm, and MACAlgorithm may be added to. */
struct { struct {
ConnectionEnd entity; ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm; BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type; CipherType cipher_type;
uint8 enc_key_length; uint8 enc_key_length;
uint8 block_length; uint8 block_length;
skipping to change at page 96, line ? skipping to change at page 99, line ?
Key Material Key Material
The number of bytes from the key_block that are used for The number of bytes from the key_block that are used for
generating the write keys. generating the write keys.
Expanded Key Material Expanded Key Material
The number of bytes actually fed into the encryption algorithm. The number of bytes actually fed into the encryption algorithm.
IV Size IV Size
The amount of data needed to be generated for the initialization The amount of data needed to be generated for the initialization
vector. Zero for stream ciphers; equal to the block size for vector. Zero for stream ciphers; equal to the block size for
block ciphers (this is equal to SecurityParameters.record_iv_length). block ciphers (this is equal to
SecurityParameters.record_iv_length).
Block Size Block Size
The amount of data a block cipher enciphers in one chunk; a The amount of data a block cipher enciphers in one chunk; a
block cipher running in CBC mode can only encrypt an even block cipher running in CBC mode can only encrypt an even
multiple of its block size. multiple of its block size.
Hash Hash Padding Hash Hash Padding
function Size Size function Size Size
NULL 0 0 NULL 0 0
MD5 16 48 MD5 16 48
skipping to change at page 96, line ? skipping to change at page 99, line ?
Implementation experience has shown that certain parts of earlier TLS Implementation experience has shown that certain parts of earlier TLS
specifications are not easy to understand, and have been a source of specifications are not easy to understand, and have been a source of
interoperability and security problems. Many of these areas have been interoperability and security problems. Many of these areas have been
clarified in this document, but this appendix contains a short list clarified in this document, but this appendix contains a short list
of the most important things that require special attention from of the most important things that require special attention from
implementors. implementors.
TLS protocol issues: TLS protocol issues:
o Do you correctly handle handshake messages that are fragmented - Do you correctly handle handshake messages that are fragmented
to multiple TLS records (see Section 6.2.1)? Including corner to multiple TLS records (see Section 6.2.1)? Including corner
cases like a ClientHello that is split to several small cases like a ClientHello that is split to several small
fragments? fragments?
o Do you ignore the TLS record layer version number in all TLS - Do you ignore the TLS record layer version number in all TLS
records before ServerHello (see Appendix E.1)? records before ServerHello (see Appendix E.1)?
o Do you handle TLS extensions in ClientHello correctly, - Do you handle TLS extensions in ClientHello correctly,
including omitting the extensions field completely? including omitting the extensions field completely?
o Do you support renegotiation, both client and server initiated? - Do you support renegotiation, both client and server initiated?
While renegotiation this is an optional feature, supporting While renegotiation this is an optional feature, supporting
it is highly recommended. it is highly recommended.
o When the server has requested a client certificate, but no - When the server has requested a client certificate, but no
suitable certificate is available, do you correctly send suitable certificate is available, do you correctly send
an empty Certificate message, instead of omitting the whole an empty Certificate message, instead of omitting the whole
message (see Section 7.4.6)? message (see Section 7.4.6)?
Cryptographic details: Cryptographic details:
o In RSA-encrypted Premaster Secret, do you correctly send and - In RSA-encrypted Premaster Secret, do you correctly send and
verify the version number? When an error is encountered, do verify the version number? When an error is encountered, do
you continue the handshake to avoid the Bleichenbacher you continue the handshake to avoid the Bleichenbacher
attack (see Section 7.4.7.1)? attack (see Section 7.4.7.1)?
o What countermeasures do you use to prevent timing attacks against - What countermeasures do you use to prevent timing attacks against
RSA decryption and signing operations (see Section 7.4.7.1)? RSA decryption and signing operations (see Section 7.4.7.1)?
o When verifying RSA signatures, do you accept both NULL and - When verifying RSA signatures, do you accept both NULL and
missing parameters (see Section 4.7)? Do you verify that the missing parameters (see Section 4.7)? Do you verify that the
RSA padding doesn't have additional data after the hash value? RSA padding doesn't have additional data after the hash value?
[FI06] [FI06]
o When using Diffie-Hellman key exchange, do you correctly strip - When using Diffie-Hellman key exchange, do you correctly strip
leading zero bytes from the negotiated key (see Section 8.1.2)? leading zero bytes from the negotiated key (see Section 8.1.2)?
o Does your TLS client check that the Diffie-Hellman parameters - Does your TLS client check that the Diffie-Hellman parameters
sent by the server are acceptable (see Section F.1.1.3)? sent by the server are acceptable (see Section F.1.1.3)?
o How do you generate unpredictable IVs for CBC mode ciphers - How do you generate unpredictable IVs for CBC mode ciphers
(see Section 6.2.3.2)? (see Section 6.2.3.2)?
o How do you address CBC mode timing attacks (Section 6.2.3.2)? - How do you address CBC mode timing attacks (Section 6.2.3.2)?
o Do you use a strong and, most importantly, properly seeded - Do you use a strong and, most importantly, properly seeded
random number generator (see Appendix D.1) for generating the random number generator (see Appendix D.1) for generating the
premaster secret (for RSA key exchange), Diffie-Hellman private premaster secret (for RSA key exchange), Diffie-Hellman private
values, the DSA "k" parameter, and other security-critical values, the DSA "k" parameter, and other security-critical
values? values?
Appendix E. Backward Compatibility Appendix E. Backward Compatibility
E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
Since there are various versions of TLS (1.0, 1.1, 1.2, and any Since there are various versions of TLS (1.0, 1.1, 1.2, and any
future versions) and SSL (2.0 and 3.0), means are needed to negotiate future versions) and SSL (2.0 and 3.0), means are needed to negotiate
skipping to change at page 96, line ? skipping to change at page 99, line ?
The general goal of the key exchange process is to create a The general goal of the key exchange process is to create a
pre_master_secret known to the communicating parties and not to pre_master_secret known to the communicating parties and not to
attackers. The pre_master_secret will be used to generate the attackers. The pre_master_secret will be used to generate the
master_secret (see Section 8.1). The master_secret is required to master_secret (see Section 8.1). The master_secret is required to
generate the finished messages, encryption keys, and MAC secrets (see generate the finished messages, encryption keys, and MAC secrets (see
Sections 7.4.9 and 6.3). By sending a correct finished message, Sections 7.4.9 and 6.3). By sending a correct finished message,
parties thus prove that they know the correct pre_master_secret. parties thus prove that they know the correct pre_master_secret.
F.1.1.1. Anonymous Key Exchange F.1.1.1. Anonymous Key Exchange
Completely anonymous sessions can be established using RSA or Diffie- Completely anonymous sessions can be established using Diffie-Hellman
Hellman for key exchange. With anonymous RSA, the client encrypts a for key exchange. The server's public parameters are contained in the
pre_master_secret with the server's uncertified public key extracted server key exchange message and the client's are sent in the client
from the server key exchange message. The result is sent in a client key exchange message. Eavesdroppers who do not know the private
key exchange message. Since eavesdroppers do not know the server's values should not be able to find the Diffie-Hellman result (i.e. the
private key, it will be infeasible for them to decode the pre_master_secret).
pre_master_secret.
With Diffie-Hellman, the server's public parameters are contained in
the server key exchange message and the client's are sent in the
client key exchange message. Eavesdroppers who do not know the
private values should not be able to find the Diffie-Hellman result
(i.e. the pre_master_secret).
Warning: Completely anonymous connections only provide protection Warning: Completely anonymous connections only provide protection
against passive eavesdropping. Unless an independent tamper- against passive eavesdropping. Unless an independent tamper-
proof channel is used to verify that the finished messages proof channel is used to verify that the finished messages
were not replaced by an attacker, server authentication is were not replaced by an attacker, server authentication is
required in environments where active man-in-the-middle required in environments where active man-in-the-middle
attacks are a concern. attacks are a concern.
F.1.1.2. RSA Key Exchange and Authentication F.1.1.2. RSA Key Exchange and Authentication
skipping to change at page 96, line ? skipping to change at page 99, line ?
The damage done by exposure of a private key can be limited by The damage done by exposure of a private key can be limited by
changing one's private key (and certificate) frequently. changing one's private key (and certificate) frequently.
After verifying the server's certificate, the client encrypts a After verifying the server's certificate, the client encrypts a
pre_master_secret with the server's public key. By successfully pre_master_secret with the server's public key. By successfully
decoding the pre_master_secret and producing a correct finished decoding the pre_master_secret and producing a correct finished
message, the server demonstrates that it knows the private key message, the server demonstrates that it knows the private key
corresponding to the server certificate. corresponding to the server certificate.
When RSA is used for key exchange, clients are authenticated using When RSA is used for key exchange, clients are authenticated using
the certificate verify message (see Section 7.4.9). The client signs the certificate verify message (see Section 7.4.8). The client signs
a value derived from the master_secret and all preceding handshake a value derived from all preceding handshake messages. These
messages. These handshake messages include the server certificate, handshake messages include the server certificate, which binds the
which binds the signature to the server, and ServerHello.random, signature to the server, and ServerHello.random, which binds the
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 DSS 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
skipping to change at page 96, line ? skipping to change at page 99, line ?
Small subgroup attacks are most easily avoided by using one of the Small subgroup attacks are most easily avoided by using one of the
DHE ciphersuites and generating a fresh DH private key (X) for each DHE ciphersuites and generating a fresh DH private key (X) for each
handshake. If a suitable base (such as 2) is chosen, g^X mod p can be handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
computed very quickly, therefore the performance cost is minimized. computed very quickly, therefore the performance cost is minimized.
Additionally, using a fresh key for each handshake provides Perfect Additionally, using a fresh key for each handshake provides Perfect
Forward Secrecy. Implementations SHOULD generate a new X for each Forward Secrecy. Implementations SHOULD generate a new X for each
handshake when using DHE ciphersuites. handshake when using DHE ciphersuites.
Because TLS allows the server to provide arbitrary DH groups, the Because TLS allows the server to provide arbitrary DH groups, the
client SHOULD verify the correctness of the DH group. [TODO: provide client should verify that the DH group is of suitable size as defined
a reference to some document describing how] and that it is of by local policy. The client SHOULD also verify that the DH public
suitable size as defined by local policy. The client SHOULD also exponent appears to be of adequate size. [KEYSIZ] provides a useful
verify that the DH public exponent appears to be of adequate size. guide to the strength of various group sizes. The server MAY choose
The server MAY choose to assist the client by providing a known to assist the client by providing a known group, such as those
group, such as those defined in [IKEALG] or [MODP]. These can be defined in [IKEALG] or [MODP]. These can be verified by simple
verified by simple comparison. comparison.
F.1.2. Version Rollback Attacks F.1.2. Version Rollback Attacks
Because TLS includes substantial improvements over SSL Version 2.0, Because TLS includes substantial improvements over SSL Version 2.0,
attackers may try to make TLS-capable clients and servers fall back attackers may try to make TLS-capable clients and servers fall back
to Version 2.0. This attack can occur if (and only if) two TLS- to Version 2.0. This attack can occur if (and only if) two TLS-
capable parties use an SSL 2.0 handshake. capable parties use an SSL 2.0 handshake.
Although the solution using non-random PKCS #1 block type 2 message Although the solution using non-random PKCS #1 block type 2 message
padding is inelegant, it provides a reasonably secure way for Version padding is inelegant, it provides a reasonably secure way for Version
skipping to change at page 96, line ? skipping to change at page 99, line ?
with it can be read. Similarly, compromise of a MAC key can make with it can be read. Similarly, compromise of a MAC key can make
message modification attacks possible. Because MACs are also message modification attacks possible. Because MACs are also
encrypted, message-alteration attacks generally require breaking the encrypted, message-alteration attacks generally require breaking the
encryption algorithm as well as the MAC. encryption algorithm as well as the MAC.
Note: MAC secrets may be larger than encryption keys, so messages can Note: MAC secrets may be larger than encryption keys, so messages can
remain tamper resistant even if encryption keys are broken. remain tamper resistant even if encryption keys are broken.
F.3. Explicit IVs F.3. Explicit IVs
[CBCATT] describes a chosen plaintext attack on TLS that depends [CBCATT] describes a chosen plaintext attack on TLS that depends on
on knowing the IV for a record. Previous versions of TLS [TLS1.0] knowing the IV for a record. Previous versions of TLS [TLS1.0] used
used the CBC residue of the previous record as the IV and the CBC residue of the previous record as the IV and therefore
therefore enabled this attack. This version uses an explicit IV enabled this attack. This version uses an explicit IV in order to
in order to protect against this attack. protect against this attack.
F.4. Security of Composite Cipher Modes F.4. Security of Composite Cipher Modes
TLS secures transmitted application data via the use of symmetric TLS secures transmitted application data via the use of symmetric
encryption and authentication functions defined in the negotiated encryption and authentication functions defined in the negotiated
ciphersuite. The objective is to protect both the integrity and ciphersuite. The objective is to protect both the integrity and
confidentiality of the transmitted data from malicious actions by confidentiality of the transmitted data from malicious actions by
active attackers in the network. It turns out that the order in active attackers in the network. It turns out that the order in
which encryption and authentication functions are applied to the which encryption and authentication functions are applied to the data
data plays an important role for achieving this goal [ENCAUTH]. plays an important role for achieving this goal [ENCAUTH].
The most robust method, called encrypt-then-authenticate, first The most robust method, called encrypt-then-authenticate, first
applies encryption to the data and then applies a MAC to the applies encryption to the data and then applies a MAC to the
ciphertext. This method ensures that the integrity and ciphertext. This method ensures that the integrity and
confidentiality goals are obtained with ANY pair of encryption confidentiality goals are obtained with ANY pair of encryption and
and MAC functions, provided that the former is secure against MAC functions, provided that the former is secure against chosen
chosen plaintext attacks and that the MAC is secure against plaintext attacks and that the MAC is secure against chosen-message
chosen-message attacks. TLS uses another method, called attacks. TLS uses another method, called authenticate-then-encrypt,
authenticate-then-encrypt, in which first a MAC is computed on in which first a MAC is computed on the plaintext and then the
the plaintext and then the concatenation of plaintext and MAC is concatenation of plaintext and MAC is encrypted. This method has
encrypted. This method has been proven secure for CERTAIN been proven secure for CERTAIN combinations of encryption functions
combinations of encryption functions and MAC functions, but it is and MAC functions, but it is not guaranteed to be secure in general.
not guaranteed to be secure in general. In particular, it has In particular, it has been shown that there exist perfectly secure
been shown that there exist perfectly secure encryption functions encryption functions (secure even in the information-theoretic sense)
(secure even in the information-theoretic sense) that combined that combined with any secure MAC function, fail to provide the
with any secure MAC function, fail to provide the confidentiality confidentiality goal against an active attack. Therefore, new
goal against an active attack. Therefore, new ciphersuites and ciphersuites and operation modes adopted into TLS need to be analyzed
operation modes adopted into TLS need to be analyzed under the under the authenticate-then-encrypt method to verify that they
authenticate-then-encrypt method to verify that they achieve the achieve the stated integrity and confidentiality goals.
stated integrity and confidentiality goals.
Currently, the security of the authenticate-then-encrypt method Currently, the security of the authenticate-then-encrypt method has
has been proven for some important cases. One is the case of been proven for some important cases. One is the case of stream
stream ciphers in which a computationally unpredictable pad of ciphers in which a computationally unpredictable pad of the length of
the length of the message, plus the length of the MAC tag, is the message, plus the length of the MAC tag, is produced using a
produced using a pseudo-random generator and this pad is xor-ed pseudo-random generator and this pad is xor-ed with the concatenation
with the concatenation of plaintext and MAC tag. The other is of plaintext and MAC tag. The other is the case of CBC mode using a
the case of CBC mode using a secure block cipher. In this case, secure block cipher. In this case, security can be shown if one
security can be shown if one applies one CBC encryption pass to applies one CBC encryption pass to the concatenation of plaintext and
the concatenation of plaintext and MAC and uses a new, MAC and uses a new, independent, and unpredictable IV for each new
independent, and unpredictable IV for each new pair of plaintext pair of plaintext and MAC. In versions of TLS prior to 1.1, CBC mode
and MAC. In previous versions of SSL, CBC mode was used properly was used properly EXCEPT that it used a predictable IV in the form of
EXCEPT that it used a predictable IV in the form of the last the last block of the previous ciphertext. This made TLS open to
block of the previous ciphertext. This made TLS open to chosen chosen plaintext attacks. This version of the protocol is immune to
plaintext attacks. This version of the protocol is immune to those attacks. For exact details in the encryption modes proven
those attacks. For exact details in the encryption modes proven secure, see [ENCAUTH].
secure, see [ENCAUTH].
F.5 Denial of Service F.5 Denial of Service
TLS is susceptible to a number of denial of service (DoS) attacks. TLS is susceptible to a number of denial of service (DoS) attacks.
In particular, an attacker who initiates a large number of TCP In particular, an attacker who initiates a large number of TCP
connections can cause a server to consume large amounts of CPU doing connections can cause a server to consume large amounts of CPU doing
RSA decryption. However, because TLS is generally used over TCP, it RSA decryption. However, because TLS is generally used over TCP, it
is difficult for the attacker to hide his point of origin if proper is difficult for the attacker to hide his point of origin if proper
TCP SYN randomization is used [SEQNUM] by the TCP stack. TCP SYN randomization is used [SEQNUM] by the TCP stack.
Because TLS runs over TCP, it is also susceptible to a number of Because TLS runs over TCP, it is also susceptible to a number of
denial of service attacks on individual connections. In particular, denial of service attacks on individual connections. In particular,
attackers can forge RSTs, thereby terminating connections, or forge attackers can forge RSTs, thereby terminating connections, or forge
partial TLS records, thereby causing the connection to stall. These partial TLS records, thereby causing the connection to stall. These
attacks cannot in general be defended against by a TCP-using attacks cannot in general be defended against by a TCP-using
protocol. Implementors or users who are concerned with this class of protocol. Implementors or users who are concerned with this class of
attack should use IPsec AH [AH] or ESP [ESP]. attack should use IPsec AH [AH] or ESP [ESP].
Security Considerations F.6 Final Notes
Security issues are discussed throughout this memo, especially in For TLS to be able to provide a secure connection, both the client
Appendices D, E, and F. and server systems, keys, and applications must be secure. In
addition, the implementation must be free of security errors.
The system is only as strong as the weakest key exchange and
authentication algorithm supported, and only trustworthy
cryptographic functions should be used. Short public keys and
anonymous servers should be used with great caution. Implementations
and users must be careful when deciding which certificates and
certificate authorities are acceptable; a dishonest certificate
authority can do tremendous damage.
Changes in This Version Changes in This Version
[RFC Editor: Please delete this] [RFC Editor: Please delete this]
- Added compression methods to the IANA considerations. - Redid the hash function advertisements for CertificateRequest
and the client-side extension. They are now pairs of
- Misc. editorial changes/clarifications hash/signature and the semantics are clearly defined for
all uses of signatures (hopefully). [Issue 41]
- Added an Implementation Pitfalls sections - Clarified the DH group checking per list discussion [Issue 35]
[Issue 26]
- Harmonized the requirement to send an empty certificate list - Added a note about DSS vs. DSA [Issue 58]
after certificate_request even when no certs are available.
[Issue 48]
- Made the verify_data length depend on the cipher suite - Editorial issues [Issue 59]
[Issue 49]
- TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement - Cleaned up certificate text in 7.4.2 and 7.4.6 [Issue 57]
cipher suite [Issue 56]
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 [DES] National Institute of Standards and Technology, "Data
Encryption Standard (DES)", FIPS PUB 46-3, October 1999. Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
[DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National
Institute of Standards and Technology, U.S. Department of Institute of Standards and Technology, U.S. Department of
Commerce, 2000. PKI 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.
[IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
Series in Information Processing, v. 1, Konstanz: Hartung- Series in Information Processing, v. 1, Konstanz: Hartung-
Gorre Verlag, 1992. Gorre Verlag, 1992.
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
April 1992. April 1992.
skipping to change at page 96, line ? skipping to change at page 99, line ?
[AEAD] Mcgrew, D., "Authenticated Encryption", February 2007, [AEAD] Mcgrew, D., "Authenticated Encryption", February 2007,
draft-mcgrew-auth-enc-02.txt. draft-mcgrew-auth-enc-02.txt.
[AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC
4302, December 2005. 4302, December 2005.
[BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS #1" in Protocols Based on RSA Encryption Standard PKCS #1" in
Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
1-12, 1998. 1-12, 1998.
[CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
Problems and Countermeasures", Problems and Countermeasures",
http://www.openssl.org/~bodo/tls-cbc.txt. http://www.openssl.org/~bodo/tls-cbc.txt.
[CBCTIME] Canvel, B., 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/SP800-38C.pdf http://csrc.nist.gov/publications/nistpubs/800-38C/
SP800-38C.pdf
[ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
for Protecting Communications (Or: How Secure is SSL?)", for Protecting Communications (Or: How Secure is SSL?)",
Crypto 2001. Crypto 2001.
[ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
Payload (ESP)", RFC 4303, December 2005. Payload (ESP)", RFC 4303, December 2005.
[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
skipping to change at page 96, line ? skipping to change at page 99, line ?
archive/msg14307.html. archive/msg14307.html.
[GCM] "NIST Special Publication 800-38D DRAFT (June, 2007): [GCM] "NIST Special Publication 800-38D DRAFT (June, 2007):
Recommendation for Block Cipher Modes of Operation: Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC" Galois/Counter Mode (GCM) and GMAC"
[IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December
2005. 2005.
[KEYSIZ] Orman, H., and Hoffman, P., "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys" RFC 3766,
April 2004.
[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.
skipping to change at page 96, line ? skipping to change at page 99, line ?
[TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
September 1981. September 1981.
[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
practical", USENIX Security Symposium 2003. practical", USENIX Security Symposium 2003.
[TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
for Transport Layer Security (TLS)", RFC 3268, June 2002. for Transport Layer Security (TLS)", RFC 3268, June 2002.
[TLSEXT], Eastlake, D.E., "Transport Layer Security (TLS) [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
Extensions: Extension Definitions", July 2007, draft-ietf- Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
tls-rfc4366-bis-00.txt. Suites for Transport Layer Security (TLS)", RFC 4492, May
2006.
[TLSEXT] Eastlake, D.E., "Transport Layer Security (TLS) Extensions:
Extension Definitions", July 2007, draft-ietf-tls-
rfc4366-bis-00.txt.
[TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS
authentication", draft-ietf-tls-openpgp-keys-11, July 2006.
[TLSPSK] Eronen, P., Tschofenig, H., "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, December
2005.
[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] Srinivansan, R., Sun Microsystems, "XDR: External Data [XDR] Eisler, M., "External Data Representation Standard", RFC
Representation Standard", RFC 1832, August 1995. 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
skipping to change at page 96, line ? skipping to change at page 99, line ?
Netscape Communications Netscape Communications
jar@netscape.com jar@netscape.com
Michael Sabin Michael Sabin
Dan Simon Dan Simon
Microsoft, Inc. Microsoft, Inc.
dansimon@microsoft.com dansimon@microsoft.com
Tom Weinstein Tom Weinstein
Tim Wright Tim Wright
Vodafone Vodafone
EMail: timothy.wright@vodafone.com EMail: timothy.wright@vodafone.com
Comments Comments
The discussion list for the IETF TLS working group is located at the The discussion list for the IETF TLS working group is located at the
e-mail address <tls@ietf.org>. Information on the group and e-mail address <tls@ietf.org>. Information on the group and
information on how to subscribe to the list is at information on how to subscribe to the list is at
<https://www1.ietf.org/mailman/listinfo/tls> <https://www1.ietf.org/mailman/listinfo/tls>
Archives of the list can be found at: Archives of the list can be found at:
<http://www.ietf.org/mail-archive/web/tls/current/index.html> <http://www.ietf.org/mail-archive/web/tls/current/index.html>
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
 End of changes. 140 change blocks. 
529 lines changed or deleted 739 lines changed or added

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