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

[Viktor Dukhovni <[e-mail]>]

On Sun, Sep 25, 2022 at 11:11:44AM -0700, Gyan Mishra via Datatracker wrote:

> The document reads well and is ready for publication.  
> 
> I do not see any issues with the draft.

I largely concur, but do have a few comments:

In the final two sentences of:

    1.  Introduction

       [...]                                It also points to the relevant
       IANA registries that relate to DNSSEC.  It does not, however, point
       to standards that rely on zones needing to be signed by DNSSEC.

it is not completely obvious to me (and perhaps more so to the uninitiated) what
the final sentence is about.  Is this about DANE and the like?  An example could
make this clear.

It may be worth mentioning in:

    1.1.  DNSSEC as a Best Current Practice

       Some observers note that, more than 15 years after the DNSSEC
       specification was published, it is still not widely deployed.  Recent
       estimates are that fewer than 10% of the domain names used for web
       sites are signed, and only around a third of queries to recursive
       resolvers are validated.  However, this low level of implementation
       does not affect whether DNSSEC is a best current practice; it just
       indicates that the value of deploying DNSSEC is often considered
       lower than the cost.  Nonetheless, the significant deployment of
       DNSSEC beneath some top-level domains (TLDs), and the near-universal
       deployment of DNSSEC for the TLDs in the DNS root zone, demonstrate
       that DNSSEC is suitable for implementation by both ordinary and
       highly sophisticated domain owners.

that part of the reluctance to deploy has been immaturity of tools, and lack of
skilled technical staff.  At least the tooling has undergone significant
improvement recently, and further automation is in active development.

In:

    2.  DNSSEC Core Documents

       *  [RFC3110] defines how to use the RSA signature algorithm (although
          refers to other documents for the details).  RSA is still the most
          popular signing algorithm for DNSSEC.

it may be worth mentioning that ECDSA P256 adoption is now almost as widely
deployed for zone signing as RSA (by count of signed zones).

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
<https://www.rfc-editor.org/rfc/rfc8624#section-3.1> lists GOST as "MUST NOT"
for signing.

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.

-- 
    Viktor.