This set of drafts is a useful addition to the DNSSEC cannon and should be published as RFCs.
--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. 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. 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. 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. ============================================ 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. ============================================ 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. 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. (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. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
