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

Patrick Pelletier <code@funwithsoftware.org> Mon, 23 September 2013 04:37 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 9413321F999B for <tls@ietfa.amsl.com>; Sun, 22 Sep 2013 21:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.358
X-Spam-Level:
X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599]
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 Dbu686-i5h-l for <tls@ietfa.amsl.com>; Sun, 22 Sep 2013 21:37:29 -0700 (PDT)
Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id 40FF511E818E for <tls@ietf.org>; Sun, 22 Sep 2013 21:37:25 -0700 (PDT)
Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.48]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 70CBB1EE5084 for <tls@ietf.org>; Mon, 23 Sep 2013 00:37:24 -0400 (EDT)
Received: (qmail 25745 invoked from network); 23 Sep 2013 04:37:24 -0000
Received: by simscan 1.4.0 ppid: 13057, pid: 25134, t: 1.3224s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4
Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender <code@funwithsoftware.org>) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <ynir@checkpoint.com>; 23 Sep 2013 04:37:22 -0000
Message-ID: <523FC581.3090103@funwithsoftware.org>
Date: Sun, 22 Sep 2013 21:37:21 -0700
From: Patrick Pelletier <code@funwithsoftware.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz> <A3161699-0975-403C-B9C1-8BE548062949@mac.com> <523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com>
In-Reply-To: <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "<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: Mon, 23 Sep 2013 04:37:34 -0000

On 9/21/13 9:00 PM, Yoav Nir wrote:

> There's also Apache, the most common web server on the web, that doesn't have configuration parameters for EDH key lengths, and tells OpenSSL to use 1024 bits.

I view the Apache situation as an entirely different thing, since it's 
on the server side, rather than the client side, and the server is the 
one who gets to choose the parameters in the first place.  If the BCP 
says "you should configure your server to use 2048 bits" and the server 
only supports 1024 bits, then the sysadmin will just configure it to use 
1024 bits, and we'll be no worse off than if the BCP had said to use 
1024 bits.  The point is that this doesn't actually break anything.

This is in contrast to the situation where the server picks 2048 bits, 
and the *client* only supports 1024 bits.  In that case, the handshake 
will fail.  So I see the Java (client side) issue as much worse than the 
Apache (server side) issue.

Also, of course, this is easy to fix, since one can recompile Apache to 
support larger DH:

http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html

(Hey, this isn't any worse than suggesting that everyone on Red Hat 
needs to recompile to get ECC support.)

It's also worth pointing out that technically this is an issue with 
mod_ssl, not with Apache itself.  You could always use mod_gnutls instead.

--Patrick