Re: [TLS] Updated EdDSA in TLS drafts

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Tue, 09 June 2015 09:43 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673F11B2B27 for <tls@ietfa.amsl.com>; Tue, 9 Jun 2015 02:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVtJstXFP1lZ for <tls@ietfa.amsl.com>; Tue, 9 Jun 2015 02:43:43 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FAE1B2B3D for <tls@ietf.org>; Tue, 9 Jun 2015 02:43:43 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 70EEB900B8; Tue, 9 Jun 2015 12:43:41 +0300 (EEST)
Date: Tue, 9 Jun 2015 12:43:41 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20150609094341.GA11347@LK-Perkele-VII>
References: <87zj4ah6i0.fsf@latte.josefsson.org> <20150608103940.GA25285@LK-Perkele-VII> <87sia1jn6q.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <87sia1jn6q.fsf@latte.josefsson.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mfb3Kqi8qcLoqhbi_dqJv38yD_k>
Cc: tls@ietf.org
Subject: Re: [TLS] Updated EdDSA in TLS drafts
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2015 09:43:49 -0000

On Tue, Jun 09, 2015 at 10:33:33AM +0200, Simon Josefsson wrote:
> Again, many thanks for feedback Ilari!
> 
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi>; writes:
> 
> > 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:
> >> 
> >> https://tools.ietf.org/html/draft-josefsson-tls-eddsa-01
> >
> > What hash algorithm is internally used? EdDSA does not fix that
> > (Ed25519 does fix it to SHA-512).
> 
> Yeah.  I think this is actually a larger question: will EdDSA be defined
> with other curves than Ed25519?  If no, the only interesting algorithm
> to specify is Ed25519.  If yes, the parameter choices needs to be
> encoded somehow.  The hash isn't the only parameter to EdDSA.

The requirements of EdDSA are so bizarre that I don't think there are
realistic curves to use with that besides Edwards form of Curve25519.

(Edwards form of M-379 might come the closest, but the needed 760-bit(!)
hash function is pretty much unobtabnium).

> > Does more need to be said about how R and S are packed into single
> > blob for signature (concatenate)?
> 
> I'm hoping draft-josefsson-eddsa-ed25519 already covers that.

Oh yeah.

> > More ciphersuites. Eew.
> 
> Yeah.  I offer this approach in the rare case that it might actually
> prove less complex to implement, and that some might find it useful.  I
> suspect it might get shot down during further discussions.

I checked the TLS 1.2 spec:
- If advertised ciphersuites and signature_algorithms conflict, latter
  takes precedence.
- If selected ciphersuite and signature algorithm in struct
  DigitallySigned conflict, latter takes percedence.

This means TLS_DHE_RSA_* key exchange can end up being signed with ECDSA,
if client told it supports ECDSA.

> > 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.
> 
> Some implementations buffer the entire handshake to deal with this
> problem.  I'm not sure what to recommend generally, or if this document
> has to care about this.

I was thinking maybe PRF-hash, since one has that running anyway (for
session_hash and finished) and it better be secure enough.

Or maybe buffering doesn't really matter.

> >> 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:
> >> 
> >> https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-00
> >
> > 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.
> 
> RFC 4492 defines SignatureAlgorithm for TLS 1.0 and 1.1, or am I
> misunderstanding what you are saying?

I mean the explicit signature algorithm in struct DigitallySigned. That
was new in TLS 1.2.

Without that, one is left guessing the algorithm from the certificate,
which is quite unclean.


-Ilari