< draft-ietf-tls-rfc4346-bis | rfc5246.txt | |||
---|---|---|---|---|
INTERNET-DRAFT Tim Dierks | Network Working Group T. Dierks | |||
Obsoletes (if approved): RFC 3268, 4346, 4366 Independent | Request for Comments: 5246 Independent | |||
Updates (if approved): RFC 4492 Eric Rescorla | Obsoletes: 3268, 4346, 4366 E. Rescorla | |||
Intended status: Proposed Standard Network Resonance, Inc. | Updates: 4492 RTFM, Inc. | |||
<draft-ietf-tls-rfc4346-bis-10.txt> March 2008 (Expires September 2008) | Category: Standards Track 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 | ||||
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 | ||||
aware will be disclosed, in accordance with Section 6 of BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF), its areas, and its working groups. Note that | ||||
other groups may also distribute working documents as Internet- | ||||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | ||||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | ||||
http://www.ietf.org/ietf/1id-abstracts.txt. | ||||
The list of Internet-Draft Shadow Directories can be accessed at | ||||
http://www.ietf.org/shadow.html. | ||||
Copyright Notice | ||||
Copyright (C) The IETF Trust (2008). | This document specifies an Internet standards track protocol for the | |||
Internet community, and requests discussion and suggestions for | ||||
improvements. Please refer to the current edition of the "Internet | ||||
Official Protocol Standards" (STD 1) for the standardization state | ||||
and status of this protocol. Distribution of this memo is unlimited. | ||||
Abstract | Abstract | |||
This document specifies Version 1.2 of the Transport Layer Security | This document specifies Version 1.2 of the Transport Layer Security | |||
(TLS) protocol. The TLS protocol provides communications security | (TLS) protocol. The TLS protocol provides communications security | |||
over the Internet. The protocol allows client/server applications to | over the Internet. The protocol allows client/server applications to | |||
communicate in a way that is designed to prevent eavesdropping, | communicate in a way that is designed to prevent eavesdropping, | |||
tampering, or message forgery. | tampering, or message forgery. | |||
Table of Contents | Table of Contents | |||
1. Introduction 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 7 | 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 ..............................................8 | |||
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 ..................................12 | |||
4.8. Constants 13 | 4.8. Constants .................................................14 | |||
5. HMAC and the Pseudorandom Function 14 | 5. HMAC and the Pseudorandom Function .............................14 | |||
6. The TLS Record Protocol 15 | 6. The TLS Record Protocol ........................................15 | |||
6.1. Connection States 16 | 6.1. Connection States .........................................16 | |||
6.2. Record layer 18 | 6.2. Record Layer ..............................................19 | |||
6.2.1. Fragmentation 19 | 6.2.1. Fragmentation ......................................19 | |||
6.2.2. Record Compression and Decompression 20 | 6.2.2. Record Compression and Decompression ...............20 | |||
6.2.3. Record Payload Protection 21 | 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 ............22 | |||
6.2.3.2. CBC Block Cipher 22 | 6.2.3.2. CBC Block Cipher ..........................22 | |||
6.2.3.3. AEAD ciphers 24 | 6.2.3.3. AEAD Ciphers ..............................24 | |||
6.3. Key Calculation 25 | 6.3. Key Calculation ...........................................25 | |||
7. The TLS Handshaking Protocols 26 | 7. The TLS Handshaking Protocols ..................................26 | |||
7.1. Change Cipher Spec Protocol 27 | 7.1. Change Cipher Spec Protocol ...............................27 | |||
7.2. Alert Protocol 27 | 7.2. Alert Protocol ............................................28 | |||
7.2.1. Closure Alerts 28 | 7.2.1. Closure Alerts .....................................29 | |||
7.2.2. Error Alerts 29 | 7.2.2. Error Alerts .......................................30 | |||
7.3. Handshake Protocol Overview 33 | 7.3. Handshake Protocol Overview ...............................33 | |||
7.4. Handshake Protocol 37 | 7.4. Handshake Protocol ........................................37 | |||
7.4.1. Hello Messages 38 | 7.4.1. Hello Messages .....................................38 | |||
7.4.1.1. Hello Request 38 | 7.4.1.1. Hello Request .............................38 | |||
7.4.1.2. Client Hello 39 | 7.4.1.2. Client Hello ..............................39 | |||
7.4.1.3. Server Hello 42 | 7.4.1.3. Server Hello ..............................42 | |||
7.4.1.4 Hello Extensions 43 | 7.4.1.4. Hello Extensions ..........................44 | |||
7.4.1.4.1 Signature Algorithms 45 | 7.4.1.4.1. Signature Algorithms ...........45 | |||
7.4.2. Server Certificate 46 | 7.4.2. Server Certificate .................................47 | |||
7.4.3. Server Key Exchange Message 49 | 7.4.3. Server Key Exchange Message ........................50 | |||
7.4.4. Certificate Request 51 | 7.4.4. Certificate Request ................................53 | |||
7.4.5 Server Hello Done 53 | 7.4.5. Server Hello Done ..................................55 | |||
7.4.6. Client Certificate 53 | 7.4.6. Client Certificate .................................55 | |||
7.4.7. Client Key Exchange Message 55 | 7.4.7. Client Key Exchange Message ........................57 | |||
7.4.7.1. RSA Encrypted Premaster Secret Message 56 | 7.4.7.1. RSA-Encrypted Premaster Secret Message ....58 | |||
7.4.7.2. Client Diffie-Hellman Public Value 58 | 7.4.7.2. Client Diffie-Hellman Public Value ........61 | |||
7.4.8. Certificate verify 59 | 7.4.8. Certificate Verify .................................62 | |||
7.4.9. Finished 60 | 7.4.9. Finished ...........................................63 | |||
8. Cryptographic Computations 62 | 8. Cryptographic Computations .....................................64 | |||
8.1. Computing the Master Secret 62 | 8.1. Computing the Master Secret ...............................64 | |||
8.1.1. RSA 62 | 8.1.1. RSA ................................................65 | |||
8.1.2. Diffie-Hellman 62 | 8.1.2. Diffie-Hellman .....................................65 | |||
9. Mandatory Cipher Suites 63 | 9. Mandatory Cipher Suites ........................................65 | |||
10. Application Data Protocol 63 | 10. Application Data Protocol .....................................65 | |||
11. Security Considerations 63 | 11. Security Considerations .......................................65 | |||
12. IANA Considerations 63 | 12. IANA Considerations ...........................................65 | |||
A. Protocol Data Structures and Constant Values 65 | Appendix A. Protocol Data Structures and Constant Values ..........68 | |||
A.1. Record Layer 65 | A.1. Record Layer ..............................................68 | |||
A.2. Change Cipher Specs Message 66 | A.2. Change Cipher Specs Message ...............................69 | |||
A.3. Alert Messages 66 | A.3. Alert Messages ............................................69 | |||
A.4. Handshake Protocol 67 | A.4. Handshake Protocol ........................................70 | |||
A.4.1. Hello Messages 67 | A.4.1. Hello Messages .....................................71 | |||
A.4.2. Server Authentication and Key Exchange Messages 69 | A.4.2. Server Authentication and Key Exchange Messages ....72 | |||
A.4.3. Client Authentication and Key Exchange Messages 70 | A.4.3. Client Authentication and Key Exchange Messages ....74 | |||
A.4.4. Handshake Finalization Message 71 | A.4.4. Handshake Finalization Message .....................74 | |||
A.5. The Cipher Suite 71 | A.5. The Cipher Suite ..........................................75 | |||
A.6. The Security Parameters 73 | A.6. The Security Parameters ...................................77 | |||
A.7. Changes to RFC 4492 74 | A.7. Changes to RFC 4492 .......................................78 | |||
B. Glossary 74 | Appendix B. Glossary ..............................................78 | |||
C. Cipher Suite Definitions 79 | Appendix C. Cipher Suite Definitions ..............................83 | |||
D. Implementation Notes 81 | Appendix D. Implementation Notes ..................................85 | |||
D.1 Random Number Generation and Seeding 81 | D.1. Random Number Generation and Seeding ......................85 | |||
D.2 Certificates and Authentication 81 | D.2. Certificates and Authentication ...........................85 | |||
D.3 Cipher Suites 81 | D.3. Cipher Suites .............................................85 | |||
D.4 Implementation Pitfalls 81 | D.4. Implementation Pitfalls ...................................85 | |||
E. Backward Compatibility 84 | Appendix E. Backward Compatibility ................................87 | |||
E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 84 | E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 ................87 | |||
E.2 Compatibility with SSL 2.0 85 | E.2. Compatibility with SSL 2.0 ................................88 | |||
E.3. Avoiding Man-in-the-Middle Version Rollback 87 | E.3. Avoiding Man-in-the-Middle Version Rollback ...............90 | |||
F. Security Analysis 88 | Appendix F. Security Analysis .....................................91 | |||
F.1. Handshake Protocol 88 | F.1. Handshake Protocol ........................................91 | |||
F.1.1. Authentication and Key Exchange 88 | F.1.1. Authentication and Key Exchange ....................91 | |||
F.1.1.1. Anonymous Key Exchange 88 | F.1.1.1. Anonymous Key Exchange ....................91 | |||
F.1.1.2. RSA Key Exchange and Authentication 89 | F.1.1.2. RSA Key Exchange and Authentication .......92 | |||
F.1.1.3. Diffie-Hellman Key Exchange with Authentication 89 | F.1.1.3. Diffie-Hellman Key Exchange with | |||
F.1.2. Version Rollback Attacks 90 | Authentication ............................92 | |||
F.1.3. Detecting Attacks Against the Handshake Protocol 91 | F.1.2. Version Rollback Attacks ...........................93 | |||
F.1.4. Resuming Sessions 91 | F.1.3. Detecting Attacks Against the Handshake Protocol ...94 | |||
F.2. Protecting Application Data 91 | F.1.4. Resuming Sessions ..................................94 | |||
F.3. Explicit IVs 92 | F.2. Protecting Application Data ...............................94 | |||
F.4. Security of Composite Cipher Modes 92 | F.3. Explicit IVs ..............................................95 | |||
F.5 Denial of Service 93 | F.4. Security of Composite Cipher Modes ........................95 | |||
F.6 Final Notes 93 | F.5. Denial of Service .........................................96 | |||
F.6. Final Notes ...............................................96 | ||||
Normative References ..............................................97 | ||||
Informative References ............................................98 | ||||
Working Group Information ........................................101 | ||||
Contributors .....................................................101 | ||||
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. | |||
TLS Record Protocol provides connection security that has two basic | The TLS Record Protocol provides connection security that has two | |||
properties: | basic properties: | |||
- The connection is private. Symmetric cryptography is used for | - The connection is private. Symmetric cryptography is used for | |||
data encryption (e.g., AES [AES], RC4 [SCH] etc.). The keys for | data encryption (e.g., AES [AES], RC4 [SCH], etc.). The keys for | |||
this symmetric encryption are generated uniquely for each | this symmetric encryption are generated uniquely for each | |||
connection and are based on a secret negotiated by another | connection and are based on a secret negotiated by another | |||
protocol (such as the TLS Handshake Protocol). The Record Protocol | protocol (such as the TLS Handshake Protocol). The Record | |||
can also be used without encryption. | Protocol can also be used without encryption. | |||
- The connection is reliable. Message transport includes a message | - The connection is reliable. Message transport includes a message | |||
integrity check using a keyed MAC. Secure hash functions (e.g., | integrity check using a keyed MAC. Secure hash functions (e.g., | |||
SHA-1, etc.) are used for MAC computations. The Record Protocol | SHA-1, etc.) are used for MAC computations. The Record Protocol | |||
can operate without a MAC, but is generally only used in this mode | can operate without a MAC, but is generally only used in this mode | |||
while another protocol is using the Record Protocol as a transport | while another protocol is using the Record Protocol as a transport | |||
for negotiating security parameters. | for negotiating security parameters. | |||
The TLS Record Protocol is used for encapsulation of various higher- | The TLS Record Protocol is used for encapsulation of various higher- | |||
level protocols. One such encapsulated protocol, the TLS Handshake | level protocols. One such encapsulated protocol, the TLS Handshake | |||
Protocol, allows the server and client to authenticate each other and | Protocol, allows the server and client to authenticate each other and | |||
to negotiate an encryption algorithm and cryptographic keys before | to negotiate an encryption algorithm and cryptographic keys before | |||
the application protocol transmits or receives its first byte of | the application protocol transmits or receives its first byte of | |||
data. The TLS Handshake Protocol provides connection security that | data. The TLS Handshake Protocol provides connection security that | |||
has three basic properties: | has three basic properties: | |||
- The peer's identity can be authenticated using asymmetric, or | - The peer's identity can be authenticated using asymmetric, or | |||
public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.). This | public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.). This | |||
authentication can be made optional, but is generally required for | authentication can be made optional, but is generally required for | |||
at least one of the peers. | at least one of the peers. | |||
- The negotiation of a shared secret is secure: the negotiated | - The negotiation of a shared secret is secure: the negotiated | |||
secret is unavailable to eavesdroppers, and for any authenticated | secret is unavailable to eavesdroppers, and for any authenticated | |||
connection the secret cannot be obtained, even by an attacker who | connection the secret cannot be obtained, even by an attacker who | |||
can place himself in the middle of the connection. | can place himself in the middle of the connection. | |||
- The negotiation is reliable: no attacker can modify the | - The negotiation is reliable: no attacker can modify the | |||
negotiation communication without being detected by the parties to | negotiation communication without being detected by the parties to | |||
the communication. | the communication. | |||
One advantage of TLS is that it is application protocol independent. | One advantage of TLS is that it is application protocol independent. | |||
Higher-level protocols can layer on top of the TLS Protocol | Higher-level protocols can layer on top of the TLS protocol | |||
transparently. The TLS standard, however, does not specify how | transparently. The TLS standard, however, does not specify how | |||
protocols add security with TLS; the decisions on how to initiate TLS | protocols add security with TLS; the decisions on how to initiate TLS | |||
handshaking and how to interpret the authentication certificates | handshaking and how to interpret the authentication certificates | |||
exchanged are left to the judgment of the designers and implementors | exchanged are left to the judgment of the designers and implementors | |||
of protocols that run on top of TLS. | of protocols that run on top of TLS. | |||
1.1. Requirements Terminology | 1.1. Requirements Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [REQ]. | document are to be interpreted as described in RFC 2119 [REQ]. | |||
1.2. Major Differences from TLS 1.1 | 1.2. Major Differences from TLS 1.1 | |||
This document is a revision of the TLS 1.1 [TLS1.1] protocol which | This document is a revision of the TLS 1.1 [TLS1.1] protocol which | |||
contains improved flexibility, particularly for negotiation of | contains improved flexibility, particularly for negotiation of | |||
cryptographic algorithms. The major changes are: | cryptographic algorithms. The major changes are: | |||
- The MD5/SHA-1 combination in the pseudorandom function (PRF) has | - The MD5/SHA-1 combination in the pseudorandom function (PRF) has | |||
been replaced with cipher suite specified PRFs. All cipher suites | been replaced with cipher-suite-specified PRFs. All cipher suites | |||
in this document use P_SHA256. | in this document use P_SHA256. | |||
- The MD5/SHA-1 combination in the digitally-signed element has been | - The MD5/SHA-1 combination in the digitally-signed element has been | |||
replaced with a single hash. Signed elements now include a field | replaced with a single hash. Signed elements now include a field | |||
that explicitly specifies the hash algorithm used. | that explicitly specifies the hash algorithm used. | |||
- Substantial cleanup to the client's and server's ability to | - Substantial cleanup to the client's and server's ability to | |||
specify which hash and signature algorithms they will accept. Note | specify which hash and signature algorithms they will accept. | |||
that this also relaxes some of the constraints on signature and | Note that this also relaxes some of the constraints on signature | |||
hash algorithms from previous versions of TLS. | and hash algorithms from previous versions of TLS. | |||
- Addition of support for authenticated encryption with additional | - Addition of support for authenticated encryption with additional | |||
data modes. | data modes. | |||
- TLS Extensions definition and AES Cipher Suites were merged in | - TLS Extensions definition and AES Cipher Suites were merged in | |||
from external [TLSEXT] and [TLSAES]. | from external [TLSEXT] and [TLSAES]. | |||
- Tighter checking of EncryptedPreMasterSecret version numbers. | - Tighter checking of EncryptedPreMasterSecret version numbers. | |||
- Tightened up a number of requirements. | - Tightened up a number of requirements. | |||
skipping to change at page 6, line 11 ¶ | skipping to change at page 6, line 13 ¶ | |||
- 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. | |||
- Removed IDEA and DES cipher suites. They are now deprecated and | - Removed IDEA and DES cipher suites. They are now deprecated and | |||
will be documented in a separate document. | will be documented in a separate document. | |||
- Support for the SSLv2 backward-compatible hello is now a MAY, not | - Support for the SSLv2 backward-compatible hello is now a MAY, not | |||
a SHOULD, with sending it a SHOULD NOT. Support will probably | a SHOULD, with sending it a SHOULD NOT. Support will probably | |||
become a SHOULD NOT in the future. | become a SHOULD NOT in the future. | |||
- Added limited "fall-through" to the presentation language to allow | - Added limited "fall-through" to the presentation language to allow | |||
multiple case arms to have the same encoding. | multiple case arms to have the same encoding. | |||
- Added an Implementation Pitfalls sections | - Added an Implementation Pitfalls sections | |||
- The usual clarifications and editorial work. | - The usual clarifications and editorial work. | |||
2. Goals | 2. Goals | |||
The goals of TLS Protocol, in order of their priority, are as | The goals of the TLS protocol, in order of 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 | |||
cryptographic parameters without knowledge of one another's code. | cryptographic parameters without knowledge of one another's code. | |||
3. Extensibility: TLS seeks to provide a framework into which new | 3. Extensibility: TLS seeks to provide a framework into which new | |||
public key and bulk encryption methods can be incorporated as | public key and bulk encryption methods can be incorporated as | |||
necessary. This will also accomplish two sub-goals: preventing the | necessary. This will also accomplish two sub-goals: preventing | |||
need to create a new protocol (and risking the introduction of | the need to create a new protocol (and risking the introduction of | |||
possible new weaknesses) and avoiding the need to implement an | possible new weaknesses) and avoiding the need to implement an | |||
entire new security library. | entire new security library. | |||
4. Relative efficiency: Cryptographic operations tend to be highly | 4. Relative efficiency: Cryptographic operations tend to be highly | |||
CPU intensive, particularly public key operations. For this | CPU intensive, particularly public key operations. For this | |||
reason, the TLS protocol has incorporated an optional session | reason, the TLS protocol has incorporated an optional session | |||
caching scheme to reduce the number of connections that need to be | caching scheme to reduce the number of connections that need to be | |||
established from scratch. Additionally, care has been taken to | established from scratch. Additionally, care has been taken to | |||
reduce network activity. | reduce network activity. | |||
3. Goals of This Document | 3. Goals of This Document | |||
This document and the TLS protocol itself are based on the SSL 3.0 | This document and the TLS protocol itself are based on the SSL 3.0 | |||
Protocol Specification as published by Netscape. The differences | Protocol Specification as published by Netscape. The differences | |||
between this protocol and SSL 3.0 are not dramatic, but they are | between this protocol and SSL 3.0 are not dramatic, but they are | |||
significant enough that the various versions of TLS and SSL 3.0 do | significant enough that the various versions of TLS and SSL 3.0 do | |||
not interoperate (although each protocol incorporates a mechanism by | not interoperate (although each protocol incorporates a mechanism by | |||
which an implementation can back down to prior versions). This | which an implementation can back down to prior versions). This | |||
document is intended primarily for readers who will be implementing | document is intended primarily for readers who will be implementing | |||
the protocol and for those doing cryptographic analysis of it. The | the protocol and for those doing cryptographic analysis of it. The | |||
specification has been written with this in mind, and it is intended | specification has been written with this in mind, and it is intended | |||
to reflect the needs of those two groups. For that reason, many of | to reflect the needs of those two groups. For that reason, many of | |||
the algorithm-dependent data structures and rules are included in the | the algorithm-dependent data structures and rules are included in the | |||
body of the text (as opposed to in an appendix), providing easier | body of the text (as opposed to in an appendix), providing easier | |||
access to them. | access to them. | |||
This document is not intended to supply any details of service | This document is not intended to supply any details of service | |||
definition or of interface definition, although it does cover select | definition or of interface definition, although it does cover select | |||
areas of policy as they are required for the maintenance of solid | areas of policy as they are required for the maintenance of solid | |||
security. | security. | |||
4. Presentation Language | 4. Presentation Language | |||
This document deals with the formatting of data in an external | This document deals with the formatting of data in an external | |||
representation. The following very basic and somewhat casually | representation. The following very basic and somewhat casually | |||
defined presentation syntax will be used. The syntax draws from | defined presentation syntax will be used. The syntax draws from | |||
several sources in its structure. Although it resembles the | several sources in its structure. Although it resembles the | |||
programming language "C" in its syntax and XDR [XDR] in both its | programming language "C" in its syntax and XDR [XDR] in both its | |||
syntax and intent, it would be risky to draw too many parallels. The | syntax and intent, it would be risky to draw too many parallels. The | |||
purpose of this presentation language is to document TLS only; it has | purpose of this presentation language is to document TLS only; it has | |||
no general application beyond that particular goal. | no general application beyond that particular goal. | |||
4.1. Basic Block Size | 4.1. Basic Block Size | |||
The representation of all data items is explicitly specified. The | The representation of all data items is explicitly specified. The | |||
basic data block size is one byte (i.e., 8 bits). Multiple byte data | basic data block size is one byte (i.e., 8 bits). Multiple byte data | |||
items are concatenations of bytes, from left to right, from top to | items are concatenations of bytes, from left to right, from top to | |||
bottom. From the bytestream, a multi-byte item (a numeric in the | bottom. From the byte stream, a multi-byte item (a numeric in the | |||
example) is formed (using C notation) by: | example) is formed (using C notation) by: | |||
value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | | value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | | |||
... | byte[n-1]; | ... | byte[n-1]; | |||
This byte ordering for multi-byte values is the commonplace network | This byte ordering for multi-byte values is the commonplace network | |||
byte order or big endian format. | byte order or big-endian format. | |||
4.2. Miscellaneous | ||||
4.2. Miscellaneous | ||||
Comments begin with "/*" and end with "*/". | Comments begin with "/*" and end with "*/". | |||
Optional components are denoted by enclosing them in "[[ ]]" double | Optional components are denoted by enclosing them in "[[ ]]" double | |||
brackets. | brackets. | |||
Single-byte entities containing uninterpreted data are of type | Single-byte entities containing uninterpreted data are of type | |||
opaque. | opaque. | |||
4.3. Vectors | 4.3. Vectors | |||
A vector (single dimensioned array) is a stream of homogeneous data | A vector (single-dimensioned array) is a stream of homogeneous data | |||
elements. The size of the vector may be specified at documentation | elements. The size of the vector may be specified at documentation | |||
time or left unspecified until runtime. In either case, the length | time or left unspecified until runtime. In either case, the length | |||
declares the number of bytes, not the number of elements, in the | declares the number of bytes, not the number of elements, in the | |||
vector. The syntax for specifying a new type, T', that is a fixed- | vector. The syntax for specifying a new type, T', that is a fixed- | |||
length vector of type T is | length vector of type T is | |||
T T'[n]; | T T'[n]; | |||
Here, T' occupies n bytes in the data stream, where n is a multiple | Here, T' occupies n bytes in the data stream, where n is a multiple | |||
of the size of T. The length of the vector is not included in the | of the size of T. The length of the vector is not included in the | |||
encoded stream. | encoded stream. | |||
In the following example, Datum is defined to be three consecutive | In the following example, Datum is defined to be three consecutive | |||
bytes that the protocol does not interpret, while Data is three | bytes that the protocol does not interpret, while Data is three | |||
consecutive Datum, consuming a total of nine bytes. | consecutive Datum, consuming a total of nine bytes. | |||
opaque Datum[3]; /* three uninterpreted bytes */ | opaque Datum[3]; /* three uninterpreted bytes */ | |||
Datum Data[9]; /* 3 consecutive 3 byte vectors */ | Datum Data[9]; /* 3 consecutive 3 byte vectors */ | |||
Variable-length vectors are defined by specifying a subrange of legal | Variable-length vectors are defined by specifying a subrange of legal | |||
lengths, inclusively, using the notation <floor..ceiling>. When | lengths, inclusively, using the notation <floor..ceiling>. When | |||
these are encoded, the actual length precedes the vector's contents | these are encoded, the actual length precedes the vector's contents | |||
in the byte stream. The length will be in the form of a number | in the byte stream. The length will be in the form of a number | |||
consuming as many bytes as required to hold the vector's specified | consuming as many bytes as required to hold the vector's specified | |||
maximum (ceiling) length. A variable-length vector with an actual | maximum (ceiling) length. A variable-length vector with an actual | |||
length field of zero is referred to as an empty vector. | length field of zero is referred to as an empty vector. | |||
T T'<floor..ceiling>; | T T'<floor..ceiling>; | |||
In the following example, mandatory is a vector that must contain | In the following example, mandatory is a vector that must contain | |||
between 300 and 400 bytes of type opaque. It can never be empty. The | between 300 and 400 bytes of type opaque. It can never be empty. | |||
actual length field consumes two bytes, a uint16, sufficient to | The actual length field consumes two bytes, a uint16, which is | |||
represent the value 400 (see Section 4.4). On the other hand, longer | sufficient to represent the value 400 (see Section 4.4). On the | |||
can represent up to 800 bytes of data, or 400 uint16 elements, and it | other hand, longer can represent up to 800 bytes of data, or 400 | |||
may be empty. Its encoding will include a two-byte actual length | uint16 elements, and it may be empty. Its encoding will include a | |||
field prepended to the vector. The length of an encoded vector must | two-byte actual length field prepended to the vector. The length of | |||
be an even multiple of the length of a single element (for example, a | an encoded vector must be an even multiple of the length of a single | |||
17-byte vector of uint16 would be illegal). | element (for example, a 17-byte vector of uint16 would be illegal). | |||
opaque mandatory<300..400>; | opaque mandatory<300..400>; | |||
/* length field is 2 bytes, cannot be empty */ | /* length field is 2 bytes, cannot be empty */ | |||
uint16 longer<0..800>; | uint16 longer<0..800>; | |||
/* zero to 400 16-bit unsigned integers */ | /* zero to 400 16-bit unsigned integers */ | |||
4.4. Numbers | 4.4. Numbers | |||
The basic numeric data type is an unsigned byte (uint8). All larger | The basic numeric data type is an unsigned byte (uint8). All larger | |||
numeric data types are formed from fixed-length series of bytes | numeric data types are formed from fixed-length series of bytes | |||
concatenated as described in Section 4.1 and are also unsigned. The | concatenated as described in Section 4.1 and are also unsigned. The | |||
following numeric types are predefined. | following numeric types are predefined. | |||
uint8 uint16[2]; | uint8 uint16[2]; | |||
uint8 uint24[3]; | uint8 uint24[3]; | |||
uint8 uint32[4]; | uint8 uint32[4]; | |||
uint8 uint64[8]; | uint8 uint64[8]; | |||
All values, here and elsewhere in the specification, are stored in | All values, here and elsewhere in the specification, are stored in | |||
"network" or "big-endian" order; the uint32 represented by the hex | network byte (big-endian) order; the uint32 represented by the hex | |||
bytes 01 02 03 04 is equivalent to the decimal value 16909060. | bytes 01 02 03 04 is equivalent to the decimal value 16909060. | |||
Note that in some cases (e.g., DH parameters) it is necessary to | Note that in some cases (e.g., DH parameters) it is necessary to | |||
represent integers as opaque vectors. In such cases, they are | represent integers as opaque vectors. In such cases, they are | |||
represented as unsigned integers (i.e., leading zero octets are not | represented as unsigned integers (i.e., leading zero octets are not | |||
required even if the most significant bit is set). | required even if the most significant bit is set). | |||
4.5. Enumerateds | 4.5. Enumerateds | |||
An additional sparse data type is available called enum. A field of | An additional sparse data type is available called enum. A field of | |||
type enum can only assume the values declared in the definition. | type enum can only assume the values declared in the definition. | |||
Each definition is a different type. Only enumerateds of the same | Each definition is a different type. Only enumerateds of the same | |||
type may be assigned or compared. Every element of an enumerated must | type may be assigned or compared. Every element of an enumerated | |||
be assigned a value, as demonstrated in the following example. Since | must be assigned a value, as demonstrated in the following example. | |||
the elements of the enumerated are not ordered, they can be assigned | Since the elements of the enumerated are not ordered, they can be | |||
any unique value, in any order. | assigned any unique value, in any order. | |||
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; | enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; | |||
Enumerateds occupy as much space in the byte stream as would its | An enumerated occupies as much space in the byte stream as would its | |||
maximal defined ordinal value. The following definition would cause | maximal defined ordinal value. The following definition would cause | |||
one byte to be used to carry fields of type Color. | one byte to be used to carry fields of type Color. | |||
enum { red(3), blue(5), white(7) } Color; | enum { red(3), blue(5), white(7) } Color; | |||
One may optionally specify a value without its associated tag to | One may optionally specify a value without its associated tag to | |||
force the width definition without defining a superfluous element. | force the width definition without defining a superfluous element. | |||
In the following example, Taste will consume two bytes in the data | In the following example, Taste will consume two bytes in the data | |||
stream but can only assume the values 1, 2, or 4. | stream but can only assume the values 1, 2, or 4. | |||
enum { sweet(1), sour(2), bitter(4), (32000) } Taste; | enum { sweet(1), sour(2), bitter(4), (32000) } Taste; | |||
The names of the elements of an enumeration are scoped within the | The names of the elements of an enumeration are scoped within the | |||
defined type. In the first example, a fully qualified reference to | defined type. In the first example, a fully qualified reference to | |||
the second element of the enumeration would be Color.blue. Such | the second element of the enumeration would be Color.blue. Such | |||
qualification is not required if the target of the assignment is well | qualification is not required if the target of the assignment is well | |||
specified. | specified. | |||
Color color = Color.blue; /* overspecified, legal */ | Color color = Color.blue; /* overspecified, legal */ | |||
Color color = blue; /* correct, type implicit */ | Color color = blue; /* correct, type implicit */ | |||
For enumerateds that are never converted to external representation, | For enumerateds that are never converted to external representation, | |||
the numerical information may be omitted. | the numerical information may be omitted. | |||
enum { low, medium, high } Amount; | enum { low, medium, high } Amount; | |||
4.6. Constructed Types | 4.6. Constructed Types | |||
Structure types may be constructed from primitive types for | Structure types may be constructed from primitive types for | |||
convenience. Each specification declares a new, unique type. The | convenience. Each specification declares a new, unique type. The | |||
syntax for definition is much like that of C. | syntax for definition is much like that of C. | |||
struct { | struct { | |||
T1 f1; | T1 f1; | |||
T2 f2; | T2 f2; | |||
... | ... | |||
Tn fn; | Tn fn; | |||
} [[T]]; | } [[T]]; | |||
The fields within a structure may be qualified using the type's name, | The fields within a structure may be qualified using the type's name, | |||
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. Case arms have limited fall-through: if two case arms | the select. Case arms have limited fall-through: if two case arms | |||
follow in immediate succession with no fields in between, then they | follow in immediate succession with no fields in between, then they | |||
both contain the same fields. Thus, in the example below, "orange" | 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 | and "banana" both contain V2. Note that this is a new piece of | |||
in TLS 1.2. | syntax in TLS 1.2. | |||
The body of the variant structure may be given a label for reference. | 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 | The mechanism by which the variant is selected at runtime is not | |||
prescribed by the presentation language. | prescribed by the presentation language. | |||
struct { | struct { | |||
T1 f1; | T1 f1; | |||
T2 f2; | T2 f2; | |||
.... | .... | |||
Tn fn; | Tn fn; | |||
skipping to change at page 11, line 47 ¶ | skipping to change at page 12, line 5 ¶ | |||
struct { | struct { | |||
select (VariantTag) { /* value of selector is implicit */ | select (VariantTag) { /* value of selector is implicit */ | |||
case apple: | case apple: | |||
V1; /* VariantBody, tag = apple */ | V1; /* VariantBody, tag = apple */ | |||
case orange: | case orange: | |||
case banana: | case banana: | |||
V2; /* VariantBody, tag = orange or banana */ | V2; /* VariantBody, tag = orange or banana */ | |||
} variant_body; /* optional label on variant */ | } variant_body; /* optional label on variant */ | |||
} VariantRecord; | } VariantRecord; | |||
4.7. Cryptographic Attributes | 4.7. Cryptographic Attributes | |||
The five cryptographic operations digital signing, stream cipher | The five cryptographic operations -- digital signing, stream cipher | |||
encryption, block cipher encryption, authenticated encryption with | encryption, block cipher encryption, authenticated encryption with | |||
additional data (AEAD) encryption and public key encryption are | additional data (AEAD) encryption, and public key encryption -- are | |||
designated digitally-signed, stream-ciphered, block-ciphered, aead- | designated digitally-signed, stream-ciphered, block-ciphered, aead- | |||
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). | |||
A digitally-signed element is encoded as a struct DigitallySigned: | A digitally-signed element is encoded as a struct DigitallySigned: | |||
struct { | struct { | |||
SignatureAndHashAlgorithm algorithm; | SignatureAndHashAlgorithm algorithm; | |||
opaque signature<0..2^16-1>; | opaque signature<0..2^16-1>; | |||
} DigitallySigned; | } DigitallySigned; | |||
The algorithm field specifies the algorithm used (see Section | The algorithm field specifies the algorithm used (see Section | |||
7.4.1.4.1 for the definition of this field.) Note that the | 7.4.1.4.1 for the definition of this field). Note that the | |||
introduction of the algorithm field is a change from previous | introduction of the algorithm field is a change from previous | |||
versions. The signature is a digital signature using those | versions. The signature is a digital signature using those | |||
algorithms over the contents of the element. The contents themselves | algorithms over the contents of the element. The contents themselves | |||
do not appear on the wire but are simply calculated. The length of | do not appear on the wire but are simply calculated. The length of | |||
the signature is specified by the signing algorithm and key. | the signature is specified by the signing algorithm and key. | |||
In RSA signing, the opaque vector contains the signature generated | In RSA signing, the opaque vector contains the signature generated | |||
using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As | using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As | |||
discussed in [PKCS1], the DigestInfo MUST be DER [X680] [X690] | discussed in [PKCS1], the DigestInfo MUST be DER-encoded [X680] | |||
encoded and for hash algorithms without parameters (which include | [X690]. For hash algorithms without parameters (which includes | |||
SHA-1) the DigestInfo.AlgorithmIdentifier.parameters field MUST be | SHA-1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be | |||
NULL but implementations MUST accept both without parameters and with | NULL, but implementations MUST accept both without parameters and | |||
NULL parameters. Note that earlier versions of TLS used a different | with NULL parameters. Note that earlier versions of TLS used a | |||
RSA signature scheme which did not include a DigestInfo encoding. | different RSA signature scheme that did not include a DigestInfo | |||
encoding. | ||||
In DSA, the 20 bytes of the SHA-1 hash are run directly through the | In DSA, the 20 bytes of the SHA-1 hash are run directly through the | |||
Digital Signing Algorithm with no additional hashing. This produces | Digital Signing Algorithm with no additional hashing. This produces | |||
two values, r and s. The DSA signature is an opaque vector, as above, | two values, r and s. The DSA signature is an opaque vector, as | |||
the contents of which are the DER encoding of: | above, the contents of which are the DER encoding of: | |||
Dss-Sig-Value ::= SEQUENCE { | Dss-Sig-Value ::= SEQUENCE { | |||
r INTEGER, | r INTEGER, | |||
s INTEGER | s INTEGER | |||
} | } | |||
Note: In current terminology, DSA refers to the Digital Signature | Note: In current terminology, DSA refers to the Digital Signature | |||
Algorithm and DSS refers to the NIST standard. In the original | Algorithm and DSS refers to the NIST standard. In the original SSL | |||
SSL and TLS specs, "DSS" was used universally. This document | and TLS specs, "DSS" was used universally. This document uses "DSA" | |||
uses "DSA" to refer to the algorithm, "DSS" to refer to the | to refer to the algorithm, "DSS" to refer to the standard, and it | |||
standard, and uses "DSS" in the code point definitions for | uses "DSS" in the code point definitions for historical continuity. | |||
historical continuity. | ||||
In stream cipher encryption, the plaintext is exclusive-ORed with an | In stream cipher encryption, the plaintext is exclusive-ORed with an | |||
identical amount of output generated from a cryptographically secure | identical amount of output generated from a cryptographically secure | |||
keyed pseudorandom number generator. | keyed pseudorandom number generator. | |||
In block cipher encryption, every block of plaintext encrypts to a | In block cipher encryption, every block of plaintext encrypts to a | |||
block of ciphertext. All block cipher encryption is done in CBC | block of ciphertext. All block cipher encryption is done in CBC | |||
(Cipher Block Chaining) mode, and all items that are block-ciphered | (Cipher Block Chaining) mode, and all items that are block-ciphered | |||
will be an exact multiple of the cipher block length. | will be an exact multiple of the cipher block length. | |||
In AEAD encryption, the plaintext is simultaneously encrypted and | In AEAD encryption, the plaintext is simultaneously encrypted and | |||
integrity protected. The input may be of any length and aead-ciphered | integrity protected. The input may be of any length, and aead- | |||
output is generally larger than the input in order to accomodate the | ciphered output is generally larger than the input in order to | |||
integrity check value. | accommodate the integrity check value. | |||
In public key encryption, a public key algorithm is used to encrypt | In public key encryption, a public key algorithm is used to encrypt | |||
data in such a way that it can be decrypted only with the matching | data in such a way that it can be decrypted only with the matching | |||
private key. A public-key-encrypted element is encoded as an opaque | private key. A public-key-encrypted element is encoded as an opaque | |||
vector <0..2^16-1>, where the length is specified by the encryption | vector <0..2^16-1>, where the length is specified by the encryption | |||
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 { | digitally-signed opaque { | |||
uint8 field3<0..255>; | uint8 field3<0..255>; | |||
uint8 field4; | uint8 field4; | |||
}; | }; | |||
} UserType; | } UserType; | |||
The contents of the inner struct (field3 and field4) are used as | The contents of the inner struct (field3 and field4) are used as | |||
input for the signature/hash algorithm, and then the entire structure | input for the signature/hash algorithm, and then the entire structure | |||
is encrypted with a stream cipher. The length of this structure, in | is encrypted with a stream cipher. The length of this structure, in | |||
bytes, would be equal to two bytes for field1 and field2, plus two | bytes, would be equal to two bytes for field1 and field2, plus two | |||
bytes for the signature and hash algorithm, plus two bytes for the | bytes for the signature and hash algorithm, plus two bytes for the | |||
length of the signature, plus the length of the output of the signing | length of the signature, plus the length of the output of the signing | |||
algorithm. This is known because the algorithm and key used for the | algorithm. The length of the signature is known because the | |||
signing are known prior to encoding or decoding this structure. | 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: | |||
struct { | struct { | |||
uint8 f1; | uint8 f1; | |||
uint8 f2; | uint8 f2; | |||
} Example1; | } Example1; | |||
Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */ | Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */ | |||
5. HMAC and the Pseudorandom Function | 5. HMAC and the Pseudorandom Function | |||
The TLS record layer uses a keyed Message Authentication Code (MAC) | The TLS record layer uses a keyed Message Authentication Code (MAC) | |||
to protect message integrity. The cipher suites defined in this | to protect message integrity. The cipher suites defined in this | |||
document use a construction known as HMAC, described in [HMAC], which | document use a construction known as HMAC, described in [HMAC], which | |||
is based on a hash function. Other cipher suites MAY define their own | is based on a hash function. Other cipher suites MAY define their | |||
MAC constructions, if needed. | own MAC constructions, if needed. | |||
In addition, a construction is required to do expansion of secrets | In addition, a construction is required to do expansion of secrets | |||
into blocks of data for the purposes of key generation or validation. | into blocks of data for the purposes of key generation or validation. | |||
This pseudo-random function (PRF) takes as input a secret, a seed, | This pseudorandom function (PRF) takes as input a secret, a seed, and | |||
and an identifying label and produces an output of arbitrary length. | an identifying label and produces an output of arbitrary length. | |||
In this section, we define one PRF, based on HMAC. This PRF with the | In this section, we define one PRF, based on HMAC. This PRF with the | |||
SHA-256 hash function is used for all cipher suites defined in this | SHA-256 hash function is used for all cipher suites defined in this | |||
document and in TLS documents published prior to this document when | document and in TLS documents published prior to this document when | |||
TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a | TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a | |||
PRF and in general SHOULD use the TLS PRF with SHA-256 or a stronger | PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a | |||
standard hash function. | stronger standard hash function. | |||
First, we define a data expansion function, P_hash(secret, data) that | First, we define a data expansion function, P_hash(secret, data), | |||
uses a single hash function to expand a secret and seed into an | that uses a single hash function to expand a secret and seed into an | |||
arbitrary quantity of output: | arbitrary quantity of output: | |||
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + | P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + | |||
HMAC_hash(secret, A(2) + seed) + | HMAC_hash(secret, A(2) + seed) + | |||
HMAC_hash(secret, A(3) + seed) + ... | HMAC_hash(secret, A(3) + seed) + ... | |||
Where + indicates concatenation. | where + indicates concatenation. | |||
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 necessary to produce the | |||
required quantity of data. For example, if P_SHA256 is being used to | required quantity of data. For example, if P_SHA256 is being used to | |||
create 80 bytes of data, it will have to be iterated three times | create 80 bytes of data, it will have to be iterated three times | |||
(through A(3)), creating 96 bytes of output data; the last 16 bytes | (through A(3)), creating 96 bytes of output data; the last 16 bytes | |||
of the final iteration will then be discarded, leaving 80 bytes of | of the final iteration will then be discarded, leaving 80 bytes of | |||
output 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 | |||
it is given without a length byte or trailing null character. For | form it is given without a length byte or trailing null character. | |||
example, the label "slithy toves" would be processed by hashing the | For example, the label "slithy toves" would be processed by hashing | |||
following bytes: | the following bytes: | |||
73 6C 69 74 68 79 20 74 6F 76 65 73 | 73 6C 69 74 68 79 20 74 6F 76 65 73 | |||
6. The TLS Record Protocol | 6. The TLS Record Protocol | |||
The TLS Record Protocol is a layered protocol. At each layer, | The TLS Record Protocol is a layered protocol. At each layer, | |||
messages may include fields for length, description, and content. | messages may include fields for length, description, and content. | |||
The Record Protocol takes messages to be transmitted, fragments the | The Record Protocol takes messages to be transmitted, fragments the | |||
data into manageable blocks, optionally compresses the data, applies | data into manageable blocks, optionally compresses the data, applies | |||
a MAC, encrypts, and transmits the result. Received data is | a MAC, encrypts, and transmits the result. Received data is | |||
decrypted, verified, decompressed, reassembled, and then delivered to | decrypted, verified, decompressed, reassembled, and then delivered to | |||
higher-level clients. | higher-level clients. | |||
Four protocols that use the record protocol are described in this | Four protocols that use the record protocol are described in this | |||
document: the handshake protocol, the alert protocol, the change | document: the handshake protocol, the alert protocol, the change | |||
cipher spec protocol, and the application data protocol. In order to | cipher spec protocol, and the application data protocol. In order to | |||
allow extension of the TLS protocol, additional record content types | allow extension of the TLS protocol, additional record content types | |||
can be supported by the record protocol. New record content type | can be supported by the record protocol. New record content type | |||
values are assigned by IANA in the TLS Content Type Registry as | values are assigned by IANA in the TLS Content Type Registry as | |||
described in Section 12. | described in Section 12. | |||
Implementations MUST NOT send record types not defined in this | Implementations MUST NOT send record types not defined in this | |||
document unless negotiated by some extension. If a TLS | document unless negotiated by some extension. If a TLS | |||
implementation receives an unexpected record type, it MUST send an | implementation receives an unexpected record type, it MUST send an | |||
unexpected_message alert. | unexpected_message alert. | |||
Any protocol designed for use over TLS must be carefully designed to | Any protocol designed for use over TLS must be carefully designed to | |||
deal with all possible attacks against it. As a practical matter, | deal with all possible attacks against it. As a practical matter, | |||
this means that the protocol designer must be aware of what security | this means that the protocol designer must be aware of what security | |||
properties TLS does and does not provide and cannot safely rely on | properties TLS does and does not provide and cannot safely rely on | |||
the latter. | the latter. | |||
Note in particular that type and length of a record are not protected | Note in particular that type and length of a record are not protected | |||
by encryption. If this information is itself sensitive, application | by encryption. If this information is itself sensitive, application | |||
designers may wish to take steps (padding, cover traffic) to minimize | designers may wish to take steps (padding, cover traffic) to minimize | |||
information leakage. | information leakage. | |||
6.1. Connection States | 6.1. Connection States | |||
A TLS connection state is the operating environment of the TLS Record | A TLS connection state is the operating environment of the TLS Record | |||
Protocol. It specifies a compression algorithm, an encryption | Protocol. It specifies a compression algorithm, an encryption | |||
algorithm, and a MAC algorithm. In addition, the parameters for these | algorithm, and a MAC algorithm. In addition, the parameters for | |||
algorithms are known: the MAC key and the bulk encryption keys for | these algorithms are known: the MAC key and the bulk encryption keys | |||
the connection in both the read and the write directions. Logically, | for the connection in both the read and the write directions. | |||
there are always four connection states outstanding: the current read | Logically, there are always four connection states outstanding: the | |||
and write states, and the pending read and write states. All records | current read and write states, and the pending read and write states. | |||
are processed under the current read and write states. The security | All records are processed under the current read and write states. | |||
parameters for the pending states can be set by the TLS Handshake | The security parameters for the pending states can be set by the TLS | |||
Protocol, and the ChangeCipherSpec can selectively make either of the | Handshake Protocol, and the ChangeCipherSpec can selectively make | |||
pending states current, in which case the appropriate current state | either of the pending states current, in which case the appropriate | |||
is disposed of and replaced with the pending state; the pending state | current state is disposed of and replaced with the pending state; the | |||
is then reinitialized to an empty state. It is illegal to make a | pending state is then reinitialized to an empty state. It is illegal | |||
state that has not been initialized with security parameters a | to make a state that has not been initialized with security | |||
current state. The initial current state always specifies that no | parameters a current state. The initial current state always | |||
encryption, compression, or MAC will be used. | specifies that no encryption, compression, or MAC will be used. | |||
The security parameters for a TLS Connection read and write state are | The security parameters for a TLS Connection read and write state are | |||
set by providing the following values: | set by providing the following values: | |||
connection end | connection end | |||
Whether this entity is considered the "client" or the "server" in | Whether this entity is considered the "client" or the "server" in | |||
this connection. | this connection. | |||
PRF algorithm | PRF algorithm | |||
An algorithm used to generate keys from the master secret (see | An algorithm used to generate keys from the master secret (see | |||
Sections 5 and 6.3). | Sections 5 and 6.3). | |||
bulk encryption algorithm | bulk encryption algorithm | |||
An algorithm to be used for bulk encryption. This specification | An algorithm to be used for bulk encryption. This specification | |||
includes the key size of this algorithm, whether it is a block, | includes the key size of this algorithm, whether it is a block, | |||
stream, or AEAD cipher, the block size of the cipher (if | stream, or AEAD cipher, the block size of the cipher (if | |||
appropriate), and the lengths of explicit and implicit | appropriate), and the lengths of explicit and implicit | |||
initialization vectors (or nonces). | initialization vectors (or nonces). | |||
MAC algorithm | MAC algorithm | |||
An algorithm to be used for message authentication. This | An algorithm to be used for message authentication. This | |||
specification includes the size of the value returned by the MAC | specification includes the size of the value returned by the MAC | |||
algorithm. | algorithm. | |||
compression algorithm | compression algorithm | |||
An algorithm to be used for data compression. This specification | An algorithm to be used for data compression. This specification | |||
must include all information the algorithm requires to do | must include all information the algorithm requires to do | |||
compression. | compression. | |||
master secret | master secret | |||
A 48-byte secret shared between the two peers in the connection. | A 48-byte secret shared between the two peers in the connection. | |||
client random | client random | |||
A 32-byte value provided by the client. | A 32-byte value provided by the client. | |||
server random | server random | |||
A 32-byte value provided by the server. | A 32-byte value provided by the server. | |||
These parameters are defined in the presentation language as: | These parameters are defined in the presentation language as: | |||
enum { server, client } ConnectionEnd; | enum { server, client } ConnectionEnd; | |||
enum { tls_prf_sha256 } PRFAlgorithm; | enum { tls_prf_sha256 } PRFAlgorithm; | |||
enum { null, rc4, 3des, aes } | enum { null, rc4, 3des, aes } | |||
BulkCipherAlgorithm; | BulkCipherAlgorithm; | |||
enum { stream, block, aead } CipherType; | enum { stream, block, aead } CipherType; | |||
enum { null, hmac_md5, hmac_sha1, hmac_sha256, | enum { null, hmac_md5, hmac_sha1, hmac_sha256, | |||
hmac_sha384, hmac_sha512} MACAlgorithm; | hmac_sha384, hmac_sha512} MACAlgorithm; | |||
enum { null(0), (255) } CompressionMethod; | enum { null(0), (255) } CompressionMethod; | |||
/* The algorithms specified in CompressionMethod, PRFAlgorithm | /* The algorithms specified in CompressionMethod, PRFAlgorithm, | |||
BulkCipherAlgorithm, and MACAlgorithm may be added to. */ | BulkCipherAlgorithm, and MACAlgorithm may be added to. */ | |||
struct { | struct { | |||
ConnectionEnd entity; | ConnectionEnd entity; | |||
PRFAlgorithm prf_algorithm; | PRFAlgorithm prf_algorithm; | |||
BulkCipherAlgorithm bulk_cipher_algorithm; | BulkCipherAlgorithm bulk_cipher_algorithm; | |||
CipherType cipher_type; | CipherType cipher_type; | |||
uint8 enc_key_length; | uint8 enc_key_length; | |||
uint8 block_length; | uint8 block_length; | |||
uint8 fixed_iv_length; | uint8 fixed_iv_length; | |||
skipping to change at page 18, line 19 ¶ | skipping to change at page 18, line 35 ¶ | |||
and are thus empty): | and are thus empty): | |||
client write MAC key | client write MAC key | |||
server write MAC key | server write MAC key | |||
client write encryption key | client write encryption key | |||
server write encryption key | server write encryption key | |||
client write IV | client write IV | |||
server write IV | server write IV | |||
The client write parameters are used by the server when receiving and | The client write parameters are used by the server when receiving and | |||
processing records and vice-versa. The algorithm used for generating | processing records and vice versa. The algorithm used for generating | |||
these items from the security parameters is described in Section 6.3. | these items from the security parameters is described in Section 6.3. | |||
Once the security parameters have been set and the keys have been | Once the security parameters have been set and the keys have been | |||
generated, the connection states can be instantiated by making them | generated, the connection states can be instantiated by making them | |||
the current states. These current states MUST be updated for each | the current states. These current states MUST be updated for each | |||
record processed. Each connection state includes the following | record processed. Each connection state includes the following | |||
elements: | elements: | |||
compression state | compression state | |||
The current state of the compression algorithm. | The current state of the compression algorithm. | |||
cipher state | cipher state | |||
The current state of the encryption algorithm. This will consist | The current state of the encryption algorithm. This will consist | |||
of the scheduled key for that connection. For stream ciphers, this | of the scheduled key for that connection. For stream ciphers, | |||
will also contain whatever state information is necessary to allow | this will also contain whatever state information is necessary to | |||
the stream to continue to encrypt or decrypt data. | allow the stream to continue to encrypt or decrypt data. | |||
MAC key | MAC key | |||
The MAC key for this connection, as generated above. | The MAC key for this connection, as generated above. | |||
sequence number | sequence number | |||
Each connection state contains a sequence number, which is | Each connection state contains a sequence number, which is | |||
maintained separately for read and write states. The sequence | maintained separately for read and write states. The sequence | |||
number MUST be set to zero whenever a connection state is made the | number MUST be set to zero whenever a connection state is made the | |||
active state. Sequence numbers are of type uint64 and may not | active state. Sequence numbers are of type uint64 and may not | |||
exceed 2^64-1. Sequence numbers do not wrap. If a TLS | exceed 2^64-1. Sequence numbers do not wrap. If a TLS | |||
implementation would need to wrap a sequence number, it must | implementation would need to wrap a sequence number, it must | |||
renegotiate instead. A sequence number is incremented after each | renegotiate instead. A sequence number is incremented after each | |||
record: specifically, the first record transmitted under a | record: specifically, the first record transmitted under a | |||
particular connection state MUST use sequence number 0. | particular connection state MUST use sequence number 0. | |||
6.2. Record layer | 6.2. Record Layer | |||
The TLS Record Layer receives uninterpreted data from higher layers | ||||
The TLS record layer receives uninterpreted data from higher layers | ||||
in non-empty blocks of arbitrary size. | in non-empty blocks of arbitrary size. | |||
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 | |||
boundaries are not preserved in the record layer (i.e., multiple | message boundaries are not preserved in the record layer (i.e., | |||
client messages of the same ContentType MAY be coalesced into a | multiple client messages of the same ContentType MAY be coalesced | |||
single TLSPlaintext record, or a single message MAY be fragmented | into a single TLSPlaintext record, or a single message MAY be | |||
across several records). | fragmented across several records). | |||
struct { | struct { | |||
uint8 major; | uint8 major; | |||
uint8 minor; | 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; | |||
skipping to change at page 19, line 37 ¶ | skipping to change at page 20, line 6 ¶ | |||
ContentType type; | ContentType type; | |||
ProtocolVersion version; | ProtocolVersion version; | |||
uint16 length; | uint16 length; | |||
opaque fragment[TLSPlaintext.length]; | opaque fragment[TLSPlaintext.length]; | |||
} TLSPlaintext; | } TLSPlaintext; | |||
type | type | |||
The higher-level protocol used to process the enclosed fragment. | The higher-level protocol used to process the enclosed fragment. | |||
version | version | |||
The version of the protocol being employed. This document | The version of the protocol being employed. This document | |||
describes TLS Version 1.2, which uses the version { 3, 3 }. The | describes TLS Version 1.2, which uses the version { 3, 3 }. The | |||
version value 3.3 is historical, deriving from the use of {3, 1} | 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 | for TLS 1.0. (See Appendix A.1.) Note that a client that | |||
multiple versions of TLS may not know what version will be | supports multiple versions of TLS may not know what version will | |||
employed before it receives the ServerHello. See Appendix E for | be employed before it receives the ServerHello. See Appendix E | |||
discussion about what record layer version number should be | for discussion about what record layer version number should be | |||
employed for ClientHello. | employed for ClientHello. | |||
length | length | |||
The length (in bytes) of the following TLSPlaintext.fragment. The | The length (in bytes) of the following TLSPlaintext.fragment. The | |||
length MUST NOT exceed 2^14. | length MUST NOT exceed 2^14. | |||
fragment | fragment | |||
The application data. This data is transparent and treated as an | The application data. This data is transparent and treated as an | |||
independent block to be dealt with by the higher-level protocol | independent block to be dealt with by the higher-level protocol | |||
specified by the type field. | specified by the type field. | |||
Implementations MUST NOT send zero-length fragments of Handshake, | Implementations MUST NOT send zero-length fragments of Handshake, | |||
Alert, or ChangeCipherSpec content types. Zero-length fragments of | Alert, or ChangeCipherSpec content types. Zero-length fragments of | |||
Application data MAY be sent as they are potentially useful as a | Application data MAY be sent as they are potentially useful as a | |||
traffic analysis countermeasure. | traffic analysis countermeasure. | |||
Note: Data of different TLS Record layer content types MAY be | Note: Data of different TLS record layer content types MAY be | |||
interleaved. Application data is generally of lower precedence for | interleaved. Application data is generally of lower precedence for | |||
transmission than other content types. However, records MUST be | transmission than other content types. However, records MUST be | |||
delivered to the network in the same order as they are protected by | delivered to the network in the same order as they are protected by | |||
the record layer. Recipients MUST receive and process interleaved | the record layer. Recipients MUST receive and process interleaved | |||
application layer traffic during handshakes subsequent to the first | application layer traffic during handshakes subsequent to the first | |||
one on a connection. | one on a connection. | |||
6.2.2. Record Compression and Decompression | 6.2.2. Record Compression and Decompression | |||
All records are compressed using the compression algorithm defined in | All records are compressed using the compression algorithm defined in | |||
the current session state. There is always an active compression | the current session state. There is always an active compression | |||
algorithm; however, initially it is defined as | algorithm; however, initially it is defined as | |||
CompressionMethod.null. The compression algorithm translates a | CompressionMethod.null. The compression algorithm translates a | |||
TLSPlaintext structure into a TLSCompressed structure. Compression | TLSPlaintext structure into a TLSCompressed structure. Compression | |||
functions are initialized with default state information whenever a | functions are initialized with default state information whenever a | |||
connection state is made active. [RFC3749] describes compression | connection state is made active. [RFC3749] describes compression | |||
algorithms for TLS. | algorithms for TLS. | |||
Compression must be lossless and may not increase the content length | Compression must be lossless and may not increase the content length | |||
by more than 1024 bytes. If the decompression function encounters a | by more than 1024 bytes. If the decompression function encounters a | |||
TLSCompressed.fragment that would decompress to a length in excess of | TLSCompressed.fragment that would decompress to a length in excess of | |||
2^14 bytes, it MUST report a fatal decompression failure error. | 2^14 bytes, it MUST report a fatal decompression failure error. | |||
struct { | struct { | |||
ContentType type; /* same as TLSPlaintext.type */ | ContentType type; /* same as TLSPlaintext.type */ | |||
ProtocolVersion version;/* same as TLSPlaintext.version */ | ProtocolVersion version;/* same as TLSPlaintext.version */ | |||
uint16 length; | uint16 length; | |||
opaque fragment[TLSCompressed.length]; | opaque fragment[TLSCompressed.length]; | |||
} TLSCompressed; | } TLSCompressed; | |||
length | length | |||
The length (in bytes) of the following TLSCompressed.fragment. | The length (in bytes) of the following TLSCompressed.fragment. | |||
The length MUST NOT exceed 2^14 + 1024. | The length MUST NOT exceed 2^14 + 1024. | |||
fragment | fragment | |||
The compressed form of TLSPlaintext.fragment. | The compressed form of TLSPlaintext.fragment. | |||
Note: A CompressionMethod.null operation is an identity operation; no | Note: A CompressionMethod.null operation is an identity operation; | |||
fields are altered. | no fields are altered. | |||
Implementation note: Decompression functions are responsible for | Implementation note: Decompression functions are responsible for | |||
ensuring that messages cannot cause internal buffer overflows. | ensuring that messages cannot cause internal buffer overflows. | |||
6.2.3. Record Payload Protection | 6.2.3. Record Payload Protection | |||
The encryption and MAC functions translate a TLSCompressed structure | The encryption and MAC functions translate a TLSCompressed | |||
into a TLSCiphertext. The decryption functions reverse the process. | structure into a TLSCiphertext. The decryption functions reverse | |||
The MAC of the record also includes a sequence number so that | the process. The MAC of the record also includes a sequence | |||
missing, extra, or repeated messages are detectable. | number so that missing, extra, or repeated messages are | |||
detectable. | ||||
struct { | struct { | |||
ContentType type; | ContentType type; | |||
ProtocolVersion version; | ProtocolVersion version; | |||
uint16 length; | uint16 length; | |||
select (SecurityParameters.cipher_type) { | select (SecurityParameters.cipher_type) { | |||
case stream: GenericStreamCipher; | case stream: GenericStreamCipher; | |||
case block: GenericBlockCipher; | case block: GenericBlockCipher; | |||
case aead: GenericAEADCipher; | case aead: GenericAEADCipher; | |||
} fragment; | } fragment; | |||
skipping to change at page 21, line 39 ¶ | skipping to change at page 22, line 8 ¶ | |||
version | version | |||
The version field is identical to TLSCompressed.version. | The version field is identical to TLSCompressed.version. | |||
length | length | |||
The length (in bytes) of the following TLSCiphertext.fragment. | The length (in bytes) of the following TLSCiphertext.fragment. | |||
The length MUST NOT exceed 2^14 + 2048. | The length MUST NOT exceed 2^14 + 2048. | |||
fragment | fragment | |||
The encrypted form of TLSCompressed.fragment, with the MAC. | The encrypted form of TLSCompressed.fragment, with the MAC. | |||
6.2.3.1. Null or Standard Stream Cipher | 6.2.3.1. Null or Standard Stream Cipher | |||
Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6) | Stream ciphers (including BulkCipherAlgorithm.null; see Appendix A.6) | |||
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: | |||
skipping to change at page 22, line 17 ¶ | skipping to change at page 22, line 35 ¶ | |||
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 | |||
do not use a synchronization vector (such as RC4), the stream cipher | that do not use a synchronization vector (such as RC4), the stream | |||
state from the end of one record is simply used on the subsequent | cipher state from the end of one record is simply used on the | |||
packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, encryption | subsequent packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, | |||
consists of the identity operation (i.e., the data is not encrypted, | encryption consists of the identity operation (i.e., the data is not | |||
and the MAC size is zero, implying that no MAC is used). For both | encrypted, and the MAC size is zero, implying that no MAC is used). | |||
null and stream ciphers, TLSCiphertext.length is TLSCompressed.length | For both null and stream ciphers, TLSCiphertext.length is | |||
plus SecurityParameters.mac_length. | TLSCompressed.length plus SecurityParameters.mac_length. | |||
6.2.3.2. CBC Block Cipher | 6.2.3.2. CBC Block Cipher | |||
For block ciphers (such as 3DES, or AES), the encryption and MAC | For block ciphers (such as 3DES or AES), the encryption and MAC | |||
functions convert TLSCompressed.fragment structures to and from block | functions convert TLSCompressed.fragment structures to and from block | |||
TLSCiphertext.fragment structures. | TLSCiphertext.fragment structures. | |||
struct { | struct { | |||
opaque IV[SecurityParameters.record_iv_length]; | opaque IV[SecurityParameters.record_iv_length]; | |||
block-ciphered struct { | block-ciphered struct { | |||
opaque content[TLSCompressed.length]; | opaque content[TLSCompressed.length]; | |||
opaque MAC[SecurityParameters.mac_length]; | opaque MAC[SecurityParameters.mac_length]; | |||
uint8 padding[GenericBlockCipher.padding_length]; | uint8 padding[GenericBlockCipher.padding_length]; | |||
uint8 padding_length; | uint8 padding_length; | |||
}; | }; | |||
} GenericBlockCipher; | } GenericBlockCipher; | |||
The MAC is generated as described in Section 6.2.3.1. | The MAC is generated as described in Section 6.2.3.1. | |||
IV | IV | |||
The Initialization Vector (IV) SHOULD be chosen at random, and | The Initialization Vector (IV) SHOULD be chosen at random, and | |||
MUST be unpredictable. Note that in versions of TLS prior to 1.1, | MUST be unpredictable. Note that in versions of TLS prior to 1.1, | |||
there was no IV field, and the last ciphertext block of the | there was no IV field, and the last ciphertext block of the | |||
previous record (the "CBC residue") was used as the IV. This was | previous record (the "CBC residue") was used as the IV. This was | |||
changed to prevent the attacks described in [CBCATT]. For block | changed to prevent the attacks described in [CBCATT]. For block | |||
ciphers, the IV length is of length | ciphers, the IV length is of length | |||
SecurityParameters.record_iv_length which is equal to the | SecurityParameters.record_iv_length, which is equal to the | |||
SecurityParameters.block_size. | SecurityParameters.block_size. | |||
padding | padding | |||
Padding that is added to force the length of the plaintext to be | Padding that is added to force the length of the plaintext to be | |||
an integral multiple of the block cipher's block length. The | an integral multiple of the block cipher's block length. The | |||
padding MAY be any length up to 255 bytes, as long as it results | padding MAY be any length up to 255 bytes, as long as it results | |||
in the TLSCiphertext.length being an integral multiple of the | in the TLSCiphertext.length being an integral multiple of the | |||
block length. Lengths longer than necessary might be desirable to | block length. Lengths longer than necessary might be desirable to | |||
frustrate attacks on a protocol that are based on analysis of the | frustrate attacks on a protocol that are based on analysis of the | |||
lengths of exchanged messages. Each uint8 in the padding data | lengths of exchanged messages. Each uint8 in the padding data | |||
vector MUST be filled with the padding length value. The receiver | vector MUST be filled with the padding length value. The receiver | |||
MUST check this padding and MUST use the bad_record_mac alert to | MUST check this padding and MUST use the bad_record_mac alert to | |||
indicate padding errors. | indicate padding errors. | |||
padding_length | padding_length | |||
The padding length MUST be such that the total size of the | The padding length MUST be such that the total size of the | |||
GenericBlockCipher structure is a multiple of the cipher's block | GenericBlockCipher structure is a multiple of the cipher's block | |||
length. Legal values range from zero to 255, inclusive. This | length. Legal values range from zero to 255, inclusive. This | |||
length specifies the length of the padding field exclusive of the | length specifies the length of the padding field exclusive of the | |||
padding_length field itself. | padding_length field itself. | |||
The encrypted data length (TLSCiphertext.length) is one more than the | The encrypted data length (TLSCiphertext.length) is one more than the | |||
sum of SecurityParameters.block_length, TLSCompressed.length, | sum of SecurityParameters.block_length, TLSCompressed.length, | |||
SecurityParameters.mac_length, and padding_length. | SecurityParameters.mac_length, and padding_length. | |||
Example: If the block length is 8 bytes, the content length | Example: If the block length is 8 bytes, the content length | |||
(TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, | (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, | |||
then the length before padding is 82 bytes (this does not include the | then the length before padding is 82 bytes (this does not include the | |||
IV. Thus, the padding length modulo 8 must be equal to 6 in order to | IV. Thus, the padding length modulo 8 must be equal to 6 in order to | |||
make the total length an even multiple of 8 bytes (the block length). | make the total length an even multiple of 8 bytes (the block length). | |||
The padding length can be 6, 14, 22, and so on, through 254. If the | The padding length can be 6, 14, 22, and so on, through 254. If the | |||
padding length were the minimum necessary, 6, the padding would be 6 | padding length were the minimum necessary, 6, the padding would be 6 | |||
bytes, each containing the value 6. Thus, the last 8 octets of the | bytes, each containing the value 6. Thus, the last 8 octets of the | |||
GenericBlockCipher before block encryption would be xx 06 06 06 06 06 | GenericBlockCipher before block encryption would be xx 06 06 06 06 06 | |||
06 06, where xx is the last octet of the MAC. | 06 06, where xx is the last octet of the MAC. | |||
Note: With block ciphers in CBC mode (Cipher Block Chaining), it is | Note: With block ciphers in CBC mode (Cipher Block Chaining), it is | |||
critical that the entire plaintext of the record be known before any | critical that the entire plaintext of the record be known before any | |||
ciphertext is transmitted. Otherwise, it is possible for the attacker | ciphertext is transmitted. Otherwise, it is possible for the | |||
to mount the attack described in [CBCATT]. | attacker to mount the attack described in [CBCATT]. | |||
Implementation Note: Canvel et al. [CBCTIME] have demonstrated a | Implementation note: Canvel et al. [CBCTIME] have demonstrated a | |||
timing attack on CBC padding based on the time required to compute | timing attack on CBC padding based on the time required to compute | |||
the MAC. In order to defend against this attack, implementations MUST | the MAC. In order to defend against this attack, implementations | |||
ensure that record processing time is essentially the same whether or | MUST ensure that record processing time is essentially the same | |||
not the padding is correct. In general, the best way to do this is | whether or not the padding is correct. In general, the best way to | |||
to compute the MAC even if the padding is incorrect, and only then | do this is to compute the MAC even if the padding is incorrect, and | |||
reject the packet. For instance, if the pad appears to be incorrect, | only then reject the packet. For instance, if the pad appears to be | |||
the implementation might assume a zero-length pad and then compute | incorrect, the implementation might assume a zero-length pad and then | |||
the MAC. This leaves a small timing channel, since MAC performance | compute the MAC. This leaves a small timing channel, since MAC | |||
depends to some extent on the size of the data fragment, but it is | performance depends to some extent on the size of the data fragment, | |||
not believed to be large enough to be exploitable, due to the large | but it is not believed to be large enough to be exploitable, due to | |||
block size of existing MACs and the small size of the timing signal. | the large block size of existing MACs and the small size of the | |||
timing signal. | ||||
6.2.3.3. AEAD ciphers | 6.2.3.3. AEAD Ciphers | |||
For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function | For AEAD [AEAD] ciphers (such as [CCM] or [GCM]), the AEAD function | |||
converts TLSCompressed.fragment structures to and from AEAD | converts TLSCompressed.fragment structures to and from AEAD | |||
TLSCiphertext.fragment structures. | TLSCiphertext.fragment structures. | |||
struct { | struct { | |||
opaque nonce_explicit[SecurityParameters.record_iv_length]; | opaque nonce_explicit[SecurityParameters.record_iv_length]; | |||
aead-ciphered struct { | aead-ciphered struct { | |||
opaque content[TLSCompressed.length]; | opaque content[TLSCompressed.length]; | |||
}; | }; | |||
} GenericAEADCipher; | } GenericAEADCipher; | |||
AEAD ciphers take as input a single key, a nonce, a plaintext, and | AEAD ciphers take as input a single key, a nonce, a plaintext, and | |||
"additional data" to be included in the authentication check, as | "additional data" to be included in the authentication check, as | |||
described in Section 2.1 of [AEAD]. The key is either the | described in Section 2.1 of [AEAD]. The key is either the | |||
client_write_key or the server_write_key. No MAC key is used. | client_write_key or the server_write_key. No MAC key is used. | |||
Each AEAD cipher suite MUST specify how the nonce supplied to the | Each AEAD cipher suite MUST specify how the nonce supplied to the | |||
AEAD operation is constructed, and what is the length of the | AEAD operation is constructed, and what is the length of the | |||
GenericAEADCipher.nonce_explicit part. In many cases, it is | GenericAEADCipher.nonce_explicit part. In many cases, it is | |||
appropriate to use the partially implicit nonce technique described | appropriate to use the partially implicit nonce technique described | |||
in Section 3.2.1 of [AEAD]; with record_iv_length being the length of | in Section 3.2.1 of [AEAD]; with record_iv_length being the length of | |||
the explicit part. In this case, the implicit part SHOULD be derived | the explicit part. In this case, the implicit part SHOULD be derived | |||
from key_block as client_write_iv and server_write_iv (as described | from key_block as client_write_iv and server_write_iv (as described | |||
in Section 6.3), and the explicit part is included in | in Section 6.3), and the explicit part is included in | |||
GenericAEAEDCipher.nonce_explicit. | GenericAEAEDCipher.nonce_explicit. | |||
The plaintext is the TLSCompressed.fragment. | The plaintext is the TLSCompressed.fragment. | |||
The additional authenticated data, which we denote as | The additional authenticated data, which we denote as | |||
additional_data, is defined as follows: | additional_data, is defined as follows: | |||
additional_data = seq_num + TLSCompressed.type + | additional_data = seq_num + TLSCompressed.type + | |||
TLSCompressed.version + TLSCompressed.length; | TLSCompressed.version + TLSCompressed.length; | |||
Where "+" denotes concatenation. | where "+" denotes concatenation. | |||
The aead_output consists of the ciphertext output by the AEAD | The aead_output consists of the ciphertext output by the AEAD | |||
encryption operation. The length will generally be larger than | encryption operation. The length will generally be larger than | |||
TLSCompressed.length, but by an amount that varies with the AEAD | TLSCompressed.length, but by an amount that varies with the AEAD | |||
cipher. Since the ciphers might incorporate padding, the amount of | cipher. Since the ciphers might incorporate padding, the amount of | |||
overhead could vary with different TLSCompressed.length values. Each | overhead could vary with different TLSCompressed.length values. Each | |||
AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. | AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. | |||
Symbolically, | Symbolically, | |||
AEADEncrypted = AEAD-Encrypt(key, nonce, plaintext, | AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, | |||
additional_data) | additional_data) | |||
In order to decrypt and verify, the cipher takes as input the key, | In order to decrypt and verify, the cipher takes as input the key, | |||
nonce, the "additional_data", and the AEADEncrypted value. The output | nonce, the "additional_data", and the AEADEncrypted value. The | |||
is either the plaintext or an error indicating that the decryption | output is either the plaintext or an error indicating that the | |||
failed. There is no separate integrity check. I.e., | decryption failed. There is no separate integrity check. That is: | |||
TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce, | TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce, | |||
AEADEncrypted, | AEADEncrypted, | |||
additional_data) | additional_data) | |||
If the decryption fails, a fatal bad_record_mac alert MUST be | If the decryption fails, a fatal bad_record_mac alert MUST be | |||
generated. | generated. | |||
6.3. Key Calculation | 6.3. Key Calculation | |||
The Record Protocol requires an algorithm to generate keys required | The Record Protocol requires an algorithm to generate keys required | |||
by the current connection state (see Appendix A.6) from the security | by the current connection state (see Appendix A.6) from the security | |||
parameters provided by the handshake protocol. | parameters provided by the handshake protocol. | |||
The master secret is expanded into a sequence of secure bytes, which | The master secret is expanded into a sequence of secure bytes, which | |||
is then split to a client write MAC key, a server write MAC key, a | is then split to a client write MAC key, a server write MAC key, a | |||
client write encryption key, and a server write encryption key. Each | client write encryption key, and a server write encryption key. Each | |||
of these is generated from the byte sequence in that order. Unused | of these is generated from the byte sequence in that order. Unused | |||
values are empty. Some AEAD ciphers may additionally require a | values are empty. Some AEAD ciphers may additionally require a | |||
client write IV and a server write IV (see Section 6.2.3.3). | client write IV and a server write IV (see Section 6.2.3.3). | |||
When keys and MAC keys are generated, the master secret is used as an | When keys and MAC keys are generated, the master secret is used as an | |||
entropy source. | entropy source. | |||
To generate the key material, compute | To generate the key material, compute | |||
key_block = PRF(SecurityParameters.master_secret, | key_block = PRF(SecurityParameters.master_secret, | |||
"key expansion", | "key expansion", | |||
SecurityParameters.server_random + | SecurityParameters.server_random + | |||
SecurityParameters.client_random); | SecurityParameters.client_random); | |||
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] | |||
Currently, the client_write_IV and server_write_IV are only generated | Currently, the client_write_IV and server_write_IV are only generated | |||
for implicit nonce techniques as described in Section 3.2.1 of | for implicit nonce techniques as described in Section 3.2.1 of | |||
[AEAD]. | [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_SHA256. It requires 2 x 32 | requires the most material is AES_256_CBC_SHA256. It requires 2 x 32 | |||
byte keys and 2 x 32 byte MAC keys, for a total 128 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, | |||
which consists of the following items: | which consists of the following items: | |||
session identifier | session identifier | |||
An arbitrary byte sequence chosen by the server to identify an | An arbitrary byte sequence chosen by the server to identify an | |||
active or resumable session state. | active or resumable session state. | |||
peer certificate | peer certificate | |||
X509v3 [PKIX] certificate of the peer. This element of the state | X509v3 [PKIX] certificate of the peer. This element of the state | |||
may be null. | may be null. | |||
compression method | compression method | |||
The algorithm used to compress data prior to encryption. | The algorithm used to compress data prior to encryption. | |||
cipher spec | cipher spec | |||
Specifies the pseudorandom function (PRF) used to generate keying | Specifies the pseudorandom function (PRF) used to generate keying | |||
material, the bulk data encryption algorithm (such as null, AES, | material, the bulk data encryption algorithm (such as null, AES, | |||
etc.) and a MAC algorithm (such as HMAC-SHA1). It also defines | etc.) and the MAC algorithm (such as HMAC-SHA1). It also defines | |||
cryptographic attributes such as the mac_length. (See Appendix A.6 | cryptographic attributes such as the mac_length. (See Appendix | |||
for formal definition.) | A.6 for formal definition.) | |||
master secret | master secret | |||
48-byte secret shared between the client and server. | 48-byte secret shared between the client and server. | |||
is resumable | is resumable | |||
A flag indicating whether the session can be used to initiate new | A flag indicating whether the session can be used to initiate new | |||
connections. | connections. | |||
These items are then used to create security parameters for use by | These items are then used to create security parameters for use by | |||
the Record Layer when protecting application data. Many connections | the record layer when protecting application data. Many connections | |||
can be instantiated using the same session through the resumption | can be instantiated using the same session through the resumption | |||
feature of the TLS Handshake Protocol. | feature of the TLS Handshake Protocol. | |||
7.1. Change Cipher Spec Protocol | 7.1. Change Cipher Spec Protocol | |||
The change cipher spec protocol exists to signal transitions in | The change cipher spec protocol exists to signal transitions in | |||
ciphering strategies. The protocol consists of a single message, | ciphering strategies. The protocol consists of a single message, | |||
which is encrypted and compressed under the current (not the pending) | which is encrypted and compressed under the current (not the pending) | |||
connection state. The message consists of a single byte of value 1. | connection state. The message consists of a single byte of value 1. | |||
struct { | struct { | |||
enum { change_cipher_spec(1), (255) } type; | enum { change_cipher_spec(1), (255) } type; | |||
} ChangeCipherSpec; | } ChangeCipherSpec; | |||
The ChangeCipherSpec message is sent by both the client and the | The ChangeCipherSpec message is sent by both the client and the | |||
server to notify the receiving party that subsequent records will be | server to notify the receiving party that subsequent records will be | |||
protected under the newly negotiated CipherSpec and keys. Reception | protected under the newly negotiated CipherSpec and keys. Reception | |||
of this message causes the receiver to instruct the Record Layer to | of this message causes the receiver to instruct the record layer to | |||
immediately copy the read pending state into the read current state. | immediately copy the read pending state into the read current state. | |||
Immediately after sending this message, the sender MUST instruct the | Immediately after sending this message, the sender MUST instruct the | |||
record layer to make the write pending state the write active state. | record layer to make the write pending state the write active state. | |||
(See Section 6.1.) The change cipher spec message is sent during the | ||||
(See Section 6.1.) The ChangeCipherSpec message is sent during the | ||||
handshake after the security parameters have been agreed upon, but | handshake after the security parameters have been agreed upon, but | |||
before the verifying finished message is sent. | before the verifying Finished message is sent. | |||
Note: If a rehandshake occurs while data is flowing on a connection, | Note: If a rehandshake occurs while data is flowing on a connection, | |||
the communicating parties may continue to send data using the old | the communicating parties may continue to send data using the old | |||
CipherSpec. However, once the ChangeCipherSpec has been sent, the new | CipherSpec. However, once the ChangeCipherSpec has been sent, the | |||
CipherSpec MUST be used. The first side to send the ChangeCipherSpec | new CipherSpec MUST be used. The first side to send the | |||
does not know that the other side has finished computing the new | ChangeCipherSpec does not know that the other side has finished | |||
keying material (e.g., if it has to perform a time consuming public | computing the new keying material (e.g., if it has to perform a | |||
key operation). Thus, a small window of time, during which the | time-consuming public key operation). Thus, a small window of time, | |||
recipient must buffer the data, MAY exist. In practice, with modern | during which the recipient must buffer the data, MAY exist. In | |||
machines this interval is likely to be fairly short. | practice, with modern machines this interval is likely to be fairly | |||
short. | ||||
7.2. Alert Protocol | 7.2. Alert Protocol | |||
One of the content types supported by the TLS Record layer is the | One of the content types supported by the TLS record layer is the | |||
alert type. Alert messages convey the severity of the message | alert type. Alert messages convey the severity of the message | |||
(warning or fatal) and a description of the alert. Alert messages | (warning or fatal) and a description of the alert. Alert messages | |||
with a level of fatal result in the immediate termination of the | with a level of fatal result in the immediate termination of the | |||
connection. In this case, other connections corresponding to the | connection. In this case, other connections corresponding to the | |||
session may continue, but the session identifier MUST be invalidated, | session may continue, but the session identifier MUST be invalidated, | |||
preventing the failed session from being used to establish new | preventing the failed session from being used to establish new | |||
connections. Like other messages, alert messages are encrypted and | connections. Like other messages, alert messages are encrypted and | |||
compressed, as specified by the current connection state. | compressed, as specified by the current connection state. | |||
enum { warning(1), fatal(2), (255) } AlertLevel; | enum { warning(1), fatal(2), (255) } AlertLevel; | |||
enum { | enum { | |||
close_notify(0), | close_notify(0), | |||
unexpected_message(10), | unexpected_message(10), | |||
bad_record_mac(20), | bad_record_mac(20), | |||
decryption_failed_RESERVED(21), | decryption_failed_RESERVED(21), | |||
record_overflow(22), | record_overflow(22), | |||
skipping to change at page 28, line 43 ¶ | skipping to change at page 29, line 19 ¶ | |||
no_renegotiation(100), | no_renegotiation(100), | |||
unsupported_extension(110), | unsupported_extension(110), | |||
(255) | (255) | |||
} AlertDescription; | } AlertDescription; | |||
struct { | struct { | |||
AlertLevel level; | AlertLevel level; | |||
AlertDescription description; | AlertDescription description; | |||
} Alert; | } Alert; | |||
7.2.1. Closure Alerts | 7.2.1. Closure Alerts | |||
The client and the server must share knowledge that the connection is | The client and the server must share knowledge that the connection is | |||
ending in order to avoid a truncation attack. Either party may | ending in order to avoid a truncation attack. Either party may | |||
initiate the exchange of closing messages. | initiate the exchange of closing messages. | |||
close_notify | close_notify | |||
This message notifies the recipient that the sender will not send | This message notifies the recipient that the sender will not send | |||
any more messages on this connection. Note that as of TLS 1.1, | any more messages on this connection. Note that as of TLS 1.1, | |||
failure to properly close a connection no longer requires that a | failure to properly close a connection no longer requires that a | |||
session not be resumed. This is a change from TLS 1.0 to conform | session not be resumed. This is a change from TLS 1.0 to conform | |||
with widespread implementation practice. | with widespread implementation practice. | |||
Either party may initiate a close by sending a close_notify alert. | Either party may initiate a close by sending a close_notify alert. | |||
Any data received after a closure alert is ignored. | Any data received after a closure alert is ignored. | |||
Unless some other fatal alert has been transmitted, each party is | Unless some other fatal alert has been transmitted, each party is | |||
required to send a close_notify alert before closing the write side | required to send a close_notify alert before closing the write side | |||
of the connection. The other party MUST respond with a close_notify | of the connection. The other party MUST respond with a close_notify | |||
alert of its own and close down the connection immediately, | alert of its own and close down the connection immediately, | |||
discarding any pending writes. It is not required for the initiator | discarding any pending writes. It is not required for the initiator | |||
of the close to wait for the responding close_notify alert before | of the close to wait for the responding close_notify alert before | |||
closing the read side of the connection. | closing the read side of the connection. | |||
If the application protocol using TLS provides that any data may be | If the application protocol using TLS provides that any data may be | |||
carried over the underlying transport after the TLS connection is | carried over the underlying transport after the TLS connection is | |||
closed, the TLS implementation must receive the responding | closed, the TLS implementation must receive the responding | |||
close_notify alert before indicating to the application layer that | close_notify alert before indicating to the application layer that | |||
the TLS connection has ended. If the application protocol will not | the TLS connection has ended. If the application protocol will not | |||
transfer any additional data, but will only close the underlying | transfer any additional data, but will only close the underlying | |||
transport connection, then the implementation MAY choose to close the | transport connection, then the implementation MAY choose to close the | |||
transport without waiting for the responding close_notify. No part of | transport without waiting for the responding close_notify. No part | |||
this standard should be taken to dictate the manner in which a usage | of this standard should be taken to dictate the manner in which a | |||
profile for TLS manages its data transport, including when | usage profile for TLS manages its data transport, including when | |||
connections are opened or closed. | connections are opened or closed. | |||
Note: It is assumed that closing a connection reliably delivers | Note: It is assumed that closing a connection reliably delivers | |||
pending data before destroying the transport. | pending data before destroying the transport. | |||
7.2.2. Error Alerts | 7.2.2. Error Alerts | |||
Error handling in the TLS Handshake protocol is very simple. When an | Error handling in the TLS Handshake protocol is very simple. When an | |||
error is detected, the detecting party sends a message to the other | error is detected, the detecting party sends a message to the other | |||
party. Upon transmission or receipt of a fatal alert message, both | party. Upon transmission or receipt of a fatal alert message, both | |||
parties immediately close the connection. Servers and clients MUST | parties immediately close the connection. Servers and clients MUST | |||
forget any session-identifiers, keys, and secrets associated with a | forget any session-identifiers, keys, and secrets associated with a | |||
failed connection. Thus, any connection terminated with a fatal alert | failed connection. Thus, any connection terminated with a fatal | |||
MUST NOT be resumed. | alert 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. For all errors where an alert level is not explicitly | the connection. For all errors where an alert level is not | |||
specified, the sending party MAY determine at its discretion whether | explicitly specified, the sending party MAY determine at its | |||
to treat this as a fatal error or not. If the implementation chooses | discretion whether to treat this as a fatal error or not. If the | |||
to send an alert but intends to close the connection immediately | implementation chooses to send an alert but intends to close the | |||
afterwards, it MUST send that alert at the fatal alert level. | 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. Given this, the | send a fatal alert to terminate the connection. Given this, the | |||
sending party cannot, in general, know how the receiving party will | sending party cannot, in general, know how the receiving party will | |||
behave. Therefore, warning alerts are not very useful when the | behave. Therefore, warning alerts are not very useful when the | |||
sending party wants to continue the connection, and thus are | sending party wants to continue the connection, and thus are | |||
sometimes omitted. For example, if a peer decides to accept an | sometimes omitted. For example, if a peer decides to accept an | |||
expired certificate (perhaps after confirming this with the user) and | expired certificate (perhaps after confirming this with the user) and | |||
wants to continue the connection, it would not generally send a | wants to continue the connection, it would not generally send a | |||
certificate_expired alert. | 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 and should | checked, weren't correct. This message is always fatal and should | |||
never be observed in communication between proper implementations | never be observed in communication between proper implementations | |||
(except when messages were corrupted in the network). | (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 and | with more than 2^14+1024 bytes. This message is always fatal and | |||
should never be observed in communication between proper | should never be observed in communication between proper | |||
implementations (except when messages were corrupted in the | implementations (except when messages were corrupted in the | |||
network). | 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 and should never be observed in communication between proper | fatal and should never be observed in communication between proper | |||
implementations. | 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. | |||
bad_certificate | bad_certificate | |||
A certificate was corrupt, contained signatures that did not | A certificate was corrupt, contained signatures that did not | |||
verify correctly, etc. | verify correctly, etc. | |||
unsupported_certificate | unsupported_certificate | |||
skipping to change at page 31, line 33 ¶ | skipping to change at page 32, line 14 ¶ | |||
certificate_expired | certificate_expired | |||
A certificate has expired or is not currently valid. | A certificate has expired or is not currently valid. | |||
certificate_unknown | certificate_unknown | |||
Some other (unspecified) issue arose in processing the | Some other (unspecified) issue arose in processing the | |||
certificate, rendering it unacceptable. | certificate, rendering it unacceptable. | |||
illegal_parameter | illegal_parameter | |||
A field in the handshake was out of range or inconsistent with | A field in the handshake was out of range or inconsistent with | |||
other fields. This message is always fatal. | other fields. This message is always fatal. | |||
unknown_ca | unknown_ca | |||
A valid certificate chain or partial chain was received, but the | A valid certificate chain or partial chain was received, but the | |||
certificate was not accepted because the CA certificate could not | certificate was not accepted because the CA certificate could not | |||
be located or couldn't be matched with a known, trusted CA. This | be located or couldn't be matched with a known, trusted CA. This | |||
message is always fatal. | message is always fatal. | |||
access_denied | access_denied | |||
A valid certificate was received, but when access control was | A valid certificate was received, but when access control was | |||
applied, the sender decided not to proceed with negotiation. 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 and should never be observed in | message is always fatal and should never be observed in | |||
communication between proper implementations (except when messages | communication between proper implementations (except when messages | |||
were corrupted in the network). | 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 or validate a finished message. | to correctly verify a signature or validate a Finished message. | |||
This message is always fatal. | 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. | |||
insufficient_security | insufficient_security | |||
Returned instead of handshake_failure when a negotiation has | Returned instead of handshake_failure when a negotiation has | |||
failed specifically because the server requires ciphers more | failed specifically because the server requires ciphers more | |||
secure than those supported by the client. This message is always | secure than those supported by the client. This message is always | |||
fatal. | fatal. | |||
internal_error | internal_error | |||
An internal error unrelated to the peer or the correctness of the | An internal error unrelated to the peer or the correctness of the | |||
protocol (such as a memory allocation failure) makes it impossible | protocol (such as a memory allocation failure) makes it impossible | |||
to continue. This message is always fatal. | to continue. This message is always fatal. | |||
user_canceled | user_canceled | |||
This handshake is being canceled for some reason unrelated to a | This handshake is being canceled for some reason unrelated to a | |||
protocol failure. If the user cancels an operation after the | protocol failure. If the user cancels an operation after the | |||
handshake is complete, just closing the connection by sending a | handshake is complete, just closing the connection by sending a | |||
close_notify is more appropriate. This alert should be followed by | close_notify is more appropriate. This alert should be followed | |||
a close_notify. This message is generally a warning. | by a close_notify. This message is generally a warning. | |||
no_renegotiation | no_renegotiation | |||
Sent by the client in response to a hello request or by the server | Sent by the client in response to a hello request or by the server | |||
in response to a client hello after initial handshaking. Either | in response to a client hello after initial handshaking. Either | |||
of these would normally lead to renegotiation; when that is not | of these would normally lead to renegotiation; when that is not | |||
appropriate, the recipient should respond with this alert. At | appropriate, the recipient should respond with this alert. At | |||
that point, the original requester can decide whether to proceed | that point, the original requester can decide whether to proceed | |||
with the connection. One case where this would be appropriate is | with the connection. One case where this would be appropriate is | |||
where a server has spawned a process to satisfy a request; the | where a server has spawned a process to satisfy a request; the | |||
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. | |||
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. | |||
The TLS Handshake Protocol involves the following steps: | The TLS Handshake Protocol involves the following steps: | |||
- Exchange hello messages to agree on algorithms, exchange random | - Exchange hello messages to agree on algorithms, exchange random | |||
values, and check for session resumption. | values, and check for session resumption. | |||
- Exchange the necessary cryptographic parameters to allow the | - Exchange the necessary cryptographic parameters to allow the | |||
skipping to change at page 33, line 40 ¶ | skipping to change at page 34, line 27 ¶ | |||
random values. | random values. | |||
- Provide security parameters to the record layer. | - Provide security parameters to the record layer. | |||
- Allow the client and server to verify that their peer has | - Allow the client and server to verify that their peer has | |||
calculated the same security parameters and that the handshake | calculated the same security parameters and that the handshake | |||
occurred without tampering by an attacker. | occurred without tampering by an attacker. | |||
Note that higher layers should not be overly reliant on whether TLS | Note that higher layers should not be overly reliant on whether TLS | |||
always negotiates the strongest possible connection between two | always negotiates the strongest possible connection between two | |||
peers. There are a number of ways in which a man in the middle | peers. There are a number of ways in which a man-in-the-middle | |||
attacker can attempt to make two entities drop down to the least | attacker can attempt to make two entities drop down to the least | |||
secure method they support. The protocol has been designed to | secure method they support. The protocol has been designed to | |||
minimize this risk, but there are still attacks available: for | minimize this risk, but there are still attacks available: for | |||
example, an attacker could block access to the port a secure service | example, an attacker could block access to the port a secure service | |||
runs on, or attempt to get the peers to negotiate an unauthenticated | runs on, or attempt to get the peers to negotiate an unauthenticated | |||
connection. The fundamental rule is that higher levels must be | connection. The fundamental rule is that higher levels must be | |||
cognizant of what their security requirements are and never transmit | cognizant of what their security requirements are and never transmit | |||
information over a channel less secure than what they require. The | information over a channel less secure than what they require. The | |||
TLS protocol is secure in that any cipher suite offers its promised | TLS protocol is secure in that any cipher suite offers its promised | |||
level of security: if you negotiate 3DES with a 1024 bit RSA key | level of security: if you negotiate 3DES with a 1024-bit RSA key | |||
exchange with a host whose certificate you have verified, you can | exchange with a host whose certificate you have verified, you can | |||
expect to be that secure. | expect to be that secure. | |||
These goals are achieved by the handshake protocol, which can be | These goals are achieved by the handshake protocol, which can be | |||
summarized as follows: The client sends a client hello message to | summarized as follows: The client sends a ClientHello message to | |||
which the server must respond with a server hello message, or else a | which the server must respond with a ServerHello message, or else a | |||
fatal error will occur and the connection will fail. The client hello | fatal error will occur and the connection will fail. The ClientHello | |||
and server hello are used to establish security enhancement | and ServerHello are used to establish security enhancement | |||
capabilities between client and server. The client hello and server | capabilities between client and server. The ClientHello and | |||
hello establish the following attributes: Protocol Version, Session | ServerHello establish the following attributes: Protocol Version, | |||
ID, Cipher Suite, and Compression Method. Additionally, two random | Session ID, Cipher Suite, and Compression Method. Additionally, two | |||
values are generated and exchanged: ClientHello.random and | random values are generated and exchanged: ClientHello.random and | |||
ServerHello.random. | ServerHello.random. | |||
The actual key exchange uses up to four messages: the server | The actual key exchange uses up to four messages: the server | |||
Certificate, the ServerKeyExchange, the client Certificate, and the | Certificate, the ServerKeyExchange, the client Certificate, and the | |||
ClientKeyExchange. New key exchange methods can be created by | ClientKeyExchange. New key exchange methods can be created by | |||
specifying a format for these messages and by defining the use of the | specifying a format for these messages and by defining the use of the | |||
messages to allow the client and server to agree upon a shared | messages to allow the client and server to agree upon a shared | |||
secret. This secret MUST be quite long; currently defined key | secret. This secret MUST be quite long; currently defined key | |||
exchange methods exchange secrets that range from 46 bytes upwards. | exchange methods exchange secrets that range from 46 bytes upwards. | |||
Following the hello messages, the server will send its certificate in | Following the hello messages, the server will send its certificate in | |||
a Certificate message if it is to be authenticated. Additionally, a | a Certificate message if it is to be authenticated. Additionally, a | |||
ServerKeyExchange message may be sent, if it is required (e.g., if | ServerKeyExchange message may be sent, if it is required (e.g., if | |||
the server has no certificate, or if its certificate is for signing | the server has no certificate, or if its certificate is for signing | |||
only). If the server is authenticated, it may request a certificate | only). If the server is authenticated, it may request a certificate | |||
from the client, if that is appropriate to the cipher suite selected. | from the client, if that is appropriate to the cipher suite selected. | |||
Next, the server will send the ServerHelloDone message, indicating | Next, the server will send the ServerHelloDone message, indicating | |||
that the hello-message phase of the handshake is complete. The server | that the hello-message phase of the handshake is complete. The | |||
will then wait for a client response. If the server has sent a | server will then wait for a client response. If the server has sent | |||
CertificateRequest message, the client MUST send the Certificate | a CertificateRequest message, the client MUST send the Certificate | |||
message. The ClientKeyExchange message is now sent, and the content | message. The ClientKeyExchange message is now sent, and the content | |||
of that message will depend on the public key algorithm selected | of that message will depend on the public key algorithm selected | |||
between the client hello and the server hello. If the client has sent | between the ClientHello and the ServerHello. If the client has sent | |||
a certificate with signing ability, a digitally-signed | a certificate with signing ability, a digitally-signed | |||
CertificateVerify message is sent to explicitly verify possession of | CertificateVerify message is sent to explicitly verify possession of | |||
the private key in the certificate. | the private key in the certificate. | |||
At this point, a ChangeCipherSpec message is sent by the client, and | At this point, a ChangeCipherSpec message is sent by the client, and | |||
the client copies the pending Cipher Spec into the current Cipher | the client copies the pending Cipher Spec into the current Cipher | |||
Spec. The client then immediately sends the Finished message under | Spec. The client then immediately sends the Finished message under | |||
the new algorithms, keys, and secrets. In response, the server will | the new algorithms, keys, and secrets. In response, the server will | |||
send its own ChangeCipherSpec message, transfer the pending to the | send its own ChangeCipherSpec message, transfer the pending to the | |||
current Cipher Spec, and send its Finished message under the new | current Cipher Spec, and send its Finished message under the new | |||
Cipher Spec. At this point, the handshake is complete, and the client | Cipher Spec. At this point, the handshake is complete, and the | |||
and server may begin to exchange application layer data. (See flow | client and server may begin to exchange application layer data. (See | |||
chart below.) Application data MUST NOT be sent prior to the | flow chart below.) Application data MUST NOT be sent prior to the | |||
completion of the first handshake (before a cipher suite other than | completion of the first handshake (before a cipher suite other than | |||
TLS_NULL_WITH_NULL_NULL is established). | TLS_NULL_WITH_NULL_NULL is established). | |||
Client Server | Client Server | |||
ClientHello --------> | ClientHello --------> | |||
ServerHello | ServerHello | |||
Certificate* | Certificate* | |||
ServerKeyExchange* | ServerKeyExchange* | |||
CertificateRequest* | CertificateRequest* | |||
<-------- ServerHelloDone | <-------- ServerHelloDone | |||
Certificate* | Certificate* | |||
ClientKeyExchange | ClientKeyExchange | |||
CertificateVerify* | CertificateVerify* | |||
[ChangeCipherSpec] | [ChangeCipherSpec] | |||
Finished --------> | Finished --------> | |||
[ChangeCipherSpec] | [ChangeCipherSpec] | |||
<-------- Finished | <-------- Finished | |||
Application Data <-------> Application Data | Application Data <-------> Application Data | |||
Fig. 1. Message flow for a full handshake | Figure 1. Message flow for a full handshake | |||
* Indicates optional or situation-dependent messages that are not | * Indicates optional or situation-dependent messages that are not | |||
always sent. | always sent. | |||
Note: To help avoid pipeline stalls, ChangeCipherSpec is an | Note: To help avoid pipeline stalls, ChangeCipherSpec is an | |||
independent TLS Protocol content type, and is not actually a TLS | independent TLS protocol content type, and is not actually a TLS | |||
handshake message. | handshake message. | |||
When the client and server decide to resume a previous session or | When the client and server decide to resume a previous session or | |||
duplicate an existing session (instead of negotiating new security | duplicate an existing session (instead of negotiating new security | |||
parameters), the message flow is as follows: | parameters), the message flow is as follows: | |||
The client sends a ClientHello using the Session ID of the session to | The client sends a ClientHello using the Session ID of the session to | |||
be resumed. The server then checks its session cache for a match. If | be resumed. The server then checks its session cache for a match. | |||
a match is found, and the server is willing to re-establish the | If a match is found, and the server is willing to re-establish the | |||
connection under the specified session state, it will send a | connection under the specified session state, it will send a | |||
ServerHello with the same Session ID value. At this point, both | ServerHello with the same Session ID value. At this point, both | |||
client and server MUST send ChangeCipherSpec messages and proceed | client and server MUST send ChangeCipherSpec messages and proceed | |||
directly to Finished messages. Once the re-establishment is complete, | directly to Finished messages. Once the re-establishment is | |||
the client and server MAY begin to exchange application layer data. | complete, the client and server MAY begin to exchange application | |||
(See flow chart below.) If a Session ID match is not found, the | layer data. (See flow chart below.) If a Session ID match is not | |||
server generates a new session ID and the TLS client and server | found, the server generates a new session ID, and the TLS client and | |||
perform a full handshake. | server perform a full handshake. | |||
Client Server | Client Server | |||
ClientHello --------> | ClientHello --------> | |||
ServerHello | ServerHello | |||
[ChangeCipherSpec] | [ChangeCipherSpec] | |||
<-------- Finished | <-------- Finished | |||
[ChangeCipherSpec] | [ChangeCipherSpec] | |||
Finished --------> | Finished --------> | |||
Application Data <-------> Application Data | Application Data <-------> Application Data | |||
Fig. 2. Message flow for an abbreviated handshake | Figure 2. Message flow for an abbreviated handshake | |||
The contents and significance of each message will be presented in | The contents and significance of each message will be presented in | |||
detail in the following sections. | detail in the following sections. | |||
7.4. Handshake Protocol | 7.4. Handshake Protocol | |||
The TLS Handshake Protocol is one of the defined higher-level clients | The TLS Handshake Protocol is one of the defined higher-level clients | |||
of the TLS Record Protocol. This protocol is used to negotiate the | of the TLS Record Protocol. This protocol is used to negotiate the | |||
secure attributes of a session. Handshake messages are supplied to | secure attributes of a session. Handshake messages are supplied to | |||
the TLS Record Layer, where they are encapsulated within one or more | the TLS record layer, where they are encapsulated within one or more | |||
TLSPlaintext structures, which are processed and transmitted as | TLSPlaintext structures, which are processed and transmitted as | |||
specified by the current active session state. | specified by the current active session state. | |||
enum { | enum { | |||
hello_request(0), client_hello(1), server_hello(2), | hello_request(0), client_hello(1), server_hello(2), | |||
certificate(11), server_key_exchange (12), | certificate(11), server_key_exchange (12), | |||
certificate_request(13), server_hello_done(14), | certificate_request(13), server_hello_done(14), | |||
certificate_verify(15), client_key_exchange(16), | certificate_verify(15), client_key_exchange(16), | |||
finished(20), (255) | finished(20), (255) | |||
} HandshakeType; | } HandshakeType; | |||
skipping to change at page 38, line 7 ¶ | skipping to change at page 38, line 7 ¶ | |||
case certificate_request: CertificateRequest; | case certificate_request: CertificateRequest; | |||
case server_hello_done: ServerHelloDone; | case server_hello_done: ServerHelloDone; | |||
case certificate_verify: CertificateVerify; | case certificate_verify: CertificateVerify; | |||
case client_key_exchange: ClientKeyExchange; | case client_key_exchange: ClientKeyExchange; | |||
case finished: Finished; | case finished: Finished; | |||
} body; | } body; | |||
} Handshake; | } Handshake; | |||
The handshake protocol messages are presented below in the order they | The handshake protocol messages are presented below in the order they | |||
MUST be sent; sending handshake messages in an unexpected order | MUST be sent; sending handshake messages in an unexpected order | |||
results in a fatal error. Unneeded handshake messages can be omitted, | results in a fatal error. Unneeded handshake messages can be | |||
however. Note one exception to the ordering: the Certificate message | omitted, however. Note one exception to the ordering: the | |||
is used twice in the handshake (from server to client, then from | Certificate message is used twice in the handshake (from server to | |||
client to server), but described only in its first position. The one | client, then from client to server), but described only in its first | |||
message that is not bound by these ordering rules is the HelloRequest | position. The one message that is not bound by these ordering rules | |||
message, which can be sent at any time, but which SHOULD be ignored | is the HelloRequest message, which can be sent at any time, but which | |||
by the client if it arrives in the middle of a handshake. | SHOULD be ignored by the client if it arrives in the middle of a | |||
handshake. | ||||
New Handshake message types are assigned by IANA as described in | New handshake message types are assigned by IANA as described in | |||
Section 12. | Section 12. | |||
7.4.1. Hello Messages | 7.4.1. Hello Messages | |||
The hello phase messages are used to exchange security enhancement | The hello phase messages are used to exchange security enhancement | |||
capabilities between the client and server. When a new session | capabilities between the client and server. When a new session | |||
begins, the Record Layer's connection state encryption, hash, and | begins, the record layer's connection state encryption, hash, and | |||
compression algorithms are initialized to null. The current | compression algorithms are initialized to null. The current | |||
connection state is used for renegotiation messages. | connection state is used for renegotiation messages. | |||
7.4.1.1. Hello Request | 7.4.1.1. Hello Request | |||
When this message will be sent: | When this message will be sent: | |||
The HelloRequest message MAY be sent by the server at any time. | The HelloRequest message MAY be sent by the server at any time. | |||
Meaning of this message: | Meaning of this message: | |||
HelloRequest is a simple notification that the client should begin | HelloRequest is a simple notification that the client should begin | |||
the negotiation process anew. In response, the client should a | the negotiation process anew. In response, the client should send | |||
ClientHello message when convenient. This message is not intended | a ClientHello message when convenient. This message is not | |||
to establish which side is the client or server but merely to | intended to establish which side is the client or server but | |||
initiate a new negotiation. Servers SHOULD NOT send a HelloRequest | merely to initiate a new negotiation. Servers SHOULD NOT send a | |||
immediately upon the client's initial connection. It is the | HelloRequest immediately upon the client's initial connection. It | |||
client's job to send a ClientHello at that time. | is the client's job to send a ClientHello at that time. | |||
This message will be ignored by the client if the client is | This message will be ignored by the client if the client is | |||
currently negotiating a session. This message MAY be ignored by | currently negotiating a session. This message MAY be ignored by | |||
the client if it does not wish to renegotiate a session, or the | the client if it does not wish to renegotiate a session, or the | |||
client may, if it wishes, respond with a no_renegotiation alert. | client may, if it wishes, respond with a no_renegotiation alert. | |||
Since handshake messages are intended to have transmission | Since handshake messages are intended to have transmission | |||
precedence over application data, it is expected that the | precedence over application data, it is expected that the | |||
negotiation will begin before no more than a few records are | negotiation will begin before no more than a few records are | |||
received from the client. If the server sends a HelloRequest but | received from the client. If the server sends a HelloRequest but | |||
does not receive a ClientHello in response, it may close the | does not receive a ClientHello in response, it may close the | |||
connection with a fatal alert. | connection with a fatal alert. | |||
After sending a HelloRequest, servers SHOULD NOT repeat the | After sending a HelloRequest, servers SHOULD NOT repeat the | |||
request until the subsequent handshake negotiation is complete. | request until the subsequent handshake negotiation is complete. | |||
Structure of this message: | Structure of this message: | |||
struct { } HelloRequest; | struct { } HelloRequest; | |||
This message MUST NOT be included in the message hashes that are | This message MUST NOT be included in the message hashes that are | |||
maintained throughout the handshake and used in the finished messages | maintained throughout the handshake and used in the Finished messages | |||
and the certificate verify message. | and the certificate verify message. | |||
7.4.1.2. Client Hello | 7.4.1.2. Client Hello | |||
When this message will be sent: | When this message will be sent: | |||
When a client first connects to a server it is required to send | When a client first connects to a server, it is required to send | |||
the ClientHello as its first message. The client can also send a | the ClientHello as its first message. The client can also send a | |||
ClientHello in response to a HelloRequest or on its own initiative | ClientHello in response to a HelloRequest or on its own initiative | |||
in order to renegotiate the security parameters in an existing | in order to renegotiate the security parameters in an existing | |||
connection. | connection. | |||
Structure of this message: | Structure of this message: | |||
The ClientHello message includes a random structure, which is used | The ClientHello message includes a random structure, which is used | |||
later in the protocol. | later in the protocol. | |||
struct { | struct { | |||
uint32 gmt_unix_time; | uint32 gmt_unix_time; | |||
opaque random_bytes[28]; | opaque random_bytes[28]; | |||
} Random; | } Random; | |||
gmt_unix_time | gmt_unix_time | |||
The current time and date in standard UNIX 32-bit format | The current time and date in standard UNIX 32-bit format | |||
(seconds since the midnight starting Jan 1, 1970, UTC, ignoring | (seconds since the midnight starting Jan 1, 1970, UTC, ignoring | |||
leap seconds) according to the sender's internal clock. Clocks | leap seconds) according to the sender's internal clock. Clocks | |||
are not required to be set correctly by the basic TLS Protocol; | are not required to be set correctly by the basic TLS protocol; | |||
higher-level or application protocols may define additional | higher-level or application protocols may define additional | |||
requirements. Note that, for historical reasons, the data | requirements. Note that, for historical reasons, the data | |||
element is named using GMT, the predecessor of the current | element is named using GMT, the predecessor of the current | |||
worldwide time base, UTC. | worldwide time base, UTC. | |||
random_bytes | random_bytes | |||
28 bytes generated by a secure random number generator. | 28 bytes generated by a secure random number generator. | |||
The ClientHello message includes a variable-length session | The ClientHello message includes a variable-length session | |||
identifier. If not empty, the value identifies a session between the | identifier. If not empty, the value identifies a session between the | |||
same client and server whose security parameters the client wishes to | same client and server whose security parameters the client wishes to | |||
reuse. The session identifier MAY be from an earlier connection, this | reuse. The session identifier MAY be from an earlier connection, | |||
connection, or from another currently active connection. The second | this connection, or from another currently active connection. The | |||
option is useful if the client only wishes to update the random | second option is useful if the client only wishes to update the | |||
structures and derived values of a connection, and the third option | random structures and derived values of a connection, and the third | |||
makes it possible to establish several independent secure connections | option makes it possible to establish several independent secure | |||
without repeating the full handshake protocol. These independent | connections without repeating the full handshake protocol. These | |||
connections may occur sequentially or simultaneously; a SessionID | independent connections may occur sequentially or simultaneously; a | |||
becomes valid when the handshake negotiating it completes with the | SessionID becomes valid when the handshake negotiating it completes | |||
exchange of Finished messages and persists until it is removed due to | with the exchange of Finished messages and persists until it is | |||
aging or because a fatal error was encountered on a connection | removed due to aging or because a fatal error was encountered on a | |||
associated with the session. The actual contents of the SessionID are | connection associated with the session. The actual contents of the | |||
defined by the server. | SessionID are defined by the server. | |||
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 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 | |||
ClientHello message, contains the combinations of cryptographic | ClientHello message, contains the combinations of cryptographic | |||
algorithms supported by the client in order of the client's | algorithms supported by the client in order of the client's | |||
preference (favorite choice first). Each cipher suite defines a key | preference (favorite choice first). Each cipher suite defines a key | |||
exchange algorithm, a bulk encryption algorithm (including secret key | exchange algorithm, a bulk encryption algorithm (including secret key | |||
length), a MAC algorithm, and a PRF. The server will select a cipher | length), a MAC algorithm, and a PRF. The server will select a cipher | |||
suite or, if no acceptable choices are presented, return a handshake | suite or, if no acceptable choices are presented, return a handshake | |||
failure alert and close the connection. If the list contains cipher | failure alert and close the connection. If the list contains cipher | |||
suites the server does not recognize, support, or wish to use, the | suites the server does not recognize, support, or wish to use, the | |||
server MUST ignore those cipher suites, and process the remaining | server MUST ignore those cipher suites, and process the remaining | |||
ones as usual. | ones as usual. | |||
uint8 CipherSuite[2]; /* Cryptographic suite selector */ | uint8 CipherSuite[2]; /* Cryptographic suite selector */ | |||
skipping to change at page 41, line 12 ¶ | skipping to change at page 41, line 19 ¶ | |||
CompressionMethod compression_methods<1..2^8-1>; | CompressionMethod compression_methods<1..2^8-1>; | |||
select (extensions_present) { | select (extensions_present) { | |||
case false: | case false: | |||
struct {}; | struct {}; | |||
case true: | case true: | |||
Extension extensions<0..2^16-1>; | Extension extensions<0..2^16-1>; | |||
}; | }; | |||
} ClientHello; | } ClientHello; | |||
TLS allows extensions to follow the compression_methods field in an | TLS allows extensions to follow the compression_methods field in an | |||
extensions block. The presence of extensions can be detected by | extensions block. The presence of extensions can be detected by | |||
determining whether there are bytes following the compression_methods | determining whether there are bytes following the compression_methods | |||
at the end of the ClientHello. Note that this method of detecting | at the end of the ClientHello. Note that this method of detecting | |||
optional data differs from the normal TLS method of having a | optional data differs from the normal TLS method of having a | |||
variable-length field but is used for compatibility with TLS before | variable-length field, but it is used for compatibility with TLS | |||
extensions were defined. | before extensions were defined. | |||
client_version | client_version | |||
The version of the TLS protocol by which the client wishes to | The version of the TLS protocol by which the client wishes to | |||
communicate during this session. This SHOULD be the latest | communicate during this session. This SHOULD be the latest | |||
(highest valued) version supported by the client. For this version | (highest valued) version supported by the client. For this | |||
of the specification, the version will be 3.3 (See Appendix E for | version of the specification, the version will be 3.3 (see | |||
details about backward compatibility). | Appendix E for details about backward compatibility). | |||
random | random | |||
A client-generated random structure. | A client-generated random structure. | |||
session_id | session_id | |||
The ID of a session the client wishes to use for this connection. | The ID of a session the client wishes to use for this connection. | |||
This field is empty if no session_id is available, or if the | This field is empty if no session_id is available, or if the | |||
client wishes to generate new security parameters. | client wishes to generate new security parameters. | |||
cipher_suites | cipher_suites | |||
This is a list of the cryptographic options supported by the | This is a list of the cryptographic options supported by the | |||
client, with the client's first preference first. If the | client, with the client's first preference first. If the | |||
session_id field is not empty (implying a session resumption | session_id field is not empty (implying a session resumption | |||
request), this vector MUST include at least the cipher_suite from | request), this vector MUST include at least the cipher_suite from | |||
that session. Values are defined in Appendix A.5. | that session. Values are defined in Appendix A.5. | |||
compression_methods | compression_methods | |||
This is a list of the compression methods supported by the client, | This is a list of the compression methods supported by the client, | |||
sorted by client preference. If the session_id field is not empty | sorted by client preference. If the session_id field is not empty | |||
(implying a session resumption request), it MUST include the | (implying a session resumption request), it MUST include the | |||
compression_method from that session. This vector MUST contain, | compression_method from that session. This vector MUST contain, | |||
and all implementations MUST support, CompressionMethod.null. | and all implementations MUST support, CompressionMethod.null. | |||
Thus, a client and server will always be able to agree on a | Thus, a client and server will always be able to agree on a | |||
compression method. | compression method. | |||
extensions | extensions | |||
Clients MAY request extended functionality from servers by sending | Clients MAY request extended functionality from servers by sending | |||
data in the extensions field. The actual "Extension" format is | data in the extensions field. The actual "Extension" format is | |||
defined in Section 7.4.1.4. | defined in Section 7.4.1.4. | |||
In the event that a client requests additional functionality using | In the event that a client requests additional functionality using | |||
extensions, and this functionality is not supplied by the server, the | extensions, and this functionality is not supplied by the server, the | |||
client MAY abort the handshake. A server MUST accept client hello | client MAY abort the handshake. A server MUST accept ClientHello | |||
messages both with and without the extensions field, and (as for all | messages both with and without the extensions field, and (as for all | |||
other messages) MUST check that the amount of data in the message | other messages) it MUST check that the amount of data in the message | |||
precisely matches one of these formats; if not, then it MUST send a | precisely matches one of these formats; if not, then it MUST send a | |||
fatal "decode_error" alert. | fatal "decode_error" alert. | |||
After sending the client hello message, the client waits for a | After sending the ClientHello message, the client waits for a | |||
ServerHello message. Any other handshake message returned by the | ServerHello message. Any handshake message returned by the server, | |||
server except for a HelloRequest is treated as a fatal error. | except for a HelloRequest, is treated as a fatal error. | |||
7.4.1.3. Server Hello | 7.4.1.3. Server Hello | |||
When this message will be sent: | When this message will be sent: | |||
The server will send this message in response to a ClientHello | The server will send this message in response to a ClientHello | |||
message when it was able to find an acceptable set of algorithms. | message when it was able to find an acceptable set of algorithms. | |||
If it cannot find such a match, it will respond with a handshake | If it cannot find such a match, it will respond with a handshake | |||
failure alert. | failure alert. | |||
Structure of this message: | Structure of this message: | |||
skipping to change at page 42, line 50 ¶ | skipping to change at page 43, line 11 ¶ | |||
Extension extensions<0..2^16-1>; | Extension extensions<0..2^16-1>; | |||
}; | }; | |||
} ServerHello; | } ServerHello; | |||
The presence of extensions can be detected by determining whether | The presence of extensions can be detected by determining whether | |||
there are bytes following the compression_method field at the end of | there are bytes following the compression_method field at the end of | |||
the ServerHello. | the ServerHello. | |||
server_version | server_version | |||
This field will contain the lower of that suggested by the client | This field will contain the lower of that suggested by the client | |||
in the client hello and the highest supported by the server. For | in the client hello and the highest supported by the server. For | |||
this version of the specification, the version is 3.3. (See | this version of the specification, the version is 3.3. (See | |||
Appendix E for details about backward compatibility.) | Appendix E for details about backward compatibility.) | |||
random | random | |||
This structure is generated by the server and MUST be | This structure is generated by the server and MUST be | |||
independently generated from the ClientHello.random. | independently generated from the ClientHello.random. | |||
session_id | session_id | |||
This is the identity of the session corresponding to this | This is the identity of the session corresponding to this | |||
connection. If the ClientHello.session_id was non-empty, the | connection. If the ClientHello.session_id was non-empty, the | |||
server will look in its session cache for a match. If a match is | server will look in its session cache for a match. If a match is | |||
found and the server is willing to establish the new connection | found and the server is willing to establish the new connection | |||
using the specified session state, the server will respond with | using the specified session state, the server will respond with | |||
the same value as was supplied by the client. This indicates a | the same value as was supplied by the client. This indicates a | |||
resumed session and dictates that the parties must proceed | resumed session and dictates that the parties must proceed | |||
directly to the finished messages. Otherwise this field will | directly to the Finished messages. Otherwise, this field will | |||
contain a different value identifying the new session. The server | contain a different value identifying the new session. The server | |||
may return an empty session_id to indicate that the session will | may return an empty session_id to indicate that the session will | |||
not be cached and therefore cannot be resumed. If a session is | not be cached and therefore cannot be resumed. If a session is | |||
resumed, it must be resumed using the same cipher suite it was | resumed, it must be resumed using the same cipher suite it was | |||
originally negotiated with. Note that there is no requirement that | originally negotiated with. Note that there is no requirement | |||
the server resume any session even if it had formerly provided a | that the server resume any session even if it had formerly | |||
session_id. Clients MUST be prepared to do a full negotiation -- | provided a session_id. Clients MUST be prepared to do a full | |||
including negotiating new cipher suites -- during any handshake. | negotiation -- including negotiating new cipher suites -- during | |||
any handshake. | ||||
cipher_suite | cipher_suite | |||
The single cipher suite selected by the server from the list in | The single cipher suite selected by the server from the list in | |||
ClientHello.cipher_suites. For resumed sessions, this field is the | ClientHello.cipher_suites. For resumed sessions, this field is | |||
value from the state of the session being resumed. | the 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, | |||
field is the value from the resumed session state. | this field is the value from the resumed session state. | |||
extensions | 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>; | |||
} Extension; | } Extension; | |||
enum { | enum { | |||
signature_algorithms(TBD-BY-IANA), (65535) | signature_algorithms(13), (65535) | |||
} ExtensionType; | } ExtensionType; | |||
Here: | Here: | |||
- "extension_type" identifies the particular extension type. | - "extension_type" identifies the particular extension type. | |||
- "extension_data" contains information specific to the particular | - "extension_data" contains information specific to the particular | |||
extension type. | extension type. | |||
The initial set of extensions is defined in a companion document | The initial set of extensions is defined in a companion document | |||
[TLSEXT]. The list of extension types is maintained by IANA as | [TLSEXT]. The list of extension types is maintained by IANA as | |||
described in Section 12. | described in Section 12. | |||
An extension type MUST NOT appear in the ServerHello unless the same | ||||
extension type appeared in the corresponding ClientHello. If a | ||||
client receives an extension type in ServerHello that it did not | ||||
request in the associated ClientHello, it MUST abort the handshake | ||||
with an unsupported_extension fatal alert. | ||||
Nonetheless, "server-oriented" extensions may be provided in the | ||||
future within this framework. Such an extension (say, of type x) | ||||
would require the client to first send an extension of type x in a | ||||
ClientHello with empty extension_data to indicate that it supports | ||||
the extension type. In this case, the client is offering the | ||||
capability to understand the extension type, and the server is taking | ||||
the client up on its offer. | ||||
When multiple extensions of different types are present in the | ||||
ClientHello or ServerHello messages, the extensions MAY appear in any | ||||
order. There MUST NOT be more than one extension of the same type. | ||||
Finally, note that extensions can be sent both when starting a new | ||||
session and when requesting session resumption. Indeed, a client | ||||
that requests session resumption does not in general know whether the | ||||
server will accept this request, and therefore it SHOULD send the | ||||
same extensions as it would send if it were not attempting | ||||
resumption. | ||||
In general, the specification of each extension type needs to | ||||
describe the effect of the extension both during full handshake and | ||||
session resumption. Most current TLS extensions are relevant only | ||||
when a session is initiated: when an older session is resumed, the | ||||
server does not process these extensions in Client Hello, and does | ||||
not include them in Server Hello. However, some extensions may | ||||
specify different behavior during session resumption. | ||||
There are subtle (and not so subtle) interactions that may occur in | There are subtle (and not so subtle) interactions that may occur in | |||
this protocol between new features and existing features which may | this protocol between new features and existing features which may | |||
result in a significant reduction in overall security. The following | result in a significant reduction in overall security. The following | |||
considerations should be taken into account when designing new | considerations should be taken into account when designing new | |||
extensions: | extensions: | |||
- Some cases where a server does not agree to an extension are error | - Some cases where a server does not agree to an extension are error | |||
conditions, and some simply a refusal to support a particular | conditions, and some are simply refusals to support particular | |||
feature. In general error alerts should be used for the former, | features. In general, error alerts should be used for the former, | |||
and a field in the server extension response for the latter. | and a field in the server extension response for the latter. | |||
- Extensions should as far as possible be designed to prevent any | - Extensions should, as far as possible, be designed to prevent any | |||
attack that forces use (or non-use) of a particular feature by | attack that forces use (or non-use) of a particular feature by | |||
manipulation of handshake messages. This principle should be | manipulation of handshake messages. This principle should be | |||
followed regardless of whether the feature is believed to cause a | followed regardless of whether the feature is believed to cause a | |||
security problem. | security problem. | |||
Often the fact that the extension fields are included in the | Often the fact that the extension fields are included in the | |||
inputs to the Finished message hashes will be sufficient, but | inputs to the Finished message hashes will be sufficient, but | |||
extreme care is needed when the extension changes the meaning of | extreme care is needed when the extension changes the meaning of | |||
messages sent in the handshake phase. Designers and implementors | messages sent in the handshake phase. Designers and implementors | |||
should be aware of the fact that until the handshake has been | should be aware of the fact that until the handshake has been | |||
authenticated, active attackers can modify messages and insert, | authenticated, active attackers can modify messages and insert, | |||
remove, or replace extensions. | remove, or replace extensions. | |||
- It would be technically possible to use extensions to change major | - It would be technically possible to use extensions to change major | |||
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 uses the "signature_algorithms" extension to indicate to | The client uses the "signature_algorithms" extension to indicate to | |||
the server which signature/hash algorithm pairs may be used in | the server which signature/hash algorithm pairs may be used in | |||
digital signatures. The "extension_data" field of this extension | digital signatures. The "extension_data" field of this extension | |||
contains a "supported_signature_algorithms" value. | contains a "supported_signature_algorithms" value. | |||
enum { | enum { | |||
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), | none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), | |||
sha512(6), (255) | sha512(6), (255) | |||
} HashAlgorithm; | } HashAlgorithm; | |||
enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } | enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } | |||
SignatureAlgorithm; | SignatureAlgorithm; | |||
struct { | struct { | |||
HashAlgorithm hash; | HashAlgorithm hash; | |||
SignatureAlgorithm signature; | SignatureAlgorithm signature; | |||
} SignatureAndHashAlgorithm; | } SignatureAndHashAlgorithm; | |||
SignatureAndHashAlgorithm | SignatureAndHashAlgorithm | |||
supported_signature_algorithms<2..2^16-2>; | 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 that 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-224, SHA-256, SHA-384, and SHA-512 [SHS] respectively. The | SHA-224, SHA-256, SHA-384, and SHA-512 [SHS], respectively. The | |||
"none" value is provided for future extensibility, in case of a | "none" value is provided for future extensibility, in case of a | |||
signature algorithm which does not require hashing before signing. | signature algorithm which does not require hashing before signing. | |||
signature | signature | |||
This field indicates the signature algorithm which may be used. | This field indicates the signature algorithm that may be used. | |||
The values indicate anonymous signatures, RSASSA-PKCS1-v1_5 | The values indicate anonymous signatures, RSASSA-PKCS1-v1_5 | |||
[PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively. The | [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively. The | |||
"anonymous" value is meaningless in this context but used in | "anonymous" value is meaningless in this context but used in | |||
Section 7.4.3. It MUST NOT appear in this extension. | Section 7.4.3. It MUST NOT appear in this extension. | |||
The semantics of this extension are somewhat complicated because the | The semantics of this extension are somewhat complicated because the | |||
cipher suite indicates permissible signature algorithms but not hash | cipher suite indicates permissible signature algorithms but not hash | |||
algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules. | algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules. | |||
If the client supports only the default hash and signature algorithms | If the client supports only the default hash and signature algorithms | |||
(listed in this section), it MAY omit the signature_algorithms | (listed in this section), it MAY omit the signature_algorithms | |||
extension. If the client does not support the default algorithms, or | extension. If the client does not support the default algorithms, or | |||
supports other hash and signature algorithms (and it is willing to | supports other hash and signature algorithms (and it is willing to | |||
use them for verifying messages sent by the server, i.e., server | use them for verifying messages sent by the server, i.e., server | |||
certificates and server key exchange), it MUST send the | certificates and server key exchange), it MUST send the | |||
signature_algorithms extension, listing the algorithms it is willing | signature_algorithms extension, listing the algorithms it is willing | |||
to accept. | to accept. | |||
If the client does not send the signature_algorithms extension, the | If the client does not send the signature_algorithms extension, the | |||
server MUST assume the following: | server MUST do 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 | |||
the value {sha1,rsa}. | sent the value {sha1,rsa}. | |||
- If the negotiated key exchange algorithm is one of (DHE_DSS, | - If the negotiated key exchange algorithm is one of (DHE_DSS, | |||
DH_DSS), behave as if the client had sent the value {sha1,dsa}. | DH_DSS), behave as if the client had sent the value {sha1,dsa}. | |||
- If the negotiated key exchange algorithm is one of (ECDH_ECDSA, | - If the negotiated key exchange algorithm is one of (ECDH_ECDSA, | |||
ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}. | ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}. | |||
Note: this is a change from TLS 1.1 where there are no explicit rules | Note: this is a change from TLS 1.1 where there are no explicit | |||
but as a practical matter one can assume that the peer supports MD5 | rules, but as a practical matter one can assume that the peer | |||
and SHA-1. | supports MD5 and SHA-1. | |||
Note: this extension is not meaningful for TLS versions prior to 1.2. | Note: this extension is not meaningful for TLS versions prior to 1.2. | |||
Clients MUST NOT offer it if they are offering prior versions. | Clients MUST NOT offer it if they are offering prior versions. | |||
However, even if clients do offer it, the rules specified in [TLSEXT] | However, even if clients do offer it, the rules specified in [TLSEXT] | |||
require servers to ignore extensions they do not understand. | require servers to ignore extensions they do not understand. | |||
Servers MUST NOT send this extension. TLS servers MUST support | Servers MUST NOT send this extension. TLS servers MUST support | |||
receiving this extension. | receiving this extension. | |||
7.4.2. Server Certificate | When performing session resumption, this extension is not included in | |||
Server Hello, and the server ignores the extension in Client Hello | ||||
(if present). | ||||
7.4.2. Server Certificate | ||||
When this message will be sent: | When this message will be sent: | |||
The server MUST send a Certificate message whenever the agreed- | The server MUST send a Certificate message whenever the agreed- | |||
upon key exchange method uses certificates for authentication | upon key exchange method uses certificates for authentication | |||
(this includes all key exchange methods defined in this document | (this includes all key exchange methods defined in this document | |||
except DH_anon). This message will always immediately follow the | except DH_anon). This message will always immediately follow the | |||
server hello message. | ServerHello message. | |||
Meaning of this message: | Meaning of this message: | |||
This message conveys the server's certificate chain to the client. | This message conveys the server's certificate chain to the client. | |||
The certificate MUST be appropriate for the negotiated cipher | The certificate MUST be appropriate for the negotiated cipher | |||
suite's key exchange algorithm, and any negotiated extensions. | suite's key exchange algorithm and any negotiated extensions. | |||
Structure of this message: | Structure of this message: | |||
opaque ASN.1Cert<1..2^24-1>; | opaque ASN.1Cert<1..2^24-1>; | |||
struct { | struct { | |||
ASN.1Cert certificate_list<0..2^24-1>; | ASN.1Cert certificate_list<0..2^24-1>; | |||
} Certificate; | } Certificate; | |||
certificate_list | certificate_list | |||
This is a sequence (chain) of certificates. The sender's | This is a sequence (chain) of certificates. The sender's | |||
certificate MUST come first in the list. Each following | certificate MUST come first in the list. Each following | |||
certificate MUST directly certify the one preceding it. Because | certificate MUST directly certify the one preceding it. Because | |||
certificate validation requires that root keys be distributed | certificate validation requires that root keys be distributed | |||
independently, the self-signed certificate that specifies the root | independently, the self-signed certificate that specifies the root | |||
certificate authority MAY be omitted from the chain, under the | certificate authority MAY be omitted from the chain, under the | |||
assumption that the remote end must already possess it in order to | assumption that the remote end must already possess it in order to | |||
validate it in any case. | validate it in any case. | |||
The same message type and structure will be used for the client's | The same message type and structure will be used for the client's | |||
response to a certificate request message. Note that a client MAY | response to a certificate request message. Note that a client MAY | |||
send no certificates if it does not have an appropriate certificate | send no certificates if it does not have an appropriate certificate | |||
to send in response to the server's authentication request. | to send in response to the server's authentication request. | |||
Note: PKCS #7 [PKCS7] is not used as the format for the certificate | Note: PKCS #7 [PKCS7] is not used as the format for the certificate | |||
vector because PKCS #6 [PKCS6] extended certificates are not used. | vector because PKCS #6 [PKCS6] extended certificates are not used. | |||
Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task | Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task | |||
of parsing the list more difficult. | of parsing the list more difficult. | |||
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 end entity certificate's public key (and associated | - The end entity certificate's public key (and associated | |||
restrictions) MUST be compatible with the selected key exchange | restrictions) MUST be compatible with the selected key exchange | |||
algorithm. | 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 allow the | |||
RSA_PSK allow the key to be used for encryption | RSA_PSK key to be used for encryption (the | |||
(the keyEncipherment bit MUST be set | keyEncipherment bit MUST be set if the key | |||
if the key usage extension is present). | 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 allow the | |||
ECDHE_RSA allow the key to be used for signing | ECDHE_RSA key to be used for signing (the | |||
(the digitalSignature bit MUST be set | digitalSignature bit MUST be set if the key | |||
if the key usage extension is present) | usage extension is present) with the signature | |||
with the signature scheme and hash | scheme and hash algorithm that will be employed | |||
algorithm that will be employed in the | ||||
server key exchange message. | ||||
Note: ECDHE_RSA is defined in [TLSECC]. | ||||
DHE_DSS DSA public key; the certificate MUST | ||||
allow the key to be used for signing with | ||||
the hash algorithm that will be employed | ||||
in the server key exchange message. | in the server key exchange message. | |||
Note: ECDHE_RSA is defined in [TLSECC]. | ||||
DH_DSS Diffie-Hellman public key; the | DHE_DSS DSA public key; the certificate MUST allow the | |||
DH_RSA keyAgreement bit MUST be set if the | key to be used for signing with the hash | |||
key usage extension is present. | algorithm that will be employed in the server | |||
key exchange message. | ||||
ECDH_ECDSA ECDH-capable public key; the public key | DH_DSS Diffie-Hellman public key; the keyAgreement bit | |||
ECDH_RSA MUST use a curve and point format supported | DH_RSA MUST be set if the key usage extension is | |||
by the client, as described in [TLSECC]. | present. | |||
ECDHE_ECDSA ECDSA-capable public key; the certificate | ECDH_ECDSA ECDH-capable public key; the public key MUST | |||
MUST allow the key to be used for signing | ECDH_RSA use a curve and point format supported by the | |||
with the hash algorithm that will be | client, as described in [TLSECC]. | |||
employed in the server key exchange | ||||
message. The public key MUST use a curve | ECDHE_ECDSA ECDSA-capable public key; the certificate MUST | |||
and point format supported by the client, | allow the key to be used for signing with the | |||
as described in [TLSECC]. | hash algorithm that will be employed in the | |||
server key exchange message. The public key | ||||
MUST use a curve and point format supported by | ||||
the client, as described in [TLSECC]. | ||||
- The "server_name" and "trusted_ca_keys" extensions [TLSEXT] 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 | |||
departure from TLS 1.1, which required that the algorithms be the | a 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 names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are | extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are | |||
historical. | historical. | |||
If the server has multiple certificates, it chooses one of them based | If the server has multiple certificates, it chooses one of them based | |||
on the above-mentioned criteria (in addition to other criteria, such | on the above-mentioned criteria (in addition to other criteria, such | |||
as transport layer endpoint, local configuration and preferences, | as transport layer endpoint, local configuration and preferences, | |||
etc.). If the server has a single certificate it SHOULD attempt to | etc.). If the server has a single certificate, it SHOULD attempt to | |||
validate that it meets these criteria. | validate that it meets these criteria. | |||
Note that there are certificates that use algorithms and/or algorithm | Note that there are certificates that use algorithms and/or algorithm | |||
combinations that cannot be currently used with TLS. For example, a | combinations that cannot be currently used with TLS. For example, a | |||
certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in | certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in | |||
SubjectPublicKeyInfo) cannot be used because TLS defines no | SubjectPublicKeyInfo) cannot be used because TLS defines no | |||
corresponding signature algorithm. | corresponding signature algorithm. | |||
As cipher suites that specify new key exchange methods are specified | As cipher suites that specify new key exchange methods are specified | |||
for the TLS Protocol, they will the imply certificate format and the | for the TLS protocol, they will imply the 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 ServerHello message, if this is an anonymous | message (or the ServerHello message, if this is an anonymous | |||
negotiation). | negotiation). | |||
The ServerKeyExchange message is sent by the server only when the | The ServerKeyExchange message is sent by the server only when the | |||
server Certificate message (if sent) does not contain enough data | server Certificate message (if sent) does not contain enough data | |||
to allow the client to exchange a premaster secret. This is true | to allow the client to exchange a premaster secret. This is true | |||
for the following key exchange methods: | for the following key exchange methods: | |||
DHE_DSS | DHE_DSS | |||
DHE_RSA | DHE_RSA | |||
DH_anon | DH_anon | |||
It is not legal to send the ServerKeyExchange message for the | It is not legal to send the ServerKeyExchange message for the | |||
following key exchange methods: | following key exchange methods: | |||
RSA | RSA | |||
DH_DSS | DH_DSS | |||
DH_RSA | DH_RSA | |||
Other key exchange algorithms, such as those defined in | Other key exchange algorithms, such as those defined in [TLSECC], | |||
[TLSECC], MUST specify whether the ServerKeyExchange message is | MUST specify whether the ServerKeyExchange message is sent or not; | |||
sent or not; and if the message is sent, its contents. | and if the message is sent, its contents. | |||
Meaning of this message: | Meaning of this message: | |||
This message conveys cryptographic information to allow the client | This message conveys cryptographic information to allow the client | |||
to communicate the premaster secret: a Diffie-Hellman public key | to communicate the premaster secret: a Diffie-Hellman public key | |||
with which the client can complete a key exchange (with the result | with which the client can complete a key exchange (with the result | |||
being the premaster secret) or a public key for some other | being the premaster secret) or a public key for some other | |||
algorithm. | algorithm. | |||
Structure of this message: | Structure of this message: | |||
enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa | enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa | |||
/* may be extended, e.g. for ECDH -- see [TLSECC] */ | /* may be extended, e.g., for ECDH -- see [TLSECC] */ | |||
} KeyExchangeAlgorithm; | } KeyExchangeAlgorithm; | |||
struct { | struct { | |||
opaque dh_p<1..2^16-1>; | opaque dh_p<1..2^16-1>; | |||
opaque dh_g<1..2^16-1>; | opaque dh_g<1..2^16-1>; | |||
opaque dh_Ys<1..2^16-1>; | opaque dh_Ys<1..2^16-1>; | |||
} ServerDHParams; /* Ephemeral DH parameters */ | } ServerDHParams; /* Ephemeral DH parameters */ | |||
dh_p | dh_p | |||
The prime modulus used for the Diffie-Hellman operation. | The prime modulus used for the Diffie-Hellman operation. | |||
skipping to change at page 50, line 45 ¶ | skipping to change at page 52, line 22 ¶ | |||
digitally-signed struct { | digitally-signed struct { | |||
opaque client_random[32]; | opaque client_random[32]; | |||
opaque server_random[32]; | opaque server_random[32]; | |||
ServerDHParams params; | ServerDHParams params; | |||
} signed_params; | } signed_params; | |||
case rsa: | case rsa: | |||
case dh_dss: | case dh_dss: | |||
case dh_rsa: | case dh_rsa: | |||
struct {} ; | struct {} ; | |||
/* message is omitted for rsa, dh_dss, and dh_rsa */ | /* message is omitted for rsa, dh_dss, and dh_rsa */ | |||
/* may be extended, e.g. for ECDH -- see [TLSECC] */ | /* may be extended, e.g., for ECDH -- see [TLSECC] */ | |||
}; | }; | |||
} ServerKeyExchange; | } ServerKeyExchange; | |||
params | params | |||
The server's key exchange parameters. | The server's key exchange parameters. | |||
signed_params | signed_params | |||
For non-anonymous key exchanges, a signature over the | For non-anonymous key exchanges, a signature over the server's | |||
server's key exchange parameters. | key exchange parameters. | |||
If the client has offered the "signature_algorithms" extension, the | If the client has offered the "signature_algorithms" extension, the | |||
signature algorithm and hash algorithm MUST be a pair listed in that | signature algorithm and hash algorithm MUST be a pair listed in that | |||
extension. Note that there is a possibility for inconsistencies here. | extension. Note that there is a possibility for inconsistencies | |||
For instance, the client might offer DHE_DSS key exchange but omit | here. For instance, the client might offer DHE_DSS key exchange but | |||
any DSA pairs from its "signature_algorithms" extension. In order to | omit any DSA pairs from its "signature_algorithms" extension. In | |||
negotiate correctly, the server MUST check any candidate cipher | order to negotiate correctly, the server MUST check any candidate | |||
suites against the "signature_algorithms" extension before selecting | cipher suites against the "signature_algorithms" extension before | |||
them. This is somewhat inelegant but is a compromise designed to | selecting them. This is somewhat inelegant but is a compromise | |||
minimize changes to the original cipher suite design. | designed to minimize changes to the original cipher suite design. | |||
In addition, the hash and signature algorithms MUST be compatible | In addition, the hash and signature algorithms MUST be compatible | |||
with the key in the server's end-entity certificate. RSA keys MAY be | with the key in the server's end-entity certificate. RSA keys MAY be | |||
used with any permitted hash algorithm, subject to restrictions in | used with any permitted hash algorithm, subject to restrictions in | |||
the certificate, if any. | the certificate, if any. | |||
Because DSA signatures do not contain any secure indication of hash | Because DSA signatures do not contain any secure indication of hash | |||
algorithm, there is a risk of hash substitution if multiple hashes | algorithm, there is a risk of hash substitution if multiple hashes | |||
may be used with any key. Currently, DSA [DSS] may only be used with | may be used with any key. Currently, DSA [DSS] may only be used with | |||
SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use | SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use | |||
of other digest algorithms with DSA, as well as guidance as to which | of other digest algorithms with DSA, as well as guidance as to which | |||
digest algorithms should be used with each key size. In addition, | digest algorithms should be used with each key size. In addition, | |||
future revisions of [PKIX] may specify mechanisms for certificates to | future revisions of [PKIX] may specify mechanisms for certificates to | |||
indicate which digest algorithms are to be used with DSA. | indicate which digest algorithms are to be used with DSA. | |||
As additional cipher suites are defined for TLS that include new key | As additional cipher suites are defined for TLS that include new key | |||
exchange algorithms, the server key exchange message will be sent if | exchange algorithms, the server key exchange message will be sent if | |||
and only if the certificate type associated with the key exchange | and only if the certificate type associated with the key exchange | |||
algorithm does not provide enough information for the client to | algorithm does not provide enough information for the client to | |||
exchange a premaster secret. | exchange a premaster secret. | |||
7.4.4. Certificate Request | 7.4.4. Certificate Request | |||
When this message will be sent: | When this message will be sent: | |||
A non-anonymous server can optionally request a certificate from | A non-anonymous server can optionally request a certificate from | |||
the client, if appropriate for the selected cipher suite. This | the client, if appropriate for the selected cipher suite. This | |||
message, if sent, will immediately follow the ServerKeyExchange | message, if sent, will immediately follow the ServerKeyExchange | |||
message (if it is sent; otherwise, the server's Certificate | message (if it is sent; otherwise, this message follows the | |||
message). | server's Certificate message). | |||
Structure of this message: | Structure of this message: | |||
enum { | enum { | |||
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | |||
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), | rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), | |||
fortezza_dms_RESERVED(20), (255) | fortezza_dms_RESERVED(20), (255) | |||
} ClientCertificateType; | } ClientCertificateType; | |||
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>; | |||
SignatureAndHashAlgorithm | SignatureAndHashAlgorithm | |||
supported_signature_algorithms<2^16-1>; | supported_signature_algorithms<2^16-1>; | |||
DistinguishedName certificate_authorities<0..2^16-1>; | DistinguishedName certificate_authorities<0..2^16-1>; | |||
} CertificateRequest; | } CertificateRequest; | |||
certificate_types | certificate_types | |||
A list of the types of certificate types which the client may | A list of the types of certificate types that the client may | |||
offer. | offer. | |||
rsa_sign a certificate containing an RSA key | rsa_sign a certificate containing an RSA key | |||
dss_sign a certificate containing a DSA key | dss_sign a certificate containing a DSA key | |||
rsa_fixed_dh a certificate containing a static DH key. | rsa_fixed_dh a certificate containing a static DH key. | |||
dss_fixed_dh a certificate containing a static DH key | dss_fixed_dh a certificate containing a static DH key | |||
supported_signature_algorithms | supported_signature_algorithms | |||
A list of the hash/signature algorithm pairs that the server is | A list of the hash/signature algorithm pairs that the server is | |||
able to verify, listed in descending order of preference. | able to verify, listed in descending order of preference. | |||
certificate_authorities | certificate_authorities | |||
A list of the distinguished names [X501] of acceptable | A list of the distinguished names [X501] of acceptable | |||
certificate_authorities, represented in DER-encoded format. These | certificate_authorities, represented in DER-encoded format. These | |||
distinguished names may specify a desired distinguished name for a | distinguished names may specify a desired distinguished name for a | |||
root CA or for a subordinate CA; thus, this message can be used | root CA or for a subordinate CA; thus, this message can be used to | |||
both to describe known roots and a desired authorization space. If | describe known roots as well as a desired authorization space. If | |||
the certificate_authorities list is empty then the client MAY send | the certificate_authorities list is empty, then the client MAY | |||
any certificate of the appropriate ClientCertificateType, unless | send any certificate of the appropriate ClientCertificateType, | |||
there is some external arrangement to the contrary. | unless 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 | hash/signature algorithm pair found in | |||
supported_signature_algorithms. | 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 that 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_algorithms. | 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 | functionality has been obsoleted by the | |||
supported_signature_algorithms, and the certificate type no longer | supported_signature_algorithms, and the certificate type no longer | |||
restricts the algorithm used to sign the certificate. For | restricts the algorithm used to sign the certificate. For | |||
example, if the server sends dss_fixed_dh certificate type and | example, if the server sends dss_fixed_dh certificate type and | |||
{{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply | {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply | |||
with a certificate containing a static DH key, signed with RSA- | with a certificate containing a static DH key, signed with RSA- | |||
SHA1. | 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. | |||
7.4.5 Server Hello Done | 7.4.5. Server Hello Done | |||
When this message will be sent: | When this message will be sent: | |||
The ServerHelloDone message is sent by the server to indicate the | The ServerHelloDone message is sent by the server to indicate the | |||
end of the ServerHello and associated messages. After sending this | end of the ServerHello and associated messages. After sending | |||
message, the server will wait for a client response. | this message, the server will wait for a client response. | |||
Meaning of this message: | Meaning of this message: | |||
This message means that the server is done sending messages to | This message means that the server is done sending messages to | |||
support the key exchange, and the client can proceed with its | support the key exchange, and the client can proceed with its | |||
phase of the key exchange. | phase of the key exchange. | |||
Upon receipt of the ServerHelloDone message, the client SHOULD | Upon receipt of the ServerHelloDone message, the client SHOULD | |||
verify that the server provided a valid certificate, if required, | verify that the server provided a valid certificate, if required, | |||
and check that the server hello parameters are acceptable. | and check that the server hello parameters are acceptable. | |||
Structure of this message: | Structure of this message: | |||
struct { } ServerHelloDone; | struct { } ServerHelloDone; | |||
7.4.6. Client Certificate | 7.4.6. Client Certificate | |||
When this message will be sent: | When this message will be sent: | |||
This is the first message the client can send after receiving a | This is the first message the client can send after receiving a | |||
server hello done message. This message is only sent if the server | ServerHelloDone 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 | |||
of zero. If the client does not send any certificates, the server | length of zero. If the client does not send any certificates, the | |||
MAY at its discretion either continue the handshake without client | server MAY at its discretion either continue the handshake without | |||
authentication, or respond with a fatal handshake_failure alert. | client authentication, or respond with a fatal handshake_failure | |||
Also, if some aspect of the certificate chain was unacceptable | alert. Also, if some aspect of the certificate chain was | |||
(e.g., it was not signed by a known, trusted CA), the server MAY | unacceptable (e.g., it was not signed by a known, trusted CA), the | |||
at its discretion either continue the handshake (considering the | server MAY at its discretion either continue the handshake | |||
client unauthenticated) or send a fatal alert. | (considering the client unauthenticated) or send a fatal alert. | |||
Client certificates are sent using the Certificate structure | Client certificates are sent using the Certificate structure | |||
defined in Section 7.4.2. | defined in Section 7.4.2. | |||
Meaning of this message: | Meaning of this message: | |||
This message conveys the client's certificate chain to the server; | This message conveys the client's certificate chain to the server; | |||
the server will use it when verifying the CertificateVerify | the server will use it when verifying the CertificateVerify | |||
message (when the client authentication is based on signing) or | message (when the client authentication is based on signing) or | |||
calculating the premaster secret (for non-ephemeral Diffie- | calculating the premaster secret (for non-ephemeral Diffie- | |||
Hellman). The certificate MUST be appropriate for the negotiated | Hellman). The certificate MUST be appropriate for the negotiated | |||
cipher suite's key exchange algorithm, and any negotiated | cipher suite's key exchange algorithm, and any negotiated | |||
extensions. | extensions. | |||
In particular: | In particular: | |||
- The certificate type MUST be X.509v3, unless explicitly negotiated | - The certificate type MUST be X.509v3, unless explicitly negotiated | |||
otherwise (e.g. [TLSPGP]). | otherwise (e.g., [TLSPGP]). | |||
- The end-entity certificate's public key (and associated | - The end-entity certificate's public key (and associated | |||
restrictions) has to be compatible with the certificate types | restrictions) has to be compatible with the certificate types | |||
listed in CertificateRequest: | listed in CertificateRequest: | |||
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 | |||
the key to be used for signing with the | key to be used for signing with the signature | |||
signature scheme and hash algorithm that | scheme and hash algorithm that will be | |||
will be employed in the certificate verify | 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 the | |||
the key to be used for signing with the | key to be used for signing with the hash | |||
hash algorithm that will be employed in | algorithm that will be employed in the | |||
the certificate verify message. | certificate verify message. | |||
ecdsa_sign ECDSA-capable public key; the certificate | ecdsa_sign ECDSA-capable public key; the certificate MUST | |||
MUST allow the key to be used for signing | allow the key to be used for signing with the | |||
with the hash algorithm that will be | hash algorithm that will be employed in the | |||
employed in the certificate verify | certificate verify message; the public key | |||
message; the public key MUST use a | MUST use a curve and point format supported by | |||
curve and point format supported by the | the server. | |||
server. | ||||
rsa_fixed_dh Diffie-Hellman public key; MUST use | rsa_fixed_dh Diffie-Hellman public key; MUST use the same | |||
dss_fixed_dh the same parameters as server's key. | dss_fixed_dh parameters as server's key. | |||
rsa_fixed_ecdh ECDH-capable public key; MUST use the | rsa_fixed_ecdh ECDH-capable public key; MUST use the | |||
ecdsa_fixed_ecdh same curve as the server's key, and | ecdsa_fixed_ecdh same curve as the server's key, and MUST use a | |||
MUST use a point format supported by | 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 | |||
this relaxes the constraints on certificate signing algorithms | that this relaxes the constraints on certificate-signing | |||
found in prior versions of TLS. | algorithms 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 | |||
use algorithms/algorithm combinations that cannot be currently used | that use algorithms/algorithm combinations that cannot be currently | |||
with TLS. | used with TLS. | |||
7.4.7. Client Key Exchange Message | 7.4.7. Client Key Exchange Message | |||
When this message will be sent: | When this message will be sent: | |||
This message is always sent by the client. It MUST immediately | This message is always sent by the client. It MUST immediately | |||
follow the client certificate message, if it is sent. Otherwise it | follow the client certificate message, if it is sent. Otherwise, | |||
MUST be the first message sent by the client after it receives the | it MUST be the first message sent by the client after it receives | |||
server hello done message. | the ServerHelloDone message. | |||
Meaning of this message: | Meaning of this message: | |||
With this message, the premaster secret is set, either through | With this message, the premaster secret is set, either by direct | |||
direct transmission of the RSA-encrypted secret, or by the | transmission of the RSA-encrypted secret or by the transmission of | |||
transmission of Diffie-Hellman parameters that will allow each | Diffie-Hellman parameters that will allow each side to agree upon | |||
side to agree upon the same premaster secret. | the same premaster secret. | |||
When the client is using an ephemeral Diffie-Hellman exponent, | When the client is using an ephemeral Diffie-Hellman exponent, | |||
then this message contains the client's Diffie-Hellman public | then this message contains the client's Diffie-Hellman public | |||
value. If the client is sending a certificate containing a static | value. If the client is sending a certificate containing a static | |||
DH exponent (i.e., it is doing fixed_dh client authentication) | DH exponent (i.e., it is doing fixed_dh client authentication), | |||
then this message MUST be sent but MUST be empty. | then this message MUST be sent but MUST be empty. | |||
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: | case rsa: | |||
EncryptedPreMasterSecret; | EncryptedPreMasterSecret; | |||
case dhe_dss: | case dhe_dss: | |||
case dhe_rsa: | case dhe_rsa: | |||
case dh_dss: | case dh_dss: | |||
case dh_rsa: | case dh_rsa: | |||
case dh_anon: | case dh_anon: | |||
ClientDiffieHellmanPublic; | 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 | |||
an encrypted premaster secret message. This structure is a variant | an encrypted premaster secret message. This structure is a | |||
of the ClientKeyExchange message and is not a message in itself. | variant of the ClientKeyExchange message and is not a message in | |||
itself. | ||||
Structure of this message: | Structure of this message: | |||
struct { | struct { | |||
ProtocolVersion client_version; | ProtocolVersion client_version; | |||
opaque random[46]; | opaque random[46]; | |||
} PreMasterSecret; | } PreMasterSecret; | |||
client_version | client_version | |||
The latest (newest) version supported by the client. This is | The latest (newest) version supported by the client. This is | |||
used to detect version roll-back attacks. | used to detect version rollback attacks. | |||
random | random | |||
46 securely-generated random bytes. | 46 securely-generated random bytes. | |||
struct { | struct { | |||
public-key-encrypted PreMasterSecret pre_master_secret; | public-key-encrypted PreMasterSecret pre_master_secret; | |||
} EncryptedPreMasterSecret; | } EncryptedPreMasterSecret; | |||
pre_master_secret | pre_master_secret | |||
This random value is generated by the client and is used to | This random value is generated by the client and is used to | |||
generate the master secret, as specified in Section 8.1. | generate the master secret, as specified in Section 8.1. | |||
Note: The version number in the PreMasterSecret is the version | Note: The version number in the PreMasterSecret is the version | |||
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 | |||
number may lead to failure to interoperate with such incorrect client | version number may lead to failure to interoperate with such | |||
implementations. | incorrect client 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 TLS 1.0 or earlier, server | the note below. If the version number is TLS 1.0 or earlier, server | |||
implementations SHOULD check the version number, but MAY have a | implementations SHOULD check the version number, but MAY have a | |||
configuration option to disable the check. Note that if the check | configuration option to disable the check. Note that if the check | |||
fails, the PreMasterSecret SHOULD be randomized as described below. | fails, the PreMasterSecret SHOULD be randomized as described below. | |||
Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. | Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. | |||
[KPR03] can be used to attack a TLS server that reveals whether a | [KPR03] can be used to attack a TLS server that reveals whether a | |||
particular message, when decrypted, is properly PKCS#1 formatted, | particular message, when decrypted, is properly PKCS#1 formatted, | |||
contains a valid PreMasterSecret structure, or has the correct | contains a valid PreMasterSecret structure, or has the correct | |||
version number. | version number. | |||
The best way to avoid these vulnerabilities is to treat incorrectly | As described by Klima [KPR03], these vulnerabilities can be avoided | |||
formatted messages in a manner indistinguishable from correctly | by treating incorrectly formatted message blocks and/or mismatched | |||
formatted RSA blocks. In other words: | version numbers in a manner indistinguishable from correctly | |||
formatted RSA blocks. In other words: | ||||
1. Generate a string R of 46 random bytes | 1. Generate a string R of 46 random bytes | |||
2. Decrypt the message to recover the plaintext M | 2. Decrypt the message to recover the plaintext M | |||
3. If the PKCS#1 padding is not correct, or the length of | 3. If the PKCS#1 padding is not correct, or the length of message | |||
message M is not exactly 48 bytes: | M is not exactly 48 bytes: | |||
premaster secret = ClientHello.client_version || R | pre_master_secret = ClientHello.client_version || R | |||
else If ClientHello.client_version <= TLS 1.0, and | else If ClientHello.client_version <= TLS 1.0, and version | |||
version number check is explicitly disabled: | number check is explicitly disabled: | |||
premaster secret = M | pre_master_secret = M | |||
else: | else: | |||
premaster secret = ClientHello.client_version || M[2..47] | pre_master_secret = ClientHello.client_version || M[2..47] | |||
Note that explicitly constructing the premaster_secret with the | Note that explicitly constructing the pre_master_secret with the | |||
ClientHello.client_version produces an invalid master_secret if the | ClientHello.client_version produces an invalid master_secret if the | |||
client has sent the wrong version in the original premaster_secret. | client has sent the wrong version in the original pre_master_secret. | |||
An alternative approach is to treat a version number mismatch as a | ||||
PKCS-1 formatting error and randomize the premaster secret | ||||
completely: | ||||
1. Generate a string R of 48 random bytes | ||||
2. Decrypt the message to recover the plaintext M | ||||
3. If the PKCS#1 padding is not correct, or the length of message | ||||
M is not exactly 48 bytes: | ||||
pre_master_secret = R | ||||
else If ClientHello.client_version <= TLS 1.0, and version | ||||
number check is explicitly disabled: | ||||
premaster secret = M | ||||
else If M[0..1] != ClientHello.client_version: | ||||
premaster secret = R | ||||
else: | ||||
premaster secret = M | ||||
Although no practical attacks against this construction are known, | ||||
Klima et al. [KPR03] describe some theoretical attacks, and therefore | ||||
the first construction described is RECOMMENDED. | ||||
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 | |||
with earlier versions of TLS, this specification uses the RSAES- | compatibility with earlier versions of TLS, this specification uses | |||
PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known | the RSAES-PKCS1-v1_5 scheme. No variants of the Bleichenbacher | |||
to exist provided that the above recommendations are followed. | attack are known to exist provided that the above recommendations are | |||
followed. | ||||
Implementation Note: Public-key-encrypted data is represented as an | Implementation note: Public-key-encrypted data is represented as an | |||
opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted | opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted | |||
PreMasterSecret in a ClientKeyExchange is preceded by two length | PreMasterSecret in a ClientKeyExchange is preceded by two length | |||
bytes. These bytes are redundant in the case of RSA because the | bytes. These bytes are redundant in the case of RSA because the | |||
EncryptedPreMasterSecret is the only data in the ClientKeyExchange | EncryptedPreMasterSecret is the only data in the ClientKeyExchange | |||
and its length can therefore be unambiguously determined. The SSLv3 | and its length can therefore be unambiguously determined. The SSLv3 | |||
specification was not clear about the encoding of public-key- | specification was not clear about the encoding of public-key- | |||
encrypted data, and therefore many SSLv3 implementations do not | encrypted data, and therefore many SSLv3 implementations do not | |||
include the length bytes, encoding the RSA encrypted data directly in | include the length bytes -- they encode the RSA-encrypted data | |||
the ClientKeyExchange message. | directly in the ClientKeyExchange message. | |||
This specification requires correct encoding of the | This specification requires correct encoding of the | |||
EncryptedPreMasterSecret complete with length bytes. The resulting | EncryptedPreMasterSecret complete with length bytes. The resulting | |||
PDU is incompatible with many SSLv3 implementations. Implementors | PDU is incompatible with many SSLv3 implementations. Implementors | |||
upgrading from SSLv3 MUST modify their implementations to generate | upgrading from SSLv3 MUST modify their implementations to generate | |||
and accept the correct encoding. Implementors who wish to be | and accept the correct encoding. Implementors who wish to be | |||
compatible with both SSLv3 and TLS should make their implementation's | compatible with both SSLv3 and TLS should make their implementation's | |||
behavior dependent on the protocol version. | behavior dependent on the protocol version. | |||
Implementation Note: It is now known that remote timing-based attacks | Implementation note: It is now known that remote timing-based attacks | |||
on TLS are possible, at least when the client and server are on the | on TLS are possible, at least when the client and server are on the | |||
same LAN. Accordingly, implementations that use static RSA keys MUST | same LAN. Accordingly, implementations that use static RSA keys MUST | |||
use RSA blinding or some other anti-timing technique, as described in | use RSA blinding or some other anti-timing technique, as described in | |||
[TIMING]. | [TIMING]. | |||
7.4.7.2. Client Diffie-Hellman Public Value | 7.4.7.2. Client Diffie-Hellman Public Value | |||
Meaning of this message: | Meaning of this message: | |||
This structure conveys the client's Diffie-Hellman public value | This structure conveys the client's Diffie-Hellman public value | |||
(Yc) if it was not already included in the client's certificate. | (Yc) if it was not already included in the client's certificate. | |||
The encoding used for Yc is determined by the enumerated | The encoding used for Yc is determined by the enumerated | |||
PublicValueEncoding. This structure is a variant of the client key | PublicValueEncoding. This structure is a variant of the client | |||
exchange message, and not a message in itself. | key exchange message, and not a message in itself. | |||
Structure of this message: | Structure of this message: | |||
enum { implicit, explicit } PublicValueEncoding; | enum { implicit, explicit } PublicValueEncoding; | |||
implicit | implicit | |||
If the client has sent a certificate which contains a suitable | If the client has sent a certificate which contains a suitable | |||
Diffie-Hellman key (for fixed_dh client authentication) then Yc | Diffie-Hellman key (for fixed_dh client authentication), then | |||
is implicit and does not need to be sent again. In this case, | Yc is implicit and does not need to be sent again. In this | |||
the client key exchange message will be sent, but it MUST be | case, the client key exchange message will be sent, but it MUST | |||
empty. | be empty. | |||
explicit | explicit | |||
Yc needs to be sent. | Yc needs to be sent. | |||
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; | |||
dh_Yc | dh_Yc | |||
The client's Diffie-Hellman public value (Yc). | The client's Diffie-Hellman public value (Yc). | |||
7.4.8. Certificate verify | 7.4.8. Certificate Verify | |||
When this message will be sent: | When this message will be sent: | |||
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 { | |||
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 and up to, but not including, | |||
message, including the type and length fields of the handshake | this message, including the type and length fields of the | |||
messages. This is the concatenation of all the Handshake | handshake messages. This is the concatenation of all the | |||
structures as defined in 7.4 exchanged thus far. Note that this | Handshake structures (as defined in Section 7.4) exchanged thus | |||
requires both sides to either buffer the messages or compute | far. Note that this requires both sides to either buffer the | |||
running hashes for all potential hash algorithms up to the time of | messages or compute running hashes for all potential hash | |||
the CertificateVerify computation. Servers can minimize this | algorithms up to the time of the CertificateVerify computation. | |||
computation cost by offering a restricted set of digest algorithms | Servers can minimize this computation cost by offering a | |||
in the CertificateRequest message. | restricted set of digest algorithms in the CertificateRequest | |||
message. | ||||
The hash and signature algorithms used in the signature MUST be | The hash and signature algorithms used in the signature MUST be | |||
one of those present in the supported_signature_algorithms field | one of those present in the supported_signature_algorithms field | |||
of the CertificateRequest message. In addition, the hash and | of the CertificateRequest message. In addition, the hash and | |||
signature algorithms MUST be compatible with the key in the | signature algorithms MUST be compatible with the key in the | |||
client's end-entity certificate. RSA keys MAY be used with any | client's end-entity certificate. RSA keys MAY be used with any | |||
permitted hash algorithm, subject to restrictions in the | permitted hash algorithm, subject to restrictions in the | |||
certificate, if any. | certificate, if any. | |||
Because DSA signatures do not contain any secure indication of | Because DSA signatures do not contain any secure indication of | |||
hash algorithm, there is a risk of hash substitution if multiple | hash algorithm, there is a risk of hash substitution if multiple | |||
hashes may be used with any key. Currently, DSA [DSS] may only be | hashes may be used with any key. Currently, DSA [DSS] may only be | |||
used with SHA-1. Future revisions of DSS [DSS-3] are expected to | used with SHA-1. Future revisions of DSS [DSS-3] are expected to | |||
allow the use of other digest algorithms with DSA, as well as | allow the use of other digest algorithms with DSA, as well as | |||
guidance as to which digest algorithms should be used with each | guidance as to which digest algorithms should be used with each | |||
key size. In addition, future revisions of [PKIX] may specify | key size. In addition, future revisions of [PKIX] may specify | |||
mechanisms for certificates to indicate which digest algorithms | mechanisms for certificates to indicate which digest algorithms | |||
are to be used with DSA. | are to be used with DSA. | |||
7.4.9. Finished | 7.4.9. Finished | |||
When this message will be sent: | When this message will be sent: | |||
A Finished message is always sent immediately after a change | A Finished message is always sent immediately after a change | |||
cipher spec message to verify that the key exchange and | cipher spec message to verify that the key exchange and | |||
authentication processes were successful. It is essential that a | authentication processes were successful. It is essential that a | |||
change cipher spec message be received between the other handshake | change cipher spec message be received between the other handshake | |||
messages and the Finished message. | messages and the Finished message. | |||
Meaning of this message: | Meaning of this message: | |||
The finished message is the first one protected with the just | The Finished message is the first one protected with the just | |||
negotiated algorithms, keys, and secrets. Recipients of finished | negotiated algorithms, keys, and secrets. Recipients of Finished | |||
messages MUST verify that the contents are correct. Once a side | messages MUST verify that the contents are correct. Once a side | |||
has sent its Finished message and received and validated the | has sent its Finished message and received and validated the | |||
Finished message from its peer, it may begin to send and receive | Finished message from its peer, it may begin to send and receive | |||
application data over the connection. | application data over the connection. | |||
Structure of this message: | Structure of this message: | |||
struct { | struct { | |||
opaque verify_data[verify_data_length]; | opaque verify_data[verify_data_length]; | |||
} Finished; | } Finished; | |||
verify_data | verify_data | |||
PRF(master_secret, finished_label, Hash(handshake_messages)) | PRF(master_secret, finished_label, Hash(handshake_messages)) | |||
[0..verify_data_length-1]; | [0..verify_data_length-1]; | |||
finished_label | finished_label | |||
For Finished messages sent by the client, the string "client | For Finished messages sent by the client, the string | |||
finished". For Finished messages sent by the server, the string | "client finished". For Finished messages sent by the server, | |||
"server finished". | the string "server finished". | |||
Hash denotes a Hash of the handshake messages. For the PRF defined | Hash denotes a Hash of the handshake messages. For the PRF | |||
in Section 5, the Hash MUST be the Hash used as the basis for the | defined in Section 5, the Hash MUST be the Hash used as the basis | |||
PRF. Any cipher suite which defines a different PRF MUST also | for the PRF. Any cipher suite which defines a different PRF MUST | |||
define the Hash to use in the Finished computation. | also define the Hash to use in the Finished computation. | |||
In previous versions of TLS, the verify_data was always 12 octets | In previous versions of TLS, the verify_data was always 12 octets | |||
long. In the current version of TLS, it depends on the cipher | long. In the current version of TLS, it depends on the cipher | |||
suite. Any cipher suite which does not explicitly specify | suite. Any cipher suite which does not explicitly specify | |||
verify_data_length has a verify_data_length equal to 12. This | verify_data_length has a verify_data_length equal to 12. This | |||
includes all existing cipher suites. Note that this | includes all existing cipher suites. Note that this | |||
representation has the same encoding as with previous versions. | representation has the same encoding as with previous versions. | |||
Future cipher suites MAY specify other lengths but such length | Future cipher suites MAY specify other lengths but such length | |||
MUST be at least 12 bytes. | MUST be at least 12 bytes. | |||
handshake_messages | handshake_messages | |||
All of the data from all messages in this handshake (not | All of the data from all messages in this handshake (not | |||
including any HelloRequest messages) up to but not including | including any HelloRequest messages) up to, but not including, | |||
this message. This is only data visible at the handshake layer | this message. This is only data visible at the handshake layer | |||
and does not include record layer headers. This is the | and does not include record layer headers. This is the | |||
concatenation of all the Handshake structures as defined in | concatenation of all the Handshake structures as defined in | |||
7.4, exchanged thus far. | Section 7.4, exchanged thus far. | |||
It is a fatal error if a finished message is not preceded by a | It is a fatal error if a Finished message is not preceded by a | |||
ChangeCipherSpec message at the appropriate point in the handshake. | ChangeCipherSpec message at the appropriate point in the handshake. | |||
The value handshake_messages includes all handshake messages starting | The value handshake_messages includes all handshake messages starting | |||
at ClientHello up to, but not including, this Finished message. This | at ClientHello up to, but not including, this Finished message. This | |||
may be different from handshake_messages in Section 7.4.8 because it | may be different from handshake_messages in Section 7.4.8 because it | |||
would include the CertificateVerify message (if sent). Also, the | would include the CertificateVerify message (if sent). Also, the | |||
handshake_messages for the Finished message sent by the client will | handshake_messages for the Finished message sent by the client will | |||
be different from that for the Finished message sent by the server, | be different from that for the Finished message sent by the server, | |||
because the one that is sent second will include the prior one. | because the one that is sent second will include the prior one. | |||
Note: ChangeCipherSpec messages, alerts, and any other record types | Note: ChangeCipherSpec messages, alerts, and any other record types | |||
are not handshake messages and are not included in the hash | are not handshake messages and are not included in the hash | |||
computations. Also, HelloRequest messages are omitted from handshake | computations. Also, HelloRequest messages are omitted from handshake | |||
hashes. | hashes. | |||
8. Cryptographic Computations | 8. Cryptographic Computations | |||
In order to begin connection protection, the TLS Record Protocol | In order to begin connection protection, the TLS Record Protocol | |||
requires specification of a suite of algorithms, a master secret, and | requires specification of a suite of algorithms, a master secret, and | |||
the client and server random values. The authentication, encryption, | the client and server random values. The authentication, encryption, | |||
and MAC algorithms are determined by the cipher_suite selected by the | and MAC algorithms are determined by the cipher_suite selected by the | |||
server and revealed in the server hello message. The compression | server and revealed in the ServerHello message. The compression | |||
algorithm is negotiated in the hello messages, and the random values | algorithm is negotiated in the hello messages, and the random values | |||
are exchanged in the hello messages. All that remains is to calculate | are exchanged in the hello messages. All that remains is to | |||
the master secret. | calculate the master secret. | |||
8.1. Computing the Master Secret | 8.1. Computing the Master Secret | |||
For all key exchange methods, the same algorithm is used to convert | For all key exchange methods, the same algorithm is used to convert | |||
the pre_master_secret into the master_secret. The pre_master_secret | the pre_master_secret into the master_secret. The pre_master_secret | |||
should be deleted from memory once the master_secret has been | should be deleted from memory once the master_secret has been | |||
computed. | computed. | |||
master_secret = PRF(pre_master_secret, "master secret", | master_secret = PRF(pre_master_secret, "master secret", | |||
ClientHello.random + ServerHello.random) | ClientHello.random + ServerHello.random) | |||
[0..47]; | [0..47]; | |||
The master secret is always exactly 48 bytes in length. The length of | The master secret is always exactly 48 bytes in length. The length | |||
the premaster secret will vary depending on key exchange method. | of the premaster secret will vary depending on key exchange method. | |||
8.1.1. RSA | 8.1.1. RSA | |||
When RSA is used for server authentication and key exchange, a | When RSA is used for server authentication and key exchange, a 48- | |||
48-byte pre_master_secret is generated by the client, encrypted under | byte pre_master_secret is generated by the client, encrypted under | |||
the server's public key, and sent to the server. The server uses its | the server's public key, and sent to the server. The server uses its | |||
private key to decrypt the pre_master_secret. Both parties then | private key to decrypt the pre_master_secret. Both parties then | |||
convert the pre_master_secret into the master_secret, as specified | convert the pre_master_secret into the master_secret, as specified | |||
above. | above. | |||
8.1.2. Diffie-Hellman | 8.1.2. Diffie-Hellman | |||
A conventional Diffie-Hellman computation is performed. The | A conventional Diffie-Hellman computation is performed. The | |||
negotiated key (Z) is used as the pre_master_secret, and is converted | negotiated key (Z) is used as the pre_master_secret, and is converted | |||
into the master_secret, as specified above. Leading bytes of Z that | into the master_secret, as specified above. Leading bytes of Z that | |||
contain all zero bits are stripped before it is used as the | contain all zero bits are stripped before it is used as the | |||
pre_master_secret. | pre_master_secret. | |||
Note: Diffie-Hellman parameters are specified by the server and may | Note: Diffie-Hellman parameters are specified by the server and may | |||
be either ephemeral or contained within the server's certificate. | be either ephemeral or contained within the server's certificate. | |||
9. Mandatory Cipher Suites | 9. Mandatory Cipher Suites | |||
In the absence of an application profile standard specifying | In the absence of an application profile standard specifying | |||
otherwise, a TLS compliant application MUST implement the cipher | otherwise, a TLS-compliant application MUST implement the cipher | |||
suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the | suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the | |||
definition). | definition). | |||
10. Application Data Protocol | 10. Application Data Protocol | |||
Application data messages are carried by the Record Layer and are | Application data messages are carried by the record layer and are | |||
fragmented, compressed, and encrypted based on the current connection | fragmented, compressed, and encrypted based on the current connection | |||
state. The messages are treated as transparent data to the record | state. The messages are treated as transparent data to the record | |||
layer. | layer. | |||
11. Security Considerations | 11. Security Considerations | |||
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 has updated these to reference this document. The | |||
reference this document. The registries and their allocation policies | registries and their allocation policies (unchanged from [TLS1.1]) | |||
(unchanged from [TLS1.1]) are listed below. | 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 via Specification Required [RFC2434]. Values from | |||
(decimal) inclusive are reserved for Private Use [RFC2434]. | 224-255 (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 range 0-191 (decimal) inclusive are assigned via Standards | the range 0-191 (decimal) inclusive are assigned via Standards | |||
Action [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]. | Use [RFC2434]. | |||
- This document defines several new HMAC-SHA256 based cipher suites, | - This document defines several new HMAC-SHA256-based cipher suites, | |||
whose values (in Appendix A.5) are to be (have been) allocated | whose values (in Appendix A.5) have been allocated from the TLS | |||
from the TLS Cipher Suite registry. | 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]. | |||
This document also uses a registry originally created in [RFC4366]. | This document also uses a registry originally created in [RFC4366]. | |||
IANA is requested to update (has updated) it to reference this | IANA has updated it to reference this document. The registry and its | |||
document. The registry and its allocation policy (unchanged from | allocation policy (unchanged from [RFC4366]) is listed below: | |||
[RFC4366]) is listed below: | ||||
- TLS ExtensionType Registry: Future values are allocated via IETF | - TLS ExtensionType Registry: Future values are allocated via IETF | |||
Consensus [RFC2434]. IANA is requested to update this registry to | Consensus [RFC2434]. IANA has updated this registry to include | |||
include the signature_algorithms extension and fill in the | the signature_algorithms extension and its corresponding value | |||
appropriate value in Section 7.4.1.4. | (see Section 7.4.1.4). | |||
In addition, this document defines two new registries to be | In addition, this document defines two new registries to be | |||
maintained by IANA: | maintained by IANA: | |||
- TLS SignatureAlgorithm Registry: The registry will be initially | - TLS SignatureAlgorithm Registry: The registry has been initially | |||
populated with the values described in Section 7.4.1.4.1. Future | populated with the values described in Section 7.4.1.4.1. Future | |||
values in the range 0-63 (decimal) inclusive are assigned via | values in the range 0-63 (decimal) inclusive are assigned via | |||
Standards Action [RFC2434]. Values in the range 64-223 (decimal) | Standards Action [RFC2434]. Values in the range 64-223 (decimal) | |||
inclusive are assigned via Specification Required [RFC2434]. | inclusive are assigned via Specification Required [RFC2434]. | |||
Values from 224-255 (decimal) inclusive are reserved for Private | Values from 224-255 (decimal) inclusive are reserved for Private | |||
Use [RFC2434]. | Use [RFC2434]. | |||
- TLS HashAlgorithm Registry: The registry will be initially | - TLS HashAlgorithm Registry: The registry has been initially | |||
populated with the values described in Section 7.4.1.4.1. Future | populated with the values described in Section 7.4.1.4.1. Future | |||
values in the range 0-63 (decimal) inclusive are assigned via | values in the range 0-63 (decimal) inclusive are assigned via | |||
Standards Action [RFC2434]. Values in the range 64-223 (decimal) | Standards Action [RFC2434]. Values in the range 64-223 (decimal) | |||
inclusive are assigned via Specification Required [RFC2434]. | inclusive are assigned via Specification Required [RFC2434]. | |||
Values from 224-255 (decimal) inclusive are reserved for Private | Values from 224-255 (decimal) inclusive are reserved for Private | |||
Use [RFC2434]. | Use [RFC2434]. | |||
This document also uses the TLS Compression Method Identifiers | This document also uses the TLS Compression Method Identifiers | |||
Registry, defined in [RFC3749]. IANA is requested to allocate | Registry, defined in [RFC3749]. IANA has allocated value 0 for | |||
value 0 for the "null" compression method. | the "null" compression method. | |||
Appendix A. Protocol Data Structures and Constant Values | Appendix A. Protocol Data Structures and Constant Values | |||
This section describes protocol types and constants. | This section describes protocol types and constants. | |||
A.1. Record Layer | A.1. Record Layer | |||
struct { | struct { | |||
uint8 major; | uint8 major; | |||
uint8 minor; | uint8 minor; | |||
} ProtocolVersion; | } ProtocolVersion; | |||
ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/ | ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/ | |||
enum { | enum { | |||
change_cipher_spec(20), alert(21), handshake(22), | change_cipher_spec(20), alert(21), handshake(22), | |||
skipping to change at page 66, line 20 ¶ | skipping to change at page 69, line 20 ¶ | |||
uint8 padding_length; | uint8 padding_length; | |||
}; | }; | |||
} GenericBlockCipher; | } GenericBlockCipher; | |||
struct { | struct { | |||
opaque nonce_explicit[SecurityParameters.record_iv_length]; | opaque nonce_explicit[SecurityParameters.record_iv_length]; | |||
aead-ciphered struct { | aead-ciphered struct { | |||
opaque content[TLSCompressed.length]; | opaque content[TLSCompressed.length]; | |||
}; | }; | |||
} GenericAEADCipher; | } GenericAEADCipher; | |||
A.2. Change Cipher Specs Message | ||||
A.2. Change Cipher Specs Message | ||||
struct { | struct { | |||
enum { change_cipher_spec(1), (255) } type; | enum { change_cipher_spec(1), (255) } type; | |||
} ChangeCipherSpec; | } ChangeCipherSpec; | |||
A.3. Alert Messages | A.3. Alert Messages | |||
enum { warning(1), fatal(2), (255) } AlertLevel; | enum { warning(1), fatal(2), (255) } AlertLevel; | |||
enum { | enum { | |||
close_notify(0), | close_notify(0), | |||
unexpected_message(10), | unexpected_message(10), | |||
bad_record_mac(20), | bad_record_mac(20), | |||
decryption_failed_RESERVED(21), | decryption_failed_RESERVED(21), | |||
record_overflow(22), | record_overflow(22), | |||
decompression_failure(30), | decompression_failure(30), | |||
skipping to change at page 67, line 16 ¶ | skipping to change at page 70, line 17 ¶ | |||
no_renegotiation(100), | no_renegotiation(100), | |||
unsupported_extension(110), /* new */ | unsupported_extension(110), /* new */ | |||
(255) | (255) | |||
} AlertDescription; | } AlertDescription; | |||
struct { | struct { | |||
AlertLevel level; | AlertLevel level; | |||
AlertDescription description; | AlertDescription description; | |||
} Alert; | } Alert; | |||
A.4. Handshake Protocol | A.4. Handshake Protocol | |||
enum { | enum { | |||
hello_request(0), client_hello(1), server_hello(2), | hello_request(0), client_hello(1), server_hello(2), | |||
certificate(11), server_key_exchange (12), | certificate(11), server_key_exchange (12), | |||
certificate_request(13), server_hello_done(14), | certificate_request(13), server_hello_done(14), | |||
certificate_verify(15), client_key_exchange(16), | certificate_verify(15), client_key_exchange(16), | |||
finished(20) | finished(20) | |||
(255) | (255) | |||
} HandshakeType; | } HandshakeType; | |||
skipping to change at page 67, line 44 ¶ | skipping to change at page 71, line 5 ¶ | |||
case certificate: Certificate; | case certificate: Certificate; | |||
case server_key_exchange: ServerKeyExchange; | case server_key_exchange: ServerKeyExchange; | |||
case certificate_request: CertificateRequest; | case certificate_request: CertificateRequest; | |||
case server_hello_done: ServerHelloDone; | case server_hello_done: ServerHelloDone; | |||
case certificate_verify: CertificateVerify; | case certificate_verify: CertificateVerify; | |||
case client_key_exchange: ClientKeyExchange; | case client_key_exchange: ClientKeyExchange; | |||
case finished: Finished; | case finished: Finished; | |||
} body; | } body; | |||
} Handshake; | } Handshake; | |||
A.4.1. Hello Messages | A.4.1. Hello Messages | |||
struct { } HelloRequest; | struct { } HelloRequest; | |||
struct { | struct { | |||
uint32 gmt_unix_time; | uint32 gmt_unix_time; | |||
opaque random_bytes[28]; | opaque random_bytes[28]; | |||
} Random; | } Random; | |||
opaque SessionID<0..32>; | opaque SessionID<0..32>; | |||
uint8 CipherSuite[2]; | uint8 CipherSuite[2]; | |||
enum { null(0), (255) } CompressionMethod; | enum { null(0), (255) } CompressionMethod; | |||
struct { | struct { | |||
ProtocolVersion client_version; | ProtocolVersion client_version; | |||
Random random; | Random random; | |||
SessionID session_id; | SessionID session_id; | |||
skipping to change at page 68, line 42 ¶ | skipping to change at page 72, line 4 ¶ | |||
struct {}; | struct {}; | |||
case true: | case true: | |||
Extension extensions<0..2^16-1>; | Extension extensions<0..2^16-1>; | |||
}; | }; | |||
} ServerHello; | } ServerHello; | |||
struct { | struct { | |||
ExtensionType extension_type; | ExtensionType extension_type; | |||
opaque extension_data<0..2^16-1>; | opaque extension_data<0..2^16-1>; | |||
} Extension; | } Extension; | |||
enum { | enum { | |||
signature_algorithms(TBD-BY-IANA), (65535) | signature_algorithms(13), (65535) | |||
} ExtensionType; | } ExtensionType; | |||
enum{ | enum{ | |||
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), | none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), | |||
sha512(6), (255) | sha512(6), (255) | |||
} HashAlgorithm; | } HashAlgorithm; | |||
enum { | enum { | |||
anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) | 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-1>; | |||
A.4.2. Server Authentication and Key Exchange Messages | A.4.2. Server Authentication and Key Exchange Messages | |||
opaque ASN.1Cert<2^24-1>; | opaque ASN.1Cert<2^24-1>; | |||
struct { | struct { | |||
ASN.1Cert certificate_list<0..2^24-1>; | ASN.1Cert certificate_list<0..2^24-1>; | |||
} Certificate; | } Certificate; | |||
enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa | enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa | |||
/* may be extended, e.g. for ECDH -- see [TLSECC] */ | /* may be extended, e.g., for ECDH -- see [TLSECC] */ | |||
} KeyExchangeAlgorithm; | } KeyExchangeAlgorithm; | |||
struct { | struct { | |||
opaque dh_p<1..2^16-1>; | opaque dh_p<1..2^16-1>; | |||
opaque dh_g<1..2^16-1>; | opaque dh_g<1..2^16-1>; | |||
opaque dh_Ys<1..2^16-1>; | opaque dh_Ys<1..2^16-1>; | |||
} ServerDHParams; /* Ephemeral DH parameters */ | } ServerDHParams; /* Ephemeral DH parameters */ | |||
struct { | struct { | |||
select (KeyExchangeAlgorithm) { | select (KeyExchangeAlgorithm) { | |||
case dh_anon: | case dh_anon: | |||
ServerDHParams params; | ServerDHParams params; | |||
case dhe_dss: | case dhe_dss: | |||
case dhe_rsa: | case dhe_rsa: | |||
ServerDHParams params; | ServerDHParams params; | |||
digitally-signed struct { | digitally-signed struct { | |||
opaque client_random[32]; | opaque client_random[32]; | |||
opaque server_random[32]; | opaque server_random[32]; | |||
skipping to change at page 69, line 51 ¶ | skipping to change at page 73, line 21 ¶ | |||
digitally-signed struct { | digitally-signed struct { | |||
opaque client_random[32]; | opaque client_random[32]; | |||
opaque server_random[32]; | opaque server_random[32]; | |||
ServerDHParams params; | ServerDHParams params; | |||
} signed_params; | } signed_params; | |||
case rsa: | case rsa: | |||
case dh_dss: | case dh_dss: | |||
case dh_rsa: | case dh_rsa: | |||
struct {} ; | struct {} ; | |||
/* message is omitted for rsa, dh_dss, and dh_rsa */ | /* message is omitted for rsa, dh_dss, and dh_rsa */ | |||
/* may be extended, e.g. for ECDH -- see [TLSECC] */ | /* may be extended, e.g., for ECDH -- see [TLSECC] */ | |||
} ServerKeyExchange; | } ServerKeyExchange; | |||
enum { | enum { | |||
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | |||
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), | rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), | |||
fortezza_dms_RESERVED(20), | fortezza_dms_RESERVED(20), | |||
(255) | (255) | |||
} ClientCertificateType; | } ClientCertificateType; | |||
opaque DistinguishedName<1..2^16-1>; | opaque DistinguishedName<1..2^16-1>; | |||
struct { | struct { | |||
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: | case rsa: | |||
EncryptedPreMasterSecret; | EncryptedPreMasterSecret; | |||
case dhe_dss: | case dhe_dss: | |||
case dhe_rsa: | case dhe_rsa: | |||
case dh_dss: | case dh_dss: | |||
case dh_rsa: | case dh_rsa: | |||
case dh_anon: | case dh_anon: | |||
skipping to change at page 71, line 14 ¶ | skipping to change at page 74, line 44 ¶ | |||
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 { | |||
digitally-signed struct { | digitally-signed struct { | |||
opaque handshake_messages[handshake_messages_length]; | 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 | |||
hello and server hello messages. | ClientHello and ServerHello 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 }; | |||
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_NULL_SHA256 = { 0x00,0x3B }; | |||
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_128_CBC_SHA256 = { 0x00,0x3C }; | |||
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBD3 }; | CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D }; | |||
The following cipher suite definitions are used for server- | The following cipher suite definitions are used for server- | |||
authenticated (and optionally client-authenticated) Diffie-Hellman. | authenticated (and optionally client-authenticated) Diffie-Hellman. | |||
DH denotes cipher suites in which the server's certificate contains | DH denotes cipher suites in which the server's certificate contains | |||
the Diffie-Hellman parameters signed by the certificate authority | the Diffie-Hellman parameters signed by the certificate authority | |||
(CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman | (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman | |||
parameters are signed by a signature-capable certificate, which has | parameters are signed by a signature-capable certificate, which has | |||
been signed by the CA. The signing algorithm used by the server is | been signed by the CA. The signing algorithm used by the server is | |||
specified after the DHE component of the CipherSuite name. The server | specified after the DHE component of the CipherSuite name. The | |||
can request any signature-capable certificate from the client for | server can request any signature-capable certificate from the client | |||
client authentication or it may request a Diffie-Hellman certificate. | for client authentication, or it may request a Diffie-Hellman | |||
Any Diffie-Hellman certificate provided by the client must use the | certificate. Any Diffie-Hellman certificate provided by the client | |||
parameters (group and generator) described by the server. | must use the parameters (group and generator) described by the | |||
server. | ||||
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; | CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; | |||
CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; | CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; | |||
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; | CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; | |||
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; | CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; | |||
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 }; | CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 }; | |||
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 }; | CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 }; | |||
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 }; | CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 }; | |||
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 }; | CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 }; | |||
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 }; | CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 }; | |||
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 }; | CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 }; | |||
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 }; | CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 }; | |||
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 }; | CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 }; | |||
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,TBD4 }; | CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x3E }; | |||
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD5 }; | CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3F }; | |||
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,TBD6 }; | CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x40 }; | |||
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD7 }; | CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x67 }; | |||
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,TBD8 }; | CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x68 }; | |||
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBD9 }; | CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x69 }; | |||
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,TBDA }; | CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x6A }; | |||
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBDB }; | CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x6B }; | |||
The following cipher suites are used for completely anonymous Diffie- | The following cipher suites are used for completely anonymous | |||
Hellman communications in which neither party is authenticated. Note | Diffie-Hellman communications in which neither party is | |||
that this mode is vulnerable to man-in-the-middle attacks. Using | authenticated. Note that this mode is vulnerable to man-in-the- | |||
this mode therefore is of limited use: These cipher suites MUST NOT | middle attacks. Using this mode therefore is of limited use: These | |||
be used by TLS 1.2 implementations unless the application layer has | cipher suites MUST NOT be used by TLS 1.2 implementations unless the | |||
specifically requested to allow anonymous key exchange. (Anonymous | application layer has specifically requested to allow anonymous key | |||
key exchange may sometimes be acceptable, for example, to support | exchange. (Anonymous key exchange may sometimes be acceptable, for | |||
opportunistic encryption when no set-up for authentication is in | example, to support opportunistic encryption when no set-up for | |||
place, or when TLS is used as part of more complex security protocols | authentication is in place, or when TLS is used as part of more | |||
that have other means to ensure authentication.) | complex security protocols that have other means to ensure | |||
authentication.) | ||||
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; | CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; | |||
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; | CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; | |||
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; | CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; | |||
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; | CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; | |||
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,TBDC}; | CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,0x6C }; | |||
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,TBDD}; | CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,0x6D }; | |||
Note that using non-anonymous key exchange without actually verifying | Note that using non-anonymous key exchange without actually verifying | |||
the key exchange is essentially equivalent to anonymous key exchange, | the key exchange is essentially equivalent to anonymous key exchange, | |||
and the same precautions apply. While non-anonymous key exchange | and the same precautions apply. While non-anonymous key exchange | |||
will generally involve a higher computational and communicational | will generally involve a higher computational and communicational | |||
cost than anonymous key exchange, it may be in the interest of | cost than anonymous key exchange, it may be in the interest of | |||
interoperability not to disable non-anonymous key exchange when the | interoperability not to disable non-anonymous key exchange when the | |||
application layer is allowing anonymous key exchange. | application layer is allowing anonymous key exchange. | |||
New cipher suite values are assigned by IANA as described in Section | New cipher suite values have been assigned by IANA as described in | |||
12. | Section 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 | |||
3. | SSL 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 | |||
Protocol and provided as parameters to the TLS Record Layer in order | Protocol and provided as parameters to the TLS record layer in order | |||
to initialize a connection state. SecurityParameters includes: | to initialize a connection state. SecurityParameters includes: | |||
enum { null(0), (255) } CompressionMethod; | enum { null(0), (255) } CompressionMethod; | |||
enum { server, client } ConnectionEnd; | enum { server, client } ConnectionEnd; | |||
enum { tls_prf_sha256 } PRFAlgorithm; | enum { tls_prf_sha256 } PRFAlgorithm; | |||
enum { null, rc4, 3des, aes } | enum { null, rc4, 3des, aes } BulkCipherAlgorithm; | |||
BulkCipherAlgorithm; | ||||
enum { stream, block, aead } CipherType; | enum { stream, block, aead } CipherType; | |||
enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384, | enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384, | |||
hmac_sha512} MACAlgorithm; | hmac_sha512} MACAlgorithm; | |||
/* The algorithms specified in CompressionMethod, PRFAlgorithm | /* Other values may be added to the algorithms specified in | |||
BulkCipherAlgorithm, and MACAlgorithm may be added to. */ | CompressionMethod, PRFAlgorithm, BulkCipherAlgorithm, and | |||
MACAlgorithm. */ | ||||
struct { | struct { | |||
ConnectionEnd entity; | ConnectionEnd entity; | |||
PRFAlgorithm prf_algorithm; | PRFAlgorithm prf_algorithm; | |||
BulkCipherAlgorithm bulk_cipher_algorithm; | BulkCipherAlgorithm bulk_cipher_algorithm; | |||
CipherType cipher_type; | CipherType cipher_type; | |||
uint8 enc_key_length; | uint8 enc_key_length; | |||
uint8 block_length; | uint8 block_length; | |||
uint8 fixed_iv_length; | uint8 fixed_iv_length; | |||
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 | A.7. Changes to RFC 4492 | |||
RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This | RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This | |||
document changes some of the structures used in that document. This | document changes some of the structures used in that document. This | |||
section details the required changes for implementors of both RFC | section details the required changes for implementors of both RFC | |||
4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing | 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing | |||
RFC 4492 do not need to read this section. | RFC 4492 do not need to read this section. | |||
This document adds a "signature_algorithm" field to the digitally- | This document adds a "signature_algorithm" field to the digitally- | |||
signed element in order to identify the signature and digest | signed element in order to identify the signature and digest | |||
algorithms used to create a signature. This change applies to digital | algorithms used to create a signature. This change applies to | |||
signatures formed using ECDSA as well, thus allowing ECDSA signatures | digital signatures formed using ECDSA as well, thus allowing ECDSA | |||
to be used with digest algorithms other than SHA-1, provided such use | signatures to be used with digest algorithms other than SHA-1, | |||
is compatible with the certificate and any restrictions imposed by | provided such use is compatible with the certificate and any | |||
future revisions of [PKIX]. | restrictions imposed by future revisions of [PKIX]. | |||
As described in Sections 7.4.2 and 7.4.6, the restrictions on the | As described in Sections 7.4.2 and 7.4.6, the restrictions on the | |||
signature algorithms used to sign certificates are no longer tied to | signature algorithms used to sign certificates are no longer tied to | |||
the cipher suite (when used by the server) or the | the cipher suite (when used by the server) or the | |||
ClientCertificateType (when used by the client). Thus, the | ClientCertificateType (when used by the client). Thus, the | |||
restrictions on the algorithm used to sign certificates specified in | restrictions on the algorithm used to sign certificates specified in | |||
Sections 2 and 3 of RFC 4492 are also relaxed. As in this document | Sections 2 and 3 of RFC 4492 are also relaxed. As in this document, | |||
the restrictions on the keys in the end-entity certificate remain. | the restrictions on the keys in the end-entity certificate remain. | |||
Appendix B. Glossary | Appendix B. Glossary | |||
Advanced Encryption Standard (AES) | Advanced Encryption Standard (AES) | |||
AES [AES] is a widely used symmetric encryption algorithm. AES is | AES [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 | a block cipher with a 128-, 192-, or 256-bit keys and a 16-byte | |||
block size. TLS currently only supports the 128 and 256 bit key | block size. TLS currently only supports the 128- and 256-bit key | |||
sizes. | sizes. | |||
application protocol | application protocol | |||
An application protocol is a protocol that normally layers | An application protocol is a protocol that normally layers | |||
directly on top of the transport layer (e.g., TCP/IP). Examples | directly on top of the transport layer (e.g., TCP/IP). Examples | |||
include HTTP, TELNET, FTP, and SMTP. | include HTTP, TELNET, FTP, and SMTP. | |||
asymmetric cipher | asymmetric cipher | |||
See public key cryptography. | See public key cryptography. | |||
authenticated encryption with additional data (AEAD) | authenticated encryption with additional data (AEAD) | |||
A symmetric encryption algorithm that simultaneously provides | A symmetric encryption algorithm that simultaneously provides | |||
confidentiality and message integrity. | confidentiality and message integrity. | |||
authentication | authentication | |||
Authentication is the ability of one entity to determine the | Authentication is the ability of one entity to determine the | |||
identity of another entity. | identity of another entity. | |||
block cipher | block cipher | |||
A block cipher is an algorithm that operates on plaintext in | A block cipher is an algorithm that operates on plaintext in | |||
groups of bits, called blocks. 64 bits was, and 128 bits, is a | groups of bits, called blocks. 64 bits was, and 128 bits is, a | |||
common block size. | common block size. | |||
bulk cipher | bulk cipher | |||
A symmetric encryption algorithm used to encrypt large quantities | A symmetric encryption algorithm used to encrypt large quantities | |||
of data. | of data. | |||
cipher block chaining (CBC) | cipher block chaining (CBC) | |||
CBC is a mode in which every plaintext block encrypted with a | CBC is a mode in which every plaintext block encrypted with a | |||
block cipher is first exclusive-ORed with the previous ciphertext | block cipher is first exclusive-ORed with the previous ciphertext | |||
block (or, in the case of the first block, with the initialization | block (or, in the case of the first block, with the initialization | |||
vector). For decryption, every block is first decrypted, then | vector). For decryption, every block is first decrypted, then | |||
exclusive-ORed with the previous ciphertext block (or IV). | exclusive-ORed with the previous ciphertext block (or IV). | |||
certificate | certificate | |||
As part of the X.509 protocol (a.k.a. ISO Authentication | As part of the X.509 protocol (a.k.a. ISO Authentication | |||
framework), certificates are assigned by a trusted Certificate | framework), certificates are assigned by a trusted Certificate | |||
Authority and provide a strong binding between a party's identity | Authority and provide a strong binding between a party's identity | |||
or some other attributes and its public key. | or some other attributes and its public key. | |||
client | client | |||
The application entity that initiates a TLS connection to a | The application entity that initiates a TLS connection to a | |||
server. This may or may not imply that the client initiated the | server. This may or may not imply that the client initiated the | |||
underlying transport connection. The primary operational | underlying transport connection. The primary operational | |||
difference between the server and client is that the server is | difference between the server and client is that the server is | |||
generally authenticated, while the client is only optionally | generally authenticated, while the client is only optionally | |||
authenticated. | authenticated. | |||
client write key | client write key | |||
The key used to encrypt data written by the client. | The key used to encrypt data written by the client. | |||
client write MAC key | client write MAC key | |||
The secret data used to authenticate data written by the client. | The secret data used to authenticate data written by the client. | |||
connection | connection | |||
A connection is a transport (in the OSI layering model definition) | A connection is a transport (in the OSI layering model definition) | |||
that provides a suitable type of service. For TLS, such | that provides a suitable type of service. For TLS, such | |||
connections are peer-to-peer relationships. The connections are | connections are peer-to-peer relationships. The connections are | |||
transient. Every connection is associated with one session. | transient. Every connection is associated with one session. | |||
Data Encryption Standard | Data Encryption Standard | |||
DES [DES] still is a very widely used symmetric encryption | DES [DES] still is a very widely used symmetric encryption | |||
algorithm although it is considered as rather weak now. DES is a | algorithm although it is considered as rather weak now. DES is a | |||
block cipher with a 56-bit key and an 8-byte block size. Note that | block cipher with a 56-bit key and an 8-byte block size. Note | |||
in TLS, for key generation purposes, DES is treated as having an | that in TLS, for key generation purposes, DES is treated as having | |||
8-byte key length (64 bits), but it still only provides 56 bits of | an 8-byte key length (64 bits), but it still only provides 56 bits | |||
protection. (The low bit of each key byte is presumed to be set to | of protection. (The low bit of each key byte is presumed to be | |||
produce odd parity in that key byte.) DES can also be operated in | set to produce odd parity in that key byte.) DES can also be | |||
a mode [3DES] where three independent keys and three encryptions | operated in a mode [3DES] where three independent keys and three | |||
are used for each block of data; this uses 168 bits of key (24 | encryptions are used for each block of data; this uses 168 bits of | |||
bytes in the TLS key generation method) and provides the | key (24 bytes in the TLS key generation method) and provides the | |||
equivalent of 112 bits of security. | equivalent of 112 bits of security. | |||
Digital Signature Standard (DSS) | Digital Signature Standard (DSS) | |||
A standard for digital signing, including the Digital Signing | A standard for digital signing, including the Digital Signing | |||
Algorithm, approved by the National Institute of Standards and | Algorithm, approved by the National Institute of Standards and | |||
Technology, defined in NIST FIPS PUB 186-2, "Digital Signature | Technology, defined in NIST FIPS PUB 186-2, "Digital Signature | |||
Standard", published January 2000 by the U.S. Dept. of Commerce | Standard", published January 2000 by the U.S. Department of | |||
[DSS]. A significant update [DSS-3] has been drafted and | Commerce [DSS]. A significant update [DSS-3] has been drafted and | |||
published in March 2006. | was published in March 2006. | |||
digital signatures | digital signatures | |||
Digital signatures utilize public key cryptography and one-way | Digital signatures utilize public key cryptography and one-way | |||
hash functions to produce a signature of the data that can be | hash functions to produce a signature of the data that can be | |||
authenticated, and is difficult to forge or repudiate. | authenticated, and is difficult to forge or repudiate. | |||
handshake | handshake An initial negotiation between client and server that | |||
An initial negotiation between client and server that establishes | 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. | |||
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. | |||
MD5 | MD5 | |||
MD5 [MD5] is a hashing function that converts an arbitrarily long | MD5 [MD5] is a hashing function that converts an arbitrarily long | |||
data stream into a hash of fixed size (16 bytes). Due to | data stream into a hash of fixed size (16 bytes). Due to | |||
significant progresses in cryptanalysis, at the time of | significant progress in cryptanalysis, at the time of publication | |||
publication of this document, MD5 no longer can be considered a | of this document, MD5 no longer can be considered a 'secure' | |||
'secure' hashing function. | hashing function. | |||
public key cryptography | public key cryptography | |||
A class of cryptographic techniques employing two-key ciphers. | A class of cryptographic techniques employing two-key ciphers. | |||
Messages encrypted with the public key can only be decrypted with | Messages encrypted with the public key can only be decrypted with | |||
the associated private key. Conversely, messages signed with the | the associated private key. Conversely, messages signed with the | |||
private key can be verified with the public key. | private key can be verified with the public key. | |||
one-way hash function | one-way hash function | |||
A one-way transformation that converts an arbitrary amount of data | A one-way transformation that converts an arbitrary amount of data | |||
into a fixed-length hash. It is computationally hard to reverse | into a fixed-length hash. It is computationally hard to reverse | |||
the transformation or to find collisions. MD5 and SHA are examples | the transformation or to find collisions. MD5 and SHA are | |||
of one-way hash functions. | examples of one-way hash functions. | |||
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 | |||
connections from clients. See also under client. | connections from clients. See also "client". | |||
session | session | |||
A TLS session is an association between a client and a server. | A TLS session is an association between a client and a server. | |||
Sessions are created by the handshake protocol. Sessions define a | Sessions are created by the handshake protocol. Sessions define a | |||
set of cryptographic security parameters that can be shared among | set of cryptographic security parameters that can be shared among | |||
multiple connections. Sessions are used to avoid the expensive | multiple connections. Sessions are used to avoid the expensive | |||
negotiation of new security parameters for each connection. | negotiation of new security parameters for each connection. | |||
session identifier | session identifier | |||
A session identifier is a value generated by a server that | A session identifier is a value generated by a server that | |||
identifies a particular session. | identifies a particular session. | |||
server write key | server write key | |||
The key used to encrypt data written by the server. | The key used to encrypt data written by the server. | |||
server write MAC key | server write MAC key | |||
The secret data used to authenticate data written by the server. | The secret data used to authenticate data written by the server. | |||
SHA | SHA | |||
The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2. It | The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2. It | |||
produces a 20-byte output. Note that all references to SHA | produces a 20-byte output. Note that all references to SHA | |||
(without a numerical suffix) actually use the modified SHA-1 | (without a numerical suffix) actually use the modified SHA-1 | |||
algorithm. | algorithm. | |||
SHA-256 | SHA-256 | |||
The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. It | The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. | |||
produces a 32-byte output. | 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 "Working Group | |||
end of this document. | Information" at the end of this document (see page 99). | |||
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 | |||
skipping to change at page 80, line 24 ¶ | skipping to change at page 84, line 28 ¶ | |||
SHA256 HMAC-SHA256 32 32 | SHA256 HMAC-SHA256 32 32 | |||
Type | Type | |||
Indicates whether this is a stream cipher or a block cipher | Indicates whether this is a stream cipher or a block cipher | |||
running in CBC mode. | running in CBC mode. | |||
Key Material | Key Material | |||
The number of bytes from the key_block that are used for | The number of bytes from the key_block that are used for | |||
generating the write keys. | generating the write keys. | |||
Expanded Key Material | ||||
The number of bytes actually fed into the encryption algorithm. | ||||
IV Size | IV Size | |||
The amount of data needed to be generated for the initialization | The amount of data needed to be generated for the initialization | |||
vector. Zero for stream ciphers; equal to the block size for block | vector. Zero for stream ciphers; equal to the block size for | |||
ciphers (this is equal to SecurityParameters.record_iv_length). | block ciphers (this is equal to | |||
SecurityParameters.record_iv_length). | ||||
Block Size | Block Size | |||
The amount of data a block cipher enciphers in one chunk; a block | The amount of data a block cipher enciphers in one chunk; a block | |||
cipher running in CBC mode can only encrypt an even multiple of | cipher running in CBC mode can only encrypt an even multiple of | |||
its block size. | its block size. | |||
Appendix D. Implementation Notes | Appendix D. Implementation Notes | |||
The TLS protocol cannot prevent many common security mistakes. This | The TLS protocol cannot prevent many common security mistakes. This | |||
section provides several recommendations to assist implementors. | section provides several recommendations to assist implementors. | |||
D.1 Random Number Generation and Seeding | D.1. Random Number Generation and Seeding | |||
TLS requires a cryptographically secure pseudorandom number generator | TLS requires a cryptographically secure pseudorandom number generator | |||
(PRNG). Care must be taken in designing and seeding PRNGs. PRNGs | (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs | |||
based on secure hash operations, most notably SHA-1, are acceptable, | based on secure hash operations, most notably SHA-1, are acceptable, | |||
but cannot provide more security than the size of the random number | but cannot provide more security than the size of the random number | |||
generator state. | generator state. | |||
To estimate the amount of seed material being produced, add the | To estimate the amount of seed material being produced, add the | |||
number of bits of unpredictable information in each seed byte. For | number of bits of unpredictable information in each seed byte. For | |||
example, keystroke timing values taken from a PC compatible's 18.2 Hz | example, keystroke timing values taken from a PC compatible's 18.2 Hz | |||
timer provide 1 or 2 secure bits each, even though the total size of | timer provide 1 or 2 secure bits each, even though the total size of | |||
the counter value is 16 bits or more. Seeding a 128-bit PRNG would | the counter value is 16 bits or more. Seeding a 128-bit PRNG would | |||
thus require approximately 100 such timer values. | thus require approximately 100 such timer values. | |||
[RANDOM] provides guidance on the generation of random values. | [RANDOM] provides guidance on the generation of random values. | |||
D.2 Certificates and Authentication | D.2. Certificates and Authentication | |||
Implementations are responsible for verifying the integrity of | Implementations are responsible for verifying the integrity of | |||
certificates and should generally support certificate revocation | certificates and should generally support certificate revocation | |||
messages. Certificates should always be verified to ensure proper | messages. Certificates should always be verified to ensure proper | |||
signing by a trusted Certificate Authority (CA). The selection and | signing by a trusted Certificate Authority (CA). The selection and | |||
addition of trusted CAs should be done very carefully. Users should | addition of trusted CAs should be done very carefully. Users should | |||
be able to view information about the certificate and root CA. | be able to view information about the certificate and root CA. | |||
D.3 Cipher Suites | 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- | |||
RSA keys or signatures are not appropriate for high-security | bit RSA keys or signatures are not appropriate for high-security | |||
applications. | applications. | |||
D.4 Implementation Pitfalls | D.4. Implementation Pitfalls | |||
Implementation experience has shown that certain parts of earlier TLS | Implementation experience has shown that certain parts of earlier TLS | |||
specifications are not easy to understand, and have been a source of | specifications are not easy to understand, and have been a source of | |||
interoperability and security problems. Many of these areas have been | interoperability and security problems. Many of these areas have | |||
clarified in this document, but this appendix contains a short list | been clarified in this document, but this appendix contains a short | |||
of the most important things that require special attention from | list 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 | |||
to multiple TLS records (see Section 6.2.1)? Including corner | multiple TLS records (see Section 6.2.1)? Including corner cases | |||
cases like a ClientHello that is split to several small | like a ClientHello that is split to several small fragments? Do | |||
fragments? Do you fragment handshake messages that exceed the | you fragment handshake messages that exceed the maximum fragment | |||
maximum fragment size? In particular, the certificate and | size? In particular, the certificate and certificate request | |||
certificate request handshake messages can be large enough to | handshake messages can be large enough to require fragmentation. | |||
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 | |||
including omitting the extensions field completely? | 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 | |||
it is highly recommended. | highly recommended. | |||
- When the server has requested a client certificate, but no | - When the server has requested a client certificate, but no | |||
suitable certificate is available, do you correctly send | suitable certificate is available, do you correctly send an empty | |||
an empty Certificate message, instead of omitting the whole | Certificate message, instead of omitting the whole message (see | |||
message (see Section 7.4.6)? | Section 7.4.6)? | |||
Cryptographic details: | Cryptographic details: | |||
- In RSA-encrypted Premaster Secret, do you correctly send and | - In the RSA-encrypted Premaster Secret, do you correctly send and | |||
verify the version number? When an error is encountered, do | verify the version number? When an error is encountered, do you | |||
you continue the handshake to avoid the Bleichenbacher | continue the handshake to avoid the Bleichenbacher attack (see | |||
attack (see Section 7.4.7.1)? | Section 7.4.7.1)? | |||
- What countermeasures do you use to prevent timing attacks against | - What countermeasures do you use to prevent timing attacks against | |||
RSA decryption and signing operations (see Section 7.4.7.1)? | RSA decryption and signing operations (see Section 7.4.7.1)? | |||
- When verifying RSA signatures, do you accept both NULL and | - When verifying RSA signatures, do you accept both NULL and missing | |||
missing parameters (see Section 4.7)? Do you verify that the | parameters (see Section 4.7)? Do you verify that the RSA padding | |||
RSA padding doesn't have additional data after the hash value? | doesn't have additional data after the hash value? [FI06] | |||
[FI06] | ||||
- 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 | |||
sent by the server are acceptable (see Section F.1.1.3)? | by the server are acceptable (see Section F.1.1.3)? | |||
- How do you generate unpredictable IVs for CBC mode ciphers | ||||
(see Section 6.2.3.2)? | ||||
- Do you accept long CBC mode padding (up to 255 bytes; see | - How do you generate unpredictable IVs for CBC mode ciphers (see | |||
Section 6.2.3.2)? | 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 | |||
random number generator (see Appendix D.1) for generating the | number generator (see Appendix D.1) for generating the premaster | |||
premaster secret (for RSA key exchange), Diffie-Hellman private | secret (for RSA key exchange), Diffie-Hellman private values, the | |||
values, the DSA "k" parameter, and other security-critical | DSA "k" parameter, and other security-critical values? | |||
values? | ||||
Appendix E. Backward Compatibility | Appendix E. Backward Compatibility | |||
E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 | E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 | |||
Since there are various versions of TLS (1.0, 1.1, 1.2, and any | Since there are various versions of TLS (1.0, 1.1, 1.2, and any | |||
future versions) and SSL (2.0 and 3.0), means are needed to negotiate | future versions) and SSL (2.0 and 3.0), means are needed to negotiate | |||
the specific protocol version to use. The TLS protocol provides a | the specific protocol version to use. The TLS protocol provides a | |||
built-in mechanism for version negotiation so as not to bother other | built-in mechanism for version negotiation so as not to bother other | |||
protocol components with the complexities of version selection. | protocol components with the complexities of version selection. | |||
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use | TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use | |||
compatible ClientHello messages; thus, supporting all of them is | compatible ClientHello messages; thus, supporting all of them is | |||
relatively easy. Similarly, servers can easily handle clients trying | relatively easy. Similarly, servers can easily handle clients trying | |||
to use future versions of TLS as long as the ClientHello format | to use future versions of TLS as long as the ClientHello format | |||
remains compatible, and the client supports the highest protocol | remains compatible, and the client supports the highest protocol | |||
version available in the server. | version available in the server. | |||
A TLS 1.2 client who wishes to negotiate with such older servers will | A TLS 1.2 client who wishes to negotiate with such older servers will | |||
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in | send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in | |||
ClientHello.client_version. If the server does not support this | ClientHello.client_version. If the server does not support this | |||
version, it will respond with ServerHello containing an older version | version, it will respond with a ServerHello containing an older | |||
number. If the client agrees to use this version, the negotiation | version number. If the client agrees to use this version, the | |||
will proceed as appropriate for the negotiated protocol. | negotiation will proceed as appropriate for the negotiated protocol. | |||
If the version chosen by the server is not supported by the client | If the version chosen by the server is not supported by the client | |||
(or not acceptable), the client MUST send a "protocol_version" alert | (or not acceptable), the client MUST send a "protocol_version" alert | |||
message and close the connection. | message and close the connection. | |||
If a TLS server receives a ClientHello containing a version number | If a TLS server receives a ClientHello containing a version number | |||
greater than the highest version supported by the server, it MUST | greater than the highest version supported by the server, it MUST | |||
reply according to the highest version supported by the server. | reply according to the highest version supported by the server. | |||
A TLS server can also receive a ClientHello containing a version | A TLS server can also receive a ClientHello containing a version | |||
number smaller than the highest supported version. If the server | number smaller than the highest supported version. If the server | |||
wishes to negotiate with old clients, it will proceed as appropriate | wishes to negotiate with old clients, it will proceed as appropriate | |||
for the highest version supported by the server that is not greater | for the highest version supported by the server that is not greater | |||
than ClientHello.client_version. For example, if the server supports | than ClientHello.client_version. For example, if the server supports | |||
TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will | TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will | |||
proceed with a TLS 1.0 ServerHello. If server supports (or is willing | proceed with a TLS 1.0 ServerHello. If server supports (or is | |||
to use) only versions greater than client_version, it MUST send a | willing to use) only versions greater than client_version, it MUST | |||
"protocol_version" alert message and close the connection. | send a "protocol_version" alert message and close the connection. | |||
Whenever a client already knows the highest protocol version known to | Whenever a client already knows the highest protocol version known to | |||
a server (for example, when resuming a session), it SHOULD initiate | a server (for example, when resuming a session), it SHOULD initiate | |||
the connection in that native protocol. | the connection in that native protocol. | |||
Note: some server implementations are known to implement version | Note: some server implementations are known to implement version | |||
negotiation incorrectly. For example, there are buggy TLS 1.0 servers | negotiation incorrectly. For example, there are buggy TLS 1.0 | |||
that simply close the connection when the client offers a version | servers that simply close the connection when the client offers a | |||
newer than TLS 1.0. Also, it is known that some servers will refuse | version newer than TLS 1.0. Also, it is known that some servers will | |||
the connection if any TLS extensions are included in ClientHello. | refuse the connection if any TLS extensions are included in | |||
Interoperability with such buggy servers is a complex topic beyond | ClientHello. Interoperability with such buggy servers is a complex | |||
the scope of this document, and may require multiple connection | topic beyond the scope of this document, and may require multiple | |||
attempts by the client. | connection attempts by the client. | |||
Earlier versions of the TLS specification were not fully clear on | Earlier versions of the TLS specification were not fully clear on | |||
what the record layer version number (TLSPlaintext.version) should | what the record layer version number (TLSPlaintext.version) should | |||
contain when sending ClientHello (i.e., before it is known which | contain when sending ClientHello (i.e., before it is known which | |||
version of the protocol will be employed). Thus, TLS servers | version of the protocol will be employed). Thus, TLS servers | |||
compliant with this specification MUST accept any value {03,XX} as | compliant with this specification MUST accept any value {03,XX} as | |||
the record layer version number for ClientHello. | the record layer version number for ClientHello. | |||
TLS clients that wish to negotiate with older servers MAY send any | TLS clients that wish to negotiate with older servers MAY send any | |||
value {03,XX} as the record layer version number. Typical values | value {03,XX} as the record layer version number. Typical values | |||
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 | |||
contain the same version number as would be used for ordinary | MUST contain the same version number as would be used for ordinary | |||
ClientHello, and MUST encode the supported TLS cipher suites 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 | |||
still assumed to be [SSL2]. | still assumed to be [SSL2]. | |||
For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same | For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same | |||
way as a ClientHello with a "null" compression method and no | way as a ClientHello with a "null" compression method and no | |||
extensions. Note that this message MUST be sent directly on the wire, | extensions. Note that this message MUST be sent directly on the | |||
not wrapped as a TLS record. For the purposes of calculating Finished | wire, not wrapped as a TLS record. For the purposes of calculating | |||
and CertificateVerify, the msg_length field is not considered to be a | Finished and CertificateVerify, the msg_length field is not | |||
part of the handshake message. | considered to be a part of the handshake message. | |||
uint8 V2CipherSpec[3]; | uint8 V2CipherSpec[3]; | |||
struct { | struct { | |||
uint16 msg_length; | uint16 msg_length; | |||
uint8 msg_type; | uint8 msg_type; | |||
Version version; | Version version; | |||
uint16 cipher_spec_length; | uint16 cipher_spec_length; | |||
uint16 session_id_length; | uint16 session_id_length; | |||
uint16 challenge_length; | uint16 challenge_length; | |||
V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; | V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; | |||
opaque session_id[V2ClientHello.session_id_length]; | opaque session_id[V2ClientHello.session_id_length]; | |||
opaque challenge[V2ClientHello.challenge_length; | opaque challenge[V2ClientHello.challenge_length; | |||
} V2ClientHello; | } V2ClientHello; | |||
msg_length | msg_length | |||
The highest bit MUST be 1; the remaining bits contain the length | The highest bit MUST be 1; the remaining bits contain the length | |||
of the following data in bytes. | of the following data in bytes. | |||
msg_type | msg_type | |||
This field, in conjunction with the version field, identifies a | This field, in conjunction with the version field, identifies a | |||
version 2 client hello message. The value MUST be one (1). | version 2 ClientHello message. The value MUST be 1. | |||
version | version | |||
Equal to ClientHello.client_version. | Equal to ClientHello.client_version. | |||
cipher_spec_length | cipher_spec_length | |||
This field is the total length of the field cipher_specs. It | This field is the total length of the field cipher_specs. It | |||
cannot be zero and MUST be a multiple of the V2CipherSpec length | cannot be zero and MUST be a multiple of the V2CipherSpec length | |||
(3). | (3). | |||
session_id_length | session_id_length | |||
This field MUST have a value of zero for a client that claims to | This field MUST have a value of zero for a client that claims to | |||
support TLS 1.2. | support TLS 1.2. | |||
challenge_length | challenge_length | |||
The length in bytes of the client's challenge to the server to | The length in bytes of the client's challenge to the server to | |||
authenticate itself. Historically, permissible values are between | authenticate itself. Historically, permissible values are between | |||
16 and 32 bytes inclusive. When using the SSLv2 backward | 16 and 32 bytes inclusive. When using the SSLv2 backward- | |||
compatible handshake the client 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, with each cipher suite prefixed by a | |||
byte. For example, TLS cipher suite {0x00,0x0A} would be sent as | zero byte. For example, the TLS cipher suite {0x00,0x0A} would be | |||
{0x00,0x00,0x0A}. | sent as {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 | |||
than 32, the TLS server will pad the data with leading (note: not | less than 32, the TLS server will pad the data with leading (note: | |||
trailing) zero bytes to make it 32 bytes long. | not trailing) zero bytes to make it 32 bytes long. | |||
Note: Requests to resume a TLS session MUST use a TLS client hello. | Note: Requests to resume a TLS session MUST use a TLS client hello. | |||
E.3. Avoiding Man-in-the-Middle Version Rollback | E.3. Avoiding Man-in-the-Middle Version Rollback | |||
When TLS clients fall back to Version 2.0 compatibility mode, they | When TLS clients fall back to Version 2.0 compatibility mode, they | |||
MUST use special PKCS#1 block formatting. This is done so that TLS | MUST use special PKCS#1 block formatting. This is done so that TLS | |||
servers will reject Version 2.0 sessions with TLS-capable clients. | servers will reject Version 2.0 sessions with TLS-capable clients. | |||
When a client negotiates SSL 2.0 but also supports TLS, it MUST set | When a client negotiates SSL 2.0 but also supports TLS, it MUST set | |||
the right-hand (least-significant) 8 random bytes of the PKCS padding | the right-hand (least-significant) 8 random bytes of the PKCS padding | |||
(not including the terminal null of the padding) for the RSA | (not including the terminal null of the padding) for the RSA | |||
encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY | encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY | |||
to 0x03 (the other padding bytes are random). | to 0x03 (the other padding bytes are random). | |||
When a TLS-capable server negotiates SSL 2.0 it SHOULD, after | When a TLS-capable server negotiates SSL 2.0 it SHOULD, after | |||
decrypting the ENCRYPTED-KEY-DATA field, check that these eight | decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding | |||
padding bytes are 0x03. If they are not, the server SHOULD generate a | bytes are 0x03. If they are not, the server SHOULD generate a random | |||
random value for SECRET-KEY-DATA, and continue the handshake (which | value for SECRET-KEY-DATA, and continue the handshake (which will | |||
will eventually fail since the keys will not match). Note that | eventually fail since the keys will not match). Note that reporting | |||
reporting the error situation to the client could make the server | the error situation to the client could make the server vulnerable to | |||
vulnerable to attacks described in [BLEI]. | attacks described in [BLEI]. | |||
Appendix F. Security Analysis | Appendix F. Security Analysis | |||
The TLS protocol is designed to establish a secure connection between | The TLS protocol is designed to establish a secure connection between | |||
a client and a server communicating over an insecure channel. This | a client and a server communicating over an insecure channel. This | |||
document makes several traditional assumptions, including that | document makes several traditional assumptions, including that | |||
attackers have substantial computational resources and cannot obtain | attackers have substantial computational resources and cannot obtain | |||
secret information from sources outside the protocol. Attackers are | secret information from sources outside the protocol. Attackers are | |||
assumed to have the ability to capture, modify, delete, replay, and | assumed to have the ability to capture, modify, delete, replay, and | |||
otherwise tamper with messages sent over the communication channel. | otherwise tamper with messages sent over the communication channel. | |||
This appendix outlines how TLS has been designed to resist a variety | This appendix outlines how TLS has been designed to resist a variety | |||
of attacks. | of attacks. | |||
F.1. Handshake Protocol | F.1. Handshake Protocol | |||
The handshake protocol is responsible for selecting a CipherSpec and | The handshake protocol is responsible for selecting a cipher spec and | |||
generating a Master Secret, which together comprise the primary | generating a master secret, which together comprise the primary | |||
cryptographic parameters associated with a secure session. The | cryptographic parameters associated with a secure session. The | |||
handshake protocol can also optionally authenticate parties who have | handshake protocol can also optionally authenticate parties who have | |||
certificates signed by a trusted certificate authority. | certificates signed by a trusted certificate authority. | |||
F.1.1. Authentication and Key Exchange | F.1.1. Authentication and Key Exchange | |||
TLS supports three authentication modes: authentication of both | TLS supports three authentication modes: authentication of both | |||
parties, server authentication with an unauthenticated client, and | parties, server authentication with an unauthenticated client, and | |||
total anonymity. Whenever the server is authenticated, the channel is | total anonymity. Whenever the server is authenticated, the channel | |||
secure against man-in-the-middle attacks, but completely anonymous | is secure against man-in-the-middle attacks, but completely anonymous | |||
sessions are inherently vulnerable to such attacks. Anonymous | sessions are inherently vulnerable to such attacks. Anonymous | |||
servers cannot authenticate clients. If the server is authenticated, | servers cannot authenticate clients. If the server is authenticated, | |||
its certificate message must provide a valid certificate chain | its certificate message must provide a valid certificate chain | |||
leading to an acceptable certificate authority. Similarly, | leading to an acceptable certificate authority. Similarly, | |||
authenticated clients must supply an acceptable certificate to the | authenticated clients must supply an acceptable certificate to the | |||
server. Each party is responsible for verifying that the other's | server. Each party is responsible for verifying that the other's | |||
certificate is valid and has not expired or been revoked. | certificate is valid and has not expired or been revoked. | |||
The general goal of the key exchange process is to create a | The general goal of the key exchange process is to create a | |||
pre_master_secret known to the communicating parties and not to | pre_master_secret known to the communicating parties and not to | |||
attackers. The pre_master_secret will be used to generate the | attackers. The pre_master_secret will be used to generate the | |||
master_secret (see Section 8.1). The master_secret is required to | master_secret (see Section 8.1). The master_secret is required to | |||
generate the finished messages, encryption keys, and MAC keys (see | generate the Finished messages, encryption keys, and MAC keys (see | |||
Sections 7.4.9 and 6.3). By sending a correct finished message, | Sections 7.4.9 and 6.3). By sending a correct Finished message, | |||
parties thus prove that they know the correct pre_master_secret. | parties thus prove that they know the correct pre_master_secret. | |||
F.1.1.1. Anonymous Key Exchange | F.1.1.1. Anonymous Key Exchange | |||
Completely anonymous sessions can be established using Diffie-Hellman | Completely anonymous sessions can be established using Diffie-Hellman | |||
for key exchange. The server's public parameters are contained in the | for key exchange. The server's public parameters are contained in | |||
server key exchange message and the client's are sent in the client | the server key exchange message, and the client's are sent in the | |||
key exchange message. Eavesdroppers who do not know the private | client key exchange message. Eavesdroppers who do not know the | |||
values should not be able to find the Diffie-Hellman result (i.e. the | private values should not be able to find the Diffie-Hellman result | |||
pre_master_secret). | (i.e., the pre_master_secret). | |||
Warning: Completely anonymous connections only provide protection | Warning: Completely anonymous connections only provide protection | |||
against passive eavesdropping. Unless an independent tamper-proof | against passive eavesdropping. Unless an independent tamper-proof | |||
channel is used to verify that the finished messages were not | channel is used to verify that the Finished messages were not | |||
replaced by an attacker, server authentication is required in | replaced by an attacker, server authentication is required in | |||
environments where active man-in-the-middle attacks are a concern. | environments where active man-in-the-middle attacks are a concern. | |||
F.1.1.2. RSA Key Exchange and Authentication | F.1.1.2. RSA Key Exchange and Authentication | |||
With RSA, key exchange and server authentication are combined. The | With RSA, key exchange and server authentication are combined. The | |||
public key is contained in the server's certificate. Note that | public key is contained in the server's certificate. Note that | |||
compromise of the server's static RSA key results in a loss of | compromise of the server's static RSA key results in a loss of | |||
confidentiality for all sessions protected under that static key. TLS | confidentiality for all sessions protected under that static key. | |||
users desiring Perfect Forward Secrecy should use DHE cipher suites. | TLS users desiring Perfect Forward Secrecy should use DHE cipher | |||
The damage done by exposure of a private key can be limited by | suites. The damage done by exposure of a private key can be limited | |||
changing one's private key (and certificate) frequently. | by changing one's private key (and certificate) frequently. | |||
After verifying the server's certificate, the client encrypts a | After verifying the server's certificate, the client encrypts a | |||
pre_master_secret with the server's public key. By successfully | pre_master_secret with the server's public key. By successfully | |||
decoding the pre_master_secret and producing a correct finished | decoding the pre_master_secret and producing a correct Finished | |||
message, the server demonstrates that it knows the private key | message, the server demonstrates that it knows the private key | |||
corresponding to the server certificate. | corresponding to the server certificate. | |||
When RSA is used for key exchange, clients are authenticated using | When RSA is used for key exchange, clients are authenticated using | |||
the certificate verify message (see Section 7.4.8). The client signs | the certificate verify message (see Section 7.4.8). The client signs | |||
a value derived from all preceding handshake messages. These | a value derived from all preceding handshake messages. These | |||
handshake messages include the server certificate, which binds the | handshake messages include the server certificate, which binds the | |||
signature to the server, and ServerHello.random, which binds the | signature to the server, and ServerHello.random, which binds the | |||
signature to the current handshake process. | signature to the current handshake process. | |||
F.1.1.3. Diffie-Hellman Key Exchange with Authentication | F.1.1.3. Diffie-Hellman Key Exchange with Authentication | |||
When Diffie-Hellman key exchange is used, the server can either | When Diffie-Hellman key exchange is used, the server can either | |||
supply a certificate containing fixed Diffie-Hellman parameters or | supply a certificate containing fixed Diffie-Hellman parameters or | |||
use the server key exchange message to send a set of temporary | use the server key exchange message to send a set of temporary | |||
Diffie-Hellman parameters signed with a DSA or RSA certificate. | Diffie-Hellman parameters signed with a DSA or RSA certificate. | |||
Temporary parameters are hashed with the hello.random values before | Temporary parameters are hashed with the hello.random values before | |||
signing to ensure that attackers do not replay old parameters. In | signing to ensure that attackers do not replay old parameters. In | |||
either case, the client can verify the certificate or signature to | either case, the client can verify the certificate or signature to | |||
ensure that the parameters belong to the server. | ensure that the parameters belong to the server. | |||
If the client has a certificate containing fixed Diffie-Hellman | If the client has a certificate containing fixed Diffie-Hellman | |||
parameters, its certificate contains the information required to | parameters, its certificate contains the information required to | |||
complete the key exchange. Note that in this case the client and | complete the key exchange. Note that in this case the client and | |||
server will generate the same Diffie-Hellman result (i.e., | server will generate the same Diffie-Hellman result (i.e., | |||
pre_master_secret) every time they communicate. To prevent the | pre_master_secret) every time they communicate. To prevent the | |||
pre_master_secret from staying in memory any longer than necessary, | pre_master_secret from staying in memory any longer than necessary, | |||
it should be converted into the master_secret as soon as possible. | it should be converted into the master_secret as soon as possible. | |||
Client Diffie-Hellman parameters must be compatible with those | Client Diffie-Hellman parameters must be compatible with those | |||
supplied by the server for the key exchange to work. | supplied by the server for the key exchange to work. | |||
If the client has a standard DSA or RSA certificate or is | If the client has a standard DSA or RSA certificate or is | |||
unauthenticated, it sends a set of temporary parameters to the server | unauthenticated, it sends a set of temporary parameters to the server | |||
in the client key exchange message, then optionally uses a | in the client key exchange message, then optionally uses a | |||
certificate verify message to authenticate itself. | certificate verify message to authenticate itself. | |||
If the same DH keypair is to be used for multiple handshakes, either | If the same DH keypair is to be used for multiple handshakes, either | |||
because the client or server has a certificate containing a fixed DH | because the client or server has a certificate containing a fixed DH | |||
keypair or because the server is reusing DH keys, care must be taken | keypair or because the server is reusing DH keys, care must be taken | |||
to prevent small subgroup attacks. Implementations SHOULD follow the | to prevent small subgroup attacks. Implementations SHOULD follow the | |||
guidelines found in [SUBGROUP]. | guidelines found in [SUBGROUP]. | |||
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 cipher suites 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 | |||
computed very quickly, therefore the performance cost is minimized. | be computed very quickly; therefore, the performance cost is | |||
Additionally, using a fresh key for each handshake provides Perfect | minimized. Additionally, using a fresh key for each handshake | |||
Forward Secrecy. Implementations SHOULD generate a new X for each | provides Perfect Forward Secrecy. Implementations SHOULD generate a | |||
handshake when using DHE cipher suites. | new X for each 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. | |||
F.1.2. Version Rollback Attacks | F.1.2. Version Rollback Attacks | |||
Because TLS includes substantial improvements over SSL Version 2.0, | Because TLS includes substantial improvements over SSL Version 2.0, | |||
attackers may try to make TLS-capable clients and servers fall back | attackers may try to make TLS-capable clients and servers fall back | |||
to Version 2.0. This attack can occur if (and only if) two TLS- | to Version 2.0. This attack can occur if (and only if) two TLS- | |||
capable parties use an SSL 2.0 handshake. | capable parties use an SSL 2.0 handshake. | |||
Although the solution using non-random PKCS #1 block type 2 message | Although the solution using non-random PKCS #1 block type 2 message | |||
padding is inelegant, it provides a reasonably secure way for Version | padding is inelegant, it provides a reasonably secure way for Version | |||
3.0 servers to detect the attack. This solution is not secure against | 3.0 servers to detect the attack. This solution is not secure | |||
attackers who can brute force the key and substitute a new ENCRYPTED- | against attackers who can brute-force the key and substitute a new | |||
KEY-DATA message containing the same key (but with normal padding) | ENCRYPTED-KEY-DATA message containing the same key (but with normal | |||
before the application specified wait threshold has expired. Altering | padding) before the application-specified wait threshold has expired. | |||
the padding of the least significant 8 bytes of the PKCS padding does | Altering the padding of the least-significant 8 bytes of the PKCS | |||
not impact security for the size of the signed hashes and RSA key | padding does not impact security for the size of the signed hashes | |||
lengths used in the protocol, since this is essentially equivalent to | and RSA key lengths used in the protocol, since this is essentially | |||
increasing the input block size by 8 bytes. | equivalent to increasing the input block size by 8 bytes. | |||
F.1.3. Detecting Attacks Against the Handshake Protocol | F.1.3. Detecting Attacks Against the Handshake Protocol | |||
An attacker might try to influence the handshake exchange to make the | An attacker might try to influence the handshake exchange to make the | |||
parties select different encryption algorithms than they would | parties select different encryption algorithms than they would | |||
normally chooses. | normally choose. | |||
For this attack, an attacker must actively change one or more | For this attack, an attacker must actively change one or more | |||
handshake messages. If this occurs, the client and server will | handshake messages. If this occurs, the client and server will | |||
compute different values for the handshake message hashes. As a | compute different values for the handshake message hashes. As a | |||
result, the parties will not accept each others' finished messages. | result, the parties will not accept each others' Finished messages. | |||
Without the master_secret, the attacker cannot repair the finished | Without the master_secret, the attacker cannot repair the Finished | |||
messages, so the attack will be discovered. | messages, so the attack will be discovered. | |||
F.1.4. Resuming Sessions | F.1.4. Resuming Sessions | |||
When a connection is established by resuming a session, new | When a connection is established by resuming a session, new | |||
ClientHello.random and ServerHello.random values are hashed with the | ClientHello.random and ServerHello.random values are hashed with the | |||
session's master_secret. Provided that the master_secret has not been | session's master_secret. Provided that the master_secret has not | |||
compromised and that the secure hash operations used to produce the | been compromised and that the secure hash operations used to produce | |||
encryption keys and MAC keys are secure, the connection should be | the encryption keys and MAC keys are secure, the connection should be | |||
secure and effectively independent from previous connections. | secure and effectively independent from previous connections. | |||
Attackers cannot use known encryption keys or MAC secrets to | Attackers cannot use known encryption keys or MAC secrets to | |||
compromise the master_secret without breaking the secure hash | compromise the master_secret without breaking the secure hash | |||
operations. | operations. | |||
Sessions cannot be resumed unless both the client and server agree. | Sessions cannot be resumed unless both the client and server agree. | |||
If either party suspects that the session may have been compromised, | If either party suspects that the session may have been compromised, | |||
or that certificates may have expired or been revoked, it should | or that certificates may have expired or been revoked, it should | |||
force a full handshake. An upper limit of 24 hours is suggested for | force a full handshake. An upper limit of 24 hours is suggested for | |||
session ID lifetimes, since an attacker who obtains a master_secret | session ID lifetimes, since an attacker who obtains a master_secret | |||
may be able to impersonate the compromised party until the | may be able to impersonate the compromised party until the | |||
corresponding session ID is retired. Applications that may be run in | corresponding session ID is retired. Applications that may be run in | |||
relatively insecure environments should not write session IDs to | relatively insecure environments should not write session IDs to | |||
stable storage. | stable storage. | |||
F.2. Protecting Application Data | F.2. Protecting Application Data | |||
The master_secret is hashed with the ClientHello.random and | The master_secret is hashed with the ClientHello.random and | |||
ServerHello.random to produce unique data encryption keys and MAC | ServerHello.random to produce unique data encryption keys and MAC | |||
secrets for each connection. | secrets for each connection. | |||
Outgoing data is protected with a MAC before transmission. To prevent | Outgoing data is protected with a MAC before transmission. To | |||
message replay or modification attacks, the MAC is computed from the | prevent message replay or modification attacks, the MAC is computed | |||
MAC key, the sequence number, the message length, the message | from the MAC key, the sequence number, the message length, the | |||
contents, and two fixed character strings. The message type field is | message contents, and two fixed character strings. The message type | |||
necessary to ensure that messages intended for one TLS Record Layer | field is necessary to ensure that messages intended for one TLS | |||
client are not redirected to another. The sequence number ensures | record layer client are not redirected to another. The sequence | |||
that attempts to delete or reorder messages will be detected. Since | number ensures that attempts to delete or reorder messages will be | |||
sequence numbers are 64 bits long, they should never overflow. | detected. Since sequence numbers are 64 bits long, they should never | |||
Messages from one party cannot be inserted into the other's output, | overflow. Messages from one party cannot be inserted into the | |||
since they use independent MAC keys. Similarly, the server-write and | other's output, since they use independent MAC keys. Similarly, the | |||
client-write keys are independent, so stream cipher keys are used | server write and client write keys are independent, so stream cipher | |||
only once. | keys are used only once. | |||
If an attacker does break an encryption key, all messages encrypted | If an attacker does break an encryption key, all messages encrypted | |||
with it can be read. Similarly, compromise of a MAC key can make | with it can be read. Similarly, compromise of a MAC key can make | |||
message modification attacks possible. Because MACs are also | message-modification attacks possible. Because MACs are also | |||
encrypted, message-alteration attacks generally require breaking the | encrypted, message-alteration attacks generally require breaking the | |||
encryption algorithm as well as the MAC. | encryption algorithm as well as the MAC. | |||
Note: MAC keys may be larger than encryption keys, so messages can | Note: MAC keys may be larger than encryption keys, so messages can | |||
remain tamper resistant even if encryption keys are broken. | remain tamper resistant even if encryption keys are broken. | |||
F.3. Explicit IVs | F.3. Explicit IVs | |||
[CBCATT] describes a chosen plaintext attack on TLS that depends 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 | |||
cipher suite. 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 | |||
skipping to change at page 93, line 15 ¶ | skipping to change at page 96, line 17 ¶ | |||
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 cipher | confidentiality goal against an active attack. Therefore, new cipher | |||
suites and operation modes adopted into TLS need to be analyzed under | suites and operation modes adopted into TLS need to be analyzed under | |||
the authenticate-then-encrypt method to verify that they achieve the | the authenticate-then-encrypt method to verify that they 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 | pseudorandom generator and this pad is exclusive-ORed with the | |||
of plaintext and MAC tag. The other is the case of CBC mode using a | concatenation of plaintext and MAC tag. The other is the case of CBC | |||
secure block cipher. In this case, security can be shown if one | mode using a secure block cipher. In this case, security can be | |||
applies one CBC encryption pass to the concatenation of plaintext and | shown if one applies one CBC encryption pass to the concatenation of | |||
MAC and uses a new, independent, and unpredictable IV for each new | plaintext and MAC and uses a new, independent, and unpredictable IV | |||
pair of plaintext and MAC. In versions of TLS prior to 1.1, CBC mode | for each new pair of plaintext and MAC. In versions of TLS prior to | |||
was used properly EXCEPT that it used a predictable IV in the form of | 1.1, CBC mode was used properly EXCEPT that it used a predictable IV | |||
the last block of the previous ciphertext. This made TLS open to | in the form of the last block of the previous ciphertext. This made | |||
chosen plaintext attacks. This version of the protocol is immune to | TLS open to chosen plaintext attacks. This version of the protocol | |||
those attacks. For exact details in the encryption modes proven | is immune to those attacks. For exact details in the encryption | |||
secure, see [ENCAUTH]. | modes proven secure, see [ENCAUTH]. | |||
F.5 Denial of Service | F.5. Denial of Service | |||
TLS is susceptible to a number of denial of service (DoS) attacks. | TLS is susceptible to a number of denial-of-service (DoS) attacks. | |||
In particular, an attacker who initiates a large number of TCP | In particular, an attacker who initiates a large number of TCP | |||
connections can cause a server to consume large amounts of CPU doing | connections can cause a server to consume large amounts of CPU for | |||
RSA decryption. However, because TLS is generally used over TCP, it | doing RSA decryption. However, because TLS is generally used over | |||
is difficult for the attacker to hide his point of origin if proper | TCP, it is difficult for the attacker to hide his point of origin if | |||
TCP SYN randomization is used [SEQNUM] by the TCP stack. | proper TCP SYN randomization is used [SEQNUM] by the TCP stack. | |||
Because TLS runs over TCP, it is also susceptible to a number of | Because TLS runs over TCP, it is also susceptible to a number of DoS | |||
denial of service attacks on individual connections. In particular, | attacks on individual connections. In particular, attackers can | |||
attackers can forge RSTs, thereby terminating connections, or forge | forge RSTs, thereby terminating connections, or forge partial TLS | |||
partial TLS records, thereby causing the connection to stall. These | records, thereby causing the connection to stall. These attacks | |||
attacks cannot in general be defended against by a TCP-using | cannot in general be defended against by a TCP-using protocol. | |||
protocol. Implementors or users who are concerned with this class of | Implementors or users who are concerned with this class of attack | |||
attack should use IPsec AH [AH] or ESP [ESP]. | should use IPsec AH [AH] or ESP [ESP]. | |||
F.6 Final Notes | F.6. Final Notes | |||
For TLS to be able to provide a secure connection, both the client | For TLS to be able to provide a secure connection, both the client | |||
and server systems, keys, and applications must be secure. In | and server systems, keys, and applications must be secure. In | |||
addition, the implementation must be free of security errors. | addition, the implementation must be free of security errors. | |||
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 | ||||
[RFC Editor: Please delete this] | ||||
Clarified traffic analysis considerations | ||||
Added support for SHA-224 for signatures (though not for HMAC). | ||||
Consistent use of camelback style for references to messages (e.g., | ||||
ServerHelloDone) in the text. | ||||
Changed "DSS" to "DSA" where we are referring to the algorithm. | ||||
Extensive editorial revisions from Alfred Hoenes. | ||||
Normative References | Normative References | |||
[AES] National Institute of Standards and Technology, | [AES] National Institute of Standards and Technology, | |||
"Specification for the Advanced Encryption Standard (AES)" | "Specification for the Advanced Encryption Standard (AES)" | |||
FIPS 197. November 26, 2001. | FIPS 197. November 26, 2001. | |||
[3DES] National Institute of Standards and Technology, | [3DES] National Institute of Standards and Technology, | |||
"Recommendation for the Triple Data Encryption Algorithm | "Recommendation for the Triple Data Encryption Algorithm | |||
(TDEA) Block Cipher", NIST Special Publication 800-67, May | (TDEA) Block Cipher", NIST Special Publication 800-67, May | |||
2004. | 2004. | |||
[DSS] NIST FIPS PUB 186-2, "Digital Signature Standard", National | [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard", | |||
Institute of Standards and Technology, U.S. Department of | National Institute of Standards and Technology, U.S. | |||
Commerce, 2000. | Department of Commerce, 2000. | |||
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||
Hashing for Message Authentication", RFC 2104, February | Hashing for Message Authentication", RFC 2104, February | |||
1997. | 1997. | |||
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, | [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | |||
April 1992. | April 1992. | |||
[PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards | [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography | |||
(PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC | Standards (PKCS) #1: RSA Cryptography Specifications | |||
3447, February 2003. | Version 2.1", RFC 3447, February 2003. | |||
[PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 | [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet | |||
Public Key Infrastructure Certificate and Certificate | X.509 Public Key Infrastructure Certificate and | |||
Revocation List (CRL) Profile", RFC 3280, April 2002. | Certificate Revocation List (CRL) Profile", RFC 3280, | |||
April 2002. | ||||
[SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, | [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, | |||
and Source Code in C, 2nd ed.", Published by John Wiley & | and Source Code in C, 2nd ed.", Published by John Wiley & | |||
Sons, Inc. 1996. | Sons, Inc. 1996. | |||
[SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National | [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National | |||
Institute of Standards and Technology, U.S. Department of | Institute of Standards and Technology, U.S. Department of | |||
Commerce, August 2002. | Commerce, August 2002. | |||
[REQ] Bradner, S., "Key words for use in RFCs to Indicate | [REQ] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 25, RFC 2434, | IANA Considerations Section in RFCs", BCP 26, RFC 2434, | |||
October 1998. | October 1998. | |||
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, | [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, | |||
Information technology - Abstract Syntax Notation One | Information technology - Abstract Syntax Notation One | |||
(ASN.1): Specification of basic notation. | (ASN.1): Specification of basic notation. | |||
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, | [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, | |||
Information technology - ASN.1 encoding Rules: Specification | Information technology - ASN.1 encoding Rules: | |||
of Basic Encoding Rules (BER), Canonical Encoding Rules | Specification of Basic Encoding Rules (BER), Canonical | |||
(CER) and Distinguished Encoding Rules (DER). | Encoding Rules (CER) and Distinguished Encoding Rules | |||
(DER). | ||||
Informative References | Informative References | |||
[AEAD] Mcgrew, D., "An Interface and Algorithms for Authenticated | [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated | |||
Encryption", RFC 5116, January 2008. | Encryption", RFC 5116, January 2008. | |||
[AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC | [AH] Kent, S., "IP Authentication Header", RFC 4302, December | |||
4302, December 2005. | 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, | |||
1-12, 1998. | pages: 1-12, 1998. | |||
[CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: | [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: | |||
Problems and Countermeasures", | Problems and Countermeasures", | |||
http://www.openssl.org/~bodo/tls-cbc.txt. | http://www.openssl.org/~bodo/tls-cbc.txt. | |||
[CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, | [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, | |||
"Password Interception in a SSL/TLS Channel", Advances in | "Password Interception in a SSL/TLS Channel", Advances in | |||
Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003. | Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003. | |||
[CCM] "NIST Special Publication 800-38C: The CCM Mode for | [CCM] "NIST Special Publication 800-38C: The CCM Mode for | |||
Authentication and Confidentiality", | Authentication and Confidentiality", | |||
http://csrc.nist.gov/publications/nistpubs/800-38C/ | http://csrc.nist.gov/publications/nistpubs/800-38C/ | |||
SP800-38C.pdf | SP800-38C.pdf | |||
[DES] National Institute of Standards and Technology, "Data | [DES] National Institute of Standards and Technology, "Data | |||
Encryption Standard (DES)", FIPS PUB 46-3, October 1999. | Encryption Standard (DES)", FIPS PUB 46-3, October 1999. | |||
[DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard", | [DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard", | |||
National Institute of Standards and Technology, U.S. | National Institute of Standards and Technology, U.S. | |||
Department of Commerce, 2006. | Department of Commerce, 2006. | |||
[ECSDSA] American National Standards Institute, "Public Key | [ECDSA] American National Standards Institute, "Public Key | |||
Cryptography for the Financial Services Industry: The | Cryptography for the Financial Services Industry: The | |||
Elliptic Curve Digital Signature Algorithm (ECDSA)", ANS | Elliptic Curve Digital Signature Algorithm (ECDSA)", ANS | |||
X9.62-2005, November 2005. | X9.62-2005, November 2005. | |||
[ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication | [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication | |||
for Protecting Communications (Or: How Secure is SSL?)", | for Protecting Communications (Or: How Secure is SSL?)", | |||
Crypto 2001. | Crypto 2001. | |||
[ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security | [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC | |||
Payload (ESP)", RFC 4303, December 2005. | 4303, December 2005. | |||
[FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on | [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based | |||
implementation error", ietf-openpgp@imc.org mailing list, 27 | on implementation error", ietf-openpgp@imc.org mailing | |||
August 2006, http://www.imc.org/ietf-openpgp/mail- | list, 27 August 2006, http://www.imc.org/ietf-openpgp/ | |||
archive/msg14307.html. | mail-archive/msg14307.html. | |||
[GCM] "NIST Special Publication 800-38D DRAFT (June, 2007): | [GCM] Dworkin, M., NIST Special Publication 800-38D, | |||
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", November 2007. | |||
[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, | |||
2005. | December 2005. | |||
[KEYSIZ] Orman, H., and Hoffman, P., "Determining Strengths For | [KEYSIZ] Orman, H. and P. Hoffman, "Determining Strengths For | |||
Public Keys Used For Exchanging Symmetric Keys" RFC 3766, | Public Keys Used For Exchanging Symmetric Keys", BCP 86, | |||
April 2004. | RFC 3766, April 2004. | |||
[KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based | [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based | |||
Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, | Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, | |||
March 2003. | March 2003. | |||
[MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) | [MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) | |||
Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC | Diffie-Hellman groups for Internet Key Exchange (IKE)", | |||
3526, May 2003. | RFC 3526, May 2003. | |||
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax | [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate | |||
Standard", version 1.5, November 1993. | Syntax Standard", version 1.5, November 1993. | |||
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax | [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message | |||
Standard", version 1.5, November 1993. | Syntax 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, | |||
Requirements for Security", BCP 106, RFC 4086, June 2005. | "Randomness Requirements for Security", BCP 106, RFC 4086, | |||
June 2005. | ||||
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol | [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol | |||
Compression Methods", RFC 3749, May 2004. | Compression Methods", RFC 3749, May 2004. | |||
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., | [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., | |||
Wright, T., "Transport Layer Security (TLS) Extensions", RFC | and T. Wright, "Transport Layer Security (TLS) | |||
4366, April 2006. | Extensions", RFC 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 | |||
Communications of the ACM, v. 21, n. 2, Feb 1978, pp. | Cryptosystems", Communications of the ACM, v. 21, n. 2, | |||
120-126. | Feb 1978, pp. 120-126. | |||
[SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks", | [SEQNUM] Bellovin, S., "Defending Against Sequence Number Attacks", | |||
RFC 1948, May 1996. | RFC 1948, May 1996. | |||
[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications | [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications | |||
Corp., Feb 9, 1995. | Corp., Feb 9, 1995. | |||
[SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0 | [SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0 | |||
Protocol", Netscape Communications Corp., Nov 18, 1996. | Protocol", Netscape Communications Corp., Nov 18, 1996. | |||
[SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" | [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" | |||
Attacks on the Diffie-Hellman Key Agreement Method for | Attacks on the Diffie-Hellman Key Agreement Method for | |||
S/MIME", RFC 2785, March 2000. | S/MIME", RFC 2785, March 2000. | |||
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, | ||||
September 1981. | ||||
[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are | ||||
practical", USENIX Security Symposium 2003. | ||||
[TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites | ||||
for Transport Layer Security (TLS)", RFC 3268, June 2002. | ||||
[TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and | [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC | |||
Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher | 793, September 1981. | |||
Suites for Transport Layer Security (TLS)", RFC 4492, May | ||||
2006. | ||||
[TLSEXT] Eastlake, D.E., "Transport Layer Security (TLS) Extensions: | [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are | |||
Extension Definitions", January 2008, draft-ietf-tls- | practical", USENIX Security Symposium 2003. | |||
rfc4366-bis-01.txt. | ||||
[TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS | [TLSAES] Chown, P., "Advanced Encryption Standard (AES) | |||
authentication", RFC 5081, November 2007. | Ciphersuites for Transport Layer Security (TLS)", RFC | |||
3268, June 2002. | ||||
[TLSPSK] Eronen, P., Tschofenig, H., "Pre-Shared Key Ciphersuites for | [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. | |||
Transport Layer Security (TLS)", RFC 4279, December 2005. | Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites | |||
for Transport Layer Security (TLS)", RFC 4492, May 2006. | ||||
[TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0", | [TLSEXT] Eastlake, D., 3rd, "Transport Layer Security (TLS) | |||
RFC 2246, January 1999. | Extensions: Extension Definitions", Work in Progress, | |||
February 2008. | ||||
[TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version | [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport | |||
1.1", RFC 4346, April, 2006. | Layer Security (TLS) Authentication", RFC 5081, November | |||
2007. | ||||
[X501] ITU-T Recommendation X.501: Information Technology - Open | [TLSPSK] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key | |||
Systems Interconnection - The Directory: Models, 1993. | Ciphersuites for Transport Layer Security (TLS)", RFC | |||
4279, December 2005. | ||||
[XDR] Eisler, M., "External Data Representation Standard", STD 67, | [TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", | |||
RFC 4506, May 2006. | RFC 2246, January 1999. | |||
Credits | [TLS1.1] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
(TLS) Protocol Version 1.1", RFC 4346, April 2006. | ||||
Working Group Chairs | [X501] ITU-T Recommendation X.501: Information Technology - Open | |||
Systems Interconnection - The Directory: Models, 1993. | ||||
Eric Rescorla | [XDR] Eisler, M., Ed., "XDR: External Data Representation | |||
EMail: ekr@networkresonance.com | Standard", STD 67, RFC 4506, May 2006. | |||
Pasi Eronen | Working Group Information | |||
pasi.eronen@nokia.com | ||||
Editors | The discussion list for the IETF TLS working group is located at the | |||
e-mail address <tls@ietf.org>. Information on the group and | ||||
information on how to subscribe to the list is at | ||||
<https://www1.ietf.org/mailman/listinfo/tls> | ||||
Tim Dierks Eric Rescorla | Archives of the list can be found at: | |||
Independent Network Resonance, Inc. | <http://www.ietf.org/mail-archive/web/tls/current/index.html> | |||
EMail: tim@dierks.org EMail: ekr@networkresonance.com | ||||
Other contributors | Contributors | |||
Christopher Allen (co-editor of TLS 1.0) | Christopher Allen (co-editor of TLS 1.0) | |||
Alacrity Ventures | Alacrity Ventures | |||
ChristopherA@AlacrityManagement.com | ChristopherA@AlacrityManagement.com | |||
Martin Abadi | Martin Abadi | |||
University of California, Santa Cruz | University of California, Santa Cruz | |||
abadi@cs.ucsc.edu | abadi@cs.ucsc.edu | |||
Steven M. Bellovin | Steven M. Bellovin | |||
Columbia University | Columbia University | |||
smb@cs.columbia.edu | smb@cs.columbia.edu | |||
Simon Blake-Wilson | Simon Blake-Wilson | |||
BCI | BCI | |||
EMail: sblakewilson@bcisse.com | sblakewilson@bcisse.com | |||
Ran Canetti | Ran Canetti | |||
IBM | IBM | |||
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 | |||
skipping to change at page 99, line 39 ¶ | skipping to change at page 102, line 29 ¶ | |||
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 | david.hopwood@blueyonder.co.uk | |||
Phil Karlton (co-author of SSLv3) | Phil Karlton (co-author of SSLv3) | |||
Paul Kocher (co-author of SSLv3) | Paul Kocher (co-author of SSLv3) | |||
Cryptography Research | Cryptography Research | |||
paul@cryptography.com | paul@cryptography.com | |||
Hugo Krawczyk | Hugo Krawczyk | |||
IBM | IBM | |||
hugo@ee.technion.ac.il | hugo@ee.technion.ac.il | |||
Jan Mikkelsen | Jan Mikkelsen | |||
Transactionware | Transactionware | |||
EMail: janm@transactionware.com | janm@transactionware.com | |||
Magnus Nystrom | Magnus Nystrom | |||
RSA Security | RSA Security | |||
EMail: magnus@rsasecurity.com | magnus@rsasecurity.com | |||
Robert Relyea | Robert Relyea | |||
Netscape Communications | Netscape Communications | |||
relyea@netscape.com | relyea@netscape.com | |||
Jim Roskind | Jim Roskind | |||
Netscape Communications | Netscape Communications | |||
jar@netscape.com | jar@netscape.com | |||
Michael Sabin | Michael Sabin | |||
Dan Simon | Dan Simon | |||
Microsoft, Inc. | Microsoft, Inc. | |||
dansimon@microsoft.com | dansimon@microsoft.com | |||
skipping to change at page 100, line 29 ¶ | skipping to change at page 103, line 18 ¶ | |||
Michael Sabin | Michael Sabin | |||
Dan Simon | Dan Simon | |||
Microsoft, Inc. | Microsoft, Inc. | |||
dansimon@microsoft.com | dansimon@microsoft.com | |||
Tom Weinstein | Tom Weinstein | |||
Tim Wright | Tim Wright | |||
Vodafone | Vodafone | |||
EMail: timothy.wright@vodafone.com | timothy.wright@vodafone.com | |||
Comments | Editors' Addresses | |||
The discussion list for the IETF TLS working group is located at the | Tim Dierks | |||
e-mail address <tls@ietf.org>. Information on the group and | Independent | |||
information on how to subscribe to the list is at | EMail: tim@dierks.org | |||
<https://www1.ietf.org/mailman/listinfo/tls> | ||||
Archives of the list can be found at: | Eric Rescorla | |||
<http://www.ietf.org/mail-archive/web/tls/current/index.html> | RTFM, Inc. | |||
EMail: ekr@rtfm.com | ||||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The IETF Trust (2008). | 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 | |||
skipping to change at page 101, line 44 ¶ | skipping to change at line 4702 ¶ | |||
attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Acknowledgment | ||||
Funding for the RFC Editor function is provided by the IETF | ||||
Administrative Support Activity (IASA). | ||||
End of changes. 640 change blocks. | ||||
1399 lines changed or deleted | 1432 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |