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

Henrik Grubbström <> Mon, 07 July 2014 17:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 91B401A0377 for <>; Mon, 7 Jul 2014 10:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QjtIkiOFDjj4 for <>; Mon, 7 Jul 2014 10:30:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED12E1A040D for <>; Mon, 7 Jul 2014 10:30:02 -0700 (PDT)
Received: by with SMTP id c11so3129793lbj.17 for <>; Mon, 07 Jul 2014 10:30:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=2N68rG3s28IXjzB76Qh88sc0JerITpo7Brwng2+uFqU=; b=Abme7LBY37PFOddm6a1fGIjtcNhDYR8v0mHuTDdsFBqJNq9IG1XtS7Ni5pg2mNwLPr pQK6cpZvnhssGLUbob264w8lhq6n6I1b0f03zAjK0Wgu4OUqAZZ/omd2PAfVWw2GyrSO 6NzaMQ8sl/C2P2kKqZgc5uh00Hq7Ql0uL20GIp/8f+GUakk8YDx8nGUqLyYA1EPnzX+o aKuaXIZYb8eH9h2MQi+Z4tKUL0BdUelMNfcKTGA6QImvDSILynP1nC6L9i93AWX36BIn U8S/VfijgVGdoEF2aiaqhRRw6GOxFamQgDveH/wOxzSIwzAJOLKo6Dx/WLVlt9B55HW+ pXbQ==
MIME-Version: 1.0
X-Received: by with SMTP id sa8mr2320902lbb.89.1404754201213; Mon, 07 Jul 2014 10:30:01 -0700 (PDT)
Received: by with HTTP; Mon, 7 Jul 2014 10:30:01 -0700 (PDT)
Date: Mon, 07 Jul 2014 19:30:01 +0200
Message-ID: <>
From: Henrik Grubbström <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Mon, 07 Jul 2014 17:30:04 -0000

Hi Peter et al.

On Mon, Jul 7, 2014 at 2:56 PM, Peter Gutmann <> wrote:
> Speaking of ECC drafts, I've posted an updated version of my ECC ciphersuites
> draft, now with the Brainpool curves added:


>From the above draft section 2:

| If no additional Chinese-menu ECC suites are used, implementations
| SHOULD NOT send the Supported Elliptic Curves or Supported Point
| Formats extensions since these parameters are fully specified by the
| suite choice.

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).

The server can probably safely assume that the client supports
certificates for all the curves in the client hello suites, but this
doesn't help with certs using curves not in the list of suites in the

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

Anyway, the intended ECDSA certificate policy ought to be made
explicit in the draft.


Henrik Grubbström                             
Roxen Internet Software AB