Douglas Otis wrote:
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.
I'm not sure what sort of DoS protection you're referring to. It's true
that the response is small (although typically the SOA gets returned)
but I'm concerned about the transaction overhead as much or more than
the volume of data itself. But IANADNSE.
Why do you believe that 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.
I definitely agree that this scales better than per-user keys when
per-user key delegation is not otherwise required.
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.
Or longer if revocation is checked when the message is read. But I
don't think that's much of a problem as long as it is bounded.
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.
The signer can make the revocation indicator anything they want; they
can make it individual per message, per user, or (as in the case of a
mailing list) per subscriber. The verifier doesn't need to know
anything about it other than what it is (and I'm picturing it would be
optionally present in the signature header). So why do we have to
define how it's formed?
-Jim