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.birkh...@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 >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg