RE: Advantages and disadvantages of using CB64 type of identifiers

> There are two issues: catalog attacks and privacy implications. I have
> already expressed my reservations about the privacy effects of having
> unique identifiers in addresses. I would certainly not recommend that my
> company ships anything like that.

We definitely need to take the privacy concerns into account.
But those concerns might imply the need to change the identifier
periodically, for instance every 24 hours, for some type of communication
such as web browsing client. If we need that, the same approach can be
used when the prefixes change without requiring that the IID is
different for every prefix. 

> You do not need to compute 2^64 keys to start having an effect. Suppose
> that there are N users in the system, and that the bad guys have
> computed a catalog of M keys. The average number of hits that a catalog
> of size N will achieve is approximately NxM/2^64. There are currently at
> least 500M Internet users, it is reasonable to expect some growth, so we
> can set N to about 1 billion -- 2^30. This means you need M=2^34 to get
> at least one hit. That is probably less than a Terabyte of data, i.e.
> pretty soon a single hard disk.

But how would an attacker make use of these precompleted keys?
A possibility is that the attacker knows that all hosts connect
to some well-known http server and the attacker launches a pre-meditated
attack against that web server for all 2^34 prefixes; presumably
the attacker would also need to maintain the state at that server
until one of the hosts try to connect. If we assume that the server
discards the multihoming state after 5 minutes this presumably implies
that the attacker would need to send at least one packet per identity
every 5 minutes i.e. about 50 million packets per second.
And if not every host on the planet connects to a single server then
this isn't sufficient to impact even one host on average.

To use the keys to lauch an attack against communication in progress the
attacker would need to predict when one of the hosts for which it has a key
would communicate with another host with a particular IP address.
And solution which use some context ID would make it
even harder for off-path attackers to take advantage of the keys they've
gathered.

> Everybody should be convinced that, when it comes to cryptography, 2^64
> is actually a small number. SEND alleviates this risk by
> cryptographically link a public key to the entire 128 bits of the
> address. This is NOT overkill.

For crypto in general, I agree.
But I'm not convinced it is required to require the inclusion the prefix
in a CB64 scheme. The hash extension in the send-cga spec is probably
a better approach to make it harder to brute force CGAs.

  Erik