Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications

[Eugène Adell <[e-mail]>]

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 <[e-mail]> 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