[dns-operations] Implementation of negative trust anchors?

[Edward Lewis]

> I don't think this is about a free choice, but adhering to the protocol.


At this point, I'm not sure who is saying what and what is inferred in the quips, but if you adhere to the protocol, you place free choice first.

This is not just from my dimming memory of the 1990's when we developed the concept, we even wrote this into the latest rendition of the DNSSEC specifications (albeit in 2004).

RFC 4033:
   ...In the final
   analysis, however, authenticating both DNS keys and data is a matter
   of local policy, which may extend or even override the protocol
   extensions defined in this document set.  See Section 5 for further
   discussion.

And this predicts NTA's (also in RFC 4033):

   Insecure: The validating resolver has a trust anchor, a chain of
      trust, and, at some delegation point, signed proof of the
      non-existence of a DS record.  This indicates that subsequent
      branches in the tree are provably insecure.  A validating resolver
      may have a local policy to mark parts of the domain space as
      insecure.
I emphasize the last sentence:

A validating resolver may have a local policy to mark parts of the domain space as insecure.
And I'll add in a cranky manner, the overall tenor of this list insinuating that operators are incompetent and should therefor not be given free will needs to be seriously reconsidered.  Perhaps I need to quite Star Wars to get the point across:

Princess Leia: The more you tighten your grip, Tarkin, the more star systems will slip through your fingers.

Ecologies that place heavy emphasis on "security" have been empirically proven to fail at scale (population and/or time).
 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130904/1097593d/attachment.html>