Subject: [ietf-dkim] Algortihm transitions

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 7 Sep 2006 12:47:09 -0700

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