On Wed, Jun 03, 2009 at 03:27:42PM +0900, Masataka Ohta wrote:
> Though we have to trust the zone administration put correct referral
> and glue data in a master zone file, unless we use DNSSEC, we don't
> have to trust the zone administration never issue certificates over
> forged keys of child zones.
>
> You know, the former operation is much simpler, thus more secure,
> than the latter.
If an attacker can get its bogus data into the referring zone, who
cares whether it's NS data or DS data? One of the important things we
are trying to add with DNSSEC is some means of assuring ourselves that
the referral we got was the one that comes from the actual authority
for that referall, rather than some other agent spoofing the response.
DNSSEC appears to provide that assurance, and so far you have provded
not one jot of evidence that it does not.
I fail completely to see how it is easier to put the wrong DS record
in the parent than it is to inject bad NS data in there. If you can
put illegitimate data in, there are two possibilities:
1. You put it in via some legitimized mechanism (e.g. via SQL
injection, you manage to get data that wasn't intended to be in
the zone into the zone). This causes that illegitimate data to be
treated as legitimate, and probably signed and such. This is a
bad attack, of course, but it is available today. This is no
different than being able to plant some evil file on the corporate
file server inside the VPN: the security is breached not by
failure of its mechanisms, but by failure of authentication.
DNSSEC doesn't solve this, I agree; that's because the
_provisioning_ of data is beyond the scope of the DNS protocol
itself. In any case, surely a more effective attack in this case
is to get phony NS or A data (or whatever) into the zone than to
put phony DS data. The latter will get you at best a DoS, whereas
the former allows you to take control of the target zone.
2. You put it in via some illegitimate mechanism (e.g. by
intercepting the wire transmission and adding the data to the
stream). Unless the keys are somehow compromised, this
vulnerability is exactly what DNSSEC aims to stop. I don't see
any argument from you that this DNSSEC capability is not
effective. If you have such an argument, it'd be nice to hear it
before we continue with the efforts at deployment.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
