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

Ted Lemon wrote: It's never been up to the DHC working group to decide whether new DHCP options are architecturally good. People have often used the DHC working group as a way to skate by due diligence on architectural considerations; this was considered to be a problem even before I was

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

It's never been up to the DHC working group to decide whether new DHCP options are architecturally good. People have often used the DHC working group as a way to skate by due diligence on architectural considerations; this was considered to be a problem even before I was chair, and we burned a

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

Ted Lemon wrote: Again, to repeat myself once more, one more time, I am asking that we actually decide what to recommend, and not just say "we all already all know what the right behavior is." If we all agreed on what the correct behavior was, we wouldn't be having this discussion. Maybe

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

this will be my last post on this topic; happy to continue on DHCP matters. Ted Lemon wrote: ... In fact, though, the people who are currently providing DoH service actually have much greater visibility into the malware problem than you possibly can. ... this is a false equivalence. i have

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

Again, to repeat myself once more, one more time, I am asking that we actually decide what to recommend, and not just say "we all already all know what the right behavior is." If we all agreed on what the correct behavior was, we wouldn't be having this discussion. Maybe if we tried to

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

> Il 21 agosto 2018 alle 19.36 David Conrad ha scritto: > > Vittorio, > > > Perhaps I’m misunderstanding: are you saying the folks who provide resolution > services in a DoH world would have incentive to not follow basic security > measures? The definition of what is safe for browsing

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

> Il 22 agosto 2018 alle 7.18 Doug Barton ha scritto: > On 08/21/2018 09:19 AM, Vladimír Čunát wrote: > > Ehm, we somehow forgot that this thread is supposed to be about DHCP, so > > that's only the "uninteresting" case where you do trust the ISP and want > > to use their DNS over a secure

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

On 08/21/2018 09:19 AM, Vladimír Čunát wrote: Ehm, we somehow forgot that this thread is supposed to be about DHCP, so that's only the "uninteresting" case where you do trust the ISP and want to use their DNS over a secure channel:-D This perspective that users "trust" their network

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

On 08/21/2018 09:25 AM, Ted Lemon wrote: DHCP is automatic, so the question of what to do when you have configuration information that conflicts with DHCP needs to be addressed.   It isn't "simple" simply because it addresses only one specific use case. If your "conflicting information"

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

What conflicting information? On 08/21/2018 08:11 PM, Ted Lemon wrote: We aren’t even talking about the same thing. I’m talking about figuring out whether we need to offer guidance for how a host implementation would handle conflicting information and, if so, what guidance to offer.  You are

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

We aren’t even talking about the same thing. I’m talking about figuring out whether we need to offer guidance for how a host implementation would handle conflicting information and, if so, what guidance to offer. You are talking about one of a number of different ways of configuring DoT. On Tue,

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

On 08/21/2018 05:48 AM, Ted Lemon wrote: On Tue, Aug 21, 2018 at 12:59 AM, Doug Barton > wrote: You, like Ted, are looking at the problem the wrong way 'round. And this, in a nutshell, is why this discussion has gone on so long.  If you just caricature what

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

Tom Pusateri wrote: it should follow therefore that i do NOT want to use UDP/53 + Cookies unless there is no alternative. DoT will be preferred. (DTLS or SCTP would be even better, but i'm only picking from items now-on-menu.) Since you can already do DoT today without an additional

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

In your letter dated Tue, 21 Aug 2018 18:19:39 +0200 you wrote: >Ehm, we somehow forgot that this thread is supposed to be about DHCP, so >that's only the "uninteresting" case where you do trust the ISP and want >to use their DNS over a secure channel :-D There are still plenty of use cases. An

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

> On Aug 21, 2018, at 3:30 PM, Paul Vixie wrote: > > this, joyfully, is a very good question. > > Tom Pusateri wrote: > >> Ok, so as Vladimír said, getting back to DHCP… >> >> 1. You obviously don’t need a DoH URI option for DHCP. 2. You’re >> comfortable with DNS over UDP/53 as long as

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

>In fact, roaming wi-fi >connections, while still relevant (especially for international tourists), are > getting less and less used, since everyone now gets several gigabytes of EU-w >ide mobile data per month included with their base mobile fee. I assume that you are aware that with HD video,

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

this, joyfully, is a very good question. Tom Pusateri wrote: Ok, so as Vladimír said, getting back to DHCP… 1. You obviously don’t need a DoH URI option for DHCP. 2. You’re comfortable with DNS over UDP/53 as long as DNS Cookies are present and using the existing DHCP DNS options 3. You

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

> On Aug 21, 2018, at 2:54 PM, Paul Vixie wrote: > > > > David Conrad wrote: >> Vittorio, >> >> ... >> >> Perhaps I’m misunderstanding: are you saying the folks who provide >> resolution services in a DoH world would have incentive to not follow >> basic security measures? > > noting that

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

Tom Pusateri wrote: The Chain Query Requests in DNS (RFC 7901) are awesome for the stub resolver. But the web/DoH server has more knowledge that the stub doesn’t have yet and so it can benefit from this knowledge in a way that the stub resolver can’t. for this to matter, the user will

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

David Conrad wrote: Vittorio, ... Perhaps I’m misunderstanding: are you saying the folks who provide resolution services in a DoH world would have incentive to not follow basic security measures? noting that i am not vittorio, i will punch in as follows. i do not expect CF to block

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

Philip Homburg wrote: If I got it well, what you are trying to bypass is your ISP's security filter that prevents you from connecting to malware or to illegal content (e.g. intellectual property violations and the likes). As a user, I think there is little reason to trust an ISP. ...

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

On 21 Aug 2018, at 16:23, Vittorio Bertola wrote: > > And I have yet to see a statement from the DoH community that Mozilla's idea > of making DoH the default and disregarding whatever resolver is being > configured in the system via DHCP is not a good one. Why would/should the DoH community

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

This is one of the problems with security. It always comes with tradeoffs, and it always looks different depending on your perspective. In fact, though, the people who are currently providing DoH service actually have much greater visibility into the malware problem than you possibly can.

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

On Tue, Aug 21, 2018 at 1:37 PM David Conrad wrote: > Vittorio, > > On Aug 21, 2018, at 3:33 AM, Vittorio Bertola < > vittorio.bert...@open-xchange.com> wrote: > > If so, I can accept your use case: a smart user, knowing what he is doing, > does not want anyone else to sanitize his queries for

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

Vittorio, On Aug 21, 2018, at 3:33 AM, Vittorio Bertola wrote: > If so, I can accept your use case: a smart user, knowing what he is doing, > does not want anyone else to sanitize his queries for him. But I don't see > why the best solution to your use case - which is quite a minority case,

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

> On Aug 21, 2018, at 7:33 AM, Tony Finch wrote: > > Tom Pusateri wrote: > >> Come to think of it, DNSSEC validation in the stub resolver or browser >> is really a place DoH could shine. Instead of all the round trips >> required for validating up (down) the chain, > > With DNS to a

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

> On Aug 21, 2018, at 3:30 AM, Marek Vavruša > wrote: > > On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček > wrote: >> On 21.8.2018 04:38, Tom Pusateri wrote: >>> Come to think of it, DNSSEC validation in the stub resolver or browser >>> is really a place DoH could

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

DHCP is automatic, so the question of what to do when you have configuration information that conflicts with DHCP needs to be addressed. It isn't "simple" simply because it addresses only one specific use case. On Tue, Aug 21, 2018 at 12:19 PM, Vladimír Čunát wrote: > Ehm, we somehow forgot

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

Ehm, we somehow forgot that this thread is supposed to be about DHCP, so that's only the "uninteresting" case where you do trust the ISP and want to use their DNS over a secure channel :-D On 08/21/2018 05:34 PM, Philip Homburg wrote: >> Then you have a problem that's not solvable in DNS itself

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

On Tue, Aug 21, 2018 at 11:23 AM, Vittorio Bertola < vittorio.bert...@open-xchange.com> wrote: > Still, I'm all in favour of encrypting and authenticating DNS connections > when you are in that situation. However, this should not be done in a way > that breaks many other use cases. > How do we

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

>Then you have a problem that's not solvable in DNS itself (yet).  That's >what people usually forget to consider. > >The hostnames are clear-text in https hanshakes (so far), and it seems >relatively easy to collect those.  So, by tunneling *only* DNS you don't >make it much more difficult for

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

> Il 21 agosto 2018 alle 16.47 Philip Homburg ha > scritto: > > > > If I got it well, what you are trying to bypass is your ISP's > > security filter that prevents you from connecting to malware or to > > illegal content (e.g. intellectual property violations and the > > likes). > > As a

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

On 08/21/2018 04:47 PM, Philip Homburg wrote: >> If I got it well, what you are trying to bypass is your ISP's >> security filter that prevents you from connecting to malware or to >> illegal content (e.g. intellectual property violations and the >> likes). > As a user, I think there is little

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

> If I got it well, what you are trying to bypass is your ISP's > security filter that prevents you from connecting to malware or to > illegal content (e.g. intellectual property violations and the > likes). As a user, I think there is little reason to trust an ISP. If you take a mobile device,

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

On Tue, Aug 21, 2018 at 12:59 AM, Doug Barton wrote: > You, like Ted, are looking at the problem the wrong way 'round. And this, in a nutshell, is why this discussion has gone on so long. If you just caricature what the people you're conversing with say, then it's inevitably going to go like

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

Tom Pusateri wrote: > Come to think of it, DNSSEC validation in the stub resolver or browser > is really a place DoH could shine. Instead of all the round trips > required for validating up (down) the chain, With DNS to a recursive server (UDP, TCP, or TLS) as currently deployed, you only need

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

Tony Finch wrote: > > A URI template usually implies the need for DNS queries to resolve the > server name (unless it's an address literal). Would it be plausible to > allow the client to assume that the DoH server IP addresses are the same > as the DNS server addresses, so it can skip the

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

> Il 21 agosto 2018 alle 5.47 John Levine ha scritto: > * - When I talk to security people at mail providers, they have > endless tales of people who take the mail out of their spam folder and > click on the links, you know, just in case it was filtered wrong. If > you know it's bad stuff, you

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

> Il 20 agosto 2018 alle 20.11 Paul Vixie ha scritto: > the DOH people should be told not to proceed to draft > standard until their design accommodates the needs of network operators. This is, honestly, what I'd have expected the "IETF leadership" (IESG, IAB...) to say: this new protocol

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

> Il 20 agosto 2018 alle 18.51 Ted Lemon ha scritto: > > > > So I cannot immediately recall cases in which a network operator in Europe > > is filtering out things that a user wants and can lawfully access. But you > > mention that your network operator is spoofing the DNS and stifling

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

On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček wrote: > On 21.8.2018 04:38, Tom Pusateri wrote: >> Come to think of it, DNSSEC validation in the stub resolver or browser >> is really a place DoH could shine. Instead of all the round trips >> required for validating up (down) the chain, the

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

On 21.8.2018 04:38, Tom Pusateri wrote: > Come to think of it, DNSSEC validation in the stub resolver or browser > is really a place DoH could shine. Instead of all the round trips > required for validating up (down) the chain, the webserver could package > up all those validated records and push

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

On 08/20/2018 06:11 PM, Paul Hoffman wrote: DHCP options are easy and cheap. However #2 was vexing. The proposal that an OS say "oh look, there is a DoH server, I'll use that because it is more secure than Do53" was what was controversial because of the utter lack of DHCP security. Some of the

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

On 08/20/2018 09:22 PM, Bill Woodcock wrote: On Aug 20, 2018, at 6:40 PM, Paul Ebersman wrote: pusateri> There was general pusateri> agreement in the room that you only should use DHCP in IPv4 pusateri> for address/router info and then use trusted sources for pusateri> everything else. In

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

> On Aug 20, 2018, at 6:40 PM, Paul Ebersman wrote: > >> pusateri> There was general >> pusateri> agreement in the room that you only should use DHCP in IPv4 >> pusateri> for address/router info and then use trusted sources for >> pusateri> everything else. In IPv6, SLAAC generally provides

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

In article <5b7b7e3b.3060...@redbarn.org> you write: >if you write down trust assumptions you'll be enumerating disjoint sets >of same as actually practiced by different users and different operators >whose reasons should be treated as valid rather than challenged. We seem to have one group who

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

I think we've gone way off track here. DoH exists, and you can't undo that. Maybe it was a mistake, maybe it wasn't, but that ship has sailed. I think you're implicitly arguing that the IETF should have done a better job of modeling the threats before advancing the protocol, and if we had

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

Ted Lemon wrote: We have no privacy expectations from DNS. We may have privacy expectations from DoH. i have excellent privacy expectations from DoT, which is in fact DNS. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org

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

Marek Vavruša wrote: ... I'm still not sure that IETF should define the provider of trust, as the trust is relative. But you're right Ted, it should definitely be at written down andformalized if we want to move forward. I have to compose my thoughts on this first. I'll try next weekend if

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

On Mon, Aug 20, 2018 at 7:31 PM, Ted Lemon wrote: > This is why we need to actually think about trust and not just handwave. > There are a number of serious misconceptions in what you've said, Paul. I'm still not sure that IETF should define the provider of trust, as the trust is relative. But

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

Tom Pusateri wrote: Come to think of it, DNSSEC validation in the stub resolver or browser is really a place DoH could shine. Instead of all the round trips required for validating up (down) the chain, the webserver could package up all those validated records and push them so the client/stub

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

pusateri> Come to think of it, DNSSEC validation in the stub resolver or pusateri> browser is really a place DoH could shine. Instead of all the pusateri> round trips required for validating up (down) the chain, the pusateri> webserver could package up all those validated records and pusateri>

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

Tom Pusateri wrote: On Aug 20, 2018, at 10:21 PM, Paul Vixie wrote: if DOH is widely used by criminals, botnets, and malware to bypass perimeter security policy, then there will be a big problem and we will be solving it for many years to come, even if the browser is the only thing using

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

Ted Lemon wrote: You're talking about devices over which you have no control. So how does it make a difference where the attack vector is on the device? Why is DNS-over-HTTPS worse than entire-attack-vector-over-HTTPS? i'm glad you asked. operating systems, web browsers, and endpoint

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

Come to think of it, DNSSEC validation in the stub resolver or browser is really a place DoH could shine. Instead of all the round trips required for validating up (down) the chain, the webserver could package up all those validated records and push them so the client/stub could do the

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

I agree. We should write down the advice that we think users and implementors of DoH need. :) On Mon, Aug 20, 2018 at 10:31 PM, Tom Pusateri wrote: > Sure. My point was that there could be legitimate uses of DoH. > > You have to move DNSSEC validation from the resolver to the client in >

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

Sure. My point was that there could be legitimate uses of DoH. You have to move DNSSEC validation from the resolver to the client in order to really validate the answers if you can’t trust the resolver. Tom > On Aug 20, 2018, at 10:28 PM, Ted Lemon wrote: > > Of course, the question is, how

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

This is why we need to actually think about trust and not just handwave. There are a number of serious misconceptions in what you've said, Paul. DHCP _is_ worse than TOFU, because there is an opportunity for attack at every lease renewal, not just the first time you ever talk to a particular

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

Of course, the question is, how does the consumer of that data decide what is okay and what's not? We can't just say that the server has to behave correctly: someone has to enforce it. On Mon, Aug 20, 2018 at 10:25 PM, Tom Pusateri wrote: > > > > On Aug 20, 2018, at 10:21 PM, Paul Vixie

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

ebersman> That may be the consensus at the IETF but it's not even close ebersman> the consensus with ISPs, nor large enterprise. That seems to ebersman> cover most of the eyeball/consumer... DHCP is still how much ebersman> of the world gets connected and that hasn't changed in decades. pusateri>

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

You're talking about devices over which you have no control. So how does it make a difference where the attack vector is on the device? Why is DNS-over-HTTPS worse than entire-attack-vector-over-HTTPS? On Mon, Aug 20, 2018 at 7:47 PM Paul Vixie wrote: > > > Ted Lemon wrote: > > I think that

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

> On Aug 20, 2018, at 10:21 PM, Paul Vixie wrote: > > > > Tom Pusateri wrote: >> ... I don’t know if it’s generally accepted that DoH will replace >> UDP/53 or DoT in the stub resolver or DoH will just end up in the >> browsers as a way to speed up web pages. But if DoH stays in the >>

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

Tom Pusateri wrote: ... I don’t know if it’s generally accepted that DoH will replace UDP/53 or DoT in the stub resolver or DoH will just end up in the browsers as a way to speed up web pages. But if DoH stays in the browser and DoT is tried and used on all DNS servers, there’s not a problem

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

> On Aug 20, 2018, at 9:40 PM, Paul Ebersman wrote: > > pusateri> Another point I remember most clearly is that DHCP has fallen > pusateri> out of favor for communicating all but the most minimal > pusateri> network bootstrap configuration information. There was general > pusateri> agreement

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

On Mon, Aug 20, 2018 at 6:58 PM, Paul Vixie wrote: > > > Tom Pusateri wrote: > >> >> One more point (from the Android crowd) was that they are going to try >> to connect to the DNS server’s IP address using port 853 using DoT at >> the same time they are trying to resolve names over port 53

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

Paul Ebersman wrote: pusateri> Another point I remember most clearly is that DHCP has fallen pusateri> out of favor for communicating all but the most minimal pusateri> network bootstrap configuration information. There was general pusateri> agreement in the room that you only should use

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

Tom Pusateri wrote: One more point (from the Android crowd) was that they are going to try to connect to the DNS server’s IP address using port 853 using DoT at the same time they are trying to resolve names over port 53 with UDP. If they’re able to make a DoT connection, they’ll use it.

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

pusateri> Another point I remember most clearly is that DHCP has fallen pusateri> out of favor for communicating all but the most minimal pusateri> network bootstrap configuration information. There was general pusateri> agreement in the room that you only should use DHCP in IPv4 pusateri> for

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

On 20 Aug 2018, at 17:47, Tom Pusateri wrote: On Aug 20, 2018, at 12:42 PM, Tony Finch wrote: Marek Vavruša wrote: https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt This is interesting to me because I want to support DoTH on my campus resolvers. Regarding

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

> On Aug 20, 2018, at 12:42 PM, Tony Finch wrote: > > Marek Vavruša wrote: >> >> https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive..txt > > This is interesting to me because I want to support DoTH on my campus > resolvers. > > Regarding DoH, the DHCP option ought

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

Ted Lemon wrote: I think that you are whistling past the graveyard. If your firewall allows HTTPS without a proxy, then everything that DoH allows is already possible, and is probably already being done, because it's so obvious. nope. the control plane stops at my doorstep, and there is

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

I think that you are whistling past the graveyard. If your firewall allows HTTPS without a proxy, then everything that DoH allows is already possible, and is probably already being done, because it's so obvious. If you disagree with me about this (and I can think of a few reasons why you might)

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

Ted Lemon wrote: I think HTTPS was pretty hostile to local network policy. Indeed, there was a big argument about that in the TLS working group over the past few IETFs. If you don't want people to use DoH, there's an easy solution, which you already need to use regardless: you have

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

On Mon, Aug 20, 2018 at 1:53 PM, Paul Vixie wrote: > > Preventing user behavior tracking seems like a pretty valid use case. >> > > it would be, if it was cheap to block. that is, on my network, under my > rules, user behavior tracking may be my policy. a user who wants to avoid > that tracking

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

Ted Lemon wrote: On Mon, Aug 20, 2018 at 12:57 PM, Paul Vixie mailto:p...@redbarn.org>> wrote: so, their network, but not their rules? when spammers used to tell me that sending spam wasn't illegal and i had to accept it, i blackholed them and said, my network, my rules. who has

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

On Mon, Aug 20, 2018 at 12:57 PM, Paul Vixie wrote: > > Il 20 agosto 2018 alle 17.55 Ted Lemon ha >>> scritto: >>> >>> I am entirely within my rights to use DoH whether the network >>> operator likes it or not. >>> >> > so, their network, but not their rules? when spammers used to tell me that

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

Il 20 agosto 2018 alle 17.55 Ted Lemon ha scritto: I am entirely within my rights to use DoH whether the network operator likes it or not. so, their network, but not their rules? when spammers used to tell me that sending spam wasn't illegal and i had to accept it, i blackholed them and

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

On Mon, Aug 20, 2018 at 12:41 PM, Vittorio Bertola < vittorio.bert...@open-xchange.com> wrote: > Can you substantiate this statement with data / details? Because I only > know cases in which: > a) ISPs filter out content on behalf of the local government due to legal > requirements/court orders;

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

I am going to echo my original comment on the draft as it may have been lost in this long thread and it will make sense to keep this close to related convo. ``` As for feedback on the draft options. - Section 2.3: Why DoH has no option data? The IP from the DNS recursive name server option merely

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

Marek Vavruša wrote: > > https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt This is interesting to me because I want to support DoTH on my campus resolvers. Regarding DoT, it seems to me that a super simple way for the client to be able to authenticate the server

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

> Il 20 agosto 2018 alle 17.55 Ted Lemon ha scritto: > >  I am entirely within my rights to use DoH whether the network operator likes > it or not.   It is not illegal for me to do so, and if I did so, it would not > be so that I could violate the law—it would be so that I could protect my

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

On Mon, 20 Aug 2018, Paul Vixie wrote: Joe Abley wrote: These are the same use-case, just viewed with different bias. so, DoH's use cases all involve either violating the law, or violating the network operator's security policy? egads, i hope not. the ietf can't be seen backing

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

Paul, it's really not helpful to do this kind of reductio ad absurdum. You are assuming that all networks operators have a security policy which they have a right to enforce on the end user. In some cases this is true. In most cases it is false. E.g., the network to which I am currently

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

On Aug 20, 2018, at 11:49, Paul Vixie wrote: > Joe Abley wrote: > ... >> >> These are the same use-case, just viewed with different bias. >> > > so, DoH's use cases all involve either violating the law, or violating the > network operator's security policy? I don't know how you managed to

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

Joe Abley wrote: These are the same use-case, just viewed with different bias. so, DoH's use cases all involve either violating the law, or violating the network operator's security policy? egads, i hope not. the ietf can't be seen backing something that has _no_ legitimate

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

On Aug 20, 2018, at 07:48, Vittorio Bertola wrote: >> Il 19 agosto 2018 alle 19.02 Doug Barton ha scritto: >> And Jason, you missed a threat model, which is users who want to bypass >> their ISP's resolver. > > I think that there should be a lot more attention to this "use case" in this >

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

> Il 19 agosto 2018 alle 19.02 Doug Barton ha scritto: > And Jason, you missed a threat model, which is users who want to bypass their > ISP's resolver. I think that there should be a lot more attention to this "use case" in this discussion. It seems to me that the designers of DoH have in

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

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

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

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

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

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

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.

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

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 >

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

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

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

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

  1   2   >