[dns-operations] why lookaside is not evil
Edward Lewis
Ed.Lewis at neustar.biz
Fri Mar 26 01:56:11 UTC 2010
At 17:49 -0700 3/25/10, Phil Pennock wrote:
>My understanding is that the long-term goal is to not have look-aside
>mechanisms and that all trust anchors will be in-tree, starting at the
>root.
When DNSSEC was originally defined, requiring the trust-anchors to be
in-tree was explicitly a non-goal. We wanted and wished to allow
flexibility in the way a validator could establish confidence in the
response.
To support this assertion you can see this in the number and dates of
RFCs. RFC 2065 contains the first definition of the signature
containing resource record. In it there are two fields dedicated to
identifying the key generating the signature. One field is the
domain name owning the key. It wasn't until RFC 3007 that in-tree
signing was defined to be the default authorization model. RFC 3007
is dated three years after RFC 2065.
One of things that transpired in the three intervening years was the
realization that the computational complexity involved with a
generalized policy was too great for the DNS to handle. With a
sufficiently complex policy, a malicious agent could cause a
validator to go into computational loops, leading to a denial of
service. In addition, generating a policy specification language was
just too much work. So we declared "failure" on this and generated
RFC 3007.
The reason for the desired flexibility is that when you extend a
system to be more secure you will naturally make it more brittle. To
counter act the drop in resiliency that results from this you need to
make the security system more agile. Who to trust and how to gain
trust are more flexible if they have choices, but as mentioned in the
previous paragraph, the decision making process required when you
have choices can be exploited.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
New pithy statement under construction...
More information about the dns-operations
mailing list