Subject: Is the back door open?

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Jul 2004 16:26:47 -0700

With the latest increase in the number of DNS lookups required to
support construction of the Sender-ID record matrix, and time allotted
being more than 3 minutes per message, the ability to defend from DDoS
attacks may prove intractable.  The number of DNS queries could be
hundreds per message, as an attack intended to disable channel checks.

Sender-ID employs existing SPF records intended to qualify the RFC 2821
MAIL FROM, but then fully ignores the RFC 2821 MAIL FROM.  Sender-ID
introduces "Purported Responsible Address" (PRA) from the RFC 2822
headers, where differing types trump more recent headers.  Dropping the
MAIL FROM strategy of ASRG to adopt this complex and proprietary scheme,
this ensures bounce mail and phishing continues. : (

Establishing accountability of sent mail and validity of the return path
is ignored by Sender-ID.  If an MTA is not checking users as messages
are received, perhaps found when selecting low preference MX records,
machines of backup MTAs, or relay providers, then these MTAs can be used
to send mail to an intended target via the return path.  (There is
little advice how to handling multi-parts or malformed partitions for
PRA determination.  This and header trumping could prove fertile soil
for abuse.)

The back door remains open.

MAIL FROM: <[email-masked]> (never checked per core draft)
RCPT TO: <[email-masked]> (could be local user, but is not)
Resent-From: <[email-masked]> (any open record or not checked)
From: <[email-masked]> (don't care per core draft)
To: <[email-masked]>   
Subject: Secret
...

The bounce becomes:
PRA = [email-masked] (validated)
MAIL FROM: <[email-masked]>  (bounce not compliant)
RCPT TO: <[email-masked]>
Subject: Undelivered Mail
...
Resent-From: <[email-masked]>
From: <[email-masked]>
To: <[email-masked]>
...
From: <[email-masked]>
...

Would this be validated as originating from [email-masked] and sent to
the inbox. If recognized as a bounce, what would the following variant
do?

MAIL FROM: <[email-masked]>  (never checked per core draft)
RCPT TO: <[email-masked]>    (could be local user, but is not)
Resent-From: <[email-masked]>  (any open records or not checked)
From: <[email-masked]> (don't care per the core draft)
To: <[email-masked]>
Subject: Secret
...

The bounce becomes:
PRA = <[email-masked]> (validated)
MAIL FROM: <> (compliant)
RCPT TO: <[email-masked]>

Subject: Undelivered Mail Returned to Sender
...
From: <[email-masked]>
To: <[email-masked]>
Subject: Secret
Resent-From: <[email-masked]>
...
From: <[email-masked]>

Phishing continues:
PRA=<[email-masked]> (a personal number you may recognize)
MAIL FROM: <[email-masked]> (never checked per core draft)
RCPT TO: <[email-masked]> (could be local user, but is not)
Resent-From: <[email-masked]> (validates)
From: <[email-masked]> (don't care per core draft)
To: <[email-masked]>   
Subject: Bogus Claim
...

Headers that trump more recent headers should prove to be a difficult
item to assess and equally difficult to sort.  Would a mail sorting rule
ignore the From if the Resent-From does not match?  As this Sender-ID
mechanism is primarily intended to assist filtering, how mail is sorted
as a result, if done differently between MUAs, could also allow an area
for confusion and fraud.

Could this be done using a DNS cache poisoning technique to even hide
real name of the PRA?  The extensive set of tools available with SPF
makes this possibility greater.

CSV can close the front door for spam and Trojans.  SPF or BATV can
close the back door.  What feature does Sender-ID bring to the table,
other than support for folders?

-Doug

---

From: Andrew Newton <[email-masked]>
Date: Tue, 27 Jul 2004 19:58:15 -0400

> Subject: Undelivered Mail

You lost me right here.  2 qs:
Why is From "don't care per core draft"?
Why is there a bounce?

-andy

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Jul 2004 18:05:51 -0700

> > From: <[email-masked]> (don't care per core draft)

draft-ietf-marid-core-02.txt:

4.  Determining the Purported Responsible Address
...

     2. Locate the first non-empty Resent-From header in the message.
        If a Resent-From header is found, proceed to step 5. Otherwise,
        continue with step 3.

This jump to step 5 omits checks for From headers in the message.  There
is a caution that differing PRA headers should be visible at the MUA,
but offers no action.  I noted that as a don't care.

PRA header trumping order (unrelated to being most recent):
1) If first Resent-Sender go to 5 
2) If first Resent-From go to 5
3) If any and all Sender go to 5
4) If any and all From go to 5
5) If single header done.
6) Else 550 Missing PRA. (Must be a single address, not a list)

> > Subject: Undelivered Mail

The [email-masked] could have been a local user, (it had the right
domain), but when relayed to a MTA with a list of valid users, the mail
was rejected as the local part 'random-1' was not valid.  The MTA second
to last in the chain, then bounces the message.  This may allow
filtering, or if done by a backup MTA, the knowledgeable server is
expected to be out of service.

-Doug

---

From: Andrew Newton <[email-masked]>
Date: Tue, 27 Jul 2004 21:26:28 -0400

On Jul 27, 2004, at 9:05 PM, Douglas Otis wrote:
> This jump to step 5 omits checks for From headers in the message.

Right.  My eyes missed the Resent-From.  Sorry.

> expected to be out of service.

Why would the first MTA receiving for dup.com not just reject the 
message?

-andy

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Jul 2004 18:50:24 -0700

> Why would the first MTA receiving for dup.com not just reject the 

It could if the MTA either had a valid list of users, or attempted to
deliver down stream to ascertain if the user was valid before completing
the session.  The MTA only knows it will relay for a domain.  In the
case of the backup MTA service, this 'knowledgeable' server is expected
to be down.  As a shortcut for administration or out of reluctance,
lists of valid users may not be shared with some MTAs relying messages. 
These become a boon for those looking for a back door.  This also
becomes a valid reason for sticking with the ASRG ground work and
dropping PRA.  Contrary to moving away from the channel, the opposite is
needed.  There are several _really_ good methods for strongly ensuring
the author when needed.  Much better than the PRA stuff.  In addition,
PRA can never protect the network.  Abating abuse should be the goal and
not filtering where there will be a loss of integrity by design.

-Doug

---

From: Andrew Newton <[email-masked]>
Date: Wed, 28 Jul 2004 07:56:18 -0400

> lists of valid users may not be shared with some MTAs relying messages.

Why do you need a list of valid users to do a Sender-ID check?

-andy

---

From: "John Glube" <[email-masked]>
Date: Wed, 28 Jul 2004 08:02:18 -0400

With the recent issues raised by Douglas Otis concerning
the PRA algorithm: 

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

and Terje Petersen concerning Submitter:

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

have the MARID proponents:

* Sought out senior IETF review of Marid core and Submitter
proposals from "security and operations geeks?" 

See the urgent suggestion of Dave Crocker on July 19, "with
one candidate source for reviewers being
http://graybeards.net/sirs/index.html."

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

* Considered putting forward a panel of reviewers for
consideration by the WG Chairs and Technical Advisors as
per a suggestion in the same thread. 

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

* Or otherwise are the WG Chairs aware of any steps being
taken by the MARID proponents to have such a review carried
out and if so, do we have any idea when this review would
be available for the benefit of the WG?

I ask because to the best of my knowledge there has been no
large scale field testing of MARID core or SUBMITTER to
verify the proposals and therefore the WG may benefit from
such a review.

On a separate note, in reading the SPF "help mailing list,"
it is becoming apparent one implementation issue is going
to be mis-configured DNS set ups. This seems to be
happening with "mom and pop" shops all the way up to and
including large corporations with huge networks and IT
departments.

Would it be helpful if there was a statement in the MARID
protocol suggesting that implementers for senders should
endeavour to ensure DNS set ups are in compliance with the
appropriate RFC's, prior to publishing an SPF record to
avoid problems? 

I appreciate this may be a statement of the obvious, but
... many folks are going to want to publish a record either
on their own and this might help with implementation.  

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.725 / Virus Database: 480 - Release Date: 19/07/2004

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Jul 2004 10:43:18 -0700

On Wed, 2004-07-28 at 04:56, Andrew Newton wrote:
> > deliver down stream to ascertain if the user was valid before 
> > completing the session.  The MTA only knows it will relay for a
> > domain.  In the case of the backup MTA service, this 'knowledgeable'
> > server is expected to be down.  As a shortcut for administration or
> > out of reluctance, lists of valid users may not be shared with some
> > MTAs relying messages.
> 

This could done using a domain with no records, open records, or to a
relay MTA that opts to turn off Sender-ID channel checks.  Sender-ID is
not always 100%, due to its extremely large scope.  With the expense of
DNS wrenches, as a defensive posture, such checks could be postponed
until it is at least determined the mail is for a valid user.  Owning to
the overhead involved, it would seem a poor assumption every point in
the MTA path enables these checks.

-Doug

---

From: Mark Lentczner <[email-masked]>
Date: Fri, 30 Jul 2004 14:45:03 -0700

It has taken me a few days to digest and understand the broad range of 
concerns with Sender-ID that Doug has raised.  Most of the specific 
points already have clear responses by others in this thread.  I hope 
to respond to grander concepts implicit in Doug's statements.

Picking an Identity
-------------------
This group has agreed up front that a piece of the spam puzzle hinges 
on being able to check that the sending MTA's IP address is authorized 
by the domain of some identity associated with the e-mail message.  By 
holding that domain responsible, and staking it's reputation on the 
actions of the MTAs it authorizes, the scheme enables systems that 
result in a reduction of spam.

For better or worse, RFC 2821 and RFC 2822 are not concerned with this 
kind of identity.  Due to both the design of the standards, and 
deployed current practices, none of the identities: not the HELO 
domain, not the MAIL FROM, nor any of the headers, presents a clear 
identity of the form we need.

The schemes discussed in this group, CSV, original SPF, and Sender-ID 
each pick an identity from the RFC 2821/RFC 2822 set and imbue it with 
the meaning we need.  We expect that upon adoption of such a scheme, by 
virtue of being checked by receiving MTAs, it will acquire this new 
meaning.

However, by doing so, the new scheme will be at odds with some segment 
of current practice, and cause some entities to change their processes. 
  Picking an identity is a matter of weighing pluses and minuses - there 
is no clear choice.

Picking PRA
-----------
Originally, SPF was based on the 2821 MAIL FROM identity.  Briefly, it 
is a convenient identity to check, and it had the additional advantage 
of directly confronting bounce-back attacks ("joe-jobs").  However, 
downsides were that it requires some significant changes for some MTAs 
(in the form of SRS) and that this identity isn't generally connected 
with anything the recipient sees.

Picking an identity based on the 2822 headers is closer to what 
recipient thinks of as the identity and can require fewer and simpler 
changes for MTAs that need them (in the form of SUBMITTER).

The current form of the PRA algorithm (in core-02) is neither heuristic 
nor proprietary nor arcane: It is a direct embodiment of the 2822 
concept of the mailbox that sent or resent the message.  The priorities 
and orderings of the headers checked is follow directly from the 2822 
definition of the headers.  I'm sure the description in core-02 could 
be more clear in this regard.

One minor related issue: Multi-part messages have no bearing on PRA, 
since the MIME multi-part construct, including the headers of any 
included messages, is all part of the body of the outer message.  Such 
attached headers are never involved.

DNS DDoS and Other Attacks
--------------------------
The number of DNS queries has been grossly overstated in this 
discussion.

As for DDoS attacks based on SPF records designed to cause large number 
of DNS queries, or through excessive querying of legitimate SPF 
records, this is discussed in the protocol draft.  In short, while 
conceivable, the possible DDoS attacks are harder to mount and have 
less impact that other, existing mail based DDoS attacks.

It seems to me that ALL schemes discussed in MARID are subject to DNS 
poising schemes.  Indeed, we talk about it clearly in the protocol 
draft.  This is nothing new.

The notion that SPF computation is so high that that sites will 
postpone the Sender-ID check until the receiver is a known good user 
does not hold up to scrutiny.  Large volume mail receivers routinely 
apply checks that are far more resource expensive than Sender-ID.

The vulnerability of sending via backup MXs is there in EVERY scheme - 
and exists today -- no one can really use backup MXs that aren't under 
their administrative control, and aren't configured to support the 
identical local mail policy.  The era of reciprocal friendly back-up 
MXs is gone.  However, deploying secondary and backup MXs within an 
organization, with common administrative control and policy still works 
in the face of Sender-ID.  And yes, the Sender-ID check needs to be 
done at the border, as do any checks that are checking the 
authorization of the sending MTA.

Yes - Sender-ID no longer directly combats bounce attacks.  But it does 
insofar as the only bounced mail is mail that doesn't fail a Sender-ID 
check (as that mail would be rejected at the 2821 layer.)  Of course, 
the reputation of the domain in a message that passes Sender-ID stakes 
its reputation on the message and hence if the bounces are joe jobs, it 
would suffer.  Does this mean that anyone launching a bounce attack 
will use a domain without a published SPF record?  Yes - but no scheme 
proposed on MARID purports to break the status quo.  And, when I 
discuss my work with anyone, bounce attacks are at the bottom of the 
pile of spam concerns.

Lastly, neither Sender-ID, CSV, nor original SPF will stop phishing 
directly:  Once a phisher catches own, they will have domains set up 
correctly.  Only the addition of reputation can fix this, and then only 
if MUAs present the information in a way that users can understand.  
"big-bank.cc" is going to be forever confused with "big-bank.com".  
Sender-ID however helps the most: Since it is based on the reputation 
of a domain the user will see, and we can only hope the "big-bank.cc"s 
of the world will get a bad reputation quickly.

I hope this helps further our group understanding.

	- Mark

---

From: "Bill McInnis" <[email-masked]>
Date: Fri, 30 Jul 2004 18:34:52 -0400

I sent this to the ASRG list as well so I apologize if you got it twice.

Last weekend a phishing attack took place against US Bank.  The phisher
spoofed and connected with the appropriate IP for US Bank,
170.135.72.63.  How would SPF or Sender ID have managed to catch that
attack?

Thanks,

Bill McInnis
MessageLevel.com

----
This outgoing message is guaranteed to be authentic by MessageLevel users.
Guarantee the authenticity of your email @ http://www.messagelevel.com.

---

From: Michel Bouissou <[email-masked]>
Date: Sat, 31 Jul 2004 11:18:03 +0200

Le samedi 31 Juillet 2004 11:07, Douglas Otis a écrit :
> This will likely create a practice where providers simply insert an RFC
> 2822 Resent-From header, to avoid difficulties, if Sender-ID checks become
> an encumbrance.

I'm sure that it's what will happen. Any mail coming out from big providers or 
forwarders will bear a "Resent-From: <[email-masked]>" and 
then PRA/Sender-ID will then show completely useless.

-- 
Michel Bouissou <[email-masked]> OpenPGP ID 0xDDE8AC6E

---

From: "Douglas Otis" <[email-masked]>
Date: Sat, 31 Jul 2004 02:07:09 -0700 (PDT)

> result in a reduction of spam.

The domain must not be held accountable, if it did not grant user access
for the message sent.  Sender-ID obscures the identity of the domain
granting such access.  Any accreditation scheme would be impractical with
Sender-ID.  The list of these reasons are long and intractable. 
Accreditation with EHLO authenticated and authorized is the best solution
for curtailing spam, where Sender-ID can not.

> kind of identity.

The EHLO identity is related to the domain granting user access, either
directly or indirectly.  Either way, it must be held accountable for abuse
emitted, irrespective of message identities.

If the domain decides to restrict freedom of the RFC 2821 MAIL FROM or RFC
2822 From, that is a practice the domain would be free implement without
using Sender-ID.  If their users are responsible, such restrictions could
be unwarranted.  Not even Sender-ID prevents RFC 2822 From spoofing by
other domains.  Rather than including the PRA, include a visible
authenticated and authorized EHLO domain to bolster these message
identities.

> Due to both the design of the standards, and deployed current practices,
> none of the identities: not the HELO domain, not the MAIL FROM, nor any of
> the headers, presents a clear identity of the form we need.

Currently the EHLO domain can not be authenticated or authorized. CSV
allows the EHLO domain to be used.  This EHLO identity is accountable for
the traffic, unlike any other identity, and allows a history to be
established, and is most closely associated with system logs tracking
abuse.

> Picking an identity is a matter of weighing pluses and minuses - there

Picking the EHLO domain does not change any use or practice, but allows
meaningful accreditation where history can be considered for the first
time.    Making this EHLO domain visible, if authenticated, at the MUA,
when combined with the RFC 2822 From, would make this identity
authoritive.  Call <RFC2822From:RFC821MAILFROM> Sender-ID, and this would
provide a lightweight method that would curtail spoofing, spam, and allow
accreditation.  Add to that, BATV and the world would be a better place.

> Picking PRA

SRS is just one option, if to continue that scheme.  It should be noted
that by attempting to constrain the RFC 2822 From address, the use or
practice of mail changes dramatically.  This is attempting to include a
form of user authentication as part of message acceptance.  This has a
high cost, but makes accreditation impractical.

> be more clear in this regard.

Microsoft has claimed this to be their intellectual property?

> attached headers are never involved.

This is not clearly stated in the draft.

> DNS DDoS and Other Attacks

It is a simple matter of limits imposed by the draft.  Currently these
limits are at 200 seconds and perhaps after hundreds of DNS queries.

> less impact that other, existing mail based DDoS attacks.

The intent of such an attack would be to force removal of the Sender-ID
check.  It is not just any type of DDoS attack, but one with a goal and a
motive.

> draft.  This is nothing new.

Did you mean poisoning?  How would this happen with a CSV-CSA record?

> apply checks that are far more resource expensive than Sender-ID.

For a typical office environment, the average size of spam runs
approximately 4k and normal mail at about 8k bytes.  The amount of DNS
traffic Sender-ID could generate, can exceed the traffic carrying mail. 
Only one Sender-ID check is needed.  If trusted MTAs are performing a
relay, these checks are not required at the first hop.

> The vulnerability of sending via backup MXs is there in EVERY scheme -

SPF and BATV prevents these configurations from being a source of
undesired bounce traffic.  Sender-ID does not prevent this traffic.

> identical local mail policy.

No.

> The era of reciprocal friendly back-up MXs is gone.  However, deploying
> secondary and backup MXs within an organization, with common
> administrative control and policy still works in the face of Sender-ID.

But now there is an added source of bounce traffic, that could have been
prevented.

> And yes, the Sender-ID check needs to be done at the border, as do any
> checks that are checking the authorization of the sending MTA.

If there is trust within the relay chain, the point where a check is made
can happen with other checks that may also result in message rejection,
such as checking the local part of the recipient address.  The bounce
traffic could be less than repeated Sender-ID checks, and may encourage
this check to be performed only at the MDA.

> check (as that mail would be rejected at the 2821 layer.)

No. A bounce would not be coming from a domain that would likely fail a
Sender-ID check.  Such a bounced message could receive a Pass(+) rating. 
The spammer would only need to be accepted at any rating.

> Of course, the reputation of the domain in a message that passes Sender-ID
> stakes its reputation on the message and hence if the bounces are joe
> jobs, it would suffer.

Sender-ID makes accreditation impractical.  To suggest a bounce be
included in such accreditation would be more trouble.  Accreditation must
use higher standards.  The source domain for each bounce could be unique. 
Don't forget about all those "open" records.  Does this mean anyone with
an "open" record should have their mail refused?  If so, remove this
option!

> Does this mean that anyone launching a bounce attack will use a domain
> without a published SPF record?

No.  The domain can be borrowed.  The spammer could simply compile a list
of domains with "open" records.  The reason for leaving the records "open"
could be to allow users the normal freedom of sending from different
domains.

> Yes - but no scheme proposed on MARID purports to break the status quo.

SPF (if closed) and BATV does attempt to stop the bounce traffic.

> And, when I discuss my work with anyone, bounce attacks are at the bottom
> of the pile of spam concerns.

Huh?

> directly:  Once a phisher catches on, they will have domains set up

The next could be big-bank.one.cc etc.  Sender-ID prevents meaningful
accreditation, so informing users of such a problem quickly is made more
difficult.

-Doug

---

From: "Chris Haynes" <[email-masked]>
Date: Sat, 31 Jul 2004 10:46:00 +0100

> 170.135.72.63.  How would SPF or Sender ID have managed to catch that

I believe that sending a single spoofed packet (containing all the data the MUA
needs to send to complete the SMTP dialog) is relatively easy, but conducting an
extended TCP session from a spoofed host address requires the hacking of
in-network routing (which would imply a seriously-escalated threat).

Was the MTA which received the message designed to _ensure_ that a valid TCP
session was in place?

A good test of session validity is to ensure that response packets are getting
back to the source.  When using SMTP I believe a common technique used is for
the receiving MTA to flush the input buffer before sending each SMTP response,
so that the protocol is used to impose 'flow control', which,  _requires_ there
to be a valid, multi-packet  TCP session.

I would be very cautious about suggesting that SPF is ineffective unless I had
established that the MTA involved was not vulnerable to this basic kind of
deception at the transport level.

Chris Haynes

---

From: Meng Weng Wong <[email-masked]>
Date: Sat, 31 Jul 2004 11:04:46 -0400

On Fri, Jul 30, 2004 at 06:34:52PM -0400, Bill McInnis wrote:
| 
| I sent this to the ASRG list as well so I apologize if you got it twice.
| 
| Last weekend a phishing attack took place against US Bank.  The phisher
| spoofed and connected with the appropriate IP for US Bank,
| 170.135.72.63.  How would SPF or Sender ID have managed to catch that
| attack?

could you please post a message with full headers, verbatim and non-obfuscated?

---

From: "Larry Seltzer" <[email-masked]>
Date: Sat, 31 Jul 2004 11:33:46 -0400

This page (http://www.messagelevel.com/spoofing.cfm#spoofex) appears to
have details on this particular phishing example, although nothing so
straightforward as an actual message with headers. 

They have a stupid Flash movie here
(http://www.messagelevel.com/register/movies/ipspoofing.cfm) that
details some of the techniques. 

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
[email-masked]

---

From: Meng Weng Wong <[email-masked]>
Date: Sat, 31 Jul 2004 11:51:46 -0400

On Sat, Jul 31, 2004 at 11:33:46AM -0400, Larry Seltzer wrote:
| This page (http://www.messagelevel.com/spoofing.cfm#spoofex) appears to
| have details on this particular phishing example, although nothing so
| straightforward as an actual message with headers. 

A message with headers would be most informative, plus a
description of what OS and TCP software the receiving server
was running.

http://lcamtuf.coredump.cx/newtcp/

If TCP sequence number spoofing remains a viable attack, we
can construct an ESMTP ECHO field of the following form:

  20040731-11:49:09 mengwong@dumbo:~% telnet dumbo 25
  Trying 208.210.125.24...
  Connected to dumbo.
  Escape character is '^]'.
  220 dumbo.pobox.com ESMTP Postfix
  EHLO dumbo.pobox.com
  250-dumbo.pobox.com
  250-PIPELINING
  250-SIZE 10240000
  250-VRFY
  250-ETRN
  250-ECHO 3yw4thwwhw345h2w35w9-huwtruhnsjbfdpsiodbnwaorghj
  250 8BITMIME
  MAIL FROM:<foo> SUBMITTER=<bar> ECHO=3yw4thwwhw345h2w35w9-huwtruhnsjbfdpsiodbnwaorghj

---

From: "Douglas Otis" <[email-masked]>
Date: Sat, 31 Jul 2004 08:59:10 -0700 (PDT)

> I wrote Sat 7/31/2004 2:07 AM:
>
> Call <RFC2822From:RFC821MAILFROM> Sender-ID, and this would
> accreditation.

I meant to say <RFC2822_From : RFC2821_EHLO> could be called Sender-ID. 
This would identify the sender with the channel, assuming the EHLO domain
was authenticated and was authorized.  This would stop spoofing, phishing
and allow accreditation.  It would not impact the way mail is used, nor
break anything.  Unlike the current definition, this could abate spam.

-Doug

---

From: "Chris Haynes" <[email-masked]>
Date: Sat, 31 Jul 2004 17:28:39 +0100

> deception at the transport level.

Having thought about this for a few hours, I withdraw the implied recommendation
above to use buffer-flushing to counter this form of IP spoofing.  I 've worked
out how, presented with an MTA using this tactic I could still spoof the IP -
were I so inclined.

My current thoughts are that a relatively simple change to SMTP is needed to
provide the desired TCP session integrity - but that breaks the nice aspect of
SPF-Classic that no changes to SMTP are needed.

If, however, the MARID proposals proceed, I understand that the SMTP protocal
will have to be enhanced (to support SUBMITTER), so the change I have in mind
could be added at the same time.

Stop-press: - Meng has just (Sat, 31 Jul 2004 11:51:46 -0400) posted the same
solution as I was about to propose: a pseudo-random ECHO.

Chris Haynes

---

From: wayne <[email-masked]>
Date: Sat, 31 Jul 2004 11:43:47 -0500

> straightforward as an actual message with headers. 

This web page appears to have a large error.  It claims:

    However, email delivery is basically a ONE WAY BROADCAST
    transaction. Meaning that your computer isn't really requesting
    anything of the other computer, it's simply delivering in a
    broadcast sense. This means that you can drop emails into the
    internet stream any where in the world, write the appropriate from
    addresses and origination IP addresses into the "text" headers of
    the email and they'll be delivered. It's that simple. [snip]

It is not that simple.  All TCP connections, SMTP included, use a 
three-way handshake to start up the connection.  This means that email
is *not* a one way broadcast, there *is* a request from your computer
to the sender.

If the operating system on the receiving MTA uses good, random
sequence numbers, IP spoofing will be hard enough to do to make it
impractical.  All major OSes that are reasonable current have
sufficiently random sequence numbers and many OSes have been secure
for much longer.

I agree with others, we need far more details about the actual email
and the receiving OS that was involved.

-wayne

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 31 Jul 2004 10:19:33 -0700 (PDT)

> can construct an ESMTP ECHO field of the following form:

Spoofing TCP is quite difficult as TCP relies on acknoledgements from both 
sides on each transmission. It takes very very very carefull planning to 
do it right and get all the data properly timed.

On the other hand spoofing UDP is easy (its generally one-way communication
with no real establishment of sessions, etc) so if somebody really wanted 
to get by with appearance of existing SPF record they could do it by 
spoofing DNS TXT at the time of connection. 

BTW - I strongly suspect the real USBANK ip address given came from forged
Received header but that the actual connection that delivered that phishing 
email really came from another ip.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Richard Parker <[email-masked]>
Date: Sat, 31 Jul 2004 10:49:02 -0700

> details some of the techniques.

Larry, I've looked at the log file excerpt in the Flash movie.  While it is
presented as evidence that true IP spoofing occurred in the case of this
phishing example, the log file excerpt does not support that hypothesis.
The commentary in the flash movie claims that the excerpt shows an attempt
to deliver spam to the richmond.com mail server, however, I believe they
have misinterpreted the log.  In my opinion the contents of the log show an
entirely valid SMTP transaction taking place in the opposite direction -
namely the richmond.com mail server connecting to a usbank.com mail server
in an attempt to deliver a bounce message, presumably because the spammer
forged the MAIL FROM to include reference a usbank.com address in a mail
handled by the richmond.com mail server.

-Richard

---

From: "Douglas Otis" <[email-masked]>
Date: Sat, 31 Jul 2004 11:42:10 -0700 (PDT)

> On the other hand spoofing UDP is easy (its generally one-way
> communication with no real establishment of sessions, etc) so if somebody
> really wanted to get by with appearance of existing SPF record they could
> do it by spoofing DNS TXT at the time of connection.
>
> Received header but that the actual connection that delivered that
> phishing email really came from another ip.

It could have spoofed as an internal bounce, as it did have a null return
path.  This may be reason to reconcider protections for the return path. 
It is also a reason to doubt SMTP is secure enough to offer assurances
beyond the immediate machine.

With respect to DNS, there is a 16 bit indentifier, but this is weak. 
This can be enhanced to 32 bits, if the source port for a DNS query is
also random, rather than from Port 53 or a sequential selection.

With respect to SMTP innovations to offer improved protections, SCTP
prevents much of the possible attacks, with the use of a state cookie, and
reduced typical connection overhead.  It also protects against DoS
attacks.  There are stacks to readily adapt TCP to SCTP.  This stack was
offered to a well-known desktop OS company, to stimulate acceptance of
this transport.
 ; )

-Doug

---

From: Andrew Newton <[email-masked]>
Date: Sat, 31 Jul 2004 21:22:32 -0400

> then PRA/Sender-ID will then show completely useless.

I'm not sure if this is meant to be an opinionated assumption or a 
statement regarding a flaw in PRA.

If it is a statement regarding a flaw in PRA, please give us the 
use/abuse cases and the details.

On the other hand, if you are merely stating an assumption, I do not 
think it is very helpful.

> break anything.  Unlike the current definition, this could abate spam.

So do you now believe that a Sender-ID record at EHLO host name is more 
desirable than an SRV record?
I'm confused by your suggestion.

-andy

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 01 Aug 2004 04:37:57 +0200

Mark Lentczner wrote:

> Yes - Sender-ID no longer directly combats bounce attacks.
[...]
> when I discuss my work with anyone, bounce attacks are at
> the bottom of the pile of spam concerns.

Then your situation must be very different from my situation:
More than 1,000 useless bounces to forged addresses per day
in my catch-all (vanity) domain are the main reason why I'm
interested in RMX resp. later SPF.

If Sender-Id / Submitter want to be incompatible with v=spf1
then they should use another tag v=marid or similar.

No 3rd party should be able to force a SPF PASS, where I could
get the bounce for a mail not sent by "me" (= any customer of
the same ISP in this case).  Apparently a Sender-Id PASS does
not more guarantee this.

And of course I don't want to get a Sender-Id FAIL instead of
a SPF UNKNOWN only because legacy software doesn't copy the
obvious MAIL FROM address to an equivalent Sender: header.

If some MUAs really want this they could handle the MAIL FROM
address as default Sender: address.

> neither Sender-ID, CSV, nor original SPF will stop phishing
> directly

As soon as I know the domains of my business partners SPF can
catch phishing attempts:

amazon.de TEXT = "v=spf1 include:amazon.com -all" and SPF are
all I need to identify forged amazon mails.

[...]
> only if MUAs present the information in a way that users can
> understand.

At the moment that's easy, anything in the headers is forged.
Only the IP in the last Received header is reliable.  SPF adds
the Return-Path.  In theory Sender-Id could add its "PRA", but
in practice Sender-Id expects that senders (MUAs resp. MSAs)
replace their existing software to copy the MAIL FROM to the
(missing) Sender: header.

But it's the MUA of the _recipient_ who wants to do something
with the "PRA", so why doesn't it handle the Return-Path: as
default Sender: address ?  As long as that's not the case my
v=spf1 sender policy is strictly incompatible with Sender-Id,
because it doesn't cover my usage of 2822 From: addresses.

                         Bye, Frank