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 <davemgarr...@gmail.com> 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--
email: rstruik....@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
