On Mon, Jan 17, 2011 at 08:54:05AM -0500, Ted Lemon wrote: > Hm. Okay, so the reason this is an issue is that I'm assuming the > resolver doesn't do its own validation. And you're right that if it > doesn't do its own validation, it's not much worse off using this > option than not using it; the degree to which its worse off is that > this option allows the attacker to deterministically attack certain > domains, whereas without the use of this option the attacker would, > in a best-case scenario, be relying on chance to succeed in its > attack.
If the resolver doesn't do its own validation, then it is not allowed to treat the AD bit as meaningful unless it can trust the DNS server handing it that bit: In any case, a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel. (RFC 4035, section 4.9.3). Presumably, then, the stub needs somehow to have authenticated the DNS server in question otherwise before accepting the claims about signature validation. I can't think of any way to do this under DHCP, but maybe I don't know the protocol well enough. > I think you also need to document the signing architectures that > will work with this option: either don't sign the zone that contains > referrals for the internal zone, or else sign two copies of the > zone; one that's visible from outside and contains no referrals, and > a second one that's visible from inside, and contains referrals. This is the point I was trying to make over on mif: I think that there's a potential issue here with "closest TA" validation strategies, but I suspect that we're going to need different TAs for these "internal zone" cases. Or something like that. A -- Andrew Sullivan [email protected] Shinkuro, Inc. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
