I have nothing to add to what Ólafur wrote below. I agree with his statement.
Patrik On 10 Dec 2015, at 1:33, Ólafur Guðmundsson wrote: > Stephen, > > Sorry for being so blunt below. > > The document totally content free as to why this makes any sense in an > operational context. > DNSSEC algorithms should not be given out lightly as there is a significant > COST to deploy support for each additional algorithm. > > While I strongly support having better ECC algorithm that the currently > specified curves, adding a new ones SHOULD take place via a performance > oriented process. > Thus I strongly advocate that this publication be held up until we can > compare this curve with other curves being proposed. > > Background I'm currently fighting an multifaceted battle to have various > entities adding support for ECDSAP256, specified over 3 years ago. > > Adding and deploying a new DNSKEY algorithm does not just require changes to > -- DNS servers, libraries and resolvers. > > That is just the top of the iceberg, but also to > - DNS provisioning systems, DNSSEC signing systems, DNS testing tools, - > user interfaces for registrars, hosting providers, third party DNS operators, > CDN's, etc. > - TLD and ccTLD policy documents, EPP implementations, plus in some cases > security evaluations, > - not to mention firewalls, network monitoring tools .... > and number of other things I had no idea existed and majority of which is not > maintained anymore. > > There are only so many times that one can get everyone's attention to upgrade > DNS stuff, thus requiring the change process to be run should not be taken > lightly. > If on the other hand if the editors are only interested in vanity algorithm > assignment without any deployment then ........... > > Olafur > > > On Wed, Dec 9, 2015 at 4:00 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > >> >> >> >> -------- Forwarded Message -------- >> Subject: code points for brainpool curves for DNSSEC >> Date: Wed, 9 Dec 2015 18:00:18 +0000 >> From: Stephen Farrell <stephen.farr...@cs.tcd.ie> >> To: s...@ietf.org >> >> >> Hiya, >> >> The brainpool folks have written an I-D [1] that they are pushing >> through the rfc editor's independent stream. [2] >> >> That I-D wants to register code points for using their curves for >> DNSSEC. >> >> For documents that come through the independent stream, the IESG >> does an RFC 5742 [3] conflict review. The purpose of that review >> is to check that the RFC doesn't conflict with ongoing work in >> the IETF. >> >> If you have thoughts on this, please let me know before Dec 17th. >> I'll forward this to the dnsop, cfrg and curdle mailing lists >> to check there too. Apologies if you get >1 copy of this. Please >> try follow up on the saag list if you can. >> >> Thanks, >> Stephen. >> >> >> [1] https://tools.ietf.org/html/draft-schmidt-brainpool-dnssec >> [2] https://www.rfc-editor.org/pubprocess/ >> [3] https://tools.ietf.org/html/rfc5742 >> >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
