On Sun, Feb 24, 2019 at 12:55 PM Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
I'm not sure where this query goes, so ietf@xxxxxxxx.
Outside of the IETF there seems to be a good tradition of versioning RESTful
APIs using URLs like /api/v1.0.0 or such.
I think that the IETF already has the answer to the problem you are raising. But it is spread out so that while the existing standards essentially constrain the space, there is no RFC that puts them together and so I wrote one myself:
This has expired but will be replaced in a few hours time. I am in fact updating the whole document set right now.
The problem as I see it is how does a client:
* Discover an Internet service.
* Select between the Hosts offering that service.
* Obtain credentials for the host it is connecting to.
SRV is not quite enough. You also need to have information that describes the services you are connecting to. This part is described in RFC6763.
RFC6763 is the way more protocols negotiate connections than anything else but when it was proposed, some folk thought that it was the wrong approach so it got pushed into a corner and largely ignored in IETF.
There are a few issues I have with RFC6763, the main one being that it is written as a set of options for protocol designers. I don't want there to be a choice of discovery mechanisms. I want this to be an IETF standard specifying EXACTLY ONE way to do things. That way we can have a DNS resolution protocol of the form 'find a XYZ service on example.com which supports versions 1.3-3.0 with ASN.2 encoding' and it can respond.
The other issue I have is a consequence of the first. I don't want every protocol to specify a different set of TXT attributes describing the service and a different way to manage them, I want these to be an IETF standard common to as many protocols as possible. That allows me to use one set of management tools to administer all my services on a machine.
Standards are good.
So lets take a DNS configuration for my Mathematical Mesh service:
_mmm._tcp.example.com SRV host1.example.com 0 10 80 host1.example.com _mmm._tcp.example.com SRV host2.example.com 0 40 80 host2.example.com _mmm._tcp.example.com TXT "version=1.0-2.0" mmm.example.com CNAME host3.example.com host1.example.com A 10.0.1.1 host2.example.com A 10.0.1.2 _mmm._tcp.host2.example.com TXT "path=/service" host3.example.com A 10.0.1.1 host3.example.com A 10.0.1.2
Here we have two hosts that offer the service but with slightly different configurations. Both hosts support versions 1.0 to 2.0 inclusive. Host1 offers the service on the default .well-known/srv/mmm/ path while host2 specifies a different path.
Note that this configuration has fallback for the case where the SRV and TXT records can't be resolved. This is essential because in the real world, 100% compatibility with legacy infrastructure is an absolute requirement. So if the client cant get an SRV record, it tries mmm.example.com because that can be made to work on the most antique setups.
So my response to Michael is that you don't want your version numbers in the .well-known path, you want them in the DNS records because then they can be used to select the host to connect to according to capabilities.
Lets say we have 10 hosts and we are upgrading them to a new version of the spec over a two year period (licenses sometimes cost money, people always do). So we might upgrade 2 hosts to start with and advertise the fact with host specific TXT records.
We can even do a multi-tiered scheme in which we have multiple mail delivery services advertised and the client selects the one it prefers.
This scheme provides an obvious means of advertising host specific information relevant to TLS. We could specify a host specific key in a TXT record that could be used to encrypt the initial TLS handshake. We could specify the fingerprint of a certificate that must be in the Certificate path for the service certificate. We can specify a minimum TLS version.
Of course, to actually make use of a scheme like this in actual deployment, the DNS records have to be 100% reliable. Which is not going to happen if they are being maintained by hand. So an adjunct specification that would be required is a means of automating the management of the DNS records. When the service comes up and every n minutes thereafter, it should ping the outbound DNS to tell it that it is still alive and what current configuration information it needs to publish.
The ability to secure attributes of this type gives DNSSEC the potential to improve application security. We can now specify that the service MUST be encrypted.
