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

[Paul Wouters <[e-mail]>]

On Sat, 23 May 2020, Peter van Dijk wrote:

> As I remarked in my reply to Jeremy, I spent quite some time thinking
> about how to do the signalling&pinning with actual TLSA records, but I
> never ended up with a satisfactory solution.

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.


I think it is worth it to take a step back and consider what we are
trying to protect here.

If we are trying to prevent someone from seeing I am going to go to
nohats.ca, then revealing I'm querying for the DNSKEY RRset for
nohats.ca means we already failed. So I'm going to define DNS privacy
as "Prevent leaking information that I am going to domain XXXX". It
hardly matters what we query of domain XXXX. The content of the A record
is not the loss of privacy. The loss of privacy is that we were trying
to go to domain XXXX.

Let's assume we can connect to the .ca nameservers securely and
privately. We query for nohats.ca. If there is no DS, all bets
are off as the child cannot signal anything to us securely. If
there is a DS, we also got NS records, and possibly A/AAAA glue.

In the case of getting A/AAAA glue, we can connect using DoT if
we knew this was an option (eg signaled in the DS record).

In the case of getting only NS records, we would have to securely and
privately look up those records first. Let's say we get ns.example.com
and no glue, we go through another iteration of this until we get A/AAAA
glue and can connect using DoT if the DS record could have signaled
this.

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.

Conveying that you can do DoT using DS can only really be done by
overloading the record type. I don't like it, but the other other
choice we have to opportunistically just try port 853, and in 20 years
perhaps we can shut down port 53 like we are now getting ready to shut
down port 80. The opportunistic part is tricky, because it does allow
an attacker to RST/filter your 853 connection and downgrading you to
plaintext - where as if we signal this in the DS record, we could
prevent downgrade and hard fail if privacy is that important to us
that we prefer not to connect over leaking that we are trying to
connect. If we don't want to hard fail, then I think we should just
drop this draft and use opportunistic. If we want to offer hard fail,
then some draft is still useful.

I would use the keytag record set to 0 to mean this DS record is not
a real DNSKEY but "something else". Whether you need anything else
is debatable. You could use the digest field to stuff in a public key.
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. You can optimize
this with False Start, Session Resumption, etc.

At the child, you can leave a CDS record of the identical special DS
record at the parent, as cryptogrpahic proof that the special DS record
for DoT at the parent was actually something the child wanted its parent
to publish.  Again, this would require another round trip to confirm
that the parent wasn't sending you to a rogue nameserver. But at least
you are ensured the parent isn't running a global TLS MITM nameserver
that logs and forwards all queries.

No additional pseudo-DNSKEYs are needed.


In your draft, you cannot connect with privacy until you obtain the
base64 encoded TLS key embedded in the DNSKEY RRset. I'm saying this
is too late - you already revealed the only important bit of
information, that you are trying to visit "nohats.ca". There might
be exceptions, like subdomain.wordpress.com or subdomain.livejournal.com
but in 99% of the cases, the domain name itself is the valuable
information to keep private.

> 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. With the amount of CNAME's splattered all over the
world, I think trying to hack around avoiding a roundtrip is not worth
it. Especially for DNSKEY/DS records, which should not have TTL=1 and
are happilly cached for extended periods of time.

As I pointed out above. If you want to protect losing privacy to a rogue
parent, a number of additional roundtrips are required anyway. Saving
one of them isn't worth creating pseudo-DNSKEY records for.

Paul