|
Re: [ietf-dkim] A proposal for restructuring SSP
2008-01-27 01:36:31
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|