Re: [Last-Call] [Ext] Opsdir last call review of draft-ietf-dnsop-dnssec-bcp-03

[Viktor Dukhovni <[e-mail]>]

On Sun, Sep 25, 2022 at 08:27:19PM +0000, Paul Hoffman wrote:

> > In:
> > 
> >    3.  Additional Cryptographic Algorithms and DNSSEC
> > 
> >       [...]
> >       The GOST signing algorithm [RFC5933] was also adopted, but has seen
> >       very limited use, likely because it is a national algorithm specific
> >       to a very small number of countries.
> > 
> > GOST is more than merely unpopular, the underlying revision of the GOST
> > algorithms have been deprecated and replaced, and RFC 8624 lists GOST as "MUST NOT"
> > for signing.
> 
> That is being rectified in the DNSOP WG, albeit too slowly to be
> reflected in this document.

Note that my point was not about the status of GOST viz DNSSEC, but
rather that the Russian Federation has deprecated and superseded the
version of GOST (GOST R 34.10-2001) that is the basis of algorithm 12.

Therefore, its use even inside .RU/.рф is no longer appropriate. The
algorithm is pining for fjords (<https://www.youtube.com/watch?v=vZw35VUBdzo>).

> > I take issue with the next paragraph:
> > 
> >       Implementation developers who want to know which algorithms to
> >       implement in DNSSEC software should refer to [RFC8624].  Note that
> >       this specification is only about what algorithms should and should
> >       not be included in implementations: it is not advice for which
> >       algorithms that zone operators should and should not sign with, nor
> >       which algorithms recursive resolver operators should or should not
> >       validate.
> > 
> > Sure, the opening sentence of Section 3.1 reads:
> > 
> >       The following table lists the implementation recommendations for
> >       DNSKEY algorithms.
> > 
> > but an attentive operator should and will indeed take this advice into
> > consideration.  Many have already, and adoption of the deprecated algorithms 5
> > and 7 have declined by ~95% from their peak values.
> 
> This document is not the place to re-litigate the scope of RFC 8624,
> not is it a good place to say what "an attentive operators should" do
> other than to read the listed RFCs.

Well, in that case it should also not make a strong disclaimer to the
effect that 8624 is not advice to operators.  It plainly is used as
such.  Perhaps silence on that topic would be best.

-- 
    Viktor.