Yes, the Achilles heel of security policy today is knowing if it is accurate or not.
But consider the fact that for all existing Internet protocols, the default is insecure.. That means that we have two possible approaches to moving to a default secure internet:
1) Replace every existing Internet protocol with one that is default secure.
2) Work out how to make security policy work.
Designing a complete replacement protocol suite is not impossible. In fact I have done exactly that. But as we all know, deployment of such a suite is another matter. So if we are to make the Internet default secure, we need to focus on (2).
One possible fix for this situation is to add an attribute to security policies that describes the preparation mechanism so that relying parties can handle the resulting assertions appropriately and includes a time stamp.
But really, it is not a problem if people misconfigure their network and their systems fail as a result. In fact that is the desired outcome here.
The key to making security policy accurate is to automate the process of publishing it. So the infrastructure that is responsible for bringing up a service host also causes the corresponding DNS records to be provisioned.
This doesn't have to be a pipe dream, this is exactly the sort of thing that kubernetes and such are supposed to be up to. I go a stage further with the Mesh Service management architecture because I don't want my host images to contain the private keys used for TLS, host authentication etc. Right now this is slideware but I think it shouldn't take too long to make it real:
* Host image has a unique set of device base key contributions.
* Each time the host image is started, it contacts the management service and obtains a set of activation key
contributions
..
* The keys used by the host for TLS, service authentication, etc. etc. are generates as a combination of the
base key contributions and activation key
contributions
* Once the host is ready to process service requests it notifies the management service
*
The
management service performs any network configuration changes that may be required to enable service (e.g. firewall rules).
* The management service calculates all the necessary DNS entries including security policy entries for the service and publishes them (and publishes any other entries in other services that might be required).
* The management service monitors the status of the host continuously and reacts appropriately in the case that it should fail.
* The management service reverses all the above in the case that the service is shut down (with appropriate handling of planned and unplanned termination).
Personal note:
We are 1/5th the way through the 21st century at this point. It is long past the point where we can or should consider manual configuration of Internet hosts and service as being normal practice. The idea that those of us who manage our systems in a maintainable fashion should be required to accommodate the folk trying to do things by hand is bunk.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
