Re: [TLS] Updated EdDSA in TLS drafts

Simon Josefsson <simon@josefsson.org> Tue, 09 June 2015 11:10 UTC

Return-Path: <simon@josefsson.org>
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 181631A00D4 for <tls@ietfa.amsl.com>; Tue, 9 Jun 2015 04:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
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 a_MN5OiR_pvA for <tls@ietfa.amsl.com>; Tue, 9 Jun 2015 04:10:11 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F541A00CA for <tls@ietf.org>; Tue, 9 Jun 2015 04:10:11 -0700 (PDT)
Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t59B9u8Q011913 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 9 Jun 2015 13:09:57 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
References: <87zj4ah6i0.fsf@latte.josefsson.org> <20150608103940.GA25285@LK-Perkele-VII> <87sia1jn6q.fsf@latte.josefsson.org> <20150609094341.GA11347@LK-Perkele-VII>
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
X-Hashcash: 1:22:150609:ilari.liusvaara@elisanet.fi::5+rd2GXnZFzUR79u:Dj1H
X-Hashcash: 1:22:150609:tls@ietf.org::Asa22/REGgCrytvo:wHPB
Date: Tue, 09 Jun 2015 13:09:55 +0200
In-Reply-To: <20150609094341.GA11347@LK-Perkele-VII> (Ilari Liusvaara's message of "Tue, 9 Jun 2015 12:43:41 +0300")
Message-ID: <87k2vddtoc.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/40UDg8QaAqnPJ6HW4Dm3Z5YHKMo>
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 11:10:13 -0000

Ilari Liusvaara <ilari.liusvaara@elisanet.fi>; writes:

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

Okay.  If that is really the case, we should specify Ed25519 directly
and don't bother with EdDSA.  But if there is a chance that we'll see
other curves used with EdDSA, then it would be better to specify EdDSA
and instantiate it for Ed25519 with some parameter choice.

I believe this is an important question, but I lack knowledge to make a
decision.

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

Can't you build one with a keyed PRF?

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

While a bit ugly, language could be added to the TLS-Ed25519 document
saying what to do in each case.  I don't propose to do this, though,
just saying that the problem above could be solved if it was really
important.

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

Ah.  Would you then sign the PRF-hash with SHA-512 for Ed25519?

> Or maybe buffering doesn't really matter.

I think not.  Let's see.

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

Ah, right.  Maybe there should be words to that effect: If TLS 1.0 or
1.1 then look at the certificate to find out the algorithm to use.

Thanks again,
/Simon