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

[tirumal reddy <[e-mail]>]

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

>
>
>
>
> On Jun 30, 2020, at 8:31 PM, Rob Sayre <[e-mail]> wrote:
>
> 
> On Tue, Jun 30, 2020 at 5:52 PM Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>> On Tue, Jun 30, 2020 at 4:25 PM Deen, Glenn (NBCUniversal) <
>> [e-mail]> wrote:
>>
>>> 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 ?
>>>
>>
>> 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.
>>
>
> 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.
>
>
> 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.
>

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


>
> This gets back  to Ekr’s question of declaring what threats you are
> actually worried about.
>
> -Glenn
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>