Hi Peter and Paul, > On 24 May 2020, at 19:43, Paul Wouters <[email protected]> wrote: > > But I don't think your current solution is satisfactory either. It is > basically the same thing we told djb about dnscurve - you cannot abuse > an RRtype for something else. Whether you put a pubkey in the NS record > LHS, or a TLS key inside a DNSKEY - you are abusing the RRtype system. > > But I also don't see the gains of abusing DNSKEY, because you already > need to query the DNSKEY of the domain to get the pesudeo-DNSKEY key, > and then you already lost your privacy.
So, the RFC4034 has to say something about DNSKEY: > 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. 2. This needs a new Protocol number 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). I think only then it won’t feel like an abuse of the protocol. Cheers, Ondrej -- Ondřej Surý [email protected]
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
