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

Hanno Böck <hanno@hboeck.de> Tue, 17 July 2018 13:55 UTC

Return-Path: <hanno@hboeck.de>
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 01FAE130F0F for <tls@ietfa.amsl.com>; Tue, 17 Jul 2018 06:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, 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 wrea028zmWmo for <tls@ietfa.amsl.com>; Tue, 17 Jul 2018 06:55:55 -0700 (PDT)
Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA3012D7F8 for <tls@ietf.org>; Tue, 17 Jul 2018 06:55:54 -0700 (PDT)
Received: from computer ([2001:2012:127:3e00:ff5e:3a82:43d7:a6d6]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Tue, 17 Jul 2018 15:55:51 +0200 id 0000000000000078.000000005B4DF568.00004F48
Date: Tue, 17 Jul 2018 15:55:50 +0200
From: Hanno Böck <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20180717155550.1a18202e@computer>
In-Reply-To: <DE8E4C1F24911E469CC24DD4819274AA2770426C@mail-essen-01.secunet.de>
References: <DE8E4C1F24911E469CC24DD4819274AA2770426C@mail-essen-01.secunet.de>
X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/itdoEd1mBZkmx9FE83AUl3B50LY>
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 13:55:58 -0000

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