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

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 11 Feb 2016 23:49:42 -0800

Hi denis,

Two questions:

  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?

     If so, does the following capture the desired state?
  
Key Exchange Method Name              Reference     Note
diffie-hellman-group-exchange-sha1    RFC4419       NOT RECOMMENDED
diffie-hellman-group-exchange-sha256  RFC4419       OPTIONAL
diffie-hellman-group1-sha1            RFC4253       NOT RECOMMENDED
diffie-hellman-group14-sha1           RFC4253       OPTIONAL
ecdh-sha2-nistp256                    RFC5656       REQUIRED
ecdh-sha2-nistp384                    RFC5656       REQUIRED
ecdh-sha2-nistp521                    RFC5656       REQUIRED
ecdh-sha2-*                           RFC5656       OPTIONAL
ecmqv-sha2                            RFC5656       OPTIONAL
gss-gex-sha1-*                        RFC4462       NOT RECOMMENDED
gss-group1-sha1-*                     RFC4462       NOT RECOMMENDED
gss-group14-sha1-*                    RFC4462       NOT RECOMMENDED
gss-*                                 RFC4462       OPTIONAL
rsa1024-sha1                          RFC4432       NOT RECOMMENDED
rsa2048-sha256                        RFC4432       OPTIONAL
diffie-hellman-group14-sha256         This Draft    OPTIONAL
diffie-hellman-group15-sha256         This Draft    REQUIRED
diffie-hellman-group16-sha512         This Draft    RECOMMENDED
diffie-hellman-group17-sha512         This Draft    OPTIONAL
diffie-hellman-group18-sha512         This Draft    OPTIONAL

Note: I do not know of any rsa2048-sha256 implementations from RFC4432,
I suspect at least someone is using it or it would not be in RFC4432,
who is using it? A similar question for gss-* and RFC4462 comes to mind
as well.

  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 ?

diffie-hellman-group14-sha256         This Draft    RECOMMENDED
diffie-hellman-group16-sha512         This Draft    RECOMMENDED
diffie-hellman-group18-sha512         This Draft    OPTIONAL

Thank you for your consideration.

	-- Mark

---

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

denis bider <[email-masked]> writes:

>If we settle on SHA-256, we run the risk of having to introduce SHA-512
>versions a year or two later.

Why would we need to do that?

Peter.

---

From: [email-masked] (Niels Möller)
Date: Sat, 13 Feb 2016 16:44:17 +0100

>      in the https://www.ietf.org/assignments/ssh-parameters/ssh-parameters.xml

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.

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

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

---

From: denis bider <[email-masked]>
Date: Fri, 12 Feb 2016 07:22:53 +0000

Hey everyone,

I think the draft as-is is more reasonable than the ideas being discussed now.

"NOT RECOMMENDED", being equal in meaning to "SHOULD NOT", seems to me the correct choice for outdated methods, such as "diffie-hellman-group1-sha1". Moving to "MUST NOT" is untenable, and would divorce the spec from reality. These algorithms need to continue to be available in some pockets of deployment, where the only viable alternatives might be no connectivity, or falling back to plaintext FTP.

It seems to me that Peter might have misinterpreted the draft as newly specifying "diffie-hellman-group1-sha1", instead of its actual purpose, which is to demote this. In order to demote a previously defined key exchange method, the draft has to mention it.

The draft does not suggest adding any new SHA-1 based key exchange methods, so I don't think there's much to be discussed about SHA-1 here.

I would prefer to see SHA-512, rather than SHA-256, for group16 and group18. If we settle on SHA-256, we run the risk of having to introduce SHA-512 versions a year or two later. It seems more likely than not that embedded environments will come under pressure to add SHA-512, anyway.

denis

----- Original Message -----
From: Mark D. Baushke 
Sent: Wednesday, February 10, 2016 11:24
To: Peter Gutmann 
Cc: [email-masked] 
Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange) 

Peter Gutmann <[email-masked]> writes:

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

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

---

From: Damien Miller <[email-masked]>
Date: Mon, 15 Feb 2016 18:50:53 +1100 (AEDT)

> diffie-hellman-group18-sha512         This Draft    OPTIONAL

list looks ok to me

>      REQUIRED, RECOMMENDED, or OPTIONAL ?

+1 to dropping the odd-numbered groups and onlist listing group14/16/18