Responding to two messages, perhaps with a "get off my lawn" old-guy attitude:
On 3/13/20, 4:59 PM, "dns-operations on behalf of Marek Vavruša" <[email protected] on behalf of [email protected]> wrote: >the DSA-NSEC3-SHA1 has been deprecated in >https://tools.ietf.org/html/rfc8624 so zones below DS with these keys >are effectively treated as unsigned zones (rfc4035 5.2), >but you raise a good point that the method of doing so is not consistent. This lament is in line with the talk I gave last month on the different ways ANY was minimized. There's a need to constrain the protocol to avoid this kind of confusion. On 3/13/20, 7:52 PM, "dns-operations on behalf of Viktor Dukhovni" <[email protected] on behalf of [email protected]> wrote: >In future RFCs deprecating algorithms (e.g. soon I hope RSASHA1 5 and >RSASHA1-NSEC3-SHA1 7) we should perhaps aim to first specify "MUST NOT" >for signing, and only some time (years) later "MUST NOT" for validation. >Which I think ideally means updating "8624" *this year* with a "MUST NOT" >for signing for 5 and 7, with a view to "MUST NOT" also for validation >no earlier than 2022. I've never been a fan of an RFC document defining the contents of a registry (in this case the DNSSEC Security Algorithm registry) also making statements on whether a parameter ought to be used. I don't think this approach "works." The DNS protocol is used on networks that are not connected to the global public Internet. (I have one example network in mind - if it still exists, I should add.) Mixing protocol definition and operational guidance is the problem when you are solving for multiple operational environments. A founding principle of DNSSEC is "local policy rules." I understand that this was established in an era where anyone dealing with DNSSEC had a graduate degree in some sort of engineering, but I still think it applies in a different form. I would leave it up to a validator to make a decision on whether it will accept data as valid. I may be mistaken, but the IETF does not like specifying default values for tools. In this instance, I believe that there ought to be document that does. First, I'd start with validation (as that's where the real work of DNSSEC is done), with an "I accept this" policy. The "default" set of DNSSEC Security Algorithms could be tool-set with local operator override. As far as signing, it's fine for a tool to warn against using an algorithm but realize there are two steps towards eliminating an algorithm's use. First, old tools will still be around, meaning "stopping signing" won't stop signing. Second, tool refresh may not be followed with a configuration refresh (evident in BIND and the KSK rollover). An operator may not be ready to change algorithms - especially if the change is not automatic. I don't think you can expect to change signing habits first. And I don't think you can change habits until tools change the default values in a way that is entirely transparent to the lay operator. _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
