Re: [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves

Hi Simon,

On Jul 16, 2014, at 5:39 PM, Simon Josefsson <simon@josefsson.org> wrote:

> I'm reviewing the selection criteria.  Some of the requirements are
> rather fine-grained and poorly justified, and appear to limit the search
> space.  If taken literally, I believe they exclude some good candidates
> and steer the selection into a rather small field of available options.
> 
> I'm fine with R1-R3.
> 
> "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> writes:
> 
>> Intellectual Property
>> 
>>   R4.  Required: available worldwide under reasonable and well
>>   understood licensing terms [1]
>> 
>>   R5.  Desired: available worldwide under royalty-free licensing
>>   terms [1]
> 
> I believe non-royalty-free licensing terms is a nonstarter.  I suggest
> collapsing this into:
> 
> R4'. Required: available for worldwide implementation (by both
>     proprietary and free open source software) and use under well
>     understood and royalty-free licensing terms
> 
>> Interoperability
>> 
>>   R6.  Desired: can be used with current software implementations
>>   (using different curve parameters) of TLS, PKIX, SSH, and IKE [4]
>> 
>>   R7.  Desired: can be used within current ECC standards of TLS,
>>   PKIX, SSH, and IKE [4]
> 
> I do not see why these are desirable properties, so I disagree they
> should be a selection criteria.  

These properties are valuable because 1) they lower the cost of adopting the new curves, thus making adoption faster or more likely, 2) they simplify (at least some) implementations by allowing them to avoid implementing an additional ECC scheme and a protocol interface for it.    Many people do see these requirements as important; this was Russ Housley’s point at the mic at the last TLS WG, and I agree with him.   Simplicity of design and implementation is a really important point that we need to not lose sight of.   Less code, fewer bugs.

I concede that these properties do limit the design space, which is why they should be “desired” rather than required.    In my opinion, anyway.

What is most important is that people understand which criteria are met by a given ECC scheme, so that they understand what they are actually getting. 

> These properties restricts the search
> space.  I would prefer if the CFRG are at liberty to recommend the best
> alternative even if it is clearly not re-usable in existing software or
> standards.  I would go even further saying that one of the reasons for
> doing this excercise is that the existing software and standards are not
> sufficient.
> 
> On the topic of interoperability, I would propose to add the following,
> to me, more important property:
> 
> Rx. Desired: either a clear algorithm description exists (with clarity
> on byte-ordering etc) or multiple interoperable implementations are
> available.

I agree that this is a good criteria, though I will note that multiple interoperable implementations are no substitute for a clear algorithm description.  

> 
> If some alternative does not appear to be sufficiently specified or
> widely implemented, the CFRG could take on driving a document to clarify
> the solution.
> 
>> Security
>> 
>>   R8.  Required: amenable to constant-time implementations, to avoid
>>   side channel attacks [2]
>> 
>>   R9.  Required: resist twist attacks [2]
>> 
>>   R10.  Required: curve parameters should have good provenance;
>>   random curves should be provably pseudorandom [5]
>> 
>>   R11.  Desired for key exchange: resist invalid curve attacks [2];
>>   note that complete addition laws help and are thus desirable [2].
>>   (Note that the use of ephemeral keys also resist such attacks.)
> 
> Instead of R8-R11, I suggest to summarize this more generally

I disagree.   These requirements should be kept separate because they allow us to differentiate between different proposed ECC schemes.

> as:
> 
> R8'. Required: the solution should be secure against reasonable and
> well-understood threats, including (but not limited to and necessarily
> not all of) brute-force, side-channel, invalid-curve, twist attacks, or
> maliciously chosen curve parameters.
> 
> Designing against security threats is a balance, and I would say that
> there are no perfect solutions.  Every solution will have some area
> where they perform less well compared to some other solution.  I believe
> the overall choice(s) should reflect well-balanced alternatives with
> strong advantages and some understood disadvantages.
> 
>>   R12.  Required for PAKE: indistinguishability of curve points from
>>   random strings [2]
> 
> I do not see why this is a desirable property for TLS, or other IETF
> areas, so I disagree it should be a requirement.

Yeah, I take your point.   In the context of TLS, perhaps this should be worded as “desired: indistinguishability of curve points from random strings, so that the curves could also be used in PAKE protocols”.    This would allow for implementation and specification re-use for PAKE, which could make a PAKE easier to adopt.  

David

> 
> /Simon
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg