[dns-privacy] the rec/auth dot problem, was Re: Call for adoption: draft-vandijk-dprive-ds-dot-signal-and-pin

[Tony Finch <[e-mail]>]

Peter van Dijk <[e-mail]> wrote:
>
> (and I agree with Paul Hoffman and others that we have plenty of
> proposals, fully worked out or not, but not a lot of agreement on what
> the actual shape is of the problem we are solving.)

At what level of detail is it not clear? The problem I see is that none of
the plausible ways to a solution are particularly attractive. The overall
shape of the problem has always seemed to me to be straightforward to map
out. Here's a quick sketch, not going into too much detail and with plenty
of gaps.


Problem: given a referral, how can a resolver find out which (if any)
authoritative servers support DoT (or some other private transport)
without leaking any of the query (especially the qname)?

Solution 1: no signalling

Solution 2: signalling in the DNS message protocol

Solution 3: signalling in the DNS zone data tree

Solution 4: signalling outside the DNS

(I'll unpack these below)


Observation: if there is an authenticated signal then authenticated
encryption and unauthenticated encryption are equally difficicult, so
there's no benefit and significant loss of security to do DoT without
authentication.


Observation: a lot of these solution sketches add multiple round trips to
the query time (even if you don't count TLS connection setup), so I won't
mention it as a problem every time, even though latency is important for
choosing between them. (this is just a sketchy map not a michelin guide)


Solution 1.1: just try DoT

Problem 1.1.1: Trying the connection is likely to be slow because SYN
packets to unexpected ports are often silently dropped.

Problem 1.1.2: There isn't a reliable way to authenticate the server:
many delegations use non-canonical authoritative server names so even
if the server supports DoT its certificate is likely to have the wrong
name.

Problem 1.1.3: TOFU authentication doesn't support rollover.


Solution 1.?: any others under the "no signalling" header?


Problem 2: in-protocol upgrades are subject to downgrade attacks


Solution 2.1: use RFC 8490 DSO to do STARTTLS

Problem 2.1.1: everyone hates STARTTLS

Problems 1.1.2 and 1.1.3 apply to solution 2.1 (and also 1.1.1 unless
you are very optimistic)


Solution 2.2: send a preflight request to ask about DoT support

Problem 2.2: if the request goes over UDP it might not always go to
the same server, so this solution implicitly requires clustered
servers to have very tightly matching configurations.

Question 2.2: does it look like a normal query and if so what is the
qname?


Solution 2.2.1: qname is a special-use name something.arpa

Problem 2.2.1.1: can't be authenticated so 1.1.2 and 1.1.4 apply


Solution 2.2.2: qname is the server name

can be authenticated

Problem 2.2.2.1: requires server to be authoritative for its name

Problem 2.2.2.2: leaks the zone name for in-bailiwick delegations


Solution 2.2.3: qname is the zone name

can be authenticated

Problem 2.2.3.1: not very private, is it?

Problem 2.2.3.2: awkward to put information about the server in every
zone it serves - co-ordination problem between server operators and
zone owners


Solution 2.?: any other in-protocol upgrades?


Solution 3.1: signalling in the delegation

can be authenticated

Problem 3.1.1: EPP

Problem 3.1.2: instead of being O(servers) the provisioning problem is
at least O(zones) and maybe O(zones*servers)

Problem 3.1.3: operator vs registrant vs registrar communications


Solution 3.2: signalling at the server name (or TLSA-style prefixed
server name)

can be authenticated

Problem 3.2.1: leaks the zone name for in-bailiwick delegations


Solution 3.3: signalling at the server IP address reverse DNS (or
TLSA-style prefixed reverse DNS)

can be authenticated

Problem 3.3.1: might have awkward dependency loops between forward and
reverse DNS

Note 3.3.2: need to explain why this is OK for DoT when we thought it was
not for ACME


Solution 3.4: DoT lookaside zones (think DLV)

Problem 3.4.1: relies on more third parties for authentication

Problem 3.4.2: where does the data come from and how do we know it is
correct?


Solution 3.5: signalling in the parent zone separate from the
delegation (like example._dot.com)

Problem 3.5.*: similar to 3.1.*


Solution 3.?: surely I have covered all the plausible options for
putting this in normal DNS data?!


Problem 4.1: difficult to do out-of-DNS signalling and avoid
centralization

Problem 4.2: these generally rely on a third party (outside the zone's
delegation path) for authentication

Problem 4.3: can these options scale big enough?

Problem 4.4: where does the data come from and how do we know it is
correct?

Solution 4.1: distribute a big public DoT server list (think public
suffix list)

Solution 4.2: rather than distributing a big list, use k-anonymity
like Troy Hunt's pwned passwords query API

Solution 4.3: parent zone has a pointer to a non-DNS DoT server list
and/or non-DNS query API server

Solution 4.?: any others?


Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Southwest Biscay: Northwesterly becoming cyclonic, 6 to gale 8, perhaps severe
gale 9 later. Rough or very rough. Rain or showers. Good, occasionally poor.