Re: [TLS] Early code point assignments for 25519/448 curves

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 28 November 2015 14:49 UTC

Return-Path: <ilariliusvaara@welho.com>
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 E32041B2B39 for <tls@ietfa.amsl.com>; Sat, 28 Nov 2015 06:49:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 dnERTt8_SGvb for <tls@ietfa.amsl.com>; Sat, 28 Nov 2015 06:49:01 -0800 (PST)
Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id 063051B2B34 for <tls@ietf.org>; Sat, 28 Nov 2015 06:49:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id 9FF4C19C1D1; Sat, 28 Nov 2015 16:48:59 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id ruR+npY6mmKV; Sat, 28 Nov 2015 16:48:59 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp4.welho.com (Postfix) with ESMTPSA id 759B25BC005; Sat, 28 Nov 2015 16:48:59 +0200 (EET)
Date: Sat, 28 Nov 2015 16:48:57 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20151128144857.GA11924@LK-Perkele-V2.elisa-laajakaista.fi>
References: <385E6AFF-52C3-4E40-A69F-178602A449A7@sn3rd.com> <45D7CFCA-1ABE-4123-9E27-4DB5B8B6D9DA@gmail.com> <CABkgnnX15PcEByT2-Q9eS2d5o1C_WfQ2VUJ30iGN_N1BX1WuXQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABkgnnX15PcEByT2-Q9eS2d5o1C_WfQ2VUJ30iGN_N1BX1WuXQ@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/C4nu9KIMrwC7OClZO1zbxes2Adg>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Early code point assignments for 25519/448 curves
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 28 Nov 2015 14:49:03 -0000

On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote:
> 
> Are we happy that we will only be needing the PureEdDSA variants and
> that no-one will be asking for the HashEdDSA versions?  I ask because
> I've heard it suggested (I think Karthik mentioned this) that we might
> want to sign the transcript directly in TLS 1.3 rather than rely on
> collision-resistance of the selected hash function.  That would be
> harder without access to HashEdDSA.

Also, one problem with signing the transcript directly is that because
of the context prefixes, one would either have to buffer all messages
or compute multiple hashes.

It is made worse by the fact that some hashes and signatures don't
mix very well. For example, trying to use SHA-512 with ECDSA is not a
good idea[1] (and nobody knows yet what the heck X448ph will use[2]).

Also, does the present 1-RTT construct in fact rely on collision-
resistance of the prf-hash?


[1] Well, it would be a good idea with ECDSA/P-521, but who uses
that?


[2] Proposals so far have included:
- SHA-512
- SHA3-512 (whee, SLOW)
- Shake256@512b (not a hash, but cryptographically looks OK).
- Sakee256@512b with some prefixing.
(That's just including the ones in more formal proposing, not
the earlier more handwavy proposals).


-Ilari