Re: Group 15 needed in draft-baushke-ssh-dh-group-sha2

Tero Kivinen <[email protected]> writes:

> Mark D. Baushke writes:
...elided...
> > I do not see any problems with letting these kex method names be defined
> > and used by folks that want them.
> 
> I think it is bad idea to define too many KEX methods. 
>
> I think there should only be two, one with sha256 one with sha512,
> i.e., diffie-hellman-group14-sha256 and diffie-hellman-group16-sha512.

You would be implementing the SHOULD MODP groups in this case. This
seems like a reasonable configuration choice. If possible, I would hope
you could also support curve25519-sha256, given it seems desirable for
it to be a MUST kex.

> The reason is that these key exchange methods are negotiated in text.
> We already have key exchange list in openssh saying something like:
> 
> [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
> 
> (150 octets), and now when we add to this list new methods:

Yes, but this draft RFC is moving most of those to MAY and some to
SHOULD NOT.

I would expect that after this RFC is published, a number of
implementation of the default kex proposals would only contain this
list:

curve25519-sha256,ecdh-sha2-nistp521,ecdh-sha2-nistp384,diffie-hellman-group16-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1

which is the MUST and SHOULD entries which is only 143 octets.

> ,diffie-hellman-group14-sha256,diffie-hellman-group15-sha512,diffie-hellman-group16-sha512,diffie-hellman-group17-sha512,diffie-hellman-group18-sha512
> 
> (another 150 octets), it gets to 300 octets, just to negotiate the key
> exchange methods. And this string is sent in both directions during
> the negotiation.

Yes.

Even if everyone were to implement all of the current kex methods and
have a proposal for each of them, is this a sufficient problem for an
implementation to need to save a sixteen bytes per algorithm?

If there support from the implementors for this change, I will ammend my
draft.

> Also I do not really expect most of them to be used ever...

The hope is that there is flexibility in the implementations to allow us
to more quicly discard 'weak' entries and adopt 'strong' entries as we
move forward.

> At least if we define all of them, how about making strings bit
> shorter, something like dh-g14-sha256 instead of
> diffie-hellman-group14-sha256?

I think that the implementors need to provide their inputs on what
strings should represent the algorithms to be used.

> When you have multiple algorithms tied together (here key exchange
> method, group, and hash) it is better to avoid full combinatory
> expansion, and only define those which are known to be used.

Isn't that a chicken and egg problem? None of these new kex names are
currently being used.

I would like to have at least one kex that uses sha512 given that some
cryptographic experts in the US government seem to think that sha256 is
not good enough for top secret. I don't know if they are ultra paranoid
or not, but it seems prudent to err on the side of being a bit paranoid
if it is not too expensive for the uses involved.

> Especially if we are saying curve25519-sha256 is going to be MUST, I
> see no reason to define that many MAYs. 

There are a lot of different stake-holders in this standard. I do not
pretend to be able to make the business trade-offs for everyone.

The primary goal of this RFC is to demote a number of weak key exchanges
and to promote the curve25519-sha256 kex. If there are enough
implementations that are able to move away from MODP groups, then
perhaps all of them could be deprecated. However, the diversity of the
math seems to be a compelling reason to have DH, ECDH, and EdDH methods
in place.

	-- Mark