Subject: Re: Last Call: 'DNSSEC Lookaside Validation (DLV)' to Informational RFC (draft-weiler-dnssec-dlv)

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 20 Oct 2006 18:13:50 +0200

On 18Oct 2006, at 6:24 PM, The IESG wrote:

> The IESG has received a request from an individual submitter to  
> consider
> the following document:
>
> - 'DNSSEC Lookaside Validation (DLV) '
>    <draft-weiler-dnssec-dlv-01.txt> as an Informational RFC
>

Dear Colleagues, Sam,

I have reviewed draft-weiler-dnssec-dlv-01.

I appreciate Sam's effort in documenting this technique and bringing  
it to the IETF as an informational draft.

----

I have a few comments. Some are nits.

In section 3:

A DLV domain SHOULD NOT contain data other than DLV records....

What are the possible consequences of not following that  
recommendation? I could imagine that there is a portion of the DNS  
tree that serves as a reputation Database; it stores DLV records,  
CERTs, "Reputation" RRs with all sort of reputation junk about the  
"ownernames". That would not hurt the DLVn tree? OH wait, I got it.  
Those records may be bitten by aggressive negative caches if the  
implementation notes in 6.1 are not followed. (Maybe it would be good  
to cross reference and make that SHOULD NOT a little weaker...)

In section 5:

> "If validation of the DLV RR sets leads to a result of Bogus, then  
> it MUST NOT be used and the validation result for the original  
> query SHOULD be Bogus."

I wonder how much wiggle room there is here. Obviously this is a  
policy matter; If you fail to find a trust-path in the regular DNS  
tree you go of into the forest of DLV trees and try to find an  
appropriate DS. It is reasonable to migrate the security status of  
the answer in the DLV forest to the DNS tree.

But what are the security consequences of not following that  
behavior, if any?

But there is another point: Consistency.

Assume there are two DLV registries that both target the same part of  
the DNS tree. Besides there is exists a chain of trust from  some  
anchor in the DNS tree. Now suppose that there are 3 reslovers, each  
configured with different trust points. One validates from the real  
tree, the others validate each using a different DLV anchor. It could  
be that one arrives at "insecure" the other at "bogus" and the third  
at "secure". That is not very consistent. By anchoring trust in  
different domains we end up with different results depending on where  
those anchors came from.  I realize that this all results from being  
able to choose who to trust and that these sort of inconsistencies  
can also happen when configuring multiple trust anchors in the  
'normal DNS" tree. In that sense it is not a new problem. But it does  
extend the range of possible mishaps and complicates the question  
"which help desk is to be called?".

In section 5: "if validation leads to an insecure result".

Nit: A DLV tree that has a secure entrypoint that turns insecure  
halfway in its tree is not much of a DLV tree. I actually think that  
that should never happen unless an algorithm unknown to the resolver  
is used. (turns insecure in the eyes
of the resolver). Describing why/when this happens could be part of  
this document as it provides background why this paragraph is there  
in the first place.

In section 7:

Overlapping DLV domains are allowed.

What is not specified is what to do in the limit of overlap: Is the 1- 
to-1 overlap allowed? May I configure two DLV domains that both  
target the same domain? Which one to use, what to do if one is bogus?

I think the author should say a few words about that in the document.

Section 8:

 From the present text it is also not clear which DLV RRsets would be  
applicable. As we are looking for the closest enclosing DLV it seems  
to me that there is always just one applicable DLV.

The author clearly tells us that the proposal is immature but that  
does not give guidance to implementors.

section 10, IANA Considerations:

Wow.

Normally we ask IANA things like:
"Can you please register this in existing table?" or "Please, create   
a new registry for technical parameters?".

But this question extends  to "Can you deploy a new service".

Why, when you ask the for the service, do you want it to stick to TLD  
level only? (This is a rhetoric question)

In any case, I am not sure if it is clear that, once this I-D passed  
last call, this question originates from the author or from the IETF.  
If the first, Sam can ask whatever he likes ('I want a pony' comes to  
mind :-) ). If the latter I am not consenting with that question  
being asked.

The information that would go into those DLV RRs should go into the  
DS RRs. We all know in which zone those DS RRs are published.

-----

My meta issue is with DLV itself.

I think that DLV changes the DNSSEC landscape. It introduces a new  
party that can act as a 3rd party certification authority. DLV might  
be useful during a transition phase where the tree is sparsly  
populated and the root is not signed. On the other hand it may also  
hinder deployment in key parts of the infrastructure where it may be  
more valuable to registries to act as certification authority in the  
DLV space than to deploy DNSSEC within their zone. Obviously, it is  
the market that will decide, the genie is out of the box.

------

As for this draft. I think that it is good to have a specification  
available; There is a major DNS implementation that has this  
functionality implemented (maybe not exactly as described in this  
document, I am not sure. I have not experimented with the  
functionality nor looked at code).

As argued above I would not like to see DLV as a permanent thing and  
I hope it  disappears. Besides there are some technical issue such as  
the consistency point above that is inherit to the design.

Therefore I think that  we'd be better off to publish this as  
experimental (if published).

--Olaf
   no hats.

Edit nits:
Last paragraph of 3:
s/section X,/section 6,/

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 27 Oct 2006 15:25:44 +0200

On Wed, Oct 18, 2006 at 12:24:22PM -0400,
 The IESG <[email-masked]> wrote 

>    <draft-weiler-dnssec-dlv-01.txt> as an Informational RFC

I've read it, and find no stopping issues. I believe that the
political issue of "who signs the root" is a sufficiently serious
problem to create a temporary workaround like DLV. Good idea, and the
document is OK, IMHO.

I have a problem with section 10. The whole idea of DLV is to be able
to move forward even if IANA cannot or does not want to sign the
root. Therefore, why this section? Is there some mandate from ICANN or
whoever to add it?

RFC editor : note there is a typo in section 3 "zone zone" should be
"root zone".

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 27 Oct 2006 15:33:39 +0200

On Fri, Oct 20, 2006 at 06:13:50PM +0200,
 Olaf M. Kolkman <[email-masked]> wrote 
 a message of 218 lines which said:

> Is the 1- to-1 overlap allowed?

Certainly, there is even an example ("two DLV domains, perhaps
operated by different parties, might target the same zone").

> Which one to use, 

Would adding "and, if they have the same specificity, it is suggested
that they are checked in an order which SHOULD be exposed as a
configuration option to the user" after "it is suggested that the most
specific DLV domain be given precedence" be OK?

So, if the DLV domains are specified in a text configuration file,
they are tried (for the same specificity), in the order of the file.

---

From: Joe Abley <[email-masked]>
Date: Fri, 27 Oct 2006 10:46:38 -0400

> problem to create a temporary workaround like DLV. Good idea, and the

Apologies to all concerned if I'm rudely pointing out the elephant in  
the living room.

This is one of two separate specifications for DLV. The document at

   http://www.isc.org/pubs/tn/isc-tn-2006-1.txt

describes an approach called "DNSSEC Lookaside Validation (DLV)"  
which uses the same DLV resource record specified in RFC 4431. This  
specification is implemented in BIND 9, as far as I know.

I haven't compared draft-weiler-dnssec-dlv-01 with the ISC tech note  
closely, but since the text is different it seems likely that  
implementations based on one would likely differ from those based on  
the other, from different interpretations of the text if not from  
fundamental differences in approach.

I am certainly not trying to promote one of these documents over the  
other. However, given that the documents are potentially different  
and that there's such an obvious overlap (e.g. in name and in the use  
of the DLV RR) it seems to me that there is great potential for  
confusion.

I would suggest that at the very least, draft-weiler-dnssec-dlv ought  
to contain an informative reference to the ISC specification, and a  
prominent note that the implementation of DLV in BIND 9 is based on  
the ISC specification, and not this document.

In addition, the IANA Considerations section of this document  
requests that IANA should create and operate a DLV registry. Since  
there is another DLV registry already in operation (run by ISC, using  
BIND 9 and hence based on the other DLV specification) this is  
additional scope for confusion. Any differences between an IANA DLV  
registry and the ISC DLV registry ought to be made clear to potential  
users, and it would seem sensible to direct the IANA in that manner  
in this document.

Failing to draw attention to these issues would be a disservice to  
readers of this document, and would likely lead to interoperability  
problems and confusion. This would appear to be in conflict with the  
primary goal of this document, which is presumably to facilitate the  
expedient deployment of DNS security.

Joe

(once an employee of ISC, friends with the authors of both  
specifications, not currently a DLV user, and no axe to grind in any  
direction)