NNSquad - Network Neutrality Squad
[ NNSquad ] Re: FW: [ga] the future .. DNS National Security and the ICANN clowns
|
(.mbox??) I’ve
already written about how the DNS is intrinsically and fatally flawed. You don’t
own your identity so guarantees failure of links over time. You need to rely on
a man in the middle for determining identity and you need to rely on the most naïve
concept of identity – JohnSmith.com. I
agree with Lauren that the problem is not locking down the DNS but the very
idea of the DNS and the idea that we can define something as complex as trust
and security as simply a protocol problem. These are not network problems.
These are application and social and societal problems. If you want someone to
vouch for the other site you can choose your authority. That’s what SSL
is about though it may be too implicit. And if you don’t encrypted then
you don’t really care that much. This
reminds me of the efforts to prove programs correct. A very strange idea –
all you could do is prove equivalence between two representations. It didn’t
address the complexities of what “correct” means and, in fact, made
it more difficult to prove the program did what you wanted because the representations
were, of necessity, arcane so they could be processed by the proof engine. BTW
I caught a snippet on NPR but didn’t hear the whole piece. But the teaser
is that all this fancy password choosing and changing gains you very little. I
find myself in agreement – today human factor attacks are the bigger
issue and all this complex technology gives us the illusion of tackling the
problem while diverting our attention from the fact these aren’t amenable
to technical fixes. Technology is important but in context. -----Original Message----- On Mon, Apr 12, 2010 at 03:29:33PM -0700, Lauren
Weinstein wrote: > Comments either way, anyone? There was just an extensive discussion about this on
dns-operations in February. I've put a Unix mbox-style archive of it
here: http://www.firemountain.net/~rsk/curve.mbox for those who wish to read it. The most succinct and
apropos comment appears to me to have come from Crist Clark, and it reads
in part: > This argument is going to go nowhere. There is no
point in pretending > that DNSCurve is in anyway a substitute or
competitor to DNSSEC. > > As the DNSCurve IETF draft says, > > DNSCurve only provides link-level security between
a client-server > pair. It does not attempt to ensure end-to-end
security for queries > and responses relayed by untrusted DNS proxies
and caches. > > Whereas end-to-end security is the purpose of
DNSSEC. In DNSSEC, anyone > can verify the authenticity of a RR from its source.
In DNSCurve, > you know the response was actually from the server
you queried, and > it's just "trust me" for all of the magic
behind that recursive > resolver. However, there are many other illuminating comments in
that discussion thread, so I urge those interested to read the entire
thing. ---Rsk [ Without addressing DNSSEC technical issues at this
point, I can't avoid the increasingly overwhelming sense
that we're building enormously complex edifices on a
foundation that was never designed to support such structures,
and that it is turning to quicksand as a result, putting
at risk much of what we've built -- and especially
putting Internet services and consumers at risk. To my way of thinking, this suggests that it's time
to "radically" rethink the existing pardigms,
rather than keep piling more and more complicated "stuff"
on top of an already overburdened and collapsing pile. And I mean this not
only in a technical sense, but in both a public interest and
political sense as well. I'll have more to say about this shortly. -- Lauren Weinstein NNSquad Moderator ] |