On Feb 21, 2006, at 7:11 AM, Michael Thomas wrote:
Douglas Otis wrote:
By just specifying the hash used in signature header, once a
hash algorithm is later discovered compromised, there is no means
to keep bad actors from using this compromised hash algorithm for
spoofing messages. It would appear the DKIM draft is not ready.
[page 21 allman-01:]
h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
allowing all algorithms). A colon-separated list of hash
algorithms that might be used. Signers and Verifiers MUST
support
the "sha1" hash algorithm.
What exactly is the problem?
If using an improved hash algorithm of the same size, when it has
been determined that SHA-1 no longer provides adequate protection,
then this statement of MUST support SHA-1 _is_ the problem. Also
this is an optional text based parameter wasting a fair amount of
_critical_ space. There is no reason to start off using TXT RRs when
a CERT RR offers a better immediate solution. A 2048 bit key will
soon become a required minimum.
Constrained to 512 bytes, 12 bytes are part of the DNS message
header, the query has 5 bytes plus the name size plus one byte per
label overhead, the answer has 9 bytes + 1 byte per label followed by
the RR data. Not including the name space, there are only 486 bytes
available for data.
Using TXT to store this key consumes 345 bytes of information leaving
only 141 bytes remaining. Of those bytes, 8 bytes are used to
indicate the version of the TXT record, leaving 133 bytes. The
"_domainkeys" label consumes another 14 bytes (assuming pointer
compression in the answer section) and that leaves 119 bytes for name
space. Add in the overhead for wasteful text methods expressing
allowed hash values and other parameters, there is then a high
probability there will not be enough space left for the query and
answer names. : (
There should be no problem using RFC2538 Cert RR for storing binary
key needed for DKIM from the outset. The 5 byte CERT header overhead
specifying the type of key, key-tag, and algorithm is already less
than the Version tag used for the TXT record. The CERT header
clearly assures the algorithm has been defined without resorting to
default or mandated parameters causing a potential security problem
for future upgrades.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html