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

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.

> However, this would shift the burden of validation to the recipient
> rather than the sender and that deserves some comment.
>
> Meng has produced and published slides which correctly, IMHO, argue that the
> some of the cost burden of email needs to be shifted from the recipients to
> the senders.  At the same time, he has argued that CBV's are too costly and
> that major providers would likely not buy into any scheme that relies on
> CBV's.  Since the incremental cost to senders of a system relying on CBV's
> is much higher than the incremental costs to recipients, this seems at odds
> with the idea of cost shifting to senders.

The problem with CBVs is that when widely implemented they can magnify the
bad effects of a joe-job on the servers for the domain that was the
subject of forgery.

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.

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.

(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.

[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.]

-- 
Tony Finch  <[email protected]>  http://dotat.at/