On Feb 16, 2006, at 9:36 AM, Mark Delany wrote:
On Thu, Feb 16, 2006 at 08:20:57AM -0800, Dave Crocker allegedly
wrote:
I keep coming back to the very limited goal of DKIM and wondering
whether the concern about a downgrade attack isn't just a little
too esoteric for that goal.
It happens that it also solves the agility requirement too. So even
if you're skeptical of downgrade attacks being relevant, we are
hoping - I presume - that DKIM will live for longer than the
current set of anointed algorithms and that we do need a way to
transition that doesn't require a forklift.
Preventing hash related exploits with the 'a=' parameter within the
signature header remains doubtful. The hash parameter should be
indicated within the key information. If I followed this correctly,
you suggested the hash information could be moved to the currently
undefined selector, which makes upward definitions difficult. As the
key must be located at the selector, there would be little advantage
in using such an approach except to retain the limited (flawed) key
definition even though DNS entries must change. Introducing a new
hash algorithm also means introducing new client software. Perhaps
modifying key content can also be resolved when transitioning to the
use of the CERT RR. This CERT RR would allow key information to be
stored in a binary form, include references to other types of key
services, and properly defined the complete algorithms as needed for
a secure design. : )
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-09.txt
This CERT RR has the algorithms defined within a fields specified
within a key parameter, the safe method for defining the hash used.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html