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

[Douglas Otis]

On Jul 10, 2007, at 2:15 PM, Hallam-Baker, Phillip wrote:

> 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.

Don't forget.

E) The message has a signature by a Third-Party domain.


You are describing a policy conformance issue caused when an  
algorithm is upgraded, but not yet supported by the recipient.  IMO,  
this is not a downgrade attack, although this could affect policy  
compliance.

When the key is obtained, it should be possible to determine whether  
the key's algorithm is supported.  Unfortunately, a key's notation  
will not cover all aspects of the signing and verification process.   
A downgrade attack might occur when two signatures are added to  
ensure compliance during an upgrade transition.

There might be an attack made possible when a stronger algorithm is  
trivially defeated.  This might happen when a weaker algorithm is  
accepted, although both algorithms are supported.  Exploitation of a  
weaker algorithm could be considered a downgrade attack when a  
stronger algorithm is supported.

The other situation might be removal of the weaker algorithm, where  
evidence a different algorithm is supported by the signing domain may  
offer some level of acceptance.  Removal of the weaker algorithm and  
spoofing a stronger algorithm might be considers an a spoofed upgrade  
attack.

Having a stronger signature algorithm signed by a weaker algorithm  
might be an expensive and perhaps fragile solution to a downgrade  
attack.  However, this approach presupposes the nature of the weaker  
algorithm's exploit.  Although a weaker algorithm may become  
problematic, abandoning a weaker algorithm may be untenable as this  
may invite conditions leading to a spoofed upgrade attack.

Preventing a downgrade attack, without presupposing what the weakness  
might be, could be handled by defining a flag within the key  
indicating that it had been deprecated and what key pairs should be  
present.  The purpose of the deprecated flag is to indicate that the  
key MUST BE accompanied by a stronger signature.  Identifying the  
stronger and weaker algorithms should also be done within the keys to  
minimize overhead and preclude either a downgrade or spoofed upgrade  
attack.

> 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.

Agreed.

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

It would seem two signatures would be the only reasonable method for  
transitioning with a strict policy.  As such, there should not be  
policy exceptions made based upon what only appears to be supported.   
The domain should be allowed to explicitly indicate what has been  
deprecated, and indicate what should be accompanied by each other  
signature within the keys.

> 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.

It would seem any unsupported algorithm clearly falls into a 'not  
signed' category.  When policy is strict, this would be within the  
'not compliant with policy' category.

> 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.

This is difficult to follow.  How can a global policy differentiate  
whether it is okay to use selector A or B.  One might presume both  
selectors are used or they would not be published.  If one were to  
sign an email-address within a sub-domain, it could also utilize  
different keys within both higher and lower domains.  The stronger  
signatures could be valid only for a sub-domain email-address whereas  
the weaker signature could be used for either domain without possible  
conflict.

Authorization of signatures within sub-domains could be used.   
Restrictions of such authorizations could occur within a TPA-SSP  
without inducing additional overhead.   : )

> 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.

It is not clear what mechanism is being proposed.  The TPA-SSP could  
be extended to include a  '*+<policy-limitation>' local-part matching  
component as an added restriction.

-Doug