Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

[Scott Morizot <[e-mail]>]

On Thu, May 2, 2024 at 6:44 AM John Levine <[e-mail]> wrote:

> It appears that Philip Homburg  <[e-mail]> 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