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