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

Steve Atkins steve at blighty.com
Thu Feb 16 08:33:02 PST 2006


On Feb 16, 2006, at 8:20 AM, Dave Crocker wrote:

> Folks,
>
>> If you can't rank algorithms, is there any meaningful concept of a
>> "downgrade attack"?
>> I'm sort of wondering though if Mark's problem here might be just as
>> easily solved by having a "current"/"next" kind of routine. That is,
>> only allow two in play at any one time, ...
>
>
> 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.
>
> Besides that presumably, having multiple signature versions, as  
> discussed here, is only for transition times.
>
> Do we really need to engineer such fine-grained mechanisms for  
> protection against attacks during limited windows of mis- 
> opportunity, for a mechanism that is only trying to aid in  
> determining whether to deliver a message?

That depends on how seriously recipients and their MUAs treat a DKIM
signature.

Is it a sign that the mail is very, very likely to come from who it  
claims to come
from, so domain-based whitelisting applies? In that case, the  
threshold of
"sufficiently expensive" to deter attacks is pretty low.

Or is it a sign that the mail definitely comes from the entity  
involved, for
instance your bank. Of course, DKIM doesn't really try to be that broad,
so there are a number of very cheap ways for a bad actor to do this
without compromising DKIM. Those approaches are extremely cheap,
and they set an upper bound on how much effort a bad actor will
bother applying to break DKIM. Again, the threshold is fairly low,
but a little higher than the previous one.

As I understand it, DKIM isn't really intended to be strong  
authentication
of message, rather it's intended to be cheap authentication of  
originating
entity.

"Simple and shipped" beats "over-engineered and irrelevant" in this  
case,
I think.

Cheers,
   Steve



More information about the ietf-dkim mailing list