-----Original Message-----
From: Dave CROCKER [mailto:dhc(_at_)dcrocker(_dot_)net]
Sent: Saturday, December 03, 2011 10:38 AM
To: Murray S. Kucherawy
Cc: ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf