On Tue, Jan 07, 2025 at 12:17 PM, Paul Hoffman <paul.hoff...@icann.org> wrote:
> This set of drafts is a useful addition to the DNSSEC cannon and should be > published as RFCs. > Thank you for your review and feedback. We have addressed these most of these below, and posted new versions in Github. --Paul Hoffman > > ============================================ > > draft-ietf-dnsop-rfc8624-bis > > This draft is much better than the original proposal, and should be > adopted. I am ambivalent on putting these recommendation updates in the > IANA registries, but doing so is much better than having them in RFCs that > need to be tracked. After these changes are made, it is incumbent on the > DNSOP WG to let the wider DNS communities know that the change has been > made and that developers and implementers should be periodically looking in > the registry. > > The placement and wording of the "editor note" at the beginning of the > abstract is confusing. I propose that it be moved to the Introduction, and > not labelled as a "note" because it is a meaningful part of the document. > Thank you very much — done. I also did some minor editorial work to make it still flow well. > Similarly, the "note" in the introduction about TLS ciphersuites should > not be a note but a normal paragraph because it is relevant to the new > design of this registry. > Thank you — done. > The WG should consider whether the publication requirements in Section 2 > are correct. I feel they are not, but I also know that this topic elicits > strong opinions in this WG, in SAAG, and in the IETF in general. > > In specific, I think the bar for all levels should be "publication that > includes the use in DNSSEC", not an RFC. RFCs take a long time to get > through the system, and there is active debate about whether all > cryptographic algorithms should even have RFCs. The extra vetting that a > standards track document requires rarely helps the community understand the > security properties of the algorithm. > > What we care most about is not who likes or dislikes a new algorithm, but > whether there is adequate description of its use in DNSSEC. Thus, saying > "RFC" or "standards track RFC" could still give the registry a reference > that does not lead to interoperability. Non-RFC references that describe > the algorithm and its use in DNSSSEC are better for this community. > > Section 3: Get rid of that editor's note. It is irrelevant to publication. > Thank you, done. It was (IMO) useful during initial discussions, but shouldn't be needed anymore; removed. > Section 5: Let's not overstate the security properties of RSA. Instead of: > ... cryptographic research so far leads > us to believe that they are likely to remain secure into the foreseeable > future. > I would prefer: > ... cryptographic research so far leads > us to believe that they are likely to remain adequately secure unless a > significant and unexpected discovery is made. > > Ooh, I like that. Done. > ============================================ > > draft-ietf-dnsop-must-not-sha1 > > This document is fine as-is, with one minor nit: Appendix C should be > marked for removal by the RFC Editor, similar to Appendix B. > Thank you, done! > ============================================ > > draft-ietf-dnsop-must-not-ecc-gost > > The goal of this document is fine. Some of the wording could be toned down > because we don't actually know why the algorithms were deprecated. I heard, > very informally, that they had a minor but real weaknesses, and their > replacements had better security proofs. Given our lack of certainty, we > should deprecate them only because the sponsoring government did. > > Section 3 might instead read: > > This document potentially increases the security of the DNSSEC ecosystem > by deprecating algorithms that are no longer recommended for use. > Thank you, done. > Section 4 might instead read: > > This document removes support for ECC-GOST. Zone operators currently > making use of ECC-GOST based algorithms should switch to algorithms that > remain supported. DNS registries should prohibit their clients to upload > and publish ECC-GOST based DS records. > Done. > (The reference to RFC 9499 there is confusing, so it can be eliminated.) > > Appendix C should be marked for removal by the RFC Editor, similar to > Appendix B. > And also done! > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org > >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
