> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Andrew Sullivan
> Sent: Tuesday, February 28, 2012 9:49 AM
> To: [email protected]
> Subject: Re: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-
> reporting ends in one week
>
> First, the document says it is an extension of RFC 6376 and RFC 5617,
> but it doesn't update those documents. Should it?
Those two documents created registries as the method of creating extensions of
them. I don't believe it's common practice both to update such a registry and
to say "Updates" in such cases. Thus, it's omitted here.
> 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. . .
Seems reasonable.
> 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.
Both these sections and the target text refer to the case of a TXT that comes
back separated into multiple "character-strings" (in the parlance of RFC1035),
and what to do in that case. I'll clarify.
> The discussion of "rp" says SHOULD NOT. Under what circumstances would
> it be ok to generate reports over the percentage indicated?
Same answer as I gave to your spf-reporting review; I'll clarify this as well.
> 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.
OK.
> Step 5 is missing something:
>
> 5. If the TXT content is syntactically invalid, the implementation,
> terminate.
Yep, this is already fixed by another report.
> 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?
I think that should be "higher than or equal to", or perhaps just "not lower
than". (Scott: Same for spf-reporting, no?)
> 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.
If the participating receiver is already using the text portion of the SMTP
reply in some way, making it MUST means the receiver has to stop doing so and
start doing what we're saying here. On the other hand, failing to do so
interferes with interoperability of what this document is trying to establish.
It seems then like SHOULD is the right way to go.
> 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.
It is in part documenting work that's already been done in this area for
several years. But you're right, it's not modifying any previous standardized
work. I can just add "pre-standardization" to that sentence and perhaps
clarify that point.
> 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.
I think 8.2 is the right place to expand on it, so I'll fold this text (and the
other information you gave me) into some new text there. How about simply
adding this:
"Negative caching offers some protection against this pattern of abuse,
although it will work only as long as the negative time-to-live on the relevant
SOA record in the DNS."
> 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.
Nice; I'll use that.
> Those were all my comments. I hope this is helpful.
Very much so, thanks!
-MSK
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
