Subject: [DNSOP] Validating stubs? Was: Re: WG review of draft-ietf-homenet-dot-03

From: Brian Dickson <[email-masked]>
Date: Wed, 22 Mar 2017 16:08:25 -0700

I was thinking about the DNSSEC validation by stubs, with respect to the
homenet discussion.

And, I was wondering about various trust anchor options (other than ICANN's
current root trust anchor).

It occurred to me, that any non-ICANN trust anchor, would possibly require
5011 key rolls under certain circumstances.

Which begs the question: are validating stub resolvers presumed to be
5011-capable?

But, I realize, the issue of 5011 capability also exists for the root trust
anchor.

So, the dilemma is:

   - Can we assume 5011 stub support regardless?
   - If not, does this make the DNSSEC issue for homenet moot, since the
   root KSK will be rolled in the near future (for some value of "near
   future"), and break stub validation?

On the other hand, if 5011 support by stubs is assumed, there is one
interesting option:

Establish a trust anchor for homenet (whatever name is used), AND publish
the private keys.

This creates the ability to have a master DNS authority server, in any
given homenet instance, sign the data in the homenet zone. The default
software could/would need to ship with the trust anchor, and the private
key. The out-of-the-box behavior would just work, and would verify/validate
properly for validating stubs that ship with the homenet trust anchor.

There would then be the ability for users running their own homenet
networks, to do the equivalent of changing the default password -- they
would be able to do a 5011 key roll, which would cause the default trust
anchor to be replaced with a unique trust anchor for that specific homenet.

It's not part of the homenet standard (yet), but might be worth thinking
about.

Again, the main question is, has an assumption about 5011 support in stubs
been made, and is it a valid assumption?

If not, to re-emphasize, then the "unsigned delegation" thing isn't even
necessary, since the stub resolvers won't be able to validate ANYTHING.

Brian

---

From: George Michaelson <[email-masked]>
Date: Thu, 23 Mar 2017 09:19:17 +1000

Your question is well timed. with DNSSEC keyroll happening, the
question: "what level of 5011 deployement" exists is unanswerable with
authority because the architects did not consider signalling of
capability sufficiently trustable. So we have no direct measure of
capability, and a weak, indirect sense of deployment from other
signals of capabilities which would imply post-5011 capable code, but
cannot say if a locally maintained hand-installed TA is in use.

So the question "is it assumed" is a good one. I think the answer is
"yes, we design for the assumption DNS now is enabled for 5011, or
else is owning its problems"

-G

On Thu, Mar 23, 2017 at 9:08 AM, Brian Dickson
<[email-masked]> wrote:
> Can we assume 5011 stub support regardless?
> If not, does this make the DNSSEC issue for homenet moot, since the root KSK
> will be rolled in the near future (for some value of "near future"), and
> break stub validation?
>
> This creates the ability to have a master DNS authority server, in any given
> homenet instance, sign the data in the homenet zone. The default software
> could/would need to ship with the trust anchor, and the private key. The
> out-of-the-box behavior would just work, and would verify/validate properly
> for validating stubs that ship with the homenet trust anchor.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Mar 2017 22:05:10 -0400

On Mar 22, 2017, at 7:08 PM, Brian Dickson <[email-masked]> wrote:
> Establish a trust anchor for homenet (whatever name is used), AND publish the private keys.

Homenet is not a globally unique namespace.   No such trust anchor can be established.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Mar 2017 05:01:40 +1100

In message <CAH1iCiq6nVGMpv7c1UVc8SurOWLQK1DViETof4W06tRXes=[email-masked]>
> necessary, since the stub resolvers won't be able to validate ANYTHING.

The output state of the validator is "secure", "insecure" and "bogus".

Without a insecure delegation the only result a validator can return is
"bogus".

With a insecure delegtion we get "insecure" by default and when the
client gets a trust anchor for "homenet", it can return "secure",
"insecure" and "bogus".

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]