Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does no

Douglas Otis wrote:
> On Sun, 2005-08-21 at 13:35 -0400, Scott Kitterman wrote:
>
> > Douglas Otis wrote:
> >
> > This also, I think, brings to light an important reason for the 
> > divergence in our perspectives.  I believe that you are saying that you 
> > think DKIM's usefulness is primarily in supporting reliable name based 
> > reporting so that repetition of abuse can be more effectively prevented.
> > If I got that right, then I understand why you are only interested in 
> > the signature piece of DKIM.
> > Personally, from my perspective as a receiver, I have little interest in 
> > cleaning the mess up after the fact.
>
> Phishing is not addressed by DKIM without unusual processing,
> conventions, and exceptions.  For anti-phishing, an industry list of
> troubled domains meeting a new regime of conventions seems a practical
> solution.  The spoofing of the bounce-address can be handled by using
> BATV, so let's take those issues off the table.
First, return-path spoofing has several potential solutions, none of 
which are germane to message body forgery, so I'm not sure why you bring 
them up here.  For me, SPF is a perfectly reasonable solution to most of 
those problems, but it's trying to solve a different problem than either 
view of DKIM that is being considered, so yes, let's take those issues 
off the table.
Just because DKIM with SSP can't stop all forgery and phishing, doesn't 
mean that it can't deal with a fraction of troublesome practices 
(threats).  I find some fraction worth going after.
> So...
>
> Are you suggesting that by requiring the use of specific providers for a
> particular mailbox-domain will determine before hand whether a message
> will be abusive?  Are you suggesting that mailbox-addresses are such a
> rarefied commodity they _must_ be spoofed for there to be abuse?  Are
> you suggesting flag-day adoptions to establish this new paradigm?
No.

> There are far fewer domains.  Predicting the probability of abuse could
> be reasonably made at the domain, but never as easily at the mailbox-
> address.  The mailbox-address may or may not be limited to specific
> accounts or even to specific providers.  Is such criteria to resolve
> abuse to the mailbox-address aimed at excusing a provider (the signing
> domain) for their lack of good governance?  Is this your desired
> benefit?
No.

> >  Although such post-facto reporting mechanisms are useful in raising
> > the marginal cost of abusive behaviour,they aren't that helpful in
> > stopping abusive mail getting sent.  The abuser just pops up
> > elsewhere.
> Locating or correlating the source of abuse is key.  A signed opaque
> identifier would be far more effective in that aim, than a mailbox-
> address which may or may not be unique across accounts or providers.  An
> opaque identifier would not require a disruptive forcing of new and
> onerous practices in a move to constraining mailbox-domain use.  Such
> constraints, together with the incumbent support issues, will likely
> create substantial barriers to adoption anyway.  
I would imagine that since you are so certain finding sources is so 
critical, you've got some evidence to support that view.  I believe that 
it's almost irrelevant.  If you find one source and squash it, they'll 
pop up somewhere else.  I lot of effort is going into finding a quashing 
sources these days.  It doesn't appear to me that its working.
> > As a receiver, MY primary interest in technologies such as DKIM is as a 
> > method to prevent abusive mail from being delivered in the first place. 
> >
> >  I want to reject it before I ever take responsibility for it.
>  
> You have piqued my curiosity.  What principle are you basing this new
> found means to predict before hand whether a message is abusive?  Why
> can't the use of the signing domain and opaque identifier play the same
> role without changing the way mail is used?
I don't think that it will.

As I've said before, we are wanting to solve two different problems. 
You want another input to improve spam filtering and reporting in order 
to get from IP based solutions to name based solutions.  Fine.  I don't 
think it will help that much, but have at it.
Filtering solutions are fundamentally dangerous to the mail system. 
They are a necessary danger these days, but we should be striving to 
find ways to minimize the risk that messages will disappear into a spam 
folder somewhere.  It's far better to reject up front.  If a legitimate 
sender is rejected, at least they'll know.
What I want is for domain owners to have better control over the use of 
their name and for me to have a mechanized way to know what messages 
fall outside their definition of acceptable use.
It seems pretty simple to me that if a domain publishes an SSP that says 
that they always sign their mail with DKIM and I get a message allegedly 
from their domain that's not signed, I can reject it.  Same if they say 
they do not want mail with third party signatures to be considered 
valid.  It fails their policy, so I reject it.
The beauty of this type of system is that there is no centralized 
clearing house who will control the mail system.  It's a distributed as 
DNS and the only parties involved in the transaction are the receiver, 
then sender, and the sending domain owner.
Now, I don't expect to win you over on this point because you've 
repeatedly declared this impossible.  It seems simple enough to me.
Frankly I find this "industry list of troubled domains" you mention 
above scary.  It appears to me to have the potential to put control over 
e-mail delivery for the internet in a few hands.  That kind of 
centralization is antithetical to the foundation of the internet.  Am I 
understanding you correctly?
I was quite relieved after reading your last message that you are not 
saying that your proposals are designed to benifit the anti-spam 
vendors, but now I find I'm concerned again.
It's sounding again to me like your pushing for some type of big money 
to somebody solution.  Surely this is about trying to make the mail 
system work better?  What am I misunderstanding about what you are saying?
Scott Kitterman
_______________________________________________
ietf-dkim mailing list
http://dkim.org