[dns-operations] IP address encryption: pseudonymization

[Paul Hoffman]

On 11 Feb 2018, at 14:09, bert hubert wrote:

> I've already exchanged several emails with Jean-Philippe, But indeed, 
> wider
> exposure to cryptographers would be good. It needs to be noted however 
> that
> we'll never get this to be really tight. It is not real encryption 
> that can
> withstand nation states.

Then we'll be faced with the question of "why not?". There is already 
ways to anonymize IPv4 addresses that have that level of security, but 
at the price of being much slower or of having collisions.

> This is one of the biggeste weaknesses in the current form. ipcrypt 
> has not
> even had a cursory glance. It only has great parents.

Parent (singular), yes. Fortunately, it is also pretty simple to 
analyze, and cryptographers love to one-up each other showing holes in, 
and improving, each other's ciphers.

>> This is why I asked: What do you think the difference between those 
>> versions
>> might be? The current version seems feature-complete.
>
> So people have come up with some nice enhancements. For example,
> pseudonymity can be tweaked so (say) 256 IP addresses all map to 1
> pseudonymous address. This still allows for many analyses, but
> re-identification becomes almost impossible.
>
> Job Snijders came up with the idea of 'class preserving' encryption, 
> so
> private space remains private space, multicast multicast. It is not 
> easy to
> see how this could be done, but perhaps.

This has been done long ago by Cryptopan.
    https://www.cc.gatech.edu/computing/Telecomm/projects/cryptopan/
    http://www.cc.gatech.edu/computing/Networking/projects/cryptopan/icnp02.ps
The description is not as easily actionable as ipcrypt, but it probably 
works fine.

> Remco van Mook came up with the idea to map IPv4 addresses to IPv6
> addresses, which would allow the use of AES all the time, plus perhaps 
> some
> other benefits.

This would cause huge problems with size of logs. Also, lots of systems 
determine whether a source is IPv4 or IPv6 by looking at the size.

> I mostly think however that 'ipcipher2' would incorporate the 
> operational
> experience of ipcipher1 in ways we can't yet predict.  EDNS Client 
> Subnet
> was very educational for me in that respect.  I supported it heartily 
> and
> now it turns out to suck in production, in ways at least I did not see
> coming.

Thanks, that helps. There are currently three options in the document 
that will soon be discussed in RSSAC Caucus, and any of them might be 
considered useful by different parties.

--Paul Hoffman