Subject: [DNSOP] IETF meeting prep and what

From: Tim Wicinski <[email-masked]>
Date: Wed, 16 Jun 2021 19:38:58 -0400

All

The chairs have been doing prep work for the upcoming IETF meeting; one
issue that we are working on is reaching out to authors whose working group
documents have recently expired. While doing this, Benno did some
datatracker stuff and ended up with this list

https://datatracker.ietf.org/doc/search?name=draft-ietf-dnsop&sort=&olddrafts=on&by=group&group=DNSOP

Which goes back to 1999 and has lots of old cruft.

We chatted with our IESG Overlord Warren, and we're looking at gracefully
removing drafts we’re unlikely to work on or advance from the datatracker’s
view of the WG. The intent is that they won’t clutter a list that’s
supposed to help WG chairs and contributors track what we’re actively
working on.

Our plan is to release from the WG all drafts that were last updated prior
to 1 January 2016. This action may create some emails to the mailing list
or the authors, and we want to make you aware of this before we start.

All documents from 1 January 2016 onward are open for discussion.   For the
older documents that are left - if someone wishes to take them on, please
reach out.

Thanks

Benno/Suzanne/Tim

---

From: Warren Kumari <[email-masked]>
Date: Thu, 17 Jun 2021 10:58:54 -0400

On Wed, Jun 16, 2021 at 7:39 PM Tim Wicinski <[email-masked]> wrote:

> All documents from 1 January 2016 onward are open for discussion.   For
> the older documents that are left - if someone wishes to take them on,
> please reach out.
>
Thank you very much, chairs!

While having a discussion with the IESG, I had a look at the number of
Active Drafts that we have, and compared it to other workinggroups -- DNSOP
currently has 14 listed, with 3 in some form of publication requested
(draft-ietf-dnsop-iana-class-type-yang, draft-ietf-dnsop-nsec-ttl,
draft-ietf-dnsop-rfc7816bis), leaving 11 "active" ones. Only 6 WGs have
more than this, and some of these are in states like "Implementation
needed", etc.

I think it would be good if we could try and clear some of the active queue
(and any expired WG documents that we still want to work on) before
adopting many new documents. This isn't "no new work!", but rather "let's
try to prioritize existing work first". The intent here is to allow us to
focus more on each individual document, and not have our attention
scattered between so many.

W

Poorly organized data here:
https://docs.google.com/spreadsheets/d/1AbOEkwVEIhIEPJ1TLUB92D-va7zszRlozZDkDBcYPw8/edit?usp=sharing

>
>
> Thanks
>
> Benno/Suzanne/Tim
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Jun 2021 17:11:45 +0000

On Jun 17, 2021, at 7:58 AM, Warren Kumari <[email-masked]> wrote:
> While having a discussion with the IESG, I had a look at the number of Active Drafts that we have, and compared it to other workinggroups -- DNSOP currently has 14 listed, with 3 in some form of publication requested (draft-ietf-dnsop-iana-class-type-yang, draft-ietf-dnsop-nsec-ttl, draft-ietf-dnsop-rfc7816bis), leaving 11 "active" ones. Only 6 WGs have more than this, and some of these are in states like "Implementation needed", etc. 
> 
> I think it would be good if we could try and clear some of the active queue (and any expired WG documents that we still want to work on) before adopting many new documents. This isn't "no new work!", but rather "let's try to prioritize existing work first". The intent here is to allow us to focus more on each individual document, and not have our attention scattered between so many.

I would go a tad further, and propose "no new work unless the WG agrees that the proposed new work is more important than at least half of the remaining documents". (And I say this as someone who has just published a new document that could easily be a DNSOP document, but am happy to have it wait a year or two for the backlog to clear out.)

With the criteria that Tim set out yesterday, the WG now has 25 accepted drafts to work on. Even if we move on one draft every month, which is faster than our pace from the past few years, we will still have a dozen drafts a year from now (and more if we make exceptions for new additions).

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Jun 2021 14:43:17 -0400 (EDT)

> With the criteria that Tim set out yesterday, the WG now has 25 accepted drafts to work on. Even if we move on one draft every month, which is faster than our pace from the past few years, we will…

Are these calendar months, or mythical-wgchair-months ? :)

On a more serious note, I do kind of agree with PaulH, and we have
already in the past tried to clear out this backlog, and we have
truly failed. While stopping or slowing new work is not ideal, it
might be a reasonable motivator for us all the push through some
of the work.

Paul
ps. draft-ietf-dnsop-delegation-only is a pretty easy one to complete O:)

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 18 Jun 2021 19:40:45 +0200

On Wed, 2021-06-16 at 19:38 -0400, Tim Wicinski wrote:
> All
> 
> The chairs have been doing prep work for the upcoming IETF meeting; one issue that we are working on is reaching out to authors whose working group documents have recently expired. While doing this, Benno did some datatracker stuff and ended up with this list 
> 
> All documents from 1 January 2016 onward are open for discussion.   For the older documents that are left - if someone wishes to take them on, please reach out. 

aname can go; I trust the WG feels SVCB will supersede it.

I hope MarkA can revive glue-is-not-optional.

I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. I am happy to write text for that, if there is an appetite - when the WG queue is small enough!

There are quite some things I like in rfc2317-bis, especially the parts where it proposes something -other than- slashes in labels. I am not offering to take it on at this time, though.

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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 18 Jun 2021 14:45:02 -0400

On Jun 18, 2021, at 13:41, Peter van Dijk <[email-masked]> wrote:
> 
> I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety.

Eh? 5011 is baked into various software. Why would replace 5011 ?

Did I miss something?

Paul

---

From: Joe Abley <[email-masked]>
Date: Fri, 18 Jun 2021 15:05:21 -0400

> Eh? 5011 is baked into various software. Why would replace 5011 ?

There were some conversations adjacent to the last great root zone KSK roll excitement about how a more measurable and reliable mechanism might be useful. My memory is that there might be value in specifying a new mechanism that could be used as an alternative to or in conjunction with 5011, though, not that 5011 was fundamentally unsound and deserved to be deprecated.

I agree that, in the end, 5011 seems to have done a reasonable job -- it was just hard to predict with any degree of comfort or certainty.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Fri, 18 Jun 2021 16:36:51 -0400 (EDT)

> I agree that, in the end, 5011 seems to have done a reasonable job -- it was just hard to predict with any degree of comfort or certainty.

Sure, but if we were to deprecate 5011, what would we expect to happen
when we want to do another rollover ? We would still have software out
there doing 5011, so we can't do it dramatically different. Which
would lead me to think at best we could do a 5011bis that's mostly
compatible but somehow improved on what we missed, the reporting.

But that is quite different from "deprecating 5011 in its entirety".

Paul "no-not-a-dns-flagday" Wouters

---

From: Joe Abley <[email-masked]>
Date: Fri, 18 Jun 2021 16:47:48 -0400

On Jun 18, 2021, at 16:36, Paul Wouters <[email-masked]> wrote:

> when we want to do another rollover ?

To be more clear, I was *not* suggesting that 5011 should be deprecated.

Joe

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 18 Jun 2021 14:21:05 -0700

Peter van Dijk <[email-masked]> writes:

> I propose replacing rfc5011-security-considerations

I keep meaning to republish it with Olafur's suggested reduced title
(since it's really describing just one problem).  But it's unlikely to
get published as an RFC due to lack of consensus after a long drawn out
conversation where most of the WG stopped reading due to the harsh
language of some messages.  It can probably be dropped from the active
list because of this.
-- 
Wes Hardaker
USC/ISI

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 18 Jun 2021 22:32:19 +0000

On Jun 18, 2021, at 2:21 PM, Wes Hardaker <[email-masked]> wrote:
> language of some messages.

For those who don't remember, the lack of consensus was based on too few people speaking to support the document after one WG member kept harshly objecting to some of the wording. This happened well WG Last Call was finished. The chairs decided to kill the document rather than deal decisively with the one obstructionist WG participant.

> It can probably be dropped from the active
> list because of this.

I would like to see the document, which we all already agreed on, moved to IETF Last Call instead.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 18 Jun 2021 22:34:36 +0000

draft-ietf-dnsop-resolver-information (in the expired queue) can probably be dropped. It was intended for some of the use cases of the ADD WG, but that WG is now no longer considering the document for its work.

--Paul Hoffman

---

From: Daniel Migault <[email-masked]>
Date: Fri, 18 Jun 2021 19:09:27 -0400

On Fri, Jun 18, 2021 at 6:33 PM Paul Hoffman <[email-masked]> wrote:

> For those who don't remember, the lack of consensus was based on too few
> people speaking to support the document after one WG member kept harshly
> objecting to some of the wording. This happened well WG Last Call was
> finished. The chairs decided to kill the document rather than deal
> decisively with the one obstructionist WG participant.
>
> +1

-- 
Daniel Migault
Ericsson

---

From: Paul Wouters <[email-masked]>
Date: Fri, 18 Jun 2021 19:11:19 -0400 (EDT)

> I would like to see the document, which we all already agreed on, moved to IETF Last Call instead.

Background can be read here:

https://www.mail-archive.com/[email-masked]/msg17749.html

Since then, -13 was published which clarifies the update to RFC 7583 and
made the document Informational:

https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-13.txt

I used this opportunity to review the document again.

Probably Section 1.2 needs an update because it refers to ICANN plans of 2018. Even if the
plans are unchanged, the date should be bumped to reflect that.

Section 4.2 states:

    2.  Sign the revoked DNSKEY with itself.

This should clarify that we are talking about signing a DNSKEY RRset,
not a single RR.

Similar in 5.1.1:

 	considering the RRSIGs that cover the DNSKEYs in this document.

s/signs the zone's key set with/signs the zone's DNSKEY RRset with/

(more places with "key set" of similar phrasing should be cleared up)

Section 6.1.7 confuses me a bit as it defines a numResolvers variable,
and uses that to calculate an acceptable new timing period. To me it
feels that number of resolvers should not matter, as we should stick
to the formal time where all resolvers are either updated or no longer
updatable. This arguments also bleeds into Section 6.2 where it is used
indirectly.

Appendix A should be updated as well:

 	In 2017 and 2018, ICANN expects to [....]

Assuming Section 6.1.7 is right and just needs a little bit more
explanation, once the above mentioned nits are resolved, I think
this document is ready to move forward. I will leave it up to the
WGchairs et all. to decide on whether that is another WGLC or IETF LC.

Dropping this document would be a mistake and possibly lead to
implementation mistakes.

Paul

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 18 Jun 2021 20:48:50 -0400

This is all great feedback everyone, please don't stop.

I wanted to say we'll talk to Warren on the 5011-considerations document,
but Warren is a co-author, so we'll need to start over.

Someone mentioned Mark's glue-is-not-optional draft. The chairs really
liked this document,
and wanted to keep it alive.  We've reached out to
mark several times with no response, so we requested the XML from the
secretariat,
dumped it into github, and since it was a short document created the
markdown version
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-glue-is-not-optional
If someone wants to assist with this document, please speak up. Otherwise,
one of the
chairs (most likely myself) will step up as editor to proceed with this.

tim

---

From: Shumon Huque <[email-masked]>
Date: Fri, 18 Jun 2021 21:26:22 -0400

> chairs (most likely myself) will step up as editor to proceed with this.

Tim (and Mark),

I would like this to proceed also.

Having dealt with more real world operational issues with glue than I'd
care to admit, I can volunteer to help ..

Shumon

---

From: Anthony Eden <[email-masked]>
Date: Sat, 19 Jun 2021 08:08:17 +0200

> aname can go; I trust the WG feels SVCB will supersede it.

I concur.

-Anthony

-- 
DNSimple.com
http://dnsimple.com/
Twitter: @dnsimple

---

From: Michael StJohns <[email-masked]>
Date: Sat, 19 Jun 2021 15:09:46 -0400

> For those who don't remember, the lack of consensus was based on too few people speaking to support the document after one WG member kept harshly objecting to some of the wording. This happened wel…

The document failed of WG consensus twice - including the last time 
around.   Blaming that on me seems to be rewriting history and somewhat 
of a personal attack.   And actually seems a bit out of character for you.

Given the amount of work I did on the document and the amount of text 
that Wes thought was useful that did get incorporated, calling me an 
obstructionist has me quoting the Princess Bride ... you know the 
quote.   For your edification, obstructionism is interfering or impeding 
with the business for the sole purpose of delaying the process. While 
you may have that opinion, it is not supported by the factual record and 
is again somewhat of a personal attack.

This document was never effectively a WG edited document - even after 
adoption, Wes kept the editing pen and accepted or rejected text based 
on his sole judgement.   That's not necessarily a bad thing for a given 
document, but it can make it difficult to gain consensus.  Besides a few 
other comments, this was a mostly a dialog between me and him on the 
validity of the math.   AFAICT, no third party spent the time to do any 
analysis of Wes' work, nor to disprove my analysis leaving some of my 
concerns unresolved and a document with less than useful and at times 
confusing results.     E.g. see 
https://mailarchive.ietf.org/arch/msg/dnsop/7or09HOoMjcJdWD576OahbOyHP8/ 
and 
https://mailarchive.ietf.org/arch/msg/dnsop/1nUrmIWSoD_UA6lYxjHskEr60uo/ 
and https://mailarchive.ietf.org/arch/msg/dnsop/JEPKl_3A5azV_l_UYKTtXGb8QtU/

At the end, I objected to the publication of this in the standards 
track, and to inaccuracies in the document shepherd summary along with 
the fact that no new WG last call had actually happened prior to the 
request for publication.   The WG chair pulled it back from publication 
requested, the authors fixed the intended status and published -13, and 
the document was placed for last call looking for support.  It got none, 
and was eventually marked by the WG chairs as dead when it expired.  
Note that I placed no objections during the final last call and not a 
single person - including you Paul - voiced support.

If you want to resurrect it, maybe grab a new editor and put Wes and me 
on a more even playing field for determining the final text.  Otherwise 
Requiescat in Pace for the document.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Sat, 19 Jun 2021 15:28:50 -0400

> updatable. This arguments also bleeds into Section 6.2 where it is used

Hi Paul -

There's a bit of discussion on the WG list but basically:

1) Given various parameters, calculate the earliest date at which a 
publisher can assume at least 1 resolver with perfect connectivity (e.g. 
all questions answered when asked) was able to install the new trust 
anchor.   Note that you figure this assuming only a single resolver and 
non-synchronicity between publisher and resolver which means the 
earliest date for the publisher is the latest date the perfect resolver 
would do the install of the new trust anchor.

2) Given set of N resolvers with imperfect connectivity (e.g, online but 
with occasional lost message/retransmits using 5011 timing) where the 
imperfection is characterized as L% chance of any given message being 
lost, how much longer after (1) should you wait to get to the 
statistical point where K% of the N resolvers have been able to install 
a new trust anchor?

(2) represents a safety factor and is calculated based on N, L and K.   
It ignores the set of offline resolvers in the calculation, because 
there is no way to characterize them.

The question "all resolvers updated" is not an answerable question nor 
one answered by the document.   "Statistically, 99.9999% of resolvers 
have updated" is an answerable question with some margin of error 
assuming N and L can be characterized.  The size of N has a small but 
important impact on the final result. 
https://mailarchive.ietf.org/arch/msg/dnsop/JEPKl_3A5azV_l_UYKTtXGb8QtU/

Later, Mike

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 23 Jun 2021 18:28:04 +0200

> aname can go; I trust the WG feels SVCB will supersede it.

Yes, please.

> I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. I am happy to write text for that, if there is an appetite - when the WG queue is small e…

I agree that 5011 doesn't seem really useful (anymore).

We have it in Knot Resolver but recommend not to use it, because it's 
just more trouble than worth in practice.  Notably, (all) resolver 
software needs much more frequent updates than the rate of root KSK 
rollovers, so it's easier to distribute root DS within the updates; some 
Linux distros even package these separately and share them among 
different resolver packages.  Even if you're conservative and use BIND 
ESV or similar, I believe it's a better approach than 5011.  For 
non-root keys there doesn't seem much point nowadays, as getting a chain 
from root is better.

(By the way, an "interesting" example: router with DNSSEC validation and 
factory reset / rollback, commonly shelved for a year, unreliable clock, 
etc.)

--Vladimir

---

From: Joe Abley <[email-masked]>
Date: Wed, 23 Jun 2021 13:27:51 -0400

On 23 Jun 2021, at 12:28, Vladimír Čunát <[email-masked]> wrote:

> We have it in Knot Resolver but recommend not to use it, because it's just more trouble than worth in practice.  Notably, (all) resolver software needs much more frequent updates than the rate of root KSK rollovers, so it's easier to distribute root DS within the updates; some Linux distros even package these separately and share them among different resolver packages.  Even if you're conservative and use BIND ESV or similar, I believe it's a better approach than 5011.  For non-root keys there doesn't seem much point nowadays, as getting a chain from root is better.
> 
> (By the way, an "interesting" example: router with DNSSEC validation and factory reset / rollback, commonly shelved for a year, unreliable clock, etc.)

There are a variety of mechanisms available to identify and configure a trust anchor to use in a validator, some automatic and some manual; some rely upon having an existing, functional trust anchor to introduce a new one, some use other trusted paths such as vendor update processes and the web PKI. There are almost certainly mechanisms we don't know about, as well as the variety with which we are familiar.

There are also a variety of scenarios in which trust anchor maintenance is important. Some scenarios involve informed administrators; some involve uninformed users; some involve isolated devices that have no immediate human administrator or user. Some (as you point out) feature long air-gapped periods between configuration and use. We do not have a complete understanding of the breadth of the set of scenarios.

Given that there is such a variety of existing mechanisms and possible use-cases, and considering the profound lack of measurement which could inform us about which mechanisms are being used (or work) and which are not (or don't), I think it's premature to start talking about retiring particular mechanisms either as operational practice or in the sense of deprecation.

As one of the people who spent painful amounts of time trying to contact people by phone and e-mail to find out whether the dirty signals we were worried about during the last (and only!) root zone KSK roll, I can attest that RFC 5011 certainly works well for some people. I think it's fair to say we don't have a good way of quantifying that data point into a more general statement that is stronger than anecdotal. This is not a firm foundation on which to build a plan.

Joe

---

From: Brian Dickson <[email-masked]>
Date: Fri, 25 Jun 2021 18:04:42 -0700

On Fri, Jun 18, 2021 at 12:06 PM Joe Abley <[email-masked]> wrote:

> >> I propose replacing rfc5011-security-considerations with a short
> document deprecating 5011 in its entirety.
> >
> There were some conversations adjacent to the last great root zone KSK
> roll excitement about how a more measurable and reliable mechanism might be
> useful. My memory is that there might be value in specifying a new
> mechanism that could be used as an alternative to or in conjunction with
> 5011, though, not that 5011 was fundamentally unsound and deserved to be
> deprecated.
>
> I agree that, in the end, 5011 seems to have done a reasonable job -- it
> was just hard to predict with any degree of comfort or certainty.
>

I didn't realize the -security-considerations document had the history in
the wg during wglc (I missed that entirely, sorry).
And hadn't really closely read either the draft (even in its latest
iteration), or looked at 5011 itself with a critical eye.

I am in favor of all of the following:

   - Advancing the -security-considerations draft as Informational (e.g. as
   IETF LC)
   - Keeping 5011 or a successor
   - Working on an informal 5011 thing to document:
      - What it can and cannot do
      - Requirements on how to strengthen it against the replay attack
      causing failed rollover
      - Requirements for how to strengthen it against a compromised key
      (discovered empirically for example)
      - Requirements for how to protect against change-of-control via
      single compromised key
   - Working on a formal 5011-bis informed by both the present
   -security-considerations work, and the informal thing (previous bullet)

I am willing to work on the last two items as a co-author, but probably
don't have the cycles to be the holder-of-the-pen.
I have specific ideas, so this isn't just wishful thinking, I don't think.
However, whether the -bis is able to get consensus is not a foregone
conclusion, I don't think.

Having a stronger and more resilient 5011 is something I think that may be
important, particularly for use in environments which are not the Root
Trust Anchor (e.g. private trust anchors in various environments, including
the 2-letter undelegated use case, the internal-only subdomain use case,
and possibly some of the HomeNet use cases presumably.).

Brian

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 30 Jun 2021 20:59:16 +0200

Hello DNSOP,

> I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. I am happy to write text for that, if there is an appetite - when the WG queue is small e…

I see this ruffled some feathers. Here's a more nuanced version.

I feel that 5011, for the purpose of root key rollovers, is the wrong tool, -especially- combined with the trust anchor signaling that various resolver stacks sent to the root. Lack of clarity about where various signals came from, combined with some interesting bugs in implementations, has led to a lot of wild goose chases, and it would not surprise me (but I cannot prove) that bad data is what delayed the first roll for so long. Not actual problems predicted by the data; just bad data. (I have mentioned before that I think the trust anchor signalling was a mistake too, and any calls for 'more of this' are 'calls for more bad data' and we do not need more bad data.)

I feel that the right mechanism for root key distribution is software distributors. This is working fine for the CA system, and with keys announced far enough in advance, should work fine for DNSSEC. Software distributors have solved this problem; they are very good at distributing things; I suggest we let them solve this for us.

rfc5011-security-considerations is a good document, and I apologise for targeting it unfairly - my problem with 5011 is as above. Given my next two point, it probably makes sense to publish rfc5011-security-considerations.

With heaps of 5011 'client' implementations out there, I am in no way proposing that root rolls happen in a way that that software could not follow along. I am only proposing that we write down that 5011 is not the best fit for the problem, and recommend against more client implementations of it *for the purpose of root key rolls*.

I think (can't find it right now) that somebody mentioned that 5011 has its place outside of the root key system, inside enterprises. I'm inclined to disagree, but do not feel entirely capable of judging that. If (again, when there's WG bandwidth) we draft a document about why 5011 is a bad fit for the root, perhaps somebody can contribute text about the level-of-fit for other use cases.

Kind regards,

---

From: Joe Abley <[email-masked]>
Date: Wed, 30 Jun 2021 15:04:35 -0400

> I feel that the right mechanism for root key distribution is software distributors. This is working fine for the CA system, and with keys announced far enough in advance, should work fine for DNSSE…

We actually spent some time back in 2009/2010 packaging trust anchors in a way that could take advantage of existing (e.g. code-signing) PKIs, specifically to facilitate distribution to software vendors. I haven't checked very recently, but I don't think there was any sign that the mechanism was being used by anybody in the decade or so that followed. See RFC 7958 section 2.3.

I mention this simply because it was our best guess at the time at how to distribute trust anchors securely (with a respectable chain of custody) from the KMF in which the keys were generated right through to the code publication pipeline operated by software vendors. Quite possibly it was a bad guess.

Joe

---

From: Michael StJohns <[email-masked]>
Date: Wed, 30 Jun 2021 15:26:36 -0400

Peter et al -

It might be useful to review RFC 4986 - 
https://www.rfc-editor.org/rfc/rfc4986.html - Requirements Related to 
DNS Security Trust Anchor Rollover - to understand what the problem 
requirements were/are before resurrecting this discussion again.   If 
the requirements have changed, then perhaps we need a new solution, but 
we should probably update 4986 before tossing 5011.

Peter -

WRT to your analogy to the CA system, I will note that browser clients 
(where the trust anchors are embedded for the CA) are not even close to 
being updated in the same manner as recursive resolvers (not simply "DNS 
clients") and many resolvers are used to provide services within various 
small and large organizations rather than being owned and updated by a 
single person.   For one thing, there are orders of magnitude more 
browers than there are resolvers.  For another,  resolvers are rarely 
updated automatically.   What would be interesting is to get some idea 
of the set of resolvers with no active management being performed on 
them - including software updates.

Mike

---

From: Mark Andrews <[email-masked]>
Date: Thu, 1 Jul 2021 08:28:25 +1000

I’d argue that there are a magnitude more resolvers than browsers in the world.  There are lots of devices that have a resolver but don’t have a browser.  Think of all the smart light bulbs.  They all need to be able to update their trust anchors.  DNSSEC deployment is still in its infancy.

> On 1 Jul 2021, at 05:26, Michael StJohns <[email-masked]> wrote:
> 
> Peter et al -
> 
> It might be useful to review RFC 4986 - https://www.rfc-editor.org/rfc/rfc4986.html - Requirements Related to DNS Security Trust Anchor Rollover - to understand what the problem requirements were/are before resurrecting this discussion again.   If the requirements have changed, then perhaps we need a new solution, but we should probably update 4986 before tossing 5011.
> 
> Peter -
> 
> WRT to your analogy to the CA system, I will note that browser clients (where the trust anchors are embedded for the CA) are not even close to being updated in the same manner as recursive resolvers (not simply "DNS clients") and many resolvers are used to provide services within various small and large organizations rather than being owned and updated by a single person.   For one thing, there are orders of magnitude more browers than there are resolvers.  For another,  resolvers are rarely updated automatically.   What would be interesting is to get some idea of the set of resolvers with no active management being performed on them - including software updates.
> 
> Mike
> 
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Michael StJohns <[email-masked]>
Date: Wed, 30 Jun 2021 18:43:46 -0400

On 6/30/2021 6:28 PM, Mark Andrews wrote:
> I’d argue that there are a magnitude more resolvers

Yes.   Be pedantic! :-)   I said "recursive resolver" and I really mean 
caching recursive resolver as opposed to stub resolver.   Fair?    I may 
be behind times, but few if any stub resolvers were actually doing their 
own DNSSEC validation (e.g. sending a CD bit to their recursive resolver 
and getting back all of the DNSSEC related records).

>   than browsers in the world.  There are lots of devices that have a resolver but don’t have a browser.  Think of all the smart light bulbs.  They all need to be able to update their trust anchors.  DNSSEC deployment is still in its infancy.

I get what you mean, but I don't actually think many of the tiniest of 
IOT devices will have anything more than an unsecure way of looking up 
their back office system - and then using TLS or something else to 
verify the connection.    Their only CA trust anchor will be to their 
vendor to start with and then to whatever local manager takes over 
ownership.   I could be wrong, but DNS has its greatest strength where 
you get passed a lot of different names that need to be looked up, and 
that mostly doesn't describe the IOT side of things.

Later, Mike