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

Michael D'Errico <> Sat, 21 September 2013 16:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A6FB11E8132 for <>; Sat, 21 Sep 2013 09:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, SARE_OBFU_ALL=0.751]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rBCx4J6Ycqtq for <>; Sat, 21 Sep 2013 09:42:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B6F8B21F9C53 for <>; Sat, 21 Sep 2013 09:42:10 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 5F51ED37F; Sat, 21 Sep 2013 12:42:08 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=n8nHUsUHt7Kg q7wmrRe82NpgOh8=; b=I1l17e85ZKh7joDFNqaJ/gBP5Ll0x3dHpyqb42uH4yxN AV7aaxZyIA8F1gkuGnkQE7TYFYt1tp6zbEmoM/y6oGAqqPg4mgDbvHhXC380RuqY r7dPpIJzMoMxRGHAkXAwImH1JMv93CNoXB42/CIPYhdDvNzQq01qj2jdg7ZR+o8=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=DAN89x Bnphq5b4YTxMS4XxV8SctG4E7OLdl3dTa07i0OemNMNN1von1uc4+T2ypexcHg+O fbhTvhSk9pcsTb7uZRXMQhjnuqhrm3LIRU6v6IQ9l8r8gWuVIjIXzkM9j9iXuJUF 1zGFQ0HZxB9EyKLXCn/27pb/AC45C1AFq4ffY=
Received: from (unknown []) by (Postfix) with ESMTP id 4FC27D375; Sat, 21 Sep 2013 12:42:08 -0400 (EDT)
Received: from iMac.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 66A02D373; Sat, 21 Sep 2013 12:42:07 -0400 (EDT)
Message-ID: <>
Date: Sat, 21 Sep 2013 09:42:05 -0700
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: james hughes <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: C0F71E68-22DC-11E3-AD32-CE710E5B5709-38729857!
Cc: " \(\)" <>
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Sep 2013 16:42:16 -0000


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.


james hughes wrote:
> On Sep 19, 2013, at 2:56 AM, Peter Gutmann <> wrote:
>> "Blumenthal, Uri - 0558 - MITLL" <> 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 []. 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]?
> 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?