spf-discuss
[Top] [All Lists]

Re: Attacking Domain Keys

2004-11-26 08:10:41
On Fri, 2004-11-26 at 09:32 -0500, Theo Schlossnagle wrote:

As for AOL, you should let AOL think about AOL -- that's their job.  The 
same thing it does with 10 billion message devilvery attempt everyday -- 
handle it.  There are likely a variety of inexpensive ways to detect 
faked signatures.  Besides, I don't need to check the DK signature 
before I look at the body, it isn't a prerequisite for anything but DK 
policy at this point.

Correct me if I am wrong, but is it not RFC policy that you must fully
accept the 2822 portion of th email before any rejection can take place.
Also according to Carl Hutzler's last posted statistics, 10B seems far
to high if I recall.

This is one of the beauties of the corporate interests.  If it was a 
problem for AOL, you'd have heard them openly opposing the technology.  
Likewise with all the other big players, they are all in the game and 
plan on preserving business continuity and controlling costs to stay in 
the game.

 ... YET.

If you have a drone army, then you'd likely just send all the data at 
once.  The TCP buffers will still do all the work.  They pay network 
costs, which is insignificant for them and no other expensive I/O costs 
(like disk).  But if you get so far as the data phase, it demonstrates 
that you already trust the connection enough and had every intention on 
reading it anyway -- DK is irrelevant in that argument.

Why on earth would I implement DK then!?

They don't have to wait for the data to finish to check the From.  The 
 From is often at the beginning of the message, as well as Sender and 
DomainKey-Signature, so as soon as the headers roll in you can start 
"thinking."  Of course you need to read in the whole DATA phase to 
perform the canonicalization.  Like I said, if you are already at the 
point of reading the DATA, then you with or without DK you'd be reading the 
DATA.

Like I said, why on earth would I implement DK then?

DomainKeys verifications are pretty cheap -- 4ms or so with no hardware 
acceleration and much faster with acceleration.  Anyone who is large 
enough to have this matter either has a horizontally scalable system 
that would be negligibly impacted by DK (think Yahoo and gmail) or have 
a tight veritcal system that they can buy very inexpensive crypto 
acceleration units for.  Anyone who isn't huge, this simply doesnt 
matter... why?  Because my MTA can verfiy DK faster than my network pipe 
can handle anyway.

So err, whats the point of DK then?

The people for whom the math really matters have certainly done it all 
ready.  It was a calculated decision by Yahoo! and gmail.  Big business 
don't implement without cost analysis.  And as it was their costs, I 
trust their results more than your speculation.

I don't doubt that they have, but it pains me to see these companies
moving forward without considering the alternatives, which are
substantially cheaper.

Back to one of David's point: the math clearly shows that doing DK 
_before_ something like spam assassin make perfect sense as it less 
expensive computationally by several orders of magnitude.

Several orders of magnitude?  Thats quite a bit and doesn't reflect the
data that I've seen in working with SA.  SA also affords me intelligent
classification of email.  Remember even with DK, people can still SPAM!
So no one will be removing SA from their networks anytime soon and not
likely in the future either.  So really, whats the value of DK again?

Cheers,

James

-- 
James Couzens,
Programmer
                                                     ( ( (      
      ((__))         __\|/__        __|-|__        '. ___ .'    
       (00)           (o o)          (0~0)        '  (> <) '    
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features 
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

Attachment: signature.asc
Description: This is a digitally signed message part

<Prev in Thread] Current Thread [Next in Thread>