Linus Nordberg linus@nordberg.se writes:
nisse@lysator.liu.se (Niels Möller) wrote 07 Oct 2004 18:21:42 +0200:
| The problem here is that the f.com MTA sends mail on behalf of a user | that "really" belongs to a different MTA, for s.com. So this is just a | special case of relaying.
| The natural conclusion is that we must drop the notion that the keys | can be used to authenticate the from address. A key can only be used | to authenticate the MTA which owns it.
Unless we could come up with some working (!) way of delegating the right to authenticate a sender.
Theoretically, f.com could show r.com some proof that it's entitled to speak for stan@s.com. Perhaps f.com got something from s.com during their transaction that serves as such a proof?
For hashcash payments, you could do it by removing the salt, and instead make the response depend only on the envelope receiver and the message contents. Might work, but I'm not sure what security holes that might introduce.
For authentication, it's different. With MTA keys, it basically works like this: The receiving MTA r.com trusts the forwarding MTA not to spam, or at least take all reasonable precautions. The forwarding MTA, f.com, trusts the sending MTA, s.com, not to send spam (or else it requires s.com to make a hash-cash payment).
Hmm, it strikes me that f.com may need to accept and forward email that uses no authentication. I think we should let f.com tell r.com what level of authentication it had when accepting the email. Not necessarily on the SMTP-level though, it may be sufficient to let f.com add a header to the message contents line expressing that (analogous to received: lines).
One may be able to do something more sophisticated of we replace the MAC:s by digital signatures, but I think that will add too much overhead (imagine a list server with a few 1000 subscribers, which needs to sign every copy of the message).
Bottom line: I think MTA keys is the simplest and lightest cryptographic infrastructure we can get away with.
The obvious downside with dropping the coupling of sender and recipient is that as soon as anyone@a.com and anyone@b.com have exchanged mail, the road is open for all users at a.com to spam all users at b.com and vice versa. Maybe that's acceptable? Or do you have any other smart ideas up your sleeve?
One can associate local per-user information with the keys. b.com can tell a.com that "sure, we have a shared key, but for email to user@b.com, you have to provide hash cash anyway".
It's quite hard to predict how all these things will work out in practice, so I think it is appropriate to specify the protocol with the "mechanism, not policy"-principle in mind.
Regards, /Niels