Re: [Doh] Dedicated DoH port

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 12 April 2019 18:46 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE00120486 for <doh@ietfa.amsl.com>; Fri, 12 Apr 2019 11:46:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97EyguAGFsbk for <doh@ietfa.amsl.com>; Fri, 12 Apr 2019 11:45:56 -0700 (PDT)
Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DABF1204AE for <doh@ietf.org>; Fri, 12 Apr 2019 11:45:56 -0700 (PDT)
Received: by mail-qt1-x841.google.com with SMTP id z17so12353561qts.13 for <doh@ietf.org>; Fri, 12 Apr 2019 11:45:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tfliy+vIrq/naozv0VOSnoSNl08GY3Vg1BJD7yv14Ho=; b=Uhw06OaAJb+gnNQIm2PD03NPFNpJ+xjKoTGkIVM/caDRQVGZj3+iEhk93X+cHTaqY4 agPt6PjxwB6yeXvIEqk7u3S2CTMztlGqn7GAbQkTOK8fkWmFZj3w4Hs1txAd7giIxb4d EM/4HT5Oaw0RBhYOPl0lV3jt/MXB/eRP8ftNB2Z6RmheTLKAac7NTxA6+U7kv6Ltmply D8qkRpfj2sS20+lpV8MbeIn8w26ZTr5hJt+q1iiJdvz1KOCRbulcDx5oxGk0whyHz05b ywCYDIDhGgsF+Q0TG7P2KJ7Dc+MeRbrt8yPfF+RLTMsYBIY2d/59BlDz+NsoeebMuCdM 8B1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Tfliy+vIrq/naozv0VOSnoSNl08GY3Vg1BJD7yv14Ho=; b=iU3GGdyfDbaZuUoHnqhkkMjjcPMZ6eZTmbTMEsEMQNX1dCjuiacCbRXhEhdtonXrst exhfL8kaZNjmFd6EFCNJaKHkTz2Oy2AWr73mvTPVX8xaJlo45pgBi853NTBTJZwJ4+SH /oHMwRYfc/FXnPcgctp9c34ye4CZ3dechm3mS0JQRUBno7Dz+QvgsdSpVDv1Pj5qQ4f/ l3Mz9KsB82XVnHQZeczJS9G8gWEUHRrlDXY3roP26LSgQsPcUcNLnLXeWBjBUvLmXHz0 XAc1tvdd7EXue3GS9Zxw3ZhuX2JP0kxyMPF/T0rkXGOvpl7f9UuoCvt03tMuAmNEnqiC +Nqg==
X-Gm-Message-State: APjAAAXbjnvzuajqmMa8vD30Yk8XFn+NjmCujfWKWBr8ZB5UlN2yuczi zOujgDBcRMEFi/3XF1Fs55toqR0xl5zFzV0ODus=
X-Google-Smtp-Source: APXvYqz0J3mWQgjRWPY/bOmu0nxTopIaAVMlZdTju41eAyvkuCFs7eCe6TBpwTWqkbDCwjsbkJKF0fMA9hrhlZbw2kI=
X-Received: by 2002:ac8:38f5:: with SMTP id g50mr46709000qtc.119.1555094755216; Fri, 12 Apr 2019 11:45:55 -0700 (PDT)
MIME-Version: 1.0
References: <d74add8f-8964-1c0f-cd2e-f10867390883@nic.cz> <87tvf48hyd.fsf@fifthhorseman.net> <af89fa30-b9a3-f471-50fc-bab48fb9cc32@nic.cz> <877ebz8kwz.fsf@fifthhorseman.net>
In-Reply-To: <877ebz8kwz.fsf@fifthhorseman.net>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Fri, 12 Apr 2019 11:45:43 -0700
Message-ID: <CAH1iCipNtv0u6iKcujL+RZsPLD_4Sa0wLYuSRbjRLpk2tWFwAA@mail.gmail.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>, DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007a10fa058659b663"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/nQpH35De-SExfR4rYawRbtYMats>
Subject: Re: [Doh] Dedicated DoH port
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2019 18:46:00 -0000

Top-posting one comment, and then additional comments provided in-line.

Please read this comment carefully, as I believe it frames the issue in
ways not included at the start of this thread.

Having a DISTINCT port for DoH, does not necessarily REQUIRE that it be the
ONLY port for DoH.

Think of it as an additional port, rather than a substitute port.
Some DNS resolvers (offering DoH) might listen only on the substitute port.
Some DNS resolvers (offering DoH) might listen only on the traditional
(443) port.
Some DNS resolvers (offering DoH) might listen on both ports.
All of the above is orthogonal to whether the above resolvers listen on
853, 53, or other ports.
(A DNS resolver listening on 443 might or might not offer other services on
443.)

On Fri, Apr 12, 2019 at 7:56 AM Daniel Kahn Gillmor <dkg@fifthhorseman.net>;
wrote:

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

This is a bug, not a feature, from the perspective of enterprise networks
who want to avoid having DNS traffic on 443.

Having DoH clients and understand both DoH:443 and DoH:DISTINCT_PORT
facilitates the two use cases (non-enterprise and enterprise).


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

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.

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


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



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


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.


>


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

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

It might be the case that the operator of "example.com" provides more than
one end-point (DoH:443 and DoH:DISTINCT_PORT,
and possibly DoT:853), and either wants that exposed for user selection, or
prefers that the DoH client (e.g. browser) determine
which end-points are currently reachable, and use the first one in an
ordered list that is accessible.

In some use cases, the operator might want the user to know that port 433
is available, and for the user to select that for <reasons>.


>
> 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.
>
>
See the top of my message about why _DNS RESOLVER_ operators,
rather than generic system administrators, might prefer NOT to use 443.

This changes the balance of the trade-off on the server side.

The client side should be designed to support whatever the server operator
offers.
This might mean more complex under-the-hood configuration, or more complex
service discovery.

However, this only needs to occur when the client establishes the DNS
resolver
connection, which should only be needed when network connections change,
or when the DNS resolver connection is reset/broken/fails (regardless of
why).


> I don't think that's a good tradeoff.
>
>   --dkg
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>