On Wed, Sep 13, 2023 at 1:47 PM Peter Thomassen <peter@xxxxxxxx> wrote:
Phillip,
On 9/13/23 06:36, Phillip Hallam-Baker wrote:
> There is already a scheme to do what you want, problem is that it isn't quite documented in one place, you need SRV records, DNS service discovery RFC6763 AND the Well Known services hack. This is my attempt to bring that earlier work together:
>
> https://www.ietf.org/archive/id/draft-hallambaker-web-service-discovery-09.html <https://www.ietf.org/archive/id/draft-hallambaker-web-service-discovery-09.html>
[...]
> * All DNS entries are generated automatically and maintained by the service orchestration.
[...]
> Automating the DNS zone management is the key to making DNS based security policy practical.
Quick summary: There's a proposal for secure service discovery, and it requires maintaining DNS entries automatically.
A lot of the proposal already exists, I began by trying to make SRV, Stuart Cheshire's work and DANE to work together and came out with the conclusion that SRV, .well-known and DNS discovery are sufficient. DANE adds nothing.
My proposal is pretty much constrained by the existing specs.
> A system like DANE or Cert Pinning is fine in theory, in practice it falls apart if the administrator doesn't keep the DNS zone up to date and completely correct. Which isn't going to happen without automation.
Your proposal requires automation, too (see above). Why is it that DANE falls apart for lack of automation, while your proposal doesn't?
What I am proposing is not new, people have been proposing similar for 20+ years. So I have to explain what is different this time round and why I expect my proposal to work.
The reason I think my system has a chance of working is that I am providing the entire device management infrastructure from onboarding to decommissioning, I have an infrastructure that provisions the devices with cryptographic credentials, bings their control surfaces to the owner's dashboard, provisions and maintains network configurations, etc. etc.
So what i am really saying here is 'yes, we already have a solution for that (I merely put it together in a coherent fashion), but if you want to use any solution of that type, you really need to think about this other stuff
The lack of automation is the reason DANE and similar have not taken off in the past, that and the DANE group producing a scheme that requires DNSSEC and doesn't actually meet the requirements for Web browser use. While DANE has been successful and useful enabling SMTP/STARTTLS, I consider it to be a niche technology servicing legacy protocols rather than something I am interested in using as a foundation to build on.
On Wed, Sep 13, 2023 at 11:38 PM Mark Andrews <marka@xxxxxxx> wrote:Both can be automated. The RFCs to support this are +20 years old. If people are to lazy to add the small amount of code to web servers to do this they only have themselves to blame. DNS servers have supported DNS UPDATE for decades and have rich policies to specify what can and can’t be updated.
I don't think it is useful to accuse people of being lazy. Integration is a non-trivial task. You can deploy Kubernetes in half a day. Getting it integrated into your systems is a multi-year team effort for even medium sized businesses. Same for SAML, etc. etc. With DNS, the issue is not merely what the spec supports but what the DNS service provider supports.
My approach is to deliver a system that provides a framework for applying all those integrations. So the automation is applied automatically.
