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

Yoav Nir <ynir@checkpoint.com> Mon, 23 September 2013 05:22 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 531D811E8186 for <tls@ietfa.amsl.com>; Sun, 22 Sep 2013 22:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.355
X-Spam-Level:
X-Spam-Status: No, score=-10.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, 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 q5W-qGbwBenn for <tls@ietfa.amsl.com>; Sun, 22 Sep 2013 22:22:00 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D3AB411E80D7 for <tls@ietf.org>; Sun, 22 Sep 2013 22:21:59 -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 r8N5Lr4a011397; Mon, 23 Sep 2013 08:21:54 +0300
X-CheckPoint: {523FCFF1-F-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Mon, 23 Sep 2013 08:21:53 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Patrick Pelletier <code@funwithsoftware.org>
Thread-Topic: draft-sheffer-tls-bcp: DH recommendations
Thread-Index: AQHOuBaedQwzN3MPlUCJDzO8Os+PB5nSlycA
Date: Mon, 23 Sep 2013 05:21:53 +0000
Message-ID: <83FC5008-BB1A-4CC9-9DB5-4F14CF52FA06@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> <523FC581.3090103@funwithsoftware.org>
In-Reply-To: <523FC581.3090103@funwithsoftware.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.24.139]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <5F80E6B39083B6478A39ED025D00F5E9@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 05:22:05 -0000

On Sep 23, 2013, at 7:37 AM, Patrick Pelletier <code@funwithsoftware.org>; wrote:

> 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.

Some people are suggesting that clients break the connection if offered a 1024-bit group. It does make sense that they would break the connection if offered, say, a 512-bit group, no?

> 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.)

No, it's different asking a vendor to change something vs asking end users to recompile Apache.

> 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.

You can, but then hardly anyone does.

Yoav