Subject: RE: [ietf-dkim] Deployment Non-Scenario 7: Cryptographic Upgrade andDowngrade Attacks

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 26 Feb 2007 07:09:24 -0800

> [mailto:[email-masked]] On Behalf Of John Levine

> I'm a receiver, a message shows up with some signatures.  For 
> each signature that uses an algorithm I understand, I check 
> and see if it verifies, which either it does or it doesn't.  
> For each one that uses an algorithm I don't understand, what 
> should I do?  I can't verify it.
> I can't assume it's good unless I want to create a 
> whale-sized security hole. So I ignore it.

OK so far

> 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.

The statement "I always sign' is useless to you in this case since a forger can sign with algorithm B which you don't support.

The statement "I always sign with B" is slightly more use but not much. It tells you that you should not expect to be able to verify signatures from that source. You cannot do anything with the message, perhaos you could increment a counter somewhere and tell the operator that the system needs an upgrade/oil change whatever.

The statement you need in this situation is "I always sign with A".

> 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?

This is a general argument against SSP in general. That is a legitimate argument but not the one we are discussing here which is strictly what is necessary for the policy to be useful in the case that it is possible to draw conclusions from lack of signature, failed verification etc.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html