Re: [Doh] Dedicated DoH port

[Daniel Kahn Gillmor <[e-mail]>]

On Fri 2019-04-12 12:16:31 +0200, Petr Špaček wrote:
> On 11. 04. 19 21:23, Daniel Kahn Gillmor wrote:
>> For knot-resolver specifically, i'd much rather it ship with DoH
>> disabled by default.
>
> Can you elaborate on the reasons, please?

 * one of the advantages of DoH is that it is indistinguishable from
   HTTPS traffic.  a distinct port defeats that advantage.

 * the proposed port is in the port range typically used by ephemeral
   port allocation, not something that would typically be assigned by
   IANA

 * system administrators who enable DoH services should probably prefer
   to offer other HTTPS content on the same HTTPS endpoint (e.g. at
   least a configuration page, so that when someone points their browser
   at this URL they get something human-readable).  It seems plausible
   that this requirement means that the DoH endpoint requires
   coordination/integration with any local https machniery anyway.

 * We went through this with the OpenPGP keyserver network years ago,
   when we were trying to figure out how to move HKP to HKPS.  The
   initial attempt was to put it on some special port like 11372, but
   that ended up making hkps less useful because it couldn't get through
   restrictive firewalls, so we moved to 443 instead.  Almost all hkps
   servers today use port 443, and clients have defaulted to it as well.
   This is network ossification for sure, but it's also a fact of the
   modern, messed-up thing that we call the Internet.

> Do you oppose enabling DoT by default as well?

No, because nothing else is using port 853.  I very strongly advocate
DoT being enabled by default, because none of the concerns above apply
to DoT, which was always going to be distinguishable on the wire from
traditional DNS-over-UDP or DNS-over-TCP.

Note that it's also possible to run DoT on port 443 in coordination with
an https service, if you want to avoid the ossification concerns
mentioned above
(https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/)
This is currently done on port 443 of dns.cmrg.net if you want to try
it.

> It utterly confuses me that this very WG on one hand invented DoH
> protocol because DoT is not good enough, but then WG participants claims
> it should not be enabled by default.

I offered those mechanisms in the context of Tomas's concern that
offering it automatically on the standard port (443) would be
problematic for those services that run on the same machine as a
different https endpoint.

I already offered two different ways to make it easy for an
administrator to enable DoH on the standard port with knot-resolver,
including one that involves nothing more than installing an operating
system package, something an admin will need to do anyway.

[ trimming Petr's serious and relevant concerns about our plans for
  smooth configuration, which i agree with but think we should take up
  in a separate thread ]

> So, how is it easier to copy&paste or hardcode
> https://doh.example.com/doh
> vs.
> https://doh.example.com:44353/doh
> ?

it's not a question of ease -- it's a question of semantics.

If you want end users to understand what they're connecting to (with all
the various tradeoffs we've already talked about with DoH), you need to
ensure that the string you're asking them to input is semantically
meaningful.

I've voiced my displeasure elsewhere about the idea that the user needs
configure DoH with a full URL, and not just a hostname -- because most
users (and maybe even some IETFers) don't understand what a URL is, or
what the semantic difference is between entering
https://doh.example.net/doh or https://doh.example.net/bananas here.
(for that matter, most users don't even understand what a hostname is,
but due to browser same-origin policy, public advertising campaigns,
etc, they probably have at least a closer fuzzy concept of "site" than
they do of "URL").

But users *definitely* don't understand what it means to enter :44353 as
part of the URL.  If we want to argue that these choices about who to
trust with sensitive data involve meaningful user action/consent, we
need make the choices that the user handles here as simple as possible.

Encouraging the wider propagation of ":44353" as part of the broader
ecosystem is encouraging people to make the (not insignificant) trust
decision about their DNS resolver based on magic strings that they don't
understand.  Let's try to keep that to a minimum.

Furthermore, the specific action requested here was to ask IANA to
allocate a port for this -- if the port were allocated to doh, then
perhaps that changes the URL from https:// to doh:// in which case the
magic ":44353" is no longer needed.  But the distinct port has all of
the disadvantages mentioned above, and now users will have to
distinguish between doh:// URLs and https:// URLs when making their
choices about who to entrust their sensitive data to -- another thing
that users won't understand.

> So, why should we make it harder for admins to make it available?

The only "harder" part you're objecting to afaict is a single
administrative command, executed during configuration of the DNS
resolver daemon.  The tradeoff is a significant amount of complexity for
the rest of the ecosystem, and potential worse interaction with the
users.

I don't think that's a good tradeoff.

  --dkg