Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er

From: "Sauer, Damon" <[email-masked]>
Date: Wed, 18 Aug 2004 12:37:54 -0500

This also can happen today.
 Viruses act just like human viruses. They need a path of contagion.
Block that path or limit it and the virus is quickly contained and dies.
The virus writer would have to tailor the virus to these type systems
and also figure out how to get the virus to propagate outside these
systems in order to have it survive and grow. The virus writer would
also have to have an account internal to these systems. Far be it from
me to try to figure out what a virus writer is going to do next, but
writing specific code to take advantage of this type of infection path
would not be in the virus writers best interest as it does not allow for
the highest, most widespread infection rate.
 Sure, the locks on my house don't keep people from driving semi-trucks
through my front door... Does that mean I should beef up my deadbolts?
 Don't try to over design the system. It is not necessary.

Regards,
Damon Sauer

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chris Haynes
Sent: Wednesday, August 18, 2004 1:14 PM
To: Daryl Odnert
Cc: IETF MARID WG
Subject: Re: Point of Order: Incomplete, flawed response to MARID WG
Chart er

RE: Point of Order: Incomplete, flawed response to MARID WG Charter On
Wednesday, August 18, 2004 5:38 PM at Daryl Odnert asked:

>Chris Haynes wrote:
>> Therefore, Sender-ID _requires_ MTAs of previous good
>> repute to generate and send Bounce messages which:
>> [snip]
>Sorry, but I don't understand this objection.  An MTA is
>only responsible for sending a non-delivery notification
>after it has accepted responsibility for relaying the message. What is 
>the real-world situation in which an MTA would be accepting a message 
>for relaying when that message will be unable to pass a Sender-ID test 
>at the next hop?

I think the following scenario is one which illustrates my concern:

Small business:  (Virus on) End user MUA sends message to internal MTA,
which stores-and-forwards message to public-facing MTA of the business'
ISP.

This ISP-MTA has not implemented Sender-ID, so does no know that the PRA
will later be detected as a forgery. This ISP is generally slack about
security, adding Resent-From headers, etc.

ISP-MTA accepts message for onward delivery, cannot initially contact
destination MTA, stores message and undertakes to try again later.

Second attempt to contact destination MTA succeeds.

Destination MTA applies Sender-ID, rejects message during SMTP protocol
exchange with a '550'.

ISP-MTA notes the '550' and fulfils its 'contract' by generating a
non-delivery "Bounce" message, which is sent to the address in
"Mail-From" in the original
(virus-generated?) message.

Chris

*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you received this in error, please contact the sender and delete the material from all computers. 113

---

From: Dean Anderson <[email-masked]>
Date: Wed, 18 Aug 2004 16:24:20 -0400 (EDT)

The flaw in this line of thought is that computer viruses are engineered 
by people who are far more intelligent than biological viruses. Once an 
obstacle appears, the human can alter the virus, most of which upgrade 
themselves automatically already.

In the case of SPF, all the virus operator has to do to continue forging
email is to have the virus upgrade itself to use the infected domain's
relays using the user's stored email configuration or just by guessing, or
better, by using the SPF records.  After that, they forge away.

		--Dean

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 18 Aug 2004 17:28:21 -0400

> better, by using the SPF records.  After that, they forge away.

  One huge benefit to viruses by forging is that millions of user
machines, with fast network connections, who aren't normally MTA's,
can suddenly all attack other peoples MTA's.  Like may people, I've
had MTA's severely hit by a new virus load, due to precisely the above
problem.

  If the viruses have to use the infected domains MTA to propogate, I
think that's a great thing.  Their MTA will probably die, won't
distribute as many viruses, and therefore my MTA won't die.

  Viruses can, of course, get around this by using "open" SPF records,
or records from an "evil" domain associated with the virus.  But both
of those situations involve a single point of attack: the DNS for the
domain.  Shut that down, and there's no longer any SPF records, and
we're back to where we are today with viruses & forgery.

  So in one situation, we'll be better off.  In another, we'll be
worse off, due to the cost of deploying a protocol that doesn't help
for that situation.

  It's up to individual MTA administrators to do the cost/benefit
analysis for the two situations, to see if it's worth it for them to
deploy a particular solution.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Aug 2004 16:39:48 -0700

> had MTA's severely hit by a new virus load, due to precisely the above

When transparent interception is not used by network providers, Trojans
are free to submit mail from compromised machines without detection. 
Sender-ID may create market disincentives for trapping Trojans in this
manner, although this is an effective ploy where network providers can
handle the outbound problem themselves.

>   If the viruses have to use the infected domains MTA to propagate, I

Sender-ID attempts to change the paradigm of being able to use a mailbox
address as an identifier from any point of access.  This leaves two
options for ISPs.  Create an "open" list, or add a Resent-From header to
the message as a means to accommodate customer expectations.  If a few
hundred thousand domains wish to retain this paradigm, then the number
of "open" lists will ensure a Trojan can use a different mailbox for
each spoofed message that "should" be accepted.

If these "open" lists become blacklisted or refused as a result of this
type of exploit, then "open" lists should have never been allowed in the
standard, as it then invites mail failure.  On the other hand, if each
message was sent using a hostile domain, both SPF and Sender-ID allow
these lists to encompass a significant portion of the Internet address
space, which enables "throw away" domains to easily stage a broad base
attack.  

> we're back to where we are today with viruses & forgery.

Just as these Trojans exploit thousands of mailbox addresses, these
mailboxes can be culled from a list with "open" records.  There would be
no single DNS to enable a shut-down.  In addition, these mailbox records
and DNS servers likely represent legitimate users.  These users would
react to retaliation tactics, as they have done nothing wrong, and
overload customer support.  This assumes mail providers are coerced into
publishing these records initially, without changing the habits of their
users.

> worse off, due to the cost of deploying a protocol that doesn't help

If ISPs check their SMTP error logs, those sending spam can be quickly
spotted.  For this reason, transparent interception becomes a good
choice incompatible with Sender-ID or SPF, however.  ISPs should be able
to track their clients to better enable quick removal, such as
blacklisting at their intercept.  Unlike Sender-ID, the channel is self
documenting with CSV, and users become aware of the channel as part of
the identification.  If there is a problem, CSV identifies the entity
responsible and safely blocked as a result.

> deploy a particular solution.

Unlike Sender-ID, CSV does not change mail paradigms, but can be an
effective deterrent as illustrated in the MPR draft.  Unlike Sender-ID
or SPF, the address space allocated by a particular CSV record is
limited to that normally occupied by a single host, making a broad based
attack more difficult.  If there is a case to be made for placing a
restriction on the RFC2822 From, MPR makes this restriction explicit and
can prevent different headers from removing the desired protection.  As
providers are not required to create an "open" list to authenticate the
MTA when using CSV and MPR, there is no record available to enable an
exploit.

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 18 Aug 2004 22:44:14 -0400

> are free to submit mail from compromised machines without detection. 

  Which would appear to be outside of the scope of MARID.

> address as an identifier from any point of access.

  That's only part of the truth.  It changes the paradigm of being
able to use SMTP from any point of access to submit messages to an MTA
you don't have a previous relationship with, UNLESS the domain hosting
your mailbox (as determined by PRA) publishes a policy saying you are
permitted to send mail.  The additional qualifiers are part of the
proposal, and leaving them out distorts any description of the
proposal.

  I still like Hadmut's comment in his RMX draft, and think it's
generally true: If you (i.e. an administrative locale) are not going
to accept mail via SMTP, you shouldn't be sending mail via SMTP.

  We've had SUBMIT for years.  Let's encourage people to use it, and
leave MARID to address the issue of enabling sending MTA's to
accountably communicate with receiving MTA's.

> react to retaliation tactics,

  Like the DNS owners realizing that their bad policies are giving
them a bad name, and updating their policies?

  You're assuming that the only possible method of dealing with bad
policies is for a third party to "retaliate".  I see that assumption
as unnecessarily pessimistic.

> Unlike Sender-ID, CSV does not change mail paradigms

  Sender-Id interacts with only the parties involved in an SMTP
conversation: sender, receiver, and (as a new paradigm) the domain(s)
who's names are (ab)used in the conversation.  In that respect,
CSV-CSA is identical.

> As providers are not required to create an "open" list to
> authenticate the MTA when using CSV and MPR, there is no record
> available to enable an exploit.

  Other methods do not require an "open" list, but they do permit it.
In that way, they are more flexible than CSV and MPR, and therefore as
a side effect, more open to abuse.

  These are common trade-offs in protocol design.  We need
quantifiable reasons to pick one design over the other.  Some
proposals have been deployed for many months, and other have not.
This difference makes it difficult to quantitatively compare methods
as implemented.

  Alan DeKok.

---

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

>   Which would appear to be outside of the scope of MARID.

By attempting to map the mail channel to a mailbox domain, the normal
practices of handling mail are affected.  Sender-ID is attempting to use
RFC2822 content as a means of authenticating the MTA.  Had the MTA been
directly authenticated, there would not be a conflict which makes this
issue relevant to MARID.

> accountably communicate with receiving MTA's.

The technique of using RFC2822 content to identify the MTA will lead to
errors and is based upon a premise such content has not been spoofed
between MTAs.  There is no means within this standard to hold a particular
MTA accountable.

> them a bad name, and updating their policies?

These are not errors of policy.  These are errors built into the standard.

> as unnecessarily pessimistic.

Those being black-listed are not provided a means to ensure the integrity
of the mail channel down stream.  It could easily be within the recipients
realm that spoofed identities are injected.  The indirect method of
identifying the MTA may lead to grevious errors where perhaps legal
retaliation becomes the only available option, should an guiltless party
become blacklisted out of the caviler confidence of the mail channel
integrity.

> who's names are (ab)used in the conversation.  In that respect,

CSV-CSA deals directly with the entity sending the mail, and not
indirectly based upon RFC2822 content.  This restriction placed upon the
RFC2822 content by the recipient with respect to the a prescibed mail
channel is a new paradigm.  CSV is still dealing directly with the MTA
without imposing such restrictions and without the possibility of false
implications of responsibilty.

> a side effect, more open to abuse.

I do not agree the Sender-ID's attempt to make a general rule for all
mailbox domains to be bound to a mail channel is more flexible.  In fact,
the desire to prevent phishing and spoofing for finacial institutions, as
example, is better addressed by MPR. MPR is far more flexible while not
breaking mail.

> This difference makes it difficult to quantitatively compare methods

This was my reason for creating a list of features.  This effort should
consider the impact of the current mail system and how this transitions. 
If there is to be an accreditation system, it better be defendable.  I do
not see how one could defend Sender-ID assessments.

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 19 Aug 2004 11:07:13 -0400

> between MTAs.  There is no means within this standard to hold a particular

  I agree.  It's only hop-by-hop accountability.

  CSV-CSA isn't any different, in that regard.

> indirectly based upon RFC2822 content.

  For similar reasons, my interest in this area has always been RFC
2821 content, alone.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Aug 2004 10:34:02 -0700

>   I agree.  It's only hop-by-hop accountability.

With Sender-ID, EHLO and MAIL FROM are ignored.  Sender-ID has no
concept of the hop, but rather considers a distribution that _may_ be
part of a merged set of domains, or even of an "open" set.  As example,
with Sender-ID, the message may initially be identified as being outside
the "open" set, but if introduced into the merged set, it will be
promoted to being validated as being inside the "open" set. : (

With Sender-ID, the entity accountable for traffic emerging from a hop
is _not_ identified.  CSV, however, clearly identifies this entity and
thus provides an identity that may safely be held accountable.  These
are important nits from the perspective of enforcement with repudiation,
reputation, or accreditation.  Once considering the likely evolution of
Sender-ID, where ISPs resort to using Resent-From, the PRA is not
substantially different than <From:EHLO*>.  With BATV, <MAILFROM:EHLO>
would be just as good as Submitter. (The reason for indicating BATV use
in MPR.)

>   CSV-CSA isn't any different, in that regard.

CSV is very different from Sender-ID in that regard.  It seems we agree
on major points, so I am confused how you can hold this view.

>   For similar reasons, my interest in this area has always been RFC

I agree 2821 EHLO and MAIL FROM should be the focus, if to curtail spoof
bounces, Trojans, and spam.  I provided the MPR draft to illustrate how
the channel could be related to the From Mailbox Domain using a single
DNS reference, to afford protections for institutions being phished, as
example.  Sender-ID however does not offer an effective protection in
this area, while it breaks much of the current mail, hammers DNS, and
ignores UDP back-off requirements.  I see such Mailbox Domain/Mail
Channel restrictions as the exceptional case.  Perhaps over time, this
exceptional case would be better accommodated by things like BATV. : ) 

*Authenticated. 

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 19 Aug 2004 14:13:19 -0400

Douglas Otis <[email-masked]> wrote:
> concept of the hop,

  It's applied by MTA's, which do have the concept of a hop.

> is _not_ identified.

  The PRA of the traffic is identified, who may not be the same as the
MTA client originating the traffic for the current SMTP session.

>  CSV, however, clearly identifies this entity and thus provides an
> identity that may safely be held accountable.

  It uses different fields to hold a different entity accountable for
different behavior.

> on major points, so I am confused how you can hold this view.

  The paradigm change to hold entities responsible for SMTP traffic is
the same in both proposals.  The fields they use, and the
implementation, differ.

  Previously, recipient MTA's had to determine the responsible
entitity by making reasonable implications, which may or not not have
been correct.  The proposals here in MARID allow entities to
explicitly state who is to be help accountable.

> Sender-ID however does not offer an effective protection in this
> area, while it breaks much of the current mail, hammers DNS, and
> ignores UDP back-off requirements.

  I'm not sure I agree with all that, but I do agree that other
systems within the MARID scope may acheive the MARID goals with less
effort.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Aug 2004 12:39:24 -0700

>   It's applied by MTA's, which do have the concept of a hop.

Perhaps one could describe the PRA algorithm as the MTA considering
prior hops, when the accountable identity is deciphered.  If an
unchanged message is passed from MTA to MTA into a prescribed channel
(merged-open set), the evaluation of this identity may be promoted, as
Sender-ID does not consider messages passing through a chain of MTAs of
differing acceptance levels.  With respect to Sender-ID, there is no
acceptance state at each hop being relayed.  This information is being
ignored.

With Sender-ID, the accountable entity is based solely upon RFC2822
message content, this may change at each hop when a header is added,
this entity may or not be checked against Sender-ID records at various
MTAs, and the accountable levels for the entity may erroneously
increase.  Although there may be _some_ notion of a hop within
Sender-ID, Sender-ID seems to assume communications are end-to-end for
the purpose of reputation, with the exception of added sending headers.

> MTA client originating the traffic for the current SMTP session.

The PRA may have been outside the prescribed mail channel initially, but
this information is lost when transferring through a chain of MTAs.  The
Purported Responsible Address offers no assurance nor tracks any level
of responsibility.  This mnemonic should refer to Purported Recent
Address instead. 

>   It uses different fields to hold a different entity accountable for

CSV attempts to hold the accountable entity accountable for the mail
sent.  There is nothing definite that could be said of Sender-ID. :)

> explicitly state who is to be help accountable.

Agreed.

> systems within the MARID scope may achieve the MARID goals with less
> effort.

I would be happy to review these other points. :)

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 19 Aug 2004 17:06:25 -0400

Douglas Otis <[email-masked]> wrote:
> prior hops, when the accountable identity is deciphered.

  Or, as the intermediate hops disclaiming responsibility for the
message.  I'm not sure it's a good idea for entities in the network to
forward traffic they won't accept responsibility for.

> message content, this may change at each hop when a header is added,

  Then the intermediate hops have claimed responsibility for the
message, and therefore are claiming to originate the message.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Aug 2004 14:35:35 -0700

> message, and therefore are claiming to originate the message.

I agree with this view.  PRA does not represent the accountable entity,
if viewed as the MTA being accountable.  If authenticated, the EHLO
domain properly provides the accountable entity.  Message content should
not excuse those running the MTA.

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 20 Aug 2004 13:35:13 -0400

Douglas Otis <[email-masked]> wrote:
> if viewed as the MTA being accountable.

  I don't think PRA is trying to hold the current sending MTA
accountable.

> If authenticated, the EHLO domain properly provides the accountable
> entity.

  For what?  Validating EHLO ensures that you know someone's
accountable, but what for?  The MAIL FROM may have a different domain
than EHLO, and the message body may have something else entirely.

  There are multiple accountable entities.  Sorting out who they are,
what they do, and how they interact is problematic.  e.g.

  EHLO accountability: The sending MTA is part of an administrative
	system which is well-known, and understands that the MTA
	is sending messages.

  MAIL FROM accountability: Someone accepts responsibility for the
	bounces.

  "From:" accountability: with something like PGP signatures, an
	individual is claiming responsibility for the message content

  The different kinds of accountability are used at different stages
of passing the email message, and do different things.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Aug 2004 12:23:36 -0700

>   I don't think PRA is trying to hold the current sending MTA

I agree. The PRA does not authenticate the MTA as a means to identify
those administering polices to control mail.

> accountable, but what for?

The MTA administrator should be seen as accountable for the stream of
mail, irrespective of message content.  If there is a problem, only this
entity is capable of taking steps to curtail abuse.

>   The MAIL FROM may have a different domain than EHLO, and the message
> body may have something else entirely.
> 
>   EHLO accountability:
>          The sending MTA is part of an administrative
> 	system which is well-known, and understands 
>          that the MTA is sending messages.

The EHLO domain entity is granting access to the mail channel and they
have logs to sort out who did what.  If networks are to be protected
from those wishing to abuse the system, only this entity is capable of
taking effective action to abate this traffic.  The authenticated EHLO
domain should be visible to the user at the MUA.  After all, this is
where trust is being placed.

>   MAIL FROM accountability:
>          Someone accepts responsibility for the	bounces.

I see this as closing the "back-door".  There will always be some MTA at
the end of a relay chain.  Being able to detect return addresses as
bogus, perhaps by way of the BATV proposal, would avoid this type of
spoof bounce abuse, often used by Trojans and spammers.  This would be a
secondary level protection after checking against the EHLO domain for a
history of abuse.  This allows two opportunities to stop this illicit
technique.

>   "From:" accountability:
>          With something like PGP signatures, an	individual is claiming
>          responsibility for the message content.

Absolutely. I agree digital signatures would be a proper means to
protect the author.  Making the authenticated EHLO domain visible
together with the From, would be a significant improvement over the
current situation.  Digital signatures would be the next logical step.

Sender-ID does not provide author protection, as it makes a false
assumption RFC2822 content is secure and allows header overrides.  Nor
does Sender-ID identify the MTA administration. Nor does Sender-ID
protect the return-path. :(

> of passing the email message, and do different things.

Agreed. But the intent of the MARID charter was to find a means to
authenticate the MTA using DNS records.  Only checking the EHLO does
this.

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 23 Aug 2004 10:43:45 -0400

> those administering polices to control mail.

  I don't think that was it's intent.  It identifies a responble
party, who may not be the connecting MTA.

> taking effective action to abate this traffic.

  Then why do we have MAIL FROM?  The user/domain in MAIL FROM is
claiming some kind of accountability for the message.  They should be
held responsible for something, too.

> assumption RFC2822 content is secure 

  Is RFC 2821 content secure?  As we've seen, it's unaccountable, and
untrustworthy.  About the only field in RFC 2821 that you can trust is
RCTP TO, which doesn't mean much.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 23 Aug 2004 10:35:18 -0700

On Mon, 2004-08-23 at 07:43, Alan DeKok wrote:
>   I don't think that was it's intent.  It identifies a responsible

It provides an identity based upon many unverifiable assumptions.  These
unverifiable assumptions ensures there can never be certainty with
respect to accountability.  Only when there is certainty, can this
identity be held accountable.  Also, as it stands, such an identity
could possibly come from any MTA in the world.  What does this mean with
respect to accountability?  Sorry, but Sender-ID is not about
responsibility or accountability.  Sender-ID may not relate to any MTA
or relate to hundreds of other unidentified domains with separate
administrations.  If there is a problem, who can take action to curtail
the problem?

If, despite a lack of certainty, this identity is held accountable and
thereby blocked, what recourse would they have?  Which MTA suffers from
a lack of integrity in the case of a spoofed Sender-ID entity?  This
could be an integrity problem with the recipient.  Sender-ID is always
checked by the recipient, and if there is a lapse of checking within a
chain leading to the recipient, why should the entity identified by
Sender-ID be held accountable?  Would there be a blacklist for
complainers and complaints?  Would it be possible to complain, if the
Sender-ID list were "open"?

> held responsible for something, too.

This is the return path for a delivery error.  By definition, this is 
unrelated to the MTA sending the message.  This MAIL FROM identity, as
it stands, is worthless for determining responsibility.  SPF attempted
to prescribe a mail channel related to the Mailbox Domain.  But that
breaks list servers, mail forwarding, etc.

> RCTP TO, which doesn't mean much.

This overlooks the EHLO domain that can be authenticated and verified to
have been authorized by the domain to act as an outbound MTA.  The RCPT
TO does not indicate any accountable entity.

-Doug