Subject: [TLS] Re: Moving forward on draft-ietf-tls-ecc-*

From: [email-masked] (David Wagner)
Date: Thu, 16 Sep 2004 01:48:45 +0000 (UTC)

Eric Rescorla  wrote:
>I'm not disputing these performance numbers, but I think they
>rather miss the point.
>
>There are really two common scenarios in which SSL/TLS is used:
>(1) PC client (fast client, fast server)
>(2) Handheld client (flow client, fast server)
>[...] the party who benefits from ECC is the server. However, this
>is not a particularly interesting optimization [...]

Well, I don't know.  I'm not so sure about this.  I won't argue with
you about TLS-HTTP (though I'm not convinced that there are no benefits
for TLS-HTTP: if you can do in software what would otherwise require a
hardware accelerator, that might be a benefit).  However, TLS is more
than just a way of securing web traffic, and I think the analysis changes
when you look at applications other than TLS.

When people come to me asking for some way to build a secure channel
for use in their custom application, I like to point them to TLS as
the canonical way to do it (rather than rolling their own scheme).
Many of these custom applications could benefit from something like ECC.
If TLS is intended as a general protocol for transport layer security,
I don't think it is accurate to say that there is no benefit from ECC.
That said, I don't claim to know what the threshold should be for adding
new schemes like ECC to TLS, so I'm not making any strong arguments here.

P.S. I hope this makes it through the anti-spam filtering.

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

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 27 Sep 2004 22:25:48 -0700

Eric Rescorla wrote:

>In either situation, the vast majority of connections involve
>anonymous clients and authenticated servers.  
>
>So, the cost matrix looks like this:
>
>            Client              Server
>-----------------------------------------------
>RSA    |   2 pubkey ops         1 private key op
>ECC    |   ECDSA vfy + ECDH     ECDH
>
>Now, RSA public key ops are MUCH faster (a factor of 2-3 on your
>8-bit platforms) than ECDSA verifies or ECDH operations. 
>This is basically a no-op in the PC client case because the
>client is so fast anyway, but in the Handheld client case,
>it's a big lose for ECC.
>
>Because ECDH is much faster than an RSA private key operation,
>the party who benefits from ECC is the server.

This comparison assumes that you don't care about forward secrecy
(i.e. keeping encrypted application data secret against adversaries
who recover the secret keys corresponding to the server certificate
after the communication has taken place).  Sometimes this might
be adequate, but usually it is just a bad compromise -- a common
scenario indeed, but we shouldn't be too happy about this state of
affairs.  If we consider forward secrecy, the comparison will have to
involve ECDH vs. DH.

The ECC TLS draft also provides for ephemeral ECDH with RSA
certificates because of the advantages of RSA signatures --
faster verification, and wide-spread deployment.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 28 Sep 2004 06:41:54 -0700

> affairs.  If we consider forward secrecy, the comparison will have to

You're right, I don't care much about forward secrecy. And since this
mode has been available with SSL since day one and yet practically
noone seems to avail themselves of it, I assert that the market
doesn't care about it either.

-Ekr

---

From: Daniel Brown <[email-masked]>
Date: Thu, 30 Sep 2004 08:07:51 -0400

Eric Rescorla wrote on 09/28/2004 09:41:54 AM:

> no one seems to avail themselves of it, I assert that the market

Yesterday, NIST released the first public draft of Special Publication 
800-52, Guidelines on the Selection and Use of Transport Layer Security. 
This draft recommends using the *_DHE_* ciphersuites because they provide 
forward secrecy.  The market of the US Federal Government agencies may 
soon care about forward secrecy.  Here's the announcement:

NIST is pleased to announce the first public draft of Special Publication 
800-52, Guidelines on the Selection and Use of Transport Layer Security. 
This document is a guideline for implementing
Transport Layer Security in the Federal Government to protect sensitive 
information. Care must be taken when selecting cryptographic mechanisms 
for authentication, confidentiality, and message integrity, as some 
choices are non-compliant with Government standards, or may pose
security risks. The comment period for this document will be 30 days, 
ending on November 1st, 2004. Please direct all comments and questions to 
Matthew J. Fanto at [email-masked].

URL for the Drafts page on CSRC is:
http://csrc.nist.gov/publications/drafts.html

        Dan