----- Original Message -----
From: "Andrew Newton" <andy(_at_)hxr(_dot_)us>
My comments are in-line:
On Aug 1, 2005, at 6:13 AM, Dave Crocker wrote:
By way of seeding discussion, here is a feeble attempt (ie, my own)
at creating
a draft response.
Don't sell yourself short. I don't think I could do any better, and
by the looks of it most people on this mailing list aren't even trying.
Well, Andrew, atleast for me, I would really like to be part of this effort,
but I can't help but feel it is a becoming a waste of time. Dave hasn't
responded to any the discussions to the rather large threads regarding the
DKIM signers and verifiers double checking OA SSP. Does that mean he
doesn't agree with it? Does he think its "Troll material" and the less you
respond the quicker it will die? He has been quoted having such a belief,
so why bother?
That said, the OA SSP verification issue, to me, is the most important issue
in DKIM and to me, it is a near show stopper for DKIM acceptance.
If it has not been said yet, this issue plays right into the key questions:
- What does DKIM solve?
- What are the benefits?
- What are the negatives?
- Where are the holes (Exploits, Bad Actors, Bad middle ware, Risk)?
- Can it be done?
To me, I thought DKIM was trying to protect "email domains" with an obvious
benefit of addressing spoofing and phishing, especially for strong exclusive
policy holders. Those with high value email and exclusive SSP policies can
benefit greatly I think. Its negatives, outside the security issues
(holes), are probably a change in software design at various levels in order
to be effective. The holes, to me, is pretty obvious that it begins with
the relaxed and 3rd party signing provisions. This is where the fuzziness
is located. And I believe it can be done, but the degree of effectiveness
will largely be based on both ends of the software honoring the OA SSP
policies.
So I think DKIM cogs really need to work out the relaxed and 3rd party
signing issues because this is where the threats will largely be located.
Seriously, if this part is ignored, I can't see how I can implement DKIM
with any degree of confidence or trust in its results.
If we learned anything from DNS based solutions such as SPF where there are
relaxed provisions, it will get exploited and by my measurements, by nearly
44% of all SPF results are relaxed. A secondary CBV check on these result
in nearly a 66% rejection.
Consider the fact that DKIM is a payload solution, you do recall that
SENDERID did have a thorn on its side over it being a PAYLOAD solution as
well. The difference here, is that I think there is a degree of technical
merit for DKIM payload analysis. SenderID has none. For over 80% of all
transactions, the PRA is equal to the x821.MailFrom, clearly showing that it
is pure overhead the majority of time.
DKIM has merit because it depends on a new entities introduces into the
system. Entities that increase and create new assertions on the validity of
the transaction that can only exist with a new presumed higher intelligence
in new software. The problematic issue of legacy software is filtered out
of the analysis.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim