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] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

[Tony Finch]

Paul Wouters  wrote:
> On Tue, 21 Aug 2018, Ólafur Guðmundsson wrote:
>
> > Ted, Would it be acceptable to just do 
> > s/TCP/Connection oriented Transport/ 
>
> For RFC 7901 we used "source-IP-verified transport"

I don't think that's a good idea, because it suggests oversised responses
over UDP with cookies. I wanted minimal-any in order to reduce both UDP
fragmentation and fallback to TCP for all UDP queries from legitimate
clients. (Spoofed queries are dealt with by RRL.)

I suggest:

4.4.  Behaviour over different DNS transports

   A DNS responder MAY behave differently when processing ANY queries
   received over different DNS transports or with different levels
   of client authentication, e.g. by providing a conventional
   ANY response over TCP whilst using one of the other mechanisms
   specified in this document in the case where a query was received
   using UDP.

   Implementers SHOULD provide configuration options to allow operators
   to specify different behaviour over different DNS transports or for
   authenticated clients.

(the TCP/UDP e.g. is just a non-normative example; more outre transports
and options are covered by the normative text)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Bailey: Northwest 5 or 6, backing west 5 to 7. Moderate or rough. Showers.
Good.___
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] I-D Action: draft-ietf-dnsop-attrleaf-13.txt

[Dave Crocker]

On 8/21/2018 11:15 AM, John Levine wrote:

It looks fine except that section 6.1 on wildcards vs. underscores is
gone.  Was that deliberate?  I don't recall anyone complainging about
it.



Moved to Section 1.4.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-fix-04.txt

[Dave Crocker]

On 8/21/2018 11:10 AM, Bob Harold wrote:

Minor typo:
"Specifiction" -> "Specification"


that might have been a freudian slip.  that, and the spelling corrector 
must not have looked into xml attributes.  sigh.


thanks!

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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] I-D Action: draft-ietf-dnsop-attrleaf-13.txt

[John Levine]

In article <153487442185.9578.1065167157914269...@ietfa.amsl.com> you write:
>Title   : DNS Scoped Data Through "Underscore" Naming of 
> Attribute Leaves
>Author  : Dave Crocker
>   Filename: draft-ietf-dnsop-attrleaf-13.txt

It looks fine except that section 6.1 on wildcards vs. underscores is
gone.  Was that deliberate?  I don't recall anyone complainging about
it.

R's,
John

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-13.txt

[Bob Harold]

On Tue, Aug 21, 2018 at 2:01 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of the
> IETF.
>
> Title   : DNS Scoped Data Through "Underscore" Naming of
> Attribute Leaves
> Author  : Dave Crocker
> Filename: draft-ietf-dnsop-attrleaf-13.txt
> Pages   : 12
> Date: 2018-08-21
>
> Abstract:
>Formally, any DNS resource record may occur under any domain name.
>However some services have defined an operational convention, which
>applies to DNS leaf nodes that are under a DNS branch having one or
>more reserved node names, each beginning with an _underscore.  The
>underscored naming construct defines a semantic scope for DNS record
>types that are associated with the parent domain, above the
>underscored branch.  This specification explores the nature of this
>DNS usage and defines the "DNS Global Underscore Scoped Entry
>Registry" with IANA.  The purpose of the Underscore registry is to
>avoid collisions resulting from the use of the same underscore-based
>name, for different services.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-13
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-13


Minor typo in 4.2

"as lower-case, to simply name comparisons."
simply -> simplify

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-fix-04.txt

[Bob Harold]

On Tue, Aug 21, 2018 at 2:02 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of the
> IETF.
>
> Title   : DNS Attrleaf Changes: Fixing Specifications with
> Underscored Node Name Use
> Author  : Dave Crocker
> Filename: draft-ietf-dnsop-attrleaf-fix-04.txt
> Pages   : 14
> Date: 2018-08-21
>
> Abstract:
>Original uses of an underscore character as a domain node name
>prefix, which creates a space for constrained interpretation of
>resource records, were specified without the benefit of an IANA
>registry.  This produced an entirely uncoordinated set of name-
>creation activities, all drawing from the same namespace.  A registry
>now has been defined.  However the existing specifications that use
>underscore naming need to be modified, to be in line with the new
>registry.  This document specifies those changes.  The changes
>preserve existing software and operational practice, while adapting
>the specifications for those practices to the newer underscore
>registry model.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-fix-04
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-fix-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-fix-04
>
>
Minor typo:
"Specifiction" -> "Specification"

In 3.3 and table of contents.

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

[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-13.txt

[Dave Crocker]

Folks,

Just posted the revised base and fix attrleaf documents.  I tried to 
fold in all of the suggested changes.  I've checked both documents but 
would appreciate a separate audit, to make sure...


d/



A new version of I-D, draft-ietf-dnsop-attrleaf-13.txt
has been successfully submitted by Dave Crocker and posted to the
IETF repository.

Name:   draft-ietf-dnsop-attrleaf
Revision:   13
Title:  DNS Scoped Data Through "Underscore" Naming of Attribute Leaves
Document date:  2018-08-21
Group:  dnsop
Pages:  12
URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-13.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-13
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-13




--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-fix-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : DNS Attrleaf Changes: Fixing Specifications with 
Underscored Node Name Use
Author  : Dave Crocker
Filename: draft-ietf-dnsop-attrleaf-fix-04.txt
Pages   : 14
Date: 2018-08-21

Abstract:
   Original uses of an underscore character as a domain node name
   prefix, which creates a space for constrained interpretation of
   resource records, were specified without the benefit of an IANA
   registry.  This produced an entirely uncoordinated set of name-
   creation activities, all drawing from the same namespace.  A registry
   now has been defined.  However the existing specifications that use
   underscore naming need to be modified, to be in line with the new
   registry.  This document specifies those changes.  The changes
   preserve existing software and operational practice, while adapting
   the specifications for those practices to the newer underscore
   registry model.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-fix-04
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-fix-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-fix-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-13.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : DNS Scoped Data Through "Underscore" Naming of 
Attribute Leaves
Author  : Dave Crocker
Filename: draft-ietf-dnsop-attrleaf-13.txt
Pages   : 12
Date: 2018-08-21

Abstract:
   Formally, any DNS resource record may occur under any domain name.
   However some services have defined an operational convention, which
   applies to DNS leaf nodes that are under a DNS branch having one or
   more reserved node names, each beginning with an _underscore.  The
   underscored naming construct defines a semantic scope for DNS record
   types that are associated with the parent domain, above the
   underscored branch.  This specification explores the nature of this
   DNS usage and defines the "DNS Global Underscore Scoped Entry
   Registry" with IANA.  The purpose of the Underscore registry is to
   avoid collisions resulting from the use of the same underscore-based
   name, for different services.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-13
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

[Bob Harold]

On Tue, Aug 21, 2018 at 1:10 PM Ted Hardie  wrote:

> On Tue, Aug 21, 2018 at 10:03 AM, Paul Wouters  wrote:
>
>> On Tue, 21 Aug 2018, Ólafur Guðmundsson wrote:
>>
>> Ted, Would it be acceptable to just do
>>> s/TCP/Connection oriented Transport/
>>>
>>
>> For RFC 7901 we used "source-IP-verified transport"
>>
>>
> If this is the only characteristic that the working group believes will
> cause variance in ANY responses, then reusing this terminology seems fine..
> I suspect, however, that it is not  the only characteristic that will in
> practice.  I can easily imagine cases where ANY returns full answers when
> the transport is confidential and minimal ones when it is not.
>
> I have absolutely no data to back this intuition, though, so I will
> understand if the working group and authors disagree.
>
> regards,
>
> Ted Hardie
>
>
>> Paul
>
>
As I see it, the data is 'public' in the sense that any other client could
also request "ANY" over a confidential transport and get the same info, so
I don't see why the server would care that the transport is confidential.
It only protects the privacy of the client.
Preventing amplification, or unnecessary traffic in general, is the basic
use case that I see.

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

Re: [DNSOP] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

[Ted Hardie]

On Tue, Aug 21, 2018 at 10:03 AM, Paul Wouters  wrote:

> On Tue, 21 Aug 2018, Ólafur Guðmundsson wrote:
>
> Ted, Would it be acceptable to just do
>> s/TCP/Connection oriented Transport/
>>
>
> For RFC 7901 we used "source-IP-verified transport"
>
>
If this is the only characteristic that the working group believes will
cause variance in ANY responses, then reusing this terminology seems fine.
I suspect, however, that it is not  the only characteristic that will in
practice.  I can easily imagine cases where ANY returns full answers when
the transport is confidential and minimal ones when it is not.

I have absolutely no data to back this intuition, though, so I will
understand if the working group and authors disagree.

regards,

Ted Hardie


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

Re: [DNSOP] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

[Paul Wouters]

On Tue, 21 Aug 2018, Ólafur Guðmundsson wrote:


Ted, Would it be acceptable to just do 
s/TCP/Connection oriented Transport/ 


For RFC 7901 we used "source-IP-verified transport"

Paul

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

Re: [DNSOP] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

[Ólafur Guðmundsson]

Ted,
Would it be acceptable to just do
s/TCP/Connection oriented Transport/

Olafur



On Tue, Aug 21, 2018 at 12:48 PM, Ted Hardie  wrote:

> Howdy,
>
> I note that section 4.4 calls out TCP transport and says this:
>
> 4.4.  Behaviour with TCP Transport
>
>A DNS responder MAY behave differently when processing ANY queries
>received over different transport, e.g. by providing a conventional
>ANY response over TCP whilst using one of the other mechanisms
>specified in this document in the case where a query was received
>using UDP.
>
>Implementers SHOULD provide configuration options to allow operators
>to specify different behaviour over UDP and TCP.
>
> Given that we now have multiple available transports for the DNS (TLS,
> DTLS, HTTPS), it may be worth generalizing the heading and updating the
> text to handle those cases.  I suspect that involves a bit more work than
> just adding the transport names to the paragraph, unfortunately.  All of
> the newer transports provide return routability, which means, as for TCP,
> that ANY doesn't create DNS amplification for them.  But they also have
> other characteristics (e.g. channel confidentiality and/or additional
> caching layers) that may make for other decision points.  Some text on that
> would be useful, at least in my opinion.
>
> regards,
>
> Ted Hardie
>
> On Tue, Aug 21, 2018 at 8:59 AM, The IESG  wrote:
>
>>
>> The IESG has received a request from the Domain Name System Operations WG
>> (dnsop) to consider the following document: - 'Providing Minimal-Sized
>> Responses to DNS Queries that have QTYPE=ANY'
>>as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final
>> comments on this action. Please send substantive comments to the
>> i...@ietf.org mailing lists by 2018-09-04. Exceptionally, comments may be
>> sent to i...@ietf.org instead. In either case, please retain the
>> beginning of
>> the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>>The operator of an authoritative DNS server might choose not to
>>respond to such queries for reasons of local policy, motivated by
>>security, performance or other reasons.
>>
>>The DNS specification does not include specific guidance for the
>>behaviour of DNS servers or clients in this situation.  This document
>>aims to provide such guidance.
>>
>>This document updates RFC 1034 and RFC 1035.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>>
>>
>>
>


-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

[Ted Hardie]

Howdy,

I note that section 4.4 calls out TCP transport and says this:

4.4.  Behaviour with TCP Transport

   A DNS responder MAY behave differently when processing ANY queries
   received over different transport, e.g. by providing a conventional
   ANY response over TCP whilst using one of the other mechanisms
   specified in this document in the case where a query was received
   using UDP.

   Implementers SHOULD provide configuration options to allow operators
   to specify different behaviour over UDP and TCP.

Given that we now have multiple available transports for the DNS (TLS,
DTLS, HTTPS), it may be worth generalizing the heading and updating the
text to handle those cases.  I suspect that involves a bit more work than
just adding the transport names to the paragraph, unfortunately.  All of
the newer transports provide return routability, which means, as for TCP,
that ANY doesn't create DNS amplification for them.  But they also have
other characteristics (e.g. channel confidentiality and/or additional
caching layers) that may make for other decision points.  Some text on that
would be useful, at least in my opinion.

regards,

Ted Hardie

On Tue, Aug 21, 2018 at 8:59 AM, The IESG  wrote:

>
> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document: - 'Providing Minimal-Sized
> Responses to DNS Queries that have QTYPE=ANY'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2018-09-04. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the
> beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>The operator of an authoritative DNS server might choose not to
>respond to such queries for reasons of local policy, motivated by
>security, performance or other reasons.
>
>The DNS specification does not include specific guidance for the
>behaviour of DNS servers or clients in this situation.  This document
>aims to provide such guidance.
>
>This document updates RFC 1034 and RFC 1035.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
___
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

[DNSOP] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

[The IESG]

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Providing Minimal-Sized
Responses to DNS Queries that have QTYPE=ANY'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2018-09-04. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
   The operator of an authoritative DNS server might choose not to
   respond to such queries for reasons of local policy, motivated by
   security, performance or other reasons.

   The DNS specification does not include specific guidance for the
   behaviour of DNS servers or clients in this situation.  This document
   aims to provide such guidance.

   This document updates RFC 1034 and RFC 1035.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ballot/


No IPR declarations have been submitted directly on this I-D.




___
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] Global DNS architecture changes, "the camel", and so on

[Vladimír Čunát]

On 08/20/2018 07:22 PM, Andrew Sullivan wrote:
> • Does TCP need to become the norm (particularly for the above use
> case)?

TCP support is mandatory now, if that's what you mean (or wasn't clear).
https://tools.ietf.org/html/rfc7766#section-5

In particular, for forwarding it actually makes sense to me to prefer a
connected protocol, even if you don't really need any "state" between
the individual queries, but in any case it's each client's freedom to
choose.  (I'd go right for TLS in the forwarding case, if provided.)

--Vladimir

___
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