Re: [ietf-dkim] New Issue: Base: Upgrade indication and protection against downgrade attacks

[Douglas Otis <[e-mail]>]

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