Simon Josefsson jas@extundo.com writes:
I read your draft, belated. I'm sure you have discussed and solved these issues already, but just for reference, below were my initial thoughts on the proposal.
At least some of the issues are addressed in the new draft.
I am not fully convinced by section 6 and 9.2, in particular: that it is impossible to abuse the MAC key management scheme. If a spammer can somehow fool you into talking to them, it seem the scheme is ruined. There may be subtle technical issues here.
At a minimum, vacation replies and bounces shouldn't count.
There may even be non-technical concerns with the approach; i.e., merely because you talk to someone doesn't mean you want them to talk to you.
Can you give some examples? In general, I don't think one should send email if one isn't prepared to receive replies and comments.
Secondary mail servers
There is no discussion how primary and secondary MX's interact, if they do at all. If they are intended to interact, I believe that may be a serious deployment issue.
I don't think we can require primaries and secondaries to share databases (even if think will probably work smoother if they do). Secondaries are unlikely to exchange keys with others, since they don't send email (unless they send email on behalf of other domains).
Do you think that even a periodic one-way communication between primary and secondary is unreasonable? I'm thinking about copy/rsync of the key and user databases from primary to secondary. (On the other hand, copying keys around is usually not a good idea).
A different approach might be to let the secondary accept authentication from other MTA:s on the primary's behalf, and check them later at delivery to the primary. Could work if we (i) make sure primary and secondary have the same "name", and (ii) store the used salt and received MAC in some header line.
This also depends a lot on how we decide to identify the MTA(s) for an organization.
Btw, what kind of MAC's are you thinking of? HMAC-SHA1 may be the simplest choice, even though I would prefer something based on a block cipher. The choice of MAC seem critical to get "fair" computation costs, i.e., it should be difficult to optimize the MAC much more compared to typical implementations.
I'm thinking of hmac-sha1, since it is well known, and it's the MAC I'm most familiar with.
Are there block-cipher MAC:s that are significantly faster (or better in some other respect)? If speed is important, perhaps one should look into MAC's based on universal hashing (e.g. http://www.cs.ucdavis.edu/~rogaway/papers/umac.html), I'm not at all familiar with that but at least they claim on order of magnitude higher performance than hmac-sha1. But perhaps that speedup is only for large messages; with the current spec, we only compute MAC:s for small messages.
/Niels