Re: [TLS] Straw poll on draft-ietf-tls-ecc-*

[Bodo Moeller <[e-mail]>]

Eric Rescorla wrote:

> This is a Straw Poll in the fate of draft-ietf-tls-ecc-*.
[...]
> This Straw Poll will run for the next week (through Tuesday
> October 5th.) Please register your opinion by then, either
> to me or to the list.

I vote for option A ("Advance draft-ietf-tls-ecc-* to Proposed
Standard").

My reasons include:

* IPR:

   I don't buy the claim "Clearly, ECC is a patent minefield"
   made in <[e-mail]>
   (http://www.imc.org/ietf-tls/mail-archive/msg04342.html).

   I am, of course, well aware of the wide-spread *perception*
   that ECC was a patent minefield.  But clearly, there is a lot of
   prior art preceding any known ECC patents; I cited some of it in
   <[e-mail]>
   (http://www.imc.org/ietf-tls/mail-archive/msg04309.html).
   There are actually no more patent issues to worry about for elliptic
   curves with ECDH or ECDSA than for conventional DH and DSA,
   unless you are specifically using certain new patented techniques
   (which often involve special classes of curves that you wouldn't
   normally run into unless you are determined to).


   Some think that the S/MIME ECC RFC 3278, "Use of Elliptic Curve
   Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)"
   (April 2002), which is Informational, sets an example that the TLS ECC
   RFC should follow.  But actually RFC 3278 uses the MQV protocol which
   is clearly patented, whether with or without elliptic curves;
   so I acknowledge that there was a good reason to make RFC 3278
   Informational for IPR reasons.  This reason does not affect the
   current TLS ECC draft: draft-ietf-tls-ecc-06.txt does not use
   MQV (early revisions did, but the specification has since been
   changed so that it avoids this patent-encumbered technique).


   There's one thing specified in draft-ietf-tls-ecc-06.txt that
   requires a patented technique: The draft specifies the use
   of point compression, as a "MAY".  Uncompressed points are the
   default and a "MUST" (TLS extensions are used to negotiate
   whether point compression is permissible, so support of point
   compression cannot affect interoperability, just efficiency).
   Point compression is affected by patents just in the case of curves
   over characteristic-2 fields; there's no problem for prime fields.


* Technical:

   One of the advantages of elliptic curve cryptography is that
   its expected security is better than that of RSA or conventional DH.
   This is a somewhat fuzzy statement; more precisely, we know that
   attacks against RSA and DH have subexponential complexity, while
   attacking ECC requires exponential time (around 2^k steps for
   ECC over (2k)-bit fields).  If 1024-bit RSA remains secure in
   practice, this is not much to worry about; but we cannot be sure
   of this (for example, Dan Bernstein is working on efficient
   factorization circuits, see http://cr.yp.to/talks/2004myths2.pdf
   and elsewhere; he is going to announce results in February 2005
   at the SHARCS conference).  Increasing keylengths to improve
   security has a more noticeable effect on performance for RSA and
   DH than for ECC (with its exponential complexity of known
   attacks).

   Currently (i.e. in the light of just those attacks that are already
   known to be practical), there's a performance argument in favor of ECC
   in particular if you want forward secrecy: To create symmetric keys
   that cannot be recovered by someone who obtains a warrant or just
   breaks in without asking anyone first to obtain your long-time server
   key, TLS can  used either Diffie-Hellman (with the ciphersuites
   specified in RFC 2246 and the rfc2246-bis draft) or elliptic curve
   Diffie-Hellman (ECDH, with the ciphersuites specified in the the TLS
   ECC draft).  Depending on the nature of the content that you are
   protecting with TLS, forward secrecy may not matter; in particular, it
   is a waste of time if you are using TLS mainly for authentication and
   don't worry about the possibility that someone might be able to
   decrypt the TLS sessions after the fact.  But when forward secrecy is
   desired, having ECDH available certainly is a plus.

   And of course, there's the potential possibility that RSA might turn
   out to be insecure when new attacks are discovered.  In this case
   it is good to have an alternative ready to switch to.  I am too
   optimistic to really worry about this, so I am mostly listing this
   additional argument for completeness.


It should be noted that ECC support for TLS has been available in open
source software implementations for a while (since 2002): both
mozilla.org and OpenSSL have it in appropriate revisions.  So when
we are discussing the TLS ECC draft, we are not talking about vaporware
or about a specification that would only be used by rare commercial
products.  This is something that would be available for everyone to
use without much of a hassle.  (You just wouldn't get point compression
for characteristic-2 fields unless you license the appropriate patent,
but that's a small loss.)




_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls