Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

[Ben Schwartz <[e-mail]>]

I want to reiterate that I support the goal of this draft.  I just think
the claimed benefits need to be more precise.  I think Petr is right: this
is mostly because we don't agree on what transparency looks like.
Specifically, we need to understand both (a) what transparency logging
requires without this flag and (b) how it is easier with this flag, in
order to compare them and identify the benefit.

Take .org as an example.  Per Joe's description, .org is not
DELEGATION_ONLY, but it is "mostly delegation only".  Knowing this, we can
start transparency-logging the org zone.  The DELEGATION_ONLY flag isn't
needed, and wouldn't substantially help, for this single case.

I think this flag does help overall.  For example, assuming we can make it
usable by some TLDs, I think it is a sufficient indicator that a TLD is
suitable for logging, avoiding the human effort of investigating those
TLDs' practices.  (I also think it greatly reduces the chance of
_accidental_ impersonation, which might be enough justification on its own.)

With or without this flag, I think we'll also want to log many zones that
are "mostly delegation only".  We might even need a different flag that
says "this zone is suitable for logging", or the inverse, but has no effect
on the resolution process.  Alternatively, perhaps those zones can be
curated manually out-of-band, like the PSL.

>
On Thu, Jul 30, 2020 at 4:28 PM Paul Wouters <[e-mail]> wrote:

> On Thu, 30 Jul 2020, Ben Schwartz wrote:
>
> >       I do not believe that is correct. The first and foremost purpose
> is for
> >       the bit to signal the parent zone's behaviour in a public way that
> >       prevents targeted / coerced attacks from the parent.
> >
> > I would love to see some more description of these attacks in the draft.
>
> I'm a bit confused that you think describing that in more detail helps.
>
...

>From this conversation, it seems like these attacks are achievable, and are
detectable by logging, with or without the DELEGATION_ONLY flag.  I was
trying to understand if the flag can sometimes _prevent_ the attack, e.g.
when there are cached DS records.  However, a prevention claim requires
much more text on possible attack modes (e.g. can the parent shorten TTLs
to enable the attack?).

> Does the targeted attack still> apply if the recursive resolver does
> QNAME minimization?
>
> It is unrelated to query minimalization, other than that targetted
> attacks in response to specific queriers is harder.
>

That seems like an important mitigation.  Does this rely on the attacker
inserting "deep" Additional records?

> From the current text, I'm having trouble understanding why it matters
> whether the attacker has to
> > generate a fake child zone or not (in the absence of transparency).
>
> The attacker could do the above (or even just present glue pretending
> the nohats.ca is unsigned, thereby leaving out cryptographic traces).
> If it is forced to generate a new DS for his attack to succeed, and they
> are forced to publish this at large (eg because query minimalization)
> then any monitoring of DS records will get them caught.
>

You said above that this flag "prevents" targeted attacks, but I think here
you are saying that it only _deters_ these attacks, provided that logging
or monitoring is in place.  (I don't really understand the difference
between logging and monitoring.)  I want this deterrence!  I also want to
be precise about the motivation.

...

> > The draft says that universal logging "would require zone owners to
> expose all their zone data ... thereby
> > introducing privacy implications".  This seems to apply whether or not
> the zone is delegation-only, so DNS
> > resolvers would be violating this proposed privacy principle unless the
> zone somehow indicates that it
> > opts in to logging.
>
> That statement applied to when we do not have this bit and we would want
> to ensure no queries every violated the implicit delegation-only role.
>

I don't understand.  What privacy implication would apply to contentful
zones, but not to delegation-only zones?  In my experience, the main
privacy concern expressed by zone owners is about the list of names, not
the content of any records.  (Hence NSEC3, NSEC5, etc.)

If I believe that names under corp.mycompany.example are supposed to be
secret, then presumably I don't want them showing up in public logs due to
an overzealous stub resolver on my network.  Yet there's no reason
corp.mycompany.example couldn't be DELEGATION_ONLY.

Again there is no "submission" of zone data to a log anywhere in this
> system by the authoritative zone operator. I will talk to Wes about
> changing this text.
>
>
> >       On an empty DNS cache, I'm quite literally broadcasting the
> largest DNS
> >       fingerprint possible to identify my. My only change at hiding is
> to have
> >       a local DNS cache.
> >
> >
> > If you move IP addresses without wiping your DNS cache, your cached DNS
> entries become a supercookie by
> > which a distant server can reidentify you across the network.
>
> That is why you use prefetching and ideally the resolver you are using
> also uses prefetching, so that hot data (eg data that is regularly
> queried for while it is still in the cache) is pre-fetched before
> expiry. And no direct IP link exists between you and the auth server.
>

I don't think that helps.  A website at example.com can easily put $
userid.example.com into your local (and recursive) cache, with long TTL,
CNAMEd to example.com.  Then, it can remove $userid from its zone.  From
now on, when a client connects via a different recursive, example.com can
check if it's you, by telling the client to connect to $userid.example.com.
If that works, you must be the same user.  (Fancier variations can scale
better.)

This is off-topic except to say: the caching recommendation is not obvious,
is not necessary, and should go in a different draft (if it is indeed the
group's consensus).