Re: [Cfrg] revised requirements for new curves

["Paterson, Kenny" <[e-mail]>]

Adam,

Thanks for interrupting your holiday to participate in this discussion.

On 09/09/2014 21:23, "Adam Langley" <[e-mail]> wrote:

>(I'm commenting with my Google hat on. I'm on vacation at the moment
>and haven't circulated this around internally but I believe that this
>reflects our position. Where I'm less sure I've used "I".)
>
>> SE5. Required: each set of curve parameters should be generated by a
>> well-defined procedure that allows only a limited and quantified amount
>>of
>> flexibility. If the selected procedure involves the choice of an initial
>> seed, then the seed will be selected by multiple independent parties
>>using
>> a procedure having the property that no collusion of all but one or
>>fewer
>> of the parties can exert any control over the chosen seed. [RC]
>
>Although flexibility should be eliminated where possible, we believe
>that forgoing sensible optimisations because of a fear that someone
>might know a magic attack on a subset of curves and might be guiding
>the selection them that would be a mistake. We are not looking for a
>replacement for P-256 because we seriously worry that the NSA
>backdoored it. We're looking for a replacement because we think that
>we can get something much faster and simpler.
>
>Past a point, constraining the curve based on that fear isn't valuable to
>us.

It's good to get Google's view on what is the main driver for this
activity.


>
>> SE6. Required: the selected curves should provide levels of security
>>that
>> match to a good approximation 128-bit, 192-bit and 256-bit security
>> levels, as these levels are currently commonly understood in the wider
>> security community. [NC]
>
>We don't want three curves. I'm not completely convinced that we even
>want two, but two is plausible. For symmetric primitives, matching
>powers of two makes sense because it fits well with software
>implementation. For curves that motivation is much weaker.

Should we infer, then, that Google would prefer at most a single curve at
each security level (rather than, say, two)?

>Above the 120ish bit level one is no longer fighting stronger
>attackers, but hedging against a breakthrough (but not too much of
>one). Matching 192 or 256 bit security levels is a *misunderstanding*
>in the wider community, and is thus of the lowest priority.
>
>> IP2. Desired: securely, simply and efficiently implementable world-wide
>>in
>> a patent-free manner. [RC]
>
>This is probably a requirement for us, unless the "royalty-free" was
>legally strong, didn't include registration etc. I cannot specify
>exactly what we would require in that case because it's not my area.

Noted.

>
>> IN2. Required: minimise work needed to generate suitable OBJECT
>> IDENTIFIERs for Subject Public Key Information Fields, as defined in RFC
>> 5480 (PKIX). [C]
>
>I don't think that I understand what this means, or rather, I can't
>imagine how a curve could fail it. By having a name so long that it
>caused tooling problems perhaps?

William Whyte pointed out more or less the same thing. This was intended
more as a placeholder to remind us that we will have some PKIX work to do,
and as a contrast to the starting requirements (from David McGrew) which
looked more onerous (to me) at first. Some rewording of this requirement
would clearly be helpful.

>> IN2. Desired: usable with minimal changes to existing IETF RFCs for CMS,
>> SSH, IKE, IKEv2, Kerberos PKINIT. [RC]
>
>The cost of making a change in these systems is largely fixed. I think
>that trading off too much to make the change smaller is often a false
>economy. If the thinking here was to try and reuse ECDSA with new
>curves for reasons of easy of patching then I think that would be an
>example of such a false economy.
>

Thanks for sharing this perspective. My feeling is that a bit more work is
needed (possibly by me, but maybe others already did it) to dig into these
RFCs and see what work would be implied with different levels of change to
curves and algorithms.

Enjoy the rest of your holiday,

Cheers

Kenny 

>
>Cheers
>
>AGL
>
>-- 
>Adam Langley [e-mail] https://www.imperialviolet.org
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>http://www.irtf.org/mailman/listinfo/cfrg