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

"Murray S. Kucherawy" <msk@cloudmark.com> Thu, 08 March 2012 18:51 UTC

Return-Path: <msk@cloudmark.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 D4B1721F861A; Thu, 8 Mar 2012 10:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.603
X-Spam-Level:
X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, 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 9xOTEn3QWeet; Thu, 8 Mar 2012 10:51:24 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A2DC621F85AD; Thu, 8 Mar 2012 10:51:24 -0800 (PST)
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Thu, 8 Mar 2012 10:51:23 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: Tero Kivinen <kivinen@iki.fi>
Thread-Topic: Review of draft-ietf-marf-dkim-reporting-11
Thread-Index: AQHM+7Jn5hDXdigsDk2cMOfl5q2RKJZd1I8ggAMhkID//73RAA==
Date: Thu, 08 Mar 2012 18:51:23 +0000
Message-ID: <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>
In-Reply-To: <20312.47947.44384.921886@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.20.2.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-marf-dkim-reporting.all@tools.ietf.org" <draft-ietf-marf-dkim-reporting.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@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: Thu, 08 Mar 2012 18:51:29 -0000

> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@iki.fi]
> Sent: Thursday, March 08, 2012 6:00 AM
> To: Murray S. Kucherawy
> Cc: iesg@ietf.org; secdir@ietf.org; draft-ietf-marf-dkim-reporting.all@tools.ietf.org
> Subject: RE: Review of draft-ietf-marf-dkim-reporting-11
> 
> Murray S. Kucherawy writes:
> > I've added this paragraph to the end of the current Security
> > Considerations "Deliberate Misuse" section (pardon the XML):
> >
> >             <t> The presence of the DNS record that indicates
> >                 willingness to accept reports opens the	
> >                 recipient to abuse by any attacker that generates
> >                 or alters signatures bearing the victim's	
> >                 domain in a DKIM "d=" tag by adding an "r=y" tag.
> >                 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. </t>
> >
> > Is that sufficient?
> 
> It is actually inaccurate, as the "d=" tag is not needed, as attacker
> can add (or modify the existing d= tag) it as needed. The attacker can
> even add DKIM-Signature headers to completely unrelated emails with
> "d=" matching the intended victim.

The proposed text above says "generates", which covers the case of deliberately adding bad signatures to messages.  The "alters" case would be someone taking a valid signature and adding "r=y" to it, optionally changing the "d=", to cause the attack.

"d=" is always needed in a DKIM signature, or it's syntactically invalid to begin with.

> I.e spambot system could add DKIM signature header to all spams it is
> sending out and put d=victim.example.com and r=y to the headers and
> cause all spam recipient seeing this kind of email to attack the
> victim.

Doesn't the "generates" case in the above text already cover that instance?

Let's try this instead, which I hope is more clear and explicit about the problem and the solution:

   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?

> > > On the other hand, even when signer requests reports to verify
> > > nobody is messing up its DKIM-Signatures the attacker can remove the "r=y"
> > > tag from the email (or the whole DKIM-Signature) and in that case
> > > the verifier do not send report to the signer (unless the Author
> > > Domain Signing Practices (ADSP) is in use, but I didn't really check
> > > whether those records are checked if no DKIM fields are found in the email).
> > >
> > > Attacker who wants to modify the emails do not want to advertise
> > > this, thus it will of course remove the "r=y", so it can fly under
> > > the radar...
> >
> > We cover that already in the "DKIM Reporting Algorithm", final
> > paragraph.
> 
> Partially yes, but I think it should also be mentioned in the Security
> Considerations section from the attackers point of view. The text in
> the DKIM Reporting Algorithm section is mostly from the Signers and
> Verifiers point of view.

I think to address this I'll move the text at the end of 3.3 into Security Considerations, where I will describe the problem from both sides.  Here's the new subsection:

8.3.  Unreported Fraud

   An attacker can craft fraudulent DKIM-Signature fields on messages,
   without using "r=" tags, and avoid having these reported.  The
   procedure described in Section 3.3 does not permit the detection and
   reporting of such cases.

   It might be useful to some Signers to receive such reports, but the
   mechanism does not support it.  To offer such support, a Verifier
   would have to violate the first step in the algorithm and continue
   even in the absence of an "r=" tag.  Although that would enable the
   desired report, it would also create a possible denial-of-service
   attack: such Verifiers would always look for the reporting TXT
   record, so a generator of fraudulent messages could simply send a
   large volume of messages without an "r=" tag to a number of
   destinations.  To avoid that outcome, reports of fraudulent DKIM-
   Signature header fields are not possible using the published mechanism.

> > Actually it's correct to strike "one taken from the", so I've done
> > that.  The RFC5322.From notation is introduced by one of the normative
> > references, namely RFC5598, so I believe it's correct.
> 
> It would be useful to put some kind of quotes around it, i.e. either
> <RFC5322.From> or "RFC5322.From" or similar so reader will understand
> it is one token, not just mistake. Also I searched that form from
> RFC5322, as that was where I expected to find it, so adding reference
> to [RFC5598] at this point would help a lot too.

Fair enough, but I prefer to have references like that, which introduce notational conventions, up in the "Definitions" section.  I'll take care of that now too.

Thanks,

-MSK