Re: [Doh] Dedicated DoH port

[Petr Špaček <[e-mail]>]

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