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

Brandon Long <blong@fiction.net> Fri, 18 August 2017 00:22 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 64CCD1323A0 for <dmarc@ietfa.amsl.com>; Thu, 17 Aug 2017 17:22:55 -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 (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 NkK7heRIA6aV for <dmarc@ietfa.amsl.com>; Thu, 17 Aug 2017 17:22:52 -0700 (PDT)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 B866D132396 for <dmarc@ietf.org>; Thu, 17 Aug 2017 17:22:51 -0700 (PDT)
Received: by mail-ua0-x234.google.com with SMTP id f9so30419486uaf.4 for <dmarc@ietf.org>; Thu, 17 Aug 2017 17:22:51 -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=K4Yheyqi00PcRFe2WVsFATjqqlQB+PjqhwUKThxNtQM=; b=DRpY4B2N8RNV+ot0b/xDS766KyfY1aQOwNMBB8WKY/JUrh5ccPbU5un8Bz+hKjzG3o 2rWlUY0kQL6iW2YhjHcgBPaDcNsKwxtB7y/HwQ6UVPmSEHIjbkrVJTVo8TN7wdgBgSCW GJhDefi1mHVV7FOe+GgnxtMMwr7cynki2fidzNGOTpnRINGy5depUc11SKtCxPb/5Nzh NJ1ASZ9QnjZgwm2IKQDbSTCUzS/wpGIx3LF7TFQJpsQAYlmh9cXrI04LaM/+K3DhrPaE OCLew21OEAGCcn78AAbTWDfLjT3XW9oh9ATLbvS5fw4dLqzbZsAic5SqLnrHtwL4fmqe jXTg==
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=K4Yheyqi00PcRFe2WVsFATjqqlQB+PjqhwUKThxNtQM=; b=QOn69nOP3ycPelk6f3CzBj5TZX1J1HhBvmxDYtWzR+XGxQ83484fBsoOah0//6RtRD iHBovcwVcFEQ/3xf/ojY6AJ8Oys2lW2HqOyvtyqtv3R6Wn3w2a+xoROvGh/QbvvSIXnk IRBKMZgaU7bIsvSohR4Upgv17KzlnbQxx/8/pAUfV+FXYEQaFlQYVtUHywe18tKIS+lB 2zYiHrs9oGx+ozLuLwQgdIWmzlHXKoBs+THQBn+gsy5BYMSVED45mTD3zj7L+f48JJII fqgbeWKUvLwijCI79qRXNDX6ne+swlNzT4XXqvi9DtmGaKlOc02xpaghwVYehbI7y0Ce 2YAw==
X-Gm-Message-State: AHYfb5iFzZ9CGnXC5k5CNM9DTr2Fq7xQtqt+6qLdr7J1pCbTjo4Y5MaI iEyZSpE1hprF3OyWaT0=
X-Received: by 10.176.2.68 with SMTP id 62mr4904780uas.202.1503015770695; Thu, 17 Aug 2017 17:22:50 -0700 (PDT)
Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com. [209.85.213.52]) by smtp.gmail.com with ESMTPSA id d16sm1020334uag.10.2017.08.17.17.22.49 for <dmarc@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 17:22:49 -0700 (PDT)
Received: by mail-vk0-f52.google.com with SMTP id j189so27702539vka.0 for <dmarc@ietf.org>; Thu, 17 Aug 2017 17:22:49 -0700 (PDT)
X-Received: by 10.31.120.12 with SMTP id t12mr4610979vkc.29.1503015769381; Thu, 17 Aug 2017 17:22:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.135.139 with HTTP; Thu, 17 Aug 2017 17:22:48 -0700 (PDT)
In-Reply-To: <1503006397.1306110.1076933224.154E25D6@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> <CABa8R6uhV9Bs42rgUGTSetBDDFmFPOhiYa6Yuqny0gv6dT3-Kg@mail.gmail.com> <1503006397.1306110.1076933224.154E25D6@webmail.messagingengine.com>
From: Brandon Long <blong@fiction.net>
Date: Thu, 17 Aug 2017 17:22:48 -0700
X-Gmail-Original-Message-ID: <CABa8R6tE7E=eEnyzfhw-veD__O4FG1s8Xf7aokjfwTFmSEzTaQ@mail.gmail.com>
Message-ID: <CABa8R6tE7E=eEnyzfhw-veD__O4FG1s8Xf7aokjfwTFmSEzTaQ@mail.gmail.com>
To: Bron Gondwana <brong@fastmailteam.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1495960745c70556fc21b0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/lhoMiJnm4qsrsGDCu4J9T55uxiM>
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 00:22:55 -0000

On Thu, Aug 17, 2017 at 2:46 PM, Bron Gondwana <brong@fastmailteam.com>
wrote:

> On Fri, 18 Aug 2017, at 05:11, Brandon Long wrote:
>
> dammit, posted from the wrong address again...
>
>
> You'll be dealing with this until the bulk of mailing lists AND receivers
> have become ARC aware, so you've got a while to get used to changing which
> address you post from :p
>

The bulk of mailing lists I deal with are rewriting From headers, IETF is a
special case.

> 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.
>
>
> I've thought quite a lot about that as well.  I would love if most mailing
> lists included enough data to reconstruct the original DKIM-passing message
> again, so the receiver could actually know the diff from the original
> message and scan it separately.  That way you could very easily know
> whether the source of any objectionable content was the mailing list or the
> original sender.
>

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.

> 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)
>
>
> I kind of buy that.  I'll be interested to see how it pans out in practice.
>
> 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.
>
>
> As someone just about to launch a new mailing list product, we will be
> from-header rewriting for DMARC p=reject domains for at least a little
> while, and likely building something horrible which attempts not rewriting
> for individual recipients and keeping a whilelist to see if they don't
> reject.  Though if someone is just dropping messages, we would never know -
> it's a horrible uncertain situation as the site in the middle, because you
> don't know how the message will be handled downstream - it depends on
> whether the recipient supports ARC, and you can't know that for sure.
>
> That's the big that makes me uncomfortable - ARC is defined in such a way
> that certain participants are unsure of whether they can safely keep
> sending legitimate email and have it accepted, because the interaction with
> DMARC is defined in such a way that ARC *changes the behaviour of DMARC*
> in a non-backwards-compatible way, and we will be running, for at least a
> while, in a world in which some recipients treat DMARC the old way
> (non-ARC-aware) and some treat it the new way.
>
> So your only possible mitigation as the middleman, if you want full
> deliverability, is to modify the message in such a way that DMARC no longer
> applies to it.
>

Yes.

Brandon