Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

Yaron Sheffer <yaronf.ietf@gmail.com> Sat, 21 September 2013 22:02 UTC

Return-Path: <yaronf.ietf@gmail.com>
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 2994A11E81A3 for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 15:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.415
X-Spam-Level:
X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 j0jrkX76YquT for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 15:02:26 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 607F211E81A2 for <tls@ietf.org>; Sat, 21 Sep 2013 15:02:26 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id n12so1747155wgh.3 for <tls@ietf.org>; Sat, 21 Sep 2013 15:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=IkiS/cWXTRt+FtLvYJ48LxjZhyOgSP+oP7LeQ0GnYxY=; b=zs/7aka9ehgQyL4OAkpbfuOC5yPN5LpkqQZtSx49musbvgj+dRYygzTkB4W+xi6yU2 YKiXjxiDMuu+ohFfaTRmeK5/upY4bosyAIgZ4HX/0zAScXF5PN3TPxCPk2MK3ufbIdLd 1yORgKCToRrqlIkx/HXuJVnAC39sjTgCuDgikzrL9biNX/2OhVpDikkTr8aWSsSk5Gd4 IVgXTQ24RUivOIhahTjeIS1c8P6avjFfUhhmxzFNXuMNuIaHk8UsawPEIl/GJyc8rEoc 3gdCTNZWetiu0yPqS+ly9uzm1qHOnVlFYJKBVpZ58WvVIWZbIqepbXO26EHDhzTpxqv/ Dduw==
X-Received: by 10.180.108.199 with SMTP id hm7mr7687246wib.31.1379800945427; Sat, 21 Sep 2013 15:02:25 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id fz8sm14391404wic.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 15:02:25 -0700 (PDT)
Message-ID: <523E176F.3050304@gmail.com>
Date: Sun, 22 Sep 2013 01:02:23 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
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: Sat, 21 Sep 2013 22:02:27 -0000

Hi Peter,

Thanks for the clarification. Two questions:

- Does any of this brittleness still apply when talking about ECDH (as 
opposed to ECDSA), with fixed parameters?

- Further supporting the brittleness argument... We recently specified 
recipient tests in IKEv2, that apply (and are actually 
security-critical) when either side reuses its DH private key [1]. The 
recipient needs to test that the received point is actually on the 
relevant curve. Are these mandated for ECDHE in TLS? I would have 
expected to see this requirement in [2] (reuse of DH keys is allowed in 
this RFC), but it ain't.

Thanks,
	Yaron

[1] http://tools.ietf.org/html/rfc6989#section-2.3
[2] http://tools.ietf.org/html/rfc4492#section-5.4

On 09/21/2013 11:42 AM, Peter Gutmann wrote:
> Yaron Sheffer <yaronf.ietf@gmail.com>; writes:
>
>> I think we've been through all these arguments (on both sides of the issue)
>> over the last week, with the exception of "ECC brittleness". Can you please
>> clarify what you mean by that?
>
> So with RSA-authenticated DH all you need to do is use a constant-time modexp
> on the server when you sign and pre-encode the PKCS #1 expected result and use
> a constant-time memcmp() on the client when you verify and you're OK.  If you
> did that ten years ago then you're safe against pretty much everything that's
> come along since then.
>
> With ECDLP-based algorithms in contrast there's a whole range of issues you
> need to take into account, the worst of which is the distressing propensity of
> the DLP algorithms to leak the private key if you get even the tiniest detail
> wrong.  Not only do you have to get all of these finicky details exactly
> right, but every now and then someone points out a new issue that you then
> need to retroactively patch into your existing code base.  For example if you
> used the recommended (until not too long ago) way to generate your k for
> (EC)DSA then you'd leak a tiny bit of your private key on each signature
> (again, that nasty propensity of DLP algorithms to leak the private key).
> That's what I meant by ECC, and DLP in general, brittleness.
>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>