Re: [ietf-dkim] draft-ietf-dkim-threats-02 nit//[various topics]

[Douglas Otis <[e-mail]>]

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