Subject: Re: [dns-privacy] Call for adoption: draft-vandijk-dprive-ds-dot-signal-and-pin

From: Brian Haberman <[email-masked]>
Date: Mon, 21 Sep 2020 14:13:05 -0400

Hi all,
     The chairs have determined there is currently no support to adopt
this document at this time. The chairs encourage the authors and the WG
to discuss how this approach may inform the phase 2 requirements draft.

Regards,
Brian

On 8/10/20 7:44 AM, Brian Haberman wrote:
> Hi all,
>      During the DPRIVE session at IETF108, we discussed adopting
> https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/
> and the results were inconclusive. The chairs would like to start a
> 2-week call for adoption to determine the WG's interest in this work.
> 
>      Please respond to the mailing list with your view (positive or
> negative) and supporting rationale on adopting the draft. This WGLC will
> end on 2020-08-24 at 23:59 UTC.
> 
> Regards,
> Brian & Tim
>

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 25 Sep 2020 22:01:31 +0200

Thanks Brian, that is my reading of the thread as well. I agree that
the conversation that's been had provides ample input for the
requirements draft.

> > end on 2020-08-24 at 23:59 UTC.

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

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 25 Sep 2020 22:06:25 +0200

Hi Paul,

On Tue, 2020-08-11 at 21:43 -0400, Paul Wouters wrote:
> I am against adoption for two reasons. The draft as it currently is,
> requires that domain name owners and nameserver hosting administrators
> synchronise their nameserver TLS keys. This is impossible to do at
> scale.

For various reasons, also unrelated to this draft, I hope that syncing
problem gets solved some day!

> Second, this method introduces a possible national MITM by the TLD being
> able to put in TLD wide DS records that might be published against the
> wishes of the childen within the TLD. A protection mechanism via the child
> confirming the parent record with a CDS record would address this concern.

I saw no appetite for that from other WG participants, which is why
this has not made it to the text, but I'm still not opposed to it.

> I truly wish the idea would work. And I still believe a DNSKEY bit on
> the DNSKEY to signal encrypted DNS availability would be worth pursuing.

As I said before, if this is the contribution that makes some other
draft work, I'll also be happy :)

Kind regards,

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 25 Sep 2020 22:09:45 +0200

Hi Ben,

On Mon, 2020-08-10 at 10:07 -0400, Ben Schwartz wrote:
> I do not support adopting this draft as-is.  I think this construction is very clever, and points us in the right direction for authentication, but it's extremely inflexible in regard to the transport protocol and key updates.  As the draft notes, "a change in TLS keys on an auth may require DS updates for thousands or even hundreds of thousands of domains", which may not be under the administrative control of the authoritative server operator.  This seems likely to make key rotation effectively impossible in many potential deployments, as rotation cannot occur until _all_ customers have updated their zones.
> 
> This draft could be suitable for "experimental" status, but for a "standards track" document I think we should start with a design that addresses these problems.

Because I still believe this approach would work for many domain owners, I think experimental would make perfect sense, but at this point I'm unsure the WG even has appetite for that, and that is very understandable.

(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.)

Kind regards,

---

From: Tony Finch <[email-masked]>
Date: Fri, 25 Sep 2020 23:52:46 +0100

Peter van Dijk <[email-masked]> 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  <[email-masked]>  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.