[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: First go at directory server details



Len wrote:
> This is a "best is the enemy of the good enough" situation. I 
> am convinced that if we continue down this path, Type III 
> will fail to be adopted. Users and remops will never sign on 
> to a system which can be rendered inoperable with the simple 
> failure of four servers.

Obviously, there will need to be more than 4 directory servers to ensure
reliability and accessibility to the entire network.

[...]
> Users are concerned about reliability first, usability 
> second, and perceived security third. Our goal is to give 
> them real security and not just perceived security, but we 
> must also deliver usability and reliability, or our offering 
> will be rejected.

I concur with Len in that the system must reliably deliver mail, each
day, every day. Users have come to expect this from email. I furthermore
believe that this reliability does not have to come at the cost of
reduced security.

User agents, much less users, should not be required to make day-to-day
trust decisions. From this follows that user agents should not be
required to engage in a voting process to select between potentially
competing directories presented by the various sub-sets directory
servers. If there is such a concept as a unique correct directory, which
appears desirable according to the current research, the decision of the
network node structure the directory represents must be determined
within the set of directory servers itself.

Consequently, any directory server appears to need to either be able to
provide the querying user agent with a directory that the directory
servers agree is "the correct" directory, or the directory server must
not be able to provide information a user agent would accept as valid
directory input.

I suspect the search to the solution to this challenge may stand to
benefit from examining the existing research in the field of secure
multi-party computation, which attempts to address this very problem.

--Lucky