Subject: Re: [dmarc-ietf] Yet another mailing list solution thread

From: Elizabeth Zwicky <[email-masked]>
Date: Mon, 2 Jun 2014 18:51:36 +0000

Whitelisting mailing well-behaved mailing lists is a hole, but not in general a horrible one; the problems are receiver consistency, scaling and maintenance, and they are pretty intractable.

One variant of the minimal DKIM signature which has been suggested to me is to double-sign, with a minimal signature and a protective one using two different selectors. That is currently pointless (if not actually dangerous, because it's very implementation-dependent what receivers will do in this situation), but there are some possible forward paths from there. I don't think I'm enthused, but it's a novel concept.

A mailing-list and receiver change option that has also been suggested to me is to have mailing lists include the original message as a MIME component -- you can then verify the signature on the original message and do some kind of comparison to the new one and decide how you feel about it. Again, it's a future-work solution.

Elizabeth
[email-masked]

From: Brandon Long <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 30, 2014 at 1:13 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [dmarc-ietf] Yet another mailing list solution thread

What can DMARC enforcing domains do right now:
1) Whitelist mailing lists from enforcement.  This is obviously a hole in DMARC which lowers the overall utility.  Its basically saying "we don't trust your p=REJECT, we'll sometimes downgrade it to p=QUARANTINE".

2) Put a really simple DKIM signature on messages which doesn't cover the subject/body.  Ick, but it could theoretically be done.

The Future
1) Support Original-Authentication-Results.  This requires the MLM to add them in the first place, and for the DMARC enforcing domains to check them.  Has an open question of how best to "trust" the OAR header on a message.  Options there are explicit whitelists from the sending domains (tpa-labels or whatever) or to leave it up to the individual receiving domain.

2) A new mailing list specific DKIM canonicalization.  Its unlikely to be possible to be 100% authentication, its open for debate whether we could come up with one that'll provide some level of auth that may be useful in a more complicated "spam/phishing evaluation".

3) Some sort of "permission to relay" token.  This is pretty similar to the DKIM above.

4) Plain old whitelisting (tpa-labels or whatever).  Personally, I think without AuthRes/OAR, this is too big a hole to be useful.

5) More radical changes to MLMs/clients such as defining new headers with associated client requirements (ie, the footer / subject prefix is theoretically redundant with the adoptions of List-* headers).  Other alternatives include embedding the original message in a wrapper (a message/digest of one).  Are there any other clients besides mutt which handle this well?

Other ideas?

Brandon

---

From: Brandon Long <[email-masked]>
Date: Mon, 2 Jun 2014 12:43:48 -0700

On Fri, May 30, 2014 at 8:10 PM, John Levine <[email-masked]> wrote:

> >1) Support Original-Authentication-Results.  This requires the MLM to add
> >them in the first place, and for the DMARC enforcing domains to check
> them.
> > Has an open question of how best to "trust" the OAR header on a message.
> > Options there are explicit whitelists from the sending domains
> (tpa-labels
> >or whatever) or to leave it up to the individual receiving domain.
>
> This keeps reducing to the previous case.  If you know what senders
> you trust, why do you need the OAR header?
>

OAR and the signed mailing list means that I trust the mailing list to have
properly checked the original validation.

The mailing list didn't reject the DMARC message because it was valid, but
its modifying the message, so no one downstream knows that it was fine.
 Or, it may not enforce DMARC at all.

OAR allows the MLM to tell everyone else what the auth state was prior to
munging.  The MLM may choose to forward the message regardless of the auth
state, but receivers downstream can then enforce.

The OAR isn't necessary for a DMARC "compliant" MLM which would know to
make sure the message passed DMARC as sent by following one of the
mitigation strategies (don't munge the message, munge the from, embed the
message as an attachment, etc).  It seems necessary for any whitelisting
scheme, however, otherwise an "anyone can post" mailing list on a host
which doesn't enforce DMARC is a wide-open hole.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Mon, 2 Jun 2014 12:58:47 -0700

On Sat, May 31, 2014 at 6:07 AM, Stephen J. Turnbull <[email-masked]>
wrote:

> Brandon Long writes:
>
>  > 1) Reject posting from p=REJECT users
>
> +1 <0.2 wink>
>
>  > It seems like [ignoring DMARC bounces when checking if the
>  > recipient is able to receive] should be relatively uncontroversial,
>
> Mailman is already working on this.  Unfortunately, some domains just
> use a generic 5.7.x policy bounce, and other don't even give you that
> much information.  (We are guessing, but backtracking to the sender --
> you don't always even get that information -- and correlating with
> other DMARC bounces, we're pretty sure that these are DMARC bounces.)
>

We use 5.7.1, and in general we don't let 5.7.1 errors set  users to
bouncing
(though, enough bounces will do so eventually).  Its tricky, that's for
sure, but generally we
treat 5.7.1 as "we can't know whether or not these will ever succeed or its
something specific to this message")

>
>  > messages would be rejected... Perhaps we should agree on an
>  > extended smtp status code that such rejections should use in order
>  > to make this easier to implement.
>
> This will take years to diffuse into the installed base, and some
> sites have this boneheaded idea that giving any information about why
> a message was rejected harms their security, so won't implement anyway.
>

If you're implementing DMARC, aren't you already on the bleeding edge?
And, if its going to take a long time, then better to do so as early as
possible.

And one could certainly hope that the olive branch from Y! would indicate
willingness to make that level of change.

DMARC also seems like a really weird thing to want to "hide".

(we try not to be too obtuse with our rejection reasons because we find
that the abusers
usually know the reason, its the innocent or semi-innocent that gets caught
that needs
help...)

>
>  > [Rewriting From:] could potentially use some finessing or
>  > standardization.  For example, several MLMs are moving the original
>  > From header to X-Original-From, I could also imagine a
>  > List-Original-From or List-Poster header.  Standardizing on that
>  > would allow clients to do intelligent things about the display of
>  > the two pieces of information, or handling reply-to better.
>
> The *last* thing we want is clients doing anything intelligent with
> any of those headers.  The problem that DMARC addresses has nothing to
> do with the letters F-R-O-M.  It has to do with identity alignment.
> It just happens that RFC5322 (and predecessors) standardized From: for
> conveying originatory identity.  So as soon as MUAs start displaying
> Use-This-Field-To-Bypass-DMARC: to users, DMARC will *need* to be
> revised to sign that one, too -- with a signature authorized by the
> Author Domain, *not* the ML domain.  This of course is impossible
> without Doug Otis's TPA-labels or something like that.
>

Yes and no.  I had a similar argument internally recently, and had a really
hard time
convincing folks that if there was a way to display that information
safely, we wouldn't
have needed DMARC in the first place.

That said, having the information available for searches (from:blong) or to
make sure
contacts aren't messed with, or maybe in extended pop-ups (ie, if you
expand the address field,
it could say something like "the original sender was supposedly [email-masked],
but we can't guarantee that).
Or, it could be used for reply-to handling (though, we just add the
original address to the reply-to for that now).

>  > 1) Whitelist mailing lists from enforcement.  This is obviously a hole
> in
>  > DMARC which lowers the overall utility.  Its basically saying "we don't
>  > trust your p=REJECT, we'll sometimes downgrade it to p=QUARANTINE".
>
> That horse already left the barn.  I don't know what GMail's criterion
> is, but our testing demonstrates that some mailing list posts are
> passed through to the spam folder rather than rejected.
>
> I don't understand what you mean by "lowers overall utility".  In
> fact, it's quite clear from the way Yahoo! is advocating various
> mitigation strategies that they really do not mean DMARC reject, they
> mean Do-What-I-Mean reject.  That's what GMail gives them.
>
> For the others, I agree with John Levine's comments.

In a perfect DMARC world, we wouldn't need the hole.  Its also clear that
eventually the bad actors
will find the hole, and so it will eventually go away or change.  Depending
on how much mail would
be caught, a better hole may be made, or there may be no hole.  I know
which way our spam/phishy team is leaning on the subject.

Brandon

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 02 Jun 2014 16:00:25 -0400

> which doesn't enforce DMARC is a wide-open hole.

If I already know to trust the mailing list, what does OAR cause me to do 
differently?

Scott K

---

From: Brandon Long <[email-masked]>
Date: Mon, 2 Jun 2014 13:10:04 -0700

> If I already know to trust the mailing list, what does OAR cause me to do

What does "trust" mean there?

Here's an example we ran into.  We had an open-posting (anyone can post)
mailing list on a "trusted" domain, but there was no way for gmail to know
the mailing list was open posting, and it didn't enforce DMARC.

The "reputation" of the mailing list was stellar, 99%+.. but a spear
phishing attack was made through the mailing list.

So, as I said, if "trust" means "enforces DMARC", then yes, OAR is
unnecessary.  But, that is a level that I don't expect many MLM services to
do.  If ietf.org doesn't enforce DMARC, then "trusting" its mailing lists
for DMARC enforcement makes no sense.  OTOH, I can potentially imagine many
MLM services at least upgrading to doing spf/dkim auth and signing their
messages.  I can then see from the receivers end, that this service signs
99+% of its mail and adds an OAR header, then its easy for me to manage a
reputation for their service and whitelist that service or mailing list.
 Even then, we would still be at the mercy if the service was compromised
or a hole was found where by a third party was able to send mail through
their servers and have it signed, but that issue is less likely or at
least, there's only so much that blanket protections can do against that
level of motivated attacker.

Brandon

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 02 Jun 2014 16:34:45 -0400

> On Sat, May 31, 2014 at 6:07 AM, Stephen J. Turnbull <[email-masked]>
...
> something specific to this message")

FYI,

There is a discussion about defining new codes for email authentication 
failures in progress on apps-discuss which may interest people interested in 
this particular topic.

https://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/

(comments there not here and I suggest a review of the ML archives prior to 
posting comments)

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 02 Jun 2014 16:36:50 -0400

On Monday, June 02, 2014 13:10:04 Brandon Long wrote:
> > > > >1) Support Original-Authentication-Results.  This requires the MLM to
> > 
> > add
> > 
> > > > > Has an open question of how best to "trust" the OAR header on a
> > 
> > message.
> > 
> > > OAR and the signed mailing list means that I trust the mailing list to
> > 
> > have
> > 
> > > The mailing list didn't reject the DMARC message because it was valid,
> > 
> > but
> > 
> > > munging.  The MLM may choose to forward the message regardless of the
> > 
> > auth
> > 

Trust in this context means "trust not to lie on the OAR".  Either you trust 
them not to lie (and the content can be used) or you don't and it can't be 
used.  If you've evaluated them sufficiently to conclude they won't lie on the 
OAR, you already know enough to just whitelist them.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 Jun 2014 13:56:38 -0700

> (comments there not here and I suggest a review of the ML archives prior to
For a little extra background: The impetus for that work came from the idea
that it might be useful to distinguish between DMARC failures and other
failures in a way that's useful to agents that will receive them.  DMARC
could, and probably should, define one or more of its own using that
document's model.

We decided not to tie that document to the progress of DMARC, which is why
there's not a DMARC code in that one.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Mon, 2 Jun 2014 14:09:47 -0700

Dear Brandon,

See comments inline:
On Jun 2, 2014, at 1:10 PM, Brandon Long <[email-masked]> wrote:

> On Mon, Jun 2, 2014 at 1:00 PM, Scott Kitterman <[email-masked]> wrote:
> Here's an example we ran into.  We had an open-posting (anyone can post) mailing list on a "trusted" domain, but there was no way for gmail to know the mailing list was open posting, and it didn't enforce DMARC.
> 
> The "reputation" of the mailing list was stellar, 99%+.. but a spear phishing attack was made through the mailing list.
> 
> So, as I said, if "trust" means "enforces DMARC", then yes, OAR is unnecessary.  But, that is a level that I don't expect many MLM services to do.  If ietf.org doesn't enforce DMARC, then "trusting" its mailing lists for DMARC enforcement makes no sense.  OTOH, I can potentially imagine many MLM services at least upgrading to doing spf/dkim auth and signing their messages.  I can then see from the receivers end, that this service signs 99+% of its mail and adds an OAR header, then its easy for me to manage a reputation for their service and whitelist that service or mailing list.  Even then, we would still be at the mercy if the service was compromised or a hole was found where by a third party was able to send mail through their servers and have it signed, but that issue is less likely or at least, there's only so much that blanket protections can do against that level of motivated attacker.

More than a decade ago, we managed a zone dedicated to mailing-list subscription policy compliance to confirm the mailing-list's practices.  Back then, the test was to ensure confirmed subscriptions. Of course, doing so remains important.  Authorizing only validated domains still leaves a few things to still check regarding posts.

1) enforcing DMARC policy alignment request (not a problem when mailing-list friendly i.e. TPA-Label)
2) protect use of List-ID or Sender header and stipulate inclusion in authorization
3) use X-original-authentication-results and stipulate inclusion in authorization (missing but can be added)

It would be easy to add any number of these stipulations for receivers to check before applying the authorization.

Also consider the TPA-Label method can disable a domain in minutes following any detected or reported abuse.  No one wants to see their services disrupted which helps ensure compliance.  Allow others to use your lists, and this hammer gets much bigger. 

Unless email is only permitted to be exchanged peer-to-peer, there will always be some intermediate steps to be trusted.  Take the Intuit example, where they make use of the Sender header.

Regards,
Douglas Otis

---

From: "John R Levine" <[email-masked]>
Date: 2 Jun 2014 17:25:01 -0400

> properly checked the original validation.

True, but if you trust the mailing list that far, how likely is it
that the OAR will tell you anything bad?

Here's a thought experiment: let's say you have a nice trustworthy
list, they're sending you OAR, you deliver all their mail and the
complaint rate rounds to zero.  I expect there will be a fair number
of lists like that.

Now you find out that the OAR headers are fake.  (They're not sending 
spam, they're just not reporting the real inbound DKIM or SPF.)  Other 
than that nothing's changed, they're sending the same mail and the 
complaint rate still rounds to zero.  Should you handle their mail 
differently? If so, why?

R's,
John

PS: Are there in fact any ISPs that pay attention to OAR?  I could easily 
add it if it made them happy.

---

From: Brandon Long <[email-masked]>
Date: Mon, 2 Jun 2014 15:21:50 -0700

On Mon, Jun 2, 2014 at 2:25 PM, John R Levine <[email-masked]> wrote:

> spam, they're just not reporting the real inbound DKIM or SPF.)  Other than
> that nothing's changed, they're sending the same mail and the complaint
> rate still rounds to zero.  Should you handle their mail differently? If
> so, why?
>

I proposed internally a scheme where we would compute a reputation for
mailing lists, and ones which are sufficiently high will be whitelisted for
DMARC.  The issue that was presented to me is spear phishing attacks
through mailing lists (which we've seen) and the amount of damage that can
be done in a single phishing campaign through such a list until the
reputation drops sufficiently to stop it.

A spear phishing attack, by definition, is usually in the noise for any
sufficiently large list or service.  Its not clear to me that we can solve
that completely, if the target is high value enough, a great deal of effort
into finding a hole would be made.

The other part is that we've seen entire spam campaigns that run to the
millions in <30s, or coordinated attacks across datacenters, all trying to
beat latencies in some of our systems.

And what happens when the reputation does fall due to one of these attacks?
 Is that mailing list dead for ever to DMARC domains?  Or just for a week?

Anyways, yes, the "they could be faking it" would be the hole in the OAR
scheme.  It may be possible to do some level of testing on the OAR, like
trying to do implied SPF verification, but perhaps the whole thing is toast.

> add it if it made them happy.

The problem with OAR is knowing when to trust it, so although we accept
OAR, we only do so for domains we trust, which last I checked was basically
only us.  Helps us and anyone who trusts us, but isn't generally useful yet.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Mon, 2 Jun 2014 15:31:36 -0700

> OAR, you already know enough to just whitelist them.

I would argue they aren't the same.

Trusting that they aren't lying on the OAR just means that I can implement
policy about the value of the OAR.

That doesn't mean that we agree on what policy we should implement in
regards to authentication-results.

An MLM could implement OAR but not enforce DMARC, for example.  In that
case, a DMARC enforcing receiver could reject the message for DMARC if it
fails, but not reject messages that passed auth for the mailing list.

One could imagine using it for other things as well, the spam filtering for
a mailing list may not be particularly strong, but with OAR, we could apply
different rules based on authentication.  One could imagine trusting
"authenticated sender in address book" more than "unauthenticated sender in
address book", for example.

Brandon

---

From: "John R Levine" <[email-masked]>
Date: 2 Jun 2014 18:46:43 -0400

> through mailing lists (which we've seen) ...

Eww.  My lists are set up so that they trap anything with DMARC failures 
on the way in (it uses the regular taboo words check on the A-R header) 
but I suppose an OAR would be a reasonable token of good faith.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 02 Jun 2014 21:29:47 -0400

> address book", for example.

Even if I grant you that (and I'm not sure I do), I also don't know why OAR is 
better than AR.  

In order to ensure OAR was added by the ML (or whoever you trust to add it 
correctly) you're going to have to grovel through the received fields and see 
if the MTA you trust added the field.  Once you've done that, you might as well 
just use AR.  Calling it OAR adds nothing beyond forcing us to re-invent the 
wheel.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 3 Jun 2014 03:16:54 -0000

>A mailing-list and receiver change option that has also been suggested to me is to have mailing lists
>include the original message as a MIME component -- you can then verify the signature on the original
>message and do some kind of comparison to the new one and decide how you feel about it. Again, it's a
>future-work solution.

Well, yeah, we call those MIME digests.  They work now in most list
managers, but the UI leaves a lot to be desired.  Most list managers
let you set the digest frequency so you could set it to something like
five minutes to limit the delivery delay, and most of the digests
would have only one or two messages.

It occurs to me that Yahoo has a set of 30,000 mailing list like hosts
that send you mail according to last month's blog post, and due the
way DMARC works, you can look at a copy of every message that is
rejected due to DMARC policy.  Have you looked at the DMARC rejected
stuff from those hosts, or a sample thereof, to see whether they're
really a hole you need to protect your users from?

R's,
John

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 03 Jun 2014 19:46:07 +0900

Scott Kitterman writes:

 > In order to ensure OAR was added by the ML (or whoever you trust to
 > add it correctly) you're going to have to grovel through the
 > received fields and see if the MTA you trust added the field.

Re: groveling.  Received fields are easy to fake and nobody signs
those (what would that mean, anyway?)  Obviously you need to sign any
*AR you did yourself, or nobody should trust it.  That should make it
"easy" to determine trust.  Am I missing something?

Besides the complexity of chains of trusted authenticators, of course.
Obviously further protocol would be needed there.

Steve

---

From: "John Levine" <[email-masked]>
Date: 3 Jun 2014 14:39:43 -0000

>which doesn't enforce DMARC is a wide-open hole.

But any list that doesn't limit who can post is a wide open hole
anyway.  I don't think there are very many, and don't much care what
happens to them.  The only one I subscribe to is freebsd-users, whose
managers apparently believe that limiting who can post is pointless
because the spammers care enough to find the list and subscribe.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 3 Jun 2014 14:42:19 -0000

>Even if I grant you that (and I'm not sure I do), I also don't know why OAR is 

I get the impression there are two reasons for OAR:

a) A-R is likely to be stripped by intermediate MTAs, OAR isn't.

b) whoever suggested OAR didn't understand A-R semantics

Take your pick.

R's,
John

PS: I just adjusted my lists to add OAR so I expect zero bounces now.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 04 Jun 2014 01:17:54 +0900

John Levine writes:

 > >Even if I grant you that (and I'm not sure I do), I also don't
 > >know why OAR is better than AR.
 > 

You're joking, right?

>From the O-A-R I-D:

   Some sites wish to take into consideration such authentication
   results claimed by trusted intermediaries, effectively extending
   the trusted channel to specific external entities.  Although
   [AUTHRES] includes support for this notion, this separate mechanism
   is simpler, more robust, and requires no changes to existing
   authentication infrastructure.

   Therefore, this document defines a new field called Original-
   Authentication-Results.  The content of the field is identical to
   that specified in [AUTHRES].  This field is required to be unique,
   appearing only once in a message, and thus it is possible to
   determine conclusively whether or not it is included in the part of
   the header covered by a signature.

I think that's clear enough, although you might dispute whether it
actually works as advertised (seems to, to me).  It also seems good
enough for 95% of all mailing list usage, including the "spear-
phishing through an ML" case described earlier.

I wonder if the d, s, i fields in DKIM could somehow be coopted to
create a conventional authserv-id for A-R.  That could make it easy to
identify the "right" A-R in a header with multiple such.  (Ignoring
the case of a 3rd party deliberately introducing fake duplicates,
which would make the message suspect all by itself.)

Regards,

---

From: Brandon Long <[email-masked]>
Date: Tue, 3 Jun 2014 12:39:20 -0700

On Tue, Jun 3, 2014 at 7:39 AM, John Levine <[email-masked]> wrote:
[quoting me, iirc]

> because the spammers care enough to find the list and subscribe.

All smtp is a wide open hole.  The point of authentication and DMARC is to
change that, to reduce
the attack surface.

The argument then becomes how big a hole is too much to leave open.  DMARC
p=REJECT was supposed
to be nearly completely closed for those implementing it.

Brandon