Re: [Cfrg] options

Andrey Jivsov <crypto@brainhub.org> Fri, 09 January 2015 20:51 UTC

Return-Path: <crypto@brainhub.org>
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 52F521A1A2F for <cfrg@ietfa.amsl.com>; Fri, 9 Jan 2015 12:51:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 IFYXrhqp_K4G for <cfrg@ietfa.amsl.com>; Fri, 9 Jan 2015 12:51:12 -0800 (PST)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845BC1A1A23 for <cfrg@irtf.org>; Fri, 9 Jan 2015 12:51:12 -0800 (PST)
Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-03v.sys.comcast.net with comcast id dwpl1p0062N9P4d01wrBk6; Fri, 09 Jan 2015 20:51:11 +0000
Received: from [IPv6:::1] ([71.202.164.227]) by resomta-ch2-13v.sys.comcast.net with comcast id dwrA1p0084uhcbK01wrA57; Fri, 09 Jan 2015 20:51:11 +0000
Message-ID: <54B03F3E.3020108@brainhub.org>
Date: Fri, 09 Jan 2015 12:51:10 -0800
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, 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> <54AFA179.4010403@cs.tcd.ie>
In-Reply-To: <54AFA179.4010403@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1420836671; bh=SvzfKYKMN+8Idq9q+keL3HPS3BGClBaZq2mggutb1rA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=uuSqJ28rB0VFfaSgIjm538GWgVBDkjqFUfMahXOD2ROPSdScOx305mxWs7DFkJR+2 all2e+CI1s1ckYHhCI2Aj6gBNOHFSrwoohC2kAM8UyMRKUbtaQlaC0vCNYpfyQObho dV8m5n/Trd4G9hlaI/v2VjcY59vj75Nc11ZKZRHlzsPfP4RZuzwZz4EsydMWvgX85s LokzQ+46bRxVmlrHbyLz+ALGKJ+HBR3IKJAANbKvUT8+4QRNw/58sObL1lKd8K/pX2 LQ4KND/7tR/H30MM3kq3u1MZElMrHap3avwRIVljXy7wSY0plRV0Z7T20BwfSsB/pJ IOhr3HFiD7bqw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/DLwFRO-3w2RqvWl0dXzH0LuGAP4>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] options
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 20:51:15 -0000

Hello Stephen. I agree in general that fewer options is a good thing.

The current format on the wire:
   (x)
proposal:
   (x,y)

The second covers the first.

While the point representation negotiation defined in TLS works OK IMO, 
the de-facto standard on the Internet is to use uncompressed point. 
(x,y) above is a natural choice then. (If you like Montgomery ladder, 
just ignore the other 32 bytes representing the y; one shouldn't care 
about 32 bytes in a ~4Kb TLS handshake).

Assessing significance is subjective. Not sending y means square root 
calculation for some implementations, which has cost of recovering y at 
~10%, which narrows the choice of implementations (including the future 
ones). I would say that I care about 10% because Curve25519 Montgomery 
ladder is ~60% faster than P-256 on modern x86.

There is likely to be a greater performance benefit to send y at 
security level beyond P-256. A single format across security strengths 
and algorithm types means fewer options.

On 01/09/2015 01:38 AM, Stephen Farrell wrote:
>
> 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
>>