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

Bron Gondwana <brong@fastmailteam.com> Thu, 17 August 2017 00: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 F1EC313239E for <dmarc@ietfa.amsl.com>; Wed, 16 Aug 2017 17:47:40 -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=F9IiPZRp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ca7pOyBu
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 cKRBcIemKjVI for <dmarc@ietfa.amsl.com>; Wed, 16 Aug 2017 17:47:39 -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 1533D132386 for <dmarc@ietf.org>; Wed, 16 Aug 2017 17:47:39 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7E10E21236 for <dmarc@ietf.org>; Wed, 16 Aug 2017 20:47:38 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 16 Aug 2017 20:47:38 -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=B+6VDPHxLa07LOMLt Q2Lg+hdubQy5viqDjXHBPKdLhY=; b=F9IiPZRplRrSjnl8C+YKvnfr2U7cqbWKH h5Uex0XZlUgbPAe7+8ZJBQwnDOXUEInWO1iAbNk7YB/RP7GF1v5q8G30dM/G2qaS W4euOTX67AHunsBW9u2V6whitwiRGhMzZEJNlFDQLE0lDP52RJZ8be3uzV5SiByd v8BqhdCpsIu2P1sgTnbcrj/QhuHW9lpj408vnzyS6DM/6R7GRSn1i+Sj1ig/90YT uzSXyNq9bAaT0Z3ncLDQDsTnoOYIfOJ3V/VEO1Vse7xmUV8/TkyW62CUrBe+Qr9N kb8BjkqjbOzOCZBd/Q0C0AaI/JiwHbg/Rm2tTJiJk+sxh4aXLYWCA==
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=B+6VDP HxLa07LOMLtQ2Lg+hdubQy5viqDjXHBPKdLhY=; b=ca7pOyBuGNy2SwYjMQ57FT jMDXwJSSaImG6Cz3KF+9SiH7xa6YRZApUg39Fubg3cmGmMTqBftdHudaD1XKhkt6 h1gtDB+l1v72nug79EZOunQ2fWQ7duYxHL2D3Zx9Be9NRmLCJKluBwLY7v80EtLa ygxU75IMgQLLW5pqPlxXbPnn7f/pPL6Ak9VVuil4fgeHy/mUaYD+M1LjoM7FrG4v 6ArRWXGVvdPcDr+K1E5svkCdjxL1nU8hYBAWGEyFnYzyZXzc4QwlFhTVQ1wO+D2C lx3ohFgSnR69+6zCeeswNT6BrvBZ8NAXJrjAxmBbaSgbSlfuwF0lq4SuiqGhlpvw ==
X-ME-Sender: <xms:queUWUv16LtcHnX7EIEE_FV3NyzNakDleuhz4fu0x-87VPxxJ9ljVA>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4BDCB9E2B5; Wed, 16 Aug 2017 20:47:38 -0400 (EDT)
Message-Id: <1502930858.4042926.1075890568.5069945B@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="_----------=_150293085840429260"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-42cf1507
In-Reply-To: <CAD2i3WN_bmDgmQBw3pnyu7vWJJM2Kzwgru87VhK=NA_H91B+og@mail.gmail.com>
Date: Thu, 17 Aug 2017 10:47:38 +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>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/DbPCvMotwrYVrdnjP95MqR7YRik>
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: Thu, 17 Aug 2017 00:47:41 -0000

On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote:
> On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana
> <brong@fastmailteam.com> wrote:>> The only way you could even hope (as a mailing list) to avoid
>> rewriting the sender is for every site that currently has DMARC
>> p=reject to change that to a new policy which explicitly means "only
>> reject if no ARC chain" - otherwise you can't stop rewriting sender
>> until you know that every receiver on your list is ARC-aware.> 
> I don't understand your point.

If you are a mailing list and you receive a message from a domain with
DMARC p=reject, you can't send that message on to the members of your
list without rewriting the sender.
> The only way DKIM works is if enough receivers validate it.
> 
> The only way adding elliptic curve to DKIM works is if enough
> receivers validate it.> 
> The only way a DMARC policy works is if enough receivers validate it.> 
> ARC is the explicit solution to mailing list breakage with DMARC.
> But, as with all other IETF RFCs, only works if enough receivers
> validate it.> 
> Our job is to make sure ARC accomplishes its goals under the DMARC
> charter, and demonstrate value to receivers that it's worthwhile to
> implement.> 
> There will always be a ramp up and implementation phase, that is a
> feature, not a bug, and not a reason to say "it won't work."
While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject
aware, you can't use ARC on a DMARC p=reject domain without rewriting
the sender.  Otherwise that site will bounce the email.
You still have to rewrite the sender until there is either full adoption
or sufficient adoption that you just don't care about the stragglers.
ARC doesn't solve that unless every receiver is either ARC-aware or DMARC-
unaware.  Hence the suggestion that I think Hector is making - to define
a new policy p=rejectnonarc or something, which means that sites which
are ARC-unaware accept rather than reject.
Bron.


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