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

Bron Gondwana Fri, 18 Aug 2017 17:27:07 -0700

On Sat, 19 Aug 2017, at 04:10, Murray S. Kucherawy wrote:
> On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker
> <dcroc...@gmail.com> wrote:>> On 8/18/2017 10:00 AM, Seth Blank wrote:
>>>
>>> Right now, we've got deployed code that we know works and improves
>>> the landscape. Everything else is - rightly or wrongly - conjecture.>> 
>> 
>> Personal Point of order:
>> 
>>     Using an 'installed base' argument for a brand new specification
>>     that is still in development and has minuscule deployment is not
>>     appropriate, in spite of having a long and storied history of
>>     being used to resist a proposal.>> 
>>     What's supposed to happen with a proposal is an evaluation of its
>>     technical and functional merits.>> 
>> 
>>  The entire point behind bringing a nascent specification to the IETF
>>  is to get review and suggestions from a wider audience.> 
> While I would normally agree firmly with that position, my view in
> this case is softer given what I believe was consensus (I'm not the
> chair, so that's not my call officially) that we're going to go for
> Experimental status.> 
> I submit that our primary mission here per our charter is to come up
> with a mechanism that mitigates DMARC's damage to mailing lists.  The
> claim that ARC as designed over-engineers a solution seems secondary
> to me; the question we need to answer is "Can this mitigate the
> damage?"  With or without Bron's reduced design, that's the question
> before us.
Yes, this is the crux of the question.


> The "snake oil" claim may be true but it's orthogonal to that core
> question, and moreover points to the way we describe what exactly ARC
> provides ("chain of custody" is clearly not appropriate given that we
> are no longer sure what that actually covers), independent of whether
> it tells us enough to solve the question at hand.> 
> Accordingly, I would suggest we continue to deploy and experiment with
> the specification as-is, because there are implementations now, until
> we've determined that ARC as currently defined does or does not
> address DMARC's mailing list issues.  I also suggest that an appendix
> be added acknowledging that the super-crypto of ARC-Seal may be
> superfluous, and at the conclusion of the experiment we can make a
> decision about removing it and moving more toward what Bron's
> suggesting.> 
> Of course, the danger of proceeding along that line is that we do
> establish a deployed base, however small, that will be difficult to
> change later.  I don't know the answer to that question immediately,
> and admittedly I'm only going to be on the periphery of cleaning up
> whatever mess results.
Well, let's have a look at the question - can ARC mitigate the damage?
It depends what p=reject means.
Right now Brandon can't email this list with his bl...@google.com
address, because google.com publishes a p=reject record.  If the
list supported ARC, he could email this list and receivers which
supported ARC would accept the email from the list despite the
p=reject record.  Yay.
I could also take a message from the list, rewrite the subject and
content to be my own, sign it with my own key from my own domain, send
that to somebody as it if had come from Brandon, and assuming they
supported ARC, they would also accept that email, depite the p=reject
record.  Boo.
p=reject no longer stopped me sending a fraudulent email claiming to be
from Brandon with a "From:" of his official work address.
The receving site now needs to run heuristics including content analysis
and trust metrics on every hop in the ARC chain to determine whether to
accept the message.  That's fine, but we've basically mitigated DMARC
breakage of mailing lists by rolling back the meaning of DMARC p=reject.
Anyone can create an ARC seal on any email.  It doesn't even have to
have an original ARC seal on it.  Attached is an email which purports to
be from Brandon and has a valid ARC-Seal on it (assuming my code works
correctly - it adds the c= parameter now after Seth pointed out that
opendkim doesn't handle leaving it out).  Somebody from Google might be
able to tell which email I based this on (an email on Aug 9th to this
list and CCd to me which then got resent from a different address)
This will be accepted by an ARC-aware receiver unless I'm on a
blacklist, despite the p=reject.
Creating a new domain and putting a key in its DNS is pretty trivial -
so I guess the question is, what is ARC  doing other than rolling back
DMARC p=reject entirely?  We'd better think about that deeply, because
spammers/scammers sure will be.
Bron.

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

header.i=@google.com header.b=G3CJSNOC;
    dmarc=pass header.from=google.com;
    spf=pass smtp.mailfrom=bl...@google.com smtp.helo=mail-oi0-f52.google.com;
    x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net 
header.i=@1e100.net header.b=JzPbB9xE
Authentication-Results: mx2.messagingengine.com;
    dkim=pass (2048-bit rsa key sha256) header.d=google.com 
header.i=@google.com header.b=G3CJSNOC;
    dmarc=pass header.from=google.com;
    spf=pass smtp.mailfrom=bl...@google.com smtp.helo=mail-oi0-f52.google.com;
    x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net 
header.i=@1e100.net header.b=JzPbB9xE
Received-SPF: pass
    (google.com: Sender is authorized to use 'bl...@google.com' in 'mfrom' 
identity (mechanism 'include:_spf.google.com' matched))
    receiver=mx2.messagingengine.com;
    identity=mailfrom;
    envelope-from="bl...@google.com";
    helo=mail-oi0-f52.google.com;
    client-ip=209.85.218.52
Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52])
    (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
    (No client certificate requested)
    by mx2.messagingengine.com (Postfix) with ESMTPS
    for <br...@fastmailteam.com>; Wed,  9 Aug 2017 20:41:33 -0400 (EDT)
Received: by mail-oi0-f52.google.com with SMTP id f11so61750290oic.0
        for <br...@fastmailteam.com>; Wed, 09 Aug 2017 17:41:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20161025;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc;
        bh=zY6dOeP3lL/8mCwUAq9ZEU6EaMfRrz9eisb5jFNCkAw=;
        b=G3CJSNOCG9sLfnnGmry0JAs11TRpAqafvhh7jPGhl+Vh2PqGTzuc7w6pRvLydgHU7E
         Crumod4uxR3LDMKVuksWKAzDbhnzGNSha0voxk4EyTCWmput8UBYQX+lYIdsWfcCaaR4
         yPViPP1RsIhjAEFflgRbnyLvivSzIkJ6PbEsUH0NlIJdfxUII1Rplohat4u9UHyhQ7bC
         8MWNxjvFZa47Fj9vDOae8onvR8BzDWDOSrzQb2F/lvspb9OL8v1pgZwnszdBlgRoqc4D
         IKEKKFim6BzVWeUdtU69+/cwEPfudPdhwf+AyEAT2kXROYQeTDRQyK0zxIfXYMmA7hN4
         z/dA==
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=zY6dOeP3lL/8mCwUAq9ZEU6EaMfRrz9eisb5jFNCkAw=;
        b=JzPbB9xEK+LzAava8efLvk0kQWSjm9DoyROazpnNJwlpWa6LqGZaBtMtUWcng4YKpO
         npybYO06Kt6/c3umeAr1Fo6XPJFhyUSK1Bd17JkuS6+9qLSeFRf7qiVtcnCqRqg5uGV1
         ZTohyTtipjJMfARtEUfBrJUm+TAYgAh/a0//OqG1QcGGf73mOfxzcUr+R+3aoeBeJL5z
         yZ8+CP+ZhgaH9U6Hc8jkFl2r+nGDY+jpMTZJWrHfp/DKKazVLsZvq4oTEvqjAgj2K/2s
         jsnWBDJx7FYHahdFlSk8LefiZaSwXNGCUAOp/v/bZ6As8o6bATex1Sp5TvrBc8MQ5OWU
         Scsg==
X-Gm-Message-State: AHYfb5hakMnae+mLFQIlhsPp2PUS3gT6NXZYJN6PQxQ0Tpa16Qq/OMKD
    1HlBo+X7sm9plWQlTp9DvvlyWb6AVUaNqaU=
X-Received: by 10.202.184.8 with SMTP id i8mr11298846oif.266.1502325691539;
 Wed, 09 Aug 2017 17:41:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.154.51 with HTTP; Wed, 9 Aug 2017 17:41:29 -0700 (PDT)
Received: by 10.74.154.51 with HTTP; Wed, 9 Aug 2017 17:41:29 -0700 (PDT)
From: Brandon Long <bl...@google.com>
Date: Fri, 18 Aug 2017 12:41:29 -0700
Message-ID: <c2ba8r6vkw0thnagrbykz9j8yg3gsiyd11ued2yug7sjmmp2...@mail.gmail.com>
Subject: this is a fake message
To: dmarc@ietf.org
Content-Type: text/plain; charset="UTF-8"

This is a fake message

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

Reply via email to