[ietf-dkim] Deployment Non-Scenario 7: Cryptographic Upgrade
and Downgrade Attacks
mike at mtcc.com
Mon Feb 26 06:11:33 PST 2007
Charles Lindsey wrote:
> On Sun, 25 Feb 2007 22:09:06 -0000, John Levine <johnl at iecc.com> wrote:
>> So now let's say I have a message that has at least one good
>> signature. As far as I'm concerned, I'm done, it's verified. If I
>> were to check the SSP, the most that could happen is a variation on
>> the "I sign nothing" scenario, if the SSP claims there's some set of
>> signature algorithms other than what I found. That is not useful to
>> the receiver, other than perhaps to identify senders insufficiently
>> competent to publish consistent key and SSP records.
> If the message has enough good signatures which match the From
> (whatever) header to meet whatever your local policy requires, then
> indeed you accept it; end of story; no need for SSP.
>> Or I have a message that didn't have any good signatures. I can't
>> tell whether that was because it was unsigned, it had a good signature
>> that broke in transit, it had a good signature that I didn't know how
>> to verify, or it had a bogus signature applied by a bad guy. So, as a
>> receiver, this is all the same situation, it's unsigned. If you
>> believe that SSP can state "I sign everything", you might throw it
>> away if that's what the SSP says. Otherwise, what?
> Eh? If it was unsigned, you know that.
> If it was signed with an algorithm you couldn't verify, you know that,
I suspect the key word here is "signed". All you know is that it has
something that looks like a DKIM-SIGNATURE. The verifier has no way to
differentiate sha0 from sha1024 since it is ignorant about both. Thus
for all intents and purposes it is just as broken as any other reason
that a signature might break, and needs to be handled in the identical
way lest you give attackers a leg up.
> If the signature was broken, you know that (but not why it was broken).
> All those situations are to be classified as 'unsigned' (but more
> detailed information is available to you if you want to use it).
> So, being "unsigned", you consult the SSP, which maybe tells you "we
> sign everything". You might then reject it regardless on that basis and
> thus lose some genuine message simply because you couldn't verify the
> algorithm in use; more likley, you would want to allow such cases
> through (whilst also persuading your local geeks to implement the new
> algorithm ASAP).
Um, that sounds like a great way to make dkim completely impotent: if
an attacker knows that you treat unverifiable signatures better, they
only have to put those majick bytes in the signature header and voila.
But, in the example quoted (message signed only by
> unverifiable algorithm B) you would then accept the bogus message. But
> an SSP response of "we sign everything with both A and B" would allow
> you to accept genuine messages from that site (because you can veriffy
> algorithm A) but reject the bogus one.
As I mentioned, you can already determine what algorithms are supported
by a given selector. Why does putting in SSP help?
More information about the ietf-dkim