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
