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

[Ondřej Surý <[e-mail]>]

Hi Peter and Paul,

> On 24 May 2020, at 19:43, Paul Wouters <[e-mail]> 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ý
[e-mail]