Re: [DNSOP] extension of DoH to authoritative servers

[Henderson, Karl]

As we discussed during the interim dprive meeting held last December, we need 
more empirical studies looking at performance as well as attack vectors. I’m 
aware of Sinodun’s efforts in this area but are there others that address 
performance and attack vectors specifically for both DoT and DoH at the 
authoritative?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] extension of DoH to authoritative servers

[Tony Finch]

Bjørn Mork  wrote:
>
> My understanding of the reference to BCP195 from
> https://tools.ietf.org/html/rfc7858#section-3.2
> is that SNI support is required for all DoT implementations.
>
> It's simple to do with haproxy at least:
> https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/
>
> ...which incidentally also can be used to support DoT with *any* DNS
> server as backend.

I'm using nginx as my DoT and DoH front-end proxy
(https://github.com/fanf2/doh101/) and it looks
like I need to add ssl_preread support to get the SNI
https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html

I'm only really interested in logging it to see what the clients think
they are talking to - they are almost all Androids doing opportunistic
DoT.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Bailey: Southwest becoming cyclonic, mainly south 5 to 7, occasionally gale 8.
High becoming rough or very rough. Occasional rain. Moderate or poor.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] extension of DoH to authoritative servers

[Bjørn Mork]

Vladimír Čunát  writes:

> You can still multiplex based on SNI sent by the client.  HTTPS clients
> surely send it commonly.  DoT clients perhaps not so often, but that's
> just an implementation detail (which I was fixing in the past few weeks
> in knot-resolver, incidentally).

My understanding of the reference to BCP195 from
https://tools.ietf.org/html/rfc7858#section-3.2
is that SNI support is required for all DoT implementations.

> I'm not sure how easy SNI-based multiplexing is to configure with
> nowadays software, but I believe I've heard of some such setup with
> nginx.  And I don't have any idea whether SNI encryption would interfere
> with that, but I hope not.  ESNI will be a key part of DNS privacy,
> though mainly for the non-DNS traffic.

It's simple to do with haproxy at least:
https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/

...which incidentally also can be used to support DoT with *any* DNS
server as backend.



Bjørn

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

Re: [DNSOP] extension of DoH to authoritative servers

[Vladimír Čunát]

On 2/14/19 9:05 AM, Stephane Bortzmeyer wrote:
>> Technically you can run DoT on whatever port you like.
>>
>> Example: with knot-resolver it's easy - you just add @443, either on
>> side of server and/or on the side of forwarding over TLS.
> The problem is that you cannot then share this port with HTTPS
> services (the dkg draft on demultiplexing was abandoned, apparently
> because it doesn't work). In a world of scarce IPv4 public addresses,
> this is a serious problem.

You can still multiplex based on SNI sent by the client.  HTTPS clients
surely send it commonly.  DoT clients perhaps not so often, but that's
just an implementation detail (which I was fixing in the past few weeks
in knot-resolver, incidentally).

I'm not sure how easy SNI-based multiplexing is to configure with
nowadays software, but I believe I've heard of some such setup with
nginx.  And I don't have any idea whether SNI encryption would interfere
with that, but I hope not.  ESNI will be a key part of DNS privacy,
though mainly for the non-DNS traffic.


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

Re: [DNSOP] extension of DoH to authoritative servers

[Jim Reid]

> On 14 Feb 2019, at 08:58, zuop...@cnnic.cn wrote:
> 
> the premise is the recursive server should completely trust an Authenticated 
> server

You’ve already made that clear. The problem with that premise is it’s a false 
one. It represents a naive/unrealistic view of how the DNS is used.

Your proposal also needs all the authoritative servers for some zone to be 
under the same administrative/operational control. That’s also a false premise. 
And naive/unrealistic. It’s been explained to you that many organisations, TLDs 
in particular, don’t do that. They arrange service from multiple DNS providers 
to avoid single points of failure, improve redundancy, have extra capacity, 
etc, etc.

> if an DNSSEC_enabled authotative server(no matter it is Alice or Bob) is evil 
> and modifies DNS records, it will succeed because it has private key and can 
> fake anything

That premise is wrong too. Only the master server needs access to the private 
DNSSEC key. That master server isn’t necessarily in the zone's NS RRset and 
handling queries from resolving servers. Besides, if someone gives their 
private key to someone else -- in this case another authoritative DNS server -- 
by definition it isn’t a private key any more.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Thu, Feb 14, 2019 at 04:58:38PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 126 lines which said:

> if an DNSSEC_enabled authotative server(no matter it is Alice or
> Bob) is evil and modifies DNS records, it will succeed because it
> has private key 

It is completely false. (You seem to think that online signing is the
only possibility but this is far from true.)

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Thu, Feb 14, 2019 at 04:31:35PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 74 lines which said:

> > for instance a DoH or DoT server that intentionally or
> > accidentally returns false data. DNSSEC can counter that.
>  
>  I dont understand why.
>  If a server intentionally returns false data , it can fake anything
>  because it owns the private key, DNSSEC does not help either.

So, you seem to not understand DNSSEC very well. I suggest you read
RFC 4033 and following. Summary: DNSSEC is designed so that the server
does not need the private key.

Also, "server" means two VERY different things in the DNS, resolvers
and authoritative. DNSSEC protects also against a lying intermediary
resolver.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Thu, Feb 14, 2019 at 04:11:20PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 102 lines which said:

> No. i might did not explain it clearly.

It was clear but you repeat the same stuff, without taking into
account the remarks (or the existing documents, such as
draft-bortzmeyer-dprive-resolver-to-auth). Both Paul Wouters and David
Conrad explained that the DNS is more complicated than that (think of
forwarders, for instance) and you did not address their remarks.

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

Re: [DNSOP] extension of DoH to authoritative servers

[zuop...@cnnic.cn]

sorry, because of my english level, i misused the word "protect".
i know the difference between channel security and object security.
but in my proposal, the premise is the recursive server should completely trust 
an Authenticated server.
 i think this is simialr in DNSSEC, because if an DNSSEC_enabled authotative 
server(no matter it is Alice or Bob) is evil and modifies DNS records, 
it will succeed because it has private key and can fake anything.



zuop...@cnnic.cn
 
From: Stephane Bortzmeyer
Date: 2019-02-14 16:33
To: zuop...@cnnic.cn
CC: dnsop; Paul Wouters
Subject: Re: [DNSOP] extension of DoH to authoritative servers
On Thu, Feb 14, 2019 at 02:36:14PM +0800,
zuop...@cnnic.cn  wrote 
a message of 86 lines which said:
 
> i think both DNSSEC and DoH(or DoT) can protect DNS data,
 
"Protect" is like "security", a word so vague,  which includes so many
different (and sometimes contradictory) services that it is not very
useful. Writing "both DNSSEC and DoH(or DoT) can protect DNS data"
seems to imply that you did not think enough about the difference
between channel security and object security. This is really the
weakest point in your argumentation. (Yes, djb always make the same
mistake but he is a famous cryptographer so people forget and forgive
about his mistakes.)
 
> the fundmental point it to establish the trust chain and transit
> trust.
 
No. The entire point of DNSSEC is that you do not need to trust the
many servers that are between the validator and the origin.
 
> Regarding the case"secondary name servers mnaged by a different
> organisation", the servers can publish several TLSAs to distingush
> them.
 
I'm afraid you did not understand. Let me explain with concrete
examples. Suppose organisation Alice subcontracts a secondary name
server to organisation Bob (a very common use case).
 
1) What is Bob is evil and modify DNS records?
2) What is Bob is sloppy in security and its servers are cracked and
the attacker modify DNS records?
 
DNSSEC protects against both. DoT and DoH does not protect against
these issues.
 
> This idea is just a sketch model
 
The problem is that there are many sketch models floating around and
few serious proposals (and even less implemented and analyzed
proposals).
 
___
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] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Thu, Feb 14, 2019 at 02:36:14PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 86 lines which said:

> i think both DNSSEC and DoH(or DoT) can protect DNS data,

"Protect" is like "security", a word so vague,  which includes so many
different (and sometimes contradictory) services that it is not very
useful. Writing "both DNSSEC and DoH(or DoT) can protect DNS data"
seems to imply that you did not think enough about the difference
between channel security and object security. This is really the
weakest point in your argumentation. (Yes, djb always make the same
mistake but he is a famous cryptographer so people forget and forgive
about his mistakes.)

> the fundmental point it to establish the trust chain and transit
> trust.

No. The entire point of DNSSEC is that you do not need to trust the
many servers that are between the validator and the origin.

> Regarding the case"secondary name servers mnaged by a different
> organisation", the servers can publish several TLSAs to distingush
> them.

I'm afraid you did not understand. Let me explain with concrete
examples. Suppose organisation Alice subcontracts a secondary name
server to organisation Bob (a very common use case).

1) What is Bob is evil and modify DNS records?
2) What is Bob is sloppy in security and its servers are cracked and
the attacker modify DNS records?

DNSSEC protects against both. DoT and DoH does not protect against
these issues.

> This idea is just a sketch model

The problem is that there are many sketch models floating around and
few serious proposals (and even less implemented and analyzed
proposals).

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

Re: [DNSOP] extension of DoH to authoritative servers

[zuop...@cnnic.cn]

> for instance a DoH or DoT server that intentionally or accidentally returns 
> false data. DNSSEC can counter that. 
 
 I dont understand why.
 If a server intentionally returns false data , it can fake anything because it 
owns the private key, DNSSEC does not help either. 
 
> Indeed. That’s yet another reason why transiting trust is hard.

YES. this proposal also needs support from the root.
 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Wed, Feb 13, 2019 at 10:51:00PM +0100,
 Vladimír Čunát  wrote 
 a message of 118 lines which said:

> Technically you can run DoT on whatever port you like.

> Example: with knot-resolver it's easy - you just add @443, either on
> side of server and/or on the side of forwarding over TLS.

The problem is that you cannot then share this port with HTTPS
services (the dkg draft on demultiplexing was abandoned, apparently
because it doesn't work). In a world of scarce IPv4 public addresses,
this is a serious problem.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Jim Reid]

On 14 Feb 2019, at 06:36, zuop...@cnnic.cn wrote:
> 
> i think both DNSSEC and DoH(or DoT) can protect DNS data

It depends on your definition of “protect”. For some threats/attacks, DoH or 
DoT by themselves can’t protect DNS data - for instance a DoH or DoT server 
that intentionally or accidentally returns false data. DNSSEC can counter that. 
Provided the client can perform validation and the DoH or DoT server returns 
DNSSEC material in its responses. It might not always be wise to make these 
assumptions, especially client-side validation.

> Transiting trust is hard but may be accomplished in the future.

That simply won’t be possible until every DNS client does DNSSEC validation. 
Good luck with that.

> The deployment of DNSSEC also takes a long time and is still in progress.

Indeed. That’s yet another reason why transiting trust is hard.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Paul Wouters]

On Thu, 14 Feb 2019, zuop...@cnnic.cn wrote:


This idea is just a sketch model and provides another option for DNS security 
and privacy. Transiting trust is hard but may be accomplished in the future. T
he deployment of DNSSEC also takes a long time and is still in progress. 


No. It simply will break applications. For example, the libreswan IKE
daemon using DNSSEC will use the system's forwarder and perform full
DNSSEC validation, without having any idea of the chain of forwarders.
It does not need to, because it is using proper DNSSEC validation.

Your proposal of using transport security implies your node can always
talk to any worldwide DNS server. That is not the case in most networks.

Paul

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

Re: [DNSOP] extension of DoH to authoritative servers

[zuop...@cnnic.cn]

i think both DNSSEC and DoH(or DoT) can protect DNS data, the fundmental point 
it to establish the trust chain and transit trust. Regarding the case"secondary 
name servers mnaged by a different organisation", the servers can publish 
several TLSAs to distingush them.

This idea is just a sketch model and provides another option for DNS security 
and privacy. Transiting trust is hard but may be accomplished in the future. 
The deployment of DNSSEC also takes a long time and is still in progress. 



zuop...@cnnic.cn
 
From: Stephane Bortzmeyer
Date: 2019-02-13 21:44
To: zuop...@cnnic.cn
CC: dnsop; Paul Wouters
Subject: Re: [DNSOP] extension of DoH to authoritative servers
On Wed, Feb 13, 2019 at 02:03:26PM +0800,
zuop...@cnnic.cn  wrote 
a message of 103 lines which said:
 
> that's ture. but in my view, if the trust chain is built, we can
> ensure a resolver(or a cache) is always talking to a identified
> server and the channel is always secure, then the content could not
> be tampered.
 
Several emails already mentioned cases where it is not true (relaying
through a forwarder - transitive trust is hard - or secondary name
servers mnaged by a different organisation - a common use case).
 
___
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] extension of DoH to authoritative servers

[Vladimír Čunát]

On 2/13/19 10:45 PM, Henderson, Karl wrote:
>
> Couldn’t DoT also run over port 443 just like DOH -– similar to what’s
> been proposed in this
> draft?: https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/
>
Technically you can run DoT on whatever port you like.  I believe the
port number argument and non-recognizability from https are mainly red
herrings when comparing DoH with DoT.  And there are more, as the two
protocols share almost all properties.

Example: with knot-resolver it's easy - you just add @443, either on
side of server and/or on the side of forwarding over TLS.

--Vladimir

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

Re: [DNSOP] extension of DoH to authoritative servers

[Henderson, Karl]

Couldn’t DoT also run over port 443 just like DOH -– similar to what’s been 
proposed in this draft?: 
https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/

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

Re: [DNSOP] extension of DoH to authoritative servers

[David Conrad]

On Feb 12, 2019, at 10:03 PM, zuop...@cnnic.cn wrote:
> that's ture. but in my view, if the trust chain is built, we can ensure a 
> resolver(or a cache) is always talking to a identified server and the channel 
> is always secure, then the content could not be tampered.

Your model of how the DNS actually works is too simplistic.

Regards,
-drc



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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 03:32:37PM -0800,
 Paul Vixie  wrote 
 a message of 75 lines which said:

> by putting that text in and leaving it in, this becomes a political
> project not a technical one.

Everything we do is political, the Internet itself is a political
project. Thinking that communication is a good thing is political.

> as it happens, nothing stops a web browser or other such client from
> using DoT, and it's possible that the right answer was to say, DoT
> will answer every technical need that this RFC describes, but none
> of its political needs, and we don't want to be in the politics
> business.

DoT will be blocked in many networks, not DoH. That's why we need
both. DoT is technically better, DoH is more realistic in many
environments.

This choice is hardly limited to DNS. It is partly for the same reason
that we have whois and RDAP.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 02:45:54PM -0800,
 Paul Vixie  wrote 
 a message of 21 lines which said:

> i remember a time when the IAB would have said "no" to an internet
> standard which mandated deliberate loss of control by network
> operators.

Giving the many attacks against network neutrality, it seems
reasonable to me to develop techniques that make these attacks less
easy.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 02:18:39PM -0800,
 Paul Vixie  wrote 
 a message of 20 lines which said:

> > Right.   So what’s to stop other malicious traffic from doing the
> > same thing?
> 
> lack of an IETF-approved standard with planned implementation by a
> half dozen tech giants, means that other malicious traffic will not
> be able to hide in the crowd, and can be made subject to policy, and
> complaints.

An IETF standard make things easier for the implementer and increases
the chances of success (that's why we develop standards, after all)
but it is not the only way to "massive deployment including half dozen
tech giants". So, not having DoH would not stop evil name resolution.

> i want DoT to be used instead,

Then petition the many hotspots, hotels, cafes, corporations, etc,
that block everything but 443. It is because of them that we need DoH,
not just DoT.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 01:48:36PM -0800,
 Paul Vixie  wrote 
 a message of 46 lines which said:

> increased for political reasons.

There is nothing wrong with political reasons. Mass surveillance is a
political problem (privacy). DNS lies by ISPs is a political problem
(network neutrality). It is perfectly normal that IETF develops stuff
for political reasons. (Everybody have read RFC 8280?)

> google, ibm, cloudflare, cisco, and other so-called "public dns"
> providers will at some point choose whether to offer DoH from shared
> addresses, making those shared addresses into risks that the rest of
> us have to manage differently; or whether to dedicate DoH to well
> known addresses that can be outright blocked.

It seems to be an issue with DoC
,
not really DoH itself.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 10:34:19AM -0800,
 Paul Vixie  wrote 
 a message of 15 lines which said:

> > How can you be sure folks on your network aren’t already tunneling
> > their evil deeds through HTTPS?
> 
> netflow. such traffic _looks_ abnormal.
> 
> the deliberate design premise of DoH is that it look normal.

If TLS does its job, how can you make the difference between DoH and
EvilNonStandardNameResolutionProtocolRunningOverTLS?

There are some metadata that can help (such as sizes and timing) but
IETF continue to develop tricks like padding to make them as
inefficient as possible.

I would really like to know how you could detect
EvilNonStandardNameResolutionProtocolRunningOverTLS but not DoH?



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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 10:14:19AM -0800,
 David Conrad  wrote 
 a message of 100 lines which said:

> Why don’t you force folks on your network to install a certificate
> that would allow you to inspect TCP/443 outbound traffic?

There are probably many connected things where this is not
possible. But I don't think blocking DNS resolution (through DoT
blocking or DoH bashing) would help: malware learned a long time ago
how to work even in the most hostile (for them) environment, so
connected things will learn to do the same, in the same way that they
use STUN, TURN and other tricks to work around NAT.

So, I don't think Paul Vixie's plan will work: either you connect only
trusted devices to your network, or you block all outbound traffic for
nodes that must stay local (a thermometer or a camera MUST NOT talk to
the outside world at all).

(And, yes, I know, that today's connected devices talk a lot to remote
nodes. But it is evil.)




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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Wed, Feb 13, 2019 at 02:03:26PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 103 lines which said:

> that's ture. but in my view, if the trust chain is built, we can
> ensure a resolver(or a cache) is always talking to a identified
> server and the channel is always secure, then the content could not
> be tampered.

Several emails already mentioned cases where it is not true (relaying
through a forwarder - transitive trust is hard - or secondary name
servers mnaged by a different organisation - a common use case).

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Wed, Feb 13, 2019 at 02:08:19PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 58 lines which said:

> i prefer DoH because it can identify a server we are talking to and the 
> content is encrypted.

To learn about DoT, I suggest you read RFC 7858.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Vladimír Čunát]

On 2/13/19 7:08 AM, zuop...@cnnic.cn wrote:
> i prefer DoH because it can identify a server we are talking to and
> the content is encrypted.

These two points are the same with DoT.  (encryption and SNI)


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

Re: [DNSOP] extension of DoH to authoritative servers

[Vittorio Bertola]

> Il 12 febbraio 2019 alle 22.00 Ted Lemon  ha scritto: 
> 
> What I am trying to point out is that the situation with DoH is a symptom of 
> the problem you are not talking about, not the only instance of it.
> You seem to be asserting that DoH is special among all other misuses of port 
> 443.   But you haven’t explained why it is special.   This is what I was 
> trying to tease out with my initial response to what you said.

Well, DoH has a couple of very special features:

- it affects name resolution, which is the initial step for almost everything 
you do over the Internet;

- apparently, it will be deployed by default to the entire mankind or so.

It is quite different than some smart users or some specific applications using 
HTTPS (or VPNs) to bypass the local network operator and/or the local 
jurisdiction. In technical terms it might not be different, but in business, 
policy and political terms this makes all the difference.

Ciao,
 -- 
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] extension of DoH to authoritative servers

[Benno Overeinder]

On 12/02/2019 09:34, Stephane Bortzmeyer wrote:
> On Tue, Feb 12, 2019 at 03:56:04PM +0800,
>  zuop...@cnnic.cn  wrote 
>  a message of 546 lines which said:
> 
>> DNSSEC is not necessary anymore
> 
> This is clearly false. DoH provides _channel security_ DNSSEC provides
> _content security_ (or object security). This is a very important
> difference in security (we have JWS even if we have HTTPS, for
> instance).

Indeed, you might want to look at one of the presentations by Willem
Toorop and myself.  In respect of channel security, DoH and DoT with
authenticated TLS are similar.

- RIPE 76 DNS WG
  https://ripe76.ripe.net/presentations/56-sunrise-DoT-sunset-DNSSEC.pdf
  https://ripe76.ripe.net/archives/video/67

- ICANN DNS Symposium 2018

https://www.icann.org/en/system/files/files/presentation-sunrise-dns-tls-sunset-dnssec-13jul18-en.pdf

- APNIC/RIPE blog post: Sunrise DNS over TLS, sunset DNSSEC?
  https://blog.apnic.net/2018/08/17/sunrise-dns-over-tls-sunset-dnssec/

https://labs.ripe.net/Members/willem_toorop/sunrise-dns-over-tls-sunset-dnssec

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

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

Re: [DNSOP] extension of DoH to authoritative servers

[zuop...@cnnic.cn]

i prefer DoH because it can identify a server we are talking to and the content 
is encrypted. 



zuop...@cnnic.cn
 
From: Stephane Bortzmeyer
Date: 2019-02-12 16:39
To: zuop...@cnnic.cn
CC: dnsop
Subject: Re: extension of DoH to authoritative servers
On Tue, Feb 12, 2019 at 03:56:04PM +0800,
zuop...@cnnic.cn  wrote 
a message of 546 lines which said:
 
> I am considering extending the DoH protocal to authoritative
> servers.
 
Why DoH and not DoT? DoH is useful because 1) port 853 may be blocked
at the edge of the network 2) applications running in a Web browser
may need DNS data. But these two reasons do not apply to your use case
1) the resolver is often closer to the core and there is less risk
that 853 is blocked 2) there is no Web browser on the resolver.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] extension of DoH to authoritative servers

[zuop...@cnnic.cn]

that's ture. but in my view, if the trust chain is built, we can ensure a 
resolver(or a cache) is always talking to a identified server and the channel 
is always secure, then the content could not be tampered.



zuop...@cnnic.cn
 
From: Paul Wouters
Date: 2019-02-12 22:07
To: zuop...@cnnic.cn
CC: dnsop
Subject: Re: [DNSOP] extension of DoH to authoritative servers
On Tue, 12 Feb 2019, zuop...@cnnic.cn wrote:
 
>In this way, the whole DNS is built on HTTPS which makes DNS more secure. 
> DNSSEC is not necessary anymore and many other
>problems like fragmentation also will 
> not exist.
 
This idea is similar to DNScurve. The problem is that channel security
does not help when you have an infrastructure of DNS caches, as nothing
in the cache can be used to validate the content.
 
djb's solution to this problem was to obsolete the cache, and at the CCC
conference he then threw around numbers that "claimed" caching is not
working or needed, and was proven wrong by me showing some cache
percentages of real DNS servers.
 
DNSSEC provides origin protection, and digital signatures are needed,
which TLS does not offer.
 
Paul
 
___
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] extension of DoH to authoritative servers

[Paul Vixie]

David Conrad wrote on 2019-02-12 15:10:

You missed my point.  The IETF declared NATs heretical and as a
result, a zillion people did it in a zillion different ways, creating
a huge mess.


i remember this. and i agree. had IAB said "this specification is
inadequate, let's get firewall traversal working before we publish",
rather than "it is heretical and must not be done", a lot of pain and
waste would have been avoided.

...  Lots of people are implementing sending/receiving DNS 
queries/responses over HTTPS.


since i did it myself (https://github.com/BII-Lab/DNSoverHTTP) years
before DoH was thought of, i can scarcely disagree.


DoH simply codifies one way of doing it so that network managers,
software developers, etc., have a chance to develop management
systems for it.



really? "simply"? i don't think it's that simple. here's the part of RFC 
8484 that i would have expected to cause a "discuss" event in IESG 
before allowing publication:


>


that's not a simple thing. IESG should have said, "that part is 
problematic, please make this protocol optional for the network 
operators and controllable their on-path devices."


by putting that text in and leaving it in, this becomes a political 
project not a technical one. IESG had the ability to say, please find a 
better way to solve this problem, that disenfranchises nobody.


as it happens, nothing stops a web browser or other such client from 
using DoT, and it's possible that the right answer was to say, DoT will 
answer every technical need that this RFC describes, but none of its 
political needs, and we don't want to be in the politics business.


to validate whether RFC 8484's goal is political, let's ponder whether 
the document would have been perfectly unhurt by the non-enumeration of 
this use case. i think yes. so, why mention it?



i'd like the same level of freedom when it comes to how DNS is
served.


Then force the folks on your network to install a cert so you can
filter out DoH.  Contrary to your assertion, I doubt netflow will let
you discriminate between good and evil. You have to have visibility
to do that.
i have embedded devices which don't let me install certs inside them, 
and i don't think i'm alone. the general name for what you're describing 
is "web application firewall" and it simply breaks anything that won't 
cooperate -- which is the policy i'm going to need, if any so-called 
"public DNS" server shares a DoH responder address with any other 
service i care about. this remains to be seen. the market will help decide.


i'm surprised and fascinated by your vision of what my security needs 
are -- even though you have misstated them here -- but you're wrong on 
the facts, and the economics. if you are willing to spend the serious 
effort it would take to fully engage with the lived experience of modern 
CISO's, then we should take that topic up 1x1.


--
P Vixie

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

Re: [DNSOP] extension of DoH to authoritative servers

[David Conrad]

On Feb 12, 2019, at 3:03 PM, Paul Vixie  wrote:
> David Conrad wrote on 2019-02-12 14:58:
>>> lack of an IETF-approved standard with planned implementation by a half 
>>> dozen tech giants,
>> And that worked so well with NAT.
> network operators had a choice whether to deploy NAT.

You missed my point.  The IETF declared NATs heretical and as a result, a 
zillion people did it in a zillion different ways, creating a huge mess.  Lots 
of people are implementing sending/receiving DNS queries/responses over HTTPS. 
DoH simply codifies one way of doing it so that network managers, software 
developers, etc., have a chance to develop management systems for it.

> i'd like the same level of freedom when it comes to how DNS is served.

Then force the folks on your network to install a cert so you can filter out 
DoH.  Contrary to your assertion, I doubt netflow will let you discriminate 
between good and evil. You have to have visibility to do that.

> too old-school?

Too ostrich-like.

Regards,
-drc



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

Re: [DNSOP] extension of DoH to authoritative servers

[Paul Vixie]

David Conrad wrote on 2019-02-12 14:58:
lack of an IETF-approved standard with planned implementation by a 
half dozen tech giants, 


And that worked so well with NAT.


network operators had a choice whether to deploy NAT. i'd like the same 
level of freedom when it comes to how DNS is served. too old-school?


--
P Vixie

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

Re: [DNSOP] extension of DoH to authoritative servers

[David Conrad]

On Feb 12, 2019, at 2:18 PM, Paul Vixie  wrote:
> Ted Lemon wrote on 2019-02-12 14:08:
>> On Feb 12, 2019, at 1:48 PM, Paul Vixie >  > >> wrote:
>>> DoH _specifically_ evades this, by looking as much as possible like other 
>>> traffic to IP addresses shared by a lot of existing traffic.
>> Right.   So what’s to stop other malicious traffic from doing the same thing?
> lack of an IETF-approved standard with planned implementation by a half dozen 
> tech giants,

And that worked so well with NAT.

Regards,
-drc




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

Re: [DNSOP] extension of DoH to authoritative servers

[Paul Vixie]

Ted Lemon wrote on 2019-02-12 14:20:

...

So you’re saying that DoH traffic that’s not going to well-known IP 
addresses is easier to detect than DoH traffic going to well-known IP 
addresses?


yes, that's what i've been trying to say. if CF only publishes DoH 
content on 1.0.0.0/23, then i can just block that, and leave their main 
HTTPS server addresses alone. same for google, opendns/umbrella/cisco, 
ibm, and the others. one of my networks only allows TCP/443 to 
explicitly enumerated destinations... one of which is the main service 
address for google. i need that to never contain DoH traffic, please.


note, i prefer to block UDP/53, TCP/53, and TCP/853, because then my 
risks are lower, and my costs for managing those risks also lower. and 
that's why DoT is a better _engineered_ solution than DoH. i remember a 
time when the IAB would have said "no" to an internet standard which 
mandated deliberate loss of control by network operators. hey you kids, 
get offa my lawn, and so on.


--
P Vixie

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

Re: [DNSOP] extension of DoH to authoritative servers

[Ted Lemon]

On Feb 12, 2019, at 2:18 PM, Paul Vixie  wrote:
> lack of an IETF-approved standard with planned implementation by a half dozen 
> tech giants, means that other malicious traffic will not be able to hide in 
> the crowd, and can be made subject to policy, and complaints.

So you’re saying that DoH traffic that’s not going to well-known IP addresses 
is easier to detect than DoH traffic going to well-known IP addresses?

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

Re: [DNSOP] extension of DoH to authoritative servers

[Paul Vixie]

Ted Lemon wrote on 2019-02-12 14:08:
On Feb 12, 2019, at 1:48 PM, Paul Vixie > wrote:
DoH _specifically_ evades this, by looking as much as possible like 
other traffic to IP addresses shared by a lot of existing traffic.


Right.   So what’s to stop other malicious traffic from doing the same 
thing?


lack of an IETF-approved standard with planned implementation by a half 
dozen tech giants, means that other malicious traffic will not be able 
to hide in the crowd, and can be made subject to policy, and complaints.


IOW, you seem to want DoH to go away, but will that actually solve your 
problem?   If so, how?


i want DoT to be used instead, and backed by google, mozilla, 
cloudflare, and the others. i want malicious traffic to stand apart from 
the crowd, where affordable anomaly detection can see it and cope with 
it. security economics is a "long game." DoH is a giant step function.


--
P Vixie

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

Re: [DNSOP] extension of DoH to authoritative servers

[Ted Lemon]

On Feb 12, 2019, at 1:48 PM, Paul Vixie  wrote:
> DoH _specifically_ evades this, by looking as much as possible like other 
> traffic to IP addresses shared by a lot of existing traffic. 

Right.   So what’s to stop other malicious traffic from doing the same thing?

IOW, you seem to want DoH to go away, but will that actually solve your 
problem?   If so, how?

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

Re: [DNSOP] extension of DoH to authoritative servers

[Patrik Fältström]

On 12 Feb 2019, at 21:48, Paul Vixie wrote:

> whether the situation turns out to be temporary or not is important to your 
> final argument. probably you shouldn't go there so soon. spammers also 
> believe that network operators should not be able to control their own 
> networks, and malware authors, and botnet creators, and IoT innovators, and 
> surveillance capitalists. none of those matters seem like they are, or will 
> ever be, settled. so, none are "temporary".

The current legal system and court decisions require access providers to have 
some control. Today it is "enough" for the access providers to block DNS lookup 
of certain domain names. We on THIS list understand how easy it is to go around 
that kind of blocking, but that does not matter. It is enough for the legal 
systems in the world.

If the control over the DNS lookups is no longer possible by the access 
provider, then the access providers by law have to use other tools to control 
the traffic from their customers.

So, it is not only their choice.

   Patrik


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

Re: [DNSOP] extension of DoH to authoritative servers

[Paul Vixie]

Ted Lemon wrote on 2019-02-12 12:07:
On Feb 12, 2019, at 11:04 AM, Paul Vixie > wrote:

actually, there are other choices.


I may have failed to communicate.   What I mean is that you said that 
you can detect all nefarious traffic, but you can’t detect DoH, which to 
you is nefarious.   What I’m saying is that there’s no such distinction, 
or at least if there is at present, it is a temporary situation.


i realize that the political tacticians who designed DoH are searching 
for a world in which network operators have no control plane choices. i 
think they're proceeding from the mistaken belief that all control is 
evil, and that all network operators are equally deserving of 
disintermediation. and other mistaken beliefs as well, which i won't 
enumerate.




Of course you have choices about what to do about this; my point is not 
to suggest that you do not.




whether the situation turns out to be temporary or not is important to 
your final argument. probably you shouldn't go there so soon. spammers 
also believe that network operators should not be able to control their 
own networks, and malware authors, and botnet creators, and IoT 
innovators, and surveillance capitalists. none of those matters seem 
like they are, or will ever be, settled. so, none are "temporary".


my network, my rules. anyone who acts otherwise will be treated by me as 
an adversary, even folks like mozilla who have been fellow travelers for 
decades now, if they continue to pursue unblockable endpoint technology.


--
P Vixie

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

Re: [DNSOP] extension of DoH to authoritative servers

[Ted Lemon]

On Feb 12, 2019, at 11:04 AM, Paul Vixie  wrote:
> actually, there are other choices.

I may have failed to communicate.   What I mean is that you said that you can 
detect all nefarious traffic, but you can’t detect DoH, which to you is 
nefarious.   What I’m saying is that there’s no such distinction, or at least 
if there is at present, it is a temporary situation.

Of course you have choices about what to do about this; my point is not to 
suggest that you do not.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 08:32:28AM -0800,
 Paul Vixie  wrote 
 a message of 39 lines which said:

> i require all visitors, family members, employees, and apps to use
> the control plane i have constructed, which includes DNS
> surveillance and control.

Reminds me of a sentence which is awfully true: "applications on the
Internet now have to use the techniques of the botnets, just to work".

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

Re: [DNSOP] extension of DoH to authoritative servers

[Paul Vixie]

Ted Lemon wrote on 2019-02-12 10:44:
On Feb 12, 2019, at 10:34 AM, Paul Vixie > wrote:

netflow. such traffic _looks_ abnormal.

the deliberate design premise of DoH is that it look normal.


It’s either one or the other.


actually, there are other choices.

--
P Vixie

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

Re: [DNSOP] extension of DoH to authoritative servers

[Ted Lemon]

On Feb 12, 2019, at 10:34 AM, Paul Vixie  wrote:
> netflow. such traffic _looks_ abnormal.
> 
> the deliberate design premise of DoH is that it look normal.

It’s either one or the other.   DoH is such traffic.  If it looks abnormal, you 
can do something about it.   If it doesn’t, you can’t.   It’s not the case that 
nefarious traffic that is not DoH is special in looking different.  Or rather, 
to the extent that you are good at identifying and blocking such traffic, that 
will naturally select for solutions that are less easily identified, and 
eventually the steady state will be exactly what you are afraid of with DoH.   
To the extent that DoH is less obvious than these other techniques, you could 
legitimately say that it is an example of this process of natural selection.   
It just happens to be visible to you, whereas all the other examples are not, 
because they are being done by black hats, not by the IETF.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Paul Vixie]

David Conrad wrote on 2019-02-12 10:14:

Paul,

On Feb 12, 2019, at 8:32 AM, Paul Vixie > wrote:
DoH is _dangerous_ because it's my network and i require all visitors, 
family members, employees, and apps to use the control plane i have 
constructed, which includes DNS surveillance and control. 


Why don’t you force folks on your network to install a certificate that 
would allow you to inspect TCP/443 outbound traffic?  How can you be 
sure folks on your network aren’t already tunneling their evil deeds 
through HTTPS?


netflow. such traffic _looks_ abnormal.

the deliberate design premise of DoH is that it look normal.

--
P Vixie

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

Re: [DNSOP] extension of DoH to authoritative servers

[David Conrad]

Paul,

On Feb 12, 2019, at 8:32 AM, Paul Vixie  wrote:
> DoH is _dangerous_ because it's my network and i require all visitors, family 
> members, employees, and apps to use the control plane i have constructed, 
> which includes DNS surveillance and control.

Why don’t you force folks on your network to install a certificate that would 
allow you to inspect TCP/443 outbound traffic?  How can you be sure folks on 
your network aren’t already tunneling their evil deeds through HTTPS?

Thanks,
-drc



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

Re: [DNSOP] extension of DoH to authoritative servers

[Joe Abley]

On 12 Feb 2019, at 12:22, Paul Wouters  wrote:

> On Tue, 12 Feb 2019, Paul Vixie wrote:
> 
>> this is especially vital for IoT, whose makers will never be profitable 
>> other than from data they collect.
> 
> I hope those makes will be unprofitable and close shop.
> 
> IoT devices should be designed to be accessed through secure VPN or TLS
> connections, without going through vulnerable large scale server farms
> in unknown or unpleasant countries invading my human privacy rights.
> 
> For example, I'm using my hue lights with or without VPN, without telling
> Philips when I turn the lights on or off and without telling philips
> when I am near or not near by house.

As an aside, it looks to me like Philips are making Hue viable with a price 
point that makes them invisible to the average consumer. The Internet is awash 
with smart lights with apparently equivalent functionality and a price point 
that is 90% lower. Either Philips have the biggest margin on consumer 
electronics the world has ever seen, or the manufacturers of the cheap 
alternatives are getting paid in ways other than money.

In terms of volume (which is what we care about if we are worried about numbers 
of active devices) Hue is a rounding error.


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

Re: [DNSOP] extension of DoH to authoritative servers

[Paul Wouters]

On Tue, 12 Feb 2019, Paul Vixie wrote:

this is especially vital for IoT, whose makers will 
never be profitable other than from data they collect.


I hope those makes will be unprofitable and close shop.

IoT devices should be designed to be accessed through secure VPN or TLS
connections, without going through vulnerable large scale server farms
in unknown or unpleasant countries invading my human privacy rights.

For example, I'm using my hue lights with or without VPN, without telling
Philips when I turn the lights on or off and without telling philips
when I am near or not near by house.

That said, software circumventing the system's resolver is bad, and is
not the layer this should be happening on, and it should really be a
last ditch effort requiring user exception. But browsers think they are
the DNS police now :(

Paul

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

Re: [DNSOP] extension of DoH to authoritative servers

[Paul Vixie]

Stephane Bortzmeyer wrote on 2019-02-12 00:39:

On Tue, Feb 12, 2019 at 03:56:04PM +0800,
  zuop...@cnnic.cn  wrote
  a message of 546 lines which said:


I am considering extending the DoH protocal to authoritative
servers.


Why DoH and not DoT? ...


well, yes, but...


DoH is useful because 1) port 853 may be blocked
at the edge of the network 


DoH is _dangerous_ because it's my network and i require all visitors, 
family members, employees, and apps to use the control plane i have 
constructed, which includes DNS surveillance and control. thanks to DoH, 
i will have to add a WAF, or require SOCKS, for all outbound TCP/443 to 
the cloudflare, google, and other so-called "public" dns services. i am 
nowhere near ready to allow cloudflare and apnic and the others to build 
their own private DNS relationship with my endpoints, bypassing parental 
controls, bypassing corporate security policy.


DoT should be preferred precisely because it _can_ be blocked by the 
network operator. if someone insists on not talking to my DNS servers, 
they can take their device elsewhere. this is especially vital for IoT, 
whose makers will never be profitable other than from data they collect.



2) applications running in a Web browser
may need DNS data. ...
i expect those apps to make normal UDP/53, TCP/53, or TCP/853 requests 
from the designated DNS servers i operate as part of my control plane. 
any attempt to speak DoH from my networks will be treated as an attack.


--
P Vixie

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 09:07:43AM -0500,
 Paul Wouters  wrote 
 a message of 23 lines which said:

> This idea is similar to DNScurve. The problem is that channel
> security does not help when you have an infrastructure of DNS
> caches,

Or when secondary name servers are not under the same organisation.


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

Re: [DNSOP] extension of DoH to authoritative servers

[Paul Wouters]

On Tue, 12 Feb 2019, zuop...@cnnic.cn wrote:


   In this way, the whole DNS is built on HTTPS which makes DNS more secure. 
DNSSEC is not necessary anymore and many other
   problems like fragmentation also will 
not exist.


This idea is similar to DNScurve. The problem is that channel security
does not help when you have an infrastructure of DNS caches, as nothing
in the cache can be used to validate the content.

djb's solution to this problem was to obsolete the cache, and at the CCC
conference he then threw around numbers that "claimed" caching is not
working or needed, and was proven wrong by me showing some cache
percentages of real DNS servers.

DNSSEC provides origin protection, and digital signatures are needed,
which TLS does not offer.

Paul

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

Re: [DNSOP] extension of DoH to authoritative servers

[Jeremy Rand]

Stephane Bortzmeyer:
> On Tue, Feb 12, 2019 at 03:56:04PM +0800,
>  zuop...@cnnic.cn  wrote 
>  a message of 546 lines which said:
> 
>> I am considering extending the DoH protocal to authoritative
>> servers.
> 
> Why DoH and not DoT? DoH is useful because 1) port 853 may be blocked
> at the edge of the network 2) applications running in a Web browser
> may need DNS data. But these two reasons do not apply to your use case
> 1) the resolver is often closer to the core and there is less risk
> that 853 is blocked 2) there is no Web browser on the resolver.

Hi Stephane,

Both of those assumptions are false when the user has installed a
recursive resolver on their home computer, as is the case when the user
has installed DNSSEC-Trigger.  They're also false when the user has
installed Namecoin, since Namecoin domain names often delegate to DNS
via NS+DS records.

(Of course, it could be argued that Namecoin users need to deal with
network censorship of Namecoin protocol traffic anyway, but I don't see
any reason to make the situation unnecessarily worse by avoiding DoH.)

Cheers,
-- 
-Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.



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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 03:56:04PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 546 lines which said:

> the child zone publishes a TLSA record instead of a DS record in the
> parent zone [RFC 6698 may need update]. The TLSA record contains the
> certificate that identifies the child zone.

The problem is that it would require all authoritative name servers of
a zone to have the same key. This is inconvenient in some setups, for
instance when part of the name servers is subcontracted. I suggest
that it is better to have a TLSA record per name server and not per
zone (draft-bortzmeyer-dprive-resolver-to-auth, section 2)

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 03:56:04PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 546 lines which said:

> I am considering extending the DoH protocal to authoritative
> servers.

Why DoH and not DoT? DoH is useful because 1) port 853 may be blocked
at the edge of the network 2) applications running in a Web browser
may need DNS data. But these two reasons do not apply to your use case
1) the resolver is often closer to the core and there is less risk
that 853 is blocked 2) there is no Web browser on the resolver.

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

Re: [DNSOP] extension of DoH to authoritative servers

[Stephane Bortzmeyer]

On Tue, Feb 12, 2019 at 03:56:04PM +0800,
 zuop...@cnnic.cn  wrote 
 a message of 546 lines which said:

> DNSSEC is not necessary anymore

This is clearly false. DoH provides _channel security_ DNSSEC provides
_content security_ (or object security). This is a very important
difference in security (we have JWS even if we have HTTPS, for
instance).

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