Subject: RE: 3. Requirements - Anonimity (was Re: FW: [Asrg] 0. General)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 28 Oct 2003 16:12:06 -0800

>   Having a requirement that SMTP creates anonymity in hostile
> situations is a simple way to guarantee that every anti-spam proposal
> will fail to satisfy that requirement, and will therefore be rejected.

I think that the requirement for anonymity is being mis-stated here.

What is really required is untraceability. This is not really true anonymity
since senders want to be able to establish reputations in general. 

Simple architectural proposal:

Sender X sends email to mail forwarder who acts as a gateway, adding the
necessary information to authenticate the gateway as the party vouching for
the message.

The sender can use a proprietary protocol for this, at the extreme using a
steganographic mechanism, including an Adam Back style hash cash proof that
some work has been expended.

		Phill

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 29 Oct 2003 06:26:53 -0800

> 
> I think that the requirements should state that proposal 
> authors should 
> address anonimity and privacy issues, not that they MUST 
> support anonimity.

This sounds like the right approach to me.

We are unlikely to have one size fits all solution, mechanisms
that support true anonymity are likely to be somewhat restrictive
in other ways. 

I think we need to clarify the term however.

Anonymity 
	End user anonymity
	ISP anonymity (why oh why would this be needed)
	
	Untraceable and unlinkable message (c.f. Chaum cash)
	Untraceable message 

In most circumstances anonymity is not the core requirement, untraceability
is. Anyone can post as anonymous coward on slashdot, this is not what most
disidents want.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 29 Oct 2003 12:04:33 -0800

I submit that authentication is irrelevant unless you the use the output of
the process as the input to a filter.

Clearly you can reject mail that the authentication process flags as forged.

But not all email will be authenticated and some of the authenticated email
will be spam.

This does not disqualify authentication from consideration, it just means to
be realistic.

Equally I detect something of a damned if you do or don't attitude. I
personally beleive that there is a lot of potential in mechanisms such as
spf which offer less than cryptograpically secure authentication. I think we
also need to go further but there is no cost to the receiver to support both
and weight according to the actual spam reduction measured. Why argue over
an issue when there will be an empirical measure?

The pushback we get agaisnt spf 9r rmx is that it is spoofable and ownership
of a domain alone is not sufficient. Ok use certs.

The pushback we get against certs is that the above is unrealistic! The
process is too expensive etc. Sure it is a reasonable argment, but not if
you also claim that spf is insufficient.

I suspect that there is truth to both sides, spf will be sufficient short
term and limited domain but hey it is free. So are certificates if people
are right and it turns out we do not need them.

I suggest that if the architectural approach is broad enough there will be a
use for whatever is proposed. There is a general problem with binding dns
names to protocols in the reverse direction. Spam is only one symptom.

Phill

 -----Original Message-----
From: 	Brad Knowles
Sent:	Wed Oct 29 05:11:13 2003
To:	David Maxwell
Cc:	Jonathan A. Zdziarski; Jon Kyme; ASRG
Subject:	Re: 3. Requirements - Anonimity (was Re: FW: [Asrg] 0.
General)

At 3:20 PM -0500 2003/10/27, David Maxwell wrote:

>  In the case of Access controls, if someone has a tight consent
>  definition such as 'I accept mail from these four people', and if mail
>  senders are authenticated, then this recipient will _never_ get
>  something outside of that consent definition.

	Depends on how you define "mail from these four people", and how 
you prove beyond a shadow of a doubt that the message did actually 
come from them.  What about messages forwarded by them from other 
people?  Does the message have to originate uniquely from one of 
these four people, or are they allowed to forward messages that they 
themselves did not write?

>  I don't recall making any criticism of filters besides a) cpu intensive
>  and b) can't ever be perfect.

	I submit that authentication methods can also be CPU intensive, 
and usually also have a small percentage of failures, both false 
negatives and false positives.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++)
R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

---

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 29 Oct 2003 15:05:18 -0500

And thus in a proposal such a philosophy should be explicitly stated and that 
would satisfy the requirement.

-e

On Monday, October 27, 2003 11:07 AM, Jonathan A. Zdziarski 
[SMTP:[email-masked]] wrote:
> > Being damaging to anonymity would not be a fatal objection to a proposal.
> > That a proposal ignores the issue would (IMO) be.
>
> This eliminates all statistical-based filters (Bayesian, Chi-Square,
> etc.), which are among the most successful spam tools that exist today,
> as the sender's true identity is of no importance to the filter.  These
> filters are based on the philosophy that all email will continue to be
> anonymous and therefore pays attention to the one tell-tale
> characteristic of all spams:  their content.  So I would recommend if
> you're going to require that a proposal address the issue of anonymity,
> you give the author the ability to suggest that it is ignored by the
> filter.
>
>
>
>

---

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 29 Oct 2003 16:10:28 -0500

Jonathan, et. al.

In the case presented 'Burden'[1] is the technical consideration at issue.  As 
with any system or systems proposed this specific technical concern (an 
'Ongoing effort' concern) should be evaluated after adoption, however I believe 
what you are positing as an argument is a 'Balance of burdens' issue where the 
sender would be at a greater burden perhaps making the solution untenable.  Am 
I missing something?

-e

[1]  D. Crocker, J. Levine and V. Schryver, "Technical Considerations for Spam 
Control
      Mechanisms", work in progress, Internet-Draft
      draft-crocker-spam-techconsider-02.txt, June 2003.

On Monday, October 27, 2003 3:38 PM, Jonathan A. Zdziarski 
[SMTP:[email-masked]] wrote:
8<...>8
> You also need to take into consideration the 'usability' issue with
> regards to access lists.  If you are using a reply-based list (where you
> have to reply to get added to their access list), there are many
> individuals (including myself) who _will not_ converse with someone
> using this approach for many reasons including both resources and
> philosophy.  If you want to catch 100% of spams, disconnect your mail
> server from the public Internet - but you'll find it's not quite as
> usable.
>
> So there's a balance...I'm not saying access controls are useless...but
> they certainly are no single solution.
8<...>8

---

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 29 Oct 2003 15:03:45 -0500

That is a correct assessment of the issue.

It should be noted in the proposal, and not ignored.  In this way all proposal 
may receive fair treatment with respect to how anonymity and accountability are 
addressed.  Though a proposal may present an obvious mechanism for obliterating 
or ensuring accountability reviewers should be made explicitly aware of these 
issues.

-e

On Monday, October 27, 2003 10:59 AM, Jon Kyme [SMTP:[email-masked]] wrote:
> No such requirement is made. Only that proposals address the issue.
> If you have strong objections to anything in the requirements document - it
> would be best if you made this clear.
>

---

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 29 Oct 2003 16:29:04 -0500

Then I think the present treatment should be satisfactory that:

"Proposals MUST address issues of accountability and anonymity of MTS users, 
specifically message senders."

So not to specifically support anonymity but to '...address issues of...'.  To 
be clear, this means to explicitly state how or whether the approach 'treats' 
these issues.

On Wednesday, October 29, 2003 12:46 AM, Yakov Shafranovich 
[SMTP:[email-masked]] wrote:
> Hallam-Baker, Phillip wrote:
> >>If an ISP allows some anonymous usage with lets say a rate limiter or
> >>free email, how long will it take until spammers start
> >>abusing that and
> >>ISPs will begin to shut down such services?
> >
> >
> > The ISP has to protect their reputation, holding the user accountable is
> > one
> > way to do that. Another would be to implement a rate limiting scheme at the
> > end user's machine.
> >
> > End user anonymity is not an intrinsic problem, it is a problem for certain
> > proposed solutions. I dont believe that requirements should be fitted to
> > solutions.
> >
>
> I think that the requirements should state that proposal authors should
> address anonimity and privacy issues, not that they MUST support anonimity.
>

---

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 29 Oct 2003 16:23:12 -0500

On Tuesday, October 28, 2003 6:10 PM, Hallam-Baker, Phillip 
[SMTP:[email-masked]] wrote:
8<...>8
> proposed solutions. I dont believe that requirements should be fitted to

I agree.  However, it is apropos to stipulate that requirements state how this 
issue is addressed, IMHO.  This is not a constraint on any proposal, other than 
to explicitly state how or whether it is 'handled' by the proposal.  IMO, it is 
perfectly appropriate to state - '...this proposal is designed to preserve the 
practical anonymity of MUA users...' OR, '...this proposal does not apply any 
controls to address perceived accountability or anonymity...'.  I do not think 
that represents any type of constraint.

-e