Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sat, 29 March 2014 01:22 UTC

Return-Path: <dkg@fifthhorseman.net>
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 11EC51A076A for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 18:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JJPJv6Pc_g52 for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 18:22:33 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 563DF1A075A for <tls@ietf.org>; Fri, 28 Mar 2014 18:22:33 -0700 (PDT)
Received: from [192.168.13.159] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 5A4C3F984; Fri, 28 Mar 2014 21:22:29 -0400 (EDT)
Message-ID: <53362055.3050304@fifthhorseman.net>
Date: Fri, 28 Mar 2014 21:22:29 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0
MIME-Version: 1.0
To: Santosh Chokhani <SChokhani@cygnacom.com>, "mrex@sap.com" <mrex@sap.com>, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
References: <AD51D38F-2CFE-4277-854D-C0E56292A336@cisco.com> <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <4262AC0DB9856847A2D00EF817E81139174CF2@scygexch10.cygnacom.com>
In-Reply-To: <4262AC0DB9856847A2D00EF817E81139174CF2@scygexch10.cygnacom.com>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="KiNFagDW53QJ6ouSsw3hE7eTgUiisKCHp"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RaPV4PPKvPu4akVffNdpgoiLTd4
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 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: Sat, 29 Mar 2014 01:22:35 -0000

On 03/26/2014 07:25 PM, Santosh Chokhani wrote:

> While I agree with most of what you say including some benefits of RSA, the DHE parameter verification by the client while desirable is not a genuine security threat.  A rogue server has many other ways to compromise the exchange,

The recent https://secure-resumption.com/ showed that one malicious
server (which a victim deliberately connects to) could use a weak
discrete log DHE group to force a client doing client-cert
authentication into signing a pre-master secret of the server operator's
choice.

The malicious server operator could then replay that pre-master secret
to another server (in a non-DHE ciphersuite), creating two sessions with
the same session id, master secret, and connection keys (they call this
an "Unknown key share attack" or UKS).

They didn't find a way to exploit a UKS directly without taking
advantage of other flaws in the TLS protocol, but if the option of using
a bad group hadn't been there, clients using DHE ciphersuites would have
been resistant to the attacks they did find.

So permitting the use of an arbitrary DL DH group whose structure is too
expensive for the client to verify is something we should try to avoid.

	--dkg