Re: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH)

I think Tero's assessments make sense.

I can provide anecdotal feedback that we still receive questions from users
about "how do I make this connection work?" where the problem is that the
other party supports only diffie-hellman-group1-sha1, and nothing else, so
the algorithm needs to be enabled.

Users SHOULD upgrade, of course, but in practice, many systems appear to be
upgraded at 10-year intervals. I expect we will continue to see occasional
demand for diffie-hellman-group1-sha1 for at least some 5 years. Although
it is off by default, we will be compelled to support it, simply because
despite its shortcomings, it is better than plaintext (by far).

denis

On Mon, Jul 17, 2017 at 10:32 AM, Tero Kivinen <kivinen@iki.fi> wrote:

> Mark D. Baushke writes:
> > > We are defining here a MUST implement and MUST not implement, not MUST
> > > use and MUST NOT use recommendations.
> >
> > For reference, there are five key exchanges that
> > draft-ietf-curdle-ssh-kex-sha2-08 marks as "MUST NOT"
> >
> >           Key Exchange Method Name           Reference  Implement
> >           ---------------------------------- ---------- ---------
> >           diffie-hellman-group1-sha1         RFC4253    MUST NOT
> >           diffie-hellman-group-exchange-sha1 RFC4419    MUST NOT
> >           gss-gex-sha1-*                     RFC4462    MUST NOT
> >           gss-group1-sha1-*                  RFC4462    MUST NOT
> >           rsa1024-sha1                       RFC4432    MUST NOT
> >
> > Of these, only diffie-hellman-group1-sha1 is moving from MUST to MUST
> > NOT. Due to 1024-bit Diffie-Hellman being considered by many as having
> > too little security (the same would be true of gss-group1-sha1-*).
>
> I think diffie-hellman-group1-sha1 is the only one where there is any
> real issues, and only because it used to be mandatory. But of course
> there might be others who want to keep some of the others in their
> codebase too...
>
> > What transition period is desirable for taking group1 "MUST" to "SHOULD
> > NOT" to "MUST NOT" ? Is it possible to codify both "SHOULD NOT" and
> > "MUST NOT" time frames into one RFC?
>
> In IPsec we decided that unless algoritm is really broken (i.e., there
> has been demonstration how it can be broken in public) we keep it
> SHOULD NOT. 786-bit Diffie-Hellman got MUST NOT because it was
> considered broken. The another 1024-bit Diffie-Hellman group which was
> generated so that we cannot be sure it is not backdoored, and which is
> not used at all, also got marked as MUST NOT, but the same group
> 1024-bit group we are talking here was left as SHOULD NOT.
>
> I am not familiar enough about the embedded ssh2 implementations to
> know what they really support, and when we can go forward. In most
> cases where we have been trying to guess when things are going away,
> we have been wrong, so I wouldn't even try to do that, and it is
> better to see what happens, and come back later when we see that those
> algorithms are no longer used ever...
> --
> kivinen@iki.fi
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>