Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-ecc-01.txt

From: [email-masked]
Date: Mon, 02 Apr 2001 07:17:54 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title		: ECC Cipher Suites For TLS
	Author(s)	: S. Blake-Wilson, T. Dierks, C. Hawk
	Filename	: draft-ietf-tls-ecc-01.txt
	Pages		: 22
	Date		: 30-Mar-01
	
This document describes additions to TLS to support Elliptic Curve
Cryptography (ECC). In particular it defines new key exchange 
algorithms which use the Elliptic Curve Digital Signature Algorithm 
(ECDSA) and the Elliptic Curve Diffie-Hellman Key Agreement Scheme 
(ECDH), and it defines how to perform client authentication with ECDSA
and ECDH.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tls-ecc-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-tls-ecc-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 2 Apr 2001 16:22:33 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-01.txt

Before looking at several details, let me note that the following
complaint about draft-ietf-tls-ecc-00.txt (March 1998) still applies:

Date: Mon, 19 Mar 2001 14:39:49 +0100
From: Bodo Moeller <[email-masked]>
To: IETF Transport Layer Security WG <[email-masked]>
Subject: Re: [ietf-tls] Re: I-D cipher suite numbers
Message-ID: <[email-masked]>
Lines: 207

[...]         If a client announces in its ClientHello message that it
supports one particular ciphersuite of those defined in
draft-ietf-tls-ecc-00.txt (TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
say), then with the draft as it is now the client must be prepared to
be faced with curve definitions over any of GF(p) or GF(2^m) with ONBs
or GF(2^m) with 'trinomial' basis representation or GF(2^m) with
'pentanomial' basis representation.  The server can do with
implementing just one of these -- after all, it is the server that
gets to choose the curve --, but the client must be able to handle all
of these to ensure interoperability.  There is no way for the client
to say 'I can do ECDH_ECDSA, but only with curves over GF(p)' or 'only
using normal bases', and this makes draft-ietf-tls-ecc-00.txt pretty
useless for weak clients.

[...]

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

(For ideas on what to do about this, see that message.)

< 2.  Elliptic Curve Key Exchange Algorithms

<    Key
<    Exchange
<    Algorithm          Description                        Key size limit
< 
<    ECDH_ECDSA         ECDH with ECDSA signatures         None
<    ECDH_ECDSA_EXPORT  ECDH with ECDSA signatures         ECDH=163 bits,
<                                                          ECDSA=none
<    ECDH_RSA           ECDH with RSA signatures           None
<    ECDH_RSA_EXPORT    ECDH with RSA signatures           ECDH=163 bits,
<                                                          RSA = none
<    ECDH_anon          Anonymous ECDH, no signatures      None
<    ECDH_anon_EXPORT   Anonymous ECDH, no signatures      ECDH=163 bits
< 
<                      Table 2: Key exchange algorithms

None of the new key exchange methods provides both forward secrecy and
authentication.  The new draft uses ephemeral ECDH only for anonymous
ciphersuites; otherwise, the server's DH share must be in its
certificate.  Forward secrecy is a desireable property (and comes at
almost no additional cost for clients when RSA signatures are used
since RSA signature verification is very fast), so there really should
be ECDHE_ECDSA and ECDHE_RSA ciphersuites.

Defining ECDHE_RSA ciphersuites has the additional practical advantage
that many servers already have RSA certificates; i.e., they could
start to use ECC ciphersuites without having to obtain additional
certificates.

< 4.2.  Server Key Exchange
  
<      struct {
<          opaque point <1..2^8-1>;
<      } ECPoint;
< 
< point 
< This is the byte string representation of an elliptic curve point
< following the conversion routine in [X9.62], section 4.3.6.

Use of the definite article suggests that there is a single byte
string representation for a given elliptic curve point.  This is not
the case; there are three forms to choose from (compressed,
uncompressed, and hybrid).  The specification should clarify which
forms may be used (all three of them?) and possibly which one is
recommended (uncompressed?).

< 4.1.  Server Certificate

< [PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in
< X.509 certificates. Servers SHOULD use the elliptic curve domain
< parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2
< [FIPS186-2], and SEC 2 [SEC2]. [...]

< 4.4. Client Certificate

< [PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in
< X.509 certificates. Clients SHOULD use the elliptic curve domain
< parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2
< [FIPS186-2], and SEC 2 [SEC2]. [...]

Readers might think that these "SHOULD"s apply to those curves that
are present in *all* of these specifications, whereas the intended
meaning presumably is that any curve recommended by any one of them
is OK.

If it is in the scope of the ECC-TLS specification to recommend
particular curves for public keys in X.509 certificates, then the
specification probably should also explicitly recommend the use of a
"namedCurve" (where available) rather then explicit "ecParameters" in
certificates for ECC keys.

Thus the above portions might be changed as follows:

     [PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in
     X.509 certificates. Servers SHOULD use elliptic curve domain
     parameters recommended in at least one of ANSI X9.62 [ANSIX962], FIPS 186-2
     [FIPS186-2], and SEC 2 [SEC2]. If elliptic curve domain parameters are
     used for which a "named curve" definition exists in ANSI X9.62 [ANSIX962]
     or SEC 2 [SEC2], then these parameters SHOULD not be included explicitly.
     [...]

(Accordingly for clients.)

< 4.2.  Server Key Exchange
  
<      enum { explicit_prime (1), explicit_char2 (2),
<             named_curve (3), (255) } ECCurveType;
[...]
< named_curve
< Indicates that a named curve will be used. The use of this option is
< strongly recommended. 

Why not use the RFC 2119 keyword "SHOULD" here as well?

< 4.5.  Client Key Exchange
  
<      enum { yes, no } EphemeralPublicKey;

This should be

       enum { yes(0), no(1) } EphemeralPublicKey;

(or rather "no(0), yes(1)", which appears more natural).  The RFC 2246
syntax requires explicit numbering.  (Exception: "For enumerateds that
are never converted to external representation, the numerical
information may be omitted."  Obviously this does not apply here.)

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 2 Apr 2001 16:29:34 +0200

[...]

Not literally, of course -- there are no ONBs on draft-ietf-tls-ecc-01.txt,
and the example ciphersuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA does
not exist in the current draft.

---

---

From: Mark Winstead <[email-masked]>
Date: Mon, 2 Apr 2001 10:06:09 -0400

There is a small error in this document. There is a bibliography reference
on page 3 to [LEN], but there is no [LEN] in the bibliography.

Of course, I reserve the right to make more comments later :)

Mark Winstead
(Insert job title here)
NetOctave, Inc
RTP, NC
www.netoctave.com
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 02, 2001 7:18 AM
To: IETF Transport Layer Security WG
Cc: [email-masked]
Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-ecc-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Transport Layer Security Working Group of
the IETF.

Send a message to:
	[email-masked].
In the body type:

---

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Mon, 2 Apr 2001 12:31:52 -0400

Thanks Mark. The reference should be:

"[LEN] A. Lenstra and E. Verhuel. Selecting cryptographic key sizes.
Available at: www.cryptosavvy.com."

I've added it to the draft so it will appear in the next rev.

Best regards. Simon

Mark Winstead <[email-masked]> on 04/02/2001 10:06:09 AM

Please respond to "IETF Transport Layer Security WG"
      <[email-masked]>

To:   "IETF Transport Layer Security WG" <[email-masked]>
cc:    (bcc: Simon Blake-Wilson/Certicom)
Subject:  [ietf-tls] RE: I-D ACTION:draft-ietf-tls-ecc-01.txt

Mark Winstead
(Insert job title here)
NetOctave, Inc
RTP, NC
www.netoctave.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 02, 2001 7:18 AM
To: IETF Transport Layer Security WG
Cc: [email-masked]
Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-ecc-01.txt

Send a message to:
     [email-masked].
In the body type:

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Mon, 2 Apr 2001 18:43:03 +0200

Not being much of an ECC guy, some general comments from me.

I do not quite understand the rationale for including exportable
ciphersuites. I was under the impression that they have become obsolete with
the new U.S. export policies.

Also, ECDH_ECDSA and ECDH_RSA define exportable ciphersuites for RC4_40 and
RC4_56, but ECDH_anon for DES_40 and RC4_40. Is that discrepancy
intentional?

A different issue are the client certificate types in the certificate
request message. I would suggest skipping values 5 and 6 to avoid
interoperability problems with SSL 3.0, which defined those values with
different semantics.

 Andreas Sterbenz              mailto:[email-masked]

---

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Mon, 2 Apr 2001 13:23:32 -0400

Hi Andreas,

Thanks for the comments. Responses embedded below.

Best regards. Simon

SBW> The only rationale was that I don't understand export restrictions
but would like to include cipher suites which allow as broad use as
possible. What's the current WG policy on export cipher suites>

SBW> Discrepancy not intentional. I'll fix in the appropriate way
based on the answer to the question above.

SBW> Will do.

---

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Mon, 2 Apr 2001 18:43:03 +0200

---

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Mon, 2 Apr 2001 13:05:29 -0400

Thanks for the comments! Some responses embedded below.

Best regards. Simon

SBW> Please note that the 01 draft was already finished when you
sent the email ... and thanks for raising the point again.

SBW> I'd argue that this concern is addressed to a large extent
by curve recommendations ... provided the server follows the
"SHOULD" about what curves to use, and the client implements the
curves, everything will work fine. I believe, for example, that
Certicom have implementations for constrained devices that support
all the recommended curves

SBW> I agree forward secrecy is a desirable attribute, but it does
come at an additional cost - basically an ephemeral key pair gen
for servers and a sig verify for clients.

SBW> The decision to leave out ECDHE suites was based on a desire
expressed by a number of people I've spoken to keep the number of
cipher suites small. If the consensus is to add them back, it's
fine with me.

SBW> How would you feel about the following compromise - no ECDHE
cipher suites, but a recommendation for servers that want FS to
perform an authenticated handshake followed by an anon handshake
over the secured record layer? (This would provide FS wouldn't it?)

SBW> Good point ... will do.

SBW> Good point ... will clarify.

SBW> I was planning to leave this to the PKIX group, but will add if
you think it's appropriate.

< named_curve

SBW> Will do.

This should be

SBW> Forgive my ignorance ... when is this info converted
to external representation? (I know it affects what is sent in
the client key exchange message, but from a quick inspection, I don't
see where it is communicated ... instead it is implied from the key
exchange method and client auth method, isn't it?.)

---

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 3 Apr 2001 09:51:14 +0200

> Not literally, of course -- there are no ONBs on draft-ietf-tls-ecc-01.txt,

This again is not quite true: While draft-ietf-tls-ecc-01.txt does not
specify ONBs for the ECCurve type (which is used for ephemeral DH), it
does not forbid using ONBs for other EC cryptography (ECDSA, or
certificate-based ECDH).

---

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 3 Apr 2001 11:33:56 +0200

On Mon, Apr 02, 2001 at 01:05:29PM -0400, Simon Blake-Wilson wrote:

>> 'pentanomial' basis representation. [...]

> Please note that the 01 draft was already finished when you
> I'd argue that this concern is addressed to a large extent

*All* of them, including those based on ONBs?  X9.62 defines curves
using ONBs, but SEC 2 doesn't (and I hear that several people have
problems even to verify that the purported generators of those X9.62
curves actually lie on the curve).

But even if the server can be expected to restrict itself to SEC 2
curves, the client will have to implement different kinds of field
arithmetics and different kinds of EC operations to guarantee
interoperability.  This makes it impossible for clients to rely on
specialized hardware circuits.  As far as implementation effort is
concerned, I'd say the difference between
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA with GF(p) curves and the same
ciphersuite with GF(2^m) curves is more significant than, for example,
the difference between TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA and
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (with curves of the same type for
these two ciphersuites).  But while a client can instruct the server
that it supports just 3DES and not AES, it cannot express that it
supports just GF(2^m) and not GF(p) or just GF(p) and not GF(2^m).

There's nothing inherently wrong about clients that don't support all
kinds of curves, so why not specify the protocol such that the client
hello contains enough information for the server to decide how to
proceed without risking handshake failures?  (Instead of defining
additional ciphersuites, a client hello extension as defined in
draft-ietf-tls-wireless-00.txt could be used for additional
information on supported curves.)

> I agree forward secrecy is a desirable attribute, but it does

The server does not actually have to generate a new key pair for each
new session.  Typically it will be acceptable to keep the key pair
for, say, an hour (or any other interval that is sufficiently shorter
than the lifetime of a session).  More of an issue is the necessity for
the server to sign its parameters during each new handshake.  If ECDSA
signatures are used, this should mean less than 20% overhead per
handshake (using a moderate amount of precomputation).  If RSA
signatures are used, the server overhead is more noticeable.

At the client side, RSA signature verification is very cheap,
so ECDHE_RSA won't be a problem even for slow clients.

> The decision to leave out ECDHE suites was based on a desire
> How would you feel about the following compromise - no ECDHE

This would provide forward secrecy, but at a higher cost (increased
latency, and in many cases additional public-key operations).

If there were a necessity to avoid adding more ciphersuites, I'd say
replace all TLS_ECDH_RSA_... ciphersuites by TLS_ECDHE_RSA_...
ciphersuites.  This would impose nearly no additional computational
effort on clients, and would insure that existing RSA certificates
can be used with ECC ciphersuites (more efficiently than with the
current TLS_DHE_RSA_... ciphersuites).

There is actually no need to have TLS_ECDHE_*_WITH_NULL_*
ciphersuites: You cannot hope for forward secrecy if you don't encrypt
in the first place.  Also it may turn out that the EXPORT ciphersuites
are not needed (are there any actual export regulations defining a
163-bit limit for ECC?).  So we are not talking about a huge list
of additional ciphersuites:

  CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA             = { 0x00, 0x?? }
  CipherSuite TLS_ECDHE_ECDSA_WITH_DES_CBC_SHA             = { 0x00, 0x?? }
  CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA        = { 0x00, 0x?? }
  CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA         = { 0x00, 0x?? }
  CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA         = { 0x00, 0x?? }
  CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA               = { 0x00, 0x?? }
  CipherSuite TLS_ECDHE_RSA_WITH_DES_CBC_SHA               = { 0x00, 0x?? }
  CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00, 0x?? }
  CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA           = { 0x00, 0x?? }
  CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA           = { 0x00, 0x?? }

> I was planning to leave this to the PKIX group, but will add if

I'm not sure if this should be just in the PKIX specs or here as
well.  (draft-ietf-pkix-ipki-pkalgs-02.txt says that

   In general, use of "well-known" curves, such as the "named curves"
   from ANSI X9.62 is a sound strategy,

but does not actually specificy that in this case "namedCurve"
parameters should be employed.  Also draft-ietf-pkix-ipki-pkalgs-02.txt
does not reference SEC 2.)  But if we say that certain parameters
"SHOULD" be used in certificates, then why not provide the additional
recommendation to avoid explicit "ecParameters" when possible?
Of course we can leave this to the PKIX specification, but in that
case why not leave curve recommendations for certificates to it as
well?

> Forgive my ignorance ... when is this info converted
> to external representation?

You are right, it is never converted to external representation (it
only appears in a "select()").  So the definition in the draft is
sufficient.

---

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Wed, 25 Apr 2001 23:28:09 -0400

Hi,

Thanks for the feedback ... sorry for the slow turn around. My thoughts embedded
below.

> curves actually lie on the curve).

SBW> I believe all SEC2 and FIPS186-2 curves.

> specialized hardware circuits.

SBW> Specialized hardware that supports a range of field sizes should be fine.
Specialized hardware that supports only one field seems like a tough sell for
ECC in TLS with or without this functionality unless you can convince servers to
go out and get a bunch of certificates.

> information on supported curves.)

SBW> I have no problem with the idea of defining additional hints in a hello
extension. I think it would be good to write up a draft about this ... the issue
seems to me to be more general than ECC ... for example it would be good to also
allow hints about min and max key sizes for DH, DSA, and RSA, especially with
AES around creating a desire to use commeasurate key sizes.

> So we are not talking about a huge list of additional ciphersuites:
>

SBW> I can live with adding these as optional cipher suites, but then I'm not
one of the strongest proponents of minimizing the number of new cipher suites.
I'll add them to the draft unless anyone cares to speak up against.

Thanks again for the feedback.

Best regards. Simon

---

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 26 Apr 2001 11:23:42 +0200

On Wed, Apr 25, 2001 at 11:28:09PM -0400, Simon Blake-Wilson wrote:

[...]

> Specialized hardware that supports a range of field sizes should be fine.

We can expect typical servers to have RSA certificates as a fallback
given that most clients don't support anything else.  Similarly,
typical clients will support RSA ciphersuites as well given that most
servers have an RSA certificate only.  Only in closed world scenarios
you can do without RSA (and then it shouldn't be a problem to require
everyone to support a specific curve).

Also the curve is not always defined by a certificate; consider the
ECDH_anon/ECDHE family of ciphersuites.

---