Subject: [ietf-dkim] Domain/Identity conflict redux

From: Douglas Otis <[email-masked]>
Date: Tue, 8 Jul 2008 19:08:52 -0700

Section 3.2 overlooks hazards related to stolen or misused private  
DKIM keys likely offered to mobile users that have restrictive local- 
part templates imposed by a public key's “g=” tag and value.  In such  
cases, the domain is indicating their lack of trust in a key's use.   
Any annotation indicating a message has a valid signature when the  
Author Address fails to match against a restrictive local-part  
template and domain encourages the exploitation of these likely  
vulnerable keys, and leaves recipients prone to deception.

,---
|3.2. ADSP Usage
|...
| o If a message has a Valid Signature from an Author Domain, ADSP
|   provides no benefit relative to that domain since the message is
|   already known to be compliant with any possible ADSP for that
|   domain.
'---

Change to:
---
o If a message has a Valid Signature from an Author Domain, and where
   a key's restrictive local-part template and domain does not preclude
   the Author Address, ADSP provides no benefit relative to that domain
   since the message is compliant with any possible ADSP assertion.
---

The definition for Author Signature also needs modification:
,---
|2.7.  Author Signature
|
|An "Author Signature" is any Valid Signature where the identity of
|the user or agent on behalf of which the message is signed (listed in
|the "i=" tag or its default value from the "d=" tag) matches an
|Author Address in the message.
'---

Change to:
---
  An "Author Signature" is any Valid Signature where an Author Address
  matches against the key's local-part template and domain.  A match
  is determined by construction of a template composed of the key's
  “g=” tag and value and domain as denoted in the signature's “d=” tag
  and value in the form <g value | * >@[*.]<d value>.  The default for
  the key's local-part template value when it is not present is “*”.
---

Many large ISPs will benefit by being able to offer an “on-behalf-of”  
identity as defined by the signature's “i=” value that may not be  
found within the From header field or elsewhere within the message.   
An ISP's authentication process may not correspond directly with email- 
addresses their customer's use.  In some cases, it will be easier, and  
will offer greater privacy, when the “i=” is permitted to be an opaque  
value derived from the ISP's authentication servers referenced from  
either an account or customer systems, rather than a specific author.

By allowing large ISPs this freedom, recipients are far more likely to  
obtain an identifier that can be used to block abuse emerging from  
large domains where completely blocking the domain would not be  
practical.  Few ISPs are likely willing to affirm an identity of the  
Author, but might be more willing to offer a surrogate identity  
instead.  After all, the WG charter precludes DKIM from being used to  
make strong assertions about Authors.  However, the aggregation of the  
“on-behalf-of” information, whether it is that of Authors or their  
surrogate identity, will allow third-parties a means to isolate  
systems likely 0wned by bot-nets.

Not changing the Author Signature definition will necessitate use of  
multiple signatures (which increases receiving systems DDoS exposure  
when these allowances need to be made), or cause ISPs to leave the “on- 
behalf-of” identity in an ambiguous state by not including the “i=”  
tag and value at all.

-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html