Re: [Cfrg] generic curves ... RE: big-endian short-Weierstrass please

[Daniel Kahn Gillmor <[e-mail]>]

On Thu 2015-01-29 17:09:18 -0500, Dan Brown wrote:

> The current set of TLS named curves includes NIST (and some SECG?) and 
> Brainpool curves, right?  Is there some of these current curves that TLS plans 
> to disallow?

There is already a plan in TLS to deprecate the use of the smaller
curves, similar to the cutoff you describe below.

> I'd suggest that TLS and IETF protocols only keep (EC)DH groups with at least 
> 2^256 - S elements (for small S), but grandfathering in Curve25519, P256, (and 
> maybe secp256k1, if there ???).  In other words, smaller curves, 163 bits, 192 
> bits, and so on, could be removed.  Actually, this should be redundant, as 
> long protocols match symmetric key sizes ...
>
> By the sounds of it, TLS doesn't yet have a good way to negotiate curves on 
> the fly (even CA / server pre-validated curves?), yet.

As i've already said on-list today, If both peers already know about
some custom curve they want to use, they should take advantage of TLS's
"private use range" and negotiate their preferred custom curve there.
This requires no external vetting of curves or point formats or
anything; just pre-agreement between peers about what they want the
codepoints within the private-use range to mean.

I have yet to hear a reason why this isn't acceptable for anyone who
needs custom curves between pre-arranged peers, so i'll stop repeating
it.  If it doesn't work for you, please explain why.

     --dkg