On Fri, 22 Aug 2008, Matt Larson wrote:
> Dean,
>
> On Fri, 22 Aug 2008, Dean Anderson wrote:
> > 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.
>
> Your analysis is incorrect.
>
> A referral from a signed zone either needs to have a DS and RRSIG(DS),
> indicating the child zone is signed and allowing the chain of trust to
> continues into the signed child, or an NSEC and RRSIG(NSEC) showing
> that no DS exists, proving that the child zone is unsigned and
> insecure. If a referral from a signed zone contains neither DS nor
> NSEC, the validating resolver assumes that a man in the middle has
> stripped them and the response is bogus.
Good call. However, NSEC and NSEC3 records are static, and
RRSIG(NSEC/NSEC3) records are statically calculated. The attacker need
only read RFC5155 section 12 for instructions on how to compute a valid
hash for use with the (known) NSEC/NSEC3 record.
--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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
