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

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
<brian.peter.dickson@gmail.com> wrote:
> 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>