ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-06.txt // Input requirements

2011-04-18 17:31:24
On 4/15/11 8:59 PM, Michael Deutschmann wrote:
On Fri, 15 Apr 2011, Douglas Otis wrote:
In addition, verifiers MUST
ensure the presence of multiple singleton originating header fields
do not provide a valid signature result.
---

Not including this additional requirement removes recipient assurances a
sender may have expected to be offered by DKIM.
Not... This... Again...

There are already other ways to get a phish past an unsuspicious user in
spite of DKIM/ADSP.  The full name trick is one, mi5pe11ings are another.
Also rather important is that few users are likely to have the thing armed
to block mail.

You're basically trying to weatherstrip a barn door that we have no idea
how to even close.  Pointless.
Michael and Barry,

For the record...

One method to avoid look-alike or display-name attacks would be to sort 
messages into folders.  A fairly common practice.

On the basis of message sorting, specific From domains accepted on the 
basis of Author-Domain DKIM signatures would provide significant 
protection not easily thwarted.  However, failings to include multiple 
 From header field checks during signature validation would permit 
simplistic phishing attacks not controllable by the domain being 
phished.  :^(
(Also, the extra filtering you want would quickly be added to
SpamAssassin anyway, once people try to exploit it.)

Requirements to strictly enforce the message format do have a place, but
in a different RFC.  Such an RFC would outline minimal standards for
supression of forgeries.  Email providers who follow this hypothetical
RFC would advertise that fact, and then phish-target sites might reward
users who provide a contact address at a compliant site.
Trust in DKIM would be misplaced when negligent verification processes 
lack both obvious and simplistic checks representing a tiny fraction of 
a signature verification process.  When the concern is about resource 
consumption, having SPAM filters recheck for multiple origination 
headers because essential checks were specified as SHOULD rather than 
MUST only adds to this level of waste.
But you'd need to put a lot more than just a reference to ADSP and your
enforcement of a unique From:, to make such a document viable.

Otherwise phish-targets won't offer sufficient reward to be worth the
tech-support hassle of being unable to disable ADSP (lest they lose
compliance) at the request of a user with a false-positive problem.
DKIM is about enabling protective policy based upon valid signatures 
without requiring modifications to MUAs.  It should not matter whether 
the policy is being applied by the enterprise on behalf of employees, or 
by ISPs on behalf of their users.  Do not permit such an obviously 
defective verification process to be specified.

-Doug

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