Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

[Jim Fenton]

Earl Hood wrote: On August 11, 2005 at 13:27, Jim Fenton wrote: But how would they get a valid signature on behalf of the OA? Or are you saying that one should treat the message differently from an unsigned message because there is an invalid OA signature present? There isn't any reason to apply a signature unless you know it will verify correctly. Conversely, there isn't any reason to downgrade a message simply because it has an invalid signature. The way DKIM is defined, the signature is not bound to the rfc2822.From. I.e. The i= tag can be anything. Therefore, any domain can sign an outgoing message with any From: address in the message header (something phishers will do). Mailing lists too.  Some recipients are going to be interested in all messages from mailing lists they subscribe to (e.g., fans of ietf-dkim).   Although we haven't fleshed out best practices for mailing list re-signers, I suspect that they'll want to sign all messages that go through the list. To deal with this, DKIM supports SSPs, where the verifier checks the SSP of the rfc2822.From to see what the signing policy is in an attempt to prevent malicious domains using arbitrary rfc2822.From addresses. Now, according to the current SSP draft, if no SSP DNS record is defined for rfc2822.From (or what the draft calls Originator Address), the draft states the following: If the Sender Signing Policy record does not exist, verifier systems MUST assume that some messages from this entity are not signed and the message SHOULD NOT be considered to be Suspicious. Now, in this case, we have a signed message with no SSP defined. Because of this, and past SSP discussion, appears the above statement needs to be revised to avoid a security problem. I'm still missing what it is.  Sorry if I'm being dense.  If it's just the conflict between the policy (published in DNS) and a key that has been published (also in DNS), I don't see where the policy is any more secure than the key record, unless it has to do with some characteristic of DNS itself (e.g., a cache poisoning attack). >From a security perspective, if no DNS SSP record is defined, the safe policy is to treat any _signed_ message as suspicious since it can indicate malicious activity. Not doing so will lead to malicious domains to adopt DKIM since during early stages of DKIM rollout, many domains will not have SSP records defined. When you say _signed_, do you mean valid or invalid signature?  I have trouble associating increased suspicion with the presence of an invalid signature (vs. no signature at all) since there are other ways that signatures can be broken by munging the message. Of course malicious domains will be early adopters of DKIM, just as they were of SPF.  But malicious domains also get to define any signing policy they want. There appears to be no real burden to require DNS SSP records to be defined for entities that will have messages signed. For example, if ISP example.com is to implement DKIM signing, along with defining the appropriate DNS records for key data, it can easily define the SSP records. I agree that publishing SSP is a good idea for any domain that is signing. -Jim

_______________________________________________
ietf-dkim mailing list
http://dkim.org