Subject: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Sep 2020 11:20:19 -0400

Another thread is
        active at: https://mailarchive.ietf.org/arch/msg/opsawg/04UY5rDs_ojh97_edY-a4xBPZT4

I meant to wait to post this email until there had been some discussion about
the acceptable-urls document.

From 2018 onwards I have been working with CIRALabs on an IoT security system
for home gateways.  This first two revisions of the effort were very much MUD
focused, and this document was written to capture my experiences with DNS
lookups vs MUD names in MUD files.

This document was presented at the IETF107 virtual interim meeting in April.
The slides are at: https://www.ietf.org/proceedings/interim-2020-opsawg-01/slides/slides-interim-2020-opsawg-01-sessa-operational-considerations-for-use-of-dns-in-iot-devices-wslide-numbers-00

As a big part of the advice is to use the local resolver, whether via Do53,
DoT or DoH, it was suggested that this advice might be better given by the
Adaptive DNS Discovery (ADD).

Perhaps that made more sense when it was the Applications Doing DNS BOF though.
A number of discussions about this document over the summer with the ADD
chairs revealed that the document does not belong in the ADD WG.

The -03 version contains mostly minor editorial changes.
I've decided that, even as a BCP, that it seems to still be using BCP14 language,
and so should include the boilerplate.

I would like the OPSAWG to consider adopting this MUD related document.
It changes no bits on the wire changes to MUD or semantic changes (like my
other document), rather this is guidance to IoT manufacturers.

Name:		draft-richardson-opsawg-mud-iot-dns-considerations
Revision:	03
Title:		Operational Considerations for use of DNS in IoT devices
Document date:	2020-09-22
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/id/draft-richardson-opsawg-mud-iot-dns-considerations-03.txt
Status:         https://datatracker.ietf.org/doc/draft-richardson-opsawg-mud-iot-dns-considerations/
Html:           https://www.ietf.org/id/draft-richardson-opsawg-mud-iot-dns-considerations-03.html
Htmlized:       https://tools.ietf.org/html/draft-richardson-opsawg-mud-iot-dns-considerations-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-richardson-opsawg-mud-iot-dns-considerations-03

Abstract:
   This document details concerns about how Internet of Things devices
   use IP addresses and DNS names.  The issue becomes acute as network
   operators begin deploying RFC8520 Manufacturer Usage Description
   (MUD) definitions to control device access.

   This document explains the problem through a series of examples of
   what can go wrong, and then provides some advice on how a device
   manufacturer can best make deal with these issues.  The
   recommendations have an impact upon device and network protocol
   design.

   {RFC-EDITOR, please remove.  Markdown and issue tracker for this
   document is at https://github.com/mcr/iot-mud-dns-considerations.git
   }

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 24 Sep 2020 18:23:45 +0200

> On 24 Sep 2020, at 17:20, Michael Richardson <[email-masked]> wrote:
> 
> 

I’d like that too.

Eliot

---

From: "Bentley, Taylor (IC)" <[email-masked]>
Date: Thu, 24 Sep 2020 16:45:49 +0000

Hi Michael, all,

Fantastic (continued) work! It's a pleasure to continue following in more-or-less personal capacity. In this same role I am following preparations for the annual global Internet Governance Forum (IGF) and Canadian Internet Governance Forum (CIGF). This includes following the intersessional efforts of the global IGF's 'Best Practice Forum on Data and New Technologies.' They are seeking input on issues that Michael's/CIRALabs work and these guidelines for IoT manufacturers seems to align with. I recommend we (and indeed, have gone ahead and,) connect the dots on these two efforts and perhaps we can highlight some great work in I* organizations in the work of the IGF BPF?

Thanks,

Taylor R.W. Bentley
Telecommunications and Internet Policy Specialist
Innovation, Science and Economic Development Canada / Government of Canada
[email-masked] / Tel: 613-292-9998 / TTY: 1-866-694-8389 
Spécialiste des politiques de telecommunications et d'Internet
Innovation, Sciences et Développement économique Canada / Gouvernement du Canada
[email-masked] / Tél. : 613-292-9998 / ATS : 1-866-694-8389

p.s.-->
Here's the callout from the UNSec support (truly exceptional individuals) for the BPF: 

Dear All, 

The BPF Data and New Technologies is collecting examples of how stakeholders address the challenges related to collecting and using users’ data. The case studies will feed into the BPF's discussions and its workshop as part of the IGF 2020 intersessional work and the virtual IGF2020 meeting in November. 

The BPF is interested in examples of 
•	applications (deployed or under development) that use users’ data to provide benefit to the user, and the measures that should avoid that the collected data may be used to harms the users.
•	frameworks, guidelines, and policies that address challenges and aim to ensure that users whose data is being collected and used, can benefit from their data and do not risk to be harmed. 

The BPF is interested in case studies that are related as well as unrelated to the COVID-19 pandemic.   

Details on the call for contributions can be found here https://www.intgovforum.org/multilingual/content/bpf-data-new-technologies-case-studies . 

We would appreciate to receive your case study by the end of this week - Friday 25 September.

In preparation of the call for contributions, the BPF discussed what could be potential issues and put them together in a ‘Data and New Technologies Issues card’. The issues card can help with putting together a case study.

For more information, please check the BPF Data and New Technologies webpage.

Kind Regards

The BPF Data and New Technologies coordinating team,
Titti, Emanuela, Wim

-----Original Message-----
From: Mud <[email-masked]> On Behalf Of Michael Richardson
Sent: September 24, 2020 11:20 AM
To: [email-masked]; [email-masked]
Subject: [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

Another thread is

I meant to wait to post this email until there had been some discussion about the acceptable-urls document.

From 2018 onwards I have been working with CIRALabs on an IoT security system for home gateways.  This first two revisions of the effort were very much MUD focused, and this document was written to capture my experiences with DNS lookups vs MUD names in MUD files.

As a big part of the advice is to use the local resolver, whether via Do53, DoT or DoH, it was suggested that this advice might be better given by the Adaptive DNS Discovery (ADD).

Perhaps that made more sense when it was the Applications Doing DNS BOF though.
A number of discussions about this document over the summer with the ADD chairs revealed that the document does not belong in the ADD WG.

The -03 version contains mostly minor editorial changes.
I've decided that, even as a BCP, that it seems to still be using BCP14 language, and so should include the boilerplate.

I would like the OPSAWG to consider adopting this MUD related document.
It changes no bits on the wire changes to MUD or semantic changes (like my other document), rather this is guidance to IoT manufacturers.

Abstract:

---

From: tirumal reddy <[email-masked]>
Date: Fri, 25 Sep 2020 13:46:33 +0530

+1.
The problem is not just with public resolvers but also with designated
resolvers. The IoT device supporting MUD must use the encrypted DNS server
discovered in the attached network.

-Tiru

On Thu, 24 Sep 2020 at 21:53, Eliot Lear <lear=[email-masked]>
wrote:

> Mud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mud
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Sep 2020 13:41:46 -0400

tirumal reddy <[email-masked]> wrote:
    > +1.  The problem is not just with public resolvers but also with
    > designated resolvers. The IoT device supporting MUD must use the
    > encrypted DNS server discovered in the attached network.

Yes-ish.

I don't think that we have to mandate use of encrypted DNS servers,
as long as it's the ones on the attached network.

My take is that it is better to use Do53 across the local LAN than public DoH
server.   If the IoT device can be convinced to use the local DoT server, great.
But, your documents in ADD are clearly trying to get there, but we aren't
there yet.

I've been looking for a YANG module that would allow for explicit management
of "/etc/resolv.conf" on a device.  If there is one, I don't know where it
would be.

---

From: tirumal reddy <[email-masked]>
Date: Sat, 26 Sep 2020 13:09:21 +0530

> as long as it's the ones on the attached network.

In the home network use case, if the CPE does not support an encrypted DNS
forwarder, endpoint will discover and use the ISP encrypted DNS recursive
server. The CPE will no longer be able to enforce MUD rules. For instance,
Firefox can discover and use Comcast Encrypted DNS recursive server, see
https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html.

> But, your documents in ADD are clearly trying to get there, but we aren't

In the interim ADD session 2, the consensus is to use DHCP/RA to discover
the local encrypted DNS server.
https://tools.ietf.org/html/draft-btw-add-home-09 extends DHCP/RA and it
also discusses hosting a DoH/DoT forwarder on the home router.

-Tiru

---

From: Eliot Lear <[email-masked]>
Date: Sat, 26 Sep 2020 11:09:32 +0200

Hi Tiru

> On 26 Sep 2020, at 09:39, tirumal reddy <[email-masked]> wrote:
> 
> In the home network use case, if the CPE does not support an encrypted DNS forwarder, endpoint will discover and use the ISP encrypted DNS recursive server. The CPE will no longer be able to enforce MUD rules. For instance, Firefox can discover and use Comcast Encrypted DNS recursive server, see https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html <https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html>. 

Not necessarily.  That is a matter of signaling between the CPE and the ISP.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Sat, 26 Sep 2020 19:02:37 -0400

> https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html.

It's reasonable that Firefox might do that, but I don't see why IoT devices
should follow suit, and that's the point of this document.

Except in some very niche digital signage and kiosk use, I don't think a MUD
file would be appropriate for a general-purpose browser.

---

From: tirumal reddy <[email-masked]>
Date: Mon, 28 Sep 2020 12:22:37 +0530

> Not necessarily.  That is a matter of signaling between the CPE and the

No, the special use domain name (SUDN) does not require any update to the
CPE. The signaling from the endpoint is resolved by the ISP DNS recursive
server and, it is not between the CPE and the ISP.

-Tiru

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Sep 2020 09:03:48 +0200

Tiru

> On 28 Sep 2020, at 08:52, tirumal reddy <[email-masked]> wrote:
> 
> No, the special use domain name (SUDN) does not require any update to the CPE. The signaling from the endpoint is resolved by the ISP DNS recursive server and, it is not between the CPE and the ISP.

All I am saying is this:

     ,--------.          ,---.           ,------.
     |Endpoint|          |CPE|           |ISPDNS|
     `---+----'          `-+-'           `--+---'
         |          1 A/AAAA Query          |    
         | --------------------------------->    
         |                 |                |    
         |        2 Response(A/AAAA)        |    
         | <---------------------------------    
         |                 |                |    
         |                 |3 add ACL/TR.369|    
         |                 | or similar     |    
         |                 |<----------------    
     ,---+----.          ,-+-.           ,--+---.
     |Endpoint|          |CPE|           |ISPDNS|
     `--------'          `---'           `------'

You can substitute “ISPDNS” for whoever offers the CPE (like Google/Eero/etc, so long as the DNS infra and CPE know about one another and agree on a control channel).

Eliot

---

From: tirumal reddy <[email-masked]>
Date: Mon, 28 Sep 2020 12:37:20 +0530

> file would be appropriate for a general-purpose browser.

I quoted Firefox as an example, the proposed mechanism of using SUDN to
discover the ISP encrypted DNS resolver is generic and not specific to
browsers. If the endpoint cannot discover the local encrypted DNS server
(hosted on the CPE) using DHCP/RA, the endpoint will fallback to using SUDN
to discover the one hosted by the ISP.

-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Mon, 28 Sep 2020 12:44:04 +0530

On Mon, 28 Sep 2020 at 12:33, Eliot Lear <[email-masked]> wrote:

> You can substitute “ISPDNS” for whoever offers the CPE (like
> Google/Eero/etc, so long as the DNS infra and CPE know about one another
> and agree on a control channel).
>

Yes, that should work for managed CPE. ISPs and security vendors want to
host a encrypted DNS forwarder on the home router itself, see
https://tools.ietf.org/html/draft-box-add-requirements-00#section-3.1.2 and
https://tools.ietf.org/html/draft-campling-operator-observations-00

-Tiru

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Sep 2020 14:39:15 -0400

tirumal reddy <[email-masked]> wrote:
    >> Except in some very niche digital signage and kiosk use, I don't think
    >> a MUD file would be appropriate for a general-purpose browser.
    >>

    > browsers.

    > If the endpoint cannot discover the local encrypted DNS
    > server (hosted on the CPE) using DHCP/RA, the endpoint will fallback to
    > using SUDN to discover the one hosted by the ISP.

Yeah, but, we really don't want this.

Way better, in my opinion, for privacy,security (MUD), and device ownership
if the IoT device sticks with Do53 on the LAN, rather than encrypted DNS to the ISP.