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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html