On Mon, 2005-03-07 at 10:20 -0800, Jim Fenton wrote:
I'm not sure where to jump into this, so I'll arbitrarily pick here.
It sounds like revocation indicators are starting to make people feel
better about the replay problem, but they still seem to me like they're
closing the barn door after the horse has already left. Replay attacks
can happen VERY fast -- consider that the originally signed message
could be .forwarded (or equivalent) directly to a bunch of available
MTAs (maybe zombies) who fan the message out to a bunch of individual
addresses. It could be over within a couple of minutes. And we expect
that signature verification will happen primarily at MTAs, so they'll be
verified as they arrive at the recipient domain. Is it worth the
additional uncached load on DNS to do this?
When used in conjunction with DoS protection, the additional DNS
overhead would occur infrequently. When the revocation check is made,
this lookup would be about as small as possible, being no record
returned. Indeed a "replay attack" occurs after the message has been
signed and sent. The horse has left the barn, but with the revocation
mechanism, the horse will not get beyond the corral.
Without a revocation mechanism, options to quickly squelch a replay seem
rather awkward and slow, being per-user records. I admit that IIM does
better with this, as the keys are sent with the message, but there is
still a rather large finger-print database published with DNS and a much
larger key repository difficult to keep resident in memory.
When users utilize a common key, this key then needs to be valid long
enough to ensure delivery of messages, which seems to preclude a brief
period where the key remains valid. These keys will need to remain
valid for days or perhaps weeks if to be robust.
A design that makes a key validation failure likely due to a rapid
expiry would create a nuisance dealing with bounces, which most try to
avoid, may cause some to ignore such failures. The revocation mechanism
can also be employed at the MUA/Filter to discover revocation at a much
later point in time, to remove messages from the mailbox, as Phillip
pointed out.
There is a benefit that can be derived from the DomainKey approach.
Address hijacking is a growing concern. DomainKeys could create a type
of stepping stone of keys (old signs new) for detecting when something
strange has occurred. This could provide a type of trip-wire or
canary-in-the-mine to detect this hijacking problem. It could also help
slow instant introductions of new domains. The response to something
odd would be temporary refusals for a few hours. NOCs would have a
chance to make sense of the problem. I envision services that do
nothing but monitor these keys. : )
If this is indeed worth it, another source of replay to consider is
replay through a mailing list (spammer joins a mailing list, then sends
one spam message through it which is signed by the list and replayed by
the spammer). In this case the choice of revocation indicator is
trickier -- it can't just be based on the mailing list's address,
because that's common with the legitimate users. The indicator could
either be per-message (lots of state to keep) or based on the
subscriber's address. I'm guessing we will see a lot more
human-moderated lists.
Going from treating all mail from an IP address as a group, to the use
of a message-signature/revocation-identifier would represent a
significant improvement over this normally very blunt tool of IP
addresses. The message-signature/revocation-identifier would allow
rapid correlation. Those replayed sources of the message should also
come under scrutiny and flagged as sending "replay" abuse simultaneously
with the message. An administrator that reacts by blocking both, can
then reconsider later. Reviewing the content of the messages and their
source to decide whether the account and/or the source remains blocked.
Each will develop a history, and a free account may not be worthy of
much consideration however.
Nah, why not just do a hierarchical query?
Base64(SHA1(messageID)).Base64(sha1(userID))._revocation.example.com
There is a very small risk for the userID, as a hash is not unique. It
would seem better directly using a unique identifier from a Radius
server, as example. Use with a message-id however could be beneficial
where this type of message resolution is desired. Accidental revocation
of a message from the same account seems less of a risk. It also seems
rather flexible. Whether this feature is worth doing an additional DNS
lookup would be another question.
-Doug