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

[Tero Kivinen <[e-mail]>]

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document adds a way to DKIM verifier to send reports to the DKIM
signer when something goes wrong with the signature verification.

It provides two fold authentication to verify that signer has really
requested the reports to protect signers from bogus reports: The
DKIM-Signature field of the email in question needs to have tag "r=y"
to indicate signer wants to see reports, and the _report._domainkey
subdomain needs to have TXT record which also indicates that signer
really wanted these reports.

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.


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

The proposed Extension to the DKIM-Signature tag does not really
protect or detect against attacks, but it might be useful for
debugging and detecting misconfigurations in the system.

I think the DKIM-ADSP extensions are more useful for detecting
attacks, as those will be checed even when there are no DKIM-Signature
fields in the email (at least I think so, as otherwise they could not
report "unsigned" messages.

----------------------------------------------------------------------

There is also some smaller issues:

----------------------------------------------------------------------
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...
----------------------------------------------------------------------
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".
----------------------------------------------------------------------
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?
----------------------------------------------------------------------
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...
-- 
[e-mail]