Re: AS IF: draft-ietf-dnsext-ad-is-secure-03.txt

[Brian Wellington <[e-mail]>]

On Sat, 28 Jul 2001, Greg Hudson wrote:

> I have yet to understand why anyone wants to set the AD bit on
> unchecked data.  Sure, an authoritative server shouldn't have to do
> cryptography, but it also shouldn't ever need to set the AD bit unless
> it's also acting as a recursive resolver for clients.  In which case
> it had better be prepared to do cryptography if it wants to set AD
> bits.

Scenario 1: A server reads secure data from a zone file, trusting the
disk.  It then can set the AD bit on responses from that file.

Scenario 2: A server reads secure data from a zone file, and the key from
a configuration file.  Before setting the AD bit, it verifies the
necessary signatures.

Which sounds more secure?  2, obviously.  Until you notice that the key is
read from disk also.  If someone can corrupt your zone files so that you
give out bad data, they can surely corrupt the key so that the bad data
properly verifies.  Or, if they don't want to do that, they can just
hijack your server and insert bad keys into the running process.

The point is that if you trust a server enough to believe that it has
verified data, you should trust it enough to read signed data from disk.
Conversely, if you don't trust it enough to read signed data from disk,
you shouldn't trust it enough that you believe it when it claims to have
verified data.

That's why I believe that setting the AD bit on locally configured data is
acceptable.  It's no more or less secure than having the server verify it.

Brian



to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.