[ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt

[Hallam-Baker, Phillip]

From: ietf-dkim-bounces at mipassoc.org on behalf of Douglas Otis

		On Jul 5, 2007, at 2:25 PM, Jim Fenton wrote:
		
		> I have seen a few comments on the list, in particular Phillip's 
		> comment about the downgrade attack that we need to discuss more.  
		> If any of you are holding onto comments, please go ahead.
		
		While Phillip is correct about the downgrade issue, the key record 
		would need to be modified instead of an SSP record.  The SSP record 
		is only checked when the message is not signed by a domain that is at 
		or above the email address domain.
		

I would like to discuss the downgrade attack certainly. We have to address the attack either by solving it or by explaining it in the security considerations.

Doug's statement above is not correct though. A recipient ONLY looks at the policy record if it does not find an acceptable signature record. That means:

A) The message has no signature at all

B) The message has a signature header but it fails to verify

C) The message has a signature that references a signature key for an algorithm that is not acceptably secure

D) The message has a signature that references a signature key for an algorithm that the recipient is unable to verify.

The outcome from signature verification is binary: either a valid signature was found, or it was not. A client that implements BASE alone is not allowed to distinguish between the four cases above. This limits the field of application to whitelisting good mail.

With policy we have three outcomes, the outcome 'not found' is expanded to 'compliant with policy' or 'not compliant with policy'.

The point about the upgrade/downgrade attack is that a DKIM policy is determined by both the key records and the policy records. A key record is an implicit statement that the signer MAY use the specified key to sign a message. 

We want to be able to ensure that a recipient is able to correctly determine whether a message signature is or is not compliant with policy in cases C and D. Without the ability to code the policy 'every message is signed with an RSA key and a EC-DSA key' we are unable to publish an EC-DSA key without allowing the attacker to negate our policy.

The information about the algorithms is kept in the key records, what we need in the policy section is a restriction on the key selectors.

 

What I propose here is to eliminate the 'partial signature' policy statements that Jim has defined and replace them with the ability to specify restrictions on the signing keys. This is neutral from a complexity point of view. We eliminate a useless option and replace it with an option we very much need.

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