[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The cost of privacy (was Re: Notes about identifier - locator separator)
> 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
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
> > 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
> 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. :-)