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

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

Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> writes:

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

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
> and MAY? 

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