The cost of privacy (was Re: Notes about identifier - locator separator)

[Pekka Nikander <Pekka.Nikander@nomadiclab.com>]

Ohta-san,

[Changed the subject to better match the contents.  Furthermore,
 this starts to be off-topic.]

Masataka Ohta wrote:
> For a receiver to retrieve an appropriate cryptographic key or
> a communication context for a packet, a long lasting ID in clear
> text, as an index to the long lasting database of key or context,
> must be carried by the packet.
Not necessarily.  Since you don't seem to believe in PK and
apparently also not in zero knowledge protocols, let me give
a simple example with only hash functions.

Let us assume that Alice's long lasting ID is A, and she
is contacting Bob.  Let the ID space be sparse, i.e., so
that there are few IDs compared to the whole space.  For
the example to make sense in the first place, Alice and Bob
must have talked to each other beforehand, and Bob therefore
knows A.

Now, instead of sending A, Alice generates a random nonce N,
and sends

   <N>, <hash(N | A)>, and perhaps <first(k, A)>

where first(k, A) are the first k bits of A.  Note that this
message does not carry A, it only carries values derived
from A.

Bob can now retrieve from his database all IDs whose first
k bits match with <first(k, A), and try them out one after
another.  Once he finds an ID where

  hash(N | ID) == <hash(N | A)>

he knows that he has found the right ID.  Unless an attacker
possesses exactly the same database as Bob, it has much
larger task ahead and in many cases can't be sure about
Alice's identifier A even after the search.

Thus, with some computational cost at the context setup
you can hide the long term identifiers from outsiders.
(To be secure against DoS, the context setup must be
protected against resource exhausting DoS but that can
be easily done with a cookie exchange.)  After the context
has been set up, it can be indexed with a short term
connection ID, as you seem to agree.

> Once such key or context is retrieved, the following packets of a
> connection can use locators as a short lasting IDs. But, it does not
> mean that a long lasting ID is not initially necessary.
I think I have countered your claim.  There are more complex,
and more effective, crypto protocols where you can get even
better results.  (Sorry, I can't give references out of hand,
but I can dig up if you are interested.)

> Proxies are a way aginst Echelon.
Proxies mean inefficient routing.

> However, more important aspect of the reality is that if identity
> of someone is hidden, the network is valunerable to SPAM and other
> forms of DOS.
If the ID is hidden from the network, that doesn't necessarily
make the network vulnerable to SPAM or DoS.  Firstly, only a
recipient is vulnerable to SPAM, not a network.  An effective
way against SPAM is to impose an artificial computational cost
on the sender of a message.  An effective way against certain
types of DoS is to impose an artificial computational cost
on the initiator of a session.  If you don't believe me, here I
have a number of references ready, if you are interested.

You can design a network for privacy, still have it open, and
make it DoS resistant.  To do so, you have to understand the
economics of security.  See e.g. Ross Andersson's paper on
last year's ACSAC for a fairly good introduction.

If you are concerned about terrorism and privacy at the same time,
you can design protocols that allow pseudonomity but where the
pseudonomity can be broken at a computational cost.  That allows
NSA with its vast CPU farms to break privacy, but not the (a)typical
spying ISP.  That is, if you want such a system, you can develop
such a system.

What comes to me, I don't want my children to ever live in "1984".

There is no black and white in security or privacy, even though
some security or privacy zealots seem to think in that way.
Security engineering is engineering, with conflicting goals,
just like any engineering.  You don't gain much by throwing
away the amount of security and privacy that you can reasonably
design in.

--------

> > Would you please point me to text that explains why the
> > reverse DNS database does not work, and in which way?
> I said "inverse query". See the RFCs.
My apologies for misreading your sentence.  It's been a while
since I last read through the DNS RFCs, and I had forgotten
the existense of inverse query.  Apparently I seem to forget
things that don't work.

--------

> I feel some difficulty that you call such approach "Homeless".
If you haven't noticed, I abandoned the "Homeless" MIPv6 idea
almost two years ago, just a few months after the ID was out.
Besides, the name was just a catchy phrase, meant to point out
how the MIPv6 home agent is becoming an unnecessary single point
of failure.

--Pekka Nikander