Subject: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 14 Dec 2017 17:51:10 -0800

Please see 
<https://github.com/APNIC-Labs/draft-kskroll-sentinel/pull/1>. This is a 
small set of changes that make the draft not treat the root zone as 
special. It allows the labels to be used for any zone, not just the 
root.

--Paul Hoffman

---

From: Geoff Huston <[email-masked]>
Date: Fri, 15 Dec 2017 16:45:46 +1100

Hi Paul,

> On 15 Dec 2017, at 12:51 pm, Paul Hoffman <[email-masked]> wrote:
> 
> Please see <https://github.com/APNIC-Labs/draft-kskroll-sentinel/pull/1>. This is a small set of changes that make the draft not treat the root zone as special. It allows the labels to be used for any zone, not just the root.
> 

Could you please elaborate on the motivation here? I am unsure whether this is needed, or, perhaps more critically, I’m unsure if this represents a harmless general form of information disclosure (that the resolver is using local trust keys for some unspecified non-root zone).

I agree the mechanics of the change in the text, and even in the code for support this are pretty minor, but I am slightly worried about the intended generality of the proposed change being a small step too far, so I am curious to understand why you are advocating this change.

regards,

   Geoff

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 15 Dec 2017 07:31:45 -0800

On 14 Dec 2017, at 21:45, Geoff Huston wrote:

>> Please see 
>> <https://github.com/APNIC-Labs/draft-kskroll-sentinel/pull/1>. This 
>> is a small set of changes that make the draft not treat the root zone 
>> as special. It allows the labels to be used for any zone, not just 
>> the root.
>>
>
> Could you please elaborate on the motivation here?

The last sentence is the motivation. Some operators add trust anchors 
for things other than the root to their validating resolver, and a user 
might want to know if such a trust anchor exists and, if it does, what 
the key tag is.

> I am unsure whether this is needed, or, perhaps more critically, I’m 
> unsure if this represents a harmless general form of information 
> disclosure (that the resolver is using local trust keys for some 
> unspecified non-root zone).

Serious question: in your mind, why is the answer for non-root zone any 
more "information disclosure" than for the root zone?

> I agree the mechanics of the change in the text, and even in the code 
> for support this are pretty minor, but I am slightly worried about the 
> intended generality of the proposed change being a small step too far, 
> so I am curious to understand why you are advocating this change.

Because the root zone is not special for DNSSEC.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Fri, 15 Dec 2017 10:37:17 -0500

> Because the root zone is not special for DNSSEC.

I agree with that philosophically, but not practically.

In practical terms anybody who has a non-root trust anchor installed has a bidirectional operational relationship with the people who publish it. Synchronising that trust anchor, with the glorious benefit of a full list of relying parties and knowledge of how to interact with them, is a far cry from the situation we find ourselves in with the root zone.

While it's conceptually elegant to have this mechanism easily available to the operator of nameservers for any zone, it's not clear to me that this is supported by a tangible use case.

If changes motivated by this desire for elegance weaken support for the one use case we have, they seem like a bad idea. (Not saying they do; I haven't thought about them that hard and in any case I am not an implementor.)

Joe

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 15 Dec 2017 07:48:10 -0800

On 15 Dec 2017, at 7:37, Joe Abley wrote:

>>> I agree the mechanics of the change in the text, and even in the 
>>> code for support this are pretty minor, but I am slightly worried 
>>> about the intended generality of the proposed change being a small 
>>> step too far, so I am curious to understand why you are advocating 
>>> this change.
>>
> In practical terms anybody who has a non-root trust anchor installed 
> has a bidirectional operational relationship with the people who 
> publish it. Synchronising that trust anchor, with the glorious benefit 
> of a full list of relying parties and knowledge of how to interact 
> with them, is a far cry from the situation we find ourselves in with 
> the root zone.

Fully agree. But you don't say why that should prevent a resolver's user 
from testing that.

> While it's conceptually elegant to have this mechanism easily 
> available to the operator of nameservers for any zone, it's not clear 
> to me that this is supported by a tangible use case.

A TLD operator who doesn't really like the fact that ICANN and Verisign 
control the contents of the root zone declares that their KSK has tag 
12321 and will have that tag until further notice. They suggest that 
everyone who wants to trust them should install their current KSK as a 
trust anchor because who knows what evil or incompetent thing ICANN and 
Verisign will do in the future. A user wants to see if their resolver 
operator has done so.

(I wish this was far-fetched. Since starting to work for ICANN, I have 
been told **by people on this list** that this could happen for their 
TLDs.)

> If changes motivated by this desire for elegance weaken support for 
> the one use case we have, they seem like a bad idea. (Not saying they 
> do; I haven't thought about them that hard and in any case I am not an 
> implementor.)

Thinking hard about the above use case is very unpleasant, I admit. It 
indicates that some TLD operators might make validation for their own 
zones more fragile. And yet it is discussed more regularly than you 
would hope.

--Paul Hoffman

---

From: Matt Larson <[email-masked]>
Date: Fri, 15 Dec 2017 11:11:41 -0500

> On Dec 15, 2017, at 10:48 AM, Paul Hoffman <[email-masked]> wrote:
> 
> A TLD operator who doesn't really like the fact that ICANN and Verisign control the contents of the root zone declares that their KSK has tag 12321 and will have that tag until further notice. They suggest that everyone who wants to trust them should install their current KSK as a trust anchor because who knows what evil or incompetent thing ICANN and Verisign will do in the future. A user wants to see if their resolver operator has done so.
> 
> (I wish this was far-fetched. Since starting to work for ICANN, I have been told **by people on this list** that this could happen for their TLDs.)

Even if someone says "this could happen for their TLD", I think the sentiment is really "they fear that this could happen for their TLD". And people are afraid of a lot of things that have an extremely low probability of occurring, which is the territory we're in when it comes to fearing that ICANN would do something "evil or incompetent" with the root zone. Since I've been at ICANN, I've been impressed with the extent to which the community's wishes drive what the organization does, and since the IANA transition, there are no actors besides the ICANN community to influence root zone management.

As for Verisign, they are ICANN's contractor for root zone management, so they are prohibited by contract from doing anything evil, and Verisign's competence when it comes to root zone management is not a thing I worry about.

So having been on the inside of both ICANN and Verisign, I can state without hesitation that concern about evil or incompetence regarding root zone policy and management should be low on everyone's list.

Matt

P.S. Though this message is in reply to Paul, he knows all of this and I'm stating it for the record.

---

From: Matt Larson <[email-masked]>
Date: Fri, 15 Dec 2017 11:24:02 -0500

> On Dec 15, 2017, at 10:37 AM, Joe Abley <[email-masked]> wrote:
> 

I'm not convinced that even in the scenario you describe the trust anchor publisher could really count on knowing all the relying parties. And even if they did, a mechanism to give visibility would still be desirable, even in that controlled situation.

I think there should be a very high bar for making any zone special in the protocol. In this case, I don't see the harm in making the sentinel mechanism more general, especially if implementations offer controls to disable it on a per-zone basis. With my root zone KSK roll responsibility hat on, I'd sure like for this mechanism to be enabled by default. In that case, an operator could have the ability to shut off sentinel on secret.example but easily leave it enabled for the root.

Matt

---

From: Joe Abley <[email-masked]>
Date: Fri, 15 Dec 2017 11:34:28 -0500

> I'm not convinced that even in the scenario you describe the trust anchor publisher could really count on knowing all the relying parties. And even if they did, a mechanism to give visibility would…

That seems fair. I was definitely speaking from a set of personal assumptions without any data; it's certainly possible that non-root trust anchors are widely deployed, however much I haven't seen it.

Joe

---

From: Ralph Dolmans <[email-masked]>
Date: Fri, 15 Dec 2017 18:31:35 +0100

Hi,

On 15-12-17 02:51, Paul Hoffman wrote:
> special. It allows the labels to be used for any zone, not just the root.

I agree that a mechanism that works for all trust anchors (like RFC8145
does) is preferable. I am, however, not sure that this suggestion works.

If I understand this proposal the idea is to use the keytag to find the
correct TA. This might work for most cases but it is possible to have a
non-root TA with the same keytag as the root. Or someone can, for some
weird reason, configure the root key as one of the entries for a local TA.

For this mechanism to work, the validator need to know the TA's zone.
This can be done by always using the root or by signaling the TA name,
for example in the query. The latter can be as simple as using the TA
for the qname without the special label. So:

- _is-ta-<tag-index>.example.com. -> applies for example.com TA
- _is-ta-<tag-index>. -> applies for root TA

In this case only the root zone manager can control the test addresses
for the root TA, which some might see as a downside. Also, Geoff's
remark about information disclosure still stands.

If the consensus is that this mechanism only has to work for the root TA
then this should be made more clear in the document. The document now
talks a lot about "a key in a trust store" instead of the root key. It
only becomes clear somewhere halfway the 2nd section that it only works
for the root TA.

Some other remarks regarding the draft-ietf-dnsop-kskroll-sentinel document:

The three times SERVFAIL case in section 4 can be distinguished from a
SERVFAIL for another reason by using a 4th query for a signed domain
without special labels. If only that one succeeds you know for sure that
a key roll will give issues, unlike in the indeterminate (Vleg) state.

Is there a reason why this mechanism should only be applied for A and
AAAA queries?

"if the left-most label of the original query name matches the template
"_is-ta-<tag-index>.""
The trailing dot should not be part of the label.

If this mechanism should only work for the root TA, what should a
validator do when the queried for name is covered by a non-root TA? Not
applying this mechanism, or applying it for the unused root TA?

Some editorial nits:
- trust anchor vs Trust Anchor, both used in document
- section 2: aplied -> applied
- section 3, Vleg: "RRSET" -> "RRset"
- section 3, Vleg: "an A record" -> "an A or AAAA RRset"

Regards,
-- Ralph Dolmans

---

From: Geoff Huston <[email-masked]>
Date: Thu, 21 Dec 2017 05:30:28 +1100

> On 16 Dec 2017, at 2:37 am, Joe Abley <[email-masked]> wrote:
> 

I share Joe’s concern here - I prefer the option of a simple, focussed mechanism that reports on a resolver’s root Zone KSK trust state. 

I’ll leave this open, but will not incorporate Paul’s proposed changes into the WG draft unless I see some further WG comments in favour of making this proposed change.

regards,

   Geoff

---

From: Geoff Huston <[email-masked]>
Date: Thu, 21 Dec 2017 05:34:08 +1100

> On 16 Dec 2017, at 2:31 am, Paul Hoffman <[email-masked]> wrote:
> 
> The last sentence is the motivation. Some operators add trust anchors for things other than the root to their validating resolver, and a user might want to know if such a trust anchor exists and, if it does, what the key tag is.
> 
>> I am unsure whether this is needed, or, perhaps more critically, I’m unsure if this represents a harmless general form of information disclosure (that the resolver is using local trust keys for some unspecified non-root zone).
> 
> Serious question: in your mind, why is the answer for non-root zone any more "information disclosure" than for the root zone?

I suppose that I am concerned that a resolver is disclosing that it has some other trust point in the name space. 

I would normally have thought that such choices of trust are choice a resolver makes, but does not necessarily need to reveal to third parties.

Geoff