| blob | 48c31d341e8c64896e2f115d10fc7addae45b3af |
3 TLS Working Group V. Gupta
4 Internet-Draft Sun Labs
5 Expires: June 1, 2005 S. Blake-Wilson
6 BCI
7 B. Moeller
8 University of California, Berkeley
9 C. Hawk
10 Corriente Networks
11 N. Bolyard
12 Dec. 2004
15 ECC Cipher Suites for TLS
16 <draft-ietf-tls-ecc-07.txt>
18 Status of this Memo
20 This document is an Internet-Draft and is subject to all provisions
21 of section 3 of RFC 3667. By submitting this Internet-Draft, each
22 author represents that any applicable patent or other IPR claims of
23 which he or she is aware have been or will be disclosed, and any of
24 which he or she become aware will be disclosed, in accordance with
25 RFC 3668.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF), its areas, and its working groups. Note that
29 other groups may also distribute working documents as
30 Internet-Drafts.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 The list of current Internet-Drafts can be accessed at
38 http://www.ietf.org/ietf/1id-abstracts.txt.
40 The list of Internet-Draft Shadow Directories can be accessed at
41 http://www.ietf.org/shadow.html.
43 This Internet-Draft will expire on June 1, 2005.
45 Copyright Notice
47 Copyright (C) The Internet Society (2004).
49 Abstract
51 This document describes new key exchange algorithms based on Elliptic
55 Gupta, et al. Expires June 1, 2005 [Page 1]
56 \f
57 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
60 Curve Cryptography (ECC) for the TLS (Transport Layer Security)
61 protocol. In particular, it specifies the use of Elliptic Curve
62 Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
63 Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
64 authentication mechanism.
66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
68 document are to be interpreted as described in RFC 2119 [1].
70 Please send comments on this document to the TLS mailing list.
72 Table of Contents
74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
75 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . 5
76 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7
77 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7
78 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7
79 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 8
80 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8
81 3. Client Authentication . . . . . . . . . . . . . . . . . . . 9
82 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9
83 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10
84 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10
85 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11
86 5. Data Structures and Computations . . . . . . . . . . . . . . 12
87 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12
88 5.2 Server Hello Extensions . . . . . . . . . . . . . . . . . 15
89 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16
90 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 17
91 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 20
92 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 21
93 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 22
94 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 23
95 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 25
96 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 25
97 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 26
98 7. Security Considerations . . . . . . . . . . . . . . . . . . 28
99 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29
100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
101 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 30
102 9.2 Informative References . . . . . . . . . . . . . . . . . . . 30
103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
104 Intellectual Property and Copyright Statements . . . . . . . 33
111 Gupta, et al. Expires June 1, 2005 [Page 2]
112 \f
113 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
116 1. Introduction
118 Elliptic Curve Cryptography (ECC) is emerging as an attractive
119 public-key cryptosystem for mobile/wireless environments. Compared
120 to currently prevalent cryptosystems such as RSA, ECC offers
121 equivalent security with smaller key sizes. This is illustrated in
122 the following table, based on [12], which gives approximate
123 comparable key sizes for symmetric- and asymmetric-key cryptosystems
124 based on the best-known algorithms for attacking them.
126 Symmetric | ECC | DH/DSA/RSA
127 -------------+---------+------------
128 80 | 163 | 1024
129 112 | 233 | 2048
130 128 | 283 | 3072
131 192 | 409 | 7680
132 256 | 571 | 15360
134 Table 1: Comparable key sizes (in bits)
137 Figure 1
139 Smaller key sizes result in power, bandwidth and computational
140 savings that make ECC especially attractive for constrained
141 environments.
143 This document describes additions to TLS to support ECC. In
144 particular, it defines
145 o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement
146 scheme with long-term or ephemeral keys to establish the TLS
147 premaster secret, and
148 o the use of fixed-ECDH certificates and ECDSA for authentication of
149 TLS peers.
151 The remainder of this document is organized as follows. Section 2
152 provides an overview of ECC-based key exchange algorithms for TLS.
153 Section 3 describes the use of ECC certificates for client
154 authentication. TLS extensions that allow a client to negotiate the
155 use of specific curves and point formats are presented in Section 4.
156 Section 5 specifies various data structures needed for an ECC-based
157 handshake, their encoding in TLS messages and the processing of those
158 messages. Section 6 defines new ECC-based cipher suites and
159 identifies a small subset of these as recommended for all
160 implementations of this specification. Section 7 and Section 8
161 mention security considerations and acknowledgments, respectively.
162 This is followed by a list of references cited in this document, the
163 authors' contact information, and statements on intellectual property
167 Gupta, et al. Expires June 1, 2005 [Page 3]
168 \f
169 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
172 rights and copyrights.
174 Implementation of this specification requires familiarity with TLS
175 [2], TLS extensions [3] and ECC [4][5][6][8] .
223 Gupta, et al. Expires June 1, 2005 [Page 4]
224 \f
225 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
228 2. Key Exchange Algorithms
230 This document introduces five new ECC-based key exchange algorithms
231 for TLS. All of them use ECDH to compute the TLS premaster secret
232 and differ only in the lifetime of ECDH keys (long-term or ephemeral)
233 and the mechanism (if any) used to authenticate them. The derivation
234 of the TLS master secret from the premaster secret and the subsequent
235 generation of bulk encryption/MAC keys and initialization vectors is
236 independent of the key exchange algorithm and not impacted by the
237 introduction of ECC.
239 The table below summarizes the new key exchange algorithms which
240 mimic DH_DSS, DH_RSA, DHE_DSS, DHE_RSA and DH_anon (see [2]),
241 respectively.
243 Key
244 Exchange
245 Algorithm Description
246 --------- -----------
248 ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates.
250 ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures.
252 ECDH_RSA Fixed ECDH with RSA-signed certificates.
254 ECDHE_RSA Ephemeral ECDH with RSA signatures.
256 ECDH_anon Anonymous ECDH, no signatures.
259 Table 2: ECC key exchange algorithms
262 Figure 2
264 The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
265 secrecy. With ECDHE_RSA, a server can reuse its existing RSA
266 certificate and easily comply with a constrained client's elliptic
267 curve preferences (see Section 4). However, the computational cost
268 incurred by a server is higher for ECDHE_RSA than for the traditional
269 RSA key exchange which does not provide forward secrecy.
271 The ECDH_RSA mechanism requires a server to acquire an ECC
272 certificate but the certificate issuer can still use an existing RSA
273 key for signing. This eliminates the need to update the trusted key
274 store in TLS clients. The ECDH_ECDSA mechanism requires ECC keys for
275 the server as well as the certification authority and is best suited
279 Gupta, et al. Expires June 1, 2005 [Page 5]
280 \f
281 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
284 for constrained devices unable to support RSA.
286 The anonymous key exchange algorithm does not provide authentication
287 of the server or the client. Like other anonymous TLS key exchanges,
288 it is subject to man-in-the-middle attacks. Implementations of this
289 algorithm SHOULD provide authentication by other means.
291 Note that there is no structural difference between ECDH and ECDSA
292 keys. A certificate issuer may use X509.v3 keyUsage and
293 extendedKeyUsage extensions to restrict the use of an ECC public key
294 to certain computations. This document refers to an ECC key as
295 ECDH-capable if its use in ECDH is permitted. ECDSA-capable is
296 defined similarly.
299 Client Server
300 ------ ------
302 ClientHello -------->
303 ServerHello
304 Certificate*
305 ServerKeyExchange*
306 CertificateRequest*+
307 <-------- ServerHelloDone
308 Certificate*+
309 ClientKeyExchange
310 CertificateVerify*+
311 [ChangeCipherSpec]
312 Finished -------->
313 [ChangeCipherSpec]
314 <-------- Finished
316 Application Data <-------> Application Data
318 Figure 1: Message flow in a full TLS handshake
319 * message is not sent under some conditions
320 + message is not sent unless the client is
321 authenticated
324 Figure 3
326 Figure 1 shows all messages involved in the TLS key establishment
327 protocol (aka full handshake). The addition of ECC has direct impact
328 only on the ClientHello, the ServerHello, the server's Certificate
329 message, the ServerKeyExchange, the ClientKeyExchange, the
330 CertificateRequest, the client's Certificate message, and the
331 CertificateVerify. Next, we describe each ECC key exchange algorithm
335 Gupta, et al. Expires June 1, 2005 [Page 6]
336 \f
337 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
340 in greater detail in terms of the content and processing of these
341 messages. For ease of exposition, we defer discussion of client
342 authentication and associated messages (identified with a + in Figure
343 1) until Section 3 and of the optional ECC-specific extensions (which
344 impact the Hello messages) until Section 4.
346 2.1 ECDH_ECDSA
348 In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
349 public key and be signed with ECDSA.
351 A ServerKeyExchange MUST NOT be sent (the server's certificate
352 contains all the necessary keying information required by the client
353 to arrive at the premaster secret).
355 The client MUST generate an ECDH key pair on the same curve as the
356 server's long-term public key and send its public key in the
357 ClientKeyExchange message (except when using client authentication
358 algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
359 modifications from section Section 3.2 or Section 3.3 apply).
361 Both client and server MUST perform an ECDH operation and use the
362 resultant shared secret as the premaster secret. All ECDH
363 calculations are performed as specified in Section 5.10
365 2.2 ECDHE_ECDSA
367 In ECDHE_ECDSA, the server's certificate MUST contain an
368 ECDSA-capable public key and be signed with ECDSA.
370 The server MUST send its ephemeral ECDH public key and a
371 specification of the corresponding curve in the ServerKeyExchange
372 message. These parameters MUST be signed with ECDSA using the
373 private key corresponding to the public key in the server's
374 Certificate.
376 The client MUST generate an ECDH key pair on the same curve as the
377 server's ephemeral ECDH key and send its public key in the
378 ClientKeyExchange message.
380 Both client and server MUST perform an ECDH operation (Section 5.10)
381 and use the resultant shared secret as the premaster secret.
383 2.3 ECDH_RSA
385 This key exchange algorithm is the same as ECDH_ECDSA except the
386 server's certificate MUST be signed with RSA rather than ECDSA.
391 Gupta, et al. Expires June 1, 2005 [Page 7]
392 \f
393 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
396 2.4 ECDHE_RSA
398 This key exchange algorithm is the same as ECDHE_ECDSA except the
399 server's certificate MUST contain an RSA public key authorized for
400 signing and the signature in the ServerKeyExchange message MUST be
401 computed with the corresponding RSA private key. The server
402 certificate MUST be signed with RSA.
404 2.5 ECDH_anon
406 In ECDH_anon, the server's Certificate, the CertificateRequest, the
407 client's Certificate, and the CertificateVerify messages MUST NOT be
408 sent.
410 The server MUST send an ephemeral ECDH public key and a specification
411 of the corresponding curve in the ServerKeyExchange message. These
412 parameters MUST NOT be signed.
414 The client MUST generate an ECDH key pair on the same curve as the
415 server's ephemeral ECDH key and send its public key in the
416 ClientKeyExchange message.
418 Both client and server MUST perform an ECDH operation and use the
419 resultant shared secret as the premaster secret. All ECDH
420 calculations are performed as specified in Section 5.10
447 Gupta, et al. Expires June 1, 2005 [Page 8]
448 \f
449 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
452 3. Client Authentication
454 This document defines three new client authentication mechanisms
455 named after the type of client certificate involved: ECDSA_sign,
456 ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is
457 usable with any of the non-anonymous ECC key exchange algorithms
458 described in Section 2 as well as other non-anonymous (non-ECC) key
459 exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and
460 RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA.
461 Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the
462 use of a long-term ECDH client key would jeopardize the forward
463 secrecy property of these algorithms.
465 The server can request ECC-based client authentication by including
466 one or more of these certificate types in its CertificateRequest
467 message. The server MUST NOT include any certificate types that are
468 prohibited for the negotiated key exchange algorithm. The client
469 must check if it possesses a certificate appropriate for any of the
470 methods suggested by the server and is willing to use it for
471 authentication.
473 If these conditions are not met, the client should send a client
474 Certificate message containing no certificates. In this case, the
475 ClientKeyExchange should be sent as described in Section 2 and the
476 CertificateVerify should not be sent. If the server requires client
477 authentication, it may respond with a fatal handshake failure alert.
479 If the client has an appropriate certificate and is willing to use it
480 for authentication, it MUST send that certificate in the client's
481 Certificate message (as per Section 5.6) and prove possession of the
482 private key corresponding to the certified key. The process of
483 determining an appropriate certificate and proving possession is
484 different for each authentication mechanism and described below.
486 NOTE: It is permissible for a server to request (and the client to
487 send) a client certificate of a different type than the server
488 certificate.
490 3.1 ECDSA_sign
492 To use this authentication mechanism, the client MUST possess a
493 certificate containing an ECDSA-capable public key and signed with
494 ECDSA.
496 The client MUST prove possession of the private key corresponding to
497 the certified key by including a signature in the CertificateVerify
498 message as described in Section 5.8.
503 Gupta, et al. Expires June 1, 2005 [Page 9]
504 \f
505 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
508 3.2 ECDSA_fixed_ECDH
510 To use this authentication mechanism, the client MUST possess a
511 certificate containing an ECDH-capable public key and that
512 certificate MUST be signed with ECDSA. Furthermore, the client's
513 ECDH key MUST be on the same elliptic curve as the server's long-term
514 (certified) ECDH key. This might limit use of this mechanism to
515 closed environments. In situations where the client has an ECC key
516 on a different curve, it would have to authenticate either using
517 ECDSA_sign or a non-ECC mechanism (e.g. RSA). Using fixed ECDH for
518 both servers and clients is computationally more efficient than
519 mechanisms providing forward secrecy.
521 When using this authentication mechanism, the client MUST send an
522 empty ClientKeyExchange as described in Section 5.7 and MUST NOT send
523 the CertificateVerify message. The ClientKeyExchange is empty since
524 the client's ECDH public key required by the server to compute the
525 premaster secret is available inside the client's certificate. The
526 client's ability to arrive at the same premaster secret as the server
527 (demonstrated by a successful exchange of Finished messages) proves
528 possession of the private key corresponding to the certified public
529 key and the CertificateVerify message is unnecessary.
531 3.3 RSA_fixed_ECDH
533 This authentication mechanism is identical to ECDSA_fixed_ECDH except
534 the client's certificate MUST be signed with RSA.
559 Gupta, et al. Expires June 1, 2005 [Page 10]
560 \f
561 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
564 4. TLS Extensions for ECC
566 Two new TLS extensions --- (i) the Supported Elliptic Curves
567 Extension, and (ii) the Supported Point Formats Extension --- allow a
568 client to negotiate the use of specific curves and point formats
569 (e.g. compressed v/s uncompressed), respectively. These extensions
570 are especially relevant for constrained clients that may only support
571 a limited number of curves or point formats. They follow the general
572 approach outlined in [3]. The client enumerates the curves and point
573 formats it supports by including the appropriate extensions in its
574 ClientHello message. By echoing that extension in its ServerHello,
575 the server agrees to restrict its key selection or encoding to the
576 choices specified by the client.
578 A TLS client that proposes ECC cipher suites in its ClientHello
579 message SHOULD include these extensions. Servers implementing ECC
580 cipher suites MUST support these extensions and negotiate the use of
581 an ECC cipher suite only if they can complete the handshake while
582 limiting themselves to the curves and compression techniques
583 enumerated by the client. This eliminates the possibility that a
584 negotiated ECC handshake will be subsequently aborted due to a
585 client's inability to deal with the server's EC key.
587 These extensions MUST NOT be included if the client does not propose
588 any ECC cipher suites. A client that proposes ECC cipher suites may
589 choose not to include these extension. In this case, the server is
590 free to choose any one of the elliptic curves or point formats listed
591 in Section 5. That section also describes the structure and
592 processing of these extensions in greater detail.
615 Gupta, et al. Expires June 1, 2005 [Page 11]
616 \f
617 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
620 5. Data Structures and Computations
622 This section specifies the data structures and computations used by
623 ECC-based key mechanisms specified in Section 2, Section 3 and
624 Section 4. The presentation language used here is the same as that
625 used in TLS [2]. Since this specification extends TLS, these
626 descriptions should be merged with those in the TLS specification and
627 any others that extend TLS. This means that enum types may not
628 specify all possible values and structures with multiple formats
629 chosen with a select() clause may not indicate all possible cases.
631 5.1 Client Hello Extensions
633 When this message is sent:
635 The ECC extensions SHOULD be sent along with any ClientHello message
636 that proposes ECC cipher suites.
638 Meaning of this message:
640 These extensions allow a constrained client to enumerate the elliptic
641 curves and/or point formats it supports.
643 Structure of this message:
645 The general structure of TLS extensions is described in [3] and this
646 specification adds two new types to ExtensionType.
649 enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType;
651 elliptic_curves: Indicates the set of elliptic curves supported by
652 the client. For this extension, the opaque extension_data field
653 contains EllipticCurveList.
654 ec_point_formats: Indicates the set of point formats supported by
655 the client. For this extension, the opaque extension_data field
656 contains ECPointFormatList.
671 Gupta, et al. Expires June 1, 2005 [Page 12]
672 \f
673 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
676 enum {
677 sect163k1 (1), sect163r1 (2), sect163r2 (3),
678 sect193r1 (4), sect193r2 (5), sect233k1 (6),
679 sect233r1 (7), sect239k1 (8), sect283k1 (9),
680 sect283r1 (10), sect409k1 (11), sect409r1 (12),
681 sect571k1 (13), sect571r1 (14), secp160k1 (15),
682 secp160r1 (16), secp160r2 (17), secp192k1 (18),
683 secp192r1 (19), secp224k1 (20), secp224r1 (21),
684 secp256k1 (22), secp256r1 (23), secp384r1 (24),
685 secp521r1 (25), reserved (240..247),
686 arbitrary_explicit_prime_curves(253),
687 arbitrary_explicit_char2_curves(254),
688 (255)
689 } NamedCurve;
691 sect163k1, etc: Indicates support of the corresponding named curve
692 specified in SEC 2 [10]. Note that many of these curves are also
693 recommended in ANSI X9.62 [6], and FIPS 186-2 [8]. Values 240
694 through 247 are reserved for private use. Values 253 and 254
695 indicate that the client supports arbitrary prime and
696 characteristic-2 curves, respectively (the curve parameters must
697 be encoded explicitly in ECParameters).
700 struct {
701 NamedCurve elliptic_curve_list<1..2^8-1>
702 } EllipticCurveList;
705 Items in elliptic_curve_list are ordered according to the client's
706 preferences (favorite choice first).
708 As an example, a client that only supports secp192r1 (aka NIST P-192)
709 and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would
710 include an elliptic_curves extension with the following octets:
712 00 ?? 02 13 15
714 A client that supports arbitrary explicit binary polynomial curves
715 would include an extension with the following octets:
717 00 ?? 01 fe
727 Gupta, et al. Expires June 1, 2005 [Page 13]
728 \f
729 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
732 enum { uncompressed (0), ansiX963_compressed (1),
733 ansiX963_hybrid (2), (255)
734 } ECPointFormat;
736 struct {
737 ECPointFormat ec_point_format_list<1..2^8-1>
738 } ECPointFormatList;
740 Three point formats are included in the defintion of ECPointFormat
741 above. The uncompressed point format is the default format that
742 implementations of this document MUST support. The
743 ansix963_compressed format reduces bandwidth by including only the
744 x-coordinate and a single bit of the y-coordinate of the point. The
745 ansix963_hybrid format includes both the full y-coordinate and the
746 compressed y-coordinate to allow flexibility and improve efficiency
747 in some cases. Implementations of this document MAY support the
748 ansix963_compressed and ansix963_hybrid point formats.
750 Items in ec_point_format_list are ordered according to the client's
751 preferences (favorite choice first).
753 A client that only supports the uncompressed point format includes an
754 extension with the following octets:
756 00 ?? 01 00
758 A client that prefers the use of the ansiX963_compressed format over
759 uncompressed may indicate that preference by including an extension
760 with the following octets:
762 00 ?? 02 01 00
764 Actions of the sender:
766 A client that proposes ECC cipher suites in its ClientHello appends
767 these extensions (along with any others) enumerating the curves and
768 point formats it supports.
770 Actions of the receiver:
772 A server that receives a ClientHello containing one or both of these
773 extensions MUST use the client's enumerated capabilities to guide its
774 selection of an appropriate cipher suite. One of the proposed ECC
775 cipher suites must be negotiated only if the server can successfully
776 complete the handshake while using the curves and point formats
777 supported by the client.
779 NOTE: A server participating in an ECDHE-ECDSA key exchange may use
783 Gupta, et al. Expires June 1, 2005 [Page 14]
784 \f
785 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
788 different curves for (i) the ECDSA key in its certificate, and (ii)
789 the ephemeral ECDH key in the ServerKeyExchange message. The server
790 must consider the "elliptic_curves" extension in selecting both of
791 these curves.
793 If a server does not understand the "elliptic_curves" extension or is
794 unable to complete the ECC handshake while restricting itself to the
795 enumerated curves, it MUST NOT negotiate the use of an ECC cipher
796 suite. Depending on what other cipher suites are proposed by the
797 client and supported by the server, this may result in a fatal
798 handshake failure alert due to the lack of common cipher suites.
800 5.2 Server Hello Extensions
802 When this message is sent:
804 The ServerHello ECC extensions are sent in response to a Client Hello
805 message containing ECC extensions when negotiating an ECC cipher
806 suite.
808 Meaning of this message:
810 These extensions indicate the server's agreement to use only the
811 elliptic curves and point formats supported by the client during the
812 ECC-based key exchange.
814 Structure of this message:
816 The ECC extensions echoed by the server are the same as those in the
817 ClientHello except the "extension_data" field is empty.
819 For example, a server indicates its acceptance of the client's
820 elliptic_curves extension by sending an extension with the following
821 octets:
823 00 ?? 00 00
825 Actions of the sender:
827 A server makes sure that it can complete a proposed ECC key exchange
828 mechanism by restricting itself to the curves/point formats supported
829 by the client before sending these extensions.
831 Actions of the receiver:
833 A client that receives a ServerHello with ECC extensions proceeds
834 with an ECC key exchange assured that it will be able to handle the
835 server's EC key(s).
839 Gupta, et al. Expires June 1, 2005 [Page 15]
840 \f
841 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
844 5.3 Server Certificate
846 When this message is sent:
848 This message is sent in all non-anonymous ECC-based key exchange
849 algorithms.
851 Meaning of this message:
853 This message is used to authentically convey the server's static
854 public key to the client. The following table shows the server
855 certificate type appropriate for each key exchange algorithm. ECC
856 public keys must be encoded in certificates as described in Section
857 5.9.
859 NOTE: The server's Certificate message is capable of carrying a chain
860 of certificates. The restrictions mentioned in Table 3 apply only to
861 the server's certificate (first in the chain).
864 Key Exchange Algorithm Server Certificate Type
865 ---------------------- -----------------------
867 ECDH_ECDSA Certificate must contain an
868 ECDH-capable public key. It
869 must be signed with ECDSA.
871 ECDHE_ECDSA Certificate must contain an
872 ECDSA-capable public key. It
873 must be signed with ECDSA.
875 ECDH_RSA Certificate must contain an
876 ECDH-capable public key. It
877 must be signed with RSA.
879 ECDHE_RSA Certificate must contain an
880 RSA public key authorized for
881 use in digital signatures. It
882 must be signed with RSA.
884 Table 3: Server certificate types
887 Structure of this message:
889 Identical to the TLS Certificate format.
891 Actions of the sender:
895 Gupta, et al. Expires June 1, 2005 [Page 16]
896 \f
897 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
900 The server constructs an appropriate certificate chain and conveys it
901 to the client in the Certificate message.
903 Actions of the receiver:
905 The client validates the certificate chain, extracts the server's
906 public key, and checks that the key type is appropriate for the
907 negotiated key exchange algorithm.
909 5.4 Server Key Exchange
911 When this message is sent:
913 This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and
914 ECDH_anon key exchange algorithms.
916 Meaning of this message:
918 This message is used to convey the server's ephemeral ECDH public key
919 (and the corresponding elliptic curve domain parameters) to the
920 client.
922 Structure of this message:
924 enum { explicit_prime (1), explicit_char2 (2),
925 named_curve (3), (255) } ECCurveType;
927 explicit_prime: Indicates the elliptic curve domain parameters are
928 conveyed verbosely, and the underlying finite field is a prime
929 field.
930 explicit_char2: Indicates the elliptic curve domain parameters are
931 conveyed verbosely, and the underlying finite field is a
932 characteristic-2 field.
933 named_curve: Indicates that a named curve is used. This option
934 SHOULD be used when applicable.
936 struct {
937 opaque a <1..2^8-1>;
938 opaque b <1..2^8-1>;
939 } ECCurve;
941 a, b: These parameters specify the coefficients of the elliptic
942 curve. Each value contains the byte string representation of a
943 field element following the conversion routine in Section 4.3.3 of
944 ANSI X9.62 [6].
946 struct {
947 opaque point <1..2^8-1>;
951 Gupta, et al. Expires June 1, 2005 [Page 17]
952 \f
953 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
956 } ECPoint;
958 point: This is the byte string representation of an elliptic curve
959 point following the conversion routine in Section 4.3.6 of ANSI
960 X9.62 [6]. Note that this byte string may represent an elliptic
961 curve point in compressed or uncompressed form.
963 enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
965 ec_basis_trinomial: Indicates representation of a characteristic-2
966 field using a trinomial basis.
967 ec_basis_pentanomial: Indicates representation of a characteristic-2
968 field using a pentanomial basis.
970 struct {
971 ECCurveType curve_type;
972 select (curve_type) {
973 case explicit_prime:
974 opaque prime_p <1..2^8-1>;
975 ECCurve curve;
976 ECPoint base;
977 opaque order <1..2^8-1>;
978 opaque cofactor <1..2^8-1>;
979 case explicit_char2:
980 uint16 m;
981 ECBasisType basis;
982 select (basis) {
983 case ec_trinomial:
984 opaque k <1..2^8-1>;
985 case ec_pentanomial:
986 opaque k1 <1..2^8-1>;
987 opaque k2 <1..2^8-1>;
988 opaque k3 <1..2^8-1>;
989 };
990 ECCurve curve;
991 ECPoint base;
992 opaque order <1..2^8-1>;
993 opaque cofactor <1..2^8-1>;
994 case named_curve:
995 NamedCurve namedcurve;
996 };
997 } ECParameters;
999 curve_type: This identifies the type of the elliptic curve domain
1000 parameters.
1007 Gupta, et al. Expires June 1, 2005 [Page 18]
1008 \f
1009 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1012 prime_p: This is the odd prime defining the field Fp.
1013 curve: Specifies the coefficients a and b of the elliptic curve E.
1014 base: Specifies the base point G on the elliptic curve.
1015 order: Specifies the order n of the base point.
1016 cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq)
1017 represents the number of points on the elliptic curve E defined
1018 over the field Fq.
1019 m: This is the degree of the characteristic-2 field F2^m.
1020 k: The exponent k for the trinomial basis representation x^m + x^k
1021 +1.
1022 k1, k2, k3: The exponents for the pentanomial representation x^m +
1023 x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).
1024 namedcurve: Specifies a recommended set of elliptic curve domain
1025 parameters. All enum values of NamedCurve are allowed except for
1026 arbitrary_explicit_prime_curves(253) and
1027 arbitrary_explicit_char2_curves(254). These two values are only
1028 allowed in the ClientHello extension.
1030 struct {
1031 ECParameters curve_params;
1032 ECPoint public;
1033 } ServerECDHParams;
1035 curve_params: Specifies the elliptic curve domain parameters
1036 associated with the ECDH public key.
1037 public: The ephemeral ECDH public key.
1039 The ServerKeyExchange message is extended as follows.
1041 enum { ec_diffie_hellman } KeyExchangeAlgorithm;
1043 ec_diffie_hellman: Indicates the ServerKeyExchange message contains
1044 an ECDH public key.
1046 select (KeyExchangeAlgorithm) {
1047 case ec_diffie_hellman:
1048 ServerECDHParams params;
1049 Signature signed_params;
1050 } ServerKeyExchange;
1052 params: Specifies the ECDH public key and associated domain
1053 parameters.
1054 signed_params: A hash of the params, with the signature appropriate
1055 to that hash applied. The private key corresponding to the
1056 certified public key in the server's Certificate message is used
1057 for signing.
1059 enum { ecdsa } SignatureAlgorithm;
1063 Gupta, et al. Expires June 1, 2005 [Page 19]
1064 \f
1065 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1068 select (SignatureAlgorithm) {
1069 case ecdsa:
1070 digitally-signed struct {
1071 opaque sha_hash[sha_size];
1072 };
1073 } Signature;
1075 NOTE: SignatureAlgorithm is 'rsa' for the ECDHE_RSA key exchange
1076 algorithm and 'anonymous' for ECDH_anon. These cases are defined in
1077 TLS [2]. SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA. ECDSA
1078 signatures are generated and verified as described in Section 5.10.
1079 As per ANSI X9.62, an ECDSA signature consists of a pair of integers
1080 r and s. These integers are both converted into byte strings of the
1081 same length as the curve order n using the conversion routine
1082 specified in Section 4.3.1 of [6]. The two byte strings are
1083 concatenated, and the result is placed in the signature field.
1085 Actions of the sender:
1087 The server selects elliptic curve domain parameters and an ephemeral
1088 ECDH public key corresponding to these parameters according to the
1089 ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to
1090 the client in the ServerKeyExchange message using the format defined
1091 above.
1093 Actions of the recipient:
1095 The client verifies the signature (when present) and retrieves the
1096 server's elliptic curve domain parameters and ephemeral ECDH public
1097 key from the ServerKeyExchange message.
1099 5.5 Certificate Request
1101 When this message is sent:
1103 This message is sent when requesting client authentication.
1105 Meaning of this message:
1107 The server uses this message to suggest acceptable client
1108 authentication methods.
1110 Structure of this message:
1112 The TLS CertificateRequest message is extended as follows.
1114 enum {
1115 ecdsa_sign(?), rsa_fixed_ecdh(?),
1119 Gupta, et al. Expires June 1, 2005 [Page 20]
1120 \f
1121 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1124 ecdsa_fixed_ecdh(?), (255)
1125 } ClientCertificateType;
1127 ecdsa_sign, etc Indicates that the server would like to use the
1128 corresponding client authentication method specified in Section 3.
1129 EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and
1130 ecdsa_fixed_ecdh have been left as ?. These values will be
1131 assigned when this draft progresses to RFC. Earlier versions of
1132 this draft used the values 5, 6, and 7 - however these values have
1133 been removed since they are used differently by SSL 3.0 [13] and
1134 their use by TLS is being deprecated.
1136 Actions of the sender:
1138 The server decides which client authentication methods it would like
1139 to use, and conveys this information to the client using the format
1140 defined above.
1142 Actions of the receiver:
1144 The client determines whether it has an appropriate certificate for
1145 use with any of the requested methods, and decides whether or not to
1146 proceed with client authentication.
1148 5.6 Client Certificate
1150 When this message is sent:
1152 This message is sent in response to a CertificateRequest when a
1153 client has a suitable certificate.
1155 Meaning of this message:
1157 This message is used to authentically convey the client's static
1158 public key to the server. The following table summarizes what client
1159 certificate types are appropriate for the ECC-based client
1160 authentication mechanisms described in Section 3. ECC public keys
1161 must be encoded in certificates as described in Section 5.9.
1163 NOTE: The client's Certificate message is capable of carrying a chain
1164 of certificates. The restrictions mentioned in Table 4 apply only to
1165 the client's certificate (first in the chain).
1175 Gupta, et al. Expires June 1, 2005 [Page 21]
1176 \f
1177 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1180 Client
1181 Authentication Method Client Certificate Type
1182 --------------------- -----------------------
1184 ECDSA_sign Certificate must contain an
1185 ECDSA-capable public key and
1186 be signed with ECDSA.
1188 ECDSA_fixed_ECDH Certificate must contain an
1189 ECDH-capable public key on the
1190 same elliptic curve as the server's
1191 long-term ECDH key. This certificate
1192 must be signed with ECDSA.
1194 RSA_fixed_ECDH Certificate must contain an
1195 ECDH-capable public key on the
1196 same elliptic curve as the server's
1197 long-term ECDH key. This certificate
1198 must be signed with RSA.
1200 Table 4: Client certificate types
1203 Structure of this message:
1205 Identical to the TLS client Certificate format.
1207 Actions of the sender:
1209 The client constructs an appropriate certificate chain, and conveys
1210 it to the server in the Certificate message.
1212 Actions of the receiver:
1214 The TLS server validates the certificate chain, extracts the client's
1215 public key, and checks that the key type is appropriate for the
1216 client authentication method.
1218 5.7 Client Key Exchange
1220 When this message is sent:
1222 This message is sent in all key exchange algorithms. If client
1223 authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this
1224 message is empty. Otherwise, it contains the client's ephemeral ECDH
1225 public key.
1227 Meaning of the message:
1231 Gupta, et al. Expires June 1, 2005 [Page 22]
1232 \f
1233 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1236 This message is used to convey ephemeral data relating to the key
1237 exchange belonging to the client (such as its ephemeral ECDH public
1238 key).
1240 Structure of this message:
1242 The TLS ClientKeyExchange message is extended as follows.
1244 enum { yes, no } EphemeralPublicKey;
1246 yes, no: Indicates whether or not the client is providing an
1247 ephemeral ECDH public key. (In ECC ciphersuites, this is "yes"
1248 except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH
1249 client authentication mechanism.)
1251 struct {
1252 select (EphemeralPublicKey) {
1253 case yes: ECPoint ecdh_Yc;
1254 case no: struct { };
1255 } ecdh_public;
1256 } ClientECDiffieHellmanPublic;
1258 ecdh_Yc: Contains the client's ephemeral ECDH public key.
1260 struct {
1261 select (KeyExchangeAlgorithm) {
1262 case ec_diffie_hellman: ClientECDiffieHellmanPublic;
1263 } exchange_keys;
1264 } ClientKeyExchange;
1266 Actions of the sender:
1268 The client selects an ephemeral ECDH public key corresponding to the
1269 parameters it received from the server according to the ECKAS-DH1
1270 scheme from IEEE 1363 [5]. It conveys this information to the client
1271 in the ClientKeyExchange message using the format defined above.
1273 Actions of the recipient:
1275 The server retrieves the client's ephemeral ECDH public key from the
1276 ClientKeyExchange message and checks that it is on the same elliptic
1277 curve as the server's ECDH key.
1279 5.8 Certificate Verify
1281 When this message is sent:
1283 This message is sent when the client sends a client certificate
1287 Gupta, et al. Expires June 1, 2005 [Page 23]
1288 \f
1289 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1292 containing a public key usable for digital signatures, e.g. when the
1293 client is authenticated using the ECDSA_sign mechanism.
1295 Meaning of the message:
1297 This message contains a signature that proves possession of the
1298 private key corresponding to the public key in the client's
1299 Certificate message.
1301 Structure of this message:
1303 The TLS CertificateVerify message is extended as follows.
1305 enum { ecdsa } SignatureAlgorithm;
1307 select (SignatureAlgorithm) {
1308 case ecdsa:
1309 digitally-signed struct {
1310 opaque sha_hash[sha_size];
1311 };
1312 } Signature;
1314 For the ecdsa case, the signature field in the CertificateVerify
1315 message contains an ECDSA signature computed over handshake messages
1316 exchanged so far. ECDSA signatures are computed as described in
1317 Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a
1318 pair of integers r and s. These integers are both converted into
1319 byte strings of the same length as the curve order n using the
1320 conversion routine specified in Section 4.3.1 of [6]. The two byte
1321 strings are concatenated, and the result is placed in the signature
1322 field.
1324 Actions of the sender:
1326 The client computes its signature over all handshake messages sent or
1327 received starting at client hello up to but not including this
1328 message. It uses the private key corresponding to its certified
1329 public key to compute the signature which is conveyed in the format
1330 defined above.
1332 Actions of the receiver:
1334 The server extracts the client's signature from the CertificateVerify
1335 message, and verifies the signature using the public key it received
1336 in the client's Certificate message.
1343 Gupta, et al. Expires June 1, 2005 [Page 24]
1344 \f
1345 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1348 5.9 Elliptic Curve Certificates
1350 X509 certificates containing ECC public keys or signed using ECDSA
1351 MUST comply with [11] or another RFC that replaces or extends it.
1352 Clients SHOULD use the elliptic curve domain parameters recommended
1353 in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10].
1355 5.10 ECDH, ECDSA and RSA Computations
1357 All ECDH calculations (including parameter and key generation as well
1358 as the shared secret calculation) MUST be performed according to [5]
1359 using the ECKAS-DH1 scheme with the identity map as key derivation
1360 function, so that the premaster secret is the x-coordinate of the
1361 ECDH shared secret elliptic curve point, i.e. the octet string Z in
1362 IEEE 1363 terminology.
1364 Note that a new extension may be introduced in the future to allow
1365 the use of a different KDF during computation of the premaster
1366 secret. In this event, the new KDF would be used in place of the
1367 process detailed above. This may be desirable, for example, to
1368 support compatibility with the planned NIST key agreement standard.
1370 All ECDSA computations MUST be performed according to ANSI X9.62 [6]
1371 or its successors. Data to be signed/verified is hashed and the
1372 result run directly through the ECDSA algorithm with no additional
1373 hashing. The default hash function is SHA-1 [7] and sha_size (see
1374 Section 5.4 and Section 5.8) is 20. However, an alternative hash
1375 function, such as one of the new SHA hash functions specified in FIPS
1376 180-2 [7], may be used instead if the certificate containing the EC
1377 public key explicitly requires use of another hash function. (The
1378 mechanism for specifying the required hash function has not been
1379 standardized but this provision anticipates such standardization and
1380 obviates the need to update this document in response. Future PKIX
1381 RFCs may choose, for example, to specify the hash function to be used
1382 with a public key in the parameters field of subjectPublicKeyInfo.)
1384 All RSA signatures must be generated and verified according to PKCS#1
1385 [9].
1399 Gupta, et al. Expires June 1, 2005 [Page 25]
1400 \f
1401 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1404 6. Cipher Suites
1406 The table below defines new ECC cipher suites that use the key
1407 exchange algorithms specified in Section 2.
1409 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? }
1410 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? }
1411 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? }
1412 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
1413 CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
1414 CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
1416 CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? }
1417 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? }
1418 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
1419 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
1420 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
1422 CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? }
1423 CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? }
1424 CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
1425 CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
1426 CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
1428 CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? }
1429 CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? }
1430 CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
1431 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
1432 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
1434 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? }
1435 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? }
1436 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
1437 CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
1438 CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
1440 Table 5: TLS ECC cipher suites
1443 Figure 30
1445 The key exchange method, cipher, and hash algorithm for each of these
1446 cipher suites are easily determined by examining the name. Ciphers
1447 other than AES ciphers, and hash algorithms are defined in [2]. AES
1448 ciphers are defined in [14].
1450 Server implementations SHOULD support all of the following cipher
1451 suites, and client implementations SHOULD support at least one of
1455 Gupta, et al. Expires June 1, 2005 [Page 26]
1456 \f
1457 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1460 them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
1461 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
1462 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and
1463 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
1511 Gupta, et al. Expires June 1, 2005 [Page 27]
1512 \f
1513 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1516 7. Security Considerations
1518 This document is based on [2], [5], [6] and [14]. The appropriate
1519 security considerations of those documents apply.
1521 One important issue that implementors and users must consider is
1522 elliptic curve selection. Guidance on selecting an appropriate
1523 elliptic curve size is given in Figure 1.
1525 Beyond elliptic curve size, the main issue is elliptic curve
1526 structure. As a general principle, it is more conservative to use
1527 elliptic curves with as little algebraic structure as possible - thus
1528 random curves are more conservative than special curves such as
1529 Koblitz curves, and curves over F_p with p random are more
1530 conservative than curves over F_p with p of a special form (and
1531 curves over F_p with p random might be considered more conservative
1532 than curves over F_2^m as there is no choice between multiple fields
1533 of similar size for characteristic 2). Note, however, that algebraic
1534 structure can also lead to implementation efficiencies and
1535 implementors and users may, therefore, need to balance conservatism
1536 against a need for efficiency. Concrete attacks are known against
1537 only very few special classes of curves, such as supersingular
1538 curves, and these classes are excluded from the ECC standards that
1539 this document references [5], [6].
1541 Another issue is the potential for catastrophic failures when a
1542 single elliptic curve is widely used. In this case, an attack on the
1543 elliptic curve might result in the compromise of a large number of
1544 keys. Again, this concern may need to be balanced against efficiency
1545 and interoperability improvements associated with widely-used curves.
1546 Substantial additional information on elliptic curve choice can be
1547 found in [4], [5], [6], [8].
1549 Implementors and users must also consider whether they need forward
1550 secrecy. Forward secrecy refers to the property that session keys
1551 are not compromised if the static, certified keys belonging to the
1552 server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key
1553 exchange algorithms provide forward secrecy protection in the event
1554 of server key compromise, while ECDH_ECDSA and ECDH_RSA do not.
1555 Similarly if the client is providing a static, certified key,
1556 ECDSA_sign client authentication provides forward secrecy protection
1557 in the event of client key compromise, while ECDSA_fixed_ECDH and
1558 RSA_fixed_ECDH do not. Thus to obtain complete forward secrecy
1559 protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange,
1560 with ECDSA_sign used for client authentication if necessary. Here
1561 again the security benefits of forward secrecy may need to be
1562 balanced against the improved efficiency offered by other options.
1567 Gupta, et al. Expires June 1, 2005 [Page 28]
1568 \f
1569 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1572 8. Acknowledgments
1574 The authors wish to thank Bill Anderson and Tim Dierks.
1623 Gupta, et al. Expires June 1, 2005 [Page 29]
1624 \f
1625 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1628 9. References
1630 9.1 Normative References
1632 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
1633 Levels", RFC 2119, March 1997.
1635 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
1636 2246, January 1999.
1638 [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
1639 T. Wright, "Transport Layer Security (TLS) Extensions",
1640 draft-ietf-tls-rfc3546bis-00.txt (work in progress), Nov. 2004.
1642 [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
1643 <http://www.secg.org/>.
1645 [5] IEEE, "Standard Specifications for Public Key Cryptography",
1646 IEEE 1363, 2000.
1648 [6] ANSI, "Public Key Cryptography For The Financial Services
1649 Industry: The Elliptic Curve Digital Signature Algorithm
1650 (ECDSA)", ANSI X9.62, 1998.
1652 [7] NIST, "Secure Hash Standard", FIPS 180-2, 2002.
1654 [8] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
1656 [9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version
1657 1.5", PKCS 1, November 1993.
1659 [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
1660 2000, <http://www.secg.org/>.
1662 [11] Polk, T., Housley, R. and L. Bassham, "Algorithms and
1663 Identifiers for the Internet X.509 Public Key Infrastructure
1664 Certificate and Certificate Revocation List (CRL) Profile", RFC
1665 3279, April 2002.
1667 9.2 Informative References
1669 [12] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
1670 Sizes", Journal of Cryptology 14 (2001) 255-293,
1671 <http://www.cryptosavvy.com/>.
1673 [13] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol
1674 Version 3.0", November 1996,
1675 <http://wp.netscape.com/eng/ssl3/draft302.txt>.
1679 Gupta, et al. Expires June 1, 2005 [Page 30]
1680 \f
1681 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1684 [14] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
1685 Transport Layer Security (TLS)", RFC 3268, June 2002.
1687 [15] Hovey, R. and S. Bradner, "The Organizations Involved in the
1688 IETF Standards Process", RFC 2028, BCP 11, October 1996.
1691 Authors' Addresses
1693 Vipul Gupta
1694 Sun Microsystems Laboratories
1695 16 Network Circle
1696 MS UMPK16-160
1697 Menlo Park, CA 94025
1698 USA
1700 Phone: +1 650 786 7551
1701 EMail: vipul.gupta@sun.com
1704 Simon Blake-Wilson
1705 Basic Commerce & Industries, Inc.
1706 96 Spandia Ave
1707 Unit 606
1708 Toronto, ON M6G 2T6
1709 Canada
1711 Phone: +1 416 214 5961
1712 EMail: sblakewilson@bcisse.com
1715 Bodo Moeller
1716 University of California, Berkeley
1717 EECS -- Computer Science Division
1718 513 Soda Hall
1719 Berkeley, CA 94720-1776
1720 USA
1722 EMail: bodo@openssl.org
1725 Chris Hawk
1726 Corriente Networks
1728 EMail: chris@corriente.net
1735 Gupta, et al. Expires June 1, 2005 [Page 31]
1736 \f
1737 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1740 Nelson Bolyard
1742 EMail: nelson@bolyard.com
1791 Gupta, et al. Expires June 1, 2005 [Page 32]
1792 \f
1793 Internet-Draft ECC Cipher Suites for TLS Dec. 2004
1796 Intellectual Property Statement
1798 The IETF takes no position regarding the validity or scope of any
1799 Intellectual Property Rights or other rights that might be claimed to
1800 pertain to the implementation or use of the technology described in
1801 this document or the extent to which any license under such rights
1802 might or might not be available; nor does it represent that it has
1803 made any independent effort to identify any such rights. Information
1804 on the procedures with respect to rights in RFC documents can be
1805 found in BCP 78 and BCP 79.
1807 Copies of IPR disclosures made to the IETF Secretariat and any
1808 assurances of licenses to be made available, or the result of an
1809 attempt made to obtain a general license or permission for the use of
1810 such proprietary rights by implementers or users of this
1811 specification can be obtained from the IETF on-line IPR repository at
1812 http://www.ietf.org/ipr.
1814 The IETF invites any interested party to bring to its attention any
1815 copyrights, patents or patent applications, or other proprietary
1816 rights that may cover technology that may be required to implement
1817 this standard. Please address the information to the IETF at
1818 ietf-ipr@ietf.org.
1821 Disclaimer of Validity
1823 This document and the information contained herein are provided on an
1824 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1825 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1826 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1827 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1828 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1829 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1832 Copyright Statement
1834 Copyright (C) The Internet Society (2004). This document is subject
1835 to the rights, licenses and restrictions contained in BCP 78, and
1836 except as set forth therein, the authors retain all their rights.
1839 Acknowledgment
1841 Funding for the RFC Editor function is currently provided by the
1842 Internet Society.
1847 Gupta, et al. Expires June 1, 2005 [Page 33]
1848 \f