Doug,
I'm not clear if you're saying that these comments are on parts of
the document that changed between -01 and -02, or on parts that
remained the same.
If the former, then it is fair to bring them up, *iff* your comment
is to the effect that the change doesn't match the resolution of
some specific (i.e. referenced) last call issue(s).
If the latter, then sorry, we've had last call. Everyone got their
chance to raise issues. Other cases are treated the same, unless
compelling.
Its too late here for me to check tonight, but I will tomorrow,
unless someone else on the list does that for me in the meantime
(he hinted:-)
Goodnight,
Stephen.
Douglas Otis wrote:
The results of the Dallas meeting and sections of the threat draft with
new material where not reviewed on the list. Some edits were not
expected, and the draft publication as an I-D was not available prior to
the close of the last call. This precluded review by the list.
Nevertheless, here are some comments.
Section 4.3.1 suggests that DKIM will _only_ contribute indirectly to
packet amplification and that other strategies specific to DNS must be
employed instead. When advocating an unlimited number of signatures,
DKIM's contribution to this problem is not indirect. Had this section
been open for review, it would have been prudent to list direct
contributions created by DKIM, such as use of wildcard key records,
walking label trees for policies, or provisions for unlimited
signatures. While a brief conversation occurred on the list, it would
be difficult to deduce this section was the outcome.
With respect to some of these nits, the desire is not to change the
meaning of the draft. The phrase "Affects the verification of messages"
for rating a threat impact is not well defined. There should be a
clearer term, if not classification. Signature verification is not
affected by a private key being compromised. Signature verification
offers no indications related to the message being part of a replay
abuse campaign or being signed by a stolen private key. What metric is
being measured to assess the threat impact? "Verification" does not
elucidate what is being affected and measured.
At the meeting, I acknowledged acceptance of the term responsible
instead of accountable, but asked if this was a reference to the message
and heard yes. The first statement in the DKIM threat draft indicates
DKIM is for the signer to claim responsibility for the use of some
email-address. While DKIM may provide a mechanism to claim some
verification was made in the use of an email-address, the signature
provides a far more basic function of indicating the domain handling the
message. There is no reason people must forgo use of their
email-addresses when it is not directly associated with their provider
who adopts DKIM.
,---
|1.1. Terminology and Model
|...
| The origin address is the address on an email message, typically the
| RFC 2822 From: address, which is associated with the alleged author
| of the message and is displayed by the recipient's MUA as the source
| of the message.
'---
This definition appears to be a statement of desire and not a
definition. The MUA is likely to exclude the display of the
email-address and favor the display-name. More than one email-address
could be associated with the From header field. There are no
conventions how the source of a message is communicated. This
terminology, in conjunction with the first sentence of the introduction,
expresses desire rather than definitions useful for assessing threats or
ascribing basic roles. DKIM should not require a provider add some
email-address in a header to claim control of the email-address. The
DKIM signature indicates who handled the message which provides value in
and of itself. How that information is used is independent of the
appearance of an email-address in some header. Few provider's who
employ DKIM would be wanting to claim they are responsible for the
email-address appearing in the From header, nor would they wish to add
an inappropriate Sender or Resent-From header.
Change to:
: The origin address is the address on an email message, typically one
: of the RFC 2822 From: address, which is associated with an alleged
: author of the message. This address may be displayed by the
: recipient's MUA.
-Doug
_______________________________________________
NOTE WELL: This list operates according
tohttp://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html