On Tue, Jul 17, 2018 at 8:04 AM, Johannes Merkle < johannes.mer...@secunet.com> wrote:
> Hi, > > > 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. > > 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. > 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
