Subject: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 21 Feb 2012 13:40:22 -0800

There are a few days left in this WGLC.  Can we see some review comments, please, even if it's just a sentence or two in support?

-MSK

Subject: [marf] REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week
From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 17 Feb 2012 12:04:20 -0800
List-Id: Message Abuse Report Format working group discussion list <marf.ietf.org>

Please provide your review comments ASAP for these two drafts, and definitely before the end of WGLC so they can be discussed if needed.

Thanks!

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 23 Feb 2012 21:47:30 +0000

One more day.  No new review comments?  We're ready to go?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, February 21, 2012 1:40 PM
To: [email-masked]
Subject: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Feb 2012 11:56:22 -0500

Dear colleagues,

> One more day.  No new review comments?  We're ready to go?

This is a late review of draft-ietf-marf-spf-reporting-07.  Apologies
for it coming late (although I did warn the chairs I'd do it today).

I have read the draft.  Overall, I believe it is in good shape.  I
have a couple questions.

First, a process issue.  The header says that this is aimed for the
standards track, and that it updates RFC 4408.  The chairs are more
experienced than I in the arcana of IETF process rules, but I think
this is going to be tricky, isn't it?

Second, in section 3, discussing rp=, the document says that a report
SHOULD NOT be generated for percentages higher than that.  Under what
circumstances is it ok to generate outside of this guidance?  Is this
a resource issue?  I don't understand when it would be ok.

Those are all my comments.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Feb 2012 12:11:02 -0500

> this is going to be tricky, isn't it?

There's a process for dealing with downrefs.  I think it's appropriate in this 
case.  AIUI whoever does the post last call writeup on the draft has to 
document for the IESG why the downreft is appropriate.  There's roughly no 
chance SPFbis will cause an impact on this specification, so it'd be wasteful 
to publish this as experimental and then come back once 4408bis is updated and 
republish the same document with a different label.

> a resource issue?  I don't understand when it would be ok.

It wouldn't be OK, but it wouldn't fundamentally cause an interoperability 
problem, so we didn't use MUST.  The worst that's likely to happen is some of 
all of your reports get routed to /dev/null.

> Those are all my comments.

Thanks,

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Feb 2012 17:22:18 +0000

Thanks, Andrew, for your reviews.  (To the WG: He did let me know ahead of time that he'd be sending a late one.)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, February 28, 2012 9:11 AM
> To: [email-masked]
> Subject: Re: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}-reporting ends in one week
> 
> There's a process for dealing with downrefs.  I think it's appropriate
> in this case.  AIUI whoever does the post last call writeup on the
> draft has to document for the IESG why the downreft is appropriate.
> There's roughly no chance SPFbis will cause an impact on this
> specification, so it'd be wasteful to publish this as experimental and
> then come back once 4408bis is updated and republish the same document
> with a different label.

Actually the reason I recommended including "Updates" is that this is supposed to mean "If you implement the older spec, you really need to also read the newer one."  It creates that forward pointer in the RFC index and on some HTML renderings of the older documents.

The specific reason for doing it in this case is the creation of the IANA registry of modifiers, which RFC4408 didn't do.  Someone that wants to make a new one but only reads RFC4408 won't know the registry exists, so it seemed the forward pointer created by an "Updates" was appropriate.

This is really a minor procedural point, however.  If the IESG doesn't like it, we can simply remove it.

> It wouldn't be OK, but it wouldn't fundamentally cause an
> interoperability problem, so we didn't use MUST.  The worst that's
> likely to happen is some of all of your reports get routed to
> /dev/null.

This is text copied from the other reporting document, as I recall.  I used SHOULD in that instance because there might be cases where one party contacts another and says, basically, "Although I advertise that I want x% reported, from you I want everything."  Thus, a private arrangement overriding what the protocol says would be a valid reason to disregard the "rp=" value.  We might want to say that, since there are people on the IESG that have specifically said they like to see examples of when one might contradict a SHOULD.  We'll save that minor thing for after the IETF-wide LC.

Thanks again,
-MSK

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2012 17:22:17 -0000

>this is going to be tricky, isn't it?

EAI moved from experimental to standards track without any trouble.
So long as there's a reasonable motivation, which there clearly is in
this case, I wouldn't expect any more pushback than we usually have
with mail security RFCs.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Feb 2012 12:49:01 -0500

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-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Feb 2012 21:04:59 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Tuesday, February 28, 2012 9:49 AM
> To: [email-masked]
> Subject: Re: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, dkim}- reporting ends in one week
> 

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.

> publication.  That was even more confusing, because it would cause DKIM
> processing to abort.  Maybe this helps:
> 

Seems reasonable.

> understanding what is meant.  (I did.)  This is also an issue in

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.

> 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.

>        or if multiple TXT records are returned, terminate.

OK.

>    5.   If the TXT content is syntactically invalid, the implementation,

Yep, this is already fixed by another report.

> 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?)

> except when?  If this is just "it's up to you", then I think the text

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.

> 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.

> 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."

>    possible using this mechanism.

Nice; I'll use that.

> Those were all my comments.  I hope this is helpful.

Very much so, thanks!

-MSK