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

[Tero Kivinen <[e-mail]>]

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...
-- 
[e-mail]