Re: [Cfrg] big-endian short-Weierstrass please

[Dan Brown <[e-mail]>]

>From: Watson Ladd [mailto:[e-mail]]
>On Jan 29, 2015 8:50 AM, "Dan Brown" <[e-mail]> wrote:
>
>> [DB] Wouldn't users of these private values have to then customize their 
>> software this?  Well, I guess TLS would work for that.  So, it seems that 
>> the advantage of specified curves, is that if a trustworthy WebSiteABC TLS 
>>  >>server, elects to use MagicCurveX, then anonymous TLS clients could 
>> connect to WebSiteABC, relying on the current trust of the WebSiteABC, and 
>> their own software.

>This is not how TLS negotiation works: the client offers and the server 
>picks. Due to vulnerabilities in all versions of TLS (still unfixed) one 
>always has to check the offered parameters for correctness.

[DB] Ah, too bad. I guess named curves (and FFDHE groups) is, among other 
things, one way to fix this problem with TLS.  (I vaguely recalled a proposal 
for the server being able to suggest alternatives outside the clients' list, I 
guess I misremembered.)

Anyway, to paraphrase others, a downside of TLS limiting curves to a small 
set, is this limitation can be spun sourly, albeit a tad unfairly, as 
pressuring users to use particular curves. That said, leaving in arbitrary 
curves, can also be spun badly, too, catch 22.

>That's on top of the fact that people don't want to use Curve25519 because 
>it's Curve25519. They want to use it because the design choices support high 
>speed secure implementations.

[DB] Right, but other users might want to use some other curves with high 
speed secure implementations, e.g., maybe a larger curve, but they disagree 
with CFRG advice about rigidity, etc.

>It's possible to get the existing extension to do this, but only if we have a 
>magic list of what to offer, and do all sorts of contortions in our 
>calculations. Much easier to negotiate an extension as the TLS WG extensively 
> >discussed.