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

Yoav Nir <ynir@checkpoint.com> Sun, 22 September 2013 04:00 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 43D1411E81FF for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 21:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.347
X-Spam-Level:
X-Spam-Status: No, score=-10.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 h0EyBR1t+teY for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 21:00:10 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EE11611E80D7 for <tls@ietf.org>; Sat, 21 Sep 2013 21:00:09 -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 r8M403W9019934; Sun, 22 Sep 2013 07:00:03 +0300
X-CheckPoint: {523E6B43-7-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Sun, 22 Sep 2013 07:00:01 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Patrick Pelletier <code@funwithsoftware.org>
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac61Hnof5dKKYJ0xmEuWRIX4Ztx5/QBYDy2AABRpPoAADr+CAAAI7iMA
Date: Sun, 22 Sep 2013 04:00:02 +0000
Message-ID: <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@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>
In-Reply-To: <523E2F56.9040307@funwithsoftware.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.24.204]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4DC508EB7CFE634EA033FBD09EAAAD18@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: Sun, 22 Sep 2013 04:00:16 -0000

On Sep 22, 2013, at 2:44 AM, Patrick Pelletier <code@funwithsoftware.org>; wrote:

> On 9/21/13 9:42 AM, Michael D'Errico wrote:
> 
>> The problem is that there apparently is lots of TLS code which can only
>> handle
>> 1024-bit DH parameters and would break if a server sent larger parameters.
> 
> Doesn't this "lots of TLS code" boil down to just Java?  That's the only implementation I've heard of that supports DHE_RSA but chokes on 2048 DH.  Is there another?

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.

> My understanding of the Windows (SChannel) situation is that Windows has a limit of 1024 for DHE_DSS, but doesn't support DHE_RSA at all. Although it's unfortunate in some ways that it doesn't support DHE_RSA, it's actually a good thing in disguise, since it means that the cipher suite negotiation will take care of the problem.
> 
>> Remember that this is an Engineering group (the "E" in IETF) which has
>> to keep
>> the Internet working while we attempt to improve security for everyone.
>> If we
>> knew how to move to 2048 bits without breaking anything we would.
> 
> We *do* know how to move to 2048 bits without breaking anything: add an extension to negotiate DH size, just like how ECC curves are negotiated.  Although yes, this will take a while to deploy universally, it at least means early adopters can start using 2048 now, without breaking the stragglers like Java.

Perhaps it would be better to have the client suggest the actual group rather than bit length in that case. Perhaps we could reuse the IKE numbering of groups, or else have the client specify it similar to ServerDHParams struct.

> (I'd rather just leave Java in the dust and switch to 2048 now.  But if we really want to avoid breaking Java, this is how to do it.)

There's lots of Java code out there, and servers have no control over what clients access them. Unfortunately, people tend to stay with old JVMs for a long time.

Yoav