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

Tony Finch <dot@dotat.at> Fri, 25 September 2020 22:52 UTC

Return-Path: <dot@dotat.at>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91293A0A56 for <dns-privacy@ietfa.amsl.com>; Fri, 25 Sep 2020 15:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdasHxLMuh2n for <dns-privacy@ietfa.amsl.com>; Fri, 25 Sep 2020 15:52:49 -0700 (PDT)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB8D3A08D6 for <dns-privacy@ietf.org>; Fri, 25 Sep 2020 15:52:49 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:59126) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1kLwa7-000HNk-gB (Exim 4.92.3) (return-path <dot@dotat.at>); Fri, 25 Sep 2020 23:52:47 +0100
Date: Fri, 25 Sep 2020 23:52:46 +0100
From: Tony Finch <dot@dotat.at>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
In-Reply-To: <b645ce6fe1539287ba8a4a7dcf2f48059d043ec8.camel@powerdns.com>
Message-ID: <alpine.DEB.2.20.2009252215450.18300@grey.csi.cam.ac.uk>
References: <4b3271ee-e796-3102-1ead-d1f9a3137514@innovationslab.net> <CAHbrMsCvbxi0q7X5TGkDq_kOVPecVYhYm4VF6UD75U=tKsiyGg@mail.gmail.com> <b645ce6fe1539287ba8a4a7dcf2f48059d043ec8.camel@powerdns.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/n1WTfxcM95G3m_zoVYfC2w_wbCc>
Subject: [dns-privacy] the rec/auth dot problem, was Re: Call for adoption: draft-vandijk-dprive-ds-dot-signal-and-pin
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Sep 2020 22:52:52 -0000

Peter van Dijk <peter.van.dijk@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  <dot@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.