Andrew Newton wrote:
On Mar 8, 2005, at 12:56 AM, Jim Fenton wrote:
This depends on all authoritative DNS servers being tightly coupled
to the revocation infrastructure, and I'm not sure how practical that
is for everyone. Some mail domains probably don't run their own name
servers; they may do this through their registrar. And every
"hammering" is one that got away (notwithstanding your next comment):
Arguments about the administrative proximity of DNS and email have
been made ever since the idea of DNS-based sender authentication
started. If an organization has this little control over their own
zones, then DK/IIM have more basic problems, as in how will they get
the key in the zone in the first place much less manage key
roll-over. In fact, this will be an issue from some domain holders
but we will probably never know just how slight or serious this
problem really is.
This goes beyond control of the name servers; this would require a
feedback loop based on name server activity, which is a new
requirement. Perhaps revocation identifiers would only be used by
domains that are capable of monitoring the activity on their
authoritative name servers.
If this is the case, how long must the revocation records be
retained? It must be much longer than has been discussed for keys (a
week or so to allow delivery of queued messages).
I don't understand this. Why would it be any longer than the signing
key?
Suppose my verifying MTA accepted a replayed message before the
revocation got published, but I was on vacation for a month before
reading it. The MTA would verify the signature and mark the message
with a header to indicate that, so the signing key doesn't need to be
retained that long. But the revocation indicator, since it would be
checked when I read the message, would need to be available until then.
I'm not saying revocation indicators are bad -- I'm still trying to
decide what I think. But I'm concerned they're being oversold a bit.
Something that actually prevented the replay attack would be best, but
we don't seem to have one. My own opinion is that revocation IDs are
good enough. Of course, we could turn Doug's idea on its head and do
validation IDs requiring the presence of A records for all valid
messages, but I would guess this would really be an administrative
challenge.
If we're going to depend on the lack of a record [BTW, why an A record?]
to indicate that a revocation ID isn't active, then we probably need to
put these records in their own zone. A small and unscientific survey of
some domains indicated minimum TTLs on the SOA of from 600 to 7200
seconds, and we want negative caching to persist for a much shorter time.
-Jim