If you've paid attention to Hacker News or various technology subreddits in recent years, you may have noticed the rise of VPN companies like Tailscale and ZeroTier. At the core of their networking products is a Noise-based Protocol (often WireGuard).
If you haven't been paying attention to Hacker News or Reddit, that's probably healthy. Keep up the good work.
What's This All About?
Noise is a framework for building protocols based on the Diffie-Hellman key agreement algorithm, combined with a few other cryptographic primitives (authenticated encryption and a hash function). The Noise specification is quite readable, if you want to see what it looks like.
WireGuard and other protocols are built atop the Noise framework, which means that each peer has an ECDH public key (typically Curve25519) and establishing a session generally involves generating an ephemeral ECDH keypair for that recipient.
Thus far, the relationship between Noise-based protocols and the aforementioned companies' use cases has been a happy one: The security and performance are extremely competitive, and the amount of source code needed to support these protocols is minimal.
However, the networking provided by Noise-based protocols is inherently unicast in their design (as most Internet-based protocols you use every day are). Multicast networking is mostly supported through emulation, rather than by low-level protocol design.
Today, I'd like to sketch out an idea of mine for integrating multicast networking support with Noise-based protocols. This idea may be a bit half-baked, but I don't have the free time to analyze it fully and build a demo.
If anyone working for one of these companies believes it's worth exploring, feel free to pick it up and run with it.
Why Multicast?
The classical use case for multicast networking is video conferencing or streaming: High-bandwidth operations that need to be robust against networking outages and failures.
However, there are some other usages of multicast that are more attractive for VPN customers; i.e. it lends well to load-balancing as well as creating more privileged partitions of your network with a public interface.
Elevator Pitch
Use Ratchet Trees from Messaging Layer Security (MLS, RFC 9420) as a primitive for establishing a shared group public key for a subset of nodes in your network.
Then, use the group key as you would a typical ECDH public key in a Noise-based protocol.
You can then encrypt traffic to any node in that subnet and they'll be capable of decrypting it.
Sounds Simple; What's the Catch?
Remember earlier when I mentioned WireGuard? Their homepage gives an example for Cryptokey routing that looks like this on the server side:
[Interface] PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk= ListenPort = 51820 [Peer] PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg= AllowedIPs = 10.192.122.3/32, 10.192.124.1/24 [Peer] PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0= AllowedIPs = 10.192.122.4/32, 192.168.0.0/16 [Peer] PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA= AllowedIPs = 10.10.10.230/32
And may look something like this on a client computer:
[Interface] PrivateKey = gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE= ListenPort = 21841 [Peer] PublicKey = HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw= Endpoint = 192.95.5.69:51820 AllowedIPs = 0.0.0.0/0
This is elegant and works beautifully for its intended use case, but adding multicast complicates matters.
Most significant: Your group key will ratchet forward every time you perform a group operation (e.g., adding or removing a node).
Whether this is a significant obstacle for the tooling these companies already provides is not my place to speculate.
As I said above, the idea is somewhat half-baked, so there may be other complications staring me in the face that I'm oblivious to.
A Subtlety of Ratchet Trees
One of the really cool things about Ratchet Trees from MLS, that probably doesn't get talked about enough, is that any peer in a tree could secretly be an entire separate tree and the top-level group will have no idea (unless it's, like, the only node that rotates its key often).
This is often highlighted as a boon for multi-device support. In federated messaging protocols, it's one way to obfuscate some social graph metadata from being observable to outside observers.
Closing Thoughts
Is this idea a good one? Is it doomed from the start? Will this effort be doomed by the advent of a cryptography-relevant quantum computer before any code gets written?
Who's to say? I don't really have the time to flesh it out and explore it fully.
Art: CMYKat
Header art by Harubaki and AJ.
No comments:
Post a Comment