Subject: [DNSOP] kskroll-sentinel and unclear results

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 20 May 2018 19:29:44 -0700

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. If I'm the only one who 
finds this part a bit hidden, that's fine, and it can move on as-is.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Wed, 23 May 2018 14:49:09 -0400

On Sun, May 20, 2018 at 10:29 PM Paul Hoffman <[email-masked]> wrote:

> 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.
W​

> If I'm the only one who
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
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

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 24 May 2018 19:51:40 -0700

> ​I for one would like to see proposed text - we can decide from that 

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.

--Paul Hoffman

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 29 May 2018 23:46:53 +0000

> On May 24, 2018, at 7:51 PM, Paul Hoffman <[email-masked]> wrote:
> 
> 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.

Paul,

I took a look at your pull request.  I like the direction this is heading, and
I like the change from "invalid" to "bogus."  It leaves me with a couple
of questions though.

Your new second paragraph of section 3 says "this entire section is about
DNS resolution systems" and "we can classify DNS resolution systems into
five distinct behavior types" but the subsequent descriptions of Vnew,
Vold, etc still talk about a single resolver?

Similarly, in Appendix A should the text be changed so that, for example,
instead of saying "Bob is not using a validating resolver" it says "None
of the resolvers in Bob's DNS resolution system are validating"?

"All of Charlie's resolvers are validating..."?

"All of Dave's resolvers implement the sentinel method..."?

Nitpick: 

  "If a client directs these three queries to a DNS	
  resolution system where the resolvers have different propertied,
  the results cannot be determined."

Should be "properties" and I'd say "cannot be reliably determined."

DW

---

From: Warren Kumari <[email-masked]>
Date: Wed, 30 May 2018 14:23:39 -0400

> > I for one would like to see proposed text - we can decide from that
> > if it
> > makes things clearer.

> 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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 30 May 2018 14:26:16 -0400

On Tue, May 29, 2018 at 7:46 PM Wessels, Duane <[email-masked]>
wrote:

> >> I for one would like to see proposed text - we can decide from that if
it

> "All of Dave's resolvers implement the sentinel method..."?

Yup.

> Should be "properties" and I'd say "cannot be reliably determined."

Yup.

Thank you -- I'll queue these for integration when I do the pull request.
W

---

From: Geoff Huston <[email-masked]>
Date: Fri, 1 Jun 2018 09:49:25 +1000

> and want them to sanity check it for me.

Warren’s analysis indicates that when we apply the proposed tests to a user’s collection of resolvers (as distinct from a single resolver)  the proposed test methodology generates responses that may well be unclear at best, particularly when the collection of resolvers include validating and non-validating resolvers and resolvers that variously do and do not recognise this sentinel mechanism. So I’ve been thinking about a subtly different test methodology than that described in the draft that is intended to provide better clarification of the capabilities of the user’s DNS resolution environment.

Firstly a few assumptions that lie behind this proposed analysis methodology:

1) when the user passes a query to a resolver it will get a consistent answer (well consistent over the timeframe of queries). i.e. when the same question asked multiple times by the same user in succession to the same IP address, the DNS responses should give the same answer. (Job’s scenario where the same query passed to the same resolver IP address may generate different responses is a tough situation, and I have no idea just how prevalent this kind of variant behaviour is in any case).

2) all current DNSSEC-validating resolvers have KSK-2010 in their local trust anchor cache.

3) When a resolver returns SERVFAIL the user will re-query using the next resolver in the set. The user’s resolution process will conclude with a SERVFAIL if and only if all the resolvers in the user’s resolver collection have responded with SERVFAIL back to the user.

The modified test uses three queries:

a) a DNS name that is badly signed

b) a DNS name with the left-most label "root-key-sentinel-not-ta-<key-tag=of-ksk-2010>"

c) a DNS name with the left-most label "root-key-sentinel-is-ta-<key-tag=of-ksk-2017>"

(note that the keys referred to in queries b) and c) are different)

I'll describe the responses to these queries as either ‘A’, indicating that the A or AAAA query returned the desired RRset, or ’S’ indicating the the query returned SERVFAIL, and  I’ll describe the sequence of the three responses as the triplet (x x x) indicating responses to queries a, b and c in order.

Firstly, let’ look at the simple case of a single resolver:

If we get a response patter of the form (A * *) then the resolver is not validating, and will survive the key roll just fine.

If we get a response pattern of the form (S A *) then the resolver is validating, but the A response to query b) indicates that it does not recognise the sentinel queries, so we cannot determine its trusted key state.

If we get a response pattern of the form (S S S) then the resolver is validating, and the S response to query b) indicates that it recognises the sentinel queries, and the S response to query c) indicates that it has _NOT_ loaded KSK-2017 as a locally trusted key, and this resolver will not fare well when the KSK rolls.

If we get a response pattern of the form (S S A) then the resolver is validating, and the S response to query b) indicates that it recognises the sentinel queries, and the A response to query c) indicates that it has loaded KSK-2017 as a locally trusted key

Now lets look at the same three queries when used with a collection of resolvers and apply a similar exercise:

The set of possible responses are:

(A * *) - if any of the resolvers returns an A result to query a), then the user’s resolver set contains at least one non-validating resolver, and the KSK roll will not affect them (other than potentially lengthening the DNS resolution times I guess).

(S A *) if any of the resolvers returns an A result to query b) at least one of the user’s resolvers does not recognise the sentinel mechanism, and the behaviour of the collection of resolvers during the KSK roll cannot be reliably determined.

(S S A) implies that all of the user’s resolvers are validating resolvers, all of the user’s resolvers recognise the sentinel mechanism and at least one of the user’s resolvers has loaded KSK-2017 as a trusted key - the user is ok for the KSK roll.

(S S S) implies that all of the user’s resolvers are validating resolvers, all of the user’s resolvers recognise the sentinel mechanism and none of the user’s resolvers has loaded KSK-2017 as a trusted key - the user is NOT ok for the KSK roll.

This analysis approach in no way modifies the actual resolver mechanism described in the draft - the resolver actions are unaltered. The change described here is a change in a test mechanisms that is intended to disambiguate the case of a collection of resolvers where one or more resolvers does not not support this sentinel mechanism from the case where one or more resolvers in the collection has not loaded KSK-2017

Finally, as a personal opinion, not necessarily shared by anyone else, I also note its now June 2018 and the KSK roll appears to be scheduled for early October 2018. As fun as this exercise has been in trying to get this draft through the DNSOP Working Group’s processes, I fear that we are now too late to get this sentinel mechanism implemented and deployed in any meaningful manner to assist in providing meaningful data to inform us of the state of uptake of KSK-2017 before the scheduled KSK roll. That makes me a bit sad.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 31 May 2018 17:05:33 -0700

On 31 May 2018, at 16:49, Geoff Huston wrote:

> Warren’s analysis indicates that when we apply the proposed tests to 
> a user’s collection of resolvers (as distinct from a single 
> resolver)  the proposed test methodology generates responses that may 
> well be unclear at best, particularly when the collection of resolvers 
> include validating and non-validating resolvers and resolvers that 
> variously do and do not recognise this sentinel mechanism. So I’ve 
> been thinking about a subtly different test methodology than that 
> described in the draft that is intended to provide better 
> clarification of the capabilities of the user’s DNS resolution 
> environment.

This is an interesting new method of analysis! Are you thinking of 
updating the draft to include it? If so, I think that my proposed 
additions would be able to be updated to point to the new material.

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 31 May 2018 17:41:33 -0700

On 29 May 2018, at 16:46, Wessels, Duane wrote:

> I like the change from "invalid" to "bogus."

Great, thanks.

> It leaves me with a couple
> of questions though.
>

Now fixed.

> "All of Dave's resolvers implement the sentinel method..."?

I started to make this change, but it made some of the sentences quite 
awkward. Instead, I added a sentence at the top of the appendix that 
says "The examples here all assume that each person has just one 
resolver, or a system of resolvers that have the same properties."

> Should be "properties" and I'd say "cannot be reliably determined."

Now fixed.

--Paul Hoffman

---

From: Geoff Huston <[email-masked]>
Date: Fri, 1 Jun 2018 10:43:11 +1000

> On 1 Jun 2018, at 10:05 am, Paul Hoffman <[email-masked]> wrote:
> 
> This is an interesting new method of analysis! Are you thinking of updating the draft to include it? If so, I think that my proposed additions would be able to be updated to point to the new material.
> 

yes, I was going to update the draft, but wanted to keep the Working group updated.

g