|
Tero -
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.
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.
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.
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.
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.
Our SSH Client is going to include all three of the above methods by
default because it does not have to worry about denial of service.
We are not going to support groups higher than 16 at this time, both
because of their cost, and because Windows CNG does not support them. I
nevertheless welcome the definition of those groups, so that it is
straightforward to implement them in case circumstances change so that this
becomes desirable.
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.
denis
From: Tero Kivinen
Sent: Tuesday, September 6, 2016 07:11
To: Mark D.
Baushke
Cc: Daniel Migault ; Peter
Gutmann ; Watson Ladd ; Damien Miller ; IETF Curdle ; Paul Hoffman ; Rich Salz ; denis bider (Bitvise) ; IETF SSH ; Phillip Hallam-Baker
Subject: Re: [Curdle] Group 15 needed in
draft-baushke-ssh-dh-group-sha2 Mark
D. Baushke writes: > The current draft-ietf-curdle-ssh-kex-sha2-03 draft expires in about a > week, so I will be publishing a new draft before this Friday. Note: I > will not be able to attend the IETF (November 13-18) in South Korea. > > Here is my current sugestions for the DH entries in the table: > > Key Exchange Method Name Reference Note > diffie-hellman-group14-sha256 This Draft SHOULD > diffie-hellman-group15-sha512 This Draft MAY > diffie-hellman-group16-sha512 This Draft SHOULD > diffie-hellman-group17-sha512 This Draft MAY > diffie-hellman-group18-sha512 This Draft MAY > > 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. The reason is that these key exchange methods are negotiated in text. We already have key exchange list in openssh saying something like: curve25519-sha256%libssh.org@localhost,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: ,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. Also I do not really expect most of them to be used ever... 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? 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. Especially if we are saying curve25519-sha256 is going to be MUST, I see no reason to define that many MAYs. -- kivinen%iki.fi@localhost _______________________________________________ Curdle mailing list Curdle%ietf.org@localhost https://www.ietf.org/mailman/listinfo/curdle |