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

[Peter van Dijk <[e-mail]>]

On Fri, 2020-05-29 at 11:59 -0400, Paul Wouters wrote:
> On Fri, 29 May 2020, Peter van Dijk wrote:
> 
> > > - Takes DNSKEY, only does syntax checks ---> we dont need to publish anything
> > 
> > Yes.
> 
> Actually I was wrong. We still need to publish something so the child
> proves the parent was not maliciously publishing a DS record. So we
> would probably publish it as a CDS to keep it out of the DNSSEC
> validation path and make it easy to compare parent DS to client CDS.

I know you have spent a lot more time thinking about attacks from a
parent to a child zone, so I'm probably missing something that's
obvious to you.

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.

> > > - Takes DNSKEY, but verifies it is a supported algorithm --> we have to convince them to support our pseudo alg
> > 
> > Yes, and, we found out and will put in -01: to allow 'weird' flags for
> > at least that algo.
> 
> 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)

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/