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

[Tero Kivinen <[e-mail]>]

Murray S. Kucherawy writes:
> > -----Original Message-----
> > From: Tero Kivinen [mailto:[e-mail]]
> > Sent: Thursday, March 08, 2012 6:00 AM
> > To: Murray S. Kucherawy
> > Cc: [e-mail]; [e-mail]; [e-mail]
> > 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. 

Actually yes. I missed the word "generates" first. It is always hard
when the difference needs to be derived from a single word, meaning
other readers might miss the same word too, especially as the rest of
the sentence ("by adding an "r=y" tag") could be more readily
interpreted only in the "alter" case...

I think we both have seme understanding what the attack is, so the
problem is just how to express it so it is clear for normal reader of
this text... 

> "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?

Partially, but when I read the rest of it saying 'by adding an "r=y"
tag', that gave me feeling that DKIM-signature needs to be there, and
thats why I missed the word generates before. If those two cases
(alters vs generates) are separated in separate senteces I think that
might be more clear for everybidy. 

> 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?

That looks very clear and good...

> > > > 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.

I think it might be useful to point out here that this whole mechanism
does not really work agains attack, but is more useful detecting
misconfigurations or errors in setup, because of attacker can do what
is desribed above...

>    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
							  ^^^

Add reference to section 3.3 (i.e. ... in the algorithm described in
section 3.3 and continue ...). Or use single term (either procedure or
algorithm) describing it. Now you have first paragraph talking about
the procedure described in section 3.3, and then the next paragraph
talks about the algorithm with out specifying which algorithm...

>    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. 

Ok.
-- 
[e-mail]