On Thu, 21 Aug 2008, Frederico A C Neves wrote:
> On Thu, Aug 21, 2008 at 10:09:50AM -0400, Dean Anderson wrote:
> > On Tue, 19 Aug 2008, Ted Lemon wrote:
> >
> > > On Aug 19, 2008, at 8:15 PM, Dean Anderson wrote:
> > > > A verifying
> > > > DNSSEC cache can be poised with bad glue records using the poisoning
> > > > attack, with only a slight change to the Kaminsky software.
> > >
> > > Do you mean that it can be convinced that an answer is valid when it
> > > is not?
> >
> > I mean that a validating cache can be convinced to think that a
> > delegation is unsigned by getting unsigned glue records without a DS
> > record. This glue can refer to a working (bogus) nameserver, or it can
> > be a DOS on the delegation. I might try to demonstrate this by running
> > code next week sometime.
>
> Even knowing that this will probably ruin our deprive of your company
> for the following week I'll point you out to carefully read 4035
> sections 3.1.4, 4 and 5.
>
> If the child is signed the DS is mandatory with the referrals, if it's
> not signed the NSEC that proofs it's inexistence is mandatory. So
> you'll still need to make the RRSIG for the NSEC, and AFAIK you'll
> need access to the parents private key to make it happen.
Sigh. Above is precisely the sort of non-critical analysis that causes
these things to have so many problems.
It is manadatory in the _proper_ response. Of course, the _forged_
response can have anything the bad guy wants. If the bad guy decides
not to follow 4035 (gasp! we never thought the bad guys might not follow
RFCs!), and instead responds with a forged response that doesn't have
the DS RR, and the delegation and glue records are normally unsigned,
then the resolver will conclude the zone is unsigned, and place
undeserved trust in the referral.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
