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

[Michael D'Errico <[e-mail]>]

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.

Remember that this is an Engineering group (the "E" in IETF) which has to keep
the Internet working while we attempt to improve security for everyone.  If we
knew how to move to 2048 bits without breaking anything we would.

Mike



james hughes wrote:
> On Sep 19, 2013, at 2:56 AM, Peter Gutmann <[e-mail]> wrote:
> 
>> "Blumenthal, Uri - 0558 - MITLL" <[e-mail]> writes:
>>
>>> I personally think that for *ephemeral* DH even 1024 bits still is enough.
>>> And would *much* prefer having PFS now with individual session keys at
>>> somewhat greater risk, over a system that is very secure and completely
>>> useless because nobody bothered to deploy it.
>> Exactly.  We don't need theoretically perfect security in ten years when we've
>> finished arguing about it and have upgraded every system on the planet to
>> support it, we just need good enough right now.  That's DH-1024, and when we
>> have that turned on everywhere we've got some breathing space to worry about
>> what to do next.
> 
> 
> "theoretically perfect security in ten years", really? You think that 1024 is "good enough"? I do not know a single reputable source that says 1024 bit is "secure" (outside the people on this list). Not even NIST. If you are going to step forward for PFS, do it right. Raise the D-H key size to 2048. 2048 bit is required now and will give you security for only 7 years (Thank you France). 
> 
> What is wrong with having a a reasonable amount padding between what is known to be vulnerable and what is known to be secure, especially when the cost is an extra 2 milliseconds of CPU?
> 
> <rant>
> It seems like the members of this list are saying 1024 is enough. Why? What is their science? Where is their proof? Repeatedly saying "We don't need theoretically perfect security" is a proof by assertion [http://en.wikipedia.org/wiki/Proof_by_assertion] The French equivelant of NSA (number 2 in the world?) is quite capable and this is their recommendation is 2048 NOW. Clearly, the TLS standards community must be smarter to say so unequivocally that 1024 is "enough".
> 
> This sounds a lot like the same arguments that were given to the cryptographers arguing against using MD5 by certificate authorities after a collision was found.
> 
> Why does the burden of proof seem to be so high on the cryptographers to prove that an algorithm (or key size) is not secure enough? Stated differently, why must crypto community, who knows something is, or will soon be, breakable have to shame the standards bodies into reasonable action with a pie in the face  [for the non-english speakers, for a definition of "pie in the face" see http://en.wikipedia.org/wiki/Pieing]?
> 
> Maybe the assumption is that the Cryptanalysists are lunatics and we are better off ignoring them. I get that, but Is this the best thing for the internet?
> </rant>
> 
> Why not a 2048 Diffie Hellman exchange? Why not even allow it to be an option?