[ietf-dkim] SSP Responsibility Delegation - Security Concerns

[Scott Kitterman]

On Wed, 16 Aug 2006 14:01:17 -0700 Jim Fenton <fenton at cisco.com> wrote:
>[I have been on vacation the last 2 weeks, and you folks have been
>busy!  I can't possibly read everything that was said; excuse me if I
>duplicate an issue here and there.  I don't think this is a duplicate
>though...]
>
>This concerns the use of SSP to delegate responsibility for signing
>messages to a non-related domain without active participation by that
>domain: requirement 5 of section 5.3 in ssp-requirements-00.  I think
>there's a security problem here, in that it could cause a signature to
>be mis-interpreted as a first-party (origination) signature when it's
>not.  I'll deviate from the usual use of "example.com" to make the roles
>clearer but these are all fictitious domains.
>
>Suppose author.com uses SSP to cause signatures from its service
>provider, isp.net, to be interpreted as first-party signatures.  So
>user at author.com sends its outgoing mail to isp.net (hopefully using
>authenticated submission), and isp.net applies its own signature.  A
>verifier acting on behalf of the recipient sees the signature, looks up
>SSP for author.com, and concludes that the message has a first-party
>signature.  This is the desired result.
>
>Now suppose that isp.net also hosts some mailing lists.  An attacker
>spoofs a message from user at author.com to some mailing list which will
>accept a message from that address.  The mailing-list re-signs its
>messages by applying a signature from isp.net.  The verifier will look
>at this signature and incorrectly conclude that it's a first-party
>signature, while in fact it's a third-party signature on behalf of the 
list.
>
>This is the problem that the i= tag in the signature is there to solve. 
>If instead the mailing list were at author.com, a verifier could
>distinguish a signature from the author from a list signature by the
>different local-part in i=.  But we can't use i= in this case, because
>it has to match (or, perhaps be a subdomain of) the d= domain for the
>signature to be valid at all.  In other words, a signature which has
>i=user at author.com and d=isp.net is never valid.
>
>I have a number of other issues with the SSP-based delegation idea as
>well, but this is the most clear cut.
>
Agree that there are risks here that need to be spelled out.  We discussed 
that an important pre-requisite for this type of signing would be that the 
signer (isp.com in your scenario) would have to have controls in place to 
make sure unauthorized use of the domain name in question didn't occur.

RFC 4408 para. 10.4 has a discussion of this type of concern as it relates 
to SPF.  I think similar concerns for DKIM are valid.

I think the bottom line is that author.com needs to be careful who they put 
on that list.

Scott K