Subject: [DNSOP] Dropping the draft "The DELEGATION_ONLY DNSKEY flag"

From: Tim Wicinski <[email-masked]>
Date: Thu, 5 Aug 2021 11:12:44 -0400

All,

This came up in the poll, but also the discussion on priorities.  There
seems to be
strong feelings on dropping this draft.   We adopted with the idea that if
we could
not find WG consensus, we were not going to advance it, and that seems to
be the case.

The document is here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-only/

If anyone feels that DNSOP should keep working on this, please speak up.

We will let this call to drop run until 18 August 2021

thanks
tim

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Aug 2021 16:34:23 -0400 (EDT)

On Thu, 5 Aug 2021, Tim Wicinski wrote:

> Subject: [DNSOP] Dropping the draft "The DELEGATION_ONLY DNSKEY flag"

> This came up in the poll, but also the discussion on priorities.  There seems to be
> strong feelings on dropping this draft.   We adopted with the idea that if we could
> not find WG consensus, we were not going to advance it, and that seems to be the case.

We had several people in favour of the experiment, and Joe Abley against
it. May I know how you determined the lack of consensus versus the in
"in the rough" ? Especially since in this case, we are talking about
something that is completely optional to implement and deploy, so that
people who don't like it find zero negative effects from this.

> The document is here:  https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-only/
> 

Note that from a point of view of "work", the biggest issues were ENT,
which were addressed based on the ideas of Paul Vixie, and orphan glue,
for which simple solutions exist (eg move it to a dedicated zone, eg
orphan-glue.tld)

I understand some people feel the experiment has no value to them. But
should the WG really prevent the experiment? It also comes with an
additional risk that there will appear "adhoc solutions" that try
to implement the "delegation only" policy based on hardcoded lists, due
to the lack of parental signaling for this.

Paul

---

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

It appears that Paul Wouters  <[email-masked]> said:
>We had several people in favour of the experiment, and Joe Abley against it.

I know I have repeatedly said why this draft is not useful, and I don't recall anyone but
you who still wants it.

Perhaps we could let our WG chairs do the chairing.

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Aug 2021 17:18:54 +0000

On Aug 9, 2021, at 1:34 PM, Paul Wouters <[email-masked]> wrote:
> I understand some people feel the experiment has no value to them.

As far as I can tell after reviewing the archives, none of the people who supported moving the "powerbind" draft to be a WG item indicated that the draft had any value to them. Now that the draft has matured more, it is clear that there is likely no real value unless a DNS transparency log is widely deployed (see the last paragraph of Section 3.1).

> But
> should the WG really prevent the experiment?

Yes. The proposal is:
- complicated (see Section 5, which is still quite under-specified)
- only useful if delegation-heavy zones adopt it
- only useful if resolver operators implement it to introduce a new resolution failure mode
- of no real value to those delegation-heavy zones

> It also comes with an

Such lists would not work well, particularly for zones that have (or might ever have) _labels in names at the apex. But, if there is enough interest in ad hoc solutions in this space, the WG could react to those in the future with this proposal or one that is better.

--Paul Hoffman

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 23 Aug 2021 20:58:49 -0400

Hi,

The chairs have discussed the DELEGATION_ONLY draft extensively. It’s reasonable to ask how we reached the conclusions we did, so here’s what we were thinking.

> On Aug 9, 2021, at 4:34 PM, Paul Wouters <[email-masked] <mailto:[email-masked]>> wrote:
> 

Multiple people who are not Joe Abley have spoken up, in this thread and previously, to question the usefulness of the draft. 

As a relatively minor point, calling the flag allocation an “experiment” is a bit confusing without a hypothesis or a way to assess the outcome. In any case, a standards track RFC is required to modify the DNSKEY FLAGS registry (https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml#dnskey-flags-1 <https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml#dnskey-flags-1>)— not Informational or Experimental. The DNSKEY FLAGS field is small and there’s no provision for calling back the code point delegation from IANA if the “experiment” fails.

The larger point is that it’s not clear what demand there is for this feature. The draft discusses TLDs almost exclusively, which is a limited use case. In previous discussion on the draft, more than one person asserted that some TLDs, including very large ones, may sometimes rely on the behavior this flag is designed to obstruct, so are extremely unlikely to ever deploy it. Others expressed skepticism regarding the costs and benefits the flag provides over other, higher-probability attacks. 

It’s always possible we overlooked something, but there’s no implementation status discussed in the current draft, and we also didn’t see anyone speaking up for a TLD that would deploy the DELEGATION_ONLY flag if they had it. 

It seems to us that consensus to support the draft would include substantial evidence that the feature would be implemented and used.

We’d be willing to re-open WG consideration of this draft if implementers or TLD operators speak up in support. 

Suzanne/Tim/Benno

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 23 Aug 2021 22:07:34 -0400

All

The Working Group Last Call for draft-ietf-dnsop-dnssec-iana-cons ended
last week, and we've filtered through the comments both pro and con.

We feel there is rough consensus to move this forward.

thanks

Benno/Suzanne/Tim

---

From: Paul Wouters <[email-masked]>
Date: Tue, 24 Aug 2021 08:52:54 +0300

> The chairs have discussed the DELEGATION_ONLY draft extensively. It’s reasonable to ask how we reached the conclusions we did, so here’s what we were thinking.

Thanks for this recap and explanation.

> As a relatively minor point, calling the flag allocation an “experiment” is a bit confusing without a hypothesis or a way to assess the outcome.

The outcome would manifest itself in TLD adoption. But as you said the demand or willingness seems low at this point, so the chairs conclusion seems fair (though imho unfortunate)

Paul