Subject: [DNSOP] draft-ietf-dnsop-delegation-only​: exchanging DS set

From: Vladimír Čunát <[email-masked]>
Date: Fri, 31 Jul 2020 11:00:48 +0200

Hello dnsop.

Let me start a simple thought experiment - attacking the planned
scheme.  It feels like I'm missing some part of the defense.

A .evil registry is using the DELEGATION_ONLY flag.  They additionally
sign a different victim.evil DS set, say adding hash of a DNSKEY they
generated themselves.  Now they could serve it e.g. to specific targets,
allowing .evil to control contents of the victim.evil subtree as seen by
those targets.  The defense against this will be logging!  So this DS
set along with its proof chain should get logged by some of the targets.

So far it's been clear.  But now... how do we know that this fake
victim.evil DS set was not submitted by the registrant?  I assume every
registrant is supposed to watch the logs from everyone for such fakes? 
Sounds OK-ish, so if they do find an incorrect set, they know that the
registry is "bad" (intentionally or not), but how can they prove *to
anyone else* that they did not submit it to the registry?

Without that ability I'd still feel quite powerless as a registrant, and
I currently can't see a nice way of solving that.  It would be nice if
there was a way we could get the ability in future (for reasonable costs).

- - -
I do support the aims of the draft, but so far the plan doesn't make me
feel safer, and deploying *all* the necessary parts doesn't seem very
easy either.  I'm sorry if I've missed something.  Well, *my* trust
isn't really important here, so if dnsop thinks the approach will
increase trust of some more important parties...

--Vladimir

---

From: Paul Wouters <[email-masked]>
Date: Fri, 31 Jul 2020 08:34:15 -0400

> anyone else* that they did not submit it to the registry?

A few things could be done.

The client could publish a CDS set which would never include the rogue DS.

The log could look and explicitly warn for “fast DS changes and undo”, since this would be flipping back and forth.

The process of a rogue parent is not a purely technical one. It can include a legal system, a payment dispute, and many other things.

Per definition, it will be a manual process to confirm if a “changed child” is a legitimate change or not. Logging helps this process.

But remember, forcing a rogue parent into this mode is already a win we currently don’t have.

> there was a way we could get the ability in future (for reasonable costs).

Some DS flip flopping can be detected so a warning can be issued to the registrant or a public entity. So the registrant isn’t entirely powerless. But contacting the registrant is still tricky if you cannot trust the info from the parent (eg whois)

> easy either. 

All the necessary parts is one bit and a few lines of code and a tool option. It’s not that much. The real work happens by log operators.

> I'm sorry if I've missed something.  Well, *my* trust

Forcing parents into mucking with their customer DS records itself is a big win. The parent now has an Enigma Problem and is more or less guaranteed to be found out it’s cheating it’s own published policy.

Paul