RE: CBV

On Sat, 15 May 2004, Seth Goodman wrote:

> A new idea to foil replay attacks was introduced more recently by Stuart
> Gathman.  Basically, his idea was to associate a MAIL FROM: with a given set
> of RCPT TO: addresses.  This would limit the replay attack to the same
> address that harvested the return path, making the replay attack useless.
> This makes it unnecessary to include a body check and also makes it possible
> to detect the replay attack before DATA, which is what we really want.  It
> is possible to use an extended precision timestamp as the database key and
> it still works with one CBV.  See my next post in this thread for details.
> I think this beats our solution, but maybe not.

I'll call this idea "SESR" - Signed Envelope Sender and Recipients -
to distinguish it from plain SES until someone has a better idea.
Here is my reiteration with a few more details thought about:

To validate a message, a recipient does CBV with either
a MAIL FROM of <> or a MAIL FROM selected from the message envelope recipients.
The CBV will fail for any MAIL FROM other than <> or one of the
original message recipients.  This can be accomplished cryptographically
(by using one of the algorithms where any k out of m keys can
decrypt / validate a message, treating each recipient as a key), or with 
a database.  I am not a crypto expert, but I can hunt up where I've
seen such algorithms.  **

Existing practice is to use <> as the MAIL FROM for CBV (is this
true?), as long as we always include this as a valid recipient, 
we stay compatible.  Recipients who still use <> will still be subject
to the limited replay attacks allowed by SES currently.  However, those
recipients who use the enhanced CBV and send an address selected from a
RCPT TO for the CBV MAIL FROM enjoy greater protection.

PROBLEMS

Do we need a flag to distinguish SESR from SES in the signature?  If we send
something other than <> in the MAIL FROM for a CBV to an MTA that has never
heard of this idea, will the CBV still work as intended?  If not, we need
to know when to use the old <> for CBV.  I am also worried that 
existing CBV implementations might send something like '[email protected]'
as the MAIL FROM - and this would require some special cases equivalent to
<>.

Someone posted to complain that my idea was a tortured abuse
of the original intent of <>.  I admit it - it's true.  However,
everything associated with SPF/SRS/SES tortures the original intent
of SMTP.  We are brought to this pass by the torture and abuse inflicted
by spammers.  The only relevant question for any sugested scheme is
whether it is sufficiently compatible with existing software.

**
If there are n recipients, then the algorithm uses k = 2 and m = n + 1.
The m keys are the hash secret plus the n recipients.  Two keys are
needed to validate.  The hash secret is used for one, so only one
of the recipients will work for the other (other than highly improbable
collisions).

-- 
	      Stuart D. Gathman <[email protected]>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.