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:

>> - Takes DS, but verifies it is a real DNSKEY at the child --> we create bogus DNSKEY matching our DS request
>
> I am hoping, also for 'normal' DNSSEC reasons (like key rolls) that no
> registry does this.

Yes, hopefully, they will limit themselves to checking that DNSSEC
validation with the new DS RRset works - and not try to be clever on
individual DS records.

>> - 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.

>> - 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.

> (Incidentally you might one day run into the same question with
> DELEGATION_ONLY, although a zone delegated from a registry would not be
> a common place for that flag)

Yes I know, it is a similar problem but hopefully smaller.

Paul