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

[Bron Gondwana <[e-mail]>]

On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote:

I'm just picking out the key quote here:

> On 8/7/2017 4:22 PM, Seth Blank wrote:
>> When validating an ARC signed message, one verifies the latest AMS
>> (which must validate), and *the entire chain* of ARC Seals, not only>> the latest. This guarantees you a list of all message signatories -
>> the chain of custody we're talking about.

Yes, I follow this bit, but then...

>> When evaluating the chain for final receipt, there are two states to>> worry about as a matter of local policy: 1) you trust all the
>> signatories on the chain 2) there is an untrusted signatory on the
>> chain

Which is why it's a bad idea to sign if you're not modifying, because
then everybody has to trust you or their chain breaks, even though you
didn't do anything which required signing.
>> In state #1, you're done - if you trust the signatories then you
>> trust they're not playing games with the AMS and AAR contents or
>> manipulating the message in malicious ways. Now you can make a
>> delivery decision as local policy dictates.

Agree.

>> In state #2, you're also done - if you don't trust all the
>> signatories, then there are a multitude of routes for the message to>> be garbage, including but not limited to everything you've outlined
>> above.

Agree.

>> The critical thing about the ARC Seal is that it guarantees this
>> behavior in state #1 - if you trust all the d= values in the ARC
>> Seals, they all validate, and you have cv=pass, then you know for
>> certain everyone who has manipulated the message (and maybe some who>> handled but did not modify).

In state #1, you don't need a chain of ARC Seal.  You just need each
site to sign their own AAR and each AAR to include "arc=pass" for the
previous AMS.  You trust the sites, so you trust them to verify the ARC
status on ingress.
So ARC Seal isn't adding anything other than complexity.  I'm not saying
"ARC Seal doesn't work in case #1" - I'm saying "ARC Seal is security
theater in state #1".  It's overly complex and adding no value.
>> Without the ARC Seal this determination is not possible and there is>> no way to evaluate the ARC chain for delivery as a final receiver.

And this is the crux of our disagreement.  Seth thinks it's necessary to
do more than signing a statement that you believed the message was
authenticated when you got it, in a way that the next hop can verify
your signature over your own Authentication Results plus the content of
the message.  I disagree.
I'm proposing exactly the same stragety DKIM uses, just with series of
signed "chain of custody" statements rather than the DKIM signature
having to align with the sender domain.
What has no value is a chain of ARC-Seal that has to stretch right back
to the start, because all that is doing is signing its own crypto and
some headers that can be trivially transplanted from another message.
If this list allows messages with attachments, you'll see a copy of
"signedforgery.txt" which has me pretending to be Kurt with the complex
test message he gave me in Prague.  I've forged the Subject and Body,
and then Sealed it as brong.net.
brong@zula:~/src/mail-dkim$ perl arc.pl < signedforgery.txt
pass
ARC-Seal: v=7 pass
ARC-Message-Signature: v=7 pass
ARC-Seal: v=6 pass
ARC-Message-Signature: v=6 fail (message has been altered)
ARC-Seal: v=5 pass
ARC-Message-Signature: v=5 fail (message has been altered)
ARC-Seal: v=4 pass
ARC-Message-Signature: v=4 fail (message has been altered)
ARC-Seal: v=3 pass
ARC-Message-Signature: v=3 fail (message has been altered)
ARC-Seal: v=2 pass
ARC-Message-Signature: v=2 fail (message has been altered)
ARC-Seal: v=1 pass
ARC-Message-Signature: v=1 fail (message has been altered)

The fact that there is an intact chain of ARC-Seal is pointless here.
And as I have (hopefully successfully) argued above, if all the sites
are trusted and they each successfully cryptographically authenticate
the previous sender (or SPF at the first hop), you need is the AMS.  ARC-
Seal does nothing.
Bron.

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