rchandra
Stargate S G-1 And Atlantis Fan
Premium
join:2000-11-09
14225-2105
clubs:
| auth and trust
STARTTLS is certainly a viable solution technically. The immediate problem with that is the cost of the current X.509 CAs. It's pretty good though. In this case, we've chosen to trust a handful of entities. Just look some time at the issuers of the CAs that come with your favorite TLS/SSL-enabled Web browser (I counted 19 distinct companies, might have made some mistakes, for Mozilla 1.5).
The idea of having keyservers (or even DNS) is good, but then the issue of trust arises (as in the web of trust idea). In this case, one is going to have a little bit more challenging time figuring out which key signatures one will trust because there are a lot more of them than just the VeriSigns, GeoTrusts, and Equifaxes (etc.) of the world. Just about anyone can buy a domain name registration and insert a DNS key record into their zone, but does that mean I want to receive mail from you? It's more than just authentication in this case. I may never want to receive email from optinoffers.com for example, because it is spam.
There are a number of peripheral issues I'm not sure have been thought of.
First, I think the whole thing is a mess, and we're trying to adapt a system and protocol that was specified when one could "trust' (to some extent anyway) that when a computer HELOed as monet.cs.berkeley.edu that it really WAS monet. We trusted that if an MTA said a piece was from linus.torvalds@transmeta.com that it really was. Trying to adapt an existing protocol for security and authenticity is troublesome at best, and sometimes the only true solution is a total rewrite/respecification.
Second, until any scheme is universally adopted, there will always be the possibility of either wanting or needing messages from the older system. The day that one says one will not accept delivery of an email if it's not authenticated will be the day one loses email one wished to receive. And for businesses this can also mean the day they start losing customers/clients. And paradoxically, reimplementing email this way is not atomic; there will have to be a transition period (it's a regular catch-22). But once a protocol becomes entrenched, it's exceedingly difficult to move forward. Look for example at IPv6. It's taking "FOREVER" to get deployed.
Third, what about third party servers? There are quite a number of companies that don't want to blur their company focus by establishing IT or Internet departments, and they outsource this task. So for example Verizon doesn't handle email; they hire Brightmail to do it for them (maybe a poor example, but it illustrates the point). When Verizon has a customer announcement, the From: will be something like custcare@verizon.net, but the cert the MTA will present may be for outgoing.brightmail.com or similar. Will some tweaks to existing software be able to handle having and presenting the correct cert based upon the message's origin or originator? For example, I've recently configured my Sendmail to authenticate when relaying outgoing mail through Verizon, but that's based on the recipient mail server, not the origin. Also, what's the liability of a company that doesn't present a correct cert when doing somehting like that?
Fourth, what do providers do when problems arise? Let's say a provider allows a customer onto their systems, and then unbeknownst to them the customer starts spamming. Even if within a day the spam stops flowing, the provider's reputation is damaged, and who knows for how long?
--
English is a difficult enough language to interpret correctly when its rules are followed, let alone when a writer chooses not to follow those rules. Blog is here |
