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

[[e-mail] (Niels Möller )]

"Mark D. Baushke" <[e-mail]> writes:

>   a) Should the draft list all of the Key Exchange Method Names 
>      in the https://www.ietf.org/assignments/ssh-parameters/ssh-parameters.xml
>      table?

I think that would be helpful.

>      If so, does the following capture the desired state?

For discussion, it would also be helpful with another column with the
previous status of the method.

> Key Exchange Method Name              Reference     Note
> diffie-hellman-group14-sha1           RFC4253       OPTIONAL
> ecdh-sha2-nistp256                    RFC5656       REQUIRED
> ecdh-sha2-nistp384                    RFC5656       REQUIRED
> ecdh-sha2-nistp521                    RFC5656       REQUIRED
> diffie-hellman-group15-sha256         This Draft    REQUIRED

I don't think it makes sense with multiple REQUIRED algorithms. (Side
note: The exact meaning of REQUIRED is somewhat unclear in the presence
of local configuration. I think it means that an implementation MUST
implement it and it MUST be enabled in the default configuration. If an
algorithm is implemented but disabled in almost every actual
configuration, then REQUIRED won't be of any help for interoperability).

To me, the point of having a REQUIED algorithm is to make it possible to
do a minimalistic implementation cutting off everything optional, and
still be able to interoperate. And implementing three different EC
curves well is not very minimal.

It also seems unfortunate to degrade diffie-hellman-group14-sha1
directly from REQUIRED to OPTIONAL. It would be a nicer rollover to move
it to RECOMMENDED (or RECOMMENDED until some specified date, if that's
possible). And then elevate *one* other algorithm to REQUIRED, where I
think my preference would be for a non-ec dh method, since (1) it's
simpler, and (2) I think it's desirable over the coming years to move
away from the old curves to "safe curves".

If it really is necessary for security, deprecating
diffie-hellman-group14-sha1 asap is the right thing to do. But first,
I'd like to know if sha1 is believed vulnerable in the setting where it
is used, mainly for key expansion. Attacks are a lot easier with input
under the attackers control, but I'm not sure that happens when sha1 is
used in the key exchange. E.g., I'd be surprised if there are any real
issues with using sha1 to expand a *secret* diffie-hellman master key
into several subkeys.

>   b) Is it desirable to specify all of group 14, 15, 16, 17, and 18 as
>      to the hashing algorithm to be used NOW? Or, is it better to drop
>      15 and 17 for now? If so, is it desirable for group14-sha256 to be
>      REQUIRED, RECOMMENDED, or OPTIONAL ?

We probably don't need all of them. I think what's most important is to
have sha256 together with one or two groups with estimated security
corresponding to some 250-300 bits.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.