[Cfrg] options (was: Re: Adoption of draft-agl-cfrgcurve-00 as a RG document)
Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 09 January 2015 09:38 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 4BC341A86FE for <cfrg@ietfa.amsl.com>; Fri, 9 Jan 2015 01:38:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 GTG2oD4EIE2S for <cfrg@ietfa.amsl.com>; Fri, 9 Jan 2015 01:38:06 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7441A8730 for <cfrg@irtf.org>; Fri, 9 Jan 2015 01:38:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D8FC9BF04; Fri, 9 Jan 2015 09:38:03 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhhqNVZnc69r; Fri, 9 Jan 2015 09:38:02 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.42.18.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1EC25BEF0; Fri, 9 Jan 2015 09:38:02 +0000 (GMT)
Message-ID: <54AFA179.4010403@cs.tcd.ie>
Date: Fri, 09 Jan 2015 09:38:01 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Andrey Jivsov <crypto@brainhub.org>, Watson Ladd <watsonbladd@gmail.com>
References: <54AAE2CA.1080701@isode.com> <54AEF855.4090100@brainhub.org> <CACsn0cm01o4vhwwzs_WNpLq6vnA_cBchvLNS+Eyg5YZH_hQyMg@mail.gmail.com> <54AF1C99.5070308@brainhub.org>
In-Reply-To: <54AF1C99.5070308@brainhub.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/RD-Pz7VkRKgotxHwuW5Exx_HwC8>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: [Cfrg] options (was: Re: Adoption of draft-agl-cfrgcurve-00 as a RG document)
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: Fri, 09 Jan 2015 09:38:16 -0000
Hiya, Not on the crypto but on the options bit, and with an IETF participant hat firmly on my head... I would hope that CFRG will not include any optional things unless there is a significant benefit from doing so *and* very very clear guidance for non-security experts on when to pick which option. Having options that only offer a marginal benefit would I think be fairly clearly harmful. I'm happy that CFRG folks can and will evaluate the performance and side channel etc. aspects of that. If some help is needed with information as to whether there's a possible significant benefit for some particular (kind of) protocol, then I'm very happy to help find the right developers or IETF folk to ask. (I'm sure Alexey would do that anyway though, but I can help if needed.) If the result of this exercise does have some options, then it'll be very important that those come with very clear and easy to understand guidance as to when to choose which option. That guidance needs to be understandable by a non-security expert - there are many cases where non-security folks add security features to their protocols and by the time those do get reviewed by someone who'd understand ECC it can be too late to make changes to PDU formats, management models etc. If CFRG cannot include such explanatory text, then I really hope you just pick one of the optional things and drop the rest. The reasons to not like options here are that IETF WGs and then implementers will make different choices leading to a lack of interop and tooling difficulty. The interop issue would likely arise if the guidance on when to use which option wasn't sufficiently clear. Or if a protocol has use-cases that match the guidance for more than one option. In either case protocol designers will probably just include all the options and pass on the difficulty to implementers and deployments. And when those make different choices we'd see interop issues. The tooling issue would be arise if different protocols make different choices. In that case, we'd likely see tools developed that only support one option and that could delay deployment for protocols that need one of the other options. So pretty please, no options without significant benefits *and* utterly crisp and easily understood guidance as to when to use which option. Thanks, S. On 09/01/15 00:11, Andrey Jivsov wrote: > On 01/08/2015 01:51 PM, Watson Ladd wrote: >> Three points: >> >> 1: There are recurring security issues caused by not sending >> compressed points, as well as additional complexity >> 2: We're not talking about signatures in this draft. >> 3: Options are bad. > > Regarding options, this draft is a foundational document of a low-level > crypto primitive. Protocols above can still pick a single wire format. > > The spec should allow, for example, S/MIME to select (x) for space > saving, while TLS to select (x,y) for performance. (I am not making > these choices here). > > The entire document is an optional primitive. SuiteB and Brainpool > curves will be around for awhile. > > One might say that the proposed tweak retains a single format, which is > (x,y), with an available (internal) optimization to use x with a > Montgomery ladder. > > > Re: security issues, the easiest fix would be to add one paragraph to to > check that (x,y) is on the curve. The spec already deals with the > cofactor>1 in section 9.1. > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg >
- [Cfrg] Adoption of draft-agl-cfrgcurve-00 as a RG… Alexey Melnikov
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Adam Langley
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Stephen Farrell
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Watson Ladd
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Tony Arcieri
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Adam Langley
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Ilari Liusvaara
- [Cfrg] (please make draft an IETF document first)… Rene Struik
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Paul Lambert
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … David Leon Gil
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Michael Hamburg
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Alyssa Rowan
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Dan Brown
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … David Gil
- Re: [Cfrg] (please make draft an IETF document fi… Alexey Melnikov
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Sean Turner
- Re: [Cfrg] (please make draft an IETF document fi… Alexey Melnikov
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Watson Ladd
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Andrey Jivsov
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Adam Langley
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Andrey Jivsov
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Watson Ladd
- [Cfrg] options (was: Re: Adoption of draft-agl-cf… Stephen Farrell
- [Cfrg] No longer talking about Adoption of draft-… Alexey Melnikov
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Joppe Bos
- Re: [Cfrg] options (was: Re: Adoption of draft-ag… Paul Hoffman
- Re: [Cfrg] options Andrey Jivsov
- Re: [Cfrg] draft-agl-cfrgcurve-00 point format (w… Alyssa Rowan
- Re: [Cfrg] draft-agl-cfrgcurve-00 point format Andrey Jivsov
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Robert Ransom
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Ilari Liusvaara
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Robert Ransom
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Alexey Melnikov
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Alexey Melnikov
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Tony Arcieri
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Alexey Melnikov
- Re: [Cfrg] Adoption of draft-agl-cfrgcurve-00 as … Stephen Farrell
- [Cfrg] (technical flaws to be corrected in next v… Rene Struik
- Re: [Cfrg] (technical flaws to be corrected in ne… Adam Langley
- Re: [Cfrg] (technical flaws to be corrected in ne… Rene Struik
- Re: [Cfrg] (technical flaws to be corrected in ne… Adam Langley