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

[Jim Fenton]

Earl Hood wrote:

>On August 17, 2005 at 22:07, Jim Fenton wrote:
>
>  
>
>>>Let's say example.org knows nothing about DKIM or has not adopted
>>>it yet.  EXAMPLE.com is operated by questionable folks, and they
>>>know example.org does not have any SSP records defined.  EXAMPLE.com
>>>defines _domainkey.EXAMPLE.com records to contain valid signer
>>>public keys.
>>>
>>>EXAMPLE.com sends out messages signed by EXAMPLE.com, but places
>>>an example.org address in the rfc2822.From.
>>>
>>>When a DKIM verifier, "V", receives the message, the signature
>>>validates cryptographically (remember, the signer public key is
>>>retrieved from EXAMPLE.com).  The verifier now checks the OA SSP by
>>>query example.org's nameserver.  The query returns no record available.
>>>
>>>What verification status should V return?
>>>      
>>>
>
>  
>
>>V should say that the message is signed by a third party.
>>    
>>
>
>I think this is dangerous behavior.
>
>What value is there to the recipient stating that the the message was
>signed by a third-party.  DKIM should not facilitate spoofing, and
>the example I gave, spoofing is the intent.  There is a danger that
>giving _any_ positive verification of the signature can legitimize
>the message in the recipient's mind.
>  
>
A third-party signature is a lot weaker assertion than an OA signature, 
unless you know something about the third party.

>If no SSP record is defined, "never signs" should be assumed (note
>the current SSP draft does support a "never signs" policy).  This will
>prevent malicious domains from exploiting any "trust" DKIM generates
>in order to spoof identities.
>  
>
Actually, the current SSP draft supports a "never sends email" policy, 
which is quite different.

>Care must be taken to insure DKIM does not facilitate malicious
>behavior.
>
>  
>
>>After all, 
>>it's possible that someone at example.org uses a mailing list hosted by 
>>example.com, which might have a good reason to sign a message.
>>    
>>
>
>Someone at example.org may not know what EXAMPLE.com does, so
>they should not be adversely affected by the application of DKIM
>by EXAMPLE.com.
>  
>
Exactly.  Are you suggesting that the default should be:
(1) Treat any signature from the OA (example.org) with suspicion, or
(2) Treat any signature on a message from the OA with suspicion ?

If it's (2), it means that domains that haven't deployed DKIM that send 
through mailing lists to domains that are checking SSP would have those 
messages marked as suspicious.

I don't have nearly as much trouble with (1), but it only helps with 
marking messages with invalid signatures as suspicious (presumably 
attackers can't attach valid signatures).  But if a domain is checking 
SSP, wouldn't they be checking the signature as well?

>Also, DKIM does not support the benevolent scenario you mention
>very well.  Since the validity of a signature is determined by the
>OA's SSP, a mailing list cannot add a signature if the SSP forbids
>third-party signing (which may be common for security reasons).
>  
>
It depends on how one interprets a message, given an EXCLUSIVE SSP, with 
a third-party signature as compared with a message with no third-party 
signature (and presumably no valid OA signature in either case).  One 
way to look at this is to let the mailing list sign everything, but then 
the verifier just ignores the out-of-policy third-party signature.  
Another way is to require the mailing list to consult SSP, and sign only 
those messages that permit third party signatures, and for the verifier 
to treat messages with out-of-policy signatures more harshly than those 
that don't.  I favor the former approach, because it makes things 
simpler for mailing lists (why check SSP at every step?) and because it 
puts the decision in the hands of the recipient's verifier because it's 
really the recipient we're serving.

-Jim