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

Patrick Pelletier <> Sat, 21 September 2013 23:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CAE1321F9468 for <>; Sat, 21 Sep 2013 16:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.353
X-Spam-Status: No, score=-1.353 tagged_above=-999 required=5 tests=[AWL=-1.168, BAYES_40=-0.185]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KZEcMFOZkx9h for <>; Sat, 21 Sep 2013 16:44:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2E27921F90A7 for <>; Sat, 21 Sep 2013 16:44:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E1FA61EE50A3 for <>; Sat, 21 Sep 2013 19:44:31 -0400 (EDT)
Received: (qmail 29200 invoked from network); 21 Sep 2013 23:44:31 -0000
Received: by simscan 1.4.0 ppid: 2509, pid: 31350, t: 0.3914s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4
Received: from (HELO PatrickMBP.local) (ppelleti@[]) (envelope-sender <>) by (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <>; 21 Sep 2013 23:44:31 -0000
Message-ID: <>
Date: Sat, 21 Sep 2013 16:44:22 -0700
From: Patrick Pelletier <>
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
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Sep 2013 23:45:15 -0000

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?

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.

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