ietf-dkim
[Top] [All Lists]

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

2006-02-16 09:35:07

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

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

<Prev in Thread] Current Thread [Next in Thread>