Re: [TLS] New Version Notification for draft-bzwu-tls-ecdhe-keyshare-00.txt

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Tue, 28 April 2015 08:17 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 5C3AE1A1A6A for <tls@ietfa.amsl.com>; Tue, 28 Apr 2015 01:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 dkpKiAGS862u for <tls@ietfa.amsl.com>; Tue, 28 Apr 2015 01:17:19 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071C01A1A60 for <tls@ietf.org>; Tue, 28 Apr 2015 01:17:16 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 1E1C9817EE; Tue, 28 Apr 2015 11:17:14 +0300 (EEST)
Date: Tue, 28 Apr 2015 11:17:13 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: =?utf-8?B?5q2m54Kz5q2jKOWFgeS4rSk=?= <bingzheng.wbz@alibaba-inc.com>
Message-ID: <20150428081713.GA10271@LK-Perkele-VII>
References: <20150427023926.28938.22369.idtracker@ietfa.amsl.com> <008e01d080e5$a2db6de0$e89249a0$@alibaba-inc.com> <20150427173533.GA910@LK-Perkele-VII> <001c01d0815e$783cbde0$68b639a0$@alibaba-inc.com> <20150428045440.GA7907@LK-Perkele-VII> <004c01d0817e$55580a80$00081f80$@alibaba-inc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <004c01d0817e$55580a80$00081f80$@alibaba-inc.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/TjXZ3N3MKK3pJB19cdjGJjaXOSU>
Cc: tls@ietf.org
Subject: Re: [TLS] New Version Notification for draft-bzwu-tls-ecdhe-keyshare-00.txt
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: Tue, 28 Apr 2015 08:17:21 -0000

On Tue, Apr 28, 2015 at 02:41:18PM +0800, 武炳正(允中) wrote:
> 
> > 
> > Also, I consider using non-named groups to bring more security problems than
> > it is worth (e.g. currently known ways to exploit THS for (EC)DHE rely on those).
> 
> This extension aims to reduce the handshake's latency only.
> I think it's more clear that this extension behaves the same as normal handshake, both for SSL library's developer and web server administrator.
> If someone thinks non-named curve is not safe, he should find a way to disable it for normal handshake;
> and this extension will not use non-named curves then.
> 
> For example, a web server administrator may prefer the instructions that "non-named curve is not safe. disable it in configure file",
>  than " non-named curve is not safe. but there is an extension which disable it automatically. However you still need to disable it in configure file".

Actually, I think I figured out a nasty exploit.

By choosing a suitable curve (assuming both server and client accept
it), one can ECDL the server's exchange key and thus impersonate the
server. Extended_master_secret will not save you.

This exploit won't work with named groups (even without key order
check). This is because client's premaster secret is too hard to
compute.

Also, TLS 1.3 server auth is different, so the same exploit won't
work there either (even if it allowed non-named groups, which it
doesn't).


-Ilari