[ietf-dkim] SSP Responsibility Delegation - Security Concerns
fenton at cisco.com
Wed Aug 16 15:56:33 PDT 2006
See dkim-base-04, section 3.5, description of i= tag: The domain part
of the address MUST be the same as or a subdomain of the value of the
This rule is not dependent on SSP. So if isp.net were to sign for
user at author.com, it would either omit i= entirely, use email@example.com, or
create an artificial local-part and use that with i=. There's some
possibility that one could disambiguate this case with artificial
local-parts, but then we're violating (IMO) the premise of "without
active participation by that domain". It also overloads the meaning of
Bill.Oxley at cox.com wrote:
> I must be missing something here,
> d=isp.net i=user at author.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?
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.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
> 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.
> NOTE WELL: This list operates according to
More information about the ietf-dkim