Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[Paul Wouters <[e-mail]>]

On Fri, 29 May 2020, Peter van Dijk wrote:

> I'm not even sure what my question is, so let's try this: if a
> malicious parent has the ability to publish a malicious DS record, why
> wouldn't that parent also change the NS records in some subtle way?
> Then the real client side CDS becomes invisible. I have trouble seeing
> a specific combination of attacker choices that makes sense here.

If a parent is coerced to publish a DoT DS record pointing to a government
run server, the child has no way to defend itself against this, unless
it can confirm in the child zone that the DoT DS is in fact the child
zone policy.

I wouldn't want .ca to start publishing national mandatory DoT servers.
Requiring confirmation of the child zone prevents this, as .ca cannot
put CDS records into my zone signed by my DNSKEY.

For a parent to be co-erced with requiring child zone confirmation,
it basically has to take over the entire child because it needs the
childzone to confirm its roque DS. Which is quite different from just
"publishing an additional DS record in their legally owned zone". Asking
the .ca people to publish a DS record is one thing. Asking them to take
over all .ca zones is quite another.

Yes, a targeted victim with an empty cache is going to lose from any
malicious parent willing to confiscate its child zone. If you have
some cache already, this is a little harder for targetted attacks,
and would have to be done publicly for everyone to see (and audit log)

We can also log the authentication chain of the DoT records. When did the
child pusblish CDS records to be picked up by the parent for DS. When
did the parent change DS records pointing to different DNSKEY records
(whether DNSKEY for resolving or DNSKEY for DoT)

See also the DELEGATION_ONLY and DNSSEC Transparency efforts we are
working on. A new (DoT) DS and CDS would be an auditable event similar to
the Certificate Transparency of seeing a new EE-cert. Cooperating clients
can log these somewhere public as to guarantee that any malicious DS/CDS
record created by the parent for a targetted attack would very likely be
caught by the child owner and become public knowledge, to be resolved by
layer 8.

>> See my other email about DNSKEY algo 253 and 254. Since that's in the RFC,
>> you will have a better case arguing they have to support those.
>
> Assuming we (our draft, or some loosely related variant like the couple
> of other proposals in this thread) get to RFC, IANA will assign a
> number (or perhaps even before that). I'm not worried about getting the
> algo number on the registries' allowlist.. eventually.
>
> (see my reply to the other email, that I had missed before, for why I
> think 253/254 are not appropriate)

The fact that current software is not properly ignoring these algorithms
is not the best argument for not using them. I do think it is
interesting to use these because they already come with pre-buildin
concepts of FQDN's before putting in "arbitrary data based on who is
using it for what". It would arguably be less of a squatting on the
DNSKEY record than the current proposal. But I'm okay to try to use a
new algorithm number first, and if squatting becomes an issue moving
forward, we can always pick one of these two.

It is much more important that we agree on the MUST vs MAY of client
side confirmation of DoT servers at the parent.

Paul