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

[Jim Fenton]

Earl Hood wrote:

>On August 17, 2005 at 16:55, Jim Fenton wrote:
>
>  
>
>>> 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).
>>    
>>
>
>SSP is tied to the OA domain, not the signer's domain.
>
>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.  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.

-Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20050817/a8344fbe/attachment.html