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

Ralph Holz <> Sun, 22 September 2013 13:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D81B21F9FF0 for <>; Sun, 22 Sep 2013 06:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lL1OYjzu7Ina for <>; Sun, 22 Sep 2013 06:03:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1538C21F9FBF for <>; Sun, 22 Sep 2013 06:03:10 -0700 (PDT)
Received: by (Postfix, from userid 5001) id 6FCE0809FB; Sun, 22 Sep 2013 15:03:09 +0200 (CEST)
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A00B1809A5; Sun, 22 Sep 2013 15:03:07 +0200 (CEST)
Message-ID: <>
Date: Sun, 22 Sep 2013 15:04:02 +0200
From: Ralph Holz <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Michael_Str=F6der?= <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.8 at ex6
X-Virus-Status: Clean
Cc: " \(\)" <>
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: Sun, 22 Sep 2013 13:03:15 -0000

Hi Michael, all,

> But the problem in the context of draft-sheffer-tls-bcp is that existing
> implementations do not support D-H key size of 2048 bits. And the author(s) of

This is not true. DHE-1024 is the second option in the draft, but 2nd
and 3rd option are described in 4.4, not 4.1. I agree with Stephen
Farell that 4.1 and 4.4 should be merged.

It seems a certain consensus has been reached concerning what can be
easily deployed and what is supported by OS. ECDHE and DHE-1024 seem to
be roughly on the same level, with different problems of their own,
while DHE-2048 is hard to deploy. And we do not want RSA without PFS.

The remaining question, in my opinion, is only whether
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 should be the only "best practice"
or whether TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 should be mentioned as an
equivalent alternative.

I am still undecided on this issue. Heninger et al. have shown last year
what can happen if you have poor entropy in your devices, and they also
gave advice that programmers should not use the non-blocking RNG on
Linux devices. Won't keep programmers from doing it. Similarly, I remain
doubtful about EC implementations.


Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
Phone +
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF