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

Bron Gondwana <brong@fastmailteam.com> Wed, 09 August 2017 22:26 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 D710C132021 for <dmarc@ietfa.amsl.com>; Wed, 9 Aug 2017 15:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=aoKTth03; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BLdcA+Fw
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 Iq_2PBIH9Mny for <dmarc@ietfa.amsl.com>; Wed, 9 Aug 2017 15:26:05 -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 B77E7131F21 for <dmarc@ietf.org>; Wed, 9 Aug 2017 15:26:05 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1DD7C21EF3 for <dmarc@ietf.org>; Wed, 9 Aug 2017 18:26:05 -0400 (EDT)
Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Wed, 09 Aug 2017 18:26:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=nt72PH+D1hJyZcphL F9aDd6aCC90rrZbiuKmLyYVKGM=; b=aoKTth03eo3eSpsS+IataQBCIbl7Fk2P1 gR/KvsDUZ71PKEKevcsFb4ywe3zhyU63Z9oujM/FZLwfMjyJwC/6EQQ0++08PscS lwKWSmTC2y/+Rvdn3rI8r0j3/ePnxudBFuVrSfS7MlVeZmwqh9xLpJYrqLjH3aU5 +L4DLaHRSMhHPC4QPtytTe7hnPjJbBxqrtEMDkgDnZF8wYzxURMAd889S2nJKNCb iZhxNJB9dGEw7zWsL1gjPAEB/ZQi4pHxntB5+pbb/b1bhKUwaU/b6YlTPcyk58cI W3Cuej00Gzvcyk2LwF+KshXhbc6JmH+mdj9szuVC8+DFhRCGI06fA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=nt72PH +D1hJyZcphLF9aDd6aCC90rrZbiuKmLyYVKGM=; b=BLdcA+FwbDwujFCQX1xo8R igY9OlDhfk5HMVGXqUkzTrpSpCP65VEfXmBMIgGI2HqEP+jWVCdOMcYUV5OKO0G3 bDrvy8ZL/F8jrbG7Iv2228prS15hY922jn4BB5F9n8gIDrMr4kc3tXj9HnoetqEK /Ocj2F8Mi7oHtqfMQ3q9QCu8UA3RjCTf8ih2h5ZKr9OZGLGVqxvlETigWDzZ/++8 th7TKyoFuqHWgmv93el56UYIWvc/p/0vgaUMexR+Abf5NYyEB06Nd2lXmeIgMuTP ajvmmHWzsd8EOQYoWOKYMHoYSe2efx6ID/eWrAZyb9DE8Vv57CBbXCsEkHEr+Ayw ==
X-ME-Sender: <xms:_IuLWZ1cDvc48_UEUp58oIU5eLmIsxXaAA3T4QGNpPAV_DsOALRMiA>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id D5FAE95713; Wed, 9 Aug 2017 18:26:04 -0400 (EDT)
Message-Id: <1502317564.1935379.1068588344.040173AF@webmail.messagingengine.com>
From: Bron Gondwana <brong@fastmailteam.com>
To: dmarc@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_150231756419353790"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-b56c1ff4
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>
In-Reply-To: <2720431.u3G7bbkkxK@kitterma-e6430>
Date: Thu, 10 Aug 2017 08:26:04 +1000
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/yhLSyr2YzQ9UWhhck0iOq23_sJ0>
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: Wed, 09 Aug 2017 22:26:08 -0000

On Wed, 9 Aug 2017, at 00:28, Scott Kitterman wrote:
> I think the "Once AMS doesn't validate anymore ..." argument is an
> suggestion that it's fragile, not that it's pointless.  I have
> concerns myself about the robustness of this design, but I think
> that's best addressed through deployment and experimentation.
It's not fragility, the older AMS is supposed to not validate any more,
because it's a signature over a bunch of headers and the body - any
change in those will break it.  That's fine so long as the chain of
custody exists.
My problem is that ARC-Seal only actually shows the chain of custody
back to the first bad actor.  That's also fine, because any bad actor
means the whole message is tainted and should be discarded.
The thing is - ARC-Seal and verifying every Seal only gives more
integrity than checking the previous AMS and signing your own AAR unless
this is true:
* There exists a site which correctly checks ARC-Seal and adds new ARC-
  Seals, but does not generate an accurate AAR.
I do feel like nobody understands what the hell I'm trying to say here
based on the responses I've seen so far, so maybe I do actually need to
find an existing ARC-Sealed email and forge a change to it.  Seth asked
to have a phone chat about this, and I'm happy to have a phone chat with
anybody  if it will help explain my point.
I'm not saying that the underlying concept of ARC are wrong - the idea
of chain of custody is sound.
The problem is that ARC-Seal makes claims it just doesn't deliver on -
it's not adding value, and it is adding cost and fragility (the need to
successfully do DNS fetches for every seal in the chain at every point,
plus the cost of checking that crypto) - and yet any one site can still
falsify all the earlier items in the chain.
Sadly I only have a few message in my entire mailbox that have ARC-Seals
on them.  They're from a Mozilla Thunderbird list of all things, and
they have some Google ARC headers on them.  I'd prefer to impersonate
someone from this list if I'm going to make a proof of concept to show
what I mean, but nobody appears to be sending messages with ARC headers
on them here!
Bron.

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