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... -- kivinen at iki.fi