Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto)

From: Benjamin Black <[email-masked]>
Date: Fri, 31 Oct 2014 10:46:43 -0700

Yes.

"Keeping in mind that this may induce negative performance impacts, but
could increase confidence in the outcome of our deliberations."

The process should allow both random and selected primes, even if CFRG
decides to only use one or the other to meet the TLS-WG request. Agreeing
on the process allows us to avoid this lengthy debate in future should
other curves be needed to meet specific requirements.

On Fri, Oct 31, 2014 at 10:34 AM, Paterson, Kenny <[email-masked]
> wrote:

> Hi
>
> We could still go down the route of generating fresh curves if there's
> consensus for it on the list.
>
> So let's do a quick poll:
>
> - Who on the list would be in favour of using a to-be-agreed procedure to
> generate new curves, instead of selecting from amongst the curves that are
> currently on the table?
>
> (Keeping in mind that this may induce negative performance impacts, but
> could increase confidence in the outcome of our deliberations.)
>
> Replies should being with a one-word answer - "yes" or "no".
> Justifications for positions can be included if you wish, but right now
> I'm more interested in the raw, 1-bit answer.
>
> Thanks,
>
> Kenny
>
>
> On 31/10/2014 14:39, "Benjamin Black" <[email-masked]> wrote:
>
> >Right, I didn't say don't pick NUMS. I said I believe the process
> >should've gone a direction it did not, which would've rejected _ALL_
> >current candidates in favor of CFRG generating new ones. That is no more
> >my saying "don't pick NUMS" than your
> > saying you want genus 2 on the table is the same as your saying "don't
> >pick Curve25519".
> >
> >On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd
> ><[email-masked]> wrote:
> >
> >On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black <[email-masked]> wrote:
> >> Watson,
> >>
> >> Where exactly did I say "don't pick NUMS"?
> >
> >On October 29
> >"I've also said repeatedly that we should be starting from
> >requirements and then consider _generating_ curves to meet them,
> >rather than limiting ourselves to the curves at hand or trying to
> >contort the requirements to match an existing favorite."
> >
> >
> >
> >That seems to suggest that we don't pick any curves, but instead
> >generate new ones.
> >
> >>
> >>
> >> b
> >>
> >> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd <[email-masked]>
> >>wrote:
> >>>
> >>> On Fri, Oct 31, 2014 at 7:10 AM, Stephen Farrell
> >>> <[email-masked]> wrote:
> >>> >
> >>> >
> >>> > On 31/10/14 14:05, Richard Barnes wrote:
> >>> >> The idea that whiz-bang new crypto is the main barrier to 100% HTTPS
> >>> >> adoption seems rather naïve.  It helps,
> >>> >
> >>> > I agree. Of course, having CFRG decide on precisely
> >>> > which whiz-bang new crypto would be a good next step:-)
> >>>
> >>> But our choices are not the fastest ones! We've decided to have genus
> >>> 1 prime, no CM, which is a very conservative choice, but not
> >>> necessarily the fastest.
> >>>
> >>> Anyway, since Benjamin Black has said he doesn't actually think we
> >>> should pick NUMS, but do our own picking, I think the answer is
> >>> clear...
> >>> >
> >>> > S.
> >>> >
> >>> > _______________________________________________
> >>> > Cfrg mailing list
> >>> > [email-masked]
> >>> > http://www.irtf.org/mailman/listinfo/cfrg
> >>>
> >>>
> >>>
> >>> --
> >>> "Those who would give up Essential Liberty to purchase a little
> >>> Temporary Safety deserve neither  Liberty nor Safety."
> >>> -- Benjamin Franklin
> >>>
> >>> _______________________________________________
> >>> Cfrg mailing list
> >>> [email-masked]
> >>> http://www.irtf.org/mailman/listinfo/cfrg
> >>
> >>
> >
> >
> >
> >--
> >"Those who would give up Essential Liberty to purchase a little
> >Temporary Safety deserve neither  Liberty nor Safety."
> >-- Benjamin Franklin
> >
> >
> >
> >
> >
> >
> >
>
>

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Fri, 31 Oct 2014 17:53:23 +0000

Yes.

I concur with Benjamin’s reasoning.
-- 
Regards,
Uri Blumenthal                               Voice: (781) 981-1638

From:  Benjamin Black <[email-masked]>
> The process should allow both random and selected primes, even if CFRG decides
> to only use one or the other to meet the TLS-WG request. Agreeing on the
> process allows us to avoid this lengthy debate in future should other curves
> be needed to meet specific requirements.
> 
> On Fri, Oct 31, 2014 at 10:34 AM, Paterson, Kenny <[email-masked]>
> wrote:
>> Hi
>>

---

From: Paul Lambert <[email-masked]>
Date: Fri, 31 Oct 2014 10:57:20 -0700

Yes.

Good options for optimized and random primes is valuable.
We should not be so focused on ‘the’ ultimate curve, but also ensure that there are well documented options for a variety of market applications.

Paul

From: Benjamin Black <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 31, 2014 at 10:46 AM
To: "Paterson, Kenny" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto)

Yes.

The process should allow both random and selected primes, even if CFRG decides to only use one or the other to meet the TLS-WG request. Agreeing on the process allows us to avoid this lengthy debate in future should other curves be needed to meet specific requirements.

On Fri, Oct 31, 2014 at 10:34 AM, Paterson, Kenny <[email-masked]<mailto:[email-masked]>> wrote:
Hi

Thanks,

Kenny

On 31/10/2014 14:39, "Benjamin Black" <[email-masked]<mailto:[email-masked]>> wrote:

><[email-masked]<mailto:[email-masked]>> wrote:
>
>On Fri, Oct 31, 2014 at 7:31 AM, Benjamin Black <[email-masked]<mailto:[email-masked]>> wrote:
>> Watson,
>>
>> On Fri, Oct 31, 2014 at 7:14 AM, Watson Ladd <[email-masked]<mailto:[email-masked]>>
>>wrote:
>>>
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>> >
>>> >
>>> > [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>

---

From: "Paterson, Kenny" <[email-masked]>
Date: Fri, 31 Oct 2014 17:34:13 +0000

Hi

Thanks,

Kenny

---

From: Michael Hamburg <[email-masked]>
Date: Fri, 31 Oct 2014 11:15:34 -0700

No.

I’m OK with this in principle, but if there aren’t new curves by Christmas, there will be mutiny.  Seriously, industry is just going to give up on CFRG and roll out new curves of their choice.

And anyway, will we actually get different curves this way?  We’ve got curves from pretty much the convex hull of the proposed strategy space, except for VPR curves and a performance-at-all-costs WF128 curve.

— Mike

> On Oct 31, 2014, at 10:34 AM, Paterson, Kenny <[email-masked]> wrote:
> 
> Hi
>

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 31 Oct 2014 18:18:40 +0000

>- Who on the list would be in favour of using a to-be-agreed procedure to generate new curves, instead of selecting from amongst the curves that are currently on the table?

No.

• If we generated new curves with rigid processes and constraints, they'd likely match one of the contenders. (That's the point. See what happened with E-521.)

• I think the already-existing Brainpool curves match random curve criteria fine.

• Concerns about delay.

There's nothing stopping us (or Brainpool) doing new random curves later, but I don't think this satisfies the TLS WG request on the table now.

- --
/akr

---

From: Watson Ladd <[email-masked]>
Date: Fri, 31 Oct 2014 11:31:20 -0700

I feel we are being asked to buy a pig in a poke. Given that the three yes
votes have wanted random primes, or "a range of market" applications, and
have left the door open to later having to pick for TLS, I'm not sure the
people voting yes actually agree with the proposal, which as I read it
would involve constructing a procedure that would output the curves, that
would then go to TLS, without regard to other uses of said procedure or
picking out some curves from the output.

I'm going to vote "no". I don't see how this speeds up the process, or is
different from the results of picking NUMS, or E-521+other junk.

I'll mail a quarter to you if I have to for use in making the decision: but
let's decide already.

On Oct 31, 2014 10:53 AM, "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
wrote:
> Uri Blumenthal                               Voice:(781) 981-1638
>
>>
>> On Fri, Oct 31, 2014 at 10:34 AM, Paterson, Kenny <

---

From: "Torsten Schütze" <[email-masked]>
Date: Fri, 31 Oct 2014 19:50:14 +0100

Yes.

Brainpool always stated that it could/would generate new VPR curves from time to time. 

In my personal opinion (not checked with BP members) one could at that occasion change some of the "critics", e.g., usage of SHA-1, twist security (not unanimously agreed within BP). Quality goes before speed. The world will not break down if TLS WG or other IETF WGs have to wait a little bit longer, but have TRUST in the selection procedure / the selected curves. 

Torsten

> Gesendet: Freitag, 31. Oktober 2014 um 18:34 Uhr
> Von: "Paterson, Kenny" <[email-masked]>
> An: "Benjamin Black" <[email-masked]>, "Watson Ladd" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Betreff: Re: [Cfrg] new curves or old (was: Actual security levels for IETF crypto)
>
> Hi
>

---

From: Yoav Nir <[email-masked]>
Date: Fri, 31 Oct 2014 20:56:46 +0200

> On Oct 31, 2014, at 8:18 PM, Alyssa Rowan <[email-masked]> wrote:
> 

+1. No.

I totally trust the Brainpool people to have picked the curves correctly and randomly. No reason to do it again.

The NUMS people have (I’m sure) done a fine job of doing the rigid process, and I don’t think we’ll come up with better rigid criteria unless we tailor the criteria to get a particular curve.

It’s time to do what IETF and IRTF usually do poorly - decide among several options, each with advantages and disadvantages.

Yoav

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 31 Oct 2014 19:02:46 +0000

No.

We have plenty of proposals for curves that are quite reasonable.  We don't need to go inventing Yet More curves...

> -----Original Message-----
> From: Cfrg [mailto:[email-masked]] On Behalf Of Paterson, Kenny
> Sent: Friday, October 31, 2014 1:34 PM
> To: Benjamin Black; Watson Ladd
> Cc: [email-masked]
> Justifications for positions can be included if you wish, but right now I'm more
> interested in the raw, 1-bit answer.
> 
> Thanks,
> 
> Kenny
> 
> 
> >current candidates in favor of CFRG generating new ones. That is no
> >more my saying "don't pick NUMS" than your  saying you want genus 2 on
> >the table is the same as your saying "don't pick Curve25519".
> >
> >On Fri, Oct 31, 2014 at 7:35 AM, Watson Ladd <[email-masked]>
> >wrote:
> >
> >"I've also said repeatedly that we should be starting from requirements
> >and then consider _generating_ curves to meet them, rather than
> >limiting ourselves to the curves at hand or trying to contort the
> >requirements to match an existing favorite."
> >
> >
> >
> >>> >> The idea that whiz-bang new crypto is the main barrier to 100%
> >>> >> HTTPS adoption seems rather naïve.  It helps,
> >>> >
> >>> > I agree. Of course, having CFRG decide on precisely which
> >>> > whiz-bang new crypto would be a good next step:-)
> >>>

---

From: Dan Brown <[email-masked]>
Date: Fri, 31 Oct 2014 19:51:41 +0000

> generate new curves, instead of selecting from amongst the curves that are
Yes, I'm in favor.

I'd like a special prime with random j-invariant (as usual, subject to some
reasonable cofactor and other to-be-agreed constraints).  This would only
slightly impact efficiency (by 1% IIRC), but would help resist *sparse*
secret attacks (which I think there's <<1% chance of existing).  Also,
existing implementations of the special prime field can be quite easily
adapted, just by switching over the coefficients.  

Although weak fields are a concern in binary-field elliptic curves, it seems
unlikely to carry over to prime-field curves.  If it does carry over, then
the Brainpool curves should prevent that problem, and they are ready to go.
That's why I think special primes would be okay.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 31 Oct 2014 21:46:44 +0000

On 31/10/14 18:56, Yoav Nir wrote:
> It’s time to do what IETF and IRTF usually do poorly - decide among
> several options, each with advantages and disadvantages.

+1, and count me as a no-hats no, on the basis that yes == more
delay and more not particularly fruitful discussion. (Though I do
find a good bit of the non-fruitful discussion educational;-)

S.

---

From: Randy Bush <[email-masked]>
Date: Sat, 01 Nov 2014 08:50:53 +0900

> several options, each with advantages and disadvantages.

bingo.  i.e. no.