On Mon, 22 Apr 2002, Eran Tromer wrote: > Eli Marmor wrote: > > Eliran wrote: > > > It's very nice of the subscribers of this list that everybody > > volunteers to help or find solutions for this problem, from using > > amAVis, to checking the headers. But the sad truth is that there is no > > solution. Maybe except for publishing ads in all the leading newspapers > > in the world, telling everybody: "The viruses that you've received from > > us were sent to you from friends of you, not from us"... > > Indeed. > And the only long-term solution is to educate users about signed e-mail, > and to help and/or pressure producers of e-mail software to improve > their S/MIME and PGP support. Signing should be enabled by default, and > possibly also encryption (though here there are political hurdles). > Unsignedplaintext e-mail is a historical remnant that must be abolished. > > To name one culprit, I find it preposterous that to this date Mozilla > has a half-cooked S/MIME support and no PGP support. > > > The toughest part is key distribution. Both the existingcentralized > solutions and the distributed ones are highly problematic for common > use: to use S/MIME you essentially have to obtain certs from VeriSign > (or its subsidiary Thawte), and to use PGP you need to know people who > know people, or to use external verification channels. > > However, if the only authentication we care about is "this e-mail was > sent by someone who owns this e-mail address", then it's possible to use > an existing distribution network, namely DNS, because you can trust a > domain owner to certify e-mails coming from his domain. I propose the > following. > > When an e-mail account is created, a PGP key pair is generated. The > private key is given to the owner of the account. The public key is > published by the SMTP server serving this account (determined according > to the MX DNS record), using an extension to the SMTP protocol (say, > using a new "PKEY OF" SMTP command). > > When you get a signed email from [EMAIL PROTECTED], your mail client contacts > mail.isp.com:25, issues a "PKEY OF [EMAIL PROTECTED]" command, and declares > the e-mail valid iff it got a public key which matches the signature. > The public key may be cached.
This is basically the equivalent of 'finger', although this is for a a domain name, rather than for a server. care must be taken to prevent privecy issues (e.g: what relpy do you give for a wrong address?) > > Problem: the SMTP server may need to delegate the request in real-time > to another SMTP server. The SMTP e-mail infrastructure is not designed > for this kind of real-time stuff. > > An alternative would be to do all communication via standard e-mail. > Namely, upon receipt of a mail from [EMAIL PROTECTED], your mail client would > send a message to "[EMAIL PROTECTED]" containing > "[EMAIL PROTECTED]" as the body. The ISP's SMTP server would (hopefully) > recognize this and reply with the approptiate public key [1]. This is a > true end-to-end solution that's transparent to proxies and firewalls. > Latency may be pretty harsh, but some client-side caching would go a > long way to address this, since the e-mails about whose authenticity you > care are usually ones you've seen before. > > Another alternative is to get the public key from the ISP via HTTP (and > thus get free caching, firewall and proxy support). The URL can be > published via the DNS infrastructure. > > One more point -- how do the messages get signed? Preferably by the > sender's mail client, but if there's some reasonable authentication > setup between the sender and its ISP (say, by login password and IP > address) then the ISP may add the signature automatically. This can > greatly speed up the transition to such a system. > > I think that if a solution of this sort is standardized and > appropriately evangelized, within a few years the majority of e-mails > will be signed. The time to start is now. > > Wadd'ya think? > > > Regards, > Eran Tromer > > [1] You'll want to add a cookey to prevent an adversaty from spoofing the > e-mail reply. BTW, note that all of these solutions are susceptible to > DNS spoofing and TCP man-in-the-middle attacks during the public key > request. That's still a great improvement over today's situation, and > will be automagically solved with IPv6 and a secure DNS infrastructure. -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
