On Oct 17, 2022, at 6:07 PM, Paul Wouters via Datatracker <[email protected]> wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > Since draft-ietf-dnsop-rfc5933-bis is in IETF Last Call now,
Timing is everything in Internet protocols and comedy. > I think it is > worth waiting on and updating this text: > > 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. > > To add a reference that RFCXXX updates the GOST algorithms for DNSSEC Yes. > (but that > it is uncertain at this point whether it will be widely adopted) It is unwise to try predict the future in any RFC, much less a BCP. > I could be convinced for this document to not wait, but then I do think this > paragraph should state that it is NOT RECOMMENDED to implement RFC5933 since > the underlying GOST algorithms have been deprecated by its issuer. No, I think it's fine to hold this document to be correct about GOST. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > One purpose is to introduce all of the RFCs in one place so > that the reader can understand the many aspects of DNSSEC. This > document does not update any of those RFCs. Another purpose is to > move DNSSEC to Best Current Practice status. > > I think another purpose not mentioned, which for me was a main motivator for > this document, is to provide a single RFC reference for other documents that > want to point to "DNSSEC" using a single reference instead of referring to the > 3 core components (in an incomplete way) Good additon. > > 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. > > What is the value of this paragraph? This was debated in the WG, and was chosen for inclusion to highlight that a BCP does not mean "widely deployed". > You wouldn't want to have a single IPv6 > reference RFC say this either :) Oh, I think I would. :-) There is a long list of technologies that could be inserted there... > > This document will be "the reference RFC" for a long time. It should not have > dated/outdated statistics in it. It feels like it is better to give statistics than to just handwave "still not widely deployed". > > However, this low level of implementation does not affect whether > DNSSEC is a best current practice > > I don't think the level of implementation is low. It is actually quite high. > Practically all DNS software implements it. I think you meant deployment ? Yes, good. > > NITS: > > which algorithms recursive resolver operators should or should not > validate. > > change to: > > which algorithms recursive resolver operations should or should not > use for validation > > (the algorithms themselves are not validated) > Yep. <https://github.com/paulehoffman/draft-hoffman-dnssec/commit/cbc5040> --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
