[Doh] Question/proposal for DoH, for discussion at side meeting

Brian Dickson <brian.peter.dickson@gmail.com> Tue, 26 March 2019 09:37 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE712029B for <doh@ietfa.amsl.com>; Tue, 26 Mar 2019 02:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FNv7hB1tuqf5 for <doh@ietfa.amsl.com>; Tue, 26 Mar 2019 02:37:07 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 F0FEA120282 for <doh@ietf.org>; Tue, 26 Mar 2019 02:37:06 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id v20so13667350qtv.12 for <doh@ietf.org>; Tue, 26 Mar 2019 02:37:06 -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; bh=Dw/MA0WrZnOCCT6NO7q+k1MRfxd8SlWy+0OSmxYbp/g=; b=iyhzc5gFLCZxZ6x8r++Oa/ky03JrLzrzD8/mPNl9Wb7jM6qEjk2POPBiO4PwTOfWX4 bS5FFxWJg+YDudDPOL5uRj9SDSteXXu4bV4esaST2UX0kkkmUh0dDNW2iNGer6w+bHSZ 8Zl8lkJA2CcTKMkTSEDI4Jb9cjADsR3X5rWES/KguhrLzkkjEAwWOVOLGk25gvkdCjDX TdzUOXgej+wcvYPb79biZKIa6ycs3zF35kFXlnQocwJ6yHxvu03acEO6BxA0hD1A8V3F R1/8DNlrVERlBoZTs4N+KaQxIIsTWLC6tNy18sUBwbxBlKbwWABRH0MiDEwMHksRDty4 NRiA==
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; bh=Dw/MA0WrZnOCCT6NO7q+k1MRfxd8SlWy+0OSmxYbp/g=; b=B8WNAj+Jlp89fIxTb4cpQBAUIUINjl7vtEKI3hade5tYQ/chfRUS2M8j46m6DERyfT 82lz2wJQ6zsieOf/gZt1HeG6heK3B8JYxaoJtzNBk8mFdJ0W9AyptTG0YhRrLTTNlPrI InwIePG9oxGYUCmHnCLZE7Kg1gI+ujjpG79uNKgb8F/wSxP0cl10VQlZpkTlt8yUjbli XdcQw7imJBaXXaiOoiaySMis7EMMrD9V7P4hwS6f9av4vKXKS12PM3TatAQ2i5cAEIGp qQdoDgd1AJTmwD4tIfEydd6FTnVfaTj5/hsMRuEf4C8I4YbdIE0Qi+pS41cGGCClFS/f Hvgw==
X-Gm-Message-State: APjAAAU1FkWrXfy1/d61d9fcerKZ6AD/R9RBTLqGxA+yjbXARvFUdm1a o/GKvDJNgQJAUcAbGm5ogJ9g3WN5NoYA7KVdg78MXNa2XlY=
X-Google-Smtp-Source: APXvYqxgEICDU0qlpSXCeFyZTqXYAJReks8u82W/qD4vxPPRJxQ/mILId3+xlUoV+QzavOHKMpRqs/aQkhbFkEgSRGQ=
X-Received: by 2002:ac8:30ea:: with SMTP id w39mr25406844qta.351.1553593025673; Tue, 26 Mar 2019 02:37:05 -0700 (PDT)
MIME-Version: 1.0
References: <CACcWx2GeKL=wN_DPbgZY=js4uyQcWi5AaFXxsyJrWaiVS2U3jQ@mail.gmail.com>
In-Reply-To: <CACcWx2GeKL=wN_DPbgZY=js4uyQcWi5AaFXxsyJrWaiVS2U3jQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 26 Mar 2019 10:36:53 +0100
Message-ID: <CAH1iCiqc7j0LZBGJHYZL9iO3Pc2vQ_QR3HruYsyn6KRWz6C+4g@mail.gmail.com>
To: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006bbc220584fc10e2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/lBvrXcJBk-6GDSPX0wYoZcz8HPE>
Subject: [Doh] Question/proposal for DoH, for discussion at side meeting
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: Tue, 26 Mar 2019 09:37:09 -0000

I have been considering many issues on the DoH and DoT protocols, along
with the important use cases (dissidents, network operators, security
issues, clients and servers).

In the interests of advancing the discussion, I have the following
observations, and possible proposal.

I'm raising them here, in advance of the DoH meeting and of the side
meeting, so as to not need to draw pictures or use a lot of words to
describe these ideas, which hopefully will allow more focused discussion if
this comes up in either meeting.

DoH uses HTTPS, and as currently specified, re-uses the existing HTTPS port
number, 443.
However, as far as I know, most (or all?) HTTP(s) servers are fully capable
of listing on multiple IP addresses, multiple ports, and doing name-based
virtual hosting. Similarly, browsers are able to access HTTP servers on
non-standard ports, by appending the port number to the server name in the

Have IANA assign a new port number, for use exclusively for DoH.
NB: I am not suggesting that DoH operate ONLY on the new port, but rather
that DoH operate on BOTH the new and old port numbers.
Also: this presumes that everything supported on the original DoH port,
would be supported on the new DoH port, e.g. including HTTP/3 if/when it
reaches the RFC status.

This is a compromise between those suggesting/requesting/demanding that
browsers use DoT in addition to DoH, with preference of DoT over DoH, and
possibly using inaccessibility on DoT as a way of inferring network policy
prohibiting use of DoH.

The main reasons for wanting DoT to be used are: (1) unique, dedicated port
number; and (2) remove the burden/requirement to handle all the HTTP(S)
encoding, parsing, negotiation, etc., and (3) having to choose between
running a full-blown web server, or re-implementing only the necessary
subset of web server software to support DoH.

Thus, using an additional dedicated port number for DoH, would allow
clients to cooperate with network operators' desire to have a dedicated
port number for Do{HT}, while not having any additional implementation
effort (since the DoH protocol would not be impacted, only the port number
used). In addition, the inferred policy logic would be equally supportable,
whether the first port used was DoT or DoH(new port). Failure to connect
would potentially allow the client to infer that the issue is network
policy preventing access on the port(s) in question.

Dissidents would still have DoH(443) available, possibly without attempting
to use the new port first. The informed user consent issue would still
apply, whether through preferences configuration, or via UI. Also, the
issue of what browsers use as their defaults, including whether/when to
fall back, is a separate issue that needs to be discussed.

I would still encourage browsers to implement DoT, since the incremental
work required is negligible, and since there may be significant push-back
by DNS operators against requiring the HTTP portion of DoH, in order to
offer privacy to DNS customers. Browsers would be able to fall-back to DoT
if no connection could be established on either of the two DoH ports,
rather than having to fall back to plain DNS, or use of a different DNS
service provider.

Brian Dickson
(speaking ONLY for myself)