Hi Paul, in the implementation I suggested, the new DNS RR types are not used for making people (administrator, decision-maker, CISO) communicating together but as an information source that is simple enough to be understood by everyone without the need of filtering and sorting data. I commented that to explain why new types are necessary, although CRC can be replaced with APL.
Why use DNS at all ? Likely many server software can be modified to use the implementation suggested, while creating dependencies to another protocol not already supported by the server looks worse. For example, it's maybe not a good idea to update an FTP or LDAP server to support HTTP only to download a text file containing these networks allowed. And they would probably still need to start by a DNS request to find that file. If the Client DNS (CRC) is lying or not configured as asked by the CISO, the client organization might expose data and it's an internal threat to this organization. If the server DNS (CRS) is lying, the client organization might complain as the contract (if any) is not honored. If all is implemented/configured correctly and one client is lying on its identity (wrong information sent during the authentication for example), there is a mismatch between its real and expected IP addresses, and no authorization at the end. The use-case I'm thinking about is indeed for static entries handled manually. In my past experience, I would say each company I worked for would have benefited of some similar entries (5~10) without thinking "big". The mechanism to authorize these records is somewhat administrative for the CRC (the decision-maker asks the CISO who in turns asks the DNS admin to add a record), and limited for the CRS (a new application is brought online, with its own domain name, and an associated CRS record). As it's intended for Business-to-business, both parts still agree by another kind of contract, and I don't any necessity to have something more for the provisioning. E.A. Le mar. 12 avr. 2022 à 14:28, Paul Wouters <[email protected]> a écrit : > > On Tue, 12 Apr 2022, Eugène Adell wrote: > > > Beyond the technical aspects, there are several different persons to > > think about in our case : the DNS administrator obviously, the > > decision maker buying (or not) a secured online service, and the CISO. > > Why should this information exchange happen via DNS? > > > It looks more simple to have dedicated RR types to let them > > communicate together > > It seems a REST API using some .well-known HTTPS link seems a better > fit ? > > > After your comments and correcting a typo, it gives > > ftp.example.com_21.example.net > > Such domain name for sure doesn't exist and uses the underscore > > character as separator. It has to be considered as storing data > > establishing a kind of contract between the two organizations > > involved. > > It should have a dot in between, eg ftp.example.com._21.example.net. > Then, the underscore name should be uniquely identifying to split it > from other DNS records. eg _crs or something. Have a look at other > documents at > https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names > > > 5. > > I give some explanation in the answer 1 but I will rephrase. The CRS > > record can be used before subscribing to a service (typically any > > storage/log system/SIEM) as an indicator that this service provides > > the kind of authorization process described in the document. > > I still wonder if DNS is really the right fit for this. > > > This document specifies the Client Roaming Control (CRC) DNS Resource > > Record allowing an organization to better control the access to > > third-party applications over Internet. The applications > > implementing an authorization mechanism to honor the CRC, publish on > > their side the Client Roaming Support (CRS) Resource Record to inform > > of this support. > > There is a big overlap here with MUD, see > https://datatracker.ietf.org/doc/html/rfc8520 > > It also seems the source of authorization depends on the DNS name, but > how do you ensure a device would not be lying about their name? Would > this only work on zones with static DNS entries? If so, how would that > scale? > > What would be the mechanism to authorize the publishing of CRS/CRC > records, and why can that provisioning protocol not also be used > to query/signal this data? > > Paul _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
