OK Paul, I accept that there is every good reason not to recognized newly created domains immediately. But you are challenging one of the foundational assumptions of DNSSEC which is that ‘security’ means seeing the authoritative zone.

Don’t get me wrong here, I think that idea is a crock. I think the idea that I want to have my machines able to connect up to a newly minted domain the second it comes online is rubbish. The only time I want that is when I am bringing up my own domains. I remember when we had to wait 24 hours for every change in .com, that led to expensive delays.

But the idea that DNSSEC is the be all and end all to DNS security is still a big problem. It solves one problem well but there are far more DNS security problems than just one.

I think that the new model you are moving to is the right one. Instead of regarding the resolver as a passive cache, it is potentially a point where we can edit out the bits of the DNS and the Internet that aren’t safe (or if we are dealing with critical infrastructure, aren’t known to be essential).

What I want though is that we run rather than walk. In particular I think that we want to look at the authentication of records published by the authoritative zones as a separate problem from authenticating messages from the resolver.

In this new world resolvers are no longer interchangeable. A resolver that is taking appropriate security feeds is better than a randomly chosen resolver.

Which is why I want to authenticate and encrypt communications between the stub and the resolver and not just encrypt.

phillip, we’re in agreement this time. i’d like an EDNS option to allow a client to signal “if the policy-based response is different than the dnssec authentic response, please send me both, and sign the former with your SIG(0) key”. clients should be able to select between truth and pravda, having access to provably authentic both. this would enable clients to decide whether to believe the domain owner, or their ISP (or their government who is compelling their ISP), based on stub resolver config knob.

m. bortzmeyer has a JSON schema for dns transactions now. that means we could specify a RESTful API for it and move to TCP/445, using only privately shared keys (no X.509 CA allowed, since this is meant to enable DANE.)

the ingredients and requirements and understanding are finally coming together on this.

This is very similar to the approach I take in Omnibroker. The idea there being an extension of the SAML approach where an assertion consists of a series of statements that answer the question originally asked plus optional Conditions and Advice. The idea of Advice being that a proof chain can be added.

So lets imagine that the client asks the resolver how to connect to example.com to do a _http._tcp connection back comes a reply ‘Use TLS to port 443 of 10.1.2.3’. The response can optionally include a list of DNSSEC and DNS records giving the rationale. But the policy ‘use TLS’ probably came from a HTTP header from a crawler that pinged the site in the past.

At the moment we have a confusion of discovery and policy mechanisms. It should all be in DNS but we can’t get from where we are to where we want to be directly. Presence services tend to be LDAP or REST based.

So the starting point for Omnibroker was a high level interface. But now we have DNS Privacy on the table. So I think we need a low level interface as well.

I don’t think we have to go to TCP. We can of course but that means a performance hit and stops use of anycast. All my transactions work with a scheme of one UDP request packets followed by up to 16 UDP response packets. There is space there for almost any sort of query and/or reply. And I can ask multiple DNS queries in one go and it still works.

As for wanting to force use of DANE, I disagree. DANE is still a science project and it is built on X,509v3 in any case so your statement makes little sense. What I think you mean is don’t build this on the WebPKI which I agree with. This is a platform to build the WebPKI on, not the other way round. Although I would not design a system to deliberately sabotage use either.

The approach I have always looked for is one where each party is their own root of trust. So part of the idea of Omnibroker is that the Omnibroker is selected by the relying party. And all the arguments made for editing ICANN’s DNS zones apply to editing CA issued certs as well.

Here is how I would see it work in an enterprise, the customer replaces their DNS resolvers with broker/resolvers and establishes a private CA. This could be run in-house on the Entrust model or be outsourced. But either way it is closely linked to the DNS/broker service which acts as a hub for managing the enterprise network. The enterprise then contracts with one or more providers of protection streams.

For the home consumer, this is going to have to be a little simpler. Which makes it harder from a design point of view as the requirements of a modern home are essentially the same as a university department back in 1995. I have 50 DHCP leases open right now and that is before I network all the light switches. This is the point where using the WebPKI to enable initial setup is useful. I can control a lot of risks by requiring the broker/trust stream configuration to be mediated by an EV certified provider.

Just to be clear here, yes Comodo does have a product in this area, to the extent that a free service is a ‘product’. The Omnibroker proposal is an attempt to generalize that product and turn it into an open system. All the specifications are public and there is open source code.

I certainly don’t want to be in a position where I have to enable every application on the Internet to use my scheme. So it has to be open to fulfill the purpose.

At the start I was looking at a high level API only. However all the complexity is actually in the initial setup of the security relationship between the client and the resolver. So adding a low level query interface for raw DNS queries is simple.

I agree that layering over HTTPS is a last resort to clean up the 3-5% of network situations where it is not possible to use UDP or DNS transport.

From a business point of view, I am not trying to get rid of CAs. There will always be a role for companies that manage cryptographic apparatus. As soon as cryptography is added to a system the stakes change and it becomes essential to get it right. For example, consider the difference between traditional unix systems and a system using an encrypted file store. On traditional unix, you make a mistake and root privilege can probably save you. On an encrypted file system you make a mistake and nothing can save you.

The point where I think traditional PKI fails is actually on the relying party side. The browser providers are not effective proxies for the interests of the relying parties. They don’t have an effective range of sanctions, dropping the Symantec roots out of the browser is not a credible threat. The cost would be too high.

What this proposal does is to provide an alternative approach where the relying party is in control rather than the subject. So this isn’t subject side PKI like the traditional CA model, it is relying party side. There are problems relying exclusively on either. Different problems have different needs. The WebPKI was only designed to meet the near term needs of Netscape’s IPO. Nothing more.