Subject: RE: TECH OMISSION: Stronger checks against email forgery

From: "Jim Lyon" <[email-masked]>
Date: Thu, 26 Aug 2004 11:27:15 -0700

John points out that a forger can defeat SenderID checks by inserting a
Resent-From (or similar) header that references either himself a domain
that hasn't published a SenderID record.

He goes on to suggest possible ameliorations, including EHLO checks
and/or classic SPF checks using MAIL-FROM.

He's right that there's a potential problem, but I think he got the
wrong amelioration.

If there's consensus that a change is required, I would recommend:

Whenever the PRA is not equal to the 2822 "From", and the SenderID
result is anything other than "pass", and at least 6 months have elapsed
since SenderID became a Proposed Standard, then the message SHOULD be
treated as forged.

Reasons for this proposal:

1. For most instances of personal mail, PRA == 2822 From == bounce
address, and none of these issues apply.  They only apply in the cases
of specialized agents like forwarders, list servers, third-party mailers
and similar.

2. It's reasonable to hold specialized agents to a higher standard than
the rest of the E/Mail community (by requiring a "pass" instead of
merely the absence of a "fail", for instance.)

3. When the set of documents hits Proposed Standard, many of the
legitimate specialized agents won't yet be in compliance.  But as a
whole, it's a well-managed community that can move fairly quickly.

Reasons against EHLO or bounce address:

1. EHLO tells you a name for the sending MTA.  But it gives you no idea
whether that MTA is authorized to act on behalf of the name mentioned in
the message he's sending.  It seems therefore to be irrelevant.

2. bounce address tells you who wants to know if the message isn't
delivered. It's also irrelevant when deciding whether the MTA is
authorized to act of behalf of the name mentioned in the message he's
sending.

-- Jim Lyon
   mailto:[email-masked]
   tel:+1-425-706-0867

Internet commerce will never really take off until you can buy something
online without getting spammed by the vendor.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of John Glube
Sent: Tuesday, August 24, 2004 10:51 PM
To: 'IETF MARID WG'
Subject: TECH OMISSION: Stronger checks against email forgery

It is very easy to forge domain information in email.

Two simple cases:

* Forging the SMTP mail from address; and

* Inserting a false received line or resent-from header. 

In essence this involves using someone else's domain without
consent.

Also, many who forge domain information also apparently send
direct from an IP address to the recipient's mail server.

Shouldn't we have stronger checks to prevent these types of
activities?

One approach is to run a mail from check at the data stage using
the SPF record format and test protocol.

Another is to run an ehelo or helo check using client smtp
validation.

Keep in mind those engaged in email forgery (which for
sophisticated operators is a form of criminal fraud) will likely
adopt approaches to muddy and defeat authentication, so that
those engaged in fighting email forgery will need to use a range
of tools, recognizing that although one data set might be
corrupted, matching of data against a number of identifiers will
likely generate better results.

(I am basing these general comments on existing research and
studies carried out by others in the criminal forensics field.)

Amending the Sender-ID drafts to reflect using a number of
data sets is one option. 

My personal recommendation is that a best current practices
document be published concurrently with any authentication
technologies recommended by this WG which would in essence
recommend receivers run PRA checks using Sender-ID:
Authenticating Email, mail from checks using the SPF record
format and test protocol and ehelo/helo checks using client
smtp validation.

It may also be appropriate to establish a steering group to
review and propose document updates on a regular basis, although
there may be other ad hoc groups which could include this process
within their mandate.

John Glube
Toronto, Canada

The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004

---

From: Douglas Otis <[email-masked]>
Date: Thu, 26 Aug 2004 15:00:54 -0700

> since SenderID became a Proposed Standard, then the message SHOULD be

The reference could be from any domain that provides an "open-ended"
record.  The referenced record could be from a "throw-away" domain as a
means to still spoof _ANY_ RFC2822 From Mailbox Domain.  As checks
become more stringent, more domains may be tempted to publish "+all"
records to quell picayune refusals.  Reputation services will become
inundated and ineffectual due to lack of Sender-ID identity
authentication.  Will Sender-ID really force the world to publish highly
problematic records as pertaining to reputation services?

> of specialized agents like forwarders, list servers, third-party mailers

Sender-ID will likely invite such assumptions to change.  From providers
dealing with customers expecting to send mail from their networks, the
norm could easily become inclusion of the Resent-From header.  This
"every field is the same" model does not fit for large amounts mail and
will impose exceptional problems for most domains to confront.

> merely the absence of a "fail", for instance.)

This could create a deployment reaction of having Resent-From included
routinely to ameliorate a long list of potential problems.  Once that
becomes the norm, EHLO authentication and authorization would then
provide the same identity.  If one were to follow this logic of all
fields are normally the same, only authenticating and confirming
authorization of the EHLO domain arrives at the same identity with much
less chance of this identity being spoofed!

> whole, it's a well-managed community that can move fairly quickly.

How will they move?  Where are we going and why are we in this
hand-basket? : )  Will they re-train their customers or add a
Resent-From?

> the message he's sending.  It seems therefore to be irrelevant.

Seems irrelevant?  There you go, blaming the message rather than the
messenger.  : )

It is a matter of first establishing accountability.  The assumptions
used to validate a Sender-ID identity will not allow the Sender-ID
identity to be held accountable. 

A simple scheme to impose a Mail Channel prescription upon either the
RFC2821 MAIL FROM or the RFC2822 From is illustrated in this draft:

http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt

Accountability is established first, and this scales well for then
prescribing the Mail Channel.  The use of the prescription is for
authorization, never authentication. 

> authorized to act of behalf of the name mentioned in the message he's

By also allowing a Mail Channel prescription for the MAIL FROM Mailbox
Domain would curtail bounce traffic.  The use of reputation services can
not abate this type of traffic.  Again, I refer you back to the MPR
draft as how this type of restriction can be imposed while not requiring
sequential DNS lookups.

-Doug

---

From: "John Glube" <[email-masked]>
Date: Thu, 26 Aug 2004 20:29:33 -0400

In the interests of process, I am forwarding to the list a
note I sent earlier today to the WG Chairs concerning the
subject. 

The body of the note read as follows:

>Andy,

>I trust this note finds you and yours well.

>This note is further to my two messages concerning the
>subject found at:

>http://www.imc.org/ietf-mxcomp/mail-archive/msg03597.html

>http://www.imc.org/ietf-mxcomp/mail-archive/msg03615.html

>Having reflected on matters, it seems best that we not
>clutter the situation further at this stage with a best
>current practice document, but rather allow the Sender-ID
>drafts to proceed.

>In my view the issue of a best current practice document
>can be raised and dealt with once the Sender-ID drafts are
>approved by the IETF MARID Working Group.

>Once Sender-ID is approved by the WG, subject to proper
>procedure the issue of a Best current practice document can
>be raised and discussed at that time.

The note had the following post script:

>P.S. Although I am formally withdrawing my concerns, I do
>not propose to send a formal message to the list, unless
>you feel this is appropriate. I say this only as others may
>wish to pursue the discussion further at this stage.

Based on guidance received from Marshall to whom the note
was copied, as the reader can see, I have sent the full
message to the list.

Why? The WG works by consensus. The WG Chairs can best
gauge consensus from comments made to the public list. 

Accordingly, if the WG consensus is that a BCP is needed
concerning the issues raised in the noted messages and
these should be dealt with at this juncture instead of
after Sender-ID approval then such is the proper course. 

John Glube
Toronto, Canada

---

---

From: "Michael R. Brumm" <[email-masked]>
Date: Fri, 27 Aug 2004 09:42:07 -0600

>authorized to act of behalf of the name mentioned in the message he's

The (2821 MAIL FROM) bounce address is irrelevant? This seems absurd
considering how many bounces (containing spam and viruses) I get for
messages I never sent. They are a *means* (not just a result) of delivering
messages, and exploited widely. Several viruses and spammers intentionally
use the method of bouncing to get their messages around filters and
blacklists.

And (even worse), the volume and content of bounce-related messages I
currently receive overwhelm my ability to detect when an honest bounce
occurs. Just a couple days ago, I found that a certain ISP has been
incorrectly blacklisting one of my MTA's IP addresses for weeks, but it
wasn't noticed because the DSNs were buried with all the spam/virus DSNs.

It appears that the bounce address attack scenarios against SenderID that I
and others (Shevek and Mark Shewmaker to name a few) brought to the
attention of this list have been ignored. Instead of modifying SenderID to
solve these problems, the problem is now "irrelevant". How convenient.

The MAIL FROM bounce address IS relevant. SenderID doesn't protect the
bounce address adequately, and it amazes me that people are arguing over the
IPR of a technology that is so obviously flawed in this respect.

Preventing forgery involves several levels:

First, protect the transfer agents:
  turn off open relaying, use AUTH, maybe CSV

Second, protect the envelope:
  via technologies like SPF or RMX

Finally, protect the message and header:
  via crypto signing like SMIME or DomainKeys

The first levels are the least expensive to perform but provide the least
protection. The last levels are the most expensive, and work best if the
earlier levels are already implemented.

Because SenderID tries to cheat the last two steps, it uses envelope checks
on the message header and appears to protect neither.

Michael R. Brumm

---

From: Dave Crocker <[email-masked]>
Date: Sun, 29 Aug 2004 11:56:47 -0700

Jim,

JL> 3. When the set of documents hits Proposed Standard, many of the
JL> legitimate specialized agents won't yet be in compliance.  But as a
JL> whole, it's a well-managed community that can move fairly quickly.

Without commenting on the rest of your proposal, I need to comment that
your estimate of adoption time is not matched by any Internet example of
the last 15 years.

When changing an existing service, adoption that reaches reasonable
utility within 3 years is lightening quick, and then it is ANOTHER 2-8
years before it is considered to be an integral part of "all" systems in
the service.

So if you are going to make a proposal that has any serious dependency
on adoption happening quicker than that, it would be very helpful if you
could explain what processes well ensure that rapidity.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 29 Aug 2004 12:09:33 -0700

Jim,

JL> Reasons against EHLO or bounce address:

JL> 1. EHLO tells you a name for the sending MTA.  But it gives you no idea
JL> whether that MTA is authorized to act on behalf of the name mentioned in
JL> the message he's sending.  It seems therefore to be irrelevant.

Apparently you missed my earlier posting :

     Channel-based tells us about the aggregate message-sending behavior
     of a specific MTA.  In a world of compromised personal computers,
     this sort of aggregate assessment can be very helpful for
     identifying "pipes" that are more or less dangerous.

     Message-based tells us about a particular author. This is clearly
     useful against phishing. To be useful against spam, the reputation
     of each author must be assessed.

     Note that per-message analysis does not permit the sort of
     aggregate analysis that lets one determine that an entire ISP's
     pool of systems is problematic.

     Note the potential scaling benefits. With HELO-based you do one
     validation per session, rather than one per message. In some
     scenarios, that is a huge savings.

     Even better, note the difference in registering the relatively
     small number of sending MTA domain names, versus the very large
     number of message authors.

A rather serious problem in these discussion is the implied assumption
that any single mechanism must do everything.  We need to get away from
that, so that we can focus on having individual mechanisms that do
individual things that are useful.

There is nothing wrong with the fact that Sender-ID does not vet the
HELO field. And it should not try to. Sender-ID has a different goal.
That's fine.

We need multiple mechanisms, each attacking different parts of the
problem space.

That is what is called a layered defense.

d/