On Tue, 2007-07-31 at 17:24 -0400, Keith Moore wrote: > IMHO, "running code" gets more credit than is warranted. While it is > certainly useful as both proof of concept and proof of > implementability, mere existence of running code says nothing about > the quality of the design, its security, scalability, breadth of > applicability, and so forth. "running code" was perhaps sufficient in > ARPAnet days when there were only a few hundred hosts and a few > thousand users of the network. It's not sufficient for global mission > critical infrastructure. A simple axiom "Do not execute scripts from strangers" is often violated. The Noscript plugin for Firefox represents an excellent (and highly recommended) example of this principle in action. Unfortunately, a mouse-click is often not required for a computer to become 0wned. : ( When coping with spam, security issues related to DNS are often ignored. Concerns raised in the draft-otis-spf-dos-exploit were dismissed by suggesting list of bogus NS records are not limited to the same extent anyway. Many libraries implementing SPF do not impose limits on the MX record, or the number of NXDOMAIN, suggested as fixes in the OpenSPF group's rebuttal. http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis Ironically, the rebuttal points out a bogus NS record method that worsens a DDoS barrage that can be caused by SPF. SPF remains a significant risk, even when limited to just 10 SPF record transactions per email-address evaluated. With local-part macro expansion, these DNS transactions represent a gift of a recipient's resources given at no cost to the spammer. DDoS attacks made absolutely free and unstoppable! Offering a method to macro expand elements of the email-address local-part, when used in a spam campaign, allows a _single_ cached SPF record to cause an _unlimited_ number of DNS transactions from any remote DNS resolver servicing SPF libraries. Uncached targeted DDoS attacks are not tracked by email logs and can not be mitigated. The gain of this attack can be highly destructive, while remaining virtually free to spammers wishing to also stage the attack. In addition to offering a means for staging a DDoS attack on authoritative servers, unfettered access afforded to remote recursive DNS servers by SPF scripts permits brute force DNS poisoning. Even knowing whether SPF related exploits are ongoing is not easily discerned. With the current state of affairs related to web browsers, the axiom "Do not execute scripts from strangers" is a concept that should be seriously taken to heart. -Doug _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf