ietf-dkim
[Top] [All Lists]

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

2006-08-16 15:01:28
Jim,
I must be missing something here,
d=isp.net i=user(_at_)author(_dot_)com the message verifies successfully 
because the isp.net signed it and the SSP=I sign all at isp.net indicates it 
does 3rd party signatures?
thanks,
Bill


-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Jim Fenton
Sent: Wed 8/16/2006 5:01 PM
To: IETF-DKIM
Subject: [ietf-dkim] SSP Responsibility Delegation - Security Concerns
 
[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(_dot_)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(_dot_)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(_dot_)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.

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


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