Subject: Re: [Mud] Unique credentials for devices in a home network

From: Michael Richardson <[email-masked]>
Date: Sun, 26 May 2019 21:28:25 -0400

In a private email, it was written:
    > Okay, I admit I never realized there was an assumption built into MUD that
    > the MUD enforcement point would be able to spy on DNS queries. I guess I had
    > assumed one could do reverse DNS, and if that meant some lazy blocking, so be
    > it.

I don't know if it's an assumption built-in to MUD.

The assumption in MUD is that a rule can be written in MUD that addresses
end points by name, and that if the MUD controller does it's own forward
lookup, that it gets the same results as the IoT device.
(I wish lookup by reverse worked, and I've long argued that allowing anything
on the network without useful reverse DNS is a bad thing, but I've lost that)

Google, Akamai, Facebook, Amazon, Azure, etc. all provide for (IoT device)
termination by DNS where the result returned depends upon who asks.  This is
done for geolocation and load balancing reasons.  Used to be it was all
RR DNS queries with TTL-0 results, but providers realized that this screwed
up the caching properties on their servers, and it was better to point a
given user/host consistently to an entry server.

If the MUD-controller can query the same recursive caching DNS server that the
IoT device will likely get the same answer from the cache.  So we have a high
probability of winning.

DNS-o-HTTPS bypasses all that local caching.

I believe that we need to write a "Operational Considerations of DNS lookups
in MUD files" document.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Mon, 27 May 2019 06:23:28 +0000

To add to what Michael said the requirement is for consistency between the client and the enforcement point. There are several ways to do that with regard to DNS names. One is to snoop DNS. Another is for the resolver to coordinate with the enforcement point. Arguably the latter is the better approach but requires more work. 

The one mechanism that will certainly not work is DOH when the end device ignores to resolve are handed to it by DHCP.

Eliot

> On May 27, 2019, at 03:28, Michael Richardson <[email-masked]> wrote:
> 
> 
> Mud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mud

---

From: tirumal reddy <[email-masked]>
Date: Mon, 27 May 2019 15:25:10 +0530

If multiple domains are hosted on the same IP address and the IoT device
uses DOH, the enforcement point will not know the domain the IoT device is
visiting. Further, MUD controller may not even know the DOH server used by
the IoT device.

Google supports domain fronting for its DOH server (see
https://mailarchive.ietf.org/arch/msg/doh/95MtwTSUxcSVCUCxjaBhpx0m98Y).

Cheers,
-Tiru

On Mon, 27 May 2019 at 13:41, Eliot Lear (elear) <[email-masked]> wrote:

> To add to what Michael said the requirement is for consistency between the
> client and the enforcement point. There are several ways to do that with
> regard to DNS names. One is to snoop DNS. Another is for the resolver to
> coordinate with the enforcement point. Arguably the latter is the better
> approach but requires more work.
>
> The one mechanism that will certainly not work is DOH when the end device
> ignores to resolve are handed to it by DHCP.
>
> Eliot
>

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Mon, 27 May 2019 10:04:23 +0000

Absolutely true.  And that matters if there is a vast quantity of crap on those IPs.  Worth keeping in mind. But this isn’t do much a MUD problem as more of a General hygiene matter.  You are likely to block IPs with garbage on them regardless of whether MUD is in play.

Eliot

On May 27, 2019, at 11:56, tirumal reddy <[email-masked]<mailto:[email-masked]>> wrote:

If multiple domains are hosted on the same IP address and the IoT device uses DOH, the enforcement point will not know the domain the IoT device is visiting. Further, MUD controller may not even know the DOH server used by the IoT device.

Google supports domain fronting for its DOH server (see https://mailarchive.ietf.org/arch/msg/doh/95MtwTSUxcSVCUCxjaBhpx0m98Y).

Cheers,
-Tiru

On Mon, 27 May 2019 at 13:41, Eliot Lear (elear) <[email-masked]<mailto:[email-masked]>> wrote:
To add to what Michael said the requirement is for consistency between the client and the enforcement point. There are several ways to do that with regard to DNS names. One is to snoop DNS. Another is for the resolver to coordinate with the enforcement point. Arguably the latter is the better approach but requires more work.

Eliot

> On May 27, 2019, at 03:28, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
> [email-masked]<mailto:[email-masked]>

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

---

From: tirumal reddy <[email-masked]>
Date: Mon, 27 May 2019 15:45:21 +0530

On Mon, 27 May 2019 at 15:34, Eliot Lear (elear) <[email-masked]> wrote:

> Absolutely true.  And that matters if there is a vast quantity of crap on
> those IPs.  Worth keeping in mind. But this isn’t do much a MUD problem as
> more of a General hygiene matter.  You are likely to block IPs with garbage
> on them regardless of whether MUD is in play.
>

No, a IP address can serve both benign and malicious domains, just because
a malicious domain is hosted on the same IP address simply blocking the IP
address is not a good technique, access to benign domains will also be
blocked. Firewalls typically grey-list such IP addresses and inspect the
traffic.

-Tiru

>
> Eliot
>
> On May 27, 2019, at 11:56, tirumal reddy <[email-masked]> wrote:
>
>> To add to what Michael said the requirement is for consistency between
>> the client and the enforcement point. There are several ways to do that
>> with regard to DNS names. One is to snoop DNS. Another is for the resolver
>> to coordinate with the enforcement point. Arguably the latter is the better

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Mon, 27 May 2019 11:50:02 +0000

You can do the same here. What has one advantage: you know the purpose of the communication.

Eliot

On May 27, 2019, at 12:16, tirumal reddy <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, 27 May 2019 at 15:34, Eliot Lear (elear) <[email-masked]<mailto:[email-masked]>> wrote:
Absolutely true.  And that matters if there is a vast quantity of crap on those IPs.  Worth keeping in mind. But this isn’t do much a MUD problem as more of a General hygiene matter.  You are likely to block IPs with garbage on them regardless of whether MUD is in play.

No, a IP address can serve both benign and malicious domains, just because a malicious domain is hosted on the same IP address simply blocking the IP address is not a good technique, access to benign domains will also be blocked. Firewalls typically grey-list such IP addresses and inspect the traffic.

-Tiru

Eliot

Cheers,
-Tiru

Eliot

---

From: tirumal reddy <[email-masked]>
Date: Mon, 27 May 2019 18:23:28 +0530

> You can do the same here. What has one advantage: you know the purpose of

Yes, encrypted traffic inspection is possible in Enterprise networks
(acting as TLS proxy) but not in home networks. If the enforcement point in
home network cannot snoop/inspect DNS traffic, looking into the traffic to
the IP address will not not reveal the domain name with TLS 1.3 and ESNI.

Cheers,
-Tiru

>
> Eliot
>
> On May 27, 2019, at 12:16, tirumal reddy <[email-masked]> wrote:
>
>>> The one mechanism that will certainly not work is DOH when the end
>>> device ignores to resolve are handed to it by DHCP.
>>>
>>> Eliot
>>>

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Mon, 27 May 2019 13:02:41 +0000

Right but you can match the IP address too query response to a domain name in a MUD file and have an understanding that the device is likely communicating with that site as designed.  That doesn’t mean the device isn’t hacked and talking to a BoT cnc on the same address.  But there is at least a good chance it’s doing what it’s supposed to be doing. As opposed to a general purpose computer, where you get no hints.

Eliot

On May 27, 2019, at 14:54, tirumal reddy <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, 27 May 2019 at 17:20, Eliot Lear (elear) <[email-masked]<mailto:[email-masked]>> wrote:
You can do the same here. What has one advantage: you know the purpose of the communication.

Yes, encrypted traffic inspection is possible in Enterprise networks (acting as TLS proxy) but not in home networks. If the enforcement point in home network cannot snoop/inspect DNS traffic, looking into the traffic to the IP address will not not reveal the domain name with TLS 1.3 and ESNI.

Cheers,
-Tiru

Eliot

-Tiru

Eliot

Cheers,
-Tiru

Eliot

---

From: tirumal reddy <[email-masked]>
Date: Mon, 27 May 2019 18:59:11 +0530

On Mon, 27 May 2019 at 18:33, Eliot Lear (elear) <[email-masked]> wrote:

> Right but you can match the IP address too query response to a domain name
> in a MUD file and have an understanding that the device is likely
> communicating with that site as designed.  That doesn’t mean the device
> isn’t hacked and talking to a BoT cnc on the same address.  But there is at
> least a good chance it’s doing what it’s supposed to be doing. As opposed
> to a general purpose computer, where you get no hints.
>

Yup, the MUD file also has to provide the DOH/DOT server used by the IoT
device, so both IoT device and MUD controller use the same DNS server.

-Tiru

>
> Eliot
>
> On May 27, 2019, at 14:54, tirumal reddy <[email-masked]> wrote:
>
>>> Absolutely true.  And that matters if there is a vast quantity of crap
>>> on those IPs.  Worth keeping in mind. But this isn’t do much a MUD problem
>>> as more of a General hygiene matter.  You are likely to block IPs with
>>> garbage on them regardless of whether MUD is in play.
>>>
>>
>> No, a IP address can serve both benign and malicious domains, just
>> because a malicious domain is hosted on the same IP address simply blocking
>> the IP address is not a good technique, access to benign domains will also
>> be blocked. Firewalls typically grey-list such IP addresses and inspect the
>> traffic.
>>
>> -Tiru
>>
>>
>>>
>>> Eliot
>>>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 May 2019 13:09:03 -0400

tirumal reddy <[email-masked]> wrote:
    > If multiple domains are hosted on the same IP address and the IoT device uses
    > DOH, the enforcement point will not know the domain the IoT device is

    > https://mailarchive.ietf.org/arch/msg/doh/95MtwTSUxcSVCUCxjaBhpx0m98Y).

I found that mail message a bit cryptic.
I think that the point is that all of the google end-point DC entry points provide
DoH services, and we can't tell searches from DNS lookups?

There is definitely a tension here between supporting DNS privacy, working
around censorship on the Internet, and having security of IoT devices.

Do we need to write an Operational BCP for IoT and DNS here?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 May 2019 13:13:52 -0400

tirumal reddy <[email-masked]> wrote:
    > No, a IP address can serve both benign and malicious domains, just because a
    > malicious domain is hosted on the same IP address simply blocking the IP

Yeah. It's a feature of IPv4 scarcity that multiple domains on the same end
point is not unusual.  That's a feature if you worry about censorship,
and a failure if you worry about malware domains.

How we inspect traffic without forced TLS official-MITM I don't know.
(What's the polite term for doing this?)

In the home MTIM the TLS connection just seems like a terrible thing, and it
fails in Enterprises outside of Windows-Group-Policy (including, BYOD, but
not limited to BYOD)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 May 2019 13:36:22 -0400

> You can do the same here. What has one advantage: you know the purpose of the

Not understanding you here. (Aren't you supposed to be AFK?)
  "same here" <- grey list?

How do we know the purpose of the communication if an IP has benign
and malicious domains on it?

I can see that if a MUD file lists "benign.example.com" with IP 2001:db8:85a3::8a2e:370:7334
and badguy.example.com is also on that address.   We don't know that of
course.  Lets say that "victim.example.com" is also on that address.

I guess there are several situations here.
1) 2001:db8:85a3::8a2e:370:7334 is the nearest entry to a data center that
   handles hundreds of domains.  It could use SNI to patch connections
   through, or it could terminate TLS itself.

   In this case it's not that the system is compromised, it's just that
   MUD can't protect victim.example.com from compromised IoT devices that
   also have legit reason to talk to benign.example.com.

   Operational advice may be: don't do this in IPv6, instead use the richness
   of the IPv6 space to route a /64 to each TLS DC end point and spread
   things out.  The downside is that is makes censorship much easier too.

2) 2001:db8:85a3::8a2e:370:7334 is the address of only benign.example.com.
   An attacker compromises benigh.example.com (or the servers behind it),
   in order to host badguy.example.com, perhaps to put their command and
   control server there.
   In this case, it seems that the IoT cloud server has actually been
   compromised, and the difference in name is inconsequential from a MUD
   point of view.
   It's not a MUD problem.

3) 2001:db8:85a3::8a2e:370:7334 is the address of benign.example.com
   and it *also* (intentionally) provides a DNS-over-HTTPS service for the
   IoT devices.  If the names returned by DoH are the same as would be
   returned to the MUD controller by regular DNS, then there is no problem.

   Of course, the DoH server has no real idea what might be returned, nor
   does the MUD controller.  This situation could arise easily if there was
   some home device from vendor X that wanted to talk to vendor Y's social
   media system. (Let X={Google,Microsoft,Amazon} and Y=Facebook)

   It seems we ought to write, "Don't do this".

Now, are there other cases to think about?

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Mon, 27 May 2019 19:34:02 +0000

Please see below (limited typing and dictation interface). 

Eliot

> On May 27, 2019, at 19:37, Michael Richardson <[email-masked]> wrote:
> 
> 

s/what/mud/

>   also have legit reason to talk to benign.example.com.

Mud isn’t out to protect victim.example.com so much as it is the end device serving the mud url. 

>   compromised, and the difference in name is inconsequential from a MUD
Yep 

>   It seems we ought to write, "Don't do this".
Yep. 

> Now, are there other cases to think about?

I’m sure there are but I can’t think of them at the moment.  

Eliot

---

From: tirumal reddy <[email-masked]>
Date: Tue, 28 May 2019 11:34:16 +0530

> DoH services, and we can't tell searches from DNS lookups?

Yup.

> Do we need to write an Operational BCP for IoT and DNS here?

Yes, looks useful to me.

Cheers,
-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Tue, 28 May 2019 11:47:25 +0530

On Mon, 27 May 2019 at 22:43, Michael Richardson <[email-masked]>
wrote:

> because a

In TLS 1.2 and prior versions, it was easy to identify the domain by
inspecting the TLS handshake. It is no longer possible with TLS 1.3, see
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04#section-2.2.1

> fails in Enterprises outside of Windows-Group-Policy (including, BYOD, but

MITM also works for mobile devices and Macs using Mobile Device Management
(MDM).
But MITM won't work for unmanaged BYOD devices and in home networks.

Cheers,
-Tiru

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Tue, 28 May 2019 07:04:48 +0000

Please see below.

Eliot

On May 28, 2019, at 08:18, tirumal reddy <[email-masked]<mailto:[email-masked]>> wrote:
MITM also works for mobile devices and Macs using Mobile Device Management (MDM).
But MITM won't work for unmanaged BYOD devices and in home networks.

While I am not recommending this, an ANIMA join registrar could serve the function of an MDM to provide root certificates.  It would be up to the manufacturer to allow such a thing. And that is why I don’t recommend its use: you can’t reasonably rely on the function being there.

This having been said, enterprise CISOs do have concerns about data exfiltration through IOT because these devices do not support  MDMs.

Cheers,
-Tiru

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 May 2019 18:43:05 -0400

mcr> Do we need to write an Operational BCP for IoT and DNS here?

    > Yes, looks useful to me.

could there be someone else who wants to write this?