--- "william(at)elan.net" <william(_at_)elan(_dot_)net> wrote:
There is no way we can completely prevent replay attacks with signatures
Sure you can - if you're prepared to add a few further constraints to Internet
mail.
Abusive replay is solely possible because there is no provable lineage between
the original submitter and the final recipient. But such a lineage is provable
with signatures and a surprisingly few constraints.
The basic constraints needed are:
1) the initial 2821.RCPTO must derive from one of the 2822.To/CC/BCC addresses
2) Changes to the 2821.RCPTTO as a mail transits the system can only be made by
the current 2821.RCPTTO and the current recipient proves this right via a
signature from their domain. Let's call this the Provable Right to Forward or
PRF.
An example: If I send an email to someone(_at_)aforwardingservice, the submitted
email has a signature that proves that I, the 2822.From/Sender intended the
email for the 2822.targets. The 2821.RCPTTO matches the 2822.target, so the
lineage is valid.
At @aforwardingservice, the 2821.RCPTTO is changed to @finaldestination and at
the @forwardingservice adds a signature proving it is the current 2821.RCPTTO
and thus has a right to the change RCPTTO to a new target.
At @finaldestination, the provable lineage chain is traced back to the original
2822.target. Any break in the lineage implies an unauthorized change to the
2822.RCPTTO and can thus be identified as a replay attack.
The granularity of the PRF has some interesting implications. If done at the
domain level, you constrain replays to the PRF domain. That is to say you can
only reply to someone in your domain. If the PRF granularity is at
localpart(_at_)domain you constrain replays to the individual address. That is
to
say you can only reply to yourself!
Of course there are some serious implications with these two constraints.
Firstly there has never been a necessity to tie the 2822 recipients to the 2821
recipients, though clearly this is the extremely common case.
Secondly, the BCC header has to remain in the email and thus obviously
submitted separately from the other recipients to maintain the BCC
functionality. SUBMIT of course can do this on behalf of UAs.
Finally, 2821.RCPTTO fan-outs such as aliases and mailing lists (or their
SUBMIT service) have to make separate 2821 transactions for each separate PRF -
this is where granularity has a big impact. A per-localpart PRF implies
dropping multiple RCPTTOs from 2821. Those who believe that multiple recipient
email provides a serious saving to Internet bandwidth will howl about this (on
a global basis we already know the average number of recipients to be much less
than 2, but on a local basis it can clearly be an issue).
A lof of people will baulk at such serious implications, but it does completely
eliminate what we are calling "replay attacks" (I prefer to call them
unauthorized forwards).
The question is, is PRF worth it? If I had my druthers I would probably adopt a
"wait and see" attitude, to paraphrase our politicians, and consider this as a
possible MASS-II deliverable in the event that a) replay because a serious
issue in practice and b) the mitigation strategies prove insufficiently
effective.
Mark.