Re: Attacking Domain Keys

James Couzens wrote:

> On Fri, 2004-11-26 at 10:16 -0500, George Schlossnagle wrote:
>
>  
>
> > > So err, whats the point of DK then?
> > >      
> > It's an authentication system - like SPF is.  It doesn't tell you 
> > anything about the quality of the sender, just like SPF doesn't.  And 
> > it isn't designed to be a computational penalty. Look at hashcash, 
> > penny black or something of that ilk if you want to purposefully 
> > incorporate computational cost into SMTP.
> >    
> So DK is expensive, puts full cryptographic burden upon the recipient,
> is vulnerable to YAdDoS, and has no more value than SPF does, and you
> can't do pre-data rejection.  Where do I sign?
>  
You sign in the message headers.  Read the spec.

DK is as expensive as SPF in my eyes.  SPF requires several DNS requests 
and is victim to DoS attacks in that respect as well (just capping the 
time or count doesn't prevent that well).  So, as processors will 
certainly get faster tomorrow, latency will not change.  Half dozen of 
one, six of the other.
SPF and DK are authentication technologies.  One handles RFC2821 and the 
other 2822.  DK adds to that the preservation of message integrity.  
They are different, but will go along with the "they have the same 
value" mentality.  But, as they tackle different problem scopes, the 
benefit of their value aggregates.
I really don't get your argument.  pre-data rejection would be done by 
technologies like SPF.  Dk has value on top of that.
> > You need to go back and do your math again.  Even from a purely 
> > computational standpoint, the standard SA classification ruleset is a 
> > couple hundred times slower that DK verification.  The SpamAssassin 
> > guys themselves will tell you this - it's not a high-performance 
> > solution.
> >    
> No I don't.  I don't run the standard ruleset and its by no means an
> ordinary setup, but it most certainly doesn't qualify from my data as
> "several orders of magnitude".
>  
DK takes about 4ms to validate.  YMMV.  I'm a computer scientist, so 
when I say order of magnitude, I mean <<1.  And yes, SA is dramatically 
more expensive than DK -- if SA slipped in DK tests, no one would even 
notice a slowdown.
> > As noted above, even with SPF people will still spam.  They are 
> > authentication solutions.  Authentication solutions only tell you that 
> > a sender is or isn't who they claim to be.  Out of the box they at best 
> > prevent fraudulent senders.  To do anything more ambitious than that 
> > they both require coupling with an authorization technology that says 
> > 'I know for certain who you are.   Now do I want mail from you?'
> >    
> Yes, this is a whole other point entirely.  If I were to have just
> stepped in here and read your message about DK I would not be
> implementing it any time soon or for that matter ever.  It seems
> absolutely pointless when with a small amount of fixing SPF can be used
> at a phenomenally reduced cost to reject in 2821.
>  
They don't reject the same messages.  DK only needs to be performed on 
messages that don't get rejected in 2821.  This dialog tastes a bit 
funny following on the heals of the whole "you shouldn't be rejection on 
SPF" argument.
> We have enough crap out there already that will deal with mail in 2822
> land.  Once mail is in the data stage, whats the point, you might as
> well run SpamAssassin for all the benefits you get with it, or some
> other classification mechanism such as procmail or maildrop.
>  
Again using "we" too loosely.  You may have enough crap.  I certainly 
have too much crap.  I am looking for things that are concise, simple 
and work.  DK is that.  And, as this message is DK signed and I didn't 
burden you with cryptographic responsiblity, I don't see how you 
argument holds water.  DK is both transparent to the end user and does 
not require participation.  If you choose not to sign messages, fine.  
If you choose not to validate them, fine.  Just like SPF, there is no 
obligation to participate.
--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on Earth