RE: Re: [spf-help] SRS for Exim

> From: Tony Finch
> Sent: Thursday, April 29, 2004 1:12 PM

<...>

>
>
> On Thu, 29 Apr 2004, Seth Goodman wrote:
> >
> > > A nice way to solve this problem would be to use asymmetric
> > > cryptography
> > > to sign sender addresses and publish the public key in the DNS.
> > > Unfortunately there's only space for about 100-200 bits of
> > > signature in an
> > > email address, which is too small for most asymmetric cryptosystems.
> >
> > Yes, this is an issue.  I'll work on it to see if there is some
> > way to deal
> > with it that is cryptographically "strong enough" for the purpose.
>
> I'm told by people who know more about crypto than myself that the
> most likely candidate is using DSA with ECC. Some of the cryptographic
> weakness can be addressed by re-keying more frequently than usual.

Thanks for the helpful lead.  I'll definitely look into it.


> However they do have advantages in the context of SSAs: for example if a
> spammer or a virus gets hold of an SSA and uses it in forged messages, the
> address can be revoked so that it no longer verifies with CBV. With public
> keys in the DNS the key would have to be revoked which will have a wider
> effect than is desired. This could be mitigated by having a key per user,
> say.

Replay attacks are a point of exploit for any envelope signing scheme, and
this includes normal SRS rewriting at forwarders.  Anyone who harvests an
SRS addresses can inflict some pain as well.

>
> Other things to do to protect SSAs against replay attacks include:
>
> (1) Timestamps in the address to limit their lifetime, as for SRS. However
> this has to be a fairly loose limit to allow for delivery delays.

Good call.  My original proposal on this list for SES includes a timestamp
field for exactly this purpose.  It was meant to be used exactly as the SRS
timestamp and would be set to whatever value a local site desires, probably
a week or two, though some sites may wish to allow longer for DSN's to
arrive.

>
> (2) The address should be unsigned on final delivery, e.g. in the case of
> the MAIL FROM address, before it is put into the Return-Path header. This
> protects it from leaking onto the web in mailing list archives, and from
> being found by viruses that grovel through mailboxes. Unfortunately this
> requires changes to third-party software.

SRS requires the exact same changes.  You don't ever want an SRS rewritten
address to be exposed.  Fortunately, this change is in the MTA, not the MUA.
In fact, we could consider leveraging off the SPF implementations so that
one package would ideally do both protocols.

>
> [BTW, I'm calling them "signed sender addresses" because they can be used
> to verify addresses in the 822 header as well as the envelope.]

That's reasonable, but from the perspective of SPF, the only thing of
interest is MAIL FROM:, so any recognition of an alternate protocol in SPF
could only relate to that field.

--

Seth Goodman