[DNSOP] Draft for dynamic discovery of secure resolvers

Hi, this is a bit off topic, but I figured it would be useful to solicit some early feedback. The current status is that for secure (as in RFC7858 DoT or DoH) resolvers is that there's no discovery mechanism, and it's also out of scope for [0]. At the same time we're seeing real world deployment o

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

DHCP authentication doesn't exist. We already rejected a draft that described how to set up DoH with DHCP. Yours is a little more complicated, but doesn't seem any less dangerous. Before you go any farther on this, you might ask yourself a couple of questions: 1. Why is DoH being used? 2. Wh

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

Ted Lemon wrote: DHCP authentication doesn't exist. We already rejected a draft that described how to set up DoH with DHCP. Yours is a little more complicated, but doesn't seem any less dangerous. Before you go any farther on this, you might ask yourself a couple of questions: 1. Why is

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

Hi Ted, thanks for comments. As said, the draft doesn't try to change the trust model or fix DHCP authentication, it merely offers network operators the ability to advertise secure resolvers for their network. The added "danger" is that recipient inherently trusts the information. On Sat, Aug 18,

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

In article <5b7893c9.7000...@redbarn.org> you write: > it is in other words a thin DNS-only way to do what Tor does. Considering what we know about Tor, that is not encouraging. It seems to me that that most likely scenario for DoH is in javascript apps that need to look up something other than a

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

Hi, thanks for comments. This draft has little to do with DoH (the primary focus is DoT), and its comparison to other technologies. It's about network operator being able to advertise that its recursive server supports DNS on more than just port 53. Please let's stay at least a bit on topic. Mare

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

On Sat, Aug 18, 2018 at 05:22:53PM -0400, Ted Lemon wrote: > 1. Why is DoH being used? > 2. What is the thread model that DoH is addressing? That not yet enough of the internet has been centralized on big cloud providers in foreign jurisdictions, I think. (this post does get DNS operational after

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

How will you block it? On Sat, Aug 18, 2018 at 5:46 PM, Paul Vixie wrote: > > > Ted Lemon wrote: > >> DHCP authentication doesn't exist. We already rejected a draft that >> described how to set up DoH with DHCP. Yours is a little more >> complicated, but doesn't seem any less dangerous. Be

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

On Sat, Aug 18, 2018 at 07:12:57PM -0400, Ted Lemon wrote: > How will you block it? So just to make this a bit more colorful, DoH allows servers to push unsollicited DNS responses, which the browser is then free to put in its DNS cache. This allows the DoH endpoint to hop around at will, or even

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

Yup. On Sat, Aug 18, 2018 at 7:21 PM, bert hubert wrote: > On Sat, Aug 18, 2018 at 07:12:57PM -0400, Ted Lemon wrote: > > How will you block it? > > So just to make this a bit more colorful, DoH allows servers to push > unsollicited DNS responses, which the browser is then free to put in its > D

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

Marek, forgive me for being blunt, but your reply was completely non-responsive. DoH and DoT are being used because they address a threat model, or because, as Bert rather bluntly put it, they allow content providers to study our query stream. They are not being used "because they are standards

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

Marek Vavruša wrote: Hi, thanks for comments. This draft has little to do with DoH (the primary focus is DoT), and its comparison to other technologies. It's about network operator being able to advertise that its recursive server supports DNS on more than just port 53. Please let's stay at l

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

On Sat, Aug 18, 2018 at 5:03 PM, Ted Lemon wrote: > Marek, forgive me for being blunt, but your reply was completely > non-responsive. DoH and DoT are being used because they address a threat > model, or because, as Bert rather bluntly put it, they allow content > providers to study our query st

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

Ted Lemon wrote: How will you block it? at work we'll probably firewall all outbound tcp and require the use of proxies, which will do some kind of payload inspection. at home i don't know yet but i'll likely just blacklist every known DOH endpoint, and tell my family, if you want netfli

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

On Sat, Aug 18, 2018 at 5:33 PM, Paul Vixie wrote: > > > Marek Vavruša wrote: >> >> Hi, >> >> thanks for comments. This draft has little to do with DoH (the primary >> focus is DoT), and its comparison to other technologies. It's about >> network operator being able to advertise that its recursive

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

bert hubert wrote: On Sat, Aug 18, 2018 at 07:12:57PM -0400, Ted Lemon wrote: How will you block it? So just to make this a bit more colorful, DoH allows servers to push unsollicited DNS responses, which the browser is then free to put in its DNS cache. This allows the DoH endpoint to hop

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

On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša wrote: > > You say that your proposal does not impact DoT's ability to address the > > threat model or use case that is the reason it is being used. But this > is > > doesn't make sense to me. The trust model for DoT and DoH right now is > > that

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

On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon wrote: > On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša > wrote: >> >> > You say that your proposal does not impact DoT's ability to address the >> > threat model or use case that is the reason it is being used. But this >> > is >> > doesn't make sense

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

my threat model is intruders or eavesdroppers on the path between me and my rdns. i'd like the dhcp announcement to include a tcp/853 signal along with a pre-shared key or the hash thereof. the benefit would be that if my rdns network path is less secure than my dhcp network path, i'll improve

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

https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-13 On Sat, Aug 18, 2018 at 8:53 PM, Marek Vavruša wrote: > On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon wrote: > > On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša > > wrote: > >> > >> > You say that your proposal does not impact DoT's ability

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

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 roam to other networks, that's fine, but we hav

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

> On Aug 18, 2018, at 8:53 PM, Marek Vavruša > wrote: > > On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon > wrote: >> On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša >> wrote: >>> You say that your proposal does not impact DoT's ability to address the threat mod

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

Thanks Tom, this is what I was asking for. I'll take a look! On Sat, Aug 18, 2018 at 6:09 PM, Tom Pusateri wrote: > > > On Aug 18, 2018, at 8:53 PM, Marek Vavruša > wrote: > > On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon wrote: > > On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša > wrote: > > > Yo

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

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. that's far afield of my stated use-case. if i receive a

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

On Sat, Aug 18, 2018 at 9:21 PM, Paul Vixie wrote: > > 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

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

Ted Lemon wrote: If you are trusting a "pre-shared key," why not just pre-share the DoT server information? ... because my preferred DoT server may not work inside someone else's network. The reason it's not drama-free is because you can't just hand-wave the threat model. What

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

Well, if that's true, Paul, then I guess DNS filter lists are totally unnecessary and you should stop working on that. Maybe you already have? On Sat, Aug 18, 2018 at 9:57 PM, Paul Vixie wrote: > > > Ted Lemon wrote: > ... > >> If you are trusting a "pre-shared key," why not just pre-share the

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

Ted Lemon wrote: Well, if that's true, Paul, then I guess DNS filter lists are totally unnecessary and you should stop working on that. Maybe you already have? see https://dnsrpz.info/ for more details on DNS Firewalls. of course, nominum was selling something like this ten years ago, and

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

> On Aug 19, 2018, at 01:03, Paul Vixie wrote: > > . this is a published spec so as to allow an unlimited number of subscribing > defenders to choose from an unlimited number of publishing suppliers using > one "language". A draft spec that unfortunately isn’t being moved along so IETF can d

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

I am going to focus back on the draft itself. While the discussion around centralizing DNS to 3rd party vs local ISP (or any other alternatives) is worth having, it is a fact that most people get their DNS server set using DHCP. the current state is that all you will get are addresses that you can