<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>On 1/24/2019 9:33 AM, grarpamp wrote:<br>
</p>
<blockquote type="cite"
cite="mid:CAD2Ti2-8Gb_-KiNMuJ7N-uViQEJse_nj9NBpNgo+LfZFn+u2Hg@mail.gmail.com">
<blockquote type="cite" style="color: #000000;">
<blockquote type="cite" style="color: #000000;">
<blockquote type="cite" style="color: #000000;">
<blockquote type="cite" style="color: #000000;">
<pre class="moz-quote-pre" wrap="">When we communicate with strangers, we can use the following
handshaking protocol.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">So here, you only accomplish confidentiality toa stranger. But you
have no idea which stranger.
</pre>
</blockquote>
</blockquote>
<blockquote type="cite" style="color: #000000;">
<pre class="moz-quote-pre" wrap="">This is to achieve end-to-end encryption without CA.
Prove a specific identity with a specific IPv6 address.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<p><br>
</p>
<p>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.</p>
<p>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. <br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p>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.</p>
<p>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.</p>
<p>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.<br>
<br>
-- Christian Huitema<br>
</p>
<p><br>
</p>
</body>
</html>