Subject: [Unbearable] Ed25519 should be a choice

From: Bill Cox <[email-masked]>
Date: Wed, 2 Sep 2015 15:52:02 -0700

>From QUIC:

TLS, non-forward-secure handshake: server, 1S (1100µs); client, 1P (34µs).
TLS, forward-secure handshake: server, 1S + 1F + 1A (1301µs); client, 1P +
1F + 1A (235µs).
QUIC: server, 2A (100µs); client, 1F + 2A + 1P (184µs).

(The operations needed for the client to verify the certificate chain are
not included.)

If we pick common primitives for each of these (RSA 2048 for the public and
private operations, ECDH P-256 for TLS forward security and Curve25519 for
QUIC) then we obtain the example times in parenthesis on an i7-3770S. If
QUIC were to use P-256 then the server times would be 300µs and the client
would be 385µs, so a fair amount of the gain comes from using better
primitives.

This is no small issue.  Server-side speed and memory usage in TLS
connections is absolutely critical.  Are we not adding Ed25519_SHA256
because of some restriction from ITEF?  With our own TLS extension, are we
really all that restricted?  For that matter, if we have the ability to add
different hashes, I'd advocate for Blake2s, which is faster than MD5, and
has excellent credentials.

Thanks,
Bill

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 2 Sep 2015 16:13:49 -0700

More generally, I would suggest Tokbind at least support whatever the CFRG
suggests as a signature standard, at least for a 128-bit security level.
This might end up being Ed25519.

On Wed, Sep 2, 2015 at 3:52 PM, Bill Cox <[email-masked]> wrote:

> If we pick common primitives for each of these (RSA 2048 for the public
> and private operations, ECDH P-256 for TLS forward security and Curve25519
> for QUIC) then we obtain the example times in parenthesis on an i7-3770S.
> If QUIC were to use P-256 then the server times would be 300µs and the
> client would be 385µs, so a fair amount of the gain comes from using better
> primitives.
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

-- 
Tony Arcieri

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Sep 2015 00:14:14 +0100

The IRTF's CFRG are currently in the process of selecting a
signature algorithm based on the same curve as used in Curve25519.

That is not going to be precisely Ed25519 but could be an
extension of that from the same folks. The reason Ed25519 won't be
picked is to preserve the init-update-final API mode of operation
that has been traditional for signature schemes in order to deal with
challenged devices. Please see the CFRG mailing list for details.

I'm hoping that IETF WGs that want signature schemes based on new
curves will agree to hold on the (hopefully) short while that CFRG
tell us will be needed before they're done.

S.

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 2 Sep 2015 16:17:39 -0700

On Wed, Sep 2, 2015 at 4:14 PM, Stephen Farrell <[email-masked]>
wrote:

> The reason Ed25519 won't be picked is to preserve the init-update-final
> API mode of operation that has been traditional for signature schemes in
> order to deal with challenged devices. Please see the CFRG mailing list for
> details.

Note that at least two variants of EdDSA have been submitted which meet
this requirement by prehashing the content while also supporting a non-IUF
mode which does not. Depending on how you interpret the chair's
requirements this may technically be a violation, but so far they haven't
voiced any disapproval of this approach so I guess it's ok?

Anyway, it's still too soon to tell what the CFRG would standardize, but I
would strongly suggest whatever algorithm they standardize be at least
recommended to implement for Tokbind.

-- 
Tony Arcieri