Re: Advantages and disadvantages of using CB64 type of identifiers

[Erik Nordmark <Erik.Nordmark@sun.com>]

> Note that there are very different requirements for servers, clients 
> and participants in peer-to-peer communication. I'm going to assume 
> that there are few privacy issues for servers as they need to be known 
> to do their job. For clients there are privacy issues but they don't 
> need long-lived ids so it's not too bad. For peer-to-peer participants 
> it's harder because they can't switch ids as easily.

Are you talking about clients, servers, and p2p participants as
different products that contain different protocol stacks (or
differently configured stacks) which make different assumptions?

I think there are *communication roles* called client, server,
and p2p participant, but the same application might play different roles
over time or depending on usage, so I don't see how a given protocol stack
can have different defaults unless that stack is bundled with a non-extensible
set of applications.
Thus, while the application that different roles have different requirements,
I don't see that being useful unless we think it makes sense to define APIs
by which an application is required to express its role or its requirements.

> Also, for clients it should be possible to hide any additional locators 
> and just send over auth info. Then, if there is loss of connectivity, 
> the client switches locators and says "hi, it's me, remember my hash 
> chain?" or something similar.

That doesn't prevent the curious peer from discovering them by
pretending that locator the client is using is having a problem
(worst case the peer should be able to force this by just
dropping the packets from the client until the client
tries a different locator).

> Obviously this way it's still fairly trivial for an adversarial 
> correspondent to find out additional locators.

Yes.

So it isn't clear to me what problem we are actually trying to solve
in the privacy space.

   Erik