Re: [ietf-dkim] A proposal for restructuring SSP

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.
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.
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.
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.
--
Sincerely

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



Jim Fenton wrote:
> Eric Allman and I have been discussing a larger change to the SSP 
> specification that we believe addresses a number of the issues that have 
> been raised.
> The biggest change is the separation of the SSP function into a 
> "checker", that retrieves the SSP record/records relevant to a given 
> message, and provides this information to an "adjudicator" that makes 
> the ultimate decision on how the message should be processed at a given 
> site.  The Adjudicator combines the DKIM signature information, SSP 
> Checker results, and any other information it cares to consult (possibly 
> including, but not limited to, reputation, accreditation, content 
> filtering, SPF, and Sender ID).  The definition of the Adjudicator is 
> out of scope of the SSP specification.
> This version addresses concerns expressed in several issues:
>
>   o  Reworded introduction for clarity.
>
>   o  Added definition of Signing Identity and other definition
>      clarifications.
>
>   o  Made examples of "strict" practice use non-normative (partially
>      addresses issue 1538).
>
>   o  Clarified possible confusion over handling of syntax errors.
>
>   o  Removed normative language from Introduction (issue 1538).
>
>   o  Changed "Originator" to "Author" throughout (issue 1529).
>
>   o  Removed all references to Third-Party Signatures (issues 1512,
>      1521).
>
>   o  Removed all mention of "Suspicious" (issues 1528, 1530).
>
>   o  Removed "t=y" (testing) flag (issue 1540).
>
>   o  Broke up the "Sender Signing Practices Check Procedure" into two
>      algorithms:  fetching the SSP record and interpretation thereof
>      (issues 1531, 1535; partially addresses issue 1520).
>
>   o  Document restructuring for better flow and remove redundancies
>      (some may address issue 1523, but I'm not sure I understand that
>      issue completely; also issues 1532, 1537).
>
>   o  Removed all mention of how this interacts with users, even though
>      it makes parts of the document harder to understand (issue 1526).
>
>   o  Introduced the concepts of "SSP Checker" and "Adjudicator".
>
> This draft isn't ready for submission yet, but I wanted to provide an 
> indication of the direction of the editors' thinking, and get a general 
> reaction if this is going in the right direction.  I'm hoping NOT to 
> launch another multi-zillion-message thread with this message, so please 
> keep your comments at a high level for now until (assuming there is 
> general consensus to go in this direction) this is submitted.
> -Jim

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html