Re: Attacking Domain Keys

James Couzens wrote:

> On Fri, 2004-11-26 at 10:04 +0000, David Woodhouse wrote:
>  
>
> > On Fri, 2004-11-26 at 00:42 -0800, James Couzens wrote:
> >    
> >
> > > You should absolutely NOT be trying to implement
> > > a cryptographic solution to the worlds most widely and diversely
> > > deployed Internet technology which puts the BURDEN _FULLY_ on the
> > > shoulders of the recipient.
> > >
> > > Odd to have everyone looking so intently at it and yet no one other than
> > > John Levine (that I have read) has voiced this concern out loud.  Wonder
> > > how that makes everyone look?
> > >      
> > CPU power is cheap enough that I think most people really don't see it
> > as a problem; I certainly don't.
> >
> > Most highly laden mail servers are presumably more I/O and network-bound
> > than CPU-bound. Has there been a serious study of how the demand for
> > crypto would affect that? 
> >
> > Perhaps I might not be able to run my primary mail server on a dual
> > Pentium-200 machine any more; but then again I already run it IPv6-only
> > to keep its SpamAssassin load down, because SA _does_ chew CPU. It
> > accepts most of its mail from the MX backups which do have addresses on
> > the Legacy Internet, using crypto (SMTP+TLS).
> >
> > It would certainly be interesting to see a study of how CPU load on mail
> > servers would be affected by DK; especially one which recognises the
> > fact that you don't actually have to run other CPU-intensive checks like
> > SpamAssassin and virus checking on mails which were already rejected due
> > to the crypto check.
> >
> > The cost of the crypto is perceived to be negligible. If you feel
> > strongly that it's not negligible, you'd need to show numbers to
> > convince me (and others) of that. Especially so if you're claiming it's
> > not just non-negligible, but prohibitive.
> >    
> With all due respect, please, THINK BIGGER.  How about AOL.  Just how is
> AOL with 90M mailboxes going to deal with my 1,000 node drone army that
> is spewing forth 100,000 fake signed messages laden with random data
> going to do?
>  
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.
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.
> As an "attacker" I can randomly generate and sign a massive volume of
> messages destined to the victim, who falls victim to the burden of not
> only having to perform public key cryptography, he also can't do
> anything until paying I/O costs as well since the DK key is signed in
> 2822 they have to wait for DATA to finish and then they have to parse
> the data to look for the signature that I signed which cost me nothing
> because I just generated gibberish looking valid.
>  
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.
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.

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.
> Do the math on that, it doesn't take much load before you are no longer
> receiving any email.
>  
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.
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.
--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on Earth