Subject: [TLS] Strawman on EdDSA/Ed25519 in TLS

From: Simon Josefsson <[email-masked]>
Date: Wed, 20 May 2015 19:14:47 +0200

Dear WG,

Support for EdDSA/Ed25519 in TLS has been suggested a couple of times.
I have started to work on an I-D to describe more precisely what that
would actually mean, and here is an initial strawman document:

https://tools.ietf.org/html/draft-josefsson-tls-eddsa-00

I'm confident I missed some major pieces of the puzzle, but feedback and
review is welcome so the document can be improved into something that
can be implemented and interoperate.

Until the main parts have been fleshed out please email me directly and
I'll try to do the best I can to merge feedback into the document.  If
the WG chairs permit, that discussion could also be done on this list.
The best form of feedback would be in the form of merge requests or a
clearly described issue in the issue tracker.  Please see:

https://gitlab.com/jas/ietf-tls-eddsa

One aspect I'm aware of is that there is no OID allocated nor
specification of PKIX certificates with EdDSA/Ed25519 public keys.  I'm
not sure the above document is the right place for doing that though,
and more thinking around this topic is especially appreciated.

Cheers,
/Simon

---

From: Nico Williams <[email-masked]>
Date: Wed, 20 May 2015 14:07:28 -0500

> Support for EdDSA/Ed25519 in TLS has been suggested a couple of times.

I'm in favor.

> and more thinking around this topic is especially appreciated.

It's an OID.  You can get your own OID arc and then allocate an OID.

Is it important to separate the addition of a PKIX algorithm OID from
the TLS bits?  Well, it is neater that way.

Nico
--

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 20 May 2015 23:30:11 +0300

> can be implemented and interoperate.

More ciphersuites? The signature algorithm negotiation (extension 13)
doesn't work in practice?

> and more thinking around this topic is especially appreciated.

AFAIK, a way to put the key into PKIX SPKI is required for the
new signature algorithm to be useful.

And that means OIDs. The curve itself is 1.3.6.1.4.1.11591.15.1,
but AFAIK, there is no OID for the signature primitive.

I think one can find more expertise about how to put various
keys into SPKI in the PKIX mailinglist.

Reading the PKIX specs, it seems like there are two ways:

1) Use algorithm "Unresricted" and use a new point format to
denote LE edwards points.

2) Define new algorithm (OID) for EdDSA, put the curve OID
as parameter and the LE edwards point as the key.

-Ilari

---

From: Peter Bowen <[email-masked]>
Date: Thu, 21 May 2015 19:42:53 -0700

> the TLS bits?  Well, it is neater that way.

I'll donate a short OID to the cause if that will help move things
forward.  We have the 1.3.187 arc which is only three bytes DER.  If
someone has a smaller arc (third node would be 127 or lower) and would
offer an OID from their arc we can shave off another couple of bytes.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 May 2015 23:14:39 +0200

> doesn't work in practice?

Yoav suggested reusing the ECDSA ciphersuites with (I assume) a new
extension 13 value for eddsa.

> keys into SPKI in the PKIX mailinglist.

I'll try to prepare an email asking for help.

> as parameter and the LE edwards point as the key.

I prefer 2).  Given that EdDSA is not applicable to arbitrary curves,
you might want to allocate a new algorithm OID for Ed25519 directly with
no parameters.  This will reduce complexity a bit.

Thank you Ilari!

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 May 2015 23:18:50 +0200

> offer an OID from their arc we can shave off another couple of bytes.

Anyone?  I have 1.3.6.1.4.1.11591 but it is much longer.

If you can allocate one OID for PKIX-EdDSA and one for PKIX-Ed25519 we
have two values to work with for doing a PKIX EdDSA or Ed25519 draft.
It is not clear to me which approach is best, and if you have room for
two OIDs let have two different from the start in case people want to
experiment with both.

Thank you for thinking of saving bytes here! :-)

/Simon

---

From: Rob Stradling <[email-masked]>
Date: Fri, 29 May 2015 22:40:31 +0100

> Anyone?  I have 1.3.6.1.4.1.11591 but it is much longer.

CABForum has 2.23.140.  That's no shorter than Amazon's 1.3.187 OID though.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Kurt Roeckx <[email-masked]>
Date: Fri, 29 May 2015 23:45:58 +0200

> Anyone?  I have 1.3.6.1.4.1.11591 but it is much longer.

I see there is already a .15.1 there for ed25519 that is being used
by gpg.  They used 1.3.6.1.4.1.3029.1.5.1 before that.

IANA actually also has 1.3.90 that is unused as far as I know.

Kurt

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 30 May 2015 09:43:03 +0300

> extension 13 value for eddsa.

Actually, looking at TLS specs, one needs the codepoint useable with
extension 13 anyway for TLS 1.2 (and 1.3-editorscopy).

(This won't work with 1.0/1.1, but who really cares).

Then there is the hash algorithm field. There are basically three
choices here:
1) Don't use it for anything. Internal hash is fixed to SHA-512, no
   pre-hashing is performed.
2) Hash algorithm field determines pre-hash. Internal hash is fixed
   to SHA-512.
3) Hash algorithm field determines internal hash, no pre-hashing.

With 3), the hash algorithm pretty much has to have 512-bit output.

While pre-hashing is not a great idea for TLS 1.2 server certificate
and TLS 1.3 server/client certificate, it could be useful for TLS
1.2 client certificate, since that covers data from number of flights.

> no parameters.  This will reduce complexity a bit.

(Nit: s/EdDSA/Ed25519/)

Yeah, agreed. Also, new algorithm lets one define what is in the
BIT STRING field containing the key data.

I actually read PKIX again, and noticed something I did not notice
before:

There actually are two kinds of OIDs relevant to a new signature
algorithm

1) What OID(s) are allowed as key algorithms for that signature
algorithm. This also sets the format of keys (and what parameters
if any there are).

E.g. ECDSA uses unrestricted EC point, which specifies the standard
SEC1 encoding, and curve OID as a parameter.

2) What OID does the actual signature algorithm, when combined
with hash algorithm use. This sets the parameters given, if any
and the signature format.

E.g. ECDSA uses multiple OIDs, one for each allowed hash function
(e.g. one for ECDSA/SHA-256, another for ECDSA/SHA-384 and another
for ECDSA/SHA-512).

Given that Ed25519 fixes the hash, it would technically (in the
sense that the protocol works) work to use the same OID for both,
but I have no idea how existing PKIX software handles that sort of
thing.

Also, given that EdDSA public keys are only usable with one single
hash algorithm (since hash algorithm is part of public key derivation),
it would make sense to limit the keys to just single hash.

So there would be Ed25519 key type and Ed25519 signature algorithm.
As said I have no idea if these two can be the same OID (these always
appear in different contexts) or not.

-Ilari

---

From: Peter Bowen <[email-masked]>
Date: Sat, 30 May 2015 15:42:10 -0700

> IANA actually also has 1.3.90 that is unused as far as I know.

The 1.3 arc is not managed by IANA, it is managed per ISO/IEC 6523-2.
90 was skipped for some unknown reason. I asked to get 90 when I
applied, but found out that it will take ISO/IEC standards action to
get it assigned as the current requirement is to assign IDs under that
arc sequentially.

More power to you if you can get ISO/IEC to approve :)

Thanks,
Peter