On Mon, 2005-03-07 at 22:10 -0800, Jim Fenton wrote:
Douglas Otis wrote:
On Mon, 2005-03-07 at 10:20 -0800, Jim Fenton wrote:
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. [I am not a DNS expert]
Any signature method will require some type of DoS protection. As
signatures are independent of the IP address, extending that feature to
the DoS protection scheme, HELO authentication offers an entity that can
be used to establish a DoS database used in conjunction with a signature
rejection list. Normally this is an IP address DoS database. If, by
convention, MTAs signing mail also assured an ability to quickly
authenticate the HELO, this should be early enough within the
transaction to thwart unwanted email connections from consuming network
capacities.
Why do you believe that the "horse" will not get beyond the "corral"?
While the barn door is always open for a signed message, responding
promptly to a replay attack should diminish the damage. Massive amounts
of mail can not be sent instantaneously. Those locations that send high
bandwidth replay should end up within a DoS database. There is also
some clean-up that can be done post acceptance as well.
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.
I suggested that the revocation records could be removed together with
the subsequent key to ensure an overlap. In general, the duration
should be longer the key is published plus the key TTL.
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?
In general, you are right. I think this issue is more about the concept
of employing a hierarchical query. This will double the number of A
records that will require examination. I would rather define this by
indicating the maximum number of labels that this revocation-identifier
would be allowed to represent. The simpler case would be to only do a
single lookup with a single label at the node prescribed for revocation
records. Allowing multiple labels and still a single lookup offers less
in the way of advantages and adds again to the overhead. Phillip
suggested this could also be used to place the revocation record load
onto different name servers. Large websites like Yahoo with extensive
free accounts will develop better data upon which to judge this issue.
-Doug