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

From: Douglas Otis <[email-masked]>
Date: Mon, 01 Aug 2011 11:25:46 -0700

On 7/28/11 2:03 PM, Mark Delany wrote:
>>> DKIM should be viewed as a Work-In-Progress still missing a viable
>>> policy layer.
>> +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.
MARID offered unsafe chained record sets as an IP address authorization 
scheme unrelated to what people were observing.  Where IPv6 increases 
the aggregate list and where DSNSEC increases the amplification, risks 
to otherwise uninvolved sites increase with this scheme.  Vetting 
messages prior to acceptance likely plays a greater role in lessening 
MTA burdens anyway.

Open-ended third-party relationships from a policy perspective may seem 
difficult to express, but it remains possible, whether by the domain or 
as a service, to acknowledge these relationships.   An authenticated 
domain can be authorized by a published hash label.  This would be a 
safe method to extend policy without requisite two party coordination as 
currently expected by DKIM.

DKIM can be more than just making an assertion "this domain is too big 
to block."  With comprehensive policy, DKIM should be able to prevent 
spoofing of a domain that may cause recipients to give up on the 
service.  Until policy can be comprehensively applied, other 
authentication related benefits will likely remain elusive.

Of course, such a goal must include proper input validation by DKIM.

-Doug

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

---

From: Michael Deutschmann <[email-masked]>
Date: Tue, 2 Aug 2011 23:43:44 -0700 (PDT)

On Mon, 1 Aug 2011, Douglas Otis wrote:
> This would be a safe method to extend policy without requisite two
> party coordination as currently expected by DKIM.

The problem is that for the majority of From: domains claimed in incoming
mail, the TPA approach is just as unfeasable as "two party
coordination".  The problem is not the lack of a language for the
alleged-sender to express detailed policy -- it is that the alleged-sender
doesn't have a fully detailed policy to express.  The real communication
barrier is between the DNS admin for a domain, and the end users who have
mailboxes on that domain.  An end-user would have to be exceptionally
computer literate in order to help his admin publish a correct TPA policy.

While *phishers* may see no point in forging that class of domain, a
layered protocol (ADSP or successor/replacement) that makes no attempt to
defend those domains is not worthwhile for me to deploy *as an MX admin*.
Which means blatant phish with a single From: and no signature could sail
right through.

The best that the administration of such domains can offer, is a claim
that the end-users have been trained to always use the official
smarthost, and thus every non-mailing-list mail will be signed.

It's weak, but it's far better than nothing.  For some recipients, such as
myself, it would be as useful as discardable.  I know that anything that
smells enough like a mailing list to invoke the loophole, yet hasn't
already been diverted by my whitelists, is junk.

---- 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: Mon, 08 Aug 2011 12:03:37 -0700

> computer literate in order to help his admin publish a correct TPA policy.
The concept behind the TPA scheme was to enable services on behalf of 
senders that lack requisite staffing to support this level of policy 
effort when using open-ended third-party services.  The list of open 
third-party services where exceptions are desired could be centrally 
managed.  Senders would be allowed to delegate the task to those 
services having requisite staffing.  For the sender, it would be a 
single one-time delegation.  A service that would need to be tailored to 
different categories of senders.
> Which means blatant phish with a single From: and no signature could sail
This effort would only be suitable for enterprises wanting to better 
defend email as a service to their customers.  Just as person to person 
communications are often secured by buddy-lists, a similar scheme could 
better defend an open-ended email notification schemes likely to become 
phishing targets.   DKIM could support a service that offers a form of 
third-party service buddy-list to assist in anti-phishing policies of 
targeted domains without disrupting use of these open third-party services.
> already been diverted by my whitelists, is junk.
Why should white-listing mailing-lists or open third-party services 
become a burden for the recipient or their administrator?  Better 
management of these lists directly benefits senders.  While it might 
represent too much effort for the average sender, this would not be too 
much effort for most email reputation services to handle.  The cost and 
management of this anti-phishing service should fall on the sender, not 
the recipient.

For this to make any sense with respect to anti-phishing, Double From 
header fields must not produce valid DKIM signatures.  While DKIM can 
potentially support enhanced policies aimed at mitigating phishing, it 
lacks a basis for gauging spam reputations.  DKIM lacks any assurance 
who the sender intended to receive a message.  This limitation in DKIM 
makes holding a signer accountable for unsolicited commercial email 
problematic.

-Doug

---

From: Michael Deutschmann <[email-masked]>
Date: Wed, 10 Aug 2011 11:18:24 -0700 (PDT)

> effort when using open-ended third-party services.  The list of open

I don't see how that can work anytime soon for the use-case that concern
me, that of ordinary end-users at a consumer ISP posting to mailing lists.
I suppose you could implement a central whitelist of mailing lists, but
some mailing lists are easier to forge than others.  If a weak mailing
list gets on to the whitelist, then you have a policy just as easy to
bypass as except-mlist.  But if a mailing list *that people actually use*
can't get on the whitelist, you have false positive rejections.

> become a burden for the recipient or their administrator?  Better

I'm not seeking to *impose* that burden as a sender, I'm looking for the
opprotunity to *accept* that burden as a recipient, so as to reduce my
incoming false negative rate.

Many recipients can't take up the burden, and thus cannot detect forgeries
of except-mlist domains.  But they lose nothing compared to the world
with just "unknown" and "discardable".  (I'm not counting "all" since it
is too vague...)

---

From: Douglas Otis <[email-masked]>
Date: Fri, 12 Aug 2011 18:08:54 -0700

> me, that of ordinary end-users at a consumer ISP posting to mailing lists.
Your alternative creates support issues beyond the senders control when 
acceptance criteria by recipients conflict with actual use.  The TPA 
scheme allows sender to establish third-party criteria beyond just 
conventional mailing-lists.
> can't get on the whitelist, you have false positive rejections.
The original TPA draft attempted to encompass any and all verification 
methods.  The goal was to lessen the recipient's burden when vetting 
messages and allow senders a means to express the infrastructure they 
use.  If there was a common method to authenticate SMTP transmitters 
cryptographically, the email attack surface could be dramatically 
reduced.   DKIM is a poor tool at curbing spam as it can not safely 
assess SMTP transmitter behaviors.  However, with a flexible policy 
layer, it might still prove useful at curbing phishing ploys. (Assuming 
input validation was properly applied.)

> incoming false negative rate.
This is about the sender policy.   As a Sender, the criteria used by the 
recipient is pivotal.  The TPA scheme allows the Sender to establish the 
specific criteria without expecting the recipient to guess.  This scheme 
could also leverage any sender authentication that might be offered by 
DANE for example.
> with just "unknown" and "discardable".  (I'm not counting "all" since it
The outcome in either "except-mlist" or "all" remains beyond the 
sender's control.  Without overcoming certainties, use of these policies 
exposes the sender's recipients to threats remain beyond the sender or 
their agents control.   The sender benefits so let the senders do the 
work.  A win-win for both the sender and the recipient.  Guessing is 
lose-lose and a win for the malefactors.

-Doug

---

From: Michael Deutschmann <[email-masked]>
Date: Sat, 13 Aug 2011 19:18:18 -0700 (PDT)

On Fri, 12 Aug 2011, Douglas Otis wrote:
> sender's control.

"except-mlist" is no worse here than "unknown", which is what the vast
majority of domains will be publishing in the absence of the
"except-mlist" option.

> The sender benefits so let the senders do the work.  A win-win for both
> the sender and the recipient.

For most domains, the sender benefits are not sufficient to motivate a
"discardable" or TPA deployment.

And with neither TPA, "discardable" nor "except-mlist" in common use,
paying attention to ADSP isn't worth an MX admin's time.  The sender loses
utterly.