[ietf-dkim] DKIM Threat Assessment v0.02 (very rough draft)

[Jim Fenton]

[Hector, apparently you have unsubscribed, which is unfortunate.  I'm 
not sure this will be of interest to you, but it may be to others on the 
list.]

Hector Santos wrote:

>>>Threats:
>>>
>>> - Adversary gains unauthorized access to domain private key
>>> - Internal thief (black market) of domain private key
>>>      
>>>
>>This is seems to be along the lines of Section 9.2, though that
>>section seems to talk mostly about user keys being compromised.
>>Perhaps that section can be broken into two subsections: one on
>>malware and user keys, and a second with an emphasis on protecting
>>private keys under the control of sysadmins.
>>    
>>
>
>I agree.   A side note would be that private keys will mostly likely be
>automated (coupled with some change frequency). So this automation has to be
>protected.
>  
>
Section 9.2 indeed does focus on compromise of user keys, as a way of 
pointing out the additional potential threats associated with MUA-based 
signing.  But you're correct, there should be more discussion about the 
other ways in which keys might be compromised.

>  
>
>>> - Adversary compromises MUA DKIM signers
>>>      
>>>
>
>  
>
>>See above.
>>    
>>
>
>The difference between the two is the entry points and the protected
>resources.  One addresses the server-side, one address the client-side. From
>a business standpoint, I think we are talking about key management
>responsibility. From a design standpoint, rethorically, do we really want
>the MUA to be signing?  Why not just move the responsibility to the MSA or
>outgoing MTA?   One less threat with user level exploits.
>  
>
To the extent that MUAs use SMTP to send messages, I can't think of a 
general way to prohibit MUA signing, so it might be best to describe the 
associated issues.

>Side note: I can see new LEGAL conflicts here. "A email service removing a
>DKIM signature does causing tort or harm to reputation of domain."
>  
>
For that matter, an email service modifying a message in a way that 
invalidates the signature does that too.

>  
>
>>> - Signers who do not honor OA SSP
>>>      
>>>
>>I don't understand how this is an attack on DKIM.
>>    
>>
>
>Correction:
>
>- Signers and verifiers who do not honor OA SSP
>
>If a message is signed as a EXCLUSIVE policy, then no additional 3rd party
>resigning must take place.  Conversely, a verifier should raise a red-flag
>when it sees a conflicting signing. i.e., 3rd party signed message when the
>OA domain policy indicates no 3rd party signing allowed.
>
>Hence, signers and verifiers need to double check policies.  The current
>protocol has an optimization feature where it only checks for the OA SSP
>policy under certain conditions.
>
>I think this optimization is premature.  The worst scenarios are still
>possible when this optimization is enabled.
>  
>
I don't see the harm in extra signatures.  If there is a valid OA 
signature on a message, what attack is facilitated by the application of 
an unnecessary third-party signature?

-Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20050817/176bc3da/attachment-0001.html