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

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

On Sun, 2020-05-24 at 13:43 -0400, Paul Wouters wrote:
> 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.

The draft says 'The pseudo DNSKEY record MUST NOT be present in the
zone.' What can we add to the text to make it clear that no query is
sent to the zone's name servers -until- their TLS key has been
verified?

> If the DS record somehow conveyed "yes you can do DoT", you can now
> connect to that IP on port 853 and send your query. We still need to
> authenticate this TLS channel.

In our proposal, the DS record conveys 'do DoT' and also authenticates
the TLS channel.

> Conveying that you can do DoT using DS can only really be done by
> overloading the record type.

Which field do you mean by 'the record type'? We chose the algorithm
field for it.

> If we don't want to hard fail, then I think we should just
> drop this draft and use opportunistic.

This draft, that signals and key-pins, with hard failure, would not
prevent an opportunistic draft/RFC to also exist.

(But, repeating myself from another reply, with my 'resolver developer'
hat on, and on behalf of our users with their 'resolver operator' hats
on, opportunistic is a software complexity and user-experienced-latency 
burden that I'm not a big fan of.)

> If we want to offer hard fail,
> then some draft is still useful.

Why not this draft then? :)

> I would use the keytag record set to 0 to mean this DS record is not
> a real DNSKEY but "something else".

This will require changes in registry software all over the world, or
some hack . I'm not saying that's prohibitive, but our draft is the way
it is because this is one of the many hurdles we wanted to avoid.

> Whether you need anything else
> is debatable. You could use the digest field to stuff in a public key.

We stuff the hash of the public key (with the rest of the DNSKEY format
prefixed) in the DS.

> Then you can connect to the nameserver, and presuming that it is a
> large DNS hoster like godaddy, you could verify the TLS connection
> before sending your first nohats.ca related query.

Which is exactly what the draft provides.

> In your draft, you cannot connect with privacy until you obtain the
> base64 encoded TLS key embedded in the DNSKEY RRset.

No, that's simply not the case. Apparently the draft is unclear - can
you help us make the language better so this confusion does not occur?

> > Also, as Petr pointed out, our DNSKEY/DS-based proposal does not
> > involve additional queries and thus roundtrips; as far as I can
> > imagine, anything using TLSA would need extra queries.
> 
> I don't believe a working solution cannot be allowed to introduce an
> extra roundtrip.

I also do not believe that, but it's nice that we can do without the
extra roundtrip anyway!

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