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

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

Damien Miller <djm%mindrot.org@localhost> writes:

>So my recommendation would be:
>
>diffie-hellman-group1-sha1        NOT RECOMMENDED
>diffie-hellman-group14-sha256     RECOMMENDED
>diffie-hellman-group16-sha512     RECOMMENDED
>diffie-hellman-group18-sha512     OPTIONAL
>
>(but 16+256 & 18+512 would be fine too)

>From an embedded perspective (which is what triggered this late reply) I'd
prefer the -256's over the -512's, the less extra huge hash functions I have
to include code for the better.  I'd also like to see SHA-1 just die, there's
no reason to specify it in a new spec published in 2016.  Having said that I
realise that there are other profiles that still specify SHA-1, but then I'd
like to at least see the wording given as "SHOULD NOT" rather than "NOT
RECOMMENDED".  The latter is for restaurants, not security-critical
infrastructure components.

In fact same with RECOMMENDED and OPTIONAL, what's wrong with SHOULD and MAY?
Those are more widely-used in standards.  In particular I'd like to be able to
point to SHA-1 as SHOULD NOT (which is pretty unambiguous) rather than NOT
RECOMMENDED, which seems to say that people can keep on using it for as long
as they like.

It'd also be good to include a note, where the groups are defined not down in
the security considerations, saying that the SHA-1 option is provided for
backwards compatibility, shouldn't be used in new designs, and should be
phased out of existing ones as quickly as possible because it's not secure.
The danger here is is illustrated by the TLS 1.2 RFC:

  Support for the SSLv2 backward-compatible hello is now a MAY, not a SHOULD,
  with sending it a SHOULD NOT.  Support will probably become a SHOULD NOT in
  the future.

That's for a protocol that was known to be insecure thirteen years earlier.
In fact all previous versions of TLS said:

 Warning: The ability to send Version 2.0 client hello messages will be
          phased out with all due haste. Implementors should make every
          effort to move forward as quickly as possible. Version 3.0
          provides better mechanisms for moving to newer versions.

Thats from TLS 1.1 in 2006, so they'd spent more than a decade phasing it out
with all due haste.

The point is that without text in the spec that implementers can point to
saying "if you're still using SHA-1, your product is broken" then it's going
to hang around forever, as the TLS experience has shown.

Still, as long as the draft doesn't decide to reintroduce support for MD5,
like TLS 1.2 did...

Peter.