[messaging] Ronion anonymous routing protocol framework

[James McGlasan]

On Fri, Nov 03, 2017 at 02:19:30PM +0100, carlo von lynX wrote:
> On Fri, Nov 03, 2017 at 12:14:42PM +0000, James McGlasan wrote:
> Who said reliable datagrams aren't an interesting thing? I haven't
> been mentioning UDP at all. I am talking about properly framing
> messages on the application level so that no attacker can later
> fingerprint the stream as it enters or exits the Tor network.
> SOCKS-UDP could be a suitable API, even if the semantics are
> "wrong" since there would not be traditional packet loss.

Unless I'm missing something, UDP is the only SOCKS5 feature that Tor
lacks. The SOCKS5 proxy does support buffering, so in theory the MTU
inside SOCKS5 could be greater than the network that transports it.

I agree that reliable, unordered datagrams are interesting, even ideal
for passing partially ordered messages to actors.

Ideally a channel is configured according to the respective properties
it assumes. Is it reliable? Do we want BBR or do we want a custom
congestion control? Is it ordered? If not ordered, is there some
potentially allocating DAG that'll construct partial ordering?

TCP and UDP are just two configurations of this, and only these two are
exposed by SOCKS5. Traditional software can only pick one or the other.
Specialized software, like the SOCKS5 implementation, would work with
the low level datagrams or configured channels.

> If GNUnet implemented SOCKS-UDP below its circuit emulation layer
> (called CADET), it can have that UDP type of semantics. In GNUnet,
> routing is non-deterministic. It's part of the design to resist 
> sybil attacks, but also protects against phoneme detection.

I.. really need to read up on GNUnet because that sounds odd. :)

> The difference is that encryption and varying degrees of metadata
> protection are provided, but the immediacy of non-blocking packet
> loss makes sense for real-time apps. I wasn't actually speaking
> of those, but rather arguing that all applications could
> provide improved metadata protection properties if they stop
> using TCP on the way in and out of the network. As long as people
> use these tools to surf HTTP sites, they will have not as good
> protection. The web is structurally a threat to privacy.
> 
> So GNUnet can do UDP-like, TCP-like but also reliable datagrams
> which is the right choice to pick for private text messaging etc.
> We have a pubsub API which provides both a history of messages
> as a distributed storage facility, so it's a bit like low-level git.

So https://ipfs.io or https://matrix.org for storage and events
respectively. (Or along similar intent)

> Someday we may even have a working multicast layer over the
> mesh network, that would enable to do distributed privacy apps
> with cloud-like scalability properties: la quadrature du net.

Or just use a simple federated solution like Matrix.

> > If you want UDP over TCP, you gain none of the benefits of UDP.  You may
> > use https://onioncat.org without modifying Tor. Just as OnionCat
> > implements UDP, yes, Tor could do the same for SOCKS5.
> 
> Blocking reliable packets would still be useful, even if they
> are disguised as UDP.  ;)  In fact it's an interesting plan to
> allow for dedicated Tor apps that resist fingerprinting.

I do not see the defence here?

> > Recap or TLDR:
> > 
> >  TCP over Tor: slow setup, low latency, per-hop retransmission.
> >  TCP over HORNET: fast setup, lower latency, whole-path retransmission.
>    TCP over GNUnet: varying setup*, varying latency*, per-hop/neighbor retr.
> 
> *) depends on subsystems and settings and whether the nodes have
>    communicated beforehand.

As you bring this up, I should add for HORNET, if the relays are using
HIPv2 instead of IP addresses, then they may have a little setup delay
approx equiv to a DNS or DHT query per HIPv2 hop, and may cache this
result. HIPv2 has the added benefit of supporting roaming for free, at
the slight cost of per node state. Not per connection.

I guess that GNUnet does a handshake for forward secrecy? HIPv2 too.

> >  UDP over Tor: slow setup, reliable and ordered (blocking).
> >  UDP over HORNET: fast setup, unreliable and unordered.
>    UDP over GNUnet: varying setup*, low latency, unordered unreliable.
> pubsub over GNUnet: varying setup*, varying latency, ordered, reliable,
>       one-to-many recipients, distributed state, per-hop/neighbor retr.
>
> >  Sidenote: one of the benefits of UDP over HORNET is that we can have
> >  send-only services / push notifications that do not leak if the
> >  recipient is actively online or not. We cannot get this feature with
> >  Tor's TLS/TCP core.
> > 
> > Finally, the lowest level protocol that HORNET can expose is similar to
> > IP, just datagrams with a destination and optional return path. With
> > this, we implement SOCKS5 for TCP and UDP.
> 
> Same with gnunet. I think gnunet also offers access to lower layers
> like neighbors-only gossip, but that's not as interesting.  ;)

Is that safe? Sounds like a de-anonymization "feature".

> HORNET and Tor however have a huge advantage over GNUnet:
> They're out there and actually doing their job.
> We're still battling bugs.

Tor is out there. GNUnet AFAIK is out there. HORNET is not yet.