Re: [TLS] Updated EdDSA in TLS drafts

Ilari Liusvaara <> Mon, 08 June 2015 10:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2B4F41A1A2E for <>; Mon, 8 Jun 2015 03:39:46 -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 zGzjlMe50kHD for <>; Mon, 8 Jun 2015 03:39:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 684ED1A038E for <>; Mon, 8 Jun 2015 03:39:43 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id F2DD1404E; Mon, 8 Jun 2015 13:39:40 +0300 (EEST)
Date: Mon, 8 Jun 2015 13:39:40 +0300
From: Ilari Liusvaara <>
To: Simon Josefsson <>
Message-ID: <20150608103940.GA25285@LK-Perkele-VII>
References: <>
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] Updated EdDSA in TLS drafts
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: Mon, 08 Jun 2015 10:39:46 -0000

On Mon, Jun 08, 2015 at 11:52:23AM +0200, Simon Josefsson wrote:
> Hello.
> I've updated my EdDSA-in-TLS draft to clarify the choice of
> HashAlgorithm that goes together with the EdDSA SignatureAlgorithm,
> please see:

What hash algorithm is internally used? EdDSA does not fix that
(Ed25519 does fix it to SHA-512).

Does more need to be said about how R and S are packed into single
blob for signature (concatenate)?

More ciphersuites. Eew.

Also, in TLS 1.2 Client CertificateVerify (does not apply to server
certificate, nor either certificate in TLS 1.3) signs the entiere
handshake so far. That could be many kilobytes in size, spread over
multiple message.

> The other feedback I have received is to reuse the existing ECDSA
> ciphersuites.  I think this is a good idea, and believe it would likely
> work, but it is a fundamentally different approach.  I created another
> draft to describe that approach, now published as:

TLS 1.0 and 1.1 lack algorithm specification for signature, which is
very useful for merging ciphersuites like this. In theory, one could
infer the algorithm from certificate, but I don't think that kind
of tricks are very often pulled off.

I don't know if mixing curves used for key exchange and curves used
for signing is a good idea. Signing is much more complicated than

The point format used by EdDSA has very little to do with montgomery X
(it does not have the same number of bits). The point format is little-
endian encoding of 2^(b-1)*lsb(x)+y, b is 256 for Curve25519, and lsb(x)
is x mod p mod 2. X and Y are edwards coordinates.

Also, notes about not seemingly fixing the hash, encoding of signature
and TLS 1.2 client certs apply.
> For more context, related to the above is a draft describing OIDs for
> EdDSA for use in PKIX certificates as public keys and a signature
> algorithm:

Repeating the definitions sounds bit odd, one could presumably just
state what to put in each field.

Public key encoding? Edwards points have two coordinates. The usual
EdDSA encoding (32 octets for Curve25519)?

Hash algorithm? Note that public keys are not compatible across hash
algoritmhs. Fixed to SHA-512?

Signature encoding? Presumably the same as on TLS side.