Definitely. We've had formal design audits, informal audits, and open source audits (like the one that found this issue). Formal audits are in the works.

We're glad this was found and glad that this is the first significant vulnerability report we've received in many years of operation, but we don't want that to make us arrogant. Distributed systems are hard and cryptography is hard. Distributed systems with cryptography are REALLY hard. :)

We've talked to Pulse Security about hiring them in the future. The fact that they found this obscure issue is a pretty strong pitch.

Who did the formal design audit? The collision/overwrite thing seems like it might blur the line between implementation and design.

Trail of Bits, and they did recommend additional scrutiny into dependencies on addresses alone for authentication. They didn't find this specific issue because as you say it is a bit of a design and implementation issue. It required that a weak point in the design be combined with a mistake in implementation somewhere else (roots).

We've fixed the mistake in the roots, and are also fixing the weak point in the design soon with a release. Fixing the roots blocks this specific attack but we want to fix the fundamental weakness to ensure that there are no similar issues in the future.

It does appear the "Node ID" section covers this issue, with the requirement that the public key back up the 40 bit key fingerprint.

What if the controller had a timer that could be set such that the network becomes static and unchanging when it expires?

The public key is bound to the address. The problem is that this binding was not as strong as we thought it was in one edge case. Exploitability relied on another problem in the roots, which is now fixed, so the issue is no longer exploitable.

We are also going to do a release though because we thought of a way to ensure that a complete hash of the address and public key (rather than just the 40 bit address) is always checked in certificates of membership. In retrospect it always should have been this way, but then again all security issues always seem silly and obvious in hindsight.

This will make an exploit of this nature impossible even if the roots are misbehaving, since the certificate of membership won't validate against a colliding identity at all.

It would be nice if the address could be at least 256 bits long, but there's a major ergonomic problem with that. Would you rather join network abcd0123ab12345 or network 8c6e2a2647ee854f469a3bb798e02ba5a8b1812cab229ff129f073e7a80c1202?

If humans could remember and easily type very long strings a lot of information security would be way, way easier. :)

Honestly, I would be okay with a larger bit sized network string.

It’s likely stored as part of automation if done on a large scale , or easy enough to copy/paste from smaller use cases.

I think it would be rare to have to type it, so even the longer string would be worth the irritation for the piece of mind.

Just my honest opinion.

(Huge fan of ZT by the way.)

Might be of interest:

https://www.zerotier.com/wp-content/uploads/2020/10/ZeroTier...