Subject: Re: [Asrg] How to defeat spam that uses encryption?

From: J C Lawrence <[email-masked]>
Date: Tue, 01 Apr 2003 10:50:42 -0800

On Mon, 31 Mar 2003 21:30:53 -0500 
Eric D Williams <[email-masked]> wrote:

> I too agree that encryption should not be considered a primary
> solution for spam as it constitutes a prohibitive threshold before any
> significant results could be realized.

An aspect I've been musing on is adding forward chained digital
signatures to Received: headers with the receiving system's DNS record
publishing the public key.  Loosely:

    A clear text version and a digital signature of the following data
    are encoded into the Received: header:

      -- the Message-ID

      -- address of the MX generating the header as a string (this
      allows later callback verification)

      -- the timestamp of the time the Received: header is generated

      -- the matching digital signature of the immediately prior
      Received: header (allows back chaining and trust verification of
      the transaction stream).

    Key width could be fairly small.  There are a few changes to RFC
    2822 in there as well (like Message IDs are now mandatory).

It suffers the same threshold problems, but could creep out fairly
quickly given a few more security holes in sendmail.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Tue, 1 Apr 2003 09:12:00 -0800 (PST)

This would be my preferred approach. Very similar to draft proposal I 
was/am going to write.

Regarding sendmail, its problems are not related to email or dns RFCs, its 
just security problems in the programming & design of the program.

---

From: J C Lawrence <[email-masked]>
Date: Tue, 01 Apr 2003 12:37:23 -0800

On Tue, 1 Apr 2003 09:12:00 -0800 (PST) 

> This would be my preferred approach. Very similar to draft proposal I

Cool.  It doesn't solve the problem of course, it just adds path audits
(which is a not-inconsequential value).

The other aspect I've been noodling is using a form of plus addressing
to encode sender-address-specific consent tokens obtained via a
challenge response handshake.    It has horrible human usability
features of course.  Basic idea:

  Bubba writes an email to Boffo.

  Bubba's MUA looks for a locally stored consent token from Boffo and
  fails to find one.  This is done at the MUA level as definitions are
  contextual, subjective, etc.

  Bubba's MUA emails Boffo for a consent token.  This could also happen
  via LDAP or SMTP extension ala VRFY or or or...  I use SMTP as the
  transport as it allows for disconnected operation (eg third world
  behind UUCP, dialup, etc).

    ObNote: Grammar and typing could be encoded into the consent token
    request to allow requesters to describe what type of mail they want
    to send to the stranger, thus allowing some forms of policy to be
    stated -- but that's a feature for Good Guys, not spammers.

  Boffo's MUA auto-replies with a token (which is really a dated source
  address).

  Bubba's MUA receives the token, stores the token for future use
  (policy encoded in the consent reply), and sends Bubba's mail
  appropriately.

  Boffo, on receiving a SPAM can revoke the token, all tokens for that
  sender, etc.

  List servers and legit marketing groups the like can auto-establish
  the token arrangement at subscribe time, and auto-renew as tokens
  expire.

Loosely its a way of encoding killfiles and sender-expense into the
protocol, which is mostly a really stupid idea, but it keeps nagging at
me in that there-is-meat-here way.  Most of the benefit seems to be that
it makes the mail transaction more expensive (this is also its critical
flaw).  For a spammer to email successfully it would have to accumulate
hordes of consent tokens in a time consumptive process (which would also
be readily visible recipient-server side due to the floods of consent
requests).  More particularly they would have to do this fairly quickly
as if not the tokens will expire, and they'll have to do it for every
source address they use...  Equally however it trebles the overhead
required for a transaction to three message exchanges for the default
unrelated case, which is not happy news.

<shrug> Just more wet noodles.

> Regarding sendmail, its problems are not related to email or dns RFCs,
> its just security problems in the programming & design of the program.

<nod, shrug> I tend to be an Exim and Postfix fan.  However, OT.

---

From: Jason Hihn <[email-masked]>
Date: Tue, 01 Apr 2003 16:47:06 -0500

> Basic idea:

Thus verifying the existence of the receiver...

>   Boffo, on receiving a SPAM can revoke the token, all tokens for that

Boffo can sell the address to spammers, who will get a first provisional
token, have it revoked and then change their identity and get a new one.
Boffo can do that too.

>   the token arrangement at subscribe time, and auto-renew as tokens

Looks like you've just reimplemented DHCP but for mail? (Leases essentially)

Continuing to use network analogies... To send a packet, you have to make
your MAC address visible on the network. An acceptable policy. The receiver
does not need to expose himself past his local trusted switch to catch the
packet, but performs no action on the wire receive. If the packet makes it
there or not and is successfully processed by the receiver no one knows,
unless you use a higher level bi-directional protocol like TCP.

I see one possible future is analogous to TCP between consenting parties,
and UDP  between non-consensual ones. Consenting parties tent not to mind to
know each other (usually) and with non-consensual ones the receiver should
not have to be known to exist. Your scheme requires that.

---

From: J C Lawrence <[email-masked]>
Date: Tue, 01 Apr 2003 14:22:58 -0800

On Tue, 01 Apr 2003 16:47:06 -0500 

> Thus verifying the existence of the receiver...

...

> Boffo can sell the address to spammers, who will get a first
> provisional token, have it revoked and then change their identity and
> get a new one.  Boffo can do that too.

Yes-ish, tho I suspect that verification of the validity/existence of an
address is not worth much any more.  The requirement for operating the
domain and MX for the duration of the process may be difficult.

More interestingly (for me) what it doesn't address are slow rolling or
distributed campaigns.  Consider:

  Spammer registers and operates a few thousand domains (which is really
  not that expensive).

  Sub domains of those engage in a slow rolling process of generating a
  consent request and sending individual spams at a rate of a hundred
  per day per machine (messages are individualised to for hash
  stomping).

  As a pack they can deliver many millions of spam a day, but avoid any
  appearance of concentration at recipients by hash distribution across
  the cluster.

> Looks like you've just reimplemented DHCP but for mail? (Leases

Yup, that too.

> I see one possible future is analogous to TCP between consenting
> parties, and UDP between non-consensual ones. Consenting parties tent
> not to mind to know each other (usually) and with non-consensual ones
> the receiver should not have to be known to exist. Your scheme
> requires that.

Ahh, use pseudo-UDP for initial contact and pseudo-TCP for exchanges
among friends, with promotion or degradation across barrier being
controlled by that end of the pipe...  Cute.  That rather requires
building in double-blind anonymous operation at the core...

---

From: Jason Hihn <[email-masked]>
Date: Wed, 02 Apr 2003 09:05:23 -0500

> building in double-blind anonymous operation at the core...

Not double-blind. Half-blind. If you send me something, I want to know who
sent it, and that is a legit request. By sending me something you enter a
"contract" where in you forfeit your right* to anoniminity in order to be
able to send me something.

We could construct a double blind system for the sake of complexity, but I'd
filter all non-identifiable messages to the bit bucket. I think most
everyone else would too, unless they want to get those mysterious anonymous
messages that we see in movies... Follow the white rabbit Neo.

-J