< draft-ietf-tls-rfc4346-bis-08.txt   draft-ietf-tls-rfc4346-bis-09.txt >
INTERNET-DRAFT Tim Dierks INTERNET-DRAFT Tim Dierks
Obsoletes (if approved): RFC 3268, 4346, 4366 Independent Obsoletes (if approved): RFC 3268, 4346, 4366 Independent
Updates (if approved): RFC 4492 Eric Rescorla Updates (if approved): RFC 4492 Eric Rescorla
Intended status: Proposed Standard Network Resonance, Inc. Intended status: Proposed Standard Network Resonance, Inc.
<draft-ietf-tls-rfc4346-bis-08.txt> January 2008 (Expires July 2008) <draft-ietf-tls-rfc4346-bis-09.txt> February 2008 (Expires August 2008)
The Transport Layer Security (TLS) Protocol The Transport Layer Security (TLS) Protocol
Version 1.2 Version 1.2
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
over the Internet. The protocol allows client/server applications to over the Internet. The protocol allows client/server applications to
communicate in a way that is designed to prevent eavesdropping, communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery. tampering, or message forgery.
Table of Contents Table of Contents
1. Introduction 4 1. Introduction 4
1.1. Requirements Terminology 5 1.1. Requirements Terminology 5
1.2. Major Differences from TLS 1.1 5 1.2. Major Differences from TLS 1.1 5
2. Goals 6 2. Goals 6
3. Goals of This Document 6 3. Goals of This Document 7
4. Presentation Language 7 4. Presentation Language 7
4.1. Basic Block Size 7 4.1. Basic Block Size 7
4.2. Miscellaneous 7 4.2. Miscellaneous 7
4.3. Vectors 8 4.3. Vectors 8
4.4. Numbers 9 4.4. Numbers 9
4.5. Enumerateds 9 4.5. Enumerateds 9
4.6. Constructed Types 10 4.6. Constructed Types 10
4.6.1. Variants 10 4.6.1. Variants 10
4.7. Cryptographic Attributes 11 4.7. Cryptographic Attributes 11
4.8. Constants 13 4.8. Constants 13
5. HMAC and the Pseudorandom Function 13 5. HMAC and the Pseudorandom Function 14
6. The TLS Record Protocol 14 6. The TLS Record Protocol 15
6.1. Connection States 15 6.1. Connection States 16
6.2. Record layer 18 6.2. Record layer 18
6.2.1. Fragmentation 18 6.2.1. Fragmentation 19
6.2.2. Record Compression and Decompression 19 6.2.2. Record Compression and Decompression 20
6.2.3. Record Payload Protection 20 6.2.3. Record Payload Protection 21
6.2.3.1. Null or Standard Stream Cipher 21 6.2.3.1. Null or Standard Stream Cipher 21
6.2.3.2. CBC Block Cipher 21 6.2.3.2. CBC Block Cipher 22
6.2.3.3. AEAD ciphers 23 6.2.3.3. AEAD ciphers 24
6.3. Key Calculation 24 6.3. Key Calculation 25
7. The TLS Handshaking Protocols 25 7. The TLS Handshaking Protocols 26
7.1. Change Cipher Spec Protocol 26 7.1. Change Cipher Spec Protocol 27
7.2. Alert Protocol 27 7.2. Alert Protocol 27
7.2.1. Closure Alerts 28 7.2.1. Closure Alerts 28
7.2.2. Error Alerts 29 7.2.2. Error Alerts 29
7.3. Handshake Protocol Overview 32 7.3. Handshake Protocol Overview 33
7.4. Handshake Protocol 35 7.4. Handshake Protocol 36
7.4.1. Hello Messages 36 7.4.1. Hello Messages 37
7.4.1.1. Hello Request 36 7.4.1.1. Hello Request 37
7.4.1.2. Client Hello 37 7.4.1.2. Client Hello 38
7.4.1.3. Server Hello 40 7.4.1.3. Server Hello 41
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 45 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 50 7.4.4. Certificate Request 50
7.4.5 Server hello done 52 7.4.5 Server hello done 51
7.4.6. Client Certificate 52 7.4.6. Client Certificate 52
7.4.7. Client Key Exchange Message 54 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 57 7.4.7.2. Client Diffie-Hellman Public Value 57
7.4.8. Certificate verify 57 7.4.8. Certificate verify 58
7.4.9. Finished 58 7.4.9. Finished 58
8. Cryptographic Computations 60 8. Cryptographic Computations 60
8.1. Computing the Master Secret 60 8.1. Computing the Master Secret 60
8.1.1. RSA 61 8.1.1. RSA 61
8.1.2. Diffie-Hellman 61 8.1.2. Diffie-Hellman 61
9. Mandatory Cipher Suites 61 9. Mandatory Cipher Suites 61
10. Application Data Protocol 61 10. Application Data Protocol 61
11. Security Considerations 61 11. Security Considerations 61
12. IANA Considerations 61 12. IANA Considerations 61
A. Protocol Constant Values 64 A. Protocol Constant Values 64
A.1. Record Layer 64 A.1. Record Layer 64
A.2. Change Cipher Specs Message 65 A.2. Change Cipher Specs Message 65
A.3. Alert Messages 65 A.3. Alert Messages 65
A.4. Handshake Protocol 66 A.4. Handshake Protocol 66
A.4.1. Hello Messages 66 A.4.1. Hello Messages 66
A.4.2. Server Authentication and Key Exchange Messages 68 A.4.2. Server Authentication and Key Exchange Messages 68
A.4.3. Client Authentication and Key Exchange Messages 69 A.4.3. Client Authentication and Key Exchange Messages 69
A.4.4. Handshake Finalization Message 70 A.4.4. Handshake Finalization Message 70
A.5. The Cipher Suite 70 A.5. The Cipher Suite 70
A.6. The Security Parameters 73 A.6. The Security Parameters 72
B. Glossary 75 A.7. Changes to RFC 4492 73
C. Cipher Suite Definitions 79 B. Glossary 73
D. Implementation Notes 81 C. Cipher Suite Definitions 78
D.1 Random Number Generation and Seeding 81 D. Implementation Notes 80
D.2 Certificates and Authentication 81 D.1 Random Number Generation and Seeding 80
D.3 Cipher Suites 81 D.2 Certificates and Authentication 80
D.4 Implementation Pitfalls 81 D.3 Cipher Suites 80
E. Backward Compatibility 84 D.4 Implementation Pitfalls 80
E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 84 E. Backward Compatibility 83
E.2 Compatibility with SSL 2.0 85 E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 83
E.3. Avoiding Man-in-the-Middle Version Rollback 87 E.2 Compatibility with SSL 2.0 84
F. Security Analysis 88 E.3. Avoiding Man-in-the-Middle Version Rollback 86
F.1. Handshake Protocol 88 F. Security Analysis 87
F.1.1. Authentication and Key Exchange 88 F.1. Handshake Protocol 87
F.1.1.1. Anonymous Key Exchange 88 F.1.1. Authentication and Key Exchange 87
F.1.1.2. RSA Key Exchange and Authentication 89 F.1.1.1. Anonymous Key Exchange 87
F.1.1.3. Diffie-Hellman Key Exchange with Authentication 89 F.1.1.2. RSA Key Exchange and Authentication 88
F.1.2. Version Rollback Attacks 90 F.1.1.3. Diffie-Hellman Key Exchange with Authentication 88
F.1.3. Detecting Attacks Against the Handshake Protocol 91 F.1.2. Version Rollback Attacks 89
F.1.4. Resuming Sessions 91 F.1.3. Detecting Attacks Against the Handshake Protocol 90
F.2. Protecting Application Data 91 F.1.4. Resuming Sessions 90
F.3. Explicit IVs 92 F.2. Protecting Application Data 90
F.4. Security of Composite Cipher Modes 92 F.3. Explicit IVs 91
F.5 Denial of Service 93 F.4. Security of Composite Cipher Modes 91
F.6 Final Notes 93 F.5 Denial of Service 92
F.6 Final Notes 92
1. Introduction 1. Introduction
The primary goal of the TLS Protocol is to provide privacy and data The primary goal of the TLS Protocol is to provide privacy and data
integrity between two communicating applications. The protocol is integrity between two communicating applications. The protocol is
composed of two layers: the TLS Record Protocol and the TLS Handshake composed of two layers: the TLS Record Protocol and the TLS Handshake
Protocol. At the lowest level, layered on top of some reliable Protocol. At the lowest level, layered on top of some reliable
transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
TLS Record Protocol provides connection security that has two basic TLS Record Protocol provides connection security that has two basic
properties: properties:
skipping to change at page 5, line 27 skipping to change at page 5, line 27
This document is a revision of the TLS 1.1 [TLS1.1] protocol which This document is a revision of the TLS 1.1 [TLS1.1] protocol which
contains improved flexibility, particularly for negotiation of contains improved flexibility, particularly for negotiation of
cryptographic algorithms. The major changes are: cryptographic algorithms. The major changes are:
- The MD5/SHA-1 combination in the PRF has been replaced with cipher - The MD5/SHA-1 combination in the PRF has been replaced with cipher
suite specified PRFs. All cipher suites in this document use suite specified PRFs. All cipher suites in this document use
P_SHA256. P_SHA256.
- The MD5/SHA-1 combination in the digitally-signed element has been - The MD5/SHA-1 combination in the digitally-signed element has been
replaced with a single hash. replaced with a single hash. Signed elements now include a field
that explicitly specifies the hash algorithm used.
- Substantial cleanup to the clients and servers ability to specify - Substantial cleanup to the clients and servers ability to specify
which hash and signature algorithms they will accept. Note that which hash and signature algorithms they will accept. Note that
this also relaxes some of the constraints on signature and hash this also relaxes some of the constraints on signature and hash
algorithms from previous versions of TLS. algorithms from previous versions of TLS.
- Addition of support for authenticated encryption with additional - Addition of support for authenticated encryption with additional
data modes. data modes.
- TLS Extensions definition and AES Cipher Suites were merged in - TLS Extensions definition and AES Cipher Suites were merged in
skipping to change at page 5, line 50 skipping to change at page 6, line 4
- Tighter checking of EncryptedPreMasterSecret version numbers. - Tighter checking of EncryptedPreMasterSecret version numbers.
- Tightened up a number of requirements. - Tightened up a number of requirements.
- Verify_data length now depends on the cipher suite (default is - Verify_data length now depends on the cipher suite (default is
still 12). still 12).
- 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.
- Added HMAC-SHA256 cipher suites - Added HMAC-SHA256 cipher suites
- IDEA and DES are now deprecated. - Removed IDEA and DES cipher suites. They are now deprecated and
will be documented in a separate document.
- Support for the SSLv2 backward-compatible hello is now a MAY, not - Support for the SSLv2 backward-compatible hello is now a MAY, not
a SHOULD. This will probably become a SHOULD NOT in the future. a SHOULD, with sending it a SHOULD not. Support will probably
become a SHOULD NOT in the future.
- Added limited "fall-through" to the presentation language to allow
multiple case arms to have the same encoding.
- Added an Implementation Pitfalls sections - Added an Implementation Pitfalls sections
- The usual clarifications and editorial work. - The usual clarifications and editorial work.
2. Goals 2. Goals
The goals of TLS Protocol, in order of their priority, are as The goals of TLS Protocol, in order of their priority, are as
follows: follows:
1. Cryptographic security: TLS should be used to establish a secure 1. Cryptographic security: TLS should be used to establish a secure
connection between two parties. connection between two parties.
2. Interoperability: Independent programmers should be able to 2. Interoperability: Independent programmers should be able to
develop applications utilizing TLS that can successfully exchange develop applications utilizing TLS that can successfully exchange
skipping to change at page 10, line 40 skipping to change at page 10, line 48
with a syntax much like that available for enumerateds. For example, with a syntax much like that available for enumerateds. For example,
T.f2 refers to the second field of the previous declaration. T.f2 refers to the second field of the previous declaration.
Structure definitions may be embedded. Structure definitions may be embedded.
4.6.1. Variants 4.6.1. Variants
Defined structures may have variants based on some knowledge that is Defined structures may have variants based on some knowledge that is
available within the environment. The selector must be an enumerated available within the environment. The selector must be an enumerated
type that defines the possible variants the structure defines. There type that defines the possible variants the structure defines. There
must be a case arm for every element of the enumeration declared in must be a case arm for every element of the enumeration declared in
the select. The body of the variant structure may be given a label the select. Case arms have limited fall-through: if two case arms
for reference. The mechanism by which the variant is selected at follow in immediate succession with no fields in between, then they
runtime is not prescribed by the presentation language. both contain the same fields. Thus, in the example below, "orange"
and "banana" both contain V2. Note that this is a new piece of syntax
in TLS 1.2.
The body of the variant structure may be given a label for reference.
The mechanism by which the variant is selected at runtime is not
prescribed by the presentation language.
struct { struct {
T1 f1; T1 f1;
T2 f2; T2 f2;
.... ....
Tn fn; Tn fn;
select (E) { select (E) {
case e1: Te1; case e1: Te1;
case e2: Te2; case e2: Te2;
.... case e3: case e4: Te3;
case en: Ten; ....
} [[fv]]; case en: Ten;
} [[fv]];
} [[Tv]]; } [[Tv]];
For example: For example:
enum { apple, orange } VariantTag; enum { apple, orange, banana } VariantTag;
struct { struct {
uint16 number; uint16 number;
opaque string<0..10>; /* variable length */ opaque string<0..10>; /* variable length */
} V1; } V1;
struct { struct {
uint32 number; uint32 number;
opaque string[10]; /* fixed length */ opaque string[10]; /* fixed length */
} V2; } V2;
struct { struct {
select (VariantTag) { /* value of selector is implicit */ select (VariantTag) { /* value of selector is implicit */
case apple: V1; /* VariantBody, tag = apple */ case apple:
case orange: V2; /* VariantBody, tag = orange */ V1; /* VariantBody, tag = apple */
case orange:
case banana:
V2; /* VariantBody, tag = orange or banana */
} variant_body; /* optional label on variant */ } variant_body; /* optional label on variant */
} VariantRecord; } VariantRecord;
Variant structures may be qualified (narrowed) by specifying a value
for the selector prior to the type. For example, an
orange VariantRecord
is a narrowed type of a VariantRecord containing a variant_body of
type V2.
4.7. Cryptographic Attributes 4.7. Cryptographic Attributes
The five cryptographic operations digital signing, stream cipher The five cryptographic operations digital signing, stream cipher
encryption, block cipher encryption, authenticated encryption with encryption, block cipher encryption, authenticated encryption with
additional data (AEAD) encryption and public key encryption are additional data (AEAD) encryption and public key encryption are
designated digitally-signed, stream-ciphered, block-ciphered, aead- designated digitally-signed, stream-ciphered, block-ciphered, aead-
ciphered, and public-key-encrypted, respectively. A field's ciphered, and public-key-encrypted, respectively. A field's
cryptographic processing is specified by prepending an appropriate cryptographic processing is specified by prepending an appropriate
key word designation before the field's type specification. key word designation before the field's type specification.
Cryptographic keys are implied by the current session state (see Cryptographic keys are implied by the current session state (see
Section 6.1). Section 6.1).
In digital signing, one-way hash functions are used as input for a A digitally-signed element is encoded as a struct DigitallySigned:
signing algorithm. A digitally-signed element is encoded as an opaque
vector <0..2^16-1>, where the length is specified by the signing struct {
algorithm and key. SignatureAndHashAlgorithm algorithm;
opaque signature<0..2^16-1>;
} DigitallySigned;
The algorithm field specifies the algorithm used (see Section
7.4.1.4.1 for the definition of this field.) Note that the
introduction of the algorithm field is a change from previous
versions. The signature is a digital signature using those
algorithms over the contents of the element. The contents themselves
do not appear on the wire but are simply calculated. The length of
the signature is specified by the signing algorithm and key.
In RSA signing, the opaque vector contains the signature generated In RSA signing, the opaque vector contains the signature generated
using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As
discussed in [PKCS1], the DigestInfo MUST be DER encoded and for hash discussed in [PKCS1], the DigestInfo MUST be DER encoded and for hash
algorithms without parameters (which include SHA-1) the algorithms without parameters (which include SHA-1) the
DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but
implementations MUST accept both without parameters and with NULL implementations MUST accept both without parameters and with NULL
parameters. Note that earlier versions of TLS used a different RSA parameters. Note that earlier versions of TLS used a different RSA
signature scheme which did not include a DigestInfo encoding. signature scheme which did not include a DigestInfo encoding.
skipping to change at page 13, line 10 skipping to change at page 13, line 30
algorithm and key. algorithm and key.
RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
defined in [PKCS1]. defined in [PKCS1].
In the following example In the following example
stream-ciphered struct { stream-ciphered struct {
uint8 field1; uint8 field1;
uint8 field2; uint8 field2;
digitally-signed opaque hash[20]; digitally-signed opaque {
uint8 field3<0..255>;
uint8 field4;
};
} UserType; } UserType;
the contents of hash are used as input for the signing algorithm, and The contents of the inner struct (field3 and field4) are used as
then the entire structure is encrypted with a stream cipher. The input for the signature/hash algorithm, and then the entire structure
length of this structure, in bytes, would be equal to two bytes for is encrypted with a stream cipher. The length of this structure, in
field1 and field2, plus two bytes for the length of the signature, bytes, would be equal to two bytes for field1 and field2, plus two
plus the length of the output of the signing algorithm. This is known bytes for the signature and hash algorithm, plus two bytes for the
because the algorithm and key used for the signing are known prior to length of the signature, plus the length of the output of the signing
encoding or decoding this structure. algorithm. This is known because the algorithm and key used for the
signing are known prior to encoding or decoding this structure.
4.8. Constants 4.8. Constants
Typed constants can be defined for purposes of specification by Typed constants can be defined for purposes of specification by
declaring a symbol of the desired type and assigning values to it. declaring a symbol of the desired type and assigning values to it.
Under-specified types (opaque, variable length vectors, and Under-specified types (opaque, variable length vectors, and
structures that contain opaque) cannot be assigned values. No fields structures that contain opaque) cannot be assigned values. No fields
of a multi-element structure or vector may be elided. of a multi-element structure or vector may be elided.
For example: For example:
skipping to change at page 19, line 14 skipping to change at page 19, line 40
type type
The higher-level protocol used to process the enclosed fragment. The higher-level protocol used to process the enclosed fragment.
version version
The version of the protocol being employed. This document The version of the protocol being employed. This document
describes TLS Version 1.2, which uses the version { 3, 3 }. The describes TLS Version 1.2, which uses the version { 3, 3 }. The
version value 3.3 is historical, deriving from the use of 3.1 for version value 3.3 is historical, deriving from the use of 3.1 for
TLS 1.0. (See Appendix A.1). Note that a client that supports TLS 1.0. (See Appendix A.1). Note that a client that supports
multiple versions of TLS may not know what version will be multiple versions of TLS may not know what version will be
employed before it receives ServerHello. See Appendix E for employed before it receives the ServerHello. See Appendix E for
discussion about what record layer version number should be discussion about what record layer version number should be
employed for ClientHello. employed for ClientHello.
length length
The length (in bytes) of the following TLSPlaintext.fragment. The The length (in bytes) of the following TLSPlaintext.fragment. The
length MUST NOT exceed 2^14. length MUST NOT exceed 2^14.
fragment fragment
The application data. This data is transparent and treated as an The application data. This data is transparent and treated as an
independent block to be dealt with by the higher-level protocol independent block to be dealt with by the higher-level protocol
skipping to change at page 25, line 32 skipping to change at page 26, line 7
until enough output has been generated. Then the key_block is until enough output has been generated. Then the key_block is
partitioned as follows: partitioned as follows:
client_write_MAC_key[SecurityParameters.mac_key_length] client_write_MAC_key[SecurityParameters.mac_key_length]
server_write_MAC_key[SecurityParameters.mac_key_length] server_write_MAC_key[SecurityParameters.mac_key_length]
client_write_key[SecurityParameters.enc_key_length] client_write_key[SecurityParameters.enc_key_length]
server_write_key[SecurityParameters.enc_key_length] server_write_key[SecurityParameters.enc_key_length]
client_write_IV[SecurityParameters.fixed_iv_length] client_write_IV[SecurityParameters.fixed_iv_length]
server_write_IV[SecurityParameters.fixed_iv_length] server_write_IV[SecurityParameters.fixed_iv_length]
The client_write_IV and server_write_IV are only generated for Currently, the client_write_IV and server_write_IV are only generated
implicit nonce techniques as described in Section 3.2.1 of [AEAD]. for implicit nonce techniques as described in Section 3.2.1 of
[AEAD].
Implementation note: The currently defined cipher suite which Implementation note: The currently defined cipher suite which
requires the most material is AES_256_CBC_SHA. It requires 2 x 32 requires the most material is AES_256_CBC_SHA256. It requires 2 x 32
byte keys and 2 x 20 byte MAC keys, for a total 104 bytes of key byte keys and 2 x 32 byte MAC keys, for a total 128 bytes of key
material. material.
7. The TLS Handshaking Protocols 7. The TLS Handshaking Protocols
TLS has three subprotocols that are used to allow peers to agree upon TLS has three subprotocols that are used to allow peers to agree upon
security parameters for the record layer, to authenticate themselves, security parameters for the record layer, to authenticate themselves,
to instantiate negotiated security parameters, and to report error to instantiate negotiated security parameters, and to report error
conditions to each other. conditions to each other.
The Handshake Protocol is responsible for negotiating a session, The Handshake Protocol is responsible for negotiating a session,
skipping to change at page 32, line 26 skipping to change at page 32, line 51
process might receive security parameters (key length, process might receive security parameters (key length,
authentication, etc.) at startup and it might be difficult to authentication, etc.) at startup and it might be difficult to
communicate changes to these parameters after that point. This communicate changes to these parameters after that point. This
message is always a warning. message is always a warning.
unsupported_extension unsupported_extension
sent by clients that receive an extended server hello containing sent by clients that receive an extended server hello containing
an extension that they did not put in the corresponding client an extension that they did not put in the corresponding client
hello. This message is always fatal. hello. This message is always fatal.
For all errors where an alert level is not explicitly specified, the
sending party MAY determine at its discretion whether this is a fatal
error or not; if an alert with a level of warning is received, the
receiving party MAY decide at its discretion whether to treat this as
a fatal error or not. However, all messages that are transmitted
with a level of fatal MUST be treated as fatal messages.
New Alert values are assigned by IANA as described in Section 12. New Alert values are assigned by IANA as described in Section 12.
7.3. Handshake Protocol Overview 7.3. Handshake Protocol Overview
The cryptographic parameters of the session state are produced by the The cryptographic parameters of the session state are produced by the
TLS Handshake Protocol, which operates on top of the TLS Record TLS Handshake Protocol, which operates on top of the TLS Record
Layer. When a TLS client and server first start communicating, they Layer. When a TLS client and server first start communicating, they
agree on a protocol version, select cryptographic algorithms, agree on a protocol version, select cryptographic algorithms,
optionally authenticate each other, and use public-key encryption optionally authenticate each other, and use public-key encryption
techniques to generate shared secrets. techniques to generate shared secrets.
skipping to change at page 39, line 5 skipping to change at page 39, line 20
protected by the Finished messages exchanged at the end of the protected by the Finished messages exchanged at the end of the
handshake.) handshake.)
The cipher suite list, passed from the client to the server in the The cipher suite list, passed from the client to the server in the
client hello message, contains the combinations of cryptographic 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 cipher suite defines a key preference (favorite choice first). Each cipher suite defines a key
exchange algorithm, a bulk encryption algorithm (including secret key exchange algorithm, a bulk encryption algorithm (including secret key
length), a MAC algorithm, and a PRF. The server will select a cipher length), a MAC algorithm, and a PRF. The server will select a cipher
suite or, if no acceptable choices are presented, return a handshake suite or, if no acceptable choices are presented, return a handshake
failure alert and close the connection. failure alert and close the connection. If the list contains cipher
suites the server does not recognize, support, or wish to use, the
server MUST ignore those cipher suites, and process the remaining
ones as usual.
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
The client hello includes a list of compression algorithms supported The client hello includes a list of compression algorithms supported
by the client, ordered according to the client's preference. by the client, ordered according to the client's preference.
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
skipping to change at page 44, line 41 skipping to change at page 45, line 8
If the client does not send the signature_algorithms extension, the If the client does not send the signature_algorithms extension, the
server MUST assume the following: server MUST assume the following:
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent
the value (sha1,rsa). the value (sha1,rsa).
- If the negotiated key exchange algorithm is one of (DHE_DSS, - If the negotiated key exchange algorithm is one of (DHE_DSS,
DH_DSS), behave as if the client had sent the value (sha1,dsa). DH_DSS), behave as if the client had sent the value (sha1,dsa).
- If the negotiated key exchnage algorithm is one of (ECDH_ECDSA, - If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa). ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa).
Note: this is a change from TLS 1.1 where there are no explicit rules Note: this is a change from TLS 1.1 where there are no explicit rules
but as a practical matter one can assume that the peer supports MD5 but as a practical matter one can assume that the peer supports MD5
and SHA-1. and SHA-1.
Note: this extension is not meaningful for TLS versions prior to 1.2. Note: this extension is not meaningful for TLS versions prior to 1.2.
Clients MUST NOT offer it if they are offering prior versions. Clients MUST NOT offer it if they are offering prior versions.
However, even if clients do offer it, the rules specified in [TLSEXT] However, even if clients do offer it, the rules specified in [TLSEXT]
require servers to ignore extensions they do not understand. require servers to ignore extensions they do not understand.
skipping to change at page 46, line 51 skipping to change at page 47, line 17
by the client, as described in [TLSECC]. by the client, as described in [TLSECC].
ECDHE_ECDSA ECDSA-capable public key; the certificate ECDHE_ECDSA ECDSA-capable public key; the certificate
MUST allow the key to be used for signing MUST allow the key to be used for signing
with the hash algorithm that will be with the hash algorithm that will be
employed in the server key exchange employed in the server key exchange
message. The public key MUST use a curve message. The public key MUST use a curve
and point format supported by the client, and point format supported by the client,
as described in [TLSECC]. as described in [TLSECC].
- The "server_name" and "trusted_ca_keys" extensions [4366bis] are - The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are
used to guide certificate selection. used to guide certificate selection.
If the client provided a "signature_algorithms" extension, then all If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a certificates provided by the server MUST be signed by a
hash/signature algorithm pair that appears in that extension. Note hash/signature algorithm pair that appears in that extension. Note
that this implies that a certificate containing a key for one that this implies that a certificate containing a key for one
signature algorithm MAY be signed using a different signature signature algorithm MAY be signed using a different signature
algorithm (for instance, an RSA key signed with a DSA key.) This is a algorithm (for instance, an RSA key signed with a DSA key.) This is a
departure from TLS 1.1, which required that the algorithms be the departure from TLS 1.1, which required that the algorithms be the
same. Note that this also implies that the DH_DSS, DH_RSA, same. Note that this also implies that the DH_DSS, DH_RSA,
skipping to change at page 48, line 19 skipping to change at page 48, line 35
Meaning of this message: Meaning of this message:
This message conveys cryptographic information to allow the client This message conveys cryptographic information to allow the client
to communicate the premaster secret: a Diffie-Hellman public key to communicate the premaster secret: a Diffie-Hellman public key
with which the client can complete a key exchange (with the result with which the client can complete a key exchange (with the result
being the premaster secret) or a public key for some other being the premaster secret) or a public key for some other
algorithm. algorithm.
Structure of this message: Structure of this message:
enum { diffie_hellman, rsa } KeyExchangeAlgorithm; enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa }
KeyExchangeAlgorithm;
struct { struct {
opaque dh_p<1..2^16-1>; opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>; opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>; opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */ } ServerDHParams; /* Ephemeral DH parameters */
dh_p dh_p
The prime modulus used for the Diffie-Hellman operation. The prime modulus used for the Diffie-Hellman operation.
dh_g dh_g
The generator used for the Diffie-Hellman operation. The generator used for the Diffie-Hellman operation.
dh_Ys dh_Ys
The server's Diffie-Hellman public value (g^X mod p). The server's Diffie-Hellman public value (g^X mod p).
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case diffie_hellman: case dh_anon:
ServerDHParams params; ServerDHParams params;
Signature signed_params; case dhe_dss:
}; case dhe_rsa:
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params; ServerDHParams params;
digitally-signed struct {
opaque client_random[32];
opaque server_random[32];
ServerDHParams params;
} signed_params;
case rsa:
case dh_dss:
case dh_rsa:
struct {} ;
/* message is omitted for rsa, dh_dss, and dh_rsa */
}; };
} ServerParams; } ServerKeyExchange;
params params
The server's key exchange parameters. The server's key exchange parameters.
signed_params signed_params
For non-anonymous key exchanges, a hash of the corresponding For non-anonymous key exchanges, a signature over the
params value, with the signature appropriate to that hash server's key exchange parameters.
applied.
hash
Hash(ClientHello.random + ServerHello.random + ServerParams)
where Hash is the chosen hash value and Hash.length is
its output.
struct {
select (SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
digitally-signed struct {
opaque hash[Hash.length];
};
case dsa:
SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
digitally-signed struct {
opaque hash[Hash.length];
};
};
};
} 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.
skipping to change at page 53, line 44 skipping to change at page 53, line 41
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. the server.
- If the certificate_authorities list in the certificate request - If the certificate_authorities list in the certificate request
message was non-empty, one of the certificates in the certificate message was non-empty, one of the certificates in the certificate
chain SHOULD be issued by one of the listed CAs. chain SHOULD be issued by one of the listed CAs.
- The certificates MUST be signed using an acceptable hash/ - The certificates MUST be signed using an acceptable hash/
signature algorithm pair, as described in Section 7.4.4. Note that signature algorithm pair, as described in Section 7.4.4. Note that
this relaxes the constraints on certificate signing algorithms this relaxes the constraints on certificate signing algorithms
found in prior versions of TLS. found in prior versions of TLS.
skipping to change at page 54, line 40 skipping to change at page 54, line 37
then this message MUST be sent but MUST be empty. then this message MUST be sent but MUST be empty.
Structure of this message: Structure of this message:
The choice of messages depends on which key exchange method has The choice of messages depends on which key exchange method has
been selected. See Section 7.4.3 for the KeyExchangeAlgorithm been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
definition. definition.
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret; case rsa:
case diffie_hellman: ClientDiffieHellmanPublic; EncryptedPreMasterSecret;
case dhe_dss:
case dhe_rsa:
case dh_dss:
case dh_rsa:
case dh_anon:
ClientDiffieHellmanPublic;
} exchange_keys; } exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
7.4.7.1. RSA Encrypted Premaster Secret Message 7.4.7.1. RSA Encrypted Premaster Secret Message
Meaning of this message: Meaning of this message:
If RSA is being used for key agreement and authentication, the If RSA is being used for key agreement and authentication, the
client generates a 48-byte premaster secret, encrypts it using the client generates a 48-byte premaster secret, encrypts it using the
public key from the server's certificate and sends the result in public key from the server's certificate and sends the result in
skipping to change at page 56, line 22 skipping to change at page 56, line 23
3. If the PKCS#1 padding is not correct, or the length of 3. If the PKCS#1 padding is not correct, or the length of
message M is not exactly 48 bytes: message M is not exactly 48 bytes:
premaster secret = ClientHello.client_version || R premaster secret = ClientHello.client_version || R
else If ClientHello.client_version <= TLS 1.0, and else If ClientHello.client_version <= TLS 1.0, and
version number check is explicitly disabled: version number check is explicitly disabled:
premaster secret = M premaster secret = M
else: else:
premaster secret = ClientHello.client_version || M[2..47] premaster secret = ClientHello.client_version || M[2..47]
Note that explicitly constructing the premaster_secret with the
ClientHello.client_version produces an invalid master_secret if the
client has sent the wrong version in the original premaster_secret.
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
(through, 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
skipping to change at page 58, line 12 skipping to change at page 58, line 18
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 {
SignatureAndHashAlgorithm signature_algorithm;
digitally-signed struct { digitally-signed struct {
opaque handshake_messages[handshake_messages_length]; opaque handshake_messages[handshake_messages_length];
} }
} CertificateVerify; } CertificateVerify;
Here handshake_messages refers to all handshake messages sent or Here handshake_messages refers to all handshake messages sent or
received starting at client hello up to but not including this received starting at client hello up to but not including this
message, including the type and length fields of the handshake message, including the type and length fields of the handshake
messages. This is the concatenation of all the Handshake messages. This is the concatenation of all the Handshake
structures as defined in 7.4 exchanged thus far. Note that this structures as defined in 7.4 exchanged thus far. Note that this
skipping to change at page 62, line 7 skipping to change at page 62, line 7
[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 the - TLS Cipher Suite Registry: Future values with the first byte in
range 0-191 (decimal) inclusive are assigned via Standards Action the range 0-191 (decimal) inclusive are assigned via Standards
[RFC2434]. Values with the first byte in the range 192-254 Action [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]. This document defines several new HMAC-SHA256 based Use [RFC2434].
cipher suites, whose values (in Appendix A.5) are to be (have
been) allocated from the TLS Cipher Suite registry. - 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 68, line 22 skipping to change at page 68, line 22
supported_signature_algorithms<2..2^16-1>; supported_signature_algorithms<2..2^16-1>;
A.4.2. Server Authentication and Key Exchange Messages A.4.2. Server Authentication and Key Exchange Messages
opaque ASN.1Cert<2^24-1>; opaque ASN.1Cert<2^24-1>;
struct { struct {
ASN.1Cert certificate_list<0..2^24-1>; ASN.1Cert certificate_list<0..2^24-1>;
} Certificate; } Certificate;
enum { rsa, diffie_hellman } KeyExchangeAlgorithm; enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa}
KeyExchangeAlgorithm;
struct { struct {
opaque dh_p<1..2^16-1>; opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>; opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>; opaque dh_Ys<1..2^16-1>;
} ServerDHParams; } ServerDHParams; /* Ephemeral DH parameters */
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case diffie_hellman: case dh_anon:
ServerDHParams params; ServerDHParams params;
Signature signed_params; case dhe_dss:
} case dhe_rsa:
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params; ServerDHParams params;
};
} ServerParams;
struct {
select (SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
digitally-signed struct { digitally-signed struct {
opaque hash[Hash.length]; opaque client_random[32];
opaque server_random[32];
}; ServerDHParams params;
case dsa: } signed_params;
SignatureAndHashAlgorithm signature_algorithm; /*NEW*/ case rsa:
digitally-signed struct { case dh_dss:
opaque hash[Hash.length]; case dh_rsa:
}; struct {} ;
}; /* message is omitted for rsa, dh_dss, and dh_rsa */
}; };
} Signature; } ServerKeyExchange;
enum { enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20), fortezza_dms_RESERVED(20),
(255) (255)
} ClientCertificateType; } ClientCertificateType;
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
struct { struct {
ClientCertificateType certificate_types<1..2^8-1>; ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest; } CertificateRequest;
struct { } ServerHelloDone; struct { } ServerHelloDone;
A.4.3. Client Authentication and Key Exchange Messages A.4.3. Client Authentication and Key Exchange Messages
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret; case rsa:
case diffie_hellman: ClientDiffieHellmanPublic; EncryptedPreMasterSecret;
case dhe_dss:
case dhe_rsa:
case dh_dss:
case dh_rsa:
case dh_anon:
ClientDiffieHellmanPublic;
} exchange_keys; } exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
struct { struct {
ProtocolVersion client_version; ProtocolVersion client_version;
opaque random[46]; opaque random[46];
} PreMasterSecret; } PreMasterSecret;
struct { struct {
public-key-encrypted PreMasterSecret pre_master_secret; public-key-encrypted PreMasterSecret pre_master_secret;
skipping to change at page 70, line 8 skipping to change at page 70, line 4
} EncryptedPreMasterSecret; } EncryptedPreMasterSecret;
enum { implicit, explicit } PublicValueEncoding; enum { implicit, explicit } PublicValueEncoding;
struct { struct {
select (PublicValueEncoding) { select (PublicValueEncoding) {
case implicit: struct {}; case implicit: struct {};
case explicit: opaque DH_Yc<1..2^16-1>; case explicit: opaque DH_Yc<1..2^16-1>;
} dh_public; } dh_public;
} ClientDiffieHellmanPublic; } ClientDiffieHellmanPublic;
struct { struct {
Signature signature; digitally-signed struct {
opaque handshake_messages[handshake_messages_length];
}
} 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 Cipher Suite A.5. The Cipher Suite
The following values define the cipher suite 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 cipher suite defines a cipher specification supported in TLS A cipher suite defines a cipher specification supported in TLS
Version 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 any signature-capable certificate in the certificate request request any signature-capable certificate in the certificate request
message. message.
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
skipping to change at page 71, line 28 skipping to change at page 71, line 25
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 }; CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 }; CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 }; CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 }; CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 }; CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 }; CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 }; CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 }; CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD4 }; CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD4};
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD5 }; CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD5};
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD6 }; CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD6};
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD7 }; CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD7};
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBD8 }; CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBD8};
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBD9 }; CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBD9};
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBD10 }; CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBDA};
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBD11 }; CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBDB};
The following cipher suites are used for completely anonymous Diffie- The following cipher suites are used for completely anonymous Diffie-
Hellman communications in which neither party is authenticated. Note Hellman communications in which neither party is authenticated. Note
that this mode is vulnerable to man-in-the-middle attacks. Using that this mode is vulnerable to man-in-the-middle attacks. Using
this mode therefore is of limited use: These cipher suites MUST NOT this mode therefore is of limited use: These cipher suites MUST NOT
be used by TLS 1.2 implementations unless the application layer has be used by TLS 1.2 implementations unless the application layer has
specifically requested to allow anonymous key exchange. (Anonymous specifically requested to allow anonymous key exchange. (Anonymous
key exchange may sometimes be acceptable, for example, to support key exchange may sometimes be acceptable, for example, to support
opportunistic encryption when no set-up for authentication is in opportunistic encryption when no set-up for authentication is in
place, or when TLS is used as part of more complex security protocols place, or when TLS is used as part of more complex security protocols
that have other means to ensure authentication.) that have other means to ensure authentication.)
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00, TBD12 }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00, TBDC};
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00, TBD13 }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00, TBDD};
Note that using non-anonymous key exchange without actually verifying Note that using non-anonymous key exchange without actually verifying
the key exchange is essentially equivalent to anonymous key exchange, the key exchange is essentially equivalent to anonymous key exchange,
and the same precautions apply. While non-anonymous key exchange and the same precautions apply. While non-anonymous key exchange
will generally involve a higher computational and communicational will generally involve a higher computational and communicational
cost than anonymous key exchange, it may be in the interest of cost than anonymous key exchange, it may be in the interest of
interoperability not to disable non-anonymous key exchange when the interoperability not to disable non-anonymous key exchange when the
application layer is allowing anonymous key exchange. application layer is allowing anonymous key exchange.
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
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
hereby deprecated for TLS 1.2. TLS 1.2 implementations MUST NOT
negotiate these cipher suites in TLS 1.2 mode. However, for backward
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
did not choose one of these cipher suites during the handshake. These
cipher suites are listed below for informational purposes and to
reserve the numbers.
CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
When SSLv3 and TLS 1.0 were designed, the United States restricted
the export of cryptographic software containing certain strong
encryption algorithms. A series of cipher suites were designed to
operate at reduced key lengths in order to comply with those
regulations. Due to advances in computer performance, these
algorithms are now unacceptably weak and export restrictions have
since been loosened. TLS 1.2 implementations MUST NOT negotiate these
cipher suites in TLS 1.2 mode. However, for backward 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 did not
choose one of these cipher suites during the handshake. These
ciphersuites are listed below for informational purposes and to
reserve the numbers.
CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
New cipher suite values are assigned by IANA as described in Section New cipher suite values are assigned by IANA as described in Section
12. 12.
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
reserved to avoid collision with Fortezza-based cipher suites in SSL reserved to avoid collision with Fortezza-based cipher suites in SSL
3. 3.
A.6. The Security Parameters A.6. The Security Parameters
These security parameters are determined by the TLS Handshake These security parameters are determined by the TLS Handshake
skipping to change at page 75, line 5 skipping to change at page 73, line 12
uint8 record_iv_length; uint8 record_iv_length;
MACAlgorithm mac_algorithm; MACAlgorithm mac_algorithm;
uint8 mac_length; uint8 mac_length;
uint8 mac_key_length; uint8 mac_key_length;
CompressionMethod compression_algorithm; CompressionMethod compression_algorithm;
opaque master_secret[48]; opaque master_secret[48];
opaque client_random[32]; opaque client_random[32];
opaque server_random[32]; opaque server_random[32];
} SecurityParameters; } SecurityParameters;
A.7. Changes to RFC 4492
RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This
document changes some of the structures used in that document. This
section details the required changes for implementors of both RFC
4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing
RFC 4492 do not need to read this section.
This document adds a "signature_algorithm" field to the digitally-
signed element in order to identify the signature and digest
algorithms used to create a signature. This change applies to digital
signatures formed using ECDSA as well, thus allowing ECDSA signatures
to be used and digest algorithms other than SHA-1, provided such use
is compatible with the certificate and any restrictions imposed by
future revisions of [PKIX].
As described in Sections 7.4.2 and 7.4.6, the restrictions on the
signature algorithms used to sign certificates are no longer tied to
the cipher suite (when used by the server) or the
ClientCertificateType (when used by the client). Thus, the
restrictions on the algorithm used to sign certificates specified in
Sections 2 and 3 of RFC 4492 are also relaxed. As in this document
the restrictions on the keys in the end-entity certificate remain.
Appendix B. Glossary Appendix B. Glossary
Advanced Encryption Standard (AES) Advanced Encryption Standard (AES)
AES is a widely used symmetric encryption algorithm. AES is a AES is a widely used symmetric encryption algorithm. AES is a
block cipher with a 128, 192, or 256 bit keys and a 16 byte block block cipher with a 128, 192, or 256 bit keys and a 16 byte block
size. [AES] TLS currently only supports the 128 and 256 bit key size. [AES] TLS currently only supports the 128 and 256 bit key
sizes. sizes.
application protocol application protocol
An application protocol is a protocol that normally layers An application protocol is a protocol that normally layers
skipping to change at page 77, line 6 skipping to change at page 75, line 38
handshake handshake
An initial negotiation between client and server that establishes An initial negotiation between client and server that establishes
the parameters of their transactions. the parameters of their transactions.
Initialization Vector (IV) Initialization Vector (IV)
When a block cipher is used in CBC mode, the initialization vector When a block cipher is used in CBC mode, the initialization vector
is exclusive-ORed with the first plaintext block prior to is exclusive-ORed with the first plaintext block prior to
encryption. encryption.
IDEA
A 64-bit block cipher designed by Xuejia Lai and James Massey.
[IDEA]
Message Authentication Code (MAC) Message Authentication Code (MAC)
A Message Authentication Code is a one-way hash computed from a A Message Authentication Code is a one-way hash computed from a
message and some secret data. It is difficult to forge without message and some secret data. It is difficult to forge without
knowing the secret data. Its purpose is to detect if the message knowing the secret data. Its purpose is to detect if the message
has been altered. has been altered.
master secret master secret
Secure secret data used for generating encryption keys, MAC Secure secret data used for generating encryption keys, MAC
secrets, and IVs. secrets, and IVs.
skipping to change at page 77, line 36 skipping to change at page 76, line 15
Messages encrypted with the public key can only be decrypted with Messages encrypted with the public key can only be decrypted with
the associated private key. Conversely, messages signed with the the associated private key. Conversely, messages signed with the
private key can be verified with the public key. private key can be verified with the public key.
one-way hash function one-way hash function
A one-way transformation that converts an arbitrary amount of data A one-way transformation that converts an arbitrary amount of data
into a fixed-length hash. It is computationally hard to reverse into a fixed-length hash. It is computationally hard to reverse
the transformation or to find collisions. MD5 and SHA are examples the transformation or to find collisions. MD5 and SHA are examples
of one-way hash functions. of one-way hash functions.
RC2
A block cipher developed by Ron Rivest, described in [RC2].
RC4 RC4
A stream cipher invented by Ron Rivest. A compatible cipher is A stream cipher invented by Ron Rivest. A compatible cipher is
described in [SCH]. described in [SCH].
RSA RSA
A very widely used public-key algorithm that can be used for A very widely used public-key algorithm that can be used for
either encryption or digital signing. [RSA] either encryption or digital signing. [RSA]
server server
The server is the application entity that responds to requests for The server is the application entity that responds to requests for
skipping to change at page 79, line 7 skipping to change at page 78, line 7
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. Cipher Suite Definitions Appendix C. Cipher Suite Definitions
Cipher Suite Key Cipher Mac 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_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_128_CBC_SHA256 RSA AES_128_CBC SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256 RSA AES_256_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_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_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256 TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256 TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256 TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256 TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256
Key Expanded IV Block Key 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_128_CBC Block 16 16 16 16
AES_256_CBC Block 32 32 16 16 AES_256_CBC Block 32 32 16 16
skipping to change at page 94, line 43 skipping to change at page 93, line 43
- Cleaned up "cipher suite" so it's always two words outside - Cleaned up "cipher suite" so it's always two words outside
of when it refers to the syntactic type [Issue #68] of when it refers to the syntactic type [Issue #68]
- Misc editorial. - Misc editorial.
- Added support for SHA256 cipher suites - Added support for SHA256 cipher suites
- Clarified warning alert behavior and client certificate omission - Clarified warning alert behavior and client certificate omission
behavior [Issue #84] behavior [Issue #84]
- Removed IDEA and DES entirely for documentation in a separate doc
[Issue #64]
- Changed the presentation language to allow fall-through to simplify
some of the PDUs.
- Cleaned up KeyExchangeAlgorithm ClientKeyExchange to use values
that match Appendix C.
- Changed digitally-signed to include SignatureAndHashAlgorithm
(another simplification)
- Considerations for RFC 4492
Normative References Normative References
[AES] National Institute of Standards and Technology, [AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard (AES)" "Specification for the Advanced Encryption Standard (AES)"
FIPS 197. November 26, 2001. FIPS 197. November 26, 2001.
[3DES] National Institute of Standards and Technology, [3DES] National Institute of Standards and Technology,
"Recommendation for the Triple Data Encryption Algorithm "Recommendation for the Triple Data Encryption Algorithm
(TDEA) Block Cipher", NIST Special Publication 800-67, May (TDEA) Block Cipher", NIST Special Publication 800-67, May
2004. 2004.
skipping to change at page 95, line 45 skipping to change at page 95, line 12
[REQ] Bradner, S., "Key words for use in RFCs to Indicate [REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 25, RFC 2434, IANA Considerations Section in RFCs", BCP 25, RFC 2434,
October 1998. October 1998.
Informative References Informative References
[AEAD] Mcgrew, D., "Authenticated Encryption", February 2007, [AEAD] Mcgrew, D., "Authenticated Encryption", July 2007, draft-
draft-mcgrew-auth-enc-02.txt. mcgrew-auth-enc-05.txt.
[AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC
4302, December 2005. 4302, December 2005.
[BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS #1" in Protocols Based on RSA Encryption Standard PKCS #1" in
Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
1-12, 1998. 1-12, 1998.
[CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
skipping to change at page 96, line 43 skipping to change at page 96, line 9
[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 97, line 23 skipping to change at page 96, line 34
[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 98, line 18 skipping to change at page 97, line 25
[TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
for Transport Layer Security (TLS)", RFC 3268, June 2002. for Transport Layer Security (TLS)", RFC 3268, June 2002.
[TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
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", January 2008, draft-ietf-tls-
rfc4366-bis-00.txt. rfc4366-bis-01.txt.
[TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS
authentication", RFC 5081, November 2007. 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.
skipping to change at page 99, line 38 skipping to change at page 98, line 45
canetti@watson.ibm.com canetti@watson.ibm.com
Pete Chown Pete Chown
Skygate Technology Ltd Skygate Technology Ltd
pc@skygate.co.uk pc@skygate.co.uk
Taher Elgamal Taher Elgamal
taher@securify.com taher@securify.com
Securify Securify
Pasi Eronen
pasi.eronen@nokia.com
Nokia
Anil Gangolli Anil Gangolli
anil@busybuddha.org anil@busybuddha.org
Kipp Hickman Kipp Hickman
Alfred Hoenes Alfred Hoenes
David Hopwood David Hopwood
Independent Consultant Independent Consultant
EMail: david.hopwood@blueyonder.co.uk EMail: david.hopwood@blueyonder.co.uk
 End of changes. 69 change blocks. 
287 lines changed or deleted 283 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/