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/ _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
