Re: [DNSOP] Updated KSK Sentinel document

[神明達哉 <[e-mail]>]

At Wed, 21 Feb 2018 08:53:23 -0500,
Warren Kumari <[e-mail]> wrote:

> > - General
> >   I think it's worth pointing out that SERVFAIL can be returned for
> >   various other reasons and the detection mechanism relying on it
> >   isn't reliable.  This is probably okay given the purpose of this
> >   detection, but I think it's better to note it explicitly.
>
> Good point. I had some trickiness writing this - how is "The
> techniques describes in this document rely on (DNSSEC validating)
> resolvers responding with SERVFAIL (RCODE 2) to valid answers. Note
> that a slew of other issues can also cause SERVFAIL responses, so
> false positive or negative results may sometimes occur." ?

Works for me, except that I might avoid 'false positive/negative' as
it's often ambiguous or confusing (exactly what "false positive" means
depends on the context).  I'd personally say something like "..., so
the sentinel processing (Section 4) may sometimes result in incorrect
conclusions".  But that's probably minor in the entire context of this
document, so I'd leave it to you.

> > - Section 3
> >
> >    [...]  Note
> >    that the <tag-index> is specified in the DNS label using hexadecimal
> >    notation.
> >
> >   I suggest clarifying whether '<tag-index>' contains leading 0s
> >   somewhere in the document (this may not be the best place to do so,
> >   but this is the first reference to 'tag-index' that made the
> >   question occur to me).
>
> Hmmm... Good point. I personally actually preferred having these as
> "decimal" keys.
> RFC1034, Sec 5.3: The DS RR Presentation Format sayeth:
>    " The Key Tag field MUST be represented as an unsigned decimal
> integer.", things like dig +multiline DNSKEY . shows it as decimal,
> etc.
> My initial demos (www.ksk-test.net) also all used decimal. Petr
> recently pointed out to me that I'd messed up, and so I converted my
> demo to use hex, as the draft states.
> What does the WG prefer? Is the new KSK called "20326" or it is "4f66"?
>
> Note that Knot Resolver 2.1  already implements (thank you!) this, and as hex.
> But, yes, either way, we need to note if it is padded.
> [TODO(WK): Raise the hex vs Dec issue]

Personally I don't have a strong opinion/preference on hex vs decimal
or with or without leading zeros as long as it's clearly specified.
But I see the point of preferring the decimal representation you
showed above.  https://data.iana.org/root-anchors/root-anchors.xml
also uses the decimal representation, so especially if we expect the
usage of this query by a human operator who builds the query name by
hand, it would be more convenient if it's consistent with other common
representations, which is currently decimal.  But again, I don't have
a strong opinion.

> > - Section 3
> >
> >    If the resolver has not placed a
> >    Root Zone Key Signing Key with tag index value matching the value
> >    specified in the query into the local resolver's store of trusted
> >    keys, then the resolver should return a response indicating that the
> >    response contains authenticated data according to section 5.8 of
> >    [RFC6840].
> >
> >   Should we perhaps define "store of trusted keys" more precisely?
> >   For example, if a key is in the "AddPend" status (per RFC5011) for
> >   the resolver, should it be considered in the "store of trusted
> >   keys"?
>
> Nope. Well, yes, we need to better define it, but no, a key in AddPend
> is not considered.
> We explicitly mean "keys which are active and can be used for
> validating entries in the root zone."

To be clear, I didn't think a key in the "AddPend" state is considered
to be in the "store of trusted keys".  I just pointed out that it may
not be super clear.  And so...

> We have: "In particular, this response mechanism can be used to
> determine whether a certain Root Zone KSK is ready to be used as a
> trusted key within the context of a key roll by this resolver."
> and I added:
> "An active key is one which could currently be used for validation (ie
> not in AddPend or Revoked state (RFC5011)).
>
> Sounds reasonable?

yes it does.

> >   BTW, you might want to say 'a query for an Address Record' or 'an
> >   Address Record query' instead of 'an A or AAAA query' (I guess
> >   that's the intent of the introduction of this term.  See also my
> >   first comment on Section 1.1 above).
>
> Actually, there are small enough number of occurrences that explicitly
> listing them (and not creating a new term) seemed better, so (see
> ablove) I removed the "Address Record" term and left in the "A or
> AAAA" stuff - please let me know if you agree.

Works for me.

--
JINMEI, Tatuya