[rssac-caucus] FOR REVIEW: Harmonizing the Anonymization of Queries to the Root

[Paul Hoffman]

On Feb 13, 2018, at 2:59 PM, Wessels, Duane via rssac-caucus <rssac-caucus at icann.org> wrote:
> In addition I would really like to see some kind of summary (table perhaps) that presents the following for the various techniques:
> 
> - advantages / disadvantages

I don't think that is possible to do in a clean fashion. The advantages/disadvantages change radically if you are a:
- RSO
- Researcher
- Person who wants your IP address completely anonymized

> - cryptographic strength (I realize this could be difficult since not all are well-studied at this point).

You also have to define what you mean by "cryptographic strength". If you mean "how much effort would I need to find the random key so I can de-anonymize the rest of the dataset", 3.1 (mixing with truncation) would require 2^128 operations, 3.2 (Cryptopan) would require 2^128 operations unless the RSO used shortcuts to keep certain CIDR classes together, and 3.3 (ipcrypt) should take 2^128 if there are no attacks on the cipher.

> - efficiency (i.e. CPU time to anonymize some amount of (DITL) data).

That's also difficult to measure given that no one has spent time optimizing the implementations. Please remember that you will only be running the mixing function if the mapping does not already exist in the table, and that will be true for the vast majority of the time unless you are under a DDoS that is using randomized source addresses. Also, if you about about to change the key and start another run, you can pre-fill in the table from the previous table and reduce the processing time even further.

> - whether or not "decryption with the same key" is a property of the technique

That is only a property of 3.3 (ipcrypt)

> - known implementations

For 3.1, the implementation is trivial. For 3.2, there are links to the implementations we know about (although they are not well documented). For 3.3, the implementation is given in the reference.

> Also I would like to better understand if the different techniques have any different cryptographic properties when there is at least one known true -> anonymized mapping.  I think we should assume it is trivial for a consumer of the anonymized data to inject beacon queries that would enable them to know the anonymized value of a specific source IP.

For 3.1, there is no linkage between any mappings: that's inherent in AES. For 3.2, there is a linkage if the mapping is in the same prefix as the address in question. In 3.3, if there is no known problem with the algorithm, there is no linkage between any mappings.

--Paul Hoffman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3906 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20180221/dc4782cd/smime.p7s>