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

[Brian Wellington <[e-mail]>]

On Sun, 29 Jul 2001, Greg Hudson wrote:

> > Which sounds more secure?  2, obviously.  Until you notice that the
> > key is read from disk also.
>
> First, the reason not to set AD bits on unchecked data is not to
> protected against compromised data on the server, but to detect
> expired signatures.

Either I'm misunderstanding you, or you'd have no problem with setting AD
on unchecked data after only checking the expiration time was.  No crypto
is needed to detect expired signatures.

> Under your scheme, an authoritative server might
> yield a different value of the AD bit than a checking recursive
> resolver, and that's confusing and error-prone.

Possibly.  But this is a reason why the draft specifies that the server
MAY classify local data as Authenticated.  If the server will never be
serving expired data (that is, is resigned on time), then that won't
happen.

> Second, you've given an argument why it might be acceptable to set AD
> on non-checked responses, but do not give any motivation for doing so.
> An authoritative server is probably not acting as a recursive resolver
> for stub resolvers; if it is, then it needs to be prepared to do
> cryptographic checking if it wants to set AD bits on out of zone data
> at least.  I can't envision a realistic scenario where your scheme
> adds any value.  A cryptography-free authoritative server which also
> serves stub resolvers and sets AD bits but only on in-zone data?
> Seems a bit of a stretch.

Just because a server can do crypto doesn't mean it should.  Crypto
operations are slow, and there's no reason to slow down either lookups of
local data and/or server startup when the zone is properly managed.

Brian



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