Subject: RE: Forged Sender (Resent-From) attacks

From: Jim Fenton <[email-masked]>
Date: Sun, 22 Aug 2004 22:02:13 -0700

Some of the later followups on this thread seem to diverge from Nate's original point.  Further amplification below.

At 03:30 PM 8/18/2004 -0700, Harry Katz wrote:

>On Wednesday, August 18, 2004 2:34 PM, Nate Leon wrote:
>
>> I realize concern around this topic has been raised multiple 
>> times (Dave Crocker, Doug Otis, Chris Haynes, etc...) but I 
>> still can't help feel we are under-estimating the seriousness 
>> of this issue.  If I missed the posting where everybody 
>> agreed on the solution (entirely possible) please point me to it. :)
>> 
>> I expect it will take years before all MUAs are updated (and widely
>> deployed) to display the PRA, which I do not think is an 
>> acceptable timeframe to put a serious dent into phishing attacks.
>> 
>> For completeness, here is another example of the concern:
>> 
>>    MAIL FROM:<>                                  // don't care
>>    RCPT TO:<[email-masked]>
>>    DATA
>>       Subject: update your account info
>>       Resent-From: [email-masked]   // valid domain
>> authenticated by MARID
>>       ...
>>       From: [email-masked]        // Spoofed domain,
>> displayed by the MUA
>>       To: [email-masked]            // bummer for you
>>       ...
>> 
>> Are we really going to RFC with this issue left open?
>> 
>> If nothing else, I at least want to add my vote to more 
>> thought being put into this topic.
>> 
>
>To address the forged Sender/Resent problem I suggest we could add the
>following logic:
>
>If PRA != 2822.From and SPFCheck(PRA) != "Pass" then receiver MAY reject
>a message after DATA.
>
>In other words, if we validate an identity different from 2822.From,
>then there's a higher bar for a message to be accepted.  The higher bar
>is that check of the SPF record must return PASS, else the receiver MAY
>reject the message.  

But I interpret Nate's "valid domain authenticated by MARID" comment above as meaning that SPFCheck(PRA) == "Pass".  So the message will be accepted, and unless the MUA does display the PRA, the recipient will see just the From: address ([email-masked] in his example).

So it doesn't seem like Sender ID (as it is currently specified) will have done much to improve things until MUAs catch up with it, which I expect to take some time.

I would like to suggest that, if the PRA != 2822.From, 2822.From be rewritten by the receiving MTA doing the MARID check, and the original From address be copied into another header.  In the majority of cases where there is a trusted path between the MTA doing the checking and the recipient, this will at least make it visible to a recipient using today's MUAs that the verification wasn't based on the From address, but something else.

In Nate's example, I would suggest rewriting the From header as something like:

From: "[via <[email-masked]>]" <[email-masked]>

I haven't had a chance to think about whether further attacks are possible with a rewritten From header, but without it I'm concerned that it will be quite a long time before end users benefit from Sender ID, because those intent on circumventing MARID will immediately adapt and use the Resent-From attack (or the Sender: attack, or the Resent-Sender attack).

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 23 Aug 2004 09:40:47 -0700

On Sun, 2004-08-22 at 22:02, Jim Fenton wrote:
> Some of the later followups on this thread seem to diverge from Nate's
> original point.  Further amplification below.
> 
> But I interpret Nate's "valid domain authenticated by MARID" comment
> above as meaning that SPFCheck(PRA) == "Pass".  So the message will be
> accepted, and unless the MUA does display the PRA, the recipient will
> see just the From: address ([email-masked] in his
> example).
> 
> So it doesn't seem like Sender ID (as it is currently specified) will
> have done much to improve things until MUAs catch up with it, which I
> expect to take some time.
> 
> I would like to suggest that, if the PRA != 2822.From, 2822.From be
> rewritten by the receiving MTA doing the MARID check, and the original
> From address be copied into another header.  In the majority of cases
> where there is a trusted path between the MTA doing the checking and
> the recipient, this will at least make it visible to a recipient using
> today's MUAs that the verification wasn't based on the From address,
> but something else.
> 

Using this email as an example-

If there is an authenticated EHLO domain, then doing something like
moving the information out of the Received header to create something
like:

From: Jim Fenton <[email-masked]>

becomes:

From: "[Rcvd: above.proper.com*]"  Jim Fenton <[email-masked]>

The '*' indicates successful completion of EHLO authentication. This
insertion would happen at the MTA at the edge of the administrative zone
receiving mail on behalf of the recipient, or by an MTA that (knows its
administrative zone and) authenticates all MTAs within this zone.  If
there was already an insertion, it would be removed.

As a fall-back strategy, if the EHLO domain did not authenticate, the
most prominent header as determined by RFC2822 could be used instead.
Sender-ID, as currently defined, is too easily spoofed as a primary ID
display offered users.  The name of the header being extracted should be
indicated within this notation.  I suspect there will be games played
with an algorithmic selection of headers, where revealing the header
selection could provide a heads up.  Not just "via" but a short-hand of
the headers.

-Doug