On Thu, 2015-05-21 at 13:59 +0100, Matthew Vernon wrote: > bits count > 1023 36 > 1535 32 I'd remove at least these completely. > 2047 28 This I'd keep probably only with a warning (according to ECRYPT II it's only safe in the range to aat best 2020-2030 > 3071 26 Still below "Long term protection", according to ECRYPT II > 4095 31 > 6143 20 > 8191 6 More of these! > A colleague reports that generating new 2047-bit moduli takes a few > minutes, and that time taking scales non-linearly with length (~90 > minutes for 4095, ~40 hours for 8191). So I'm not sure if we should > make some newer larger moduli and start shipping them, and/or start > generating some at install time; the latter feels too invasive to me. It shouldn't be a problem if the groups are pre-competed (and thus known to the attacker). > iii) it's less clear what to do about the weaker KexAlgorithms - > diffie-hellman-group1-sha1 uses Oakley Group 2 (1024 bits) and > diffie-hellman-group14-sha1 uses Oakley Group 14 (2048 bits); RFC4253 > says that implementations MUST support these, and I don't know what > clients might break if we were to stop doing so. They should be kept in the client/server, but disabled per default (not via patching the hardcoded defaults, but via a custom ssh[d]_config file). Or even better, they should be disabled upstream per default and enabling them should be only possible when e.g. specifying some "--allow-unsafe-algos" parameter as option to ssh[d]. > I'd be interested to hear the opinions of the other openssh > maintainers, and perhaps we should ask upstream for their views (I've > not seen anything on the upstream dev list as yet). I've did that some months ago and as mentioned before I've even opened bug reports about the related issues,... but there seems to be little willingness to work on this issue. Apparently focus is more on CSH (having a _C_ompatbile SH) than SSH (having a _S_ecure SH)... but that seems to match Debian's security philosophy quite well =) Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature