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

["Murray S. Kucherawy" <[e-mail]>]

Hi Tero, thanks for your review.

> -----Original Message-----
> From: Tero Kivinen [mailto:[e-mail]]
> Sent: Tuesday, March 06, 2012 8:01 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Review of draft-ietf-marf-dkim-reporting-11
> 
> [...]
> This is all fine, but the security considerations section should really
> point out that the TXT record is the only part that is really
> protecting the signer from distributed bogus reports. Even if signer
> does not ever put "r=y" tag in any of the messages, but still publishes
> the TXT records "just in case" they ever want to get those reports, the
> attacker can modify every single email in transit to include bogus
> DKIM-signature field with "r=y" and "d=" matching the signer and DKIM
> verifiers will start flooding reports to the signer.
> Note, that those emails do not even need to be originally have anything
> to do with the domain being attacked.
> 
> Actually just adding "r=y" to valid DKIM-Signatures will cause the
> signature to fail (if I have understood things correctly), thus
> triggering the report.
> 
> So the only way the signer can protect himself against bogus reports is
> to remove the TXT records from the DNS. There should be text about this
> in the security considerations sections, as otherwise adminstrators
> might put those TXT records out there just in case they are needed, and
> open themselves to the attack.

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?

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

> ADSP is not spelled out ever, and the reference to the RFC5617 uses
> different title than what is the actual title of the RFC5617:
> 
> 	"DomainKeys Identified Mail (DKIM) Author Domain Signing
> 	Practices (ADSP)"
> 
> 	vs
> 
> 	"DKIM Sender Signing Practises".
> 
> so it was bit hard to see what ADSP actually meant, until I actually
> checked the RFC5617. I am not sure why the references are getting wrong
> titles, as shouldn't the
> http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml
> references get those directly from RFCs. On the other hand it might be
> the references are written out manually...

They are, and actually it seems it was imported from a much older document.  ADSP went through several name changes in its lifetime, and that's a fairly old one.  Anyway, fixed; expanded on first use, and the reference has been repaired.

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

> ----------------------------------------------------------------------
> In section 5:
> 
>    This memo also includes, as the "ro" tags defined above, the means
> by
> 				    ^^
> 
> I do not think this document defines "ro" tag, I assume it was meant to
> mean "rr" tag instead?

Yes, it was renamed during the document's evolution and I missed this one.  Fixed.

> ----------------------------------------------------------------------
> In section 5.2:
> 
> How can DKIM ADSP failures ever report "d" type errors, as if they have
> DNS issues for fetching ADSP records, they will not get the "rr"
> tag saying "d" or "all" types should be reported...

It looks like that was copied from the DKIM reporting flags without realizing this discontinuity.  I'll remove it.

Thanks again,
-MSK