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:e...@rtfm.com] Sent: Tuesday, July 17, 2018 11:02 AM To: Dan Brown <danibr...@blackberry.com> Cc: Hanno Böck <ha...@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 <danibr...@blackberry.com <mailto:danibr...@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: ha...@hboeck.de <mailto:ha...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
