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

Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> Fri, 28 March 2014 06:38 UTC

Return-Path: <karthik.bhargavan@gmail.com>
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 549E01A0462 for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 23:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.982
X-Spam-Level:
X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 ymQMoOCpjxA4 for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 23:38:51 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 120E81A0468 for <tls@ietf.org>; Thu, 27 Mar 2014 23:38:50 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.97,749,1389740400"; d="scan'208,217"; a="65115271"
Received: from 147.47.192.77.rev.sfr.net (HELO [192.168.1.44]) ([77.192.47.147]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 28 Mar 2014 07:38:48 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_8004C28B-CD0A-4CD8-A96B-7F9E8E7CCC5D"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
In-Reply-To: <5334C8A8.2020906@streamsec.se>
Date: Fri, 28 Mar 2014 07:38:47 +0100
Message-Id: <C3A58B39-69DE-4AF9-99F5-41169886F87A@gmail.com>
References: <CABkgnnX=KM4YVf1+znp_HS+Pu6DSw64q1adDC4EOPqRLuTDZKQ@mail.gmail.com> <CACsn0cksap5t0--65gnJt5a2yJCNtzvkDX9mmQR=T_r2xYJjYQ@mail.gmail.com> <5334C8A8.2020906@streamsec.se>
To: henrick@streamsec.se
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/po4o2phLLeRku3P6XHthFEx4vFI
Cc: tls@ietf.org
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
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 06:38:53 -0000

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

In regard to DHE validation, one answer (already proposed on this thread) is to use well-known named groups, instead of arbitrary groups. So, rather than banning DHE, we could standardise named groups (like named curves) and ban the use of arbitrary groups (and arbitrary explicit curves).

Still, public key validation remains important for both ECDHE and DHE, and essential to prevent insecure resumption-like attacks.

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

Yes, which is why the attack requires 3 handshakes not two. By injecting a resumption handshake between 1. and 2. above, the finished messages of C/A and A/S can be made the same. I’d be happy to discuss off-list.

Best,
Karthik


> 
> Am I missing something obvious?
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls