Subject: Security issue: Minority installed base of compatible MUAs?

From: "Chris Haynes" <[email-masked]>
Date: Sat, 7 Aug 2004 11:59:02 +0100

I reference draft-ietf-marid-core-02.txt

The abstract states that the specification is 'carefully tailored to ensure that
the overwhelming majority of legitimate emailers, remailers and mailing list
operators are already compliant'.

It says nothing about the compliance of / compatibility with existing MUAs.

Section 6.3 acknowledges that there is no defence against a message sent with a
forged From: header, but with a valid Resent-From: header.

I would imagine that this attack is relatively easy to undertake, e.g. by trojan
or zombie control of hosts which are valid 'marid1' mail originators.

It would, I imagine be a mode of attack which would be very attractive to
'phishers'.

The draft states that "in order to avoid this attack, MUAs will need to start
displaying at least the header that was verified".

My concern is the need for new MUA purchases.

I can't find reliable market share statistics, but I would imagine that Outlook
Express is the leading MUA in the world, being the default MUA supplied with the
vast majority of the world's installed base of consumer PCs.

AFAICT Outlook Express cannot directly 'display the header that was verified'
(i.e. the Resent-From: header content) under these attack conditions.  Therefore
a large proportion of the world's consumer users will have to purchase (or
otherwise obtain) new MUA software to obtain the ability to defend against this
attack.

Is the IETF MARID WG 'comfortable' with the implication that very many of the
world's PC consumers will have to purchase a new product in order to be defended
against this trivial and highly-likely attack?

In 'educating' the world about this important and high-profile defence of the
world's eMail service, is the IETF prepared to give adequate prominence to the
need for hundreds of millions of replacement product purchases?

Or, to put it another way (and one which is rather more to the point of the
present editorial phase), I think that the security analysis of section 6.3
needs to be a lot more candid about the vulnerability of (what is probably) the
majority of the world's installed base of MUAs to this attack, and about how
long it will take for Sender-ID to play a significant role in solving the
identified global problem.

Chris Haynes

---

From: Rand Wacker <[email-masked]>
Date: Mon, 9 Aug 2004 08:43:10 -0700 (PDT)

> My concern is the need for new MUA purchases.

Why can't the server-side check modify the message to display the results
in an MUA-compatible way similar to the way that SpamAssassin modifies
bodies and (optionally) headers today?

-Rand

---

From: "Chris Haynes" <[email-masked]>
Date: Mon, 9 Aug 2004 17:56:15 +0100

> bodies and (optionally) headers today?

Could you please supply an example of the modifications you propose in such a
way that:

1) It is displayable in Outlook Express

2) The display could not have been forged by the sender

Thanks,

Chris

---

From: "Chris Haynes" <[email-masked]>
Date: Mon, 9 Aug 2004 17:56:15 +0100

Thanks,

Chris

---

From: Rand Wacker <[email-masked]>
Date: Mon, 9 Aug 2004 08:43:10 -0700 (PDT)

-Rand

---

From: Jim Fenton <[email-masked]>
Date: Mon, 09 Aug 2004 22:23:51 -0700

>2) The display could not have been forged by the sender

I share Chris's concern.  Unless the PRA is displayed prominently to the user, the From address (when it isn't the PRA) can be anything it wants.

I'm not an OE user, but I'd suggest something like the following:

The MTA verifying the source of the email would rewrite the From line to something like:

From: {original From address} via {PRA address}

It would also copy the original From address into a newly-created header, perhaps Originally-From:

There needs to be a chain of trust between where the source of the email is verified and the recipient.  I believe that is needed whether you do the rewriting I'm describing or not.  If that chain of trust exists, the sender shouldn't be able to forge it.

-Jim

---

From: Mark Shewmaker <[email-masked]>
Date: Tue, 10 Aug 2004 03:52:09 -0400

On Tue, 2004-08-10 at 01:23, Jim Fenton wrote:
> 
> There needs to be a chain of trust between where the source of the email
> is verified and the recipient.  I believe that is needed whether you do
> the rewriting I'm describing or not.  If that chain of trust exists,
> the sender shouldn't be able to forge it.

If we had a sender_agents modifier (or something close), and the
purported previous senders participated in sender_agents, then receiving
MTAs could reject messages with broken chains of trust between the body
header address that the mail purports to originally be made on behalf
of, and the final recipient.

So then the modified MUA displays need only alert people about
"questionable" messages, ie, message that were accepted but for which
either:

o  the purported original senders don't participate in sender_agents,
   *AND*
   there are forwarding PRAs not authorized and white-listed by the
   recipient,

   (I would think this would be rare for legitimate mails--large
   legitimate bulk mailers should have the expertise to properly
   participate in sender_agents.)

OR

o  The purported original senders do participate in sender_agents,
   but the Sender_ID tests don't result in a complete PASS because
   of recipient forwarding hops that result in NEUTRAL or SOFTFAIL
   answers.

   (This problem is under the control of the recipient.)

The end-users wouldn't have to be worry about messages with
provably-forged chain-of-trust forwarding hops, as they'd have been
rejected.

They'd only have to worry about "questionable" mails, and for any
legitimate ones they could go complain to their ISPs who don't do
forwarding properly, or they could complain to the the real sender who
doesn't participate in sender_agents, depending on the circumstance.

That is, in most cases I would think the receipt of legitimate but
"questionable" mails according to the Sender-ID/sender_agents tests
would be a solvable problem given customer feedback.

(For instance, I couldn't imagine citibank and paypal not having spf
records *and* sender_id modifiers in those records, say, 2 years from
now, as their existence could eliminate almost all body-header-address
forgeries using their real domain names in the body From: line. 
Obviously you'd need domain-name block lists to catch things like From:
lines with paypa2.com (or with a numeral 1 instead of numeral 2))

(Of course all the above still doesn't address the bounce problems that
classic SPF and SES&SRS handle so well--just the
authorized-by-onbehalfof-person-to-submit problem that SenderID
purportedly addresses.  So I'd hope people would do spf classic tests on
MAIL FROM at message receipt as well to address the bounce problem, and
SES/BATV on message transmission to address filter forged bounces
bounced back to you.)

-- 
Mark Shewmaker
[email-masked]

---

From: "Chris Haynes" <[email-masked]>
Date: Tue, 10 Aug 2004 11:04:19 +0100

At 20040810 0623 "Jim Fenton" suggested:
> I share Chris's concern.  Unless the PRA is displayed prominently to the user,
the > From address (when it isn't the PRA) can be anything it wants.
> From: {original From address} via {PRA address}

Do you mean like the To: part of this eMail?

AFAIK the only way to get OE to display anything like this is to put  the text
into the displayable version of the address.

This contaminates the address used in the Address Book, used in replies,
forwards etc.

Now how about preventing forgery?

I think you suggest that receiving MTAs should strip off any pre-existing 'via'
text before adding its own.

Look closely at my demonstration. Would your MTA strip this suffix?

Would the user read it as "via PHISHER" (hope you've got crisp glyphs in your
display)?

In which RFC do we make "via" a prohibited word in the free-text part of
addresses?

Exactly which character sequences do we prohibit?

How about encoding "via" in octet encodings intended for the display of
non-US-ASCII?

And what about the cases (listed in my Saturday eMail
Security issue: End-user dependence on MTA integrity" 40040807 11:59) in which
the last MTA in the chain is not undertaking the tests? Forged "via"s could get
straight through without being challenged.

>
> It would also copy the original From address into a newly-created header,
perhaps >Originally-From:

Useful in OE only to those who know and understand the "RightClick-Properties -
Details" dialog sequence.

>
> There needs to be a chain of trust between where the source of the email is
verified
> and the recipient.  I believe that is needed whether you do the rewriting I'm
> describing or not.  If that chain of trust exists, the sender shouldn't be
able to forge it.

I absolutely agree that any time we display information to the user a chain of
trust is needed.

My points are:

1) The drafts on the table today do not provide even the basis for such a chain,

2) I would be very surprised if there are many MUAs in the consumer market today
which have the capability to play their role in that chain - by displaying the
information to be trusted in a way which (a) cannot be forged and (b) does not
contaminate the message itself.

That's why I have suggested to the authors of -core-02 that their "Security
Considerations" section needs to be much more candid about this difficulty in
displaying the PRA in a trustworthy way, and that both the draft and the IETF's
decision-making process needs to understand (what I believe is) the need to
replace a large proportion of the world's MUAs in order to provide the
trust-worthy display of the PRA, which is an _essential_  aspect of Sender-ID.

> -Jim

HTH

Chris