[DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-rfc5933-bis-12: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

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:
----------------------------------------------------------------------

(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/


----------------------------------------------------------------------
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