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

From: Peter Gutmann <[email-masked]>
Date: Wed, 10 Feb 2016 08:22:32 +0000

Damien Miller <[email-masked]> 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.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 10 Feb 2016 09:24:26 -0800

> infrastructure components.

RFC2119 says that "SHOULD NOT" and "NOT RECOMMENDED" have the same meaning.

To make it stronger would mean moving to "MUST NOT" instead.

Today diffie-hellman-group1-sha1 is "REQUIRED" so I only moved to
"NOT RECOMMENDED/SHOULD NOT" are you suggesting a need to move to
"MUST NOT" here?

Today diffie-hellman-group14-sha1 is "REQUIRED" and is not mentioned. Do
you believe that we should change that one to "OPTIONAL/MAY" and select
a new "REQUIRED" key exchange to avoid SHA-1? If so, which one should
now be "REQUIRED" ?

> In fact same with RECOMMENDED and OPTIONAL, what's wrong with SHOULD

Nothing is wrong with SHOULD or MAY. Per RFC2119:

   * "RECOMMENDED" and "SHOULD" are equivalent

   * "OPTIONAL" and "MAY" are equivalent

   * "MUST" and "REQUIRED" are equivalent

> Those are more widely-used in standards.

I have seen the terms used interchangeably per RFC2119.

> 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.

The terms are supposed to be understood in the context of RFC2119.

Are you speaking of the use of SHA-1 in key exchange only?

There is diffie-hellman-group-exchange-sha1 in RFC4419 which also uses
SHA-1. I presume it is currently an OPTIONAL key exchange. Should we
be moving it to a MUST NOT now too?

I have no strong preference for which of the equivalent terms are used
if it helps make the point better. Does it really make the point better?

> 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 concern for SHA-1 is specified in the Overview nd Rationale
as well as in the Security Considerations section. Where do you
feel it should be noted in addition to those two locations?

> The danger here is is illustrated by the TLS 1.2 RFC:
...elided...

Yes, I think we are currently trying to do the right thing with the
Secure Shell requirements.

I suspect we really do need to have at least one REQUIRED key exchange
mechanism that is common before and after these drafts are published.
Otherwise, we probably need to bump to SSHv3 if we are going to get
rid of all of the MUST NOT algorithms.

Are there any additional thoughts for this draft?

Is it desirable to list out all of the Key Exchange Method names in the
https://www.ietf.org/assignments/ssh-parameters/ssh-parameters.xml table
and their new state?

Key Exchange Method Names

Method Name                           Reference     Note
diffie-hellman-group-exchange-sha1    RFC4419       MUST NOT
diffie-hellman-group-exchange-sha256  RFC4419       MAY
diffie-hellman-group1-sha1            RFC4253       MUST NOT
diffie-hellman-group14-sha1           RFC4253       MAY
ecdh-sha2-nistp256                    RFC5656       MUST
ecdh-sha2-nistp384                    RFC5656       MUST
ecdh-sha2-nistp521                    RFC5656       MUST
ecdh-sha2-*                           RFC5656       Other curves are possible?
ecmqv-sha2                            RFC5656       MAY
gss-gex-sha1-*                        RFC4462       MUST NOT
gss-group1-sha1-*                     RFC4462       MUST NOT
gss-group14-sha1-*                    RFC4462       MUST NOT
gss-*                                 RFC4462       MAY
rsa1024-sha1                          RFC4432       MUST NOT
rsa2048-sha256                        RFC4432       MAY
diffie-hellman-group14-sha256         This Draft    MAY
diffie-hellman-group15-sha256         This Draft    MUST
diffie-hellman-group16-sha512         This Draft    SHOULD
diffie-hellman-group17-sha512         This Draft    MAY
diffie-hellman-group18-sha512         This Draft    MAY

Above I have moved all of the *sha1* exchange methods to MUST NOT
with the exception of diffie-hellman-group14-sha1. Should that one
also be moved to MUST NOT too?

If we want to fix RFC4419 to pass q in addition to g,p so that we are
able to use Lim/Lee primes for q and allow for run-time checking of a g
being a generator of the q-ordered subgroup, does that need to be rolled
into this draft too? What do we want to call this option for negotiation?

Additional comments solicited on these topics.

	Thanks,
	-- Mark

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 12 Feb 2016 13:42:22 +0000

>RFC2119 says that "SHOULD NOT" and "NOT RECOMMENDED" have the same meaning.

This assumes that whoever's reading that knows that 2119 exists, and bothers
reading it.  If you're dealing with an industry standards group doing working
on, say, PLCs for infrastructure control whose primary goal is to find reasons
to avoid changing what they've got now (not that I have any experience with
those or anything...) then they're going to look at "NOT RECOMMENDED" and
decide that it's OK to keep using SHA-1 for the next ten years (literally,
that's the time frames they think in).

>To make it stronger would mean moving to "MUST NOT" instead.

No, just use the SHOULD NOT wording option rather than NOT RECOMMENDED.  Same
for the others, SHOULD rather than RECOMMENDED.

>The terms are supposed to be understood in the context of RFC2119.

See above.  People working on things like SCADA neither know about RFC 2119,
nor care about it if it's pointed out to them.  They'll look at the spec at
hand, take the simplest option in there, and go with that.  "SHA-1 isn't
necessarily recommended but we have legacy considerations so we'll keep using
it forever.  We can consider the other recommendations in the next
standardisation round in 2025 if required".

>I have no strong preference for which of the equivalent terms are used if it
>helps make the point better. Does it really make the point better?

Yes, definitely.  SHOULD NOT is pretty explicit while NOT RECOMMENDED is,
well, something you see in restaurant reviews.

>The concern for SHA-1 is specified in the Overview nd Rationale as well as in
>the Security Considerations section. 

The Overview portion, which is the one that'll get read, mentions "security
concerns with SHA-1", which really doesn't tell you much, almost everything
has security concerns to some degree.  So I'd be good to have the note with
the text I proposed saying something like "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"
somewhere close to the SHOULD NOT -sha1.

Peter.