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

Bron Gondwana <brong@fastmailteam.com> Sat, 19 August 2017 01:47 UTC

Return-Path: <brong@fastmailteam.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A6013245F for <dmarc@ietfa.amsl.com>; Fri, 18 Aug 2017 18:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=anSvokG8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Aq614TR/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-8rZERzcNIi for <dmarc@ietfa.amsl.com>; Fri, 18 Aug 2017 18:47:26 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16851132436 for <dmarc@ietf.org>; Fri, 18 Aug 2017 18:47:26 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 317872210A; Fri, 18 Aug 2017 21:47:25 -0400 (EDT)
Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Fri, 18 Aug 2017 21:47:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Z1n5sK S3S0hvLRYtxwh0dVTc36WQi5e3nsQIn0tGGBY=; b=anSvokG8IRDAiUPr7ykS7H OmjAi6R6y0aXH36hb1J4aRBA7N3HPrKtyHH+HXnSTwNvD4rNrxtwA+aRGgVwO/H8 ZtqGHze5yA6ivjy4zrM8KQHIf89qmcrQMhE20s2m7Ssv/6PvWpUUvqyWe93cTXi9 7+Ss+v8J7b0XEyX9qIF27pJJI48SSweB0LwnT3eEKK/cri79Ii4WF/t9vPLVmvX0 fVdW5qHshgs7IxjAgW0Pyk3jOMW8gJvpiwjbm3XnpN07gDG3a0ZPm6KGBvG87jUx 39PEsknYR+ByJh9zV802ZSLYsXRlBjTiQagYUFJCpVSoopcizFLXAov3CcAHQ7QA ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Z1n5sK S3S0hvLRYtxwh0dVTc36WQi5e3nsQIn0tGGBY=; b=Aq614TR/Ko6QephgUosCIt JiD7muf6KIUXnhKljgkW4+B7LZcP8sDYGx0nruCpIaJ4w6lPRHftWjhfuiqJRgjP nhnQcjJcdItFFKQ2aZqm0fHz4/YUC5Wc2isz1Xqnc0WU6yFlJyArkCXiPQlDOXGz ynQ/8ELS+6jM8pmYaoxD5xUAkvcphv0vqwxuN1bupp9EheHyoE8tej+CUS6NVu3z umO/RCvLVK4TlqKX6vyHZkAqpLlg3Mk7GOgFLJ0tdiK4z8IeFkvufQspR7bU/hW2 40+EyurVSuEHIhQDxk9FbJA5WlGx9JRx3WQHb0SrldgexanVDTRPZvaoXzraanug ==
X-ME-Sender: <xms:rZiXWSRgQSqVlp7HtMWNaZ6Y-cuzLYQ1qBrwRIDfb1Vf3pkv1y565Q>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0F2FCBAB71; Fri, 18 Aug 2017 21:47:25 -0400 (EDT)
Message-Id: <1503107244.2691235.1078169016.1D12AE95@webmail.messagingengine.com>
From: Bron Gondwana <brong@fastmailteam.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>, Brandon Long <blong@fiction.net>
Cc: dmarc@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_150310724526912352"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-21c69044
In-Reply-To: <CAL0qLwbOZ2VPYG=MLhSnHWZmbhZSuN0gU2E4rcQeL2ZfRSqdYg@mail.gmail.com>
Date: Sat, 19 Aug 2017 11:47:24 +1000
References: <1502083287.2191248.1065195288.7CDC7FF3@webmail.messagingengine.com> <CABuGu1oTMbuLd4yTwecu5sKFnsmH+HiwT1FG=JpySYHzpMTx_w@mail.gmail.com> <1502200759.3946686.1066841264.607B4D0B@webmail.messagingengine.com> <2720431.u3G7bbkkxK@kitterma-e6430> <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com> <a08c7590-ded3-1642-4ffc-07848b3c6cd2@gmail.com> <e14f2130-6f00-4ef1-485b-850a4cc1c48c@gmail.com> <1502495646.4099176.1070896040.2B09B1F8@webmail.messagingengine.com> <166070f0-4ba1-70da-1f73-885b4a7f7640@gmail.com> <1502497178.4103451.1070917304.23DD466D@webmail.messagingengine.com> <598F9484.7020700@isdg.net> <CABuGu1p=oLfLRkuoaDHoz3Cv3_FrURdsFPzkac7jNzBpqBmiSg@mail.gmail.com> <599484FB.9050908@isdg.net> <1502929303.4038704.1075868960.5D80A788@webmail.messagingengine.com> <CAD2i3WN_bmDgmQBw3pnyu7vWJJM2Kzwgru87VhK=NA_H91B+og@mail.gmail.com> <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com> <CABa8R6uhV9Bs42rgUGTSetBDDFmFPOhiYa6Yuqny0gv6dT3-Kg@mail.gmail.com> <1503006397.1306110.1076933224.154E25D6@webmail.messagingengine.com> <CABa8R6tE7E=eEnyzfhw-veD__O4FG1s8Xf7aokjfwTFmSEzTaQ@mail.gmail.com> <CAL0qLwbOZ2VPYG=MLhSnHWZmbhZSuN0gU2E4rcQeL2ZfRSqdYg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/vFBbPLP3rV7DnAZt5vy6LdsK2n0>
Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Aug 2017 01:47:28 -0000

On Sat, 19 Aug 2017, at 11:43, Murray S. Kucherawy wrote:
> On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long
> <blong@fiction.net> wrote:>> We went down the path of including a diff of the message in the
>> headers, but you run up against more complicated changes that make
>> that challenging.  Ie, mailing lists which strip attachments.  If all
>> we cared about were subject munging and footers, there probably would
>> have been a practical solution there.> 
> I wrote a draft a while ago that would allow a DKIM-Signature to
> include an annotation indicating that the signing ADMD did one or more
> of a specific set of small but well-defined message changes (e.g., add
> a footer, add a Subject tag).  Knowing what those are, a verifier
> could undo them and attempt validation of earlier signatures in the
> handling chain.  Presumably if no other modifications were made, the
> original content is thus discoverable, and you could then produce a
> chain of custody of the actual content before you that makes sense.> 
> If that's worthy of consideration now I could certainly revivify it.

That seems really valuable to me.  Being able to track the provenance on
individual parts of the message payload is a much stronger way to
determine who is at fault when bad content is being injected than just
knowing some bits of the message handling chain.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com