Re: [Curdle] State of draft-ietf-curdle-ssh-kex-sha2?

[denis bider <[e-mail]>]

(Replying to Curdle - the message I forward below was posted only on the
ole' [e-mail])

I'm pretty sure all the feedback so far suggests that
"diffie-hellman-group14-sha256" is the only key exchange method that has
consensus as a MUST right now.

With regard to group15 - if memory serves, the OpenSSH guys were
complaining about too much granularity in that regard, they preferred
group16+.

group16 and larger have my protest as a MUST because too expensive.

DH group exchange methods are not interoperable: implementations that
generate their own groups fail to interoperate with FIPS implementations
half of the time.

ECDH has protestations from some niche implementers. Curve25519 apparently
isn't coming soon to SSH clients that run on clothing tags.

That leaves "diffie-hellman-group14-sha256", which is sensible for MUST,
even though in no way ambitious.

(Note the lowercase "diffie-hellman-group14-...". I've seen someone
capitalize it in this thread. Per RFC 4251, SSH algorithm names are case
sensitive.)

In the SSH/QUIC draft, I opted for the following language:

"The requirement to implement any particular QUIC protocol version or TLS
cipher suite expires on the 5-year anniversary of the publishing of this
memo. At that point, implementers SHOULD consult any new standards
documents if available, or survey the practical use of SSH/QUIC for
implementation guidance."

Perhaps we could put in something like that, given that the only candidate
for MUST is the lowest common denominator that still meets current security
requirements.

denis



-------- Forwarded Message --------
Subject: Re: [Curdle] State of draft-ietf-curdle-ssh-kex-sha2?
Date: Tue, 14 Jul 2020 04:10:18 +0000
From: Peter Gutmann <[e-mail]>
To: Mouse <[e-mail]>, [e-mail]
<[e-mail]>

Mouse <[e-mail]> writes:

As an implementor, it is highly unlikely I will support anything elliptic
curve in the foreseeable future.


I support it but it's disabled by default because I can't think of a
commonly-
used cryptosystem more riddled with side-channels than (EC)DSA, and most of
them end up leaking the private key (that's ECDSA, not 25519 which is too
novel/nonstandard to be usable with anything I work with). In fact a recent
paper on yet another set of side-channel attacks (either "Minerva: The Curse
of ECDSA Nonces" or "Big Numbers - Big Troubles") mentions that this is
merely
the latest set of side-channels that need patching, and more are expected in
the future. And that's after several years of patching ECDSA side-channels
already.

At least with RSA you can just blind and be mostly done with it, you don't
have to deal with a mechanism where there's a linear relation between the
signing nonce and the private key, with everything around that tied up in
side-channels.

Peter.