Subject: [DNSOP] extension of DoH to authoritative servers

From: "[email-masked]" <[email-masked]>
Date: Tue, 12 Feb 2019 15:56:04 +0800

HI ALL,
RFC8484 《DNS Queries over HTTPS》defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Its primary secnario is between stub resolver and recursive resolver.
I am considering extending the DoH protocal to authoritative servers. To build the trust chain, 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.
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.
The sketch diagram is as followed.  Any comments are welcome!

[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Feb 2019 09:34:36 +0100

On Tue, Feb 12, 2019 at 03:56:04PM +0800,
 [email-masked] <[email-masked]> 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).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Feb 2019 09:39:08 +0100

On Tue, Feb 12, 2019 at 03:56:04PM +0800,
 [email-masked] <[email-masked]> 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.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Feb 2019 09:42:50 +0100

On Tue, Feb 12, 2019 at 03:56:04PM +0800,
 [email-masked] <[email-masked]> 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)

---

From: Jeremy Rand <[email-masked]>
Date: Tue, 12 Feb 2019 12:50:14 +0000

> 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: [email-masked]
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 [email-masked] is having technical issues at the
moment.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Feb 2019 09:07:43 -0500 (EST)

On Tue, 12 Feb 2019, [email-masked] 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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Feb 2019 15:51:15 +0100

On Tue, Feb 12, 2019 at 09:07:43AM -0500,
 Paul Wouters <[email-masked]> 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.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Feb 2019 08:32:28 -0800

Stephane Bortzmeyer wrote on 2019-02-12 00:39:
> 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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Feb 2019 12:22:53 -0500 (EST)

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

---

From: Joe Abley <[email-masked]>
Date: Tue, 12 Feb 2019 12:31:35 -0500

On 12 Feb 2019, at 12:22, Paul Wouters <[email-masked]> wrote:

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

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

---

From: David Conrad <[email-masked]>
Date: Tue, 12 Feb 2019 10:14:19 -0800

Paul,

On Feb 12, 2019, at 8:32 AM, Paul Vixie <[email-masked]> 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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Feb 2019 10:34:19 -0800

David Conrad wrote on 2019-02-12 10:14:
> Paul,
> 
> On Feb 12, 2019, at 8:32 AM, Paul Vixie <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> 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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Feb 2019 10:44:01 -0800

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Feb 2019 11:04:58 -0800

Ted Lemon wrote on 2019-02-12 10:44:
> On Feb 12, 2019, at 10:34 AM, Paul Vixie <[email-masked] 
> It’s either one or the other.

actually, there are other choices.

-- 
P Vixie

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Feb 2019 20:41:38 +0100

On Tue, Feb 12, 2019 at 08:32:28AM -0800,
 Paul Vixie <[email-masked]> 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".

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Feb 2019 12:07:42 -0800

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Feb 2019 12:48:14 -0800

Ted Lemon wrote on 2019-02-12 12:07:
> On Feb 12, 2019, at 11:04 AM, Paul Vixie <[email-masked] 
> 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.

> 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

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 12 Feb 2019 21:55:50 +0100

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Feb 2019 13:00:02 -0800

On Feb 12, 2019, at 12:48 PM, Paul Vixie <[email-masked]> wrote:
> 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.

I still feel like we are talking past each other.

What I am saying is that there are a set of different mechanisms, all of which use port 443, in order to avoid being subjected to your control plane.   DoH is in principle one of these.   We do not disagree about this, as far as I can tell.

What I think we differ on is the idea that, in the absence of these “political tacticians” of whom you speak, that this problem would not exist.

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.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Feb 2019 13:48:36 -0800

Ted Lemon wrote on 2019-02-12 13:00:
> ...
> What I am saying is that there are a set of different mechanisms, all of 
> which use port 443, in order to avoid being subjected to your control 
> plane.   DoH is in principle one of these.   We do not disagree about 
> this, as far as I can tell.
> 
> What I think we differ on is the idea that, in the absence of these 
> “political tacticians” of whom you speak, that this problem would not exist.
> 
> 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.

i may have been too brief. however, i reject this false equivalence.

when a new flow or pattern of flows shows up to distant tcp/443 
responders, this is detectable. if what's detected exceeds thresholds, 
or if it is found to coincide with any other behaviour change, then it 
can be investigated, and perhaps made the subject of new policy. no 
security is perfect and we can't demand it. what we have is temporary 
equilibriums that appropriately match investments and known risks.

DoH _specifically_ evades this, by looking as much as possible like 
other traffic to IP addresses shared by a lot of existing traffic. this 
means the only way to maintain the risk:cost balance of pre-DoH is to 
inspect every flow. many network operators can't afford this or can't 
otherwise do it. those who can and do, can be expected to be grumpy 
about it having their risks and costs increased for political reasons. 
those who can't or don't, can be expected to be grumpy about losing more 
of what little control or visibility they had, for political reasons.

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. in the later case, existing 
anomaly detection and post-facto investigations and policy shifts will 
continue to be good enough.

and that's why DoH is special.

(five paragraphs elided.)

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Feb 2019 14:08:45 -0800

On Feb 12, 2019, at 1:48 PM, Paul Vixie <[email-masked]> 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?

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Feb 2019 14:18:39 -0800

Ted Lemon wrote on 2019-02-12 14:08:
> On Feb 12, 2019, at 1:48 PM, Paul Vixie <[email-masked] 
>> other traffic to IP addresses shared by a lot of existing traffic.
> 

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 

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Feb 2019 14:20:18 -0800

On Feb 12, 2019, at 2:18 PM, Paul Vixie <[email-masked]> 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?

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Feb 2019 14:45:54 -0800

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

---

From: David Conrad <[email-masked]>
Date: Tue, 12 Feb 2019 14:58:36 -0800

On Feb 12, 2019, at 2:18 PM, Paul Vixie <[email-masked]> wrote:
>> On Feb 12, 2019, at 1:48 PM, Paul Vixie <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> lack of an IETF-approved standard with planned implementation by a half dozen tech giants,

And that worked so well with NAT.

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Feb 2019 15:03:57 -0800

> 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

---

From: David Conrad <[email-masked]>
Date: Tue, 12 Feb 2019 15:10:36 -0800

On Feb 12, 2019, at 3:03 PM, Paul Vixie <[email-masked]> wrote:
> 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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Feb 2019 15:32:37 -0800

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:

<<Two primary use cases were considered during this protocol's 
development.  These use cases are preventing on-path devices from 
interfering with DNS operations, ...>>

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?

> 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

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 13 Feb 2019 14:03:26 +0800

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.

[email-masked]
 
From: Paul Wouters
Date: 2019-02-12 22:07
To: [email-masked]
CC: dnsop
Subject: Re: [DNSOP] extension of DoH to authoritative servers

 

Paul
 
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 13 Feb 2019 14:08:19 +0800

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

[email-masked]
 
From: Stephane Bortzmeyer
Date: 2019-02-12 16:39
To: [email-masked]
CC: dnsop
Subject: Re: extension of DoH to authoritative servers
On Tue, Feb 12, 2019 at 03:56:04PM +0800,
[email-masked] <[email-masked]> wrote

---

From: Benno Overeinder <[email-masked]>
Date: Wed, 13 Feb 2019 09:44:08 +0100

> difference in security (we have JWS even if we have HTTPS, for

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/

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 13 Feb 2019 13:30:32 +0100 (CET)

> Il 12 febbraio 2019 alle 22.00 Ted Lemon <[email-masked]> ha scritto: 
> 

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
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 13 Feb 2019 14:37:34 +0100

> the content is encrypted.

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Feb 2019 14:42:30 +0100

On Wed, Feb 13, 2019 at 02:08:19PM +0800,
 [email-masked] <[email-masked]> wrote 

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Feb 2019 14:44:08 +0100

On Wed, Feb 13, 2019 at 02:03:26PM +0800,
 [email-masked] <[email-masked]> 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).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Feb 2019 15:19:13 +0100

On Tue, Feb 12, 2019 at 10:14:19AM -0800,
 David Conrad <[email-masked]> 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.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Feb 2019 15:22:56 +0100

On Tue, Feb 12, 2019 at 10:34:19AM -0800,
 Paul Vixie <[email-masked]> 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?
> 

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?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Feb 2019 15:28:51 +0100

On Tue, Feb 12, 2019 at 01:48:36PM -0800,
 Paul Vixie <[email-masked]> 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?)

> 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
<https://blog.powerdns.com/2019/02/07/the-big-dns-privacy-debate-at-fosdem/>,
not really DoH itself.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Feb 2019 15:34:19 +0100

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

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Feb 2019 15:36:31 +0100

On Tue, Feb 12, 2019 at 02:45:54PM -0800,
 Paul Vixie <[email-masked]> 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.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 13 Feb 2019 15:40:53 +0100

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

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

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

---

From: David Conrad <[email-masked]>
Date: Wed, 13 Feb 2019 08:30:11 -0800

> 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…

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

Regards,
-drc

---

From: Brian Dickson <[email-masked]>
Date: Wed, 13 Feb 2019 13:56:29 -0800

I've been thinking a bit about some of the issues raised in the recent DoH
discussion.

What I am wondering about, is what the goals of different parties might be.

I am also wondering whether some available standards (or additions to some
of those standards) might be helpful.

Finding particular middle ground technical solutions to balance the
different goals (hard requirements vs philosophical issues vs real-world
things), is what I think is a productive direction to have discussions.

Some of the issues may need to be examined a bit closer. E.g. distrust is
pretty vague. There are multiple underlying issues, e.g. privacy ("I don't
trust you to know stuff"), or data integrity ("I don't trust you to not
mangle data"), or surveillance ("I trust him more than I trust you, because
he doesn't keep logs longer than X hours").

I think the ability to separate out DNS from non-DNS traffic when the
transport is TLS on some commonly-used TCP port, is another issue.

Similarly, being able to identify end-points by name or by cert, and
possibly having the ability to act on that identification (permit/deny) is
another thing.

Are there other requirements/drivers on these issues, that are implied or
that might need to be considered?

Is there any need/desire to separate the transport from the actual DNS
resolution? Or would that add too much complexity with no obvious benefit?
Would anyone offer transport while allowing use of a third/fourth party DNS
resolver??

The technical things that might be worth looking at, that I can think of,
are:

   - New certificate use types (specific to only DNS, DoH, DoT,
   server/client etc?)
   - SNI
   - DNS server names (standardized or validated, or white-listed)
   - SRV stuff or similar
   - AH without any content encryption (Null cipher), allows channel
   integrity while letting network operator monitor view query/response
   traffic, e.g. for pseudo-RPZ functionality
   - Is there a DANE use case anywhere in here?

Sorry for the noise, if anyone isn't interested in this stuff.

Brian

---

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Feb 2019 17:29:30 -0500

This discussion (and the other DoH ones) would probably be better handled
on the DoH mailing list -- https://www.ietf.org/mailman/listinfo/doh - so
that the DoH people are involved.

The DoH WG charter specifically says: "The working group will coordinate
with the DNSOP and INTAREA working groups
for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics,
respectvely. In particular, DNSOP will be consulted for guidance on the
operational impacts that result from traditional host behaviors (i.e.,
stub-resolver to recursive-resolver interaction) being replaced with the
specified mechanism."

W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 14 Feb 2019 14:36:14 +0800

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. 

[email-masked]
 
Date: 2019-02-13 21:44
CC: dnsop; Paul Wouters

---

From: Paul Wouters <[email-masked]>
Date: Thu, 14 Feb 2019 02:34:10 -0500 (EST)

On Thu, 14 Feb 2019, [email-masked] 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

---

From: Jim Reid <[email-masked]>
Date: Thu, 14 Feb 2019 07:50:15 +0000

On 14 Feb 2019, at 06:36, [email-masked] 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.

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 14 Feb 2019 16:11:20 +0800

No. i might did not explain it clearly.  

Regarding connecting requirement, my proposal is no different from existing DNS except the recursive server 
needs to talk to authoritative server via HTTPS(or TLS) using the TLSA record. 
The TLSA record contains child zone's(or the server hosting that child zone, those details can be discussed in the future)
 public key and is published in the parent zone. 
 I mean, for the authoritive servers, the trust chain can be built using TLSA other then DS. then a recursive server can ensure
the data it receives in each step of resolving comes from an authenticated server and is encrypted.

[email-masked]
 
From: Paul Wouters
Date: 2019-02-14 15:34
To: [email-masked]
CC: Stephane Bortzmeyer; dnsop
Subject: Re: Re: [DNSOP] extension of DoH to authoritative servers

 
 
Paul

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 14 Feb 2019 16:31:35 +0800

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 14 Feb 2019 09:33:11 +0100

On Thu, Feb 14, 2019 at 02:36:14PM +0800,
 [email-masked] <[email-masked]> 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).

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 14 Feb 2019 16:58:38 +0800

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.

[email-masked]
 
Date: 2019-02-14 16:33

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 14 Feb 2019 10:10:20 +0100

On Thu, Feb 14, 2019 at 04:11:20PM +0800,
 [email-masked] <[email-masked]> wrote 

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 14 Feb 2019 10:12:35 +0100

On Thu, Feb 14, 2019 at 04:31:35PM +0800,
 [email-masked] <[email-masked]> 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.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 14 Feb 2019 10:14:00 +0100

On Thu, Feb 14, 2019 at 04:58:38PM +0800,
 [email-masked] <[email-masked]> 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.)

---

From: Jim Reid <[email-masked]>
Date: Thu, 14 Feb 2019 09:49:05 +0000

> On 14 Feb 2019, at 08:58, [email-masked] 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.