[ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade and
mike at mtcc.com
Sun Feb 25 10:53:27 PST 2007
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.
>>>> 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.
More information about the ietf-dkim