Subject: RE: [Asrg] 6. Email Path Verification

From: Paul Judge <[email-masked]>
Date: Mon, 8 Sep 2003 13:04:48 -0400

Jonathan,

Welcome to the group. It seems that you have put a fair amount of thought
into the problem and a possible solution. Yes, more details would be
interesting. The most efficient way to communicate those to the group would
be to create a document that details your approach. It seems that you've
already begin to think about it relative to other proposals. Additionally,
as you create your document, please take into account the considerations
presented in
http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt .

We look forward to seeing your ideas.

Paul

> -----Original Message-----
> From: Jonathan Morton [mailto:[email-masked]] 
> Sent: Monday, September 08, 2003 1:10 PM
> To: [email-masked]
> Subject: [Asrg] 6. Email Path Verification
> 
> 
> Hi, I'm new to ASRG so feel free to point out any obvious flaws (or 
> redundancy) in my post.
> 
> After reading an article on The Register, which quoted Dr. Solomon as 
> suggesting that a "penny post" scheme would be the best anti-junk 
> system around (but conceding that present takeup and attitudes to the 
> idea were not encouraging), I got to thinking about schemes 
> which might 
> work.
> 
> Starting from the "penny post" principle, I figured out a high-level 
> method of attaching a cryptographic signature to an e-mail, via a 
> third-party "payment agent".  The recipient would then have 
> the option 
> of checking the signature both against the e-mail and against the 
> agent.  The agent, moreover, could be looked up in a directory of 
> agents, chosen by the recipient.
> 
> At this point, I realised that the agent not only need not actually 
> charge for it's services, and also need not be attached to 
> the sender's 
> smarthost or ISP.  This makes deployment and acceptance much 
> easier in 
> the early stages, certainly easier than IPv6.  The agent does have to 
> check whether a user is apparently trying to sign a large batch of 
> mails, but this is not technically difficult.
> 
> The actual volume and pricing policy would be set by the agent, which 
> would be under market pressure from both ends - allowing sufficient 
> volume and low prices to please senders, while still keeping the 
> quantity and quality of mail sent through it in line with recipients' 
> (really the directory maintainers') expectations.  I can suggest a 
> number of models which might be considered by different agents.
> 
> At this point I started looking through the RFC and I-D databases to 
> see what other people were doing in this line, and eventually came 
> across the ASRG's work.
> 
> The end result of my idea's evolution (over several days) looks less 
> like the SHRED system presented by AT&T Labs, and more like the last 
> entry in the Email Path Verification paper.  My system, however, adds 
> an extra trust layer in the form of the agent directory, which would 
> operate in a similar manner to the present RBLs, but generally as a 
> whitelist rather than a blacklist.
> 
> The system operates entirely independently of the mail transport 
> system.  Signatures are added as headers in the RFC2822 
> scope, so they 
> survive through SMTP, POP3, IMAP and all similar protocols with no 
> modifications to existing MTAs.  Signing and verification are both 
> optional, and initiated by the MUA at the appropriate end.
> 
> I've also considered scalability problems introduced by large mailing 
> lists, some problems associated with the limited resources on some 
> e-mail clients, the usability and security problems introduced by 
> storing cryptographic keys on inexperienced users' machines, and can 
> suggest a solution to each of these.  I believe the idea is 
> implementable using existing infrastructure and technologies, with 
> minimal impact on most users' experience of e-mail.
> 
> If you'd like me to go into more detail, please ask.
> 
> --------------------------------------------------------------
> from:     Jonathan "Chromatix" Morton
> mail:     [email-masked]
> website:  http://www.chromatix.uklinux.net/
> tagline:  The key to knowledge is not to rely on people to 
> teach you it.
> 
> 
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 

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

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 8 Sep 2003 18:48:16 +0100

> Yes, more details would be interesting. The most efficient way to  
> communicate those to the group would be to create a document that  
> details your approach.

OK.  Since several of the other ASRG documents are in PDF format, I'll  
take that as tacit approval of using LyX and outputting a PDF for this.  
  :)  Something tells me that the official I-D format is a bit too  
high-maintenance at this stage.

> It seems that you've already begin to think about it relative to other  
> proposals. Additionally, as you create your document, please take into  
> account the considerations presented in

Already done, though I'll go over it again and check.  That document is  
actually where I found the first reference to the ASRG and this mailing  
list.

tagline:  The key to knowledge is not to rely on people to teach you it.

---

From: Jonathan Morton <[email-masked]>
Date: Tue, 9 Sep 2003 00:11:47 +0100

> take that as tacit approval of using LyX and outputting a PDF for 
> this.  :)  Something tells me that the official I-D format is a bit 
> too high-maintenance at this stage.

I've uploaded the initial version of the document here:
	http://www.chromatix.org.uk/temp/email-authentication-00.pdf

There's a formatting problem in one place there, but that seems to be a 
LaTeX bug which I'm not really awake enough to chase just now.  The 
meaning should be clear.

---

From: Jose Marcio Martins da Cruz <[email-masked]>
Date: Wed, 10 Sep 2003 16:42:53 +0200

Well, some questions...

If I understood from 3, sender MAA shall store some data from each message in order to 
authenticate the message when the recipient MUA/MAA ask for it. This shall be done for a 
period of probably 5 days plus some epsilon. So you shall imagine that at some moment, ALL 
the messages stored in mailqueues over all internet will correspond some authentication 
data stored somewhere in some MAA.

As we have some kind of variable data to be stored, maybe this may led to some possible 
way to do a DoS attack if someone can fill up sender MAA capacity.

Also, as this will be a very living database, it will be difficult to assure redondance or 
distribute the database or recovery when some sender MAA fails. I think this may led to 
some very complex database problems to solve.

Is it realistic to limit the number of messages each one may send each day ?

-- 
  ---------------------------------------------------------------
  Jose Marcio MARTINS DA CRUZ           Tel. :(33) 01.40.51.93.41
  Ecole des Mines de Paris              http://j-chkmail.ensmp.fr
  60, bd Saint Michel                http://www.ensmp.fr/~martins
  75272 - PARIS CEDEX 06      mailto:[email-masked]

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 10 Sep 2003 16:04:51 +0100

> Well, some questions...
>
> If I understood from 3, sender MAA shall store some data from each 
> message in order to authenticate the message when the recipient 
> MUA/MAA ask for it. This shall be done for a period of probably 5 days 
> plus some epsilon. So you shall imagine that at some moment, ALL the 
> messages stored in mailqueues over all internet will correspond some 
> authentication data stored somewhere in some MAA.
>
> As we have some kind of variable data to be stored, maybe this may led 
> to some possible way to do a DoS attack if someone can fill up sender 
> MAA capacity.

The MAA has to authenticate the sender before it will consent to sign a 
message.  Therefore, it's reasonable to say that it's up to the MAA to 
perform resource checking - it can implement quotas on the sender's 
account and return a Temporary Failure.  I don't think a DoS risk is 
inherent in this part of the design.

The only state the recipient MAA has to store is a cache of public 
signature-verification keys, a resource that can be expired on an LRU 
or LFUDA basis and limited to a given amount of disk space.  Of course, 
such expiry can cause extra network traffic to other MAAs, but even 
that is unlikely to trigger a robustly-implemented MAA into an 
inadvertent DoS.

> Also, as this will be a very living database, it will be difficult to 
> assure redondance or distribute the database or recovery when some 
> sender MAA fails. I think this may led to some very complex database 
> problems to solve.

If an MAA goes down, the recipient's MAA will say "temporary failure", 
probably causing the MUA to try again later.  If an MAA's database gets 
corrupted, the recipient's MAA will say (at worst) "signature invalid". 
  Finally, I don't know all that much about databases, but I don't think 
it's too much of a problem to propagate signatures to a back-end 
database which can be queried by multiple MAA servers.

> Is it realistic to limit the number of messages each one may send each 

Again, this is up to the sender's MAA.  A limit should be quite easy to 
select, in practice, because it can simultaneously be high enough to 
avoid interaction with 99.9% of legitimate users, low enough to curtail 
a spammer's activities, and the remaining 0.1% of legit users can be 
contacted and asked "are you sure?".

Remember, a typical legitimate user might send tens of messages a day, 
whereas a spammer or mass-mailing worm wants to send millions.  Mailing 
lists are a special case, but these aren't terribly hard to account for.

Ultimately, the quality of the MAA's policy will be judged by it's 
users and by the trust directory.  I reckon market forces will be 
sufficient to keep them in line, though a BCP document can be helpful.