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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 12/3/2011 12:32 AM, Murray S. Kucherawy wrote:
Does a signature by this "on behalf of" signer mean something different
from a regular DKIM signature?  It appears the current text means the
answer to be yes.

Correct, inasmuch as there are some people in the community who think author
domain signatures might be more important or valuable than others.  This memo
doesn't make such an assertion, but merely acknowledges that perception.

Understood. I meant the this as a writing question; the meaning wasn't clear to me and I think it needs to be easily clear to the reader.

So I suggest for the Abstract:

   This specification modifies Domain Keys
   Identified Mail (DKIM) by allowing advertisement of third-party
   signature authorizations that are to be interpreted as equivalent to a
   signature by the administrative domain of a message's author. The supplement
   initially has Experimental status.

(I think it's important for an Abstract to summarize the core semantic.)

Also, the original text said 'originator' and I think you don't mean that, since that equates to the Sender: field and not the From: field, per RFC 5598.

I also suggest:

   3. Discussion
   ...

   o  Signers, who send mail on behalf of Authors and apply [DKIM]
      signatures using their own domains; and

   ->

   o  Signer, which applies a [DKIM] signature using its own domain,
      but on behalf of the message's Author ADMD; and

{ Stylistically, I find that specification text is easier when things are written in the singular. So I suggest author (ADMD), signer and verifier, rather than their plural form. }

and

   A Verifier participates in this protocol if it wishes to ensure that
   a message bears one or more signatures from sources approved to sign
   mail on behalf of the Author, and identify for special treatment mail
   that meets (or does not meet) that criterion.

   ->

   A Verifier participating in this protocol treats the signer's
   authorization on behalf of the author's ADMD as meaning that the signer's
   signature is equivalent to a signature by the author's ADMD.

That is, I'm pressing for having this semantic made clear more than once in the document, even though it needs formal, normative assertion only once (of course).

On re-reading, I think this also warrants an enhanced statement in the Introduction (roughly from the view that an Introduction expands on the Abstract.)

So:

   Absent is a protocol by which an ADMD can announce that DKIM
   signatures on its mail added by other ADMDs should also be considered
   trustworthy by verifiers.  This memo presents an experimental
   mechanism for doing so.

   ->

   Absent is a protocol by which an Author ADMD can announce that specific
   DKIM signatures on its mail, which are added by other ADMDs, are to
   treated the same as a signature by the Author ADMD itself.  This memo
   presents an experimental mechanism for doing so.

{BTW, the document should be sanitized of normative vocabulary that is not meant to be normative. That is, replace should, must and may with synonyms. }


   It should say this explicitly.  If it is not redefining the existing,
core DKIM semantic, it should say so.  If it /is/ changing basic DKIM
semantics, then this is more than an "extension" to DKIM.

It is not.

Thinking a bit more about this, actually, I think it is.

With a normal DKIM signature, the d= string is taken as the output to the higher-level module that then makes whatever reputation (or the like) assessment that is to be performed.

With ATPS, the requirement is to replace the d= string with the domain name from the From: field. That replacement value is then passed to the assessment module.

In other words, DKIM provides it's own identifier to be used for assessment, whereas ATPS dictates use of the From: field domain name for assessment.

That's a fundamental change in semantics.


Section 1 of this draft reiterates that DKIM's core semantics don't extend
toany kind of binding of the delivered, validated domain name to any part of the
message. However, there are some people who believe that such a binding is valid
and useful. This draft is meant for those people, without altering DKIM's base
semantics.

ack.


I suggest that the incremental semantic should merely be that the
signature by an authorized signer should be interpreted as if the
signature had been by the authorizing domain.

It's a simple semantic and is, frankly, what I think is intended, based
on the discussions surrounding this mechanism that I've heard.

This is stated in Sections 5 and 6.

Indeed, they do.

And while we're in Section 5 (DKIM):  the SHOULD needs to be a MUST.

With respect to DKIM itself, this new mechanism has one simple semantic: Use the domain name in the From: field as the output. That's not optional and that's not modifiable. If the verifier is playing in the ATPS sandbox, that's the single immutable requirement.

With respect to section 6 (ADSP), I suspect the situation is more complicated than "SHOULD" admits. The core question is what the publisher intends and the problem with the current spec is that the verifier cannot be sure.

One possibility is a simple, rigid definition of ATPS that says "if there is an ADSP record and there is an ATPS record, then the verifier MUST treat the message as passing ADSP.

If everyone agrees that this semantic is the only one to allow, then fine. make the current SHOULD in Section 6 be a MUST.

If, however, some ADSP publishers will want that semantic but others won't, then the ATPS publisher needs to publish another parameter to indicate the interpretation. (Getting complicated, ain't it?)


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

+1

The definition used for "Updates", as I understand it, is that we say "X updates Y" if someone implementing X really needs also to read Y in order to implement X completely.  I don't think that's true here.  In this case, RFC5617 stands on its own just fine without this addition.

If I should be using some other criteria for doing the "Updates", please let me know.



Other tidbits:

I haven't done an audit, but is there any vocabulary from DKIM or ADSP that is used in this draft? If so, those documents should be cited in the Definitions section.

(Complete diligence would require declaring which terms are imported, but I'd find that task onerous enough for myself that it makes it doubtful I'd dictate anyone else do it...)


4.1. Extension to DKIM
...
   For creating records in the DNS, a hash algorithm needs to be
   selected.

This needs to be motivated. Why is this being done? Why is it required to be done? Some introductory explanation will help quite a bit.


The Signer and the Author have to agree on which hash is
   to be used, since the Author places a corresponding record in its DNS
   and the Signer will have to indicate in its generated signatures
   which hash algorithm the Author is using.

I'm not easily understanding why any of this is needed.


   If they do match, the Verifier issues a TXT query to the DNS at a
   specific name looking for confirmation by the Author that the Signer
   is authorized by the Author to sign mail on its behalf.  Where

It's pretty cryptic to say "specific name" and not specify what it is.  Perhaps:

   ...at the domain name associated with the Author ADMD, as defined below...

{ actually a sub-section citation to the 'below' algorithm would also help. }


Hmmm. The hash appears to be used to generate a string that's a bit like a DKIM selector? Is this to have a single string be used for referencing the authorized domain name, rather than to have more DNS sub-tree name structure?

If so, I suppose that's clever, but is the added complexity worthwhile? I don't see why just using the plain authorized domain name -- as substructure to the authorizing domain name (separated by the _atps node) -- isn't sufficient.


7. Experiment Process

Kudos for including this section.


   The working group that developed DKIM was not convinced that third
   party assertions were critical to DKIM's success, nor were they
   likely to be immediately useful.  However, this was not based on

   The working group that developed DKIM considered a third-party mechanism
   like ATPS to be highly controversial, in terms of need and practicality and
   decided that an alternative mechanism was sufficient.  However...

I think it's important to give some sense that there was serious disagreement and that it was vigorous. Your current language might let the reader think that this merely wasn't considered very much...

With respect to the earlier discussion, I think the current draft also needs to explain that the DKIM wg decided that sub-domain delegation was sufficient.

My above text asserts the existence of an alternative. I think it needs to be explained, as well as the arguments against DNS sub-domain delegation that motivate the current spec. I actually think that discussion belongs in the Introduction.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]