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

[Tero Kivinen <kivinen%iki.fi@localhost>]

denis bider \(Bitvise\) writes:
> I agree I would much rather see dh-g14-sha256 than
> diffie-hellman-group14-sha256. However, the ship for this has sailed a long
> time ago. As far as I know, some of these methods are already implemented. The
> benefit of shortening the names is negligible compared to the likely
> coordination issues, and it could be argued that the longer names are more
> understandable, as well.

If they follow the rules set for the identifiers for the secure shell,
they should not use names without domain name before "IETF CONSENSUS".
If they do that is their problem. We cannot make old names to use
shorter names, but we can make the new allocations to use shorter
names. If someone implements things before it is out as RFC, they
should be able to update their implementations too when the RFCs come
out. 

> As far as I know, the cost of making the KEXINIT messages longer is trivial
> and probably not even worth mentioning. If SSH wanted to optimize this to
> begin with, it would have gone with single-character names for most
> algorithms, omit the commas in algorithm lists when not necessary, etc. The
> original designers have, in my opinion correctly, decided that readability
> trumps conciseness, and that the savings of a few bytes in a message that’s
> exchanged once per connection, and then once per hour or per 1 GB of data, are
> not worth chasing.

The idea was that there is only one or two key exchange methods at
times, there was never supposed to be dozens of them. The encryption
algorithms, mac algorithms etc used much shorter names. And I do
remember people complaing that they do not want ot use @ssh.com etc
prefix, as it makes the names longer...

> From a performance perspective, the algorithms that involve DH group exchange
> are much costlier than negotiating the DH group in the KEXINIT packet, even if
> you were to enumerate many more groups than we are currently proposing. The
> group exchange methods involve not only sending two extra messages, which are
> hundreds of bytes themselves, but require an entire additional round-trip
> between the client and the server, adding noticeable latency to the
> establishment of the connection, or completion of key re-exchange.

There is no need to really negotiate DH group in the KEXINIT packet,
you need to agree on common one. For example IKEv2 uses a method,
where the initiator proposes all groups it will allow, and picks one
of them and sends KE payload for it. The responder will then either
accept the selected group if it acceptable for him. If it is not
acceptable for responder, it will send notification back, saying that
your group was not acceptable, but this group is, so then the
initiator retries with the same list of allowed groups, but different
group in KE payload.

This allows agreement of common group in case there is one, and also
most of the times both ends have same group allowed, thus the initial
selection is suitable for both ends too. This is how the DH group
agreement should have been done in secure shell too, but unfortunately
it was not done in this way, and now is too late to change that.

> Compared to the group exchange methods, negotiating the DH group in
> KEXINIT is downright efficient. And if you don’t want to use all of
> the groups, it is fairly straightforward to simply not include them.

If i remember right the secure shell DH group negotation sends the
full group information, and I think that is bad idea. Verifying the
group takes long time (full primatlity checks etc), thus you should
not accept random groups sent by other end. On the other hand if you
always require both ends to configure same set of groups to both ends
before they can be used, then you might as well give names for them.

Yes, I agree that using predefined groups is much better than using
groups sent inline the exchange. 

> Our SSH Server is going to include by default only
> diffie-hellman-group14-sha256 and diffie-hellman-group15-sha512. It is also
> going to be possible to enable diffie-hellman-group16-sha512, but it’s likely
> going to be disabled by default because it’s twice as costly as group 15 and
> exacerbates a denial of service vector for busy servers.

Ok, so you would like to define three. That would still be ok, and it
is better than the five there is now, but I still think two should be
enough.

> With respect to Curve25519, I think it’s nice and all, but it’s
> probably going to be the first thing broken by a quantum computer.
> Anyone concerned with forward secrecy should start using a hybrid
> key exchange method that incorporates a quantum-safe algorithm
> approximately now. It is that we should be focusing on, I think,
> instead of trying to put X25519 everywhere, cast in concrete. It’s
> going to bite us.

We are working on that in the IPsecME for the ESP. I.e., a way to make
ESP quantum computer resistant. I.e., the main goal is to make so that
even if you store all ESP traffic now, you cannot decrypt them when
you get the quantum computers, unless you also know the shared secret
between hosts.

Something like that might also work with secure shell, but situation
is bit different there, as in IKE/ESP both the client and server will
have connection related configuration, thus having one more
pairwise configurable thing there is not that hard, while in secure
shell it might be.
-- 
kivinen%iki.fi@localhost