Subject: Re: [dmarc-ietf] ARC (was - Re: DMARC and ietf.org)

From: Alessandro Vesely <[email-masked]>
Date: Wed, 17 Aug 2016 11:47:02 +0200

The message quoted below deserves discussion, which didn't take place on
the IETF list where it was originally posted:
https://mailarchive.ietf.org/arch/msg/ietf/0sFUeCumvE8ij6Y92H9CvLKSTJY

Since ARC adoption, that discussion belongs to this WG list.  So I reply
here.

On Sat 13/Aug/2016 17:22:52 +0200 Dave Crocker wrote:
> On 8/13/2016 8:10 AM, John R Levine wrote:
>> More to the point, ARC lets lists keep working they way they're supposed
>> to.
> 
> I participate in the informal group that created ARC.  I am hoping ARC
> will be helpful.
> 
> But we need to be cautious with our expectations.  First, it isn't
> operational yet, so we don't even know whether it will do what we want
> it to.  Worse, we don't know how much that will help.
> 
> That's not a claim that it won't work or won't be useful, but it is
> playing amidst some Internet-scale, multi-stage dynamics that can get
> complicated.
> 
> By way of example:  With DKIM, trust assessment is of the entity doing
> the signing, typically the originating service.  With ARC, that
> assessment still must be made, but it must be coupled with an assessment
> of the first ARC-signing entity.
> 
> Maybe that's not a big deal.  But I think that combinatorial trust
> assessments are new and therefore might be challenging.

That challenge can only be accepted by mailbox providers who are large
enough to maintain a statistically meaningful perspective of global
Internet mailing.  Smallish MTAs will likely have to take recourse to
dnswl.org, possibly after some more attempts at creating
protocol-specific white lists.

Formal criteria to establish when valid ARC fields can inhibit DMARC's
policy would seem to be better suited for protocol specifications.  I
proposed ARC-0, [0] but there may be better methods than that.

[0] Proposal to adopt ARC documents into the WG (toward phase 2
milestone), 11 May 2016:
http://mailarchive.ietf.org/arch/msg/dmarc/RXpz36Rs_aXvhlt9Tkpi89LJmrI

> And that's not counting the question of whether an ARC signature will
> survive better than a DKIM signature...  (The design is intended to have
> better survival, but again, it hasn't been tested in the field.)

SMTP currently warns that, in some unspecified cases, "more caution and
conservatism should be applied when considering whether or not to
perform fixes and how."  Some implementations[1] look for DKIM
signatures and refrain to fix if any is found.  Rather than just adding
ARC's fields to the list of header fields whose presence should prevent
fixing, it might be more stable to standardize a generic method to
signal that caution and conservatism should be applied --unless we think
ARC is the final, ultimate message signing technique, that is.

[1] For one, parameter NOADDRREWRITE, as documented in:
http://www.courier-mta.org/submit.html

Ale
--

---

From: Brandon Long <[email-masked]>
Date: Thu, 18 Aug 2016 16:40:42 -0700

> http://www.courier-mta.org/submit.html

With ARC, one's MTA could do the DKIM check, fix the message, and then ARC
sign the result.

Brandon

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 20 Aug 2016 13:02:14 +0200

On Fri 19/Aug/2016 01:40:42 +0200 Brandon Long wrote:
>>> [...]  With DKIM, trust assessment is of the entity doing the
>>> signing, typically the originating service.  With ARC, that 
>>> assessment still must be made, but it must be coupled with an
>>> assessment of the first ARC-signing entity.
>>>
>>> Maybe that's not a big deal.  But I think that combinatorial
>>> trust assessments are new and therefore might be challenging.
>>
>> That challenge can only be accepted by mailbox providers who are
>> large enough to maintain a statistically meaningful perspective of
>> global Internet mailing.  Smallish MTAs will likely have to take
>> recourse to dnswl.org, possibly after some more attempts at
>> creating protocol-specific white lists.
>>
>> Formal criteria to establish when valid ARC fields can inhibit 
>> DMARC's policy would seem to be better suited for protocol 
>> specifications.  I proposed ARC-0, but there may be better methods
>> than that.
>> [...]
> 
> With ARC, one's MTA could do the DKIM check, fix the message, and
> then ARC sign the result.

How can that ARC set be used by the next hop?  *Guidance for receivers*
is based on /sufficient history/:

                           Final message recipients may or may not
   choose to examine these results when messages fail other
   authentication checks.  They are more likely to override, say, a
   failing DMARC result in the presence of an intact ARC chain where the
   participating ARC message handlers have been observed to not convey
   "bad" content in the past, and the initial ARC participant indicates
   the message they received had passed authentication checks.

Say A -> B -> C are the MTAs:  C sees a message where B is cited in the
To: or Cc: header fields.  The message is ARC signed by B.  B says A's
DKIM signature was good, but now it is broken.  A's DMARC policy says
that C should reject in that case.  What should C do?

If C is gmail, it likely has sufficient history to know how A and B
behave.  But what about small MTAs whose email flow is statistically not
enough to use combinatorial trust assessments?

If A had added a second DKIM signature, signing just the To: or Cc:
field(s) which cited B, with l=0 for the body, then that signature
likely survived B's fixing and hence C could infer that B is a true (not
self-styled) forwarder.  IOW, A's second (weak) signature provides C
with a formal criterion to instruct its local policy to accept email
that fails the DMARC mechanism check even if A has published a "reject"
policy.

So, what I called ARC-0 in my former proposal, doesn't really have much
to do with ARC.  The concept is weak signatures.  Of course, they won't
work unless carefully standardized and implemented.  The question is if
they will ever work at all, and if this WG is willing to consider them.
If not, we need to address Dave's concern some other way, or resign
ourselves to building a solution which will likely work 98.7% for some
and 0.2% for others.

Ale
--

---

From: Brandon Long <[email-masked]>
Date: Mon, 22 Aug 2016 17:07:24 -0700

> enough to use combinatorial trust assessments?

If your MTA is too small to use combinatorial trust assessments, then you
are stuck
with the same two options you have today: manual whitelists or using a
service to
give you that information.

If you're small enough, I don't think manually whitelisting the mailing
list servers your users
are subscribed to would be that challenging, especially if you receive the
DMARC reports your
server generates.

> ourselves to building a solution which will likely work 98.7% for some

So, any message sent from A to B can then be used as a replay with any
content to any party as long
as the To/Cc are intact?  That seems pretty useless.

Brandon

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 23 Aug 2016 20:55:38 +0200

On Tue 23/Aug/2016 02:07:24 +0200 Brandon Long wrote:
> are stuck with the same two options you have today: manual whitelists or
> using a service to give you that information.
>
> If you're small enough, I don't think manually whitelisting the mailing list
> servers your users are subscribed to would be that challenging, especially
> if you receive the DMARC reports your server generates.

I can configure my filter to accept DMARC-failed messages from authenticated 
domains which are trusted MLMs.  Even if I only see 20~30 new mail domains each 
day, I'm not going to manually look for names which seem to be lists.

A two-step heuristic to determine trusted MLMs consists of (1) collect domain 
names from received List-Post: header fields matching <mailto:*@*.*>, and 
authenticated (via SPF, DKIM, or DNSWL), and then (2) from the domains 
collected that way, select those that my users write to.  _Small domains_ --by 
definition, for the scope of this discussion-- have no anonymous users.

That heuristics keeps failing until a subscribed user actually posts to a MLM. 
Skipping step (2) makes it an obvious attack path, but whitelisting can 
mitigate it a bit.

How can aggregate reports help here?  Would you please expand?

> content to any party as long as the To/Cc are intact?  That seems pretty
> useless.

Yes, B can send whatever they like using your name@A.  That's how weak 
signatures work.  Of course, valuable domains such as banks and other phish 
targets should never use them.  Our task here is to better indirect flows, not 
counter phishing.  Anyway, regular domains may want to weak-sign only the copy 
of a message addressed to a trusted MLM.  Bumping DKIM version was proposed as 
a means to have C also require a valid signature of B.  Some receivers already 
use local policies to limit the shape of DKIM-Signatures they accept; for 
example, some regard signatures with l=0 as invalid.  Smart C-role verifiers 
may want to match B to To: or Cc: before accepting weak signatures.

I'd put weak signatures when I play A.  That way I'd complement the above 
technique, trusted MLMs whitelisting, which I'd use when I play C.  An 
additional element would be to have B save From:.  In fact, A's weak h= should 
not include From:, because rewriting From: currently seems to be the best 
anti-DMARC workaround.  B would save the value of From: using a new header 
field name, e.g., say, Original-From:, Authenticated-From:, or ARC-From: for 
daisy chaining (vote for one).  Finally, C may consider the presence of this 
new field to confirm A's role, and possibly fix From:.  In those cases, a 
message passes if C is either smart or dumb, not somewhere in between.  DKIM 
v=2 would eliminate the "dumb" side.

If I were clever, I would list all possible statuses of A, B, and C (such as 
complying with DKIM, DMARC and ARC, applying or recognizing weak signatures, 
being aware of either DKIM v=2 or the new header field, et cetera) along with 
the relative probabilities that they are implemented at various stages in time, 
and then compute the chances that C can pass/reject correctly in the two cases 
of B being white or black, at each stage.  I reckon there are cases of A 
unknown to C, perhaps because either is small, where some mixes of the above 
techniques would save the day, thereby encouraging more small domains to 
publish strict DMARC policies, don't you think?

Ale
--

---

From: Brandon Long <[email-masked]>
Date: Tue, 23 Aug 2016 17:19:35 -0700

On Tue, Aug 23, 2016 at 11:55 AM, Alessandro Vesely <[email-masked]> wrote:

>> list
> I can configure my filter to accept DMARC-failed messages from
> authenticated domains which are trusted MLMs.  Even if I only see 20~30 new
> mail domains each day, I'm not going to manually look for names which seem
> to be lists.
>
> A two-step heuristic to determine trusted MLMs consists of (1) collect
> domain names from received List-Post: header fields matching <mailto:*@*.*>,
> and authenticated (via SPF, DKIM, or DNSWL), and then (2) from the domains
> collected that way, select those that my users write to.  _Small domains_
> --by definition, for the scope of this discussion-- have no anonymous users.
>
> That heuristics keeps failing until a subscribed user actually posts to a
> MLM. Skipping step (2) makes it an obvious attack path, but whitelisting
> can mitigate it a bit.
>

aggregate reports you send to others would tell you about posts you were
rejecting.

And I guess it depends on what "small" means, if you're seeing 20-30 new
domains a day that are lists and you're rejecting for DMARC, then yes, that
may be beyond the ability to whitelist.

If you were actually seeing 20-30 whiitelistable mailing list domains a
day, I think you might get >90% of them in a couple months.

Ok, that's not true, Google Apps allows domains to have mailing lists, but
that's probably the bulk of them... but they'll all be ARC signed by the
same provider (google.com).  O365 may also have a ton, but again, probably
whitelistable as a single entity.

> targets should never use them.  Our task here is to better indirect flows,
> not counter phishing.  Anyway, regular domains may want to weak-sign only
> the copy of a message addressed to a trusted MLM.  Bumping DKIM version was
> proposed as a means to have C also require a valid signature of B.  Some
> receivers already use local policies to limit the shape of DKIM-Signatures
> they accept; for example, some regard signatures with l=0 as invalid.
> Smart C-role verifiers may want to match B to To: or Cc: before accepting
> weak signatures.
>
> additional element would be to have B save From:.  In fact, A's weak h=
> should not include From:, because rewriting From: currently seems to be the
> best anti-DMARC workaround.  B would save the value of From: using a new
> header field name, e.g., say, Original-From:, Authenticated-From:, or
> ARC-From: for daisy chaining (vote for one).  Finally, C may consider the
> presence of this new field to confirm A's role, and possibly fix From:.  In
> those cases, a message passes if C is either smart or dumb, not somewhere
> in between.  DKIM v=2 would eliminate the "dumb" side.
>

But you're still whitelisting MLMs in C, or even possibly in A in this
scenario.

If I were clever, I would list all possible statuses of A, B, and C (such
> as complying with DKIM, DMARC and ARC, applying or recognizing weak
> signatures, being aware of either DKIM v=2 or the new header field, et
> cetera) along with the relative probabilities that they are implemented at
> various stages in time, and then compute the chances that C can pass/reject
> correctly in the two cases of B being white or black, at each stage.  I
> reckon there are cases of A unknown to C, perhaps because either is small,
> where some mixes of the above techniques would save the day, thereby
> encouraging more small domains to publish strict DMARC policies, don't you
> think?
>

I'm not sure if that's a goal.

Brandon

---

From: Terry Zink <[email-masked]>
Date: Wed, 24 Aug 2016 00:33:38 +0000

> O365 may also have a ton, but again, probably whitelistable as a single entity

We’re trying to get this signed by groups.office.net.

-- Terry

From: dmarc [mailto:[email-masked]] On Behalf Of Brandon Long
Sent: Tuesday, August 23, 2016 5:20 PM
To: Alessandro Vesely
Cc: dmarc-ietf
Subject: Re: [dmarc-ietf] ARC and weak signatures (again)

On Tue, Aug 23, 2016 at 11:55 AM, Alessandro Vesely <[email-masked]<mailto:[email-masked]>> wrote:
On Tue 23/Aug/2016 02:07:24 +0200 Brandon Long wrote:
On Sat, Aug 20, 2016 at 4:02 AM, Alessandro Vesely <[email-masked]<mailto:[email-masked]>> wrote:

I can configure my filter to accept DMARC-failed messages from authenticated domains which are trusted MLMs.  Even if I only see 20~30 new mail domains each day, I'm not going to manually look for names which seem to be lists.

A two-step heuristic to determine trusted MLMs consists of (1) collect domain names from received List-Post: header fields matching <mailto:*@*.*>, and authenticated (via SPF, DKIM, or DNSWL), and then (2) from the domains collected that way, select those that my users write to.  _Small domains_ --by definition, for the scope of this discussion-- have no anonymous users.

That heuristics keeps failing until a subscribed user actually posts to a MLM. Skipping step (2) makes it an obvious attack path, but whitelisting can mitigate it a bit.

aggregate reports you send to others would tell you about posts you were rejecting.

And I guess it depends on what "small" means, if you're seeing 20-30 new domains a day that are lists and you're rejecting for DMARC, then yes, that may be beyond the ability to whitelist.

If you were actually seeing 20-30 whiitelistable mailing list domains a day, I think you might get >90% of them in a couple months.

Ok, that's not true, Google Apps allows domains to have mailing lists, but that's probably the bulk of them... but they'll all be ARC signed by the same provider (google.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fgoogle.com&data=02%7c01%7ctzink%40exchange.microsoft.com%7c723de85caec64ffeb2d708d3cbb458a1%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636075947847055377&sdata=XnSxn8I2o6IQ4YGCuf55UmtKUKtaAbVGuHR%2bCirvMhs%3d>).  O365 may also have a ton, but again, probably whitelistable as a single entity.

Yes, B can send whatever they like using your name@A.  That's how weak signatures work.  Of course, valuable domains such as banks and other phish targets should never use them.  Our task here is to better indirect flows, not counter phishing.  Anyway, regular domains may want to weak-sign only the copy of a message addressed to a trusted MLM.  Bumping DKIM version was proposed as a means to have C also require a valid signature of B.  Some receivers already use local policies to limit the shape of DKIM-Signatures they accept; for example, some regard signatures with l=0 as invalid.  Smart C-role verifiers may want to match B to To: or Cc: before accepting weak signatures.

I'd put weak signatures when I play A.  That way I'd complement the above technique, trusted MLMs whitelisting, which I'd use when I play C.  An additional element would be to have B save From:.  In fact, A's weak h= should not include From:, because rewriting From: currently seems to be the best anti-DMARC workaround.  B would save the value of From: using a new header field name, e.g., say, Original-From:, Authenticated-From:, or ARC-From: for daisy chaining (vote for one).  Finally, C may consider the presence of this new field to confirm A's role, and possibly fix From:.  In those cases, a message passes if C is either smart or dumb, not somewhere in between.  DKIM v=2 would eliminate the "dumb" side.

But you're still whitelisting MLMs in C, or even possibly in A in this scenario.

If I were clever, I would list all possible statuses of A, B, and C (such as complying with DKIM, DMARC and ARC, applying or recognizing weak signatures, being aware of either DKIM v=2 or the new header field, et cetera) along with the relative probabilities that they are implemented at various stages in time, and then compute the chances that C can pass/reject correctly in the two cases of B being white or black, at each stage.  I reckon there are cases of A unknown to C, perhaps because either is small, where some mixes of the above techniques would save the day, thereby encouraging more small domains to publish strict DMARC policies, don't you think?

Brandon

Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 30 Aug 2016 20:48:19 +0200

Back to connected lands...

On Wed 24/Aug/2016 02:19:35 +0200 Brandon Long wrote:
>>>> Say A -> B -> C are the MTAs:  [...]
>>>
> If you were actually seeing 20-30 whitelistable mailing list domains a

20-30 was the total number, it would take me even less time to do manual
whitelisting.  Fact is I'd feel like wasting my time while providing a
fuzzy service to my few users that way.

> whitelistable as a single entity.

Thanks for the insight.

>>>> [...] The concept is weak signatures.  [...]
>>>
>> Yes, B can send whatever they like using your name@A.  That's how
>> weak signatures work.  [...] regular domains may want to weak-sign
>> only the copy of a message addressed to a trusted MLM.
>>
>> technique, trusted MLMs whitelisting, which I'd use when I play C.
> 

Yup,  in A it works from the first time.

> I'm not sure if that's a goal.

I agree it is not a goal to have more strict DMARC policies, not in the
sense of the quest for SPF -all a dozen years ago.  However, I'd regard
widespread adoption of non-test policies as a success indicator of DMARC.

Personally, mailing list is what prevents me from such policy shift, but
other local providers don't even DKIM sign...

Ale