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
the signing-domain.
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.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org