On Thu, Feb 23, 2012 at 09:47:30PM +0000, Murray S. Kucherawy wrote:
> One more day. No new review comments? We're ready to go?
Dear colleagues,
This is my (late) review of draft-ietf-marf-dkim-reporting-10.
Apologies for being late, but I was unable to turn to this before
today.
I think this document is in fairly good shape, but I have some
questions and some suggestions.
First, the document says it is an extension of RFC 6376 and RFC 5617,
but it doesn't update those documents. Should it?
Next, I find Section 3.2 to start oddly:
When a Signer wishes to advertise that it wants to receive failed
verification reports, it also places in the DNS a TXT resource record
(RR) whose content follows the same general syntax as DKIM key
records, as defined in Section 3.6.1 of [DKIM], in that it is made up
of a sequence of tag-value objects.
It left me with the impression that it was modifying DKIM, but then I
understood this TXT record is independent of the usual DKIM
publication. That was even more confusing, because it would cause
DKIM processing to abort. Maybe this helps:
When a Signer wishes to advertise that it wants to receive failed
verification reports, it also places in the DNS a TXT resource
record (RR). The RR is made up of a sequence of tag-value objects
(much like DKIM key records as defined in section 3.6.1 of [DKIM]),
but it is entirely independent of those key records and is found at
a different owner name. In the case of advertising the desire to
receive failed verification reports, the tags and values. . .
The same section refers to section 3.6.2.2 of RFC 6376, but nowhere
does the target text talk about "reassembly", so someone following the
reference from section 3.2 of this draft might have a hard time
understanding what is meant. (I did.) This is also an issue in
section 3.3, step 4.
The discussion of "rp" says SHOULD NOT. Under what circumstances would
it be ok to generate reports over the percentage indicated?
In section 3.3, I'd restate this
3. If the DNS query returns anything other than a success status
code (0), also known as NOERROR, or if multiple TXT records are
returned, terminate.
as
3. If the DNS query returns anything other than RCODE 0 (NOERROR),
or if multiple TXT records are returned, terminate.
Step 5 is missing something:
5. If the TXT content is syntactically invalid, the implementation,
terminate.
I'm notoriously dumb at these things, but I don't get this in step 7:
7. If a report percentage ("rp=") tag was present, select a random
number between 0 and 99, inclusive; if the selected number is
higher than the tag's value, terminate.
100 is a possible value for rp; but 99<100. What am I missing?
What does the SHOULD in step 10 mean? That is, you have all these
conditions already; if all those happen, you SHOULD send the string
except when? If this is just "it's up to you", then I think the text
should say MAY.
Immediately after that, "advantages over previous implementations".
Of this reporting system? I don't understand; this I-D doesn't seem
to be obsoleting anything.
Item (b) of that section relies on negative caches to reduce the
deleterious effects of an attack using this mechanism. Negative
caches are not typically that long-lived, however, so I'm not sure
quite how much mitigation you get. This likely ought to be mentioned
in the security considerations, because it's yet another query. (I
don't think this is a fatal issue, but I think it needs mentioning.)
If this is what the reference in 8.2 is supposed to be, then I think
it needs to be clarified there.
Nit: the paragraph following item (c) has way too many "this"es.
Suggested alternative:
The above procedure does not permit the detection and reporting of
messages including a fraudulent DKIM-Signature header field, where
such signature did not include an "r=" tag. 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 above and continue 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 frauduleny DKIM-Signature header fields are not
possible using this mechanism.
Those were all my comments. I hope this is helpful.
Best regards,
A
--
Andrew Sullivan
[email protected]
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
