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

Brandon Long <blong@fiction.net> Thu, 17 August 2017 19:11 UTC

Return-Path: <blong@fiction.net>
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 2F95213237B for <dmarc@ietfa.amsl.com>; Thu, 17 Aug 2017 12:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level:
X-Spam-Status: No, score=-2.199 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_SORBS_SPAM=0.5, 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=fiction.net
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 hxnO1_zFiLkY for <dmarc@ietfa.amsl.com>; Thu, 17 Aug 2017 12:11:11 -0700 (PDT)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 669EC13214D for <dmarc@ietf.org>; Thu, 17 Aug 2017 12:11:10 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id d124so25613730vkf.2 for <dmarc@ietf.org>; Thu, 17 Aug 2017 12:11:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lgG69PeYJI4Vk+E+ssPEPx6UI/xlY9Yx7JY+NDan2Bg=; b=fblD7MZfY//jtPMn2QcGqGUe3tVI5NC8tyFMsP5oAdY51W0yBUolN00O0uPTNDL5gu FSFxzncwqqTJ7uIsnTIfWcsJyiDE3jtcqAZ3Y4VjkLqb1aI6kIaujO95C3gWNHuicxWb O/629JJRm2mLrh6KoTZtL0+FeExqZ1hKVuDzYsQpclEvcnsHDM1gmIVp/c74mEPFqbnJ igBi1JqIVfx8romYCwfnwqJm/WaOSzYyXtSMV23HxuJwYEXrUfEMhUCVJ+EvBXF8ybjz 6ewHHC0kFFM22+THN/y2qb+6BgXCgCxRtbCM29CWwRiekgs0tl8DodZ1ntklAoZ/oWtS CTCQ==
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=lgG69PeYJI4Vk+E+ssPEPx6UI/xlY9Yx7JY+NDan2Bg=; b=iWPQdnNVCLX/91r7YFd5SDeXyiVM8K8SWeeacoJF4n5G3oWMmP91o/fveh+W9OKI9Z Xc9U6dcRjswBMaz/E6aIQzlZc58OkdYs7+1aPR951msvuGJlON1vJ4rTbxfRXlpWVik1 gTeRu+9Y6mHPePPYLoI7Cgy4Zx9Mm9g690MWEVlom4zDTTuNwR07hgm3Cm83ssEALj6a 1wGEAhB3INGl93WWouh0xBUxc6bvZJ7AiDTN6yFDM7+j5DnayvxCYtH0cmAnmpBfQZ+g 7ZygB+KmHXDp302dCtYg97wgeQOvlqFGt+GoCL8qBGjiU2NHUVab6y+dqa6wJpAvXLN0 IZMw==
X-Gm-Message-State: AHYfb5iOc+tzJzYxdZuBkjs/aFOzq3qikSBDboCSAzxw8xeVT8oQEB30 bMZTrkePA4z7VGBJBvo=
X-Received: by 10.31.242.73 with SMTP id q70mr1267330vkh.60.1502997069408; Thu, 17 Aug 2017 12:11:09 -0700 (PDT)
Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com. [209.85.213.44]) by smtp.gmail.com with ESMTPSA id 195sm824604vkv.33.2017.08.17.12.11.08 for <dmarc@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 12:11:08 -0700 (PDT)
Received: by mail-vk0-f44.google.com with SMTP id j189so25590399vka.0 for <dmarc@ietf.org>; Thu, 17 Aug 2017 12:11:08 -0700 (PDT)
X-Received: by 10.31.89.195 with SMTP id n186mr4075680vkb.5.1502997067943; Thu, 17 Aug 2017 12:11:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.135.139 with HTTP; Thu, 17 Aug 2017 12:11:07 -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: Brandon Long <blong@fiction.net>
Date: Thu, 17 Aug 2017 12:11:07 -0700
X-Gmail-Original-Message-ID: <CABa8R6uhV9Bs42rgUGTSetBDDFmFPOhiYa6Yuqny0gv6dT3-Kg@mail.gmail.com>
Message-ID: <CABa8R6uhV9Bs42rgUGTSetBDDFmFPOhiYa6Yuqny0gv6dT3-Kg@mail.gmail.com>
To: Bron Gondwana <brong@fastmailteam.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="001a114e1ff256093f0556f7c675"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/CdoNc99Vj-hfR_p4cidpg_MRMlo>
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 19:11:14 -0000

dammit, posted from the wrong address again...

On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <brong@fastmailteam.com>
wrote:

> 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.
>

Theoretically, if rewriting the from header had been the "approved" way to
work around DMARC issues for mailing ilsts, one could imagine that
something like ARC could have explicitly allowed for that concept and
making it so receivers could back-sub the original From or something. That
way, ARC implementers would get immediate benefits over from rewriting.

OTOH, if you ignore from header rewriting as a solution (which many have),
then ARC implementation theoretically adds immediate benefit (or the
potential for immediate benefit, since it requires participation from both
the mailing list and receivers)

ARC definitely solves more than from header rewriting does, but from header
rewriting is certainly a much simpler solution for mailing lists... even as
it makes them slightly worse to use.

Brandon