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

["Deen, Glenn (NBCUniversal)" <[e-mail]>]

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" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:



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

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

On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
Office @ Via Treviso 12, 10144 Torino, Italy
--
Add mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!PIZeeW5wscynRQ!8RdwGngL7jdPag-AlvdKIHmRc3kH6T_Me_y-tASbVGqPg257EP7hd7EOzV0mITDr$>