Subject: [DNSOP] Last Call: <draft-ietf-dnsop-obsolete-dlv-00.txt> (Moving DNSSEC Lookaside Validation (DLV) to Historic Status) to Informational RFC

From: The IESG <[email-masked]>
Date: Wed, 04 Sep 2019 16:42:36 -0700

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Moving DNSSEC Lookaside
Validation (DLV) to Historic Status'
  <draft-ietf-dnsop-obsolete-dlv-00.txt> as Informational RFC

  Please note that this is primarily to support: 
    https://datatracker.ietf.org/doc/status-change-dlv-to-historic
  and should be read with that.

We are using option 2 of
   https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2019-09-18. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   This document obsoletes DNSSEC lookaside validation (DLV) and
   reclassifies RFCs 4431 and 5074 as Historic.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-obsolete-dlv/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-obsolete-dlv/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: william manning <[email-masked]>
Date: Thu, 5 Sep 2019 13:10:17 -0700

I support this.  DLV was a mistake and making it historic should close that
door.

On Wed, Sep 4, 2019 at 4:42 PM The IESG <[email-masked]> wrote:

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Sep 2019 13:17:25 -0700

> I support this.  DLV was a mistake

yup.  but resistance was futile.

randy

---

From: Paul Wouters <[email-masked]>
Date: Thu, 5 Sep 2019 16:48:34 -0400

> yup.  but resistance was futile.

It was very useful at the beginning, especially before the root was signed. I used it to get DNSSEC from a number of TLDs and could not have done that without DLV.

It served its purpose well, and it should be formally retired and this document should get published.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Sep 2019 21:07:07 +0000

On Thursday, 5 September 2019 20:48:34 UTC Paul Wouters wrote:
> [DLV] was very useful at the beginning, especially before the root was 
signed.
> I used it to get DNSSEC from a number of TLDs and could not have done that
> without DLV.

me too. if the first production use of dnssec had been the day .COM was 
signed, then deployment would be even less advanced today than it is.

> document should get published.

sam weiler argued unsuccessfully that trust should not be required to follow 
the delegation path, and with a decade or more of perspective i can see that 
he was right. however, DLV as specified and implemented would not be the 
mechanism i'd propose if non-hierarchical trust had to scale. right now 
private distribution of static trust anchors is working as well as it has to.

-- 
Paul

---

From: Michael Sinatra <[email-masked]>
Date: Thu, 5 Sep 2019 14:25:36 -0700

> private distribution of static trust anchors is working as well as it has to.

I remember scaring a bunch of people at a NANOG meeting by suggesting 
that we should have an alternate method of establishing trust, and that 
method should be non-hierarchical (or perhaps "counter-hierarchical"). 
I believe I used "DLV-like" to describe it and I remember the reactions 
I got (esp from Randy).  My goal was to mitigate risk from anything that 
might cause the root KSK to become bolloxed, like a botched key roll.

Of course, the root KSK roll turned out to be a non-event, due to great 
preparation and plenty of other mitigating steps and ideas, so 
counter-hierarchical trust chains, outside of static TAs, don't seem 
necessary ATM.

TL;DR: Kill it.

michael

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Sep 2019 14:46:12 -0700

> that we should have an alternate method of establishing trust, and
> that method should be non-hierarchical (or perhaps
> "counter-hierarchical"). I believe I used "DLV-like" to describe it
> and I remember the reactions I got (esp from Randy).  My goal was to
> mitigate risk from anything that might cause the root KSK to become
> bolloxed, like a botched key roll.

you misunderstood me.

dlv had no particular trust model.  i was and remain a web of trust
heritic as far as net ops is concerned.  it's the way operators actually
work.  if you and cat, who i know, trust brielle, i'll trust her, though
not necessarily her friends.

lack of an inter-operator trust model is why slurm is not usable other
than in one's own net.  it is droll that lta-use touches this but got
enough pushback from a sec ad that i have not had the time to educate.

i was also not successful pushing wot in the rpki-based routing security
development cabal.  essentially, the ietf's total focus on the x.509
based pki hierarchy meant wot went for decades with no energy behind
analysis, design, development, etc.; starved from birth.

randy

---

From: Warren Kumari <[email-masked]>
Date: Thu, 5 Sep 2019 17:59:58 -0400

Oh, and a quick update -- someone poked me off-list to point out that
I should have updated the Last Call text to note that this doesn't get
published as an RFC directly, instead:
"An individual or a working group posts an Internet Draft containing
an explanation of the reason for the status change. The I-D is
discussed and iterated as usual for I-Ds. At some point, it is sent to
an appropriate AD to request publication. The AD creates a
status-change document, with an explanation that points to the I-D.
The I-D and the status-change are then last-called together, after
which the IESG evaluates and ballots on both. If the change is
approved, the content of the I-D is moved into the status-change
document, and the I-D is marked as "dead", having served its purpose."
-- https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/

They are right, I should have noted this... We very seldom do
status-changes to Historic[0], and so the process is somewhat
unfamiliar. This shouldn't change anyone's behavior, etc, but don't
expect to see this particular document show up as RFCxxxx.
Here endeth the process wonkery for the day...

W
[0]: This is, IMO, a separate issue...

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Sep 2019 22:02:11 +0000

On Thursday, 5 September 2019 21:46:12 UTC Randy Bush wrote:
> ...
> 
> dlv had no particular trust model.  ...

as one of its janitors, its trust model was pub-sub. that's why it could never 
have scaled. wot is what's actually needed for this. follows-delegation is 
neither the best or worst way to do it, but at the moment, it's not slowing 
deployment.

-- 
Paul