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 to
http://mipassoc.org/dkim/ietf-list-rules.html