IETF Logo Mail Archive

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

Kurt Andersen <kurta@drkurt.com> Fri, 18 August 2017 06:46 UTC

Return-Path: <kurta@drkurt.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 9829412009C for <dmarc@ietfa.amsl.com>; Thu, 17 Aug 2017 23:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com
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 tORio6lNbk6q for <dmarc@ietfa.amsl.com>; Thu, 17 Aug 2017 23:46:51 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDFE91323CB for <dmarc@ietf.org>; Thu, 17 Aug 2017 23:46:48 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id 49so53196343wrw.2 for <dmarc@ietf.org>; Thu, 17 Aug 2017 23:46:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UPsaaZ8QHNyB9me+jCqGRokY8qOvDoVB9xIQ2HyP4iA=; b=Z8lCJoeFXJGXHN+6g0J+ngtnvMEnEdIL64keMjRG7mkOe+bf2EUwvCDK+shVPq3hzZ +qEn9DEza7HcVyDeMfD22KLLRKDV0PbP4XHJACnR3LUVJacfvRi966H8j4o7Z2NjAyIw Sx3x5aM9u15yErYGVyNkADe1KJ1syOQ144DKY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UPsaaZ8QHNyB9me+jCqGRokY8qOvDoVB9xIQ2HyP4iA=; b=jGQlSk13TQkzT+19LFSocUbbs5SvuPPbj5dmF5CW0jK+n8IRBZWDVh/0pTqlQtVxQ8 FrcMIcIKUeqIqd1UzJSFnwbj6QYxKuWjQfDX26r5gTWeThV4zW3KEJH+Z91SJdgdrRGc otMcELQNFEpQXa951OF6T/Q4kYFMCg4VCA2sn5mKe4wJN87BBe+obkMEZjy8xEFqpBIk EeJg2fOVbhGTC+8oQ7ckC1QSexvLFAd6XoW5xU0cfy9DV8ftY+f0/oX/c/kvJJYyms9T oQNN1EhkqkmyS6jyvBaK3k3nC/0lwI+Hz7Qo4SQ4jK6vjFwtWyOPU+98usvkJdW4n2G+ Q11A==
X-Gm-Message-State: AHYfb5jvpCnmBjhCguYD29WRicu5B5HOEGfuiggb80Bg0QTrpk6PZytM hX1LextoRUM1h1qfnrXoBi4ept1BSaWW/pc=
X-Received: by 10.80.137.131 with SMTP id g3mr3789335edg.125.1503038807365; Thu, 17 Aug 2017 23:46:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.178.229 with HTTP; Thu, 17 Aug 2017 23:46:46 -0700 (PDT)
In-Reply-To: <1502930858.4042926.1075890568.5069945B@webmail.messagingengine.com>
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>
From: Kurt Andersen <kurta@drkurt.com>
Date: Thu, 17 Aug 2017 23:46:46 -0700
Message-ID: <CABuGu1ofdkP6Gdsfin6KfpiTJW39gXz8Fa0iAAmXfcvyWGZxdA@mail.gmail.com>
To: Bron Gondwana <brong@fastmailteam.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="f403045c2952326e480557017e44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/EWDWV14kjYoI9KdpEjncg-7HJUk>
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: Fri, 18 Aug 2017 06:46:53 -0000

So I was able to retrace our design steps which led to the 3-piece model
(AAR + AMS + AS) and the reasoning for the AS, signing just the ARC header
sequence was to provide the verifiable chain of custody trace (though, of
course, only from participating intermediaries). Some of the recent tweaks
to the spec to deal with malformed sets of ARC header fields have weakened
that original idea.

In keeping with Bron's general idea to simplify, I'd suggest that having an
AAR + [optional AMS] + AS would be a close approach for handling steps
which do not break the ingress signature. Skipping the AMS would be a sign
to downstream intermediaries that the prior DKIM or AMS was still valid
upon egress. (certain details would have to be worked out)

Does that help the conversation?

--Kurt

v2.23.0 | Report a Bug | By Email