On Thu, May 24, 2018 at 10:51 PM Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> On 23 May 2018, at 11:49, Warren Kumari wrote:
> > On Sun, May 20, 2018 at 10:29 PM Paul Hoffman <paul.hoff...@vpnc.org>
> > wrote:
> >
> >> Greetings. As I re-read the current draft of
> >> draft-ietf-dnsop-kskroll-sentinel, I'm feeling a bit uneasy about the
> >> description of "Vleg" and of what happens when you get a result that
> >> doesn't fit into the query/type table. The draft is fine for when the
> >> results are Vnew, Vold, and nonV, but it gets mushy for other
> >> results.
> >>
> >> It's just a name, but "Vleg" indicates that the resolver is a legacy
> >> validating resolver (that is, doesn't do
> >> draft-ietf-dnsop-kskroll-sentinel). As the document says, that's one
> >> possibility, but you can also get the same set of answers from a set
> >> of
> >> resolvers that validate and support the protocol, but don't all
> >> support
> >> the key whose Key Tag is in the query.
> >> Similarly, if all the client's resolvers support this mechanism,
> >> but
> >> some have loaded the key into the trusted key stash and some have
> >> not, then the result is indeterminate ("Vleg").
> >> The draft also uses "indeterminate" in other places for the result.
> >> Given that, calling it "Vleg" could lead implementers of tests to the
> >> wrong conclusion. Calling it "Vind" would be clearer.
> >>
> >> And this brings up the second point. The earlier sections of the
> >> draft
> >> mix saying that the tests are for "a resolver" and for "a system of
> >> resolvers". Although Section 4 does a good job of discussing the
> >> complications of measuring for a user that has more than one resolver
> >> that have different configurations, earlier sections make the
> >> protocol
> >> sound more definitive than it is.
> >>
> >> If others agree with me that the draft can use better language around
> >> these, I'm happy to offer new proposed text.
> >
> >
> > I for one would like to see proposed text - we can decide from that
> > if it
> > makes things clearer.
> The proposed text is at
> https://github.com/APNIC-Labs/draft-kskroll-sentinel/pull/21
> It's an omnibus change, so you might want to pick up parts, but I think
> as a whole it deals with the above concerns in a consistent fashion.
Thank you, I like most of the changes, but the primary text which addresses
the above question is:
"If the resolvers don't all have the same setup (such as if some validate
but others do not, or if those that validate don't all have the same root
KSKs trusted), the results of the sentinel test described in this document
may be indeterminate. For example, running the same test twice could get
different results if the different resolvers are queried in a different
order."
I believe that the ordering doesn't matter - it will always converge to the
same answer.
I've got a really long response to this, which shows all of the options in
all the different orders, but my co-authors are in different time-zones,
and want them to sanity check it for me.
Just didn't want you to think we were ignoring you.
W
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
