Re: [TLS] New Algorithm identifier for EDH > 1024 bits?

Yoav Nir <ynir@checkpoint.com> Fri, 27 September 2013 13:48 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 E6F5721F9F88 for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 06:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.36
X-Spam-Level:
X-Spam-Status: No, score=-10.36 tagged_above=-999 required=5 tests=[AWL=0.239, 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 b2tcEJ6HYXuS for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 06:48:32 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 307CC11E80F8 for <tls@ietf.org>; Fri, 27 Sep 2013 06:48:28 -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 r8RDmRn6008119; Fri, 27 Sep 2013 16:48:27 +0300
X-CheckPoint: {52458CAB-31-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; Fri, 27 Sep 2013 16:48:27 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "Yngve N. Pettersen" <yngve@spec-work.net>
Thread-Topic: [TLS] New Algorithm identifier for EDH > 1024 bits?
Thread-Index: AQHOusLlwoOMr2hLMkyK9fecAbG0bZnX6AOAgAACgQCAAX47AA==
Date: Fri, 27 Sep 2013 13:48:26 +0000
Message-ID: <36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com>
References: <CAMm+Lwioy8Z+wo7czrOT+5-HOf-G=8X3MF-bEjX2L0uxsXhO8Q@mail.gmail.com> <CALTJjxHeJ8WVuaTfSa5G7xQ1F21VRpYuQ0nDsym8vGL_MOrEVQ@mail.gmail.com> <op.w30xbev03dfyax@killashandra.invalid.invalid>
In-Reply-To: <op.w30xbev03dfyax@killashandra.invalid.invalid>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.136]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3F6F27E4FC308240BBE3824DCE6FDBB0@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] New Algorithm identifier for EDH > 1024 bits?
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: Fri, 27 Sep 2013 13:48:41 -0000

On Sep 26, 2013, at 6:00 PM, Yngve N. Pettersen <yngve@spec-work.net> wrote:

> Hi,
> 
> 
> On Thu, 26 Sep 2013 16:51:43 +0200, Wan-Teh Chang <wtc@google.com> wrote:
> 
>> On Thu, Sep 26, 2013 at 7:15 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>> My understanding of the 1024 bit Ephemeral DH key issue is that it is not
>>> currently possible to use longer keys because a certain number of deployed
>>> Web servers will abort the connection if a client presents a longer key.
>> 
>> The size of ephemeral DH keys is specified by the server, and the
>> client must present a key of that size. (This doesn't change the
>> problem though.)
>> 
>> The client needs a way to negotiate the ephemeral DH key size (or the
>> DH domain parameters) with the server. This can be done by either an
>> extension (similar to the elliptic_curves extension of RFC 4492 for
>> ephemeral ECDH keys) or new cipher suites.
> 
> In my opinion the length of the DHE key should have at least the same length (number of bits) as the signing RSA key. And similar for ECDHE, if necessary.

Not for ECDHE_RSA, though. That would require that we define what ECDHE curve is equivalent to X-bit RSA.

In general I don't like us doing the NIST magic tables of naming equivalent strength key lengths among different algorithms, as in 1024-bit RSA is similar to some non-existing 80-bit perfect symmetric algorithm, and a 1024-bit MODP group is sort of like that.

Yoav