Subject: [Cfrg] Elliptic Curves - poll on security levels (ends on February 17th)

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Feb 2015 10:52:19 +0000

CFRG chairs are starting a poll, containing 2 initial questions:

Q1: Should CFRG recommend a curve at the 192-bit security level?

Q2: Should CFRG recommend a curve at the 256-bit security level?

Answering Yes/No to each of these would suffice.

Once this first set of issues is resolved, we will move to choices of prime
at the selected security level(s), if any. After that we will be
discussing implementation specifics and coordinate systems for
Diffie-Hellman. We will then make decisions on signature schemes.
Please don't discuss any of these future topics at this time.

---

From: "Torsten Schütze" <[email-masked]>
Date: Tue, 10 Feb 2015 13:33:26 +0100

> Q1: Should CFRG recommend a curve at the 192-bit security level?

Yes, absolutely. 

> Q2: Should CFRG recommend a curve at the 256-bit security level?

Yes, i.e., 192-bit security is much more important. But for the real paranoid and/or for security systems with a wide timing horizon we should recommend a 256-bit security level curve as well.

Torsten

---

From: "Nguyen Dr., Kim" <[email-masked]>
Date: Tue, 10 Feb 2015 15:22:46 +0100

Q1: Yes
Q2: Yes

-----Ursprüngliche Nachricht-----
Von: Cfrg [mailto:[email-masked]] Im Auftrag von Alexey Melnikov
Gesendet: Dienstag, 10. Februar 2015 11:52
An: [email-masked]
Betreff: [Cfrg] Elliptic Curves - poll on security levels (ends on February 17th)

Once this first set of issues is resolved, we will move to choices of prime at the selected security level(s), if any. After that we will be discussing implementation specifics and coordinate systems for Diffie-Hellman. We will then make decisions on signature schemes.
Please don't discuss any of these future topics at this time.

_______________________________________________
Cfrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/cfrg

---

From: Watson Ladd <[email-masked]>
Date: Tue, 10 Feb 2015 07:00:10 -0800

> Please don't discuss any of these future topics at this time.

Does this mean that 2^448-2^224-1 is not being considered?

Does this mean that 2^414-17 is not being considered?

How much distance from 2^192 is allowed? How much from 2^256? Would
2^521-1 be an acceptable prime at the 256 bit level?

I don't know what the above questions mean, so I can't say yes or no.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 10 Feb 2015 16:06:15 +0100

> Q1: Should CFRG recommend a curve at the 192-bit security level?

No (see below).

> Q2: Should CFRG recommend a curve at the 256-bit security level?

Yes.

The reason for the first no being: more is not always better. Just look
at the list of possible tunables w.r.t. TLS ciphersuites. 128bit, 256bit
and one or two "high-security" curves would be preferable to as many
options as possible. But that's strictly my personal opinion.

Aaron

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Feb 2015 10:14:29 -0500

> Q2: Should CFRG recommend a curve at the 256-bit security level?

Q1: No
Q2: Yes

The reason I don't see a need for 192 bit is that I have never seen
significant use of 192 bit AES.

The more complexity we put into the systems, the more opportunity there is
for attack. This is not a choice like RSA or DH where the exact same code
can be used for different bit levels.

The two places we will be using the code is for ephemeral key agreement and
for initial agreement of a master key. Assuming that we fix the TLS key
derivation alg so that a 128 bit ephemeral does not weaken a 256 bit
negotiation, I predict ephemeral will be exclusively Curve 25519 and PKI
will be exclusively Curve~512.

Phill

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Tue, 10 Feb 2015 16:19:58 +0100

> Q1: Should CFRG recommend a curve at the 192-bit security level?
Optionally, but the focus should be on 256bit, or higher

Yes.

None of this should mean however, that efforts for the much higher
security levels >=512 respectively 521 bits would be abandoned.

Cheers,
Chris.

---

From: Dan Brown <[email-masked]>
Date: Tue, 10 Feb 2015 15:31:53 +0000

> From: Phillip Hallam-Baker
> Sent: Tuesday, February 10, 2015 10:14 AM

> for initial agreement of a
> master key. Assuming that we fix the TLS key derivation alg so that a 128 
> bit ephemeral does not weaken a
> 256 bit negotiation, I predict ephemeral will be exclusively Curve 25519 and 
> PKI will be exclusively
> Curve~512.

Counterarguments for the opposite, i.e. 128-bit security for PKI and 256-bit 
security for key agreement. First, confidentiality often relies key agreement 
and confidentiality potentially needs long-term (future) security, so 
margin-of-error is arguably more important. PKI, by definition, is only as 
secure as the security of CAs and the security of the communication used to 
obtain their CA self-signed certificates: larger key sizes does not fix these 
two bottlenecks.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Feb 2015 11:28:24 -0500

On Tue, Feb 10, 2015 at 10:19 AM, Christoph Anton Mitterer <
[email-masked]> wrote:

> It appears the poll is causing confusion. Curve 25519 is a 255 bit prime
that is being positioned to deliver a 128 bit security level.

In practice it is rather more, but the 'naive' approach to ECC strength is
to halve the bit size.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Feb 2015 08:37:09 -0800

> Q1: Should CFRG recommend a curve at the 192-bit security level?

No.

> Q2: Should CFRG recommend a curve at the 256-bit security level?

Yes, but only if it does not delay the publication of the CFRG recommendation of the 128-bit security level curve by more than 30 days.

--Paul Hoffman

---

From: Adam Langley <[email-masked]>
Date: Tue, 10 Feb 2015 08:39:19 -0800

No.

No.

Nor do I believe that 192 or 256 are useful stops on the security
scale for ECC primitives.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Feb 2015 18:57:45 +0200

> On Feb 10, 2015, at 5:00 PM, Watson Ladd <[email-masked]> wrote:
> 

+1

I don’t see any point in aiming for a particular security level. Sure, there’s the “weakest link” argument although even that’s more involved as evidenced by the separate sub-thread about PKI vs key agreement vs confidentiality vs MAC, but we can set a security level at, say, 192 bits and require a suite of algorithms at at least that level, as NIST did when specifying the higher Suite-B with AES-256 even though they were aiming for 192-bit.

To the point, there may be a reason for recommending 2^448-2^224-1 or 2^414-17, and there may be a reason for recommending 2^521-1. I don’t see a reason for aiming at 2^192, finding something close and declaring that as “good enough”. I’m not at all convinced that there is a likely scenario where it the foreseeable future Curve25519 will be easily enough broken that  people will lose confidence, but the mysterious 192-bit one will still be considered secure.

Yoav

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 10 Feb 2015 17:14:33 +0000

I agree with Phil and his reasoning: NO-192; YES-256

--
Principal Security Engineer, Akamai Technologies
IM: [email-masked]<mailto:[email-masked]> Twitter: RichSalz

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 10 Feb 2015 09:29:17 -0800

On Tue, Feb 10, 2015 at 8:57 AM, Yoav Nir <[email-masked]> wrote:

> To the point, there may be a reason for recommending 2^448-2^224-1 or
> 2^414-17, and there may be a reason for recommending 2^521-1. I don’t see a
> reason for aiming at 2^192, finding something close and declaring that as
> “good enough”. I’m not at all convinced that there is a likely scenario
> where it the foreseeable future Curve25519 will be easily enough broken
> that  people will lose confidence, but the mysterious 192-bit one will
> still be considered secure.

I agree with this entire sentiment. It's difficult to envision a scenario
where a 192-bit curve will be broken, but a 256-bit one will not.

For high security curves, I think we should pick primes that offer the best
performance/security tradeoffs, not necessarily ones that are closest to
192-bits or 256-bits.

2^448-2^224-1 is quite promising in this regard, but provides a security
level that lies between 192-bit and 256-bit

-- 
Tony Arcieri

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Feb 2015 17:39:02 +0000

> Q1: Should CFRG recommend a curve at the 192-bit security level?

Not interesting.

> Q2: Should CFRG recommend a curve at the 256-bit security level?

Yes, approximately.

I would also be fine if there were compelling performance reasons
for one strength that is in between, e.g. 2^414-17 or similar, but
I would like only one strength level in addition to ~128-bit.

I'm not that convinced that anything more than the 128-bit level
is needed, but I believe it will be demanded regardless so having
just one such specified is better than a zoo of higher strength
curves.

S.

---

From: Mike Hamburg <[email-masked]>
Date: Tue, 10 Feb 2015 10:03:01 -0800

> Q2: Should CFRG recommend a curve at the 256-bit security level?

One or the other, but not both.

On 02/10/2015 08:37 AM, Paul Hoffman wrote:

> ... but only if it does not delay the publication of the CFRG recommendation of the 128-bit security level curve by more than 30 days.
>
+1

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Feb 2015 13:05:46 -0500

On Tue, Feb 10, 2015 at 12:39 PM, Stephen Farrell <[email-masked]

> just one such specified is better than a zoo of higher strength

One of the reasons I really want a curve above 128 bit / Curve 25519 is
precisely to clean up the zoo. And for that to happen there has to be a
clear advantage of the new curve over ECC384 which is what we  (and I
suspect most other CAs who do ECC) support today.

And by clear advantage I mean, can be explained over the phone in as short
as time as possible. This has to be a complete no-brainer upgrade.

It isn't just a matter of not being interested in the 192 bit curve, I want
to phase out that strength.

It is important that we have a back up algorithm that can be more or less
relied on to provide a ten year cushion in the case that Curve 25519 is
broken. But we don't need that cushion to be particularly efficient.

On Tue, Feb 10, 2015 at 12:46 PM, Daniel Kahn Gillmor <[email-masked]

> On Tue 2015-02-10 09:20:59 -0500, Stanislav V. Smyshlyaev wrote:
> > Q1: No.
> > Q2: Yes.
> >
> > For Q2: for Russia it is of primary importance that the curve is strictly
> > 512-bit, not 521-bit.
>
> Can you elaborate on why this is of primary importance?  If a 521-bit
> curve is as performant, what would cause you to reject it?

The performance advantages only exist for a 64 bit machine. Anyone building
a dedicated crypto processor would probably choose either 256 bits or 512
bits for the internal bus size. The successor to DDR4 will almost certainly
be a 512 bit I/O bus width.

If you are working at the silicon level then 521 bits is a lot harder to
manage than 512. Those extra 9 bits really do make a huge difference.

Going from 256 bits to 255 is not a big deal. But going above 512 makes
things really painful.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Feb 2015 20:20:47 +0200

> The performance advantages only exist for a 64 bit machine. Anyone building a dedicated crypto processor would probably choose either 256 bits or 512 bits for the internal bus size. The successor to DDR4 will almost certainly be a 512 bit I/O bus width.

All desktops, laptops and most newer phones are 64-bit. Than trend is not going to reverse itself. Dedicated crypto hardware is a very specialized applications Most crypto is done on general-purpose hardware (hoping not to get into the discussion of whether an Intel CPU with an AES unit is specialized or general-purpose)

I don’t think we should sacrifice the performance of the devices we all use for surfing the net for specialized applications like smartObjects or military grade hardware.

Yoav

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 10 Feb 2015 19:34:23 +0100

> Q2: Should CFRG recommend a curve at the 256-bit security level?

It's my understanding that 2^128 is currently considered to be
safe with a large enough margin.  Is there an estimate for when
we believe we need more than 2^128?  Would something around 2^160
then be enough?

Kurt

---

From: Alyssa Rowan <[email-masked]>
Date: Tue, 10 Feb 2015 18:35:13 +0000

> Q2: Should CFRG recommend a curve at the 256-bit security level?

Tricky. I think I'd rank my preferences from top to bottom:

    [≈128] ≫ [≈128,≈192] > [≈128,≈256] ⋙ [≈128,≈192,≈256]

So [No, No] ideally; followed by [Yes, No], followed by [No, Yes],
followed by "oh, god no".

Explaining my thoughts here:
 • I absolutely do not want to delay the ≈WF128 curve.
 • Is a jumbo ρ truly security-relevant in practice? Is it worth it?
   - No, I think, probably not.
   - It's certainly not the biggest threat/easiest real-world attack!
 • I'd generally prefer to specify as few curves as possible.
 • If we have to specify 2 curves, I would prefer the faster 2.
    - If we specify a larger curve:
       * CAs will use it for their roots¹
       * Everyone will have to verify the sigs on intermediates
       * That _might_ be too costly for mobile/constrained devices?
 • If we specify 3 curves, we'll only actually _use_ 2. (See AES-192.)

I do appreciate the sentiment in wanting to narrow issues down, but if
we want two curves, I am not sure we can usefully distinguish (or
agree) which would be more preferable without considering the actual
primes: as we actually have a whole spectrum of candidates from ≈192
to ≈260ish with no single clear-cut best-fit.

We had enough trouble deciding on ≈128 when we did have one
outstanding candidate! So, I'm perfectly happy using that one.

___
[1] CAs (critically important to the upstream WG asking for this work)
currently use secp384r1, a ≈WF192 curve, for their roots - largely
because NSA Suite B had that and secp256r1, and for competitive parity.

They are likely to use the strongest one we specify for new roots, but
don't seem to have any actual problems with any of the curves under
discussion.

See the on-list conversation I had with Rob from COMODO from October:
<https://www.ietf.org/mail-archive/web/cfrg/current/msg05294.html>
<https://www.ietf.org/mail-archive/web/cfrg/current/msg05328.html>
<https://www.ietf.org/mail-archive/web/cfrg/current/msg05329.html>
<https://www.ietf.org/mail-archive/web/cfrg/current/msg05354.html>

- -- 
/akr

---

From: Mike Hamburg <[email-masked]>
Date: Tue, 10 Feb 2015 10:46:15 -0800

On 02/10/2015 10:05 AM, Phillip Hallam-Baker wrote:
>
>
> On Tue, Feb 10, 2015 at 12:39 PM, Stephen Farrell 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
> One of the reasons I really want a curve above 128 bit / Curve 25519 
> is precisely to clean up the zoo. And for that to happen there has to 
> be a clear advantage of the new curve over ECC384 which is what we 
>  (and I suspect most other CAs who do ECC) support today.
>
> And by clear advantage I mean, can be explained over the phone in as 
> short as time as possible. This has to be a complete no-brainer upgrade.
For the upgrade to be a no-brainer, the performance will need to be good.
> It isn't just a matter of not being interested in the 192 bit curve, I 
> want to phase out that strength.
>
> It is important that we have a back up algorithm that can be more or 
> less relied on to provide a ten year cushion in the case that Curve 
> 25519 is broken. But we don't need that cushion to be particularly 
> efficient.
Ah, good point!  And at the standard rate of 25 bits/year, 384 bits 
would only provide a 5-year cushion.
> On Tue, Feb 10, 2015 at 12:46 PM, Daniel Kahn Gillmor 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> The performance advantages only exist for a 64 bit machine.
So far as I know, nobody's done a high-speed implementation on 32-bit 
for proposed primes other than 2^255-19, 2^414-17, and 2^448-2^224-1; 
and I'm not aware of FPGA benchmarks for any pair of the proposed primes 
which can be compared.  But I don't see why 2^521-1 wouldn't perform 
well on many other bit sizes.  It doesn't stop being a Mersenne prime 
when you change bit sizes.
> Anyone building a dedicated crypto processor would probably choose 
> either 256 bits or 512 bits for the internal bus size.
It depends on the crypto processor.  The ones I've seen have either an 
N-long register for some arbitrary N (and a zwei-drei-N serial 
multiplier), or a 32- or 64-bit internal bus because they accelerate 
NIST curves with 32-bit-aligned coefficients.

Also, 256 bits is a monstrous fat bus.  It's absolutely enormous for a 
crypto bignum processor, since ECC is ALU-bound and not memory-bound.  
Maybe you're thinking of an accumulator register?
> The successor to DDR4 will almost certainly be a 512 bit I/O bus width.
Cache.  Nobody's going to hit DRAM in their ECC inner loop.
> If you are working at the silicon level then 521 bits is a lot harder 
> to manage than 512. Those extra 9 bits really do make a huge difference.
This is the exact opposite of the truth.  Hardware has the flexibility 
to use 34-bit multipliers, 88-bit internal buses and 119-bit registers 
if it wants.

Maybe in GPUs or in AVX512F vector registers you'd have a point, but 
you'll need to reduce the radix in both of those cases.  And if that 8x 
52-bit multiplier ever makes it into Intel hardware, the performance 
tier will be near 400 bits instead of 512.
> Going from 256 bits to 255 is not a big deal. But going above 512 
> makes things really painful.
[citation needed].  I know that the Germans have smart cards with 
1024-bit registers and this messes up their blinding, but otherwise I 
don't know of any platform where 521 bits has a performance disadvantage 
vs 512.  If you do, please provide a citation with actual performance 
numbers, rather than BS about a "512-bit bus".

-- Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Feb 2015 13:54:59 -0500

> For the upgrade to be a no-brainer, the performance will need to be good.

It is going to be a lot better than RSA2048 but with the public/private
advantage reversed.

Since we are usually worried about performance on servers rather than
clients, this will probably remove the need for special hardware.

> less relied on to provide a ten year cushion in the case that Curve 25519
> is broken. But we don't need that cushion to be particularly efficient.
>
> Ah, good point!  And at the standard rate of 25 bits/year, 384 bits would
> only provide a 5-year cushion.
>

The only way we are going to need an algorithm with more bits is if someone
goes and does something very very clever. I am not at all worried about the
prospect of CPU performance eroding the key size. What would be a concern
is a quantum computer or something like index calculus for elliptic curves.

Whatever happens at the memory bus will propagate through the rest.

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 10 Feb 2015 11:52:14 -0800

On Tue, Feb 10, 2015 at 9:29 AM, Tony Arcieri <[email-masked]> wrote:

> For high security curves, I think we should pick primes that offer the
> best performance/security tradeoffs, not necessarily ones that are closest
> to 192-bits or 256-bits.
>

To put my response in Alexey's requested form:

> Q1: Should CFRG recommend a curve at the 192-bit security level?

No

No

-- 
Tony Arcieri

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 10 Feb 2015 12:23:35 -0800

No

No

IMO CFRG should generate a curve with WF ~ 2^128 ASAP and should
subsequently generate *one* good paranoid curve.  If that curve ends
up having security level at or near 192 or 256 bits, then that's fine.

--Andy

---

From: James Cloos <[email-masked]>
Date: Tue, 10 Feb 2015 15:42:37 -0500

>>>>> "AM" == Alexey Melnikov <[email-masked]> writes:

AM> CFRG chairs are starting a poll, containing 2 initial questions:
AM> Q1: Should CFRG recommend a curve at the 192-bit security level?

No.

AM> Q2: Should CFRG recommend a curve at the 256-bit security level?

No.

Something in between, with better than 200 security and good performance,
would be better than targeting 192 or 256.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Feb 2015 23:05:01 +0200

> On Feb 10, 2015, at 10:23 PM, Andy Lutomirski <[email-masked]> wrote:
> 

A paranoid curve would be nice, but I think that after ~2^128 is done, CFRG should start looking into specifying a genus-2 curve, like maybe the “kummer” in supercop.

The IETF groups are not clamoring for hyper-elliptic right now, which means that CFRG has enough time to do this slowly^H^H^H^H^H^H thoroughly, with no artificial deadlines.

Yoav

---

From: Damien Miller <[email-masked]>
Date: Wed, 11 Feb 2015 08:24:50 +1100 (AEDT)

> Q1: Should CFRG recommend a curve at the 192-bit security level?

Definitely no

> Q2: Should CFRG recommend a curve at the 256-bit security level?

Maybe and approximately. I.e. if doing it at all, then it doesn't
have to be exactly WF(2^256), some +/- should be tolerated for
performance, simplicitly or security.

-d

---

From: James Cloos <[email-masked]>
Date: Tue, 10 Feb 2015 14:21:15 -0500

No.

No.

-JimC

---

From: Mike Jones <[email-masked]>
Date: Tue, 10 Feb 2015 22:29:41 +0000

Yes

Yes

---

From: Benjamin Beurdouche <[email-masked]>
Date: Tue, 10 Feb 2015 23:38:12 +0100

> On 10 Feb 2015, at 11:52, Alexey Melnikov <[email-masked]> wrote:
> 

No

Yes

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 10 Feb 2015 17:00:31 -0800 (PST)

No.

  Yes.

  regards,

  Dan.

---

From: "Olafur Gudmundsson" <[email-masked]>
Date: Tue, 10 Feb 2015 21:46:01 -0500 (EST)

I agree with Kurt, we MUST get 2^128 recommendation out the door ASAP. 
talking about other levels at this point is a distraction. 
So my answer to both questions is 
NO at this time!
 
  Olafur
 
-----Original Message-----
From: "Kurt Roeckx" <[email-masked]>
Sent: Tuesday, 10 February, 2015 13:34
To: "Alexey Melnikov" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Cfrg] Elliptic Curves - poll on security levels (ends on February 17th)

Kurt

---

From: Bindhunadhava <[email-masked]>
Date: Wed, 11 Feb 2015 09:12:46 +0530

I agree with Olafur we must go stepwise 2^128 recommendation at the 
earliest. My answer is NO to both the questions.

Bindhumadhava
> we believe we need more than 2^128? Would something around 2^160

-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------------------------------------------------------------------------

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 11 Feb 2015 06:10:04 +0100

> So my answer to both questions is 

I also concur with this sentiment. If this RG spends too much time (and
discussion) on a "~256bit security" curve we should postpone the whole
discussion to some point in the future. I'd like to have something at
200-256bits but that's not as pressing an issue as is getting a curve
with ~128bits security out of the door and recommended to IETF WGs ASAP.

Aaron

---

From: "Manger, James" <[email-masked]>
Date: Wed, 11 Feb 2015 18:06:49 +1100

> Q1: Should CFRG recommend a curve at the 192-bit security level?

No, not yet

> Q2: Should CFRG recommend a curve at the 256-bit security level?

No, not yet

--
James Manger

---

From: Russ Housley <[email-masked]>
Date: Wed, 11 Feb 2015 05:17:56 -0500

No.

Yes.

The mandatory-to-implement curve should have a security level of 256 bits.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 11 Feb 2015 05:47:21 -0500

I agree with this prioritization.  I thought the question that the CFRG Co-chair was asking was about the value working on other curves _after_ the recommendation for a 128-bit security curve is done.

Russ

---

From: Brian Smith <[email-masked]>
Date: Wed, 11 Feb 2015 03:23:20 -0800

No.

No.

CFRG should finish the work on standardizing X25519. After that is
done, a well-reasoned contingency plan for a breakthrough in defeating
Curve25519 and P-256 should be created. I doubt that such a
contingency plan will be merely the recommendation of a larger curve.

Cheers,
Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Feb 2015 08:59:59 -0500

Knowing if we are going to do p=~512 or not makes a big difference to what
I would think we should be doing on p=~256.

If we are not doing p=~512 then this is adding one more point to the zoo,
no biggie. If we are doing p=~512 and NOT p=~384 then we are sending a
signal that we are shutting the zoo down and starting over.

To give an opinion on the plan, I want to know what the backup plan is
likely to look like. That does not mean agreeing every detail of the backup
plan.

On Wed, Feb 11, 2015 at 5:47 AM, Russ Housley <[email-masked]> wrote:

> I agree with this prioritization.  I thought the question that the CFRG
> Co-chair was asking was about the value working on other curves _after_ the
> recommendation for a 128-bit security curve is done.
>
> Russ
>
>

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 11 Feb 2015 14:16:42 +0000

Russ,

Just for clarity: no, the poll was asking about agreeing on other curves
at those security levels *now*, rather than after the recommendation for a
128-bit security curve is done.

Sorry for any confusion.

Cheers

Kenny 

On 11/02/2015 10:47, "Russ Housley" <[email-masked]> wrote:

>Co-chair was asking was about the value working on other curves _after_
>the recommendation for a 128-bit security curve is done.
>
>
>Russ
>
>
>

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 11 Feb 2015 14:23:47 +0000

Phillip,

On 11/02/2015 13:59, "Phillip Hallam-Baker" <[email-masked]> wrote:

>Knowing if we are going to do p=~512 or not makes a big difference to
>what I would think we should be doing on p=~256.

We're settled on Curve25519 and close relatives at the p=~256 (128-bit
security level).

The question about 192-bit and 256-bit security was intended to be
regarded as being independent of that choice. From your message, it seems
you don't think it is. Can you expand?

>signal that we are shutting the zoo down and starting over.

I don't really understand what you are saying here, as none of it is about
the 128-bit security level which is where your message started from.

Sorry, but I am confused.

>likely to look like. That does not mean agreeing every detail of the
>backup plan.

If there's no consensus on doing curves at 192-bit and 256-bit security
level, then the plan would be to abandon work on such curves until after
we've delivered recommendations to the TLS WG. The chairs' current
thinking would be to then come back to this later on. (Of course, at that
point, people might decide that IETF is not the place to put their
efforts, and that NIST's activity is the place to be. So be it.)

Cheers,

Kenny

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 Feb 2015 16:37:24 +0200

> efforts, and that NIST's activity is the place to be. So be it.)

In that case, my vote (and I realize this is a write-in candidate) is to:
 1. Not delay the answer to TLS about Curve25519
 2. Immediately start a (hopefully) short-term process to make a similar recommendation about Goldilocks or other, similar candidates.
 3. Start a long-term process for a next-generation algorithm, perhaps a genus-2 curve, with the property that it is not likely to fail together with Curve25519.

And since write-ins are not really allowed, I’ll just go with my #1 and vote “No” to both.

Yoav

---

From: Watson Ladd <[email-masked]>
Date: Wed, 11 Feb 2015 07:48:53 -0800

Yes

No

Existing practice does not use P521 but P384.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Feb 2015 13:23:04 -0500

> you don't think it is. Can you expand?

As I see it the problem with ECC is that people pushed it long before the
market was ready for it. A lot of FUD was thrown about and a lot of
confusion resulted. We ended up with 25+ curves.

The only reason to add another curve in my view is to enable the industry
to move from the RSA/discrete log era to a new era. But we can only do that
if the new proposal beats the existing standards embedded in legacy code on
every single feature.

So X25519 is definitely not going to be enough on its own. We are going to
need a high security curve as well. And that curve has to beat the p-512
curves on performance and implementation robustness and match them on
algorithm security.

So just doing X25519 ends up muddying the waters and missing an
opportunity.

Now when we get to the next stage and deciding which X25519 to implement,
whether this program is intended to provide an algorithm set some of us can
regard as definitive or is just another curve beauty contest makes a big
difference. If we are only doing the latter then pick DJB's parameters and
we are done because what we are doing isn't important enough to be worth
introducing something new.

If we are going for definitive parameters then I would like us to have
exactly two choices: everyday and indisputable. Where the indisputable
curve is the backup curve, curve for long term stored data, etc. And I
would like the two to use different approaches if there is a security
difference and the same approach otherwise (yes I know the curves are
isomorphic but the complexity of the operations isn't necessarily so).

> Sorry, but I am confused.

If we are only doing a 128 bit security level then we are building a new
attraction for the existing zoo. To pull the zoo down and replace it we
need 128 bit and 256 bit.

> efforts, and that NIST's activity is the place to be. So be it.)

The order of operations that makes sense to me is

0) Decide on the next charter/ order of deliverables now

1) Advise TLS on a 128 bit security level curve for key agreement ASAP

2) Advise TLS on the 256 bit curve

3) Advise on the 128 bit and 256 bit signatures

Reason for doing 2 before 3 is that we are as close to a decision as we
will ever be. Delaying the argument now just means starting it all over
again.

The signatures part is going to be lots of bit twiddlin' details and best
do both curves together so they get done the same way.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Feb 2015 10:24:13 -0800

> Answering Yes/No to each of these would suffice.

Sorry for giving an unclear answer, but:

I believe that the CFRG should probably specify one stronger curve at
either 192 or 256.
Both of these seem to have arguments in favor, but if I were pushed I would
probably
go for 256 for the reason that if we're going to be conservative we should
be really
conservative.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Wed, 11 Feb 2015 21:02:55 -0500

> I believe that the CFRG should probably specify one stronger curve at either 192 or 256.
> Both of these seem to have arguments in favor, but if I were pushed I would probably
> go for 256 for the reason that if we're going to be conservative we should be really
> conservative.

I agree with Eric's reasoning, but I would add that getting the 128-bit security level recommendation finished is a high priority.  Get it done first.

Russ

---

From: Andrey Jivsov <[email-masked]>
Date: Wed, 11 Feb 2015 21:57:44 -0800

No.

> Q2: Should CFRG recommend a curve at the 256-bit security level?

Yes. One curve in that security level neighbourhood.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 12 Feb 2015 20:37:58 +0200

> go for 256 for the reason that if we're going to be conservative we should

I consider 256-level curve a bad idea (and Goldilocks as the largest practical
curve) for the following reasons:

1) Too slow

We have performance budgets, and the real world standard for higher-
security curve is P384, so that sets our performance budget.

Now, P-384 implelmentation in OpenSSL is hilariously bad (In fact, I seem
to have a version of OpenSSL where P-521 is faster(!) than P-384). But
proper P-384 would be a lot faster and even well-optimized E-521 would be
slower.

I would estimate that 256-level is about half the speed (for E-521, since
that's faster than 512-bit curves) of 192-level (and goldilocks would be
about 25% slower than 192-level, due to extraordinarily efficient prime).
This is on top of 2.5-3x penalty for 192-level over 128-level.

And remember that some CA people have actually expressed interest at
actually using the larger curve.

There's also similar arguments on low side (P-256 is the standard there),
but Curve25519 (or whatever it is called) delivers the needed performance.

2) Signature problems

Pretty much anything larger than Goldilocks (448-bit p, so ~224 security,
albeit NIST specs seem say it would be 192) runs into trouble with
signatures.

Specifically, such curve would require one of:
- Questionable signature primitives.
- >512-bit hashes (rare, so replaceability becomes a problem).
- Hash extension (very easy to get this wrong).

3) No real security benefit

Anything that can actually break 192-224 bit curve would cast at least
serious doubt on 256 bit curve (imminent breach), if not break it outright.

Rho aginst Curve25519 is already extremely nasty (due to thermodynamical
limitations). But that's a joke compared to rho on 192-224 level curve.
So classical computation projections appear invalid, so actual threats
come elsewhere. E.g. Major cryptoanalysis results, large enough QC.

4) TLS limitations

TLS is seemingly built only for up to 192-level security (even in 1.3).
One could extend TLS for 256-level, but this would run into issues with
symmetric encryption (E-521 and AES-256 aren't even close to being
matched).

Not really useful, given how high 192-level security really is.

Summary:
So not much less vague: There should be one stronger curve, at least
on 192-level (to match the present standard), but faster than P384.

Out of 192 or 256, I would say 192 (but unconstrained choice in range
might be different, but no higher than 224).

-Ilari

---

From: Adam Langley <[email-masked]>
Date: Thu, 12 Feb 2015 10:50:43 -0800

On Thu, Feb 12, 2015 at 10:37 AM, Ilari Liusvaara
<[email-masked]> wrote:
> to have a version of OpenSSL where P-521 is faster(!) than P-384).

Aside: this is my fault. If you build with uint128_t support then you
get optimised implementations of P-224, P-256 and P-521 by Emilia,
Bodo and myself. The five-term structure of P-256 and P-384 is such a
pain that I didn't bother doing P-384 I'm afraid.

Cheers

AGL

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 16 Feb 2015 10:29:54 +0100

No.

No.

Rationale: going beyond 2^128 work factor (which I assume is what is
meant here -- talking about bit-level security is not particulary well
defined) is harmful for security as it introduces complexity and I have
seen no technical or scientifical justification for that complexity.

/Simon

---

From: _MiW <[email-masked]>
Date: Tue, 17 Feb 2015 00:41:11 +1030

Q1: Yes
Q2: Yes, to replace disabled/removed secp521r1 in major TLS libraries.

Thanks,
_MiW

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Feb 2015 10:44:33 +0000

Hi,
To get some closure on the consensus poll:

> Q1: Should CFRG recommend a curve at the 192-bit security level?
About 25% of people responded that they want to work on this (slightly 
more if we count people stating that as a second preference).
Chairs are still discussing what should be done on this.

> Q2: Should CFRG recommend a curve at the 256-bit security level?
About 54% of respondents want to work on this. So chairs think that a 
curve at this level should be included as a recommendation to IETF.

Best Regards,
Alexey, on behalf of chairs.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 18 Feb 2015 09:43:39 -0500

> On Feb 18, 2015, at 5:44 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi,
> About 25% of people responded that they want to work on this (slightly more if we count people stating that as a second preference).
> About 54% of respondents want to work on this. So chairs think that a curve at this level should be included as a recommendation to IETF.
> 
> Best Regards,

Alexey, 

Question about order 128 and 256 at the same time or first 128 and then 256 ? 

	Olafur

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Feb 2015 16:56:23 +0000

On 11/02/2015 10:47, Russ Housley wrote:
> I agree with this prioritization.  I thought the question that the 
> CFRG Co-chair was asking was about the value working on other curves 
> _after_ the recommendation for a 128-bit security curve is done.
>
> Russ
TLS WG chairs would prefer to get recommendations about 128 and 256 
levels at the same time, if possible.
If CFRG gets stuck on 256 level for too long, CFRG chairs will review 
this decision.

---

From: Brian Smith <[email-masked]>
Date: Thu, 19 Feb 2015 01:23:28 -0800

Alexey Melnikov <[email-masked]> wrote:
> TLS WG chairs would prefer to get recommendations about 128 and 256 levels
> at the same time, if possible.

Why?

And is that a TLS WG consensus, or just the opinion of the TLS WG chairs?

Cheers,
Brian

---

From: "Paterson, Kenny" <[email-masked]>
Date: Thu, 19 Feb 2015 10:15:38 +0000

Hi Brian,

>> at the same time, if possible.

Because they perceive that, while they would like CFRG to deliver sooner
rather than later, the time pressure is not so strong that we don't have
time to come up with a curve at the 256-bit level as well. (After all, we
have a generation procedure, and we're in the middle of a poll about the
choice of prime now.)

>And is that a TLS WG consensus, or just the opinion of the TLS WG chairs?

That's something you'd need to ask the TLS WG chairs.

Cheers

Kenny

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 19 Feb 2015 08:45:29 -0800

On Thu, Feb 19, 2015 at 2:15 AM, Paterson, Kenny <[email-masked]>
wrote:

> [Joe] TLS originally asked for curves at two security levels. Rough
consensus in the CFRG indicates that a higher strength curve is desirable.
Since this is not currently holding up any work in the TLS working group
the TLS chairs think it beneficial to deliver both recommendations at the
same time.   The TLS chairs did request that the 128-bit proposal be
refined in parallel in the case that selecting a higher strength curve
drags on.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 19 Feb 2015 08:54:23 -0800

On Thu, Feb 19, 2015 at 8:45 AM, Joseph Salowey <[email-masked]> wrote:
> Since this is not currently holding up any work in the TLS working group the
> TLS chairs think it beneficial to deliver both recommendations at the same
> time.   The TLS chairs did request that the 128-bit proposal be refined in
> parallel in the case that selecting a higher strength curve drags on.

This is just not true: There is this document
https://tools.ietf.org/html/draft-josefsson-tls-curve25519-06 which
sort of is the reason we're doing this.

We've known for months there are no issues with the above draft: why
isn't that enough from the TLS WG perspective?

Sincerely,
Watson Ladd

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 20 Feb 2015 17:07:47 +0000

Hi Olafur,

> Question about order 128 and 256 at the same time or first 128 and then 256 ?
We try to do both at the same time, but this would depend on how much 
CFRG tries to co-operate with chairs. Chairs will monitor progress on 
both and might need to adjust.

Best Regards,
Alexey

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 21 Feb 2015 17:47:06 +0100

On Wed, Feb 18, 2015 at 10:44:33AM +0000, Alexey Melnikov wrote:
> About 25% of people responded that they want to work on this (slightly more
> if we count people stating that as a second preference).
> About 54% of respondents want to work on this. So chairs think that a curve
> at this level should be included as a recommendation to IETF.

My interpration of the answers:
1) Release 128 asap?
- Unknown: 18
- Just do 128 for now: 14
- add others at the same time: 0

2) Which levels?
- Unknown: 5
- Only do 128, higher curves aren't needed: 1
- Something larger than 128, only 1 (ie 192, 256): 9
- Something larger than 192, only 1 (ie 207, 224, 256, 260): 11
- Two curves, one larger than 128, one larger then 192: 6
- Exactly 256 bit: 2

(I might have made some mistakes interpreting people)

Kurt

---

From: Nex6|Bill <[email-masked]>
Date: Sat, 21 Feb 2015 20:06:20 -0800

> On Feb 10, 2015, at 2:52 AM, Alexey Melnikov <[email-masked]> wrote:
> 

yes to both, I agree that 192-bit is more than fine for the everyday use, but for higher security environments or for those more paranoid 256-bit may be required.

-Nex6|Bill