Re: dmarc damage, was gmail users read on... [bozo subtopic]

John C Klensin <john-ietf@jck.com> Sat, 13 September 2014 20:09 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA6F1A00D4 for <ietf@ietfa.amsl.com>; Sat, 13 Sep 2014 13:09:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.252
X-Spam-Level:
X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] autolearn=ham
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 0LveEXz9j4gs for <ietf@ietfa.amsl.com>; Sat, 13 Sep 2014 13:09:06 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B306F1A00D1 for <ietf@ietf.org>; Sat, 13 Sep 2014 13:09:06 -0700 (PDT)
Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1XStd3-000P9h-Am; Sat, 13 Sep 2014 16:09:05 -0400
Date: Sat, 13 Sep 2014 16:09:00 -0400
From: John C Klensin <john-ietf@jck.com>
To: John Levine <johnl@taugh.com>, ietf@ietf.org
Subject: Re: dmarc damage, was gmail users read on... [bozo subtopic]
Message-ID: <832617A8DFA9BF93CBDA3D97@JcK-HP8200.jck.com>
In-Reply-To: <20140913191426.3310.qmail@joyce.lan>
References: <20140913191426.3310.qmail@joyce.lan>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/NOvTA6k9gIqwnY0YjXNDgx390ME
Cc: tytso@mit.edu
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Sep 2014 20:09:08 -0000


--On Saturday, September 13, 2014 19:14 +0000 John Levine
<johnl@taugh.com> wrote:

>...
> DMARC is only useful because many crooks are remarkably lazy or
> stupid.  I've seen numbers showing that it blocks vast amounts
> of spam with From: addresses like <security@paypal.com> which
> means that a lot of crooks just uses the exact address they're
> attacking But it's not effective against stuff like this,
> which they also use:
> 
>   From: <security@paypaI.com>
>   From: security at paypal.com <boris@rbn.ru>
>...

I would have added that it provides no protection against 
    From: <security@pаypаl.com>
(the oft-cited "Cyrillic 'a'" example) either.

I think we are largely in agreement, but I think there is a
reasonable hypothesis that would substitute "lazy and
economically rational" for "remarkably lazy or stupid".  No
matter how vast the number of messages that are intercepted, the
crooks have  no incentive to adopt smarter procedures until the
number and pattern of messages intercepted hurt the bottom line.
Up to that point, they have multiple incentives to ignore DMARC
and let it trap whatever it traps.  Doing so forces us to expend
resources to adjust to a technique they know how to (mostly)
defeat and thereby lowers, however slightly, the available
resources for dealing with the next attack.  It leaves us
guessing as to what new attacks will be mounted, forcing us to
either wait and then react or to waste resources on approaches
they are unlikely to try (or will avoid trying once we've spent
the resources and deployed the solutions.

As others have pointed out, spending our resources making the
bad guys smarter is rarely a good tradeoff.  DMARC does not seem
to be a good candidate for a long-term exception.

> For that second one, remember that a lot of MUAs only show the
> comment on the From: line, not the address.

I've often wondered how many successful phishing attacks we
could stop by issuing a "best practices" statement pointing out
the risks and difficulties associated with that
address-suppression practice.   I don't know that MUA
authors/maintainers would pay any attention to us, but, if we
hypothesize that they would not, it gets much harder to believe
that plans that require MUA changes to deal with DMARC
countermeasures would be effective.

best,
    john