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

From: Henk Birkholz <[email-masked]>
Date: Mon, 4 Jan 2021 19:03:58 +0100

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 4 Jan 2021 21:36:14 +0100

Hi!

I’ve read this document and support its adoption.  Michael is doing a really good job here of making use of BCP in the truest sense of the word.  I suspect this would be a good document to involve the dnsops people in as well.

Eliot

> On 4 Jan 2021, at 19:03, Henk Birkholz <[email-masked]> 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.
> 
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: tirumal reddy <[email-masked]>
Date: Tue, 5 Jan 2021 12:57:09 +0530

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

---

From: "Panwei (William)" <[email-masked]>
Date: Sun, 24 Jan 2021 14:14:03 +0000

I've read the draft and I support the adoption.

Regards & Thanks!
Wei Pan

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Henk
> Birkholz
> Sent: Tuesday, January 5, 2021 2:04 AM
> To: opsawg <[email-masked]>
> Subject: [OPSAWG] 🔔 WG Adoption Call on
> draft-richardson-opsawg-mud-iot-dns-considerations-03
> 
> Dear OPSAWG members,
> 
> 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.
>

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 26 Jan 2021 16:22:44 +0100

Dear OPSAWG members,

this email concludes the call for Working Group Adoption on 
https://tools.ietf.org/html/draft-richardson-opsawg-mud-iot-dns-considerations-03.

We received a reasonable number of positive replies, no objections, and 
some significant comments.

The chairs believe this I-D is ready for adoption and for the working 
group to work on.

Authors please rename the I-D to 
draft-ietf-opsawg-mud-iot-dns-considerations-00, keeping the content as 
is, and resubmit.

Henk