Re: [Doh] Dedicated DoH port

Brian Dickson <> Fri, 12 April 2019 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E053012031C for <>; Fri, 12 Apr 2019 14:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZReNQpQY52UX for <>; Fri, 12 Apr 2019 14:37:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DFD4C120301 for <>; Fri, 12 Apr 2019 14:37:47 -0700 (PDT)
Received: by with SMTP id w30so12943781qta.8 for <>; Fri, 12 Apr 2019 14:37:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y+ieAejMkZ3pqJg3TVpygZBHjdyFaM0whoBUZCYV2Ew=; b=maY5d1ZkUxLV6b0a94RwkpLN3xXG8FkmfG5Zv+l1Va8BP6zghfXfkvdTxiPFNRaAv0 VrhWtRcRM86KeeYLnS8J69oAoD6/2xRnzBht0/s2Cz51GxQsfHKBjaAFx9oiorJsOURg mPpiVdW4MgEXmDwAjPTZxEjPLCSU95VQCZOBPPZzAeL0kU6V31mzQYh5ax4cH1552tBC jU7qqiiLh0bL4WSROWBOhUI8Lx9bvJx7Jhm7CLEXOpzyWlPtA+LwYcaI8bD4uJkoeJ7f 8AF8+1A6s2g9xTSnpFPUUgKZvDMIW7edrSF/Q6eNU3HsZFIPa1rNufR+ge9EjkHeqENB 8Ilw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y+ieAejMkZ3pqJg3TVpygZBHjdyFaM0whoBUZCYV2Ew=; b=cohWZ4BsLVq3oKNAPW6XMns7irOW3v6JLQGfOt5rVBCM3pzrvVJn3wGQrpfAGaximz gN6mP0E1Hb1r1KGb/8e4V9Yy+Sus+kSoQT9FQxp9KcvxK32W5p5ez9x+VGKm8dXhvJ+E ij6sx1G8oXPEtrBEpXg+3vfSrmvIKP/GNwxy4muLfiI0NJkvxmKrVf+iYUpKDTdmuVd7 OeMk9j14nr2wjyCJxFiBTv1ru8eS/1o6hM8MBD6mIvDvswWB8kpIFzpsY7QMbx+R/LD2 vU46WFhj3OWHX33nk8+VlRMgiQt+Yh1nWUoQUM3a8lJacCwhPx7hsCJdS4um0NG2CrqY rZGQ==
X-Gm-Message-State: APjAAAXGWV0fGuo/aHt/5r3NRZRUXluwKfOUmNMb+MKBeKC+Kz7A60KR gUW7nhaCwJcMNkDqZ0bYxWrHdJI0AnDhHtZm5fA=
X-Google-Smtp-Source: APXvYqzWljpxz1e13IENI6l2OE6vcvb7tFBQ88SQFxipDiPn1OWjK+nNEQaHOauhRnyPvtO+9ivtFxklX2XPstJf3Mw=
X-Received: by 2002:a0c:812d:: with SMTP id 42mr2369999qvc.68.1555105066880; Fri, 12 Apr 2019 14:37:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Fri, 12 Apr 2019 14:37:35 -0700
Message-ID: <>
To: Daniel Kahn Gillmor <>
Cc: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <>, DoH WG <>
Content-Type: multipart/alternative; boundary="00000000000019968205865c1d2f"
Archived-At: <>
Subject: Re: [Doh] Dedicated DoH port
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Apr 2019 21:37:51 -0000

On Fri, Apr 12, 2019 at 2:01 PM Daniel Kahn Gillmor <>

> Hi Brian--
> Thanks for the thoughtful followup.

You're welcome.
(I prefer to think first and only then stick my foot in my mouth. ;-) )

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

Actually, I want to have my cake and eat it too.

In this case, the enterprise use case would probably best be met by:
- an enterprise end-point running on a non-443 port (possibly DoT, or
- which forwards queries to an external DoH provider (on 443)

So, the internal user would not have DIRECT access to the external DoH
but WOULD have indirect access.

The enterprise forwarder might do other things (regular DNS stuff, like
RPZ, malware detection),
but might otherwise be configured/operated so as to not interfere with
privacy. Having such a
well-defined, standardized DISTINCT_PORT allows an enterprise to easily set
that up, without
having the problems of 443 outbound DNS leakage.

It's something that clearly needs to be figured out between all the parties
involved, including
the browser software folks, and probably needs to fail safe, if the host is
inside an enterprise,
the user is not a privileged (admin) user, and no new "opt-in" type extra
configurations for these
new enhancements have been done (new includes vanilla DoH, IMHO).

> >>  * 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
> > 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
> >> (
> >> This is currently done on port 443 of 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 "" and have this associated
> > with whatever the DoH operator of wants.  It is the
> > operator of "", 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 see the "under-the-hood" elements and the UX elements as being
loosely related but mostly orthogonal.

If there is a standardized "publishing" spec for each DNS provider,
perhaps as one or more RR types in DNS, in some well-known place
(like an underscore namespace, standardized via the IETF),
that would allow the mapping of DNS provider's base name to whatever
the DNS provider wanted to offer.

The UX piece is something separate, and as long as the semantics are
implementations should be free to do whatever they want. At that point,
the presentation stuff is truly orthogonal to the publishing/discovery.

Also, browser vendors have lots of developers, with hopefully some UX
skills and experience.

> 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 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.
Maybe, but as long as someone does want to register, we should standardize
on that,
and publish that, as an OPTIONAL port choice to use.

A given DNS resolver operator would then have lots of good options,
as check-boxes: UDP/53, TCP/53, TLS/853, HTTPS/443, HTTPS/NEWPORT,