DNSSEC, a cryptographic version of DNS, has been in development since
1993 but is still not operational.
It seems that Mr. Bernstein also suffers from the "America is the not the
world" syndrome.
???
DNSSEC has been deployed on large scale by some TLD's and RIR's already.
It is very much operational.
Bernstein said that DNSSEC offers "a surprisingly low level of security"
while causing severe problems for DNS reliability and performance.
Let's not argue about the subjective "suprisingly". But what is this
"low level of security"? Is a fully trusted path 'low level'? If so,
what is 'high level'?
I think http://cr.yp.to/talks/2004.04.28/slides.pdf might help.
I did not really see anything there that shows a weakness or 'low level'
of security. What I see there are a few funny suggestions about changing
the concept of a URL to match an outdated DNS infrastructure, and some
mechanism to 'cause less packets' based on key/fingerprint size that is
both based only on near term key sizes and cpu speeds, and disregards DNS
caching by resolvers. Using TXT records to hack around something as
fundamental as DNS security seems a very outdated concept. How long do
we hack around a system before before making a protocol change? Sure,
not every day, as EDNS0 proves, but surely using TXT records and source
port numbers for the next 25 years sounds like overshooting it at the
other end of the spectrum.
1) What is more broken with DNSSEC then on DNS?
The question really should be 'What is LESS broken with DNSSEC than with
DNS?'
This shows more an unwillingness to discuss then anything else. DNSSEC
offers secure transport over plaintext channels of DNS data. Perhaps not
in a method you prefer, but that was not part of questions 1). So at
most here, you can answer "more cpu" and "more bandwidth" and "more error
prone by administrators". The first two are a direct consquence of any
solution that adds cryptography to a previous solution not using cryptography.
The error proneness is (and this is a subjective opinion of mine) something
we have to deal with, and DNSSEC seems to be a reasonable approach to this,
even if we're lacking a little in proper tools to make it easier.
Equally broken is bad, too. 'More broken' is clearly a disaster.
'Not broken' is the goal.
I'm not talking about English Lit. classes here. Stay on target please.
2) If DNSSEC is flawed, where is a better alternative?
I think there are indeed better alternatives. Bernstein calls for
development of alternatives.
So there are better alternatives, but even Mr. Bernstein wants to develop
alternatives, suggesting to me that tehre are currently no alternatives.
Which again leads to you requiring more proof of 1) before shooting down
DNSSEC. If there is nothing better, and DNSSEC does not make it worse (and
some complexity in return for fixing the recent Kaminsky class bugs seems
pretty acceptable to me), then it is you who needs to do the work of
developing these 'better alternatives' that you so desire. "Consensus
and Running Code"?
But to find alternatives, IETF has to stop
silencing the people who can figure out solutions, merely because those
people oppose the BIND cartel.
I'm skipping the conspiracy theory discussion bit. I see many clever people
who dare to stand up and show mistakes and propose alternatives.
The BIND cartel gave us the flawed solutions;
However, after I asked you to show these flaws, I was not answered. See
above.
Sure you can reject DNSSEC. One broken solution doesn't justify
See above. I still don't see any argument where DNSSEC is worse then
DNS without it. I also still see no alternative that is reasonable (and
changing URL symmentics and moving the DNS problem to be a browser
problem is not a solution).
deployment of another broken solution. Time and again we've seen this
same pattern: Someone essentially yells "Emergency! Lets rush out this
(non) solution! No time to think things through!".
You are the first person I've ever heard say that DNSSEC was "rushed". The
other 99.99999% of people complained it took us more then 10 years.
In almost every case,
there is usually no emergency, and the 'solution' is frequently worse
than the problem.
Show is the problems. Brasil, Sweden and RIPE's reverse tree did not vanish
from the net when they implemented things. Resolvers of bug ISP's in Sweden
did not cause the Swedish endusers to lose connectivity to the internet.
Where are these problems you are speaking of?
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
