DNS security and spoofing (Re: [cobalt-security] Anyone else get this error?)

["E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>]

EC> Date: 30 Dec 2002 08:35:31 +0300
EC> From: Eugene Crosser


EC> Actually, your solution looks insufficiantly paranoid to me.

I agree.  If a better way of which I'm unaware exists, please
speak up. :-)


EC> Imagine you are somehow tricked to dowload a bogus root

This would be difficult.  When one has the roots' IP addresses
stored locally, one should not be vulnerable to cache poisoning.

However, you make a _very_ good point in that:

One could use brute-force bogus UDP replies at the proper time.
If "dig" or the supporting libraries are broken and use the same
DNS query ID each time, it would be trivial to spoof a UDP
response.  (Don't get me started on how networks should filter
egress to the world and/or ingress from customers...)

Such broken dig/resolver combinations _do_ exist, too.  IIRC,
Slackware 7.0 was afflicted by this... I've not made an extensive
search, so there could well be others.


EC> cache...  I would prefer to obtain the file by independant
EC> means (e.g. http[s]) and check its cryptograpic signature

HTTP would offer no benefit over AXFR, which also utilizes TCP
instead of UDP, and some benefit over UDP-based NS queries.  (DNS
queries have a 16-bit identifier; TCP has 32-bit sequences.)
Both plain HTTP and unauthenticated AXFR are vulnerable to MITM
attacks.

HTTPS would be very nice.  The DNS protocol also has had some
extensions (TSIG and TKEY) similar to HTTPS's SSL/TLS.


EC> before replacing.  The impact of getting a fake is too high.

Indeed.  If you know of an authoritative HTTPS source for the
roots, I'm certainly interested in learning of it. :-)  Likewise,
I don't recall any TSIG/TKEY support from the roots.  I'd love it
if I'm wrong about this...

Finally, note that named would be just as vulnerable as dig,
assuming both generate comparable DNS query IDs.  Letting named
handle the updates wouldn't buy any additional security, and
suffers from the permissions issue.

It is rather odd how DNS security has lagged behind HTTP, no?


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@xxxxxxxxx>, or you are likely to
be blocked.