Subject: [dns-privacy] Discovery of DNS over (not 53) and ALPN

From: Ted Hardie <[email-masked]>
Date: Fri, 13 Dec 2019 13:53:18 +0000

So this came up in an another thread, but it probably needs a separate
topic.

The point being made was:

We really need to figure out how to do DoWhatever discovery, preferably
> better than probe ports on the same IP as the port 53 server.
>

I think one critical question is how discovery of DoT and DoH (and later
entrants)  servers is related to the discovery of port 53 servers.  One
possibility here, if we do define ALPN tokens for each of these, is to
combine that token with the base discovery methods.  So, DHCPv4 Option 6
(or DHCPv6 option 23) gives you the IP address of the server, and a new
DNS-ALPN option code gives you the ALPN(s), from which you derive the port.

If the DNS-ALPN option code is absent, go to port 53.  If there is one
present, it is a list, like the ALPN next protocol list, of the tokens
corresponding to the list the server supports.  This implies that you would
need an ALPN token for DoT port 853 to be available and distinct from DoT
port 443.

Router advertisements are a little trickier.  If someone is currently using
RFC 8106 style advertisements, I think it would be cleaner to have those
still present and a new option for DNS-over-not-53 options.  That could
still leverage the ALPN list as a way of making that a single option
(rather than a bunch of separate announcements).

There are clearly operational environments that wouldn't follow this (those
that use the URI template in RFC 8484, for example), but something that
allows you to signal them together does seem useful.

Note that this approach means that if you have a client that supports DNS
over 53 and doesn't understand the ALPN token in the new option, you can
run into a corner case.  If the network does not support DNS over 53, the
client will fail to see the alternatives to port 53.  It would then have to
interpret an ICMP destination unreachable (presuming that gets through).

I'm not an expert on either DHCP or RA, of course, so I may have this wrong
way around.

regards,

Ted

---

From: Erik Nygren <[email-masked]>
Date: Fri, 13 Dec 2019 09:12:09 -0500

Linking ALPN and port defeats the purpose of ALPN.  It would be preferable
to have the discovery mechanism
enumerate an preference-ordered list of tuples of {host/ip(s), port,
proto/alpn, [uri_template]}.
This is similar to what Alt-Svc in HTTP does as well as what SVCB does.
For example:

   { 192.168.1.2, 853, "doq" }
   { 192.168.1.2, 853, "dot" }
   { 192.168.1.3, 443, "dot" }
   { "doh.example.com", 443, "h2", "https://doh.example.com/query/?{}" }
   { 192.168.1.1, 53, "do53" }

The main driving factor for having an ALPN token is for cases when there
is a desire to configure dot and doh to share a port (especially 443)
for some use-case.

Regards, Erik

On Fri, Dec 13, 2019 at 8:53 AM Ted Hardie <[email-masked]> wrote:

> Router advertisements are a little trickier.  If someone is currently
> using RFC 8106 style advertisements, I think it would be cleaner to have
> those still present and a new option for DNS-over-not-53 options.  That
> could still leverage the ALPN list as a way of making that a single option
> There are clearly operational environments that wouldn't follow this
> (those that use the URI template in RFC 8484, for example), but something
> that allows you to signal them together does seem useful.
>
> I'm not an expert on either DHCP or RA, of course, so I may have this
> wrong way around.
>
> regards,
>
> Ted
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 13 Dec 2019 09:27:53 -0500 (EST)

On Fri, 13 Dec 2019, Erik Nygren wrote:

> Linking ALPN and port defeats the purpose of ALPN.

Indeed.

> is a desire to configure dot and doh to share a port (especially 443)

But take into account that DoH is partially motivated by fighting
against DNS censorship, so in those cases using ALPN would be a
non-starter. Sure, services like Google DNS or Cloudflare, that
would be running DoH and DoT on port 443 to make it easier to
bypass unintended filters (eg blocking of port 853) while still
not trying to hide their DoH traffic from Paul Vixie's home network,
could use this ALPN setting to demux, although I wonder if they
couldn't determine this by the incoming stream somehow anyway.
Especially if the services use the same TLS key/cert.

Although I doubt we would need to write an RFC with ALPN for this
use case. It's pretty easy to enumerate all public DoH servers for
those who want to block them to offer their own DNS security services.

ALPN did come up in the DoH discussion. It was a conscious decision
not to require it because it defeated some of the goals of DoH.

Paul

---

From: Ted Hardie <[email-masked]>
Date: Fri, 13 Dec 2019 14:43:08 +0000

Hi Erik,

> Linking ALPN and port defeats the purpose of ALPN.

Unfortunately, ALPN's native "discovery" mechanism is more-or-less connect
and see what the list is.  That's pretty much what the original respondents
are trying to avoid.

If you have an external method, you can certainly make it more detailed
(and a set of tuples is a way to do that), but there is question of
synchronization of the addresses used in each.  If DHCP/RA are going to be
used for discovery, what I think that means is that if both the current DNS
option and a DNS-Tuple option are present, the DNS-Tuple option's
information would have to supersede any information in the current options.

So, let's back up a step:  are people interested in using DHCP and RA as
part of the discovery story here or not?

regards,

Ted

It would be preferable to have the discovery mechanism

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 16 Dec 2019 11:35:27 +1100

Ted,

On Sat, Dec 14, 2019, at 01:43, Ted Hardie wrote:
> On Fri, Dec 13, 2019 at 2:12 PM Erik Nygren <[email-masked]>
> Unfortunately, ALPN's native "discovery" mechanism is more-or-less 
> connect and see what the list is. That's pretty much what the original 
> respondents are trying to avoid. 

I think that you are conflating the protocol negotiation with discovery.  ALPN is a negotiation method, and what we are looking for here is discovery.  ALPN allows client and server to negotiate DoT and then be confident that the resulting connection truly is DoT.  ALPN might be useful in identifying a protocol, but we shouldn't be loading ALPN with other semantics as you propose.

The first question we are trying to answer with discovery is "does the network provide a DoT resolver?"  (The next question being "Where is it?"; a question that is at least partially answered by existing methods.)  You answer that by say "I have DoT" or "I have DoT *at this location*".  ALPN only factors into that process to the extent that you need to have some way to distinguish different protocols.  Erik points out that using ALPN as a component of the key tuple is potentially a valuable way of using it.  I agree.

There's a related question here about how the server is then authenticated.  RFC 8310 is far too permissive in its definition of options to be of much use here.  For me, that's a far more interesting question than the one you pose.
 
> part of the discovery story here or not?

I am.

I tend to think that https://thpts.github.io/draft-peterson-dot-dhcp/draft-peterson-dot-dhcp.html is a reasonable start here.  Sure, it makes some assumptions, and leaves some of the harder 8310-style questions unanswered, but that's where I think we should be paying more attention anyway.

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 15 Dec 2019 21:40:40 -0500

> On Dec 15, 2019, at 7:35 PM, Martin Thomson <[email-masked]> wrote:
> 

This is at least the fourth list that DoT discovery over DHCP has been discussed (see DoH, DNSOP, and DRIU).

In the previous three times, it was rejected as not a trustworthy source.

Willem and I wrote a draft on DHCP options that was well received by DHCP experts but not well received by DNS folks.

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

We presented it at IETF 102 in Montréal (July 2018). Looking at the DRIU mailing list, both Martin Thomason and Ted Hardie were active and so you may remember it and the poor reception it received. Our slides are here:

https://datatracker.ietf.org/meeting/102/materials/slides-102-driu-dhcpv6-dns-discovery-00

This draft could be easily revived but that doesn’t change the objections we received back then.

I think Ted Lemon led the charge against this. Here are his slides:

https://datatracker.ietf.org/meeting/102/materials/slides-102-driu-when-to-use-dhcp-00 <https://datatracker.ietf.org/meeting/102/materials/slides-102-driu-when-to-use-dhcp-00>

and here is the video presentation. Ted Lemon starts at 33:13

https://www.youtube.com/watch?v=cfEX8zuoRAA <https://www.youtube.com/watch?v=cfEX8zuoRAA>

Tom

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 16 Dec 2019 15:06:32 +1100

> In the previous three times, it was rejected as not a trustworthy source.
[...]
> https://www.youtube.com/watch?v=cfEX8zuoRAA

I refreshed my memory here and I my interpretation of Ted's presentation is perhaps different than what you took away.  I could make one of two inferences:

1. Don't allow the network to configure DNS.  You can't trust it.

2. Be clearer about the trust model when you allow the network to provide this information.

There was a bunch of other noise about the shortcomings of DHCP, but this was the central point.

The first might be read as a firm argument for certain DoH deployment arrangements.  Arrangements that have proven to be highly controversial.  Your own introduction to the next presentation acknowledges the shortcoming and even identified a trust model or two that might fit within the remit of the second option.

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 15 Dec 2019 23:34:36 -0500

> On Dec 15, 2019, at 11:06 PM, Martin Thomson <[email-masked]> wrote:
> 

My take-away was that it was ok to use DHCP to bootstrap but then a host should then establish trust in other ways. Maybe this was the result of other discussions in combination.

The Android folks seemed happy with using the existing DHCP DNS server information and attempting to connect to that server over port 853 for DoT at the same time as sending queries to port 53 and preferring the TLS connection if it was available.

This required no new DHCP options.

I was under the impression this is how most clients were going to proceed.

Thanks,
Tom

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 16 Dec 2019 12:22:44 +0100 (CET)

> Il 16/12/2019 05:06 Martin Thomson <[email-masked]> ha scritto:
> 

Incidentally, though it is much easier said than done, I think that being able to apply different trust models to different types of networks, so that the OS/application behaves differently when you connect to a random wi-fi in a cafe than when you connect to the usual network in your home, would really help in finding possible middle grounds in terms of deployment models.

-- 
 
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: Mon, 16 Dec 2019 12:55:51 +0100

> Incidentally, though it is much easier said than done, I think that being able to apply different trust models to different types of networks, so that the OS/application behaves differently when yo…

Trust model: I could imagine each client having a pre-configured *list*
of TLS-certificate names trusted for the purpose of encrypted DNS.  You
might add your ISP's in there or you might not.

Then address+port+protocol from DHCP (or any insecure magic) seems fine
to me - it only matters whether it "matches" an item on the list...
otherwise there would fallback to a public service.  For example, some
items of the list would also have a configured IP, or perhaps even
bootstrapping with the untrusted DNS could be done.

Of course, here I'm not trying to address what exactly is the client (I
personally prefer OS level) and how exactly the choice is exposed to the
human users (a hard question).

--Vladimir

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 17 Dec 2019 09:55:49 +1100

> might add your ISP's in there or you might not.

Yes, this is approximately the model I had in mind.  And it was one Tom mentioned.

---

From: Dan Wing <[email-masked]>
Date: Tue, 17 Dec 2019 18:57:13 -0800

> bootstrapping with the untrusted DNS could be done.

Exactly that, yes.

Said another way:  the network coiuld send you to a malicious DoH/DoT server via the network's DHCP advertisement, or the network could send your queries to a malicious host (by routing the packets towards the malicious host). Both attacks are solved the same way:  by validating the certificate presented in the TLS handshake.  Throwing out DHCP and RA advertisements of DNS won't get us to a happy place, it will get us to vendors building TLS ALPN routing and port routing and lots of other stuff, in order to deliver split-horizon DNS and .local resolution and DNS filtering and avoiding round-trips to corporate HQ's DNS server.

> human users (a hard question).

Yes, there are difficult questions and answers there.

But when I visit a branch office of my company, I would like to use the local DNS belonging to my company (split horizon DNS, thanks) rather than suffering the round-trip to corporate HQ.

-d