Per the recent C4ISR Conference (https://c4isrconf.com/) the problem is how to link thousands of connections in a military communications network, that needs reliable, simple encryption?  Foremost in mind is the requirement that this be integrated and operational in Combined Arms, Joint and Coalition contexts. When the concept of identity is baked into the protocol, we loose an ability to evolve solutions. So part of the problem is adaptability and a design that supports experimentation. We need a layered solution that can be modified in Cyber time-frames.
To meet these needs a standard & extensible framework for encrypted communications is absolutely necessary. I would introduce ParrotTalk as an inviting solution.
ParrotTalk as a solution
ParrotTalk is a minimal protocol for establishing a secured link between two computers. It allows for user-defined cipher and encoder. It exchanges Diffie-Hellman parameters with 2048-bit primes/generator to determine the shared key. It uses 2048-bit RSA Public/Private keys only for the purpose of signing the message traffic for Authentication, avoiding issues with RSA Certificate encryption which has been shown to be vulnerable. There are no Certificates, so there is no Certificate Management. It meets the minimal, capable requirements to establish an encrypted connection. Small in scope, wide in applicability.
We deferred the issue of identity verification to a software management layer above the secure connections. This provides a pathway to evolution and experimentation in identity management. The result of this decision implies various things about the encryption layer. It should be the simplest, most-minimal protocol negotiation that can be achieved. It should have the flexibility to specify cipher and encoding.
It must have the ability to encrypt end-to-end, between users (automated or actual). This implies the requirement to have double encryption: a capability to encrypt between computers and also encrypt a layer above over a route of links of computer connections. So we can manage routing, as well as deal with NATs and firewalls protecting internal networks. That would require a naming service and a coordinated bridging service, to bridge links. So we need a doubly layered encryption mechanism. With naming we need an identity solution.
However, the capability to negotiate a second higher layer encryption is missing in ParrotTalk, though the pieces to do so are there. As ParrotTalk was designed carefully to offer building blocks of a componentized, composable, reconfigurable manufacturing design nature, such a second layer of encryption can be realized with this framework. The existence of a naming service and a bridging service are absent. The identity is not present.
View 3 message specification for ParrotTalk-v3.7 Protocol.
Browse the Java code for ParrotTalk.
Browse the Squeak/Pharo code for ParrotTalk.
Given the shortcomings, more development is needed to meet all the objectives in the Problem Space. However, what exists is a simply designed, highly adjustable protocol that could fill the need to have an encryption standard across countries, branches and units. It is flexible enough to sustain evolutionary requirements. It may be able to support TLS-v1.2 and SSH. With such a capability it is an obvious framework for doing automated encrypted traffic analysis.