Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

Dan Brown <danibrown@blackberry.com> Tue, 17 July 2018 14:57 UTC

Return-Path: <danibrown@blackberry.com>
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 C2010130E58 for <tls@ietfa.amsl.com>; Tue, 17 Jul 2018 07:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YDRfSZo1wR2 for <tls@ietfa.amsl.com>; Tue, 17 Jul 2018 07:57:36 -0700 (PDT)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD8A130F65 for <tls@ietf.org>; Tue, 17 Jul 2018 07:57:36 -0700 (PDT)
X-Spoof:
Received: from xct104cnc.rim.net ([10.65.161.204]) by mhs214cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2018 10:57:34 -0400
Received: from XCT111CNC.rim.net (10.65.161.211) by XCT104CNC.rim.net (10.65.161.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 17 Jul 2018 10:57:34 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Tue, 17 Jul 2018 10:57:33 -0400
From: Dan Brown <danibrown@blackberry.com>
To: Hanno Böck <hanno@hboeck.de>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Why are the brainpool curves not allowed in TLS 1.3?
Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pAALHowA///OLCs=
Date: Tue, 17 Jul 2018 14:57:30 +0000
Message-ID: <20180717145727.8642646.41749.26614@blackberry.com>
References: <DE8E4C1F24911E469CC24DD4819274AA2770426C@mail-essen-01.secunet.de>, <20180717155550.1a18202e@computer>
In-Reply-To: <20180717155550.1a18202e@computer>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/b2-hKFFzeEndzFKWKF1ZWlM9z3I>
Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.27
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: <https://mailarchive.ietf.org/arch/browse/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, 17 Jul 2018 14:57:56 -0000

It's mainly due to CFRG's advice, isn't it?
Calling other curves potentially unsafe or inappropriate for general use is a bit harsh and outside the scope of TLS, isn't it?
As to using a narrow or wide set of curves, there are reputable proposals for the latter:

ia.cr/2015/647 and ia.cr/2015/366

which may be too slow for TLS, or lacking in some other practicalities, but it is hard to conclude it is riskier or less secure.

If it's not too late then an editorial softening for the reason for the set of allowed TLS curves makes sense.

Best regards,

Dan


  Original Message
From: Hanno Böck
Sent: Tuesday, July 17, 2018 9:56 AM
To: tls@ietf.org
Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?


Hi,

I think there's been a mentality change in the TLS community that
explains this.
Back when Brainpool curves were standardized there was a "more is
better" mentality when it came to algorithms. I.e. if an algorithm is
not broken it's good to have it in TLS. Particularly all kinds of
nationalized algs made it into TLS.

There's a very strong reason against this: It creates complexity. More
opportunities for attacks, more fragmentation of the ecosystem. I
believe I speak for a lot of people here when I say that fewer
algorithms is better and having more algs "just because" is not a good
reason. With that in mind an algorithm doesn't have to be weak to be
removed from TLS. It's reason enough if it's rarely used and doesn't
have a significant advantage over alternatives.

Brainpool curves were never widely used in mainstream deployments of TLS
(aka browsers). They have no significant advantage over the other
choices. They pretty much exist because Germany wanted to have their
homegrown crypto algorithm, too, meaning they exist for nationalistic
reasons, not technical ones. So deprecating them has the same reason we
don't have SEED or Camellia in TLS any more.

--
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls