Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3)

Henrick Hellström <henrick@streamsec.se> Fri, 28 March 2014 01:16 UTC

Return-Path: <henrick@streamsec.se>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46081A078D for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 18:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level:
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9rID5EeZt27 for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 18:16:16 -0700 (PDT)
Received: from vsp3.ballou.se (vsp3.ballou.se [91.189.40.101]) by ietfa.amsl.com (Postfix) with SMTP id 6C35F1A0776 for <tls@ietf.org>; Thu, 27 Mar 2014 18:16:14 -0700 (PDT)
Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp3.ballou.se (Halon Mail Gateway) with ESMTP for <tls@ietf.org>; Fri, 28 Mar 2014 02:13:09 +0100 (CET)
Received: from [192.168.0.195] (c-a2c1e555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.193.162]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 048B115A0A0 for <tls@ietf.org>; Fri, 28 Mar 2014 01:56:25 +0100 (CET)
Message-ID: <5334C8A8.2020906@streamsec.se>
Date: Fri, 28 Mar 2014 01:56:08 +0100
From: =?UTF-8?B?SGVucmljayBIZWxsc3Ryw7Zt?= <henrick@streamsec.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: tls@ietf.org
References: <CABkgnnX=KM4YVf1+znp_HS+Pu6DSw64q1adDC4EOPqRLuTDZKQ@mail.gmail.com> <CACsn0cksap5t0--65gnJt5a2yJCNtzvkDX9mmQR=T_r2xYJjYQ@mail.gmail.com>
In-Reply-To: <CACsn0cksap5t0--65gnJt5a2yJCNtzvkDX9mmQR=T_r2xYJjYQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/heM2pgmXHV4hzDUjX9gcZmULGjA
Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: henrick@streamsec.se
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, 28 Mar 2014 01:16:18 -0000

On 2014-03-28 01:09, Watson Ladd wrote:
> On Thu, Mar 27, 2014 at 8:04 PM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
>> (Renaming the thread, since this is what we seem to be talking about)
>>
>> On 27 March 2014 16:55, Marsh Ray <maray@microsoft.com> wrote:
>>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Alyssa Rowan
>>>>
>>>> Show of hands: who *really* wants to deploy 2048-bit (or above) DHE, when they could have curve25519 instead?
>>>
>>> The general consensus at Microsoft is that we like ECDHE much better than the classic DHE.
>>
>> I think that this is the general trend, but is it so bad that you
>> would want to prohibit DHE?
>
> Well, the DHE handshake has validation issues: implementations aren't
> checking they get sensible inputs.
> Fix that, and maybe you have an argument for keeping it. But as it
> stands now the insecure resumption attacks are exploiting behavior in
> DHE that isn't fixable without a DOS vector being introduced.

Pardon for breaking into the conversation, but isn't the attack outlined 
here https://secure-resumption.com/ actually stopped by the 
renegotiation indication extension, contrary to what the author states 
at the page?

1. At the end of the first handshake, the finished messages of the 
connections C/A and A/S will be different.
2. The outline of the attack rests on the assumption that A might simply 
forward the messages during the second handshake, because all parameters 
are the same, and here the finished messages for C/A and A/S will 
consequently also be the same. Well, they will be if no renegotiation 
indication extension is included. If it is, this will however be 
different for C/A and A/S, and hence result in different finished 
messages after the second handshake as well.

Am I missing something obvious?