Re: [Cfrg] When's the decision?

David Jacobson <dmjacobson@sbcglobal.net> Tue, 07 October 2014 04:08 UTC

Return-Path: <dmjacobson@sbcglobal.net>
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 CA9FB1A911E for <cfrg@ietfa.amsl.com>; Mon, 6 Oct 2014 21:08:01 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 QjN-r3B8Tufn for <cfrg@ietfa.amsl.com>; Mon, 6 Oct 2014 21:07:59 -0700 (PDT)
Received: from nm15-vm4.access.bullet.mail.gq1.yahoo.com (nm15-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.103]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CA71A1A16 for <cfrg@irtf.org>; Mon, 6 Oct 2014 21:07:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1412654879; bh=rxkJLUuVBvHnGqUluZJxQtUEhDZ4fFmH50dUYB5Hxx4=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:From:Subject; b=PUZxrPEEyfZR9O939cjzb+e/RTbRLw8Cl2h1DilWTpRFUkgBpjJgrHPZAIxx3cnCBT/+oQvUl57Mk6c30ZwmTL9AWyqSIjh8Movp3DSBy36O2/8HOM59d7RNVIqDEjYSCdabQtQr0XQiquUGY+mFgpkqxYLwteT7AnKEllPZfD8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; b=rN+8FTgzQPB8ERgjg2cKGD/zSol3KrrckMlxuEa973NWh0/diRo+jUCDDrCL28o5zoTDPW7L5uWUlV9j+lkfMikTJahFiU0S1h24+ZfFM1dMo9GhiWvbiOkZNJfuZyHPgMnUNeHaZ1siTIaOivZ0q8uyiJiFpLuxyMnT+g9xngE=;
Received: from [216.39.60.175] by nm15.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 Oct 2014 04:07:59 -0000
Received: from [67.195.22.113] by tm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 07 Oct 2014 04:07:59 -0000
Received: from [127.0.0.1] by smtp115.sbc.mail.gq1.yahoo.com with NNFMP; 07 Oct 2014 04:07:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1412654879; bh=rxkJLUuVBvHnGqUluZJxQtUEhDZ4fFmH50dUYB5Hxx4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=J7Rk8tZH/DqSmQjHUuUhcJQ+oSEMG8rWv5W+jXD0BVdm9kX0uF1y78esb6ZigCMyNrnYZOwAZRE+MiwLUT7z3lYJhriDkMp3s9GarMx3RUGdtOvOVnt1nlLU9/SwfzoqwDlEQlmJv/AzXaYYAgSsuGyuEnyRQ0Myrvu59orK3GU=
X-Yahoo-Newman-Id: 116154.50389.bm@smtp115.sbc.mail.gq1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: GaWNrScVM1k88QgDdCMMEyhKX_QA4QjRl5VSn.hE2Nv2j9O T0s5jAl_NAVaFtmogniRWmy9oga.D.3jPeBqxHA._QeJB3HWRElO.S6xZCHs 5ls9ECbA50Fo1jzwGIymo9i_EGbNqrsdT5UYCAUSV0.CovtOLZ5O0It6AJ35 OZgiXu7oySzjA2ceSUIQpeJXxahERGciOZm0iIkC9tF4Ap.mT808A.1Frtuk MzIy5o9r6UKcJxKDRVR.dlTYnUf0JbcLgtVX5985XY3ItiY.8hnmflbIocu. VXl..2NFPW2oxSUwvcB7kTzkSoowYVnB3vvvttZq76nevbJjFrSMF2dsF0v_ TuqT2Qebz0NfzX3a6AhWrpg8pibIr2_CX7L7Kv0qMh8rJaYWjGz8p74sOkq. i2QPhoPZl2x.u8RfYyVOSv7r_jx.fVj6sFhRPGEtTWO2d1s2MnBtB5vFx2YL GsT2_UJBhOid9Fq_uDY4yafXH5wtwz7R79KYKtZVhR.fiW7bBzZZhoRiliju qK4C1ZGL7noVzvtg0zoqaKHhV83NNywyP8Z2gqBMOWfRIPpGo9hpZFjxQ
X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g--
Message-ID: <5433671E.9080308@sbcglobal.net>
Date: Mon, 06 Oct 2014 21:07:58 -0700
From: David Jacobson <dmjacobson@sbcglobal.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Watson Ladd <watsonbladd@gmail.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <CACsn0cnHDc6_jWf1mXc5kQgj5XEc6dBBZa7K8D2=4uLti5e3aA@mail.gmail.com> <3EE5AEA5-3ADE-4D67-AC51-478074349D1B@gmail.com> <5432BBF1.5060003@cs.tcd.ie> <CACsn0cmwJh295=R8Ns3Y01UTLBwoQAg5g_PB=yN6nJUCYxgqnw@mail.gmail.com>
In-Reply-To: <CACsn0cmwJh295=R8Ns3Y01UTLBwoQAg5g_PB=yN6nJUCYxgqnw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------080401040304070206020702"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/BfzzHr29-wQof4f70M17wjlNvY8
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] When's the decision?
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, 07 Oct 2014 04:08:02 -0000

On 10/6/14, 4:28 PM, Watson Ladd wrote:
>
>
> On Oct 6, 2014 8:57 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie 
> <mailto:stephen.farrell@cs.tcd.ie>> wrote:
> >
> >
> > Hiya,
> >
> > On 06/10/14 16:53, Yoav Nir wrote:
> > > They're all good enough
> >
> > Tend to agree. But CFRG, pretty-please don't pick them all!
>
> This ignores the significance of choices such as which coordinates to 
> use on the wire, whether to use compression, and which signature 
> scheme to use.
>
> These are not make or break items, and any curve could be used several 
> ways, but these issues do not go away with the choice of curve.
> >
> > If you do we'll just have to pick elsewhere (e.g. saag or
> > specific IETF wgs) with less clue immediately involved.
>
> Agreed: the buck stops here.
> >
> > S.
> >
>
>
I've implemented elliptic curve systems quite a few times.  But never 
with compression.  (The patent just expired.)  Could someone with 
experience implementing compression and with the short list of 
candidates, comment, for each curve, on how much of a hassle compression 
is to write, how much it expands the code, and how much it slows down 
the computation?

If the hassle, code bloat, and slowdown are minor, I suggest we just do 
compressed.  (Rationale:  Compression is always a win so do compressed.  
Keep it simple---no options)

If the hassle, code bloat, or slowdown are considerable, I suggest we 
require uncompressed and make compressed optional.  (Rationale: 
Compression is sometimes a win, e.g. for applications were bits on the 
wire are precious, and sometimes a lose.  For guaranteed 
interoperability there should be one variant that is always there, and 
that one should be the simpler, smaller.)

This probably interacts with the on-the-wire representation.  That will 
make the deciding a bit harder, but such is life.

    --David Jacobson