Subject: [secdir] secdir review of draft-ietf-dnsop-obsolete-dlv-00

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 26 Sep 2019 06:20:30 -0700 (PDT)

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is ready.

From the abstract, this document obsoletes DNSSEC lookaside validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic.

The document lists all current references to DLV RFCs and describes necessary changes to those RFCs. The security considerations basically say that zones relying on DLV will have to find another way, but that there are no well-known DLV registries, so this number will likely be small.

I'm not a DNSSEC expert, so maybe this is a dumb question, but is there any possibility that someone doesn't get the memo, and continues to rely on some not-so-well-known DLV registry? And if so, what could happen as a result? Anything anyone should care about?

Thanks,

Scott

---

From: Paul Wouters <[email-masked]>
Date: Thu, 26 Sep 2019 09:32:11 -0400 (EDT)

> I'm not a DNSSEC expert, so maybe this is a dumb question, but is there any possibility that someone doesn't get the memo, and continues to rely on some not-so-well-known DLV registry? And if so, w…

It is possible someone has spun up a private DLV none of us knows about.
They will at some point upgrade their software and see it is no longer
working. Some of their queries will potentially change from secure to
insecure. It is highly unlikely this would cover any public domains,
because those queries would also be insecure for anyone not using that
DLV, and it would already be too fragile to rely on getting nameservers
assigned on roaming devices that would chain back to a resolver that
uses this private DLV.

So it would be a very fragile infrastructure that goes from fragile to
insecure.

I think the short warning in Section 5 is enough to discuss this case.

Paul