Subject: Re: Last Call: <draft-kucherawy-dkim-atps-11.txt> (DKIM Authorized Third-Party Signers) to Experimental RFC

From: SM <[email-masked]>
Date: Wed, 30 Nov 2011 12:34:50 -0800

At 11:38 30-11-2011, The IESG wrote:

>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'DKIM Authorized Third-Party Signers'
>   <draft-kucherawy-dkim-atps-11.txt> as an Experimental RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2011-12-28. Exceptionally, comments may be

In Section 2:

   "Readers should be familiar with the material and terminology
    discussed in [MAIL] and [EMAIL-ARCH]."

The references to RFC 5598 and RFC 5322 should be normative.

In Section 3:

   "An Author participates in this protocol if it wishes to announce that
    a message from it (in the RFC5322.From sense) should be considered
    authentic as long as it bears a signature from any in a set of
    specified domains."

It's the domain and not the author which participates in this 
protocol.  As a nit, the RFC 5598 term looks more like Originator 
instead of Author.

The Abstract section uses the term "authorization" whereas 
"authentic" is used in the above text.  Shouldn't that be "considered 
as authorized"?

In Section 4.1:

   "When the Signer generates a DKIM signature on behalf of an Author, it
    MUST include an "atps" tag in the signature and include as its value
    the Author's domain name."

See above comment about originator.

In Section 6:

   "A Verifier implementing both ADSP and ATPS SHOULD treat a message for
    which the ATPS test described above passes as if it were signed by
    the author domain.  That is, a pass of ATPS means a pass for ADSP."

In plain English, this reads as an update of ADSP but this draft does 
not update RFC 5617.

In Section 8:

   "No actions are required by IANA at this time.  The following need
    only be applied if and when this specification reaches the Standards
    Track."

The IANA Considerations section is unusual.  If no action is required 
at this time, the sub-sections are not needed.  I suggest updating 
the "DKIM-Signature Tag Specification Registry" for the tags as they 
will appear on the Internet.

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Wed, 30 Nov 2011 16:03:55 -0500

> The references to RFC 5598 and RFC 5322 should be normative.

I agree; I missed that in my shepherd review.  So sorry.

> In plain English, this reads as an update of ADSP but this draft does not
> update RFC 5617.

It does not.  There's no reason that anyone implementing ADSP need pay
attention to this.  *IF* you implement this, it might change your
behaviour with respect to ADSP, but information about that is
contained here.  There's no reason for this to "update" 5617 in the
IETF sense.

> The IANA Considerations section is unusual.  If no action is required at
> this time, the sub-sections are not needed.

I did call this out in my shepherd review (see the PROTO writeup:
https://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/history/
and click "show all" on the PROTO writeup entry; side point: it should
probably be easier to get to the PROTO writeup for a document).

I actually think it's clever to put the information here in this
manner, but, as I say in the writeup, it is unusual.  I prefer that we
leave it here, and just make sure that the intelligent folks at IANA
do the intelligent thing.  This can then serve as a template for the
IANA Considerations section for a possible revision that moves ATPS to
Standards Track, should that happen.

Barry, document shepherd

---

From: SM <[email-masked]>
Date: Wed, 30 Nov 2011 13:34:19 -0800

Hi Barry,
>contained here.  There's no reason for this to "update" 5617 in the

Ok.

>probably be easier to get to the PROTO writeup for a document).

I missed that.

>Standards Track, should that happen.

Agreed.

I support publication of the draft as Experimental.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 30 Nov 2011 14:21:05 -0800

Hi, SM.  Thanks for your comments.

In reply to the stuff Barry hasn't already covered:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Wednesday, November 30, 2011 12:35 PM
> To: [email-masked]
> Subject: Re: Last Call: <draft-kucherawy-dkim-atps-11.txt> (DKIM Authorized Third-Party Signers) to Experimental RFC
> 
> In Section 3:
> 
> It's the domain and not the author which participates in this protocol.
> As a nit, the RFC 5598 term looks more like Originator instead of
> Author.

The term is more based on how DKIM and ADSP use it.  But you're right in that Author Domain is the more correct term rather than Author.  I'll change that for -12.

> The Abstract section uses the term "authorization" whereas "authentic"
> is used in the above text.  Shouldn't that be "considered as
> authorized"?

Yes, I think that's more correct as well.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 30 Nov 2011 15:01:25 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Wednesday, November 30, 2011 2:21 PM
> To: [email-masked]
> Subject: RE: Last Call: <draft-kucherawy-dkim-atps-11.txt> (DKIM Authorized Third-Party Signers) to Experimental RFC
> 
> The term is more based on how DKIM and ADSP use it.  But you're right
> in that Author Domain is the more correct term rather than Author.
> I'll change that for -12.

Actually "ADMD" from RFC5598 seems to be a good fit, so I'll use that.

Thanks again!

-MSK

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2011 02:04:12 -0000

I'm one of the authors of RFC 5617, which this document would update
if it moved into the standards track.  It doesn't seem very useful to
me, but it also seems mostly harmless so there's no reason not to
publish it as experimental.

This strikes me a hack that appeals primarily to bulk mail senders who
grossly overestimate how interested receivers are in helping them do
their mail management.  So I would be surprised if there were many
receiver-side implementations, but it's an experiment so what the
heck.

>  only be applied if and when this specification reaches the Standards

I would strongly suggest changing the IANA section so that the
DKIM-Signature tags in section 8.4 are registered when this is
published.  Tags are text strings, and I'd rather the tags it uses be
noted and reserved so that nobody uses them for something else in the
future and risks collisions.  For the same reason, it'd probably be a
good idea to register the authentication-results tags described in
sections 8.2 and 8.3.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 30 Nov 2011 20:09:06 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Wednesday, November 30, 2011 6:04 PM
> To: [email-masked]
> I'm one of the authors of RFC 5617, which this document would update if
> it moved into the standards track.  It doesn't seem very useful to me,
> but it also seems mostly harmless so there's no reason not to publish
> it as experimental.
> 
> receiver-side implementations, but it's an experiment so what the heck.

As the draft says, the point is to make the idea available and see if it sticks to anyone or anything.  If the bulk senders (or receivers) do decide they collectively want this, there's something for them to try and report back.

> I would strongly suggest changing the IANA section so that the DKIM-
> Signature tags in section 8.4 are registered when this is published.
> Tags are text strings, and I'd rather the tags it uses be noted and
> reserved so that nobody uses them for something else in the future and
> risks collisions.  For the same reason, it'd probably be a good idea to
> register the authentication-results tags described in sections 8.2 and
> 8.3.

I'd be fine with that, so long as experimental-status drafts are allowed to make IANA registrations.  (I thought they weren't, which is why it is the way it is right now.)

Thanks,
-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 30 Nov 2011 23:16:07 -0800

> As the draft says, the point is to make the idea available and see if it sticks to anyone or anything.  If the bulk senders (or receivers) do decide they collectively want this, there's something f…

if one thinks the mechanism is a bad idea, it's still worth having a good 
document to describe it.l

> I'd be fine with that, so long as experimental-status drafts are allowed to make IANA registrations.  (I thought they weren't, which is why it is the way it is right now.)

depends on the criteria for the registry.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 30 Nov 2011 23:37:47 -0800

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Wednesday, November 30, 2011 11:16 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> > I'd be fine with that, so long as experimental-status drafts are
> > allowed to make IANA registrations.  (I thought they weren't, which is
> > why it is the way it is right now.)
> 

So it does, and the registry for DKIM signature tags is "IETF Consensus", which doesn't require standards track documents to update.  So I guess the registrations could indeed be made here.  Neat.

It's a short walk from the current wording to actually requesting the IANA action.  I'll check with my shepherd and sponsoring AD for advice prior to the end of LC.

Thanks,
-MSK