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

[Paul Hoffman <[e-mail]>]

On Sep 25, 2022, at 12:00 PM, Viktor Dukhovni <[e-mail]> wrote:
> 
> 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.

Yes, it was (at least) about DANE; added.

> 
> 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.

I would rather not speculate on the reasons for the low rate of adoption, particularly because the reasons might change with the adoption rate remaining low.

> 
> 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).

The paragraph is about RSA, not about algorithms in general. Your point is good, however, so I have changed the sentence to say "RSA is still among the most popular...", and added the sentence "ECDSA and EdDSA have become very popular signing algorithms in recent years" in the section below.

> 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.

> 
> 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.

--Paul Hoffman