Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-kskroll-sentinel-15: (with DISCUSS and COMMENT)

Good additions, warren

Joao

> On 27 Sep 2018, at 01:35, Warren Kumari <warren@kumari.net <mailto:warren@kumari.net>> wrote:
> 
> Thank you for providing text. I put that in the GitHub version.
> 
> 
> W
> 
> On Wed, Sep 26, 2018 at 3:13 PM Paul Hoffman <paul.hoffman@vpnc.org <mailto:paul.hoffman@vpnc.org>> wrote:
> On 26 Sep 2018, at 14:30, Warren Kumari wrote:
> 
> > On Wed, Sep 26, 2018 at 12:40 PM Paul Hoffman <paul.hoffman@vpnc.org <mailto:paul.hoffman@vpnc.org>> 
> > wrote:
> >
> >> On 26 Sep 2018, at 12:07, Warren Kumari wrote:
> >>
> >>> On Wed, Sep 26, 2018 at 11:16 AM Benjamin Kaduk <kaduk@mit.edu <mailto:kaduk@mit.edu>> 
> >>> wrote:
> >>>
> >>>> On Wed, Sep 26, 2018 at 10:12:08AM -0700, Warren Kumari wrote:
> >>>>> On Wed, Sep 26, 2018 at 8:16 AM Benjamin Kaduk <kaduk@mit.edu <mailto:kaduk@mit.edu>>
> >>>>> wrote:
> >>>>>
> >>>>>> Benjamin Kaduk has entered the following ballot position for
> >>>>>> draft-ietf-dnsop-kskroll-sentinel-15: 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/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> >>>>>> for more information about IESG DISCUSS and COMMENT positions.
> >>>>>>
> >>>>>>
> >>>>>> The document, along with other ballot positions, can be found 
> >>>>>> here:
> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----------------------------------------------------------------------
> >>>>>> DISCUSS:
> >>>>>> ----------------------------------------------------------------------
> >>>>>>
> >>>>>> Thanks for preparing this document and mechanism; it is good to
> >>>>>> have
> >>>> more
> >>>>>> data about the expected impact of the root KSK roll.  That said, 
> >>>>>> I
> >>>> have two
> >>>>>> Discuss-worthy points, albeit both fairly minor.
> >>>>>>
> >>>>>> The first one may just be something that I missed, but does this
> >>>> document
> >>>>>> actually say anywhere that there needs to be a real zone with 
> >>>>>> real
> >>>>>> configured A and/or AAAA records for the query names used for 
> >>>>>> these
> >>>> tests?
> >>>>>> The Appendix sort-of-mentions it, but I feel like there needs to 
> >>>>>> be
> >>>>>> a
> >>>>>> mention in the main body text.
> >>>>>>
> >>>>>>
> >>>>> No hats (OMG, everyone will see I'm going bald...)
> >>>>>
> >>>>> Ok, fair. This was actually a source of confusion when we first
> >>>>> started
> >>>>> discussing the document -- we explained it on-list / at mics / in
> >>>>> person,
> >>>>> but it became so well understood that we didn't notice that it is
> >>>>> not
> >>>>> actually specified in the document. I'll try figure out text.
> >>>>
> >>>> Thanks.
> >>>>
> >>>> It eventually became pretty clear to me from things like "return 
> >>>> the
> >>>> A or
> >>>> AAAA response unchanged" that there was supposed to be a valid
> >>>> response
> >>>> provisioned so that it could be returned, but I don't want to rely 
> >>>> on
> >>>> all
> >>>> readers making the same inference.
> >>>>
> >>>>
> >>> So I opened my editor to add text, and scrolled down to try figure 
> >>> out
> >>> where to add this.
> >>> "Section 4.3 - Test Procedure" seemed like a good spot -- and it
> >>> already
> >>> has this text:
> >>>
> >>> A query name containing the left-most label
> >>> "root-key-sentinel-not-ta-<key-tag-of-KSK-current>". This name MUST 
> >>> be
> >>> a
> >>> validly-signed. ***Any validly-signed DNS zone can be used for this
> >>> test.***
> >>> A query name containing the left-most label
> >>> "root-key-sentinel-is-ta-<key-tag-of-KSK-new>".. This name MUST be a
> >>> validly-signed. ***Any validly-signed DNS zone can be used for this
> >>> test.***
> >>>
> >>> (emphasis mine).
> >>>
> >>> Does this perhaps address your concerns?
> >>
> >> It should not: Section 2.1 specifically says that the query must be 
> >> for
> >> A or AAAA.
> >>
> >>
> > Ah, I think I'm starting to understand...
> >
> > A query name containing the left-most label
> > "root-key-sentinel-not-ta-<key-tag-of-KSK-current". This name MUST be 
> > a
> > validly-signed name." cover it?
> > I'd tried putting in stuff like "in a public zone" (but this isn't 
> > actually
> > true, I could do this entirely in a private namespace if I only wanted 
> > to
> > test a closed network).
> > Or perhaps: "This name MUST be a validly-signed name in a validly 
> > signed
> > zone"? (which is somewhat redundant, but makes it clearer)?
> >
> > Any suggestions?
> 
> Ben asked for the text to appear early, so I think that putting it in 
> the last section before the Security Considerations doesn't really 
> count. :-)
> 
> How about in Section 2.2 where the document defines the special 
> processing. Adding a last sentence to the last paragraph might clear 
> things up:
>     The answer for the A or AAAA query is sent on to the client.
> 
> --Paul Hoffman
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>    ---maf
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnsop