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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
