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

james hughes <> Sun, 22 September 2013 14:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D30D11E80F1 for <>; Sun, 22 Sep 2013 07:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.726
X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=2.478, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9VF7CTpo5omC for <>; Sun, 22 Sep 2013 07:43:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C620011E80E4 for <>; Sun, 22 Sep 2013 07:43:21 -0700 (PDT)
Received: from [] ( []) by (Oracle Communications Messaging Server 7u4-27.08( 64bit (built Aug 22 2013)) with ESMTPSA id <> for; Sun, 22 Sep 2013 14:43:12 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-22_01:2013-09-22, 2013-09-22, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1309220078
References: <> <> <> <>
In-reply-to: <>
MIME-version: 1.0 (1.0)
Content-transfer-encoding: quoted-printable
Content-type: text/plain; charset=utf-8
Message-id: <>
X-Mailer: iPad Mail (11A465)
From: james hughes <>
Date: Sun, 22 Sep 2013 07:41:13 -0700
To: Ralph Holz <>
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 14:43:28 -0000

> On Sep 22, 2013, at 6:04 AM, Ralph Holz <> wrote:
> 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.

A clearer statement in the draft about what the implementation should do would be enabled by the merging of these sections.

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

Parameter negotiation seems to be a reasonable (obvious?) bridge to higher levels of security. The fact that the server (or the client, and even sometime a MITM) can reject these higher key lengths seems to be OK with me, the client can choose that to fail a connection instead of accepting being downgraded. Even if this results in additional round trips, this would be something that people will work at removing.

The following is probably a naïve attempt at a compromise.

To do a better job of "future proofing" the protocol, why aren't we talking about the key length negotiation of ECDHE? Stated differently, why is the key length hard coded at 256 with the curves being negotiated? Isn't that what got us into this mess?

If we want to stay with negotiating the complete cypher suites (which I think is a good thing to avoid ISAKMP style negotiation hell) why not put the key sizes in the suites like we do for AES and SHA?

We can define two new ones 

And create an alias for the existing DHE using 1024 as TLS_DHE1024_RSA1024_GCMAES128_SHA256.

Naming is one of the two hardest things in Computer Science.

Again, I apologize if this is an overly simplistic solution.