[Cfrg] options (was: Re: Adoption of draft-agl-cfrgcurve-00 as a RG document)

[Stephen Farrell <[e-mail]>]

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
>