Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson <[e-mail]>]

On Wed, Feb 8, 2017 at 2:41 PM, Mark Andrews <[e-mail]> wrote:

>
> In message <[e-mail]>, Ted Lemon
> writes:
> >
> > On Feb 8, 2017, at 3:30 PM, Mark Andrews <[e-mail]> wrote:
> > > And if the service has the same privacy issues as .onion has?
> > >
> > > So we leak names until every recursive server in the world is
> > > validating (what % is that today?) and supports agressive negative
> > > caching (still a I-D).
> >
> > I feel like I am arguing with a wall, so if this doesn't work I will just
> > give up.   But if it's okay for us to ask resolvers to make a chance, it
> > is okay for us to ask resolvers to make the right change.   And if they
> > don't, yes, it's possible that some queries will leak.   There is nothing
> > we can do to prevent that other than harden caching servers and stub
> > resolvers; if we are going to do that, we might as well do it right, by
> > caching the full proof of nonexistence, rather lying about what's in the
> > root zone.
>
> Actually we can do something that doesn't require that validation
> be enabled.  We don't have to create that linkage.  It's not like
> the names are not supposed to exist.  They do/will exist and not
> as in they are/will be squatted upon.
>

I'm confused here.

The point of ALT (and/or LCL if a 2nd draft is created), and ONION, is that
they exist ONLY within their own (local) scope, if they exist at all.

>From the viewpoint of the global DNS, they do not exist, and the point of
those I-Ds/RFCs is to enforce that non-existence, in the global scope.

My problem with what you are proposes, is that it removes the mechanism for
that enforcement.

Here's a thought - for any/all validating stubs, use CD=1 for names in the
set of "things that are meant to be local", and turn off validation of
those.
That *should*, if I understand 4035's directives for CD=1, prevent
validation by the recursive resolver in use by the client, and will return
whatever answers are present, with or without DNSSEC records.

Or, perhaps the organizations that represent the requestor of the 6761
names, could establish something like a "distrust anchor" - a trust anchor
which is only to be used for signing negative assertions about the TLD
name, or assertions about its insecure status to enable local service of
the TLD name, and which can be published to the community, along with a
static DNS zone file to be served by the <name>-aware resolvers?

Again, just to reiterate, in the global root zone, and for any resolvers
which are not yet onion-aware, onion does not exist and must not exist.

For onion-aware resolvers, everything related to onion is just an
optimization; avoiding leakage for privacy reasons might be an issue for
some folks, but IMHO must not tread on the previous requirement - that
onion must not exist in the root, and must not appear to exist to any
onion-unaware resolvers.

If you want to find a way to fix that, without resulting in BOGUS or
SERVFAIL, there may be ways that aren't easy, but the one way not permitted
by the published RFCs is, an unsigned delegation in the root.

I'm not sure why you disagree with this, it is clear as day in the relevant
RFCs.

Brian




>
> Oh sorry, you can't have privacy unless you validate.  And only
> because people are too scared to ask for changes to the root
> zone to add a delegation.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
>