Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Tue, 30 Jun 2020 23:25:06 +0000

This all comes back to the three slices of access types that had been discussed some months ago:

  1.  Trusted & known networks – this is your enterprise, your home.  You have a relationship with them.
  2.  Unknown networks – This is the café, school, hotel - you choose them because they are available, but you know very little to nothing about them.
  3.  Hostile networks – you may not have any choice in network and must use this is you want any Internet access at all.  However, not only do you not trust them, you know they are actively acting in ways you do not want.

Another slice around threat levels would be: Green, Yellow, Red networks

Certainly in terms of policy and security concerns one size does not fit all 3.  The question is can we fashion a discovery means that works in all 3, but perhaps mitigates the policy and security concerns in each?

DHCP may be a perfectly fine choice in a green network, but in a yellow network there is a need for validation and assurance of the choice, while in a red network – can you trust anything at all, even things you explicitly specified such as IP address of resolvers without some additional validation ?

-glenn

On 6/30/20, 3:07 PM, "Add on behalf of Eric Rescorla" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jun 30, 2020 at 2:24 PM Vittorio Bertola <vittorio.bertola=[email-masked]<mailto:[email-masked]>> wrote:

Il 30/06/2020 14:58 Eric Rescorla <[email-masked]<mailto:[email-masked]>> ha scritto:

On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie <[email-masked]<mailto:[email-masked]>> wrote:
i have badly misunderstood.

the way i know that the ip address provided by the isp was delivered securely
today is because off-net DHCP forgery is hard,

Let's start here:
I agree that off-net DHCP forgery is hard. However, once you assume that you are off-path, then Do53 interception is *also* hard. So for this to be useful you need an environment in which the attacker is able to attack Do53 but *not* to attack DHCP. What I'm asking for is for someone to define that threat model precisely so that we can design protocols that match it.
I have written and deleted two or three longer replies to this, so I will just quote what Daniel Migault wrote a few messages ago: "The threat model seems for Comcast and the end user having the traffic redirected to Cloudflare instead of the local resolver." But of course the basic issue is that we seem to disagree on what a threat is.

No, I don't in fact that's the issue at all. To recap, this is a solution for a very specific problem. I'm not suggesting that it's a generic solution.

However, there have been a number of proposals for nominally generic solutions none of which seem to come with a fully defined threat model. I'm trying to get to what that model is. Specifically, I agree that it would be a useful to allow endpoint devices to securely learn the identity of the Do[HT] server associated with their local network [0]. This would then allow you to get private resolution even if there were attackers on the network (as in classical Ethernet or unencrypted WiFi). However, even with that objective, we still need to define a realistic set of attacker capabilities and then a design which is secure given those capabilities. That is what I am asking for.

-Ekr

[0] Under the assumption that you are connecting to the right network, of course, which is sometimes a very thin assumption.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]<mailto:[email-masked]>
Office @ Via Treviso 12, 10144 Torino, Italy
--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!PIZeeW5wscynRQ!8RdwGngL7jdPag-AlvdKIHmRc3kH6T_Me_y-tASbVGqPg257EP7hd7EOzV0mITDr$>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jun 2020 17:51:27 -0700

On Tue, Jun 30, 2020 at 4:25 PM Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:

>    2. Unknown networks – This is the café, school, hotel - you choose
>    them because they are available, but you know very little to nothing about
>    them.
>    3. Hostile networks – you may not have any choice in network and must
>    use this is you want any Internet access at all.  However, not only do you
>    not trust them, you know they are actively acting in ways you do not want.
>
>
>
> Certainly in terms of policy and security concerns one size does not fit
> all 3.  The question is can we fashion a discovery means that works in all
> 3, but perhaps mitigates the policy and security concerns in each?
>
>
>
> DHCP may be a perfectly fine choice in a green network, but in a yellow
> network there is a need for validation and assurance of the choice, while
> in a red network – can you trust anything at all, even things you
> explicitly specified such as IP address of resolvers without some
> additional validation ?
>

This is a great taxonomy. Thanks.

I think the question I would ask is: in a green network, how much benefit
do you get from Do[HT]? We can probably divide this up into the local
network environment (e.g., the wireless network) and the access link from
the ISP.

On the local network, it seems like the fate of DHCP and Do[HT] is kind of
similar, so it's not clear to me how much value you are getting here.
For the access link, it seems like there is value, but it would also quite
possibly be easier to just tunnel the traffic over that link from the
access router, in which case you don't need discovery.

-Ekr

>
> -glenn
>
>
>
> On 6/30/20, 3:07 PM, "Add on behalf of Eric Rescorla" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
>
>
>
>
> On Tue, Jun 30, 2020 at 2:24 PM Vittorio Bertola <vittorio.bertola=
> [email-masked]> wrote:
>
>
>
> Il 30/06/2020 14:58 Eric Rescorla <[email-masked]> ha scritto:
>
>
>
> On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie <[email-masked]> wrote:
>
> I agree that off-net DHCP forgery is hard. However, once you assume that
> you are off-path, then Do53 interception is *also* hard. So for this to be
> useful you need an environment in which the attacker is able to attack Do53
> but *not* to attack DHCP. What I'm asking for is for someone to define that
> threat model precisely so that we can design protocols that match it.
>
> I have written and deleted two or three longer replies to this, so I will
> just quote what Daniel Migault wrote a few messages ago: "The threat model
> seems for Comcast and the end user having the traffic redirected to
> Cloudflare instead of the local resolver." But of course the basic issue is
> that we seem to disagree on what a threat is.
>
>
>
> No, I don't in fact that's the issue at all. To recap, this is a solution
> for a very specific problem. I'm not suggesting that it's a generic
> solution.
>
>
>
> However, there have been a number of proposals for nominally generic
> solutions none of which seem to come with a fully defined threat model. I'm
> trying to get to what that model is. Specifically, I agree that it would be
> a useful to allow endpoint devices to securely learn the identity of the
> Do[HT] server associated with their local network [0]. This would then
> allow you to get private resolution even if there were attackers on the
> network (as in classical Ethernet or unencrypted WiFi). However, even with
> that objective, we still need to define a realistic set of attacker
> capabilities and then a design which is secure given those capabilities.
> That is what I am asking for.
>
>
>
> -Ekr
>
>
>
> [0] Under the assumption that you are connecting to the right network, of
> course, which is sometimes a very thin assumption.
>
> --
>
> [email-masked]
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!PIZeeW5wscynRQ!8RdwGngL7jdPag-AlvdKIHmRc3kH6T_Me_y-tASbVGqPg257EP7hd7EOzV0mITDr$>
>
>

---

From: Rob Sayre <[email-masked]>
Date: Tue, 30 Jun 2020 20:31:00 -0700

> network environment (e.g., the wireless network) and the access link from

There are lots of attacks that create compromised "Green" networks. For
example:

https://www.zdnet.com/article/brazil-is-at-the-forefront-of-a-new-type-of-router-attack

I might categorize an "enterprise" network as something managed well enough
to do an investigation in the event of a security breach. Most business and
home networks do not fit this definition, so they are category 2
("Yellow"), because people set them up and forget them.

thanks,
Rob

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Wed, 1 Jul 2020 04:01:20 +0000

On Jun 30, 2020, at 8:31 PM, Rob Sayre <[email-masked]> wrote:

On Tue, Jun 30, 2020 at 5:52 PM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jun 30, 2020 at 4:25 PM Deen, Glenn (NBCUniversal) <[email-masked]<mailto:[email-masked]>> wrote:
This all comes back to the three slices of access types that had been discussed some months ago:

I think the question I would ask is: in a green network, how much benefit do you get from Do[HT]? We can probably divide this up into the local network environment (e.g., the wireless network) and the access link from the ISP.

There are lots of attacks that create compromised "Green" networks. For example:

I might categorize an "enterprise" network as something managed well enough to do an investigation in the event of a security breach. Most business and home networks do not fit this definition, so they are category 2 ("Yellow"), because people set them up and forget them.

Should we design for the edge case where something bad happens, but is the exception or should we design for the 99% case when the home network is just fine?

Granted hacks and attacks will happen, but while we should and do take reasonable steps to mitigate obvious problems, most of the time and most of the experience of home networks is that they aren’t compromised and behave the way their users expect.

If we classified networks based on the concern that something bad may happen. Then everything would be yellow, or even red as it’s easy to find examples when bad things happened in any situation. Example: Home Depot was compromised - thus corporate networks can’t be trusted. Example: The NSA was compromised - thus highly secured networks can’t be trusted. Each such reaction is a fearful over generalization of an incident and not the normal expected state of such network types.

If you look broadly at home networks the common generalized case is that The vast majorityaren’t compromised and the configuration information from the network can be trusted.

So instead of designing for edge case of a previously trust network being compromised , why not design for the more common state of the network being trustworthy but and then add in some mechanism to verify the information you get from it. Basically a version of the trust but verify approach, which has been proven repeatedly as a reasonable strategy in the real world.

For instance, if you get a DoH resolver from the green network, why not trust but verify by checking the reasonableness of the answer you were directed to?  This could something like validating with DNSSEC or some other validation method.

This gets back  to Ekr’s question of declaring what threats you are actually worried about.

-Glenn

---

From: Rob Sayre <[email-masked]>
Date: Tue, 30 Jun 2020 21:55:30 -0700

On Tue, Jun 30, 2020 at 9:01 PM Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:

>
> Should we design for the edge case where something bad happens, but is the
> exception or should we design for the 99% case when the home network is
> just fine?
>
> Granted hacks and attacks will happen, but while we should and do take
> reasonable steps to mitigate obvious problems, most of the time and most of
> the experience of home networks is that they aren’t compromised and behave
> the way their users expect.
>

Although only one example was given, it's a common problem. A web search
will turn up many other instances. Note that Mozilla's current approach is
resistant to such misconfiguration, whether or not it's malicious. Most of
these problems seem to be unintentional or the work of common criminals,
not anything more sophisticated.

I agree that DNSSEC or some other validation method might improve discovery
over DHCP etc, but have yet to see anything like that deployed. Examples
might help.

> This gets back  to Ekr’s question of declaring what threats you are

Private IPs should not be trusted as DNS servers absent client software
such as VPNs, enterprise management, or parental control features. I know
others disagree.

thanks,
Rob

---

From: tirumal reddy <[email-masked]>
Date: Wed, 1 Jul 2020 12:17:48 +0530

On Wed, 1 Jul 2020 at 09:31, Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:

>>>    3. Hostile networks – you may not have any choice in network and
>>>    must use this is you want any Internet access at all.  However, not only do
>>>    you not trust them, you know they are actively acting in ways you do not
>>>    want.
>>>
>>>
>>>
> I might categorize an "enterprise" network as something managed well
> enough to do an investigation in the event of a security breach. Most
> business and home networks do not fit this definition, so they are category
> 2 ("Yellow"), because people set them up and forget them.
>
>
> If we classified networks based on the concern that something bad may
> happen. Then everything would be yellow, or even red as it’s easy to find
> examples when bad things happened in any situation. Example: Home Depot was
> compromised - thus corporate networks can’t be trusted. Example: The NSA
> was compromised - thus highly secured networks can’t be trusted. Each such
> reaction is a fearful over generalization of an incident and not the normal
> expected state of such network types.
>
> If you look broadly at home networks the common generalized case is that
> The vast majorityaren’t compromised and the configuration information from
> the network can be trusted.
>
> So instead of designing for edge case of a previously trust network being
> compromised , why not design for the more common state of the network being
> trustworthy but and then add in some mechanism to verify the information
> you get from it. Basically a version of the trust but verify approach,
> which has been proven repeatedly as a reasonable strategy in the real world.
>
> For instance, if you get a DoH resolver from the green network, why not
> trust but verify by checking the reasonableness of the answer you were
> directed to?  This could something like validating with DNSSEC or some
> other validation method.
>

Good point. If the discovered DoH/DoT server is not pre-configure in the
OS/Browser,
https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-03 can
be used by DNS client to authenticate it is connecting to a DoH/DoT server
hosted by a specific organization (e.g., ISP). It is particularly useful
when the DoH/DoT server is insecurely discovered, the discovered DoH/DoT
server is not pre-configured as TRR and prevents the client from connecting
to an attacker's DoH/DoT server.

-Tiru