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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 28 Feb 2007 09:43:47 -0800

> [mailto:[email-masked]] On Behalf Of Jim Fenton

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

That is exactly the attack that concerns me.

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

The problem is that the verifier is acting on incomplete information.

If verifiers do this there is a disincentive for senders to use the new signature algorithm until it is supported everywhere.

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

The policy record would only be checked in the circumstance that a message was received that ONLY bore a message that had a signature that the verifier considered to be inadequate.

If there is an acceptably secure signature then the verifier would check that and the job is done.

Since an inadequate signature is by definition essentially the same as no signature at all the need to check policy is inevitable and not an optimization. You have to check policy if there is no signature and you have to check policy if there is an inadequate signature.

In practice I don't rate this as a very important attack for the deployment scenarios we are considering today. My concern here is that it is exactly the type of issue that a Bellovin or a Resorla or anyone else in the Security Area might point to as a protocol flaw and in this case they would be right. 

In particular if all you are going to be using DKIM for is to control spam perhaps you could ignore the security issue. If on the other hand your key record is

beta._domainkey.example.com. 1D IN TXT 
     "g=; k=rsa; t=y; p=MFwwDQYJKoZIhv...== 
        letterhead=http://repository.verisign.com/9652d63d06d1b0b0489db2452bf796e4"

Your security considerations have just become considerably more demanding.

What is going on here is that the letterhead URI points to an EV certificate with a logotype extension that contains a subject icon.

OK now imagine that such a certificate is issued to an EBay or a Paypal. The security demands we have just placed on DKIM have increased dramatically. At this point there is an incentive to spend time factoring a weak modulus or whatever.

Now I can of course come out with a convincing explanation as to why the issue does not directly affect the usage but its much better to avoid the problem entirely if possible.

> I am also concerned that this is a multi-dimensional problem 
> which may lead to some very complex policy records.

That is the reason why the policy constraint mechanism proposed is a lexical constraint on the key record selectors rather than a direct constraint in the policy record.

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 28 Feb 2007 12:15:29 -0800

> That is exactly the attack that concerns me.

You're kidding. This is all about receivers who pass things that they
ought not? Wouldn't it be easier to just file a bug report?

> If verifiers do this there is a disincentive for senders to use the new signature algorithm until it is supported everywhere.
No, I'd say that the verifier has a bug and  that it should just fix the
bug. There are a hopeless number of other bugs that a verifier can have,
so I don't see why this one is special.
> The policy record would only be checked in the circumstance that a message was received that ONLY bore a message that had a signature that the verifier considered to be inadequate.

In which case you'd do SSP as usual and if it said "I sign everything",
then it wouldn't pass muster just like usual.
> If there is an acceptably secure signature then the verifier would check that and the job is done.

But the verifier would do that before it consulted SSP.
> In practice I don't rate this as a very important attack for the deployment scenarios we are considering today. My concern here is that it is exactly the type of issue that a Bellovin or a Resorla…
As described, this isn't a protocol flaw it's an implementation error.

But what might be helpful here to state the *exact* text that you think
needs to go into the requirements draft and we can have a poll as to whether
to included or not and alleviate me from having to understand that which
I clearly do not.

       Mike