On 9/9/15, 15:29, [email protected] on behalf of [email protected] wrote:
>My other concern is that at this point, perhaps every time >we consider adding more algorithm ids to DNSSEC we should consider >retiring some old ones, we are starting to have too many: This reminds me of a line in the movie "Amadeus (1984)" [http://www.imdb.com/title/tt0086879/?ref_=nv_sr_1]: Emperor Joseph II: My dear young man, don't take it too hard. Your work is ingenious. It's quality work. And there are simply too many notes, that's all. Just cut a few and it will be perfect. Wolfgang Amadeus Mozart: Which few did you have in mind, Majesty? (http://www.imdb.com/title/tt0086879/quotes?item=qt0469793) The registry is simply a list of what is defined. One use of the registry is, many years in the future, wanting to figure out what a '5' means in an old packet dump, fossilized zone files, or in an old set of documentation. You can't reassign the values. Perhaps you want to document what should be in a general-purpose implementation. (Developers can simply list the RFCs they support, in a sense that Wireless router vendors list all the 802.11's they support.) Perhaps you want to document what an operator ought to do. There are RFCs on deploying DNSSEC, which probably don't update quite often enough. This would be good work for an BCP - but in a venue where documents are updated at the speed of operations. But there is a need for guidance here - I've seen TLDs open this year with what I'd label "old" DNSSEC Security Algorithms. I have even seen one open with DNSSEC Security Algorithm 5 and use NSEC3, (5 is the pre-NSEC5 version of RSA-SHA256), which is objectively an error. (This was fixed after a few messages.) Operators evidently could use help in selecting their cryptography. Note that there will always be someone using an older value, if just to preserve the past or if they never experience a reason to do a tech-refresh.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
