On Aug 25, 2008, at 5:48 AM, Masataka Ohta wrote:
>> I think you're seriously discounting the importance of human factors
>> when you say that the security of the DNS channel doesn't matter.

> You're seriously discounting the importance of human factors
> when you say that the security of the DNS channels through zones
> don't matter.

Ohta-san, the way argument works is that you make a statement, and
then you give a reason why it's true. And then if I agree with your
reason, and agree that your reason applies, I have to agree with your
statement. Just making a statement isn't enough - if we do that,
then we wind up just contradicting each other over and over, and never
coming to a conclusion.

The problem with your thinking here is that it's _always_ true that if
the server for a zone is pwned, you can't trust the contents of the
zone or subzone of that zone, because the person who pwned the server
can arbitrarily modify the data the server serves.

With DNSSEC, however, there are two differences. First of all, if
the server has not been pwned, then bogus data inserted by a third
party will be detected. This is because the zone has been signed,
and there exists a validation path that can be used to verify that

The second difference is that with DNSSEC, the mere fact that the
server has been pwned does not *necessarily* mean that the signing key
has been revealed. This is because the administrator has a choice as
to where to do zone signing - it need not be done on the same machine
that serves the zone. So in the case of DNSSEC, a sufficiently
paranoid security policy protects against a vulnerability that PODS
simply cannot protect against.

There are still ways to forge the contents of a DNS zone. But they
all involve getting access to the signing key for that zone. So yes,
DNSSEC is not a panacea. If you ever thought that I was arguing that
it is, please stop trying to convince me of that - I already realize
that that is the case.

to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.