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

Dan Brown <danibrown@blackberry.com> Mon, 30 July 2018 14:36 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 07B82131141 for <tls@ietfa.amsl.com>; Mon, 30 Jul 2018 07:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 rEpcAouJ1XMy for <tls@ietfa.amsl.com>; Mon, 30 Jul 2018 07:36:07 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (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 E64AB131114 for <tls@ietf.org>; Mon, 30 Jul 2018 07:36:06 -0700 (PDT)
X-Spoof:
Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs210cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jul 2018 10:36:05 -0400
Received: from XCT114CNC.rim.net (10.65.161.214) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 30 Jul 2018 10:36:05 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT114CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Mon, 30 Jul 2018 10:36:04 -0400
From: Dan Brown <danibrown@blackberry.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: 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///OLCuAAEQ9AP/wPvXg
Date: Mon, 30 Jul 2018 14:36:03 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF501CA9EDD@XMB116CNC.rim.net>
References: <DE8E4C1F24911E469CC24DD4819274AA2770426C@mail-essen-01.secunet.de> <20180717155550.1a18202e@computer> <20180717145727.8642646.41749.26614@blackberry.com> <CABcZeBNjsU+FLdF7nnfhaqLWDNU5HHcX-W_261wmAfWqmMqm+w@mail.gmail.com>
In-Reply-To: <CABcZeBNjsU+FLdF7nnfhaqLWDNU5HHcX-W_261wmAfWqmMqm+w@mail.gmail.com>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.252]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_004B_01D427F1.1C4320F0"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ohiXg2lwHzDWbLUgk0jY3ZbC0zw>
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: Mon, 30 Jul 2018 14:36:15 -0000

The TLS 1.3 draft sentence “They are no longer considered appropriate for general use and should be assumed to be potentially unsafe” seems a bit excessive.  I suggest deleting it, and think that its encompassing paragraph flows fine without it, and is sufficiently logical.  I see its removal as an editorial change (though I am not sure it is too late or not to make such a change).

 

More rationale below …

 

For example, consider secp256k1 (used in bitcoin), one of the curves obsoleted/deprecated in TLS 1.3 and 4492bis.  I certainly agree with the prevailing wisdom (first suggested by Miller) that, because secp256k1 is a special CM curve, it is a greater security risk than non-CM curves (including secp251r1 (aka NIST P256), Curve25519, and the Brainpool curves).  It is fine for TLS to heed this advice.

 

But there is still no proof that the risk is greater, and various reputable authors have pointed out situations that special algorithms may sometimes better survive disasters than their less special counterparts, I can dig up references if needed.  (My view is that this risk of disaster is to apply both types of algorithms, i.e. defense in depth, (hence I proposed a new CM curve to CFRG) but I would perfectly understand if doubling the cost of key agreement is too expensive for TLS.

 

I also don’t dispute that supporting (a choice of) many curves might induce security risks (e.g. spreading security analysis too thin, etc., weakest option attacks, etc.), and that there may be greater implementation risks (of some curves vs others), and so on, but I view most of these risk as pragmatic risks, which are mitigatable with sufficient effort.

 

The quoted sentence “They are no longer considered appropriate for general use and should be assumed to be potentially unsafe” loses most of these nuances. 

 

From: Eric Rescorla [mailto:ekr@rtfm.com] 
Sent: Tuesday, July 17, 2018 11:02 AM
To: Dan Brown <danibrown@blackberry.com>
Cc: Hanno Böck <hanno@hboeck.de>; tls@ietf.org
Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

 

Well, I note that the text also says "or have had very little usage,"

 

-Ekr

 

 

On Tue, Jul 17, 2018 at 7:57 AM, Dan Brown <danibrown@blackberry.com <mailto:danibrown@blackberry.com> > wrote:

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 <http://ia.cr/2015/647>  and ia.cr/2015/366 <http://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 <mailto: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 <mailto:hanno@hboeck.de> 
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

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

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