Open Network Handles--Abstract Protocol Specification
(DRAFT 0.1)

Michael J. O'Donnell

Date: 22 August, 2002


I propose a system of Open Network Handles to provide permanent primitive network handles promiscuously to all who request them. Handles provide an intermediate level of service between IP numbers and domain names. While assignment of IP numbers is constrained by routing considerations, the owner of a handle may reassign it to different addresses over time for mobility or changes in configuration of resources. Unlike domain names, handles carry no significance in natural language, so they should not have high commercial value, nor should they attract disputes based on assertions of rights in significant names.

This document describes a protocol for an open network handle system at the abstract level--what information needs to be in each type of message--but no syntax or other implementation detail.


1 Purpose of the Protocol

I propose a system of open network handles, similar to domain names, but deliberately free of humanly meaningful semantics. A handle is intended to provide permanent global consistent reference to a particular agent, and nothing else.

This article describes a protocol for an Open Network Handle System (ONHS) at an abstract level. It only describes the messages sent and received by users of the system, not the internal messages, data structures, and algorithms needed to implement such a system. It describes messages abstractly in terms of the information that they carry. All questions of format, syntax, and other implementation details are left to a later work.

Most if not all of the difficult problems that must be solved to implement ONHS have already been addressed in the implementation of the Domain Name System, so there is little uncertainty regarding the feasibility of the system. In the short run, the service provided by ONHS is a subset of the service provided by DNS. By cutting back service to a logical minimum, ONHS hopes to provide stronger confidence in the permanence of handle resolution than DNS provides for domain name resolution, mainly because by avoiding humanly meaningful semantics, we can avoid the administrative disputes surrounding name resolution.

I have discussed elsewhere the nature of handles, and their relations to routes, addresses, and names []. For present purposes, it suffices that an agent participating in the global Internet may own a handle, and may bind and rebind it at will to addresses at which the agent may be reached. Any agent may query ONHS to discover the address currently bound to a given handle.

1.1 ONHS Responsibilities

ONHS deals with communications between handle owners, queriers, and handle servers who constitute a highly distributed global system. Many or even most handle owners and queriers will also participate in the global system as handle servers, but it is convenient to separate their actions according to the roles they serve.

ONHS is only intended to provide a sort of continuity in communication with an agent whose address changes from time to time. It is not intended to provide any sort of assurance regarding the identity nor the good behavior of that agent, including the agent's good faith and competence in managing his handle.

ONHS provides mechanisms for an agent to acquire a handle, and to announce bindings of that handle to different addresses over time. When another agent queries the system, it tries to return a hint, giving the address most recently bound to that handle by the owner.

The global system focuses on putting each querier in contact with the correct handle owner. As much as possible, authentication of the handle owner, and all other assurance of quality in communication, are left as the responsibilities of the querier and handle owner. The ONHS global system takes responsibility for responding to each query with the correct resolvent address promptly with high probability. The precise promptness of response and highness of probability are determined by the needs and capabilities of the global network at any time. The global system is only responsible for overall productivity--owners and queriers are responsible for the reliability of individual transactions. Responses to queries are called hints, because the global system does not try to make them individually highly reliable.

Although the global system does not take direct responsibility for the correctness of individual hints, to be useful it must operate in a manner that allows owners and queriers to authenticate their communications effectively. To this end, the global system also takes responsibility for maintaining a low rate of false hints. In a distributed system, we usually cannot enforce a one-to-one correspondence between queries and responses, so the low rate of false hints is a separate goal from the high probability of prompt correct response.

With current public-key authentication techniques, and presumably with other authentication techniques invented in the future, individual agents have the tools to insure the correctness of their communications, as long as their authentication techniques remain secure. But improvements in computing speed and mathematical advances tend naturally to break the security of any particular technique, so as a secondary goal, the global system should help handle owners through transitions in authentication techniques. This seems to be best done by allowing a combination of self-authentication and third-party authentication, along with support for irrevocable announcements by handle owners transferring the meaning of an old handle to a new one. Such transfer can be used to reassign a handle to a new agent, as well as to a new authentication technique.

Since no mathematical technique can make authentication foolproof, the global system should also provide handle owners and queriers with hooks by which they may audit security.

The global system operates in a highly distributed fashion on a loose coalition of more and less trusted hosts. A good system should allow individual queriers and handle owners, as well as coalitions, to contract with vendors who participate in the global system on their behalf to improve performance and reliability for particular handles in which they take a special interest. A good system also allows essentially unlimited subspaces of the handle space to be administered locally by any authority who cares to do so.

2 Data Types in the ONHS Protocol

The exact scopes of authentication types, address types, time stamps, and performance parameters is open, both for the initial implementation of ONHS, and for future improvements of the system. Here are some particularly important members to include from the beginning, and some discussion of possible future developments.

3 Essential Messages, Useful Messages, and Policy

In the following sections, I describe the different sorts of messages that may be sent by queriers, the global system, and handle owners. I do not describe messages sent between participants in the global system--I leave those to the implementation. To allow the greatest possible flexibility in distributed implementation, I distinguish messages that are essential to system utility, and messages that may improve system performance and/or utility but are not essential. I describe messages in a self-contained form, so that each message has a clear meaning entirely by itself without any conversational context. I also describe messages containing the smallest increments of information that seem to make sense. A particular implementation may allow some of the information to be determined by conversational context, and/or it may bundle messages for efficiency.

4 Announcements from Handle Owners

4.1 Essential Messages

4.2 Useful Messages

4.3 Policy

A handle owner's policy depends on the importance of her handle.

To avoid the risk of differential delays reordering announcements, a handle owner should use increasing $ \mathord{\text{\textit{$<$sequencer$>$}}}$ values in announcements. Without increasing $ \mathord{\text{\textit{$<$sequencer$>$}}}$ values in her announcements, a handle owner is vulnerable to resubmission of a saved announcement by an adversary.

A handle owner should verify the effect of an important announcement with a test query.

A single $ \mathord{\text{\textit{$<$handle$>$}}}$ value only lasts as long as its authentication technique remains secure. We hope that new and stronger authentication techniques will be invented months or years before old techniques become insecure, providing a substantial upgrade window. A handle owner who needs handle service beyond the lifetime of a particular authentication technique should create a new handle with a stronger new technique as soon as it becomes available, and announce an irrevocable transfer from the old handle to the new one. All queriers who use the old handle before it becomes insecure should redirect to the new one. Depending on the importance of the handle, the owner may provide authentication of identity out of band, and gather additional certificates of transfer from trusted third parties. A trusted time stamp, showing that the transfer was made before the old handle became insecure, is particularly valuable. The additional certificates are not included in the ONHS protocols: the handle owner may provide them directly to the querier.

A handle owner should not depend on ONHS to establish the authenticity of individual contacts made through the handle system. The handle owner has no defense against the credulity of a misdirected querier who consents to transactions without authentication. But the handle owner may present authentication policies to her correspondents as early as possible in the correspondence, to reduce the likelihood of loss of a correspondent through misdirection.

As soon as a handle owner learns that an adversary has gained the power to issue authentic-looking announcements, she may limit the damage by announcing a compromise, and using trusted third parties out of band to try to recapture lost correspondents. The existence of an unauthorized binding with a correct certificate often indicates that the handle authentication technique is compromised, but it may indicate another sort of compromise of the handle owner's computing and communication resources. If cancellation of handles is supported, the owner should cancel a compromised handle. By announcing compromise and cancellation, the owner limits the consequences of unauthorized bindings and delegations and directs attention to trusted third parties out of band.

Mention policy for transfers, including recipients of transfers.

5 Using Announcements to Resolve Handles

We are only interested in handles that appear to be in use.

The set of authentic announcements known to name servers determine partial resolutions of handles to other handles, and full resolutions of handles to addresses.

After a long sequence of announcements, there are likely to be many ways to fully resolve a given handle, but all but one of them are usually obsolete.

The ONHS attempts to resolve handles by nonobsolete resolutions, but in a distributed system, there is no certain guard against obsolescence. The ONHS should provide resolutions that, with high probability, are not very obsolete. I am not sure what measure of obsolescence is appropriate, and I suspect that the measure will always be rather fuzzy. In general, the seriousness of obsolescence increases with the length of time since the posting of the announcement with a larger sequencer. It has little or nothing to do with the age of the obsolete announcement itself, nor with the increment in sequencers. The seriousness of obsolescence probably depends on the nature of the particular ancestor involved in the obsoleting announcement, but the nature of that dependence is not obvious, and probably varies according to the intentions of the agents involved.

The attribution of security compromise is even more confusing than resolution. If a handle is compromised, then all of its descendants inheriting authentication from it are presumably compromised as well. Other handles with the same authentication method and the same key are probably compromised, but there probably won't be very many of those, and it seems to much to expect the ONHS to track them down.

What sort of compromise have I missed?

6 Queries and Checks to Handle Servers

Queries ask for hints derived from announcements sent previously by handle owners.

6.1 Essential Messages

6.2 Useful Messages

There are some additional messages that may be useful to a querier, but they are discussed under Section 7 on Audit Requests.

6.3 Policy

Mention trusting the ONHS, end-to-end authentication, selective auditing.

7 Audit Requests

Handle owners, queriers, and other interested parties may audit the operation of the ONHS system, by querying individual announcements and by requesting notification of all announcements for a given handle.

7.1 Essential Messages

7.2 Useful Messages

8 Hints, Reassurances, Audits, and Declinations from Handle Servers

Responses by handle servers to queries, checks, and audit requests include:

8.1 Essential Messages

8.2 Useful Messages

8.3 Policy

A handle server should respond to each $ \mathord{\text{\textbf{QueryAddress}}}$ message as promptly as possible with an address or handle bound to the nearest/lowest possible ancestor of the given handle. If the server is aware of more than one binding to the same ancestor, it should prefer the one with the highest sequencer. If sequencers are the same, the server may apply any sensible local policy.

The global system should make a best effort to respond promptly to every address query with the irrevocable transfer of the handle if there is one, and the authentic binding of that handle carrying the latest time stamp if there is no reassignment. The system is useful only if the probability of such a prompt response is very high. The system may guide and/or limit its effort based on performance parameters provided by the querier. If two or more authentic bindings to the same handle tie for the latest time stamp value, the highest priority is to return at least one of them. If the cost is reasonable, the system should return as many of them as possible, or at least announce the existence of the multiplicity.

The system should keep the probability of a false hint very low. If there is a conflict, this takes precedence over prompt correct response. A correct response has little value when buried in incorrect responses. On the other hand, avoiding incorrect responses has some value even when correct responses are absent.

The real technical point of authentication within the global system is to keep the rate of false hints low, and to avoid masking a correct announcement behind an inauthentic one. Once a querier is in contact with the correct handle owner, they may perform all sorts of end-to-end authentication completely independently of the ONHS, using other sorts of trusted registries if they like.

The global system should make a best effort to report a security compromise of a given handle promptly in response to every query of every sort involving the same handle. If a binding is discoverable at a sensible cost, it should provide that binding also. But compromise announcements should be stored in such a way that cost is never or at most very seldom an issue in discovering an authentic announcement of a security compromise.

The global system may find it valuable to give higher priority to discovery of an irrevocable reassignment than to discovery of a binding to an address, so that failure to find a binding will be even rarer in the case of reassignment than in the case of a normal binding.

As long as the cost is moderate, the system should provide certificates authenticating announcements even when they are not requested, and especially in the case of reassignment.

The system should provide the promptest and fullest possible notification and explanation of negative results that is feasible at a sensible cost.

Mention audit policies, priority to handle owner.

9 Examples



About this document ...

Open Network Handles--Abstract Protocol Specification
(DRAFT 0.1)

This document was generated using the LaTeX2HTML translator Version 99.2beta6 (1.42)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -split 0 -show_section_numbers -no_navigation abstract_protocol.tex

The translation was initiated by Mike O'Donnell on 2002-08-22

Mike O'Donnell 2002-08-22