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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 21 September 2013 08:42 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 46B1F21F9F31 for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 01:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level:
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599]
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 1NNG+E1+5Hyp for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 01:42:15 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id B4A1921F9F23 for <tls@ietf.org>; Sat, 21 Sep 2013 01:42:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379752935; x=1411288935; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=NOzA+a3hW/N1WP3Qfl8ki9PEVpCAQqmcOapUb5mjfXo=; b=UcAl8AOVMhCQM5XXR4FX4B2mQUhP7331WLjRjOmkRIAgQwgQkUzJTbAw kvQLziJPFV7NHJg3c508jJH8jNol0APintNMoHiJKsobP20Ft7GVG+RKN W5npTE1LBVR/Xw6wWo35Hap+UvAcT9Gf5VIf/pody6uQUIjxKFWmKHGPa s=;
X-IronPort-AV: E=Sophos;i="4.90,951,1371038400"; d="scan'208";a="213315268"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Sep 2013 20:42:11 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.02.0318.004; Sat, 21 Sep 2013 20:42:10 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac62pnXrb7/i0DxYQ4+uyNbGLzUQnQ==
Date: Sat, 21 Sep 2013 08:42:09 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 08:42:20 -0000

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.