[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

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