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

james hughes <hughejp@mac.com> Sat, 21 September 2013 06:57 UTC

Return-Path: <hughejp@mac.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DA211E810D for <tls@ietfa.amsl.com>; Fri, 20 Sep 2013 23:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.248
X-Spam-Level:
X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BsYAYqmG4bR for <tls@ietfa.amsl.com>; Fri, 20 Sep 2013 23:57:47 -0700 (PDT)
Received: from st11p06mm-asmtp001.mac.com (st11p06mm-asmtpout004.mac.com [17.172.124.249]) by ietfa.amsl.com (Postfix) with ESMTP id B0D5D11E8115 for <tls@ietf.org>; Fri, 20 Sep 2013 23:57:44 -0700 (PDT)
Received: from [10.0.1.9] (209-82-80-116.dedicated.allstream.net [209.82.80.116]) by st11p06mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MTG00LJMRC40C00@st11p06mm-asmtp001.mac.com> for tls@ietf.org; Sat, 21 Sep 2013 06:57:42 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-21_01:2013-09-20, 2013-09-21, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1309200188
Content-type: text/plain; charset=us-ascii
MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: james hughes <hughejp@mac.com>
In-reply-to: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>
Date: Fri, 20 Sep 2013 23:57:39 -0700
Content-transfer-encoding: quoted-printable
Message-id: <A3161699-0975-403C-B9C1-8BE548062949@mac.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
X-Mailer: Apple Mail (2.1510)
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Sep 2013 06:57:52 -0000

On Sep 19, 2013, at 2:56 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz>; wrote:

> "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>; 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?