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

From: "Harry Katz" <[email-masked]>
Date: Wed, 18 Aug 2004 15:30:08 -0700

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.  

Another approach that's been discussed is to fall back to doing a check
on the MAIL FROM address when there is no SPF record for the PRA.  

Both alternatives share some things in common:

- Neither approach permits rejecting a message before DATA, unless
SUBMITTER is present. If SUBMITTER is present then both approaches
permit rejection before DATA.

- Both place a higher burden on the "specialty" senders, namely the
forwarders and list servers. This is a good thing.  (Not that it's a
good thing to place a burden, but that the burden is on the specialty
senders rather than all MTAs in general.)

- Neither approach can be done on day 1.  At minimum we need to allow
time for the specialty senders to publish SPF records.

I think the approach I'm suggesting has several advantages:

- It's semantically cleaner. We're basing the check on 2822 identities,
with a higher burden in special cases where PRA is different from
2822.From. This isn't just a theoretical distinction. As we have
repeatedly discussed on this list there are substantial semantic
differences between MAIL FROM and the 2822 identities. 

- More importantly, this allow us to give much clearer directions to
senders in terms of what to publish. You publish the IP addresses of
servers authorized to send mail on behalf of your domain. We're not
trying to mix this up with the IP addresses of servers that receive
bounce messages on behalf of your domain. 

- This approach involves fewer DNS lookups because you're only
performing the spoof check on one identity in all cases. 

Thus, if a spammer wants to forge a Sender or Resent- header, they have
to use their own domain name. That'll get block-listed fairly quickly. I
belive that plugs the hole that we're addressing.

At this late point in the process I'm not sure whether this idea needs
to go into the spec itself.  It could be written up in a BCP.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Aug 2004 17:49:53 -0700

> If PRA != 2822.From and SPFCheck(PRA) != "Pass" then receiver MAY reject

These terms are odd as the Sender-ID check is called Check_Host() and
not SPFCheck(PRA).  From this terminology, it seems there is an
expectation that a different data-set will now exclude the PRA.  The
flawed concept behind using Resent-From was to allow the From to be
ignored, as this From domain will not pass!  You are suggesting that if
the forwarding domain does not publish, reject the message?  Publish or
die.

> is that check of the SPF record must return PASS, else the receiver MAY

This will immediately reject valid mail.  You may note the MPR draft
allowed this treatment to be specifically defined. 

> permit rejection before DATA.

This is not true for the MPR draft. : )

> senders rather than all MTAs in general.)

Again, the MPR draft does not place a higher burden upon these MTAs.  It
does however allow institutions to ensure their mail is not valid when
the From does not indicate coming from their Mail Channel regardless of
whether the Resent-From was published by some entity.  The MPR provides
a suitable treatment for this class of mail, without breaking other
mail.  Remember, forwarded mail is still rejected.

> time for the specialty senders to publish SPF records.

The MPR scheme would not need to impose any changes for institutions to
have restrictions placed upon their From mailbox.

> differences between MAIL FROM and the 2822 identities.

This Resent-From may evolve into being the normal PRA.  In which case,
simply authenticating the EHLO domain and making this visible would
arrive at that point much sooner, and not by imposing sets of "burdens"
for mail to be accepted.  It would also more quickly educate users and
not run afoul of PRA selection errors or IPR contracts. : )
 
> bounce messages on behalf of your domain.

You just suggested a MAIL FROM fall-back mode?
 
> performing the spoof check on one identity in all cases.

You have simply decided more otherwise valid mail should be rejected. 

> belive that plugs the hole that we're addressing.

You seemed to have overlooked the "open" list problem.  The spammer can
use other people's records.  You will be black-listing these people that
have done nothing wrong, other than implemented this specification and
made the mistake of publishing a record.  Publish and die.

> to go into the spec itself.  It could be written up in a BCP. 

Now you think the best practices should be to reject mail, if these
records are not found?  Publish or die. 

Death seems inevitable. : )

-Doug

---

From: Margaret Olson <[email-masked]>
Date: Wed, 18 Aug 2004 22:11:42 -0400

> <...much good stuff snipped ...>

> belive that plugs the hole that we're addressing.

This works. It for all practical purposes closes the hole whereby 
incomplete or absent records for Sender and particularly Resent can be 
used to dive under identity based controls in the temporary (but 
undoubtedly not brief) period before Sender ID records are for all 
practical purposes mandatory.

My gut says that the people burdened - those running mail related 
services - are those most likely to be able to publish definitive and 
complete Sender ID records quickly.

Margaret.

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 18 Aug 2004 23:39:42 -0700 (PDT)

"Margaret Olson" <[email-masked]> wrote:
>> If PRA != 2822.From and SPFCheck(PRA) != "Pass" then receiver MAY
>> reject a message after DATA.
>
>> to use their own domain name. That'll get block-listed fairly quickly.
>> I belive that plugs the hole that we're addressing.
>

This implies once a record gets published, these domains may also become
blacklisted.  If there are MTAs shared by more than a single domain, then
this MTA MUST compare these records against the PRA as a means to protect
these domains.  This also implies every MTA application must have a signed
contract with Microsoft?  It also suggests that when these records are
"open" they may become blacklisted, as spammers are not required to use
"their" records to spoof the system.

By making statements that without a Sender-ID record, mail will be
rejected should also include the statement that without a "closed"
Sender-ID record, mail will be backlisted.  Or to conclude, all ISPs will
soon include a Resent-From header with their "closed" list.  How would
this Resent-From header be better or different than CSV?  500 DNS lookups
or 1 DNS lookup? Many possible PRA headers, or one EHLO domain?  IPR or no
IPR?

My gut says Sender-ID is the wrong approach. Call From:EHLO Mailer-ID.  By
moving to such a name based accreditation, a history can be established. 
If they are new, a go slow approach can minimize the potential damage. 
Sender-ID makes it easy for every message to assume a different identity
and allows records to span large address spaces.  CSV constrains such a
dodge far better.  MPR can put clamps on phishing and spoofing far better
than Sender-ID with a single DNS lookup for the channel.

-Doug

---

From: "Chris Haynes" <[email-masked]>
Date: Thu, 19 Aug 2004 09:44:03 +0100

On Wednesday, August 18, 2004 at 11:30 PM "Harry Katz" wrote:
<snip>
> bounce messages on behalf of your domain.
<snip>

Harry,

There's a VERY important point here.

I presume that when you talk of "IP addresses of servers that receive
bounce messages on behalf of your domain" you are referring to the SPF records.

You and I seem to have a significantly different understanding of how SPF works.

In my understanding, a 'pass' result from a call of SPF's
    check_host(IP, DOMAIN, SENDER)
function, with DOMAIN and SENDER derived from the MailFrom: address has the
following semantics:

"The domain DOMAIN authorises the host IP to *originate* messages whose
Mail-From address is SENDER".

SPF is not designating "servers that receive".
Just like Sender-ID it is designating servers which are authorised to send.

The semantic differences between the two authorities are actually very subtle,
and it is my understanding from discussions on the spf-discuss list that the
majority of sites could have identical records for both tests - which is why it
so galls many knowledgable observers that the IETF seems determined to proceed
with an approach which _forces_ two sets of usually-identical records to be
established and maintained.

This is not the time and place to explore the circumstances under which the
records would be different - it needs extensive, detailed UseCase analysis (and
for SPF to have been submitted to the IETF?).

Significant questions:
=============

Is it possible that, all along,  there has been a fundamental misunderstanding
of SPF amongst the designers of Sender-ID?

If so (and these misunderstandings were corrected), is there an engineering
opportunity to work towards a sympathetic fusion of Sender-ID and SPF *at this
time*?

Yours optimistically,
Chris Haynes

---

From: Graham Murray <[email-masked]>
Date: Thu, 19 Aug 2004 10:36:01 +0100

> opportunity to work towards a sympathetic fusion of Sender-ID and SPF *at this

Do not forget that Sender-ID is supposed to already be a fusion of SPF
and the original MicroSoft Caller-ID.

---

From: "Chris Haynes" <[email-masked]>
Date: Thu, 19 Aug 2004 11:27:13 +0100

> and the original MicroSoft Caller-ID.

Hello Graham,

What do you mean by "supposed"?

"required"?
"alleged"?
"presumed"?

As far as I can tell, Sender-ID has adopted some of SPF's better implementation
ideas, including:

- The record and macro formats
- The opportunity for early rejection (with the SUBMITTER option)

but, functionally, it still tests a different entity (the PRA vs. the Mail-From:
address) and thus has the 'unauthorised bounce' weakness that many people are
concerned about.

There may be other significant differences - I've not done that detailed an
analysis.

Then there is the licensing issue: I don't think any Open Source advocate would
describe the current Sender-ID as a "sympathetic fusion" of the two approaches
to licencing.

Note also Meng's post of
http://www.imc.org/ietf-mxcomp/mail-archive/msg03093.html
which seems to indicate that Meng believed (on 6 Aug)  that there was still a
substantive difference between Sender-ID and his conception of "Unified spf".

Chris Haynes

---

From: Graham Murray <[email-masked]>
Date: Thu, 19 Aug 2004 12:48:44 +0100

> What do you mean by "supposed"?

alleged.

> describe the current Sender-ID as a "sympathetic fusion" of the two approaches

It also does not help that Microsoft have kept delaying telling us
exactly what is covered by their claimed IPR. 

> substantive difference between Sender-ID and his conception of "Unified spf".

I may be wrong about this, but I think that since the original merger
of SPF and Caller-ID to form Sender-ID that (with one notable
exception - the use of XML) Sender-ID has diverged considerably from
SPF (hence the 'supposed' in my original email). In my opinion (which
probably counts for almost nothing) this divergence has not been an
improvement.