ietf-mailsig
[Top] [All Lists]

Re: MASS Security Review document

2005-02-07 13:10:34

On Mon, 2005-02-07 at 11:00 -0800, Jim Fenton wrote:
Douglas Otis wrote:

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.

A key/fingerprint represents a greater consumption of resources than
would a negative lookup.  An opaque identifier actually offers greater
flexibility, in that it could be sequentially assigned and thus not
resolve to a particular user for greater anonymity when needed, and yet
afford replay protection.  (This mode could be useful when an account is
not used.)  This mechanism would be optional and would not prevent use
of per-user keys where practical or desired.

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

This should only be done for larger domains that opt to use the
identifier.  The alternative could be a burdensome numbers of
keys/fingerprints that could impair deployment and would need to be held
in local caches.  Transitioning between key selectors when using
per-user keys could further aggravate the caching situation.  For most
domains not using this identifier mechanism, there would be no added
lookups.  If a replay problem became apparent, adding the opaque
identifier would be less problematic than restructuring DNS to add a
large number of keys or fingerprints.

(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)

A key/fingerprint TTL could delay revocation, if not kept short.  A
short TTL may add a fair amount of traffic (from the perspective of DNS
payloads).  This is to prevent an occasional, and even then optional,
subsequent (wafer thin) negative lookup?  

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

There would be no records published for non-revoked identifiers.  This
approach should be responsive and allow manual entry when needed in most
cases.

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.

Just as not every street signal needs a traffic cop, not every receiving
domain would need to query for revocation before the mechanism acts as a
deterrent.  This would be an option large domains may find beneficial
and again an option (when offered) recipients may find beneficial. 

There would be no requirement for this option to be offered, nor for it
to have a per-user granularity.  The alternative of millions of per-user
domain keys could prove to be a greater problem.  With the opaque
identifier, the TTL on the key/fingerprint could be kept long, and yet
there would remain an ability to quickly revoke authorization that a
valid signature would imply.

-Doug


    


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