----- Original Message -----
From: "Scott Kitterman" <ietf-dkim(_at_)kitterman(_dot_)com>
To: "IETF-DKIM" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Tuesday, August 15, 2006 10:36 AM
Subject: [ietf-dkim] When will there be SSP Requirements-01?
It seems like comments have died down on the -00 draft. Given the number
of
comments/revisions, is an 01 draft planned so we can review that?
Well, its dangerous the dive into this ocean of mixed exotic fishes without
an active lifeguard around :-)
I would like to see one final one just to clean it up, but I personally
would not like to further waste time on word-smiting, semantics,
"terminologies," etc.
We had over one year of discussion and the lines has been drawn. It is
already clear to me what the DKIM/SSP protocol model has to be, satisfying
any POLICY framework you wish to choose.
Personally?
I think the requirements docs needs a VERY good section on what 3rd party
signatures mean, how they play a role, or don't and why they might be needed
without OA permission. This is the critical question a DOMAIN will be
facing - why would I want to allow others to sign without my permission and
if so, can I keep a reasonable high level of confidence in the purpose of
signing in the first place.
The latter seems to be one of the main issues of contention here and has
been since last year.
I started thread last year:
3rd party Signers - Definition/Usage
http://www.imc.org/ietf-mailsig/mail-archive/msg01933.html
This helped draw the fine line among all sides, regarding simplicity vs.
complexity, weak vs. strong, the business potentials, the TCO that might be
required between ISP/ESP and domains and users, and respectively including
among those who understood the issues, those who don't, as well as those who
almost understood and rather err with simplicity, etc.
The problem with the usage cases cited in the req-00 doc is that its too
limited and tries to justify a particular type of policy for a particular
type of industry, which can quickly be debunked when just about anyone can
use these benefits of DKIM/SSP.
The WHO and WHY has no bearing on the verifiers - regardless of who/why, it
all has to be consistent.
Maybe I am completely wrong, but the bottom line to me is what are technical
capabilities of the protocol as it is currently defined and what are the
possibilities that came come from that - good or bad, meaningful or not. It
is about being consistent on both ends.
So if we want to go simple with 2-3 policies, fine, but we have to lock it
down and not allow the other possibilities to be used as an threat entry
point.
My take is that we don't have to close any of the possible policies. Let the
domain choose what it wants.
People will quickly see what works or doesn't work. No one want to lose
mail, no one what's to reject legitimate mail. But I think we all want
is to stop others from using our domains in unauthorized ways. If that is
not the goal, then why are we doing this for?
Just keep in mind that DKIM will not be successful if there are not enough
receivers out there supporting DKIM. We might give them a high payoff
REASON to support it.
Lets also keep in mind that if we do this right, it is highly probably and
possible to see an early DKIM verifier-only market out there first that will
not begin signing themselves until some later point.
Lets also keep in mind that if we do this right, it is highly probably and
possible to see an early DKIM policy declaration only market out there first
that will not begin signing themselves until some later point. This might
be to just expose the idea the domain does not (currently) sign mail or it
doesn't send mail with certain domains.
So it is very conceivable to have a SSP only market as the domains begin
their begin their DKIM-BASE migration plans.
To me, this would be a good marketing approach for DKIM/SSP.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html