[Cryptography] Implementing full Internet IPv6 end-to-end encryption based on Cryptographically Generated Address

[Christian Huitema]

On 1/24/2019 9:33 AM, grarpamp wrote:

>>>>> When we communicate with strangers, we can use the following
>>>>> handshaking protocol.
>>>> So here, you only accomplish confidentiality toa stranger. But you
>>>> have no idea which stranger.
>>> This is to achieve end-to-end encryption without CA.
>>>
>>> Prove a specific identity with a specific IPv6 address.
>> You miss the point. Talking with confidentiality to an IP address means
>> nothing.
>> Using null-authentication with any protocol accomplishes the same. You
>> left out how binding that IP address to a psuedo identity would work.
>>
>> If I talk with confidentiality with 2600::c900:9106:adca:dc36 then who
>> am I talking to? You ? Your server? Your phone? The NSA?
>>
>> Besides that, anyone who controls some of the BGP tables or routing
>> can be an instance of 2600::c900:9106:adca:dc36 passing identification
>> of your crypto scheme. So I don't even know if I am talking to the "real"
>> 2600::c900:9106:adca:dc36. And if you meant the IPv6 as a "shared
>> secret" then we have better methods like PAKE to go from a weak shared
>> secret we exchange at a party, to a strong secret we can use to
>> authenticate a private channel.
>>
>> In other words, your proposal is the equivalent to any kind of
>> DiffieHellman key exchange. Now you have confidentiality, you need
>> to authenticate the other party.
> As readers may be aware,
>
> Tor has an interesting capability via OnionCat and OnionVPN
> to join its 80-bits of v2 onion addressing with the IPv6/48
> bits provided by the latter tools to yield a self authenticating
> 128-bit host and internet stack compatible private space.
> This brings IPv6 (UDP, ICMP, all its applications, etc) to
> the Tor overlay.
>
> Tor breaks that with its v3 onions which are much wider.
> As does I2P. And of course CJDNS isn't exctly interop
> friendly.


If you want real integration with IPv6 addressing, the crypto systems
can really only use 64 bits. The top 64 bits are claimed by the routing
system, and the network providers just won't let you put something
arbitrary there. That's a big issue, because if your cryptographic proof
of ownership relies on matching 64 bits, then it is not much of a proof.

The CGA specification (RFC 3972) tried to mitigate that by introducing
the "SEC" field. It tries to make the proof harder by specifying a
number of matching zeroes. There is a tradeoff there. We wanted to
encode the number of zeroes in the address itself: we feared that doing
otherwise would make address spoofing too easy. But we were also worried
about birthday paradox issues. Each bit allocated to the SEC field is
one fewer bit available to differentiate the addresses of hosts on the
same network. The compromise was to pick a 16 bit granularity.

It order to generate the address, the defender has to do O(2^(16*SEC))
trials. In order to generate a matching address, the attacker has to
perform O(2^(61 + 16*SEC)) trials. We felt at the time that it was an OK
compromise between required load at the defender and resulting security.
I am not sure that we were right.

It turns out that there is a huge range of capabilities between Internet
hosts. On a mobile system, doing 2^32 hash trials turns out to be a very
big deal, if only because of the energy it burns. The practical limit is
probably be something like 2^16. But then, the attacker only has to do
2^77 trials to break the hash. Nation state attackers can probably do
that without breaking a sweat. They could also build rainbow tables,
which makes the problem even worse.

We also realize the privacy issues with keeping the same IPv6 address
for a long time, or with keeping the same 64 bit host identifier when a
device moves to a new location. When moving, the devices learns the IPv6
prefix of the network that it visits. The current algorithm is to
generate a new host identifier for that network by hashing the prefix
with a local secret. RFC 3972 did not envisage that. It could be
modified to require hashing the local prefix with the public key, which
would create "private CGA addresses" and would also provide some defense
against rainbow tables. But see the argument about mobile devices above:
they really don't want to wait a minute or two and burn their batteries
before getting an address and being ready to use the network.

Big static servers do not have these limitations and could perhaps spend
a lot of CPU and get a large SEC value. But these big servers also have
no problem getting a PKI certificate, and don't need CGA so much.

Bottom line, back in 2005 we had high hopes that CGA would enable all
kinds of security improvements, be it end-to-end IPSEC or secure IP
Mobility. That did not happen, and hardly anybody uses CGA today. Lots
of the work was done at Microsoft Research, but Microsoft never found a
real reason to deploy CGA in Windows. The real reason is that 64 bits is
too small for crypto.

-- Christian Huitema


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190124/80617fca/attachment.html>