> -----Original Message----- > From: Dave CROCKER [mailto:dhc@xxxxxxxxxxxx] > Sent: Saturday, December 03, 2011 10:38 AM > To: Murray S. Kucherawy > Cc: ietf@xxxxxxxx > Subject: Re: Last Call: <draft-kucherawy-dkim-atps-11.txt> (DKIM Authorized Third-Party Signers) to Experimental RFC > > > 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.) I'm a little worried about using this kind of language in something Experimental when referencing a Draft Standard. My understanding is that the former can't formally modify the latter. So instead of "This specification modifies", I'd be comfortable with "This experimental specification proposes a modification to", or suchlike. Should it earn its way up to the Standards Track, your wording would be adopted. > 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 OK. > { 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. } I would agree, but in fact when ATPS is in use there are at least two ADMDs and there may be multiple signers involved for a single verifier, so the plural seems more illustrative here. > > 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 ascribes semantics that are discussed later. This section is really trying to describe the potential audience first, leaving an actual description of the mechanism for later. So I'd prefer a merge of the two, something like: <t> A Verifier participates in this protocol if it wishes to ensure that a message bears one or more signatures from sources authorized to sign mail on behalf of the ADMD, and identify for special treatment mail that meets (or does not meet) that criterion. It will do so by treating the signer's authorization on behalf of the author's ADMD as meant that the signer's signature is equivalent to one affixed by the author's ADMD. </t> > 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. OK. > {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. } Done. > 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. If you are using ATPS, sure. So ATPS augments DKIM's semantics if you're using it. But I don't think it's reasonable to say this is any kind of update to DKIM itself, at least not in the way the IETF uses the term "Updates" as it refers to RFCs. At any rate, I think this draft already does make it clear that it's doing something quite beyond what DKIM itself does. > And while we're in Section 5 (DKIM): the SHOULD needs to be a MUST. Why? The implementation might know something about the third-party that renders it suspicious even if it otherwise trusts the author domain. In the same way that DKIM avoided requiring specific handling of a message with (or without) a valid signature, I believe this one should avoid forcing one's hand if other information is available. > 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. Why wouldn't both the third-party domain and the author domain both be presented for evaluation? > 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?) I think my answer here is the same as it is for Section 5: If the Verifier knows something about the third-party or the author domain that gives it pause about considering the two equivalent, we shouldn't proscribe the use of that information by making these into MUSTs. > 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. In addition to them being listed as references? That seems a bit like overkill. > > 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. The Author's ADMD has to add a TXT record to its DNS whose construction is based on a digest of the third-party's name. The third-party signer has to know which digest is used, because this will be indicated as part of the signature. Thus, they must agree on which digest is in use. > > 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. } OK. > 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. This is discussed in Section 9.1. > > 7. Experiment Process > > Kudos for including this section. Credit where credit's due: It was Sean Turner's idea. > > 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... OK. > 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... I'm fine with "controversial". > 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. Section 3 does cover this, but I'll augment the Introduction accordingly. -MSK _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf