[ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade and Downgrade Attacks

[Michael Thomas]

Paul Hoffman wrote:
> At 12:09 PM -0800 2/23/07, Dave Crocker wrote:
>>>> Deployment Scenario 7: Cryptographic Upgrade and Downgrade Attacks
>>>>
>>>> In the case that a signer advertises key records for multiple 
>>>> signature algorithms this may allow an attacker to circumvent an 
>>>> insufficiently expressive signature policy.
>>>>
>>>> Example:
>>>>
>>>> Legitimate sender advertises key records A, B. Record A describes a 
>>>> signature key for a widely supported signature algorithm. Record B 
>>>> describes a signature key for a signature algorithm that is not 
>>>> generally supported. The senders signature policy says 'I always 
>>>> sign every message'. The sender always signs messages with 
>>>> algorithm A (whether algorithm B is used by the legitimate sender 
>>>> as an additional algorithm or not does not affect the success of 
>>>> the attack).
>>
>>
>> Color me confused.  I thought we agreed long ago that downgrade 
>> attacks were not an issue for the problem DKIM addresses.
>
> What Phill describes is not a downgrade attack: it is an attack based 
> on algorithm agility. If we allow multiple algorthims, and not all the 
> algorithms are the the "MUST implement" level, this attack is 
> feasible. Every protocol with algorithm agility but not a fixed list 
> of "MUST implement" algorithms has this issue.

At this point, all we have is MUST implements. Considering there is
no opportunity for negotiation with mail, MAY/SHOULD implement
algorithms seems like a pretty bad idea altogether. So is this still a real
problem for DKIM?
>
>> In general, there are myriad ways to break a signed message, to 
>> render the signature invalid.  We have chosen not to attempt to 
>> prevent breakage.
>
> Phill's example does not deal with breaking a signed message, nor 
> rendering a signature invalid.
>
>> More basically, we are moving quickly into the morass of requiring 
>> SSP lookups for signed messages, rather than limiting SSP for use 
>> with unsigned messages.
>
> I agree that this is an example of an SSP lookup for signed messages. 
> I hope it does not mean that we are opening the door for other 
> purposes. It is also not requiring an SSP lookup; the only time you 
> care if the message is signed with an algorithm you don't understand 
> is if you know that they sign all messages. Therefore, you already did 
> the SSP lookup to find out that information. The algorithm list would 
> come along with the "I sign everything" information.

Cf my previous mail, we already transmit algorithm information in the
selector itself. I don't understand why simply nuking selectors with bad
algorithms isn't an adequate defense.

       Mike