Re: [TLS] Fwd: Updated elliptic curve drafts

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 13 October 2015 05:23 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 4333B1B37CA for <tls@ietfa.amsl.com>; Mon, 12 Oct 2015 22:23:34 -0700 (PDT)
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 PTZFyRlpyPGo for <tls@ietfa.amsl.com>; Mon, 12 Oct 2015 22:23:32 -0700 (PDT)
Received: from filtteri6.pp.htv.fi (filtteri6.pp.htv.fi [213.243.153.189]) by ietfa.amsl.com (Postfix) with ESMTP id C88291B37C8 for <tls@ietf.org>; Mon, 12 Oct 2015 22:23:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by filtteri6.pp.htv.fi (Postfix) with ESMTP id 4519656F75E; Tue, 13 Oct 2015 08:23:30 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from smtp4.welho.com ([213.243.153.38]) by localhost (filtteri6.pp.htv.fi [213.243.153.189]) (amavisd-new, port 10024) with ESMTP id ejgmPAXc809F; Tue, 13 Oct 2015 08:23:29 +0300 (EEST)
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 DB3AE5BC010; Tue, 13 Oct 2015 08:23:29 +0300 (EEST)
Date: Tue, 13 Oct 2015 08:23:29 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20151013052329.GA18808@LK-Perkele-V2.elisa-laajakaista.fi>
References: <87oag395kx.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <87oag395kx.fsf@latte.josefsson.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/7SOOEmPkkVeeyDRTviJV5z_Rwbs>
Cc: tls@ietf.org
Subject: Re: [TLS] Fwd: Updated elliptic curve 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: <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: Tue, 13 Oct 2015 05:23:34 -0000

On Mon, Oct 12, 2015 at 10:47:58PM +0200, Simon Josefsson wrote:
> 
> The following document adds new EdDSA key/signature OIDs directly:
> 
> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04

The certificate example seems to contain OID 1.3.101.100.1... Is that
intended or should it be 1.3.101.101?

IIRC, someone pointed mistake in OIDs before, dunno if that has been
corrected.
 
> The following document adds new namedCurve OIDs, thus going indirectly
> through the existing ECDSA 3279 route:
> 
> https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01

I think this approach is unsuitable for signature keys, but it would
be suitable for X25519/X448 DH public keys, which some people apparently
have been requesting (IiRC, I have heard requests for that, don't
remember from whom)..

And AFAICT, those keys don't have associated hashes, and such public keys
should be marked for DH only (1.3.132.1.12).

> These two drafts take different approaches to including the new curves
> into PKIX, and currently both lack applicability statements.  There is
> potential for overlap and conflict right now.  It recently came up that
> for PKCS#11 a namedCurve approach would be useful, but for normal PKIX
> Certificates, it may be that the first direct approach is preferrable.
> The former lack the possibility of encoding keys for DH.  I believe each
> approach can be useful on its own, but we need to include text adressing
> use-cases that can be resolved by both documents to avoid conflicts.

IMO, new algorithm is more suited for signature keys, whereas new curve
is more suited for DH public keys.

This is because there is currently no way to designate correct algorithm
for signatures[1], whereas there is for DH, so one just needs to
designate correct curve.


[1] ECDSA uses "unrestricted", which has been implicated in TLS ECDH
KCI MITM attack (equivalent attack doesn't work for "discrete" DH because
signature keys are distinct from DH keys).



-Ilari