Subject: [OPSAWG] revisions in draft-ietf-opsawg-mud-iot-dns-considerations-01

From: Michael Richardson <[email-masked]>
Date: Sun, 21 Feb 2021 18:09:32 -0500

Reorganized your comments to bring the discussion to the top.

    > 5) Wildcard certificates are also commonly available which allowed for
    > an infinite number of possible names.

    Comment> https://tools.ietf.org/html/rfc6125#section-6.4.3 does not
    Comment> recommend the use of wildcard certificates.

okay, but they are widely used in Enterprises, and the point here is that
having a unique name for each product model's download server should not be a
burden.
So, while I'm not trying to disagree with RFC6125, I don't think it materially
matters here.

    > 6) Where the solution is more complex is when the MUD controller is
    > located elsewhere in an Enteprise, or remotely in a cloud such as when
    > a Software Defines Network (SDN) is used to manage the ACLs.  The DNS
    > servers for a particular device may not be known to the MUD controller,
    > nor the MUD controller be even permitted to make recusive queries that
    > server if it is known.  In this case, additional installation specific
    > mechanisms are probably needed to get the right view of DNS.

    Comment> The MUD controller can program the Enterprise DNS resolver to
    Comment> enforce the DNS filtering rules. DNS resolvers can enforce
    Comment> device  specific filtering.

I think that your comment misses the point.
It isn't about DNS filtering, it's about the MUD controller getting the same
view of DNS as the device.

tirumal reddy <[email-masked]> wrote:
    > Use of DoT to a local DNS recursive resolver is a preferred choice,
    > assuming that the trust anchor for the local DNS server can be
    > obtained, such as via [I-D.reddy-dprive-bootstrap-dns-server].

    Comment> I would replace DoT with "Encrypted DNS connection"

Done.

    > 2) The use of DoT and DoH eliminates the minimizes threat from passive
    > eavesdropped, but still exposes the list to the operator of the DoT or
    > DoH server.

    Comment> The threat is further minimized by the use of oblivous DNS
    Comment> https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-03
    Comment> (see https://blog.cloudflare.com/oblivious-dns/).

Done.

    > 3) IoT devices that reach out to the manufacturer at regular intervals
    > to check for firmware updates are informing passive eavesdroppers of
    > the existence of a specific manufacturer's device being present at the
    > origin location.

    Comment> Identifying the IoT device type empowers the attacker to launch
    Comment> targeted attacks to the IoT device (e.g., Attacker can advantage
    Comment> of the device vulnerability).

Done.

However, I don't want to overstate this.
An attacker internal to the network, for which internal ACLs do not work
(because of lack of L2 hairpinning) may be able to fingerprint the device
independantly, and attack it directly.
An attacker external to the network, should not, given appropriate incoming
MUD ACLs, be able to even connect to the device.

So, I'm really more worried about privacy issues here.

    > 4) IoT Devices should prefer doing DNS to the network provided DNS
    > servers.  Whether this is restricted to Classic DNS (Do53) or also
    > includes using DoT/DoH is a local decision, but a locally provided DoT
    > server SHOULD be used, as recommended by
    > [I-D.reddy-dprive-bootstrap-dns-server] and [I-D.peterson-doh-dhcp].

    Comment> ADD WG is currently only focusing on insecure discovery
    Comment> mechanisms like DHCP/RA
    Comment> (https://tools.ietf.org/html/draft-btw-add-home-10) and DNS
    Comment> based discovery mechanisms
    Comment> (https://tools.ietf.org/html/draft-pauly-add-deer-00). Secure
    Comment> discovery of network provided DoH/DoT resolver is possible using
    Comment> the mechanisms discussed in
    Comment> https://tools.ietf.org/html/draft-reddy-add-enterprise-00#section-4.

Done.  Only, draft-reddy-add-enterprise has expired ...

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide