Subject: [ietf-dkim] Doublefrom, ADSP and mailing lists in perspective,

From: Michael Deutschmann <[email-masked]>
Date: Wed, 27 Jul 2011 00:13:29 -0700 (PDT)

I have one comment to make which ties together both my stance on Otis'
doublefrom crusade, and some reforms I have argued for in ADSP.

Basically, at present the doublefrom trick is simply *unnecessary* for
someone trying to pass me a forged mail.  My MTA, Exim-4.76, does not
natively support ADSP.  It does support core DKIM, but without ADSP it's
not reasonable for the DKIM result to have any effect on the message
disposition.

It probably wouldn't be *that* hard to cobble together some receiverside
ADSP implementation using Exim's other features, but it's just not worth
my while.

I'm not afraid of any phish fooling me, but I am interested in anything
that reduces the amount of "bad mail" reaching my inbox.  But while a
lot of spam is forged, it's forged to be from some ordinary schlub, not
Paypal.

I keep records going back to 2007, and since the start of that year 254
bad mails (spam and viruses) have gotten through to me.  They represent
210 alleged From: domains.  Of those domains, -absolutely none- of them,
-today-, have ADSP records at all.  Not even a "dkim=unknown"! Thus
retrospective analysis shows ADSP is unlikely to make any difference.

I may well implement double-From: detection alone.  *It* would have
blocked three spams from that interval (none of which bear any attempt
at a signature).

Now, all that aside, Paypal would probably still really like me to arm
ADSP, just in case.  But while it may be worth *their* time to sail
100km to meet me (that is, by actually maintaining no-mailing-list
discipline so they can use discardable), it's not worth *my* time to
drive 1km from my hilltop home to the port to meet them.

If ADSP were fixed so that it could be deployed meaningfully at ordinary
domains, with users who post to mailing lists, this might change.

I've already stated my fix -- add "dkim=except-mlist", which states that
any message with broken/absent signatures should be considered bogus if
it is known not to be a mailing list message.

While merely adding a fake "List-Id:" header might let forgeries of
except-mlist domains get through to many users, that will never work on
me.  I recognize my mailing lists via other indicia that are harder to
forge (the MAIL FROM:).

---- Michael Deutschmann <[email-masked]>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 27 Jul 2011 10:38:48 -0700

> me.  I recognize my mailing lists via other indicia that are harder to
Michael,

Your fix will not control phishing or spoofing abuse and would expose 
these domains to open-ended sources.  Reactive methods will prove less 
and less effective as the name and address space grows.

DKIM should be viewed as a Work-In-Progress still missing a viable 
policy layer.  Key sharing will not scale well enough to solve the 
mailing list issue.  Not having a solution for open third-party services 
leaves ADSP suitable only for a tiny fraction of senders that could 
benefit from improved anti-phishing measures.

For DKIM's protections to be comprehensive, policy needs an 
authorization structure able to include open but trusted third-party 
services.  Such policies can be supported by a DNS zone of the domain or 
one referencing that of a reputation provider.  The authorization in 
either case can be resolved within a single and small transaction.

http://tools.ietf.org/html/draft-kucherawy-dkim-atps-03

Unfortunately, such a goal makes little sense when DKIM fails to 
validate input for valid DKIM signatures by ignoring multiple From 
header fields.   None of this will happen over-night, where indeed the 
eventual strategy must be easy for administrators to implement.  IMHO, 
easy should not always mean the use of TXT records however.

-Doug

---

From: Michael Deutschmann <[email-masked]>
Date: Wed, 27 Jul 2011 21:12:14 -0700 (PDT)

On Wed, 27 Jul 2011, Douglas Otis wrote:
> these domains to open-ended sources.

ADSP reforms along my lines would not create any additional exposure,
because they are only intended for senderside deployment by sites that
are currently entirely naked.

The availability of weak ADSP declarations would actually increase the
protection afforded by "dkim=discardable", because then fewer domains
would go without ADSP, and more MX administrators would be incentivized to
implement and arm it.

Remember, for an MX admin the goal is not to "control phishing".  That's
just a side benefit of their true goal, to "control forgeries".  When
forgery can be reliably detected, it becomes a low-false-positive noise
filter, something every MX admin loves.

---

From: Hector Santos <[email-masked]>
Date: Thu, 28 Jul 2011 12:13:10 -0400

As long as the deployment of the pure DKIM protocol continues to 
openly allows for blind middle-ware resigners and destruction of 
author domain signatures to exist without any sort of protocol 
guidelines to offer controls, its hard to see any kind of policy 
concept having a chance to work - author domain as well as the 
inherent abstract 3rd party signer trust policy in DKIM.   It really 
doesn't matter what we call it or who we wish to anchor a policy on, 
if the protocol allows for middle ware to ignore it and still be 
legit, then there is no worth in original signatures, including the 
previous resigner.  At this point, the only real signer one can focus 
on is the last signer.

I've been working on an idea to have our POP3 server SIGN all mail 
that is picked up! Why? because mail is not always RFC5321 (SMTP) 
based. Mail can be created online in the backend format. There is no 
RFC5322 format expectation at this point. Its only during an export or 
gateway does RFC5322 come into play and if the message is export to 
SMTP to send out, then we sign it.  But there are users who will POP 
in to get their mail and that mail is unsigned. So we are looking at 
signing local mail pickups.
-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Hector Santos <[email-masked]>
Date: Thu, 28 Jul 2011 12:48:22 -0400

Douglas Otis wrote:
> ...
> policy layer.  

+1.  But 5+ years WIP? :) It wasn't rocket science.

---

From: "Mark Delany" <[email-masked]>
Date: 28 Jul 2011 14:03:36 -0700

> +1.  But 5+ years WIP? :) It wasn't rocket science.

Well, 7+ years ago it was suggested that "Domain policy is nascent"
with the stated expectation that MARID would soon develop something
comprehensive to satisfy our needs...

Apropos rocket science, at our current rate of progress we risk
outliving the Space Shuttle program.

Mark.

---

From: Michael Deutschmann <[email-masked]>
Date: Fri, 29 Jul 2011 00:46:12 -0700 (PDT)

> DKIM should be viewed as a Work-In-Progress still missing a viable

So you at least agree ADSP needs reform or replacement.

Here's another way to express my points.  Of the policies a sender may
wish to publish in ADSP or a successor, some are worthless or nearly so
for the purpose of preventing phish sent in the name of that sending
entity.  "dkim=unknown" is of course such a policy, and so is my
"dkim=except-mlist".  I imagine TPA could be used to write an infinity of
such policies, as well as solid ones.

But such policies may still be useful in the big picture.  If a sender is
not a bank, perfect forgery protection is not needed, and likely not worth
the sacrifices required for a solid policy.  But such senders may be able
to provide information stronger than unknown, yet weaker than
discardable.

It's good for the phish targets if those domains do.  At present, admins
seem in no hurry to develop and deploy receiverside ADSP support, since it
is rare for a domain to deploy discardable, and thus even rarer for ADSP
(as-it-stands) to ever make a reject recommendation.

If most domains published -at least- a weak policy, receiverside ADSP
deployment would become worthwhile.

If except-mlist became standard, a BOFH might implement ADSP for his own
account, and he would see a decent reduction in overall false-negative
rate, because after applying his mailing-list whitelist, he can treat
except-mlist as discardable.  He can't do that for his users (as he does
not know for sure what they are subscribed to), but once he's taken that
first step, it's easy for him to treat except-mlist as unknown for them
while *still respecting discardable*.  And the phish targets will then be
happy to see discardable honoured.

Consider SPF.  SPF does nothing to prevent phish, as it only protects the
MAIL FROM: address which is not presented to the user by default.  Yet
receiverside SPF deployment has progressed further than ADSP, because SPF
does kill some spam.

---

From: Hector Santos <[email-masked]>
Date: Sat, 30 Jul 2011 02:27:59 -0400

> So you at least agree ADSP needs reform or replacement.

The ADSP "poison pill" didn't do anyone nor DKIM any favors.  It 
wasted an often lot of time for DKIM development. Even as we tried to 
make do with the it minimum offering, not even its author support it 
or wishes to "fix it" so whats the point?

I'm no IETF administrative guru, but this sounds like a problem the 
IETF, WG Chairs, AD, needed to address long ago.

The fact is people are interested and have been for a long time, and 
continues to do so. But when an idea, concept, etc lacks a champion, 
it really doesn't have a chance and quite frankly that was the 
intention all along, hence an IETF poison pill - break it enough to 
make sure there is controversy and conflict to create an IETF no 
consensus.

Hey, I'm all for proving me wrong.  Please do so.

---

From: Hector Santos <[email-masked]>
Date: Sat, 30 Jul 2011 02:40:30 -0400

As you probably recall, the focus of MARID was on LMAP solutions, SPF 
namely.  The reputation proposals have the same problems we had here. 
  It was never a surprise to see the same issues - a Reputation 
protocol requires Batteries and a market we were not ready for. 
DKIM's pins on the side are the same issues and reasons CSV/DNA went 
nowhere.   We lost focus on securing author-domain operations 
foremost.  The 3rd party should of been secondary , and if I recall 
that was the original charter - see how to fit list systems in after 
the fact.    Instead, it became a principle 3rd party anyone can sign 
without restriction protocol and author domains lost all controls.

I find it difficult, yet interesting to see how DKIM can work well in 
this mode.  It risk if not already, of become a high bandwidth mail 
stamping protocol that serves very little purpose and without a doubt 
absolutely no purpose in the world of anonymous mail transaction where 
all the problems exist.    We don't have a real problem with known 
transactions and we certainly don't need DKIM for that.