[dmarc-ietf] ARC-Seal is meaningless security theatre

[Bron Gondwana <[e-mail]>]

I thought long and hard about using a less inflammatory title, but I
figure maybe going in hard is the right way here, because I'd rather
fix this before it becomes a standard! (and thanks Dave for your
thoughtful questions during the Prague DMARC session which prompted
some of my thinking)
Unfortunately I didn't get a full chance to think about ARC and how it
all functions before Prague, and then I hadn't fully internalised it by
the DMARC session - I was still refactoring the code I wrote on the
weekend and testing it some more, as well as getting the signing side
done.  It took a few days to fully understand how all those signatures
work together.  I had let others focus on ARC within our company rather
than looking at it myself until now.
So my apologies for coming along late with this manifesto!  I've been
trying to think of a more polite and diplomatic way to say it, but so
far I haven't see anything to convince me that ARC-Seal is anything
other than snake oil.  It's excessive crypto for no benefit, and with
the way I've had it described to me and the way it's being used right
now at least at Google (sealing every message on the way in), it adds
confusion rather than clarity to message provenance.
Let me explain.  Starting with purpose.

ARC conflates two purposes:

a) providing a new signature when you change a message in ways that
   break its existing signature.
b) providing a signature where there is none, but SPF passed and you
   would have trusted the source email anyway.
Apparently "just DKIM sign everything" isn't viable due to key
management problems and "sending on behalf of".  I'm willing to
stipulate that, because we have to work with the reality of deployed
systems with any new standard if it wants traction.
There is a third purpose that needs signatures:

c) new email received from trusted/internal host with no signature yet

This is generally handled by DKIM-signing the message before sending it
outside an organisation's trusted infrastructure.  FastMail for example
DKIM signs our outbound email during the final scan before adding to the
outbound queues.  Internally it travels around with an internal-only
header that identifies the sending user to allow us to choose which DKIM
signatures to apply, then we sign on final injection into the outbound
queue.  I suspect other organisations do the same, and this is what DKIM
was designed for.  My understanding of ARC is that is not supposed to
replace DKIM for this case.
Anyway, we are conflating:

1) I need to sign this email which I didn't modify because the next hop
   wouldn't be able to verify that it was sent from an authorised source
   any more; with
2) I'm modifying this message and I am asserting that I believed it was
   from an authorised source and correctly signed before I modified it
Right now AAR and AMS are exactly the same for those two cases.

The problem is - advice on "when should I ARC-Seal" is really woolly,
leading to a third case being conflated in here:
3) I'm not modifying this message or breaking its signature, I'm just
   adding my own signature as it passes through
Case three is the real problem.  By adding an AAR, AMS and AS in that
case, you're adding crypto which is misleading.  I will make my case
below :)  I use the following parties:
d=gmail.com - a sender and eventual receiver.  I could sub fastmail.com
here just as easily, but "everyone" knows gmail, and they currently ARC-
Seal all incoming email.
d=mailinglist.com - a mailing list which modifies all email, and hence
needs to apply ARC to every message for case (2) above.
d=forwarder.com - a site that just forwards email without changing the
message at all - something like pobox.com, our alias service.
d=sketchy.com - another forwarder who isn't well known or trusted.

Trust isn't transitive, gmail trusts mailinglist.com to validate
signatures and to only apply clean transformations (change sender, add a
footer) to any email it receives, but it doesn't trust sketchy.com at
all.  mailinglist.com on the other hand isn't sure about sketchy.com,
but has no reason to consider it less trustworthy than other forwarders
because it doesn't have a giant machine learning database to handle site
reputation.
Now let's consider the following message history.  The mail is going to
follow this path:
gmail.com => sketchy.com => mailinglist.com => forwarder.com =>
gmail.com
This seems somewhat contrived, but maybe sketchy.com is some university
system where a club has set up an alias that goes to their mailing list,
and one of the members is an alumnus using a separate university alumni
system which forwards to their gmail account.  That's not a totally
unreasonable mail flow.
Here's a message where sketchy.com just forwards the message, with no
changes made:
original message:

DKIM-Signature: d=gmail.com (VALID)
From: <[e-mail]>
To: <[e-mail]>

first hop:

AS: i=1, d=sketchy.com, cv=none (VALID)
AMS: i=1, d=sketchy.com (VALID)
AAR: i=1, dkim=pass, spf=pass, arc=none
DKIM-Signature: d=gmail.com (VALID)
From: <[e-mail]>
To: <[e-mail]>
ENV-To: <[e-mail]>

second hop:

AS: i=2, d=mailinglist.com, cv=pass (VALID)
AMS: i=2, d=mailinglist.com (VALID)
AAR: i=2, dkim=pass, spf=fail, arc=pass
AS: i=1, d=sketchy.com, cv=none (VALID)
AMS: i=1, d=sketchy.com (INVALID)
AAR: i=1, dkim=pass, spf=pass
DKIM-Signature: d=gmail.com (INVALID)
From: <[e-mail]>
To: <[e-mail]>

We see that both DKIM and i=1 AMS are now invalid, only the AS chain
continues to validate.  The DKIM still passed on arrival to
mailinglist.com, because sketchy.com didn't actually modify the message,
but won't pass again after this.
third hop:

AS: i=3, d=forwarder.com, cv=pass (VALID)
AMS: i=3, d=forwarder.com (VALID)
AAR: i=3, dkim=fail, spf=fail, arc=pass
AS: i=2, d=mailinglist.com, cv=pass (VALID)
AMS: i=2, d=mailinglist.com (VALID)
AAR: i=2, dkim=pass, spf=fail, arc=pass
AS: i=1, d=sketchy.com, cv=none (VALID)
AMS: i=1, d=sketchy.com (INVALID)
AAR: i=1, dkim=pass, spf=pass
DKIM-Signature: d=gmail.com (INVALID)
From: <[e-mail]>
To: <[e-mail]>
ENV-To: <[e-mail]>

and finally gmail seal it on the way in:

AS: i=4, d=gmail.com, cv=pass (VALID)
AMS: i=4, d=gmail.com (VALID)
AAR: i=4, dkim=fail, spf=fail, arc=pass
AS: i=3, d=forwarder.com, cv=pass (VALID)
AMS: i=3, d=forwarder.com (VALID)
AAR: i=3, dkim=fail, spf=fail, arc=pass
AS: i=2, d=mailinglist.com, cv=pass (VALID)
AMS: i=2, d=mailinglist.com (VALID)
AAR: i=2, dkim=pass, spf=fail, arc=pass
AS: i=1, d=sketchy.com, cv=none (VALID)
AMS: i=1, d=sketchy.com (INVALID)
AAR: i=1, dkim=pass, spf=pass
DKIM-Signature: d=gmail.com (INVALID)
From: <[e-mail]>
To: <[e-mail]>
ENV-To: <[e-mail]>

In here we have two things that are interesting:

1) the oldest AMS that still validates.  Nothing was changed since then.2) the AAR with the same i= value (i=2) which shows that DKIM still
   passed then.
So we can tell from these headers that the only place which modified the
message was mailinglist.com.  So far so good.  Absent ANY value at all
are the ARC headers with i=1, i=3 or i=4.  They add no value.  Likewise
the ARC-Seal at i=2 only adds value because it signs the AAR at i=2.
This is literally the only proof we have at this point that sketchy.com
didn't completely rewrite the message.  This same value could be
obtained by having sketchy.com and forwarder.com and gmail's inbound do
no ARC processing at all other than validating the AMS of
mailinglist.com rather than the DKIM signature at forwarder.com and
gmail.com inbound.
The only way to know that sketchy.com didn't modify the message is
because mailinglist.com's AAR said that dkim still passed at that time.
But mailinglist.com could easily lie about that if it wanted to, the
chain would still be unbroken.
Further, ARC-Seal doesn't capture the really interesting bits -
which are "what was the envelope at this point" or even "what was
the date at this point" - meaning you can re-purpose old ARC-Seals
for as long as you like if the selectors still exist, and they will
continue to validate.
OK, this has become pretty long and rambly, but here's the thing:

*AS adds nothing over just having AMS signing its own AAR, and then you
only have to verify ONE signature, the most recent.*
 Any site which lies about AAR and also modifies the message can just as
 easily file the serial numbers off an existing ARC chain, pretend it
 received the message from a point in that chain, and then mint a
 convincing AAR, a valid AMS and a valid AS which chains with the
 existing set of seals.  The seals don't include any previous facts
 about the message other than the hashes in the lower i= AMS headers,
 and a single modification to message content will render them invalid.
 Short of a global registry of all known email mesages (in which case
 ARC is pointless), you can't tell if those ARC headers were lifted off
 another message and reused.
You either trust the most recent signer and trust that THEY validated
the previous signer/SPF (and so on) or the chain is broken anyway, so
why add a parallel, easily falsified, chain of signatures?
So since ARC-Seal doesn't add any value, and adds complexity and cost
(in extra DNS lookups and crypto) and failure points (in potential DNS
tempfails which break the chain even though the underlying crypto is
sound and could be verified later) - it's a waste and, as I stated in
the subject,  snakeoil with no benefit.
What is valuable is AMS and AAR, and along with that - advice to not add
your own AMS unless you really have to.  If you aren't breaking the
existing signature, don't add your own, because it confuses provenance
on the message.  ARC would be a better standard if it removed AS
entirely, and had AMS sign its own AAR (e.g. by adding another tag to
the AMS header which is the hash of the  associated AAR)
A more cheap and nasty fix, assuming it's too late/complex to change the
protocol more, would be to keep AS, but change the validation  to  only
require checking the most recent AS, since validating the rest is
meaningless.
Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]