Date: Fri, 03 Jan 2003 17:24:22 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: Dave Hayes <dave@jetcafe.org>, dever@getaclue.net, freebsd-chat@FreeBSD.ORG Subject: Re: Bystander shot by a spam filter. Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz wrote: > > > Authentication is a prerequisite to being able to enforce policies > > > for authorization. > > > > No, it's not. > > > > Consider: > > > [...] > > > > Basically: there is no authetication, only authorization, since a > > certificate does not provide me with identity, unless we modify the > > domain name registration system to require proof of identity. > > 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. The DNS solution depends on the fact there there are two DNS authorities involved, and you would need to compromise both of them, in order to substitute false information for the domain name (which in this approach, is the credential). Because you would have to subvert both the reverse IP address delegation via .in-addr.arpa., which is easy to subvert by placing false data in your DNS server so that gethostbyaddr(3) returns a false name, AND the forward lookup -- which you would have to subvert by placing false data in *someone else's* DNS server, you are able to trust the cross-check information. In fact, most mail servers today refuse to accept email from hosts which fail this cross-check already... so no additional requests are added in the new system, and therefore no additional latency. > 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. > Also, in your system the people running the network write > the policy, not the people receiving the mail. Will the ISPs > in Taiwan implement a policy that I can agree with, or do I > have to blackhole all of Taiwan? If you want to implement your own policy, then buy your IP connectivity from someone who will permit you to run your own mail server, and is willing to either provide you with a static IP address to do it, or is willing to let your mail server designate their mail server as a SMART_HOST(), and forward all email through it. 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. If you want to blackhole Taiwan, obtain your services from an ISP that only recognizes certificates signed by people who will not sign them for Taiwan (as an example). > > Yes. But having a key in hand does not provide sufficient data > > to discern the sender's identity. The ability to send anonymous > > email is not lost... in fact, given the way today's blacklists > > operate, it is regained. > > You still need an authority in the system, perhaps to sign > personal keys. Not personal keys, domain keys. > But that's true of any system that allows you to > receive mail from a select group of people you don't know, your > proposal included. In your system, the authority always returns a > `yes' or `no' answer to the question of whether a particular > principal is authorized to send mail. Yes. You could even go so far as to retrofit a recipient system or mail client to as "given this email, would you sign a cert. for this sender, were they to have asked you to sign their cert."; this lets you deploy the infrastructure incrementally, rather than having to rely on a global Internet "flag day". > I claim that the authority ought to return some information about > the principal that would permit the implementation of more > expressive policies. That information doesn't need to include a > name and SSN, but it might have a `SPAM history' of some sort and > SPAM statistics for the originating ISP. Then I could say, ``I > don't want to receive mail from anyone who has sent confirmed SPAM,'' > or ``I don't want to hear from people who use anonymous remailers''. Anyone can start any authority they deem fit. If you want an authority that will sign certs to get this information, then you could embed the information as name/value pairs in the cert, or as SPAM records into your DNS service associated with the certificate, etc.. If you are a SPAM'mer, and actually believe people want SPAM, then you will believe that they will add your public key to the list of signing authority public keys, and you can sign certs for your SPAM as much as you want. Actually, there are classes of SPAM that people may be willing to accept, based on the function of their email account. An office manager may be willing to accept those about toner and ink jet cartridge refilling, if in fact they are interested in those services. > Of course, there are ways to abuse the policies I just stated, so > further refinement is needed. Ideally, we would have an inclusion > set. Yes. This is trivial, as well. You merely note to your mail server the public keys of the certificate authorities whose certificates you are willing to accept incoming SMTP connections from; the longer the list, though, the more time it would take; if you want to take this to extreme, then you would index by issuing authority, look in the cert. for the authority identifier, and verify that the public key matching that identifier was the one that signed that cert.; the result is the same, but the lookup remains O(1), not matter how many authorities you want to accept. 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. -- Terry 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?3E1637C6.42ADF04A>