[ietf-dkim] What's a replay?
dot at dotat.at
Thu Aug 11 10:19:50 PDT 2005
On Tue, 9 Aug 2005, Eric Allman wrote:
> It seems like the obvious place to store revocation information is in DNS (so
> that you don't start having to add additional ports, which is a problem from a
> firewall perspective). If you don't store the revocation ids in DNS then you
> have substantially raised the bar for using DKIM. But if you do store them in
> DNS, aren't you actually trashing DNS in exactly the same way as with per-user
I'll just state my understanding of Doug's suggestion in a briefer form:
The advantage of fine-grained revocation IDs over fine-grained keys is
that a negative cache entry is much smaller than a key. Revocation IDs
only have a DNS entry when they have been revoked, which should be rare.
Key IDs will usually have a relatively large DNS entry.
Doug also suggests an optimisation based on when you could reasonably
expect that checking for revocation would be unnecessary: if the message
came directly from the signing domain (which you could detect using CSA,
and which is the common case) you can skip the revocation check because
it's unlikely that a message would be signed then revoked before it even
travelled one hop.
f.a.n.finch <dot at dotat.at> http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
More information about the ietf-dkim