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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 24 September 2013 04:45 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 795A521F9385 for <tls@ietfa.amsl.com>; Mon, 23 Sep 2013 21:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level:
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 LpRdk6ST5iVu for <tls@ietfa.amsl.com>; Mon, 23 Sep 2013 21:45:36 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3C121F8D90 for <tls@ietf.org>; Mon, 23 Sep 2013 21:45:33 -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=1379997935; x=1411533935; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=t1PiqpYD2k/L70WuBFfU223NsF5f5UqixbVL6dDujCc=; b=Hf1Zraby/WV6q1f1QLSjZeEzy/bw11xuTFF1BVNqy3tPchJew8Epcq2L c+drdOoAg+lRcvRuq3SCS/ySMclWNj7qWi4pF4PEX3nTI5q8neV8ptM8/ 2mjcyETXXP162l2wxEhG4blgAlM6Z+y481NmkbHUYejuA3q4bf2NYvaWL k=;
X-IronPort-AV: E=Sophos;i="4.90,968,1371038400"; d="scan'208";a="213846775"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 24 Sep 2013 16:45:32 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 16:45:31 +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: Ac644OZtN2dnW93GRayVY4eMNcQBdA==
Date: Tue, 24 Sep 2013 04:45:31 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355676085@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: Tue, 24 Sep 2013 04:45:44 -0000

Yaron Sheffer <yaronf.ietf@gmail.com> writes:

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

Probably not, in terms of brittleness.  But then if you're using fixed ECDH
parameters (rather than, say, regenerating them once an hour and discarding
the old ones) you've got potentially NSA-influenced values like P256 that the
NSA has been awfully keen to get everyone to use, and that even without NSA
skullduggery make a nice single target for attack.  So that's an entirely
different problem.

If you do want to generate your own ECDH parameters (i.e. curves), that's
another huge mess to deal with.  For DH you just use Lim-Lee and you're done
(although the fact that TLS doesn't communicate the 'q' value is something I'd
really like to see corrected), while for ECC you need to get an awful lot of
special-case checks and conditions just right.

Then, once you've done that, you get to find out how many implementations
support the arbitrary_explicit_prime_curves format, which I suspect is pretty
close to zero.

Peter.