ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP Responsibility Delegation - Security Concerns

2006-08-16 18:31:40
On Wed, 16 Aug 2006 17:41:35 -0700 Michael Thomas <mike(_at_)mtcc(_dot_)com> 
wrote:
Jim Fenton wrote:

Douglas Otis wrote:
 

This seems like a minor change for the better.  What weakness can't be
fixed by the proper procedures followed by a signing domain?
   

The one I described:  the inability for a verifier to distinguish an
author signature generated by the delegate from a third-party signature
generated by the delegate operating in a different context.
 

What would be useful is for people who are neutral about this issue to
look at the attack vector Jim describes. It sure seems real to me, but some
independent verification would be helpful as well. In particular what would
be nice is to place requirement constraints on the protocol such that this
attack must be able to be mitigated by the delegated third party. If that's
possible at all.

It seems to me that bringing a mailing list into the scenario changes the 
scenario slightly, but not in a significant way.  I would envision two 
basic modes of operation for a signer:

1.  Uncontrolled - Sign mail submitted by authorized users of the MTA 
without extra regard for identities used in the message (I say extra regard 
since many mailing lists only accept mail sent by subscribers).

2.  Controlled - Sign mail submitted by authorized users whose authority to 
use the requisite identity (2822.From) has been verified.  

Shifting from uncontrolled operation to controlled operation is, in my 
opinion, a pre-requisite for being a safe delegated first party signer.  I 
can see that doing this for a mailing list could be problematic.  I expect 
that this is the next step in the evolution of MSA operational constraints 
- a next logical step analagous to closing open relays.

In summary, I think the concern is valid, but not one the protocol can 
solve.  I view it as an operational issue for MSA operators.

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