Subject: [Driu] How to describe various flavors of DNS resolvers

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 May 2018 22:30:34 +0000

Greetings. This mailing list has many purposes, but a (hopefully easy) one is: how should DNS-over-TLS be described in protocols like DHCP? Should there be a separate DHCP option for naming DNS-over-TLS servers to the DHCP client? If not, how should clients upgrade from DNS-over-53 to DNS-over-TLS?

And: who wants to write the Internet Draft for this?

--Paul Hoffman

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 12 May 2018 19:19:34 -0400

> On May 12, 2018, at 6:30 PM, Paul Hoffman <[email-masked]> wrote:
> 

This is something Willem and I have been working on:

https://github.com/pusateri/draft-tpwt-dhc-dns-discovery/blob/master/draft-tpwt-dhc-dns-discovery.txt <https://github.com/pusateri/draft-tpwt-dhc-dns-discovery/blob/master/draft-tpwt-dhc-dns-discovery.txt>

But Ted Lemon is concerned that learning about private DNS over DHCP is not much benefit because you can’t trust the DNS server you learn about.

We have been discussing this is more detail and so I wrote this threat document to try and work through it:

https://github.com/pusateri/draft-tpwt-dhc-dns-discovery/blob/master/threat.md <https://github.com/pusateri/draft-tpwt-dhc-dns-discovery/blob/master/threat.md>

This is still a work in progress and talks are ongoing.

1. In the presence of DNSSEC, the responses can be shown to be trustworthy. In the absence of DNSSEC, there are still some benefits in my opinion.

2. I think there may be a benefit for operating system vendors  and/or dhclient vendors to have a black list / white list.
    Something similar is done today with browser vendors / operating system vendors with https://hstspreload.org <https://hstspreload.org/>

3. Any DNS server providing DNS over TLS or DNS over HTTPS should have DNSSEC records to show they are authentic servers and TLSA records to ensure the client is talking to the actual server. Other out of band mechanisms such as SPKI pinning could be used but distributing this over DHCP is worthless because having the network provider include the information needed to check the network provider is not helpful. But even DNSSEC records for the server do not guarantee the responses that don’t have DNSSEC validation are not tampered with. SIG(0) can help. See the threat document.

4. If a well known DNS over TLS server like 1.1.1.1 or 9.9.9.9 is blocked, then the DHCP client is probably in a hostile environment. If it can’t verify through DNSSEC, the records it learns, it probably should disconnect. But how do we know we can trust 1.1.1.1 or 9.9.9.9?

I welcome more discussion and feedback.

Thanks,
Tom

---

From: Philip Homburg <[email-masked]>
Date: Mon, 14 May 2018 11:59:53 +0200

>    [2]https://github.com/pusateri/draft-tpwt-dhc-dns-discovery/blob/maste
>    r/draft-tpwt-dhc-dns-discovery.txt

For IPv6 it is unfortunately also necessary to consider router advertisements.
It might be worth trying to align the DHCPv6 options and any RA options 
such that they use as much as possible the same conceptual model.

>    But Ted Lemon is concerned that learning about private DNS over
>    DHCP is not much benefit because you cant trust the DNS server
>    you learn about.

>    3. Any DNS server providing DNS over TLS or DNS over HTTPS should
>    have DNSSEC records to show they are authentic servers and TLSA
>    records to ensure the client is talking to the actual server.

I wonder if, even just as strawman, we should document how to signal DNS over
TLS and DNS over HTTPS just using DNS, i.e.
- DANE in the reverse zone can signal TLS or HTTPS
- the PTR can be used as ADN
- SRV records can be used to specify ports as well as ADNs and also signal
  DNS over TLS or HTTPS.

The advantage is that no new wire representations have to be introduced. 
The disavantage it that it only works if the operator of the resolver has
control over reverse DNS.

Note that for IPv6, it may take a long time before router vendors support
the required changes to router advertisements and some client device vendors
seem to have strong objections against the use of DHCPv6.

---

From: Erik Kline <[email-masked]>
Date: Tue, 15 May 2018 13:46:11 +0900

> Greetings. This mailing list has many purposes, but a (hopefully easy)
one is: how should DNS-over-TLS be described in protocols like DHCP? Should
there be a separate DHCP option for naming DNS-over-TLS servers to the DHCP
client? If not, how should clients upgrade from DNS-over-53 to DNS-over-TLS?

I'm not sure I understand the benefit of trying to provide this extra
information.  I think clients will need to probe nameservers for their
capabilities.

Do we think TLS-only nameservers are a likely operational model?

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 May 2018 14:51:32 +0000

> Do we think TLS-only nameservers are a likely operational model?

"Probe for DNS-over-TLS" is a possible outcome, but yes, there are parties who *only* want to provide privacy-enhanced resolvers. In the DOH WG, there has also been discussion of how to prevent downgrade attacks from privacy-enhanded to clear-on-port-53.

--Paul Hoffman

---

From: Mateusz Jończyk <[email-masked]>
Date: Tue, 15 May 2018 18:07:04 +0200

W dniu 15.05.2018 o 16:51, Paul Hoffman pisze:
> "Probe for DNS-over-TLS" is a possible outcome, but yes, there are parties who *only* want to provide privacy-enhanced resolvers. In the DOH WG, there has also been discussion of how to prevent downgrade attacks from privacy-enhanded to clear-on-port-53>
> --Paul Hoffman
IMHuO, preventing downgrade attacks will not work because there are likely going
to be environments that will block DNS-over-TLS and common DOH servers (China
comes to mind). Browsers will have to keep working for these people.

Greetings,
Mateusz

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 15 May 2018 12:20:11 -0400

> On May 14, 2018, at 5:59 AM, Philip Homburg <[email-masked]> wrote:
> 

Yes, this makes sense. We will also consider IPv4 if/when there is general agreement about IPv6.

> control over reverse DNS.

I think this is always a possibility (even now) but it causes delays so it would be better to explicitly advertise the service offering.

It’s also possible to have an SRV record advertising the service that can be verified and the server authenticated.

> seem to have strong objections against the use of DHCPv6.

Yes, definitely.

This is an attempt at determining what the community wants and hashing out the details. The difference between using RA or DHCPv6 mechanisms is mostly the same from the trust / threat on DNS perspective since the network operator controls both.

Thanks for the comments,
Tom

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 15 May 2018 12:32:07 -0400

> On May 15, 2018, at 12:46 AM, Erik Kline <[email-masked]> wrote:
> 

If by ‘probe’ you mean try something and if it works, use it, then I agree this is going to happen and will change dynamically as trust relationships develop.

But as the delays of probing accumulate, it makes sense to provide a mechanism to advertise a more advanced service offering directly. DHCP is one way to do this. SRV/TLSA records are another. Manual configuration is a third way. This won’t apply in all environments.

> Do we think TLS-only nameservers are a likely operational model?

Under some environments, yes.

There will be circumstances where if a client can’t connect to a well known and pre-trusted DNS server, it will drop its lease and disconnect from the network because it sees this as a form of attack.

There will be other environments where the only DNS available is provided by the enterprise network and the clients are happy about this (clients and servers have the same owners).

Tom

---

From: Philip Homburg <[email-masked]>
Date: Tue, 15 May 2018 19:33:26 +0200

>comes to mind). Browsers will have to keep working for these people.

Does that mean that browsers are also going to downgrade https to http if
https is blocked?

When I made a mistake with a Strict-Transport-Security header, there was
really no way I could convince firefox to let me do http.

In any case, I would prefer my browser to complain about downgrade attacks
and possibly offer an option to allow it. Not just silently switch to an
insecure protocol.

Related to this issue: a lot of people configure resolvers like 8.8.8.8
manually. It would be nice if we can avoid input fields for TLS, HTTPS, 
port, sni, certificate, etc. Way better if that kind of stuff is auto
discovered.