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

[Stephen Farrell <[e-mail]>]

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