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

[Aaron Stone <[e-mail]>]

[Text clipped to replied-to sections only]

On Fri, Mar 16, 2012 at 10:42 AM, Murray S. Kucherawy <[e-mail]> wrote:
>> -----Original Message-----
>> From: Aaron Stone [mailto:[e-mail]]
>> Sent: Friday, March 16, 2012 4:11 AM
>> To: [e-mail]; [e-mail]
>> Cc: The IESG
>> Subject: APPSDIR review of draft-ietf-marf-dkim-reporting-15
>>
>> Document: draft-ietf-marf-dkim-reporting-15
>> Title: Extensions to DKIM for Failure Reporting
>> Reviewer: Aaron Stone
>> Review Date: 3/15/2012
>> IESG Telechat Date: 3/15/2012

--
>> Please add a note about DKIM selectors. The name "_report._domainkey"
>> is in the same namespace as RFC 6376, Section 3.1 Selectors, which take
>> the form, "yourselector._domainkey". This effectively states that a
>> domain implementing both strategies MUST NOT use "_report" as a
>> selector, because of this requirement of the algorithm described in
>> Section 3.3:
>>
>>    3.   If the DNS query returns anything other than RCODE 0 (NOERROR),
>>         or if multiple TXT records are returned, terminate.
>
> A selector, per RFC6376 Section 3.1, is a set of "sub-domain"s concatenated by periods.  A "sub-domain" is defined in Section 4.1.2 of RFC5321 in a way that disallows underscores.  There's therefore no overlap.

Of course! I've been using service records so much lately that I
lapsed on the whole point of using "_".

--
>> Section 2.4 - report generator has an awkward use of "also". Remove the
>> world "also":
>>
>> OLD
>>     ... also designed to ...
>> NEW
>>    ... designed to ...
>
> Actually the intent there is to indicate this is a slightly atypical Verifier in the DKIM sense; it's a DKIM Verifier that also has a report generation capability.  I'll say that explicitly.

Sounds good.

>
>> Section 3:
>>
>> OLD
>>    A domain name owner employing [DKIM] for email signing and
>>    authentication might want to know when signatures in use by that ought to be
>>    verifiable with specific public keys are not successfully verifying.
>>    Currently there is no such mechanism defined.
>>
>>    This document adds optional "tags" (as defined in [DKIM]) to the
>>    DKIM-Signature header field and the DKIM key record in the DNS, using
>>    the formats defined in that specification.
>> NEW
>>    A domain name owner employing [DKIM] for email signing and
>>    authentication might want to know when message recipients are unable
>>    to verify a message due to problems in the keys published for a domain.
>>    Currently there is no such mechanism defined.
>
> This isn't quite right, because there could be no problem with the keys, but rather message alteration in transit that the signer wants to know about.

I had a hard time understanding what "signatures that ought to be
verifiable with specific public keys are not successfully verifying"
refers to. It's not bad, just a little confusing at first. I don't
object to your original text.

--
>> Section 3.2: Confusing use of "tags" and "tokens". Edited to use "tokens".
>> HOWEVER - maybe the word "values" would be better?
>
> I used "tags" in this context to refer to the left half of "a=b" objects; "tokens" are the elements in a list of values.

Sounds good.

--
>> Section 4: Confusing language, similar edits as intro to Section 3:
>>
>> OLD
>>    There also exist cases in which a domain name owner employing [ADSP]
>>    for announcing signing practises with DKIM may want to know when
>>    messages are received without valid author domain signatures.
>>    Currently there is no such mechanism defined.
>>
>>    This document adds the following optional "tags" (as defined in
>>    [ADSP]) to the DKIM ADSP records, using the form defined in that
>>    specification:
>> NEW
>>    A domain name owner employing Author Domain Signing Practices [ADSP]
>>    may also want to know when message recipients are unable to verify
>>    a message due to errors in the ADSP records.
>>    Currently there is no such mechanism defined.
>
> This is also not quite right.  The intent is to allow reporting of messages that fail ADSP checks even when there aren't errors in ADSP records.

Ok, my misunderstanding. Original text should remain, though "There
also exist cases in which" could be removed :)

--
>> Section 4: remove this sentence, it's not particularly useful?
>>
>>       ... An exception to this
>>       might be some out-of-band arrangement between two parties to
>>       override it with some mutually agreed value. ...
>
> The IESG lately likes to see example cases where one might go against the admonition of a SHOULD NOT, so I think it's reasonable to leave in.

Ok.

--
> Thanks for the review!

Most welcome! Per Pete's note, I apologize for mixing minor technical
comments with wordsmithing nits.

Aaron