Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

From: Bron Gondwana <[email-masked]>
Date: Thu, 17 Aug 2017 18:09:03 +1000

On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote:
> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana
> <[email-masked]> wrote:>> While there exists A SINGLE SITE which is ARC-unaware and DMARC
>> p=reject aware, you can't use ARC on a DMARC p=reject domain without
>> rewriting the sender.  Otherwise that site will bounce the email.>> 
>> 
> Goodness, it's a wonder that we've ever successfully deployed anything
> incremental around here.  ;-)> -MSK

I laugh as well, but it's more than p=reject isn't enough in the ARC
world, because it doesn't distinguish between:a) I'm OK with email from my domain being sent via mailing lists; and
b) no, this domain is only ever used for direct messages, it should
   never appear in ARC chains that don't also pass DKIM.
The existing behaviour of p=reject is (b) for receivers that don't
support ARC - so the question becomes:  are we defining ARC to changing
the behaviour of p=reject to (a)?  If so, will we define a different (b)
later, when we could instead havedefined a different p= for (a).

The interesting question is what happens at non-updated sites in each
case, because the answer is either "valid emails that should have been
accepted are rejected by old policy engine" or "spoofed emails that
should have been rejected are accepted by old policy engine"
That's a worthwhile question.  Maybe it's already been asked and
answered and I just missed that.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 17 Aug 2017 10:18:25 -0400

On 8/17/2017 4:09 AM, Bron Gondwana wrote:
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     While there exists A SINGLE SITE which is ARC-unaware and DMARC
>>     p=reject aware, you can't use ARC on a DMARC p=reject domain
>>     without rewriting the sender. Otherwise that site will bounce the
>>     email.
>>
>>
>> Goodness, it's a wonder that we've ever successfully deployed 
>> anything incremental around here.  ;-)
>> -MSK
>
> world, because it doesn't distinguish between:
> a) I'm OK with email from my domain being sent via mailing lists; and
You assume that mailing lists are the only corner case that ARC might 
address. It’s quite possible that this is not true. It's also not clear 
what you mean by "direct messages". When an agent does an MX lookup, it 
has no way of knowing whether the indicated MX host is the final 
destination or whether there are additional internal (to the 
administrative domain) or external hops beyond the initially indicated 
MX host. That's one of the things that makes the wonderful wacky world 
of email so interesting. While mailing lists are important to many, they 
are the tail and not the dog in the email world.

> support ARC - so the question becomes:  are we defining ARC to 
> changing the behaviour of p=reject to (a)?  If so, will we define a 
> different (b) later, when we could instead have
> defined a different p= for (a).
>

This is absolutely an incorrect statement. Policy within DMARC, as 
expressed by p=, is a request by the sending domain and can always be 
ignored or overridden by local policy. Using ARC as an input is no 
different than any other input that a mailbox provider/validator 
considers in making delivery decisions.

> should have been rejected are accepted by old policy engine"

In the DMARC world, emails are only valid in the sense that they pass 
either SPF or DKIM validation. A decision to accept or reject any given 
email involves many choices beyond simply passing DMARC validation for a 
given from domain. Spoofing may involve emails which pass DMARC 
validation but contain spoofing in the From display name, or any number 
of other ways.

Mike

---

From: Seth Blank <[email-masked]>
Date: Thu, 17 Aug 2017 11:48:58 -0700

On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana <[email-masked]>
wrote:
> b) no, this domain is only ever used for direct messages, it should never
> appear in ARC chains that don't also pass DKIM.
>

The DMARC WG charter directly addresses this:
https://datatracker.ietf.org/wg/dmarc/charter/

Our stated goal is to fix indirect mail flows so that they do not break
under DMARC. To me, that's an explicit requirement of a), with b) being out
of scope.

Seth

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Aug 2017 11:56:11 -0700

On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana <[email-masked]>
wrote:

> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <[email-masked]>
> wrote:
>
> While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject
> aware, you can't use ARC on a DMARC p=reject domain without rewriting the
> sender.  Otherwise that site will bounce the email.
>
>
> incremental around here.  ;-)
> -MSK
>
>
> The existing behaviour of p=reject is (b) for receivers that don't support
> ARC - so the question becomes:  are we defining ARC to changing the
> behaviour of p=reject to (a)?  If so, will we define a different (b) later,
> when we could instead have

My point is that the "SINGLE SITE" posture is absurd.  In all likelihood
there are still some MTAs out there that don't implement ESMTP and nothing
has melted.  We should fully expect things to roll out gradually, as they
always have.  Anyone planning for a flag day should speak up now so we can
disabuse them (and, of course, abuse them).

If the success of DMARC depends on 100% deployment of ARC, we may as well
pack up and go home now.  It'll never happen.

I support the idea of trying ARC even in the form you claim includes
superfluous operations.  (For the record, I find your technical argument
compelling.)  If after a period of experimentation and data collecting we
find that the seal is not itself useful, we can negotiate a reduced form
and try that.

If you really want to prove your point sooner, implement both, run them for
a while, and publish the results.  But given that there are interoperating
implementations now, I think there's enough to be learned from the
experiment to continue from here rather than reset.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Aug 2017 12:12:45 -0700

> under DMARC. To me, that's an explicit requirement of a), with b) being out

+1.  My understanding is that altering DMARC is off the table right now.
We have to try to move forward.

I'm particularly opposed to adding a new "p=" value without a great deal of
thought put into it, lest the set of values there become hopelessly
polluted with things representing every conceivable combination of
authentication results and header field values, many of which will end up
being ephemeral.

-MSK

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 18 Aug 2017 08:46:06 +1000

On Fri, 18 Aug 2017, at 04:48, Seth Blank wrote:
> On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana
> <[email-masked]> wrote:>> I laugh as well, but it's more than p=reject isn't enough in the ARC
>> world, because it doesn't distinguish between:>> a) I'm OK with email from my domain being sent via mailing lists; and>> b) no, this domain is only ever used for direct messages, it should
>>    never appear in ARC chains that don't also pass DKIM.> 
> https://datatracker.ietf.org/wg/dmarc/charter/> 
> Our stated goal is to fix indirect mail flows so that they do not
> break under DMARC. To me, that's an explicit requirement of a), with
> b) being out of scope.
OK, so case (a) means that we are explicitly redefining the behaviour of
a DMARC receiver.  It should now accept messages that it used to reject,
because they have additional new headers.  Which means what - until it's
updated it now no longer compliant, or else it means (as I have just
responded to Brandon in what appears to be a split of this same thread)
that intermediate sites which modify messages are left in a limbo where
they have to guess what happens.
In one respect, that's no different than the situation now where
intermediate modifiers KNOW that they can't send on messages for
p=reject domains (or at least, they would know if they were DMARC-
aware).  But it does mean that workarounds for DMARC (like modifying the
from header) are needed for some time yet.
Bron.