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

From: "Bruckert, Leonie" <[email-masked]>
Date: Tue, 17 Jul 2018 12:39:31 +0000

Dear WG members,

I am quite astonished that the brainpool curves are eventually prohibited in TLS 1.3. Based on an earlier comment (https://www.ietf.org/mail-archive/web/tls/current/msg17204.html), I would have thought that the brainpool curves will be allowed in any future version, especially since they have been deployed successfully to date.

Reading the latest draft I happened to notice that the numbers 0x001A to 0x001C that point to the brainpool curves are marked as obsolete_RESERVED for the following reasons:

"The obsolete curves have various known/theoretical weaknesses or have had very little usage, in some cases only due to unintentional server configuration issues.  They are no longer considered appropriate for general use and should be assumed to be potentially unsafe." (See p. 127)

I am not aware of any weaknesses of the brainpool curves, so I consider this banishment unjustified. As I did not at all understand this decision and furthermore, could not find any explanations in the mailing list archive, I would like to ask how all this happened.

Best regards,

Leonie

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 17 Jul 2018 16:27:16 +0300

On Tue, Jul 17, 2018 at 12:39:31PM +0000, Bruckert, Leonie wrote:
> Dear WG members,
> 
> I am quite astonished that the brainpool curves are eventually
> prohibited in TLS 1.3. Based on an earlier comment
> (https://www.ietf.org/mail-archive/web/tls/current/msg17204.html),
> I would have thought that the brainpool curves will be allowed in
> any future version, especially since they have been deployed
> successfully to date.

That comment was three years ago. TLS 1.3 was quite different
back then. And dropping Brainpool came later. But that discussion
already touched reasons why Brainpool was dropped.

> I am not aware of any weaknesses of the brainpool curves, so I
> consider this banishment unjustified. As I did not at all
> understand this decision and furthermore, could not find any
> explanations in the mailing list archive, I would like to ask
> how all this happened.

Altough brainpool curves are not in any known class of weak curves
(base field degree >2, l == p, or small k where l | p^k-1), and as
such, finding these to be weak would be a cryptographic breakthrough
(highly likely taking out lots of other curves with them):

- These curves are pretty much national.
- These curves are slow compared to other curves.

There was also other pieces of national crypto that were dropped,
like the non-AES GCM modes, even if porting these across would
have been trivial, and AFAIK there is no known cryptographic
trouble with those algorithms.

I took look when Brainpool was finally actually dropped. It was
draft-12 in March 2016 (the previous one from December 2015 still
had them). At the same time, signature negotiation was revamped,
which may be related, given that the revamped signature negotiation
does not have room for ECDSA with Brainpool curves.

-Ilari

---

From: Hanno Böck <[email-masked]>
Date: Tue, 17 Jul 2018 15:55:50 +0200

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: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: Dan Brown <[email-masked]>
Date: Tue, 17 Jul 2018 14:57:30 +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: [email-masked]
Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

Hi,

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

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Jul 2018 08:01:44 -0700

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 <[email-masked]> wrote:

> Calling other curves potentially unsafe or inappropriate for general use
> is a bit harsh and outside the scope of TLS, isn't it?
> 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.
>

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 17 Jul 2018 17:04:23 +0200

Hi,

> have a significant advantage over alternatives.

Crypto agility definitely has its value. There are not so many curves supported by TLS 1.3, and all of them use primes
of a very special form. Of course, this is exactly what makes these curves faster than the Brainpool curves, but from a
security perspective it might be advisable to have alternatives at hand which have very different properties (and have
not been generated by the NSA using seeds of obscure origin). In particular, as the code points had already been
registered and have already been implemented in some products.

Furthermore, the reasoning in the draft that these curves "should be assumed to be potentially unsafe" is completely wrong.

Johannes

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 17 Jul 2018 08:37:16 -0700

On Tue, Jul 17, 2018 at 8:04 AM Johannes Merkle <[email-masked]>
wrote:

> Crypto agility definitely has its value. There are not so many curves
> supported by TLS 1.3, and all of them use primes
> of a very special form. Of course, this is exactly what makes these curves
> faster than the Brainpool curves, but from a
> security perspective it might be advisable to have alternatives at hand
> which have very different properties

Between the NIST curves and Curve25519/Ed448 we have this already.

> (and have not been generated by the NSA using seeds of obscure origin).
>

We've been through this before, e.g.:

https://www.ietf.org/mail-archive/web/tls/current/msg10271.html
https://bada55.cr.yp.to/brainpool.html

...the latter of which quotes you as saying the repeated digits in the "A"
and "B" values used in Brainpool seed generation process were "unfortunate".

There are no compelling practical reasons to continue to support the
Brainpool curves. They are both redundant and obscure.

--
Tony Arcieri

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Jul 2018 08:47:48 -0700

On Tue, Jul 17, 2018 at 8:04 AM, Johannes Merkle <
[email-masked]> wrote:

> which have very different properties (and have
> not been generated by the NSA using seeds of obscure origin). In
> particular, as the code points had already been

Well, I think the question here centers on what "at hand" means. We've
generally decided to limit the number of algorithms we recommend (the
Recommended) column in the registry. I have trouble seeing any situation in
which we would have these curves as Recommended. And so "at hand" really
means (1) code points assigned and (2) some small number of people who
don't follow our Recommended advice do them. I have trouble seeing, for
instance, many Web implementations having these curves.

If we think that we need a backup set of curves with yet different
properties from the CFRG curves and the NIST curves, then we should ask
CFRG to produce such curves, which we would then feel good about marking
"Recommended"

-Ekr

Furthermore, the reasoning in the draft that these curves "should be
> assumed to be potentially unsafe" is completely wrong.
>
> Johannes
>

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 17 Jul 2018 18:42:12 +0200

> and "B" values used in Brainpool seed generation process were "unfortunate".

I am so tired of this polemic discussion. Everything that need to be said in response can be found here:
https://www.ietf.org/mail-archive/web/cfrg/current/msg05353.html

Give it a read.

Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 17 Jul 2018 18:45:40 +0200

Eric Rescorla schrieb am 17.07.2018 um 17:47:
> We've
> don't follow our Recommended advice do them

But the draft states
   Values within "obsolete_RESERVED" ranges are used in previous
   versions of TLS and MUST NOT be offered or negotiated by TLS 1.3

So its not merely a recommendation.

Johannes

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Jul 2018 10:23:39 -0700

> So its not merely a recommendation.

Yes, what I am saying is that even if we were to remove that text it would
not significantly change matters.

-Ekr

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 17 Jul 2018 17:28:44 +0000

But the draft states
   Values within "obsolete_RESERVED" ranges are used in previous
   versions of TLS and MUST NOT be offered or negotiated by TLS 1..3

Yes, what I am saying is that even if we were to remove that text it would not significantly change matters.

I think “MUST NOT” is way too strong in this context, and “must” be softened.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Jul 2018 17:44:54 +0000

But the draft states

TLS 1.3 does not define use of the Brainpool curves.  Any implementation that wants to use them in TLS 1.3 is already out-of-scope of the standard, and is therefore not required to follow MUST etc.

The intent of the WG was to not allow some things, and changing away from MUST violates that intent.

A separate RFC proposal adding Brainpool to TLS 1.3 is the way to go, and the only way to go.

For now, use TLS 1.2

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 18 Jul 2018 08:52:08 +0000

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

When the Brainpool-with-TLS RFC was published, several implementers announced
that they'd added support within 24 hours of the RFC appearing (in some cases
determined by time zones).

I think that was the fastest uptake of any security RFC I've ever seen.

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 18 Jul 2018 13:13:48 +0200

On Wednesday, 18 July 2018 10:52:08 CEST Peter Gutmann wrote:
> When the Brainpool-with-TLS RFC was published, several implementers
> announced that they'd added support within 24 hours of the RFC appearing
> (in some cases determined by time zones).
> 

just because implementations added them, doesn't mean they were deployed

last time I performed scan looking for them, they haven't crossed 10%, 4 years 
*after* the RFC7027 was published:

https://securitypitfalls.wordpress.com/2017/04/

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: "Bruckert, Leonie" <[email-masked]>
Date: Wed, 18 Jul 2018 16:54:52 +0000

As I understand from the text, the Brainpool curves itself are not prohibited, but the code points assigned to them. So, if people still want to use the Brainpool curves in conformance with the standard, I would conclude that they can request new code points. This would result in an IANA registry with duplicated entries for brainpool curves: the old, now prohibited code points and the new assigned ones. Is this correct?

Leonie

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Jul 2018 17:33:39 +0000

> This would result in an IANA registry with duplicated entries for brainpool curves: the old, now prohibited code points and the new assigned ones. Is this correct?

No.  The request could ask for the existing reserved codepoints to be re-used.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Jul 2018 17:37:29 +0000

>No.  The request could ask for the existing reserved codepoints to be re-used.

But note that the WG decision was to remove all sorts of things, including Brainpool curves, and it would probably be best to discuss bringing them back via the WG.

The TLS registries are now document-required BTW.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 18 Jul 2018 17:40:28 +0000

No offense meant, but this does not make sense. Code points were assigned, probably some apps were/are using them. Now those code points are to be invalidated, and new ones assigned instead?!

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Jul 2018 17:42:44 +0000

>No offense meant, but this does not make sense. Code points were assigned, probably some apps were/are using them. Now those code points are to be invalidated, and new ones assigned instead?!

Perhaps I am confused.

Code points for pre-1.3 were assigned, and they are invalid for TLS 1.3.  Those “you should not send these for 1.3” could be re-used for TLS 1.3, if that was desired.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 18 Jul 2018 13:59:44 -0400

> On Jul 18, 2018, at 13:42, Salz, Rich <[email-masked]> wrote:
> 

Likelier that I am confused… It’s been a tough day.
 
> Code points for pre-1.3 were assigned, and they are invalid for TLS 1.3.  Those “you should not send these for 1.3” could be re-used for TLS 1.3, if that was desired.

Yes this makes sense. And I think that they should, documented as something other than “Recommended”.

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 19 Jul 2018 12:27:52 +0200

> Yes this makes sense. And I think that they should, documented as something other than “Recommended”.

I still don't get it. If the existing code points are re-used, the TLS 1.3 standard is violated.

Johannes

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 19 Jul 2018 11:18:21 +0000

SHOULD NOT would probably be fine. MUST NOT is too strong, and probably needs revisiting.

Regards,
Uri

Sent from my iPhone

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Jul 2018 13:18:27 +0000

>    I still don't get it. If the existing code points are re-used, the TLS 1.3 standard is violated.
  
Right.  So a document will have to be written that updates the RFC to use them.  Or, go for other codepoints.

Either way, I think it will be an uphill struggle to convince the WG, who would probably defer to CFRG so convince them as well, that Brainpool curves are necessary for TLS 1.3.  just some advice.

---

From: Dan Brown <[email-masked]>
Date: Mon, 30 Jul 2018 14:36:03 +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:[email-masked]] 
Sent: Tuesday, July 17, 2018 11:02 AM
To: Dan Brown <[email-masked]>
Cc: Hanno Böck <[email-masked]>; [email-masked]
Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

-Ekr

On Tue, Jul 17, 2018 at 7:57 AM, Dan Brown <[email-masked] <mailto:[email-masked]> > wrote:

ia.cr/2015/647 <http://ia.cr/2015/647>  and ia.cr/2015/366 <http://ia.cr/2015/366> 

Best regards,

Dan

  Original Message
From: Hanno Böck
Sent: Tuesday, July 17, 2018 9:56 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?

Hi,

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

mail/jabber: [email-masked] <mailto:[email-masked]> 
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

_______________________________________________
TLS mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/tls

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 30 Jul 2018 11:54:46 -0400

> On Jul 30, 2018, at 10:36, Dan Brown <[email-masked]> wrote:
> 

I concur with your reasoning, and think that at the very least the words “should be assumed to be potentially unsafe” be removed from the document.