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

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

Hello Ondřej,

On Tue, 2020-05-26 at 09:10 +0200, Ondřej Surý wrote:
> >    Bit 7 of the Flags field is the Zone Key flag.  If bit 7 has value 1,
> >    then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's
> >    owner name MUST be the name of a zone.  If bit 7 has value 0, then
> >    the DNSKEY record holds some other type of DNS public key and MUST
> >    NOT be used to verify RRSIGs that cover RRsets.
> 
> and also:
> 
> >    The DNSKEY RR is not intended as a record for storing arbitrary
> >    public keys and MUST NOT be used to store certificates or public keys
> >    that do not directly relate to the DNS infrastructure.
> 
> So, while my first though was same as Paul’s - this is abuse…  I came to
> conclusion, it actually isn’t.
> 
> That said - I think this needs some modifications:
> 
> 1. Bit 7 of the Flags fields needs to be 0.

Definitely - it is not explicit but the examples in draft -00, and the
PoC code, all use 0 for the flags. In 
https://github.com/PowerDNS/parent-signals-dot/issues/20 I noted
earlier that whatever flags we might need, it's definitely *not* ZONE
and SEP.

> 2. This needs a new Protocol number

I understand why you would say that, but I'd love to avoid doing that.
I wonder how much 'IETF' pain specifying another protocol number would
be, but what worries me more, ironically, is how it changes the format
away from normal DNSSEC. The draft was written such that a lot of
existing software needs no changes at all - I don't know if changing
the protocol number is compatible with that goal.

> 3. And since we now have non-„DNS zone key“ with a different protocol we might get a separate IANA registry for the algorithms (if needed).

We liked this, until we realised it will be painful with DS records.

Because the protocol number is not visible in the DS records, a 'pin
signal algo 8' and 'DNSSEC RSASHA256' DS are indistuingishible from
eachother. While validators should accept this, it will make tools like
dnsviz very hard to use if assignments between the existing and this
new registry overlap. So, we'd have to state that the two registries
may not issue overlapping assignments, in which case we might as well
stick with the one registry we have.

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