Re: Additional lookups (was Re: [ietf-dkim] Re: 1368 straw-poll)
2007-03-01 20:35:43
Douglas Otis wrote:
On Mar 1, 2007, at 5:12 PM, Hector Santos wrote:
Of course, this was pointed out to the yahoo guy in a similar thread
last year where verifiers might give different "reputation" treatments
to valid DKIM messages. This will also have the same exploitation
factor - XYZ domain signs up with ABC Reputation house, XYZ domain
is now spoofed everywhere else due it is "credentials."
When millions of new domains are acquired at no cost every day, even
finding a valid signature is not likely to hold much value.
If we are on the same wavelength, with the premise a node will process a
high volume of bad domains, overhead will be tremendous, efficiency low
in looking for the small percentage "good needle in the haystack" in the
avalanche of mail. It probably won't be worth the effort.
Just keep in mind that these MILLION DOMAINS do not have to waste time
with any kind of DKIM consideration since ALL systems must operate in
legacy mode anyway and since FSUSP is a (unfortunate) part of the
DKIM-BASE spec, to me, that just tells bad guys they don't have to worry
too much about cracking anyone keys - just fake it. Just make it look
like it has some "high profile" status in relationship to contemporary
non-existence profiles.
In
addition, even where providers such as Yahoo restrict the volume of
messages from each account, nothing prevents these messages from being
relayed well beyond these constraints.
Now I am a different wavelength <g>
By allowing a signer policy that can associate various originating
domains with that of the signing domain, permit the detection of
possible replay abuse and DSN MailFrom spoofing. Few messages being
returned will verify. "Does this MailFrom belong with this signing
domain?" could be answered by a signing policy. Such would be a feature
of the DOSP draft. I admit this draft is well over the top, but it does
provide a means to answer these basic questions.
Well, maybe, but going back to my paragraph about, that thread was about
the same concern Wieste suddenly discovered.
For failure, the DKIM-BASE solution is FSUSP but since it allows for
local policy, I highly doubt FSUSP will be tolerated, especially when as
systems learn how abusive FSUSP can be in a high volume of bad mail.
For success, there is NO standard handling. We have ideas, such as DAC.
But because there is no standard for handling success, there will be
different treatments at the verifiers and this is just as exploitable as
the failures.
That was my point.
I'm a very practical engineer, and in my view, SSP offers a MINIMAL set
of instructions to eliminating the (unexpected) obvious.
Rejecting messages carrying a particular From header will not provide
substantial protection. Taken to the extreme, this approach is likely
make things worse. DKIM can help curb abuse when there is a means to
associate the signing domain with different originating domains. I am
not a fan of the oft heard suggestion that everyone should delegate
their domain or share their private key, to say the least.
To me, successful process automations are based on how good it can
detect failure or deviations from the norm (expected protocol behavior).
When you have provisions to be flexible with failure, then it makes the
process unpredictable. So whatever you admins want to do just has to
make sense from a protocol and automation standpoint.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|