< draft-ietf-tls-rfc4346-bis-07.txt   draft-ietf-tls-rfc4346-bis-08.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 Updates (if approved): RFC 4492 Eric Rescorla
Network Resonance, Inc. Intended status: Proposed Standard Network Resonance, Inc.
<draft-ietf-tls-rfc4346-bis-07.txt> November 2007 (Expires May 2008) <draft-ietf-tls-rfc4346-bis-08.txt> January 2008 (Expires July 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 1, line 37 skipping to change at page 1, line 37
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
7.2.1. Closure Alerts 28 7.2.1. Closure Alerts 28
7.2.2. Error Alerts 29 7.2.2. Error Alerts 29
7.3. Handshake Protocol Overview 32 7.3. Handshake Protocol Overview 32
7.4. Handshake Protocol 35 7.4. Handshake Protocol 35
7.4.1. Hello Messages 36 7.4.1. Hello Messages 36
7.4.1.1. Hello Request 36 7.4.1.1. Hello Request 36
7.4.1.2. Client Hello 37 7.4.1.2. Client Hello 37
7.4.1.3. Server Hello 40 7.4.1.3. Server Hello 40
7.4.1.4 Hello Extensions 42 7.4.1.4 Hello Extensions 42
7.4.1.4.1 Signature Algorithms 43 7.4.1.4.1 Signature Algorithms 43
7.4.2. Server Certificate 44 7.4.2. Server Certificate 45
7.4.3. Server Key Exchange Message 47 7.4.3. Server Key Exchange Message 47
7.4.4. Certificate Request 49 7.4.4. Certificate Request 50
7.4.5 Server hello done 51 7.4.5 Server hello done 52
7.4.6. Client Certificate 52 7.4.6. Client Certificate 52
7.4.7. Client Key Exchange Message 53 7.4.7. Client Key Exchange Message 54
7.4.7.1. RSA Encrypted Premaster Secret Message 54 7.4.7.1. RSA Encrypted Premaster Secret Message 54
7.4.7.2. Client Diffie-Hellman Public Value 56 7.4.7.2. Client Diffie-Hellman Public Value 57
7.4.8. Certificate verify 57 7.4.8. Certificate verify 57
7.4.9. Finished 58 7.4.9. Finished 58
8. Cryptographic Computations 59 8. Cryptographic Computations 60
8.1. Computing the Master Secret 60 8.1. Computing the Master Secret 60
8.1.1. RSA 60 8.1.1. RSA 61
8.1.2. Diffie-Hellman 60 8.1.2. Diffie-Hellman 61
9. Mandatory Cipher Suites 60 9. Mandatory Cipher Suites 61
10. Application Data Protocol 60 10. Application Data Protocol 61
11. Security Considerations 60 11. Security Considerations 61
12. IANA Considerations 61 12. IANA Considerations 61
A. Protocol Constant Values 63 A. Protocol Constant Values 64
A.1. Record Layer 63 A.1. Record Layer 64
A.2. Change Cipher Specs Message 64 A.2. Change Cipher Specs Message 65
A.3. Alert Messages 64 A.3. Alert Messages 65
A.4. Handshake Protocol 65 A.4. Handshake Protocol 66
A.4.1. Hello Messages 65 A.4.1. Hello Messages 66
A.4.2. Server Authentication and Key Exchange Messages 67 A.4.2. Server Authentication and Key Exchange Messages 68
A.4.3. Client Authentication and Key Exchange Messages 68 A.4.3. Client Authentication and Key Exchange Messages 69
A.4.4. Handshake Finalization Message 69 A.4.4. Handshake Finalization Message 70
A.5. The CipherSuite 69 A.5. The Cipher Suite 70
A.6. The Security Parameters 72 A.6. The Security Parameters 73
B. Glossary 73 B. Glossary 75
C. CipherSuite Definitions 77 C. Cipher Suite Definitions 79
D. Implementation Notes 79 D. Implementation Notes 81
D.1 Random Number Generation and Seeding 79 D.1 Random Number Generation and Seeding 81
D.2 Certificates and Authentication 79 D.2 Certificates and Authentication 81
D.3 CipherSuites 79 D.3 Cipher Suites 81
D.4 Implementation Pitfalls 79 D.4 Implementation Pitfalls 81
E. Backward Compatibility 82 E. Backward Compatibility 84
E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 82 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 84
E.2 Compatibility with SSL 2.0 83 E.2 Compatibility with SSL 2.0 85
E.3. Avoiding Man-in-the-Middle Version Rollback 85 E.3. Avoiding Man-in-the-Middle Version Rollback 87
F. Security Analysis 86 F. Security Analysis 88
F.1. Handshake Protocol 86 F.1. Handshake Protocol 88
F.1.1. Authentication and Key Exchange 86 F.1.1. Authentication and Key Exchange 88
F.1.1.1. Anonymous Key Exchange 86 F.1.1.1. Anonymous Key Exchange 88
F.1.1.2. RSA Key Exchange and Authentication 87 F.1.1.2. RSA Key Exchange and Authentication 89
F.1.1.3. Diffie-Hellman Key Exchange with Authentication 87 F.1.1.3. Diffie-Hellman Key Exchange with Authentication 89
F.1.2. Version Rollback Attacks 88 F.1.2. Version Rollback Attacks 90
F.1.3. Detecting Attacks Against the Handshake Protocol 89 F.1.3. Detecting Attacks Against the Handshake Protocol 91
F.1.4. Resuming Sessions 89 F.1.4. Resuming Sessions 91
F.2. Protecting Application Data 89 F.2. Protecting Application Data 91
F.3. Explicit IVs 90 F.3. Explicit IVs 92
F.4. Security of Composite Cipher Modes 90 F.4. Security of Composite Cipher Modes 92
F.5 Denial of Service 91 F.5 Denial of Service 93
F.6 Final Notes 91 F.6 Final Notes 93
1. Introduction 1. Introduction
The primary goal of the TLS Protocol is to provide privacy and data The primary goal of the TLS Protocol is to provide privacy and data
integrity between two communicating applications. The protocol is integrity between two communicating applications. The protocol is
composed of two layers: the TLS Record Protocol and the TLS Handshake composed of two layers: the TLS Record Protocol and the TLS Handshake
Protocol. At the lowest level, layered on top of some reliable Protocol. At the lowest level, layered on top of some reliable
transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
TLS Record Protocol provides connection security that has two basic TLS Record Protocol provides connection security that has two basic
properties: properties:
skipping to change at page 6, line 8 skipping to change at page 6, line 8
- Cleaned up description of Bleichenbacher/Klima attack defenses. - Cleaned up description of Bleichenbacher/Klima attack defenses.
- Alerts MUST now be sent in many cases. - Alerts MUST now be sent in many cases.
- After a certificate_request, if no certificates are available, - After a certificate_request, if no certificates are available,
clients now MUST send an empty certificate list. clients now MUST send an empty certificate list.
- 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.
- IDEE and DES are now deprecated. - Added HMAC-SHA256 cipher suites
- IDEA and DES are now deprecated.
- Support for the SSLv2 backward-compatible hello is now a MAY, not - Support for the SSLv2 backward-compatible hello is now a MAY, not
a SHOULD. This will probably become a SHOULD NOT in the future. a SHOULD. This will probably become a SHOULD NOT in the future.
- Added an Implementation Pitfalls sections - Added an Implementation Pitfalls sections
- The usual clarifications and editorial work. - The usual clarifications and editorial work.
2. Goals 2. Goals
The goals of TLS Protocol, in order of their priority, are as The goals of TLS Protocol, in order of their priority, are as
skipping to change at page 14, line 26 skipping to change at page 14, line 26
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_SHA256 is being used to
create 64 bytes of data, it will have to be iterated 4 times (through create 80 bytes of data, it will have to be iterated three times
A(4)), creating 80 bytes of output data; the last 16 bytes of the (through A(3)), creating 96 bytes of output data; the last 16 bytes
final iteration will then be discarded, leaving 64 bytes of output of the final iteration will then be discarded, leaving 80 bytes of
data. output data.
TLS's PRF is created by applying P_hash to the secret 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:
skipping to change at page 18, line 36 skipping to change at page 18, line 36
6.2.1. Fragmentation 6.2.1. Fragmentation
The record layer fragments information blocks into TLSPlaintext The record layer fragments information blocks into TLSPlaintext
records carrying data in chunks of 2^14 bytes or less. Client message records carrying data in chunks of 2^14 bytes or less. Client message
boundaries are not preserved in the record layer (i.e., multiple boundaries are not preserved in the record layer (i.e., multiple
client messages of the same ContentType MAY be coalesced into a client messages of the same ContentType MAY be coalesced into a
single TLSPlaintext record, or a single message MAY be fragmented single TLSPlaintext record, or a single message MAY be fragmented
across several records). across several records).
struct { struct {
uint8 major, minor; uint8 major;
uint8 minor;
} ProtocolVersion; } ProtocolVersion;
enum { enum {
change_cipher_spec(20), alert(21), handshake(22), change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255) application_data(23), (255)
} ContentType; } ContentType;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion version;
skipping to change at page 21, line 21 skipping to change at page 21, line 25
convert TLSCompressed.fragment structures to and from stream convert TLSCompressed.fragment structures to and from stream
TLSCiphertext.fragment structures. TLSCiphertext.fragment structures.
stream-ciphered struct { stream-ciphered struct {
opaque content[TLSCompressed.length]; opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length]; opaque MAC[SecurityParameters.mac_length];
} GenericStreamCipher; } GenericStreamCipher;
The MAC is generated as: The MAC is generated as:
MAC(MAC_write_secret, seq_num + MAC(MAC_write_key, seq_num +
TLSCompressed.type + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.version +
TLSCompressed.length + 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.
MAC MAC
The MAC algorithm specified by SecurityParameters.mac_algorithm. The MAC algorithm specified by SecurityParameters.mac_algorithm.
Note that the MAC is computed before encryption. The stream cipher Note that the MAC is computed before encryption. The stream cipher
encrypts the entire block, including the MAC. For stream ciphers that encrypts the entire block, including the MAC. For stream ciphers that
do not use a synchronization vector (such as RC4), the stream cipher do not use a synchronization vector (such as RC4), the stream cipher
state from the end of one record is simply used on the subsequent state from the end of one record is simply used on the subsequent
packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, encryption
consists of the identity operation (i.e., the data is not encrypted, consists of the identity operation (i.e., the data is not encrypted,
and the MAC size is zero, implying that no MAC is used). and the MAC size is zero, implying that no MAC is used).
TLSCiphertext.length is TLSCompressed.length plus TLSCiphertext.length is TLSCompressed.length plus
SecurityParameters.mac_length. SecurityParameters.mac_length.
6.2.3.2. CBC Block Cipher 6.2.3.2. CBC Block Cipher
For block ciphers (such as 3DES, or AES), the encryption and MAC For block ciphers (such as 3DES, or AES), the encryption and MAC
functions convert TLSCompressed.fragment structures to and from block functions convert TLSCompressed.fragment structures to and from block
TLSCiphertext.fragment structures. TLSCiphertext.fragment structures.
struct { struct {
opaque IV[SecurityParameters.record_iv_length]; opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct { block-ciphered struct {
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];
skipping to change at page 24, line 28 skipping to change at page 24, line 31
Where "+" denotes concatenation. Where "+" denotes concatenation.
The aead_output consists of the ciphertext output by the AEAD The aead_output consists of the ciphertext output by the AEAD
encryption operation. The length will generally be larger than encryption operation. The length will generally be larger than
TLSCompressed.length, but by an amount that varies with the AEAD TLSCompressed.length, but by an amount that varies with the AEAD
cipher. Since the ciphers might incorporate padding, the amount of cipher. Since the ciphers might incorporate padding, the amount of
overhead could vary with different TLSCompressed.length values. Each overhead could vary with different TLSCompressed.length values. Each
AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
Symbolically, Symbolically,
AEADEncrypted = AEAD-Encrypt(key, IV, plaintext, AEADEncrypted = AEAD-Encrypt(key, nonce, plaintext,
additional_data) additional_data)
In order to decrypt and verify, the cipher takes as input the key, In order to decrypt and verify, the cipher takes as input the key,
IV, the "additional_data", and the AEADEncrypted value. The output is nonce, the "additional_data", and the AEADEncrypted value. The output
either the plaintext or an error indicating that the decryption is either the plaintext or an error indicating that the decryption
failed. There is no separate integrity check. I.e., failed. There is no separate integrity check. I.e.,
TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
AEADEncrypted, AEADEncrypted,
additional_data) additional_data)
If the decryption fails, a fatal bad_record_mac alert MUST be If the decryption fails, a fatal bad_record_mac alert MUST be
generated. generated.
6.3. Key Calculation 6.3. Key Calculation
The Record Protocol requires an algorithm to generates keys required The Record Protocol requires an algorithm to generates keys required
by the current connection state (see Appendix A.6) from the security by the current connection state (see Appendix A.6) from the security
skipping to change at page 29, line 17 skipping to change at page 29, line 17
Error handling in the TLS Handshake protocol is very simple. When an Error handling in the TLS Handshake protocol is very simple. When an
error is detected, the detecting party sends a message to the other error is detected, the detecting party sends a message to the other
party. Upon transmission or receipt of a fatal alert message, both party. Upon transmission or receipt of a fatal alert message, both
parties immediately close the connection. Servers and clients MUST parties immediately close the connection. Servers and clients MUST
forget any session-identifiers, keys, and secrets associated with a forget any session-identifiers, keys, and secrets associated with a
failed connection. Thus, any connection terminated with a fatal alert failed connection. Thus, any connection terminated with a fatal alert
MUST NOT be resumed. 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. For all errors where an alert level is not explicitly
alert which may be a warning alert but intends to close the specified, the sending party MAY determine at its discretion whether
connection immediately afterwards, it MUST send that alert at the to treat this as a fatal error or not. If the implementation chooses
fatal alert level. to send an alert but intends to close the connection immediately
afterwards, it MUST send that alert at the fatal alert level.
If an alert with a level of warning is sent and received, generally 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. Given this, the
sending party cannot, in general, know how the receiving party will
behave. Therefore, warning alerts are not very useful when the
sending party wants to continue the connection, and thus are
sometimes omitted. For example, if a peer decides to accept an
expired certificate (perhaps after confirming this with the user) and
wants to continue the connection, it would not generally send a
certificate_expired alert.
The following error alerts are defined: The following error alerts are defined:
unexpected_message unexpected_message
An inappropriate message was received. This alert is always fatal An inappropriate message was received. This alert is always fatal
and should never be observed in communication between proper and should never be observed in communication between proper
implementations. implementations.
bad_record_mac bad_record_mac
This alert is returned if a record is received with an incorrect This alert is returned if a record is received with an incorrect
MAC. This alert also MUST be returned if an alert is sent because MAC. This alert also MUST be returned if an alert is sent because
a TLSCiphertext decrypted in an invalid way: either it wasn't an a TLSCiphertext decrypted in an invalid way: either it wasn't an
even multiple of the block length, or its padding values, when even multiple of the block length, or its padding values, when
checked, weren't correct. This message is always fatal. checked, weren't correct. This message is always fatal and should
never be observed in communication between proper implementations
(except when messages were corrupted in the network).
decryption_failed_RESERVED decryption_failed_RESERVED
This alert was used in some earlier versions of TLS, and may have This alert was used in some earlier versions of TLS, and may have
permitted certain attacks against the CBC mode [CBCATT]. It MUST permitted certain attacks against the CBC mode [CBCATT]. It MUST
NOT be sent by compliant implementations. NOT be sent by compliant implementations.
record_overflow record_overflow
A TLSCiphertext record was received that had a length more than A TLSCiphertext record was received that had a length more than
2^14+2048 bytes, or a record decrypted to a TLSCompressed record 2^14+2048 bytes, or a record decrypted to a TLSCompressed record
with more than 2^14+1024 bytes. This message is always fatal. with more than 2^14+1024 bytes. This message is always fatal and
should never be observed in communication between proper
implementations (except when messages were corrupted in the
network).
decompression_failure decompression_failure
The decompression function received improper input (e.g., data The decompression function received improper input (e.g., data
that would expand to excessive length). This message is always that would expand to excessive length). This message is always
fatal. fatal and should never be observed in communication between proper
implementations.
handshake_failure handshake_failure
Reception of a handshake_failure alert message indicates that the Reception of a handshake_failure alert message indicates that the
sender was unable to negotiate an acceptable set of security sender was unable to negotiate an acceptable set of security
parameters given the options available. This is a fatal error. parameters given the options available. This is a fatal error.
no_certificate_RESERVED no_certificate_RESERVED
This alert was used in SSLv3 but not any version of TLS. It MUST This alert was used in SSLv3 but not any version of TLS. It MUST
NOT be sent by compliant implementations. NOT be sent by compliant implementations.
skipping to change at page 31, line 5 skipping to change at page 31, line 19
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. This applied, the sender decided not to proceed with negotiation. This
message is always fatal. message is always fatal.
decode_error decode_error
A message could not be decoded because some field was out of the A message could not be decoded because some field was out of the
specified range or the length of the message was incorrect. This specified range or the length of the message was incorrect. This
message is always fatal. message is always fatal and should never be observed in
communication between proper implementations (except when messages
were corrupted in the network).
decrypt_error decrypt_error
A handshake cryptographic operation failed, including being unable A handshake cryptographic operation failed, including being unable
to correctly verify a signature, decrypt a key exchange, or to correctly verify a signature or validate a finished message.
validate a finished message. This message is always fatal.
export_restriction_RESERVED export_restriction_RESERVED
This alert was used in some earlier versions of TLS. It MUST NOT This alert was used in some earlier versions of TLS. It MUST NOT
be sent by compliant implementations. be sent by compliant implementations.
protocol_version protocol_version
The protocol version the client has attempted to negotiate is The protocol version the client has attempted to negotiate is
recognized but not supported. (For example, old protocol versions recognized but not supported. (For example, old protocol versions
might be avoided for security reasons). This message is always might be avoided for security reasons). This message is always
fatal. fatal.
skipping to change at page 38, line 31 skipping to change at page 38, line 47
opaque SessionID<0..32>; opaque SessionID<0..32>;
Warning: Because the SessionID is transmitted without encryption or Warning: Because the SessionID is transmitted without encryption or
immediate MAC protection, servers MUST NOT place confidential immediate MAC protection, servers MUST NOT place confidential
information in session identifiers or let the contents of fake information in session identifiers or let the contents of fake
session identifiers cause any breach of security. (Note that the session identifiers cause any breach of security. (Note that the
content of the handshake as a whole, including the SessionID, is content of the handshake as a whole, including the SessionID, is
protected by the Finished messages exchanged at the end of the protected by the Finished messages exchanged at the end of the
handshake.) handshake.)
The CipherSuite list, passed from the client to the server in the The cipher suite list, passed from the client to the server in the
client hello message, contains the combinations of cryptographic client hello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's algorithms supported by the client in order of the client's
preference (favorite choice first). Each CipherSuite defines a key preference (favorite choice first). Each cipher suite defines a key
exchange algorithm, a bulk encryption algorithm (including secret key exchange algorithm, a bulk encryption algorithm (including secret key
length), a MAC algorithm, and a PRF. The server will select a cipher length), a MAC algorithm, and a PRF. The server will select a cipher
suite or, if no acceptable choices are presented, return a handshake suite or, if no acceptable choices are presented, return a handshake
failure alert and close the connection. failure alert and close the connection.
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
The client hello includes a list of compression algorithms supported The client hello includes a list of compression algorithms supported
by the client, ordered according to the client's preference. by the client, ordered according to the client's preference.
skipping to change at page 40, line 5 skipping to change at page 40, line 19
compression_methods compression_methods
This is a list of the compression methods supported by the client, This is a list of the compression methods supported by the client,
sorted by client preference. If the session_id field is not empty sorted by client preference. If the session_id field is not empty
(implying a session resumption request) it MUST include the (implying a session resumption request) it MUST include the
compression_method from that session. This vector MUST contain, compression_method from that session. This vector MUST contain,
and all implementations MUST support, CompressionMethod.null. and all implementations MUST support, CompressionMethod.null.
Thus, a client and server will always be able to agree on a Thus, a client and server will always be able to agree on a
compression method. compression method.
client_hello_extension_list extensions
Clients MAY request extended functionality from servers by sending Clients MAY request extended functionality from servers by sending
data in the client_hello_extension_list. Here the new data in the extensions Here the new "extensions" field contains a
"client_hello_extension_list" field contains a list of extensions. list of extensions. The actual "Extension" format is defined in
The actual "Extension" format is defined in Section 7.4.1.4. Section 7.4.1.4.
In the event that a client requests additional functionality using In the event that a client requests additional functionality using
extensions, and this functionality is not supplied by the server, the extensions, and this functionality is not supplied by the server, the
client MAY abort the handshake. A server that supports the client MAY abort the handshake. A server MUST accept client hello
extensions mechanism MUST accept client hello messages in either the messages both with and without the extensions field, and (as for all
original (TLS 1.0/TLS 1.1) ClientHello or the extended ClientHello other messages) MUST check that the amount of data in the message
format defined in this document, and (as for all other messages) MUST precisely matches one of these formats; if not, then it MUST send a
check that the amount of data in the message precisely matches one of fatal "decode_error" alert.
these formats; if not then it MUST send a fatal "decode_error" alert.
After sending the client hello message, the client waits for a server After sending the client hello message, the client waits for a 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
skipping to change at page 41, line 43 skipping to change at page 42, line 8
cipher_suite cipher_suite
The single cipher suite selected by the server from the list in The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions, this field is the ClientHello.cipher_suites. For resumed sessions, this field is the
value from the state of the session being resumed. value from the state of the session being resumed.
compression_method compression_method
The single compression algorithm selected by the server from the The single compression algorithm selected by the server from the
list in ClientHello.compression_methods. For resumed sessions this list in ClientHello.compression_methods. For resumed sessions this
field is the value from the resumed session state. field is the value from the resumed session state.
server_hello_extension_list extensions
A list of extensions. Note that only extensions offered by the A list of extensions. Note that only extensions offered by the
client can appear in the server's list. client can appear in the server's list.
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>;
skipping to change at page 43, line 16 skipping to change at page 43, line 24
aspects of the design of TLS; for example the design of cipher aspects of the design of TLS; for example the design of cipher
suite negotiation. This is not recommended; it would be more suite negotiation. This is not recommended; it would be more
appropriate to define a new version of TLS - particularly since appropriate to define a new version of TLS - particularly since
the TLS handshake algorithms have specific protection against the TLS handshake algorithms have specific protection against
version rollback attacks based on the version number, and the version rollback attacks based on the version number, and the
possibility of version rollback should be a significant 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 Signature Algorithms 7.4.1.4.1 Signature Algorithms
The client MAY use the "signature_algorithms" extension to indicate The client uses the "signature_algorithms" extension to indicate to
to the server which signature/hash algorithm pairs may be used in the server which signature/hash algorithm pairs may be used in
digital signatures. The "extension_data" field of this extension digital signatures. The "extension_data" field of this extension
contains a "supported_signature_algorithms" value. contains a "supported_signature_algorithms" value.
enum { enum {
none(0), md5(1), sha1(2), sha256(3), sha384(4), none(0), md5(1), sha1(2), sha256(3), sha384(4),
sha512(5), (255) sha512(5), (255)
} HashAlgorithm; } HashAlgorithm;
enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
SignatureAlgorithm; SignatureAlgorithm;
struct { struct {
HashAlgorithm hash; HashAlgorithm hash;
SignatureAlgorithm signature; SignatureAlgorithm signature;
} SignatureAndHashAlgorithm; } SignatureAndHashAlgorithm;
SignatureAndHashAlgorithm SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-1>; supported_signature_algorithms<2..2^16-2>;
Each SignatureAndHashAlgorithm value lists a single hash/signature Each SignatureAndHashAlgorithm value lists a single hash/signature
pair which the client is willing to verify. The values are indicated pair which the client is willing to verify. The values are indicated
in descending order of preference. in descending order of preference.
Note: Because not all signature algorithms and hash algorithms may be Note: Because not all signature algorithms and hash algorithms may be
accepted by an implementation (e.g., DSA with SHA-1, but not accepted by an implementation (e.g., DSA with SHA-1, but not
SHA-256), algorithms here are listed in pairs. SHA-256), algorithms here are listed in pairs.
hash hash
This field indicates the hash algorithm which may be used. The This field indicates the hash algorithm which may be used. The
values indicate support for unhashed data, MD5 [MD5], SHA-1, values indicate support for unhashed data, MD5 [MD5], SHA-1,
SHA-256, SHA-384, and SHA-512 [SHA] respectively. The "none" value SHA-256, SHA-384, and SHA-512 [SHA] respectively. The "none" value
is provided for future extensibility, in case of a signature is provided for future extensibility, in case of a signature
algorithm which does not require hashing before signing. algorithm which does not require hashing before signing.
signature signature
This field indicates the signature algorithm which may be used. This field indicates the signature algorithm which may be used.
The values indicate anonymous signatures, RSA [PKCS1] and DSA The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
[DSS] respectively. The "anonymous" value is meaningless in this [PKCS1] and DSA [DSS] respectively. The "anonymous" value is
context but used later in the specification. It MUST NOT appear in meaningless in this context but used in Section 7.4.3. It MUST NOT
this extension. appear in this extension.
The semantics of this extension are somewhat complicated because the The semantics of this extension are somewhat complicated because the
cipher suite indicates permissible signature algorithms but not hash cipher suite indicates permissible signature algorithms but not hash
algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate rules. algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate rules.
Clients SHOULD send this extension if they support any hash algorithm If the client supports only the default hash and signature algorithms
other than SHA-1. (listed in this section), it MAY omit the signature_algorithms
extension. If the client does not support the default algorithms, or
supports other hash and signature algorithms (and it is willing to
use them for verifying messages sent by server; server certificates
and server key exchange), it MUST send the signature_algorithms
extension listing the algorithms it is willing to accept.
If the client does not send the signature_algorithms extension, the If the client does not send the signature_algorithms extension, the
server SHOULD assume the following: server MUST assume the following:
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent
the value (sha1,rsa). the value (sha1,rsa).
- If the negotiated key exchange algorithm is one of (DHE_DSS, - If the negotiated key exchange algorithm is one of (DHE_DSS,
DH_DSS), behave as if the client had sent the value (sha1,dsa). DH_DSS), behave as if the client had sent the value (sha1,dsa).
- If the negotiated key exchnage algorithm is one of (ECDH_ECDSA, - If the negotiated key exchnage algorithm is one of (ECDH_ECDSA,
ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa). ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa).
Note: this is a change from TLS 1.1 where there are no explicit rules Note: this is a change from TLS 1.1 where there are no explicit rules
but as a practical matter one can assume that the peer supports MD5 but as a practical matter one can assume that the peer supports MD5
and SHA-1. and SHA-1.
Servers MUST NOT send this extension. Note: this extension is not meaningful for TLS versions prior to 1.2.
Clients MUST NOT offer it if they are offering prior versions.
However, even if clients do offer it, the rules specified in [TLSEXT]
require servers to ignore extensions they do not understand.
Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension.
7.4.2. Server Certificate 7.4.2. Server Certificate
When this message will be sent: When this message will be sent:
The server MUST send a certificate whenever the agreed-upon key The server MUST send a certificate 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:
This message conveys the server's certificate to the client. The This message conveys the server's certificate chain to the client.
certificate MUST be appropriate for the negotiated cipher suite's The certificate MUST be appropriate for the negotiated cipher
key exchange algorithm, and any negotiated extensions. suite's key exchange algorithm, and any negotiated extensions.
Structure of this message: Structure of this message:
opaque ASN.1Cert<1..2^24-1>; opaque ASN.1Cert<1..2^24-1>;
struct { struct {
ASN.1Cert certificate_list<0..2^24-1>; ASN.1Cert certificate_list<0..2^24-1>;
} Certificate; } Certificate;
certificate_list certificate_list
skipping to change at page 45, line 38 skipping to change at page 46, line 10
Note: PKCS #7 [PKCS7] is not used as the format for the certificate Note: PKCS #7 [PKCS7] is not used as the format for the certificate
vector because PKCS #6 [PKCS6] extended certificates are not used. vector because PKCS #6 [PKCS6] extended certificates are not used.
Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
of parsing the list more difficult. of parsing the list more difficult.
The following rules apply to the certificates sent by the server: The following rules apply to the certificates sent by the server:
- The certificate type MUST be X.509v3, unless explicitly negotiated - The certificate type MUST be X.509v3, unless explicitly negotiated
otherwise (e.g., [TLSPGP]). otherwise (e.g., [TLSPGP]).
- The certificate's public key (and associated restrictions) MUST be - The end entity certificate's public key (and associated
compatible with the selected key exchange algorithm. restrictions) MUST be compatible with the selected key exchange
algorithm.
Key Exchange Alg. Certificate Key Type Key Exchange Alg. Certificate Key Type
RSA RSA public key; the certificate MUST RSA RSA public key; the certificate MUST
RSA_PSK allow the key to be used for encryption RSA_PSK allow the key to be used for encryption
(the keyEncipherment bit MUST be set (the keyEncipherment bit MUST be set
if the key usage extension is present). if the key usage extension is present).
Note: RSA_PSK is defined in [TLSPSK]. Note: RSA_PSK is defined in [TLSPSK].
DHE_RSA RSA public key; the certificate MUST DHE_RSA RSA public key; the certificate MUST
skipping to change at page 46, line 48 skipping to change at page 47, line 21
departure from TLS 1.1, which required that the algorithms be the departure from TLS 1.1, which required that the algorithms be the
same. Note that this also implies that the DH_DSS, DH_RSA, same. Note that this also implies that the DH_DSS, DH_RSA,
ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
algorithm used to sign the certificate. Fixed DH certificates MAY be algorithm used to sign the certificate. Fixed DH certificates MAY be
signed with any hash/signature algorithm pair appearing in the signed with any hash/signature algorithm pair appearing in the
extension. The naming is historical. extension. The naming is historical.
If the server has multiple certificates, it chooses one of them based If the server has multiple certificates, it chooses one of them based
on the above-mentioned criteria (in addition to other criteria, such on the above-mentioned criteria (in addition to other criteria, such
as transport layer endpoint, local configuration and preferences, as transport layer endpoint, local configuration and preferences,
etc.). etc.). If the server has a single certificate it SHOULD attempt to
validate that it meets these criteria.
Note that there are certificates that use algorithms and/or algorithm Note that there are certificates that use algorithms and/or algorithm
combinations that cannot be currently used with TLS. For example, a combinations that cannot be currently used with TLS. For example, a
certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
SubjectPublicKeyInfo) cannot be used because TLS defines no SubjectPublicKeyInfo) cannot be used because TLS defines no
corresponding signature algorithm. corresponding signature algorithm.
As CipherSuites that specify new key exchange methods are specified As cipher suites that specify new key exchange methods are specified
for the TLS Protocol, they will imply certificate format and the for the TLS Protocol, they will imply certificate format and the
required encoded keying information. required encoded keying information.
7.4.3. Server Key Exchange Message 7.4.3. Server Key Exchange Message
When this message will be sent: When this message will be sent:
This message will be sent immediately after the server certificate This message will be sent immediately after the server certificate
message (or the server hello message, if this is an anonymous message (or the server hello message, if this is an anonymous
negotiation). negotiation).
skipping to change at page 49, line 4 skipping to change at page 49, line 24
its output. its output.
struct { struct {
select (SignatureAlgorithm) { select (SignatureAlgorithm) {
case anonymous: struct { }; case anonymous: struct { };
case rsa: case rsa:
SignatureAndHashAlgorithm signature_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*/ SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
digitally-signed struct { digitally-signed struct {
opaque hash[Hash.length]; opaque hash[Hash.length];
}; };
}; };
}; };
} Signature; } Signature;
If the client has offered the "signature_algorithms" extension, the If the client has offered the "signature_algorithms" extension, the
signature algorithm and hash algorithm MUST be a pair listed in that signature algorithm and hash algorithm MUST be a pair listed in that
extension. Note that there is a possibility for inconsistencies here. extension. Note that there is a possibility for inconsistencies here.
For instance, the client might offer DHE_DSS key exchange but omit For instance, the client might offer DHE_DSS key exchange but omit
any DSS pairs from its "signature_algorithms" extension. In order to any DSS pairs from its "signature_algorithms" extension. In order to
negotiate correctly, the server MUST check any candidate cipher negotiate correctly, the server MUST check any candidate cipher
suites against the "signature_algorithms" extension before selecting suites against the "signature_algorithms" extension before selecting
them. This is somewhat inelegant but is a compromise designed to them. This is somewhat inelegant but is a compromise designed to
minimize changes to the original cipher suite design. minimize changes to the original cipher suite design.
If no "signature_algorithms" extension is present, the server MUST
use SHA-1 as the hash algorithm.
In addition, the hash and signature algorithms MUST be compatible In addition, the hash and signature algorithms MUST be compatible
with the key in the server's end-entity certificate. RSA keys MAY be with the key in the server's end-entity certificate. RSA keys MAY be
used with any permitted hash algorithm, subject to restrictions in used with any permitted hash algorithm, subject to restrictions in
the certificate, if any. the certificate, if any.
Because DSA signatures do not contain any secure indication of hash Because DSA signatures do not contain any secure indication of hash
algorithm, there is a risk of hash substitution if multiple hashes algorithm, there is a risk of hash substitution if multiple hashes
may be used with any key. Currently, DSS [DSS] may only be used with may be used with any key. Currently, DSS [DSS] may only be used with
SHA-1. Future revisions of DSS [DSS-3] are expected to allow other SHA-1. Future revisions of DSS [DSS-3] are expected to allow other
digest algorithms, as well as guidance as to which digest algorithms digest algorithms, as well as guidance as to which digest algorithms
should be used with each key size. In addition, future revisions of should be used with each key size. In addition, future revisions of
[PKIX] may specify mechanisms for certificates to indicate which [PKIX] may specify mechanisms for certificates to indicate which
digest algorithms are to be used with DSA. digest algorithms are to be used with DSA.
As additional CipherSuites are defined for TLS that include new key As additional cipher suites are defined for TLS that include new key
exchange algorithms, the server key exchange message will be sent if exchange algorithms, the server key exchange message will be sent if
and only if the certificate type associated with the key exchange and only if the certificate type associated with the key exchange
algorithm does not provide enough information for the client to algorithm does not provide enough information for the client to
exchange a premaster secret. exchange a premaster secret.
7.4.4. Certificate Request 7.4.4. Certificate Request
When this message will be sent: When this message will be sent:
A non-anonymous server can optionally request a certificate from A non-anonymous server can optionally request a certificate from
skipping to change at page 51, line 7 skipping to change at page 51, line 24
any certificate of the appropriate ClientCertificateType, unless any certificate of the appropriate ClientCertificateType, unless
there is some external arrangement to the contrary. there is some external arrangement to the contrary.
The interaction of the certificate_types and The interaction of the certificate_types and
supported_signature_algorithms fields is somewhat complicated. supported_signature_algorithms fields is somewhat complicated.
certificate_types has been present in TLS since SSLv3, but was certificate_types has been present in TLS since SSLv3, but was
somewhat underspecified. Much of its functionality is superseded by somewhat underspecified. Much of its functionality is superseded by
supported_signature_algorithms. The following rules apply: supported_signature_algorithms. The following rules apply:
- Any certificates provided by the client MUST be signed using a - Any certificates provided by the client MUST be signed using a
hash/signature algorithm pair found in supported_signature_types. hash/signature algorithm pair found in
supported_signature_algorithms.
- The end-entity certificate provided by the client MUST contain a - The end-entity certificate provided by the client MUST contain a
key which is compatible with certificate_types. If the key is a key which is compatible with certificate_types. If the key is a
signature key, it MUST be usable with some hash/signature signature key, it MUST be usable with some hash/signature
algorithm pair in supported_signature_types. algorithm pair in supported_signature_algorithms.
- For historical reasons, the names of some client certificate types - For historical reasons, the names of some client certificate types
include the algorithm used to sign the certificate. For example, include the algorithm used to sign the certificate. For example,
in earlier versions of TLS, rsa_fixed_dh meant a certificate 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 signed with RSA and containing a static DH key. In TLS 1.2, this
functionality has been obsoleted by the signature_types field, and functionality has been obsoleted by the
the certificate type no longer restricts the algorithm used to supported_signature_algorithms, and the certificate type no longer
sign the certificate. For example, if the server sends restricts the algorithm used to sign the certificate. For
dss_fixed_dh certificate type and {dss_sha1, rsa_sha1} signature example, if the server sends dss_fixed_dh certificate type and
types, the client MAY to reply with a certificate containing a {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply
static DH key, signed with RSA-SHA1. with a certificate containing a static DH key, signed with RSA-
SHA1.
New ClientCertificateType values are assigned by IANA as described in New ClientCertificateType values are assigned by IANA as described in
Section 12. Section 12.
Note: Values listed as RESERVED may not be used. They were used in Note: Values listed as RESERVED may not be used. They were used in
SSLv3. SSLv3.
Note: It is a fatal handshake_failure alert for an anonymous server Note: It is a fatal handshake_failure alert for an anonymous server
to request client authentication. to request client authentication.
skipping to change at page 52, line 18 skipping to change at page 52, line 36
7.4.6. Client Certificate 7.4.6. Client Certificate
When this message will be sent: When this message will be sent:
This is the first message the client can send after receiving a This is the first message the client can send after receiving a
server hello done message. This message is only sent if the server server hello done message. This message is only sent if the server
requests a certificate. If no suitable certificate is available, requests a certificate. If no suitable certificate is available,
the client MUST send a certificate message containing no the client MUST send a certificate message containing no
certificates. That is, the certificate_list structure has a length certificates. That is, the certificate_list structure has a length
of zero. If client authentication is required by the server for of zero. If the client does not send any certificates, the server
the handshake to continue, it may respond with a fatal handshake MAY at its discretion either continue the handshake without client
failure alert. Client certificates are sent using the Certificate authentication, or respond with a fatal handshake_failure alert.
structure defined in Section 7.4.2. Also, if some aspect of the certificate chain was unacceptable
(e.g., it was not signed by a known, trusted CA), the server MAY
at its discretion either continue the handshake (considering the
client unauthenticated) or send a fatal alert.
Client certificates are sent using the Certificate structure
defined in Section 7.4.2.
Meaning of this message: Meaning of this message:
This message conveys the client's certificate to the server; the This message conveys the client's certificate chain to the server;
server will use it when verifying the certificate verify message the server will use it when verifying the certificate verify
(when the client authentication is based on signing), or calculate message (when the client authentication is based on signing), or
the premaster secret (for non-ephemeral Diffie-Hellman). The calculate the premaster secret (for non-ephemeral Diffie-Hellman).
certificate MUST be appropriate for the negotiated cipher suite's
key exchange algorithm, and any negotiated extensions. The certificate MUST be appropriate for the negotiated cipher
suite's key exchange algorithm, and any negotiated extensions.
In particular: In particular:
- The certificate type MUST be X.509v3, unless explicitly negotiated - The certificate type MUST be X.509v3, unless explicitly negotiated
otherwise (e.g. [TLSPGP]). otherwise (e.g. [TLSPGP]).
- The certificate's public key (and associated restrictions) has to - The end-entity certificate's public key (and associated
be compatible with the certificate types listed in restrictions) has to be compatible with the certificate types
CertificateRequest: listed in CertificateRequest:
Client Cert. Type Certificate Key Type Client Cert. Type Certificate Key Type
rsa_sign RSA public key; the certificate MUST allow rsa_sign RSA public key; the certificate MUST allow
the key to be used for signing with the the key to be used for signing with the
signature scheme and hash algorithm that signature scheme and hash algorithm that
will be employed in the certificate verify will be employed in the certificate verify
message. message.
dss_sign DSA public key; the certificate MUST allow dss_sign DSA public key; the certificate MUST allow
skipping to change at page 53, line 19 skipping to change at page 53, line 44
message; the public key MUST use a message; the public key MUST use a
curve and point format supported by the curve and point format supported by the
server. server.
rsa_fixed_dh Diffie-Hellman public key; MUST use rsa_fixed_dh Diffie-Hellman public key; MUST use
dss_fixed_dh the same parameters as server's key. dss_fixed_dh the same parameters as server's key.
rsa_fixed_ecdh ECDH-capable public key; MUST use rsa_fixed_ecdh ECDH-capable public key; MUST use
ecdsa_fixed_ecdh the same curve as server's key, and ecdsa_fixed_ecdh the same curve as server's key, and
MUST use a point format supported by MUST use a point format supported by
the server.
- If the certificate_authorities list in the certificate request - If the certificate_authorities list in the certificate request
message was non-empty, the certificate SHOULD be issued by one of message was non-empty, one of the certificates in the certificate
the listed CAs. chain SHOULD be issued by one of the listed CAs.
- The certificates MUST be signed using an acceptable hash/ - The certificates MUST be signed using an acceptable hash/
signature algorithm pair, as described in Section 7.4.4. Note that signature algorithm pair, as described in Section 7.4.4. Note that
this relaxes the constraints on certificate signing algorithms this relaxes the constraints on certificate signing algorithms
found in prior versions of TLS. found in prior versions of TLS.
Note that as with the server certificate, there are certificates that Note that as with the server certificate, there are certificates that
use algorithms/algorithm combinations that cannot be currently used use algorithms/algorithm combinations that cannot be currently used
with TLS. with TLS.
skipping to change at page 55, line 16 skipping to change at page 55, line 41
offered by the client in the ClientHello.client_version, not the offered by the client in the ClientHello.client_version, not the
version negotiated for the connection. This feature is designed to version negotiated for the connection. This feature is designed to
prevent rollback attacks. Unfortunately, some old implementations prevent rollback attacks. Unfortunately, some old implementations
use the negotiated version instead and therefore checking the version use the negotiated version instead and therefore checking the version
number may lead to failure to interoperate with such incorrect client number may lead to failure to interoperate with such incorrect client
implementations. implementations.
Client implementations MUST always send the correct version number in Client implementations MUST always send the correct version number in
PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher,
server implementations MUST check the version number as described in server implementations MUST check the version number as described in
the note below. If the version number is earlier than 1.0, server the note below. If the version number is 1.0 or earlier, server
implementations SHOULD check the version number, but MAY have a implementations SHOULD check the version number, but MAY have a
configuration option to disable the check. Note that if the check configuration option to disable the check. Note that if the check
fails, the PreMasterSecret SHOULD be randomized as described below. fails, the PreMasterSecret SHOULD be randomized as described below.
Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
[KPR03] can be used to attack a TLS server that reveals whether a [KPR03] can be used to attack a TLS server that reveals whether a
particular message, when decrypted, is properly PKCS#1 formatted, particular message, when decrypted, is properly PKCS#1 formatted,
contains a valid PreMasterSecret structure, or has the correct contains a valid PreMasterSecret structure, or has the correct
version number. version number.
skipping to change at page 55, line 50 skipping to change at page 56, line 28
premaster secret = M premaster secret = M
else: else:
premaster secret = ClientHello.client_version || M[2..47] premaster secret = ClientHello.client_version || M[2..47]
In any case, a TLS server MUST NOT generate an alert if processing an In any case, a TLS server MUST NOT generate an alert if processing an
RSA-encrypted premaster secret message fails, or the version number RSA-encrypted premaster secret message fails, or the version number
is not as expected. Instead, it MUST continue the handshake with a is not as expected. Instead, it MUST continue the handshake with a
randomly generated premaster secret. It may be useful to log the randomly generated premaster secret. It may be useful to log the
real cause of failure for troubleshooting purposes; however, care real cause of failure for troubleshooting purposes; however, care
must be taken to avoid leaking the information to an attacker must be taken to avoid leaking the information to an attacker
(though, e.g., timing, log files, or other channels.) (through, e.g., timing, log files, or other channels.)
The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
against the Bleichenbacher attack. However, for maximal compatibility against the Bleichenbacher attack. However, for maximal compatibility
with earlier versions of TLS, this specification uses the RSAES- with earlier versions of TLS, this specification uses the RSAES-
PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known
to exist provided that the above recommendations are followed. to exist provided that the above recommendations are followed.
Implementation Note: Public-key-encrypted data is represented as an Implementation Note: Public-key-encrypted data is represented as an
opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
PreMasterSecret in a ClientKeyExchange is preceded by two length PreMasterSecret in a ClientKeyExchange is preceded by two length
skipping to change at page 57, line 34 skipping to change at page 58, line 12
This message is used to provide explicit verification of a client This message is used to provide explicit verification of a client
certificate. This message is only sent following a client certificate. This message is only sent following a client
certificate that has signing capability (i.e. all certificates certificate that has signing capability (i.e. all certificates
except those containing fixed Diffie-Hellman parameters). When except those containing fixed Diffie-Hellman parameters). When
sent, it MUST immediately follow the client key exchange message. sent, it MUST immediately follow the client key exchange message.
Structure of this message: Structure of this message:
struct { struct {
Signature signature; SignatureAndHashAlgorithm signature_algorithm;
digitally-signed struct {
opaque handshake_messages[handshake_messages_length];
}
} CertificateVerify; } CertificateVerify;
The Signature type is defined in 7.4.3. Here handshake_messages refers to all handshake messages sent or
received starting at client hello up to but not including this
The hash algorithm is denoted Hash below. message, including the type and length fields of the handshake
messages. This is the concatenation of all the Handshake
CertificateVerify.signature.hash = Hash(handshake_messages); structures as defined in 7.4 exchanged thus far. Note that this
requires both sides to either buffer the messages or compute
The hash and signature algorithms MUST be one of those present in the running hashes for all potential hash algorithms up to the time of
supported_signature_algorithms field of the CertificateRequest the CertificateVerify computation. Servers can minimize this
message. In addition, the hash and signature algorithms MUST be computation cost by offering a restricted set of digest algorithms
compatible with the key in the client's end-entity certificate. RSA in the CertificateRequest message.
keys MAY be used with any permitted hash algorith, subject to
restrictions in the certificate, if any.
Because DSA signatures do not contain any secure indication of hash The hash and signature algorithms used in the signature MUST be
algorithm, there is a risk of hash substitution if multiple hashes one of those present in the supported_signature_algorithms field
may be used with any key. Currently, DSS [DSS] may only be used with of the CertificateRequest message. In addition, the hash and
SHA-1. Future revisions of DSS [DSS-3] are expected to allow other signature algorithms MUST be compatible with the key in the
digest algorithms, as well as guidance as to which digest algorithms client's end-entity certificate. RSA keys MAY be used with any
should be used with each key size. In addition, future revisions of permitted hash algorith, subject to restrictions in the
[PKIX] may specify mechanisms for certificates to indicate which certificate, if any.
digest algorithms are to be used with DSA.
Here handshake_messages refers to all handshake messages sent or Because DSA signatures do not contain any secure indication of
received starting at client hello up to but not including this hash algorithm, there is a risk of hash substitution if multiple
message, including the type and length fields of the handshake hashes may be used with any key. Currently, DSS [DSS] may only be
messages. This is the concatenation of all the Handshake structures used with SHA-1. Future revisions of DSS [DSS-3] are expected to
as defined in 7.4 exchanged thus far. allow other digest algorithms, as well as guidance as to which
digest algorithms should be used with each key size. In addition,
future revisions of [PKIX] may specify mechanisms for certificates
to indicate which digest algorithms are to be used with DSA.
7.4.9. Finished 7.4.9. Finished
When this message will be sent: When this message will be sent:
A finished message is always sent immediately after a change A finished message is always sent immediately after a change
cipher spec message to verify that the key exchange and cipher spec message to verify that the key exchange and
authentication processes were successful. It is essential that a authentication processes were successful. It is essential that a
change cipher spec message be received between the other handshake change cipher spec message be received between the other handshake
messages and the Finished message. messages and the Finished message.
skipping to change at page 61, line 4 skipping to change at page 61, line 39
suite TLS_RSA_WITH_AES_128_CBC_SHA. suite TLS_RSA_WITH_AES_128_CBC_SHA.
10. Application Data Protocol 10. Application Data Protocol
Application data messages are carried by the Record Layer and are Application data messages are carried by the Record Layer and are
fragmented, compressed, and encrypted based on the current connection fragmented, compressed, and encrypted based on the current connection
state. The messages are treated as transparent data to the record state. The messages are treated as transparent data to the record
layer. layer.
11. Security Considerations 11. Security Considerations
Security issues are discussed 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
[TLS1.1]. 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.
- TLS ClientCertificateType Identifiers Registry: Future values in - TLS ClientCertificateType Identifiers Registry: Future values in
the range 0-63 (decimal) inclusive are assigned via Standards the range 0-63 (decimal) inclusive are assigned via Standards
Action [RFC2434]. Values in the range 64-223 (decimal) inclusive Action [RFC2434]. Values in the range 64-223 (decimal) inclusive
are assigned Specification Required [RFC2434]. Values from 224-255 are assigned Specification Required [RFC2434]. Values from 224-255
(decimal) inclusive are reserved for Private Use [RFC2434]. (decimal) inclusive are reserved for Private Use [RFC2434].
- TLS Cipher Suite Registry: Future values with the first byte in - TLS Cipher Suite Registry: Future values with the first byte in the
the range 0-191 (decimal) inclusive are assigned via Standards range 0-191 (decimal) inclusive are assigned via Standards Action
Action [RFC2434]. Values with the first byte in the range 192-254 [RFC2434]. Values with the first byte in the range 192-254
(decimal) are assigned via Specification Required [RFC2434]. (decimal) are assigned via Specification Required [RFC2434].
Values with the first byte 255 (decimal) are reserved for Private Values with the first byte 255 (decimal) are reserved for Private
Use [RFC2434]. Use [RFC2434]. This document defines several new HMAC-SHA256 based
cipher suites, whose values (in Appendix A.5) are to be (have
been) allocated from the TLS Cipher Suite registry.
- TLS ContentType Registry: Future values are allocated via - TLS ContentType Registry: Future values are allocated via
Standards Action [RFC2434]. Standards Action [RFC2434].
- TLS Alert Registry: Future values are allocated via Standards - TLS Alert Registry: Future values are allocated via Standards
Action [RFC2434]. Action [RFC2434].
- TLS HandshakeType Registry: Future values are allocated via - TLS HandshakeType Registry: Future values are allocated via
Standards Action [RFC2434]. Standards Action [RFC2434].
skipping to change at page 63, line 12 skipping to change at page 64, line 12
Registry, defined in [RFC3749]. IANA is requested to allocate value Registry, defined in [RFC3749]. IANA is requested to allocate value
0 for the "null" compression method. 0 for the "null" compression method.
Appendix A. Protocol Constant Values Appendix A. Protocol Constant Values
This section describes protocol types and constants. This section describes protocol types and constants.
A.1. Record Layer A.1. Record Layer
struct { struct {
uint8 major, minor; uint8 major;
uint8 minor;
} ProtocolVersion; } ProtocolVersion;
ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/ ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/
enum { enum {
change_cipher_spec(20), alert(21), handshake(22), change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255) application_data(23), (255)
} ContentType; } ContentType;
struct { struct {
skipping to change at page 69, line 19 skipping to change at page 70, line 19
struct { struct {
Signature signature; Signature signature;
} CertificateVerify; } CertificateVerify;
A.4.4. Handshake Finalization Message A.4.4. Handshake Finalization Message
struct { struct {
opaque verify_data[verify_data_length]; opaque verify_data[verify_data_length];
} Finished; } Finished;
A.5. The CipherSuite A.5. The Cipher Suite
The following values define the CipherSuite codes used in the client The following values define the cipher suite codes used in the client
hello and server hello messages. hello and server hello messages.
A CipherSuite defines a cipher specification supported in TLS Version A cipher suite defines a cipher specification supported in TLS
1.2. Version 1.2.
TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
TLS connection during the first handshake on that channel, but MUST TLS connection during the first handshake on that channel, but MUST
not be negotiated, as it provides no more protection than an not be negotiated, as it provides no more protection than an
unsecured connection. unsecured connection.
CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
The following CipherSuite definitions require that the server provide The following CipherSuite definitions require that the server provide
an RSA certificate that can be used for key exchange. The server may an RSA certificate that can be used for key exchange. The server may
request either any signature-capable certificate in the certificate request any signature-capable certificate in the certificate request
request message. message.
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
CipherSuite TLS_RSA_WITH_NULL_SHA256 = { 0x00,TBD1 };
CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F }; CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 }; CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD2 };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBD3 };
The following CipherSuite definitions are used for server- The following cipher suite definitions are used for server-
authenticated (and optionally client-authenticated) Diffie-Hellman. authenticated (and optionally client-authenticated) Diffie-Hellman.
DH denotes cipher suites in which the server's certificate contains DH denotes cipher suites in which the server's certificate contains
the Diffie-Hellman parameters signed by the certificate authority the Diffie-Hellman parameters signed by the certificate authority
(CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
parameters are signed by a a signature-capable certificate, which has parameters are signed by a a signature-capable certificate, which has
been signed by the CA. The signing algorithm used is specified after been signed by the CA. The signing algorithm used by the server is
the DH or DHE parameter. The server can request any signature-capable specified after the DHE parameter. The server can request any
certificate from the client for client authentication or it may signature-capable certificate from the client for client
request a Diffie-Hellman certificate. Any Diffie-Hellman certificate authentication or it may request a Diffie-Hellman certificate. Any
provided by the client must use the parameters (group and generator) Diffie-Hellman certificate provided by the client must use the
described by the server. parameters (group and generator) described by the server.
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 }; CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 }; CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 }; CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 }; CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 }; CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 }; CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 }; CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 }; CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD4 };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD5 };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD6 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD7 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBD8 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBD9 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBD10 };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBD11 };
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 cipher suites MUST NOT
used by TLS 1.2 implementations unless the application layer has be used by TLS 1.2 implementations unless the application layer has
specifically requested to allow anonymous key exchange. (Anonymous specifically requested to allow anonymous key exchange. (Anonymous
key exchange may sometimes be acceptable, for example, to support key exchange may sometimes be acceptable, for example, to support
opportunistic encryption when no set-up for authentication is in opportunistic encryption when no set-up for authentication is in
place, or when TLS is used as part of more complex security protocols place, or when TLS is used as part of more complex security protocols
that have other means to ensure authentication.) that have other means to ensure authentication.)
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00, TBD12 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00, TBD13 };
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.
SSLv3, TLS 1.0, and TLS 1.1 supported DES and IDEA. DES had a 56-bit SSLv3, TLS 1.0, and TLS 1.1 supported DES and IDEA. DES had a 56-bit
key which is too weak for modern use. Triple-DES (3DES) has an key which is too weak for modern use. Triple-DES (3DES) has an
effective key strength of 112 bits and is still acceptable. IDEA and effective key strength of 112 bits and is still acceptable. IDEA and
is no longer in wide use. Cipher suites using RC2, DES, and IDEA are is no longer in wide use. Cipher suites using RC2, DES, and IDEA are
hereby deprecated for TLS 1.2. TLS 1.2 implementations MUST NOT hereby deprecated for TLS 1.2. TLS 1.2 implementations MUST NOT
negotiate these cipher suites in TLS 1.2 mode. However, for backward negotiate these cipher suites in TLS 1.2 mode. However, for backward
compatibility they may be offered in the ClientHello for use with TLS compatibility they may be offered in the ClientHello for use with TLS
1.0 or SSLv3 only servers. TLS 1.2 clients MUST check that the server 1.0 or SSLv3 only servers. TLS 1.2 clients MUST check that the server
did not choose one of these cipher suites during the handshake. These did not choose one of these cipher suites during the handshake. These
ciphersuites are listed below for informational purposes and to cipher suites are listed below for informational purposes and to
reserve the numbers. reserve the numbers.
CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
skipping to change at page 76, line 27 skipping to change at page 78, line 27
The key used to encrypt data written by the server. The key used to encrypt data written by the server.
server write MAC key server write MAC key
The secret data used to authenticate data written by the server. The secret data used to authenticate data written by the server.
SHA SHA
The Secure Hash Algorithm is defined in FIPS PUB 180-2. It The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
produces a 20-byte output. Note that all references to SHA produces a 20-byte output. Note that all references to SHA
actually use the modified SHA-1 algorithm. [SHA] actually use the modified SHA-1 algorithm. [SHA]
SHA-256
The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. It
produces a 32-byte output.
SSL SSL
Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
SSL Version 3.0 SSL Version 3.0
stream cipher stream cipher
An encryption algorithm that converts a key into a An encryption algorithm that converts a key into a
cryptographically strong keystream, which is then exclusive-ORed cryptographically strong keystream, which is then exclusive-ORed
with the plaintext. with the plaintext.
symmetric cipher symmetric cipher
See bulk cipher. See bulk cipher.
Transport Layer Security (TLS) Transport Layer Security (TLS)
This protocol; also, the Transport Layer Security working group of This protocol; also, the Transport Layer Security working group of
the Internet Engineering Task Force (IETF). See "Comments" at the the Internet Engineering Task Force (IETF). See "Comments" at the
end of this document. end of this document.
Appendix C. CipherSuite Definitions Appendix C. Cipher Suite Definitions
CipherSuite Key Cipher Hash Cipher Suite Key Cipher Mac
Exchange Exchange
TLS_NULL_WITH_NULL_NULL NULL NULL NULL TLS_NULL_WITH_NULL_NULL NULL NULL NULL
TLS_RSA_WITH_NULL_MD5 RSA NULL MD5 TLS_RSA_WITH_NULL_MD5 RSA NULL MD5
TLS_RSA_WITH_NULL_SHA RSA NULL SHA TLS_RSA_WITH_NULL_SHA RSA NULL SHA
TLS_RSA_WITH_NULL_SHA256 RSA NULL SHA256
TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA
TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA
TLS_RSA_WITH_AES_128_CBC_SHA256 RSA AES_128_CBC SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256 RSA AES_256_CBC SHA256
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA256 DH_DSS AES_128_CBC SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256
Key Expanded IV Block Key Expanded IV Block
Cipher Type Material Key Material Size Size Cipher Type Material Key Material Size Size
NULL Stream 0 0 0 N/A NULL Stream 0 0 0 N/A
RC4_128 Stream 16 16 0 N/A RC4_128 Stream 16 16 0 N/A
3DES_EDE_CBC Block 24 24 8 8 3DES_EDE_CBC Block 24 24 8 8
AES_128_CBC Block 16 16 16 16
AES_256_CBC Block 32 32 16 16
MAC Algorithm mac_length mac_key_length
NULL N/A 0 0
MD5 HMAC-MD5 16 16
SHA HMAC-SHA1 20 20
SHA256 HMAC-SHA256 32 32
Type Type
Indicates whether this is a stream cipher or a block cipher Indicates whether this is a stream cipher or a block cipher
running in CBC mode. running in CBC mode.
Key Material Key Material
The number of bytes from the key_block that are used for The number of bytes from the key_block that are used for
generating the write keys. generating the write keys.
Expanded Key Material Expanded Key Material
skipping to change at page 79, line 36 skipping to change at page 81, line 36
D.2 Certificates and Authentication D.2 Certificates and Authentication
Implementations are responsible for verifying the integrity of Implementations are responsible for verifying the integrity of
certificates and should generally support certificate revocation certificates and should generally support certificate revocation
messages. Certificates should always be verified to ensure proper messages. Certificates should always be verified to ensure proper
signing by a trusted Certificate Authority (CA). The selection and signing by a trusted Certificate Authority (CA). The selection and
addition of trusted CAs should be done very carefully. Users should addition of trusted CAs should be done very carefully. Users should
be able to view information about the certificate and root CA. be able to view information about the certificate and root CA.
D.3 CipherSuites D.3 Cipher Suites
TLS supports a range of key sizes and security levels, including some TLS supports a range of key sizes and security levels, including some
that provide no or minimal security. A proper implementation will that provide no or minimal security. A proper implementation will
probably not support many cipher suites. For instance, anonymous probably not support many cipher suites. For instance, anonymous
Diffie-Hellman is strongly discouraged because it cannot prevent man- Diffie-Hellman is strongly discouraged because it cannot prevent man-
in-the-middle attacks. Applications should also enforce minimum and in-the-middle attacks. Applications should also enforce minimum and
maximum key sizes. For example, certificate chains containing 512-bit maximum key sizes. For example, certificate chains containing 512-bit
RSA keys or signatures are not appropriate for high-security RSA keys or signatures are not appropriate for high-security
applications. applications.
skipping to change at page 80, line 12 skipping to change at page 82, line 12
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:
- 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? Do you fragment handshake messages that exceed the
maximum fragment size? In particular, the certificate and
certificate request handshake messages can be large enough to
require fragmentation.
- 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)?
- 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?
- Do you support renegotiation, both client and server initiated? - Do you support renegotiation, both client and server initiated?
While renegotiation is an optional feature, supporting While renegotiation is an optional feature, supporting
it is highly recommended. it is highly recommended.
skipping to change at page 81, line 5 skipping to change at page 83, line 8
- 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)?
- 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)?
- 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)?
- Do you accept long CBC mode padding (up to 255 bytes; see
Section 6.2.3.2)?
- 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)?
- 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
skipping to change at page 83, line 30 skipping to change at page 85, line 30
would be {03,00}, the lowest version number supported by the client, would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version. No single value will and the value of ClientHello.client_version. No single value will
guarantee interoperability with all old servers, but this is a guarantee interoperability with all old servers, but this is a
complex topic beyond the scope of this document. complex topic beyond the scope of this document.
E.2 Compatibility with SSL 2.0 E.2 Compatibility with SSL 2.0
TLS 1.2 clients that wish to support SSL 2.0 servers MUST send TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST
contain the same version number as would be used for ordinary contain the same version number as would be used for ordinary
ClientHello, and MUST encode the supported TLS ciphersuites in the ClientHello, and MUST encode the supported TLS cipher suites in the
CIPHER-SPECS-DATA field as described below. CIPHER-SPECS-DATA field as described below.
Warning: The ability to send version 2.0 CLIENT-HELLO messages will Warning: The ability to send version 2.0 CLIENT-HELLO messages will
be phased out with all due haste, since the newer ClientHello format be phased out with all due haste, since the newer ClientHello format
provides better mechanisms for moving to newer versions and provides better mechanisms for moving to newer versions and
negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0. negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0.
However, even TLS servers that do not support SSL 2.0 MAY accept However, even TLS servers that do not support SSL 2.0 MAY accept
version 2.0 CLIENT-HELLO messages. The message is presented below in version 2.0 CLIENT-HELLO messages. The message is presented below in
sufficient detail for TLS server implementors; the true definition is sufficient detail for TLS server implementors; the true definition is
skipping to change at page 84, line 47 skipping to change at page 86, line 47
The length in bytes of the client's challenge to the server to The length in bytes of the client's challenge to the server to
authenticate itself. Historically, permissible values are between authenticate itself. Historically, permissible values are between
16 and 32 bytes inclusive. When using the SSLv2 backward 16 and 32 bytes inclusive. When using the SSLv2 backward
compatible handshake the client SHOULD use a 32 byte challenge. compatible handshake the client SHOULD use a 32 byte challenge.
cipher_specs cipher_specs
This is a list of all CipherSpecs the client is willing and able This is a list of all CipherSpecs the client is willing and able
to use. In addition to the 2.0 cipher specs defined in [SSL2], to use. In addition to the 2.0 cipher specs defined in [SSL2],
this includes the TLS cipher suites normally sent in this includes the TLS cipher suites normally sent in
ClientHello.cipher_suites, each cipher suite prefixed by a zero ClientHello.cipher_suites, each cipher suite prefixed by a zero
byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as byte. For example, TLS cipher suite {0x00,0x0A} would be sent as
{0x00,0x00,0x0A}. {0x00,0x00,0x0A}.
session_id session_id
This field MUST be empty. This field MUST be empty.
challenge challenge
Corresponds to ClientHello.random. If the challenge length is less Corresponds to ClientHello.random. If the challenge length is less
than 32, the TLS server will pad the data with leading (note: not than 32, the TLS server will pad the data with leading (note: not
trailing) zero bytes to make it 32 bytes long. trailing) zero bytes to make it 32 bytes long.
skipping to change at page 88, line 21 skipping to change at page 90, line 21
in the client key exchange message, then optionally uses a in the client key exchange message, then optionally uses a
certificate verify message to authenticate itself. certificate verify message to authenticate itself.
If the same DH keypair is to be used for multiple handshakes, either If the same DH keypair is to be used for multiple handshakes, either
because the client or server has a certificate containing a fixed DH because the client or server has a certificate containing a fixed DH
keypair or because the server is reusing DH keys, care must be taken keypair or because the server is reusing DH keys, care must be taken
to prevent small subgroup attacks. Implementations SHOULD follow the to prevent small subgroup attacks. Implementations SHOULD follow the
guidelines found in [SUBGROUP]. guidelines found in [SUBGROUP].
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 cipher suites 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 cipher suites.
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 that the DH group is of suitable size as defined client should verify that the DH group is of suitable size as defined
by local policy. The client SHOULD also verify that the DH public by local policy. The client SHOULD also verify that the DH public
exponent appears to be of adequate size. [KEYSIZ] provides a useful exponent appears to be of adequate size. [KEYSIZ] provides a useful
guide to the strength of various group sizes. The server MAY choose guide to the strength of various group sizes. The server MAY choose
to assist the client by providing a known group, such as those to assist the client by providing a known group, such as those
defined in [IKEALG] or [MODP]. These can be verified by simple defined in [IKEALG] or [MODP]. These can be verified by simple
comparison. comparison.
skipping to change at page 90, line 34 skipping to change at page 92, line 34
[CBCATT] describes a chosen plaintext attack on TLS that depends on [CBCATT] describes a chosen plaintext attack on TLS that depends on
knowing the IV for a record. Previous versions of TLS [TLS1.0] used knowing the IV for a record. Previous versions of TLS [TLS1.0] used
the CBC residue of the previous record as the IV and therefore the CBC residue of the previous record as the IV and therefore
enabled this attack. This version uses an explicit IV in order to enabled this attack. This version uses an explicit IV 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 cipher suite. 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 data which encryption and authentication functions are applied to the 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 and confidentiality goals are obtained with ANY pair of encryption and
MAC functions, provided that the former is secure against chosen MAC functions, provided that the former is secure against chosen
plaintext attacks and that the MAC is secure against chosen-message plaintext attacks and that the MAC is secure against chosen-message
attacks. TLS uses another method, called authenticate-then-encrypt, attacks. TLS uses another method, called authenticate-then-encrypt,
in which first a MAC is computed on the plaintext and then the in which first a MAC is computed on the plaintext and then the
concatenation of plaintext and MAC is encrypted. This method has concatenation of plaintext and MAC is encrypted. This method has
been proven secure for CERTAIN combinations of encryption functions been proven secure for CERTAIN combinations of encryption functions
and MAC functions, but it is not guaranteed to be secure in general. and MAC functions, but it is not guaranteed to be secure in general.
In particular, it has been shown that there exist perfectly secure In particular, it has been shown that there exist perfectly secure
encryption functions (secure even in the information-theoretic sense) encryption functions (secure even in the information-theoretic sense)
that combined with any secure MAC function, fail to provide the that combined with any secure MAC function, fail to provide the
confidentiality goal against an active attack. Therefore, new confidentiality goal against an active attack. Therefore, new cipher
ciphersuites and operation modes adopted into TLS need to be analyzed suites and operation modes adopted into TLS need to be analyzed under
under the authenticate-then-encrypt method to verify that they the 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 has Currently, the security of the authenticate-then-encrypt method has
been proven for some important cases. One is the case of stream been proven for some important cases. One is the case of stream
ciphers in which a computationally unpredictable pad of the length of ciphers in which a computationally unpredictable pad of the length of
the message, plus the length of the MAC tag, is produced using a the message, plus the length of the MAC tag, is produced using a
pseudo-random generator and this pad is xor-ed with the concatenation pseudo-random generator and this pad is xor-ed with the concatenation
of plaintext and MAC tag. The other is the case of CBC mode using a of plaintext and MAC tag. The other is the case of CBC mode using a
secure block cipher. In this case, security can be shown if one secure block cipher. In this case, security can be shown if one
applies one CBC encryption pass to the concatenation of plaintext and applies one CBC encryption pass to the concatenation of plaintext and
MAC and uses a new, independent, and unpredictable IV for each new MAC and uses a new, independent, and unpredictable IV for each new
skipping to change at page 92, line 11 skipping to change at page 94, line 11
The system is only as strong as the weakest key exchange and The system is only as strong as the weakest key exchange and
authentication algorithm supported, and only trustworthy authentication algorithm supported, and only trustworthy
cryptographic functions should be used. Short public keys and cryptographic functions should be used. Short public keys and
anonymous servers should be used with great caution. Implementations anonymous servers should be used with great caution. Implementations
and users must be careful when deciding which certificates and and users must be careful when deciding which certificates and
certificate authorities are acceptable; a dishonest certificate certificate authorities are acceptable; a dishonest certificate
authority can do tremendous damage. authority can do tremendous damage.
Changes in This Version Changes in This Version
[RFC Editor: Please delete this] [RFC Editor: Please delete this]
- SSLv2 backward compatibility downgraded to MAY - Added a new pitfall about fragmenting messages when necessary
[Issue #71]
- Altered DSA hash rules to more closely match FIPS186-3 and - Added Updates: RFC 4492 [Issue #83]
PKIX, plus remove OID restriction.
- verify_length no longer in SecurityParameters - Long CBC padding pitfall [Issue #73]
- Moved/cleaned up cert selection text for server cert - Fixed ProtocolVersion structure [Issue #79]
when signature_algorithms is not specified.
- Other editorial changes. - Cleaned up extensions text [Issue #78]
- Clarified alerts some [Issue #85]
- Added AES to the table in Appendix C [Issue #72]
- Tightened up when signature_algorithms is used
(it is now a MUST if you support other than SHA-1)
and the interpretation when it is absent is also a MUST
[Issue #67]
- Cleaned up "cipher suite" so it's always two words outside
of when it refers to the syntactic type [Issue #68]
- Misc editorial.
- Added support for SHA256 cipher suites
- Clarified warning alert behavior and client certificate omission
behavior [Issue #84]
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
skipping to change at page 92, line 48 skipping to change at page 95, line 17
Encryption Standard (DES)", FIPS PUB 46-3, October 1999. Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
[DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National
Institute of Standards and Technology, U.S. Department of Institute of Standards and Technology, U.S. Department of
Commerce, 2000. Commerce, 2000.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February Hashing for Message Authentication", RFC 2104, February
1997. 1997.
[IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
Series in Information Processing, v. 1, Konstanz: Hartung-
Gorre Verlag, 1992.
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
April 1992. April 1992.
[PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards [PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
(PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
3447, February 2003. 3447, February 2003.
[PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002. Revocation List (CRL) Profile", RFC 3280, April 2002.
[RC2] Rivest, R., "A Description of the RC2(r) Encryption
Algorithm", RFC 2268, March 1998.
[SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
and Source Code in C, 2nd ed.", Published by John Wiley & and Source Code in C, 2nd ed.", Published by John Wiley &
Sons, Inc. 1996. Sons, Inc. 1996.
[SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National [SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of Institute of Standards and Technology, U.S. Department of
Commerce., August 2001. Commerce., August 2001.
[REQ] Bradner, S., "Key words for use in RFCs to Indicate [REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 94, line 31 skipping to change at page 96, line 43
[FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on
implementation error", ietf-openpgp@imc.org mailing list, 27 implementation error", ietf-openpgp@imc.org mailing list, 27
August 2006, http://www.imc.org/ietf-openpgp/mail- August 2006, http://www.imc.org/ietf-openpgp/mail-
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"
[IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
Series in Information Processing, v. 1, Konstanz: Hartung-
Gorre Verlag, 1992.
[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 [KEYSIZ] Orman, H., and Hoffman, P., "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys" RFC 3766, Public Keys Used For Exchanging Symmetric Keys" RFC 3766,
April 2004. 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/,
skipping to change at page 95, line 8 skipping to change at page 97, line 23
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
Standard," version 1.5, November 1993. Standard," version 1.5, November 1993.
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
Standard," version 1.5, November 1993. Standard," version 1.5, November 1993.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RC2] Rivest, R., "A Description of the RC2(r) Encryption
Algorithm", RFC 2268, March 1998.
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
Compression Methods", RFC 3749, May 2004. Compression Methods", RFC 3749, May 2004.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
Wright, T., "Transport Layer Security (TLS) Extensions", RFC Wright, T., "Transport Layer Security (TLS) Extensions", RFC
4366, April 2006. 4366, April 2006.
[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems," Obtaining Digital Signatures and Public-Key Cryptosystems,"
Communications of the ACM, v. 21, n. 2, Feb 1978, pp. Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
skipping to change at page 95, line 52 skipping to change at page 98, line 22
[TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
Suites for Transport Layer Security (TLS)", RFC 4492, May Suites for Transport Layer Security (TLS)", RFC 4492, May
2006. 2006.
[TLSEXT] Eastlake, D.E., "Transport Layer Security (TLS) Extensions: [TLSEXT] Eastlake, D.E., "Transport Layer Security (TLS) Extensions:
Extension Definitions", July 2007, draft-ietf-tls- Extension Definitions", July 2007, draft-ietf-tls-
rfc4366-bis-00.txt. rfc4366-bis-00.txt.
[TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS
authentication", draft-ietf-tls-openpgp-keys-11, July 2006. authentication", RFC 5081, November 2007.
[TLSPSK] Eronen, P., Tschofenig, H., "Pre-Shared Key Ciphersuites for [TLSPSK] Eronen, P., Tschofenig, H., "Pre-Shared Key Ciphersuites for
Transport Layer Security (TLS)", RFC 4279, December 2005. 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.
skipping to change at page 99, line 7 skipping to change at page 101, line 7
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 (2008).
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
 End of changes. 102 change blocks. 
214 lines changed or deleted 319 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/