On 18Oct 2006, at 6:24 PM, The IESG wrote:
The IESG has received a request from an individual submitter to considerthe 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/
Attachment:
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf