Re: [Doh] WG Review: DNS Over HTTPS (doh)

Phillip Hallam-Baker <> Sat, 16 September 2017 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E906313307D; Sat, 16 Sep 2017 09:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9kQnLWnvfaW3; Sat, 16 Sep 2017 09:07:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A73671321A1; Sat, 16 Sep 2017 09:07:50 -0700 (PDT)
Received: by with SMTP id t21so1887923oih.6; Sat, 16 Sep 2017 09:07:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0rAvSW2LpORwAWA4TeXlb8kifxl0Lq5pyEsdLNH+gxY=; b=NTNJiw/QyD6xVzQqFfLzmt6vF3uaBjCTgsFc8CaRvphR6DSw90/Xg3bLfnFO0ykZ1O jpYtSKrxgUfl6rpoWZnvHK0wNUPVZWZXuO2U8KJqOzAH65NlnyXH1CtKK99csanCJ6oq BRmgqb4jvKWUD267J0whlsEM9PRIGgs9YY1PZi7w9S83+QAxqPuH+h1Cx3pnaUzatKez Ndi+AIUSaDJczx0EwolKfr3MKQuauXE9mdbstG5YZM4OwcXde2IXup/TL3VWUNQL+ACU VAeBH+uSNDdrVRZfsHuK2eQCYPDBTYObArctexDjHImIXKdhJod/lQGpAdcQPL6Uogr2 90QA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0rAvSW2LpORwAWA4TeXlb8kifxl0Lq5pyEsdLNH+gxY=; b=EsRGYXwoDLn43bsBA7RB9AAKEGRiK4EZsaGwLWwdrpN4bOm7jn38ilGjyCqXmNcPLS VxVlL5DRj1S3LPDmMLxQq9P2HzAuNYATO+gRPMXnUmhZkHZQH6p7Br373JetaDcS6e82 VBcGKRdg8mdmMh3BxBY+ct0DUDqDnNb1ryDZBPCFdICF7JzNIUQNuXsdCDhy+1BDnBl+ vpw/sXGYx+hNICfZaORLvvl+k10VIOn8uzRCk/uj/dkL50inDhO2I20lLFjqYU4bT/7Y wUXcq3tbasjqkAOs/5ceC9zf3265TBXwavsK2bqp3mLmdHxF1lfnOyZOsIUNJs2QmH8b JEzw==
X-Gm-Message-State: AHPjjUi8Xe2BWHX58eCo7iCmAVQxt6YNY/9VoDxNLQd84wf+3NEEK+tD jl60YNEqjPBLyBKg+q1QBblXSSijWCSxr2WURCk=
X-Google-Smtp-Source: AOwi7QBBmLX4Kt6R+PrVAjqHCDXlfF11l31LacmRa8/kgBLeZjxwTvrj99H+FQKiqP8O6Cski1VETCbNs8uAXi2wKM8=
X-Received: by with SMTP id i84mr5758547oia.166.1505578069710; Sat, 16 Sep 2017 09:07:49 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 16 Sep 2017 09:07:48 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Phillip Hallam-Baker <>
Date: Sat, 16 Sep 2017 12:07:48 -0400
X-Google-Sender-Auth: Ld4vIl-3vhkVveoJx5r1HrDQjLc
Message-ID: <>
To: Patrick McManus <>
Cc:, IETF <>
Content-Type: multipart/alternative; boundary="001a113cf8d006e799055950b6f6"
Archived-At: <>
X-Mailman-Approved-At: Sun, 17 Sep 2017 10:27:43 -0700
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Sep 2017 16:07:53 -0000

Responding to the thread as a whole:

1) I see no evidence that HTTP/2 is suited to Web Services or will be
dominant in that role. HTTP/2 was designed to serve Web Browsing to the
exclusion of all other concerns. Which was the right choice to make.

Web Services that are not merely information fetch protocols rarely make
any use of HTTP features at all except for framing and to increase the
number of ports by using URIs as ports. Raw TCP/IP transport is no longer
practical due to the large number of firewalls and NATs and 2^16 ports
would be insufficient anyway.

2) Web Services over some form of QUIC are almost certain to be popular.

QUIC addresses pretty much the exact same set of concerns that the use of
HTTP/1.1 for Web Services does and finesses the problem of TCP/IP being
designed for a different age. If QUIC was not being developed, a lot of Web
Service developers might well look at HTTP/2 but as things stand, I have
zero interest in HTTP/2 because I know that it is a dead end for Web

This is a *good thing* BTW. There are only two types of traffic: Web
Browsing and non-Web browsing. Does it really make sense to suggest that
they both over the same protocol?

3) This is the wrong time to do this work.

Failed experiments come at the cost of creating obstacles that get in the
way of real progress. The same argument is made every time one of these
experiments is proposed and we get the same result. During chartering the
argument is "We are just concentrating on one problem, this does not
exclude anyone else", After the working group is chartered it is "Hands off
our turf", after the RFCs are published and nobody is implementing them it
is "we tried and we proved that nobody else could have solved the problem".

There is a growing list of these failed projects, lets just pick DANE. DANE
was meant to be a way to publish TLS certificates and to communicate 'must
use TLS' security policy. There are numerous technical and commercial
reasons that combination was doomed to fail even if the deployment platform
was not DNS which makes the difficulty of everything squared. The proposal
did not have support from the Web Browser providers whose co-operation was
essential and killed attempts to sell DNSSEC through DNS Registrars (most
of whom make their margin on WebPKI affiliate fees). Input from all
stakeholders was rejected.

If you recall, CAA was originally proposed by myself and Ben Laurie of
Google. The reason Ben dropped out was that I was forced to remove the
security policy dimension of CAA. Now given that CAs are now required to
support CAA by CABForum, doesn't this mean that there was a real cost to
letting the DANE group bully us out of that space?

[This is not how I would do security policy now BTW, I would look to use
the TXT records as described in RFC 6763 to incorporate the same sort of
data that is specified in HTTP Key Pinning for Web Services.]

We had a re-run of the same issues with DPRIV which began with the
assertion that a solution must be found within a year. This restricted the
range of technology solutions to a set that were utterly inappropriate.
Currently, the WG is still functioning but it has no support from any
deployment stakeholder I am aware of.

The point I am making here is that DNS is the wrong layer in the stack for:

* Working Groups with a narrow scope
* Working Groups attempting to achieve a result in a narrow time scale
* Working Groups that insist on owning the topic.
* Working Groups that refuse to engage the necessary stakeholders