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

Yoav Nir <ynir@checkpoint.com> Mon, 09 September 2013 06:59 UTC

Return-Path: <ynir@checkpoint.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 21B5E21E8159; Sun, 8 Sep 2013 23:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 9wBBMCqqD5Ve; Sun, 8 Sep 2013 23:59:28 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A7B2D21E8143; Sun, 8 Sep 2013 23:59:27 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r896x18I029156; Mon, 9 Sep 2013 09:59:01 +0300
X-CheckPoint: {522D71B5-6-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Mon, 9 Sep 2013 09:59:01 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Patrick Pelletier <code@funwithsoftware.org>
Thread-Topic: [perpass] [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt
Thread-Index: AQHOrSAT7vhu+KgFPUyyfi4xkQQkepm8x56A
Date: Mon, 9 Sep 2013 06:59:01 +0000
Message-ID: <F11AE80B-E1A1-4868-8C81-AFF533B6E6A9@checkpoint.com>
References: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> <7CBBDAB6-15FF-4EB8-B1D0-CE96B3F8002F@funwithsoftware.org>
In-Reply-To: <7CBBDAB6-15FF-4EB8-B1D0-CE96B3F8002F@funwithsoftware.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.29]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: multipart/alternative; boundary="_000_F11AE80BE1A148688C81AFF533B6E6A9checkpointcom_"
MIME-Version: 1.0
Cc: "<perpass@ietf.org>" <perpass@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] [perpass] 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 06:59:40 -0000

Hi Patrick.

Those tables are mostly quoting NIST publications, so while it seems like there's many sources, they're not really independent.

There are academic results in factoring 768-bit numbers, so with sufficient thrust (and the NSA has more thrust than most academics), it's perfectly logical to suspect that the NSA can factor 1024-bit numbers. That would be a breakage of RSA, not D-H or DSA. There seems to be an assumption behind those tables that the strength of RSA and DSA for the same bit length is about equal. I don't know what this is based on, but then, IANAC.

BTW: If the entire Internet was using 768-bit RSA keying and single-DES encryption, then the NSA could decrypt any connection they wanted, but they would only have the resources to spy on very few people. Even if we used anonymous D-H for TLS, which would allow the NSA to trivially MITM any connection, just having the encryption there means that the same hardware can intercept far fewer connections.

I suspect that with enough TOR traffic scrambled hard enough that you can't decrypt a particular one without decrypting a significant portion of the connections, 1024-bit DHE is plenty strong enough. Sure, upgrading to 2048-bit makes it harder to crack, but the TOR network is already way too slow.

Yoav

On Sep 9, 2013, at 8:46 AM, Patrick Pelletier <code@funwithsoftware.org<mailto:code@funwithsoftware.org>> wrote:

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

Patrick Pelletier <code@funwithsoftware.org<mailto: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

_______________________________________________
perpass mailing list
perpass@ietf.org<mailto:perpass@ietf.org>
https://www.ietf.org/mailman/listinfo/perpass