On Thu, May 2, 2024 at 6:44 AM John Levine <jo...@taugh.com> wrote:
> It appears that Philip Homburg <pch-dnso...@u-1.phicoh.com> said: > >In your letter dated Thu, 2 May 2024 10:27:17 +0200 you wrote: > >>I'm not following what breaks based on the wording I suggested, and I'm > not su > >>re why you keep bringing that up. :-) > > > >Then an RFC gets published that signers MUST NOT support signing using > SHA1, > >so ldns removes those algorithms. Then a software update brings the new > >version of ldns my system. Now an unsigned zone gets deployed, .... > > On the other hand, if it issued annoying warning messages every time it > used a SHA1 key, I'd eventually notice and probably rotate the keys. > > I'm with Peter, I do not see a MUST NOT as requiring vendors or operators > to do stupid stuff. > A MUST NOT in RFC 8624 directs implementations to remove their implementation of an algorithm. The current NOT RECOMMENDED is the appropriate recommendation, according to the text of an RFC, for an implementation to issue a warning that the algorithm is deprecated and should not be used for signing. Here's the description of the intent in the deprecation process outlined in RFC 8624. It seems to me this discussion has strayed from that core process to various perspectives about whether or not SHA-1 remains "secure enough". "It is expected that deprecation of an algorithm will be performed gradually in a series of updates to this document. This provides time for various implementations to update their implemented algorithms while remaining interoperable. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to NOT RECOMMENDED or MAY, instead of to MUST NOT. Similarly, an algorithm that has not been mentioned as mandatory-to-implement is expected to be introduced with a RECOMMENDED instead of a MUST. Since the effect of using an unknown DNSKEY algorithm is that the zone is treated as insecure, it is recommended that algorithms downgraded to NOT RECOMMENDED or lower not be used by authoritative nameservers and DNSSEC signers to create new DNSKEYs. This will allow for deprecated algorithms to become less and less common over time. Once an algorithm has reached a sufficiently low level of deployment, it can be marked as MUST NOT so that recursive resolvers can remove support for validating it. Recursive nameservers are encouraged to retain support for all algorithms not marked as MUST NOT." I have seen absolutely no "strong security reasons" presented in this discussion for altering that deprecation model when it comes to DNSSEC algorithms 5 and 7. (I would consider 5 less widely deployed, but since the only difference between the two is support for NSEC3 I don't see a reason to treat them differently.) Algorithm 7 remains widely used and by zones most people would consider significant. In the US, for instance, that includes cdc.gov. Moreover, as others have pointed out, the following assertion in the draft is factually wrong. I'm not going to support a standards document that can't even accurately state facts. "This document retires the use of SHA-1 within DNSSEC." Well, no. It doesn't. NSEC3 will continue to require SHA-1 until such time as that standard is also changed. The draft instructs implementations to no longer support algorithms 5 and 7 for both signing and validation and by changing both to MUST NOT at the same time it contravenes the deprecation model outlined in RFC 8624 without providing any justification beyond some security hand-waving. RFC 8624 provides the correct guidance to implementations for the current state of use for algorithms 5 and 7. There are no "strong security reasons" for deviating from the deprecation model outlined in the RFC. "NOT RECOMMENDED" for signing means the same as "SHOULD NOT". (That's also included with the RFC reference in the text of RFC 8624.) That seems appropriate for signing implementations to issue warnings that the algorithms are deprecated for signing if they choose. The guidance for support in validators is not supposed to move to MUST NOT until an algorithm has reached a low enough level of deployment. I don't see how anyone can reasonably argue that is the case today for algorithm 7. In my opinion, this draft should not move forward. Scott
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
