Transport Layer Security Working Group T. Dierks INTERNET-DRAFT Consensus Development Corp. Expires September, 1998 B. Anderson Certicom Corp. March 13, 1998 ECC Cipher Suites For TLS draft-ietf-tls-ecc-00.txt 1. Status of this Memo This document is an Internet-Draft. 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 made obsolete 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. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 2. Introduction This document describes additions to TLS to support the Elliptic Curve Cryptosystem (ECC). The document assumes that the reader is familiar with the TLS protocol. The document defines cipher suites which use the Elliptic Curve Encryption Scheme (ECES), the Elliptic Curve Digital Signature Algorithm (ECDSA), the Elliptic Curve Nyberg-Rueppel Signature Scheme with Appendix (ECNRA), the Elliptic Curve Diffie-Hellman Key Agreement (ECDH), and the Elliptic Curve Menezes-Qu-Vanstone Key Agreement (ECMQV) key establishment algorithms. References to these algorithms can be found in section 13. Dierks [Page 1] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 3. Table of Contents 1. Status of this Memo ........................................ 1 2. Introduction ............................................... 1 3. Table of Contents .......................................... 2 4. Rationale .................................................. 2 5. Elliptic Curve Key Establishment Methods ................... 3 6. Key Establishment Operation ................................ 5 6.1. ECES_ECDSA ................................................. 6 6.2. ECES_ECNRA ................................................. 6 6.3. ECDHE_ECDSA ................................................ 6 6.4. ECDHE_ECDSA_EXPORT ......................................... 7 6.5. ECDHE_ECNRA ................................................ 7 6.6. ECDHE_ECNRA_EXPORT ......................................... 7 6.7. ECDH_ECDSA ................................................. 7 6.8. ECDH_ECNRA ................................................. 8 6.9. ECMQV_ECDSA ................................................ 8 6.10. ECMQV_ECNRA ................................................ 9 6.11. ECDH_anon .................................................. 9 6.12. ECDH_anon_EXPORT ........................................... 9 7. Client Certification ....................................... 9 8. Data Structures ........................................... 10 8.1. Server Key Exchange ....................................... 10 8.2. Certificate Request ....................................... 13 8.3. Client Key Exchange ....................................... 14 8.4. Certificate Verify ........................................ 15 9. Elliptic Curve Certificates ............................... 15 10. Cipher Suites ............................................. 16 11. Elliptic Curve Cryptography Definitions ................... 17 12. Recommended Cipher Suites ................................. 17 13. References ................................................ 17 14. Security Considerations ................................... 18 15. Authors' Addresses ........................................ 18 4. Rationale Several design goals drove our choice of key establishment algorithms: 1. A desire to replicate all of the functionality and operating modes found in the current TLS cipher suites based on integer factorization and discret log cryptographic algorithms. 2. While we wished to define cipher suites which use export-strength Dierks [Page 2] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 cryptography, we did not want to define any cipher suites which would require certificates with export-strength keys; thus, exportable cipher suites are only defined for those key establishment mechanisms which use the certificate key for authentication rather than for key establishment. These criteria for key establishment algorithms, when combined with a number of symmetric algorithms, led to a large number of possible cipher suites. This is problematic in that it could lead to a lack of interoperability due to implementors supporting different subsets of the available cipher suites. In order to alleviate this, we have indicated two of the total cipher suites as recommended (see section 12). Unless there are specific reasons to choose other cipher suites, implementors should implement the recommended suites first. 5. Elliptic Curve Key Establishment Methods Key establishment is the terminology used in ISO standards to refer to the methods of establishing a shared key between two or more parties. Within key establishment there are two classifications: The operation is called key transport when only one party contributes to the generation of the shared key. The operation is called key agreement when 2 or more parties contribute to the generation of the shared key. For the purposes of this definition, the key in question is the premaster secret: TLS uses the master secret generation process to ensure that both parties contribute to the eventual master secret. The cipher suites defined here use the following key establishment methods: ECES_ECDSA Elliptic-curve encryption is used for the key transport; the server's certificate is signed using ECDSA. ECES_ECNRA Elliptic-curve encryption is used for the key transport; the server's certificate is signed using ECNRA. ECDHE_ECDSA Ephemeral elliptic-curve Diffie-Hellman is used for the key agreement; the server signs the parameters with an ECDSA key and is authenticated with a certificate signed with ECDSA. Dierks [Page 3] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 ECDHE_ECDSA_EXPORT Ephemeral elliptic-curve Diffie-Hellman in export strength is used for the key agreement; the server signs the parameters with an ECDSA key and is authenticated with a certificate signed with ECDSA. ECDHE_ECNRA Ephemeral elliptic-curve Diffie-Hellman is used for the key agreement; the server signs the parameters with an ECNRA key and is authenticated with a certificate signed with ECNRA. ECDHE_ECNRA_EXPORT Ephemeral elliptic-curve Diffie-Hellman in export strength is used for the key agreement; the server signs the parameters with an ECNRA key and is authenticated with a certificate signed with ECNRA. ECDH_ECDSA Fixed elliptic-curve Diffie-Hellman is used for the key agreement; the server's certificate is signed with ECDSA. ECDH_ECNRA Fixed elliptic-curve Diffie-Hellman is used for the key agreement; the server's certificate is signed with ECNRA. ECMQV_ECDSA Ephemeral elliptic-curve MQV is used for key agreement and authentication; the server is authenticated with a certificate signed with ECDSA. ECMQV_ECNRA Ephemeral elliptic-curve MQV is used for key agreement and authentication; the server is authenticated with a certificate signed with ECNRA. ECDH_anon Anonymous elliptic-curve Diffie-Hellman is used for the key agreement. ECDH_anon_EXPORT Anonymous elliptic-curve Diffie-Hellman in export strength is used for the key agreement. Key establishment mechanisms which indicate that they are for export strength should use an ECC key for the key agreement of no more than 113 bits. A 113-bit ECC key provides security that is roughly equivalent to a 512-bit RSA key and is expected to be eligible for export. The following table relates ECC key sizes to RSA key sizes Dierks [Page 4] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 of equivalent security. These key sizes are considered equivalent in terms of work factor required to recover the private key using currently known fastest methods for solving the underlying mathematical problems of ECC and RSA. ECC RSA Time to break (MIPS-years) ________ _________ __________________________ 106 bits 512 bits 1E4 MY 132 bits 768 bits 1E8 MY 160 bits 1024 bits 1E11 MY 191 bits 1536 bits 1E14 MY 211 bits 2048 bits 1E20 MY Table 1: ECC and RSA key sizes for equivalent security 6. Key Establishment Operation The TLS key establishment protocol involves this message exchange: Client Server __________________ ___________________ ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Figure 1: Message flow in a full TLS handshake * - Message is not sent under some conditions Of these messages, the ones involved in the key establishment itself are the server's Certificate message, the ServerKeyExchange, the client's Certificate message, and the ClientKeyExchange. In order to specify the ECC cipher suites, we must specify the following elements for each key establishment algorithm: - The format of the server's certificate. Dierks [Page 5] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 - The format of the server key exchange message - For methods in which the client's certificate can participate in the key agreement, the format of the client's certificate and the criteria for deciding if this certificate is eligible to participate in the key agreement. - The format of the client key exchange message - How to arrive at the premaster secret given all the preceding information. Several different key establishment modes are available. In order to allow full negotiation of supported algorithms, the signature algorithm used for the server's X.509 certificate is encoded into the cipher suite for those key establishment mechanisms where no signature algorithm is used; for those key establishments which utilize signature algorithms, the certificate signature algorithm is expected to be the same as the algorithm used in the key establishment. 6.1. ECES_ECDSA In ECES_ECDSA, the server sends a certificate with an ECES-capable public key in it. The server's certificate should be signed with ECDSA. A ServerKeyExchange message is not sent because the server's certificate contains all the necessary keying information for the client to complete the key establishment. The client's certificate is not involved in the key establishment for this method, although the client can still be authenticated via the normal mechanism. The client generates a 48 byte premaster secret, encrypts it using ECES using the public key from the server's certificate, and sends it to the server in the ClientKeyExchange message (see section 8.3). This premaster secret is decrypted by the server and both sides use it to generate the master secret for this TLS session. 6.2. ECES_ECNRA ECES_ECNRA is the same as ECES_ECDSA except for the fact that the server's certificate is signed by its CA with ECNRA. 6.3. ECDHE_ECDSA In ECDHE_ECDSA, the server's certificate has an ECDSA key and is, in Dierks [Page 6] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 turn, signed by its CA with ECDSA. The ServerKeyExchange message contains an ephemeral ECDH key and a specification of the curve for this key. (see section 8.1). These parameters are signed with the server's authenticated ECDSA key. The client's certificate is not involved in the key establishment for this method, although the client can still be authenticated via the normal mechanism. The client should verify the signature on the ServerKeyExchange message and generate an ECDH key on the same curve as the server's ephemeral key. The client encodes the public half of that key into the ClientKeyExchange message and sends it to the server. The client and server perform an ECDH key agreement using their private keys and the public keys they have sent to each other. The resultant shared secret is the premaster secret. 6.4. ECDHE_ECDSA_EXPORT ECDHE_ECDSA_EXPORT is the same as ECDHE_ECDSA except for the fact that the curve used for the server's ephemeral ECDH key should be no longer than 113 bits. Because the server's certified key is only used for authentication, its length is unrestricted. 6.5. ECDHE_ECNRA ECDHE_ECNRA is the same as ECDHE_ECDSA except for the fact that the server's public key is an ECNRA key and the server's certificate is signed by its CA with ECNRA. 6.6. ECDHE_ECNRA_EXPORT ECDHE_ECNRA_EXPORT is the same as ECDHE_ECNRA except for the fact that the curve used for the server's ephemeral ECDH key should be no longer than 113 bits. Because the server's certified key is only used for authentication, its length is unrestricted. 6.7. ECDH_ECDSA In ECDH_ECDSA, the server's certificate contains an ECDH public key. This certificate is signed by the server's CA using ECDSA. The ServerKeyExchange message is not sent because the server's certificate contains all the necessary keying information for the client to complete the key establishment. If the server requests client authentication and includes the ecdsa_fixed_dh or ecnra_fixed_dh client certificate types (see Dierks [Page 7] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 section 8.2) and the client has a certificate which contains an ECDH key on the same curve as the server's public key, and this certificate is otherwise eligible to be used for client authentication, then the client's certified public key is used in conjunction with the server's public key to do an ECDH key agreement; the resultant shared secret is the premaster key. In this situation, the client key exchange message is empty when sent and the client CertificateVerify message is not sent, as both the client and the server are authenticated by their ability to arrive at the same premaster secret. If client certification is not requested or if the client does not have a certificate with a suitable ECDH public key, the client can generate an ephemeral key on the same curve as the server's public key. This key is encoded into the ClientKeyExchange message (see section 8.3) and used in conjunction with the server's key to complete the ECDH key agreement, yielding the premaster secret. 6.8. ECDH_ECNRA ECDH_ECNRA is the same as ECDH_ECDSA except for the fact that the server's certificate is signed by its CA with ECNRA. 6.9. ECMQV_ECDSA In ECMQV_ECDSA, the server's certificate contains an ECMQV key and is signed by the server's CA with ECDSA. The server then generates an temporary key pair and sends the public half of the temporary key in the ServerKeyExchange message (see section 8.1). If the server requests client authentication and includes the ecdsa_mqv or ecnra_mqv client certificate types (see section 8.2) and the client has a certificate which contains an ECMQV key on the same curve as the server's public key, and this certificate is otherwise eligible to be used for client authentication, then the client should send that certificate, then generate a temporary key and send the public half of that key in the ClientKeyExchange message (see section 8.3). The client and server then perform an MQV key agreement using their private keys and their peer's public keys (for each party, both the certified and temporary key pairs are used). The resultant shared secret is the premaster secret. The client CertificateVerify message is not sent, as both the client and the server are authenticated by their ability to arrive at the same premaster secret. If client certification is not requested or if the client does not have a certificate with a suitable ECMQV public key, the client should generate two temporary key pairs on the same curve as the Dierks [Page 8] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 server's public key. The public halves of these temporary key pairs are encoded into the ClientKeyExchange message. One key pair is the usual temporary key used for MQV and the other takes the place of the certified key. Each side performs an MQV key agreement using the peer's public keys and its own private keys, yielding the premaster secret. 6.10. ECMQV_ECNRA ECMQV_ECNRA is the same as ECMQV_ECDSA except for the fact that the server's certificate is signed by its CA with ECNRA. 6.11. ECDH_anon In ECDH_anon, an anonymous Elliptic-Curve Diffie-Hellman operation is used to arrive at the premaster secret. In this case, the server is not authenticated and may not request that the client authenticate itself. The server's Certificate message is not sent. The ServerKeyExchange message contains the specification of a curve and a Diffie-Hellman public key (see section 8.1). The client responds with a ClientKeyExchange message containing a Diffie-Hellman public key on the same curve; the premaster secret is the shared secret resulting from an Elliptic Curve Diffie-Hellman key agreement with these keys. 6.12. ECDH_anon_EXPORT ECDH_anon_EXPORT is the same as ECDH_anon except for the fact that the curve used for the server's ephemeral ECDH key should be no longer than 113 bits. 7. Client Certification Six new client certificate types have been added: ecdsa_sign, ecnra_sign, ecdsa_fixed_dh, ecnra_fixed_dh, ecdsa_mqv, and ecnra_mqv. As noted above, the fixed_dh and mqv types are used in key establishment methods which allow the client's certified key to participate in key agreement. In these cases, the CertificateVerify message is not sent; the client's ability to arrive at the same premaster secret as the server demonstrates its control over the private half of the certified public key. One of these certificates is eligible for use in the key agreement operation if it has a key which can be used with that algorithm. Because elliptic curve keys have the same mathematical properties for all the algorithms discussed in this specification, a certificate could have a key which was authorized for use in any of several algorithms or for only a particular algorithm. In addition to the Dierks [Page 9] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 key's eligibility, it must be defined using the same curve parameters as the server's key to be used in a operation with it. Of course, the use of a certificate is always subject to any and all policy constraints placed on it. In these certificates, the ecdsa or ecnra refers to the algorithm which the CA uses to sign the client's certificate. The ecdsa_sign and ecnra_sign certificate types are used in other key establishment methods and in cases where the client can not or chooses not to supply a suitable certificate to participate in one of the above methods. In these cases, the client must send a CertificateVerify message to demonstrate its control of the private half key of the certified key pair. (See section 8.4). Certificates requested with the ecdsa_sign ClientCertificateType must include an ECDSA public key and be signed by the CA with ECDSA; ecnra_sign certificates must include an ECNRA key and be signed with ECNRA. With all key establishment methods, it is permissible to request a client certificate using a different algorithm than the one used for the server's certificate; for example, a server doing a ECDHE_ECDSA or ECMQV_ECDSA key establishment could still request an ECNRA client certificate. 8. Data Structures Here the descriptions of the data structures exchanged are given. The presentation language is the same as that used in the TLS specification. Because these specifications extend the TLS protocol specification, these descriptions should be merged with those in TLS and in any other specifications which extend TLS. This means that enum types may not specify all the possible values and structures with multiple formats chosen with a select() clause may not indicate all the possible cases. 8.1. Server Key Exchange This messages is sent in the following key establishment methods: ECDHE_ECDSA ECDHE_ECDSA_EXPORT ECDHE_ECNRA ECDHE_ECNRA_EXPORT ECMQV_ECDSA ECMQV_ECNRA ECDH_anon Dierks [Page 10] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 ECDH_anon_EXPORT It can contain elliptic curve Diffie-Hellman keys, either signed or unsigned, or MQV parameters. Structure of this message: enum { ec_eces, ec_diffie_hellman, ec_menezes_qu_vanstone } KeyExchangeAlgorithm; enum { ec_prime_p (1), ec_characteristic_two (2), (255) } ECFieldID; enum { ec_basis_onb, ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; struct { opaque a <1..2^8-1>; opaque b <1..2^8-1>; opaque seed <0..2^8-1>; } ECCurve; a, b: These parameters specify the coefficients of the elliptic curve. Each value shall be the octet string representation of a field element following the conversion routine in [X9.62], section 4.3.1. seed: This is an optional parameter used to derive the coefficients of a randomly generated elliptic curve. struct { opaque point <1..2^8-1>; } ECPoint; point: This is the octet string representation of an elliptic curve point following the conversion routine in [X9.62], section 4.4.2.a. The representation format is defined following the definition in [X9.62], section 4.4. struct { ECFieldID field; select (field) { case ec_prime_p: opaque prime_p <1..2^8-1>; case ec_characteristic_two: Dierks [Page 11] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 uint16 m; ECBasisType basis; select (basis) { case ec_basis_onb: struct { }; case ec_trinomial: opaque k <1..2^8-1>; case ec_pentanomial: opaque k1 <1..2^8-1>; opaque k2 <1..2^8-1>; opaque k3 <1..2^8-1>; }; }; ECCurve curve; ECPoint base; opaque order <1..2^8-1>; opaque cofactor <1..2^8-1>; } ECParameters; field: This identifies the finite field over which the elliptic curve is defined. prime_p: This is the odd prime defining the field Fp. m: This is the degree of the characteristic-two field F2^m. k: The exponent k for the trinomical basis representation x^m + x^k + 1. k1, k2, k3: The exponents for the pentanomial representation x^m + x^k3 + x^k2 + x^k1 + 1. curve: Specifies the coefficients a and b of the elliptic curve E. base: The base point P on the elliptic curve. order: The order n of the base point. The order of a point P is the smallest possible integer n such that nP = 0 (the point at infinity). cofactor: The integer h = #E(Fq)/n, where #E(Fq) represents the number of points on the elliptic curve E defined over the field Fq. struct { ECParameters curve_params; ECPoint public; } ServerECDHParams; Dierks [Page 12] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 curve_params: This specifies the curve on which the elliptic-curve Diffie-Hellman key agreement is to occur. public: The ephemeral public key for the elliptic-curve Diffie- Hellman key agreement. struct { ECPoint temp_public; } ServerMQVParams; temp_public: The temporary MQV public key; the curve on which the MQV operation will take place is specified by the server's certificate. enum { ec_dsa, ec_nra } SignatureAlgorithm; select (SignatureAlgorithm) { case ec_dsa: digitally-signed struct { opaque sha_hash[20]; }; case ec_nra: digitally-signed struct { opaque sha_hash[20]; }; } Signature; select (KeyExchangeAlgorithm) { case ec_diffie_hellman: ServerECDHParams params; Signature signed_params; case ec_menezes_qu_vanstone: ServerMQVParams params; } ServerKeyExchange; Note: The anonymous case for Signature is used for ECDH_anon and ECDH_anon_EXPORT key establishment methods: in this case, the Signature element is empty. 8.2. Certificate Request The only addition to this message is six new types for the client certificate. Structure of this message: enum { Dierks [Page 13] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 ecdsa_sign(5), ecnra_sign(6), ecdsa_fixed_dh(7), ecnra_fixed_dh(8), ecdsa_mqv (9), ecnra_mqv (10), (255) } ClientCertificateType; 8.3. Client Key Exchange This message is sent in all key exchanges. It can contain either an ECES encrypted secret, an ECDH public key (for use in ECDHE or ECDH_anon key establishment methods), an ECMQV temporary public key, or two temporary keys for use with MQV when the client does not have a suitable certificate. Structure of this message: struct { select (PublicValueEncoding) { case implicit: struct { }; case explicit: ECPoint ecdh_Yc; } ecdh_public; } ClientECDiffieHellmanPublic; If the client has sent a certificate with an ECDH key, the PublicValueEncoding will be implicit and this message will be empty. Otherwise, ecdh_Yc will be the client's public value for the Diffie- Hellman key agreement. struct { select (PublicValueEncoding) { case implicit: struct { }; case explicit: ECPoint ecmqv; } ecmqv_public; ECPoint ecmqv_temp; } ClientECMQVPublic; If the client has sent a certificate with an MQV key, the PublicValueEncoding will be implicit and the ecmqv_public field will be empty; otherwise, ecmqv will contain the client's MQV public value. In either case, ecmqv_temp will contain the temporary public key for the MQV operation. In the explicit case, the cost of an additional key generation can be saved by generating only one ephemeral key and sending two copies: one in ecmqv and one in ecmqv_temp. Dierks [Page 14] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 struct { select (KeyExchangeAlgorithm) { case ec_eces: EncryptedPreMasterSecret; case ec_diffie_hellman: ClientECDiffieHellmanPublic; case ec_menezes_qu_vanstone: ClientECMQVPublic; } exchange_keys; } ClientKeyExchange; In the ECES case, the premaster secret will be sent encrypted with the server's public key. The standard TLS definition of EncryptedPreMasterSecret is suitable for this transmission. 8.4. Certificate Verify This message is sent when the client has sent a certificate which did not participate in a Diffie-Hellman or Menezes-Qu-Vanstone key agreement. This type needs no new definition: the CertificateVerify message in TLS uses the Signature type, which we have extended for ECDSA and ECNRA (see section 8.1). 9. Elliptic Curve Certificates All X.509 certificates must be in compliance with the PKIX profile of the X.509 standard [PKIX]. Elliptic curve keys should be encoded into X.509 certificates as specified in [PKIX-ECDSA]. However, this document currently only specifies formats for ECDSA keys and signatures. When this document refers to a certificate with an ECDSA, ECNRA, ECES, ECDH, or ECMQV key, it means a public key which is capable of performing a particular algorithm and which is permitted by the policy encoded in the certificate to participate in this algorithm. This may be a key which is specifically indicated as being useful for a particular algorithm or a general-purpose elliptic curve key which is allowed to perform a particular operation. The X.509 key usage extension encodes functions a key is allowed to perform. The relevant key usage bits for algorithms are: Algorithm Key Usage Bit _________ ________________ ECDSA digitalSignature ECNRA digitalSignature ECES keyEncipherment ECDH keyAgreement ECMQV keyAgreement Dierks [Page 15] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 Table 2: Pertinent X.509 key usage bits A TLS entity shall not present a certificate which is not eligible to participate in the negotiated cipher suite and shall refuse to communicate with a TLS peer which presents such a certificate. 10. Cipher Suites The following cipher suites are defined: CipherSuite TLS_ECES_ECDSA_NULL_SHA = { 0x00, 0x2C } CipherSuite TLS_ECES_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x2D } CipherSuite TLS_ECES_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x2E } CipherSuite TLS_ECES_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x2F } CipherSuite TLS_ECES_ECNRA_NULL_SHA = { 0x00, 0x30 } CipherSuite TLS_ECES_ECNRA_WITH_RC4_128_SHA = { 0x00, 0x31 } CipherSuite TLS_ECES_ECNRA_WITH_DES_CBC_SHA = { 0x00, 0x32 } CipherSuite TLS_ECES_ECNRA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x33 } CipherSuite TLS_ECDHE_ECDSA_NULL_SHA = { 0x00, 0x34 } CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x36 } CipherSuite TLS_ECDHE_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x37 } CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x38 } CipherSuite TLS_ECDHE_ECDSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x39 } CipherSuite TLS_ECDHE_ECDSA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x40 } CipherSuite TLS_ECDHE_ECNRA_NULL_SHA = { 0x00, 0x41 } CipherSuite TLS_ECDHE_ECNRA_WITH_RC4_128_SHA = { 0x00, 0x42 } CipherSuite TLS_ECDHE_ECNRA_WITH_DES_CBC_SHA = { 0x00, 0x43 } CipherSuite TLS_ECDHE_ECNRA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x44 } CipherSuite TLS_ECDHE_ECNRA_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x45 } CipherSuite TLS_ECDHE_ECNRA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x46 } CipherSuite TLS_ECDH_ECDSA_NULL_SHA = { 0x00, 0x47 } CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 } CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 } CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A } CipherSuite TLS_ECDH_ECNRA_NULL_SHA = { 0x00, 0x4B } CipherSuite TLS_ECDH_ECNRA_WITH_RC4_128_SHA = { 0x00, 0x4C } CipherSuite TLS_ECDH_ECNRA_WITH_DES_CBC_SHA = { 0x00, 0x4D } CipherSuite TLS_ECDH_ECNRA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4E } CipherSuite TLS_ECMQV_ECDSA_NULL_SHA = { 0x00, 0x4F } CipherSuite TLS_ECMQV_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x50 } CipherSuite TLS_ECMQV_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x51 } CipherSuite TLS_ECMQV_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x52 } CipherSuite TLS_ECMQV_ECNRA_NULL_SHA = { 0x00, 0x53 } CipherSuite TLS_ECMQV_ECNRA_WITH_RC4_128_SHA = { 0x00, 0x54 } CipherSuite TLS_ECMQV_ECNRA_WITH_DES_CBC_SHA = { 0x00, 0x55 } CipherSuite TLS_ECMQV_ECNRA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x56 } CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x57 } CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x58 } Dierks [Page 16] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 CipherSuite TLS_ECDH_anon_WITH_DES_CBC_SHA = { 0x00, 0x59 } CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x5A } CipherSuite TLS_ECDH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x5B } CipherSuite TLS_ECDH_anon_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x5C } Table 3: TLS ECC cipher suites The key establishment method, cipher, and hash algorithm for each cipher suite are easily determined by examining the name. Those cipher suites which use the "NULL" cipher or one of the "EXPORT" key establishment mechanisms are considered to be "exportable" cipher suites for the purposes of the TLS protocol. 11. Elliptic Curve Cryptography Definitions These definitions provide a quick reference for the elliptic curve terms. Elliptic curve Definition to come. Elliptic curve point Definition to come. EC parameters Definition to come. EC private key Definition to come. EC public key Definition to come. EC key pair Definition to come. 12. Recommended Cipher Suites In order to promote common interoperability, two cipher suites are recommended for initial implementation: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA and TLS_ECDHE_ECDSA_EXPORT_WITH_RC4_40_SHA. Implementing these two gives a basis of cryptographic strength, perfect forward secrecy, and well-accepted algorithms. 13. References [ECDH] IEEE P1363 Working Draft, February, 1997. [ECDSA] IEEE P1363 Working Draft, February, 1997. [ECDSA] ANSI X9.62 Working Draft, November 17, 1997. Dierks [Page 17] INTERNET-DRAFT ECC Cipher Suites For TLS March 13, 1998 [ECES] ANSI X9.63 Working Draft. [ECMQV] IEEE P1363 Working Draft, February, 1997. [ECNRA] IEEE P1363 Working Draft, February, 1997. [PKIX] R. Housley, W. Ford, W. Polk, D. Solo, Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile, , October 1997. [PKIX-ECDSA] L. Bassham, D. Johnson, W. Polk, Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509 Public Key Infrastructure Certificates , November 1997. [X9.62] ANSI X9.62 Working Draft, November 17, 1997. 14. Security Considerations This document is entirely concerned with security mechanisms. Implementors should take care to ensure that code which controls security mechanisms is free of errors which might be exploited by attackers. 15. Authors' Addresses Authors: Tim Dierks Consensus Development timd@consensus.com Bill Anderson Certicom banderson@certicom.com Contributors: Gilles Garon ggaron@aol.com Dierks [Page 18]