spf-discuss
[Top] [All Lists]

Re: proposed PGP mechanism for SPF

2004-01-15 03:21:18
On Thu, Jan 15, 2004 at 05:45:35AM +0100, Rob Kaper wrote:

  Message content outside the signed area should be discarded by the
  receiving MTA.

Wouldn't it be sufficient to just sign a Message-ID/From combo, to reduce
overhead? We're only interested in verifying sender identity here, not
entire messages.

Agreed. But Message-ID/From combination would make us vulnerable to replay
attacks.

Just think for a moment what we hope to gain by using PGP over current
SPF mechanisms.

IIRC, the main desired benefit is that we hope to avoid the forwarder problem.

This means that forwarders would not have to perform SRS, and the
envelope sender would still be originalsender(_at_)sender(_dot_)domain(_dot_)

So we need to generate a signature for that data and include it in the
message headers [ignoring for the moment that this alone is replayable].

The sender domain's public key can be found by including the key ID in
the SPF record (e.g. "pgp=cc983928"), and this can then be retrieved from
e.g. pgp.mit.edu. and then cached. Key IDs are supposed to be unique and
should be adequate protection against forgery of the public key. If not,
the entire fingerprint could easily be included, and the ID derived from
that to enable retrieval. Additional web-of-trust calculations could be
performed if desired (e.g. if this key is signed by someone I trust then
the message is 99.999% likely not spam, if signed by someone I don't know
it's 99.9%, if signature doesn't verify it's 0.01%...).

I think retrieving the key this way is preferable to sticking the whole thing
in DNS. Thoughts?


Now, that replay problem. You *could* sign the whole message, but that's
subject to modification in ways that should not cause you to treat
it as a forgery -- e.g. a gateway has virus-scanned the mail and removed a
virus. It also requires heavier computation than we'd like.

Since the message can be modified in arbitrary ways (but for our purposes,
remain a valid message sent by a valid sender in a valid originating domain),
we have to pretty much stick to signing what we are claiming to verify --
basically the sending user and domain (and any other metadata which cannot/
must not be modified by forwarders, such as date).

This is still replayable by a malicious 3rd party posing as a non-SPF-aware
forwarder. In fact, I can't see any way of avoiding this without either
signing the whole message (which brings all sorts of ugliness to the table),
or tracking previously-recieved message data (perhaps a hash of message ID,
date sent, and sender) -- this is also ugly.

I think we really need to define very carefully what it is we want to achieve
with this kind of mechanism...


Cheers,


Nick

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡