Re: [Doh] Dedicated DoH port

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 12 April 2019 14:56 UTC

Return-Path: <dkg@fifthhorseman.net>
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 1DE0F1207E0 for <doh@ietfa.amsl.com>; Fri, 12 Apr 2019 07:56:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=eHg6Vz3N; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=WZCyhibZ
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 2F_Y3o0cprTO for <doh@ietfa.amsl.com>; Fri, 12 Apr 2019 07:56:03 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8ED1207DE for <doh@ietf.org>; Fri, 12 Apr 2019 07:56:03 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555080962; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=oxplh7tMESSgIcdZ7Z6DnMamv7+lN97jIJc6loSpQjs=; b=eHg6Vz3N1DQHRXTBdUklbYqnsBu+K5iQV0hLkp/DG6n8N/J99uXCF7jy FnDJ/tY267kraXAhP4YMXxfjcwkrCQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555080962; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=oxplh7tMESSgIcdZ7Z6DnMamv7+lN97jIJc6loSpQjs=; b=WZCyhibZ0yqVjsXieUR3buDUywx0vVHpOqAs2kMzAtohFVleBV/jK6r4 Eaya4naITIH0zYmuRd5clWKW5IQV/WB0+m915mF02HxvN4t1lEgC3auTzW fm9V9/2pxNQkiOVBecwZ1HP3mfoqxrWu77wEdvAbGsf+Ls2a9t0Bz209b+ 0ne2JIIO3ztL5qBBAx0znq6SNrwoYLFrItIY6klPtBA7vbwl0B01pyBe2W O8ZwuK19soX/HeOUARSqhWljLQrE2mVJ9IvhaYdLS34Q4UkG4GSJnxfHaJ O0PuujYSPOoGu6vTm6YIu7Y0Whb6pKypQ0Gy2Dr8jv9MJHDMyXXCSQ==
Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id E6257F99F; Fri, 12 Apr 2019 10:56:01 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id A9FE4200E8; Fri, 12 Apr 2019 08:31:24 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Petr =?utf-8?B?xaBwYcSNZWs=?= <petr.spacek@nic.cz>, doh@ietf.org
In-Reply-To: <af89fa30-b9a3-f471-50fc-bab48fb9cc32@nic.cz>
References: <d74add8f-8964-1c0f-cd2e-f10867390883@nic.cz> <87tvf48hyd.fsf@fifthhorseman.net> <af89fa30-b9a3-f471-50fc-bab48fb9cc32@nic.cz>
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw==
Date: Fri, 12 Apr 2019 08:31:24 -0400
Message-ID: <877ebz8kwz.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/q6G3q_6Lm2xqwTkgWkWgQa319Bc>
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 14:56:06 -0000

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