[ietf-dkim] A proposal for restructuring SSP

[Hector Santos]

Jim,

Well, I had much to say, but I'm still in shock by all this.

I just don't get it. Is this idea even allowed in IETF RFCs?  An IETF 
open standard-track proposal requiring a non-standard business solution 
in order to function?

I mean, its not like we have today with an open standard SSL 
client/server system where we have tons of commercial CA vendors and the 
idea is acceptable because they all work with an open standard.  People 
can go from one vendor to another.

We just don't have this with reputation and I don't wish to get holding 
the bag when we burn in some specific trust system proprietary solution 
and they go out of business, change their business model or subscription 
model, or is found to be problematic and exploitable because it isn't a 
standard and hasn't been through a IETF WG vetting process.

My company been there before and don't wish to be getting again of a 
costly revamping of a product line and having PR issues because our 
customers were having a hard time with some reputation service thus 
making their new DKIM system useless.

At the very least, there should be some default consistency with all 
DKIM/SSP compliant systems.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


Jim Fenton wrote:
> Hector Santos wrote:
>> Jim,
>>
>> If this proposal does not provide the fundamental standard idea of 
>> checking for DKIM signing protocol consistency, then I don't think 
>> this is solving the basis issue here.
>>
>> If we separate this fundamental SSP checking concept into a separate 
>> but "out of scope" adjudicator "plug and play" idea, where one segment 
>> uses this, another uses that, etc, then I think this will create an 
>> exploitable situation of target hot spots.  This idea is one the Cat's 
>> Meow in the Bad Actor World.  As long as they know there will be a 
>> population of similar systems, but some are weaker than others, they 
>> will continue to target everyone with the hope of hitting the weaker 
>> ones.  That means a DOMAIN is vulnerable in varying DKIM systems.  I 
>> don't think we want this to happen.
> 
> There is variability in any case, because some recipients will not 
> deploy DKIM at all, and others will deploy it without SSP.  Others will 
> deploy something SSP-like, even if SSP is very specific about how things 
> should be done.
>>
>> Unless I am missing something,  this new separation and complexity 
>> provide no world wide standardization for general case, widely adopted 
>> expectations by the domain owners.  While is it conceivable the 
>> domains might not care how a receiver reaches a decision, I believe 
>> they will care that the end result is consistently the same across the 
>> board, at least from a standards point of view.
> 
> Domain owners have no reason to expect their mail to be handled in any 
> particular way.  They can state what they do, IMO they can state 
> something about how they'd like their mail handled, but expectations...no.
> 
>>
>> In my technical opinion,  this "Roll your own" filtering is going to 
>> create hot spots of target systems and lower the confidence of DKIM 
>> signers. We would be offering a "cross your fingers" approach with a 
>> lack of confidence of how a receiver is expected to operate.
> 
> It's cross-your-fingers anyway, regardless of what the spec says.
>>
>> IMV, restrictive policies needs to be available for DKIM signers with 
>> a expectation they will be honored across all SSP supportive systems 
>> regardless of what add-on adjudicators are available.  We will not be 
>> able to do this with a 3rd reputation service dependency.
> 
> I agree that we need to avoid a dependency on reputation services, but I 
> do believe that reputation services, when available, are useful.  
> Unfortunately the current draft is perceived as closing the door to the 
> use of reputation and accreditation.  That was not my intent, at least.
> 
> -Jim
> 
> 
>