dh1024 should not be marked bad.

[wolfbeast]

1024-bit DH primes are fine. You should not mark clients that accept 1024-bit DH primes as "bad".

See also weakdh.org:

If you’re a sysadmin or developer …

Make sure any TLS libraries you use are up-to-date, that servers you maintain use 2048-bit or larger primes, and that clients you maintain reject Diffie-Hellman primes smaller than 1024-bit.

It clearly says "smaller than" not "smaller than or equal to". Smaller than is also the concensus as to where the safe edge should be placed. 1023 and smaller is bad, 1024 and larger is good.

[roycewilliams]

weakdh.org also says:

We further estimate that an academic team can break a 768-bit prime and that a nation-state can break a 1024-bit prime.

Since users' risk model can vary, in my opinion 1024-bit primes should continue to be considered bad.

[alex]

It's also worth noting that key-exchange strength is important forever. An attacker who records traffic now can simply wait until discrete logarithm is cheaper. Therefore the key exchange must not only be strong today, it has to be strong tomorrow as well. 1024-bit FFDH completely fails to meet this standard and should be purged.

[roycewilliams]

Agreed with @alex. And NIST is aware of this, and now considers 80-bit-equivalent such as 1024 to be allowable for legacy use only.

Source: search for "1024" here.

[wolfbeast]

Then place it under "legacy"?

I'm well aware that these keys should be considered weak. I'm also saying that clients should still support them because a good percentage of the servers out there can't upgrade to stronger DH keys (yet) for various reasons.

If you want to consider everything that is not "strong tomorrow" then you may as well mark everything red we have today. The site should be a reflection of today. If 3DES is still considered legacy and [OK], then 1024DH should be classified similarly (for clients, not for servers). Perhaps not "OK" but not under "not secure" for client support, at any rate. Use yellow instead of red, and label it WEAK, or something.

PS: "Waiting until non-FS algorithms become cheap enough" isn't really an argument -- data recovered years from now will likely be a lot less relevant than what can be decrypted that is used today.

[roycewilliams]

For the data itself, tomorrow is today.

Someone can capture your traffic today, and crack it five years from now.

[wolfbeast]

I repeat; "Waiting until non-FS algorithms become cheap enough" isn't really an argument -- data recovered years from now will likely be a lot less relevant than what can be decrypted that is used today.

If you want to be that pro-future, then like I said you should mark just about everything red. Do you know the future? Can you predict what crypto breakthroughs are going to be there? Or do you just want to be able to say "your browser isn't as secure as ours because arbitrary reason based on guesswork"? I'm guessing Chromium doesn't accept DH1024 any longer? I'm guessing what you test happens to exactly coincide with the exact limits of Chromium? Please.

[lgarron]

I don't have new reasons to add, but based on weakdh.org and arguments presented in this thread, 1024-bit DH was intentionally marked as bad and should remain so.

Some browsers haven't quite removed it yet, but unlike, say, CBC, it should not be sticking around for "legacy" purposes very long.