On Aug 16, 2008, at 4:56 PM, Dean Anderson wrote:
For example, besides the previously mentioned key rollover
issue, I understand that DNSSEC also doesn't allow the protocol to be
changed securely. And we do expect the protocol to be changed.
As a non-expert in DNSSEC, I have to admit that I am not aware of an
expectation that the protocol will change. Can you expand on this?
Also, is there a way to build the protocol so that it can be changed
securely? I would think that the way this would happen would be that
the resolver would ask different, or additional, questions. Does the
current protocol preclude that?
The hype surrounding the Kaminsky report is unjustified. For example,
one can't steal bank information with this attack, as the mainstream
press has reported.
This isn't true, because if I can convince you that a naive user that
he or she is talking to your bank, I can get them to enter their
information into a web page that isn't protected by SSL.
Alternatively, I can find a server that has a valid SSL cert, crack
it, set up a redirect that sends the user's password through that
server. They wind up doing an SSL-validated transaction that appears
to be completely fine, but is not. Since I've suborned an existing
server, even once the hack is discovered, if it is, it can't be traced
back to me through the SSL cert trust chain.
It's true that some modifications to the browser would mitigate this,
but those modifications would go against current practice - it's not
uncommon for authentication to go through some kind of cross-site
redirect. So there is a risk that if browsers were modified to do
this, people would disable the feature.
Furthermore, since preventing this attack depends on changes to
browsers, such changes would only protect those people who routinely
upgrade their browsers; unfortunately, those are the same people who
are least likely to be fooled by an attack like this in the first place.
So while I realize that there has been a lot of theatre around the
Kaminsky attack, I have to say that it still seems very credible to me.
There has been some assertions that SMTP anti-spam security depends on
DNS security. These schemes don't hold water. In 2003, I showed that
the
information theory result that no communication system can be proven
free of covert channels implies that no communication system can be
designed 'spam-free'.
I think you carry this argument a bit farther than is justified.
It's probably true that no security system can be perfect. Locks
don't keep out determined lock pickers. They certainly don't keep
out people with fire axes. But they do raise the cost of entry.
That's what a good computer security system does too. That's the
goal of DNSSEC. Of course DNSSEC is still crackable, and of course
people will imagine that it is not, in much the same way that they
place too much trust in locks. The question is, are they better off
with the lock, or without it. I don't think you've really spoken to
that question here.
I also seem to recall some claims that DNSSEC can create more
opportunity for cryptographic DOS attacks on DNS servers. Can anyone
speak to that?
You could definitely DoS a validating resolver by asking too many
questions. To the extent that people do that, it seems likely that
the point of validation will move closer and closer to the end-user.
So to me this seems like a problem whose solution actually improves
security, and therefore it's kind of problem we'd like to have. But
you're right that it's a problem.
In practice, I expect that the way DNSSEC resolvers will be deployed
initially is that people will install them on their own computers.
The same caching resolvers may be used, since DNSSEC works through
caching resolvers. So the infrastructure won't change much, and the
early adopters won't suffer from the DoS problem.
However, if part of the deployment involves putting DNSSEC-validating
resolvers in the DNS caching servers, then there will be an
opportunity for DoS attacks, and so deployments of that type will have
to be done very carefully.
However, I think the fear of this particular sort of attack isn't
substantial enough to justify not signing the root zone or the TLDs.
As I understand it, preventing cryptographic DoS attacks on
authoritative name servers is one of the key features of the current
DNSSEC architecture. But as I say, I'm not an expert, so if I'm
wrong about this I'd like to hear why.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
