Re: [apps-discuss] APPSDIR review of draft-ietf-marf-dkim-reporting-15

[Aaron Stone <[e-mail]>]

On Fri, Mar 16, 2012 at 11:18 AM, Pete Resnick <[e-mail]> wrote:
> Hi Aaron,
>
> Thanks for the review. Murray has addressed many of the issues, but I had a
> few questions:

I realized that I mixed together some wordsmithing nits with minor
issues. Sorry about that, and thank you for calling it out.

>
>> === Minor Issues:
>>
>> Introduction:
>>
>> UPDATED
>>    DomainKeys Identified Mail [DKIM] introduced a mechanism for message
>>    signing and authentication.  It uses digital signing to associate a
>>    domain name with a message in a reliable manner.
>>    The verified domain name can then be evaluated before
>>    the message is delivered, e.g., checking advertised sender
>>    policy, comparing to a known-good sender list, submitting to a
>> reputation
>>    service, and so on.
--
> That's an awful lot of rewrite and, even though it's in the intro, I am
> worried about introducing something that the WG would not agree with. What
> about the current text are you trying to clarify? Is there something wrong
> with the current text, or is this just a stylistic change? Similary below:

Mostly style, a little bit of understanding. In this case, I tried to
unwind the sentence so that it reads straight through.

I withdraw the proposed changes to the intro except as to remove the
parentheses.

Severity reduced to nit.

>> OLD
>>    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 name.  In the case of a record advertising the desire for
>>    authentication failure reports, the tags and values comprise the
>>    parameters to be used when generating the reports.  A report
>>    generator will request the content of this record when it sees an
>>    "r=" tag in a DKIM-Signature header field.
>> NEW
>>    When a Signer wants to receive reports of failed DKIM verifications,
>>    it adds a TXT resource record (RR) in the DNS, advertising how to
>>    notify the Signer of such failures.  The RR contains a sequence of
>>    tag-value objects in a similar format as DKIM key records, specifying
>>    parameters to be used when generating failure reports.
>>
>>    The TXT record containing failure reporting information MUST be
>>    "_report._domainkey" within the relevant DNS domains.  A report
>>    generator will request the contents of this record when it sees an
>>    "r=" tag in a DKIM-Signature header field.
>>
>
>
> Same issue (but moreso) as in the introduction. What is the clarification
> you are making or the issue that you are trying to fix?

Severity reduced to nit. This is totally wordsmithing. Here's what I
thought was important:

  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 name.
  In the case of a record advertising the desire for
  authentication failure reports, the tags and values comprise the
  parameters to be used when generating the reports.

These two sentences had low signal to noise, so I combined them into
one shorter sentence that got straight to the point.

>> Section 5: remove extra sentence
>>
>> OLD
>>    This memo also includes, as the "ro" "rr" tags defined above, the means
>> by
>>    which the signer can request reports for specific circumstances of
>>    interest.  Verifiers MUST NOT generate reports for incidents that do
>>    not match a requested report, and MUST ignore requests for reports
>>    not included in this list.
>> NEW
>>    The "ro" and "rr" tags allow a Signer to specify the types of errors it
>>    is interested in receiving reports about. This section defines
>>    the error types and corresponding token values.
>>
>>    Verifiers MUST NOT generate reports for incidents that do
>>    not match a requested report, and MUST ignore requests for reports
>>    not included in this list.
>>
>
> Again, why?

Nit. Removed the comma splice in the first sentence. Separated the
sentences because one introduces the section, and the other states
normative requirements.

>> OLD
>>    Implementers are therefore strongly advised not to advertise that DNS
>>    record except when reports desired, including the risk of receiving
>>    this kind of attack.
>>
>>    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.
>> NEW
>>    Domain owners are therefore strongly advised not to advertise the DNS
>>    records specified in this document except when failure reports are
>> desired.
>>    Domain owners ought to be prepared to receive unexpected traffic and
>> attacks.
>>
>>    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.
>>
>>    Positive caching of DNS records 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.
>>
>
> And this one too. Please explain.

The reordered paragraph was a problem, because the negative caching
had no context until a few paragraphs later when I got that the topic
was DNS caching.

Tightening up the sentences was a clarity nit.

> Nits I've got no concerns about, and some of the re-ordering and the like is
> just nits. But since you put these in the "Minor issues" section, I'd like
> to understand the issues.
>
> Thanks again for your thorough review.

Thanks for your review review! :)

Aaron