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.

(EDIT: The Noise protocol is not presently in the production version of ZeroTier, but an upcoming version instead. Thanks to api for clarifying this detail.)

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; typically high-bandwidth operations.

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

When this is brought up, it’s 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.

How Would This Affect Protocol Complexity?

Other than rotating a peer’s identity public key every time a group operation is performed, it’s totally backwards compatible with what Noise already does today. No fundamental changes to the transport cryptography needed.

That being said, printing the contents of RFC 9420 clocks in at over 130 pages, so the ratchet tree itself does add overall protocol complexity.

Integrating ratchet trees with a Noise-based protocol will require careful planning and review from other cryptographers.

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.

Header art by Harubaki and AJ.