Subject: Re: [dmarc-ietf] signature sample, was So if you don't want

From: Vlatko Salaj <[email-masked]>
Date: Thu, 19 Jun 2014 23:18:52 -0700

> 4. How does the sending MTA know when to stamp this v=2 DKIM header?
> Presumably, it would need to have a list of known forwarders stored somewhere?

yeah, CDKIM suffers from the same spoofing issue DKIM-D does.

1. aka, if u don't create a whitelist for ur sending MTA to know when to use
   CDKIM or DKIM-D, and when it should not,

2. but instead choose to verbatim include either with every messages u send,

3. any of ur non-ML receivers can just misuse ur CDKIM/DKIM-D,

4. copying it to their email,

5. and signing with their own domain [which was, originally, allowed with
   ur CDKIM/DKIM-D, as it appears in To:].

so, to solve this spoofing hole, u fallback to whitelisting, making sure
ur MTA uses CDKIM/DKIM-D only on email u know will go through legitimate
3rd party munging and resigning.

however, all that work with implementing new header protocol, and creating
a whitelist, while still worrying if ur CDKIM/DKIM-D will get through to
final receiver intact and functional, all while u have no solution for other
3rd party sending on ur behalf, makes me believe these r half-baked solutions,
and i would choose to specify alignment exemption policy through DNS instead,
which does require u make a whitelist, ofc, but other than inputing it into
DNS, doesn't require u do anything else with it, meaning ur MTA is unchanged,
ur DKIM software is the same, and any additional work is on DMARC receiver which
has to upgrade its DMARC verifier to handle 3rd party alignment, but which it
has to do anyway, as DMARC is still new and changing, and making changes to
something new is much easier than changing something old and widespread as DKIM.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 20 Jun 2014 17:49:32 +0900

Vlatko Salaj writes:

 > [A DNS-based whitelist] does require u make a whitelist, ofc, but
 > other than inputing it into DNS, doesn't require u do anything else
 > with it,

Inputting it into DNS is a *very* big deal, however.  First, it's not
at all clear that it scales to precisely the sites I (at least) care
about most: the "> 1 million users" mailbox providers.  Several people
have commented here that they expect pushback from their DNS teams on
any DNS-based solution.  Also, both populating the list and culling it
of "undesirables" have no good solutions yet (admittedly, nobody has
really tried, there probably *are* "pretty good" solutions, but are
they good enough for Yahoo!?)  Most of us control MTAs (or are close
buddies with those who do) -- "let's try it and see, then fix what
ain't so great" will fly for MTA changes.  DNS experiments are less
likely, perhaps much less likely, to fly if DNS is in a different
department.

Second, DNS entries almost automatically provide a reasonably long
window where they are cached downstream (or you greatly increase the
DNS load at the Author Domain).  Eg, right now the TXT resource for
_dmarc.yahoo.com appears to have a TTL of 1800 (30 min).  But spammers
can move millions of messages in 5 minutes.  If abuse is possible,
you're wide open.

Third, this is a very unconventional use of the DNS.  I know, SPF,
DKIM, and DMARC, but those require O(1) subdomain per Author Domain,
not O(users) or even O(forwarders), dynamically named.

Fourth, inputting it into DNS either requires a global list (which is
probably feasible from an operations standpoint) or a proliferation of
artificial domains representing <user, forwarder> pairs, which isn't
going to make the DNS team happy at all (especially since even with a
terribly long TTL they'll have a ruinously low cache hit rate).  But a
global list (ie, one entry per "trusted" forwarder) means that you've
opened a much bigger window for abuse.

By contrast, changes to the MTA mean much more flexibility for making
decisions at message injection time, based on a local lookup in a user
profile database.  I prefer that (knowing that my preferred MTAs'
developers are responsive to user demands for security features).

 > any additional work is on DMARC receiver which has to upgrade its
 > DMARC verifier to handle 3rd party alignment, but which it has to
 > do anyway, as DMARC is still new and changing,

I tend to disagree with your logic, again for several reasons.  First,
the originators who *need* this are relatively few (Yahoo!, AOL, and
who else?); Author Domains used only for "transactional email" will
never need it, and the rest of us probably have a fair amount of time
before we *need* it (granted, several posters here clearly want it
badly so they can use "p=reject" too, but like the rest of us they've
survived for several years without it, and continue to do so).  Better
to impose the costs (and risks of experimentation) on those who
benefit most.

Second, to the extent that receivers need to make adjustments in their
MTAs to handle new versions of DMARC, originators will, too.  And
weighted by mail volume, the relevant originators and recipients are
on the same, fairly short, list of major mailbox providers.

Third, whether done by DNS or by MTA, the hard work is in determining
what policy you want to publish.  And with the MTA the policy is
surely more flexible than with the DNS.

Finally, there's some risk in making changes to any system (and the
amount of data you propose adding to DNS, along with the extra queries
and the likely effect on cache hit rate, make it a systemic change).
Which would you rather have go down on you, your MTA or your DNS?
I'll take a working DNS any time!

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Jun 2014 06:32:16 -0700

> likely, perhaps much less likely, to fly if DNS is in a different

A few further points:

You'll need to come up with a way to populate the list, and keep it
current.  The minute one of your users can't send to a list because your
whitelist isn't up to date, you're getting complaints.  In a DMARC world,
you're even possibly messing with domains outside of your control if that
list is stale.  The notion of having users register the domains of the
lists they want to use is problematic because (a) users don't want to have
to do that, and (b) that puts extending your domain's trust to other
domains in the hands of your users, not all of whom are necessarily
reliable and honest.  That leaves the need for some automated way to
populate the list so your users don't have to do it.  I haven't seen such a
proposal yet, and I doubt we could punt and say "that's out of scope"
unless there's some kind of feasible concept for doing so.

Also, it's a dance to put more policy data into the DNS in any form.  The
"DNS people", as we appear to like to call them, don't like use of DNS to
store policy data even though it's extremely convenient for us to do so.
At a minimum, if we try to do that with TXT records again, we can expect a
huge amount of friction.  We need to be sure that battle is worth having,
and I'm not convinced that it is given the caveats above and in Stephen's
email.

Finally, no DNS-based third party whitelisting scheme has ever gotten any
traction.  The problems caused by the recent application of DMARC don't
appear to have spurred any vendors or operators to try deploying ATPS, TPA,
DSAP, or any variant thereof, even as experiments.  I even put ATPS into
OpenDKIM with zero demand just so it's available for free, today, for
anyone that wants to try it as a concept.  I saw exactly one use of it
after months of data collection.  I think this whole topic has turned into
something we think those people want or need, but they don't.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 20 Jun 2014 15:05:44 -0000

>about most: the "> 1 million users" mailbox providers.

It's not a problem.  Every large mail system* uses DNSBLs; they know
how to deal with the scaling issues.

The problems are figuring out what to put in the DNSBL and who
maintains it.

R's,
John

* - yes, really

---

From: "John Levine" <[email-masked]>
Date: 20 Jun 2014 15:07:56 -0000

>and I'm not convinced that it is given the caveats above and in Stephen's

I don't see that as a problem.  We already have RFC 5518 vouch by
reference which is very close if not identical to what you'd need
here.

>traction. 

That, on the other hand, is a problem.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Jun 2014 13:02:47 -0700

Dear John,

Comments inline:

> reference which is very close if not identical to what you'd need

Strongly disagree.  DMARC is an anti-phishing solution deployed by financial institutions interested in suppressing phishing attacks.  Phish related fraud was not effecting their bottom-line, it was customer loss resulting from phish related abuse that drove this effort to protect the From address.  DMARC is not about dealing with high volume spam.  Especially since methods for dealing with spam are wholly ineffective against phish.

We offer similar anti-phishing services for corporate customers.  Reputation had proved hopelessly ineffective.  The issue is rather simple.  Only the sending domain knows with certainty when their From address is being spoofed.  As such, content of the From address can not be effectively assessed by third-party reputation services, nor are normal spam collection techniques comprehensive or effective.  DMARC feedback provides what is needed but contains PII and should not be generally shared with various third-parties.  Although users may have never sent a message to a mailing-list, DMARC rejection will expose who subscribed to which mailing list nevertheless. 

Since third-party allowances are absolutely critical for maintaining user privacy, TPA-Label expects this information be directly provided by the DMARC domain.  Publication can be easily delegated, but only the DMARC domain is authoritative about which services are being used or which of these services are abusing their From headers.  

> That, on the other hand, is a problem.

While meeting with management in Europe, it seems there is some interest in our company in offering a TPA-Label zone as a service for DMARC domains.  Those interested can contact me privately for appropriate contacts in their area. Perhaps this will also assuage Stephen's DNS related issues.   Publishing in DNS should never be an issue for mailing-lists.  I will attempt to create a draft outlining how a subscription process can send a request via DMARC feedback for authorizations to be granted.

It seems wrong to suggest that Yahoo and AOL will be the only domains able to benefit by enhanced anti-phishing strategies, and that this issue will soon fade.  Unless DMARC is able to ensure adoption of its recommended handling does not result in service disruption or massive complaints, a reject recommendation will quickly devolve into a far less effective quarantine.  If this further devolves into discardable, it will significantly erode email integrity and its usefulness as offering effective notifications.

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Jun 2014 13:05:37 -0700

> reference which is very close if not identical to what you'd need

I'm not talking about recycling existing stuff.  I'm talking about new
mechanisms that aren't out there already, not new data.

-MSK

---

From: Vlatko Salaj <[email-masked]>
Date: Fri, 20 Jun 2014 09:51:07 -0700

On Friday, June 20, 2014 3:32 PM, Murray S. Kucherawy <[email-masked]> wrote:

> no DNS-based third party whitelisting scheme has ever gotten any traction.
> I think this whole topic has turned into something we think those people
> want or need, but they don't.

i beg to disagree. DMARC is barely known to the world at large, and even
less deployed by world at large. even my ISP doesn't know or care about it
yet, yet alone all those poor, small, around-every-corner cPanel-based domains
that populate internet and make it worthwhile our time.

so, any conclusion whether DMARC needs 3rd party alignment support
isn't something anyone can base on some concrete data, but merely pure
common sense and logic. and i do not subscribe to common sense and logic
saying we don't need it.

this mailing list wouldn't have three proposals already, and these requests
wouldn't go repeating every once in a while if there was zero need for it.

and, to be blunt - cause that's just my style - both DKIM-D and CDKIM r,
in a way, 3rd party alignment support proposals, even if of a different kind
and much lesser support-degree.

btw, the same goes for any "DNS ppl" argument. i am a "DNS ppl" for 15 small
companies, and i am strongly for DNS TXT 3rd party DMARC alignment policy
support.

the same goes with the rest of the tl;dr arguments, cause i barely consider
something true if its basic truth can't be put in a sentence or two, instead
of a novel.

-- 
Vlatko Salaj aka goodone
http://goodone.tk