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

Ilari Liusvaara <> Sat, 30 May 2015 06:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 53F7A1A92AD for <>; Fri, 29 May 2015 23:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EnpxLoae7NRl for <>; Fri, 29 May 2015 23:43:06 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C31161A9142 for <>; Fri, 29 May 2015 23:43:05 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id B1A9A9004B; Sat, 30 May 2015 09:43:03 +0300 (EEST)
Date: Sat, 30 May 2015 09:43:03 +0300
From: Ilari Liusvaara <>
To: Simon Josefsson <>
Message-ID: <20150530064303.GA20551@LK-Perkele-VII>
References: <> <20150520203011.GA25549@LK-Perkele-VII> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
Archived-At: <>
Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 30 May 2015 06:43:09 -0000

On Fri, May 29, 2015 at 11:14:39PM +0200, Simon Josefsson wrote:
> Ilari Liusvaara <> writes:
> > On Wed, May 20, 2015 at 07:14:47PM +0200, Simon Josefsson wrote:
> >>
> >
> > More ciphersuites? The signature algorithm negotiation (extension 13)
> > doesn't work in practice?
> Yoav suggested reusing the ECDSA ciphersuites with (I assume) a new
> 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.

> > 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.
> 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.

(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

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

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

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.