Yes, the attack can happen fast, but if they are sending spam the revocation
check will get hammered and there is a great way to spot something odd going
on.
There are two opportunities to block, when the message is received and when
it is opened.
-----Original Message-----
From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com]
Sent: Monday, March 07, 2005 1:20 PM
To: Hallam-Baker, Phillip
Cc: 'Douglas Otis'; Andrew Newton; MASS
Subject: Re: In response to Housley-mass-sec-review
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?
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.
More comments below...
Hallam-Baker, Phillip wrote:
How about if there was a means of obtaining BOTH message and
user level
revocation in one go?
Consider the following, we put a unique opaque identifier
code in each
message which looks just like a base64 string:
Yrpwqefhkjfoiuh2q3poiu32198ry2qph23p8ru2==
Active code on the DNS server unpacks to a structure:
NameID : MessageID
Nah, why not just do a hierarchical query?
Base64(SHA1(messageID)).Base64(sha1(userID))._revocation.example.com
I'm not clear on why you want to go to all this work rather than just
include a revocation ID in the signature (which is signed by the
signature)? SHA1 isn't going to provide any more anonymity,
because you
can probably do a dictionary attack to find the userID. And
(as William
Leibzon has pointed out in the context of IIM), Base64 is
case-dependent
and DNS lookups aren't, so you probably need to use base32 or hex.
This type of mechanism would have to be signalled in the policy
mechanism so the recipient knows whether to do the check or not.
Why not just signal it in the signature?
-Jim