Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Resorting to in-line responses to reduce the amount of talking past each other. On 08/19/2018 07:17 PM, Ted Lemon wrote: No, I think maybe I haven't been communicating as well as I should.  What I have been saying is that we need to decide what our threat model is, You've been very clear o

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

No, I think maybe I haven't been communicating as well as I should. What I have been saying is that we need to decide what our threat model is, so that we can figure out what to recommend. What you are saying is "we should recommend this." What you are proposing to recommend has a perfectly v

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/19/2018 04:57 PM, manu tman wrote: On Sun, Aug 19, 2018 at 4:46 PM Ted Lemon > wrote: A user who relies on the dhcp server for dns server info is no worse off. The problem is that if your host lets the dhcp server override the DoT or DoH configuratio

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Okay. How are you going to write the applicability statement? On Sun, Aug 19, 2018 at 8:10 PM Paul Vixie wrote: > i think a good modern stub should have several settings that are missing > in today's stable of internet endpoints. > > "these are my preferred servers, even when dhcp tells me other

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

i think a good modern stub should have several settings that are missing in today's stable of internet endpoints. "these are my preferred servers, even when dhcp tells me otherwise" "if there's a tcp/853 trust path available, and it works, prefer it" "if my preferred servers can't be reached i

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On Sun, Aug 19, 2018 at 4:46 PM Ted Lemon wrote: > A user who relies on the dhcp server for dns server info is no worse off. > The problem is that if your host lets the dhcp server override the DoT or > DoH configuration you entered manually, you are a lot worse off. > This seems to be a static

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

A user who relies on the dhcp server for dns server info is no worse off. The problem is that if your host lets the dhcp server override the DoT or DoH configuration you entered manually, you are a lot worse off. So you have to specify how you’re going to handle this. I’m not saying don’t do it. I’

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

I agree with Steinar's sensibilities on this, FWIW. Ted, you've restated your thesis several times now, but what I haven't seen is an answer to my question, so let me pose it a different way. How is a user that relies on the DHCP server's DOH or DOT resolving name server instructions worse of

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Right, that's the second trust model. It's incompatible with the first trust model. Did you see the message earlier to day where I described these trust models? On Sun, Aug 19, 2018 at 4:04 PM, Paul Ebersman wrote: > mellon> Think about DHCP providing an SMTP server address. Does that > mell

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

mellon> Think about DHCP providing an SMTP server address. Does that mellon> make sense? That doesn't. But DHCP already hands out DNS servers. You are already trusting the DHCP server to give you default gateway and DNS server (or you are choosing not to use DHCP). Take the use case of coffee hou

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

That may indeed be correct. If it is correct, then the next step would be to try to design a trust model that we can agree on, that addresses both use cases rather than requiring us to choose one or the other. E.g., we could say that if you are Chinese, then your device is required to trust the

Re: [DNSOP] Comments on draft-wessels-dns-zone-digest-02

On Mon, 13 Aug 2018, Brian Dickson wrote: Subject: Re: [DNSOP] Comments on draft-wessels-dns-zone-digest-02 IF (big if, with the how/when/where etc kept as a separate discussion) an attacker manages to modify glue (for example, poisoning a resolver's cache for glue info), the attacker has th

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

I am indeed saying that when the IETF publishes a standards track document with an applicability statement, the IETF is recommending that, where applicable, the specification be used. The problem with not deciding on the trust model is that it would be impossible to write a clear applicability sta

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> The DHCP solution is compatible only with trust relationship two. So if > the IETF were to recommend this way of configuring DoH and DoT, we would > essentially be throwing away the privacy benefits of DoH and DoT (assuming > that such benefits exist). I don't believe people are saying that th

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Interesting. This approach is similar to the lists curated by Frank and people from dnscrypt-proxy: https://dnscrypt.info/public-servers Assuming that separating protocol change from trust model change is a no-go, then the trust would need to go both ways - the network operator would need to push

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> On Aug 19, 2018, at 9:29 AM, Livingood, Jason > wrote: > > On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert" on behalf of bert.hub...@powerdns.com> wrote: >Especially when such a move will incidentally kill intranets, VPNs, split >horizon, DNS monitoring & DNS malware detecion a

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 8/19/18, 1:02 PM, "DNSOP on behalf of Doug Barton" wrote: > Personally I see securing the path from the stub to the resolver as a good step in the ultimate goal of encrypting all of the things. :) [JL] No disagreement here. I think the issue may be more to do with choice over the r

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Ted Lemon wrote: I will freely admit that this is not clear-cut, but that's really my point. I believe that it is wrong to advance a DHCP-based solution without consensus that we prefer the second trust model, and I don't think such a consensus is attainable. Pursuing a DHCP-based sol

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Or, you have malware trying to bypass DNS checks. Craig Finseth > On Aug 19, 2018, at 11:43, Doug Barton wrote: > >> On 08/18/2018 06:08 PM, Ted Lemon wrote: >> The thing is that most devices don't connect to just one network. So while >> your devices on your network can certainly trust por

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

I went over this in some detail a while back, but to recap, the point of something like DoH or DoT is to protect the client from eavesdropping. There are three senses in which this can be useful. - First, that there is a trust relationship between the client and the server, which is validat

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/19/2018 06:18 AM, Livingood, Jason wrote: So I suppose that the threat model in this example is presumably someone (1) eavesdropping on the relatively short path between CMTS and resolver or (2) modifying non-DNSSEC-validated responses - and that's does not seem like a very high risk thr

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/18/2018 06:08 PM, Ted Lemon wrote: The thing is that most devices don't connect to just one network.   So while your devices on your network can certainly trust port 853 on your network, when they roam to other networks, they have no reason to trust it.   If you have devices that never ro

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

I think this would be a better place to start than proposing a solution. It's pretty clear that the thinking in this space is all over the map. On Sun, Aug 19, 2018 at 9:29 AM, Livingood, Jason < jason_living...@comcast.com> wrote: > On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert" < > dnso

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert" wrote: Especially when such a move will incidentally kill intranets, VPNs, split horizon, DNS monitoring & DNS malware detecion and blocking. It seems to me that the underlying protocol is separable from the operational implementatio

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

In a DOCSIS network, for whatever that's worth, the link from the home (cable modem) to the next hop (CMTS) is encrypted. It is then usually just one or two hops within the ISP's regional network to the recursive DNS (in some cases DNSSEC-validating, as in our case). So I suppose that the threat