Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-rfc5933-bis-12: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
