On Aug 22, 2008, at 7:23 AM, Dean Anderson wrote:
Sigh. Above is precisely the sort of non-critical analysis that causes these things to have so many problems.
Instead of making fun of other peoples' lack of critical thinking, you might want to take responsibility for your own thinking and let others take responsibility for theirs.
The problem with your reasoning is that the resolver is configured with a trust anchor, and the zone with the missing DS records is below that trust anchor. So the resolver is required to validate the entire trust chain up to the trust anchor. When it does this, it will discover a problem.
Suppose this is a host in .SE, and you have a trust anchor configured for .SE. And the name you're looking up is avalon.fugue.se. So you go to .SE, and it tells you that fugue is unsigned, because your attacker has forged the response. The signature doesn't verify. So you discard the response from the fake .SE, and try again. If the attacker has complete control of your path, the lookup will never succeed, which is the desired result. If the attacker is doing a scattershot attack, the next response that comes back will probably be the correct one, and you'll be back in business.
Suppose the response from .SE is correct, but the response from fugue is modified to remove the DS records. .SE says fugue is signed. So you discard the forged response from fugue, and the same thing happens.
Is there some avenue of attack I've missed here? Do I fail to correctly understand how the protocol works in some subtle way that makes your argument correct, and mine mistaken?
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
