ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Doublefrom language should be in ADSP, not core

2011-07-10 06:25:45
Well, you have a point:

    DKIM has failed to address legacy spoofing problems.

The hope was this would be one of the highest and immediate benefits 
when an domain raised the bar by what was expected in his mail and 
supportive receivers saw deviations from the domain's published policy 
expectation.

But DKIM lost its reason for living when it failed to compete with SPF 
and SPF did this work of addressing legacy spoofs.   So DKIM looked to 
see if it can fill in the SPF hole with transition points (relays, 
multi-hops), thus offering an alternative for a path independent solution.

But before you can make DKIM work at any level, you can't do it on a 
relaxed principle that FAILURES is a norm or that anyone in the middle 
can break/resign the mail.

So as you stated, legacy mail still can exist because we don't know 
how to deal with failure or what is too be expected.


Michael Deutschmann wrote:
On Sun, 10 Jul 2011, Hector Santos wrote:
Now of course, if ADSP was a standard and whitehouse.com had an
exclusive signing policy, receivers would of rejected the junk
distributed by Dave's list server as an ADSP violation.  But ADSP is a
pipe dream.

The attack only matters if the user believes that forgery is impossible
because his ISP and the putative sender both "deploy ADSP" -- and thus the
fact that the message made it to his mailbox means it has to be validly
signed.  (Of course, such users are suckers for messages from "0bama"...)

Otherwise, "Obama" messages with an alternate From: (which the forger
hopes the MUA will ignore) and signature for that second From:, are no
more convincing than plain old forgeries with a single From: and no
signature at all.  In fact, they can be less effective, since:

1. At any step on the way, the message may be rejected as a protocol
violation.

2. The MUA might display to the user, the From: instance that was
intended by the forger for the validator's eyes only.

3. The lazy validator might act on the From: instance that was intended
by the forger for the MUA to display.

Failures (from the forger's perspective) 1 and 2 produce a result less
convincing than a simple unsigned forgery.  Failure 3 produces a result
no more convincing than the simple unsigned forgery.

---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html



-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com



_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html