SSP-02 does not
provide a useful mechanism for coping with algorithm transisions.
In a transition from
algorithm A to B there will be the following conditions:
A set of receivers
RA that only supports algorithm A
A set of receivers
RAB that supports algorithms A and B and accepts both as
secure
A set of receivers
RB that considers only algorithm B to be acceptably secure.
A set of senders SA
that always sign with only algorithm A
A set of senders SAB
that always sign with both algorithm A and B
A set of senders SB
that always signs with only algorithm B.
Note that if the set
RA is large, as will inevitably be the case at the start of a transition any
sender in the set SB will effectively lose the benefit from DKIM. Equally
insiting on algorithm B is not feasible unless the set SA is acceptably
small.
It follows then that
the choices for senders are constrained by the deployments of receivers and
vice-versa.
At the start of the
transition all senders and receivers will fall into sets SA and RA by defnition.
In this case the only viable choices are SA, SAB, RA, RAB.
Without the ability
for a receiver to determine the type of sender they are dealing with the
following problems arise:
Attacker knows that
receiver is in set RA:
Attacker can impersonate any sender in set SAB by inserting a bogus
signature for algorithm B that recipient cannot check.
Attacker knows that
receiver is in set RB:
Attacker can impersonate any sender in set SAB by
inserting a bogus signature for algorithm A that recipient will not
trust
It follows therefore that the system is DEADLOCKED
without the ability for the receiver to distinguish a sender in set SAB from one
in set SB. No party can ever upgrade their algorithm.
This situation can be remedied by allowing the sender
to:
1) specify that multiple signatures
are used.
2) specify a constraint on the DKIM
selectors for each signature.
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
