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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 23 Feb 2007 18:07:58 -0800

> [mailto:[email-masked]] On Behalf Of Dave Crocker

> 1. If the signer publishes support for multiple algorithms, 
> then the publisher supports those algorithms.  If they made 
> poor choices, that's their problem.

The term 'poor choice' is POV.

What you mean here is 'poor choice from the practical point of view'. The new algorithms is almost certainly going to be a better point of view from the cryptographic point of view or why change?

So what you are saing is that if someone wants to migrate from SHA-1 to SHA-256 or the equivalent then that's the problem for the publisher rather than the working group charged with engineering a system here.

That's nonsense.

> Doing something that causes a signature to fail is something 
> I class as a downgrade.

That is not the security area definition of a downgrade attack. A downgrade attack is when the attacker gains a more favorable outcome by causing a party to accept a lower degree of security than they should expect.

The only purpose of a security policy mechanism is to prevent a downgrade attack.

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

---

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

> From: Hector Santos [mailto:[email-masked]] 

> Hallam-Baker, Phillip wrote:
> 
> > The discussion here is about a REQUIREMENT. How the requirement is 
> > achieved is not the issue at this point.
> >  
> > Of course since everyone seems to skip straight to the 
> implementation,
> 
> That is what happens in a mixed discipline environment. :-) 
> Plus there is 100s if not 1000s of man-years experience here 

And that is another major problem in itself. It is easy to become paralysed by past experience. Some of what was possible in 1985 became impossible in 1995 and some of what was impossible in 1995 is possible today.

The objective here is dilectic. For DKIM to succeed the amount of arbitrary message modification has to decline sharply. Fortunately this is already happening to some degree.

> > The policy record does not directly reference the signing 
> algorithm, 
> > all that information remains in the key record. All that you get in 
> > the policy record is a statement 'there is always a key record that 
> > has a selector that looks like this' or 'there is always 
> one like this 
> > and one like that'.
> 
> I don't understand why.  The ultimate selector is the one in 
> the DKIM-Signature heeader.

The selector in the signature header tells you where to find the key

The selector in the policy record, if present, tells you that you should expect at least one signature header which has a selector with the specified prefix.

So if you have only one DKIM signature header of the form 

   DKIM-SIGNATURE: s=key1.sha3keys d=example.com .... 

It tells you to look for a key record of the form:

   key1.sha3keys._domainkey.example.com TXT "h=sha3 ... 

If the signature verifies then you are done!

If on the other hand you do not support SHA3 which is not suprising you go to the policy record to decide if the message is consistent or inconsistent with policy. 

If the policy states:

  _outbound._smtp.example.com   TXT  "DKIM"

The message is consistent since the message has a DKIM signature header. The header did not fail verification so we do not need to ignore it completely (and yes I noted the wording in base very carefully at the time), instead we note that there is an unverifiable signature header and the message is compliant with policy

RESULT: Message goes to content filtering as if the signer had no DKIM signature or policy statement.

If on the other hand the policy states:

  _outbound._smtp.example.com   TXT  "DKIM=sha2keys"

The message is not compliant with the specified policy. key1.sha3keys does not match *.sha2keys.

So we have a policy inconsistency here.

The consequence of the policy violation would depend on various factors. If the receiver was some sort of mailing list or remailer then the most appropriate course of action might well be to simply reject the message. If the receiver was a personal inbox and domain was on a list of commonly targetted domains issued by the APWG then the most appropriate course of action might be REJECT. Otherwise we would process the message using content filtering but with the constraint that if the message is legitimate it must have been forwarded through a legitimate forwarding relationship.

If on the other hand you had started with two signatures:

   DKIM-SIGNATURE: s=key5.sha2keys d=example.com .... 
   DKIM-SIGNATURE: s=key1.sha3keys d=example.com .... 

If either signature could be verified the message would be accepted without ever retrieving the policy record.

If both signatures fail verification we have a policy inconsistency and deal with it as before.

There are two outcomes possible with DKIM Base: VERIFIED and UNKNOWN
There are three outcomes possible with DKIM Base+policy: VERIFIED, UNKNOWN and INCONSISTENT

The whole point of policy is to establish the possibility of the third outcome. The point of checking policy is that a message that receives the outcome INCONSISTENT is treated less favorably that UNKNOWN. Less favorably may mean outright rejection or merely different content filtering parameters.

The only constraint that BASE gives us is that messages with broken signatures should map to the same states in the same circumstances as messages with no signatures at all.  

Notes:

* No additional DNS lookups took place.
* There is no optimization value in fetching the policy before checking the signature in any case
* The policy record does not specify the hash algorithm.
* The key record specifies the hash algorithm.

* This proposal is much simpler than SSP.
* This proposal is more powerful than SSP.
* This proposal makes it much easier to understand policies than for SSP
* This proposal is considerably more extensible.

* If you use fully qualified domains in the selector specification (sha2keys._domainkey.example.com) you could even express policy of the form 'all mail for domain X is signed by domain Y'.