Re: [OPSAWG] 🔔 WG Adoption Call on draft-richardson-opsawg-mud-iot-dns-considerations-03

I support adoption of the draft. My initial comments below:

1)

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"

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
https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-03 (see
https://blog.cloudflare.com/oblivious-dns/).

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
targeted attacks
to the IoT device (e.g., Attacker can advantage of the device
vulnerability).

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 mechanisms
like DHCP/RA (https://tools.ietf.org/html/draft-btw-add-home-10) and DNS
based discovery mechanisms (
https://tools.ietf.org/html/draft-pauly-add-deer-00). Secure discovery of
network provided DoH/DoT resolver is possible using the mechanisms
discussed in
https://tools.ietf.org/html/draft-reddy-add-enterprise-00#section-4.

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
recommend the use of wildcard certificates.

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
enforce the DNS
filtering rules. DNS resolvers can enforce device specific filtering.

Cheers,
-Tiru

On Mon, 4 Jan 2021 at 23:34, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
wrote:

> Dear OPSAWG members,
>
> this starts a call for Working Group Adoption on
>
> https://tools.ietf.org/html/draft-richardson-opsawg-mud-iot-dns-considerations-03
> ending on Monday, January 25.
>
> As a reminder, this I-D describes potential issues and concerns
> regarding the use of DNS names and IP addressed with RFC8520
> Manufacturer Usage Description (MUD) in support of device access.
>
> Please reply with your support and especially any substantive comments
> you may have.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>