I'm not on SAAG and don't have the time to add another mail list... My one recommendation is, if they want to assign this a DNSSEC security algorithm number, propose that in a separate draft akin to what's in RFCs 5155, 5702, 5933, 6605 - or as seen in the DNS Security Algorithm Numbers registry at IANA:
http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xht ml#dns-sec-alg-numbers-1 "We don't need no stinkin' crypto talk on DNSOP!" DNSSEC is not wedded to any kind of cryptography except the "working" kind. On 12/10/15, 4:42, "DNSOP on behalf of Stephen Farrell" <dnsop-boun...@ietf.org on behalf of stephen.farr...@cs.tcd.ie> wrote: > >FYI. > >Please continue to follow up on the saag list for now so the >discussion (if more is needed) is in one place. (And thanks >for doing that so far.) > >S. > > >-------- Forwarded Message -------- >Subject: Re: [saag] [DNSOP] code points for brainpool curves for DNSSEC >Date: Thu, 10 Dec 2015 09:39:17 +0000 >From: Stephen Farrell <stephen.farr...@cs.tcd.ie> >To: s...@ietf.org > > >Thanks all, that's sufficient feedback for me to propose to the >IESG that we return a "potentially disrupts, so please do not >publish now" 5742 response so I have proposed that to the IESG. >Additional discussion of reasons to not do this allocation now >may therefore be redundant. > >Discussion of what to do in future is still welcome, and if >that doesn't happen I at least will raise the issue on the list >for the in-formation curdle WG. [1] > >The text I've proposed is at [2], feel free to suggest edits, >but that can be done offlist. > >Cheers, >S. > >[1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ >[2] >https://datatracker.ietf.org/doc/conflict-review-schmidt-brainpool-dnssec/ > >On 10/12/15 09:15, Patrik Fältström wrote: >> 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 > > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
