Re: [Doh] Dedicated DoH port

Petr Špaček <petr.spacek@nic.cz> Fri, 12 April 2019 17:46 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 12CB21203C0 for <doh@ietfa.amsl.com>; Fri, 12 Apr 2019 10:46:21 -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 tuZcboDUctMi for <doh@ietfa.amsl.com>; Fri, 12 Apr 2019 10:46:18 -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 A87341200FE for <doh@ietf.org>; Fri, 12 Apr 2019 10:46:17 -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 D96DB63416; Fri, 12 Apr 2019 19:46:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1555091174; bh=XTTndjYB+KjeDAHdJX606IrbqFLExcmGkEhjBwUl9kI=; h=To:From:Date; b=OoWusduGKTqxNec+bZRwXkPGM4LjX0mYhtMLlGwe/MsgSdxc6ZMEDGcYg09XtS5RK lEsDyYdR6RBlSQpm5YXVB8+0xTjED9yLthIJgrJgasXmCIT9qkQ6Pg1lK5ssaS78XV RgTFxuAJTTvETWOs8rwlih2aGwuYs9DZx0iMUOHk=
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, doh@ietf.org
References: <d74add8f-8964-1c0f-cd2e-f10867390883@nic.cz> <87tvf48hyd.fsf@fifthhorseman.net> <af89fa30-b9a3-f471-50fc-bab48fb9cc32@nic.cz> <877ebz8kwz.fsf@fifthhorseman.net>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <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: <ae5dbfd5-637f-0193-cdb0-42f43c76bb75@nic.cz>
Date: Fri, 12 Apr 2019 19:46:54 +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: <877ebz8kwz.fsf@fifthhorseman.net>
Content-Type: text/plain; charset=utf-8
Content-Language: cs
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/M_jdBI1URQ800_VXM3zL4m6l_uY>
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 17:46:21 -0000

On 12. 04. 19 14:31, Daniel Kahn Gillmor 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.
> 
>  * 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

Thank you for elaborate reply, I will think about it.

-- 
Petr Špaček  @  CZ.NIC