Re: [Cfrg] options

[Andrey Jivsov <[e-mail]>]

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
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
>>