Re: [Doh] Dedicated DoH port

Petr Špaček <petr.spacek@nic.cz> Fri, 12 April 2019 10:15 UTC

Return-Path: <petr.spacek@nic.cz>
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 66A11120287 for <doh@ietfa.amsl.com>; Fri, 12 Apr 2019 03:15:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.019
X-Spam-Level:
X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 EvMpdSCOc1Rx for <doh@ietfa.amsl.com>; Fri, 12 Apr 2019 03:15:55 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F3512019E for <doh@ietf.org>; Fri, 12 Apr 2019 03:15:54 -0700 (PDT)
Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2001:67c:1220:80c:8010:dac7:96a7:dd53]) by mail.nic.cz (Postfix) with ESMTPSA id 4005662923; Fri, 12 Apr 2019 12:15:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1555064151; bh=tE3UIfKh3NDVCf+K+oyxgTXfLTO4tmhzcg7maP02RzY=; h=To:From:Date; b=WYgDBqh/9XNLa/QrjVuKXDYbnEcyw/JY9C3PWy9CrqJth68zIWqxWxy6NxnYXQKgM FoTY+oeN2d9cKGwblbIprQpf1j4dfkWdsSP1RnVYD1cAoZQ1T+bMTRLxpkzOgkyJw8 HFgkouQxKtCnOmgpkQLcXa0jIk+5W28DsY/YvI2U=
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, doh@ietf.org
References: <d74add8f-8964-1c0f-cd2e-f10867390883@nic.cz> <87tvf48hyd.fsf@fifthhorseman.net>
From: Petr Špaček <petr.spacek@nic.cz>
Openpgp: preference=signencrypt
Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCBQZXRyIFNwYWNl ayA8cGV0ci5zcGFjZWtAbmljLmN6PokCVAQTAQgAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIe AQIXgBYhBL4m67nL4FmzkQyjW86N1qGlCiHkBQJcEOXhBQkFp4LgAAoJEM6N1qGlCiHkxNwQ ALFyQ7Rrghf0rM9GN2+kgP92Qvot21h8/Je3bRTvoLyhYUXcAMRmODZQ/0EsjExFc+pRwn+E 0GD2TpiorDnRMpJYEmHqenYGIrZ5TE0lHwwu0fi/X3evDY4j68OFlim5Q6+7pHOlZWaRsSm5 T6blSwIaNDFYtBhI0X1ZXTGqbXIUBFuGxolo/xEgUkeDy+6D4R8yT17CTHkuGYYrfUYnoBTr j3xMVil/lNMievaklAL8kRNVl0It4M8VzHTyEdMq7pG0CJ0CfU8COizCsu4+zy8dsxMVE0Su hju05LSsClZ9X1csxSK9HjKq+TG1Hx2qciFHRB1qC2mNIvWTm10Gkj4tLTWcJp3k2Wyv+1K2 sLFxreGOwbx0uR7XtIIBTiiZAiVsjBH0D39qG2ZLz+bJkQvlTDZQuXzsMS51wROvTVxPYcXX p069hON2+/QqJasmpOHhOydGkB3uokA0crqvMOnK+EcueKQQspvdLGiFLefJPuM8VVyR9fFZ YjnX2vfGZbE+MxY8wG4mDbhgxsUORAEtNUH/G0dvTv66fzKpl5q9GIZs7el+1IU31w7KivgS 7fsWcOsdzq4KzZzNBRJtEDoxX4b9lQ8P6ttMlPi7PnQ+iN0OUxKSnAnKQiqKMFRO1zH22vn7 iiF4JMO32//0HcpsyV8oEdjDkSJsFRnDfLW2uQINBFhri/0BEADFp4ZfxSoKTAad0IkFK9CV oZ6XKywYLFNPPhzw++gbvHL2EX7QqhEsqbsWMYpH4jc/Kq55OYYU/lIcULuD0Y9oDR26XFQo u0FeSNnzRGb607U8OFOPQ+ei92Mm1YPQ33GPj8GqbQpkAp35sfjJ64TH/EQY38RN33jsHRkh wtWU/6yo+RZs7cFRuihuLl8FuoP0A5u/x+lNNeIBk8f27LVYrF81NSDDDYjnObCah+QLzGAw GDtjWkBVawpoHWwq58OQSx5piwyOCnFJeFONRcTRgOz239rsEA5LeYfmOGcnNwG6CHoJ5ZdW Jw5OV9BoA7UTHG95xVHV5QiEm6q6igI6wKV2RtFS7Roe0Wt8H7gC41JeqaKTUsGkz6uJraF8 mmKyS8E+mSh3djmqdJNHF1pJqKxAxPYA9Y0jPnYWeEH4fPeOR2YvBjztsye9nOv1AuKNu03d uzocyU95DfP/lwNJr5SH918Vf1t7WcJj9dg6J9Jc5LOwg13Qr31TuZijrMdqM7LJKC/0tOkS eXNoMlHJOIqbqm7N414I0HytbENf7AiyDxNA5TzJKkB0eBPLm2FMQCHLfasJHgbCrQut6nYw 3f3Gn3+PDzGEHI9sfQv/mYvO77oRSGw+3Hy1ToxIncIirAyRpa5KdPLklDpADvpfkXjuL6If ZZ0OIWKLSRa/DQARAQABiQI8BBgBCAAmAhsMFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAlwQ 5fcFCQWngvoACgkQzo3WoaUKIeTg+w/9Gyp5EcB4AoR3vKVxP0SAh1zBher3bh9uGaKTAWt0 +0v8fyZYGEPqZr//9rkodPnXbQnr9ogzjJmZpsPvGPyRZikWjYIwkfM2Vb4BCyr5wQ9++9KB kob5zCQmUw2o7s/gISpFsCC5B0eYusArVDnrCyrroyaxbN6MpUb5lzVMEOCzYljtdrPRAXPL FKRm3ijLV0RcYPzJJVOPV5EzUfCtGsGTXXRI9Y9O/7lFaJ+iWnwygo/Xoi0IgBHvOAj9Gp3Q 0BY+sI6Rgzm9dbddm8gYJ4+FjfZivI7fbdfSubTWvrtFmFdHovIPJYLvXK7hUG22ww4CneIF D4oZSVy9xUoqJf0qQNruzEqTr7y7lbZIzxgPCSVmH0jpgJ1po6RLaJllNA+ZklOQ76fCMiaD 5yQuJluwD5w+acPWTbmZX6DijGHPZSjzeUkiMKctYSRqVUo6JmK0dgwwm3l1/Orb4D3YsLVP QDa4ZrCfSldrGC3zkEJ8iCVSYQwlc0JfIxyn8C3LLxToPYeFv/bQTeDYBjaV7a0SQ/xKUdpg RFzrGrxj7CM2WHcpxCLVK0agobuUO7YXoufHRM6y0rfMwT10baDjh+hLKMshxTqsP55lWvtM SleSGjheVTiZChb3jK0rUPCC4Rg3gDTEQsptC3TgN48PtLpmhsNc4JPm64zlrreInZQ=
Organization: CZ.NIC
Message-ID: <af89fa30-b9a3-f471-50fc-bab48fb9cc32@nic.cz>
Date: Fri, 12 Apr 2019 12:16:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <87tvf48hyd.fsf@fifthhorseman.net>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/2ULw7PX-MeXQZtNkt_KeVufwl3Q>
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 10:15:58 -0000

On 11. 04. 19 21:23, Daniel Kahn Gillmor wrote:
> On Thu 2019-04-11 19:41:42 +0200, Tomas Krizek wrote:
>> Service Name:         [domain-doh]
>> Desired Port Number:  [44353]
>> Description:          [DNS query-response protocol over HTTPS]
> 
> i agree with other commenters that this seems like it might not a useful
> allocation for a number of reasons.
> 
> For knot-resolver specifically, i'd much rather it ship with DoH
> disabled by default.

Can you elaborate on the reasons, please?

Do you oppose enabling DoT by default as well?

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.

> In terms of integration into a modern GNU/Linux system, an interested
> admin can do "systemctl enable kresd-doh.socket" to turn it on on port
> 443.  Or, you could imagine providing a separate OS-level
> "knot-resolver-doh" package that depends on knot-resolver, supplies the
> necessary module and .socket unit file, and explicitly conflicts with
> the other OS-level packages that would typically listen on port 443.
> 
> Either of these solutions seems better to me (and easier for an
> administrator) than establishing a distinct TCP port for DoH.

Can you elaborate? I do not understand where "easiness" of manual
configuration comes from. Here my reasoning on this topic:

Current state of DoH protocol is that it requires manual configuration
on all clients. In near future it is going to rely on hardcoded values
from browser vendor. I.e. actual hostname and port number are irrelevant
because admin (or vendor) has copy&paste then anyway.

Draft
https://tools.ietf.org/html/draft-ietf-doh-resolver-associated-doh-03
might be different story if WG decides to go with solutions other than
section 3, but honestly it seems that draft is not going to get
consensus any time soon.

My reading of this mailing list indicates that there is strong
opposition to any insecure means of discovery, which renders the draft
useless and we are back to copy&pasted or hardcoded values.


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

Having dedicated port could allow us to do everything automatically so
only copy&paste is left for admin. Default on port used by other
services requires even more manual manual configuration, which goes
against idea of having as many resolvers available as we can, with as
little effort as possible.

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

I'm eager to hear reasons.
-- 
Petr Špaček  @  CZ.NIC