Re: [Cfrg] should the CFRG really strive for consensus?

[Watson Ladd <[e-mail]>]

On Wed, Dec 31, 2014 at 11:19 AM, Christoph Anton Mitterer
<[e-mail]> wrote:
> On Wed, 2014-12-31 at 14:44 +0000, Adam Langley wrote:
>> If you believe in the security of curve25519 then you also believe in
>> the security of Microsoft's current position at ~128 bits. They have
>> the same structure and thus strictly the same strength.
> My point wasn't specifically about that discrepancy between curve25519
> and MS' position... as you pointed out already in your previous email,
> they have the same security, by all means of current knowledge....
>
>
>> IRTF groups do not, technically, have to reach consensus. However,
>> everyone does have to function on the same Internet at the end of the
>> day.
> ... my point was rather about the general political problem that still
> hides behind the "now open and no longer NIST controlled"
> standardisation process of crypto stuff:
> Even though the current example of MS vs. "everyone else" may not be a
> security problem, it still shows that the whole process would be kinda
> "vulnerable" to manipulations - namely if a big player puts pressure on
> the CFRG on behalf of his own ideas (which may - or may not - have some
> evil hidden within).

Yeah, but we would be done now if that was what was going on. Might
even be worth it ;)

What people might not be aware of, particularly if they joined the
list late, is that we've been discussing all of these proposals
(except for 2^389-21) since April. Nothing new has been discovered.
Yet we've missed two self-imposed deadlines, and have no visible plan
to actually meet hard external deadlines, coming close to a year since
we decided to start.

Why? Unclear. We've had requests since 2010 to add X25519 to TLS. In
the meantime, Brainpool and ANSSI curves got added without this mess.
Why are we treating Curve25519 differently from these national
standards? And why did it take so long for the initial request to get
sent to CFRG? Irrelevant the problem we face now, but interesting in
considering how avoid it in the future, or, punt it to someone else.

The CFRG is potentially very good at answering questions about
security. But we shouldn't be surprised that it is bad at having to
make choices, particularly when one group remains determined to stay
in the running by consistently modifying its proposal as issues are
raised. The net effect is that people will go out of their way to not
involve CFRG, new cryptography will not get proposed, and attempts to
ensure that protocols are reviewed by people who know what they are
doing in cryptography will meet resistance due to the long delay that
will be feared.

The IRTF and IETF leadership bear a substantial amount of blame for
this situation, as does the leadership of the TLS WG. By kicking over
to the CFRG a question that wasn't "is X25519 secure? What are the
issues with adoption?", they managed to ensnare us. Meanwhile, SSH
continues to adopt Ed25519, and X25519 without a problem.

The proposed longer curve over 2^384-317 or whatever, is inferior in
security to the equally fast Ed448, and equal in security to the 8%
faster 2^389-21. This is a substantial difference between the
proposals, and is not going away, even with the lower-security curve
being a bikeshed color away from X25519. It's the same difference
between Curve25519 and the original NUMS proposal in terms of prime.

The NUMS group has repeatedly explained that they will not take their
ball and go home, and I doubt that IE and IIS will make the decision
to support or not based on whether or not we pick the NUMS proposal,
which has been repeatedly modified to try to stay in the game. The
concern that we need an actual consensus, or Microsoft won't add these
curves, is one I think is overblown, judging from public statements
from many of the proponents of the NUMS draft.

The fewer differences between the two rival proposals there are, the
more pointless this debate gets. In April the differences were in
point format on the wire, choice of prime (with DJB et al favoring
faster primes, and NUMS slower primes) and signature method. Now we've
eliminated the point format difference, leaving the prime choice
difference, except that the 2^255-19 prime is now being used by both,
and NUMS is open to adding a different signature scheme in addition to
their FrankenECDSA proposal, of which several implementors have been
skeptical of the utility.

The choice is between the extra security of Ed448, extra speed of
2^389-21, or a prime with few redeeming features. Far from being "not
horrible", the NUMS proposal is pure bikeshedding at the 255 bit
length, and retains some of the original disadvantages at the 384
length. We don't know how well it performs in as much detail as I
would like, because there has not been an eBATS submission. Almost all
of the bad original features of the NUMS proposal have been fixed:
they are now proposing the point format for ECDH that was originally
suggested for Curve25519, have corrected the use of incomplete
coordinates, and I think any remaining questions about signatures are
uncontroversial enough to be easily resolved. (If one sentence will
get thrown back at me, this one is it)

TL,DR: I think there are technical factors in favor of either Ed448 or
2^389-21 over the proposed prime at the 384 bit level, either extra
security or extra speed. If the chairs think it necessary to pick the
2^384-317 prime for political reasons they should do, ruling that at
the 384 level the extra performance or security are less important.
They shouldn't rely on the variance between differing benchmarking
systems as an excuse, or try to claim a political choice as due to
spurious technical reasons: I doubt anyone is going to be fooled and
it will only further undermine the reputation of CFRG.

Sincerely,
Watson Ladd


>
>
> Cheers,
> Chris.
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> 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