It has been apparent to me for several years that the IETF needs to have a better approach to service discovery and that SRV like technologies should be a part of that solution.
Making DANE work with SRV discovery seems to be a good idea. But it is a piecemeal approach that I think is unlikely to help adoption of DANE or SRV type discovery. Rather than look at the problem from the point of view of making two existing technologies play nice together, it is better to approach the bigger problem we are trying to solve. I don't think DANE can be made to work nicely with SRV, NAPTR and the rest as people would like. But working the other way around and proposing a new discovery record that has support for DANE built in does allow a 'fluent' result. Proposing new discovery mechanisms is not to be done lightly but neither SRV nor NAPTR is adequate for Web Services in any case. SRV only provides a redirection to a domain name, Web Services require the ability to host multiple Web Services on the same server under the same domain name. Hence the need for the URI proposal. SRV records don't have quite enough power, NAPTR records have too much. They were designed to support URN discovery and not service discovery. Constraints: 1) The IETF has three separate prefix based discovery mechanisms: SRV, NAPTR and URI (proposed) in addition to A and AAAA. 1a) Protocol designers should not choose the discovery mechanism because the constraints that affect the choice of mechanism are all constraints that fall on the network administrator deploying the system. 1b) The design of DNS makes the use of multiple records for the same purpose highly unsatisfactory and inefficient. 1c) SRV and NAPTR are already deployed and so any accommodations have to be made in DANE. 2) The IETF has also proposed two separate mechanisms for asserting a PKI policy information. There is DANE and there is HTTP certificate pinning. 3) Application providers tell us that they will only perform a limited number of DNS lookups to support discovery. At the moment they are required to do A, AAAA, and possibly SRV or NAPTR as well plus potentially a whole additional resolution chain afterward. Assertions A1: There should not be a choice between mechanisms, there should instead be an order of precedence so that if there is a record of type X it will take precedence over all the other types of record. A2: Rather than trying to force a choice between mechanisms asserting or pinning a public key, the discovery mechanism should be agnostic and support both. These considerations result in the following design. We introduce a new record, the URII record that has the same syntax as the existing URI record proposal but instead of the target being just a URI, it is a URI followed by optional discovery parameters: _service1.example.com URII 10 10 "https://ws.example.com/service1/"; _service2.example.com URII 10 10 "https://ws.example.com/service2/ dane" _service3.example.com URII 10 10 "https://ws.example.com/service3/ pin=foo" Service1 simply redirects to a Web Service URI just like the current URI scheme does. Service2 and Service3 have a redirect but also provide TLS policy information. In the first case the discovery record says 'look for DANE records' in the second case the HTTP pinning data is specified. Note that the discovery parameters could also tell us other things we might want to know, whether to look for an A or AAAA record for example. Rules for processing URII records would be as follows: 1) If a URII record set is present it takes precedence over all A, AAAA, SRV, NAPTR and URI record sets. 2) Unless the specification of the Web Service explicitly states that other record types are not supported, Web Services MUST specify A, AAAA, SRV or NAPTR records to support discovery by clients that do not support URII. The motivation behind this particular dance is to enable optimization and rationalization of the discovery process as a whole rather than piecemeal additions that create even more complexity. The DNS protocol only supports queries for one RR type at a time, there are multiple areas of interest that would all like to add in a little nugget of information into the discovery process. Special pleading is not going to work. There is never going to be consensus that applications should support DANE or TLS cert pinning or any one of the dozens of schemes that have been proposed. At the moment everyone concentrates on the arguments why their pet project should have priority. That is not productive. If we are going to get anywhere then it has got to stop being a choice between extended discovery for DANE vs extended discovery for other purposes. We have to have one mechanism that can satisfy every requirement to hook a little bit of extra data into the discovery process if any of those requirements is going to be satisfied. -- Website: http://hallambaker.com/
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
