Peter van Dijk <peter.van.d...@powerdns.com> 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 <d...@dotat.at> 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. _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
