Subject: [ietf-dkim] The key record upgrade attack

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 4 Aug 2006 06:38:55 -0700

OK here is a more compact description of the problem with algorithm transitions:

In order to perform a transition to algorithms that are not part of the original base there will be a period in which messages are signed using both the old algorithm and the new, stronger one. The three value SSP policy proposed is negated by any party that attempts this transition.

Example:

Alice prepares to support XXX, this might be a cannonicalization algorithm, digest algorithm or signature algorithm. Since XXX is not part of the original specification it is only supported by a small minority (5%) of recipients.

Alice publishes

1 The policy statement 'I always sign'
2 A key record for algorithm XXX.

At this point Alice has lost 95% of the value the policy record is intended to provide.

Mallet can produce a forgery of a message by Alice that is 95% certain to be considered to be in compliance with Alice's sending policy. All he needs to do is to create a bogus header that refers to the selector for the XXX algorithm. 95% of recipients will be unable to check the message and determine that it is out of compliance.

Note that this is a security requirement. 'This is too complex' is not a valid rebuttal, nor is claiming not to understand policy.

The requirement here is that it must be possible to specify a key record for an algorithm that is not widely supported without compromising the value of the policy record.

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 04 Aug 2006 14:58:21 +0100

Thanks Phill,

That is a clear statement of what you see as the problem.

> The requirement here is that it must be possible to specify a key record for an algorithm that is not widely supported without compromising the value of the policy record.

My issue with this is that I don't see why this is much different
from:

Everyone supports rsa-sha256

Alice publishes:

1. The policy statement 'I always sign'
2. A key record for algorithm rsa-sha256

Mallet can produce a forgery of a message by Alice that is 100%
certain to be considered in compliance with policy - the signature
value just won't verify.

But we don't need to decide anything about this until after
reqs-00 is out.

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 4 Aug 2006 10:09:01 -0400

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>

>
> Note that this is a security requirement. 'This is too complex' is
> not a valid rebuttal, nor is claiming not to understand policy.
>
> The requirement here is that it must be possible to specify a key
> record for an algorithm that is not widely supported without
> compromising the value of the policy record.

+1

Phillip, I have to reread your MALLET messages to fully understand the
problem description to see if I have considered this in DSAP I-D.    Can I
ask if conceptually, does this touch base with the same security issue?

http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html#anchor16

4.4.  DSAP Tag: a=<hash-algorithm>

   The a=<hash-algorithm> tag defines the possible signature hashing
   algorithms used by the domain DKIM message signer.  The a= tag is NOT
   optional.

   The current algorithms are defined in DKIM [DKIM-BASE] section 3.3.

   o  rsa-sha1
   o  rsa-sha256

   Example:

   a=rsa-sha1,rsa-sha256;

   The main purpose of the a= tag is to allow domain signers the design
   and implementation opportunity to determine the highest strength
   possible by a particular target verifier by looking the DSAP DNS
   record for the target recipient domain host.  If this query results
   with no a= tag information, the default should be rsa-sha1 is the
   highest strength possible.

   Essentially, this is a negotiation and backward compatibility
   concept.  It is quite possible earlier pre-standard DKIM
   implementations supporting only rsa-sha1 may still exist.  The domain
   DKIM message signer's desire is to achieve the highest protection
   possible.  Instead of signing mail with a particular algorithm and
   hoping for the best, the signer can predetermine what the receiving
   system can handle in terms of hashing strength.

   This verifier lookup concept is best utilize for high-
   value domains in 1 to 1 transactions.  It would not be practice
   Mailing List resigners with large distributions to use this
   concept.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com