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

[grarpamp <grarpamp@xxxxxxxxx>]

On 1/24/19, Christian Huitema <huitema@xxxxxxxxxxx> wrote:
> 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.

Depends on if and to what extent one needs or wishes to speak
to the clearnet hardware that currently exists...

"
Yes, one cannot rationally overload all 128 bits for that without colliding
upon allocated IPv6 space that may appear in one's host stack.
However the 1:1 key network can be larger than 64 or 80 bit. One could
easily play with up to say 125 bits by squatting on entirely
unallocated space. (Unlike the clear mistake CJDNS made by
squatting on space already allocated for a specific and conflicting
real world in stack purpose.) Obviously the common library widths
of 96 and 112 could be keyed. And request could be made for a
formal allocation if compatibility and compliance was felt needed
by some mental gymnastics.

https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
"

Agreed, going from say 64 to 125 bits is not the huge or
universally strong and ideal leap that could be sought for.

And there is the question of secure levels and offloading
(or onboarding as it may be)... at what level would many
users perhaps choose to share their cat pictures...
64, 80, 120, 512? And their finances, affairs, work, email?
Were a slider to exist, where would offloading bulk traffic,
of any given content or purpose, end up being set, and
start to occur? How would you run each as needed?

Do you need a future 8192-bit IPvN in backbone routers
and host stacks to achieve certain strengths and utility
goals? Or can you do it some other way?


> 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.
> ...

For reference...
https://tools.ietf.org/html/rfc3972

> ...
> 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.


ORCHIDv2 is also commonly noted...

https://tools.ietf.org/html/rfc7343

An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
Version 2 (ORCHIDv2)

   This document specifies an updated Overlay Routable Cryptographic
   Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843.
   These identifiers are intended to be used as endpoint identifiers at
   applications and Application Programming Interfaces (APIs) and not as
   identifiers for network location at the IP layer, i.e., locators.
   They are designed to appear as application-layer entities and at the
   existing IPv6 APIs, but they should not appear in actual IPv6
   headers.  To make them more like regular IPv6 addresses, they are
   expected to be routable at an overlay level.  Consequently, while
   they are considered non-routable addresses from the IPv6-layer
   perspective, all existing IPv6 applications are expected to be able
   to use them in a manner compatible with current IPv6 addresses.

   The Overlay Routable Cryptographic Hash Identifiers originally
   defined in RFC 4843 lacked a mechanism for cryptographic algorithm
   agility.  The updated ORCHID format specified in this document
   removes this limitation by encoding, in the identifier itself, an
   index to the suite of cryptographic algorithms in use.
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk