Hi! > -----Original Message----- > From: iesg <iesg-boun...@ietf.org> On Behalf Of Paul Hoffman > Sent: Thursday, November 17, 2022 7:06 PM > To: Roman Danyliw <r...@cert.org> > Cc: The IESG <i...@ietf.org>; draft-ietf-dnsop-rfc5933-...@ietf.org; dnsop- > cha...@ietf.org; dnsop@ietf.org; Tim Wicinski <tjw.i...@gmail.com> > Subject: Re: [Ext] [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop- > rfc5933-bis-12: (with DISCUSS and COMMENT) > > On Nov 17, 2022, at 3:02 PM, Roman Danyliw via Datatracker > <nore...@ietf.org> wrote: > > ---------------------------------------------------------------------- > > 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. > >
[snip] > It feels like this DISCUSS ballot is asking for a non-IETF-stream RFC to > obsolete > an IETF-stream RFC. Yuck. Instead, it might be better to publish this in the > IETF > stream; separately, the IESG could then publish a statement that future > national algorithm documents should not come through the IETF stream. I agree that we need to be careful on what a non-IETF stream document would do to an IETF-stream document. As a counter proposal, I would recommend that we use the flexibility afforded by RFC6014 and RFC9157 to address our current situation, and split the document. The document has several components: (a) Specification of and guidance for new DNSKEY and RRSIG behavior using GOST R 34.10-2012 and GOST R 34.11-2012 (i.e., Section 2 - 6, 9) (b) Guidance to obsolete/update previous RFC5933/RFC8624 behavior per (a) (i.e., Section 7, 8) (c) Request new IANA registry entries for (a) (i.e., Section 10) (d) Request updates to IANA registries to deprecate older GOST code points specified by IETF-stream documents (i.e., Section 10) Components (a) and (c) could be extracted from this document and added to a new document published by the ISE. This text is the new national crypto that the WG cannot render judgement on per my DISCUSS. The remaining text, components (b) and (d), would be the reduced draft-ietf-dnsop-rfc5933-bis document and would reference this new ISE document with the appropriate caveats on the confidence the WG in this new ISE reference. This reduced draft-ietf-dnsop-rfc5933-bis document would be the compromise where an IETF-stream document is needed to redefine previously specified behavior so that an ISE-stream document wouldn't have to obsolete an IETF-stream one. If (when) GOST R 34.10-2012/GOST R 34.11-2012 is superseded (and assuming it remains national crypto), algorithm revisions can be handled entirely by the ISE. Regards, Roman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
