ietf-dkim
[Top] [All Lists]

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

2006-08-04 07:24:11
----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>


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





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