[ietf-dkim] SSP Responsibility Delegation - Security Concerns

[Jim Fenton]

Bill,

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
"d=" tag.

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 i=@isp.net, 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
the local-part.

-Jim

Bill.Oxley at cox.com wrote:
> Jim,
> 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?
> thanks,
> Bill
>
>
> -----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
> 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.
>
> -Jim
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>
>