Re: [DNSOP] Obsoleting DLV

[Mark Andrews]

> On 25 Jul 2019, at 9:10 pm, Tony Finch  wrote:
> 
> Samuel Weiler  wrote:
>> 
>> That does not include the argument in the below bullet, which I find unclear.
>> What does "name redirection" mean in this context?
>> 
>>   o  Since the zones are related to private networks, it would make
>>  more sense to make the internal network more secure to avoid name
>>  redirection, rather than complicate the DNS protocol.
> 
> I guess it's referring to active DNS modification attacks?
> 
> Another reason not mentioned in the draft is resilience against loss of
> connectivity. If you have a local trust anchor you can validate local
> zones even when you can't reach the outside world. With normal DNSSEC
> validation everything is screwed if you can't obtain the chain of trust.
> 
> Of course, the network should be secure and reliable in its lower layers,
> but I tend to think the DNS should be secure and reliable itself, even if
> the lower layers are a bit dodgy.
> 
> Having thought about this a bit, I now prefer something like catalog zones
> as a way to distribute trust anchors.

You just slave the private DLV registry and load the trust anchors from that
after validating each DLV RRset.

> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Lundy, Fastnet: Variable 2 to 4 in east Lundy, otherwise southerly veering
> southwesterly 4 to 6. Slight or moderate in east Lundy, but elsewhere moderate
> or rough. Thundery showers. Moderate or good.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Matthijs Mekking]

Sam,


On 7/25/19 1:22 AM, Samuel Weiler wrote:
> On Tue, 2 Jul 2019, Matthijs Mekking wrote:
> 
>> Here's a draft with discussion why also the protocol should go
>> away. We would like to hear what you think about it.
> 
> The discussion of the private network use case in section 2 has two
> minor errors plus one bit that is unclear.
> 
> When we designed DLV, we certainly considered a private network use
> case.  RFC5074 does not strictly have public trust anchors take
> precedence over ("mask") DLV records [1].

I read text from RFC 6840 (Section C.3):

   When the trust anchors have come from different sources (e.g.,
   automated updates ([RFC5011]), one or more DNSSEC Lookaside
   Validation (DLV) registries ([RFC5074]), and manual configuration), a
   validator may wish to choose between them based on the perceived
   reliability of those sources.  The order of precedence might be
   exposed as a configuration option.


> I suggest replacing the text in section 2 starting with "One other..."
> with:
> 
>    One other possible reason to keep DLV is to distribute trust anchors
>    for private enterprises.  The authors are not aware of any such use
>    of DLV.
> 
> That does not include the argument in the below bullet, which I find
> unclear.  What does "name redirection" mean in this context?
> 
>    o  Since the zones are related to private networks, it would make
>   more sense to make the internal network more secure to avoid name
>   redirection, rather than complicate the DNS protocol.

Thanks, I made the change in the GitHub repository (BTW I also resolved
Paul Wouters nit comments from earlier).


Best regards,

Matthijs



> -- Sam
> 
> 
> [1] Specifically, 5074 says to use public trust anchors first.  If they
> give a validation result other than "Secure", then do DLV processing. 
> I'm not 100% sure of how BIND's logic works here.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Tony Finch]

Samuel Weiler  wrote:
>
> That does not include the argument in the below bullet, which I find unclear.
> What does "name redirection" mean in this context?
>
>o  Since the zones are related to private networks, it would make
>   more sense to make the internal network more secure to avoid name
>   redirection, rather than complicate the DNS protocol.

I guess it's referring to active DNS modification attacks?

Another reason not mentioned in the draft is resilience against loss of
connectivity. If you have a local trust anchor you can validate local
zones even when you can't reach the outside world. With normal DNSSEC
validation everything is screwed if you can't obtain the chain of trust.

Of course, the network should be secure and reliable in its lower layers,
but I tend to think the DNS should be secure and reliable itself, even if
the lower layers are a bit dodgy.

Having thought about this a bit, I now prefer something like catalog zones
as a way to distribute trust anchors.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Lundy, Fastnet: Variable 2 to 4 in east Lundy, otherwise southerly veering
southwesterly 4 to 6. Slight or moderate in east Lundy, but elsewhere moderate
or rough. Thundery showers. Moderate or good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Samuel Weiler]

On Tue, 2 Jul 2019, Matthijs Mekking wrote:


Here's a draft with discussion why also the protocol should go
away. We would like to hear what you think about it.


The discussion of the private network use case in section 2 has two 
minor errors plus one bit that is unclear.


When we designed DLV, we certainly considered a private network use 
case.  RFC5074 does not strictly have public trust anchors take 
precedence over ("mask") DLV records [1].


I suggest replacing the text in section 2 starting with "One other..." 
with:


   One other possible reason to keep DLV is to distribute trust anchors
   for private enterprises.  The authors are not aware of any such use
   of DLV.

That does not include the argument in the below bullet, which I find 
unclear.  What does "name redirection" mean in this context?


   o  Since the zones are related to private networks, it would make
  more sense to make the internal network more secure to avoid name
  redirection, rather than complicate the DNS protocol.

-- Sam


[1] Specifically, 5074 says to use public trust anchors first.  If 
they give a validation result other than "Secure", then do DLV 
processing.  I'm not 100% sure of how BIND's logic works here.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Samuel Weiler]

On Tue, 2 Jul 2019, Matthijs Mekking wrote:


Here's a draft with discussion why also the protocol should go
away. We would like to hear what you think about it.


No objection.  I'm not aware of any active private use of DLV.

Thank you for doing the detailed work of looking up the citations and 
figuring out the dependencies.


-- Sam

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Tim Wicinski]

The chairs discussed this and the "process" moving documents to Historic is
varied based on the documentation.
(https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/).
We've assigned our IESG Overlord to do what
IESG Overlords do in these situations.  From reading the available options,
this chair prefers option #2, which
involves a small amount of work on the working group, and then hands it
over to our AD.

Once the chairs are given a sign, we'll let all know.

tim

On Wed, Jul 3, 2019 at 10:31 AM Loganaden Velvindron 
wrote:

>
>
> On Tue, Jul 2, 2019 at 10:13 PM Matthijs Mekking 
> wrote:
>
>> Hi,
>>
>>
>> A while back I was asked why BIND 9 still had code to do DLV. Good
>> question, and we asked our users if they would mind if we remove the
>> code. Almost everyone was okay with that.
>>
>> So ISC plans to deprecate the feature in BIND 9.  But also I think it is
>> time to move the protocol to Historic status as a clear signal to
>> everyone that it should no longer be implemented or deployed.
>>
>> Dan Mahoney cleared the only well-known DLV registry almost two years
>> ago. Here's a draft with discussion why also the protocol should go
>> away. We would like to hear what you think about it.
>>
>> I think that it's worth going forward.
>
> ISC BIND commit:
>
> https://github.com/isc-projects/bind9/commit/f29359299aaab519f39b090cd83de85cd2fc3820
>
>
>
>> Best regards,
>>
>> Matthijs
>>
>>
>>  Forwarded Message 
>> A new version of I-D, draft-mekking-dnsop-obsolete-dlv-00.txt
>> has been successfully submitted by Matthijs Mekking and posted to the
>> IETF repository.
>>
>> Name: draft-mekking-dnsop-obsolete-dlv
>> Revision: 00
>> Title:Moving DNSSEC Lookaside Validation (DLV) to Historic Status
>> Pages:5
>> Status:
>>
>>   https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/
>>
>> Abstract:
>>This document obsoletes DNSSEC lookaside validation (DLV) and
>>reclassifies RFCs 4431 and 5074 as Historic.
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Loganaden Velvindron]

On Tue, Jul 2, 2019 at 10:13 PM Matthijs Mekking 
wrote:

> Hi,
>
>
> A while back I was asked why BIND 9 still had code to do DLV. Good
> question, and we asked our users if they would mind if we remove the
> code. Almost everyone was okay with that.
>
> So ISC plans to deprecate the feature in BIND 9.  But also I think it is
> time to move the protocol to Historic status as a clear signal to
> everyone that it should no longer be implemented or deployed.
>
> Dan Mahoney cleared the only well-known DLV registry almost two years
> ago. Here's a draft with discussion why also the protocol should go
> away. We would like to hear what you think about it.
>
> I think that it's worth going forward.

ISC BIND commit:
https://github.com/isc-projects/bind9/commit/f29359299aaab519f39b090cd83de85cd2fc3820



> Best regards,
>
> Matthijs
>
>
>  Forwarded Message 
> A new version of I-D, draft-mekking-dnsop-obsolete-dlv-00.txt
> has been successfully submitted by Matthijs Mekking and posted to the
> IETF repository.
>
> Name: draft-mekking-dnsop-obsolete-dlv
> Revision: 00
> Title:Moving DNSSEC Lookaside Validation (DLV) to Historic Status
> Pages:5
> Status:
>
>   https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/
>
> Abstract:
>This document obsoletes DNSSEC lookaside validation (DLV) and
>reclassifies RFCs 4431 and 5074 as Historic.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Paul Vixie]

fine by me.

⁣Get BlueMail for Android ​

On 2 Jul 2019, 13:11, at 13:11, Dan York  wrote:
>
>
>> On Jul 2, 2019, at 3:31 PM, Jim Reid  wrote:
>>
>>
>>
>>> On 2 Jul 2019, at 19:12, Matthijs Mekking 
>wrote:
>>>
>>> I think it is time to move the protocol to Historic status as a
>clear signal to
>>> everyone that it should no longer be implemented or deployed.
>>
>> Agreed. Kill it with fire!
>
>Yes, please!  We can celebrate all it did to help get DNSSEC going, but
>that time is now long gone.
>
>Dan
>___
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Dan York]

> On Jul 2, 2019, at 3:31 PM, Jim Reid  wrote:
> 
> 
> 
>> On 2 Jul 2019, at 19:12, Matthijs Mekking  wrote:
>> 
>> I think it is time to move the protocol to Historic status as a clear signal 
>> to
>> everyone that it should no longer be implemented or deployed.
> 
> Agreed. Kill it with fire!

Yes, please!  We can celebrate all it did to help get DNSSEC going, but that 
time is now long gone.

Dan
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Erwin Lansing]

> On 2 Jul 2019, at 21.31, Jim Reid  wrote:
> 
> 
> 
>> On 2 Jul 2019, at 19:12, Matthijs Mekking  wrote:
>> 
>> I think it is time to move the protocol to Historic status as a clear signal 
>> to
>> everyone that it should no longer be implemented or deployed.
> 
> Agreed. Kill it with fire!
> 

Should have know last week, we had a nice big bonfire just for the occasion :-)

Yes, please put it out of its misery.

Erwin
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Jim Reid]

> On 2 Jul 2019, at 19:12, Matthijs Mekking  wrote:
> 
> I think it is time to move the protocol to Historic status as a clear signal 
> to
> everyone that it should no longer be implemented or deployed.

Agreed. Kill it with fire!

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Joe Abley]

+1 to all of that which follows!

> On 2 Jul 2019, at 14:41, Paul Wouters  wrote:
> 
> On Tue, 2 Jul 2019, Matthijs Mekking wrote:
> 
>> So ISC plans to deprecate the feature in BIND 9.  But also I think it is
>> time to move the protocol to Historic status as a clear signal to
>> everyone that it should no longer be implemented or deployed.
> 
> I agree with moving DLV to historic. It is no longer needed at large,
> and while it can serve a few corner cases, the only public DLV registry
> has been deactivated years ago, and DLV is not universally implemented
> to begin with, so one could not depend on a new to be launched DLV registry
> anyways.
> 
> The draft seems to explain it well.
> 
>> Title: Moving DNSSEC Lookaside Validation (DLV) to Historic Status
> 
>> https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/
> 
>   "As of May 2019, the root zone is signed"
> 
> While it is correct that in May 2019, the root zone is signed, I don't
> think that's the information you are trying to relay :) :) :)
> 
> 
> 3.1.1.2.  I-D.lhotka-dnsop-iana-class-type-yang
> 
>   The draft "YANG Types for DNS Classes and Resource Record Types"
>   [I-D.lhotka-dnsop-iana-class-type-yang] refers to RFC 4431 to
>   describe the DLV entry in the YANG module iana-dns-class-rr-type.
>   This reference should be removed.
> 
> I think this does not need to be in this document, but the authors
> should be requested to remove it in an update to their document.
> In general, yang documents should not populate IANA registries, which
> is something I raised afew months ago and the yang community is looking
> at that. (and reference IANA registries instead)
> 
> And I think Ondej  should fix up his name :)
> 
> Paul
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Warren Kumari]

On Tue, Jul 2, 2019 at 11:13 AM Matthijs Mekking 
wrote:

> Hi,
>
>
> A while back I was asked why BIND 9 still had code to do DLV. Good
> question, and we asked our users if they would mind if we remove the
> code. Almost everyone was okay with that.
>
> So ISC plans to deprecate the feature in BIND 9.  But also I think it is
> time to move the protocol to Historic status as a clear signal to
> everyone that it should no longer be implemented or deployed.
>
> Dan Mahoney cleared the only well-known DLV registry almost two years
> ago. Here's a draft with discussion why also the protocol should go
> away. We would like to hear what you think about it.
>

Yes please; DLV was a useful tool to get DNSSEC off the ground, but had
long outlived its usefulness, and is now just extra code to fail.

Rip it out,
W


>
> Best regards,
>
> Matthijs
>
>
>  Forwarded Message 
> A new version of I-D, draft-mekking-dnsop-obsolete-dlv-00.txt
> has been successfully submitted by Matthijs Mekking and posted to the
> IETF repository.
>
> Name: draft-mekking-dnsop-obsolete-dlv
> Revision: 00
> Title:Moving DNSSEC Lookaside Validation (DLV) to Historic Status
> Pages:5
> Status:
>
>   https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/
>
> Abstract:
>This document obsoletes DNSSEC lookaside validation (DLV) and
>reclassifies RFCs 4431 and 5074 as Historic.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Paul Wouters]

On Tue, 2 Jul 2019, Matthijs Mekking wrote:


So ISC plans to deprecate the feature in BIND 9.  But also I think it is
time to move the protocol to Historic status as a clear signal to
everyone that it should no longer be implemented or deployed.


I agree with moving DLV to historic. It is no longer needed at large,
and while it can serve a few corner cases, the only public DLV registry
has been deactivated years ago, and DLV is not universally implemented
to begin with, so one could not depend on a new to be launched DLV registry
anyways.

The draft seems to explain it well.


Title:Moving DNSSEC Lookaside Validation (DLV) to Historic Status



 https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/


"As of May 2019, the root zone is signed"

While it is correct that in May 2019, the root zone is signed, I don't
think that's the information you are trying to relay :) :) :)


3.1.1.2.  I-D.lhotka-dnsop-iana-class-type-yang

   The draft "YANG Types for DNS Classes and Resource Record Types"
   [I-D.lhotka-dnsop-iana-class-type-yang] refers to RFC 4431 to
   describe the DLV entry in the YANG module iana-dns-class-rr-type.
   This reference should be removed.

I think this does not need to be in this document, but the authors
should be requested to remove it in an update to their document.
In general, yang documents should not populate IANA registries, which
is something I raised afew months ago and the yang community is looking
at that. (and reference IANA registries instead)

And I think Ondej  should fix up his name :)

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[David Conrad]

I strongly support moving it to Historic.

Regards,
-drc

> On Jul 2, 2019, at 11:12 AM, Matthijs Mekking  wrote:
> 
> Hi,
> 
> 
> A while back I was asked why BIND 9 still had code to do DLV. Good
> question, and we asked our users if they would mind if we remove the
> code. Almost everyone was okay with that.
> 
> So ISC plans to deprecate the feature in BIND 9.  But also I think it is
> time to move the protocol to Historic status as a clear signal to
> everyone that it should no longer be implemented or deployed.
> 
> Dan Mahoney cleared the only well-known DLV registry almost two years
> ago. Here's a draft with discussion why also the protocol should go
> away. We would like to hear what you think about it.
> 
> 
> Best regards,
> 
> Matthijs
> 
> 
>  Forwarded Message 
> A new version of I-D, draft-mekking-dnsop-obsolete-dlv-00.txt
> has been successfully submitted by Matthijs Mekking and posted to the
> IETF repository.
> 
> Name:   draft-mekking-dnsop-obsolete-dlv
> Revision: 00
> Title:  Moving DNSSEC Lookaside Validation (DLV) to Historic Status
> Pages:  5
> Status:
> 
>  https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/ 
> 
> 
> Abstract:
>   This document obsoletes DNSSEC lookaside validation (DLV) and
>   reclassifies RFCs 4431 and 5074 as Historic.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop