Hi Alyssa,

On 11/02/2015 06:56, "Alyssa Rowan" <akr@akr.io> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>On 11/02/2015 02:04, Watson Ladd wrote:
>
>>> 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.
>
>Um, what.
>
>Chairs: No! I assumed that when you were asking these questions you were
>including all of the 383<n<511 primes in the "192-bit" category, because
>you _explicitly_ mentioned that choice of primes would take place
>_afterwards_ - but instead, you've arbitarily eliminated most of the
>leading candidates for an extra-strength curve?!

Sorry, no, that was not our intention.

It was not an arbitrary decision, though. We reviewed the long discussion
we had about security levels and how they are perceived externally by
non-cryptographers, and decided that it was better to stick to
easily-digested security levels. There was NOT consensus (even rough) on
that point, but the chairs believe that we need to make progress quickly
now, and this is one of the ways we are using to simplify the choices that
we need to make. Chairs have that discretion in IRTF, and we are
exercising it.

I don't believe it eliminates "most of the leading candidates for an
extra-strength curve" as you put it. There are several candidates with
good performance (albeit with the limited perf analysis we've seem on the
list) within a few bits of 384 and 512.

>
>Does this also affect 41417?
>
>Let me guess: Was your next question going to be, depending on the
>choice, 2^384-317/2^389-21 and/or 2^512-569/2^521-1?

No. It was going to be a more open-ended question - what primes should be
considered at the 192-bit and/or 256-bit security levels? Presumably the
primes you mention would be then be put forward.

But the question also depends on the view of the list - maybe the
consensus will be that we shouldn't do any other security levels for now,
in which case the question would not need to be asked.

>
>> This strikes me as extremely premature. [Š]
>
>I concur. There was no consensus earlier because we didn't have the
>performance data to make any decisions on technical grounds.

We don't have a full set of performance data now either, and it seems
highly unlikely that we're going to get *all* the data that *all* list
readers might want to have within a reasonable time-frame. So we have to
move forward with the data we have seen so far, which while not complete
is certainly useful and indicative.

People who are uncomfortable about the amount of available performance
data for higher security levels should feel free to vote "no" on both
questions.

>
>The performance data we have now looks pretty good for Goldilocks, as
>I was tabulatingŠ
>
>For the chairs here to start making arbitrary choices may be
>externally inappropriate and suggests the process has simply failed.
>(Do we still have an NSA co-chair? ¬_¬)

The choice was not arbitrary. See above.

We are trying to prevent a larger-scale process failure by steadily
narrowing the scope of our choices, based on reviewing what we've seen on
the list, our best judgement, and any consensus where we see it.

>
>This unexpected development changes my answer to a firm [No, No].

Noted.

>
>And inspires me to suggest that instead, perhaps an individual draft for
>Goldilocks is the way to go here?

Please produce one if you feel strongly about it. We can even consider
adopting it as a RG draft, after we're done with the current work of
making recommendations to the TLS WG.

>
>It's a leading candidate and an excellent compromise. It's a pretty
>good choice for a high-performance, extra-strength, rigid curve
>if we were going to recommend 2 curves.
>
>Your arbitrary decision changes nothing with that.

The choice was not arbitrary. See above.


>I think it may be
>more likely to reach consensus than this ill-conceived guided choice
>ballot.

Based on what I have seen on the list over the last 9 months, I tend to
disagree. There has been little consensus on pretty much anything
curve-related at any point. We very much need to start making decisions -
consensus-based where possible, and not if necessary.


Cheers

Kenny

>
>- -- 
>/akr
>-----BEGIN PGP SIGNATURE-----
>
>iQIcBAEBCgAGBQJU2v0cAAoJEOyEjtkWi2t6A9IP/jca62wUoaGl2Y447MTRv8xl
>1qg5XRQ6L1ysBMZz3LVaNKcTmqZl6L4881X2f3BB6Og/YCB2iwFRRUugmiTKBhxa
>RM3sdmyYHE7d2EDAvjChltUMorOWC+FocDX4GsMOc5wn3z+rnN5cvM0YOYKxa/sp
>A7GXL6efpQnIi+uee12V+D1Qw/IpbxOLQUQIQRMONhsMggfydLyRvm0Kuc490KBD
>iWHCqPrSawAiXUaWfwXQi2yOkUPKlYgfwkEYzf/fd5wO4koi+q0/8Eqkz6xbR36S
>KpqHHQMymf7HVLyTOMj8KXRozc3RFvMateAUAD2v9ODCJtGvcK4lyUiYJLM5/RFY
>7LjbQ0X/9iDQz9bxh2yAT5RorzcMAFIOMF4VSNXn9xg6dHFLhlOxURFO4ibN1E9a
>0Jrz5in1DwiZh3bWUeXgkVELVXMmtXoM6squSSvmwX86hWa/GH323R9XPwkOrBeV
>ej7qJQHUSdwOnih595hZk7tcUVel4L9JqHoFXL8YdyrxYazzuxun0vzGTkPpZMf7
>XZ2pgV4mgHC+nt609Iy3GVP4Yw1blkCCLH0+KGaH+PqXFM52hk/vxHw3Xnu1iSTd
>EkcnuObp5nGqW/NDB8J0Z/4kKBbaNh+iN/bP7Afx0G6iiHUt4GgMawsjxMYQ9+p9
>U5qccirwc3XQ3jC3Wqqy
>=1Nsn
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.org/mailman/listinfo/cfrg