Please consider adding a Zero Trust Digital DNAID for the requestor

[rjb4standards]

Please consider adding a "Zero Trust DNAID" for the entity that is requesting service. This will enable a receiver to verify that the entity is authorized to access the requested resource/service.

https://www.energycentral.com/intelligent-utility/post/a-trust-control-plane-for-the-digital-age-t4Li00S02OlbhOu

[cbuijs]

Hi @rjb4standards,

Thanks for bringing it to my attention.

I had a quick look, I didn't hear about it before and it seems to be a fairly new initiative? I do not see any drafts/rfcs. I think it is quite complex and "heavy" to implement, and I am not sure what it solves (yet)... It is something that is still under development?

Are there any reference setups, is this implemented already somewhere, preferable a DNS project that I can peek into (couldn't find any on Github)? I don't grasp the DNS side of the story somehow other then repository/validation maybe? So it would be validation/authorization to/for relaying DNS queries?

As said, I did a "glance" and this were my first impressions (I could be wrong).

Cheers,
-Chris.

[rjb4standards]

@cbuijs Thanks for the feedback. I saw that this work includes a Proxy, which may benefit from supporting Zero Trust Semantics that are becoming more "required" in certain US Government implementations that protect a resource using a Zero Trust verification for a requesting party. See latest guidance from CISA regarding Zero Trust in OT environments. https://www.cisa.gov/news-events/news/cisa-and-us-government-partners-unveil-guide-accelerate-zero-trust-adoption-operational-technology

Zero Trust verification should be supported, but should not be required. An entity requesting access to a Zero Trust resource needs to assert a Zero Trust Identity during initial connection processing, which is verified as trusted before allowing any access to a Resource. I showed an example using the SMTP protocol:
HELO smtp.example.com ZTDNAID: EntityZTDNAID\r\n

[cbuijs]

I think this makes only sense to use encrypted DNS protocols (DOT, DOH, DOH3 and DOQ), by the clients with valid certificates on the TLS/QUIC side of the story with ECH on top to make it waterproof. SDProxy already supports this (both as client and forwarder). Embedding the verification process by adding "headers" into the transport layer would be possible if all ends (Clients/Forwarders/Servers) understand what to do with it.

If it is access to particular categories of sites, and utilize DNS filtering for this, based on the identity and roles/responsibility there should be possibilities, but integration DNS with an AUTH authority is maybe a bit much for DNS to handle. It makes the "first line of defense" that DNS is (it sits before every network transaction), brittle. Especially as DNS is already attacked massively, breaking it now not only breaks DNS but also other access.

It feels a bit overdone for my taste to be honest. There is also the question "what do we trust" and "how would we validate". With DNS in mind, it is first of all, access to DNS itself (which DNS do we trust), it would also which query (or response) do we trust (the domain that needs to be resolved). This adds probably a lot of latency for building up a connection on the application layer...

I am not saying it is impossible, but standardization should be made first...

Again, just thinking up loud :-).

[rjb4standards]

@cbuijs This is a very common question in the Zero Trust community of implementers "There is also the question "what do we trust" and "how would we validate""

This is where an IETF SCITT Trust Registry (Transparency Service) becomes essential. An IETF SCITT Trust Registry, like SAG-CTR include API's to checktrust(ZTDNAID) to verify that an Entity is registered as "trusted" before allowing any access to application functionality.

[cbuijs]

@rjb4standards Is DNS considered an application in that context? Or is it access? Or both? I feel if the application is already trusted, its access is granted? How does that translate to access? I mean in a network way. Do we grant the application access, or its user? What kind of traffic belongs to the application. How does it translate to DNS queries and so on. I think the housekeeping on this will be enormous as these things shift and change all the time. What about applications that are trusted, but not registered? New applications. Applications that change behaviour (including its users), etc.

It feels like DNSSEC, we need everyone to do it before it works completely, which, after many years, is still not true. You can only validate what is signed/registered, and in some cases, validate what is not registered.

Sorry for all the questions, I might need to read all this stuff first I guess :-).

[rjb4standards]

IMO, a DNS server like Bind is considered a Resource in a Zero Trust context and the entities requesting DNS services should present a Zero Trust Identifier so that a Zero Trust Gateway for a DNS Resource can verify that a trust relationship exists between the two.

I very much appreciate you engaging in this discussion, it helps flush out the important details that need to be communicated clearly. Thanks.