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

[Aaron Zauner <[e-mail]>]

Dan Brown wrote:
> New thread name ... should have done so earlier.
> 
> When TLS asked CFRG for new curves, I didn't interpret that to mean that 
> generic curves would be banned. Banishing generic curves adds slightly more 
> weight to the TLS request, because users cannot easily opt out of the chosen 
> few elite curves.
> 
> Upon further reflection, I think CFRG already spent enough time to find an 
> answer that weightier question, and in particular, I'll keep my vote the same.
> 
> 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?
> 
> 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.
> 
> My proposal for generic curves presumes that the generic elliptic curve domain 
> parameters are authenticated, i.e. Alice and Bob are not duped into using a 
> curve that they don't agree upon, and validated, perhaps in advance. 
> Actually, the old standards, SEC1, X9, etc., pretty much make this a 
> requirement before doing ECC.  Having tried to maintain a couple of these old 
> standards, I sometimes take such things for granted.  Anyway, if TLS is unable 
> to only achieve this authentication by using vetted and named curves, then my 
> generic curve proposal would not apply to TLS.
> 
> Best regards,
> 
> Dan
> 
> PS While we're tracking thread discussions, I remember suggesting to one the 
> lists last year that TLS add for support generic curves, but I was mistakenly 
> confusing TLS and PKIX: it was PKIX that had restricted named-curves only.  I 
> don't recall this much discussion in response, other a couple people 
> correcting my mistake.  If it was pointed out at that time that TLS was unable 
> to securely support generic curves, then I apologize for forgetting.
> 

...

I read this as: we have this custom patented curves that we want to push
and want to use in TLS. Can we please? Use dkg's suggested private range.

Aaron