Ballot for draft-ietf-dnsop-rfc5933-bis
Discuss
Yes
No Objection
Abstain
No Record
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
(updated DISCUSS to -13, thanks for addressing my DISCUSS items on -12) I agree with Roman's DISCUSS on the stream of the document, and his proposed solution.
RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security Extensions, called DNSSEC. This document could be the first user of using [BCPxx] (draft-ietf-dnsop-dnssec-bcp, currently at RFC Editor) instead of referencing an incomplete set of what DNSSEC is. Note: Algorithm numbers 23 and 5 are used in this document as an example, since the actual numbers have not yet been assigned. This note should be more clearly marked using [brackets] so that the RFC Editor knows it is meant for them to remove/update and/or the authors to update upon their allocation and updated examples
(updated ballot) The IETF has steered away from publishing protocol mechanisms with dependencies on national cryptography as we do not have the ability to validate their security properties ourselves. IETF stream documents typically rely on documents published in the Crypto Forum Research Group (CFRG) [1]; an open and peer-reviewed vetting process; or a review by the IRTF Crypto Panel [2] to give us confidence in cryptographic algorithm choices. Since the described GOST mechanism doesn’t fit into these vetting criteria and the WG (based on the shepherd’s report) has not provided alternative analysis, it is not appropriate to publish this document in the IETF stream. 11/28/2022: Suggested resolution per mailing list discussion: https://mailarchive.ietf.org/arch/msg/dnsop/XZoakWUDruPXylJ2wLIS4l4vevo/
Thank you to Mohti Sethi for the SECDIR review. I have no insight into the deliberations in 2010 that resulted in RFC5933 being published. However, as the shepherd’s report notes, with the publication of RFC6014 (in 2010) and RFC9157 (in 2021), the relevant IANA DNSSEC registries [4] [5] provide sufficient flexibility to assign code points with an RFC outside of the IETF stream (a situation that didn’t exist in 2010). Such flexible policies in DNSSEC registries have also been made for TLS and IPsec registries to avoid the IETF having to render judgement on cryptography, national or otherwise, while still providing code points -- the exact situation we find ourselves in. Similar GOST-related protocol mechanisms have successfully been submitted to the Independent Submission Stream (ISE) [3] (e.g., RFC 9189, draft-smyslov-ike2-gost, and draft-smyshlyaev-tls13-gost-suites). It seems possible to follow the same approach here. [1] https://datatracker.ietf.org/rg/cfrg/about/ [2] https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%20Panel [3] https://www.rfc-editor.org/about/independent/ [4] https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 [5] https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
The document is short and readable, I have no objection to it as such. Roman's DISCUSS position makes sense to me, however, as does his proposed solution (even though the additional work is regrettable).
I support Roman's DISCUSS.
# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-rfc5933-bis-12 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). I share Roman's feeling about the ISE stream rather than the IETF stream, especially since 'informative' is enough. Special thanks to Tim Wicinski for the shepherd's detailed write-up including the WG consensus *but* missing the justification of the intended status (even if the write-up alludes to informational is enough). Thanks to Jim Reid and Scott Rose who did the DNS directorate reviews of this document (even if the expectation of DNS directorate is to focus on documents from non DNS WGs): * https://datatracker.ietf.org/doc/review-ietf-dnsop-rfc5933-bis-10-dnsdir-lc-reid-2022-10-16/ * https://datatracker.ietf.org/doc/review-ietf-dnsop-rfc5933-bis-12-dnsdir-telechat-rose-2022-11-02/ Alas no public reaction by the authors... I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Consensus boilerplate It is missing ;-) ### Section 2.2 Suggest to add a RFC editor note with a request to update the text when the official allocation is known (and redo the math of course). Last paragraph of section 10 should be more detailed. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
# Internet AD comments for draft-ietf-dnsop-rfc5933-bis-12 CC @ekline ## Comments * I'll defer to SEC ADs on the appropriate course of action, notwithstanding the fact that this is a bis of a previous Standards Track document.
I support Roman's discuss. I would rather see this document be published by the ISE than go through the IETF stream. My specific concern is than an operator who reads this RFC and doesn't know the context may not be aware that this may be an inappropriate algorithm to use. Even if this is published via the ISE channel then I think that it should be stated very clearly early in the document that the cryptographic properties haven't been independently verified. Regards, Rob