ietf-mailsig
[Top] [All Lists]

Re: MASS Security Review document

2005-02-07 12:00:41

Douglas Otis wrote:

A technique based upon the current widespread practice of blackhole
listing would allow rapid revocations to occur, while still allowing a
common signature.  The provider would not need to do anything, but they
could publish this information themselves, as the authoritative, least
expensive, and hopefully the fastest method to distribute this
information.

The information could take the form:

<opaque-identifier>._rl.<signature-domain>
 or
<opaque-identifier>._rl.<signature-domain>.<third-party-domain>
One problem I see is that the verifier of a signature needs to make this additional DNS request, which does not have very good cacheing properties (since the opaque-identifier would typically allocated per user address), before considering a signature to be valid.

Another way to approach this is to just allocate more keys. There is an expense there, too, due to the volume of data in DNS and the poorer cacheing of the keys.

I think it just comes down to an optimization problem:  is it better to:

(1) Support fewer keys and revocation lists, with the need for a verifier to make two DNS queries (2) Support more keys (for domains that need it) and no revocation lists, with only one DNS query but a larger volume of data in DNS (because a key retrieval would be larger than a revocation result)

Would a DNS record be published for each unique identifier or would the lack of a response indicate the authorization hasn't been revoked?

It's important that we not burden domains that won't have a significant replay problem (small, well-controlled domains, for example) in order to deal with this problem. So it needs to be possible for the opaque-identifier to be at a coarser granularity than individual addresses. But the second DNS query still bothers me.

-Jim


<Prev in Thread] Current Thread [Next in Thread>