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

[Dennis Glatting <dennis.glatting@software-munitions.com>]

Andreas Gustafsson wrote:
> 
> > 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.
> 

An unknown RR could be an A6. If a server doesn't understand an A6
then its cache can be poisoned and the resolution process impacted.
Additionally, we cannot predict what future RR types will have on the
resolution process.


> > 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.
>

Yet the draft implies, assuming I am interpreting Section 3 correctly,
a DNS content firewall is to ignore the data and pass it on. In that
case, the draft says: DNS content firewall are non-compliant. 

I do not believe a DNS content firewall will simply pass unknown data.
Assuming for the sake of argument that would be true, then the reality
would be many non-compliant servers thereby rendering the draft moot.


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