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

From: Brian Haberman <[email-masked]>
Date: Mon, 10 Aug 2020 07:44:03 -0400

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: Ben Schwartz <[email-masked]>
Date: Mon, 10 Aug 2020 10:07:53 -0400

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.

On Mon, Aug 10, 2020 at 7:44 AM Brian Haberman <[email-masked]>
wrote:

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 10 Aug 2020 17:26:37 +0200

Moin!

> 2-week call for adoption to determine the WG's interest in this work.
I oppose adopting this draft. The problems space of connecting recursive
to authoritative currently has a lot of solution type drafts in 
different
working groups. There is this draft here, draft-tapril-ns2 in dnsop and
draft-pauly-add-resolver-discovery in add. So the working group chairs
have first to figure out where to discuss the problem (here is fine) and
then discuss them all or finish work on 
draft-ietf-dprive-phase2-requirements
first. Just adopting this one would narrow us to much as once something 
is
out it’s hard to remove it.

> end on 2020-08-24 at 23:59 UTC.
I assume you mean the adoption call will end then ;-).

So long
-Ralf
—--
Ralf Weber

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 10 Aug 2020 15:54:15 +0000

I oppose adopting this draft at this time. There seemed to be interest in the WG to focus on use cases first, and this draft is an instantiation of an use case that is not clearly identified. Once that use case is identified, the WG can decide whether this draft is a good potential solution for the use case.

FWIW, I could certainly believe that I would support this draft later, after the use case is clarified and other ideas for that use case are bounced around.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 Aug 2020 21:43:00 -0400 (EDT)

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

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. As I suggested, TLSA records on the nameserver FQDN's avoids
this problem.

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

Paul

---

From: "John Levine" <[email-masked]>
Date: 12 Aug 2020 14:39:09 -0400

In article <[email-masked]> you write:
>synchronise their nameserver TLS keys.

Why wouldn't you publish multiple DS records for multiple nameserver
keys, like the draft says? We have multiple DS for multiple DNSKEYs.

>wishes of the childen within the TLD.

I don't understand the issue. How is that any different from now? If a
parent publishes a DS with a key that doesn't match a child DNSKEY,
the child loses.

R's,
John

PS: I am not 100% sure I like this draft but I like it enough to adopt it
and work on it.

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 13 Aug 2020 01:13:08 +0200

> keys, like the draft says? We have multiple DS for multiple DNSKEYs.

Yes, they would.  Zones would surely publish their new DS additionally
to the old one, but you don't want to use the corresponding cert until
*all* of them have done so (+TTL).  Well, you could tell them that
unless they fail to do so by some deadline, the zones may get broken
because of this...