Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-add-server-policy-selection-06.txt

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Thu, 4 Mar 2021 20:43:42 +0000

Should qualify – I’m just writing as an interested consumer/user.

On 3/4/21, 11:12 AM, "Add on behalf of Ben Schwartz" <[email-masked]<mailto:[email-masked]> on behalf of bemasc=[email-masked]<mailto:bemasc=[email-masked]>> wrote:

On Thu, Mar 4, 2021 at 11:52 AM Deen, Glenn <Glenn_Deen=[email-masked]<mailto:[email-masked]>> wrote:
On 3/4/21, 8:30 AM, "Add on behalf of Ben Schwartz" <[email-masked]<mailto:[email-masked]> on behalf of bemasc=[email-masked]<mailto:bemasc=[email-masked]>> wrote:
Regarding this draft: Quad9 conveys this information on their website, and this draft provides users with a link to it.  I think that's sufficient, and a much better fit to the problem space, given the endless variety of reasons someone might want to filter a DNS response.
That’s a browser centric view of network devices – meaning it assumes the device has a UI and a user looking at it.   How could this draft be extended to accommodate IoT devices for instance that the device owner wants to direct to choose to use DNS that filters out malware that is known to attack IoT devices?

I find it very difficult to think of a use case where this question would come up.

Why is such a use case hard?   Once we put in place discovery schemes that don’t use my local DHCP provided DNS, there becomes the need for a means to convey to devices like low-compute feature IoT devices what DNS they should be using under the my-device+my-home-network = my-choice doctrine.

Today, on my own network at home I point all my IoT devices to a DNS service that does active filtering of bad actor domains.   It’s one more layer of defense in depth, and especially valuable for IoT device which aren’t capable of having active end-point security on them. One reason it to help isolate them from C&C domains, as part of the overall defense in depth model.

In the current proposals around SVCB it’s entirely possible that an IoT device could be directed to a different DNS resolver than the one that I want. In such a scenario - I’m both the network owner/administrator and the device owner/administrator so I should have the final say on selection if I want to assert it.

    Would more detailed filtering information be useful to convey?

This may be getting into out of scope territory for ADD – as in specifying the details of what is being sent versus the how do we send it – but wherever that actual task of laying out what ends up, it would seem important to always be considering the no-UI/no screen scenario of devices that connect to the network and need to choose services that fit into what the device admin wants.

I'm not sure I understand what you're envisioning, but I don't see any scenario in which it makes sense for the network to present multiple non-equivalent resolvers to a non-interactive client device that chooses among the resolvers based on their claimed behaviors.  There is no ability for networks to do this today, and I have not heard of any IoT manufacturers wishing that the network would make them choose the DNS server from a list with descriptions.

While not there today, it is not a big reach to imagine some IoT software writer lifting DNS discovery code from inside chromium for use in their IoT device.   So the DNS resolver discovery we imagine for browsers – involving a UI and user interaction, may very likely get tweaked and show up in IoT or imbedded systems.

In general, I think the MUD approach to IoT security is a much better choice than anything we are likely to design here.

MUD is a helpful and fine tool in the security toolbox, but relying on just it alone is not good defense in depth.   Don’t rely on just one thing for protection.   New DNS resolver selection approaches such as the DNS domains specifying what resolvers the client should be using instead of their default resolver are introducing a new device behaviors that can significantly alter security architecture assumptions and as a consequence can create new attack vectors.  MUD is good, but MUD only isn’t prudent if you want defense in depth.

-glenn

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 4 Mar 2021 16:59:41 -0500

On Thu, Mar 4, 2021 at 3:43 PM Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:

> On 3/4/21, 11:12 AM, "Add on behalf of Ben Schwartz" <[email-masked]
> on behalf of bemasc=[email-masked]> wrote:
>
>
>
> On Thu, Mar 4, 2021 at 11:52 AM Deen, Glenn <Glenn_Deen=
> [email-masked]> wrote:
>
> On 3/4/21, 8:30 AM, "Add on behalf of Ben Schwartz" <[email-masked]
> on behalf of bemasc=[email-masked]> wrote:
>
> Regarding this draft: Quad9 conveys this information on their website, and
> this draft provides users with a link to it.  I think that's sufficient,
> and a much better fit to the problem space, given the endless variety of
> reasons someone might want to filter a DNS response.
>
> That’s a browser centric view of network devices – meaning it assumes the
> device has a UI and a user looking at it.   How could this draft be
> extended to accommodate IoT devices for instance that the device owner
> wants to direct to choose to use DNS that filters out malware that is known
> to attack IoT devices?
>
>
>
> Why is such a use case hard?   Once we put in place discovery schemes that
> don’t use my local DHCP provided DNS,
>

We (ADD) have not adopted drafts that would put in place any such schemes.
They do, of course, exist anyway, and have ever since the invention of
/etc/resolv.conf.

> there becomes the need for a means to convey to devices like low-compute
> feature IoT devices what DNS they should be using under the
> my-device+my-home-network = my-choice doctrine.
>

We (ADD) have not put in place any such doctrine either.  But if such a
doctrine is in place in your network, then there is no need for this
business of multiple servers with different behaviors.  You can simply
provide these IoT devices with the DNS server they should be using, and
they will use it.

Today, on my own network at home I point all my IoT devices to a DNS
> service that does active filtering of bad actor domains.   It’s one more
> layer of defense in depth, and especially valuable for IoT device which
> aren’t capable of having active end-point security on them. One reason it
> to help isolate them from C&C domains, as part of the overall defense in
> depth model.
>

That is your prerogative, of course.  I have not seen any proposal
mentioned in this working group that would affect your arrangement.

In the current proposals around SVCB it’s entirely possible that an IoT
> device could be directed to a different DNS resolver than the one that I
> want.
>

Side note: SVCB itself has no effect on this.  I assume you're referring
to draft-pauly-add-resolver-discovery [1], which uses SVCB's format to
express its "Designated Resolver" concept.

[1]
https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-01#section-3

> In such a scenario - I’m both the network owner/administrator and the
> device owner/administrator so I should have the final say on selection if I
> want to assert it.
>

Of course!  That's why there's no need for a complicated new dance between
the network and the device.  There's only one controlling party (you), so
your devices can simply do whatever you tell them to do.

> This may be getting into out of scope territory for ADD – as in specifying
> the details of what is being sent versus the how do we send it – but
> wherever that actual task of laying out what ends up, it would seem
> important to always be considering the no-UI/no screen scenario of devices
> that connect to the network and need to choose services that fit into what
> the device admin wants.
>
>
>
> I'm not sure I understand what you're envisioning, but I don't see any
> scenario in which it makes sense for the network to present multiple
> non-equivalent resolvers to a non-interactive client device that chooses
> among the resolvers based on their claimed behaviors.  There is no ability
> for networks to do this today, and I have not heard of any IoT
> manufacturers wishing that the network would make them choose the DNS
> server from a list with descriptions.
>
>
>
> While not there today, it is not a big reach to imagine some IoT software
> writer lifting DNS discovery code from inside chromium for use in their IoT
> device.   So the DNS resolver discovery we imagine for browsers – involving
> a UI and user interaction, may very likely get tweaked and show up in IoT
> or imbedded systems.
>

I don't see how this relates to the draft in question.  If those behaviors
are "tweaked" for IoT, then they can be tweaked to always use the network's
indicated DNS server, or to never use the network's indicated DNS server,
or anything in between.  You should probably buy IoT devices whose behavior
is compatible with your intended network policy.

> In general, I think the MUD approach to IoT security is a much better
> choice than anything we are likely to design here.
>
>
>
> MUD is a helpful and fine tool in the security toolbox, but relying on
> just it alone is not good defense in depth.   Don’t rely on just one thing
> for protection.   New DNS resolver selection approaches such as the DNS
> domains specifying what resolvers the client should be using instead of
> their default resolver are introducing a new device behaviors that can
> significantly alter security architecture assumptions and as a consequence
> can create new attack vectors.
>

I believe you're referring to draft-pauly-add-resolver-discovery.  Note
that MUD would automatically prevent the device from contacting any new DNS
servers discovered in that fashion, so the point seems moot.

If that draft were to become standardized, its use by clients would
necessarily be optional.  Clients that are configured to send all queries
through a network-provided DNS server would simply ignore it.

>   MUD is good, but MUD only isn’t prudent if you want defense in depth.
>

Sure, but standardizing redundant and overlapping technology leads to
confusion.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 Mar 2021 02:36:35 +0000

On Thu, Mar 04, 2021 at 08:43:42PM +0000, Deen, Glenn (NBCUniversal) wrote:
> Should qualify ??? I???m just writing as an interested consumer/user.

same.

> Why is such a use case hard?   Once we put in place discovery schemes that don???t use my local DHCP provided DNS, there becomes the need for a means to convey to devices like low-compute feature IoT devices what DNS they should be using under the my-device+my-home-network = my-choice doctrine.
> 
> Today, on my own network at home I point all my IoT devices to a DNS service that does active filtering of bad actor domains.   It???s one more layer of defense in depth, and especially valuable for IoT device which aren???t capable of having active end-point security on them. One reason it to help isolate them from C&C domains, as part of the overall defense in depth model.
> 
> ...

+1.

-- 
Paul Vixie

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 11 Mar 2021 14:45:07 +0000

Thanks for pinging this, Paul.

glenn> Once we put in place discovery schemes that don't use my local DHCP provided DNS, there becomes the need for a means to convey to devices like low-compute feature IoT devices what DNS they should be using under the my-device+my-home-network = my-choice doctrine.

Forgive me for questioning a chair on this, but... isn't "there becomes the need for a means to convey to devices [...] what DNS they should be using " communication of policy, as in out of scope? I don't deny the validity of the scenario, but I don't see how ADD is the right to solve the "network needs to make client devices understand expected behavior on my network" problem given it's larger than just DNS. 

I think Ben made a good point in a separate reply that highlights why ADD has nothing special beyond DDR/DNR to do here:

ben> Clients that are configured to send all queries through a network-provided DNS server would simply ignore it.

Paul, Glenn, please feel free to correct me if there's an in-charter scenario for the "I own network and device" larger scenario besides these three we should be addressing:

1) The IoT device is antagonistic, and does not care what the network says -> it will use its own resolver anyway and new mechanisms will not change that
2) the IoT device is configurable -> endpoint management can solve the problem
3) the IoT device is cooperative but not directly configurable -> DNR will provide it with the network's approved resolver.

Thanks,
Tommy

-----Original Message-----
From: Add <[email-masked]> On Behalf Of Paul Vixie
Sent: Wednesday, March 10, 2021 6:37 PM
To: Deen, Glenn (NBCUniversal) <[email-masked]>
Cc: tirumal reddy <[email-masked]>; Ben Schwartz <bemasc=[email-masked]>; ADD Mailing list <[email-masked]>; Deen, Glenn <Glenn_Deen=[email-masked]>
Subject: [EXTERNAL] Re: [Add] Fwd: New Version Notification for draft-reddy-add-server-policy-selection-06.txt

same.

+1.

-- 
Paul Vixie

-- 
Add mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=04%7C01%7CJensen.Thomas%40microsoft.com%7Cd5f08a6f0422445f5c9208d8e43686b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637510270163377137%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=eBKLY7Px5YsoL1Axm6BKDbxp4s4cJSASsMCWIjOCuww%3D&amp;reserved=0

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Thu, 11 Mar 2021 15:09:25 +0000

[Glenn] inline...

On 3/11/21, 6:45 AM, "Tommy Jensen" <[email-masked]> wrote:

[Glenn] As I said - comments were given without wearing my chair hat as are these.... 

[Glenn] The reason I made the comments where because I was going through the sniff test around the proposals the group has come up with and thinking through the question of adoption and if there were scenarios/environments that adoption may be difficult in and to try to understand why that might be.

[Glenn] I think it falls into a consideration to be considered in how the WG approaches thinking about what is being discovered and from where, and the ability for a user with a home network to be able to make use of the discovery mechanisms that ADD produces.   Meaning if the WG creates automated discovery mechanisms that rely upon the ability to populate records in DNS, and possibly do more once security features are added, then it would be cutting out the home admin from the ability to participate in configuring their home network and devices to use the ADD's discovery mechanisms.    Admittedly I'm talking about a home admin that is more sophisticated than one who just plugs things in, but if there is a path for the more sophisticated home admin to use ADD discovery that in turn opens the path for CPE SW to build that in as a feature that any home admin can choose to use.

[Glenn] Perhaps a simpler version is to say that as ADD considers solutions the group should also consider who would be adopting and deploying such solutions and should consider that not all adopters will be experts at DNS or have easy access to publishing DNS records, yet they may want to adopt, use, and have control over the discovery mechanisms developed in ADD.   

[Glenn] I bring this up now because as the group discusses ways to merge the DHCP proposal to link with SVCB it may be increasing the ability to make use of ADD's discovery mechanisms outside the reach of a home admin to make use of. 

[Glenn] This is a good breakdown of the cases,  but in #3 what's being assumed about the network's admin?   Is it at the level of a home user configuring their CPE advertising or is it at the ISP level ?

[Glenn] - thanks, Glenn

    Thanks,
    Tommy

    -----Original Message-----
    From: Add <[email-masked]> On Behalf Of Paul Vixie
    Sent: Wednesday, March 10, 2021 6:37 PM
    To: Deen, Glenn (NBCUniversal) <[email-masked]>
    Cc: tirumal reddy <[email-masked]>; Ben Schwartz <bemasc=[email-masked]>; ADD Mailing list <[email-masked]>; Deen, Glenn <Glenn_Deen=[email-masked]>
    Subject: [EXTERNAL] Re: [Add] Fwd: New Version Notification for draft-reddy-add-server-policy-selection-06.txt

    same.

    +1.

    -- 
    Paul Vixie

    -- 
    Add mailing list
    [email-masked]
    https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fadd&amp;data=04*7C01*7CJensen.Thomas*40microsoft.com*7Cd5f08a6f0422445f5c9208d8e43686b2*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637510270163377137*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&amp;sdata=eBKLY7Px5YsoL1Axm6BKDbxp4s4cJSASsMCWIjOCuww*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!PIZeeW5wscynRQ!7IlLGTnMH49YyQ-UkRzWtmXwsDnIVapqQrpjdam31sKY-SMJiWUq2zUb7stzvMS3$