Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt

Patrick Pelletier <code@funwithsoftware.org> Mon, 09 September 2013 05:47 UTC

Return-Path: <code@funwithsoftware.org>
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 25C3021E809F for <tls@ietfa.amsl.com>; Sun, 8 Sep 2013 22:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001]
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 oXNnmAuQHgtX for <tls@ietfa.amsl.com>; Sun, 8 Sep 2013 22:46:51 -0700 (PDT)
Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id E04A621F9EAD for <tls@ietf.org>; Sun, 8 Sep 2013 22:46:47 -0700 (PDT)
Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.53]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 34D7B1EE4FC4 for <tls@ietf.org>; Mon, 9 Sep 2013 01:46:44 -0400 (EDT)
Received: (qmail 19651 invoked from network); 9 Sep 2013 05:46:43 -0000
Received: by simscan 1.4.0 ppid: 8977, pid: 30391, t: 1.6383s scanners: clamav: 0.88.2/m:52/d:13495 spam: 3.0.4
Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO [192.168.11.2]) (ppelleti@[69.17.96.185]) (envelope-sender <code@funwithsoftware.org>) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for <pgut001@cs.auckland.ac.nz>; 9 Sep 2013 05:46:42 -0000
Message-Id: <7CBBDAB6-15FF-4EB8-B1D0-CE96B3F8002F@funwithsoftware.org>
From: Patrick Pelletier <code@funwithsoftware.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, perpass@ietf.org, tls@ietf.org
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz>
Content-Type: multipart/alternative; boundary=Apple-Mail-15-966441861
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sun, 8 Sep 2013 22:46:40 -0700
References: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz>
X-Mailer: Apple Mail (2.936)
Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt
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: Mon, 09 Sep 2013 05:47:03 -0000

On Sep 8, 2013, at 8:16 PM, Peter Gutmann wrote:

> Patrick Pelletier <code@funwithsoftware.org> writes:
>
>> It seems generally accepted that 1024-bit Diffie-Hellman is no  
>> longer secure,
>
> Really?  DLP != factoring.

I'm an engineer, not a cryptographer, and I don't claim to understand  
the math.  But I've seen statements to that effect here, for example:

http://blog.erratasec.com/2013/09/tor-is-still-dhe-1024-nsa-crackable.html

The IETF's own RFC 3766/BCP 86 indicates that 1024-bit Diffie-Hellman  
would fall in between a 70 and 80 bit symmetric key:

    +-------------+-----------+--------------+--------------+
    | System      |           |              |              |
    | requirement | Symmetric | RSA or DH    | DSA subgroup |
    | for attack  | key size  | modulus size | size         |
    | resistance  | (bits)    | (bits)       | (bits)       |
    | (bits)      |           |              |              |
    +-------------+-----------+--------------+--------------+
    |     70      |     70    |      947     |     129      |
    |     80      |     80    |     1228     |     148      |
    |     90      |     90    |     1553     |     167      |
    |    100      |    100    |     1926     |     186      |
    |    150      |    150    |     4575     |     284      |
    |    200      |    200    |     8719     |     383      |
    |    250      |    250    |    14596     |     482      |
    +-------------+-----------+--------------+--------------+

and other such tables come to similar conclusions.  For example,  
ECRYPT II says a 1248-bit discrete log group only provides protection  
until 2015:

http://www.keylength.com/en/3/

>> How about something along the lines of "Diffie-Hellman parameters  
>> of at least
>> 2048 bits SHOULD be chosen"?
>
> Why at least 2048 bits?  What's wrong with 1280, or 1536, which will  
> be quite
> a lot faster.

It seems like a good ballpark from looking at these tables, but I'm  
certainly not claiming 2048 exactly the right number.  My point was  
merely that the draft should say something about DH group size.  If  
1024 is in fact good enough, then it should say that, rather than  
being silent on the subject.

--Patrick