ietf-dkim
[Top] [All Lists]

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

2005-08-17 16:58:55
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
<Prev in Thread] Current Thread [Next in Thread>