Re: Security comments re draft-ietf-dnsext-unknown-rrs-00.txt

[gson@nominum.com (Andreas Gustafsson)]

> One problem I have with this draft is blind Kashpureff attacks. One of
> the reasons Kashpureff was successful is that implementations didn't
> check returned data very hard, rather they simply cached it and passed
> it on later.  What this draft does, I believe, and regardless of
> DNSsec, is make this kind of attack trivial again.

I don't think so.  I believe you are referring to a cache poisoning
attack, and the reasons those worked was that servers cached RRs
without checking their *origin*.  This is an entirely different issue
from checking their *contents*.

Also, those attacks involve record types used by the resolution
process itself, such as NS and/or A records, which are not unknown
types and therefore not affected by the draft.

> Additionally, I can imagine a cleverly crafted unknown RR type that
> tickles an resolver implementation error, such as a buffer overrun or
> an off-by-one error, for a given set of clients, such as a particular
> unpatched version of Microsoft NT. Since a server simply passes data
> on, then you have no hope of distinguishing between proper data and
> bad data and protecting clients.

Any client that does not sufficiently check its network input, be it
from the DNS or some other protocol, is broken and needs to be fixed.
The DNS specifications have never explicitly required servers to
verify the internal format of the RR data, and adding such a
requirement is likely to mislead client authors into trusting the
server instead of doing proper checking themselves.

I'm not saying that such server-based checking should not be done - it
can be a useful part of a firewall designed to protect insecure legacy
applications.  It just shouldn't be required by the protocol.  We don't
require HTTP proxies to strip unknown HTML tags either, even though
they too could potentially be malicious.
-- 
Andreas Gustafsson, gson@nominum.com


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.