Re: [TLS] draft-gutmann-tls-eccsuites

Peter Gutmann <> Tue, 08 July 2014 11:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BE0581B280E for <>; Tue, 8 Jul 2014 04:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qMtnQYv2VNDc for <>; Tue, 8 Jul 2014 04:55:34 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 962A91B2810 for <>; Tue, 8 Jul 2014 04:55:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=uoa; t=1404820534; x=1436356534; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=dG/436z/qDG3mb8uyME2lX6Tn0T2s2p73TZrbJYfSi4=; b=k8rcZHNfECAWaa4WciObzhxGMDg/Z04EetWZglB813Sd+uHlGe/ZteUE iTrnxI5xxXZwbX/MzbpVSyiPBO4qoeqiIKEBK0DAQKEnpQMELJV3Kqt5p U3HiU+DOUuPkcDH9QggESweWCf38ylImUoc30SQTKT6O6ds+mhppTFtF3 0=;
X-IronPort-AV: E=Sophos;i="5.01,625,1399982400"; d="scan'208";a="262568374"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 08 Jul 2014 23:55:32 +1200
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Tue, 8 Jul 2014 23:55:31 +1200
From: Peter Gutmann <>
To: "<>" <>
Thread-Topic: [TLS] draft-gutmann-tls-eccsuites
Thread-Index: Ac+ao4SLCSsYr4f8TkevRphBmdYRTQ==
Date: Tue, 8 Jul 2014 11:55:31 +0000
Message-ID: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] draft-gutmann-tls-eccsuites
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Jul 2014 11:55:41 -0000

Henrik Grubbström <> writes:

>Have you considered the following note in RFC 4492 section 5.1?
>| NOTE: A server participating in an ECDHE-ECDSA key exchange may use different
>| curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral ECDH key in the
>| ServerKeyExchange message. The server must consider the extensions in both cases.
>As I read the above, your suites would default to imply extra restrictions on
>the possible server certificates, as you would be restricted to only the same
>curve as in the suite (eg you wouldn't be able to use a SECP521 cert with
>TLS_ECDHE_ECDSA_P384_SHA384_WITH_AES_256_GCM_SHA384, as the server wouldn't
>know if the client was capable of verifying the cert).

Yep, and that's a feature, not a bug.  The ambiguity over what's what is one
of the (numerous) problems with the current use of ECC in TLS, the eccsuites
draft nails it down to a single, unambiguous choice (currently this is done
implicitly by implementations following set of de facto "profiles" as
described in the draft, but the draft makes this explicit).

(It could also be argued that using a P256 cert with a P521 curve, or vice
versa, or some similar combination doesn't make much sense, why authenticate a
521-bit keyex with only a 256-bit signature?).

>Or is the intent of the draft that the server just should select a cert and
>hope for the best?

The intent is that the security of the curve used for keyex match the curve
used in the cert, and that there's just a single unambiguous choice for that.