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

[Tero Kivinen <[e-mail]>]

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.

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.

The comment about the positive caching and low TTL is actually very
good, and I missed those when reading the document myself.

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

> > ----------------------------------------------------------------------
> > In section 4:
> > 
> >       only.  To construct the actual address to which the report is
> >       sent, the Verifier simply appends to this value an "@" followed by
> >       the domain whose policy was queried in order to evaluate the
> >       sender's ADSP, i.e., the one taken from the RFC5322.From domain of
> > 							^^^
> >       the message under evaluation.  Therefore, a signer making use of
> >       this extension tag MUST ensure that an email address thus
> >       constructed can receive reports generated as described in
> >       Section 6.  ABNF:
> > 
> > 
> > It seems there is extra . between the "RFC5322" and "From".
> 
> 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. 
-- 
[e-mail]