[dns-operations] closest keys and validation policy

[Edward Lewis]

At 14:14 +0100 7/18/10, Jim Reid wrote:

>Rather than define these terms, can I suggest we encourage everyone to
>adopt the One True Path to DNSSEC, ie the trust anchor for the root, instead
>of kludging about with multiple trust anchors and ad-hoc validation schemes?

Why would we be "kludging about" with multiple this and ad-hoc that? 
Because that is the very heart and soul of the extension's design 
philosophy.

DNSSEC is a combination of the attestations of the publisher of the 
zone and the use of these attestations by the receiver to decide if 
the receiver will accept the learned information.  First and 
foremost, DNSSEC is for the protection of the recipient.  Protection 
of the sender is not the primary goal.

If DNSSEC was designed to take a strictly tree-based approach to 
security, why would the owner of the key need to be identified in the 
RRSIG?  The original designers recognized that security makes a 
resilient system brittle, there had to be multiple ways for a 
recipient to be able to learn to trust data.

Remember "local policy" trumps all other stated policies.  It's about 
protection of the cache from cache poisoning.  That's why.

In particular, debating a trust anchor that is hard coded in a name 
server versus the live root chain - sure it might be the case that 
the trust anchor might be out of date and therefore only the root 
chain should be trusted.  But if you are cut off from the global 
public Internet a local trust anchor may be all you have.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.