Re: [dnsext] Possible DNSSECbis clarifications

[Mark Andrews <[e-mail]>]

In message <01b701cbed61$61cd3480$25679d80$@[e-mail]>, "Marc Lampo" write
s:
> A "theorical" attack would be a "man-in-the-middle" change the trailing
> SOA, thus causing the secondary server to throw away each zone transfer it
> attempts (if it "believes" the second SOA is correct, in the absence of a
> valid RRSIG for it - that trailing SOA).
> 
> If a secondary name server is prevented from downloaded update of the true
> zone data, this is a security issue, I would say.

And we have solutions a solution to this.  It's called TSIG and has
been deployed for years with both signed and unsigned zones.

> It may not be that easy to set up this kind of attack, but then again,
> perhaps in some time somebody might show it can be done.
> My feeling is that, with DNSSEC, both SOA's in a zone transfer should be
> signed in a proper way (that they can  be validated) even if the SOA's
> differ.

DNSSEC as currently deployed cannot do this as RRSIG's are not
signed.  Early DNSSEC specs had the concept of a zone SIG.  This
covered the signatures.

> Which leaves us with another "hole" :
> Suppose potential attacker does indeed change trailing SOA, and fails to
> produce a validatable RRSIG, then what should the recipient do with the
> zone it downloaded ?  Since it can no longer verify if the content of the
> zone did not change, at the master, since the start of the zone transfer.
> 
> Marc

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]