Date: Sat, 4 Jan 2003 15:26:41 -0800 From: David Schultz <dschultz@uclink.berkeley.edu> To: Terry Lambert <tlambert2@mindspring.com> Cc: Dave Hayes <dave@jetcafe.org>, dever@getaclue.net, freebsd-chat@FreeBSD.ORG Subject: Re: Bystander shot by a spam filter. Message-ID: <20030104232641.GA587@HAL9000.homeunix.com> In-Reply-To: <3E1637C6.42ADF04A@mindspring.com> References: <200212302207.gBUM74175262@hokkshideh2.jetcafe.org> <20021230235954.GB2072@HAL9000.homeunix.com> <3E10FD38.87438C83@mindspring.com> <20030103095508.GA10237@HAL9000.homeunix.com> <3E15E208.18128D71@mindspring.com> <20030103214648.GE10237@HAL9000.homeunix.com> <3E1637C6.42ADF04A@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Terry Lambert <tlambert2@mindspring.com>: > David Schultz wrote: > > A DNS-based solution doesn't save you from IP spoofing > > You are safe from "IP spoofing", because any such attacks would > result in the SYN-ACK going back to the spoofed system, rather > than to the system that was spoofing the IP. Therefore a TCP > connection would never be established, and it's not a problem. Right, you need to be able to sniff at least one packet in order to initiate or hijack a connection this way. I guess we'd better throw away the last remaining hubs out there and replace them with switches. Oops, ARP is insecure. > > and other routing-based attacks. > > Everyone turns off source routing. It's not on, and if it's on on > your routers, expect people to refuse to peer with you. I'm not referring to source routing. Say you're an unscrupulous ISP and want to send SPAM, and your recipients peer with you. You advertise to your targets that you have a really great route to microsoft.com, and thereby masquerade as microsoft.com. Now maybe BGP 4 has a mechanism to fix that, and maybe the attack is a bit far-fetched if you're trying to send millions of messages, but my point is that one shouldn't base the integrity of email on the integrity of a network that isn't secure. Another problem one might want to solve is that any user with a shell account on a system can spoof any other user on the system. If one of those trolls had an account on the freebsd.org cluster, for example, you'd never be able to determine who is the *real* Matt Dillon. ;-) Hence, per-user public keys. > > Also, in your system the people running the network write > > the policy, not the people receiving the mail. Apologies to Cliff for the grammar of this sentence. :-O > > Will the ISPs > > in Taiwan implement a policy that I can agree with, or do I > > have to blackhole all of Taiwan? [...] > If you dislike your ISP's policy, then take your patronage to a > different ISP, if you choose to rely on renting time on an ISP's > mail server, instead of running your own. [...] > > You still need an authority in the system, perhaps to sign > > personal keys. > > Not personal keys, domain keys. The problem is that the ISP sending mail to my ISP gets to dictate part of the policy. I can say, ``I trust this ISP'' or ``I don't trust this ISP'', but I can't say ``I trust certain users on this ISP''. Many people, particularly in southeast Asia, become victims when their ISP gets blackholed for tolerating SPAM. We can begin to address this problem if we can cryptographically identify individual users on each system. (As I mentioned earlier, any sort of trust authority in the system would have to be wary of potential abuses, such as creating lots of bogus user accounts for the purpose of sending SPAM. Perhaps this issue could be addressed by having a nominal registration fee, but the problem is orthogonal to the present discussion.) > In any case, I hope it's pretty clear that this type of thing is > completely workable, no problem, and support copetition, and > personal choice in relaxation of criteria, at least to the > terminal mail server, at which point the connection and envelope > information is implicitly destroyed, as the mail leaves the SMTP > transport. Yes, either your scheme or mine would be easy enough to implement. The fact that we disagree about some of the details is minor. PGP already has most of the required functionality, although if I were to do it, I wouldn't do it in the same way as PGP. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030104232641.GA587>