Douglas Otis wrote:
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.
Sure, CSV is complementary to signatures. But requiring CSV means that
signature verification can only happen at the edge MTA, which is a
significant operational constraint. Are you also saying that CSV
authentication MUST succeed before you even try to verify the
signature? Does the HELO domain also have to have a reasonably good
reputation? I would not be happy with codifying either of these
dependencies (although recipients, of course, can do whatever they want).
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.
I hate to lean too much on the "zombie" example, but with enough
coordinated senders, a lot of mail can be sent very quickly.
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.
I think it's longer than that. See my response a few minutes ago to
Andrew Newton.
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.
Hmm, maybe we can accommodate this just by allowing a "." in the
revocation-identifier.
-Jim