Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1

Johannes Merkle <> Tue, 21 July 2015 14:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4DFF11B2E9D for <>; Tue, 21 Jul 2015 07:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e7TloApWP9Rf for <>; Tue, 21 Jul 2015 07:39:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 746451B2E99 for <>; Tue, 21 Jul 2015 07:39:22 -0700 (PDT)
Received: from localhost (alg1 []) by (Postfix) with ESMTP id 003401A0085 for <>; Tue, 21 Jul 2015 16:39:05 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id Jd2UiXE4Eo1h for <>; Tue, 21 Jul 2015 16:39:03 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id C898A1A007F for <>; Tue, 21 Jul 2015 16:39:03 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Tue, 21 Jul 2015 16:39:18 +0200
Message-ID: <>
Date: Tue, 21 Jul 2015 16:39:17 +0200
From: Johannes Merkle <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
Archived-At: <>
Subject: Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1
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, 21 Jul 2015 14:39:33 -0000

Rene Struik schrieb am 16.07.2015 um 03:42:
> Dear colleagues:
> It seems prudent to keep some diversity of the gene pool and not only have curves defined over prime curves. Similarly,
> one should perhaps have some diversity of gene pool criteria within the set of recommend curves and not only include
> special primes. Should some problem with a particular subclass show up over time, one then at least has other classes
> available.
> On a general note, I do not understand what is wrong with having a dictionary of curves that is well-specified, but
> whose members are not all widely used. To my knowledge, having a dictionary does not force everyone to use every term in
> this (mandatory vs. optional to implement vs. mandatory to use, etc.).
> If one follows the line of reasoning of some people on the mailing list earlier today, doesn't this also call into
> question Brainpool curves, or, e.g., the Misty cipher, etc.? Moreover, this certainly calls into question why one would
> have a whole set of new DLP groups (which certainly cannot be widely used yet, since the ink to write the parameters
> down is still wet). What about RSA-1024, etc.?

I absolutely back up this position. Currently, the TLS 1.3 draft only permits curves over special primes. It has become
quite clear in the discussions in CFRG and at the NIST ECC workshop that some parties (major hardware manufacturers,
certification bodies) prefer curves over random primes. And as Rene has pointed out, allowing both would also give more
agility w.r.t potential future attacks on certain sub-classes.

Why can't the draft just specify the curves that are MTI but allow (at least some) alternative options, instead of
putting all our eggs in one basket?