On Fri, 22 Aug 2008, Blacka, David wrote:
> If you had actually followed any of the discussions about DNSSEC over
> that last 13 years, you would know that this is false. Thinking about
> how it could break is what the vast majority of work on this topic has
> been about.
I have paid attention to many of these discussions, and have recently
reviewed some of the ones I didn't pay attention to. And indeed, there
hasn't been a thorough analysis. Instead, critics (such as myself and
Dr. Bernstein, perhaps others) were silenced. It appears that only
Bernstein and myself were noisy about being silenced. Most people would
just go away quietly, as many people expected myself and Bernstein to
do, and some have even told me as much.
Evidence of the lack of critical analysis is found in the several
serious flaws identified so far. More evidence of a lack of analysis is
found in the repeated cycles of going back to the drawing board and then
reporting "I think we have it this time", only to 'not have it', still.
The tri fecta is found in the acts silencing critics. These acts
conclusively discredit the claims that DNSSEC people were genuinely
concerned with critical analysis of problems. Yet, despite all these
contrary facts, Blacka still asserts DNSSEC advocates were somehow
genuinely interested in solving security problem, rather than some other
objective. There seems to be an irreconcilable difference of opinion
here. Perhaps another example might shed light on the credibility of
their approach:
I recently read David Blacka's blog entry on Anycast, where Blacka
asserted that Anycast had to be proven UNstable before anyone should
consider stability questions. Blacka suggests that non-root operators
had no experience or data to prove these things unstable--which is true
and root operators aren't sharing their data. Hold on! Why should
non-root operators have prove Anycast root operations are unstable using
root-operations data? Why should anyone ASSUME a new, untested service
will be stable? I think most people would agree that high stability
operations must have some proof of stability BEFORE deployment of a new
service. And once again, we see the same 'assume stability and deploy
without extensive testing' as before.
And after they asserted that TCP is stable for Anycast, they now want to
deprecate TCP for DNS. (RFC 1546, analysis, and testing show TCP
Anycast isn't stable)
This is a lesson to be applied to DNSSEC deployment plans as well.
"Deploy untested and hope for the best" is really not a credible
operations strategy.
> > And the delegation records are unsigned; the resolver has no way to
> > know if they are correct; The delegation was picked so that NSEC3
> > RR's didn't change with the addition, and so the NSEC3 RRs verify
> > correctly. The bad guy just uses those NSEC3 records 'as-is'.
>
> In all forms of DNSSEC (NSEC3 or NSEC) the delegation records are
> unsigned.
I noticed.
> This is not a problem because, if the delegation is secure
> (i.e., has a DS RRset), the referred-to zone MUST have a DNSKEY that
> matches one of the DS records. If not, then the response is
> considered bogus and (normally) thrown away.
It is only 'not a problem' in the ideal case where no one is trying to
trick the resolver. But when one is trying to trick the resolver, they
can succeed as I described. This is just exactly what is meant by
'non-critcial analysis'. You only considered the ideal case.
> > One can also do this exact same thing on signed delegations provided
> > you have an earlier copy of a covering NSEC3 record signed with the
> > same key. [So operators have to rekey anytime they create a new
> > delegation.]
>
> No, you don't. This old NSEC3 (or NSEC) RRset isn't valid forever.
The old record valid until its signature expires. As I noted, to avoid
the attack, one must rekey everytime a change is made.
> It is well understood that you are vulnerable to a replay attack while
> the old RRSIGs are still valid. Which argues for short signature
> durations, not rekeying.
Ok. But when you resign using arbitrary data controlled by the
attacker, the private key can be obtained. [There is a crypto attack on
rekeying] OOPS!!. Rekeying is out of the question for, say, .com, .net,
etc. I guess you didn't know that.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
