Subject: RE: namedroppers, continued

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Dec 2002 11:12:36 -0800

First off, the problem of SPAM is one of the perfect being the enemy of
the good. If we can cut the spam by 95% then that is a pretty useful
achievement.

So, no I don't think that the folk selling feather luggage, herbal
viagra, p0rn etc are likely to go to that length in great numbers,
unless that is the Internet as a whole adopts the same type of measure
following our lead.

However I have thought ahead to the issues of scale here, let us imagine
that a large number of groups use the same scheme, that email agents
that filter based on signatures are available and widely used.

First, consider the effect of a minor authentication requirement on
certificate issue, the ability to read email sent to the address
specified in the certificate. Using that technique we could eliminate
spams with bogus addresses which itself would be a major advance. The
amount of spam that comes through with a valid email address is
vanishingly small.

Second consider that if the whole internet follows our lead and starts
to use cryptography routinely there are a lot of additional steps that
then become possible that are not practical until most people have a
public key and there is a means of discovering that via a DNS linkage.

Third one of the things we could do in an extended enrollment process
would be to get participants to agree to the following set of terms:

	1) Thou shalt not SPAM.
	2) Thou shalt permit your messages to be posted in the archives.
	3) Thou shalt provide timely notice of any intellectual property
claims.
	4) Thou shalt not take the name of the chair in vain unless she
deserves it.
	5) etc.

Then we could sue the b*#*@#&ds if they spammed after that. People have
been looking for a test case for digital signatures for ages, so don't
worry about the cost.

A side benefit of this is that it would cause a lot of people to start
using secure email and thus start to create some critical mass for email
security.

What we need is for someone to take Majordomo or the like and merge in
some sort of filter to check S/MIME and PGP signatures. Then find a
group that wanted to serve as a guinea pig (S/MIME or PKIX perhaps?).

Alternatively we should perhaps form a group 'Deployment of secure
email' which could apply this rubric.

		Phill

> -----Original Message-----
> From: Aaron Swartz [mailto:[email-masked]]
> Sent: Monday, December 02, 2002 1:43 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: namedroppers, continued
>
>
> Hallam-Baker, Phillip wrote:
> > The only way to resolve this issue properly would be to
> require every
> > submission to an IETF mailing list to be cryptographically signed
> > [and] to require the subscribers to register their signing key
>
> And how do we prevent spammers from registering their signing
> key? Are
> you suggesting that we change the IETF's open enrollment policy?
>
> --
> Aaron Swartz [http://www.aaronsw.com]
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Dec 2002 11:12:36 -0800

1) Thou shalt not SPAM.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Dec 2002 11:12:36 -0800

1) Thou shalt not SPAM.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Dec 2002 11:12:36 -0800

1) Thou shalt not SPAM.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Dec 2002 11:12:36 -0800

1) Thou shalt not SPAM.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Dec 2002 11:12:36 -0800

1) Thou shalt not SPAM.

		Phill

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 06 Dec 2002 17:08:36 -0500

In message <[email-masked]>, Fred Bake
r writes:
>At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote:
>>The only way to resolve this issue properly would be to require every
>>submission to an IETF mailing list to be cryptographically signed (PGP
>>or S/MIME), to require the subscribers to register their signing key and
>>to then filter the mail sent out on the list so that only signed mail
>>gets through.
>
>I would be in favor of that, personally, as long as we can ensure that the 
>appropriate signature facility (be it RSA, PGP, or whatever) is freely 
>available to all who need to use it. The issue here is not us corporate 
>types who have a business reason to buy the software, it is the students 
>who often lack the funds. The big issue would be the procedures for posting 
>one's key to the appropriate place - what is to stop a spammer from posting 
>a key and sending the spam anyway? I'm not proposing a mechanism, but 
>someone who is good at such things might well find it of value.
>
Well, it's also the availability of the right signature facility in the 
myriad email clients people use.
>
>I think it was Steve Bellovin that suggested a procedure for reducing the 
>utility of spoofing source addresses in emails; if not, it was me and I 
>happened to suggest something his favorite algorithm fit into, by having a 
>host in each mail domain (mailid.example.com) be able to assert that its 
>domain had or had not sent an email within a given recent  time period 
>whose MD5 hash, when divided by <vector of prime numbers> resulted in 
><vector of remainders>. I could write that up in an internet draft if folks 
>think it makes sense. That would be a more global procedure that didn't 
>require a PKI and only addressed spoofed addresses. 
>
Wasn't me...

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 6 Dec 2002 14:48:13 -0800 (PST)

Hi -

> Message-Id: <[email-masked]>
> Date: Fri, 06 Dec 2002 13:41:52 -0800
> To: "Hallam-Baker, Phillip" <[email-masked]>
> From: Fred Baker <[email-masked]>
> Subject: RE: namedroppers, continued
> Cc: [email-masked], [email-masked], [email-masked]
> In-Reply-To: <[email-masked]
>  .com>
...
> someone who is good at such things might well find it of value.
...

At least for now, the stuff with forged addresses aimed at
the IETF lists I handle can be stopped simply by blocking
multipart/alternative, multipart/mixed, and text/html.
Is this generally true, or am I working with a particularly
old-fashioned subscriber base?

On non-IETF lists I manage, I've had to permit these types, and
resort to finer-grained (read costlier) spam-blocking measures.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  SJC-1.3141
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 7 Dec 2002 12:24:36 -0700 (MST)

> From: Paul Vixie <[email-masked]>

> ...
> i am reminded by this thread that the most powerful force on the internet
> continues to be a single voice saying that something cannot be done.

No, what you are seeing is something that has always been true on the
Internet.  Anything that depends on the actions of third parties who
will not gain by it takes a long time.  To hope for something to take
off, it must be worthwhile from the start.  This proposal costs many
people and organizations now (new software) and forever (MX, .forward,
mailing list, and mobile hassles) and benefits no one for at least
the first year or so.

What's in it for the owners of the domains most commonly (not really)
"forged" into Mail_From values, the free mail providers?  The main
effect for them is that they both be forced to process more out-going
mail and see their user base reduced.  Many users who now use a free
mail provider Mail_From value would either have arrange to send through
the free mail provider or switch to a return address based on IP
bandwidth provider.

What is the difference in the short and medium term between your
proposal and teaching your MTA to check that one of the A records for
the reverse DNS name of the SMTP clients contains the IP address of
the client?  A major difference is that you can install this check
today without waiting for anyone else to do anything.  We all (well,
some of us) can name a raft of reasons why such checking is a bad idea
in general, but you could easily do it only for the domains you think
might eventually provide the new DNS RR and that have a significant
(so called) "forgery" problem, the free mail providers.

For that matter, why not simply blacklist any and all mail with From
values pointing at free providers.  With a white list of your friends
who use free providers, that is an extremely effective spam filter.

Vernon Schryver    [email-masked]

---

From: "Bill Cunningham" <[email-masked]>
Date: Sun, 8 Dec 2002 20:29:33 -0500

----- Original Message -----
From: "Bill Cunningham" <[email-masked]>
To: "Lloyd Wood" <[email-masked]>; "Ayyasamy, Senthilkumar
(UMKC-Student)" <[email-masked]>
Cc: "Fred Baker" <[email-masked]>; "Hallam-Baker, Phillip"
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Sunday, December 08, 2002 8:09 PM
Subject: Re: namedroppers, continued

>
> ----- Original Message -----
> From: "Lloyd Wood" <[email-masked]>
> To: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
> Cc: "Fred Baker" <[email-masked]>; "Hallam-Baker, Phillip"
> <[email-masked]>; <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Sent: Sunday, December 08, 2002 5:29 PM
> > On Fri, 6 Dec 2002, Ayyasamy, Senthilkumar  (UMKC-Student) wrote:
> >
> > > " If I don't know you, and you want your e-mail to appear in my
> > >   inbox, then you must attach to your message an easily verified
> > >  "proof of computational effort", just for me and just for this
> > >  message.
> > >
> > > If the proof of effort requires, say, 10 seconds to compute, then
> > > the economics of sending spam are radically altered, as a single
> > > machine can send only 8,000 messages per day.
> >
> > tracking moore's law could be a problem.
> >
> > > The recent proliferation of spam has lead to a renewed interest in
> > > these ideas.  This work is about both the choice of functions that
> > > can be used to yield easily verifiable proofs of computational
> > > effort, and architectures for implementing the proof of effort
> > > approach.  Filtering and/or forcing senders to pay in other
> > > currencies, such as human attention and money, will be covered as
> > > time permits"
> >
> > "Sender pays" is good. The penny black stamp effectively introduced a
> > flat-rate tax on sending letters, rather than a variable-rate tax on
> > receiving them, effectively turning mail into a common good available
> > to all society.
>
> Lloyd, in the US we pay .37 to mail a first-class letter. I don't know how
> many pence you pay in the UK but we still have "spam" bulk rate unwanted
> solicitations. Forcing the sender to pay doesn't solve a spam problem. I
> don't see how in could. It would force everyone to have to pay a price.
>
>
> > The government also undercut private messaging operators and
> > effectively put them out of business, but could use money earned
> > towards other services for society (having simplified and saved on its
> > operational costs along the way).
> >
> > So, computing as a social good - you want to send an email to someone
> > you're unknown to, you've got to provide proof that you're
> > participating in SETI@home, searching for big primes, in a distributed
> > crypto challenge, working on processing public GIS information,
> > autocomparing versions of typed ascii out-of-copyright texts (or raw
> > CD rips?) for accuracy, processing gene data or archived NASA tapes or
> > otherwise doing good things -- guess this would make each computing
> > charity (give us your spare cycles) the ticket server or PKI manager,
> > although you might want to try distributing that too.
> >
> > > for more details
> > > http://research.microsoft.com/research/sv/PennyBlack
> >
> > I don't see any discussion there of the computation as a social good,
> > or computational functions as utility functions. Microsoft, eh?
> >
> > http://www.glassinesurfer.com/f/gsrowlandhill.shtml
> > -- and here's the obligatory mention of Jeremy Bentham.
> >
> > L.
> >
> > <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> >
> >
>
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 6 Dec 2002 15:45:43 -0800

> myriad email clients people use.

I disagree here, I believe it is a case of supporting the
overwhelming majority of the platforms with software that
is freely available and free.

I don't believe that we should consider support for Open
Genera to be a 'must support' issue. Years ago people used
to whinge when someone sent a MIME attachment of 10K or
so because it took too long to download over a 300 baud
modem.

I don't think it is a bad thing to consider that high
bandwidth connectivity is still a constrained resource
absent in many less developed parts of the world. However
the complaints about using MIME never come from those
quarters.

> I could write that up in an internet
> draft if folks

The problem is not the PKI, the problem is the directory.

Deployment of PKI is easy. It is the Directory baggage that
people foisted onto PKI that is the failure. X.500 has set
us back more than the NSA crypto export regulations ever did.
LDAP merely compounds the problem, building failure on top
of failure.

We need a DNS linked PKI, not a directory linked PKI.

We need a PKI that only cares about the addresses the
applications route on. The idea of using human names for
PKI is bogus.

The directory PKI model fails for the Internet for many
reasons. First taxonomic organization is a broken concept.
No real world information is stuctured in that fashion,
not even genealogies (cousins marry cousins). The reason
that so many enterprise directory projects are fiascos
is that they are trying to fit data into a representation
that is simply inappropriate.

The other main reason that directories are a failure for
Internet PKI is that they are exclusively an internal
data resource. VeriSign has an employee directory accessible
from the inside of the company. There is no way it is
ever going to be accessible from the outside.

At the Internet level trust relationships are complex,
they are certainly not hierarchical. Trying to store that
data in a taxanomic sturcture then do path discovery is
nonsense on stilts.

Linking the PKI to the DNS completes the picture. I want
to send Fred Baker an email, well I had better know his
email address first. My email client can follow an SRV
record from cisco.com to find an XKMS service for cisco.com
where I can ask 'what key should I use to send an
encrypted S/MIME email to [email-masked]'.

Allowing organizations to find out that [email-masked] is still
working for Cisco is actually a security improvement. It
means that Office Max can shut off his personal stationary
account ordering privs the minute he leaves Cisco.

Don't reject the leverage that public key provides just
because you don't like the package people tried to wrap
arround it. The protocol you describe requires state and
is simply not deployable for large systems like hotmail.

It would be nice if the IETF could get ahead of the curve
this time instead of being the brake. We still have members
of the IESG speaking to security forums disputing the
utility of network security measures such as firewalls
even after Steve became a security area director.

We need to shift towards a comprehensive multi-level
security approach which accepts that there are problems
that cannot be addressed by the end to end argument.

Real users are saying that SPAM is their number one
internet related problem today. Classify it how you like
but deal with it with a security mentality. The spamers
are seriously degrading the utility of email. We need
a short term approach to mitigate the problem (filtering)
and long term approaches that have the potential to
put them out of business. Authenticating the good signal
is completely complimentary with rejecting the bad.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 6 Dec 2002 17:14:23 -0800

Don't discount the unexloited features already supported in the deployed
base.

In particular most mail servers support inline SSL connection upgrades,
or can be upgraded to do so with minimal hassle.

Another instance in which a self signed cert is possibly sufficient
authentication - although when you consider the security you get from
upgrading the connection to SSL the price of the cert is kinda de
minimis but I'll play along with the rulling IETF assumption of millions
for hardware, not a cent for software.

		Phill

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 3:59 PM
> To: Marc Schneiders
> Cc: Fred Baker; Hallam-Baker, Phillip; [email-masked]; [email-masked]
> I'v been saying about need for more radical change in mail
> protocol for
> years now on mailing lists. I'd rather work on smtp itself, but some
> people who were involved in original protocol do not want any serious
> changes to what they'v done, though its clear that abuse and
> other holes
> with current system is creating too many problems.
>
> In any case, by next ietf meeting in san francisco, I'll
> bring complete
> proposal for new protocol and might even try some practical
> tests. I do still
> believe that smtp can be saved, but not without more complex
> authentication
> system during delivery of email and that can't be done with current
> protocol design or current available extension process.
>
> Also were there any discussions or more complete discription of this
> algorithm for checking if host had sent an email and if so is this
> available on website or archive to read more about? If answer
> is yes, can
> somebody send me url or approximate date of discussions so I
> could lookup
> in archives.
>
> And am I correct here in understanding what was proposed is that smtp
> conversation id be such that receiving mail server could verify with
> sender (callback?) that it deed indeed initiate the email. If
> so I do not
> quite understand how MD5 helps there, plus I see quite a few
> problems with
> creating some special mx-like record in dns just for verification. If
> this is indeed what was proposed its better to go with paul vixie's
> proposal of mailfrom dns record -
http://www.vix.com/~vixie/mailfrom.txt or
http://www.ietf.org/internet-drafts/draft-church-dns-mail-sender-02.txt

On Fri, 6 Dec 2002, Marc Schneiders wrote:

> On Fri, 6 Dec 2002, at 13:41 [=GMT-0800], Fred Baker wrote:
>
> Spammers would be the first to set up your mailid host. They will have
> had years of experience to find holes in the system before you've
> convinced everyone to adopt or accept the mailid.
>
> It might be easier to write a new protocol to succeed email, instant
> messaging, mobile phones (something useful in itself) with built-in
> abuse control from the start.

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 10 Dec 2002 12:38:58 -0500

For those of you who are in the Boston area, the following
presentation might be of interest, given recent discussions about
methods of compating SPAM.  It is hosted by the MIT Laboratory for
Computer Science's Applied Security Reading Group.

						- Ted

ASRG TALK - in NE43-941 at 400 p.m. this THURS

Open to the Public

Date:    THURSDAY, DEC 12th
Time:    4:00 p.m. - 5:00 p.m.
Place:   NE43-941, 200 Tech Square
Speaker: Cynthia Dwork, Microsoft Research, Silicon Valley Campus
Title:   Fighting Spam May Be Easier Than You Think

Abstract:

In CRYPTO'92 Dwork and Naor proposed the following simple technique
for combating spam:

        If I don't know you, and you want your e-mail to appear in my
        inbox, then you must attach to your message an easily verified
        "proof of computational effort", just for me and just for this
        message.

If the proof of effort requires, say, 10 seconds to compute, then the
economics of sending spam are radically altered, as a single machine
can send only 8,000 messages per day.

The recent proliferation of spam has lead to a renewed interest in
these ideas.  This talk surveys recent work on both the choice of
functions that can be used to yield easily verifiable proofs of
computational effort, and architectures for implementing the proof of
effort approach.  Filtering and/or forcing senders to pay in other
currencies, such as human attention and money, will be covered as time
permits.

Hosted by the Applied Security Reading Group
http://pdos.lcs.mit.edu/asrg/