Subject: [Cfrg] EC - next steps to get draft-irtf-cfrg-curves done

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

Chairs discussed next steps for finishing draft-irtf-cfrg-curves and what kind of questions CFRG needs to be asked in order to get progress. We are planning to do a series of polls/consensus calls, approximately every 7 days, and for some questions even more frequently.(*)

Chairs would remind everybody not to rehash old arguments. Pointing to older messages where such arguments were made would be much more preferable.

Chairs are also asking people to stay on topic and only discuss the current set of issues at any given time. Comments/opinions made on future or unrelated topics are likely to be ignored by chairs and offenders will be told off-list.

Chairs are also thinking about asking one of the CFRG participants to keep track of other [new] issues with draft-irtf-cfrg-curves. If you are interested to help, please contact chairs directly.

Best Regards,
Alexey, for CFRG chairs

(*) - while chairs might not summaries results of each poll/consensus call right away, the RG should have expectation to move to the next set of questions after the deadline from the previous poll/consensus call is reached. Chairs reserve the right to extend deadlines if new information is presented, but this will not be the default mode of operation.

---

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

Thanks to the chairs for trying this approach. I've answered
your first poll, but I'd also like to say that I'm entirely
fine if the chairs use their judgement to evaluate poll responses
and I hope you do not limit yourselves to purely mechanical
evaluations. That's because it's inevitable that people will
question the questions, as has happened already;-) And we
don't want to have to re-do a bunch of polls I hope.

So thanks again and please use your good judgement in how you
go about determining rough consensus where you see that exists.

Cheers,
S.

On 10/02/15 10:44, Alexey Melnikov wrote:
> Chairs discussed next steps for finishing draft-irtf-cfrg-curves and
> what kind of questions CFRG needs to be asked in order to get progress.
> We are planning to do a series of polls/consensus calls, approximately
> every 7 days, and for some questions even more frequently.(*)
> 
> Chairs would remind everybody not to rehash old arguments. Pointing to
> older messages where such arguments were made would be much more
> preferable.
> 
> Chairs are also asking people to stay on topic and only discuss the
> current set of issues at any given time. Comments/opinions made on
> future or unrelated topics are likely to be ignored by chairs and
> offenders will be told off-list.
> 
> Chairs are also thinking about asking one of the CFRG participants to
> keep track of other [new] issues with draft-irtf-cfrg-curves. If you are
> interested to help, please contact chairs directly.
> 
> Best Regards,
> Alexey, for CFRG chairs
> 
> (*) - while chairs might not summaries results of each poll/consensus
> call right away, the RG should have expectation to move to the next set
> of questions after the deadline from the previous poll/consensus call is
> reached. Chairs reserve the right to extend deadlines if new information
> is presented, but this will not be the default mode of operation.
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

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

> don't want to have to re-do a bunch of polls I hope.

I'm surprised that you consider implicitly rejecting 2^448-2^224-1 for
unstated arguments a good idea, given your openness to supporting it.

Then again the CFRG leadership has refused to judge between rival proposals
on technical grounds, instead choosing to poll what amounts to a bunch of
random people. The best arguments, not the popularity of bad arguments,
should carry the day.

The IETF leadership has likewise decided to turn what should have been a
straightforward evaluation of a proposed mechanism into a lengthy and
unwarranted design by committe exercise. If we're serious about reducing
the number of options, we shouldn't turn around and accept national
standard after national standard. If we're going to try the crypto
standardization game, we should use the methods that produced standards
like AES, not ones that require people willing to put forward proposals to
sit through increasingly lengthy and irrelevant threads, for fears the
chairs will attempt to call consensus despite strong technical arguments
against the position being put forward.

This is not an idle fear: it's exactly what happened in November with
regards to the primes put forward at higher levels.

If all possible arguments have been put forward, it shouldn't be
controversial which proposals are better than others, at least for most
comparisons, and all that remains is to pick between a few local maxima.
But that's not what is being done.

Sincerely,
Watson Ladd
>http://www.irtf.org/mailman/listinfo/
<http://www.irtf.org/mailman/listinfo/cfrg>cfrg

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Feb 2015 18:38:28 +0000

Hi Stephen,

On 10/02/2015 17:41, Stephen Farrell wrote:
> evaluations.
Yes, this is not going to be purely mechanical.
> That's because it's inevitable that people will
This co-chair agrees.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 10 Feb 2015 21:23:07 +0000

Hi,

>unstated arguments a good idea, given your openness to supporting it.

Thanks for making explicit what was implicit.

Yes, we are ruling out 2^448-2^224-1 and focussing on primes yielding
curves at or near the 192 and 256 bit security levels. There was a long
discussion on this on the list a while back, no clear consensus emerged on
whether we should "stick" to the 192-bit and/or 256-bit security levels or
go for "intermediate" values, and the chairs are now making a decision on
this.

>Then again the CFRG leadership has refused to judge between rival
>proposals on technical grounds, instead choosing to poll what amounts to
>a bunch of random people.

That doesn't seem like a very nice thing to say about all your fellow
participants on the CFRG list, Watson!

Best regards, 

Kenny 

> The best arguments, not the popularity of bad arguments, should carry
>the day.
>the number of options, we shouldn't
> turn around and accept national standard after national standard. If
>we're going to try the crypto standardization game, we should use the
>methods that produced standards like AES, not ones that require people
>willing to put forward proposals to sit through
> increasingly lengthy and irrelevant threads, for fears the chairs will
>attempt to call consensus despite strong technical arguments against the
>position being put forward.

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 10 Feb 2015 13:29:44 -0800

> go for "intermediate" values, and the chairs are now making a decision on

It seems to me that no clear consensus emerged because no one actually
tried to steer the discussion in the direction of answering the
question.

I bet that, if you asked the following question:

    Should CFRG pick a curve that is Pareto-optimal in terms of
prime-order subgroup size and performance?

then you would get a pretty resounding "yes", modulo a few comments
about 512-bit memory busses and national standards.  But no one ever
codified desiderata nor asked the question.

To me, the questions I've seen are mostly of the form "should we do
A", where A is insufficiently well defined, a yes answer seems to make
some progress, and a no answer keeps us in the morass we're in.

And no, the answers to these current questions seem to be extremely
far from a "yes" consensus to me.

--Andy

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 10 Feb 2015 21:40:45 +0000

Hi Andy,

>tried to steer the discussion in the direction of answering the

Possibly, possibly not. Perhaps the chairs were over-optimistic in the
past in assuming that folks would have sensible discussions and come to
consensus without too much prodding.

>prime-order subgroup size and performance?

And I'd bet you the same amount that we'd end up with a long meta
discussion about the precise definition of Pareto optimality!

>some progress, and a no answer keeps us in the morass we're in.

Maybe so previously, but not in this case, I feel. If there's a clear "no"
to both questions, we will just not do higher security levels (possibly
returning to the question later, much later, once we've delivered
something useful for the TLS WG).

>far from a "yes" consensus to me.

That's just fine - see above.

Cheers,

Kenny

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 10 Feb 2015 13:59:40 -0800

> go for "intermediate" values, and the chairs are now making a decision on

Oh no!

Ed448-Goldilocks is the best performing curve "near" a 256-bit security
level. Granted we're talking about a 32-bit difference, but really that
32-bits is a bit "fuzzy" in terms of how it relates to equivalent symmetric
security levels.

>From what I've seen other curves near a 256-bit security level are much
slower, and E-521 specifically is problematic because it's greater than
512-bits (which means we can't do things like use a 512-bit hash function
when computing signatures).

I'm really sad to hear this. I think Ed448-Goldilocks is the best choice
for a fast high-security curve.

-- 
Tony Arcieri

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 10 Feb 2015 14:07:29 -0800

On 02/10/2015 01:59 PM, Tony Arcieri wrote:
> E-521 specifically is problematic because it's greater than 512-bits 
> (which means we can't do things like use a 512-bit hash function when 
> computing signatures).

The above reads a bit odd. Often the hash function cannot be perfectly 
matches to the curve size, thus the expansion or contraction rules are 
defined and relied upon.

e.g. one can use SHA-256 with P-384.

---

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

> e.g. one can use SHA-256 with P-384.

EdDSA in its current form uses hash functions in many places. One of them
is as a KDF for the private scalar.

-- 
Tony Arcieri

---

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

> e.g. one can use SHA-256 with P-384.

Can you show me an ECDSA specification that says it's allowed to use
SHA-256 with P-384?

-- 
Tony Arcieri

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 10 Feb 2015 14:19:06 -0800

On 02/10/2015 02:12 PM, Tony Arcieri wrote:
> On Tue, Feb 10, 2015 at 2:07 PM, Andrey Jivsov <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The above reads a bit odd. Often the hash function cannot be
>     perfectly matches to the curve size, thus the expansion or
>     contraction rules are defined and relied upon.
>
> EdDSA in its current form uses hash functions in many places. One of 
> them is as a KDF for the private scalar.
>
>

OK, but I think this is fine.

SHA-256 + P-384 is expected to have 128-bit security. Likewise, it seems 
OK to allow the padding/truncation with EdDSA. It will make the 
higher-level system less flexible and harder to deploy if the hash 
algorithm (or hash algorithm size) are hardwired into the signature 
algorithm for the curve size.

---

From: Andrey Jivsov <[email-masked]>
Date: Tue, 10 Feb 2015 14:41:09 -0800

> Can you show me an ECDSA specification that says it's allowed to use 

http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf sec "4.6 DSA 
Signature Generation" for DSA defines the truncation/expansion.

Sec "6.4 ECDSA Digital Signature Generation and Verification" discusses 
the implications of mismatch of the strength of the hash function. The 
section then prescribes:

"When the length of the output of the hash function is greater than the 
bit length of n, then the leftmost n bits of the hash function output 
block shall be used in any calculation using the hash function output 
during the generation or verification of a digital signature." The 
section also says that weaker hash function "ordinarily should not be 
used", but doesn't prohibit this (otherwise why discuss the implications 
of the mismatch earlier in the section?).

Because weaker hash is an implicit default in many online protocols and 
in offline protocols you never know the capabilities of all the 
verifiers, please consider that prohibiting P-384 with SHA-256 would 
have an effect of punishing these who want stronger security of P-384 
(or a single X.509 cert that works for all security levels).