[TLS] (selection criteria for crypto primitives) Re: sect571r1

[Rene Struik <[e-mail]>]

Dear colleagues:

It seems prudent to keep some diversity of the gene pool and not only 
have curves defined over prime curves. Similarly, one should perhaps 
have some diversity of gene pool criteria within the set of recommend 
curves and not only include special primes. Should some problem with a 
particular subclass show up over time, one then at least has other 
classes available.

On a general note, I do not understand what is wrong with having a 
dictionary of curves that is well-specified, but whose members are not 
all widely used. To my knowledge, having a dictionary does not force 
everyone to use every term in this (mandatory vs. optional to implement 
vs. mandatory to use, etc.).

If one follows the line of reasoning of some people on the mailing list 
earlier today, doesn't this also call into question Brainpool curves, 
or, e.g., the Misty cipher, etc.? Moreover, this certainly calls into 
question why one would have a whole set of new DLP groups (which 
certainly cannot be widely used yet, since the ink to write the 
parameters down is still wet). What about RSA-1024, etc.?

I would suggest one to have a clear criteria by which to judge 
inclusion/exclusion of cryptographic algorithms.

As a final note: if one can define curves explicitly, then removing 
these from a list does  not really remove them, except "pestering" 
people who would like to use them by forcing sending big chunks of 
descriptive text instead of short-hand references.

Best regards, Rene

On 7/15/2015 8:20 PM, Martin Rex wrote:
> Tony Arcieri wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> Dave Garrett <[e-mail]> wrote:
>>> It's the most used of the rarely used curves.
>>
>> I think all "rarely used curves" should be removed from TLS. Specifically,
>> I think it would make sense for TLS to adopt a curve portfolio like this:
>>
>> - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks
>> - NIST curves (SUPPORTED): P-256, P-384, P-521
> P-256 and P-384 seem to be pretty important to some folks
> (those with a NIST/NSA Suite B checklist).  I'm OK with P-521,
> but I would prefer to get rid of pretty much all _other_
> NIST curves with unexplained parameters, including 571
>
> Either the NIST curves with unexplained constants _are_ backdoored,
> then you get screwed no matter which one of them you use.
> Or the NIST curves are OK, then P-521 will be good enough.  IMO.
>
> -Martin
>
>
> Microsoft SChannel seems to implent the 3 NIST curves (P-256, P-384, P-521),
> and MSIE 10 exhibits a curious behaviour on my Win7 machine:
> when only TLSv1.0 is enabled, then MSIE 10 sends a ClientHello
> with P-521 as the first curve in the named_curve extension.
> when TLSv1.2 is also enabled, then MSIE 10 sends a ClientHello
> with P-256 as the first curve in the named_curve extension.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]