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

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Pekka;

> 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

And sends just N, as an ID.

It is called a cookie.

But, your case is even simpler.

> Bob can now retrieve from his database all IDs whose first
> k bits match with <first(k, A),

With your assumption that Bob has A even before they first
communicate, everything is possible.

The hidden assumption is that Alice and Bob has a secure OOB
channel before the beginning or that A is publicly known to
everyone.

Note that, if A is known by a sniffer, locators of A is publicly
available, which is required for multihoming, that frequent
changes of locators is not a protection against traffic analysis.

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

As you understand, it is a routing issue that locators act as
IDs.

> > 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.

That is pointless.

That I can make some form of DoS difficult does not mean I can
identify the attacker nor can I be protected from other forms
of DoS.

> If you don't believe me, here I
> have a number of references ready, if you are interested.

I know an effective way against SPAM with current SMTP as is is
not to give any reply for SYN.

> 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.

First, you should understand the real networking, including, but
not limited to economics.

Say, for example, cookie.

> 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.

Do you know how the computational cost varies?

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

That is the problem.

In good old days of 1984, DES was unbreakable.

In 2001, though we still don't have HAL...

> 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.

How can you say engineering?

> > 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.

Remembering a mistake is good not to repeat the mistake.

> > 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.

...

Good terminology is the first step toward good engineering.

> 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.

It is trivially easy to make an RFC 2002 compliant mobilie host
have multiple home agents. A mobile host should just send
multiple registration packets.

I even proposed so to mobile WG people and told it too late to be
added, long after which, RFC 2002 was published. :-)

						Masataka Ohta