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

From: Dennis Glatting <[email-masked]>
Date: Fri, 15 Dec 2000 22:14:07 -0800

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.

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.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: [email-masked] (Andreas Gustafsson)
Date: Sat, 16 Dec 2000 13:33:57 -0800 (PST)

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

> 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, [email-masked]

---

From: Dennis Glatting <[email-masked]>
Date: Sat, 16 Dec 2000 14:40:13 -0800

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

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

---

From: [email-masked] (Andreas Gustafsson)
Date: Sat, 16 Dec 2000 19:53:25 -0800 (PST)

> Additionally, we cannot predict what future RR types will have on the

Unknown types are no more prone to poisoning than known types are.
The anti-poisoning logic used by modern DNS servers is not based on
examining the contents of the RRs.

> case, the draft says: DNS content firewall are non-compliant.

Yes, that's what it says.  I'm not sure that's a problem - you could
argue that any firewall system is non-compliant by definition because
its very purpose is to sometimes fail to provide the services defined
by the protocols being filtered.  If necessary, the text of the draft
could be changed explicitly make firewalls compliant, for example by
changing "must handle transparently" into "must be capable of handling
transparently".
-- 
Andreas Gustafsson, [email-masked]