Re: [Cfrg] Curve manipulation, revisited

Tony Arcieri <bascule@gmail.com> Tue, 30 December 2014 02:52 UTC

Return-Path: <bascule@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057A01AC400 for <cfrg@ietfa.amsl.com>; Mon, 29 Dec 2014 18:52:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 3fBLGWuNbHha for <cfrg@ietfa.amsl.com>; Mon, 29 Dec 2014 18:52:37 -0800 (PST)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B3F1ACEB8 for <cfrg@irtf.org>; Mon, 29 Dec 2014 18:52:36 -0800 (PST)
Received: by mail-oi0-f47.google.com with SMTP id v63so31159512oia.6 for <cfrg@irtf.org>; Mon, 29 Dec 2014 18:52:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4KPzspz9/Wd5jW3PA9BI+rtmsWdQm0PRPrHIE+e58Ks=; b=K3czi5Wa2V4G4XyrQ+4V3hJTOAd6ktg0PGXNItHiqqPShgH1SdpZZhoNUlhOG+0T4S q8/6UbUuUNjYahN+pirBDXMzmwE/iVZ1zU9QuLQDAEU3Xq4pBbTOmAr3IED6aRPqb+1J Jhw83we5nPgxDkXtDzUULMZ/RP33oPJTNVquK68B7s9BHNF5J+6xrlMLKHLmVS+yAtdi N6Wx/zz1a2beQwkvIVhTxM/WO9SlYlY0Tl60SJ0SNgd01MaTP5kJInZaAv9diUPq6i3t 6hse/AHGgVjwvNgYj9uns5eCnzfUUgOLjXbaUUNRYTjzbiqMvNbO2TCOTdx9PkuZJhNG SXBQ==
X-Received: by 10.202.182.11 with SMTP id g11mr32106560oif.13.1419907955819; Mon, 29 Dec 2014 18:52:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.227.225 with HTTP; Mon, 29 Dec 2014 18:52:15 -0800 (PST)
In-Reply-To: <CA+Vbu7zqFcu8d1053mZ_eEm0q=np6T3snSQ4rfY0k1-4hBVDsA@mail.gmail.com>
References: <CAMfhd9W684XMmXn3ueDmwrsQ_ZdiFG+VqYLxkvs7qDwiJdpk6w@mail.gmail.com> <1725646678.805875.1419539885135.JavaMail.yahoo@jws100115.mail.ne1.yahoo.com> <CAMfhd9Ua5fFZk46Xx1AN2VgyJ=Yng6fnO8aN-_ZfzXQn0Xbxhg@mail.gmail.com> <CA+Vbu7zqFcu8d1053mZ_eEm0q=np6T3snSQ4rfY0k1-4hBVDsA@mail.gmail.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Mon, 29 Dec 2014 18:52:15 -0800
Message-ID: <CAHOTMV+jO+8pvU4-McPb+t-4=0jp0-5Gg-3Psis+zZ-FRu-R3w@mail.gmail.com>
To: Benjamin Black <b@b3k.us>
Content-Type: multipart/alternative; boundary=001a113caa44520c8a050b661505
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/1mCYH1eVe-3CvgwTKDMUzuqGkbg
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Curve manipulation, revisited
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Dec 2014 02:52:40 -0000

On Sun, Dec 28, 2014 at 11:57 PM, Benjamin Black <b@b3k.us>; wrote:

> The request might've come from the TLS-WG, but it is almost inconceivable
> that something CFRG recommended to TLS-WG would not be quickly adopted by
> many other WGs. It is disingenuous to argue that since the request came
> from TLS-WG nothing outside TLS-WG should be a consideration while also
> arguing that things like cofactors for 1 (mod 4)  curves must be exactly
> (8,4) without giving an example of how it matters to TLS-WG. The latter is
> an implicit acknowledgement that the scope extends beyond TLS-WG.
> Similarly, suggesting that TLS-WG could be given only X25519 without
> Ed25519 being pulled in is either naive or an attempt to sneak them both in
> the back door.
>

I think you can avoid this slippery slope by the CFRG recommending
Curve25519 as one of potentially many curves at a 128-bit security level,
for now, as an interim solution, simply to avoid the current situation of
apparent infinite deadlock.

Proposal: If and when rigid curve generation guidelines can be agreed upon,
the CFRG can recommend an "updated" curve at a 128-bit security level.

Everything I've described is little different from exactly what's happening
right now: there's an informal agreement on Curve25519, and you would like
to specify a different curve based on "rigid" guidelines.

I'm afraid if we wait on the bikeshedding debate surrounding what
constitutes "rigidity" to conclude, we're just going to be stuck with the
existing choices forever.

Compromise to avoid the slippery slope: proceed with Curve25519 for D-H
with an option for a new curve in the future after the rigidity
bikeshedding debate is over, and postpone any Ed25519-related discussion
until after that.

Here in the real world we're still using RSA signatures. I don't know how
many years until the stuff being discussed here actually trickles down into
what I can practically use day-to-day.

-- 
Tony Arcieri