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

[tirumal reddy <[e-mail]>]

Hi Michael,

Please see inline

On Mon, 22 Feb 2021 at 04:39, Michael Richardson <[e-mail]>
wrote:

>
> 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.
>

I don't think it is possible for the MUD manager to get the same responses
to DNS queries as the IoT device even if both of them use the same DNS
recursive server (e.g., successive DNS queries may never resolve to the
same IP address).


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

Okay.


>
>     > 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 ...
>

ADD WG has adopted DDR and DNR drafts (both are insecure discovery
mechanisms). I am hoping the WG will discuss secure discovery mechanisms
like BRSKI and SZTP for IoT devices.

-Tiru


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