[DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-rfc5933-bis-12: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-dnsop-rfc5933-bis-12: No Objection 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/ -- COMMENT: -- # É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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements
On 25/11/2022 18.26, Daniel Migault wrote: So let me know how we came to this lines and I suspect we do share some similar concerns. A recurrent question and reticence we receive from MNO and ISPs regarding DNSSEC is that they are really scared about having the cache with incoherent RRsets in their cache that causes the validation to fail and in many cases they imagine a mechanism to prevent and address such incoherent data in the cache. One of the intentions of this draft is to prevent such mechanisms to be implemented - mostly as it is likely to generate errors that DNSSEC experts would not be able to catch or understand - as generated by the home made solutions. As a result we wanted to minimize the change to the DNSSEC mechanic and only rely on very simple and standard mechanisms. 4033 provided one way to limit some incoherencies, and we also thought of a similar mechanism that was like the one described in I-D.ietf-dnsop-ns-revalidation which as we saw it ensures something like a mechanism that refreshes the chain of trust. I get that in countries with low validation rates [1] it may be difficult to explain to resolver operators that it should be only the authoritative side who worries that they "do DNSSEC wrong". Maybe I'm also personally biased against putting much work to work around mistakes done on the other side of the protocol. [1] https://stats.labs.apnic.net/dnssec What we expect is that the validator proposes this option and as such the DRO selects that option in the validator if present. Well, OK. Well yes, I'm in favor of keeping the supported-algorithm set centralized internet-wide, instead of trying to start deploying a decentralized mechanism. [...] I mainly wanted to dissuade from early algorithm deprecation on validator side. [...] I got your point and agree it might be counter productive to encourage a mechanism that is not reliable. I propose to remove the text below: [...] OK. I don't see the part about extended errors as problematic (RFC 8914). It really seems to be getting into (open-source) implementations and it can help with debugging in some cases, though deploying it is probably not very important either. Oh! sure for the TA. My understanding of the text is that it recommends 5011 for running instances, but that new instances are configured with up-to-date TA that in most cases are updated by software update. So yes I agree and will check this appears clearly. I don't think 5011 is worth doing at all. Maybe in some exceptional use cases. Well, I haven't heard much about deployment experience with non-root TAs, so perhaps I just don't know those well. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-thomassen-dnsop-mske: DNSKEYs in non-apex
Hi Vladimir, Thanks for your feedback! Please see below. On 11/11/22 19:01, Vladimír Čunát wrote: It's not a major thing in your design, but I see a risk that DNSKEYs at non-apex might have trouble validating, so at some point I'd expect your proposal to choose a different approach (e.g. allocate a new identical RR type) or at least confirm that it won't be a major problem. I agree that this would be a significant risk if the consumers of these records were the general public, who generally use whatever resolver without paying specific attention or controlling any of the moving pieces. However, the records would only be processed by supporting DNS operators, and it is entirely in their hands to use a resolver that would allow such validation. As such, I don't see any risk that would not be exposed immediately during implementation/testing, and the fix is also trivial. IMO, this means that nothing needs to be done about it on the spec side. What do other think about the significance of that risk? Thanks, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-thomassen-dnsop-mske: DNSKEYs in non-apex
I didn't explain why, so let me add just a short pointer. No need to go deeper here at this point of the draft, I think. On 28/11/2022 19.26, Peter Thomassen wrote: As such, I don't see any risk that would not be exposed immediately during implementation/testing, and the fix is also trivial. Triviality of a fully correct fix may depend on the particular implementation. Note the implications for caching, etc. These DNSKEYs will be DNSSEC-validated but must not be used for validation of other signatures. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Roman Danyliw's Discuss on draft-ietf-dnsop-rfc5933-bis-12: (with DISCUSS and COMMENT)
Hi! > -Original Message- > From: iesg On Behalf Of Paul Hoffman > Sent: Thursday, November 17, 2022 7:06 PM > To: Roman Danyliw > Cc: The IESG ; draft-ietf-dnsop-rfc5933-...@ietf.org; dnsop- > cha...@ietf.org; dnsop@ietf.org; Tim Wicinski > 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 > 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
