Re: Additional lookups (was Re: [ietf-dkim] Re: 1368 straw-poll)

Paul Hoffman wrote:
> At 4:17 PM -0800 2/27/07, Jim Fenton wrote:
> > With a mechanism in SSP to specify the signature algorithms that 
> > should be present, it is always necessary to consult SSP to find out 
> > the list of required signature algorithms.
> Why?!?! If one of the signatures is good, there is no need to do the 
> SSP lookup.
Phillip Hallam-Baker wrote:
> If the message has any valid, acceptable sig you accept and the policy 
> record is never read.
> So no, there is no extra lookup.
I at least partially misunderstood the proposal then, and I doubt that 
I'm alone. Apologies to Phill, who explained this to me over lunch at 
RSA as well.
The idea here, as I understand it now, is to provide some additional 
information about messages that contain a signature a verifier can't 
verify.  Rather than considering the SSP result for such messages to be 
"unknown, because I can't determine whether that signature is valid or 
not", it provides a way for the verifier to be able to say "I know that 
this fails SSP, because it lacks another signature that should be there 
(and that I probably would understand)".
The related attack would be as follows:  A signer might deploy a 
brand-new signature algorithm (I'll call it N) that very few verifiers 
can yet handle.  The attacker sees this, and starts forging messages 
with invalid signatures referencing the N selector, in hopes that some 
verifiers will accept the message on the premise that they're just not 
"smart enough" to verify using N yet.  If this were to happen, it would 
introduce a problem getting signers to start using new algorithms.
Of course a solution to this is to make sure all verifiers treat 
signatures they can't verify (as well as those that fail verification) 
as if the signatures aren't there.  But perhaps some of the verifiers 
won't do this, because they don't want to risk adverse consequences from 
taking action against such messages.
But the downgrade attack described in the last paragraph of Phill's 
original message:
> There is also a downgrade attack using essentially the same principle except 
> that in this case algorithm A is actually broken and Algorithm B has a 
> sunstantial amount of deployment. Instead of creating a nonsense signature that 
> will fail validation the attacker forges a valid signature for the 
> untrustworthy algorithm.
>
>   
would require that SSP be consulted in all cases, because the attacker 
is able to forge a valid signature.  However, I think this is adequately 
dealt with by the signing domain removing all selectors that reference 
the broken algorithm.
I am also concerned that this is a multi-dimensional problem which may 
lead to some very complex policy records.  In addition to the signing 
and hash algorithms, the body and header canonicalization algorithms are 
likely to invite this sort of policy treatment.  This would be easier 
for the attacker, since unlike the hash and signature algorithms, the 
acceptable canonicalization algorithms aren't called out in the key 
record (although an extension could be defined to do that).
My overall inclination right now is that trying to distinguish a message 
that definitely fails SSP from a message that has an unknown SSP 
(because the verifier doesn't know how to verify it) is putting too fine 
a point on SSP.  The "unknown SSP" case should just be treated as "fails 
SSP" and the signer should be cajoled into providing useful signatures.
-Jim



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