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

[Vipul Gupta <[e-mail]>]

I, too,  vote for option A (advance to proposed standard).

vipul

On Sep 29, 2004, at 6:56 PM, Bodo Moeller wrote:

> 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


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