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

"Yngve N. Pettersen" <yngve@spec-work.net> Thu, 26 September 2013 15:01 UTC

Return-Path: <yngve@spec-work.net>
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 E488D21F9ACA for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 08:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 HJD+8xtVDUeD for <tls@ietfa.amsl.com>; Thu, 26 Sep 2013 08:01:29 -0700 (PDT)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1968021F8F4A for <tls@ietf.org>; Thu, 26 Sep 2013 08:00:52 -0700 (PDT)
Received: from 228.72.202.84.customer.cdi.no ([84.202.72.228]:54511 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <yngve@spec-work.net>) id 1VPD3j-0005cc-5m for tls@ietf.org; Thu, 26 Sep 2013 17:00:51 +0200
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: tls@ietf.org
References: <CAMm+Lwioy8Z+wo7czrOT+5-HOf-G=8X3MF-bEjX2L0uxsXhO8Q@mail.gmail.com> <CALTJjxHeJ8WVuaTfSa5G7xQ1F21VRpYuQ0nDsym8vGL_MOrEVQ@mail.gmail.com>
Date: Thu, 26 Sep 2013 17:00:40 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" <yngve@spec-work.net>
Message-ID: <op.w30xbev03dfyax@killashandra.invalid.invalid>
In-Reply-To: <CALTJjxHeJ8WVuaTfSa5G7xQ1F21VRpYuQ0nDsym8vGL_MOrEVQ@mail.gmail.com>
User-Agent: Opera Mail/12.15 (Win32)
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: Thu, 26 Sep 2013 15:01:44 -0000

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.

Thus, no need to negotiate a length, or incur any delays caused by having  
to generate a new key to match the length requested by the client, or any  
performance problems caused by a client asking for a very long DHE key.

Unfortunately, based on what I have seen, it seems like the DHE keysizes  
are hardcoded in many cases.

> Wan-Teh Chang
>
>
>>
>> Hmmm, wonder who made that decision...
>>
>>
>> Regardless, this is not a problem that will solve itself. Even if  
>> presenting
>> a longer key will cause a connection to abort in 0.1% of cases,  
>> browsers are
>> not going to make the attempt. So if nothing is done the legacy servers  
>> will
>> prevent use of longer DH keys for the next 20+ years.
>>
>> I don't think a TLS version number upgrade is the solution either. It is
>> just a bad idea for an algorithm suite identifier to mean one thing in  
>> TLS
>> 1.2 and another in TLS 1.3.
>>
>>
>> The simple solution to this problem in my view is to specify a new  
>> algorithm
>> suite identifier for DH larger than 1024 and use that in parallel. That
>> might get us to a point where 25% of Web Servers are using very strong  
>> EDH
>> within 12-24 months.
>>
>>
>> --
>> Website: http://hallambaker.com/
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/