On Wed, 16 Aug 2006 14:01:17 -0700 Jim Fenton <fenton(_at_)cisco(_dot_)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(_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.
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html