Re: [secdir] Review of draft-ietf-marf-dkim-reporting-11

Barry Leiba <barryleiba@computer.org> Fri, 09 March 2012 03:02 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08A111E8075; Thu, 8 Mar 2012 19:02:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.985
X-Spam-Level:
X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yx+5hdneneH7; Thu, 8 Mar 2012 19:02:46 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C680911E8072; Thu, 8 Mar 2012 19:02:44 -0800 (PST)
Received: by obbta4 with SMTP id ta4so1704137obb.31 for <multiple recipients>; Thu, 08 Mar 2012 19:02:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nhlRFa/PvaH1qo23LVngIMkxcqTAesSQ0RuOtCaaAAs=; b=VqtlDlaOyCr1760CyqZfx+Dqju+uRN7CRU7UZYfkGu1KggHJA3wqwOqAIhLh1kmeBC Z3EwmGe0jxkdDD8C4epao26YQzWX+/qBOWeebqyzXdtJ0PygiHmiQ3aS/kzvZMdIDJnV DNH4R52Us+yfMUF3yLqiMI/Trz0cHMOin3Q1reCNCG8jlqHVhRHIBMSRiyXulqWBSlel bpCWKm6IMGKcsg+R1j6pS2MTrO2DopeBoNmb5A0oMrxeYItIoExyZ7brm89q4xCpXQ6Q +Xxo9yx2I5u3uI3K9dV0eVydM06Q7JrkDJv3OuXQEZrhL2Nzxu+f3eY0g5rG4ez5vuIU gFYQ==
MIME-Version: 1.0
Received: by 10.182.182.101 with SMTP id ed5mr212841obc.64.1331262164455; Thu, 08 Mar 2012 19:02:44 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.60.125.37 with HTTP; Thu, 8 Mar 2012 19:02:44 -0800 (PST)
In-Reply-To: <9452079D1A51524AA5749AD23E003928080B06@exch-mbx901.corp.cloudmark.com>
References: <20310.13509.461991.185885@fireball.kivinen.iki.fi> <9452079D1A51524AA5749AD23E00392807D2D5@exch-mbx901.corp.cloudmark.com> <20312.47947.44384.921886@fireball.kivinen.iki.fi> <9452079D1A51524AA5749AD23E003928080B06@exch-mbx901.corp.cloudmark.com>
Date: Thu, 8 Mar 2012 22:02:44 -0500
X-Google-Sender-Auth: JG4kU_idqDO4fTKiVHHlj56CBo8
Message-ID: <CALaySJKie1voEVa2xtZXS5X_GnOWNUROYJB9S=pzom25tRUOsA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: "Murray S. Kucherawy" <msk@cloudmark.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-marf-dkim-reporting.all@tools.ietf.org" <draft-ietf-marf-dkim-reporting.all@tools.ietf.org>
Subject: Re: [secdir] Review of draft-ietf-marf-dkim-reporting-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2012 03:02:47 -0000

>   The presence of the DNS record that indicates willingness to accept
>   reports opens the recipient to abuse.  In particular, it is possible
>   for an attacker to attempt to cause a flood of reports toward the
>   domain identified in a signature's "d=" tag in one of these ways:
>
>   1.  Alter existing signatures by adding an "r=y" tag (and possibly
>       altering the "d=" tag to point at the target domain);
>
>   2.  Add a new but invalid signature bearing an "r=y" tag and a "d="
>       tag pointing at the target domain;
>
>   3.  Generate a completely new message bearing an "r=y" tag and a "d="
>       tag pointing at the target domain.
>
>   Implementers are therefore strongly advised not to advertise that DNS
>   record except when reports desired, including the risk of receiving
>   this kind of attack.
>
>   Positive caching of this DNS reply also means turning off the flow of
>   reports by removing the record is not likely to have immediate
>   effect.  A low time-to-live on the record needs to be considered.
>
> How does that look?

And I've now seen it in context, in the -12 version.  Some typos in
there, but we'll let the RFC Editor sort it out.

But...
You're going to hate this, but I think the copious new text in section
8.2 really wants another paragraph.  In between the three numbered
items and this:

       Implementers are therefore strongly advised not to advertise that DNS
       record except when reports desired, including the risk of receiving
       this kind of attack.

...I'd like to see an extreme-case (but a very-possible-case) example, thus:

       Consider, for example, the situation if someone should send out a
       multi-million-message spam run, and include in the messages a fake
       DKIM signature containing "d=example.com; r=y".  It won't matter that
       those signatures couldn't possibly be real: each will fail verification,
       and any implementations that support this specification will report
       those failures, in the millions and in short order, to example.com.

I don't think the text that's there lays out the scary possibilities
clearly enough.  I think something like this does.

Barry