Re: [Cfrg] options

Andrey Jivsov <> Fri, 09 January 2015 20:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 52F521A1A2F for <>; Fri, 9 Jan 2015 12:51:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IFYXrhqp_K4G for <>; Fri, 9 Jan 2015 12:51:12 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id 845BC1A1A23 for <>; Fri, 9 Jan 2015 12:51:12 -0800 (PST)
Received: from ([]) by with comcast id dwpl1p0062N9P4d01wrBk6; Fri, 09 Jan 2015 20:51:11 +0000
Received: from [IPv6:::1] ([]) by with comcast id dwrA1p0084uhcbK01wrA57; Fri, 09 Jan 2015 20:51:11 +0000
Message-ID: <>
Date: Fri, 09 Jan 2015 12:51:10 -0800
From: Andrey Jivsov <>
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 <>, Watson Ladd <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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: <>
Cc: "" <>
Subject: Re: [Cfrg] options
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:

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