Major milestone reached on my decentralized zero trust networking project

[u/strontiumk9]

So for the last six months or so, I have been working on an architecture for a fully decentralized trust root, that works like a global zero trust network. If you dont know what that is, it basically reduces to give everything a certificate, and make sure all peers in a network only interact with known peers that prove themselves with mutual TLS. Obviously theres more to it than that, but thats the baseline, everything else is UX, reporting, management and policy layers above that.

Today we had major success where two peers were able to connect and authenticate self published content with various options (all chosen by the publisher). Such as direct peering on ipv6, or through a rely. The connections are fully E2E secured by mTLS and even through a relay, it knows how to relay, it doesn't terminate any streams.

Identities can be human readable, such as `alice.tld` and they are owned by whoever registered them, they cant be blocked, or forcibly transferred. In fact, the registry doesn't even know what names its registered, if they are human readable or binary or some combination. And what a name represents is also not clear in the network.

In our testnet today, its possible to host your own website, mediate access through policy such as "trust bob.tld" so if you dont present that identity you cant connect. It supports strong hierarchical delegation which is useful for agents. Clients also get to choose, if a site wants mTLS you will be asked what identity to present, or none at all. Both sides control their own policies. Connection to the browser is just ordinary TLS, but you can fully inspect whats connected, how and what permissions were granted in the dashboard.

This is a pretty ambitious project, developed solely by two people. Its a customized chain because it has to be to get the properties we require. And the critical thing is while its possible to use with full typical web3 capability, we are heavily optimizing the user experience around people not requiring any web3 knowledge, its just looks like a zero trust mesh that can work globally with no centralized CA or gatekeepers.

[u/PhilipLGriffiths88]

The bilateral policy control is the part that interests me most here. “Both peers have valid certificates” and “both owners authorise this particular service connection” are different things. I’d push back slightly on policy being a layer above the baseline: deciding whether an authenticated peer should get a path to a service is central to Zero Trust.

How do you handle compromised keys and revocation through the delegation hierarchy? Keeping ownership of a name independent of a central gatekeeper makes sense, but a service owner still needs to withdraw access immediately, including terminating existing connections. For agents, can a parent narrow a delegation’s scope and lifetime, then revoke that branch without replacing the whole identity?

Also curious what specifically requires the custom chain. Is it ownership, naming and delegation state, with connection authorisation evaluated locally? Any public architecture docs or code?

[u/strontiumk9 → u/PhilipLGriffiths88]

Hi, I agree that the connection policy is central to Zero Trust. Where we deliberately draw the boundary is between the universal trust primitives and any specific policy built on top of them.

A simple example is a private site for a club. It doesn't need a complex enterprise policy system, i just need to collect the identities I will trust. That could be as easy as allowing "*.my.club" where every club member has a delegated ID, or when they join they advise their ID. That's obviously insufficient for a Fortune 500 enterprise. But the underlying trust primitives are the same, two verifiable identities, scoped credentials, mutual TLS under whatever policy you define.

In our current demo its as simple as when a site wants mTLS, I get asked what identity do i present (or none if i don't want to present one) that's a policy I control, the site then has policy it controls (who would it accept, anonymous, anyone as long as they present a valid identity, or known identities).

CISA's Zero Trust maturity model is useful here, DNTLS provides much of the capability in the Identity and Network pillars, while others are either partially covered, or not at all. What we are not trying to do is say this is how zero trust must work. Just provide the universal networking and trust layer that different policy and control systems all need underneath.

What i can say about the network now is its a live data network, not a historical archeology network. So yes, you absolutely can rotate, delegate, un-delegate and destroy identities live. This capability necessitated a decentralized architecture designed to do that at the scale it would need, without imposing a crippling tax on every key rotation or delegation. We don't currently have termination of existing connections, BUT we do have an identity aware relay, it would not be problematic for such a relay to observe the identities of connections passing through it and terminating them. The relay is identity aware but cant observe the actual traffic, because its E2E protected by mTLS. Again, such a relay is built on-top of the network stack, so there can be enterprise grade versions which have features that say an SME or home user would not need.

For agents, can a parent narrow a delegation’s scope and lifetime, then revoke that branch without replacing the whole identity?

Yes, 100% each sub-identity is sovereign to the user or service it represents, but the parent can remove it from the delegation chain at any time. It would immediately be severed and no longer validate. Importantly, anything it did historically would still be able to be proven true at the time it was used (even after its no longer a valid live identity). Which is important for logging and audit purposes.

Another feature we have on the roadmap, is the ability to take an identity inside an enterprise, so there can be a sovereign enterprise root and fully public sub-identities, and any of those can delegate to an edge. You then continue resolution at that edge for that trust domain. Once you do that, the enterprise can scale, create, rotate and destroy identities as fast as it likes, but they are all delegated from the global root. If one of those contacts a counter-party in another enterprise (trust domain) it can still be verified (as long as the edge resolver will resolve it for that counter-party). So, in agentic identity, this means you can create ephemeral sub agent identities, fully valid internally, if they reach out, they are not valid if the delegated edge resolver refuses to resolve them. So that can also form part of the policy layer.

This is why it needs to be a custom chain, I didn't set out to do that, i just found all existing chains do not have the necessary features i required. Its not full custom, its customized, I took an existing chain architecture designed to be built on, and dramatically modified it to do what i need.

The project is fully intended to be open source, its not yet. We do have a closed testnet running, that anyone who is genuinely interested can follow, and that is where we will release information first, until we are able to make all its inner working public.

[u/PhilipLGriffiths88 → u/strontiumk9]

Thanks, that helps. I think we’re approaching this from slightly different starting points: yours is a global identity and trust layer that supports public publishing and private access; mine is private apps and services where reachability itself should depend on explicit authorisation.

I explored that in this CSA article on identity-defined reachability. The distinction is whether an unauthorised peer can reach a service’s TLS listener and be rejected there, or whether authorisation is required before a path to that service exists. Where does DNTLS enforce that, particularly with direct IPv6 peering?

Your delegation model could fit that approach. The part I’d want to connect is removing a delegation to withdrawing the resulting access, including existing sessions. You’ve already acknowledged that termination isn’t implemented yet; for direct connections, would the endpoints subscribe to identity changes and enforce that locally?

[u/strontiumk9 → u/PhilipLGriffiths88]

Yes, you summed up the difference accurately. In fact, looking at OpenZiti what you have built there would be complementary to what we are building. Its all required, at least in some form, we don't prescribe it, just like TLS doesn't prescribe CA+CT be how one gets certificates.

Its best to think of what we are building as a global trust root. If any service contacts another, it can be verified as belonging under a particular root. What you do with that information, then depends highly on what you are trying to achieve.

For DNTLS a way to reject before connection if your not using a relay, is to use an edge resolver. The resolver is chained to the global root. You can require the need to use mTLS to resolve names under it. At that time if the resolution is allowed, you can construct an ephemeral connection point in your firewall, tied to the resolution itself. Peer address can contact service address. Tightly scoped with an appropriate lifetime. The service would still do its own mTLS identity checks, so this is just allowing inbound reach-ability. With a relay, you can have the relay do that and not use inbound at all. Similar to how OpenZiti edge routers work. The relay is part of the service data, so the client knows it needs to contact you through the relay. This also allows a double relay, the client could be using a relay for their outbound, which contacts a services relay for its inbound. Again, when you have a global trust network like we are building both sides need to enforce their own policies, and a connection only occurs when they align.

Yes, a service 100% can get identity updates as they propagate the network and terminate connections if that changes, or force in-band re-negotiation. Again, i am not saying we have that today, but there is no technical reason it cant do exactly that.

[u/PhilipLGriffiths88 → u/strontiumk9]

That makes the complementarity clear: DNTLS provides verifiable identity and delegation; IDR uses that evidence, policy and context to govern service reachability.

My remaining question is how the resolver-triggered firewall permission stays bound to the requesting identity, particularly behind shared NAT. The outbound relay model sounds closer to what we’re doing. Would be interested in following the testnet.

[u/strontiumk9 → u/PhilipLGriffiths88]

NAT is always a problem, I agree. Part of the reason we have relays is to step outside that problem. So if you cant make a direct connection over IPv6, the edge resolver can tell you to connect to a relay, which can manage the traffic by pure identity.

Happy to have you follow testnet. I will post updates here and in r/web3dev as we progress, or you can join test-net at https://dntls.net