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 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>, or you are likely to be blocked. _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
