| rfc4346.txt | draft-ietf-tls-rfc4346-bis-09.txt > | |||
|---|---|---|---|---|
| INTERNET-DRAFT Tim Dierks | ||||
| Network Working Group T. Dierks | Obsoletes (if approved): RFC 3268, 4346, 4366 Independent | |||
| Request for Comments: 4346 Independent | Updates (if approved): RFC 4492 Eric Rescorla | |||
| Obsoletes: 2246 E. Rescorla | Intended status: Proposed Standard Network Resonance, Inc. | |||
| Category: Standards Track RTFM, Inc. | <draft-ietf-tls-rfc4346-bis-09.txt> February 2008 (Expires August 2008) | |||
| April 2006 | ||||
| The Transport Layer Security (TLS) Protocol | The Transport Layer Security (TLS) Protocol | |||
| Version 1.1 | Version 1.2 | |||
| Status of This Memo | Status of this Memo | |||
| This document specifies an Internet standards track protocol for the | By submitting this Internet-Draft, each author represents that any | |||
| Internet community, and requests discussion and suggestions for | applicable patent or other IPR claims of which he or she is aware | |||
| improvements. Please refer to the current edition of the "Internet | have been or will be disclosed, and any of which he or she becomes | |||
| Official Protocol Standards" (STD 1) for the standardization state | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| and status of this protocol. Distribution of this memo is unlimited. | ||||
| 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 Notice | |||
| Copyright (C) The Internet Society (2006). | Copyright (C) The IETF Trust (2008). | |||
| Abstract | Abstract | |||
| This document specifies Version 1.1 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. Differences from TLS 1.0 ...................................5 | 1.1. Requirements Terminology 5 | |||
| 1.2. Requirements Terminology ...................................5 | 1.2. Major Differences from TLS 1.1 5 | |||
| 2. Goals ...........................................................5 | 2. Goals 6 | |||
| 3. Goals of This Document ..........................................6 | 3. Goals of This Document 7 | |||
| 4. Presentation Language ...........................................6 | 4. Presentation Language 7 | |||
| 4.1. Basic Block Size ...........................................7 | 4.1. Basic Block Size 7 | |||
| 4.2. Miscellaneous ..............................................7 | 4.2. Miscellaneous 7 | |||
| 4.3. Vectors ....................................................7 | 4.3. Vectors 8 | |||
| 4.4. Numbers ....................................................8 | 4.4. Numbers 9 | |||
| 4.5. Enumerateds ................................................8 | 4.5. Enumerateds 9 | |||
| 4.6. Constructed Types ..........................................9 | 4.6. Constructed Types 10 | |||
| 4.6.1. Variants ...........................................10 | 4.6.1. Variants 10 | |||
| 4.7. Cryptographic Attributes ..................................11 | 4.7. Cryptographic Attributes 11 | |||
| 4.8. Constants .................................................12 | 4.8. Constants 13 | |||
| 5. HMAC and the Pseudorandom Function .............................12 | 5. HMAC and the Pseudorandom Function 14 | |||
| 6. The TLS Record Protocol ........................................14 | 6. The TLS Record Protocol 15 | |||
| 6.1. Connection States .........................................15 | 6.1. Connection States 16 | |||
| 6.2. Record layer ..............................................17 | 6.2. Record layer 18 | |||
| 6.2.1. Fragmentation ......................................17 | 6.2.1. Fragmentation 19 | |||
| 6.2.2. Record Compression and Decompression ...............19 | 6.2.2. Record Compression and Decompression 20 | |||
| 6.2.3. Record Payload Protection ..........................19 | 6.2.3. Record Payload Protection 21 | |||
| 6.2.3.1. Null or Standard Stream Cipher ............20 | 6.2.3.1. Null or Standard Stream Cipher 21 | |||
| 6.2.3.2. CBC Block Cipher ..........................21 | 6.2.3.2. CBC Block Cipher 22 | |||
| 6.3. Key Calculation ...........................................24 | 6.2.3.3. AEAD ciphers 24 | |||
| 7. The TLS Handshaking Protocols ..................................24 | 6.3. Key Calculation 25 | |||
| 7.1. Change Cipher Spec Protocol ...............................25 | 7. The TLS Handshaking Protocols 26 | |||
| 7.2. Alert Protocol ............................................26 | 7.1. Change Cipher Spec Protocol 27 | |||
| 7.2.1. Closure Alerts .....................................27 | 7.2. Alert Protocol 27 | |||
| 7.2.2. Error Alerts .......................................28 | 7.2.1. Closure Alerts 28 | |||
| 7.3. Handshake Protocol Overview ...............................31 | 7.2.2. Error Alerts 29 | |||
| 7.4. Handshake Protocol ........................................34 | 7.3. Handshake Protocol Overview 33 | |||
| 7.4.1. Hello Messages .....................................35 | 7.4. Handshake Protocol 36 | |||
| 7.4.1.1. Hello request .............................35 | 7.4.1. Hello Messages 37 | |||
| 7.4.1.2. Client Hello ..............................36 | 7.4.1.1. Hello Request 37 | |||
| 7.4.1.3. Server Hello ..............................39 | 7.4.1.2. Client Hello 38 | |||
| 7.4.2. Server Certificate .................................40 | 7.4.1.3. Server Hello 41 | |||
| 7.4.3. Server Key Exchange Message ........................42 | 7.4.1.4 Hello Extensions 42 | |||
| 7.4.4. Certificate request ................................44 | 7.4.1.4.1 Signature Algorithms 43 | |||
| 7.4.5. Server Hello Done ..................................46 | 7.4.2. Server Certificate 45 | |||
| 7.4.6. Client certificate .................................46 | 7.4.3. Server Key Exchange Message 47 | |||
| 7.4.7. Client Key Exchange Message ........................47 | 7.4.4. Certificate Request 50 | |||
| 7.4.7.1. RSA Encrypted Premaster Secret Message ....47 | 7.4.5 Server hello done 51 | |||
| 7.4.7.2. Client Diffie-Hellman Public Value ........50 | 7.4.6. Client Certificate 52 | |||
| 7.4.8. Certificate verify .................................50 | 7.4.7. Client Key Exchange Message 54 | |||
| 7.4.9. Finished ...........................................51 | 7.4.7.1. RSA Encrypted Premaster Secret Message 54 | |||
| 7.4.7.2. Client Diffie-Hellman Public Value 57 | ||||
| 8. Cryptographic Computations .....................................52 | 7.4.8. Certificate verify 58 | |||
| 8.1. Computing the Master Secret ...............................52 | 7.4.9. Finished 58 | |||
| 8.1.1. RSA ................................................53 | 8. Cryptographic Computations 60 | |||
| 8.1.2. Diffie-Hellman .....................................53 | 8.1. Computing the Master Secret 60 | |||
| 9. Mandatory Cipher Suites ........................................53 | 8.1.1. RSA 61 | |||
| 10. Application Data Protocol .....................................53 | 8.1.2. Diffie-Hellman 61 | |||
| 11. Security Considerations .......................................53 | 9. Mandatory Cipher Suites 61 | |||
| 12. IANA Considerations ...........................................54 | 10. Application Data Protocol 61 | |||
| A. Appendix - Protocol constant values ............................55 | 11. Security Considerations 61 | |||
| A.1. Record layer .........................................55 | 12. IANA Considerations 61 | |||
| A.2. Change cipher specs message ..........................56 | A. Protocol Constant Values 64 | |||
| A.3. Alert messages .......................................56 | A.1. Record Layer 64 | |||
| A.4. Handshake protocol ...................................57 | A.2. Change Cipher Specs Message 65 | |||
| A.4.1. Hello messages .....................................57 | A.3. Alert Messages 65 | |||
| A.4.2. Server authentication and key exchange messages ....58 | A.4. Handshake Protocol 66 | |||
| A.4.3. Client authentication and key exchange messages ....59 | A.4.1. Hello Messages 66 | |||
| A.4.4.Handshake finalization message ......................60 | A.4.2. Server Authentication and Key Exchange Messages 68 | |||
| A.5. The CipherSuite ......................................60 | A.4.3. Client Authentication and Key Exchange Messages 69 | |||
| A.6. The Security Parameters ..............................63 | A.4.4. Handshake Finalization Message 70 | |||
| B. Appendix - Glossary ............................................64 | A.5. The Cipher Suite 70 | |||
| C. Appendix - CipherSuite definitions .............................68 | A.6. The Security Parameters 72 | |||
| D. Appendix - Implementation Notes ................................69 | A.7. Changes to RFC 4492 73 | |||
| D.1 Random Number Generation and Seeding ..................70 | B. Glossary 73 | |||
| D.2 Certificates and authentication .......................70 | C. Cipher Suite Definitions 78 | |||
| D.3 CipherSuites ..........................................70 | D. Implementation Notes 80 | |||
| E. Appendix - Backward Compatibility With SSL .....................71 | D.1 Random Number Generation and Seeding 80 | |||
| E.1. Version 2 client hello ...............................72 | D.2 Certificates and Authentication 80 | |||
| E.2. Avoiding man-in-the-middle version rollback ..........74 | D.3 Cipher Suites 80 | |||
| F. Appendix - Security analysis ...................................74 | D.4 Implementation Pitfalls 80 | |||
| F.1. Handshake protocol ...................................74 | E. Backward Compatibility 83 | |||
| F.1.1. Authentication and key exchange ....................74 | E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 83 | |||
| F.1.1.1. Anonymous key exchange ...........................75 | E.2 Compatibility with SSL 2.0 84 | |||
| F.1.1.2. RSA key exchange and authentication ..............75 | E.3. Avoiding Man-in-the-Middle Version Rollback 86 | |||
| F.1.1.3. Diffie-Hellman key exchange with authentication ..76 | F. Security Analysis 87 | |||
| F.1.2. Version rollback attacks ...........................77 | F.1. Handshake Protocol 87 | |||
| F.1.3. Detecting attacks against the handshake protocol ...77 | F.1.1. Authentication and Key Exchange 87 | |||
| F.1.4. Resuming sessions ..................................78 | F.1.1.1. Anonymous Key Exchange 87 | |||
| F.1.5. MD5 and SHA ........................................78 | F.1.1.2. RSA Key Exchange and Authentication 88 | |||
| F.2. Protecting application data ..........................78 | F.1.1.3. Diffie-Hellman Key Exchange with Authentication 88 | |||
| F.3. Explicit IVs .........................................79 | F.1.2. Version Rollback Attacks 89 | |||
| F.4 Security of Composite Cipher Modes ...................79 | F.1.3. Detecting Attacks Against the Handshake Protocol 90 | |||
| F.5 Denial of Service ....................................80 | F.1.4. Resuming Sessions 90 | |||
| F.6. Final notes ..........................................80 | F.2. Protecting Application Data 90 | |||
| Normative References ..............................................81 | F.3. Explicit IVs 91 | |||
| Informative References ............................................82 | F.4. Security of Composite Cipher Modes 91 | |||
| F.5 Denial of Service 92 | ||||
| F.6 Final Notes 92 | ||||
| 1. Introduction | 1. Introduction | |||
| The primary goal of the TLS Protocol is to provide privacy and data | The primary goal of the TLS Protocol is to provide privacy and data | |||
| integrity between two communicating applications. The protocol is | integrity between two communicating applications. The protocol is | |||
| composed of two layers: the TLS Record Protocol and the TLS Handshake | composed of two layers: the TLS Record Protocol and the TLS Handshake | |||
| Protocol. At the lowest level, layered on top of some reliable | Protocol. At the lowest level, layered on top of some reliable | |||
| transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The | transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The | |||
| TLS Record Protocol provides connection security that has two basic | TLS Record Protocol provides connection security that has two basic | |||
| properties: | properties: | |||
| - The connection is private. Symmetric cryptography is used for | - The connection is private. Symmetric cryptography is used for | |||
| data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for | data encryption (e.g., DES [DES], 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 (such as the TLS Handshake Protocol). The Record Protocol | |||
| Protocol can also be used without encryption. | can also be used without encryption. | |||
| - The connection is reliable. Message transport includes a message | - The connection is reliable. Message transport includes a message | |||
| integrity check using a keyed MAC. Secure hash functions (e.g., | integrity check using a keyed MAC. Secure hash functions (e.g., | |||
| SHA, MD5, etc.) are used for MAC computations. The Record | SHA, MD5, etc.) are used for MAC computations. The Record Protocol | |||
| Protocol can operate without a MAC, but is generally only used in | can operate without a MAC, but is generally only used in this mode | |||
| this mode while another protocol is using the Record Protocol as a | while another protocol is using the Record Protocol as a transport | |||
| transport for negotiating security parameters. | for negotiating security parameters. | |||
| The TLS Record Protocol is used for encapsulation of various higher- | The TLS Record Protocol is used for encapsulation of various higher- | |||
| level protocols. One such encapsulated protocol, the TLS Handshake | level protocols. One such encapsulated protocol, the TLS Handshake | |||
| Protocol, allows the server and client to authenticate each other and | Protocol, allows the server and client to authenticate each other and | |||
| to negotiate an encryption algorithm and cryptographic keys before | to negotiate an encryption algorithm and cryptographic keys before | |||
| the application protocol transmits or receives its first byte of | the application protocol transmits or receives its first byte of | |||
| data. The TLS Handshake Protocol provides connection security that | data. The TLS Handshake Protocol provides connection security that | |||
| has three basic properties: | has three basic properties: | |||
| - The peer's identity can be authenticated using asymmetric, or | - The peer's identity can be authenticated using asymmetric, or | |||
| public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This | public key, cryptography (e.g., RSA [RSA], DSS [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. Differences from TLS 1.0 | 1.1. Requirements Terminology | |||
| This document is a revision of the TLS 1.0 [TLS1.0] protocol, and | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| contains some small security improvements, clarifications, and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| editorial improvements. The major changes are: | document are to be interpreted as described in RFC 2119 [REQ]. | |||
| - The implicit Initialization Vector (IV) is replaced with an | 1.2. Major Differences from TLS 1.1 | |||
| explicit IV to protect against CBC attacks [CBCATT]. | ||||
| - Handling of padding errors is changed to use the bad_record_mac | This document is a revision of the TLS 1.1 [TLS1.1] protocol which | |||
| alert rather than the decryption_failed alert to protect against | contains improved flexibility, particularly for negotiation of | |||
| CBC attacks. | cryptographic algorithms. The major changes are: | |||
| - IANA registries are defined for protocol parameters. | - The MD5/SHA-1 combination in the PRF has been replaced with cipher | |||
| suite specified PRFs. All cipher suites in this document use | ||||
| P_SHA256. | ||||
| - Premature closes no longer cause a session to be nonresumable. | - The MD5/SHA-1 combination in the digitally-signed element has been | |||
| replaced with a single hash. Signed elements now include a field | ||||
| that explicitly specifies the hash algorithm used. | ||||
| - Additional informational notes were added for various new attacks | - Substantial cleanup to the clients and servers ability to specify | |||
| on TLS. | which hash and signature algorithms they will accept. Note that | |||
| this also relaxes some of the constraints on signature and hash | ||||
| algorithms from previous versions of TLS. | ||||
| In addition, a number of minor clarifications and editorial | - Addition of support for authenticated encryption with additional | |||
| improvements were made. | data modes. | |||
| 1.2. Requirements Terminology | - TLS Extensions definition and AES Cipher Suites were merged in | |||
| from external [TLSEXT] and [TLSAES]. | ||||
| In this document, the keywords "MUST", "MUST NOT", "REQUIRED", | - Tighter checking of EncryptedPreMasterSecret version numbers. | |||
| "SHOULD", "SHOULD NOT" and "MAY" are to be interpreted as described | ||||
| in RFC 2119 [REQ]. | - Tightened up a number of requirements. | |||
| - Verify_data length now depends on the cipher suite (default is | ||||
| still 12). | ||||
| - Cleaned up description of Bleichenbacher/Klima attack defenses. | ||||
| - Alerts MUST now be sent in many cases. | ||||
| - After a certificate_request, if no certificates are available, | ||||
| clients now MUST send an empty certificate list. | ||||
| - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement | ||||
| cipher suite. | ||||
| - Added HMAC-SHA256 cipher suites | ||||
| - Removed IDEA and DES cipher suites. They are now deprecated and | ||||
| will be documented in a separate document. | ||||
| - Support for the SSLv2 backward-compatible hello is now a MAY, not | ||||
| a SHOULD, with sending it a SHOULD not. Support will probably | ||||
| become a SHOULD NOT in the future. | ||||
| - Added limited "fall-through" to the presentation language to allow | ||||
| multiple case arms to have the same encoding. | ||||
| - Added an Implementation Pitfalls sections | ||||
| - The usual clarifications and editorial work. | ||||
| 2. Goals | 2. Goals | |||
| The goals of TLS Protocol, in order of their priority, are as | The goals of TLS Protocol, in order of their priority, are as | |||
| follows: | follows: | |||
| 1. Cryptographic security: TLS should be used to establish a secure | 1. Cryptographic security: TLS should be used to establish a secure | |||
| connection between two parties. | connection between two parties. | |||
| 2. Interoperability: Independent programmers should be able to | 2. Interoperability: Independent programmers should be able to | |||
| develop applications utilizing TLS that can successfully exchange | develop applications utilizing TLS that can successfully exchange | |||
| 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 | necessary. This will also accomplish two sub-goals: preventing the | |||
| the need to create a new protocol (and risking the introduction of | 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 TLS 1.1, TLS 1.0, and SSL 3.0 do not | significant enough that the various versions of TLS and SSL 3.0 do | |||
| interoperate (although each protocol incorporates a mechanism by | not interoperate (although each protocol incorporates a mechanism by | |||
| which an implementation can back down prior versions). This document | which an implementation can back down to prior versions). This | |||
| is intended primarily for readers who will be implementing the | document is intended primarily for readers who will be implementing | |||
| 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 bytestream, 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 | |||
| skipping to change at page 7, line 32 ¶ | skipping to change at page 8, line 15 ¶ | |||
| 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. | between 300 and 400 bytes of type opaque. It can never be empty. The | |||
| The actual length field consumes two bytes, a uint16, sufficient to | actual length field consumes two bytes, a uint16, sufficient to | |||
| represent the value 400 (see Section 4.4). On the other hand, longer | represent the value 400 (see Section 4.4). On the other hand, longer | |||
| can represent up to 800 bytes of data, or 400 uint16 elements, and it | can represent up to 800 bytes of data, or 400 uint16 elements, and it | |||
| may be empty. Its encoding will include a two-byte actual length | may be empty. Its encoding will include a two-byte actual length | |||
| field prepended to the vector. The length of an encoded vector must | field prepended to the vector. The length of an encoded vector must | |||
| be an even multiple of the length of a single element (for example, a | be an even multiple of the length of a single element (for example, a | |||
| 17-byte vector of uint16 would be illegal). | 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" or "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 | ||||
| represent integers as opaque vectors. In such cases, they are | ||||
| represented as unsigned integers (i.e., leading zero octets are not | ||||
| 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 | type may be assigned or compared. Every element of an enumerated must | |||
| must be assigned a value, as demonstrated in the following example. | be assigned a value, as demonstrated in the following example. Since | |||
| Since the elements of the enumerated are not ordered, they can be | the elements of the enumerated are not ordered, they can be assigned | |||
| assigned any unique value, in any order. | 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 | Enumerateds occupy 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. The body of the variant structure may be given a label | the select. Case arms have limited fall-through: if two case arms | |||
| for reference. The mechanism by which the variant is selected at | follow in immediate succession with no fields in between, then they | |||
| runtime is not prescribed by the presentation language. | both contain the same fields. Thus, in the example below, "orange" | |||
| and "banana" both contain V2. Note that this is a new piece of syntax | ||||
| in TLS 1.2. | ||||
| struct { | The body of the variant structure may be given a label for reference. | |||
| T1 f1; | The mechanism by which the variant is selected at runtime is not | |||
| T2 f2; | prescribed by the presentation language. | |||
| .... | ||||
| Tn fn; | struct { | |||
| T1 f1; | ||||
| T2 f2; | ||||
| .... | ||||
| Tn fn; | ||||
| select (E) { | select (E) { | |||
| case e1: Te1; | case e1: Te1; | |||
| case e2: Te2; | case e2: Te2; | |||
| case e3: case e4: Te3; | ||||
| .... | .... | |||
| case en: Ten; | case en: Ten; | |||
| } [[fv]]; | } [[fv]]; | |||
| } [[Tv]]; | } [[Tv]]; | |||
| For example: | For example: | |||
| enum { apple, orange } VariantTag; | enum { apple, orange, banana } VariantTag; | |||
| struct { | ||||
| uint16 number; | ||||
| opaque string<0..10>; /* variable length */ | ||||
| } V1; | ||||
| struct { | ||||
| uint32 number; | ||||
| opaque string[10]; /* fixed length */ | ||||
| } V2; | ||||
| struct { | ||||
| select (VariantTag) { /* value of selector is implicit */ | ||||
| case apple: V1; /* VariantBody, tag = apple */ | ||||
| case orange: V2; /* VariantBody, tag = orange */ | ||||
| } variant_body; /* optional label on variant */ | ||||
| } VariantRecord; | ||||
| Variant structures may be qualified (narrowed) by specifying a value | struct { | |||
| for the selector prior to the type. For example, an | uint16 number; | |||
| opaque string<0..10>; /* variable length */ | ||||
| } V1; | ||||
| orange VariantRecord | struct { | |||
| uint32 number; | ||||
| opaque string[10]; /* fixed length */ | ||||
| } V2; | ||||
| is a narrowed type of a VariantRecord containing a variant_body of | struct { | |||
| type V2. | select (VariantTag) { /* value of selector is implicit */ | |||
| case apple: | ||||
| V1; /* VariantBody, tag = apple */ | ||||
| case orange: | ||||
| case banana: | ||||
| V2; /* VariantBody, tag = orange or banana */ | ||||
| } variant_body; /* optional label on variant */ | ||||
| } VariantRecord; | ||||
| 4.7. Cryptographic Attributes | 4.7. Cryptographic Attributes | |||
| The four cryptographic operations digital signing, stream cipher | The five cryptographic operations digital signing, stream cipher | |||
| encryption, block cipher encryption, and public key encryption are | encryption, block cipher encryption, authenticated encryption with | |||
| designated digitally-signed, stream-ciphered, block-ciphered, and | additional data (AEAD) encryption and public key encryption are | |||
| public-key-encrypted, respectively. A field's cryptographic | designated digitally-signed, stream-ciphered, block-ciphered, aead- | |||
| processing is specified by prepending an appropriate key word | ciphered, and public-key-encrypted, respectively. A field's | |||
| designation before the field's type specification. Cryptographic | cryptographic processing is specified by prepending an appropriate | |||
| keys are implied by the current session state (see Section 6.1). | key word designation before the field's type specification. | |||
| Cryptographic keys are implied by the current session state (see | ||||
| Section 6.1). | ||||
| In digital signing, one-way hash functions are used as input for a | A digitally-signed element is encoded as a struct DigitallySigned: | |||
| signing algorithm. A digitally-signed element is encoded as an | ||||
| opaque vector <0..2^16-1>, where the length is specified by the | ||||
| signing algorithm and key. | ||||
| In RSA signing, a 36-byte structure of two hashes (one SHA and one | struct { | |||
| MD5) is signed (encrypted with the private key). It is encoded with | SignatureAndHashAlgorithm algorithm; | |||
| PKCS #1 block type 1, as described in [PKCS1A]. | opaque signature<0..2^16-1>; | |||
| } DigitallySigned; | ||||
| Note: The standard reference for PKCS#1 is now RFC 3447 [PKCS1B]. | The algorithm field specifies the algorithm used (see Section | |||
| However, to minimize differences with TLS 1.0 text, we are | 7.4.1.4.1 for the definition of this field.) Note that the | |||
| using the terminology of RFC 2313 [PKCS1A]. | introduction of the algorithm field is a change from previous | |||
| versions. The signature is a digital signature using those | ||||
| algorithms over the contents of the element. The contents themselves | ||||
| do not appear on the wire but are simply calculated. The length of | ||||
| the signature is specified by the signing algorithm and key. | ||||
| In DSS, the 20 bytes of the SHA hash are run directly through the | In RSA signing, the opaque vector contains the signature generated | |||
| Digital Signing Algorithm with no additional hashing. This produces | using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As | |||
| two values, r and s. The DSS signature is an opaque vector, as | discussed in [PKCS1], the DigestInfo MUST be DER encoded and for hash | |||
| above, the contents of which are the DER encoding of: | algorithms without parameters (which include SHA-1) the | |||
| DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but | ||||
| implementations MUST accept both without parameters and with NULL | ||||
| parameters. Note that earlier versions of TLS used a different RSA | ||||
| signature scheme which did not include a DigestInfo encoding. | ||||
| Dss-Sig-Value ::= SEQUENCE { | In DSS, the 20 bytes of the SHA-1 hash are run directly through the | |||
| r INTEGER, | Digital Signing Algorithm with no additional hashing. This produces | |||
| s INTEGER | two values, r and s. The DSS signature is an opaque vector, as above, | |||
| } | the contents of which are the DER encoding of: | |||
| Dss-Sig-Value ::= SEQUENCE { | ||||
| r INTEGER, | ||||
| s INTEGER | ||||
| } | ||||
| Note: In current terminology, DSA refers to the Digital Signature | ||||
| Algorithm and DSS refers to the NIST standard. For historical | ||||
| reasons, this document uses DSS and DSA interchangeably | ||||
| to refer to the DSA algorithm, as was done in SSLv3. | ||||
| In stream cipher encryption, the plaintext is exclusive-ORed with an | In stream cipher encryption, the plaintext is exclusive-ORed with an | |||
| identical amount of output generated from a cryptographically secure | identical amount of output generated from a cryptographically secure | |||
| keyed pseudorandom number generator. | keyed pseudorandom number generator. | |||
| In block cipher encryption, every block of plaintext encrypts to a | In block cipher encryption, every block of plaintext encrypts to a | |||
| block of ciphertext. All block cipher encryption is done in CBC | block of ciphertext. All block cipher encryption is done in CBC | |||
| (Cipher Block Chaining) mode, and all items that are block-ciphered | (Cipher Block Chaining) mode, and all items that are block-ciphered | |||
| will be an exact multiple of the cipher block length. | will be an exact multiple of the cipher block length. | |||
| In AEAD encryption, the plaintext is simultaneously encrypted and | ||||
| integrity protected. The input may be of any length and aead-ciphered | ||||
| output is generally larger than the input in order to accomodate 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 signing | vector <0..2^16-1>, where the length is specified by the encryption | |||
| algorithm and key. | algorithm and key. | |||
| An RSA-encrypted value is encoded with PKCS #1 block type 2, as | RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme | |||
| described in [PKCS1A]. | defined in [PKCS1]. | |||
| In the following example, | In the following example | |||
| stream-ciphered struct { | stream-ciphered struct { | |||
| uint8 field1; | uint8 field1; | |||
| uint8 field2; | uint8 field2; | |||
| digitally-signed opaque hash[20]; | digitally-signed opaque { | |||
| } UserType; | uint8 field3<0..255>; | |||
| uint8 field4; | ||||
| }; | ||||
| } UserType; | ||||
| the contents of hash are used as input for the signing algorithm, and | The contents of the inner struct (field3 and field4) are used as | |||
| then the entire structure is encrypted with a stream cipher. The | input for the signature/hash algorithm, and then the entire structure | |||
| length of this structure, in bytes, would be equal to two bytes for | is encrypted with a stream cipher. The length of this structure, in | |||
| field1 and field2, plus two bytes for the length of the signature, | bytes, would be equal to two bytes for field1 and field2, plus two | |||
| plus the length of the output of the signing algorithm. This is | bytes for the signature and hash algorithm, plus two bytes for the | |||
| known because the algorithm and key used for the signing are known | length of the signature, plus the length of the output of the signing | |||
| prior to encoding or decoding this structure. | algorithm. This is known because the algorithm and key used for the | |||
| signing are known prior to encoding or decoding this structure. | ||||
| 4.8. Constants | 4.8. Constants | |||
| Typed constants can be defined for purposes of specification by | Typed constants can be defined for purposes of specification by | |||
| declaring a symbol of the desired type and assigning values to it. | declaring a symbol of the desired type and assigning values to it. | |||
| Under-specified types (opaque, variable length vectors, and | Under-specified types (opaque, variable length vectors, and | |||
| structures that contain opaque) cannot be assigned values. No fields | structures that contain opaque) cannot be assigned values. No fields | |||
| of a multi-element structure or vector may be elided. | of a multi-element structure or vector may be elided. | |||
| For example: | For example: | |||
| 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 | |||
| A number of operations in the TLS record and handshake layer require | The TLS record layer uses a keyed Message Authentication Code (MAC) | |||
| a keyed MAC; this is a secure digest of some data protected by a | to protect message integrity. The cipher suites defined in this | |||
| secret. Forging the MAC is infeasible without knowledge of the MAC | document use a construction known as HMAC, described in [HMAC], which | |||
| secret. The construction we use for this operation is known as HMAC, | is based on a hash function. Other cipher suites MAY define their own | |||
| and is described in [HMAC]. | MAC constructions, if needed. | |||
| HMAC can be used with a variety of different hash algorithms. TLS | ||||
| uses it in the handshake with two different algorithms, MD5 and SHA- | ||||
| 1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret, | ||||
| data). Additional hash algorithms can be defined by cipher suites | ||||
| and used to protect record data, but MD5 and SHA-1 are hard coded | ||||
| into the description of the handshaking for this version of the | ||||
| protocol. | ||||
| In addition, a construction is required to do expansion of secrets | In addition, a construction is required to do expansion of secrets | |||
| into blocks of data for the purposes of key generation or validation. | into blocks of data for the purposes of key generation or validation. | |||
| This pseudo-random function (PRF) takes as input a secret, a seed, | This pseudo-random function (PRF) takes as input a secret, a seed, | |||
| and an identifying label and produces an output of arbitrary length. | and an identifying label and produces an output of arbitrary length. | |||
| In order to make the PRF as secure as possible, it uses two hash | In this section, we define one PRF, based on HMAC. This PRF with the | |||
| algorithms in a way that should guarantee its security if either | SHA-256 hash function is used for all cipher suites defined in this | |||
| algorithm remains secure. | document and in TLS documents published prior to this document when | |||
| 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 | ||||
| standard hash function. | ||||
| First, we define a data expansion function, P_hash(secret, data) that | First, we define a data expansion function, P_hash(secret, data) that | |||
| uses a single hash function to expand a secret and seed into an | uses a single hash function to expand a secret and seed into an | |||
| arbitrary quantity of output: | arbitrary quantity of output: | |||
| P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + | P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + | |||
| HMAC_hash(secret, A(2) + seed) + | HMAC_hash(secret, A(2) + seed) + | |||
| HMAC_hash(secret, A(3) + seed) + ... | HMAC_hash(secret, A(3) + seed) + ... | |||
| Where + indicates concatenation. | Where + indicates concatenation. | |||
| A() is defined as: | A() is defined as: | |||
| A(0) = seed | A(0) = seed | |||
| A(i) = HMAC_hash(secret, A(i-1)) | A(i) = HMAC_hash(secret, A(i-1)) | |||
| P_hash can be iterated as many times as is necessary to produce the | P_hash can be iterated as many times as is necessary to produce the | |||
| required quantity of data. For example, if P_SHA-1 is being used to | required quantity of data. For example, if P_SHA256 is being used to | |||
| create 64 bytes of data, it will have to be iterated 4 times (through | create 80 bytes of data, it will have to be iterated three times | |||
| A(4)), creating 80 bytes of output data; the last 16 bytes of the | (through A(3)), creating 96 bytes of output data; the last 16 bytes | |||
| final iteration will then be discarded, leaving 64 bytes of output | of the final iteration will then be discarded, leaving 80 bytes of | |||
| data. | output data. | |||
| TLS's PRF is created by splitting the secret into two halves and | ||||
| using one half to generate data with P_MD5 and the other half to | ||||
| generate data with P_SHA-1, then exclusive-ORing the outputs of these | ||||
| two expansion functions together. | ||||
| S1 and S2 are the two halves of the secret, and each is the same | ||||
| length. S1 is taken from the first half of the secret, S2 from the | ||||
| second half. Their length is created by rounding up the length of | ||||
| the overall secret, divided by two; thus, if the original secret is | ||||
| an odd number of bytes long, the last byte of S1 will be the same as | ||||
| the first byte of S2. | ||||
| L_S = length in bytes of secret; | ||||
| L_S1 = L_S2 = ceil(L_S / 2); | ||||
| The secret is partitioned into two halves (with the possibility of | ||||
| one shared byte) as described above, S1 taking the first L_S1 bytes, | ||||
| and S2 the last L_S2 bytes. | ||||
| The PRF is then defined as the result of mixing the two pseudorandom | ||||
| streams by exclusive-ORing them together. | ||||
| PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR | TLS's PRF is created by applying P_hash to the secret as: | |||
| P_SHA-1(S2, label + seed); | ||||
| The label is an ASCII string. It should be included in the exact | PRF(secret, label, seed) = P_<hash>(secret, label + seed) | |||
| form it is given without a length byte or trailing null character. | ||||
| For example, the label "slithy toves" would be processed by hashing | ||||
| the following bytes: | ||||
| 73 6C 69 74 68 79 20 74 6F 76 65 73 | The label is an ASCII string. It should be included in the exact form | |||
| it is given without a length byte or trailing null character. For | ||||
| example, the label "slithy toves" would be processed by hashing the | ||||
| following bytes: | ||||
| Note that because MD5 produces 16-byte outputs and SHA-1 produces | 73 6C 69 74 68 79 20 74 6F 76 65 73 | |||
| 20-byte outputs, the boundaries of their internal iterations will not | ||||
| be aligned. Generating an 80-byte output will require that P_MD5 | ||||
| iterate through A(5), while P_SHA-1 will only iterate through A(4). | ||||
| 6. The TLS Record Protocol | 6. The TLS Record Protocol | |||
| The TLS Record Protocol is a layered protocol. At each layer, | The TLS Record Protocol is a layered protocol. At each layer, | |||
| messages may include fields for length, description, and content. | messages may include fields for length, description, and content. | |||
| The Record Protocol takes messages to be transmitted, fragments the | The Record Protocol takes messages to be transmitted, fragments the | |||
| data into manageable blocks, optionally compresses the data, applies | data into manageable blocks, optionally compresses the data, applies | |||
| a MAC, encrypts, and transmits the result. Received data is | a MAC, encrypts, and transmits the result. Received data is | |||
| decrypted, verified, decompressed, reassembled, and then delivered to | decrypted, verified, decompressed, reassembled, and then delivered to | |||
| higher-level clients. | higher-level clients. | |||
| Four record protocol clients are described in this document: the | Four record protocol clients are described in this document: the | |||
| handshake protocol, the alert protocol, the change cipher spec | handshake protocol, the alert protocol, the change cipher spec | |||
| protocol, and the application data protocol. In order to allow | protocol, and the application data protocol. In order to allow | |||
| extension of the TLS protocol, additional record types can be | extension of the TLS protocol, additional record types can be | |||
| supported by the record protocol. Any new record types SHOULD | supported by the record protocol. New record type values are assigned | |||
| allocate type values immediately beyond the ContentType values for | by IANA as described in Section 12. | |||
| the four record types described here (see Appendix A.1). All such | ||||
| values must be defined by RFC 2434 Standards Action. See Section 11 | ||||
| for IANA Considerations for ContentType values. | ||||
| If a TLS implementation receives a record type it does not | Implementations MUST NOT send record types not defined in this | |||
| understand, it SHOULD just ignore it. Any protocol designed for use | document unless negotiated by some extension. If a TLS | |||
| over TLS MUST be carefully designed to deal with all possible attacks | implementation receives an unexpected record type, it MUST send an | |||
| against it. Note that because the type and length of a record are | unexpected_message alert. | |||
| not protected by encryption, care SHOULD be taken to minimize the | ||||
| value of traffic analysis of these values. | Any protocol designed for use over TLS MUST be carefully designed to | |||
| deal with all possible attacks against it. Note that because the | ||||
| type and length of a record are not protected by encryption, care | ||||
| SHOULD be taken to minimize the value of traffic analysis of these | ||||
| values. | ||||
| 6.1. Connection States | 6.1. Connection States | |||
| A TLS connection state is the operating environment of the TLS Record | A TLS connection state is the operating environment of the TLS Record | |||
| Protocol. It specifies a compression algorithm, and encryption | Protocol. It specifies a compression algorithm, an encryption | |||
| algorithm, and a MAC algorithm. In addition, the parameters for | algorithm, and a MAC algorithm. In addition, the parameters for these | |||
| these algorithms are known: the MAC secret and the bulk encryption | algorithms are known: the MAC key and the bulk encryption keys for | |||
| keys for the connection in both the read and the write directions. | the connection in both the read and the write directions. Logically, | |||
| Logically, there are always four connection states outstanding: the | there are always four connection states outstanding: the current read | |||
| current read and write states, and the pending read and write states. | and write states, and the pending read and write states. All records | |||
| All records are processed under the current read and write states. | are processed under the current read and write states. The security | |||
| The security parameters for the pending states can be set by the TLS | parameters for the pending states can be set by the TLS Handshake | |||
| Handshake Protocol, and the Change Cipher Spec can selectively make | Protocol, and the Change Cipher Spec can selectively make either of | |||
| either of the pending states current, in which case the appropriate | the pending states current, in which case the appropriate current | |||
| current state is disposed of and replaced with the pending state; the | state is disposed of and replaced with the pending state; the pending | |||
| pending state is then reinitialized to an empty state. It is illegal | state is then reinitialized to an empty state. It is illegal to make | |||
| to make a state that has not been initialized with security | a state that has not been initialized with security parameters a | |||
| parameters a current state. The initial current state always | current state. The initial current state always specifies that no | |||
| specifies that no encryption, compression, or MAC will be used. | encryption, compression, or MAC will be used. | |||
| The security parameters for a TLS Connection read and write state are | The security parameters for a TLS Connection read and write state are | |||
| set by providing the following values: | set by providing the following values: | |||
| connection end | connection end | |||
| Whether this entity is considered the "client" or the "server" in | Whether this entity is considered the "client" or the "server" in | |||
| this connection. | this connection. | |||
| PRF algorithm | ||||
| An algorithm used to generate keys from the master secret (see | ||||
| 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, how much of that key is | includes the key size of this algorithm, whether it is a block, | |||
| secret, whether it is a block or stream cipher, and the block size | stream, or AEAD cipher, the block size of the cipher (if | |||
| of the cipher (if appropriate). | appropriate), and the lengths of explicit and implicit | |||
| 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 hash 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 compression. | must include all information the algorithm requires to do | |||
| 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 { null, rc4, rc2, des, 3des, des40, idea, aes } | enum { tls_prf_sha256 } PRFAlgorithm; | |||
| BulkCipherAlgorithm; | ||||
| enum { stream, block } CipherType; | enum { null, rc4, 3des, aes } | |||
| BulkCipherAlgorithm; | ||||
| enum { null, md5, sha } MACAlgorithm; | enum { stream, block, aead } CipherType; | |||
| enum { null(0), (255) } CompressionMethod; | enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384, | |||
| hmac_sha512} MACAlgorithm; | ||||
| /* The algorithms specified in CompressionMethod, | /* The use of "sha" above is historical and denotes SHA-1 */ | |||
| BulkCipherAlgorithm, and MACAlgorithm may be added to. */ | ||||
| struct { | enum { null(0), (255) } CompressionMethod; | |||
| ConnectionEnd entity; | ||||
| BulkCipherAlgorithm bulk_cipher_algorithm; | /* The algorithms specified in CompressionMethod, | |||
| CipherType cipher_type; | BulkCipherAlgorithm, and MACAlgorithm may be added to. */ | |||
| uint8 key_size; | ||||
| uint8 key_material_length; | struct { | |||
| MACAlgorithm mac_algorithm; | ConnectionEnd entity; | |||
| uint8 hash_size; | PRFAlgorithm prf_algorithm; | |||
| CompressionMethod compression_algorithm; | BulkCipherAlgorithm bulk_cipher_algorithm; | |||
| opaque master_secret[48]; | CipherType cipher_type; | |||
| opaque client_random[32]; | uint8 enc_key_length; | |||
| opaque server_random[32]; | uint8 block_length; | |||
| } SecurityParameters; | uint8 fixed_iv_length; | |||
| uint8 record_iv_length; | ||||
| MACAlgorithm mac_algorithm; | ||||
| uint8 mac_length; | ||||
| uint8 mac_key_length; | ||||
| CompressionMethod compression_algorithm; | ||||
| opaque master_secret[48]; | ||||
| opaque client_random[32]; | ||||
| opaque server_random[32]; | ||||
| } SecurityParameters; | ||||
| The record layer will use the security parameters to generate the | The record layer will use the security parameters to generate the | |||
| following four items: | following six items (some of which are not required by all ciphers, | |||
| and are thus empty): | ||||
| client write MAC secret | client write MAC key | |||
| server write MAC secret | server write MAC key | |||
| client write key | client write encryption key | |||
| server write key | server write encryption key | |||
| client write IV | ||||
| server write IV | ||||
| The client write parameters are used by the server when receiving and | The client write parameters are used by the server when receiving and | |||
| processing records and vice-versa. The algorithm used for generating | processing records and vice-versa. The algorithm used for generating | |||
| these items from the security parameters is described in Section 6.3. | these items from the security parameters is described in Section 6.3. | |||
| Once the security parameters have been set and the keys have been | Once the security parameters have been set and the keys have been | |||
| generated, the connection states can be instantiated by making them | generated, the connection states can be instantiated by making them | |||
| the current states. These current states MUST be updated for each | the current states. These current states MUST be updated for each | |||
| record processed. Each connection state includes the following | record processed. Each connection state includes the following | |||
| elements: | elements: | |||
| 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, | of the scheduled key for that connection. For stream ciphers, this | |||
| this will also contain whatever state information is necessary to | will also contain whatever state information is necessary to allow | |||
| allow the stream to continue to encrypt or decrypt data. | the stream to continue to encrypt or decrypt data. | |||
| MAC secret | MAC key | |||
| The MAC secret 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 | records carrying data in chunks of 2^14 bytes or less. Client message | |||
| message boundaries are not preserved in the record layer (i.e., | boundaries are not preserved in the record layer (i.e., multiple | |||
| multiple client messages of the same ContentType MAY be coalesced | client messages of the same ContentType MAY be coalesced into a | |||
| into a single TLSPlaintext record, or a single message MAY be | single TLSPlaintext record, or a single message MAY be fragmented | |||
| fragmented across several records). | across several records). | |||
| struct { | struct { | |||
| uint8 major, minor; | uint8 major; | |||
| } ProtocolVersion; | uint8 minor; | |||
| } ProtocolVersion; | ||||
| enum { | enum { | |||
| change_cipher_spec(20), alert(21), handshake(22), | change_cipher_spec(20), alert(21), handshake(22), | |||
| application_data(23), (255) | application_data(23), (255) | |||
| } ContentType; | } ContentType; | |||
| struct { | struct { | |||
| ContentType type; | ContentType type; | |||
| ProtocolVersion version; | ProtocolVersion version; | |||
| 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.1, which uses the version { 3, 2 }. The | describes TLS Version 1.2, which uses the version { 3, 3 }. The | |||
| version value 3.2 is historical: TLS version 1.1 is a minor | version value 3.3 is historical, deriving from the use of 3.1 for | |||
| modification to the TLS 1.0 protocol, which was itself a minor | TLS 1.0. (See Appendix A.1). Note that a client that supports | |||
| modification to the SSL 3.0 protocol, which bears the version | multiple versions of TLS may not know what version will be | |||
| value 3.0. (See Appendix A.1.) | employed before it receives the ServerHello. See Appendix E for | |||
| discussion about what record layer version number should be | ||||
| 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 should not exceed 2^14. | length MUST NOT exceed 2^14. | |||
| fragment | fragment | |||
| The application data. This data is transparent and is treated as | The application data. This data is transparent and treated as an | |||
| 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, | ||||
| Alert, or Change Cipher Spec content types. Zero-length fragments of | ||||
| Application data MAY be sent as they are potentially useful as a | ||||
| traffic analysis countermeasure. | ||||
| Note: Data of different TLS Record layer content types MAY be | Note: Data of different TLS Record layer content types MAY be | |||
| interleaved. Application data is generally of lower precedence for | interleaved. Application data is generally of lower precedence for | |||
| transmission than other content types. However, records MUST be | transmission than other content types. However, records MUST be | |||
| delivered to the network in the same order as they are protected by | delivered to the network in the same order as they are protected by | |||
| the record layer. Recipients MUST receive and process interleaved | the record layer. Recipients MUST receive and process interleaved | |||
| application layer traffic during handshakes subsequent to the first | application layer traffic during handshakes subsequent to the first | |||
| one on a connection. | one on a connection. | |||
| 6.2.2. Record Compression and Decompression | 6.2.2. Record Compression and Decompression | |||
| All records are compressed using the compression algorithm defined in | All records are compressed using the compression algorithm defined in | |||
| the current session state. There is always an active compression | the current session state. There is always an active compression | |||
| algorithm; however, initially it is defined as | algorithm; however, initially it is defined as | |||
| CompressionMethod.null. The compression algorithm translates a | CompressionMethod.null. The compression algorithm translates a | |||
| TLSPlaintext structure into a TLSCompressed structure. Compression | TLSPlaintext structure into a TLSCompressed structure. Compression | |||
| functions are initialized with default state information whenever a | functions are initialized with default state information whenever a | |||
| connection state is made active. | connection state is made active. | |||
| 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 should 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 should 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; no | |||
| fields are altered. | fields are altered. | |||
| Implementation note: Decompression functions are responsible for | Implementation note: Decompression functions are responsible for | |||
| ensuring that messages cannot cause internal | ensuring that messages cannot cause internal buffer overflows. | |||
| 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 structure | |||
| into a TLSCiphertext. The decryption functions reverse the process. | into a TLSCiphertext. The decryption functions reverse the process. | |||
| The MAC of the record also includes a sequence number so that | The MAC of the record also includes a sequence number so that | |||
| missing, extra, or repeated messages are detectable. | missing, extra, or repeated messages are detectable. | |||
| struct { | struct { | |||
| ContentType type; | ContentType type; | |||
| ProtocolVersion version; | ProtocolVersion version; | |||
| uint16 length; | uint16 length; | |||
| select (CipherSpec.cipher_type) { | select (SecurityParameters.cipher_type) { | |||
| case stream: GenericStreamCipher; | case stream: GenericStreamCipher; | |||
| case block: GenericBlockCipher; | case block: GenericBlockCipher; | |||
| } fragment; | case aead: GenericAEADCipher; | |||
| } TLSCiphertext; | } fragment; | |||
| } TLSCiphertext; | ||||
| type | type | |||
| The type field is identical to TLSCompressed.type. | The type field is identical to TLSCompressed.type. | |||
| 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 may 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[CipherSpec.hash_size]; | opaque MAC[SecurityParameters.mac_length]; | |||
| } GenericStreamCipher; | } GenericStreamCipher; | |||
| The MAC is generated as: | The MAC is generated as: | |||
| HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + | MAC(MAC_write_key, seq_num + | |||
| TLSCompressed.version + TLSCompressed.length + | TLSCompressed.type + | |||
| TLSCompressed.fragment)); | TLSCompressed.version + | |||
| TLSCompressed.length + | ||||
| TLSCompressed.fragment); | ||||
| where "+" denotes concatenation. | where "+" denotes concatenation. | |||
| seq_num | seq_num | |||
| The sequence number for this record. | The sequence number for this record. | |||
| hash | MAC | |||
| The hashing algorithm specified by | The MAC algorithm specified by SecurityParameters.mac_algorithm. | |||
| SecurityParameters.mac_algorithm. | ||||
| Note that the MAC is computed before encryption. The stream cipher | Note that the MAC is computed before encryption. The stream cipher | |||
| encrypts the entire block, including the MAC. For stream ciphers | encrypts the entire block, including the MAC. For stream ciphers that | |||
| that do not use a synchronization vector (such as RC4), the stream | do not use a synchronization vector (such as RC4), the stream cipher | |||
| cipher state from the end of one record is simply used on the | state from the end of one record is simply used on the subsequent | |||
| subsequent packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, | packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, encryption | |||
| encryption consists of the identity operation (i.e., the data is not | consists of the identity operation (i.e., the data is not encrypted, | |||
| encrypted, and the MAC size is zero, implying that no MAC is used). | and the MAC size is zero, implying that no MAC is used). | |||
| TLSCiphertext.length is TLSCompressed.length plus | TLSCiphertext.length is TLSCompressed.length plus | |||
| CipherSpec.hash_size. | SecurityParameters.mac_length. | |||
| 6.2.3.2. CBC Block Cipher | 6.2.3.2. CBC Block Cipher | |||
| For block ciphers (such as RC2, DES, 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. | |||
| block-ciphered struct { | struct { | |||
| opaque IV[CipherSpec.block_length]; | opaque IV[SecurityParameters.record_iv_length]; | |||
| opaque content[TLSCompressed.length]; | block-ciphered struct { | |||
| opaque MAC[CipherSpec.hash_size]; | opaque content[TLSCompressed.length]; | |||
| uint8 padding[GenericBlockCipher.padding_length]; | opaque MAC[SecurityParameters.mac_length]; | |||
| uint8 padding_length; | uint8 padding[GenericBlockCipher.padding_length]; | |||
| } GenericBlockCipher; | uint8 padding_length; | |||
| }; | ||||
| } 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 | |||
| Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit | The Initialization Vector (IV) SHOULD be chosen at random, and | |||
| IV in order to prevent the attacks described by [CBCATT]. We | MUST be unpredictable. Note that in versions of TLS prior to 1.1, | |||
| recommend the following equivalently strong procedures. For | there was no IV field, and the last ciphertext block of the | |||
| clarity we use the following notation. | previous record (the "CBC residue") was used as the IV. This was | |||
| changed to prevent the attacks described in [CBCATT]. For block | ||||
| IV | ciphers, the IV length is of length | |||
| The transmitted value of the IV field in the GenericBlockCipher | SecurityParameters.record_iv_length which is equal to the | |||
| structure. | SecurityParameters.block_size. | |||
| CBC residue | ||||
| The last ciphertext block of the previous record. | ||||
| mask | ||||
| The actual value that the cipher XORs with the plaintext prior | ||||
| to encryption of the first cipher block of the record. | ||||
| In prior versions of TLS, there was no IV field and the CBC | ||||
| residue and mask were one and the same. See Sections 6.1, | ||||
| 6.2.3.2, and 6.3, of [TLS1.0] for details of TLS 1.0 IV handling. | ||||
| One of the following two algorithms SHOULD be used to generate the | ||||
| per-record IV: | ||||
| (1) Generate a cryptographically strong random string R of length | ||||
| CipherSpec.block_length. Place R in the IV field. Set the | ||||
| mask to R. Thus, the first cipher block will be encrypted as | ||||
| E(R XOR Data). | ||||
| (2) Generate a cryptographically strong random number R of length | ||||
| CipherSpec.block_length and prepend it to the plaintext prior | ||||
| to encryption. In this case either: | ||||
| (a) The cipher may use a fixed mask such as zero. | ||||
| (b) The CBC residue from the previous record may be used as | ||||
| the mask. This preserves maximum code compatibility with | ||||
| TLS 1.0 and SSL 3. It also has the advantage that it does | ||||
| not require the ability to quickly reset the IV, which is | ||||
| known to be a problem on some systems. | ||||
| In either (2)(a) or (2)(b) the data (R || data) is fed into | ||||
| the encryption process. The first cipher block (containing | ||||
| E(mask XOR R) is placed in the IV field. The first block of | ||||
| content contains E(IV XOR data). | ||||
| The following alternative procedure MAY be used; however, it has | ||||
| not been demonstrated to be as cryptographically strong as the | ||||
| above procedures. The sender prepends a fixed block F to the | ||||
| plaintext (or, alternatively, a block generated with a weak PRNG). | ||||
| He then encrypts as in (2), above, using the CBC residue from the | ||||
| previous block as the mask for the prepended block. Note that in | ||||
| this case the mask for the first record transmitted by the | ||||
| application (the Finished) MUST be generated using a | ||||
| cryptographically strong PRNG. | ||||
| The decryption operation for all three alternatives is the same. | ||||
| The receiver decrypts the entire GenericBlockCipher structure and | ||||
| then discards the first cipher block, corresponding to the IV | ||||
| component. | ||||
| 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 SHOULD 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 CipherSpec.block_length, TLSCompressed.length, | sum of SecurityParameters.block_length, TLSCompressed.length, | |||
| CipherSpec.hash_size, 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 | (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, | |||
| bytes, then the length before padding is 82 bytes (this does | then the length before padding is 82 bytes (this does not include the | |||
| not include the IV, which may or may not be encrypted, as | IV. Thus, the padding length modulo 8 must be equal to 6 in order to | |||
| discussed above). Thus, the padding length modulo 8 must be | make the total length an even multiple of 8 bytes (the block length). | |||
| equal to 6 in order to make the total length an even | The padding length can be 6, 14, 22, and so on, through 254. If the | |||
| multiple of 8 bytes (the block length). The padding length | padding length were the minimum necessary, 6, the padding would be 6 | |||
| can be 6, 14, 22, and so on, through 254. If the padding | bytes, each containing the value 6. Thus, the last 8 octets of the | |||
| length were the minimum necessary, 6, the padding would be 6 | GenericBlockCipher before block encryption would be xx 06 06 06 06 06 | |||
| bytes, each containing the value 6. Thus, the last 8 octets | 06 06, where xx is the last octet of the MAC. | |||
| of the GenericBlockCipher before block encryption would be | ||||
| xx 06 06 06 06 06 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 | critical that the entire plaintext of the record be known before any | |||
| before any ciphertext is transmitted. Otherwise, it is | ciphertext is transmitted. Otherwise, it is possible for the attacker | |||
| possible for the attacker to mount the attack described in | to mount the attack described in [CBCATT]. | |||
| [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 | timing attack on CBC padding based on the time required to compute | |||
| required to compute the MAC. In order to defend | the MAC. In order to defend against this attack, implementations MUST | |||
| against this attack, implementations MUST ensure | ensure that record processing time is essentially the same whether or | |||
| that record processing time is essentially the | not the padding is correct. In general, the best way to do this is | |||
| same whether or not the padding is correct. In | to compute the MAC even if the padding is incorrect, and only then | |||
| general, the best way to do this is to compute | reject the packet. For instance, if the pad appears to be incorrect, | |||
| the MAC even if the padding is incorrect, and | the implementation might assume a zero-length pad and then compute | |||
| only then reject the packet. For instance, if | the MAC. This leaves a small timing channel, since MAC performance | |||
| the pad appears to be incorrect, the | depends to some extent on the size of the data fragment, but it is | |||
| implementation might assume a zero-length pad | not believed to be large enough to be exploitable, due to the large | |||
| and then compute the MAC. This leaves a small | block size of existing MACs and the small size of the timing signal. | |||
| timing channel, since MAC performance depends to | ||||
| some extent on the size of the data fragment, | 6.2.3.3. AEAD ciphers | |||
| but it is not believed to be large enough to be | ||||
| exploitable, due to the large block size of | For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function | |||
| existing MACs and the small size of the timing | converts TLSCompressed.fragment structures to and from AEAD | |||
| signal. | TLSCiphertext.fragment structures. | |||
| struct { | ||||
| opaque nonce_explicit[SecurityParameters.record_iv_length]; | ||||
| aead-ciphered struct { | ||||
| opaque content[TLSCompressed.length]; | ||||
| }; | ||||
| } GenericAEADCipher; | ||||
| AEAD ciphers take as input a single key, a nonce, a plaintext, and | ||||
| "additional data" to be included in the authentication check, as | ||||
| 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. | ||||
| Each AEAD cipher suite MUST specify how the nonce supplied to the | ||||
| AEAD operation is constructed, and what is the length of the | ||||
| GenericAEADCipher.nonce_explicit part. In many cases, it is | ||||
| appropriate to use the partially implicit nonce technique described | ||||
| 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 | ||||
| from key_block as client_write_iv and server_write_iv (as described | ||||
| in Section 6.3), and the explicit part is included in | ||||
| GenericAEAEDCipher.nonce_explicit. | ||||
| The plaintext is the TLSCompressed.fragment. | ||||
| The additional authenticated data, which we denote as | ||||
| additional_data, is defined as follows: | ||||
| additional_data = seq_num + TLSCompressed.type + | ||||
| TLSCompressed.version + TLSCompressed.length; | ||||
| Where "+" denotes concatenation. | ||||
| The aead_output consists of the ciphertext output by the AEAD | ||||
| encryption operation. The length will generally be larger than | ||||
| TLSCompressed.length, but by an amount that varies with the AEAD | ||||
| cipher. Since the ciphers might incorporate padding, the amount of | ||||
| overhead could vary with different TLSCompressed.length values. Each | ||||
| AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. | ||||
| Symbolically, | ||||
| AEADEncrypted = AEAD-Encrypt(key, nonce, plaintext, | ||||
| additional_data) | ||||
| In order to decrypt and verify, the cipher takes as input the key, | ||||
| nonce, the "additional_data", and the AEADEncrypted value. The output | ||||
| is either the plaintext or an error indicating that the decryption | ||||
| failed. There is no separate integrity check. I.e., | ||||
| TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce, | ||||
| AEADEncrypted, | ||||
| additional_data) | ||||
| If the decryption fails, a fatal bad_record_mac alert MUST be | ||||
| generated. | ||||
| 6.3. Key Calculation | 6.3. Key Calculation | |||
| The Record Protocol requires an algorithm to generate keys, and MAC | The Record Protocol requires an algorithm to generates keys required | |||
| secrets from the security parameters provided by the handshake | by the current connection state (see Appendix A.6) from the security | |||
| protocol. | parameters provided by the handshake protocol. | |||
| The master secret is hashed into a sequence of secure bytes, which | The master secret is expanded into a sequence of secure bytes, which | |||
| are assigned to the MAC secrets and keys required by the current | is then split to a client write MAC key, a server write MAC key, a | |||
| connection state (see Appendix A.6). CipherSpecs require a client | client write encryption key, and a server write encryption key. Each | |||
| write MAC secret, a server write MAC secret, a client write key, and | of these is generated from the byte sequence in that order. Unused | |||
| a server write key, each of which is generated from the master secret | values are empty. Some AEAD ciphers may additionally require a | |||
| in that order. Unused values are empty. | client write IV and a server write IV (see Section 6.2.3.3). | |||
| When keys and MAC secrets are generated, the master secret is used as | When keys and MAC keys are generated, the master secret is used as an | |||
| 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_secret[SecurityParameters.hash_size] | client_write_MAC_key[SecurityParameters.mac_key_length] | |||
| server_write_MAC_secret[SecurityParameters.hash_size] | server_write_MAC_key[SecurityParameters.mac_key_length] | |||
| client_write_key[SecurityParameters.key_material_length] | client_write_key[SecurityParameters.enc_key_length] | |||
| server_write_key[SecurityParameters.key_material_length] | server_write_key[SecurityParameters.enc_key_length] | |||
| client_write_IV[SecurityParameters.fixed_iv_length] | ||||
| server_write_IV[SecurityParameters.fixed_iv_length] | ||||
| Implementation note: The currently defined cipher suite that requires | Currently, the client_write_IV and server_write_IV are only generated | |||
| the most material is AES_256_CBC_SHA, defined in [TLSAES]. It | for implicit nonce techniques as described in Section 3.2.1 of | |||
| requires 2 x 32 byte keys, 2 x 20 byte MAC secrets, and 2 x 16 byte | [AEAD]. | |||
| Initialization Vectors, for a total of 136 bytes of key material. | ||||
| Implementation note: The currently defined cipher suite which | ||||
| 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 | ||||
| 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 [X509] certificate of the peer. This element of the state | X509v3 [PKIX] certificate of the peer. This element of the state | |||
| may be null. | may be null. | |||
| compression method | compression method | |||
| The algorithm used to compress data prior to encryption. | The algorithm used to compress data prior to encryption. | |||
| cipher spec | cipher spec | |||
| Specifies the bulk data encryption algorithm (such as null, DES, | Specifies the bulk data encryption algorithm (such as null, DES, | |||
| etc.) and a MAC algorithm (such as MD5 or SHA). It also defines | etc.) and a MAC algorithm (such as MD5 or SHA). It also defines | |||
| cryptographic attributes such as the hash_size. (See Appendix A.6 | cryptographic attributes such as the mac_length. (See Appendix A.6 | |||
| for formal definition.) | for formal definition.) | |||
| master secret | master secret | |||
| 48-byte secret shared between the client and server. | 48-byte secret shared between the client and server. | |||
| is resumable | is resumable | |||
| A flag indicating whether the session can be used to initiate new | A flag indicating whether the session can be used to initiate new | |||
| connections. | connections. | |||
| 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 change cipher spec message is sent by both the client and the | The change cipher spec message is sent by both the client and the | |||
| server to notify the receiving party that subsequent records will be | server to notify the receiving party that subsequent records will be | |||
| protected under the newly negotiated CipherSpec and keys. Reception | protected under the newly negotiated CipherSpec and keys. Reception | |||
| of this message causes the receiver to instruct the Record Layer to | of this message causes the receiver to instruct the Record Layer to | |||
| immediately copy the read pending state into the read current state. | immediately copy the read pending state into the read current state. | |||
| Immediately after sending this message, the sender MUST instruct the | Immediately after sending this message, the sender MUST instruct the | |||
| record layer to make the write pending state the write active state. | record layer to make the write pending state the write active state. | |||
| (See Section 6.1.) The change cipher spec message is sent during the | (See Section 6.1.) The change cipher spec message is sent during the | |||
| handshake after the security parameters have been agreed upon, but | handshake after the security parameters have been agreed upon, but | |||
| before the verifying finished message is sent (see Section 7.4.9). | 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 | the communicating parties may continue to send data using the old | |||
| old CipherSpec. However, once the ChangeCipherSpec has been | CipherSpec. However, once the ChangeCipherSpec has been sent, the new | |||
| sent, the new CipherSpec MUST be used. The first side to send | CipherSpec MUST be used. The first side to send the ChangeCipherSpec | |||
| the ChangeCipherSpec does not know that the other side has | does not know that the other side has finished computing the new | |||
| finished computing the new keying material (e.g., if it has to | keying material (e.g., if it has to perform a time consuming public | |||
| perform a time consuming public key operation). Thus, a small | key operation). Thus, a small window of time, during which the | |||
| window of time, during which the recipient must buffer the | recipient must buffer the data, MAY exist. In practice, with modern | |||
| data, MAY exist. In practice, with modern machines this | machines this interval is likely to be fairly short. | |||
| 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 | One of the content types supported by the TLS Record layer is the | |||
| the alert type. Alert messages convey the severity of the | alert type. Alert messages convey the severity of the message and a | |||
| message and a description of the alert. Alert messages with a | description of the alert. Alert messages with a level of fatal result | |||
| level of fatal result in the immediate termination of the | in the immediate termination of the connection. In this case, other | |||
| connection. In this case, other connections corresponding to | connections corresponding to the session may continue, but the | |||
| the session may continue, but the session identifier MUST be | session identifier MUST be invalidated, preventing the failed session | |||
| invalidated, preventing the failed session from being used to | from being used to establish new connections. Like other messages, | |||
| establish new connections. Like other messages, alert messages | alert messages are encrypted and compressed, as specified by the | |||
| are encrypted and compressed, as specified by the current | current connection state. | |||
| connection state. | ||||
| enum { warning(1), fatal(2), (255) } AlertLevel; | ||||
| enum { | enum { warning(1), fatal(2), (255) } AlertLevel; | |||
| close_notify(0), | enum { | |||
| unexpected_message(10), | close_notify(0), | |||
| bad_record_mac(20), | unexpected_message(10), | |||
| decryption_failed(21), | bad_record_mac(20), | |||
| record_overflow(22), | decryption_failed_RESERVED(21), | |||
| decompression_failure(30), | record_overflow(22), | |||
| handshake_failure(40), | decompression_failure(30), | |||
| no_certificate_RESERVED (41), | handshake_failure(40), | |||
| bad_certificate(42), | no_certificate_RESERVED(41), | |||
| unsupported_certificate(43), | bad_certificate(42), | |||
| certificate_revoked(44), | unsupported_certificate(43), | |||
| certificate_expired(45), | certificate_revoked(44), | |||
| certificate_unknown(46), | certificate_expired(45), | |||
| illegal_parameter(47), | certificate_unknown(46), | |||
| unknown_ca(48), | illegal_parameter(47), | |||
| access_denied(49), | unknown_ca(48), | |||
| decode_error(50), | access_denied(49), | |||
| decrypt_error(51), | decode_error(50), | |||
| export_restriction_RESERVED(60), | decrypt_error(51), | |||
| protocol_version(70), | export_restriction_RESERVED(60), | |||
| insufficient_security(71), | protocol_version(70), | |||
| internal_error(80), | insufficient_security(71), | |||
| user_canceled(90), | internal_error(80), | |||
| no_renegotiation(100), | user_canceled(90), | |||
| (255) | no_renegotiation(100), | |||
| } AlertDescription; | unsupported_extension(110), | |||
| (255) | ||||
| } 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 | transport without waiting for the responding close_notify. No part of | |||
| of this standard should be taken to dictate the manner in which a | this standard should be taken to dictate the manner in which a usage | |||
| usage profile for TLS manages its data transport, including when | 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 | failed connection. Thus, any connection terminated with a fatal alert | |||
| alert MUST NOT be resumed. The following error alerts are defined: | MUST NOT be resumed. | |||
| Whenever an implementation encounters a condition which is defined as | ||||
| a fatal alert, it MUST send the appropriate alert prior to closing | ||||
| the connection. For all errors where an alert level is not explicitly | ||||
| specified, the sending party MAY determine at its discretion whether | ||||
| to treat this as a fatal error or not. If the implementation chooses | ||||
| to send an alert but intends to close the connection immediately | ||||
| afterwards, it MUST send that alert at the fatal alert level. | ||||
| If an alert with a level of warning is sent and received, generally | ||||
| the connection can continue normally. If the receiving party decides | ||||
| not to proceed with the connection (e.g., after having received a | ||||
| no_renegotiation alert that it is not willing to accept), it SHOULD | ||||
| send a fatal alert to terminate the connection. Given this, the | ||||
| sending party cannot, in general, know how the receiving party will | ||||
| behave. Therefore, warning alerts are not very useful when the | ||||
| sending party wants to continue the connection, and thus are | ||||
| sometimes omitted. For example, if a peer decides to accept an | ||||
| expired certificate (perhaps after confirming this with the user) and | ||||
| wants to continue the connection, it would not generally send a | ||||
| certificate_expired alert. | ||||
| The following error alerts are defined: | ||||
| unexpected_message | unexpected_message | |||
| An inappropriate message was received. This alert is always fatal | An inappropriate message was received. This alert is always fatal | |||
| and should never be observed in communication between proper | and should never be observed in communication between proper | |||
| implementations. | implementations. | |||
| bad_record_mac | bad_record_mac | |||
| This alert is returned if a record is received with an incorrect | This alert is returned if a record is received with an incorrect | |||
| MAC. This alert also MUST be returned if an alert is sent because | MAC. This alert also MUST be returned if an alert is sent because | |||
| a TLSCiphertext decrypted in an invalid way: either it wasn't an | a TLSCiphertext decrypted in an invalid way: either it wasn't an | |||
| even multiple of the block length, or its padding values, when | even multiple of the block length, or its padding values, when | |||
| checked, weren't correct. This message is always fatal. | checked, weren't correct. This message is always fatal and should | |||
| never be observed in communication between proper implementations | ||||
| decryption_failed | (except when messages were corrupted in the network). | |||
| This alert MAY be returned if a TLSCiphertext decrypted in an | ||||
| invalid way: either it wasn't an even multiple of the block | ||||
| length, or its padding values, when checked, weren't correct. | ||||
| This message is always fatal. | ||||
| Note: Differentiating between bad_record_mac and decryption_failed | decryption_failed_RESERVED | |||
| alerts may permit certain attacks against CBC mode as used in | This alert was used in some earlier versions of TLS, and may have | |||
| TLS [CBCATT]. It is preferable to uniformly use the | permitted certain attacks against the CBC mode [CBCATT]. It MUST | |||
| bad_record_mac alert to hide the specific type of the error. | 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 | 2^14+2048 bytes, or a record decrypted to a TLSCompressed record | |||
| record with more than 2^14+1024 bytes. This message is always | with more than 2^14+1024 bytes. This message is always fatal and | |||
| fatal. | should never be observed in communication between proper | |||
| implementations (except when messages were corrupted in the | ||||
| network). | ||||
| decompression_failure | decompression_failure | |||
| The decompression function received improper input (e.g., data | The decompression function received improper input (e.g., data | |||
| that would expand to excessive length). This message is always | that would expand to excessive length). This message is always | |||
| fatal. | fatal and should never be observed in communication between proper | |||
| implementations. | ||||
| handshake_failure | handshake_failure | |||
| Reception of a handshake_failure alert message indicates that | Reception of a handshake_failure alert message indicates that the | |||
| the sender was unable to negotiate an acceptable set of | sender was unable to negotiate an acceptable set of security | |||
| security parameters given the options available. This is a | parameters given the options available. This is a fatal error. | |||
| fatal error. | ||||
| no_certificate_RESERVED | no_certificate_RESERVED | |||
| This alert was used in SSLv3 but not in TLS. It should not be | This alert was used in SSLv3 but not any version of TLS. It MUST | |||
| 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 | |||
| A certificate was of an unsupported type. | A certificate was of an unsupported type. | |||
| certificate_revoked | certificate_revoked | |||
| A certificate was revoked by its signer. | A certificate was revoked by its signer. | |||
| certificate_expired | certificate_expired | |||
| A certificate has expired or is not currently valid. | A certificate has expired or is not currently valid. | |||
| certificate_unknown | certificate_unknown | |||
| Some other (unspecified) issue arose in processing the | Some other (unspecified) issue arose in processing the | |||
| certificate, rendering it unacceptable. | certificate, rendering it unacceptable. | |||
| illegal_parameter | illegal_parameter | |||
| A field in the handshake was out of range or inconsistent with | A field in the handshake was out of range or inconsistent with | |||
| other fields. This is always fatal. | other fields. This message is always fatal. | |||
| unknown_ca | unknown_ca | |||
| A valid certificate chain or partial chain was received, but | A valid certificate chain or partial chain was received, but the | |||
| the certificate was not accepted because the CA certificate | certificate was not accepted because the CA certificate could not | |||
| could not be located or couldn't be matched with a known, | be located or couldn't be matched with a known, trusted CA. This | |||
| trusted CA. This message is always fatal. | message is always fatal. | |||
| access_denied | access_denied | |||
| A valid certificate was received, but when access control was | A valid certificate was received, but when access control was | |||
| applied, the sender decided not to proceed with negotiation. | applied, the sender decided not to proceed with negotiation. This | |||
| 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 | A message could not be decoded because some field was out of the | |||
| the specified range or the length of the message was incorrect. | specified range or the length of the message was incorrect. This | |||
| This message is always fatal. | message is always fatal and should never be observed in | |||
| communication between proper implementations (except when messages | ||||
| were corrupted in the network). | ||||
| decrypt_error | decrypt_error | |||
| A handshake cryptographic operation failed, including being | A handshake cryptographic operation failed, including being unable | |||
| unable to correctly verify a signature, decrypt a key exchange, | to correctly verify a signature or validate a finished message. | |||
| or validate a finished message. | This message is always fatal. | |||
| export_restriction_RESERVED | export_restriction_RESERVED | |||
| This alert was used in TLS 1.0 but not TLS 1.1. | This alert was used in some earlier versions of TLS. It MUST NOT | |||
| 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 | recognized but not supported. (For example, old protocol versions | |||
| versions might be avoided for security reasons). This message | might be avoided for security reasons). This message is always | |||
| 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 | secure than those supported by the client. This message is always | |||
| always fatal. | fatal. | |||
| internal_error | internal_error | |||
| An internal error unrelated to the peer or the correctness of | An internal error unrelated to the peer or the correctness of the | |||
| the protocol (such as a memory allocation failure) makes it | protocol (such as a memory allocation failure) makes it impossible | |||
| 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 | close_notify is more appropriate. This alert should be followed by | |||
| followed by a close_notify. This message is generally a | a close_notify. This message is generally a warning. | |||
| warning. | ||||
| no_renegotiation | no_renegotiation | |||
| Sent by the client in response to a hello request or by the | Sent by the client in response to a hello request or by the server | |||
| server in response to a client hello after initial handshaking. | in response to a client hello after initial handshaking. Either | |||
| Either of these would normally lead to renegotiation; when that | of these would normally lead to renegotiation; when that is not | |||
| is not appropriate, the recipient should respond with this | appropriate, the recipient should respond with this alert. At | |||
| alert. At that point, the original requester can decide | that point, the original requester can decide whether to proceed | |||
| whether to proceed with the connection. One case where this | with the connection. One case where this would be appropriate is | |||
| would be appropriate is where a server has spawned a process to | where a server has spawned a process to satisfy a request; the | |||
| satisfy a request; the process might receive security | process might receive security parameters (key length, | |||
| parameters (key length, authentication, etc.) at startup and it | authentication, etc.) at startup and it might be difficult to | |||
| might be difficult to communicate changes to these parameters | communicate changes to these parameters after that point. This | |||
| after that point. This message is always a warning. | message is always a warning. | |||
| For all errors where an alert level is not explicitly specified, the | unsupported_extension | |||
| sending party MAY determine at its discretion whether this is a fatal | sent by clients that receive an extended server hello containing | |||
| error or not; if an alert with a level of warning is received, the | an extension that they did not put in the corresponding client | |||
| receiving party MAY decide at its discretion whether to treat this as | hello. This message is always fatal. | |||
| a fatal error or not. However, all messages that are transmitted | ||||
| with a level of fatal MUST be treated as fatal messages. | ||||
| New alert values MUST be defined by RFC 2434 Standards Action. See | New Alert values are assigned by IANA as described in Section 12. | |||
| Section 11 for IANA Considerations for alert values. | ||||
| 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 31, line 48 ¶ | skipping to change at page 33, line 36 ¶ | |||
| 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. | |||
| However, one SHOULD never send data over a link encrypted with 40-bit | ||||
| security unless one feels that data is worth no more than the effort | ||||
| required to break that encryption. | ||||
| 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 client hello message to | |||
| which the server must respond with a server hello message, or else a | which the server must respond with a server hello message, or else a | |||
| fatal error will occur and the connection will fail. The client | fatal error will occur and the connection will fail. The client hello | |||
| hello and server hello are used to establish security enhancement | and server hello are used to establish security enhancement | |||
| capabilities between client and server. The client hello and server | capabilities between client and server. The client hello and server | |||
| hello establish the following attributes: Protocol Version, Session | hello establish the following attributes: Protocol Version, Session | |||
| ID, Cipher Suite, and Compression Method. Additionally, two random | ID, Cipher Suite, and Compression Method. Additionally, two random | |||
| values are generated and exchanged: ClientHello.random and | values are generated and exchanged: ClientHello.random and | |||
| ServerHello.random. | ServerHello.random. | |||
| The actual key exchange uses up to four messages: the server | The actual key exchange uses up to four messages: the server | |||
| certificate, the server key exchange, the client certificate, and the | certificate, the server key exchange, the client certificate, and the | |||
| client key exchange. New key exchange methods can be created by | client key exchange. 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 48 to 128 bytes in | exchange methods exchange secrets that range from 46 bytes upwards. | |||
| length. | ||||
| Following the hello messages, the server will send its certificate, | Following the hello messages, the server will send its certificate, | |||
| if it is to be authenticated. Additionally, a server key exchange | if it is to be authenticated. Additionally, a server key exchange | |||
| message may be sent, if it is required (e.g., if the server has no | message may be sent, if it is required (e.g., if their server has no | |||
| certificate, or if its certificate is for signing only). If the | certificate, or if its certificate is for signing only). If the | |||
| server is authenticated, it may request a certificate from the | server is authenticated, it may request a certificate from the | |||
| client, if that is appropriate to the cipher suite selected. Next, | client, if that is appropriate to the cipher suite selected. Next, | |||
| the server will send the server hello done message, indicating that | the server will send the server hello done message, indicating that | |||
| the hello-message phase of the handshake is complete. The server | the hello-message phase of the handshake is complete. The server will | |||
| will then wait for a client response. If the server has sent a | then wait for a client response. If the server has sent a certificate | |||
| certificate request message, the client must send the certificate | request message, the client MUST send the certificate message. The | |||
| message. The client key exchange message is now sent, and the | client key exchange message is now sent, and the content of that | |||
| content of that message will depend on the public key algorithm | message will depend on the public key algorithm selected between the | |||
| selected between the client hello and the server hello. If the | client hello and the server hello. If the client has sent a | |||
| client has sent a certificate with signing ability, a digitally- | certificate with signing ability, a digitally-signed certificate | |||
| signed certificate verify message is sent to explicitly verify the | verify message is sent to explicitly verify possession of the private | |||
| certificate. | key in the certificate. | |||
| At this point, a change cipher spec message is sent by the client, | At this point, a change cipher spec message is sent by the client, | |||
| and the client copies the pending Cipher Spec into the current Cipher | and the client copies the pending Cipher Spec into the current Cipher | |||
| Spec. The client then immediately sends the finished message under | Spec. The client then immediately sends the finished message under | |||
| the new algorithms, keys, and secrets. In response, the server will | the new algorithms, keys, and secrets. In response, the server will | |||
| send its own change cipher spec message, transfer the pending to the | send its own change cipher spec 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 | Cipher Spec. At this point, the handshake is complete, and the client | |||
| client and server may begin to exchange application layer data. (See | and server may begin to exchange application layer data. (See flow | |||
| flow chart below.) Application data MUST NOT be sent prior to the | chart below.) Application data MUST NOT be sent prior to the | |||
| completion of the first handshake (before a cipher suite other | 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 | |||
| skipping to change at page 33, line 38 ¶ | skipping to change at page 35, line 20 ¶ | |||
| 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 | Fig. 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 | independent TLS Protocol content type, and is not actually a TLS | |||
| 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. | be resumed. The server then checks its session cache for a match. If | |||
| a match is found, and the server is willing to re-establish the | ||||
| 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 change cipher spec messages and proceed | client and server MUST send change cipher spec messages and proceed | |||
| directly to finished messages. Once the re-establishment is | directly to finished messages. Once the re-establishment is complete, | |||
| complete, the client and server MAY begin to exchange application | the client and server MAY begin to exchange application layer data. | |||
| layer data. (See flow chart below.) If a Session ID match is not | (See flow chart below.) If a Session ID match is not found, the | |||
| found, the server generates a new session ID and the TLS client and | server generates a new session ID and the TLS client and server | |||
| server perform a full handshake. | 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 | |||
| skipping to change at page 34, line 24 ¶ | skipping to change at page 36, line 4 ¶ | |||
| 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 | Fig. 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) | |||
| skipping to change at page 35, line 17 ¶ | skipping to change at page 36, line 45 ¶ | |||
| 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 | results in a fatal error. Unneeded handshake messages can be omitted, | |||
| omitted, however. Note one exception to the ordering: the | however. Note one exception to the ordering: the Certificate message | |||
| Certificate message is used twice in the handshake (from server to | is used twice in the handshake (from server to client, then from | |||
| client, then from client to server), but is described only in its | client to server), but described only in its first position. The one | |||
| first position. The one message that is not bound by these ordering | message that is not bound by these ordering rules is the Hello | |||
| rules is the Hello Request message, which can be sent at any time, | Request message, which can be sent at any time, but which SHOULD be | |||
| but which should be ignored by the client if it arrives in the middle | ignored by the client if it arrives in the middle of a handshake. | |||
| of a handshake. | ||||
| New Handshake message type values MUST be defined via RFC 2434 | New Handshake message types are assigned by IANA as described in | |||
| Standards Action. See Section 11 for IANA Considerations for these | Section 12. | |||
| values. | ||||
| 7.4.1. Hello Messages | 7.4.1. Hello Messages | |||
| The hello phase messages are used to exchange security enhancement | The hello phase messages are used to exchange security enhancement | |||
| capabilities between the client and server. When a new session | capabilities between the client and server. When a new session | |||
| begins, the Record Layer's connection state encryption, hash, and | begins, the Record Layer's connection state encryption, hash, and | |||
| compression algorithms are initialized to null. The current | compression algorithms are initialized to null. The current | |||
| connection state is used for renegotiation messages. | connection state is used for renegotiation messages. | |||
| 7.4.1.1. Hello request | 7.4.1.1. Hello Request | |||
| When this message will be sent: | When this message will be sent: | |||
| The hello request message MAY be sent by the server at any time. | The hello request message MAY be sent by the server at any time. | |||
| Meaning of this message: | Meaning of this message: | |||
| Hello request is a simple notification that the client should | Hello request is a simple notification that the client should | |||
| begin the negotiation process anew by sending a client hello | begin the negotiation process anew by sending a client hello | |||
| message when convenient. This message will be ignored by the | message when convenient. This message is not intended to establish | |||
| client if the client is currently negotiating a session. This | which side is the client or server but merely to initiate a new | |||
| message may be ignored by the client if it does not wish to | negotiation. Servers SHOULD NOT send a HelloRequest immediately | |||
| renegotiate a session, or the client may, if it wishes, respond | upon the client's initial connection. It is the client's job to | |||
| with a no_renegotiation alert. Since handshake messages are | send a ClientHello at that time. | |||
| intended to have transmission precedence over application data, it | ||||
| is expected that the negotiation will begin before no more than a | ||||
| few records are received from the client. If the server sends a | ||||
| hello request but does not receive a client hello in response, it | ||||
| may close the connection with a fatal alert. | ||||
| After sending a hello request, servers SHOULD not repeat the | This message will be ignored by the client if the client is | |||
| currently negotiating a session. This message may be ignored by | ||||
| the client if it does not wish to renegotiate a session, or the | ||||
| client may, if it wishes, respond with a no_renegotiation alert. | ||||
| Since handshake messages are intended to have transmission | ||||
| precedence over application data, it is expected that the | ||||
| negotiation will begin before no more than a few records are | ||||
| received from the client. If the server sends a hello request but | ||||
| does not receive a client hello in response, it may close the | ||||
| connection with a fatal alert. | ||||
| After sending a hello request, servers SHOULD NOT repeat the | ||||
| request until the subsequent handshake negotiation is complete. | request until the subsequent handshake negotiation is complete. | |||
| Structure of this message: | Structure of this message: | |||
| struct { } HelloRequest; | struct { } HelloRequest; | |||
| Note: This message MUST NOT be included in the message hashes that | Note: This message MUST NOT be included in the message hashes that | |||
| are maintained throughout the handshake and used in the | are maintained throughout the handshake and used in the finished | |||
| finished messages and the certificate verify message. | messages and the certificate verify message. | |||
| 7.4.1.2. Client Hello | 7.4.1.2. Client Hello | |||
| When this message will be sent: | When this message will be sent: | |||
| When a client first connects to a server it is required to send | When a client first connects to a server it is required to send | |||
| the client hello as its first message. The client can also send a | the client hello as its first message. The client can also send a | |||
| client hello in response to a hello request or on its own | client hello in response to a hello request or on its own | |||
| initiative in order to renegotiate the security parameters in an | initiative in order to renegotiate the security parameters in an | |||
| existing connection. | existing connection. | |||
| Structure of this message: | Structure of this message: | |||
| The client hello message includes a random structure, which is | The client hello message includes a random structure, which is | |||
| used later in the protocol. | used 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 The current time and date in standard UNIX 32-bit | gmt_unix_time | |||
| format (seconds since the midnight starting Jan 1, 1970, GMT, | The current time and date in standard UNIX 32-bit format | |||
| ignoring leap seconds) according to the sender's internal clock. | (seconds since the midnight starting Jan 1, 1970, GMT, ignoring | |||
| Clocks are not required to be set correctly by the basic TLS | leap seconds) according to the sender's internal clock. Clocks | |||
| Protocol; higher-level or application protocols may define | are not required to be set correctly by the basic TLS Protocol; | |||
| additional requirements. | higher-level or application protocols may define additional | |||
| requirements. | ||||
| random_bytes | random_bytes | |||
| 28 bytes generated by a secure random number generator. | 28 bytes generated by a secure random number generator. | |||
| The client hello message includes a variable-length session | The client hello 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, | reuse. The session identifier MAY be from an earlier connection, this | |||
| from this connection, or from another currently active connection. | connection, or from another currently active connection. The second | |||
| The second option is useful if the client only wishes to update the | option is useful if the client only wishes to update the random | |||
| random structures and derived values of a connection, and the third | structures and derived values of a connection, and the third option | |||
| option makes it possible to establish several independent secure | makes it possible to establish several independent secure connections | |||
| connections without repeating the full handshake protocol. These | without repeating the full handshake protocol. These independent | |||
| independent connections may occur sequentially or simultaneously; a | connections may occur sequentially or simultaneously; a SessionID | |||
| SessionID becomes valid when the handshake negotiating it completes | becomes valid when the handshake negotiating it completes with the | |||
| with the exchange of Finished messages and persists until it is | exchange of Finished messages and persists until it is removed due to | |||
| removed due to aging or because a fatal error was encountered on a | aging or because a fatal error was encountered on a connection | |||
| connection associated with the session. The actual contents of the | associated with the session. The actual contents of the SessionID are | |||
| SessionID are defined by the server. | 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 | immediate MAC protection, servers MUST NOT place confidential | |||
| confidential information in session identifiers or let the | information in session identifiers or let the contents of fake | |||
| contents of fake session identifiers cause any breach of | session identifiers cause any breach of security. (Note that the | |||
| security. (Note that the content of the handshake as a | content of the handshake as a whole, including the SessionID, is | |||
| whole, including the SessionID, is protected by the Finished | protected by the Finished messages exchanged at the end of the | |||
| messages exchanged at the end of the handshake.) | handshake.) | |||
| The CipherSuite list, passed from the client to the server in the | The cipher suite list, passed from the client to the server in the | |||
| client hello message, contains the combinations of cryptographic | client hello message, contains the combinations of cryptographic | |||
| algorithms supported by the client in order of the client's | algorithms supported by the client in order of the client's | |||
| preference (favorite choice first). Each CipherSuite defines a key | preference (favorite choice first). Each cipher suite defines a key | |||
| exchange algorithm, a bulk encryption algorithm (including secret key | exchange algorithm, a bulk encryption algorithm (including secret key | |||
| length), and a MAC algorithm. The server will select a cipher suite | length), a MAC algorithm, and a PRF. The server will select a cipher | |||
| or, if no acceptable choices are presented, return a handshake | suite or, if no acceptable choices are presented, return a handshake | |||
| failure alert and close the connection. | failure alert and close the connection. If the list contains cipher | |||
| suites the server does not recognize, support, or wish to use, the | ||||
| server MUST ignore those cipher suites, and process the remaining | ||||
| ones as usual. | ||||
| uint8 CipherSuite[2]; /* Cryptographic suite selector */ | uint8 CipherSuite[2]; /* Cryptographic suite selector */ | |||
| The client hello includes a list of compression algorithms supported | The client hello includes a list of compression algorithms supported | |||
| by the client, ordered according to the client's preference. | by the client, ordered according to the client's preference. | |||
| enum { null(0), (255) } CompressionMethod; | enum { null(0), (255) } CompressionMethod; | |||
| struct { | struct { | |||
| ProtocolVersion client_version; | ProtocolVersion client_version; | |||
| Random random; | Random random; | |||
| SessionID session_id; | SessionID session_id; | |||
| CipherSuite cipher_suites<2..2^16-1>; | CipherSuite cipher_suites<2..2^16-2>; | |||
| CompressionMethod compression_methods<1..2^8-1>; | CompressionMethod compression_methods<1..2^8-1>; | |||
| select (extensions_present) { | ||||
| case false: | ||||
| struct {}; | ||||
| case true: | ||||
| Extension extensions<0..2^16-1>; | ||||
| }; | ||||
| } ClientHello; | } ClientHello; | |||
| TLS allows extensions to follow the compression_methods field in an | ||||
| extensions block. The presence of extensions can be detected by | ||||
| determining whether there are bytes following the compression_methods | ||||
| at the end of the ClientHello. Note that this method of detecting | ||||
| optional data differs from the normal TLS method of having a | ||||
| variable-length field but is used for compatibility with TLS 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 | (highest valued) version supported by the client. For this version | |||
| version of the specification, the version will be 3.2. (See | of the specification, the version will be 3.3 (See Appendix E for | |||
| Appendix E for details about backward compatibility.) | details about backward compatibility). | |||
| random | random | |||
| A client-generated random structure. | A client-generated random structure. | |||
| session_id | session_id | |||
| The ID of a session the client wishes to use for this connection. | The ID of a session the client wishes to use for this connection. | |||
| This field should be empty if no session_id is available or if the | This field is empty if no session_id is available, or it 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. | |||
| After sending the client hello message, the client waits for a server | extensions | |||
| hello message. Any other handshake message returned by the server | Clients MAY request extended functionality from servers by sending | |||
| except for a hello request is treated as a fatal error. | data in the extensions Here the new "extensions" field contains a | |||
| list of extensions. The actual "Extension" format is defined in | ||||
| Section 7.4.1.4. | ||||
| Forward compatibility note: In the interests of forward | In the event that a client requests additional functionality using | |||
| compatibility, it is permitted that a client hello message include | extensions, and this functionality is not supplied by the server, the | |||
| extra data after the compression methods. This data MUST be included | client MAY abort the handshake. A server MUST accept client hello | |||
| in the handshake hashes, but must otherwise be ignored. This is the | messages both with and without the extensions field, and (as for all | |||
| only handshake message for which this is legal; for all other | other messages) MUST check that the amount of data in the message | |||
| messages, the amount of data in the message MUST match the | precisely matches one of these formats; if not, then it MUST send a | |||
| description of the message precisely. | fatal "decode_error" alert. | |||
| Note: For the intended use of trailing data in the ClientHello, | After sending the client hello message, the client waits for a server | |||
| see RFC 3546 [TLSEXT]. | hello message. Any other handshake message returned by the server | |||
| except for a hello request is treated as a fatal error. | ||||
| 7.4.1.3. Server Hello | 7.4.1.3. Server Hello | |||
| The server will send this message in response to a client hello | When this message will be sent: | |||
| 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 failure | The server will send this message in response to a client hello | |||
| alert. | 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 | ||||
| failure alert. | ||||
| Structure of this message: | Structure of this message: | |||
| struct { | struct { | |||
| ProtocolVersion server_version; | ProtocolVersion server_version; | |||
| Random random; | Random random; | |||
| SessionID session_id; | SessionID session_id; | |||
| CipherSuite cipher_suite; | CipherSuite cipher_suite; | |||
| CompressionMethod compression_method; | CompressionMethod compression_method; | |||
| } ServerHello; | select (extensions_present) { | |||
| case false: | ||||
| struct {}; | ||||
| case true: | ||||
| Extension extensions<0..2^16-1>; | ||||
| }; | ||||
| } ServerHello; | ||||
| The presence of extensions can be detected by determining whether | ||||
| there are bytes following the compression_method field at the end of | ||||
| 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.2. (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. | originally negotiated with. Note that there is no requirement that | |||
| the server resume any session even if it had formerly provided a | ||||
| session_id. Client MUST be prepared to do a full 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 | ClientHello.cipher_suites. For resumed sessions, this field is the | |||
| the value from the state of the session being resumed. | value from the state of the session being resumed. | |||
| compression_method The single compression algorithm selected by the | compression_method | |||
| server from the list in ClientHello.compression_methods. For | The single compression algorithm selected by the server from the | |||
| resumed sessions this field is the value from the resumed session | list in ClientHello.compression_methods. For resumed sessions this | |||
| state. | field is the value from the resumed session state. | |||
| 7.4.2. Server Certificate | extensions | |||
| A list of extensions. Note that only extensions offered by the | ||||
| client can appear in the server's list. | ||||
| When this message will be sent: | 7.4.1.4 Hello Extensions | |||
| The server MUST send a certificate whenever the agreed-upon key | The extension format is: | |||
| exchange method is not an anonymous one. This message will always | ||||
| immediately follow the server hello message. | ||||
| Meaning of this message: | struct { | |||
| ExtensionType extension_type; | ||||
| opaque extension_data<0..2^16-1>; | ||||
| } Extension; | ||||
| The certificate type MUST be appropriate for the selected cipher | enum { | |||
| suite's key exchange algorithm, and is generally an X.509v3 | signature_algorithms(TBD-BY-IANA), (65535) | |||
| certificate. It MUST contain a key that matches the key exchange | } ExtensionType; | |||
| method, as follows. Unless otherwise specified, the signing | ||||
| algorithm for the certificate MUST be the same as the algorithm | ||||
| for the certificate key. Unless otherwise specified, the public | ||||
| key MAY be of any length. | ||||
| Key Exchange Algorithm Certificate Key Type | Here: | |||
| RSA RSA public key; the certificate MUST | - "extension_type" identifies the particular extension type. | |||
| allow the key to be used for encryption. | ||||
| DHE_DSS DSS public key. | - "extension_data" contains information specific to the particular | |||
| extension type. | ||||
| DHE_RSA RSA public key that can be used for | The initial set of extensions is defined in a companion document | |||
| signing. | [TLSEXT]. The list of extension types is maintained by IANA as | |||
| described in Section 12. | ||||
| DH_DSS Diffie-Hellman key. The algorithm used | There are subtle (and not so subtle) interactions that may occur in | |||
| to sign the certificate MUST be DSS. | this protocol between new features and existing features which may | |||
| result in a significant reduction in overall security, The following | ||||
| considerations should be taken into account when designing new | ||||
| extensions: | ||||
| DH_RSA Diffie-Hellman key. The algorithm used | - Some cases where a server does not agree to an extension are error | |||
| to sign the certificate MUST be RSA. | conditions, and some simply a refusal to support a particular | |||
| feature. In general error alerts should be used for the former, | ||||
| and a field in the server extension response for the latter. | ||||
| All certificate profiles and key and cryptographic formats are | - Extensions should as far as possible be designed to prevent any | |||
| defined by the IETF PKIX working group [PKIX]. When a key usage | attack that forces use (or non-use) of a particular feature by | |||
| extension is present, the digitalSignature bit MUST be set for the | manipulation of handshake messages. This principle should be | |||
| key to be eligible for signing, as described above, and the | followed regardless of whether the feature is believed to cause a | |||
| keyEncipherment bit MUST be present to allow encryption, as described | security problem. | |||
| above. The keyAgreement bit must be set on Diffie-Hellman | ||||
| certificates. | ||||
| As CipherSuites that specify new key exchange methods are specified | Often the fact that the extension fields are included in the | |||
| for the TLS Protocol, they will imply certificate format and the | inputs to the Finished message hashes will be sufficient, but | |||
| required encoded keying information. | extreme care is needed when the extension changes the meaning of | |||
| messages sent in the handshake phase. Designers and implementors | ||||
| should be aware of the fact that until the handshake has been | ||||
| authenticated, active attackers can modify messages and insert, | ||||
| remove, or replace extensions. | ||||
| - It would be technically possible to use extensions to change major | ||||
| aspects of the design of TLS; for example the design of cipher | ||||
| suite negotiation. This is not recommended; it would be more | ||||
| appropriate to define a new version of TLS - particularly since | ||||
| the TLS handshake algorithms have specific protection against | ||||
| version rollback attacks based on the version number, and the | ||||
| possibility of version rollback should be a significant | ||||
| consideration in any major design change. | ||||
| 7.4.1.4.1 Signature Algorithms | ||||
| The client uses the "signature_algorithms" extension to indicate to | ||||
| the server which signature/hash algorithm pairs may be used in | ||||
| digital signatures. The "extension_data" field of this extension | ||||
| contains a "supported_signature_algorithms" value. | ||||
| enum { | ||||
| none(0), md5(1), sha1(2), sha256(3), sha384(4), | ||||
| sha512(5), (255) | ||||
| } HashAlgorithm; | ||||
| enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } | ||||
| SignatureAlgorithm; | ||||
| struct { | ||||
| HashAlgorithm hash; | ||||
| SignatureAlgorithm signature; | ||||
| } SignatureAndHashAlgorithm; | ||||
| SignatureAndHashAlgorithm | ||||
| supported_signature_algorithms<2..2^16-2>; | ||||
| Each SignatureAndHashAlgorithm value lists a single hash/signature | ||||
| pair which the client is willing to verify. The values are indicated | ||||
| in descending order of preference. | ||||
| Note: Because not all signature algorithms and hash algorithms may be | ||||
| accepted by an implementation (e.g., DSA with SHA-1, but not | ||||
| SHA-256), algorithms here are listed in pairs. | ||||
| hash | ||||
| This field indicates the hash algorithm which may be used. The | ||||
| values indicate support for unhashed data, MD5 [MD5], SHA-1, | ||||
| SHA-256, SHA-384, and SHA-512 [SHA] respectively. The "none" value | ||||
| is provided for future extensibility, in case of a signature | ||||
| algorithm which does not require hashing before signing. | ||||
| signature | ||||
| This field indicates the signature algorithm which may be used. | ||||
| The values indicate anonymous signatures, RSASSA-PKCS1-v1_5 | ||||
| [PKCS1] and DSA [DSS] respectively. The "anonymous" value is | ||||
| meaningless in this context but used in Section 7.4.3. It MUST NOT | ||||
| appear in this extension. | ||||
| The semantics of this extension are somewhat complicated because the | ||||
| cipher suite indicates permissible signature algorithms but not hash | ||||
| algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate rules. | ||||
| If the client supports only the default hash and signature algorithms | ||||
| (listed in this section), it MAY omit the signature_algorithms | ||||
| extension. If the client does not support the default algorithms, or | ||||
| supports other hash and signature algorithms (and it is willing to | ||||
| use them for verifying messages sent by server; server certificates | ||||
| and server key exchange), it MUST send the signature_algorithms | ||||
| extension listing the algorithms it is willing to accept. | ||||
| If the client does not send the signature_algorithms extension, the | ||||
| server MUST assume the following: | ||||
| - 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 | ||||
| the value (sha1,rsa). | ||||
| - If the negotiated key exchange algorithm is one of (DHE_DSS, | ||||
| DH_DSS), behave as if the client had sent the value (sha1,dsa). | ||||
| - If the negotiated key exchange algorithm is one of (ECDH_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 | ||||
| but as a practical matter one can assume that the peer supports MD5 | ||||
| and SHA-1. | ||||
| Note: this extension is not meaningful for TLS versions prior to 1.2. | ||||
| Clients MUST NOT offer it if they are offering prior versions. | ||||
| However, even if clients do offer it, the rules specified in [TLSEXT] | ||||
| require servers to ignore extensions they do not understand. | ||||
| Servers MUST NOT send this extension. TLS servers MUST support | ||||
| receiving this extension. | ||||
| 7.4.2. Server Certificate | ||||
| When this message will be sent: | ||||
| The server MUST send a certificate whenever the agreed-upon key | ||||
| exchange method uses certificates for authentication (this | ||||
| includes all key exchange methods defined in this document except | ||||
| DH_anon). This message will always immediately follow the server | ||||
| hello message. | ||||
| Meaning of this message: | ||||
| This message conveys the server's certificate chain to the client. | ||||
| The certificate MUST be appropriate for the negotiated cipher | ||||
| 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 X.509v3 certificates. The sender's | This is a sequence (chain) of certificates. The sender's | |||
| certificate must come first in the list. Each following | certificate MUST come first in the list. Each following | |||
| certificate must directly certify the one preceding it. Because | certificate MUST directly certify the one preceding it. Because | |||
| certificate validation requires that root keys be distributed | certificate validation requires that root keys be distributed | |||
| independently, the self-signed certificate that specifies the root | independently, the self-signed certificate that specifies the root | |||
| certificate authority may optionally be omitted from the chain, | certificate authority MAY optionally be omitted from the chain, | |||
| under the assumption that the remote end must already possess it | under the assumption that the remote end must already possess it | |||
| in order to validate it in any case. | in order to validate it in any case. | |||
| The same message type and structure will be used for the client's | The same message type and structure will be used for the client's | |||
| response to a certificate request message. Note that a client MAY | response to a certificate request message. Note that a client MAY | |||
| send no certificates if it does not have an appropriate certificate | send no certificates if it does not have an appropriate certificate | |||
| to send in response to the server's authentication request. | to send in response to the server's authentication request. | |||
| Note: PKCS #7 [PKCS7] is not used as the format for the | Note: PKCS #7 [PKCS7] is not used as the format for the certificate | |||
| certificate vector because PKCS #6 [PKCS6] extended | vector because PKCS #6 [PKCS6] extended certificates are not used. | |||
| certificates are not used. Also, PKCS #7 defines a SET rather | Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task | |||
| than a SEQUENCE, making the task of parsing the list more | of parsing the list more difficult. | |||
| difficult. | ||||
| The following rules apply to the certificates sent by the server: | ||||
| - The certificate type MUST be X.509v3, unless explicitly negotiated | ||||
| otherwise (e.g., [TLSPGP]). | ||||
| - The end entity certificate's public key (and associated | ||||
| restrictions) MUST be compatible with the selected key exchange | ||||
| algorithm. | ||||
| Key Exchange Alg. Certificate Key Type | ||||
| RSA RSA public key; the certificate MUST | ||||
| RSA_PSK allow the key to be used for encryption | ||||
| (the keyEncipherment bit MUST be set | ||||
| if the key usage extension is present). | ||||
| Note: RSA_PSK is defined in [TLSPSK]. | ||||
| DHE_RSA RSA public key; the certificate MUST | ||||
| ECDHE_RSA allow the key to be used for signing | ||||
| (the digitalSignature bit MUST be set | ||||
| if the key usage extension is present) | ||||
| with the signature scheme and hash | ||||
| algorithm that will be employed in the | ||||
| server key exchange message. | ||||
| DHE_DSS DSA public key; the certificate MUST | ||||
| allow the key to be used for signing with | ||||
| the hash algorithm that will be employed | ||||
| in the server key exchange message. | ||||
| DH_DSS Diffie-Hellman public key; the | ||||
| DH_RSA keyAgreement bit MUST be set if the | ||||
| key usage extension is present. | ||||
| ECDH_ECDSA ECDH-capable public key; the public key | ||||
| ECDH_RSA MUST use a curve and point format supported | ||||
| by the client, as described in [TLSECC]. | ||||
| ECDHE_ECDSA ECDSA-capable public key; the certificate | ||||
| MUST allow the key to be used for signing | ||||
| with the hash algorithm that will be | ||||
| employed in the server key exchange | ||||
| message. The public key MUST use a curve | ||||
| and point format supported by the client, | ||||
| as described in [TLSECC]. | ||||
| - The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are | ||||
| used to guide certificate selection. | ||||
| If the client provided a "signature_algorithms" extension, then all | ||||
| certificates provided by the server MUST be signed by a | ||||
| hash/signature algorithm pair that appears in that extension. Note | ||||
| that this implies that a certificate containing a key for one | ||||
| signature algorithm MAY be signed using a different signature | ||||
| algorithm (for instance, an RSA key signed with a DSA key.) This is a | ||||
| departure from TLS 1.1, which required that the algorithms be the | ||||
| same. Note that this also implies that the DH_DSS, DH_RSA, | ||||
| ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the | ||||
| algorithm used to sign the certificate. Fixed DH certificates MAY be | ||||
| signed with any hash/signature algorithm pair appearing in the | ||||
| extension. The naming is historical. | ||||
| If the server has multiple certificates, it chooses one of them based | ||||
| on the above-mentioned criteria (in addition to other criteria, such | ||||
| as transport layer endpoint, local configuration and preferences, | ||||
| etc.). If the server has a single certificate it SHOULD attempt to | ||||
| validate that it meets these criteria. | ||||
| Note that there are certificates that use algorithms and/or algorithm | ||||
| combinations that cannot be currently used with TLS. For example, a | ||||
| certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in | ||||
| SubjectPublicKeyInfo) cannot be used because TLS defines no | ||||
| corresponding signature algorithm. | ||||
| As cipher suites that specify new key exchange methods are specified | ||||
| for the TLS Protocol, they will imply certificate format and the | ||||
| required encoded keying information. | ||||
| 7.4.3. Server Key Exchange Message | 7.4.3. Server Key Exchange Message | |||
| When this message will be sent: | When this message will be sent: | |||
| This message will be sent immediately after the server certificate | This message will be sent immediately after the server certificate | |||
| message (or the server hello message, if this is an anonymous | message (or the server hello message, if this is an anonymous | |||
| negotiation). | negotiation). | |||
| The server key exchange message is sent by the server only when | The server key exchange message is sent by the server only when | |||
| the server certificate message (if sent) does not contain enough | the server certificate message (if sent) does not contain enough | |||
| data to allow the client to exchange a premaster secret. This is | data to allow the client to exchange a premaster secret. This is | |||
| true for the following key exchange methods: | true for the following key exchange methods: | |||
| DHE_DSS | DHE_DSS | |||
| DHE_RSA | DHE_RSA | |||
| DH_anon | DH_anon | |||
| It is not legal to send the server key exchange message for the | It is not legal to send the server key exchange message for the | |||
| following key exchange methods: | following key exchange methods: | |||
| RSA | RSA | |||
| DH_DSS | DH_DSS | |||
| DH_RSA | DH_RSA | |||
| Meaning of this message: | Meaning of this message: | |||
| This message conveys cryptographic information to allow the client | This message conveys cryptographic information to allow the client | |||
| to communicate the premaster secret: either an RSA public key with | to communicate the premaster secret: a Diffie-Hellman public key | |||
| which to encrypt the premaster secret, or a Diffie-Hellman public | with which the client can complete a key exchange (with the result | |||
| key with which the client can complete a key exchange (with the | being the premaster secret) or a public key for some other | |||
| result being the premaster secret). | algorithm. | |||
| As additional CipherSuites are defined for TLS that include new key | ||||
| exchange algorithms, the server key exchange message will be sent if | ||||
| and only if the certificate type associated with the key exchange | ||||
| algorithm does not provide enough information for the client to | ||||
| exchange a premaster secret. | ||||
| Structure of this message: | Structure of this message: | |||
| enum { rsa, diffie_hellman } KeyExchangeAlgorithm; | enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa } | |||
| KeyExchangeAlgorithm; | ||||
| struct { | ||||
| opaque rsa_modulus<1..2^16-1>; | ||||
| opaque rsa_exponent<1..2^16-1>; | ||||
| } ServerRSAParams; | ||||
| rsa_modulus | ||||
| The modulus of the server's temporary RSA key. | ||||
| rsa_exponent | ||||
| The public exponent of the server's temporary RSA key. | ||||
| struct { | struct { | |||
| opaque dh_p<1..2^16-1>; | opaque dh_p<1..2^16-1>; | |||
| opaque dh_g<1..2^16-1>; | opaque dh_g<1..2^16-1>; | |||
| opaque dh_Ys<1..2^16-1>; | opaque dh_Ys<1..2^16-1>; | |||
| } ServerDHParams; /* Ephemeral DH parameters */ | } ServerDHParams; /* Ephemeral DH parameters */ | |||
| dh_p | dh_p | |||
| The prime modulus used for the Diffie-Hellman operation. | The prime modulus used for the Diffie-Hellman operation. | |||
| dh_g | dh_g | |||
| The generator used for the Diffie-Hellman operation. | The generator used for the Diffie-Hellman operation. | |||
| dh_Ys | dh_Ys | |||
| The server's Diffie-Hellman public value (g^X mod p). | The server's Diffie-Hellman public value (g^X mod p). | |||
| struct { | struct { | |||
| select (KeyExchangeAlgorithm) { | select (KeyExchangeAlgorithm) { | |||
| case diffie_hellman: | case dh_anon: | |||
| ServerDHParams params; | ServerDHParams params; | |||
| Signature signed_params; | case dhe_dss: | |||
| case rsa: | case dhe_rsa: | |||
| ServerRSAParams params; | ||||
| Signature signed_params; | ||||
| }; | ||||
| } ServerKeyExchange; | ||||
| struct { | ||||
| select (KeyExchangeAlgorithm) { | ||||
| case diffie_hellman: | ||||
| ServerDHParams params; | ServerDHParams params; | |||
| digitally-signed struct { | ||||
| opaque client_random[32]; | ||||
| opaque server_random[32]; | ||||
| ServerDHParams params; | ||||
| } signed_params; | ||||
| case rsa: | case rsa: | |||
| ServerRSAParams params; | case dh_dss: | |||
| case dh_rsa: | ||||
| struct {} ; | ||||
| /* message is omitted for rsa, dh_dss, and dh_rsa */ | ||||
| }; | }; | |||
| } ServerParams; | } ServerKeyExchange; | |||
| params | params | |||
| The server's key exchange parameters. | The server's key exchange parameters. | |||
| signed_params | signed_params | |||
| For non-anonymous key exchanges, a hash of the corresponding | For non-anonymous key exchanges, a signature over the | |||
| params value, with the signature appropriate to that hash | server's key exchange parameters. | |||
| applied. | ||||
| md5_hash | If the client has offered the "signature_algorithms" extension, the | |||
| MD5(ClientHello.random + ServerHello.random + ServerParams); | signature algorithm and hash algorithm MUST be a pair listed in that | |||
| extension. Note that there is a possibility for inconsistencies here. | ||||
| For instance, the client might offer DHE_DSS key exchange but omit | ||||
| any DSS pairs from its "signature_algorithms" extension. In order to | ||||
| negotiate correctly, the server MUST check any candidate cipher | ||||
| suites against the "signature_algorithms" extension before selecting | ||||
| them. This is somewhat inelegant but is a compromise designed to | ||||
| minimize changes to the original cipher suite design. | ||||
| sha_hash | In addition, the hash and signature algorithms MUST be compatible | |||
| SHA(ClientHello.random + ServerHello.random + ServerParams); | with the key in the server's end-entity certificate. RSA keys MAY be | |||
| used with any permitted hash algorithm, subject to restrictions in | ||||
| the certificate, if any. | ||||
| enum { anonymous, rsa, dsa } SignatureAlgorithm; | Because DSA signatures do not contain any secure indication of hash | |||
| algorithm, there is a risk of hash substitution if multiple hashes | ||||
| may be used with any key. Currently, DSS [DSS] may only be used with | ||||
| SHA-1. Future revisions of DSS [DSS-3] are expected to allow other | ||||
| digest algorithms, as well as guidance as to which digest algorithms | ||||
| should be used with each key size. In addition, future revisions of | ||||
| struct { | [PKIX] may specify mechanisms for certificates to indicate which | |||
| select (SignatureAlgorithm) { | digest algorithms are to be used with DSA. | |||
| case anonymous: struct { }; | ||||
| case rsa: | ||||
| digitally-signed struct { | ||||
| opaque md5_hash[16]; | ||||
| opaque sha_hash[20]; | ||||
| }; | ||||
| case dsa: | ||||
| digitally-signed struct { | ||||
| opaque sha_hash[20]; | ||||
| }; | ||||
| }; | ||||
| }; | ||||
| } Signature; | ||||
| 7.4.4. Certificate request | As additional cipher suites are defined for TLS that include new key | |||
| exchange algorithms, the server key exchange message will be sent if | ||||
| and only if the certificate type associated with the key exchange | ||||
| algorithm does not provide enough information for the client to | ||||
| exchange a premaster secret. | ||||
| When this message will be sent: | 7.4.4. Certificate Request | |||
| A non-anonymous server can optionally request a certificate from | When this message will be sent: | |||
| the client, if it is appropriate for the selected cipher suite. | ||||
| This message, if sent, will immediately follow the Server Key | A non-anonymous server can optionally request a certificate from | |||
| Exchange message (if it is sent; otherwise, the Server Certificate | the client, if appropriate for the selected cipher suite. This | |||
| message). | message, if sent, will immediately follow the Server Key Exchange | |||
| message (if it is sent; otherwise, the Server 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), | 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>; | |||
| SignatureAndHashAlgorithm | ||||
| supported_signature_algorithms<2^16-1>; | ||||
| DistinguishedName certificate_authorities<0..2^16-1>; | DistinguishedName certificate_authorities<0..2^16-1>; | |||
| } CertificateRequest; | } CertificateRequest; | |||
| certificate_types | certificate_types | |||
| This field is a list of the types of certificates requested, | A list of the types of certificate types which the client may | |||
| sorted in order of the server's preference. | offer. | |||
| certificate_authorities | rsa_sign a certificate containing an RSA key | |||
| A list of the distinguished names of acceptable certificate | dss_sign a certificate containing a DSS key | |||
| authorities. These distinguished names may specify a desired | rsa_fixed_dh a certificate containing a static DH key. | |||
| distinguished name for a root CA or for a subordinate CA; thus, | dss_fixed_dh a certificate containing a static DH key | |||
| this message can be used to describe both known roots and a | ||||
| desired authorization space. If the certificate_authorities | ||||
| list is empty then the client MAY send any certificate of the | ||||
| appropriate ClientCertificateType, unless there is some | ||||
| external arrangement to the contrary. | ||||
| ClientCertificateType values are divided into three groups: | supported_signature_algorithms | |||
| A list of the hash/signature algorithm pairs that the server is | ||||
| able to verify, listed in descending order of preference. | ||||
| 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are | certificate_authorities | |||
| reserved for IETF Standards Track protocols. | A list of the distinguished names [X501] of acceptable | |||
| certificate_authorities, represented in DER-encoded format. These | ||||
| distinguished names may specify a desired distinguished name for a | ||||
| root CA or for a subordinate CA; thus, this message can be used | ||||
| both to describe known roots and a desired authorization space. If | ||||
| the certificate_authorities list is empty then the client MAY send | ||||
| any certificate of the appropriate ClientCertificateType, unless | ||||
| there is some external arrangement to the contrary. | ||||
| 2. Values from 64 decimal (0x40) through 223 decimal (0xDF) | The interaction of the certificate_types and | |||
| inclusive are reserved for assignment for non-Standards Track | supported_signature_algorithms fields is somewhat complicated. | |||
| methods. | certificate_types has been present in TLS since SSLv3, but was | |||
| somewhat underspecified. Much of its functionality is superseded by | ||||
| supported_signature_algorithms. The following rules apply: | ||||
| 3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) | - Any certificates provided by the client MUST be signed using a | |||
| inclusive are reserved for private use. | hash/signature algorithm pair found in | |||
| supported_signature_algorithms. | ||||
| Additional information describing the role of IANA in the allocation | - The end-entity certificate provided by the client MUST contain a | |||
| of ClientCertificateType code points is described in Section 11. | key which is compatible with certificate_types. If the key is a | |||
| signature key, it MUST be usable with some hash/signature | ||||
| algorithm pair in supported_signature_algorithms. | ||||
| Note: Values listed as RESERVED may not be used. They were used in | - For historical reasons, the names of some client certificate types | |||
| SSLv3. | include the algorithm used to sign the certificate. For example, | |||
| in earlier versions of TLS, rsa_fixed_dh meant a certificate | ||||
| signed with RSA and containing a static DH key. In TLS 1.2, this | ||||
| functionality has been obsoleted by the | ||||
| supported_signature_algorithms, and the certificate type no longer | ||||
| restricts the algorithm used to sign the certificate. For | ||||
| example, if the server sends dss_fixed_dh certificate type and | ||||
| {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply | ||||
| with a certificate containing a static DH key, signed with RSA- | ||||
| SHA1. | ||||
| Note: DistinguishedName is derived from [X501]. DistinguishedNames | New ClientCertificateType values are assigned by IANA as described in | |||
| are represented in DER-encoded format. | Section 12. | |||
| Note: It is a fatal handshake_failure alert for an anonymous server | Note: Values listed as RESERVED may not be used. They were used in | |||
| to request client authentication. | SSLv3. | |||
| 7.4.5. Server Hello Done | Note: It is a fatal handshake_failure alert for an anonymous server | |||
| to request client authentication. | ||||
| 7.4.5 Server hello done | ||||
| When this message will be sent: | When this message will be sent: | |||
| The server hello done message is sent by the server to indicate | The server hello done message is sent by the server to indicate | |||
| the end of the server hello and associated messages. After | the end of the server hello and associated messages. After sending | |||
| sending this 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 server hello done message, the client SHOULD | Upon receipt of the server hello done 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 hello done message. This message is only sent if the server | |||
| server requests a certificate. If no suitable certificate is | requests a certificate. If no suitable certificate is available, | |||
| available, the client SHOULD send a certificate message containing | the client MUST send a certificate message containing no | |||
| no certificates. That is, the certificate_list structure has a | certificates. That is, the certificate_list structure has a length | |||
| length of zero. If client authentication is required by the | of zero. If the client does not send any certificates, the server | |||
| server for the handshake to continue, it may respond with a fatal | MAY at its discretion either continue the handshake without client | |||
| handshake failure alert. Client certificates are sent using the | authentication, or respond with a fatal handshake_failure alert. | |||
| Certificate structure defined in Section 7.4.2. | Also, if some aspect of the certificate chain was unacceptable | |||
| (e.g., it was not signed by a known, trusted CA), the server MAY | ||||
| at its discretion either continue the handshake (considering the | ||||
| client unauthenticated) or send a fatal alert. | ||||
| Note: When using a static Diffie-Hellman based key exchange method | Client certificates are sent using the Certificate structure | |||
| (DH_DSS or DH_RSA), if client authentication is requested, the | defined in Section 7.4.2. | |||
| Diffie-Hellman group and generator encoded in the client's | ||||
| certificate MUST match the server specified Diffie-Hellman | Meaning of this message: | |||
| parameters if the client's parameters are to be used for the key | ||||
| exchange. | This message conveys the client's certificate chain to the server; | |||
| the server will use it when verifying the certificate verify | ||||
| message (when the client authentication is based on signing), or | ||||
| calculate the premaster secret (for non-ephemeral Diffie-Hellman). | ||||
| The certificate MUST be appropriate for the negotiated cipher | ||||
| suite's key exchange algorithm, and any negotiated extensions. | ||||
| In particular: | ||||
| - The certificate type MUST be X.509v3, unless explicitly negotiated | ||||
| otherwise (e.g. [TLSPGP]). | ||||
| - The end-entity certificate's public key (and associated | ||||
| restrictions) has to be compatible with the certificate types | ||||
| listed in CertificateRequest: | ||||
| Client Cert. Type Certificate Key Type | ||||
| rsa_sign RSA public key; the certificate MUST allow | ||||
| the key to be used for signing with the | ||||
| signature scheme and hash algorithm that | ||||
| will be employed in the certificate verify | ||||
| message. | ||||
| dss_sign DSA public key; the certificate MUST allow | ||||
| the key to be used for signing with the | ||||
| hash algorithm that will be employed in | ||||
| the certificate verify message. | ||||
| ecdsa_sign ECDSA-capable public key; the certificate | ||||
| MUST allow the key to be used for signing | ||||
| with the hash algorithm that will be | ||||
| employed in the certificate verify | ||||
| message; the public key MUST use a | ||||
| curve and point format supported by the | ||||
| server. | ||||
| rsa_fixed_dh Diffie-Hellman public key; MUST use | ||||
| dss_fixed_dh the same parameters as server's key. | ||||
| rsa_fixed_ecdh ECDH-capable public key; MUST use | ||||
| ecdsa_fixed_ecdh the same curve as server's key, and | ||||
| MUST use a point format supported by | ||||
| the server. | ||||
| - If the certificate_authorities list in the certificate request | ||||
| message was non-empty, one of the certificates in the certificate | ||||
| chain SHOULD be issued by one of the listed CAs. | ||||
| - The certificates MUST be signed using an acceptable hash/ | ||||
| signature algorithm pair, as described in Section 7.4.4. Note that | ||||
| this relaxes the constraints on certificate signing algorithms | ||||
| found in prior versions of TLS. | ||||
| Note that as with the server certificate, there are certificates that | ||||
| use algorithms/algorithm combinations that cannot be currently used | ||||
| with TLS. | ||||
| 7.4.7. Client Key Exchange Message | 7.4.7. Client Key Exchange Message | |||
| When this message will be sent: | When this message will be sent: | |||
| This message is always sent by the client. It MUST immediately | This message is always sent by the client. It MUST immediately | |||
| follow the client certificate message, if it is sent. Otherwise | follow the client certificate message, if it is sent. Otherwise it | |||
| it MUST be the first message sent by the client after it receives | MUST be the first message sent by the client after it receives the | |||
| the server hello done message. | server hello done message. | |||
| Meaning of this message: | Meaning of this message: | |||
| With this message, the premaster secret is set, either though | With this message, the premaster secret is set, either though | |||
| direct transmission of the RSA-encrypted secret or by the | direct transmission of the RSA-encrypted secret, or by the | |||
| transmission of Diffie-Hellman parameters that will allow each | transmission of Diffie-Hellman parameters that will allow each | |||
| side to agree upon the same premaster secret. When the key | side to agree upon the same premaster secret. | |||
| exchange method is DH_RSA or DH_DSS, client certification has been | ||||
| requested, and the client was able to respond with a certificate | When the client is using an ephemeral Diffie-Hellman exponent, | |||
| that contained a Diffie-Hellman public key whose parameters (group | then this message contains the client's Diffie-Hellman public | |||
| and generator) matched those specified by the server in its | value. If the client is sending a certificate containing a static | |||
| certificate, this message MUST not contain any data. | DH exponent (i.e., it is doing fixed_dh client authentication) | |||
| then this message MUST be sent but MUST be empty. | ||||
| Structure of this message: | Structure of this message: | |||
| The choice of messages depends on which key exchange method has | The choice of messages depends on which key exchange method has | |||
| been selected. See Section 7.4.3 for the KeyExchangeAlgorithm | been selected. See Section 7.4.3 for the KeyExchangeAlgorithm | |||
| definition. | definition. | |||
| struct { | struct { | |||
| select (KeyExchangeAlgorithm) { | select (KeyExchangeAlgorithm) { | |||
| case rsa: EncryptedPreMasterSecret; | case rsa: | |||
| case diffie_hellman: ClientDiffieHellmanPublic; | EncryptedPreMasterSecret; | |||
| case dhe_dss: | ||||
| case dhe_rsa: | ||||
| case dh_dss: | ||||
| case dh_rsa: | ||||
| case dh_anon: | ||||
| ClientDiffieHellmanPublic; | ||||
| } exchange_keys; | } exchange_keys; | |||
| } ClientKeyExchange; | } ClientKeyExchange; | |||
| 7.4.7.1. RSA Encrypted Premaster Secret Message | 7.4.7.1. RSA Encrypted Premaster Secret Message | |||
| Meaning of this message: | Meaning of this message: | |||
| If RSA is being used for key agreement and authentication, the | If RSA is being used for key agreement and authentication, the | |||
| client generates a 48-byte premaster secret, encrypts it using the | client generates a 48-byte premaster secret, encrypts it using the | |||
| public key from the server's certificate or the temporary RSA key | public key from the server's certificate and sends the result in | |||
| provided in a server key exchange message, 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 client key exchange message and is not a message in itself. | |||
| variant of the client key exchange 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 The latest (newest) version supported by the | client_version | |||
| client. This is used to detect version roll-back attacks. | The latest (newest) version supported by the client. This is | |||
| Upon receiving the premaster secret, the server SHOULD check | used to detect version roll-back attacks. | |||
| that this value matches the value transmitted by the client in | ||||
| the client hello message. | ||||
| 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: An attack discovered by Daniel Bleichenbacher [BLEI] can be | Note: The version number in the PreMasterSecret is the version | |||
| used to attack a TLS server that is using PKCS#1 v 1.5 encoded | offered by the client in the ClientHello.client_version, not the | |||
| RSA. The attack takes advantage of the fact that, by failing | version negotiated for the connection. This feature is designed to | |||
| in different ways, a TLS server can be coerced into revealing | prevent rollback attacks. Unfortunately, some old implementations | |||
| whether a particular message, when decrypted, is properly | use the negotiated version instead and therefore checking the version | |||
| PKCS#1 v1.5 formatted or not. | number may lead to failure to interoperate with such incorrect client | |||
| implementations. | ||||
| The best way to avoid vulnerability to this attack is to treat | Client implementations MUST always send the correct version number in | |||
| incorrectly formatted messages in a manner indistinguishable | PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, | |||
| from correctly formatted RSA blocks. Thus, when a server | server implementations MUST check the version number as described in | |||
| receives an incorrectly formatted RSA block, it should generate | the note below. If the version number is 1.0 or earlier, server | |||
| a random 48-byte value and proceed using it as the premaster | implementations SHOULD check the version number, but MAY have a | |||
| secret. Thus, the server will act identically whether the | configuration option to disable the check. Note that if the check | |||
| received RSA block is correctly encoded or not. | fails, the PreMasterSecret SHOULD be randomized as described below. | |||
| [PKCS1B] defines a newer version of PKCS#1 encoding that is | Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. | |||
| more secure against the Bleichenbacher attack. However, for | [KPR03] can be used to attack a TLS server that reveals whether a | |||
| maximal compatibility with TLS 1.0, TLS 1.1 retains the | particular message, when decrypted, is properly PKCS#1 formatted, | |||
| original encoding. No variants of the Bleichenbacher attack | contains a valid PreMasterSecret structure, or has the correct | |||
| are known to exist provided that the above recommendations are | version number. | |||
| followed. | ||||
| The best way to avoid these vulnerabilities is to treat incorrectly | ||||
| formatted messages in a manner indistinguishable from correctly | ||||
| formatted RSA blocks. In other words: | ||||
| 1. Generate a string R of 46 random bytes | ||||
| 2. Decrypt the message M | ||||
| 3. If the PKCS#1 padding is not correct, or the length of | ||||
| message M is not exactly 48 bytes: | ||||
| premaster secret = ClientHello.client_version || R | ||||
| else If ClientHello.client_version <= TLS 1.0, and | ||||
| version number check is explicitly disabled: | ||||
| premaster secret = M | ||||
| else: | ||||
| premaster secret = ClientHello.client_version || M[2..47] | ||||
| Note that explicitly constructing the premaster_secret with the | ||||
| ClientHello.client_version produces an invalid master_secret if the | ||||
| client has sent the wrong version in the original premaster_secret. | ||||
| In any case, a TLS server MUST NOT generate an alert if processing an | ||||
| RSA-encrypted premaster secret message fails, or the version number | ||||
| is not as expected. Instead, it MUST continue the handshake with a | ||||
| randomly generated premaster secret. It may be useful to log the | ||||
| real cause of failure for troubleshooting purposes; however, care | ||||
| must be taken to avoid leaking the information to an attacker | ||||
| (through, e.g., timing, log files, or other channels.) | ||||
| The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure | ||||
| against the Bleichenbacher attack. However, for maximal compatibility | ||||
| with earlier versions of TLS, this specification uses the RSAES- | ||||
| PKCS1-v1_5 scheme. No variants of the Bleichenbacher 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). | opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted | |||
| Thus, the RSA-encrypted PreMasterSecret in a | PreMasterSecret in a ClientKeyExchange is preceded by two length | |||
| 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 | EncryptedPreMasterSecret is the only data in the ClientKeyExchange | |||
| RSA because the EncryptedPreMasterSecret is the | and its length can therefore be unambiguously determined. The SSLv3 | |||
| only data in the ClientKeyExchange and its | specification was not clear about the encoding of public-key- | |||
| length can therefore be unambiguously | encrypted data, and therefore many SSLv3 implementations do not | |||
| determined. The SSLv3 specification was not | include the the length bytes, encoding the RSA encrypted data | |||
| clear about the encoding of public-key-encrypted | directly in the ClientKeyExchange message. | |||
| data, and therefore many SSLv3 implementations | ||||
| do not include the length bytes, encoding the | ||||
| RSA encrypted data directly in the | ||||
| ClientKeyExchange message. | ||||
| This specification requires correct encoding of | This specification requires correct encoding of the | |||
| the EncryptedPreMasterSecret complete with | EncryptedPreMasterSecret complete with length bytes. The resulting | |||
| length bytes. The resulting PDU is incompatible | PDU is incompatible with many SSLv3 implementations. Implementors | |||
| with many SSLv3 implementations. Implementors | upgrading from SSLv3 MUST modify their implementations to generate | |||
| upgrading from SSLv3 must modify their | and accept the correct encoding. Implementors who wish to be | |||
| implementations to generate and accept the | compatible with both SSLv3 and TLS should make their implementation's | |||
| correct encoding. Implementors who wish to be | behavior dependent on the protocol version. | |||
| compatible with both SSLv3 and TLS should make | ||||
| their implementation's 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 SSL are possible, at least when the client | on TLS are possible, at least when the client and server are on the | |||
| and server are on the same LAN. Accordingly, | same LAN. Accordingly, implementations that use static RSA keys MUST | |||
| implementations that use static RSA keys SHOULD | use RSA blinding or some other anti-timing technique, as described in | |||
| use RSA blinding or some other anti-timing | [TIMING]. | |||
| technique, as described in [TIMING]. | ||||
| Note: The version number in the PreMasterSecret MUST be the version | ||||
| offered by the client in the ClientHello, not the version | ||||
| negotiated for the connection. This feature is designed to | ||||
| prevent rollback attacks. Unfortunately, many implementations | ||||
| use the negotiated version instead, and therefore checking the | ||||
| version number may lead to failure to interoperate with such | ||||
| incorrect client implementations. Client implementations, MUST | ||||
| and Server implementations MAY, check the version number. In | ||||
| practice, since the TLS handshake MACs prevent downgrade and no | ||||
| good attacks are known on those MACs, ambiguity is not | ||||
| considered a serious security risk. Note that if servers | ||||
| choose to check the version number, they should randomize the | ||||
| PreMasterSecret in case of error, rather than generate an | ||||
| alert, in order to avoid variants on the Bleichenbacher attack. | ||||
| [KPR03] | ||||
| 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 | PublicValueEncoding. This structure is a variant of the client key | |||
| key exchange message and not a message in itself. | 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 certificate already contains a suitable Diffie- | If the client has sent a certificate which contains a suitable | |||
| Hellman key, then Yc is implicit and does not need to be sent | Diffie-Hellman key (for fixed_dh client authentication) then Yc | |||
| again. In this case, the client key exchange message will be | is implicit and does not need to be sent again. In this case, | |||
| sent, but it MUST be empty. | the client key exchange message will be sent, but it MUST 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 { | |||
| Signature signature; | digitally-signed struct { | |||
| opaque handshake_messages[handshake_messages_length]; | ||||
| } | ||||
| } CertificateVerify; | } CertificateVerify; | |||
| The Signature type is defined in 7.4.3. | Here handshake_messages refers to all handshake messages sent or | |||
| received starting at client hello up to but not including this | ||||
| CertificateVerify.signature.md5_hash | message, including the type and length fields of the handshake | |||
| MD5(handshake_messages); | messages. This is the concatenation of all the Handshake | |||
| structures as defined in 7.4 exchanged thus far. Note that this | ||||
| requires both sides to either buffer the messages or compute | ||||
| running hashes for all potential hash algorithms up to the time of | ||||
| the CertificateVerify computation. Servers can minimize this | ||||
| computation cost by offering a restricted set of digest algorithms | ||||
| in the CertificateRequest message. | ||||
| CertificateVerify.signature.sha_hash | The hash and signature algorithms used in the signature MUST be | |||
| SHA(handshake_messages); | one of those present in the supported_signature_algorithms field | |||
| of the CertificateRequest message. In addition, the hash and | ||||
| signature algorithms MUST be compatible with the key in the | ||||
| client's end-entity certificate. RSA keys MAY be used with any | ||||
| permitted hash algorith, subject to restrictions in the | ||||
| certificate, if any. | ||||
| Here handshake_messages refers to all handshake messages sent or | Because DSA signatures do not contain any secure indication of | |||
| received starting at client hello up to but not including this | hash algorithm, there is a risk of hash substitution if multiple | |||
| message, including the type and length fields of the handshake | hashes may be used with any key. Currently, DSS [DSS] may only be | |||
| messages. This is the concatenation of all the Handshake structures, | used with SHA-1. Future revisions of DSS [DSS-3] are expected to | |||
| as defined in 7.4, exchanged thus far. | allow other digest algorithms, as well as guidance as to which | |||
| digest algorithms should be used with each key size. In addition, | ||||
| future revisions of [PKIX] may specify mechanisms for certificates | ||||
| to indicate which digest algorithms are to be used with DSA. | ||||
| 7.4.9. Finished | 7.4.9. Finished | |||
| When this message will be sent: | When this message will be sent: | |||
| A finished message is always sent immediately after a change | A finished message is always sent immediately after a change | |||
| cipher spec message to verify that the key exchange and | cipher spec message to verify that the key exchange and | |||
| authentication processes were successful. It is essential that a | authentication processes were successful. It is essential that a | |||
| change cipher spec message be received between the other handshake | change cipher spec message be received between the other handshake | |||
| messages and the Finished message. | messages and the Finished message. | |||
| Meaning of this message: | Meaning of this message: | |||
| The finished message is the first protected with the just- | The finished message is the first 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: | ||||
| struct { | struct { | |||
| opaque verify_data[12]; | opaque verify_data[verify_data_length]; | |||
| } Finished; | } Finished; | |||
| verify_data | verify_data | |||
| PRF(master_secret, finished_label, MD5(handshake_messages) + | PRF(master_secret, finished_label, Hash(handshake_messages)) | |||
| SHA-1(handshake_messages)) [0..11]; | [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 "client | |||
| finished". For Finished messages sent by the server, the | finished". For Finished messages sent by the server, the string | |||
| string "server finished". | "server finished". | |||
| Hash denotes a Hash of the handshake messages. For the PRF defined | ||||
| in Section 5, the Hash MUST be the Hash used as the basis for the | ||||
| PRF. Any cipher suite which defines a different PRF MUST also | ||||
| define the Hash to use in the Finished computation. | ||||
| In previous versions of TLS, the verify_data was always 12 octets | ||||
| long. In the current version of TLS, it depends on the cipher | ||||
| suite. Any cipher suite which does not explicitly specify | ||||
| verify_data_length has a verify_data_length equal to 12. This | ||||
| includes all existing cipher suites. Note that this | ||||
| representation has the same encoding as with previous versions. | ||||
| Future cipher suites MAY specify other lengths but such length | ||||
| MUST be at least 12 bytes. | ||||
| handshake_messages | handshake_messages | |||
| All of the data from all messages in this handshake (not | All of the data from all messages in this handshake (not | |||
| including any HelloRequest messages) up to but not including | including any HelloRequest messages) up to but not including | |||
| this message. This is only data visible at the handshake | this message. This is only data visible at the handshake layer | |||
| layer and does not include record layer headers. This is the | and does not include record layer headers. This is the | |||
| concatenation of all the Handshake structures, as defined in | concatenation of all the Handshake structures as defined in | |||
| 7.4, exchanged thus far. | 7.4, exchanged thus far. | |||
| It is a fatal error if a finished message is not preceded by a change | It is a fatal error if a finished message is not preceded by a change | |||
| cipher spec message at the appropriate point in the handshake. | cipher spec message at the appropriate point in the handshake. | |||
| The value handshake_messages includes all handshake messages starting | The value handshake_messages includes all handshake messages starting | |||
| at client hello up to, but not including, this finished message. | at client hello up to, but not including, this finished message. This | |||
| This may be different from handshake_messages in Section 7.4.8 | may be different from handshake_messages in Section 7.4.8 because it | |||
| because it would include the certificate verify message (if sent). | would include the certificate verify message (if sent). Also, the | |||
| Also, the handshake_messages for the finished message sent by the | handshake_messages for the finished message sent by the client will | |||
| client will be different from that for the finished message sent by | be different from that for the finished message sent by the server, | |||
| the server, because the one that is sent second will include the | because the one that is sent second will include the prior one. | |||
| prior one. | ||||
| Note: Change cipher spec messages, alerts, and any other record types | Note: Change cipher spec messages, alerts, and any other record types | |||
| are not handshake messages and are not included in the hash | are not handshake messages and are not included in the hash | |||
| computations. Also, Hello Request messages are omitted from | computations. Also, Hello Request messages are omitted from handshake | |||
| handshake hashes. | hashes. | |||
| 8. Cryptographic Computations | 8. Cryptographic Computations | |||
| In order to begin connection protection, the TLS Record Protocol | In order to begin connection protection, the TLS Record Protocol | |||
| requires specification of a suite of algorithms, a master secret, and | requires specification of a suite of algorithms, a master secret, and | |||
| the client and server random values. The authentication, encryption, | the client and server random values. The authentication, encryption, | |||
| and MAC algorithms are determined by the cipher_suite selected by the | and MAC algorithms are determined by the cipher_suite selected by the | |||
| server and revealed in the server hello message. The compression | server and revealed in the server hello message. The compression | |||
| algorithm is negotiated in the hello messages, and the random values | algorithm is negotiated in the hello messages, and the random values | |||
| are exchanged in the hello messages. All that remains is to | are exchanged in the hello messages. All that remains is to calculate | |||
| calculate the master secret. | 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 | The master secret is always exactly 48 bytes in length. The length of | |||
| of the premaster secret will vary depending on key exchange method. | 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 48- | When RSA is used for server authentication and key exchange, a | |||
| byte pre_master_secret is generated by the client, encrypted under | 48-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. | |||
| RSA digital signatures are performed using PKCS #1 [PKCS1] block type | ||||
| 1. RSA public key encryption is performed using PKCS #1 block type 2. | ||||
| 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 | be either ephemeral or contained within the server's certificate. | |||
| 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_3DES_EDE_CBC_SHA. | suite TLS_RSA_WITH_AES_128_CBC_SHA. | |||
| 10. Application Data Protocol | 10. Application Data Protocol | |||
| Application data messages are carried by the Record Layer and are | Application data messages are carried by the Record Layer and are | |||
| fragmented, compressed, and encrypted based on the current connection | fragmented, compressed, and encrypted based on the current connection | |||
| state. The messages are treated as transparent data to the record | state. The messages are treated as transparent data to the record | |||
| layer. | layer. | |||
| 11. Security Considerations | 11. Security Considerations | |||
| Security issues are discussed throughout this memo, especially in | Security issues are discussed throughout this memo, especially in | |||
| Appendices D, E, and F. | Appendices D, E, and F. | |||
| 12. IANA Considerations | 12. IANA Considerations | |||
| This document describes a number of new registries that have been | This document uses several registries that were originally created in | |||
| created by IANA. We recommended that they be placed as individual | [TLS1.1]. IANA is requested to update (has updated) these to | |||
| registries items under a common TLS category. | reference this document. The registries and their allocation policies | |||
| (unchanged from [TLS1.1]) are listed below. | ||||
| Section 7.4.3 describes a TLS ClientCertificateType Registry to be | - TLS ClientCertificateType Identifiers Registry: Future values in | |||
| maintained by the IANA, defining a number of such code point | the range 0-63 (decimal) inclusive are assigned via Standards | |||
| identifiers. ClientCertificateType identifiers with values in the | Action [RFC2434]. Values in the range 64-223 (decimal) inclusive | |||
| range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards | are assigned Specification Required [RFC2434]. Values from 224-255 | |||
| Action. Values from the range 64-223 (decimal) inclusive are | (decimal) inclusive are reserved for Private Use [RFC2434]. | |||
| assigned via [RFC2434] Specification Required. Identifier values | ||||
| from 224-255 (decimal) inclusive are reserved for RFC 2434 Private | ||||
| Use. The registry will initially be populated with the values in | ||||
| this document, Section 7.4.4. | ||||
| Section A.5 describes a TLS Cipher Suite Registry to be maintained by | - TLS Cipher Suite Registry: Future values with the first byte in | |||
| the IANA, and it defines a number of such cipher suite identifiers. | the range 0-191 (decimal) inclusive are assigned via Standards | |||
| Cipher suite values with the first byte in the range 0-191 (decimal) | Action [RFC2434]. Values with the first byte in the range 192-254 | |||
| inclusive are assigned via RFC 2434 Standards Action. Values with | (decimal) are assigned via Specification Required [RFC2434]. | |||
| the first byte in the range 192-254 (decimal) are assigned via RFC | Values with the first byte 255 (decimal) are reserved for Private | |||
| 2434 Specification Required. Values with the first byte 255 | Use [RFC2434]. | |||
| (decimal) are reserved for RFC 2434 Private Use. The registry will | ||||
| initially be populated with the values from Section A.5 of this | ||||
| document, [TLSAES], and from Section 3 of [TLSKRB]. | ||||
| Section 6 requires that all ContentType values be defined by RFC 2434 | - This document defines several new HMAC-SHA256 based cipher suites, | |||
| Standards Action. IANA has created a TLS ContentType registry, | whose values (in Appendix A.5) are to be (have been) allocated | |||
| initially populated with values from Section 6.2.1 of this document. | from the TLS Cipher Suite registry. | |||
| Future values MUST be allocated via Standards Action as described in | ||||
| [RFC2434]. | ||||
| Section 7.2.2 requires that all Alert values be defined by RFC 2434 | - TLS ContentType Registry: Future values are allocated via | |||
| Standards Action. IANA has created a TLS Alert registry, initially | Standards Action [RFC2434]. | |||
| populated with values from Section 7.2 of this document and from | ||||
| Section 4 of [TLSEXT]. Future values MUST be allocated via Standards | ||||
| Action as described in [RFC2434]. | ||||
| Section 7.4 requires that all HandshakeType values be defined by RFC | - TLS Alert Registry: Future values are allocated via Standards | |||
| 2434 Standards Action. IANA has created a TLS HandshakeType | Action [RFC2434]. | |||
| registry, initially populated with values from Section 7.4 of this | ||||
| document and from Section 2.4 of [TLSEXT]. Future values MUST be | - TLS HandshakeType Registry: Future values are allocated via | |||
| allocated via Standards Action as described in [RFC2434]. | Standards Action [RFC2434]. | |||
| This document also uses a registry originally created in [RFC4366]. | ||||
| IANA is requested to update (has updated) it to reference this | ||||
| document. The registry and its allocation policy (unchanged from | ||||
| [RFC4366]) is listed below: | ||||
| - TLS ExtensionType Registry: Future values are allocated via IETF | ||||
| Consensus [RFC2434] | ||||
| In addition, this document defines two new registries to be | ||||
| maintained by IANA: | ||||
| - TLS SignatureAlgorithm Registry: The registry will be initially | ||||
| populated with the values described in Section 7.4.1.4.1. Future | ||||
| values in the range 0-63 (decimal) inclusive are assigned via | ||||
| Standards Action [RFC2434]. Values in the range 64-223 (decimal) | ||||
| inclusive are assigned via Specification Required [RFC2434]. | ||||
| Values from 224-255 (decimal) inclusive are reserved for Private | ||||
| Use [RFC2434]. | ||||
| - TLS HashAlgorithm Registry: The registry will be initially | ||||
| populated with the values described in Section 7.4.1.4.1. Future | ||||
| values in the range 0-63 (decimal) inclusive are assigned via | ||||
| Standards Action [RFC2434]. Values in the range 64-223 (decimal) | ||||
| inclusive are assigned via Specification Required [RFC2434]. | ||||
| Values from 224-255 (decimal) inclusive are reserved for Private | ||||
| Use [RFC2434]. | ||||
| This document defines one new TLS extension, signature_algorithms, | ||||
| which is to be (has been) allocated value TBD-BY-IANA in the TLS | ||||
| ExtensionType registry. | ||||
| This document also uses the TLS Compression Method Identifiers | ||||
| Registry, defined in [RFC3749]. IANA is requested to allocate value | ||||
| 0 for the "null" compression method. | ||||
| Appendix A. Protocol Constant Values | Appendix A. Protocol Constant Values | |||
| This section describes protocol types and constants. | This section describes protocol types and constants. | |||
| A.1. Record Layer | A.1. Record Layer | |||
| struct { | struct { | |||
| uint8 major, minor; | uint8 major; | |||
| uint8 minor; | ||||
| } ProtocolVersion; | } ProtocolVersion; | |||
| ProtocolVersion version = { 3, 2 }; /* TLS v1.1 */ | ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/ | |||
| enum { | enum { | |||
| change_cipher_spec(20), alert(21), handshake(22), | change_cipher_spec(20), alert(21), handshake(22), | |||
| application_data(23), (255) | application_data(23), (255) | |||
| } ContentType; | } ContentType; | |||
| struct { | struct { | |||
| ContentType type; | ContentType type; | |||
| ProtocolVersion version; | ProtocolVersion version; | |||
| uint16 length; | uint16 length; | |||
| skipping to change at page 55, line 40 ¶ | skipping to change at page 64, line 41 ¶ | |||
| ContentType type; | ContentType type; | |||
| ProtocolVersion version; | ProtocolVersion version; | |||
| uint16 length; | uint16 length; | |||
| opaque fragment[TLSCompressed.length]; | opaque fragment[TLSCompressed.length]; | |||
| } TLSCompressed; | } TLSCompressed; | |||
| struct { | struct { | |||
| ContentType type; | ContentType type; | |||
| ProtocolVersion version; | ProtocolVersion version; | |||
| uint16 length; | uint16 length; | |||
| select (CipherSpec.cipher_type) { | select (SecurityParameters.cipher_type) { | |||
| case stream: GenericStreamCipher; | case stream: GenericStreamCipher; | |||
| case block: GenericBlockCipher; | case block: GenericBlockCipher; | |||
| case aead: GenericAEADCipher; | ||||
| } fragment; | } fragment; | |||
| } TLSCiphertext; | } TLSCiphertext; | |||
| stream-ciphered struct { | stream-ciphered struct { | |||
| opaque content[TLSCompressed.length]; | opaque content[TLSCompressed.length]; | |||
| opaque MAC[CipherSpec.hash_size]; | opaque MAC[SecurityParameters.mac_length]; | |||
| } GenericStreamCipher; | } GenericStreamCipher; | |||
| struct { | ||||
| block-ciphered struct { | opaque IV[SecurityParameters.record_iv_length]; | |||
| opaque IV[CipherSpec.block_length]; | block-ciphered struct { | |||
| opaque content[TLSCompressed.length]; | opaque content[TLSCompressed.length]; | |||
| opaque MAC[CipherSpec.hash_size]; | opaque MAC[SecurityParameters.mac_length]; | |||
| uint8 padding[GenericBlockCipher.padding_length]; | uint8 padding[GenericBlockCipher.padding_length]; | |||
| uint8 padding_length; | uint8 padding_length; | |||
| }; | ||||
| } GenericBlockCipher; | } GenericBlockCipher; | |||
| aead-ciphered struct { | ||||
| opaque IV[SecurityParameters.record_iv_length]; | ||||
| opaque aead_output[AEADEncrypted.length]; | ||||
| } 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(21), | decryption_failed_RESERVED(21), | |||
| record_overflow(22), | record_overflow(22), | |||
| decompression_failure(30), | decompression_failure(30), | |||
| handshake_failure(40), | handshake_failure(40), | |||
| no_certificate_RESERVED (41), | no_certificate_RESERVED(41), | |||
| bad_certificate(42), | bad_certificate(42), | |||
| unsupported_certificate(43), | unsupported_certificate(43), | |||
| certificate_revoked(44), | certificate_revoked(44), | |||
| certificate_expired(45), | certificate_expired(45), | |||
| certificate_unknown(46), | certificate_unknown(46), | |||
| illegal_parameter(47), | illegal_parameter(47), | |||
| unknown_ca(48), | unknown_ca(48), | |||
| access_denied(49), | access_denied(49), | |||
| decode_error(50), | decode_error(50), | |||
| decrypt_error(51), | decrypt_error(51), | |||
| export_restriction_RESERVED(60), | export_restriction_RESERVED(60), | |||
| protocol_version(70), | protocol_version(70), | |||
| insufficient_security(71), | insufficient_security(71), | |||
| internal_error(80), | internal_error(80), | |||
| user_canceled(90), | user_canceled(90), | |||
| no_renegotiation(100), | no_renegotiation(100), | |||
| (255) | unsupported_extension(110), /* new */ | |||
| } AlertDescription; | (255) | |||
| } 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), (255) | finished(20) | |||
| (255) | ||||
| } HandshakeType; | } HandshakeType; | |||
| struct { | struct { | |||
| HandshakeType msg_type; | HandshakeType msg_type; | |||
| uint24 length; | uint24 length; | |||
| select (HandshakeType) { | select (HandshakeType) { | |||
| case hello_request: HelloRequest; | case hello_request: HelloRequest; | |||
| case client_hello: ClientHello; | case client_hello: ClientHello; | |||
| case server_hello: ServerHello; | case server_hello: ServerHello; | |||
| 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 57, line 51 ¶ | skipping to change at page 67, line 14 ¶ | |||
| 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; | |||
| CipherSuite cipher_suites<2..2^16-1>; | CipherSuite cipher_suites<2..2^16-2>; | |||
| CompressionMethod compression_methods<1..2^8-1>; | CompressionMethod compression_methods<1..2^8-1>; | |||
| select (extensions_present) { | ||||
| case false: | ||||
| struct {}; | ||||
| case true: | ||||
| Extension extensions<0..2^16-1>; | ||||
| }; | ||||
| } ClientHello; | } ClientHello; | |||
| struct { | struct { | |||
| ProtocolVersion server_version; | ProtocolVersion server_version; | |||
| Random random; | Random random; | |||
| SessionID session_id; | SessionID session_id; | |||
| CipherSuite cipher_suite; | CipherSuite cipher_suite; | |||
| CompressionMethod compression_method; | CompressionMethod compression_method; | |||
| select (extensions_present) { | ||||
| case false: | ||||
| struct {}; | ||||
| case true: | ||||
| Extension extensions<0..2^16-1>; | ||||
| }; | ||||
| } ServerHello; | } ServerHello; | |||
| struct { | ||||
| ExtensionType extension_type; | ||||
| opaque extension_data<0..2^16-1>; | ||||
| } Extension; | ||||
| enum { | ||||
| signature_algorithms(TBD-BY-IANA), (65535) | ||||
| } ExtensionType; | ||||
| enum{ | ||||
| none(0), md5(1), sha1(2), sha256(3), sha384(4), | ||||
| sha512(5), (255) | ||||
| } HashAlgorithm; | ||||
| enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm; | ||||
| struct { | ||||
| HashAlgorithm hash; | ||||
| SignatureAlgorithm signature; | ||||
| } SignatureAndHashAlgorithm; | ||||
| SignatureAndHashAlgorithm | ||||
| supported_signature_algorithms<2..2^16-1>; | ||||
| A.4.2. Server Authentication and Key Exchange Messages | A.4.2. Server Authentication and Key Exchange Messages | |||
| opaque ASN.1Cert<2^24-1>; | opaque ASN.1Cert<2^24-1>; | |||
| struct { | struct { | |||
| ASN.1Cert certificate_list<0..2^24-1>; | ASN.1Cert certificate_list<0..2^24-1>; | |||
| } Certificate; | } Certificate; | |||
| enum { rsa, diffie_hellman } KeyExchangeAlgorithm; | enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa} | |||
| KeyExchangeAlgorithm; | ||||
| struct { | ||||
| opaque rsa_modulus<1..2^16-1>; | ||||
| opaque rsa_exponent<1..2^16-1>; | ||||
| } ServerRSAParams; | ||||
| struct { | struct { | |||
| opaque dh_p<1..2^16-1>; | opaque dh_p<1..2^16-1>; | |||
| opaque dh_g<1..2^16-1>; | opaque dh_g<1..2^16-1>; | |||
| opaque dh_Ys<1..2^16-1>; | opaque dh_Ys<1..2^16-1>; | |||
| } ServerDHParams; | } ServerDHParams; /* Ephemeral DH parameters */ | |||
| struct { | struct { | |||
| select (KeyExchangeAlgorithm) { | select (KeyExchangeAlgorithm) { | |||
| case diffie_hellman: | case dh_anon: | |||
| ServerDHParams params; | ServerDHParams params; | |||
| Signature signed_params; | case dhe_dss: | |||
| case rsa: | case dhe_rsa: | |||
| ServerRSAParams params; | ||||
| Signature signed_params; | ||||
| }; | ||||
| } ServerKeyExchange; | ||||
| enum { anonymous, rsa, dsa } SignatureAlgorithm; | ||||
| struct { | ||||
| select (KeyExchangeAlgorithm) { | ||||
| case diffie_hellman: | ||||
| ServerDHParams params; | ServerDHParams params; | |||
| case rsa: | ||||
| ServerRSAParams params; | ||||
| }; | ||||
| } ServerParams; | ||||
| struct { | ||||
| select (SignatureAlgorithm) { | ||||
| case anonymous: struct { }; | ||||
| case rsa: | ||||
| digitally-signed struct { | ||||
| opaque md5_hash[16]; | ||||
| opaque sha_hash[20]; | ||||
| }; | ||||
| case dsa: | ||||
| digitally-signed struct { | digitally-signed struct { | |||
| opaque sha_hash[20]; | opaque client_random[32]; | |||
| }; | opaque server_random[32]; | |||
| }; | ServerDHParams params; | |||
| } signed_params; | ||||
| case rsa: | ||||
| case dh_dss: | ||||
| case dh_rsa: | ||||
| struct {} ; | ||||
| /* message is omitted for rsa, dh_dss, and dh_rsa */ | ||||
| }; | }; | |||
| } Signature; | } ServerKeyExchange; | |||
| enum { | enum { | |||
| rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | |||
| rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), | rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), | |||
| fortezza_dms_RESERVED(20), | fortezza_dms_RESERVED(20), | |||
| (255) | (255) | |||
| } ClientCertificateType; | } ClientCertificateType; | |||
| opaque DistinguishedName<1..2^16-1>; | opaque DistinguishedName<1..2^16-1>; | |||
| struct { | struct { | |||
| ClientCertificateType certificate_types<1..2^8-1>; | ClientCertificateType certificate_types<1..2^8-1>; | |||
| DistinguishedName certificate_authorities<0..2^16-1>; | DistinguishedName certificate_authorities<0..2^16-1>; | |||
| } CertificateRequest; | } CertificateRequest; | |||
| struct { } ServerHelloDone; | struct { } ServerHelloDone; | |||
| A.4.3. Client Authentication and Key Exchange Messages | A.4.3. Client Authentication and Key Exchange Messages | |||
| struct { | struct { | |||
| select (KeyExchangeAlgorithm) { | select (KeyExchangeAlgorithm) { | |||
| case rsa: EncryptedPreMasterSecret; | case rsa: | |||
| case diffie_hellman: ClientDiffieHellmanPublic; | EncryptedPreMasterSecret; | |||
| case dhe_dss: | ||||
| case dhe_rsa: | ||||
| case dh_dss: | ||||
| case dh_rsa: | ||||
| case dh_anon: | ||||
| ClientDiffieHellmanPublic; | ||||
| } exchange_keys; | } exchange_keys; | |||
| } ClientKeyExchange; | } ClientKeyExchange; | |||
| struct { | struct { | |||
| ProtocolVersion client_version; | ProtocolVersion client_version; | |||
| opaque random[46]; | opaque random[46]; | |||
| } | } PreMasterSecret; | |||
| PreMasterSecret; | ||||
| struct { | struct { | |||
| public-key-encrypted PreMasterSecret pre_master_secret; | public-key-encrypted PreMasterSecret pre_master_secret; | |||
| } EncryptedPreMasterSecret; | } EncryptedPreMasterSecret; | |||
| enum { implicit, explicit } PublicValueEncoding; | enum { implicit, explicit } PublicValueEncoding; | |||
| struct { | struct { | |||
| select (PublicValueEncoding) { | select (PublicValueEncoding) { | |||
| case implicit: struct {}; | case implicit: struct {}; | |||
| skipping to change at page 60, line 22 ¶ | skipping to change at page 70, line 4 ¶ | |||
| } EncryptedPreMasterSecret; | } EncryptedPreMasterSecret; | |||
| enum { implicit, explicit } PublicValueEncoding; | enum { implicit, explicit } PublicValueEncoding; | |||
| struct { | struct { | |||
| select (PublicValueEncoding) { | select (PublicValueEncoding) { | |||
| case implicit: struct {}; | case implicit: struct {}; | |||
| case explicit: opaque DH_Yc<1..2^16-1>; | case explicit: opaque DH_Yc<1..2^16-1>; | |||
| } dh_public; | } dh_public; | |||
| } ClientDiffieHellmanPublic; | } ClientDiffieHellmanPublic; | |||
| struct { | struct { | |||
| Signature signature; | digitally-signed struct { | |||
| opaque handshake_messages[handshake_messages_length]; | ||||
| } | ||||
| } CertificateVerify; | } CertificateVerify; | |||
| A.4.4. Handshake Finalization Message | A.4.4. Handshake Finalization Message | |||
| struct { | struct { | |||
| opaque verify_data[12]; | opaque verify_data[verify_data_length]; | |||
| } Finished; | } Finished; | |||
| A.5. The CipherSuite | A.5. The Cipher Suite | |||
| The following values define the CipherSuite codes used in the client | The following values define the cipher suite codes used in the client | |||
| hello and server hello messages. | hello and server hello messages. | |||
| A CipherSuite defines a cipher specification supported in TLS Version | A cipher suite defines a cipher specification supported in TLS | |||
| 1.1. | Version 1.2. | |||
| TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a | TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a | |||
| TLS connection during the first handshake on that channel, but must | TLS connection during the first handshake on that channel, but MUST | |||
| not be negotiated, as it provides no more protection than an | NOT be negotiated, as it provides no more protection than an | |||
| unsecured connection. | unsecured connection. | |||
| CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; | CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; | |||
| The following CipherSuite definitions require that the server provide | The following CipherSuite definitions require that the server provide | |||
| an RSA certificate that can be used for key exchange. The server may | an RSA certificate that can be used for key exchange. The server may | |||
| request either an RSA or a DSS signature-capable certificate in the | request any signature-capable certificate in the certificate request | |||
| 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_RC4_128_MD5 = { 0x00,0x04 }; | CipherSuite TLS_RSA_WITH_NULL_SHA256 = { 0x00,TBD1 }; | |||
| CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; | CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; | |||
| CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; | CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; | |||
| CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; | 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_256_CBC_SHA = { 0x00,0x35 }; | ||||
| CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD2 }; | ||||
| CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBD3 }; | ||||
| The following CipherSuite definitions are used for server- | The following cipher suite definitions are used for server- | |||
| authenticated (and optionally client-authenticated) Diffie-Hellman. | authenticated (and optionally client-authenticated) Diffie-Hellman. | |||
| DH denotes cipher suites in which the server's certificate contains | DH denotes cipher suites in which the server's certificate contains | |||
| the Diffie-Hellman parameters signed by the certificate authority | the Diffie-Hellman parameters signed by the certificate authority | |||
| (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman | (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman | |||
| parameters are signed by a DSS or RSA certificate that has been | parameters are signed by a a signature-capable certificate, which has | |||
| signed by the CA. The signing algorithm used is specified after the | been signed by the CA. The signing algorithm used by the server is | |||
| DH or DHE parameter. The server can request an RSA or DSS | specified after the DHE parameter. The server can request any | |||
| signature-capable certificate from the client for client | signature-capable certificate from the client for client | |||
| authentication or it may request a Diffie-Hellman certificate. Any | authentication or it may request a Diffie-Hellman certificate. Any | |||
| Diffie-Hellman certificate provided by the client must use the | Diffie-Hellman certificate provided by the client must use the | |||
| parameters (group and generator) described by the server. | parameters (group and generator) described by the server. | |||
| CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; | 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_DES_CBC_SHA = { 0x00,0x0F }; | CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; | |||
| CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; | CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; | |||
| CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; | CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 }; | |||
| CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; | CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 }; | |||
| CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; | CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 }; | |||
| CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; | CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 }; | |||
| CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 }; | ||||
| The following cipher suites are used for completely anonymous | CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 }; | |||
| Diffie-Hellman communications in which neither party is | CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 }; | |||
| authenticated. Note that this mode is vulnerable to man-in-the- | CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 }; | |||
| middle attacks and is therefore deprecated. | CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD4}; | |||
| CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD5}; | ||||
| CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; | CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD6}; | |||
| CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; | CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD7}; | |||
| CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; | CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBD8}; | |||
| CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBD9}; | ||||
| When SSLv3 and TLS 1.0 were designed, the United States restricted | CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBDA}; | |||
| the export of cryptographic software containing certain strong | CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBDB}; | |||
| encryption algorithms. A series of cipher suites were designed to | ||||
| operate at reduced key lengths in order to comply with those | ||||
| regulations. Due to advances in computer performance, these | ||||
| algorithms are now unacceptably weak, and export restrictions have | ||||
| since been loosened. TLS 1.1 implementations MUST NOT negotiate | ||||
| these cipher suites in TLS 1.1 mode. However, for backward | ||||
| compatibility they may be offered in the ClientHello for use with TLS | ||||
| 1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the | ||||
| server did not choose one of these cipher suites during the | ||||
| handshake. These ciphersuites are listed below for informational | ||||
| purposes and to reserve the numbers. | ||||
| CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; | ||||
| CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; | ||||
| CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; | ||||
| CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; | ||||
| CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; | ||||
| CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; | ||||
| CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; | ||||
| CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; | ||||
| CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; | ||||
| The following cipher suites were defined in [TLSKRB] and are included | ||||
| here for completeness. See [TLSKRB] for details: | ||||
| CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E }: | The following cipher suites are used for completely anonymous Diffie- | |||
| CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F }; | Hellman communications in which neither party is authenticated. Note | |||
| CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 }; | that this mode is vulnerable to man-in-the-middle attacks. Using | |||
| CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 }; | this mode therefore is of limited use: These cipher suites MUST NOT | |||
| CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 }; | be used by TLS 1.2 implementations unless the application layer has | |||
| CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 }; | specifically requested to allow anonymous key exchange. (Anonymous | |||
| CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 }; | key exchange may sometimes be acceptable, for example, to support | |||
| CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 }; | opportunistic encryption when no set-up for authentication is in | |||
| place, or when TLS is used as part of more complex security protocols | ||||
| that have other means to ensure authentication.) | ||||
| The following exportable cipher suites were defined in [TLSKRB] and | CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; | |||
| are included here for completeness. TLS 1.1 implementations MUST NOT | CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; | |||
| negotiate these cipher suites. | 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_128_CBC_SHA256 = { 0x00, TBDC}; | ||||
| CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00, TBDD}; | ||||
| CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26}; | Note that using non-anonymous key exchange without actually verifying | |||
| CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27}; | the key exchange is essentially equivalent to anonymous key exchange, | |||
| CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28}; | and the same precautions apply. While non-anonymous key exchange | |||
| CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29}; | will generally involve a higher computational and communicational | |||
| CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A}; | cost than anonymous key exchange, it may be in the interest of | |||
| CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B}; | interoperability not to disable non-anonymous key exchange when the | |||
| application layer is allowing anonymous key exchange. | ||||
| The following cipher suites were defined in [TLSAES] and are included | New cipher suite values are assigned by IANA as described in Section | |||
| here for completeness. See [TLSAES] for details: | 12. | |||
| CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F }; | Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are | |||
| CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x30 }; | reserved to avoid collision with Fortezza-based cipher suites in SSL | |||
| CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x31 }; | 3. | |||
| CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x32 }; | ||||
| CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x33 }; | ||||
| CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 }; | ||||
| CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 }; | ||||
| CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x36 }; | ||||
| 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_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x39 }; | ||||
| CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A }; | ||||
| The cipher suite space is divided into three regions: | A.6. The Security Parameters | |||
| 1. Cipher suite values with first byte 0x00 (zero) through decimal | These security parameters are determined by the TLS Handshake | |||
| 191 (0xBF) inclusive are reserved for the IETF Standards Track | Protocol and provided as parameters to the TLS Record Layer in order | |||
| protocols. | to initialize a connection state. SecurityParameters includes: | |||
| 2. Cipher suite values with first byte decimal 192 (0xC0) through | enum { null(0), (255) } CompressionMethod; | |||
| decimal 254 (0xFE) inclusive are reserved for assignment for | ||||
| non-Standards Track methods. | ||||
| 3. Cipher suite values with first byte 0xFF are reserved for | enum { server, client } ConnectionEnd; | |||
| private use. | ||||
| Additional information describing the role of IANA in the allocation | enum { tls_prf_sha256 } PRFAlgorithm; | |||
| of cipher suite code points is described in Section 11. | ||||
| Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are | enum { null, rc4, 3des, aes } | |||
| reserved to avoid collision with Fortezza-based cipher suites | BulkCipherAlgorithm; | |||
| in SSL 3. | ||||
| A.6. The Security Parameters | enum { stream, block, aead } CipherType; | |||
| These security parameters are determined by the TLS Handshake | enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384, | |||
| Protocol and provided as parameters to the TLS Record Layer in | hmac_sha512} MACAlgorithm; | |||
| order to initialize a connection state. SecurityParameters | ||||
| includes: | ||||
| enum { null(0), (255) } CompressionMethod; | /* The algorithms specified in CompressionMethod, | |||
| BulkCipherAlgorithm, and MACAlgorithm may be added to. */ | ||||
| enum { server, client } ConnectionEnd; | struct { | |||
| ConnectionEnd entity; | ||||
| PRFAlgorithm prf_algorithm; | ||||
| BulkCipherAlgorithm bulk_cipher_algorithm; | ||||
| CipherType cipher_type; | ||||
| uint8 enc_key_length; | ||||
| uint8 block_length; | ||||
| uint8 fixed_iv_length; | ||||
| uint8 record_iv_length; | ||||
| MACAlgorithm mac_algorithm; | ||||
| uint8 mac_length; | ||||
| uint8 mac_key_length; | ||||
| CompressionMethod compression_algorithm; | ||||
| opaque master_secret[48]; | ||||
| opaque client_random[32]; | ||||
| opaque server_random[32]; | ||||
| } SecurityParameters; | ||||
| enum { null, rc4, rc2, des, 3des, des40, aes, idea } | A.7. Changes to RFC 4492 | |||
| BulkCipherAlgorithm; | ||||
| enum { stream, block } CipherType; | RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This | |||
| document changes some of the structures used in that document. This | ||||
| section details the required changes for implementors of both RFC | ||||
| 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing | ||||
| RFC 4492 do not need to read this section. | ||||
| enum { null, md5, sha } MACAlgorithm; | This document adds a "signature_algorithm" field to the digitally- | |||
| signed element in order to identify the signature and digest | ||||
| algorithms used to create a signature. This change applies to digital | ||||
| signatures formed using ECDSA as well, thus allowing ECDSA signatures | ||||
| to be used and digest algorithms other than SHA-1, provided such use | ||||
| is compatible with the certificate and any restrictions imposed by | ||||
| future revisions of [PKIX]. | ||||
| /* The algorithms specified in CompressionMethod, | As described in Sections 7.4.2 and 7.4.6, the restrictions on the | |||
| BulkCipherAlgorithm, and MACAlgorithm may be added to. */ | signature algorithms used to sign certificates are no longer tied to | |||
| struct { | the cipher suite (when used by the server) or the | |||
| ConnectionEnd entity; | ClientCertificateType (when used by the client). Thus, the | |||
| BulkCipherAlgorithm bulk_cipher_algorithm; | restrictions on the algorithm used to sign certificates specified in | |||
| CipherType cipher_type; | Sections 2 and 3 of RFC 4492 are also relaxed. As in this document | |||
| uint8 key_size; | the restrictions on the keys in the end-entity certificate remain. | |||
| uint8 key_material_length; | ||||
| MACAlgorithm mac_algorithm; | ||||
| uint8 hash_size; | ||||
| CompressionMethod compression_algorithm; | ||||
| opaque master_secret[48]; | ||||
| opaque client_random[32]; | ||||
| opaque server_random[32]; | ||||
| } SecurityParameters; | ||||
| Appendix B. Glossary | Appendix B. Glossary | |||
| Advanced Encryption Standard (AES) | Advanced Encryption Standard (AES) | |||
| AES is a widely used symmetric encryption algorithm. AES is a | AES is a widely used symmetric encryption algorithm. AES is a | |||
| block cipher with a 128, 192, or 256 bit keys and a 16 byte block | block cipher with a 128, 192, or 256 bit keys and a 16 byte block | |||
| size. [AES] TLS currently only supports the 128 and 256 bit key | size. [AES] TLS currently only supports the 128 and 256 bit key | |||
| sizes. | sizes. | |||
| application protocol | application protocol | |||
| An application protocol is a protocol that normally layers | An application protocol is a protocol that normally layers | |||
| 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) | ||||
| A symmetric encryption algorithm that simultaneously provides | ||||
| confidentiality and message integrity. | ||||
| authentication | authentication | |||
| Authentication is the ability of one entity to determine the | Authentication is the ability of one entity to determine the | |||
| identity of another entity. | identity of another entity. | |||
| block cipher | block cipher | |||
| A block cipher is an algorithm that operates on plaintext in | A block cipher is an algorithm that operates on plaintext in | |||
| groups of bits, called blocks. 64 bits is a common block size. | groups of bits, called blocks. 64 bits is a common block size. | |||
| bulk cipher | bulk cipher | |||
| A symmetric encryption algorithm used to encrypt large quantities | A symmetric encryption algorithm used to encrypt large quantities | |||
| of data. | of data. | |||
| cipher block chaining (CBC) | cipher block chaining (CBC) | |||
| CBC is a mode in which every plaintext block encrypted with a | CBC is a mode in which every plaintext block encrypted with a | |||
| block cipher is first exclusive-ORed with the previous ciphertext | block cipher is first exclusive-ORed with the previous ciphertext | |||
| block (or, in the case of the first block, with the initialization | block (or, in the case of the first block, with the initialization | |||
| vector). For decryption, every block is first decrypted, then | vector). For decryption, every block is first decrypted, then | |||
| 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 secret | client write MAC key | |||
| The secret data used to authenticate data written by the client. | The secret data used to authenticate data written by the client. | |||
| connection | connection | |||
| A connection is a transport (in the OSI layering model definition) | A connection is a transport (in the OSI layering model definition) | |||
| that provides a suitable type of service. For TLS, such | that provides a suitable type of service. For TLS, such | |||
| connections are peer-to-peer relationships. The connections are | connections are peer-to-peer relationships. The connections are | |||
| transient. Every connection is associated with one session. | transient. Every connection is associated with one session. | |||
| Data Encryption Standard | Data Encryption Standard | |||
| DES is a very widely used symmetric encryption algorithm. DES is | DES is a very widely used symmetric encryption algorithm. DES is a | |||
| a block cipher with a 56 bit key and an 8 byte block size. Note | block cipher with a 56 bit key and an 8 byte block size. Note that | |||
| that in TLS, for key generation purposes, DES is treated as having | in TLS, for key generation purposes, DES is treated as having an 8 | |||
| an 8 byte key length (64 bits), but it still only provides 56 bits | byte key length (64 bits), but it still only provides 56 bits of | |||
| of protection. (The low bit of each key byte is presumed to be | protection. (The low bit of each key byte is presumed to be set to | |||
| set to produce odd parity in that key byte.) DES can also be | produce odd parity in that key byte.) DES can also be operated in | |||
| operated in a mode where three independent keys and three | a mode where three independent keys and three encryptions are used | |||
| encryptions are used for each block of data; this uses 168 bits of | for each block of data; this uses 168 bits of key (24 bytes in the | |||
| key (24 bytes in the TLS key generation method) and provides the | TLS key generation method) and provides the equivalent of 112 bits | |||
| equivalent of 112 bits of security. [DES], [3DES] | of security. [DES], [3DES] | |||
| Digital Signature Standard (DSS) | Digital Signature Standard (DSS) | |||
| A standard for digital signing, including the Digital Signing | A standard for digital signing, including the Digital Signing | |||
| Algorithm, approved by the National Institute of Standards and | Algorithm, approved by the National Institute of Standards and | |||
| Technology, defined in NIST FIPS PUB 186, "Digital Signature | Technology, defined in NIST FIPS PUB 186, "Digital Signature | |||
| Standard," published May 1994 by the U.S. Dept. of Commerce. | Standard", published May, 1994 by the U.S. Dept. of Commerce. | |||
| [DSS] | [DSS] | |||
| digital signatures | digital signatures | |||
| Digital signatures utilize public key cryptography and one-way | Digital signatures utilize public key cryptography and one-way | |||
| hash functions to produce a signature of the data that can be | hash functions to produce a signature of the data that can be | |||
| authenticated, and is difficult to forge or repudiate. | authenticated, and is difficult to forge or repudiate. | |||
| handshake | handshake | |||
| An initial negotiation between client and server that establishes | An initial negotiation between client and server that establishes | |||
| the parameters of their transactions. | the parameters of their transactions. | |||
| Initialization Vector (IV) | Initialization Vector (IV) | |||
| When a block cipher is used in CBC mode, the initialization vector | When a block cipher is used in CBC mode, the initialization vector | |||
| is exclusive-ORed with the first plaintext block prior to | is exclusive-ORed with the first plaintext block prior to | |||
| encryption. | encryption. | |||
| IDEA | ||||
| A 64-bit block cipher designed by Xuejia Lai and James Massey. | ||||
| [IDEA] | ||||
| Message Authentication Code (MAC) | Message Authentication Code (MAC) | |||
| A Message Authentication Code is a one-way hash computed from a | A Message Authentication Code is a one-way hash computed from a | |||
| message and some secret data. It is difficult to forge without | message and some secret data. It is difficult to forge without | |||
| knowing the secret data. Its purpose is to detect if the message | knowing the secret data. Its purpose is to detect if the message | |||
| has been altered. | has been altered. | |||
| master secret | master secret | |||
| Secure secret data used for generating encryption keys, MAC | Secure secret data used for generating encryption keys, MAC | |||
| secrets, and IVs. | secrets, and IVs. | |||
| MD5 | MD5 | |||
| MD5 is a secure hashing function that converts an arbitrarily long | MD5 is a secure hashing function that converts an arbitrarily long | |||
| data stream into a digest of fixed size (16 bytes). [MD5] | data stream into a hash of fixed size (16 bytes). [MD5] | |||
| 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 | the transformation or to find collisions. MD5 and SHA are examples | |||
| examples of one-way hash functions. | of one-way hash functions. | |||
| RC2 | ||||
| A block cipher developed by Ron Rivest at RSA Data Security, Inc. | ||||
| [RSADSI] described in [RC2]. | ||||
| RC4 | RC4 | |||
| A stream cipher invented by Ron Rivest. A compatible cipher is | A stream cipher invented by Ron Rivest. A compatible cipher is | |||
| described in [SCH]. | described in [SCH]. | |||
| RSA | RSA | |||
| A very widely used public-key algorithm that can be used for | A very widely used public-key algorithm that can be used for | |||
| either encryption or digital signing. [RSA] | either encryption or digital signing. [RSA] | |||
| server | server | |||
| The server is the application entity that responds to requests for | The server is the application entity that responds to requests for | |||
| connections from clients. See also under client. | connections from clients. See also under 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 secret | server write MAC key | |||
| The secret data used to authenticate data written by the server. | The secret data used to authenticate data written by the server. | |||
| SHA | SHA | |||
| The Secure Hash Algorithm is defined in FIPS PUB 180-2. It | The Secure Hash Algorithm is defined in FIPS PUB 180-2. It | |||
| produces a 20-byte output. Note that all references to SHA | produces a 20-byte output. Note that all references to SHA | |||
| actually use the modified SHA-1 algorithm. [SHA] | actually use the modified SHA-1 algorithm. [SHA] | |||
| SHA-256 | ||||
| The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. It | ||||
| produces a 32-byte output. | ||||
| SSL | SSL | |||
| Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on | Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on | |||
| SSL Version 3.0 | SSL Version 3.0 | |||
| stream cipher | stream cipher | |||
| An encryption algorithm that converts a key into a | An encryption algorithm that converts a key into a | |||
| cryptographically strong keystream, which is then exclusive-ORed | cryptographically strong keystream, which is then exclusive-ORed | |||
| with the plaintext. | with the plaintext. | |||
| symmetric cipher | symmetric cipher | |||
| See bulk cipher. | See bulk cipher. | |||
| Transport Layer Security (TLS) | Transport Layer Security (TLS) | |||
| This protocol; also, the Transport Layer Security working group of | This protocol; also, the Transport Layer Security working group of | |||
| the Internet Engineering Task Force (IETF). See "Comments" at the | the Internet Engineering Task Force (IETF). See "Comments" at the | |||
| end of this document. | end of this document. | |||
| Appendix C. CipherSuite Definitions | Appendix C. Cipher Suite Definitions | |||
| CipherSuite Key Exchange Cipher Hash | Cipher Suite Key Cipher Mac | |||
| 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_RC4_128_MD5 RSA RC4_128 MD5 | TLS_RSA_WITH_NULL_SHA256 RSA NULL SHA256 | |||
| TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA | TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 | |||
| TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA | TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA | |||
| TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA | TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA | |||
| TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA | TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA | |||
| TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA | TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA | |||
| TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA | TLS_RSA_WITH_AES_128_CBC_SHA256 RSA AES_128_CBC SHA256 | |||
| TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA | TLS_RSA_WITH_AES_256_CBC_SHA256 RSA AES_256_CBC SHA256 | |||
| TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA | TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA | |||
| TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA | TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA | |||
| TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA | TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA | |||
| TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA | |||
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA | TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 | |||
| TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA | |||
| TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA | TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA | |||
| TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA | TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA | |||
| TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA | ||||
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA | ||||
| TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA | ||||
| TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA | ||||
| TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA | ||||
| TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA | ||||
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA | ||||
| TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA | ||||
| TLS_DH_DSS_WITH_AES_128_CBC_SHA256 DH_DSS AES_128_CBC SHA256 | ||||
| TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256 | ||||
| TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256 | ||||
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256 | ||||
| TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256 | ||||
| TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256 | ||||
| TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256 | ||||
| TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256 | ||||
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256 | ||||
| TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256 | ||||
| Key | Key Expanded IV Block | |||
| Exchange | Cipher Type Material Key Material Size Size | |||
| Algorithm Description Key size limit | ||||
| DHE_DSS Ephemeral DH with DSS signatures None | NULL Stream 0 0 0 N/A | |||
| DHE_RSA Ephemeral DH with RSA signatures None | RC4_128 Stream 16 16 0 N/A | |||
| DH_anon Anonymous DH, no signatures None | 3DES_EDE_CBC Block 24 24 8 8 | |||
| DH_DSS DH with DSS-based certificates None | AES_128_CBC Block 16 16 16 16 | |||
| DH_RSA DH with RSA-based certificates None | AES_256_CBC Block 32 32 16 16 | |||
| RSA = none | ||||
| NULL No key exchange N/A | ||||
| RSA RSA key exchange None | ||||
| Key Expanded IV Block | ||||
| Cipher Type Material Key Material Size Size | ||||
| NULL Stream 0 0 0 N/A | MAC Algorithm mac_length mac_key_length | |||
| IDEA_CBC Block 16 16 8 8 | ||||
| RC2_CBC_40 Block 5 16 8 8 | NULL N/A 0 0 | |||
| RC4_40 Stream 5 16 0 N/A | MD5 HMAC-MD5 16 16 | |||
| RC4_128 Stream 16 16 0 N/A | SHA HMAC-SHA1 20 20 | |||
| DES40_CBC Block 5 8 8 8 | SHA256 HMAC-SHA256 32 32 | |||
| DES_CBC Block 8 8 8 8 | ||||
| 3DES_EDE_CBC Block 24 24 8 8 | ||||
| Type | Type | |||
| Indicates whether this is a stream cipher or a block cipher | Indicates whether this is a stream cipher or a block cipher | |||
| running in CBC mode. | running in CBC mode. | |||
| Key Material | Key Material | |||
| The number of bytes from the key_block that are used for | The number of bytes from the key_block that are used for | |||
| generating the write keys. | generating the write keys. | |||
| Expanded Key Material | Expanded Key Material | |||
| The number of bytes actually fed into the encryption algorithm. | The number of bytes actually fed into the encryption algorithm. | |||
| IV Size | IV Size | |||
| The amount of data needed to be generated for the initialization | The amount of data needed to be generated for the initialization | |||
| vector. Zero for stream ciphers; equal to the block size for | vector. Zero for stream ciphers; equal to the block size for block | |||
| block ciphers. | 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. | |||
| Hash Hash Padding | ||||
| function Size Size | ||||
| NULL 0 0 | ||||
| MD5 16 48 | ||||
| SHA 20 40 | ||||
| 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 MD5 and/or SHA, are | based on secure hash operations, most notably SHA-1, are acceptable, | |||
| acceptable, but cannot provide more security than the size of the | but cannot provide more security than the size of the random number | |||
| random number generator state. (For example, MD5-based PRNGs usually | generator state. | |||
| provide 128 bits of 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 CipherSuites | D.3 Cipher Suites | |||
| TLS supports a range of key sizes and security levels, including some | TLS supports a range of key sizes and security levels, including some | |||
| that provide no or minimal security. A proper implementation will | that provide no or minimal security. A proper implementation will | |||
| probably not support many cipher suites. For example, 40-bit | probably not support many cipher suites. For instance, anonymous | |||
| encryption is easily broken, so implementations requiring strong | Diffie-Hellman is strongly discouraged because it cannot prevent man- | |||
| security should not allow 40-bit keys. Similarly, anonymous Diffie- | in-the-middle attacks. Applications should also enforce minimum and | |||
| Hellman is strongly discouraged because it cannot prevent man-in- | maximum key sizes. For example, certificate chains containing 512-bit | |||
| the-middle attacks. Applications should also enforce minimum and | RSA keys or signatures are not appropriate for high-security | |||
| maximum key sizes. For example, certificate chains containing 512- | ||||
| bit RSA keys or signatures are not appropriate for high-security | ||||
| applications. | applications. | |||
| Appendix E. Backward Compatibility with SSL | D.4 Implementation Pitfalls | |||
| For historical reasons and in order to avoid a profligate consumption | Implementation experience has shown that certain parts of earlier TLS | |||
| of reserved port numbers, application protocols that are secured by | specifications are not easy to understand, and have been a source of | |||
| TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same | interoperability and security problems. Many of these areas have been | |||
| connection port. For example, the https protocol (HTTP secured by | clarified in this document, but this appendix contains a short list | |||
| SSL or TLS) uses port 443 regardless of which security protocol it is | of the most important things that require special attention from | |||
| using. Thus, some mechanism must be determined to distinguish and | implementors. | |||
| negotiate among the various protocols. | ||||
| TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus, | TLS protocol issues: | |||
| supporting both is easy. TLS clients who wish to negotiate with such | ||||
| older servers SHOULD send client hello messages using the SSL 3.0 | ||||
| record format and client hello structure, sending {3, 2} for the | ||||
| version field to note that they support TLS 1.1. If the server | ||||
| supports only TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 | ||||
| server hello; if it supports TLS 1.1 it will respond with a TLS 1.1 | ||||
| server hello. The negotiation then proceeds as appropriate for the | ||||
| negotiated protocol. | ||||
| Similarly, a TLS 1.1 server that wishes to interoperate with TLS 1.0 | - Do you correctly handle handshake messages that are fragmented | |||
| or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages and | to multiple TLS records (see Section 6.2.1)? Including corner | |||
| respond with a SSL 3.0 server hello if an SSL 3.0 client hello with a | cases like a ClientHello that is split to several small | |||
| version field of {3, 0} is received, denoting that this client does | fragments? Do you fragment handshake messages that exceed the | |||
| not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a | maximum fragment size? In particular, the certificate and | |||
| version field of {3, 1} is received, the server SHOULD respond with a | certificate request handshake messages can be large enough to | |||
| TLS 1.0 hello with a version field of {3, 1}. | require fragmentation. | |||
| - Do you ignore the TLS record layer version number in all TLS | ||||
| records before ServerHello (see Appendix E.1)? | ||||
| - Do you handle TLS extensions in ClientHello correctly, | ||||
| including omitting the extensions field completely? | ||||
| - Do you support renegotiation, both client and server initiated? | ||||
| While renegotiation is an optional feature, supporting | ||||
| it is highly recommended. | ||||
| - When the server has requested a client certificate, but no | ||||
| suitable certificate is available, do you correctly send | ||||
| an empty Certificate message, instead of omitting the whole | ||||
| message (see Section 7.4.6)? | ||||
| Cryptographic details: | ||||
| - In RSA-encrypted Premaster Secret, do you correctly send and | ||||
| verify the version number? When an error is encountered, do | ||||
| you continue the handshake to avoid the Bleichenbacher | ||||
| attack (see Section 7.4.7.1)? | ||||
| - What countermeasures do you use to prevent timing attacks against | ||||
| RSA decryption and signing operations (see Section 7.4.7.1)? | ||||
| - When verifying RSA signatures, do you accept both NULL and | ||||
| missing parameters (see Section 4.7)? Do you verify that the | ||||
| RSA padding doesn't have additional data after the hash value? | ||||
| [FI06] | ||||
| - When using Diffie-Hellman key exchange, do you correctly strip | ||||
| leading zero bytes from the negotiated key (see Section 8.1.2)? | ||||
| - Does your TLS client check that the Diffie-Hellman parameters | ||||
| sent 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 | ||||
| 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 | ||||
| random number generator (see Appendix D.1) for generating the | ||||
| premaster secret (for RSA key exchange), Diffie-Hellman private | ||||
| values, the DSA "k" parameter, and other security-critical | ||||
| values? | ||||
| Appendix E. Backward Compatibility | ||||
| 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 | ||||
| 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 | ||||
| built-in mechanism for version negotiation so as not to bother other | ||||
| 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 | ||||
| compatible ClientHello messages; thus, supporting all of them is | ||||
| relatively easy. Similarly, servers can easily handle clients trying | ||||
| to use future versions of TLS as long as the ClientHello format | ||||
| remains compatible, and the client support the highest protocol | ||||
| version available in the server. | ||||
| 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 | ||||
| ClientHello.client_version. If the server does not support this | ||||
| version, it will respond with ServerHello containing an older version | ||||
| number. If the client agrees to use this version, the negotiation | ||||
| will proceed as appropriate for the negotiated protocol. | ||||
| If the version chosen by the server is not supported by the client | ||||
| (or not acceptable), the client MUST send a "protocol_version" alert | ||||
| message and close the connection. | ||||
| If a TLS server receives a ClientHello containing a version number | ||||
| greater than the highest version supported by the server, it MUST | ||||
| reply according to the highest version supported by the server. | ||||
| A TLS server can also receive a ClientHello containing version number | ||||
| smaller than the highest supported version. If the server wishes to | ||||
| negotiate with old clients, it will proceed as appropriate for the | ||||
| highest version supported by the server that is not greater 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 | ||||
| proceed with a TLS 1.0 ServerHello. If server supports (or is willing | ||||
| to use) only versions greater than client_version, it MUST send a | ||||
| "protocol_version" alert message and close the connection. | ||||
| Whenever a client already knows the highest protocol known to a | Whenever a client already knows the highest protocol known to a | |||
| server (for example, when resuming a session), it SHOULD initiate the | server (for example, when resuming a session), it SHOULD initiate the | |||
| connection in that native protocol. | connection in that native protocol. | |||
| TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL | Note: some server implementations are known to implement version | |||
| Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept | negotiation incorrectly. For example, there are buggy TLS 1.0 servers | |||
| either client hello format if they wish to support SSL 2.0 clients on | that simply close the connection when the client offers a version | |||
| the same connection port. The only deviations from the Version 2.0 | newer than TLS 1.0. Also, it is known that some servers will refuse | |||
| specification are the ability to specify a version with a value of | connection if any TLS extensions are included in ClientHello. | |||
| three and the support for more ciphering types in the CipherSpec. | Interoperability with such buggy servers is a complex topic beyond | |||
| the scope of this document, and may require multiple connection | ||||
| Warning: The ability to send Version 2.0 client hello messages will be | attempts by the client. | |||
| phased out with all due haste. Implementors SHOULD make every | ||||
| effort to move forward as quickly as possible. Version 3.0 | ||||
| provides better mechanisms for moving to newer versions. | ||||
| The following cipher specifications are carryovers from SSL | ||||
| Version 2.0. These are assumed to use RSA for key exchange and | ||||
| authentication. | ||||
| V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; | Earlier versions of the TLS specification were not fully clear on | |||
| V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; | what the record layer version number (TLSPlaintext.version) should | |||
| V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; | contain when sending ClientHello (i.e., before it is known which | |||
| V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 | version of the protocol will be employed). Thus, TLS servers | |||
| = { 0x04,0x00,0x80 }; | compliant with this specification MUST accept any value {03,XX} as | |||
| V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 }; | the record layer version number for ClientHello. | |||
| V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 }; | ||||
| V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; | ||||
| Cipher specifications native to TLS can be included in Version | TLS clients that wish to negotiate with older servers MAY send any | |||
| 2.0 client hello messages using the syntax below. Any | value {03,XX} as the record layer version number. Typical values | |||
| V2CipherSpec element with its first byte equal to zero will be | would be {03,00}, the lowest version number supported by the client, | |||
| ignored by Version 2.0 servers. Clients sending any of the above | and the value of ClientHello.client_version. No single value will | |||
| V2CipherSpecs SHOULD also include the TLS equivalent (see | guarantee interoperability with all old servers, but this is a | |||
| Appendix A.5): | complex topic beyond the scope of this document. | |||
| V2CipherSpec (see TLS name) = { 0x00, CipherSuite }; | E.2 Compatibility with SSL 2.0 | |||
| Note: TLS 1.1 clients may generate the SSLv2 EXPORT cipher suites in | TLS 1.2 clients that wish to support SSL 2.0 servers MUST send | |||
| handshakes for backward compatibility but MUST NOT negotiate them | version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST | |||
| in TLS 1.1 mode. | contain the same version number as would be used for ordinary | |||
| ClientHello, and MUST encode the supported TLS cipher suites in the | ||||
| CIPHER-SPECS-DATA field as described below. | ||||
| E.1. Version 2 Client Hello | Warning: The ability to send version 2.0 CLIENT-HELLO messages will | |||
| be phased out with all due haste, since the newer ClientHello format | ||||
| provides better mechanisms for moving to newer versions and | ||||
| negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0. | ||||
| The Version 2.0 client hello message is presented below using this | However, even TLS servers that do not support SSL 2.0 MAY accept | |||
| document's presentation model. The true definition is still assumed | version 2.0 CLIENT-HELLO messages. The message is presented below in | |||
| to be the SSL Version 2.0 specification. Note that this message MUST | sufficient detail for TLS server implementors; the true definition is | |||
| be sent directly on the wire, not wrapped as an SSLv3 record | still assumed to be [SSL2]. | |||
| uint8 V2CipherSpec[3]; | For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same | |||
| way as a ClientHello with a "null" compression method and no | ||||
| extensions. Note that this message MUST be sent directly on the wire, | ||||
| not wrapped as a TLS record. For the purposes of calculating Finished | ||||
| and CertificateVerify, the msg_length field is not considered to be a | ||||
| part of the handshake message. | ||||
| struct { | uint8 V2CipherSpec[3]; | |||
| uint16 msg_length; | struct { | |||
| uint8 msg_type; | uint16 msg_length; | |||
| Version version; | uint8 msg_type; | |||
| uint16 cipher_spec_length; | Version version; | |||
| uint16 session_id_length; | uint16 cipher_spec_length; | |||
| uint16 challenge_length; | uint16 session_id_length; | |||
| V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; | uint16 challenge_length; | |||
| opaque session_id[V2ClientHello.session_id_length]; | V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; | |||
| opaque challenge[V2ClientHello.challenge_length; | opaque session_id[V2ClientHello.session_id_length]; | |||
| } V2ClientHello; | opaque challenge[V2ClientHello.challenge_length; | |||
| } V2ClientHello; | ||||
| msg_length | msg_length | |||
| This field is the length of the following data in bytes. The high | The highest bit MUST be 1; the remaining bits contain the length | |||
| bit MUST be 1 and is not part of the length. | 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 SHOULD be one (1). | version 2 client hello message. The value MUST be one (1). | |||
| version | version | |||
| The highest version of the protocol supported by the client | Equal to ClientHello.client_version. | |||
| (equals ProtocolVersion.version; see Appendix A.1). | ||||
| 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. | This field MUST have a value of zero for a client that claims to | |||
| 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. When using the SSLv2 backward compatible | authenticate itself. Historically, permissible values are between | |||
| handshake the client MUST use a 32-byte challenge. | 16 and 32 bytes inclusive. When using the SSLv2 backward | |||
| 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. There MUST be at least one CipherSpec acceptable to the | to use. In addition to the 2.0 cipher specs defined in [SSL2], | |||
| server. | this includes the TLS cipher suites normally sent in | |||
| ClientHello.cipher_suites, each cipher suite prefixed by a zero | ||||
| byte. For example, TLS cipher suite {0x00,0x0A} would be sent as | ||||
| {0x00,0x00,0x0A}. | ||||
| session_id | session_id | |||
| This field MUST be empty. | This field MUST be empty. | |||
| challenge The client challenge to the server for the server to | challenge | |||
| identify itself is a (nearly) arbitrary-length random. The TLS | Corresponds to ClientHello.random. If the challenge length is less | |||
| server will right-justify the challenge data to become the | than 32, the TLS server will pad the data with leading (note: not | |||
| ClientHello.random data (padded with leading zeroes, if | trailing) zero bytes to make it 32 bytes long. | |||
| necessary), as specified in this protocol specification. If the | ||||
| length of the challenge is greater than 32 bytes, only the last 32 | ||||
| bytes are used. It is legitimate (but not necessary) for a V3 | ||||
| server to reject a V2 ClientHello that has fewer than 16 bytes of | ||||
| challenge data. | ||||
| Note: Requests to resume a TLS session MUST use a TLS client | Note: Requests to resume a TLS session MUST use a TLS client hello. | |||
| hello. | ||||
| E.2. 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 | |||
| SHOULD use special PKCS #1 block formatting. This is done so that | MUST use special PKCS#1 block formatting. This is done so that TLS | |||
| TLS servers will reject Version 2.0 sessions with TLS-capable | servers will reject Version 2.0 sessions with TLS-capable clients. | |||
| clients. | ||||
| When TLS clients are in Version 2.0 compatibility mode, they set the | When a client negotiates SSL 2.0 but also supports TLS, it MUST set | |||
| 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). After decrypting the | to 0x03 (the other padding bytes are random). | |||
| ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an | ||||
| error if these eight padding bytes are 0x03. Version 2.0 servers | When a TLS-capable server negotiates SSL 2.0 it SHOULD, after | |||
| receiving blocks padded in this manner will proceed normally. | decrypting the ENCRYPTED-KEY-DATA field, check that these eight | |||
| padding bytes are 0x03. If they are not, the server SHOULD generate a | ||||
| random value for SECRET-KEY-DATA, and continue the handshake (which | ||||
| will eventually fail since the keys will not match). Note that | ||||
| reporting the error situation to the client could make the server | ||||
| vulnerable to 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 CipherSpec 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 | total anonymity. Whenever the server is authenticated, the channel is | |||
| is secure against man-in-the-middle attacks, but completely anonymous | 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 secrets (see | generate the finished messages, encryption keys, and MAC keys (see | |||
| Sections 7.4.8, 7.4.9, and 6.3). By sending a correct finished | Sections 7.4.9 and 6.3). By sending a correct finished message, | |||
| message, parties thus prove that they know the correct | parties thus prove that they know the correct pre_master_secret. | |||
| pre_master_secret. | ||||
| F.1.1.1. Anonymous Key Exchange | F.1.1.1. Anonymous Key Exchange | |||
| Completely anonymous sessions can be established using RSA or Diffie- | Completely anonymous sessions can be established using Diffie-Hellman | |||
| Hellman for key exchange. With anonymous RSA, the client encrypts a | for key exchange. The server's public parameters are contained in the | |||
| pre_master_secret with the server's uncertified public key extracted | server key exchange message and the client's are sent in the client | |||
| from the server key exchange message. The result is sent in a client | key exchange message. Eavesdroppers who do not know the private | |||
| key exchange message. Since eavesdroppers do not know the server's | values should not be able to find the Diffie-Hellman result (i.e. the | |||
| private key, it will be infeasible for them to decode the | pre_master_secret). | |||
| pre_master_secret. | ||||
| Note: No anonymous RSA Cipher Suites are defined in this document. | ||||
| With Diffie-Hellman, the server's public parameters are contained in | ||||
| the server key exchange message and the client's are sent in the | ||||
| client key exchange message. Eavesdroppers who do not know the | ||||
| private values should not be able to find the Diffie-Hellman result | ||||
| (i.e., the pre_master_secret). | ||||
| Warning: Completely anonymous connections only provide protection | Warning: Completely anonymous connections only provide protection | |||
| against passive eavesdropping. Unless an independent | against passive eavesdropping. Unless an independent tamper-proof | |||
| tamper-proof channel is used to verify that the finished | channel is used to verify that the finished messages were not | |||
| messages were not replaced by an attacker, server | replaced by an attacker, server authentication is required in | |||
| authentication is required in environments where active | environments where active man-in-the-middle attacks are a concern. | |||
| 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 either may be contained in the server's certificate or may | public key is contained in the server's certificate. Note that | |||
| be a temporary RSA key sent in a server key exchange message. When | compromise of the server's static RSA key results in a loss of | |||
| temporary RSA keys are used, they are signed by the server's RSA | confidentiality for all sessions protected under that static key. TLS | |||
| certificate. The signature includes the current ClientHello.random, | users desiring Perfect Forward Secrecy should use DHE cipher suites. | |||
| so old signatures and temporary keys cannot be replayed. Servers may | The damage done by exposure of a private key can be limited by | |||
| use a single temporary RSA key for multiple negotiation sessions. | changing one's private key (and certificate) frequently. | |||
| Note: The temporary RSA key option is useful if servers need large | ||||
| certificates but must comply with government-imposed size | ||||
| limits on keys used for key exchange. | ||||
| Note that if ephemeral RSA is not used, compromise of the server's | ||||
| static RSA key results in a loss of confidentiality for all sessions | ||||
| protected under that static key. TLS users desiring Perfect Forward | ||||
| Secrecy should use DHE cipher suites. The damage done by exposure of | ||||
| a private key can be limited 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 the master_secret and all preceding handshake | a value derived from all preceding handshake messages. These | |||
| messages. These handshake messages include the server certificate, | handshake messages include the server certificate, which binds the | |||
| which binds the signature to the server, and ServerHello.random, | signature to the server, and ServerHello.random, which binds the | |||
| which binds the signature to the current handshake process. | signature to the current handshake process. | |||
| F.1.1.3. Diffie-Hellman Key Exchange with Authentication | F.1.1.3. Diffie-Hellman Key Exchange with Authentication | |||
| When Diffie-Hellman key exchange is used, the server can either | When Diffie-Hellman key exchange is used, the server can either | |||
| supply a certificate containing fixed Diffie-Hellman parameters or | supply a certificate containing fixed Diffie-Hellman parameters or | |||
| use the server key exchange message to send a set of temporary | use the server key exchange message to send a set of temporary | |||
| Diffie-Hellman parameters signed with a DSS or RSA certificate. | Diffie-Hellman parameters signed with a DSS or RSA certificate. | |||
| Temporary parameters are hashed with the hello.random values before | Temporary parameters are hashed with the hello.random values before | |||
| signing to ensure that attackers do not replay old parameters. In | signing to ensure that attackers do not replay old parameters. In | |||
| either case, the client can verify the certificate or signature to | either case, the client can verify the certificate or signature to | |||
| ensure that the parameters belong to the server. | ensure that the parameters belong to the server. | |||
| If the client has a certificate containing fixed Diffie-Hellman | If the client has a certificate containing fixed Diffie-Hellman | |||
| parameters, its certificate contains the information required to | parameters, its certificate contains the information required to | |||
| complete the key exchange. Note that in this case the client and | complete the key exchange. Note that in this case the client and | |||
| server will generate the same Diffie-Hellman result (i.e., | server will generate the same Diffie-Hellman result (i.e., | |||
| pre_master_secret) every time they communicate. To prevent the | pre_master_secret) every time they communicate. To prevent the | |||
| pre_master_secret from staying in memory any longer than necessary, | pre_master_secret from staying in memory any longer than necessary, | |||
| it should be converted into the master_secret as soon as possible. | it should be converted into the master_secret as soon as possible. | |||
| Client Diffie-Hellman parameters must be compatible with those | Client Diffie-Hellman parameters must be compatible with those | |||
| supplied by the server for the key exchange to work. | supplied by the server for the key exchange to work. | |||
| If the client has a standard DSS or RSA certificate or is | If the client has a standard DSS 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 ciphersuites and generating a fresh DH private key (X) for each | DHE cipher suites and generating a fresh DH private key (X) for each | |||
| handshake. If a suitable base (such as 2) is chosen, g^X mod p can | handshake. If a suitable base (such as 2) is chosen, g^X mod p can be | |||
| be computed very quickly, therefore the performance cost is | computed very quickly, therefore the performance cost is minimized. | |||
| minimized. Additionally, using a fresh key for each handshake | Additionally, using a fresh key for each handshake provides Perfect | |||
| provides Perfect Forward Secrecy. Implementations SHOULD generate a | Forward Secrecy. Implementations SHOULD generate a new X for each | |||
| new X for each handshake when using DHE ciphersuites. | handshake when using DHE cipher suites. | |||
| Because TLS allows the server to provide arbitrary DH groups, the | ||||
| 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 | ||||
| exponent appears to be of adequate size. [KEYSIZ] provides a useful | ||||
| guide to the strength of various group sizes. The server MAY choose | ||||
| to assist the client by providing a known group, such as those | ||||
| defined in [IKEALG] or [MODP]. These can be verified by simple | ||||
| 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 | 3.0 servers to detect the attack. This solution is not secure against | |||
| against attackers who can brute force the key and substitute a new | attackers who can brute force the key and substitute a new ENCRYPTED- | |||
| ENCRYPTED-KEY-DATA message containing the same key (but with normal | KEY-DATA message containing the same key (but with normal padding) | |||
| padding) before the application specified wait threshold has expired. | before the application specified wait threshold has expired. Altering | |||
| Parties concerned about attacks of this scale should not use 40-bit | the padding of the least significant 8 bytes of the PKCS padding does | |||
| encryption keys. Altering the padding of the least-significant 8 | not impact security for the size of the signed hashes and RSA key | |||
| bytes of the PKCS padding does not impact security for the size of | lengths used in the protocol, since this is essentially equivalent to | |||
| the signed hashes and RSA key lengths used in the protocol, since | increasing the input block size by 8 bytes. | |||
| this is essentially 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 chooses. | |||
| 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 | session's master_secret. Provided that the master_secret has not been | |||
| been compromised and that the secure hash operations used to produce | compromised and that the secure hash operations used to produce the | |||
| the encryption keys and MAC secrets are secure, the connection should | encryption keys and MAC keys are secure, the connection should be | |||
| 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 (which use both SHA and MD5). | 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.1.5. MD5 and SHA | ||||
| TLS uses hash functions very conservatively. Where possible, both | ||||
| MD5 and SHA are used in tandem to ensure that non-catastrophic flaws | ||||
| in one algorithm will not break the overall protocol. | ||||
| 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 | Outgoing data is protected with a MAC before transmission. To prevent | |||
| prevent message replay or modification attacks, the MAC is computed | message replay or modification attacks, the MAC is computed from the | |||
| from the MAC secret, the sequence number, the message length, the | MAC key, the sequence number, the message length, the message | |||
| message contents, and two fixed character strings. The message type | contents, and two fixed character strings. The message type field is | |||
| field is necessary to ensure that messages intended for one TLS | necessary to ensure that messages intended for one TLS Record Layer | |||
| Record Layer client are not redirected to another. The sequence | client are not redirected to another. The sequence number ensures | |||
| number ensures that attempts to delete or reorder messages will be | that attempts to delete or reorder messages will be detected. Since | |||
| detected. Since sequence numbers are 64 bits long, they should never | sequence numbers are 64 bits long, they should never overflow. | |||
| overflow. Messages from one party cannot be inserted into the | Messages from one party cannot be inserted into the other's output, | |||
| other's output, since they use independent MAC secrets. Similarly, | since they use independent MAC keys. Similarly, the server-write and | |||
| the server-write and client-write keys are independent, so stream | client-write keys are independent, so stream cipher keys are used | |||
| cipher keys are used only once. | 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 secrets 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 | |||
| ciphersuite. The objective is to protect both the integrity and | cipher suite. The objective is to protect both the integrity and | |||
| confidentiality of the transmitted data from malicious actions by | confidentiality of the transmitted data from malicious actions by | |||
| active attackers in the network. It turns out that the order in | active attackers in the network. It turns out that the order in | |||
| which encryption and authentication functions are applied to the data | which encryption and authentication functions are applied to the data | |||
| plays an important role for achieving this goal [ENCAUTH]. | plays an important role for achieving this goal [ENCAUTH]. | |||
| The most robust method, called encrypt-then-authenticate, first | The most robust method, called encrypt-then-authenticate, first | |||
| applies encryption to the data and then applies a MAC to the | applies encryption to the data and then applies a MAC to the | |||
| ciphertext. This method ensures that the integrity and | ciphertext. This method ensures that the integrity and | |||
| confidentiality goals are obtained with ANY pair of encryption and | confidentiality goals are obtained with ANY pair of encryption and | |||
| MAC functions, provided that the former is secure against chosen | MAC functions, provided that the former is secure against chosen | |||
| plaintext attacks and that the MAC is secure against chosen-message | plaintext attacks and that the MAC is secure against chosen-message | |||
| attacks. TLS uses another method, called authenticate-then-encrypt, | attacks. TLS uses another method, called authenticate-then-encrypt, | |||
| in which first a MAC is computed on the plaintext and then the | in which first a MAC is computed on the plaintext and then the | |||
| concatenation of plaintext and MAC is encrypted. This method has | concatenation of plaintext and MAC is encrypted. This method has | |||
| been proven secure for CERTAIN combinations of encryption functions | been proven secure for CERTAIN combinations of encryption functions | |||
| and MAC functions, but it is not guaranteed to be secure in general. | and MAC functions, but it is not guaranteed to be secure in general. | |||
| In particular, it has been shown that there exist perfectly secure | In particular, it has been shown that there exist perfectly secure | |||
| encryption functions (secure even in the information-theoretic sense) | encryption functions (secure even in the information-theoretic sense) | |||
| that combined with any secure MAC function, fail to provide the | that combined with any secure MAC function, fail to provide the | |||
| confidentiality goal against an active attack. Therefore, new | confidentiality goal against an active attack. Therefore, new cipher | |||
| ciphersuites and operation modes adopted into TLS need to be analyzed | suites and operation modes adopted into TLS need to be analyzed under | |||
| under the authenticate-then-encrypt method to verify that they | the authenticate-then-encrypt method to verify that they achieve the | |||
| achieve the stated integrity and confidentiality goals. | stated integrity and confidentiality goals. | |||
| Currently, the security of the authenticate-then-encrypt method has | Currently, the security of the authenticate-then-encrypt method has | |||
| been proven for some important cases. One is the case of stream | been proven for some important cases. One is the case of stream | |||
| ciphers in which a computationally unpredictable pad of the length of | ciphers in which a computationally unpredictable pad of the length of | |||
| the message, plus the length of the MAC tag, is produced using a | the message, plus the length of the MAC tag, is produced using a | |||
| pseudo-random generator and this pad is xor-ed with the concatenation | pseudo-random generator and this pad is xor-ed with the concatenation | |||
| of plaintext and MAC tag. The other is the case of CBC mode using a | of plaintext and MAC tag. The other is the case of CBC mode using a | |||
| secure block cipher. In this case, security can be shown if one | secure block cipher. In this case, security can be shown if one | |||
| applies one CBC encryption pass to the concatenation of plaintext and | applies one CBC encryption pass to the concatenation of plaintext and | |||
| MAC and uses a new, independent, and unpredictable IV for each new | MAC and uses a new, independent, and unpredictable IV for each new | |||
| pair of plaintext and MAC. In previous versions of SSL, CBC mode was | pair of plaintext and MAC. In versions of TLS prior to 1.1, CBC mode | |||
| used properly EXCEPT that it used a predictable IV in the form of the | was used properly EXCEPT that it used a predictable IV in the form of | |||
| last block of the previous ciphertext. This made TLS open to chosen | the last block of the previous ciphertext. This made TLS open to | |||
| plaintext attacks. This version of the protocol is immune to those | chosen plaintext attacks. This version of the protocol is immune to | |||
| attacks. For exact details in the encryption modes proven secure, | those attacks. For exact details in the encryption modes proven | |||
| see [ENCAUTH]. | secure, see [ENCAUTH]. | |||
| F.5. Denial of Service | F.5 Denial of Service | |||
| TLS is susceptible to a number of denial of service (DoS) attacks. | TLS is susceptible to a number of denial of service (DoS) attacks. | |||
| In particular, an attacker who initiates a large number of TCP | In particular, an attacker who initiates a large number of TCP | |||
| connections can cause a server to consume large amounts of CPU doing | connections can cause a server to consume large amounts of CPU doing | |||
| RSA decryption. However, because TLS is generally used over TCP, it | RSA decryption. However, because TLS is generally used over TCP, it | |||
| is difficult for the attacker to hide his point of origin if proper | is difficult for the attacker to hide his point of origin if proper | |||
| TCP SYN randomization is used [SEQNUM] by the TCP stack. | TCP SYN randomization is used [SEQNUM] by the TCP stack. | |||
| Because TLS runs over TCP, it is also susceptible to a number of | Because TLS runs over TCP, it is also susceptible to a number of | |||
| denial of service attacks on individual connections. In particular, | denial of service attacks on individual connections. In particular, | |||
| attackers can forge RSTs, thereby terminating connections, or forge | attackers can forge RSTs, thereby terminating connections, or forge | |||
| partial TLS records, thereby causing the connection to stall. These | partial TLS records, thereby causing the connection to stall. These | |||
| attacks cannot in general be defended against by a TCP-using | attacks cannot in general be defended against by a TCP-using | |||
| protocol. Implementors or users who are concerned with this class of | protocol. Implementors or users who are concerned with this class of | |||
| attack should use IPsec AH [AH-ESP] or ESP [AH-ESP]. | attack 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, 40-bit | cryptographic functions should be used. Short public keys and | |||
| bulk encryption keys, and anonymous servers should be used with great | anonymous servers should be used with great caution. Implementations | |||
| caution. Implementations and users must be careful when deciding | and users must be careful when deciding which certificates and | |||
| which certificates and certificate authorities are acceptable; a | certificate authorities are acceptable; a dishonest certificate | |||
| dishonest certificate authority can do tremendous damage. | authority can do tremendous damage. | |||
| Normative References | Changes in This Version | |||
| [RFC Editor: Please delete this] | ||||
| [AES] National Institute of Standards and Technology, | - Added a new pitfall about fragmenting messages when necessary | |||
| "Specification for the Advanced Encryption Standard (AES)" | [Issue #71] | |||
| FIPS 197. November 26, 2001. | ||||
| [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To | - Added Updates: RFC 4492 [Issue #83] | |||
| DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41. | ||||
| [DES] ANSI X3.106, "American National Standard for Information | - Long CBC padding pitfall [Issue #73] | |||
| Systems-Data Link Encryption," American National Standards | ||||
| Institute, 1983. | ||||
| [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," | - Fixed ProtocolVersion structure [Issue #79] | |||
| National Institute of Standards and Technology, U.S. | ||||
| Department of Commerce, 2000. | ||||
| [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | - Cleaned up extensions text [Issue #78] | |||
| Hashing for Message Authentication", RFC 2104, February | ||||
| 1997. | ||||
| [IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH | - Clarified alerts some [Issue #85] | |||
| Series in Information Processing, v. 1, Konstanz: | ||||
| Hartung-Gorre Verlag, 1992. | ||||
| [MD5] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, | - Added AES to the table in Appendix C [Issue #72] | |||
| April 1992. | ||||
| [PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: | - Tightened up when signature_algorithms is used | |||
| RSA Cryptography Specifications Version 1.5", RFC 2313, | (it is now a MUST if you support other than SHA-1) | |||
| March 1998. | and the interpretation when it is absent is also a MUST | |||
| [Issue #67] | ||||
| [PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards | - Cleaned up "cipher suite" so it's always two words outside | |||
| (PKCS) #1: RSA Cryptography Specifications Version 2.1", | of when it refers to the syntactic type [Issue #68] | |||
| RFC 3447, February 2003. | ||||
| [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet | - Misc editorial. | |||
| X.509 Public Key Infrastructure Certificate and | ||||
| Certificate Revocation List (CRL) Profile", RFC 3280, | ||||
| April 2002. | ||||
| [RC2] Rivest, R., "A Description of the RC2(r) Encryption | - Added support for SHA256 cipher suites | |||
| Algorithm", RFC 2268, March 1998. | ||||
| [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, | - Clarified warning alert behavior and client certificate omission | |||
| and Source Code in C, 2ed", Published by John Wiley & | behavior [Issue #84] | |||
| Sons, Inc. 1996. | ||||
| [SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National | - Removed IDEA and DES entirely for documentation in a separate doc | |||
| Institute of Standards and Technology, U.S. Department of | [Issue #64] | |||
| Commerce., August 2001. | ||||
| [REQ] Bradner, S., "Key words for use in RFCs to Indicate | - Changed the presentation language to allow fall-through to simplify | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | some of the PDUs. | |||
| [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | - Cleaned up KeyExchangeAlgorithm ClientKeyExchange to use values | |||
| IANA Considerations Section in RFCs", BCP 26, RFC 2434, | that match Appendix C. | |||
| October 1998. | ||||
| [TLSAES] Chown, P., "Advanced Encryption Standard (AES) | - Changed digitally-signed to include SignatureAndHashAlgorithm | |||
| Ciphersuites for Transport Layer Security (TLS)", RFC | (another simplification) | |||
| 3268, June 2002. | ||||
| [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., | - Considerations for RFC 4492 | |||
| and T. Wright, "Transport Layer Security (TLS) | ||||
| Extensions", RFC 3546, June 2003. | ||||
| [TLSKRB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher | Normative References | |||
| Suites to Transport Layer Security (TLS)", RFC 2712, | ||||
| October 1999. | [AES] National Institute of Standards and Technology, | |||
| "Specification for the Advanced Encryption Standard (AES)" | ||||
| FIPS 197. November 26, 2001. | ||||
| [3DES] National Institute of Standards and Technology, | ||||
| "Recommendation for the Triple Data Encryption Algorithm | ||||
| (TDEA) Block Cipher", NIST Special Publication 800-67, May | ||||
| 2004. | ||||
| [DES] National Institute of Standards and Technology, "Data | ||||
| Encryption Standard (DES)", FIPS PUB 46-3, October 1999. | ||||
| [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National | ||||
| Institute of Standards and Technology, U.S. Department of | ||||
| Commerce, 2000. | ||||
| [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | ||||
| Hashing for Message Authentication", RFC 2104, February | ||||
| 1997. | ||||
| [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, | ||||
| April 1992. | ||||
| [PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards | ||||
| (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC | ||||
| 3447, February 2003. | ||||
| [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 | ||||
| Public Key Infrastructure Certificate and Certificate | ||||
| Revocation List (CRL) Profile", RFC 3280, April 2002. | ||||
| [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, | ||||
| and Source Code in C, 2nd ed.", Published by John Wiley & | ||||
| Sons, Inc. 1996. | ||||
| [SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National | ||||
| Institute of Standards and Technology, U.S. Department of | ||||
| Commerce., August 2001. | ||||
| [REQ] Bradner, S., "Key words for use in RFCs to Indicate | ||||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | ||||
| [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | ||||
| IANA Considerations Section in RFCs", BCP 25, RFC 2434, | ||||
| October 1998. | ||||
| Informative References | Informative References | |||
| [AH-ESP] Kent, S., "IP Authentication Header", RFC 4302, December | [AEAD] Mcgrew, D., "Authenticated Encryption", July 2007, draft- | |||
| 2005. | mcgrew-auth-enc-05.txt. | |||
| Eastlake 3rd, D., "Cryptographic Algorithm Implementation | [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC | |||
| Requirements for Encapsulating Security Payload (ESP) and | 4302, December 2005. | |||
| Authentication Header (AH)", RFC 4305, December 2005. | ||||
| [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against | [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against | |||
| Protocols Based on RSA Encryption Standard PKCS #1" in | Protocols Based on RSA Encryption Standard PKCS #1" in | |||
| Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, | Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: | |||
| pages: 1-12, 1998. | 1-12, 1998. | |||
| [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: | [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: | |||
| Problems and Countermeasures", | Problems and Countermeasures", | |||
| http://www.openssl.org/~bodo/tls-cbc.txt. | http://www.openssl.org/~bodo/tls-cbc.txt. | |||
| [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel", | [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, | |||
| http://lasecwww.epfl.ch/memo_ssl.shtml, 2003. | "Password Interception in a SSL/TLS Channel", Advances in | |||
| Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003. | ||||
| [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication | [CCM] "NIST Special Publication 800-38C: The CCM Mode for | |||
| for Protecting Communications (Or: How Secure is SSL?)", | Authentication and Confidentiality", | |||
| Crypto 2001. | http://csrc.nist.gov/publications/nistpubs/800-38C/ | |||
| SP800-38C.pdf | ||||
| [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based | [DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard," | |||
| Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, | National Institute of Standards and Technology, U.S. | |||
| March 2003. | Department of Commerce, 2006. | |||
| [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate | [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication | |||
| Syntax Standard," version 1.5, November 1993. | for Protecting Communications (Or: How Secure is SSL?)", | |||
| Crypto 2001. | ||||
| [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message | [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security | |||
| Syntax Standard," version 1.5, November 1993. | Payload (ESP)", RFC 4303, December 2005. | |||
| [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, | [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on | |||
| "Randomness Requirements for Security", BCP 106, RFC 4086, | implementation error", ietf-openpgp@imc.org mailing list, 27 | |||
| June 2005. | August 2006, http://www.imc.org/ietf-openpgp/mail- | |||
| archive/msg14307.html. | ||||
| [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for | [GCM] "NIST Special Publication 800-38D DRAFT (June, 2007): | |||
| Obtaining Digital Signatures and Public-Key | Recommendation for Block Cipher Modes of Operation: | |||
| Cryptosystems," Communications of the ACM, v. 21, n. 2, | Galois/Counter Mode (GCM) and GMAC" | |||
| Feb 1978, pp. 120-126. | ||||
| [SEQNUM] Bellovin, S., "Defending Against Sequence Number Attacks", | [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the | |||
| RFC 1948, May 1996. | Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December | |||
| 2005. | ||||
| [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications | [KEYSIZ] Orman, H., and Hoffman, P., "Determining Strengths For | |||
| Corp., Feb 9, 1995. | Public Keys Used For Exchanging Symmetric Keys" RFC 3766, | |||
| April 2004. | ||||
| [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 | [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based | |||
| Protocol", Netscape Communications Corp., Nov 18, 1996. | Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, | |||
| March 2003. | ||||
| [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" | [MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) | |||
| Attacks on the Diffie-Hellman Key Agreement Method for | Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC | |||
| S/MIME", RFC 2785, March 2000. | 3526, May 2003. | |||
| [TCP] Hellstrom, G. and P. Jones, "RTP Payload for Text | [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax | |||
| Conversation", RFC 4103, June 2005. | Standard," version 1.5, November 1993. | |||
| [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are | [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax | |||
| practical", USENIX Security Symposium 2003. | Standard," version 1.5, November 1993. | |||
| [TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", | [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness | |||
| RFC 2246, January 1999. | Requirements for Security", BCP 106, RFC 4086, June 2005. | |||
| [X501] ITU-T Recommendation X.501: Information Technology - Open | [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol | |||
| Systems Interconnection - The Directory: Models, 1993. | Compression Methods", RFC 3749, May 2004. | |||
| [X509] ITU-T Recommendation X.509 (1997 E): Information | [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., | |||
| Technology - Open Systems Interconnection - "The Directory | Wright, T., "Transport Layer Security (TLS) Extensions", RFC | |||
| - Authentication Framework". 1988. | 4366, April 2006. | |||
| [XDR] Srinivasan, R., "XDR: External Data Representation | [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for | |||
| Standard", RFC 1832, August 1995. | Obtaining Digital Signatures and Public-Key Cryptosystems," | |||
| Communications of the ACM, v. 21, n. 2, Feb 1978, pp. | ||||
| 120-126. | ||||
| Authors' Addresses | [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks", | |||
| RFC 1948, May 1996. | ||||
| Working Group Chairs | [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications | |||
| Corp., Feb 9, 1995. | ||||
| Win Treese | [SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0 | |||
| Protocol", Netscape Communications Corp., Nov 18, 1996. | ||||
| EMail: treese@acm.org | [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" | |||
| Attacks on the Diffie-Hellman Key Agreement Method for | ||||
| S/MIME", RFC 2785, March 2000. | ||||
| Eric Rescorla | [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, | |||
| September 1981. | ||||
| EMail: ekr@rtfm.com | [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are | |||
| practical", USENIX Security Symposium 2003. | ||||
| Editors | [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites | |||
| for Transport Layer Security (TLS)", RFC 3268, June 2002. | ||||
| Tim Dierks | [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and | |||
| Independent | Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher | |||
| Suites for Transport Layer Security (TLS)", RFC 4492, May | ||||
| 2006. | ||||
| EMail: tim@dierks.org | [TLSEXT] Eastlake, D.E., "Transport Layer Security (TLS) Extensions: | |||
| Extension Definitions", January 2008, draft-ietf-tls- | ||||
| rfc4366-bis-01.txt. | ||||
| [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS | ||||
| authentication", RFC 5081, November 2007. | ||||
| [TLSPSK] Eronen, P., Tschofenig, H., "Pre-Shared Key Ciphersuites for | ||||
| Transport Layer Security (TLS)", RFC 4279, December 2005. | ||||
| [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0", | ||||
| RFC 2246, January 1999. | ||||
| [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version | ||||
| 1.1", RFC 4346, April, 2006. | ||||
| [X501] ITU-T Recommendation X.501: Information Technology - Open | ||||
| Systems Interconnection - The Directory: Models, 1993. | ||||
| [XDR] Eisler, M., "External Data Representation Standard", RFC | ||||
| 4506, May 2006. | ||||
| Credits | ||||
| Working Group Chairs | ||||
| Eric Rescorla | Eric Rescorla | |||
| RTFM, Inc. | EMail: ekr@networkresonance.com | |||
| EMail: ekr@rtfm.com | Pasi Eronen | |||
| pasi.eronen@nokia.com | ||||
| Other Contributors | Editors | |||
| Tim Dierks Eric Rescorla | ||||
| Independent Network Resonance, Inc. | ||||
| EMail: tim@dierks.org EMail: ekr@networkresonance.com | ||||
| Other contributors | ||||
| Christopher Allen (co-editor of TLS 1.0) | Christopher Allen (co-editor of TLS 1.0) | |||
| Alacrity Ventures | Alacrity Ventures | |||
| EMail: ChristopherA@AlacrityManagement.com | ChristopherA@AlacrityManagement.com | |||
| Martin Abadi | Martin Abadi | |||
| University of California, Santa Cruz | University of California, Santa Cruz | |||
| EMail: abadi@cs.ucsc.edu | abadi@cs.ucsc.edu | |||
| Steven M. Bellovin | ||||
| Columbia University | ||||
| smb@cs.columbia.edu | ||||
| Simon Blake-Wilson | ||||
| BCI | ||||
| EMail: sblakewilson@bcisse.com | ||||
| Ran Canetti | Ran Canetti | |||
| IBM | IBM | |||
| EMail: canetti@watson.ibm.com | canetti@watson.ibm.com | |||
| Pete Chown | ||||
| Skygate Technology Ltd | ||||
| pc@skygate.co.uk | ||||
| Taher Elgamal | Taher Elgamal | |||
| taher@securify.com | ||||
| Securify | Securify | |||
| EMail: taher@securify.com | ||||
| Pasi Eronen | ||||
| pasi.eronen@nokia.com | ||||
| Nokia | ||||
| Anil Gangolli | Anil Gangolli | |||
| EMail: anil@busybuddha.org | anil@busybuddha.org | |||
| Kipp Hickman | Kipp Hickman | |||
| Alfred Hoenes | ||||
| David Hopwood | ||||
| Independent Consultant | ||||
| EMail: 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 | |||
| EMail: paul@cryptography.com | paul@cryptography.com | |||
| Hugo Krawczyk | Hugo Krawczyk | |||
| Technion Israel Institute of Technology | IBM | |||
| EMail: hugo@ee.technion.ac.il | hugo@ee.technion.ac.il | |||
| Jan Mikkelsen | ||||
| Transactionware | ||||
| EMail: janm@transactionware.com | ||||
| Magnus Nystrom | ||||
| RSA Security | ||||
| EMail: magnus@rsasecurity.com | ||||
| Robert Relyea | Robert Relyea | |||
| Netscape Communications | Netscape Communications | |||
| EMail: relyea@netscape.com | relyea@netscape.com | |||
| Jim Roskind | Jim Roskind | |||
| Netscape Communications | Netscape Communications | |||
| EMail: jar@netscape.com | jar@netscape.com | |||
| Michael Sabin | Michael Sabin | |||
| Dan Simon | Dan Simon | |||
| Microsoft, Inc. | Microsoft, Inc. | |||
| EMail: dansimon@microsoft.com | dansimon@microsoft.com | |||
| Tom Weinstein | Tom Weinstein | |||
| Tim Wright | ||||
| Vodafone | ||||
| EMail: timothy.wright@vodafone.com | ||||
| Comments | Comments | |||
| The discussion list for the IETF TLS working group is located at the | The discussion list for the IETF TLS working group is located at the | |||
| e-mail address <ietf-tls@lists.consensus.com>. Information on the | e-mail address <tls@ietf.org>. Information on the group and | |||
| group and information on how to subscribe to the list is at | information on how to subscribe to the list is at | |||
| <http://lists.consensus.com/>. | <https://www1.ietf.org/mailman/listinfo/tls> | |||
| Archives of the list can be found at: | Archives of the list can be found at: | |||
| <http://www.imc.org/ietf-tls/mail-archive/> | <http://www.ietf.org/mail-archive/web/tls/current/index.html> | |||
| Full Copyright Statement | Full Copyright Statement | |||
| Copyright (C) The Internet Society (2006). | Copyright (C) The IETF Trust (2008). | |||
| This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
| contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
| retain all their rights. | retain all their rights. | |||
| This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | |||
| ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | |||
| INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | |||
| INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
| Intellectual Property | Intellectual Property | |||
| The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
| Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
| pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
| this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
| might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
| made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
| skipping to change at page 87, line 45 ¶ | skipping to change at page 101, line 45 ¶ | |||
| 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. | |||
| Acknowledgement | Acknowledgment | |||
| Funding for the RFC Editor function is provided by the IETF | Funding for the RFC Editor function is provided by the IETF | |||
| Administrative Support Activity (IASA). | Administrative Support Activity (IASA). | |||
| End of changes. 625 change blocks. | ||||
| 2054 lines changed or deleted | 2713 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||