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

From: Dan Brown <[email-masked]>
Date: Thu, 29 Jan 2015 22:09:18 +0000

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.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 29 Jan 2015 18:30:08 -0500

> Brainpool curves, right?  Is there some of these current curves that TLS plans 

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

> 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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 29 Jan 2015 15:40:48 -0800

If you want to debate the wisdom of what the TLS WG is doing, it is best done in the TLS WG, not here. Of course, you should read the threads on the list where the WG had strong consensus to remove generic curves. If you want to change their minds on that topic, doing so on the CFRG mailing list is probably not effective, and gets in the way of us making progress on what the TLS WG asked us to do.

--Paul Hoffman

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 30 Jan 2015 01:07:40 -0800 (PST)

On Thu, January 29, 2015 3:40 pm, Paul Hoffman wrote:
> If you want to debate the wisdom of what the TLS WG is doing, it is best
> done in the TLS WG, not here. Of course, you should read the threads on
> the list where the WG had strong consensus to remove generic curves. If
> you want to change their minds on that topic, doing so on the CFRG mailing
> list is probably not effective, and gets in the way of us making progress
> on what the TLS WG asked us to do.

  You are neither the chairman of this group nor the parliamentarian;
stop telling people what to do.

  Dan.

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 31 Jan 2015 15:50:03 +0100

> 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