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

[Paul Vixie]

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
chair, and we burned a lot of time evaluating bad ideas before we
decided not to be the place where new work on DHCP options is done by
default.   If a DHCP option were to be entertained, this WG, the dprive
WG or the DoH WG would be where it would have to happen, not because the
DHC working group is freezing new features, but because it's not in
their charter.


you, as an author of two implementations as a former DHC WG chair, have 
said that new features should not be added to DHCP because 
authentication. while i disagree, i recognize that your voice has more 
credibility in the DHCP space than mine does, and i'm ready to give up 
rather than actually fight and lose the battle.



That said, you responded to a message where I talked about what I think
we ought to do to move forward by saying that moving forward is
impossible other than by just adding a hack somewhere.   I don't think
that's true, and in fact I'm feeling like I need to write up a threat
analysis because even though it's not something that I want to work on,
it sounds like most people assume it's impossible and I'm just
suggesting it as a roadblock, and the people who get that it's necessary
don't seem to be any more enthusiastic about doing it than I am.   I'd
appreciate it if, when I've written that analysis, you could contribute
to it, but I'll understand if you don't have time or don't think it's
worthwhile.


my own experience as a widely unread author is that i have to keep 
things short or people will refile/delete them, no matter how 
meritorious or relevant (or even pithy and clever) the writing was.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 lot of time evaluating bad ideas before we decided not to be the place
where new work on DHCP options is done by default.   If a DHCP option were
to be entertained, this WG, the dprive WG or the DoH WG would be where it
would have to happen, not because the DHC working group is freezing new
features, but because it's not in their charter.

That said, you responded to a message where I talked about what I think we
ought to do to move forward by saying that moving forward is impossible
other than by just adding a hack somewhere.   I don't think that's true,
and in fact I'm feeling like I need to write up a threat analysis because
even though it's not something that I want to work on, it sounds like most
people assume it's impossible and I'm just suggesting it as a roadblock,
and the people who get that it's necessary don't seem to be any more
enthusiastic about doing it than I am.   I'd appreciate it if, when I've
written that analysis, you could contribute to it, but I'll understand if
you don't have time or don't think it's worthwhile.

On Wed, Aug 22, 2018 at 2:24 PM, Paul Vixie  wrote:

>
>
> 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 if we tried
>> to describe what we all think the correct behavior was, we would realize
>> that we do agree on it, but we haven't done that yet.   And the possible
>> set of all behaviors is more complicated than you suggest.
>>
>
> with regard to dhcp, if the dhc wg is freezing new features pending
> authentication capabilities which are not forthcoming, then dhcp is off the
> table for DoT discovery.
>
> in that case, the purported android approach of "use DoT if it works" may
> be the only way forward. this means when current unauthenticated dhcp tells
> you what your rdns servers are, you'll try each of them with TCP/853 and
> use that if it works, else fall back to whatever you did before, which is
> probably UDP/53 falling back to TCP/53.
>
> --
> P Vixie
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 if we tried
to describe what we all think the correct behavior was, we would realize
that we do agree on it, but we haven't done that yet.   And the possible
set of all behaviors is more complicated than you suggest.


with regard to dhcp, if the dhc wg is freezing new features pending 
authentication capabilities which are not forthcoming, then dhcp is off 
the table for DoT discovery.


in that case, the purported android approach of "use DoT if it works" 
may be the only way forward. this means when current unauthenticated 
dhcp tells you what your rdns servers are, you'll try each of them with 
TCP/853 and use that if it works, else fall back to whatever you did 
before, which is probably UDP/53 falling back to TCP/53.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 responsibility for my network's security. the DoH provider does not.

i _will_ know what's targetting me. the DoH provider _might_ know.

i know my policies and tradeoffs. the DoH provider will not know.

if i choose to outsource my perimeter defense, that's one thing. but to 
have a visitor or BYOD or malware or employee or family member decide to 
do this, is quite another.


the DoH team has badly misunderstood a full segment of the community, 
and the resulting knee-jerk ignorant politics-based engineering is going 
to have a very long tail of foreseeable negative side effects.


-- P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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
describe what we all think the correct behavior was, we would realize that
we do agree on it, but we haven't done that yet.   And the possible set of
all behaviors is more complicated than you suggest.

On Wed, Aug 22, 2018 at 4:32 AM, Vittorio Bertola <
vittorio.bert...@open-xchange.com> wrote:

> > 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 and what is not is highly
> local - each network and each country have their policies. How could a
> QuadX operator implement a filter that fits the needs of the entire planet?
>
> (Unless we imagine a model in which the DoH operator receives policies
> from networks and countries and applies them depending on where the request
> is coming from.)
>
> Also, network operators have a direct interest in implementing security
> measures to prevent threats from spreading to more devices on their
> network. What's the incentive for a centralized DoH operator to spend money
> and time in security filters?
>
> Regards,
> --
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bert...@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vittorio Bertola]

> 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 and what is not is highly local - 
each network and each country have their policies. How could a QuadX operator 
implement a filter that fits the needs of the entire planet?

(Unless we imagine a model in which the DoH operator receives policies from 
networks and countries and applies them depending on where the request is 
coming from.)

Also, network operators have a direct interest in implementing security 
measures to prevent threats from spreading to more devices on their network. 
What's the incentive for a centralized DoH operator to spend money and time in 
security filters?
 
Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vittorio Bertola]

> 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 channel:-D
> 
> This perspective that users "trust" their network environment is deeply 
> flawed. Users don't understand how any of this stuff works, and we 
> should not be making any decisions with that as a premise.

But we should also not make the premise that the user does not trust the 
network environment. It really depends on the situation.

Also, there are cases in which the user perhaps does not trust his network, but 
his network has the right to enforce policies on the user: think at the 
employees on a corporate network. We should be making this enforcement easier, 
not harder - for example, adding ways for the network operator to communicate 
to DoH operators that certain restrictions have to be put in place for the 
users of its network.

Moreover, even if the user does not trust his network and has the right to do 
something about this, you cannot also assume that he trusts his application 
maker or his destination website operator more than he trusts his network. 
Actually, if you define trust in terms of expectations, until now the users 
that understand what we are talking about expect their network operator to 
provide the resolver, not the application maker.

The real problem here is that you cannot establish a trust model that is always 
valid, and the trust model that applies to a situation can be opposite to the 
model applying to another one, without any automatable way to distinguish among 
the two.

This is also what makes this issue so thorny. You can decide that, in the end, 
the only way to get out of this is to entrust the user with the choice of who 
to trust, though, as you say, many users will not be able to make an informed 
choice. Or you can entrust the network operator or the DoH server operator: it 
is more likely to make competent choices, but in some cases might not make them 
in the user's interest, though in some cases it also has the right, or even the 
legal duty, to make choices that users dislike. All in all, I see no easy way 
to find a model and a policy that work in all cases.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

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 environment is deeply 
flawed. Users don't understand how any of this stuff works, and we 
should not be making any decisions with that as a premise.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

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" issue is "What do I do with DHCP 
options I receive for things I've already configured manually?" when has 
the answer ever been anything other than, "Ignore them?"


Are there seriously cases where a DHCP option would override something 
I've manually configured already?


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

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 talking about one of a number of different ways of 
configuring DoT.


On Tue, Aug 21, 2018 at 11:04 PM Doug Barton > wrote:


On 08/21/2018 05:48 AM, Ted Lemon wrote:
 > On Tue, Aug 21, 2018 at 12:59 AM, Doug Barton
mailto:do...@dougbarton.us>
 > >> 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 this:

[ Snipped a bunch of arguments I didn't make ]

 > This is why discussions balloon in the IETF.   So now I have the
choice
 > of either being silenced, or continuing to be Person A in this
charade.
 >   I think I've spoken my peace.   If you want to proceed with
this work,
 > please do not be surprised if, when the call for adoption comes,
I come
 > in and say "I raised substantive objections to this, which were not
 > addressed, so please do not take this on as a working group item."

Ted,

While I'm not concerned about the issues you raised in your caricature,
I feel that I have tried to engage you in your discussion of different
security models. My understanding is that your models devolve down to
two. Either the user configures a resolver themselves (whether it's
DOH/DOT or not), and user doesn't configure a resolver themselves. I
recognize the distinction you made between your models 1 and 3, and
further recognize that it's extremely important to some people. My
point
is that *from the standpoint of a DHCP option for DOH/DOT* it's not
relevant.

  From our discussion, it seems that you're in agreement with me
that if
a user isn't configuring a resolver explicitly that they are no worse
off with DOH/DOT than they are without it. Am I right so far?

Meanwhile, you've also voiced an opinion that the presence of a DHCP
option implies some sort of endorsement by the IETF. I (and others)
replied that we've never heard of this, and disagree strongly with your
position.

So other than the fact that we disagree on the endorsement issue, what
am I missing here?

Doug


___
DNSOP mailing list
DNSOP@ietf.org 
https://www.ietf.org/mailman/listinfo/dnsop



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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, Aug 21, 2018 at 11:04 PM Doug Barton  wrote:

> 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 the people you're conversing with say,
> > then it's inevitably going to go like this:
>
> [ Snipped a bunch of arguments I didn't make ]
>
> > This is why discussions balloon in the IETF.   So now I have the choice
> > of either being silenced, or continuing to be Person A in this charade.
> >   I think I've spoken my peace.   If you want to proceed with this work,
> > please do not be surprised if, when the call for adoption comes, I come
> > in and say "I raised substantive objections to this, which were not
> > addressed, so please do not take this on as a working group item."
>
> Ted,
>
> While I'm not concerned about the issues you raised in your caricature,
> I feel that I have tried to engage you in your discussion of different
> security models. My understanding is that your models devolve down to
> two. Either the user configures a resolver themselves (whether it's
> DOH/DOT or not), and user doesn't configure a resolver themselves. I
> recognize the distinction you made between your models 1 and 3, and
> further recognize that it's extremely important to some people. My point
> is that *from the standpoint of a DHCP option for DOH/DOT* it's not
> relevant.
>
>  From our discussion, it seems that you're in agreement with me that if
> a user isn't configuring a resolver explicitly that they are no worse
> off with DOH/DOT than they are without it. Am I right so far?
>
> Meanwhile, you've also voiced an opinion that the presence of a DHCP
> option implies some sort of endorsement by the IETF. I (and others)
> replied that we've never heard of this, and disagree strongly with your
> position.
>
> So other than the fact that we disagree on the endorsement issue, what
> am I missing here?
>
> Doug
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

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 the people you're conversing with say, 
then it's inevitably going to go like this:


[ Snipped a bunch of arguments I didn't make ]

This is why discussions balloon in the IETF.   So now I have the choice 
of either being silenced, or continuing to be Person A in this charade.  
  I think I've spoken my peace.   If you want to proceed with this work, 
please do not be surprised if, when the call for adoption comes, I come 
in and say "I raised substantive objections to this, which were not 
addressed, so please do not take this on as a working group item."


Ted,

While I'm not concerned about the issues you raised in your caricature, 
I feel that I have tried to engage you in your discussion of different 
security models. My understanding is that your models devolve down to 
two. Either the user configures a resolver themselves (whether it's 
DOH/DOT or not), and user doesn't configure a resolver themselves. I 
recognize the distinction you made between your models 1 and 3, and 
further recognize that it's extremely important to some people. My point 
is that *from the standpoint of a DHCP option for DOH/DOT* it's not 
relevant.


From our discussion, it seems that you're in agreement with me that if 
a user isn't configuring a resolver explicitly that they are no worse 
off with DOH/DOT than they are without it. Am I right so far?


Meanwhile, you've also voiced an opinion that the presence of a DHCP 
option implies some sort of endorsement by the IETF. I (and others) 
replied that we've never heard of this, and disagree strongly with your 
position.


So other than the fact that we disagree on the endorsement issue, what 
am I missing here?


Doug


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 DHCP DNS
option and adding that option will indisputably also come with a DoH
URI option too, I would think you would be arguing against any new
DHCP options for consistency.


no, sir. i must have misspoke. i have DoT available, but nothing uses 
it, though i am expecting android 9 ("Pie") which dropped yesterday to 
start opportunistically doing so. if that's the behaviour we want for 
stubs, we should document it instead of adding anything to DHCP.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Philip Homburg]

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 ISP may not want to run a recursive
resolver and instead refer to a public resolver using DHCP.

Additionally, on an open wifi, encrypting DNS traffic can help against 
snooping. So it is in the ISP's interest to announce that the local
recursive resolvers support DoH

>Well, DoT has been standardized for some time, and we now have multiple
>open-source implementations for client- and daemon-side, and some large
>public services support it.  DoH is a little later, but it might gather
>more speed eventually.  From *my* point of view the SNI is the biggest
>hindrance ATM; other technical issues don't seem bad, at least not for
>most motivated users.  (Finding a trusted service might be problem for
>some people, I suspect.)

For DNS, code is not enough. You need to get admins of recursive resolvers
to upgrade. And there are lots of those resolvers. Many of them almost
unmanaged.

DNS is for a large part not end-to-end. You have the recursive resolvers
as middle men.

>Defense against changing DNS is something else than privacy - we have
>DNSSEC for that, so you don't even need to trust the server sending you
>the data, but I think we're getting too much off-topic anyway...

DNSSEC is part of the puzzle, but leaves a lot of holes:
- Currently very few systems ship with locally validating resolvers. So
  most systems can be attacked on the last mile.
- Many domains are not signed for one reason or another. 
- Even with DNSSEC, an on path attacker can see the queries and selectively
  mount a denial of service attack.

DoH protects the last mile from all of those attacks.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

> 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 DNS Cookies are present
>> and using the existing DHCP DNS options 3. You seem happy with the
>> Android approach of just trying DoT with the IP address learned via
>> standard DHCP DNS options
>> 
>> Why do you care about additional DHCP options?
> 
> in my previous explaination as to the security model i follow, i noted that 
> the network paths to my dhcp server and my rdns servers were different, and 
> that in the dhcp case i have far more observability and control than in the 
> rdns case.
> 
> 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 DHCP DNS option and 
adding that option will indisputably also come with a DoH URI option too, I 
would think you would be arguing against any new DHCP options for consistency.

Tom

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Philip Homburg]

>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, you can easily burn through a
couple of Gbyte in an hour.

>How many browsers can I choose from? Definitely many less than the possible IS
>Ps, and not a single one from the jurisdiction I live in.

Many places have essentially two landline options. Only 3 mobile network is
also quite common. 

In addition, two serious browsers are open source. And there are firefox
forks that try to fix some of the damage done by mozilla.

>> There are many ISPs that try to do the right thing for their customers.
>> There are quite a few ISPs that have court orders to do things that go again
>st the interests of their customers.
>
>Yes, but that's the law. I still don't get how is it possible that the IETF is
> releasing a technology openly designed to allow people to break the law. In m
>y part of the world, this is ethically unacceptable, and possibly also illegal
>.

It is not that black and white. In the Netherlands, a few ISPs are forced to
block access to The Pirate Bay.

That court order applies only to those ISPs, consumers are completely free
to visit The Pirate Bay.


>No, they can't, if the application defaults to its own resolvers, possibly not
> even letting the user choose different resolvers unless they click into three
>-level-deep configuration menus.

Anybody can write an application that does weird stuff. That's not something
a RFC can prevent.

>> The big difference is that when the user does decide to bypass the ISP's
>> resolvers, there will be no way for the ISP to interfere.
>
>Good luck explaining that to several hundred governments that rely on mandator
>y DNS filters to enforce gambling, hate speech and pornography regulation.

Governments will figure out that eventually protocols that communicate in
plaintext will die out. Of course, they can mandate the use of plaintext in
their respective countries, at their own economic disadvantage.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 seem happy with the
Android approach of just trying DoT with the IP address learned via
standard DHCP DNS options

Why do you care about additional DHCP options?


in my previous explaination as to the security model i follow, i noted 
that the network paths to my dhcp server and my rdns servers were 
different, and that in the dhcp case i have far more observability and 
control than in the rdns case.


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.)


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

> 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 i am not vittorio, i will punch in as follows.
> 
> i do not expect CF to block resolution of its free-tier of CDN 
> pseudo-customers; if they thought those folks didn't deserve DNS, they would 
> probably think they didn't deserve CDN services either.
> 
> i block quite a few free-tier CF CDN pseudo-customers here, because that 
> service tier is widely abused. since the addresses associated with these 
> low-value pseudo-customers are shared by their paying customers, i can't 
> block them at the IP layer. so i block them using DNS RPZ. (i do not publish 
> this RPZ because in 1997 or so i got tired of lawsuits.)
> 
> anyhow, this is but one of many reasons why i don't want control-plane 
> information injected into my network, bypassing my security perimeter. while 
> CF is a special case, the general case is where my policies are aligned 
> somewhat differently than the user's policies or the content provider's 
> policies or the "public DoH" server operator's policies.
> 
> my network, my rules. one rule is, no bot-on-bot violence in my house.
> 
> -- 
> P Vixie

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 seem happy with the Android approach of just trying DoT with the IP 
address learned via standard DHCP DNS options

Why do you care about additional DHCP options?

Thanks,
Tom


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 either have to visit a very large 
number of completely unrelated destinations, or will have to visit the 
same site or site-cluster many times. i consider the former unlikely, 
and have therefore limited my thinking to the latter.


in the case where someone is visiting the same site or site-cluster many 
times, the cost of fetching the necessary crypto-chain materials will 
only be borne once, or at worst very infrequently, due to caching.


this means that the difference between having the crypto-chain pushed to 
you in advance by someone who can predict where you're about to go 
because they're also sending you content with those references, will be 
so rare as to be non-impacting.


in addition, DoH is not connected to web service in any necessary way. 
the DoH channel will be to a DoH provider such as CF. while there's a 
good chance in today's internet that you'll also be fetching content 
from CF, there are in fact other CDN's and many non-CDN content hosts. 
if you are talking to any content host other than CF, then the CF DoH 
service will have no knowledge of what to push toward you.


in further addition, even in the case where you have a persistent CF DoH 
connection open, it may not be easy for CF to share enough 
connection-state between its DoH and other-content servers so that the 
one will be able to push crypto-chain information to you in support of 
the other.


in short, i don't think DoH can usefully optimize by pushing.

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 resolution of its free-tier of CDN 
pseudo-customers; if they thought those folks didn't deserve DNS, they 
would probably think they didn't deserve CDN services either.


i block quite a few free-tier CF CDN pseudo-customers here, because that 
service tier is widely abused. since the addresses associated with these 
low-value pseudo-customers are shared by their paying customers, i can't 
block them at the IP layer. so i block them using DNS RPZ. (i do not 
publish this RPZ because in 1997 or so i got tired of lawsuits.)


anyhow, this is but one of many reasons why i don't want control-plane 
information injected into my network, bypassing my security perimeter. 
while CF is a special case, the general case is where my policies are 
aligned somewhat differently than the user's policies or the content 
provider's policies or the "public DoH" server operator's policies.


my network, my rules. one rule is, no bot-on-bot violence in my house.

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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.

...


while any company can be scummy, some aren't. the ISP in this case may 
be a value added security vendor who also offers IP transit. if you want 
to do business with a scummy ISP, or if you have no choice, then they 
should still have the ability to transparently prevent you from doing 
things you want to do. (transparently means you know it's happening and 
can decide to just unplug if you don't like it.)


my ISP is comcast, and i use their RDNS servers as backups to my own, 
because i trust them to run dnssec and rdns, and to not filter content. 
your perspective may differ; one trust model will not fit all situations.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jim Reid]

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 -- whatever that is -- make such a 
statement? In some cases, it will be better to use the current network’s 
resolving DNS servers. In others it won’t. For some definition of “better”. The 
use or non-use of DoH is somewhat orthogonal to those underlying 
considerations. 

Deciding what’s “good” or “bad" gets very messy very quickly. For instance I 
might decide to trust $coffeeshop’s resolver in my home town (say) but not at a 
branch of $coffeeshop that's behind the Great Firewall of China. Or 
$coffeeshop’s outlet in the foyer of my employer’s building.

> Actually, during the discussions in Montreal there were people talking about 
> centralized DNS operators paying the browser makers to get their DNS traffic, 
> and then monetizing it to get back the money. How can this be presented as 
> "more privacy" is baffling.

If this happens, it can be worked around. Almost nobody is going to be forced 
to use privacy-unfriendly browsers or resolvers at gunpoint. Besides, providers 
offering “even more privacy” will emerge if this centralisation/monetisation 
thing turns out to be a problem. Having low barriers to entry is one of the 
nice things about the Internet. Well OK, it’s a nice thing some of the time. :-)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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.   This doesn't mean that it doesn't suck for you to not be
able to collect the data, because at a university you presumably want to be
able to do research on the data.   But that's one of the tensions here.
 The answer to the observation "security requires us to make unpalatable
tradeoffs" is not "don't do security."

On Tue, Aug 21, 2018 at 1:52 PM, Bob Harold  wrote:

>
> On Tue, Aug 21, 2018 at 1:37 PM David Conrad  wrote:
>
>> Vittorio,
>>
>> On Aug 21, 2018, at 3:33 AM, Vittorio Bertola > 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 him. But I
>> don't see why the best solution to your use case - which is quite a
>> minority case, though easily overrepresented in a technical environment -
>> is to build a sort of "nuclear bomb" protocol that, if widely adopted, will
>> destroy most of the existing practices in the DNS "ecosystem" (I'm using
>> the word that was being used at ICANN's DNS Symposium in Montreal),
>> including the basic security measures that protect the 99.9% of the users
>> who are not technically smart.
>>
>>
>> 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?
>>
>> Regards,
>> -drc
>>
>
> At my university, our security group watches DNS rpz logs and DNS traffic
> logs for signs of malware, and takes action.  In a DoH world, I cannot
> imagine every third-party DoH provider giving our security group that
> information.  They will follow their own security measures, but will still
> affect ours because we lose visibility.
>
> --
> Bob Harold
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

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 him. But I don't see
> why the best solution to your use case - which is quite a minority case,
> though easily overrepresented in a technical environment - is to build a
> sort of "nuclear bomb" protocol that, if widely adopted, will destroy most
> of the existing practices in the DNS "ecosystem" (I'm using the word that
> was being used at ICANN's DNS Symposium in Montreal), including the basic
> security measures that protect the 99.9% of the users who are not
> technically smart.
>
>
> 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?
>
> Regards,
> -drc
>

At my university, our security group watches DNS rpz logs and DNS traffic
logs for signs of malware, and takes action.  In a DoH world, I cannot
imagine every third-party DoH provider giving our security group that
information.  They will follow their own security measures, but will still
affect ours because we lose visibility.

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[David Conrad]

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, 
> though easily overrepresented in a technical environment - is to build a sort 
> of "nuclear bomb" protocol that, if widely adopted, will destroy most of the 
> existing practices in the DNS "ecosystem" (I'm using the word that was being 
> used at ICANN's DNS Symposium in Montreal), including the basic security 
> measures that protect the 99.9% of the users who are not technically smart. 

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?

Regards,
-drc

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

> 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 recursive server (UDP, TCP, or TLS) as currently deployed,
> you only need 1 round trip in simple cases or 2 round trips if there's a
> CNAME or SRV (etc.) because you know ahead of time all the queries you
> need to make to get the validation chain and they can trivially be
> pipelined.
> 
> Tony.

Yes, and with CHAIN Query Requests in DNS it’s even better. But this still 
can’t beat the fore knowledge the web/DoH server has about the page you’re 
viewing. The web/DoH server can HTTP/2 Push all of validation records for links 
you MAY click on in the future while you’re reading the page, taking into 
account the scroll position of your page. The validation can then be done in 
the browser before you click on the link and once you do, the browser knows the 
address and has validated it.

Tom


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

> 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 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 validation quickly for all of the links in a page in an order that
>>> the user is most likely to need based on previous statistics and
>>> scrolling position.
>> 
>> Could you elaborate how DOH helps here? I can't see it now.
>> 
>> We already have RFC 7901 (Chain Query requests in DNS) which allows
>> resolvers to get all RRs required for DNSSEC validation in one round
>> trip even over "classic" DNS.
>> 
>> This haven't been implemented because up to know browser vendors have
>> not been interested in DNSSEC which consequently lead us (resolver
>> vendors) to ignore complex RFC with no demand.
>> 
>>> From my point of view DOH does not change anything in this regard,
>> complexity on stub & resolver side is the same no matter what transport
>> is used.
>> 
>> What am I missing? How does DOH help with this complexity when compared
>> to classical DNS?
> 
> I think Tom is referring to the h/2 push semantics. The resolver can
> push the trust chain records
> ahead of time, so the forwarder will already have them in cache when
> revalidating the final answer.

Yes, plus the fact that the web/DoH server already knows all of the questions 
you might ask because it just fed you a page of content with links.

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.

Tom



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 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 (yet).  That's
> >> what people usually forget to consider.
> >> [...]
> > This is too some extent a chicken and egg problem. Without encrypted DNS
> > there is no point in encrypted SNI and vice versa.
>
> Yes, partially.
>
> > I expect that encrypted SNI will be relatively easy to deploy. It can
> happen
> > as soon as both endpoints support it.
> >
> > In contrast, DNS is a very complex eco system. So it makes sense to start
> > deploying encrypted DNS now, under the assumption that encrypted SNI will
> > follow.
>
> Well, DoT has been standardized for some time, and we now have multiple
> open-source implementations for client- and daemon-side, and some large
> public services support it.  DoH is a little later, but it might gather
> more speed eventually.  From *my* point of view the SNI is the biggest
> hindrance ATM; other technical issues don't seem bad, at least not for
> most motivated users.  (Finding a trusted service might be problem for
> some people, I suspect.)
>
> >> After SNI encryption gets widely deployed, tracking through IP addresses
> >> only will be somewhat harder, so there it will start getting
> >> interesting.
> > We have seen already that 'domain fronting' is can be a very effective
> way
> > to bypass filters. For large CDNs or cloud providers, filtering based on
> > IP addresses is not going to be effective.
>
> Centralizing most of the traffic to a few CDN providers would solve
> that, but somehow I don't think privacy should depend on that.  And I
> don't think it's so easy to significantly reduce the information leak -
> you just *move* it to somewhere else (someone else), and it's not really
> clear to me in general who is more trustworthy.  Still, such
> possibilities certainly are nice to have.
>
> >> Until then, IMHO you just need to either trust the ISP or
> >> tunnel *all* traffic to somewhere, e.g. via tor or VPN to some trusted
> >> party.
> > True. But we can take small steps to reduce unwanted interference from
> ISPs.
> >
> > From a security point of view, it helps a lot if you can just trust DNS..
> > Instead of always having to take into account that somebody may
> interfere
> > with DNS replies.
>
> Defense against changing DNS is something else than privacy - we have
> DNSSEC for that, so you don't even need to trust the server sending you
> the data, but I think we're getting too much off-topic anyway...
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vladimír Čunát]

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 (yet).  That's
>> what people usually forget to consider.
>> [...]
> This is too some extent a chicken and egg problem. Without encrypted DNS 
> there is no point in encrypted SNI and vice versa.

Yes, partially.

> I expect that encrypted SNI will be relatively easy to deploy. It can happen
> as soon as both endpoints support it.
>
> In contrast, DNS is a very complex eco system. So it makes sense to start
> deploying encrypted DNS now, under the assumption that encrypted SNI will
> follow.

Well, DoT has been standardized for some time, and we now have multiple
open-source implementations for client- and daemon-side, and some large
public services support it.  DoH is a little later, but it might gather
more speed eventually.  From *my* point of view the SNI is the biggest
hindrance ATM; other technical issues don't seem bad, at least not for
most motivated users.  (Finding a trusted service might be problem for
some people, I suspect.)

>> After SNI encryption gets widely deployed, tracking through IP addresses
>> only will be somewhat harder, so there it will start getting
>> interesting.
> We have seen already that 'domain fronting' is can be a very effective way
> to bypass filters. For large CDNs or cloud providers, filtering based on 
> IP addresses is not going to be effective.

Centralizing most of the traffic to a few CDN providers would solve
that, but somehow I don't think privacy should depend on that.  And I
don't think it's so easy to significantly reduce the information leak -
you just *move* it to somewhere else (someone else), and it's not really
clear to me in general who is more trustworthy.  Still, such
possibilities certainly are nice to have.

>> Until then, IMHO you just need to either trust the ISP or
>> tunnel *all* traffic to somewhere, e.g. via tor or VPN to some trusted
>> party.
> True. But we can take small steps to reduce unwanted interference from ISPs.
>
> From a security point of view, it helps a lot if you can just trust DNS.
> Instead of always having to take into account that somebody may interfere 
> with DNS replies.

Defense against changing DNS is something else than privacy - we have
DNSSEC for that, so you don't even need to trust the server sending you
the data, but I think we're getting too much off-topic anyway...

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 know when we are in that situation and not in some other
situation?   I think this is a solvable problem, but we have to say what
the solution is.   That's what I've been advocating for here.

Yes, but that's the law. I still don't get how is it possible that the IETF
> is releasing a technology openly designed to allow people to break the law.
> In my part of the world, this is ethically unacceptable, and possibly also
> illegal.
>

It's illegal in some countries for women to drive.   Should we stop making
cars?   Is it ethically unacceptable to make cars because women might use
them to violate this law in jurisdictions where it exists?

Why would you ever use an ISP that you don't trust and that is positively
> evil?
>

There is often no alternative.


> Ok, this is the real issue. There is no reason why, but this is how it is
> being deployed, starting with Mozilla. 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. Actually, during the discussions in Montreal there were
> people talking about centralized DNS operators paying the browser makers to
> get their DNS traffic, and then monetizing it to get back the money. How
> can this be presented as "more privacy" is baffling.
>

The DoH community does not have consensus on this, so it can't make a
statement about it.


> Perhaps what we are missing is just a set of policy guidelines on how DoH
> should be deployed by operators and application developers, though I do not
> know how you could then enforce them.
>

We can't write a set of policy guidelines.   That's an issue that will vary
by jurisdiction.   What we can do is document the threat model, document
the use cases, and talk about how to address them.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Philip Homburg]

>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 the ISP, and in addition you share the
>names with some other party.  That doesn't sound very appealing to me
>personally, from privacy point of view at least.  (On the other hand,
>big resolvers will have lots of cached answers, etc.)

This is too some extent a chicken and egg problem. Without encrypted DNS 
there is no point in encrypted SNI and vice versa.

I expect that encrypted SNI will be relatively easy to deploy. It can happen
as soon as both endpoints support it.

In contrast, DNS is a very complex eco system. So it makes sense to start
deploying encrypted DNS now, under the assumption that encrypted SNI will
follow.

>After SNI encryption gets widely deployed, tracking through IP addresses
>only will be somewhat harder, so there it will start getting
>interesting.

We have seen already that 'domain fronting' is can be a very effective way
to bypass filters. For large CDNs or cloud providers, filtering based on 
IP addresses is not going to be effective.

>Until then, IMHO you just need to either trust the ISP or
>tunnel *all* traffic to somewhere, e.g. via tor or VPN to some trusted
>party.

True. But we can take small steps to reduce unwanted interference from ISPs.

>From a security point of view, it helps a lot if you can just trust DNS.
Instead of always having to take into account that somebody may interfere 
with DNS replies.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vittorio Bertola]

> 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 user, I think there is little reason to trust an ISP.
> 
> If you take a mobile device, do you trust every hotel, bar, etc. where you
> may connect to the wifi? Are they all competent? Are you sure none of them 
> will
> violate your privacy?

Sure, roaming at hotels and cafes is a good use case for encrypted DNS, though 
for many people it is not the typical Internet access situation (not everyone 
travels to conferences all the time). Most people here in Europe either access 
the Internet at home or at work through DSL or fiber, or access it on their 
mobile phone using the mobile operator's data network. 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-wide mobile data per month included with their base mobile fee.

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.

> If you have only a few ISPs to chose from, do you trust that ISP?

How many browsers can I choose from? Definitely many less than the possible 
ISPs, and not a single one from the jurisdiction I live in.
 
> There are many ISPs that try to do the right thing for their customers.
> There are quite a few ISPs that have court orders to do things that go 
> against the interests of their customers.

Yes, but that's the law. I still don't get how is it possible that the IETF is 
releasing a technology openly designed to allow people to break the law. In my 
part of the world, this is ethically unacceptable, and possibly also illegal.

> And the are quite a few ISPs that are positively evil.
> 
> You need to have options in case you can't trust the ISP.

Why would you ever use an ISP that you don't trust and that is positively evil?

> > build a sort of "nuclear bomb" protocol
> > that, if widely adopted, will destroy most of the existing practices
> > in the DNS "ecosystem" 
> 
> There is no reason why DoH has to be deployed as a 'nuclear bomb'.

Ok, this is the real issue. There is no reason why, but this is how it is being 
deployed, starting with Mozilla. 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. 
Actually, during the discussions in Montreal there were people talking about 
centralized DNS operators paying the browser makers to get their DNS traffic, 
and then monetizing it to get back the money. How can this be presented as 
"more privacy" is baffling.

Perhaps what we are missing is just a set of policy guidelines on how DoH 
should be deployed by operators and application developers, though I do not 
know how you could then enforce them.

> Hosts can still default to using the resolvers offered by DHCP only switching
> to public resolvers when directed by the user.

No, they can't, if the application defaults to its own resolvers, possibly not 
even letting the user choose different resolvers unless they click into 
three-level-deep configuration menus.

> The big difference is that when the user does decide to bypass the ISP's
> resolvers, there will be no way for the ISP to interfere.

Good luck explaining that to several hundred governments that rely on mandatory 
DNS filters to enforce gambling, hate speech and pornography regulation.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vladimír Čunát]

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 reason to trust an ISP.
>
> If you take a mobile device, do you trust every hotel, bar, etc. where you
> may connect to the wifi? Are they all competent? Are you sure none of them 
> will
> violate your privacy?

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 the ISP, and in addition you share the
names with some other party.  That doesn't sound very appealing to me
personally, from privacy point of view at least.  (On the other hand,
big resolvers will have lots of cached answers, etc.)

https://tools.ietf.org/html/draft-rescorla-tls-esni-00

After SNI encryption gets widely deployed, tracking through IP addresses
only will be somewhat harder, so there it will start getting
interesting.  Until then, IMHO you just need to either trust the ISP or
tunnel *all* traffic to somewhere, e.g. via tor or VPN to some trusted
party.

--Vladimir

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Philip Homburg]

> 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, do you trust every hotel, bar, etc. where you
may connect to the wifi? Are they all competent? Are you sure none of them will
violate your privacy?

If you have only a few ISPs to chose from, do you trust that ISP?

There are many ISPs that try to do the right thing for their customers.
There are quite a few ISPs that have court orders to do things that go against
the interests of their customers.
And the are quite a few ISPs that are positively evil.

You need to have options in case you can't trust the ISP.

> build a sort of "nuclear bomb" protocol
> that, if widely adopted, will destroy most of the existing practices
> in the DNS "ecosystem" 

There is no reason why DoH has to be deployed as a 'nuclear bomb'.

Hosts can still default to using the resolvers offered by DHCP only switching
to public resolvers when directed by the user.

The big difference is that when the user does decide to bypass the ISP's
resolvers, there will be no way for the ISP to interfere.

Of course, an ISP can still try to block encrypted access to 8.8.8.8, etc.
Ultimately, that may result in users routing their requests over tor. In
areas with netneutrality laws, blocking access to public resolvers is probably
not an option.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 this:

Person A: I think that there are some issues here that we need to consider,
and that your use model is the not the only use model we need to think
about.
Person B: You want the malware operators to take over the Internet
Person A: No, I didn't say that.   I get that your use model makes sense to
you, and we should address your use model.   I'm just saying it's not the
only use model we should address
Person B: Right, you're saying that I shouldn't be able to control what
happens on my network.
Person A: No, I'm really not saying that.   I'm saying we need to consider
other use cases as well.
Person B: So you're saying that we should also consider the use case where
you want to be able to bypass my controls and let the malware operators
control my network.
Person A: No, I'm NOT saying that.   I'm saying that there are legitimate
reasons why people might want to bypass DNS resolvers.
Person B: So you're helping the malware operators.

This is why discussions balloon in the IETF.   So now I have the choice of
either being silenced, or continuing to be Person A in this charade.   I
think I've spoken my peace.   If you want to proceed with this work, please
do not be surprised if, when the call for adoption comes, I come in and say
"I raised substantive objections to this, which were not addressed, so
please do not take this on as a working group item."
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

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 1 round trip in simple cases or 2 round trips if there's a
CNAME or SRV (etc.) because you know ahead of time all the queries you
need to make to get the validation chain and they can trivially be
pipelined.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
individual and social justice

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

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 lookup? I guess that would
> be too annoying for operators that want their DoH servers to be separate
> from their normal DNS resolvers, so maybe it's a bad idea :-)

There was an interesting discussion on Twitter last night -
https://twitter.com/PowerDNS_Bert/status/1031284355686178817

Bert Hubert made the point that https has a lot more opportunities for
identifying and tracking individual devices, compared to trad DNS. Home
gateways that act as DNS relays help with individual privacy, especially
if they also cache.

I think the implications of this, and the arguments that Paul Vixie has
been making, are that there will be unexpected privacy and security upsets
if the DoH resolution path is too different from the trad DNS resolution
path.

This is really a problem with how DoH is deployed and used. So it's
important to make it easy for operators to deploy DoH in a way that
doesn't have surprising privacy leaks when it is supposed to be a
privacy-enhancing technology. DHCP options can help to make all the
DoTH stuff behave in a similar way to the network's trad DNS - it's much
simpler from the user's perspective if they only need to worry about how
respectful or abusive their network provider is as a whole, without having
to get into the details of exactly which resolution protocol they are
using.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Humber, Thames, Dover: Southwest 4 or 5, occasionally 6, except in Humber.
Slight, occasionally moderate. Fog patches at first. Moderate or good,
occasionally very poor at first.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vittorio Bertola]

> 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 don't want the users to see it at all.

It's true, and there is an additional consideration to this: the users that do 
so are not just damaging themselves, but everyone else, by spreading the 
infections and becoming attack vectors. I understand why some people are 
conceptually irked by the idea that the ISP can decide on its own to make 
something unreachable to them, but they should understand that most Internet 
users are not technically savvy, often not savvy at all, and this threatens the 
Internet as a whole.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vittorio Bertola]

> 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 would have a significant impact on how the Internet 
works, there are conflicting views in different parts of the IETF community and 
a lot of non-technical concerns outside of it, please work on it until everyone 
is happy. But possibly I don't understand how the IETF works yet.

Regards,
-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vittorio Bertola]

> 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 your 
> > freedom of expression, so I guess it is censoring legitimate websites - 
> > this is bad, of course, but can you tell me which operator, and which 
> > websites? It would help my understanding of your use case.
>  
> No, it's not bad.   It's the service they offer, and it's fine that they 
> offer it.   I think it's the right default.   It's also fine that I choose to 
> bypass it.

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). I also imagine that your ISP 
is doing some transparent proxying/scanning so that you cannot simply bypass 
this filter by configuring a different resolver in your OS, right? (which, by 
the way, is the simple solution to your problem that is already available and 
widely used across the world - see the famous picture of people painting 
8.8.8.8 on walls in Turkey)
 
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, though easily 
overrepresented in a technical environment - is to build a sort of "nuclear 
bomb" protocol that, if widely adopted, will destroy most of the existing 
practices in the DNS "ecosystem" (I'm using the word that was being used at 
ICANN's DNS Symposium in Montreal), including the basic security measures that 
protect the 99.9% of the users who are not technically smart. Perhaps it would 
have been enough for you to have a discussion with your ISP and get them to 
give you an opt-out, which is entirely possible with today's DNS filtering 
techniques - or to just change to another ISP.
 
Anyway, this looks to me a lot like a policy issue, rather than a technical 
one; and the more I get into this discussion, the more DoH looks like "the IETF 
against the world's governments and ISPs" - not a good thing, IMHO.

> Yes, and if we come up with a solution that allows both situations to be 
> securely communicated to the end user device, and allows the end user to make 
> an informed decision about whether or not to use the service with these 
> restrictions in place, I'm okay with that, and I think it's appropriate for 
> the IETF to do it.   What I am arguing is that we should actually describe 
> how to do that, and not just hack together a solution without thinking about 
> that.

I would be fine with this approach and happy to work on it, as long as there is 
an agreement by the DoH/browsers community that DoH will not be deployed to the 
general public until this missing piece is completed and implemented. Otherwise 
it would just be a waste of time.

Regards, 
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Marek Vavruša]

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 webserver could package
>> up all those validated records and push them so the client/stub could do
>> the validation quickly for all of the links in a page in an order that
>> the user is most likely to need based on previous statistics and
>> scrolling position.
>
> Could you elaborate how DOH helps here? I can't see it now.
>
> We already have RFC 7901 (Chain Query requests in DNS) which allows
> resolvers to get all RRs required for DNSSEC validation in one round
> trip even over "classic" DNS.
>
> This haven't been implemented because up to know browser vendors have
> not been interested in DNSSEC which consequently lead us (resolver
> vendors) to ignore complex RFC with no demand.
>
> >From my point of view DOH does not change anything in this regard,
> complexity on stub & resolver side is the same no matter what transport
> is used.
>
> What am I missing? How does DOH help with this complexity when compared
> to classical DNS?

I think Tom is referring to the h/2 push semantics. The resolver can
push the trust chain records
ahead of time, so the forwarder will already have them in cache when
revalidating the final answer.

> Petr Špaček  @  CZ.NIC
>
>
>> Tom
>>
>>> On 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
>>> 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 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 >>> > 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
 >> browser and DoT is tried and used on all DNS servers, there’s not a
 >> problem to solve.
 >
 > 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 it. browsers are where most
 modern vulns have occurred, and i expect that trend to
 accelerate. "because that's where the money was.”

 I can see good use cases and bad ones.

 If web servers did DNSSEC validation and only served addresses
 for names that were validated, I wouldn’t have a problem with
 that at all.

 If web servers only served addresses for names within the domain
 of the web server, I wouldn’t have a problem with that either.

 if they start serving non DNSSEC validated addresses for names
 outside their domain, I think they’re overreaching.

 Tom
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Petr Špaček]

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 them so the client/stub could do
> the validation quickly for all of the links in a page in an order that
> the user is most likely to need based on previous statistics and
> scrolling position.

Could you elaborate how DOH helps here? I can't see it now.

We already have RFC 7901 (Chain Query requests in DNS) which allows
resolvers to get all RRs required for DNSSEC validation in one round
trip even over "classic" DNS.

This haven't been implemented because up to know browser vendors have
not been interested in DNSSEC which consequently lead us (resolver
vendors) to ignore complex RFC with no demand.

>From my point of view DOH does not change anything in this regard,
complexity on stub & resolver side is the same no matter what transport
is used.

What am I missing? How does DOH help with this complexity when compared
to classical DNS?

Petr Špaček  @  CZ.NIC


> Tom
> 
>> On 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
>> 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 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 >> > 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
>>> >> browser and DoT is tried and used on all DNS servers, there’s not a
>>> >> problem to solve.
>>> > 
>>> > 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 it. browsers are where most
>>> modern vulns have occurred, and i expect that trend to
>>> accelerate. "because that's where the money was.”
>>>
>>> I can see good use cases and bad ones.
>>>
>>> If web servers did DNSSEC validation and only served addresses
>>> for names that were validated, I wouldn’t have a problem with
>>> that at all.
>>>
>>> If web servers only served addresses for names within the domain
>>> of the web server, I wouldn’t have a problem with that either.
>>>
>>> if they start serving non DNSSEC validated addresses for names
>>> outside their domain, I think they’re overreaching.
>>>
>>> Tom

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

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 folks on the mic line disagreed 
with the assumption that, given two pieces of insecurely-acquired 
information (a Do53 address and a DoH template) that the latter would 
result with a more secure connection. A network admin can see the port 
53 traffic and see if there's crap in there; they can't see the inner 
DoH traffic.


Paul,

You, like Ted, are looking at the problem the wrong way 'round. The USER 
is no worse with a DOH/DOT DHCP option than they are with the existing 
resolver option. 99.% of users don't even know what DHCP 
is, they just want to connect their iDevice to the coffee shop WiFi.


Unless you can show how the user is harmed by the option, it's silly to 
oppose it.


Now, the network operator may very well be harmed by not being able to 
see the user's DNS traffic, if they are not the ones operating the 
resolver; because their opportunities to monetize NXDOMAIN, sell user 
data, etc. may be reduced, or go away entirely. If they ARE operating 
the resolver, they can still see all the DNS traffic they want to. And 
operators in the former case won't use the option anyway.


So again, what is the harm, to real world users, for having DHCP options 
to configure DOH or DOT?


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

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 IPv6, SLAAC generally provides this.


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


My experience corroborates Paul’s observation.


Saying this is all broken and that we need to protect the world from
themselves by not having a DHCP option simply means that vendors will
have a slew of non-standard ways of doing it and we've helped noone.


…and I agree with his conclusion.

 -Bill


+1, FWIW

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bill Woodcock]

> 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 this.
>> 
> That may be the consensus at the IETF but it's not even close the
> consensus with ISPs, nor large enterprise. That seems to cover most of
> the eyeball/consumer... DHCP is still how much of the world gets
> connected and that hasn't changed in decades.
> DHCP is how hotspots, ISPs and enterprise work.

My experience corroborates Paul’s observation.

> Saying this is all broken and that we need to protect the world from
> themselves by not having a DHCP option simply means that vendors will
> have a slew of non-standard ways of doing it and we've helped noone.

…and I agree with his conclusion.

-Bill



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

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 see their network operator as a hostile
entity that uses the DNS to censor content and probably stuffs ads
instead of NXDOMAIN.

The other group sees the network operator as a major line of defense
against malware, phishes, and all of the other evil stuff on the
Internet, making it harder for the naive and wilfully clueless to
hurt themselves.*


The two aren't mutually exclusive but it is my impression that unless
you live a country toward the repressive end of the spectrum, your
network is likely to do more of the latter than the former, and if you
are in repression land, they probably have a firewall that will keep
DoH from doing what the first group believes it will.

R's,
John

* - 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 don't want the users to see it at all.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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
done, perhaps we wouldn't have advanced it.   So why are you now arguing
that the IETF shouldn't do a similarly good job of modeling the threats
around configuring DoH using DHCP?

On Mon, Aug 20, 2018 at 10:51 PM, Paul Vixie  wrote:

>
>
> 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 I
>> get
>> some of that bravery or willpower back.
>>
>
> 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.
>
> mine is, i monitor and control the network path between my dhcp client and
> my dhcp server very much more carefully than i can monitor and control the
> network path to RDNS servers. therefore i am comfortable having the former
> introduce me to the latter. other perspectives differ.
>
> --
> P Vixie
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 I get
some of that bravery or willpower back.


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.


mine is, i monitor and control the network path between my dhcp client 
and my dhcp server very much more carefully than i can monitor and 
control the network path to RDNS servers. therefore i am comfortable 
having the former introduce me to the latter. other perspectives differ.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Marek Vavruša]

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 you're right Ted, it should definitely be at written down and formalized
if we want to move forward.

I have to compose my thoughts on this first. I'll try next weekend if I get
some of that bravery or willpower back.

> 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
> DHCP server.   I actually proposed a protocol that would have worked nicely
> for TOFU, but it didn't get consensus, so we don't even have TOFU-level
> authenticity.
>
> The rest of what you said is nice, but "we have to balance theoretical risk
> versus sane and widespread deployment" is a statement that sounds a lot
> better if we do the math.   If we just decide to do something without doing
> the math, then we aren't really balancing anything.   We're just deciding
> not to do our homework, because math is hard.
>
> On Mon, Aug 20, 2018 at 10:26 PM, Paul Ebersman 
> wrote:
>>
>> 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> You're misquoting me and arguing against a point I didn't
>> pusateri> make. There was no one saying we don't need DHCP. There was a
>> pusateri> general agreement that DHCP should not be extended.
>>
>> pusateri> The DHC working group never completed the work for DHCP
>> pusateri> authentication. It's not trustworthy enough in its current
>> pusateri> form to add more things to it.
>>
>> And I'd argue that this is also an IETF opinion, not the majority of the
>> internet. There's a reason it's still the most widespread configuration
>> management for devices. "Not trustworthy enough to extend" is a fine
>> academic opinion but doesn't hold water in the marketplace.
>>
>> DHCP is no worse currently than TOFU. We trust that the OFFER packet
>> will be from the DHCP server we're supposed to use. Trust On First
>> Use. Not great but it works more than not. At least that's the argument
>> I kept hearing for TOFU. We actually have operational experience of
>> decades for DHCP and this isn't a wide spread enough problem to kill any
>> innovation forever because it's not perfect.
>>
>> If we want the world to use what the IETF develops, we have to be able
>> to balance theoretical risk vs sane and widespread deployment.
>>
>> If not, someone will just wind up shoving this into yet another DHCP
>> vendor option and every vendor will be different. That will be even less
>> secure.
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 could do
the validation quickly for all of the links in a page in an order that
the user is most likely to need based on previous statistics and
scrolling position.


that's what the DOT people said, and what mr. wouters said before he 
offered the first internet draft on certificate chain responses. so, 
yes, but DOH is somewhat late to that party, and shows some ignorance.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Ebersman]

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> push them so the client/stub could do the validation quickly
pusateri> for all of the links in a page in an order that the user is
pusateri> most likely to need based on previous statistics and scrolling
pusateri> position.

Agreed.

My discomfort with some current proposals where I get DNS answers to
questions I didn't ask yet would be a lot less if I had full validation
info to DNSSEC validate them. Even getting SRV and other service entry
points would be less if they're in the domain I'm already playing in and
the DNSSEC validate.

Trick with this will be getting browser support. We're still debating
why SRV is too many lookups vs CNAME at zone apex. Fingers crossed we
make progress on both.

For other apps, stubby seems like a fine way to get this in the app.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 it. browsers are where most modern vulns have
occurred, and i expect that trend to accelerate. "because that's
where the money was.”


I can see good use cases and bad ones.


all power tools can kill.


If web servers did DNSSEC validation and only served addresses for
names that were validated, I wouldn’t have a problem with that at
all.

If web servers only served addresses for names within the domain of
the web server, I wouldn’t have a problem with that either.

if they start serving non DNSSEC validated addresses for names
outside their domain, I think they’re overreaching.


DOH's use will be indiscriminate, and will reach DNS servers who have 
web protocol front ends, who will offer full-spectrum RDNS. there will 
be no binding or relation at all between the web content servers and the 
DNS content servers who happen to use web protocols. so, please worry.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 
security has a pretty good handle today on data plane attacks, even if 
delivered over https. they do not however have a handle on control plane 
attacks, such as can be delivered or administered via DNS.


http://www.circleid.com/posts/20100728_taking_back_the_dns/

if ubiquitous perimeter security policy bypass via https becomes the 
norm, then far more https will have to be intercepted or blocked than is 
done today. the DOH WG is playing chicken with network operators. i wish 
they could see down the road a bit further than they do.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

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 validation 
quickly for all of the links in a page in an order that the user is most likely 
to need based on previous statistics and scrolling position.

Tom

> On 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 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 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 > > > 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
>> >> browser and DoT is tried and used on all DNS servers, there’s not a
>> >> problem to solve.
>> > 
>> > 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 it. browsers are where most modern vulns have occurred, and i expect 
>> > that trend to accelerate. "because that's where the money was.”
>> 
>> I can see good use cases and bad ones.
>> 
>> If web servers did DNSSEC validation and only served addresses for names 
>> that were validated, I wouldn’t have a problem with that at all.
>> 
>> If web servers only served addresses for names within the domain of the web 
>> server, I wouldn’t have a problem with that either.
>> 
>> if they start serving non DNSSEC validated addresses for names outside their 
>> domain, I think they’re overreaching.
>> 
>> Tom
>> 
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org 
>> https://www.ietf.org/mailman/listinfo/dnsop 
>> 
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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
> 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 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  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
>> >> browser and DoT is tried and used on all DNS servers, there’s not a
>> >> problem to solve.
>> >
>> > 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 it. browsers are where most modern vulns have occurred, and i expect
>> that trend to accelerate. "because that's where the money was.”
>>
>> I can see good use cases and bad ones.
>>
>> If web servers did DNSSEC validation and only served addresses for names
>> that were validated, I wouldn’t have a problem with that at all.
>>
>> If web servers only served addresses for names within the domain of the
>> web server, I wouldn’t have a problem with that either.
>>
>> if they start serving non DNSSEC validated addresses for names outside
>> their domain, I think they’re overreaching.
>>
>> Tom
>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

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 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  > > 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
> >> browser and DoT is tried and used on all DNS servers, there’s not a
> >> problem to solve.
> > 
> > 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 it. browsers are where most modern vulns have occurred, and i expect 
> > that trend to accelerate. "because that's where the money was.”
> 
> I can see good use cases and bad ones.
> 
> If web servers did DNSSEC validation and only served addresses for names that 
> were validated, I wouldn’t have a problem with that at all.
> 
> If web servers only served addresses for names within the domain of the web 
> server, I wouldn’t have a problem with that either.
> 
> if they start serving non DNSSEC validated addresses for names outside their 
> domain, I think they’re overreaching.
> 
> Tom
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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
DHCP server.   I actually proposed a protocol that would have worked nicely
for TOFU, but it didn't get consensus, so we don't even have TOFU-level
authenticity.

The rest of what you said is nice, but "we have to balance theoretical risk
versus sane and widespread deployment" is a statement that sounds a lot
better if we *do the math.*   If we just decide to do something without
doing the math, then we aren't really balancing anything.   We're just
deciding not to do our homework, because math is hard.

On Mon, Aug 20, 2018 at 10:26 PM, Paul Ebersman 
wrote:

> 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> You're misquoting me and arguing against a point I didn't
> pusateri> make. There was no one saying we don't need DHCP. There was a
> pusateri> general agreement that DHCP should not be extended.
>
> pusateri> The DHC working group never completed the work for DHCP
> pusateri> authentication. It's not trustworthy enough in its current
> pusateri> form to add more things to it.
>
> And I'd argue that this is also an IETF opinion, not the majority of the
> internet. There's a reason it's still the most widespread configuration
> management for devices. "Not trustworthy enough to extend" is a fine
> academic opinion but doesn't hold water in the marketplace.
>
> DHCP is no worse currently than TOFU. We trust that the OFFER packet
> will be from the DHCP server we're supposed to use. Trust On First
> Use. Not great but it works more than not. At least that's the argument
> I kept hearing for TOFU. We actually have operational experience of
> decades for DHCP and this isn't a wide spread enough problem to kill any
> innovation forever because it's not perfect.
>
> If we want the world to use what the IETF develops, we have to be able
> to balance theoretical risk vs sane and widespread deployment.
>
> If not, someone will just wind up shoving this into yet another DHCP
> vendor option and every vendor will be different. That will be even less
> secure.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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  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
> >> browser and DoT is tried and used on all DNS servers, there’s not a
> >> problem to solve.
> >
> > 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 it. browsers are where most modern vulns have occurred, and i expect
> that trend to accelerate. "because that's where the money was.”
>
> I can see good use cases and bad ones.
>
> If web servers did DNSSEC validation and only served addresses for names
> that were validated, I wouldn’t have a problem with that at all.
>
> If web servers only served addresses for names within the domain of the
> web server, I wouldn’t have a problem with that either.
>
> if they start serving non DNSSEC validated addresses for names outside
> their domain, I think they’re overreaching.
>
> Tom
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Ebersman]

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> You're misquoting me and arguing against a point I didn't
pusateri> make. There was no one saying we don't need DHCP. There was a
pusateri> general agreement that DHCP should not be extended.

pusateri> The DHC working group never completed the work for DHCP
pusateri> authentication. It's not trustworthy enough in its current
pusateri> form to add more things to it.

And I'd argue that this is also an IETF opinion, not the majority of the
internet. There's a reason it's still the most widespread configuration
management for devices. "Not trustworthy enough to extend" is a fine
academic opinion but doesn't hold water in the marketplace.

DHCP is no worse currently than TOFU. We trust that the OFFER packet
will be from the DHCP server we're supposed to use. Trust On First
Use. Not great but it works more than not. At least that's the argument
I kept hearing for TOFU. We actually have operational experience of
decades for DHCP and this isn't a wide spread enough problem to kill any
innovation forever because it's not perfect.

If we want the world to use what the IETF develops, we have to be able
to balance theoretical risk vs sane and widespread deployment.

If not, someone will just wind up shoving this into yet another DHCP
vendor option and every vendor will be different. That will be even less
secure.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 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 no ubiquitous
> bypass occurring. i urge you to consider my level of commitment to this
> state of affairs, and whether i'm alone, and what could happen if it's
> threatened by the DOH WG's work.
>
> >If you disagree with me about this (and I can think of a few reasons
> > why you might) then you should articulate what is possible with DoH that
> > isn't already possible with HTTPS.
>
> done.
>
> --
> P Vixie
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

> 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
>> browser and DoT is tried and used on all DNS servers, there’s not a
>> problem to solve.
> 
> 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 it. 
> browsers are where most modern vulns have occurred, and i expect that trend 
> to accelerate. "because that's where the money was.”

I can see good use cases and bad ones.

If web servers did DNSSEC validation and only served addresses for names that 
were validated, I wouldn’t have a problem with that at all.

If web servers only served addresses for names within the domain of the web 
server, I wouldn’t have a problem with that either.

if they start serving non DNSSEC validated addresses for names outside their 
domain, I think they’re overreaching.

Tom


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 to solve.


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 it. browsers are where most modern vulns have occurred, and 
i expect that trend to accelerate. "because that's where the money was."


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

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

You’re misquoting me and arguing against a point I didn’t make. There was no 
one saying we don’t need DHCP. There was a general agreement that DHCP should 
not be extended.

The DHC working group never completed the work for DHCP authentication. It’s 
not trustworthy enough in its current form to add more things to it.

> 
> Saying this is all broken and that we need to protect the world from
> themselves by not having a DHCP option simply means that vendors will
> have a slew of non-standard ways of doing it and we've helped noone.
> 
> Let's just give the option, document the security holes and risks and at
> least offer much of the world a standard way of doing this if they so
> choose.

Again, some better understanding of DoH deployment would help. 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 to solve.

Tom

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Marek Vavruša]

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 with UDP. If
>> they’re able to make a DoT connection, they’ll use it. This doesn’t
>> provide for a way to have an ADN to verify the certificate but a PTR
>> query can give you a name to do certificate validation and/or DANE
>> validation. So they seemed to be making the point that no DHCP
>> extensions were necessary.
>
>
> that's a cool hack, showing once again DoT's superiority over DoH.

This has been used to detect DoH support in dnscrypt-proxy as well.
One subtle issue with probing is that "it doesn't work" is not the
same as "it's not supported".
It can mean that port/traffic is being blocked, client is
incompatible, crypto is incompatible, etc.,
so it's difficult to distinguish whether the service is being offered
but unavailable for various reasons,
and service not being offered.

> --
> P Vixie
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 DHCP in IPv4
pusateri>  for address/router info and then use trusted sources for
pusateri>  everything else. In IPv6, SLAAC generally provides this.

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


+1.

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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. This doesn’t
provide for a way to have an ADN to verify the certificate but a PTR
query can give you a name to do certificate validation and/or DANE
validation. So they seemed to be making the point that no DHCP
extensions were necessary.


that's a cool hack, showing once again DoT's superiority over DoH.

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Ebersman]

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 address/router info and then use trusted sources for
pusateri> everything else. In IPv6, SLAAC generally provides this.

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

pusateri> One more point (from the Android crowd) was that they are
pusateri> going to try to connect to the DNS server's IP address using
pusateri> port 853 using DoT at the same time they are trying to resolve
pusateri> names over port 53 with UDP. If they're able to make a DoT
pusateri> connection, they'll use it. This doesn't provide for a way
pusateri> to have an ADN to verify the certificate but a PTR query can
pusateri> give you a name to do certificate validation and/or DANE
pusateri> validation. So they seemed to be making the point that no DHCP
pusateri> extensions were necessary.

The google/android crowd's bias against DHCP and DHCPv6 is well known
and is why android is having trouble penetrating said enterprise
market.

Getting DOH via DHCP is the same argument as TOFU and the IETF has used
TOFU.

DHCP is how hotspots, ISPs and enterprise work. Users able to understand
security risks and who read drafts from the IETF already know how to
deal with this and won't need a DHCP option. Much of the world does need
and want configure hosts/devices via DHCP.

Saying this is all broken and that we need to protect the world from
themselves by not having a DHCP option simply means that vendors will
have a slew of non-standard ways of doing it and we've helped noone.

Let's just give the option, document the security holes and risks and at
least offer much of the world a standard way of doing this if they so
choose.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

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 DoH, the DHCP option ought to include a URI template (there
isn't a .well-known for DoH). I plan to set up my servers so that
misdirected attempts to get web pages from the DoH server are 
redirected

to the relevant documentation; that's much easier if the DoH endpoint
isn't at the server root.


Our variant of this same idea that Willem Toorop and I presented at 
the DRIU BOF in Montréal has a URI for the DoH case:


https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00 



But let me remind everyone that there was a lot of people agreeing 
with Ted in Montréal and so far, Ted appears to be standing all by 
himself.


Where are all the other folks that shot down this idea earlier? :)


Judging what was said at an excited mic line is always challenging. :-) 
Two issues are being conflated here:

1) a DHCP option to include a URI template
2) how the DHCP client in an OS would use that option

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 folks on the mic line disagreed 
with the assumption that, given two pieces of insecurely-acquired 
information (a Do53 address and a DoH template) that the latter would 
result with a more secure connection. A network admin can see the port 
53 traffic and see if there's crap in there; they can't see the inner 
DoH traffic.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom Pusateri]

> 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 to include a URI template (there
> isn't a .well-known for DoH). I plan to set up my servers so that
> misdirected attempts to get web pages from the DoH server are redirected
> to the relevant documentation; that's much easier if the DoH endpoint
> isn't at the server root.

Our variant of this same idea that Willem Toorop and I presented at the DRIU 
BOF in Montréal has a URI for the DoH case:

https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00 


But let me remind everyone that there was a lot of people agreeing with Ted in 
Montréal and so far, Ted appears to be standing all by himself.

Where are all the other folks that shot down this idea earlier? :)

Thanks,
Tom


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 no ubiquitous 
bypass occurring. i urge you to consider my level of commitment to this 
state of affairs, and whether i'm alone, and what could happen if it's 
threatened by the DOH WG's work.



   If you disagree with me about this (and I can think of a few reasons
why you might) then you should articulate what is possible with DoH that
isn't already possible with HTTPS.


done.

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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) then you should articulate what is possible with DoH that isn't
already possible with HTTPS.

On Mon, Aug 20, 2018 at 2:11 PM, Paul Vixie  wrote:

>
>
> 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 to MiTM
>> their HTTTPS traffic.   If you don't agree that you have to MiTM their
>> HTTPS traffic to achieve what you want, then I think we are not arguing
>> about the same thing.
>>
>
> it used to be occasionally necessary. with DOH it will be universally
> nec'y. this will add complexity (so, cost and error rate) and increase
> surveillance. the DOH people should be told not to proceed to draft
> standard until their design accommodates the needs of network operators.
>
> --
> P Vixie
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 to MiTM
their HTTTPS traffic.   If you don't agree that you have to MiTM their
HTTPS traffic to achieve what you want, then I think we are not arguing
about the same thing.


it used to be occasionally necessary. with DOH it will be universally 
nec'y. this will add complexity (so, cost and error rate) and increase 
surveillance. the DOH people should be told not to proceed to draft 
standard until their design accommodates the needs of network operators.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 should ask for non-tracking. if they won't ask, or if i say
> no, then the default should be non-functionality.
>

Well, the success of the HTTP Do Not Track header field certainly supports
your argument here...


> the DOH people are trying to ram something down the throats of network
> operators worldwide, and i'm gagging on it. a deep breath won't help.


this has nothing to do with what i use. for me it's about employees, family
> members, and visitors. for turkey and china and others, it's about national
> law. the ietf has not been knowingly and deliberately hostile to local
> network policy before now. this is a sea change. it will not end here, and
> it will escalate.


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 to MiTM their HTTTPS
traffic.   If you don't agree that you have to MiTM their HTTPS traffic to
achieve what you want, then I think we are not arguing about the same thing.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 what rights,
and why?

Paul, take a deep breath.   I'm paying for my network service.


if the plural of anecdote was data, i'd counter by saying, my family and 
my employees and my visitors do not pay for my network service. but that 
way lies madness. your network, your rules. if you're paying for it then 
you should make the rules. i pay for mine; i make my own rules.



some references i've seen go by in this thread indicate that the DoH
team wants its protocol to be unblockable, ...


I think the DoH team is not quite as cohesive as you think it is,
but yes, that is one implication of the use of DoH. If you find it
problematic, then you need to get your end users to proxy all their
HTTPS traffic through your HTTPS proxy. This will be really obvious
to them, so you won't be able to do it without their agreement.


indeed, DoT was designed to solve this problem -- it can't be 
intercepted or blocked without the user become aware of it. but it's 
designed to be blockable by network operators who don't want it to be 
used. that's better engineering, because it rams nothing down any throat.



This is by design. This situation has existed since HTTPS has
existed—it's not something that DoH invented. You've always been able
to use HTTPS to bypass firewalls; this has good uses and bad. Tough
luck—see Figure One. :)


see also my own prior work in this area:

https://github.com/BII-Lab/DNSoverHTTP

the difference there was, it's ad hoc, intended to solve point problems 
for individuals, and it would be very easy to block if it caused new or 
worse problems for the coffee shop or hotel room owner.


DOH is designed to be hard to block and to become ubiquitous. that's a 
problem that no amount of gaslighting will reduce the relevance of.



if there are use cases beyond violating the law and violating network
operator security policy, then they are obviously secondary, but do
tell-- what do you think those might be?


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 behaviour tracking may be my policy. a user who wants to 
avoid that tracking should ask for non-tracking. if they won't ask, or 
if i say no, then the default should be non-functionality.


the DOH people are trying to ram something down the throats of network 
operators worldwide, and i'm gagging on it. a deep breath won't help.



i also block tor endpoints. because, my network, my rules. if it's
going to be my network but mozilla's or cloudflare's rules, then this
conversation is going to travel very differently, because i'll still
be paying for it, but it won't be _my_ network any more. would that
sit well with you? it wouldn't with me.


If you think that Mozilla isn't trustworthy, don't use Firefox. It's
all about trust. It's naive to think that you aren't going to have
to trust someone; thinking about trust models is no longer optional
for network operators.


this has nothing to do with trusting mozilla, although in this case, 
they are giving me reasons to treat them as a hostile opponent.


this has nothing to do with what i use. for me it's about employees, 
family members, and visitors. for turkey and china and others, it's 
about national law. the ietf has not been knowingly and deliberately 
hostile to local network policy before now. this is a sea change. it 
will not end here, and it will escalate.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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
> sending spam wasn't illegal and i had to accept it, i blackholed them and
> said, my network, my rules. who has what rights, and why?


Paul, take a deep breath.   I'm paying for my network service.   My ISP
does not require me to use their DNS resolvers.   U.S. law does not require
me to use their DNS resolvers.   So yes, I am perfectly within my rights to
not use their DNS resolvers, but the reason is not "their network, my
rules."   It is that there's no rule against doing it.


> It is certainly true that in some cases, someone using DoH would be
>>> violating a network operator policy that is enforceable, or would
>>> be violating the law.   But that is by no means the most common
>>> case, and it does you no credit to pretend otherwise.
>>>
>>
> some references i've seen go by in this thread indicate that the DoH team
> wants its protocol to be unblockable, and hopes that RDNS DOH providers
> will co-locate their DOH endpoints with other valuable content, "so that
> network operators will think twice about blocking it."
>

I think the DoH team is not quite as cohesive as you think it is, but yes,
that is one implication of the use of DoH.  If you find it problematic,
then you need to get your end users to proxy all their HTTPS traffic
through your HTTPS proxy.   This will be really obvious to them, so you
won't be able to do it without their agreement.   This is by design.   This
situation has existed since HTTPS has existed—it's not something that DoH
invented.   You've always been able to use HTTPS to bypass firewalls; this
has good uses and bad.   Tough luck—see Figure One.  :)

if there are use cases beyond violating the law and violating network
> operator security policy, then they are obviously secondary, but do tell--
> what do you think those might be?
>

Preventing user behavior tracking seems like a pretty valid use case.


> i also block tor endpoints. because, my network, my rules. if it's going
> to be my network but mozilla's or cloudflare's rules, then this
> conversation is going to travel very differently, because i'll still be
> paying for it, but it won't be _my_ network any more. would that sit well
> with you? it wouldn't with me.


If you think that Mozilla isn't trustworthy, don't use Firefox.   It's all
about trust.   It's naive to think that you aren't going to have to trust
someone; thinking about trust models is no longer optional for network
operators.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 said, my network, my rules. who has what rights, and why?



It is certainly true that in some cases, someone using DoH would be
violating a network operator policy that is enforceable, or would
be violating the law.   But that is by no means the most common
case, and it does you no credit to pretend otherwise.


some references i've seen go by in this thread indicate that the DoH 
team wants its protocol to be unblockable, and hopes that RDNS DOH 
providers will co-locate their DOH endpoints with other valuable 
content, "so that network operators will think twice about blocking it."


if there are use cases beyond violating the law and violating network 
operator security policy, then they are obviously secondary, but do 
tell-- what do you think those might be?


i also block tor endpoints. because, my network, my rules. if it's going 
to be my network but mozilla's or cloudflare's rules, then this 
conversation is going to travel very differently, because i'll still be 
paying for it, but it won't be _my_ network any more. would that sit 
well with you? it wouldn't with me.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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;
>
Yes, although in many cases they are required by law to do it, but I am not
required by law to accept it—I can quite legally bypass this feature if I
want to.


> b) ISPs filter out content on request by the user, e.g. for parental
> control; in the UK, ISPs are actually required by law to provide this
> service to the user, that can then decide whether to activate it or not and
> even what to filter out;
>

Yes, and in that case wouldn't it be nice to be able to know that you're
actually talking to the right resolver?   You can't do that with DHCP.


> c) ISPs filter out threats such as botnets, compromised websites
> distributing malware, etc - this does not entail any freedom of speech
> consideration and contributes to everyone's security.
>

Same question.


> In many European countries network operators are selling b)+c) (see for
> example https://securenet.vodafone.com/ ) and people are actively buying
> the service, so they explicitly want this kind of filtering (and will not
> be able to continue getting it if their browser redirects their DNS queries
> somewhere else); and if you do not want it, you just don't buy it. As for
> a), possibly users do not want it, but it is still mandated by law.
>

Yup, absolutely.   I used to work for Nominum—we made a product that did
this, and a lot of people bought it, and I think they were wise to do so.


> 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 your
> freedom of expression, so I guess it is censoring legitimate websites -
> this is bad, of course, but can you tell me which operator, and which
> websites? It would help my understanding of your use case.
>

No, it's not bad.   It's the service they offer, and it's fine that they
offer it.   I think it's the right default.   It's also fine that I choose
to bypass it.


> Finally, note that *in your country* it may be your right to use DoH to
> tamper with what your network operator is doing, but this may not be true
> in other countries. In fact, deploying any technology that circumvents
> security measures that network operators are required to implement by law
> might be illegal in itself.
>

Yes, and if we come up with a solution that allows both situations to be
securely communicated to the end user device, and allows the end user to
make an informed decision about whether or not to use the service with
these restrictions in place, I'm okay with that, and I think it's
appropriate for the IETF to do it.   What I am arguing is that we should
actually describe how to do that, and not just hack together a solution
without thinking about that.


> In the end, the DNS is a very complex policy subject (see the mess that
> ICANN is) with lots of stakeholders and conflicting views, and IMHO such a
> deep change in its architecture and "ecosystem" would require much more
> caution and a much broader discussion going well beyond the IETF.


I believe that I too have been arguing for caution.   Perhaps we disagree
on what the outcome of that cautious approach would be, but we both seem to
agree that it's worth thinking about carefully.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[manu tman]

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 provide an IP to connect to. DoH server may have
a cert that will validate for a hostname. The endpoint may or may not be
/dns-query . How about alternate ports? It seems a having the URI as part
of the data would be useful ( e.g https://dnsserver.example.net/dns-query ,
https://10.10.10.10:8443/dns-query , https://2001:DB8::1/doh ...)
- the draft as is, assumes that port 853 will be used for DoT, 443 for DoH.
Being able to provide alternate ports could be a plus
- It is not clear to me if the options apply to all nameservers from the
dns recursive nameserver option, or if there needs to be 1 option for each
nameserver. I could for instance have nameserver1 which does DoT + DoH
while nameserver2 does none. In this case, I would get option 147 with
option len of 2 for the first server, followed by option 147 with option
len of 0 for the second one.
- A DHCP option should be able to be set multiple time, so one can
configure TLS_SPKI with multiple values. May be useful for rotations and
such.
```

Manu

On Mon, Aug 20, 2018 at 9:42 AM 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 DoT, it seems to me that a super simple way for the client to
> be able to authenticate the server would be to include the server's IP
> address(es) in the subjectAltName field. This wouldn't require a DHCP
> extension, and nicely supports opportunistic updgrade. I'm afraid I wasn't
> paying attention when RFC 8310 was being prepared so I don't know why it
> excludes iPAddress authentication.
>
> Regarding DoH, the DHCP option ought to include a URI template (there
> isn't a .well-known for DoH). I plan to set up my servers so that
> misdirected attempts to get web pages from the DoH server are redirected
> to the relevant documentation; that's much easier if the DoH endpoint
> isn't at the server root.
>
> 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 lookup? I guess that would
> be too annoying for operators that want their DoH servers to be separate
> from their normal DNS resolvers, so maybe it's a bad idea :-)
>
> Tony.
>
> (PS. DoTH is clearly what happens if someone suggests "DoNT" but we do it
> anyway.)
>
> --
> f.anthony.n.finchhttp://dotat.at/
> fight poverty, oppression, hunger, ignorance, disease, and
> aggression___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

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 would be to include the server's IP
address(es) in the subjectAltName field. This wouldn't require a DHCP
extension, and nicely supports opportunistic updgrade. I'm afraid I wasn't
paying attention when RFC 8310 was being prepared so I don't know why it
excludes iPAddress authentication.

Regarding DoH, the DHCP option ought to include a URI template (there
isn't a .well-known for DoH). I plan to set up my servers so that
misdirected attempts to get web pages from the DoH server are redirected
to the relevant documentation; that's much easier if the DoH endpoint
isn't at the server root.

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 lookup? I guess that would
be too annoying for operators that want their DoH servers to be separate
from their normal DNS resolvers, so maybe it's a bad idea :-)

Tony.

(PS. DoTH is clearly what happens if someone suggests "DoNT" but we do it 
anyway.)

-- 
f.anthony.n.finchhttp://dotat.at/
fight poverty, oppression, hunger, ignorance, disease, and aggression___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vittorio Bertola]

> 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 
> privacy and avoid DNS spoofing that returns forged answers, which I consider 
> to be a security threat, and which I am fairly certain my network operator 
> does.
>  
> It is certainly true that in some cases, someone using DoH would be violating 
> a network operator policy that is enforceable, or would be violating the law. 
>   But that is by no means the most common case, and it does you no credit to 
> pretend otherwise.

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;
b) ISPs filter out content on request by the user, e.g. for parental control; 
in the UK, ISPs are actually required by law to provide this service to the 
user, that can then decide whether to activate it or not and even what to 
filter out;
c) ISPs filter out threats such as botnets, compromised websites distributing 
malware, etc - this does not entail any freedom of speech consideration and 
contributes to everyone's security.

In many European countries network operators are selling b)+c) (see for example 
https://securenet.vodafone.com/ ) and people are actively buying the service, 
so they explicitly want this kind of filtering (and will not be able to 
continue getting it if their browser redirects their DNS queries somewhere 
else); and if you do not want it, you just don't buy it. As for a), possibly 
users do not want it, but it is still mandated by law.
 
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 your freedom of 
expression, so I guess it is censoring legitimate websites - this is bad, of 
course, but can you tell me which operator, and which websites? It would help 
my understanding of your use case.

Finally, note that *in your country* it may be your right to use DoH to tamper 
with what your network operator is doing, but this may not be true in other 
countries. In fact, deploying any technology that circumvents security measures 
that network operators are required to implement by law might be illegal in 
itself.

In the end, the DNS is a very complex policy subject (see the mess that ICANN 
is) with lots of stakeholders and conflicting views, and IMHO such a deep 
change in its architecture and "ecosystem" would require much more caution and 
a much broader discussion going well beyond the IETF.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

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 something that has _no_ legitimate purpose.


None of the hotels, coffeeshops or prepaid SIM cards I buy disallow me
either by corporate policy or by local law to not share my DNS traffic
with them.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 connected has no such right of enforcement.   It would be
*catastrophic* if it did, because I'm the paying customer, and supposedly
this is a country in which freedom of speech is guaranteed.   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 privacy
and avoid DNS spoofing that returns forged answers, which I consider to be
a security threat, and which I am fairly certain my network operator does.

It is certainly true that in some cases, someone using DoH would be
violating a network operator policy that is enforceable, or would be
violating the law.   But that is by no means the most common case, and it
does you no credit to pretend otherwise.

On Mon, Aug 20, 2018 at 11:49 AM, 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 something that has _no_ legitimate purpose.
>
> --
> P Vixie
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

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 read that into what I wrote. I was just saying 
that those two particular use-cases were the same.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 purpose.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

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 
> discussion. It seems to me that the designers of DoH have in their minds a 
> romantic picture of the dissident in some authoritarian country trying to 
> escape censorship and save her own life, so that being able to bypass the 
> local ISP, obviously run by evil government cronies, would be a good thing. 
> 
> However, in most of the world, the reality is that the biggest motivation for 
> people to try bypassing the ISP's resolver is to access illegal Web content 
> that has been filtered out at the DNS level, such as unauthorized gambling 
> websites, illegal pornography, "free" football live streams (which are 
> usually full of malware), etc. - not to mention bots trying to contact their 
> command and control server without incurring into RPZ-based filtering.

These are the same use-case, just viewed with different bias.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vittorio Bertola]

> 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 their minds a 
romantic picture of the dissident in some authoritarian country trying to 
escape censorship and save her own life, so that being able to bypass the local 
ISP, obviously run by evil government cronies, would be a good thing. 

However, in most of the world, the reality is that the biggest motivation for 
people to try bypassing the ISP's resolver is to access illegal Web content 
that has been filtered out at the DNS level, such as unauthorized gambling 
websites, illegal pornography, "free" football live streams (which are usually 
full of malware), etc. - not to mention bots trying to contact their command 
and control server without incurring into RPZ-based filtering.

If I accepted Ted Lemon's point that publishing a proposed standard (like DoH) 
implies active endorsement by the IETF, I would wonder why the IETF is actively 
endorsing a standard that will make this much easier.

> I agree that encrypting from the CMTS to the local resolver isn't that 
> valuable, since (unless I'm missing something) the ISP is the only one 
> that can see that traffic, and they'll be able to log/manipulate the 
> resolver already. So it's unlikely that an ISP would deploy DOH or DOT 
> in the first place, so the idea of a DHCP option to support it isn't 
> necessarily relevant in that environment. That doesn't mean it's not 
> relevant elsewhere.

Well, if I were an ISP, I'd rush to deploy DoH on my consumer resolver so to 
deprive the browser makers of the excuse "we are redirecting by default your 
DNS traffic to us because we encrypt it and your ISP does not". I agree that 
technically speaking there is not a lot of need for this, but DoH (more 
precisely: the upcoming deployment of DoH in the browsers) is mostly a business 
and marketing issue, not a technical one.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

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 on your numerous repetitions that this is your 
perspective. I and others have quite clearly disagreed with that. Please 
don't mistake lack of agreement with lack of clarity. I understand your 
argument, I just don't agree with it.


so that we can figure out what to recommend.   What you are 
saying is "we should recommend this." 


No, I'm definitely NOT saying that. I and others have expressed surprise 
that you feel that the existence of a DHCP option constitutes an 
endorsement. I've been in the business over 20 years, and have never 
heard this line of reasoning, for example.


 What you are proposing to 
recommend has a perfectly valid threat model associated with it.   I'm 
just saying write that up, don't just leave it unstated.   Let's get 
clarity on it and decide that we're okay with it, or not, before we 
write a standard based on it.   I don't think this needs to be a 
heavy-weight process—I'm just objecting to the handwaving.   And to be 
clear, the model that Paul has been advocating actually is not what you 
just said—it's a different, also valid, threat model.   The problem with 
Paul's model is that it assumes a user who is able to reason clearly 
about threat models; I don't think we can do that, and I would object to 
a spec that was based on that threat model.   I think we need to do that 
work, and not leave it to the user.   We've all seen what happens when 
you demand that users be security experts.


I think Paul's threat model and mine have more in common than you 
imagine, but I'll leave that aside. What confuses me is the idea that a 
given option can only be deployed to address one threat model. Clearly, 
for any draft the security section needs to weigh the pros and cons of 
the approach.


What it seems like we do agree on is that there is no additional risk to 
the user who would have been relying on the unencrypted resolver anyway 
to rely on an encrypted one.


While your three security models have distinctions to a person who is 
knowledgeable about such things, the only time they matter to your 
normal, non-security-aware user is when they intentionally configure a 
resolver (DOH/DOT or not). If they do this, they are taken out of the 
realm of DHCP resolver options entirely.


Doug

On Sun, Aug 19, 2018 at 8:28 PM, Doug Barton > wrote:


On 08/19/2018 04:57 PM, manu tman wrote:



On Sun, Aug 19, 2018 at 4:46 PM Ted Lemon mailto:mel...@fugue.com> >> 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 vs dynamic setup. Either you use
dynamic and you will happily accept what you get from DHCP and
possibly upgrade to (HTTP|TL)S or you have set your resolvers
statically and you are already ignoring the nameservers provided
by the DHCP server.
If you do not accept the servers provided by DHCP, there is no
reason you would accept extra attributes for those same
snameservers.
Manu


Yes, those are my thoughts precisely.

I don't see a risk model where a user configures DOH or DOT servers
explicitly, but does not disable DHCP configuration for DNS. Am I
missing something?


___
DNSOP mailing list
DNSOP@ietf.org 
https://www.ietf.org/mailman/listinfo/dnsop





___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 valid threat model associated with it.   I'm just saying write
that up, don't just leave it unstated.   Let's get clarity on it and decide
that we're okay with it, or not, before we write a standard based on it.
 I don't think this needs to be a heavy-weight process—I'm just objecting
to the handwaving.   And to be clear, the model that Paul has been
advocating actually is not what you just said—it's a different, also valid,
threat model.   The problem with Paul's model is that it assumes a user who
is able to reason clearly about threat models; I don't think we can do
that, and I would object to a spec that was based on that threat model.   I
think we need to do that work, and not leave it to the user.   We've all
seen what happens when you demand that users be security experts.

On Sun, Aug 19, 2018 at 8:28 PM, Doug Barton  wrote:

> On 08/19/2018 04:57 PM, manu tman wrote:
>
>>
>>
>> On Sun, Aug 19, 2018 at 4:46 PM Ted Lemon > mel...@fugue.com>> 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 vs dynamic setup. Either you use dynamic and
>> you will happily accept what you get from DHCP and possibly upgrade to
>> (HTTP|TL)S or you have set your resolvers statically and you are already
>> ignoring the nameservers provided by the DHCP server.
>> If you do not accept the servers provided by DHCP, there is no reason you
>> would accept extra attributes for those same snameservers.
>> Manu
>>
>
> Yes, those are my thoughts precisely.
>
> I don't see a risk model where a user configures DOH or DOT servers
> explicitly, but does not disable DHCP configuration for DNS. Am I missing
> something?
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

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 configuration you entered manually, you are a lot
worse off. 




This seems to be a static vs dynamic setup. Either you use dynamic and 
you will happily accept what you get from DHCP and possibly upgrade to 
(HTTP|TL)S or you have set your resolvers statically and you are already 
ignoring the nameservers provided by the DHCP server.
If you do not accept the servers provided by DHCP, there is no reason 
you would accept extra attributes for those same snameservers.

Manu


Yes, those are my thoughts precisely.

I don't see a risk model where a user configures DOH or DOT servers 
explicitly, but does not disable DHCP configuration for DNS. Am I 
missing something?


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 otherwise"
>
> "if there's a tcp/853 trust path available, and it works, prefer it"
>
> "if my preferred servers can't be reached i do/don't want to follow dhcp"
>
> "if dhcp doesn't give me working servers, try these global ones instead"
>
> the lack of these knobs today should not inform our debate as to whether
> to add dhcp elements to support tcp/853. rather, they are a separate
> problem -- just as dhcp authentication is a separate problem.
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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 do/don't want to follow dhcp"

"if dhcp doesn't give me working servers, try these global ones instead"

the lack of these knobs today should not inform our debate as to whether 
to add dhcp elements to support tcp/853. rather, they are a separate 
problem -- just as dhcp authentication is a separate problem.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[manu tman]

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 vs dynamic setup. Either you use dynamic and you
will happily accept what you get from DHCP and possibly upgrade to
(HTTP|TL)S or you have set your resolvers statically and you are already
ignoring the nameservers provided by the DHCP server.
If you do not accept the servers provided by DHCP, there is no reason you
would accept extra attributes for those same snameservers.
Manu

> So you have to specify how you’re going to handle this. I’m not saying
> don’t do it. I’m saying figure out how to specify it so that either that is
> the only use case, or the other is the only use case, or the implementor
> knows how to make the right thing happen for both cases. Don’t just pretend
> there’s no conflict.
>
> On Sun, Aug 19, 2018 at 6:07 PM Doug Barton  wrote:
>
>> 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 off than one who relies on the DHCP server's
>> ordinary resolving name server instruction?
>>
>> Also, we're not talking about introducing a new service here, we're
>> talking about a configuration detail for a service that not only already
>> exists, but is critical to get any real work done once you're on the
>> network.
>>
>> Doug
>>
>> On 08/19/2018 12:28 PM, Ted Lemon wrote:
>> > 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 statement, and hence the
>> > protocol would be implicitly applicable in all cases.   When you are
>> > designing a protocol with very serious and significant trust
>> > implications, this is a really bad idea.
>> >
>> > Think about DHCP providing an SMTP server address.   Does that make
>> > sense?   What is the trust model?   The IETF does indeed recommend this
>> > for IPv4, but we didn't do it for IPv6 because we'd realized by the
>> time
>> > we did RFC 3315 that not every single thing you can in principle
>> > configure with DHCP should be configured with DHCP.
>> >
>> >
>> > On Sun, Aug 19, 2018 at 2:48 PM, > > > wrote:
>> >
>> > > 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 the IETF should *recommend*
>> > this way of configuring DoH and DoT - they're saying the DHCP option
>> > should be *available*.
>> >
>> > Are you saying that all DHCP options introduced so far have been the
>> > IETF recommended way of configuring things?
>> >
>> > Are you saying that no new DHCP option can be made available unless
>> > the IETF recommends this way of configuring things?
>> >
>> > Both of these sound equally unreasonable/unlikely to me...
>> >
>> > Steinar Haug, AS2116
>> >
>> >
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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’m saying figure out how to specify it so that either that is the only
use case, or the other is the only use case, or the implementor knows how
to make the right thing happen for both cases. Don’t just pretend there’s
no conflict.

On Sun, Aug 19, 2018 at 6:07 PM Doug Barton  wrote:

> 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 off than one who relies on the DHCP server's
> ordinary resolving name server instruction?
>
> Also, we're not talking about introducing a new service here, we're
> talking about a configuration detail for a service that not only already
> exists, but is critical to get any real work done once you're on the
> network.
>
> Doug
>
> On 08/19/2018 12:28 PM, Ted Lemon wrote:
> > 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 statement, and hence the
> > protocol would be implicitly applicable in all cases.   When you are
> > designing a protocol with very serious and significant trust
> > implications, this is a really bad idea.
> >
> > Think about DHCP providing an SMTP server address.   Does that make
> > sense?   What is the trust model?   The IETF does indeed recommend this
> > for IPv4, but we didn't do it for IPv6 because we'd realized by the time
> > we did RFC 3315 that not every single thing you can in principle
> > configure with DHCP should be configured with DHCP.
> >
> >
> > On Sun, Aug 19, 2018 at 2:48 PM,  > > wrote:
> >
> > > 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 the IETF should *recommend*
> > this way of configuring DoH and DoT - they're saying the DHCP option
> > should be *available*.
> >
> > Are you saying that all DHCP options introduced so far have been the
> > IETF recommended way of configuring things?
> >
> > Are you saying that no new DHCP option can be made available unless
> > the IETF recommends this way of configuring things?
> >
> > Both of these sound equally unreasonable/unlikely to me...
> >
> > Steinar Haug, AS2116
> >
> >
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Doug Barton]

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 off than one who relies on the DHCP server's 
ordinary resolving name server instruction?


Also, we're not talking about introducing a new service here, we're 
talking about a configuration detail for a service that not only already 
exists, but is critical to get any real work done once you're on the 
network.


Doug

On 08/19/2018 12:28 PM, Ted Lemon wrote:
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 statement, and hence the 
protocol would be implicitly applicable in all cases.   When you are 
designing a protocol with very serious and significant trust 
implications, this is a really bad idea.


Think about DHCP providing an SMTP server address.   Does that make 
sense?   What is the trust model?   The IETF does indeed recommend this 
for IPv4, but we didn't do it for IPv6 because we'd realized by the time 
we did RFC 3315 that not every single thing you can in principle 
configure with DHCP should be configured with DHCP.



On Sun, Aug 19, 2018 at 2:48 PM, > wrote:


> 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 the IETF should *recommend*
this way of configuring DoH and DoT - they're saying the DHCP option
should be *available*.

Are you saying that all DHCP options introduced so far have been the
IETF recommended way of configuring things?

Are you saying that no new DHCP option can be made available unless
the IETF recommends this way of configuring things?

Both of these sound equally unreasonable/unlikely to me...

Steinar Haug, AS2116




___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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
> 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 house or wireless hotspot. I think that it
> would be an improvement of privacy to not allow anyone there to sniff
> DNS packets because the owner of the network uses DOH for their
> recursive resolver. I'm already trusting the network for default gateway
> and most users would trust the DNS servers handed via DHCP. So no huge
> new leap of trust and improved privacy. Seems like a win.
>
> Why not allow network operators that option via a new DHCP option? You
> don't have to use it but it would be a good choice for some.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Ebersman]

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 house or wireless hotspot. I think that it
would be an improvement of privacy to not allow anyone there to sniff
DNS packets because the owner of the network uses DOH for their
recursive resolver. I'm already trusting the network for default gateway
and most users would trust the DNS servers handed via DHCP. So no huge
new leap of trust and improved privacy. Seems like a win.

Why not allow network operators that option via a new DHCP option? You
don't have to use it but it would be a good choice for some.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 GFWoC; if you are not, and you never go to China, your device should
not trust it.  If you aren't Chinese but you travel to China, you should
probably be asked to make a policy decision.   And now when the network
operator hands you a DoH or DoT server, you should be able to validate what
you've been handed.   Am I willing to trust Paul Vixie's network?   Then I
can configure that, and then when I am on Paul's network and his network
hands me a pointer to his DoH server, I'll use that.   When I'm not on his
network, I won't.   Right?

On Sun, Aug 19, 2018 at 2:46 PM, Marek Vavruša 
wrote:

> 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 the list of resolvers that she considers
> trusted, and the client would crosscheck that list to its provisioned
> configuration (or list downloaded from a public service such as this
> etc.). This is conceptually similar to NPN/ALPN.
>
> Marek
>
> On Sun, Aug 19, 2018 at 11:35 AM, Tom Pusateri  wrote:
> >
> >
> > On 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"
> >  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 implementation, and the latter case is likely where most of
> the
> > concerns lie. Thus, the issue is likely less DoH itself but rather how
> it is
> > likely to be deployed.
> >
> > I am considering starting work on a draft along the lines of 'potential
> > impacts of DoH deployment' to try to document some of this, if for
> nothing
> > else than to organize my own thinking on the matter. This is because I
> also
> > share concern, given the apparent deployment model, around what may
> break in
> > enterprise networks, malware detection & remediation, walled garden
> portals
> > during service provisioning, parental controls, and the impacts of
> > eliminating other local policies. The CDN-to-CDN competition case is an
> > interesting one as well, with respect to passing EDNS client subnet or
> not.
> >
> > JL
> >
> >
> > In the DRIU BOF, I mentioned establishing a reputation service for public
> > DNS resolvers. With a JSON interface, this could lead to users conveying
> > some trust of a public service or more likely, the inverse of trust for
> > operating systems or stub resolvers to whitelist/blacklist public DNS
> > resolvers.
> >
> > I tried to summarize it here:
> >
> > https://dnsdisco.com/reputation-post.html
> >
> > Or you could go listen to the proceedings of the DRIU BOF.
> >
> > Thanks,
> > Tom
> >
> >
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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 statement, and hence the protocol
would be implicitly applicable in all cases.   When you are designing a
protocol with very serious and significant trust implications, this is a
really bad idea.

Think about DHCP providing an SMTP server address.   Does that make sense?
 What is the trust model?   The IETF does indeed recommend this for IPv4,
but we didn't do it for IPv6 because we'd realized by the time we did RFC
3315 that not every single thing you can in principle configure with DHCP
should be configured with DHCP.


On Sun, Aug 19, 2018 at 2:48 PM,  wrote:

> > 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 the IETF should *recommend*
> this way of configuring DoH and DoT - they're saying the DHCP option
> should be *available*.
>
> Are you saying that all DHCP options introduced so far have been the
> IETF recommended way of configuring things?
>
> Are you saying that no new DHCP option can be made available unless
> the IETF recommends this way of configuring things?
>
> Both of these sound equally unreasonable/unlikely to me...
>
> Steinar Haug, AS2116
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[sthaug]

> 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 the IETF should *recommend*
this way of configuring DoH and DoT - they're saying the DHCP option
should be *available*.

Are you saying that all DHCP options introduced so far have been the
IETF recommended way of configuring things?

Are you saying that no new DHCP option can be made available unless
the IETF recommends this way of configuring things?

Both of these sound equally unreasonable/unlikely to me...

Steinar Haug, AS2116

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop