Subject: Re: [Curdle] Adoption

From: denis bider <[email-masked]>
Date: Sat, 20 Feb 2016 16:39:29 +0000

Phillip:

> We want it to be possible for NIST to adopt CFRG curves
> in place of their 15 year old curves.

+1.

I am in favor of curve448-sha512 (rather than -sha256) for this reason.

We have no way to compel NIST to cooperate. However, I would prefer to create circumstances where NIST can adopt IETF work, especially when the opportunity is this easy. Everyone wins if they do.

Non-cooperation is generally counter-productive. The flexibility required to allow for cooperation in this case seems minor.

Watson:

> What about encryption? You lose all confidentiality even
> for old messages. There is no reason to use Curve448 in
> authentication.

The use of Curve25519 and Curve448 in SSH is for encryption. It's used for key exchange, not authentication.

> includes unnecessary flexibility.

The cost of flexibility in SSH has already been paid in its design. The cost of supporting an additional algorithm is highly reduced.

If we standardize curve448-sha512, this could become a single key exchange method adopted both by NIST-oriented and non-NIST-oriented users. If we do not, we guarantee a fork where ecdh-nistp384 will be required by NIST-oriented users, and curve25519-sha256 will be preferred by others.

Paul:

> If a small number of national security agencies want stronger
> than 128-bit security, they can do their own standardization.

IETF is a standards body. The US is the world's largest economy, and NIST sets standards for a large proportion of it.

A standards body cannot be ignorant as to the needs of a large proportion of its users. The sentiment you express is purposeful non-cooperation, out of principle rather than practicality. Such sentiments are a disservice to implementors and users, who need standards for the real world.

It seems to me this type of a sentiment does not belong in a standards body.

denis

---

From: Watson Ladd <[email-masked]>
Date: Sat, 20 Feb 2016 08:43:04 -0800

On Sat, Feb 20, 2016 at 8:39 AM, denis bider <[email-masked]> wrote:
> We have no way to compel NIST to cooperate. However, I would prefer to
> create circumstances where NIST can adopt IETF work, especially when the
> opportunity is this easy. Everyone wins if they do.
>
> Non-cooperation is generally counter-productive. The flexibility required to
> allow for cooperation in this case seems minor.
>
>
> Watson:
>

Look at the list of drafts again. It includes DNSSEC, where the cost
of multiple options is petty high. Using Curve448 and Ed448 in SSH
doesn't create the same issues.

> The cost of flexibility in SSH has already been paid in its design. The cost
> of supporting an additional algorithm is highly reduced.
>
> If we standardize curve448-sha512, this could become a single key exchange
> method adopted both by NIST-oriented and non-NIST-oriented users. If we do
> not, we guarantee a fork where ecdh-nistp384 will be required by
> NIST-oriented users, and curve25519-sha256 will be preferred by others.
>
>
> Paul:
>
> IETF is a standards body. The US is the world's largest economy, and NIST
> sets standards for a large proportion of it.
>
> A standards body cannot be ignorant as to the needs of a large proportion of
> its users. The sentiment you express is purposeful non-cooperation, out of
> principle rather than practicality. Such sentiments are a disservice to
> implementors and users, who need standards for the real world.
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: denis bider <[email-masked]>
Date: Sat, 20 Feb 2016 16:49:59 +0000

DNSSEC is not my area of expertise, so I have no opinion about the use of Curve448 there.

I support curve448-sha512 for SSH, to increase the likelihood - though not a guarantee - that in a few years, we might have a single, common, strong key exchange method that everyone can agree on.

Watson Ladd <[email-masked]> , 2/20/2016 4:43 PM:

 
 
_______________________________________________ 
Curdle mailing list 
[email-masked] 
https://www.ietf.org/mailman/listinfo/curdle

---

From: Kyle Rose <[email-masked]>
Date: Sun, 21 Feb 2016 14:36:30 -0500

> key exchange, not authentication.

At least for curve 25519, it is offered by recent versions of OpenSSH
both for KX ([email-masked]) and for authentication
([email-masked], for both host key authentication
and user authentication).

draft-josefsson-ssh-curves notwithstanding, curve 448 doesn't yet
appear to be in-use in the real world for either at this point.

Kyle