Re: [Doh] Dedicated DoH port

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

Hi Brian--

Thanks for the thoughtful followup.

On Fri 2019-04-12 11:45:43 -0700, Brian Dickson wrote:
> Having a DISTINCT port for DoH, does not necessarily REQUIRE that it be the
> ONLY port for DoH.

Absolutely agreed here, though i note that this discussion is in the
context of a proposed IANA registration.

I think we can all agree here that operators are always free to run
arbitrary services on any port that they like, and what the IANA
registry is managing is conventions for use.  In the discussion here
we're in the process of establishing norms about deployment, not strict
requirements.

All of my considerations written earlier were intended in that context,
and were about how i think the norms we establish here will affect the
broader ecosystem.

> On Fri, Apr 12, 2019 at 7:56 AM Daniel Kahn Gillmor <[e-mail]> wrote:
>>  * one of the advantages of DoH is that it is indistinguishable from
>>    HTTPS traffic.  a distinct port defeats that advantage.
>
> This is a bug, not a feature, from the perspective of enterprise networks
> who want to avoid having DNS traffic on 443.

I'm sorry, but it's a feature, not a bug, for users attached to (or
routed through) networks that they neither control nor trust.

Keeping it in the enterprise lane: do you want your enterprise users to
have their connections to remote DoH servers trivially blockable by some
remote network operator that is beholden to a competitor of your
enterprise?  I certainly don't.

>>  * 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.
>
> This is true ONLY if the end-point is a general-purpose HTTP(S) server.
>
> I know for a fact that some resolver operators do not intend on running DNS
> resolvers on machines offering other HTTP(S) content.
> I know for a fact that some resolver operators do not want to us
> general-purpose HTTP(S) server software to implement DoH.

Those operators are encouraged to run (the equivalent of):

    systemctl enable --now knot-resolver-doh.socket

and never have to think about it again. :)

For the rest of the operators who care what happens when a curious user
probes the actual endpoint in question, they might need to think about
it in a bit more detail.  And that's fine.  I'm trying to preserve both
options when it comes to deployment.

> And in the possible case where, for whatever reason, the same IP address is
> hosting multiple services (DoH and HTTP(S)), it might
> not be the case that the DoH and HTTP(S) sessions are terminated on the
> same server (e.g. virtualized server environments,
> or servers behind load balancers sharing an external IP.)

This is a distinct case, and "behind the curtain" of an organization's
internal jurisdiction -- i think we expect folks that operate machines
in complicated networks to be proficient about fiddling with port and IP
address allocation on the systems they control, so norms we establish
for the public communications network are less relevant there.

>> 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.
>
> This gets dangerously close to "bike-shed" arguments, or maybe "straw man"
> logic.
>
> Yes, it is *possible* to do <some action> <some way>.
>
> This does not mean that it is reasonable for <some way> to be mandated,
> e.g. if there are important distinctions in <some environment> which makes
> <other way> much better (more scalable for instance, or more secure, or
> whatever), than <some way>.
>
> In this case <some way> = 443, <other way> = DISTINCT_PORT.

heh, yes, i agree.  to be clear, the demux draft above is a provocation,
designed to encourage network protocol designers to think about metadata
leakage, channel multiplexing, ossification, privacy, and traffic
analysis.  It's not at all a "mandate".  It's a demonstration of the
lengths that people will go to when the network ossifies around them
based on designed-in leakage.

> There are MANY more resolvers than knot, including some number of
> independent implementations (not open source). What needs to be
> achieved is interoperability, without specific dependencies on
> specific implementations, IMHO.
>
> As open a *protocol* (or standard, or whatever you want to call it) is
> required, which should not be dependent about assumptions about the
> host OS or resolver software.

Agreed.  That's why i think we shouldn't deviate from the standard port
443.

> This basically gets to the UI issue vs the service offered issue.
>
> I don't think it is either necessary or useful for the connection details
> to be exposed to users in this way.
>
> The UI can very easily display "example.com" and have this associated
> with whatever the DoH operator of example.com wants.  It is the
> operator of "example.com", and not the user, who knows what the full
> URI is (including port numbers if appropriate).

you say "very easily" and i hear "simple matter of UX design" (by
analogy with "SMOP").  Perhaps you have UX design background and
experience, but the majority of the people i meet at the IETF (including
myself) definitely do not, and have given very little thought to the
difficulties of designing interoperable, meaningful, secure user
experience for the protocols that we use.  The example you then give
describes a range of things that the protocol needs to expose to the
user without giving any clear directive how to do it.

I just don't think it's that simple, unless we accept a configuration
option that is a pre-populated list with only the names of a handful of
operators; but that further entrenches the consolidation concerns i
believe we both share.

The norms we establish about DoH service discoverability and
representation (hopefully in a different thread) will have a real impact
on our ability to offer users meaningful choice in their decisions about
who to trust with their sensitive metadata.

> See the top of my message about why _DNS RESOLVER_ operators, rather
> than generic system administrators, might prefer NOT to use 443.

By all means, they should offer their services on whatever ports they
want.  My dns.cmrg.net service offers DoT on several non-standard ports
as well (53053 and 443 in addition to the standard 853).  But i wouldn't
want to register those with IANA.

   --dkg