ietf-dkim
[Top] [All Lists]

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

<Prev in Thread] Current Thread [Next in Thread>