[ietf-dkim] Review of draft-fenton-dkim-threats-01
dotis at mail-abuse.org
Sat Oct 29 16:22:36 PDT 2005
On Sat, 2005-10-29 at 16:55 -0500, Earl Hood wrote:
> > S 5.2.3:
> > I don't see how you can reasonably deal with replay attacks
> > by revoking the key that was used to sign the message. This
> > enables a trivial DoS attack on any message sender--just
> > get some messages from that sender and generate some replays.
> Key revocation is also a heavy method for dealing with replay, and
> may be impractical for many when a single private key is used
> to sign messages for multiple senders. Revoking a key can invalidate
> many legitimate messages.
> Doug's opaque ID method is more suitable for revocation of a known
> message. It is still TBD, FMPOV, if the opaque ID is still sufficient
> enough to deal with replay since the window of opportunity may still
> be large enough that when revocation is done: the damage has already
> been done.
The reviews I published of this problem recommend a mitigation strategy
that can eliminate a window of opportunity. The opaque-identifier would
speed the correlation of abuse to seconds. There would also be a means
to detect when the channel of transport changed. This could be done
using your technique, where a hash of the RCPT TO is captured within the
signed portion of the message. The alternative technique would be to
verify the EHLO and noting when the EHLO was not within the domain of
When these conditions indicate the channel may be controlled by a
different domain, the messages are delayed. This delay can be done at
the transmitter. Although problematic at first, this technique has
undergone a break-in. In other words, there is no window of opportunity
that needs to be left open when using the opaque-identifier technique.
For those recipients that do not use a reputation service, they would
benefit as if they had a reputation service. This benefit would be
obtained by the sender publishing their own list of known bad opaque-
identifiers. The strategy would be simple. When the message appears to
be out of the channel, enforce a small delay of a few minutes.
A history of sources that normally cause the channel to change could be
white-listed to minimize the overhead this may cause, but even when the
white-listing is not done, the messages would still be exchanged after a
slight delay. For those that do not implement the delay, there would be
a small window, but this window should be measured in minutes. Keeping
this window small, should deter much of the possible abuse.
More information about the ietf-dkim