[saag] Re: Draft Charter for ZTCPP(Zero Trust Control and Policy Protocols
Eric Rescorla <[email protected]> Tue, 13 Jan 2026 06:30:53 -0800
| Newsgroups | gmane.ietf.saag |
|---|---|
| Message-ID | <CABcZeBNuW0fHJW4yW9DSVjufJqQzN72zxkEuGzfJgYLyVMW3RA@mail.gmail.com> |
This charter as written is a long way from what would be acceptable. I see two major problems. The first is that it's simply not clear what it intends to do. A lot of this is due to the use of the term "Zero Trust", which, as Richard has pointed out, is a term which has been stretched largely out of meaning by use in marketing, so it doesn't help us understand what you intend to do. This charter shouldn't use it at all in text that is trying to describe what work will happen. Even ignoring that, the actual scope of the WG is way too large: each of the last three items (Dynamic trust and context signaling, Zero Trust control-plane communication, Application of Zero Trust principles within network infrastructure), could potentially be a WG of its own, and the last one could mean essentially anything. More broadly, I just think it's premature to discuss charter text at this point. As I understand the situation, there is quite a bit of deployment of the kinds of technologies that are described in this charter; it's just that they are proprietary and noninteroperable. So what you're asking for isn't for the IETF to develop a conceptually new protocol to address an unsolved problem, but instead to drive towards an industry standard solution that would replace the proprietary solutions. This really only works, in cases where there is support from existing vendors and where they intend to switch to the resulting protocol. In the absence of such vendor support, you just end up with N+1 protocols, which isn't helpful. To that end, what would be most productive here would be for you to pick one specific problem (e.g., solely "Authenticated-before-connect access to protected resources") and come up with a single draft that actually represents a step towards standardization in that area and where there is support from existing vendors. Absent that, I don't think it's useful to discuss WG formation at all. -Ekr On Tue, Jan 13, 2026 at 5:58 AM Aijun Wang <[email protected]> wrote: > > Hi, All: > > Based on the past discussions, we determined to limit the scope of “zero > trust” to “zero trust control and policy protocol”, which is above the TLS > transport layer, accomplishes the aim of “zero trust”, and is also the > necessary standards that are needed for the interoperable operation among > the zero trust solutions from different vendors. > > We would like to seek more feedbacks(suggested expressions) on the > following charters. > > We are also preparing the BoF application in theses days for ZTCPP. > > If you have also interests in this topic, and would like to make some > presentations on the BoF meeting, please let me know. > > Aijun Wang > China Telecom > > ================================== > > # Zero Trust Control and Policy Protocols WG Charter(ZTCPP) > > > > Working Group Name: > > ## Zero Trust Control and Policy Protocols (ztcpp) > > > > ## Area: > > Security (SEC) > > > > ## Chair(s): > > To be determined > > > > ## Problem Statement: > > Existing Internet protocols rely on a default-trust model, where IP > addresses and ports are accessible without prior authorization, and > security measures are applied only after a connection attempt. This model > is increasingly inadequate in today’s threat landscape, especially with > AI-driven, automated scanning and exploitation, where mere network > visibility heightens risk. > > > > Zero Trust Control and Policy Protocols working group aims to eliminate > implicit trust by enforcing continuous authentication, > > authorization, and policy evaluation. Existing Zero Trust deployments rely > heavily on proprietary, > > non-interoperable mechanisms. There is a need for open, interoperable > protocol specifications to > > address these gaps, particularly for authenticated-before-connect access, > control-plane signaling, and enforcement within network infrastructure. > > > > ## Objectives: > > The ZTCPP Working Group will define interoperable protocols and frameworks > that support: > > - Authenticated-before-connect access to protected resources > > - Dynamic trust and context signaling > > - Zero Trust control-plane communication > > - Application of Zero Trust principles within network infrastructure > > > > ## Scope of Work: > > The WG will produce specifications and guidance for Zero Trust protocol > interoperability, > > including authenticated-before-connect mechanisms, in-network policy > enforcement considerations and control-plane requirements. > > The WG will reuse existing IETF protocols where possible and define new > mechanisms only when gaps are identified. > > > > ## Out of Scope: > > - Redefinition of Zero Trust principles or architectures > > - Vendor-specific or proprietary mechanisms > > - Endpoint security technologies unrelated to protocol interoperability > > > > ## Deliverables: > > - Zero Trust Problem Statements and Gap Analysis(Informational) > > - Network-infrastructure aligned Zero Trust considerations > (Informational/BCP) > > - Zero Trust protocol interoperability framework (Informational) > > - Authenticated-before-connect mechanisms (Standards Track) > > - Control-plane protocol requirements (Informational) > > > > ## Milestones: > > - Adopt Problem Statements and Gap Analysis/Network-infrastructure aligned > Zero Trust considerations drafts.(6 months) > > - Adopt framework and requirements drafts(12 months) > > - Adopt authenticated-before-connect draft(18 months) > > - Publish above WG documents as RFCs(24 months) > > - Publish deployment and interoperability guidance(24 months) > > - Re-Charter or Close the WG > > > > ## Coordination: > > The WG will coordinate with SAAG, ACE, RATS, OAuth, and Other relevant WGs. > > ===================================== > _______________________________________________ > saag mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ saag mailing list -- [email protected] To unsubscribe send an email to [email protected]