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/
PGP.sig
Description: This is a digitally signed message part
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf