Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

[Yoav Nir <[e-mail]>]

On Sep 21, 2013, at 7:42 PM, Michael D'Errico <[e-mail]> wrote:

> James,
> 
> The problem is that there apparently is lots of TLS code which can only handle
> 1024-bit DH parameters and would break if a server sent larger parameters.
> 
> The idea that 1024 is big enough stems from the fact that many many connections
> don't use DH at all, and would benefit if RSA was replaced by EDH.  Thus an
> attacker would need to break 1024-bit DH for each connection of interest.

Many websites cannot deploy 2048-bit EDH because of limitations in their software, and those who can won't, because of interop issues with many of the browsers that are out there.

OTOH 2048-bit RSA keys work well pretty much everywhere. So we're left with three choices:

 1. 2048-bit RSA keying. That's good security, but no forward secrecy.
 2. 1024-bit EDH, which gives forward secrecy, but may be breakable now or in 5 years.
 3. 256-bit ECDH, which gives forward secrecy, but some people feel uneasy about.

There are good arguments for and against each of these. I don't think we have a measure of whether it's easier to compromise a single RSA private key, or to calculate the DL for several 1024-bit EDH. I don't like how #1 creates an attractive, shiny target for attackers - a single file stolen from a web server, and all the traffic can be decrypted in Wireshark. OTOH assuming that an agency such as the NSA or French equivalent is able to break any 1024-bit EDH (that's not a given) they will be able to decrypt any single connection that they would like, but I don't believe they have the resources to decrypt every one. That's good for people who are not near the top of the list of threats to national security, but kind of not so good for those who are.

As I've said before, I'd rather we chose #3.

Yoav