Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)

["Mark D. Baushke" <mdb%juniper.net@localhost>]

Ni Niels,

Niels Möller <nisse%lysator.liu.se@localhost> writes:

> If at all possible, I think it would be desirable to
> 
> 1. Limit the number of REQUIRED/MUST key exchange algorithms to one (1).
>    I think curve25519 (if people agree it's mature enough) or group16
>    are reasonable choices. I.e., demote ecdh-sha2-nistp384 to SHOULD or
>    MAY.

I am willing to consider a move of ecdh-sha2-nistp384 to SHOULD.
This would mean only one Elliptic Curve (curve25519-sha256) is a MUST.

For ecdh-sha2-nistp384, the downside of this is that OpenSSL library has
no tuning or constant-time multiplication optimizations for the
NIST-P384 curve. It is not clear to me if anyone is going to try to
improve this situation. So, this means that ecdh-sha2-nistp384 may be
open to side-channel attacks right now for those using the OpenSSL
implementation.

If it were defined, I might be interested in moving to curve448-sha512
as the single MUST algorithm, with the understanding that a lot of the
other algorithms that are listed will continue to live for a time
anyway.

That said, is it desirable to also make one of the MODP Diffie-Hellman
groups also be a MUST? 

Perhaps the selection of diffie-hellman-group18-sha512 which has a
security strength estimate of ~190 bits as compared to curve448 which has a
security strength estimate of ~224 bits of security (per RFC7748).

> 2. Make it possible for a conforming implementation to support only one
>    of sha256 and sha512. If we make anything using sha512 REQUIRED, I
>    think we should avoid to make sha256 REQUIRED too. And vice versa.
> 
>    I don't think I follow the argument in favor of sha512, but using
>    sha512 for all REQUIRED methods is nevertheless better than a mix.

I am not sure I follow this line of reasoning. I have seen most
libraries that implement one of the SHA2 family of functions tends to
have an implementation for all members of the family.

>    According to the table, group 16 has an estimated security strength
>    of 240 bits. As argued before, I don't think birthday-paradox is
>    relevant as the hash function is used. Hence, if sha256 is used
>    together with group16, sha256 seems good enough for the foreseeable
>    future, and in addition, unlikely to be the weakest link.

Sure, I tend to think that the weakest element will be the source of
entropy in the system. 

This does not mean that I understand all of the attacks against hashing.
(For example, I still do not understand why BLAKE2 did not win the SHA3
competition. Although, I do admit that I find the SHA3 XOF functions to
be fascinating.)

The key here is the phrase 'foreseeable future' and for that I want to
be a bit more forward-looking and would very much like to see SHA2-512
if there is a negative bias in other publications for SHA2-256 still
being used as a cryptographic primitive.

Many processor families even have some chips with hardware acceleration
for SHA2-256 (e.g., Arm, Intel, Octeon).

> > Please let me know of additional comments.
> 
> In short, no strong objections, but I'd prefer if the selection of
> REQUIRED algorithm(s) were even more restrictive.

Okay, I can understand this.

	-- Mark