Re: [Doh] [EXTERNAL] Re: DoH

George Michaelson <> Fri, 29 March 2019 11:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 567BE120264 for <>; Fri, 29 Mar 2019 04:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zsCAPxiaLxwU for <>; Fri, 29 Mar 2019 04:03:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1786E120258 for <>; Fri, 29 Mar 2019 04:03:31 -0700 (PDT)
Received: by with SMTP id d201so1366643iof.7 for <>; Fri, 29 Mar 2019 04:03:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bMHrzu+Rnc973Fd+YuIHeZrtVgIYyJUPBSdy7LFIXYY=; b=oBSviGjqQENwdv0WPY2Udmj7UPWTvzFXAd8a0ruF1zkEDlz6pEa56joGNwkMHW0elu 0KywHguoEd6hcxkmLNhqPM6a8RUlegl1gy4TwSz9QCzz9iU+/1TSyfa+17a9Rudv5A2t 1J5Qrq2bm22lgPNRYtjwThi65nuR6zLSZ31KcoKB0GQs3Hv+wG+6rkegwDhQGUZqATLd eQ/meW6CC/Arr7Wyfefw7AMDFiULVIHLgn9lceGjB+tkE0AEST7Yw7AVG5sA69pAaUAJ s3yc3nMWjxgCePlWZ1JuveKsjw/myoD7n2nOu11gsX4ovbBWwzxrVmckZaF8//TjEQ4i 7ecQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bMHrzu+Rnc973Fd+YuIHeZrtVgIYyJUPBSdy7LFIXYY=; b=pecaT7a12MkDRf/Uq0iyndKCS3cbyVbjutkdxtTii9AICUtvHGwZzWmdviI9QdNRpk AxXSJwhOYF/fm65r8G25dLWgZ3Znh6+xj1SvHHyPkWW4O1C0YsizHxiSojHP0NtbVzPO XQ+1Cxz7+o7Ptk8kqSVEzGDItCD4GnQPa+GL8rj2r3NZ4X+wFRqbtpOwt8h18WVb4Won CKP1e1dzDXVjyUDY9gDveczMZ2/nFJy54spTMknCBJEUtzcHzXtxNs/LZd1nAfSOA2fI f8MgFbEwn27um7mZgzFk4W+ATD7EDBLiq6IGW2sqpGHtPNo2Wjyfg1hXvc6Kri42dcWk oShg==
X-Gm-Message-State: APjAAAXHmLkLhXU/teAK5DpRkczqNRa//HemLdNOyUSxdLREH3mg6/mW 7Cpgp+XRxwPfRT75wI984bUKrD7tBrclU02CBrX6JA==
X-Google-Smtp-Source: APXvYqzBmog9nVxSkC/AtLcBb0gq+nnK2AGyMngeprWrANvdj8L6FqxhJtOrmu0fMlxQADPsDgicPxTzPFaa5+0vMTU=
X-Received: by 2002:a5d:899a:: with SMTP id m26mr35597515iol.268.1553857410308; Fri, 29 Mar 2019 04:03:30 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: George Michaelson <>
Date: Fri, 29 Mar 2019 12:03:19 +0100
Message-ID: <>
Cc:,,,, Paul Hoffman <>, DoH WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Doh] [EXTERNAL] Re: DoH
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Mar 2019 11:03:35 -0000

Do you believe there are substantive differences in respect of the
legal challenge to Operators of DoH compared to say DoT and DoC?

As to its protocol maturity and risks, Because DoH moves out of strict
53 framing and processing, I think it does have qualitative
differences to DoT and DoC in these terms because it is less likely to
be classic DNS processing by a resolver client. But, I might ask the
same question: Do you see risks different in scale and type to DoT and


On Fri, Mar 29, 2019 at 11:58 AM <> wrote:
> On Mar 28, 2019, at 22:40, Winfield, Alister <> wrote:
> > Top posting on purpose ….
> > I’ve tried to respond twice to this and I think third time I might get closer to my thinking…
> > The DoH solution (note not necessarily protocol) is missing at least two key elements which together would have reduced the
> > immediate panic in the implementation. Not to say there aren’t other things that need work just the really problematic issues
> > could be contained or deferred.
> > The current active work on discovery and somehow defining a trust and privacy mechanism surrounding TRR’s.
> > With trusted lists of TRR’s you’d then be able to use the output of a fundamentally insecure discovery method. If that
> > ‘trust and privacy’ were to be selectable say by choice of provider. You get the option to allow the local network policy / or
> > not. You can chose to allow trusted coffee shops but others may be not in your list because they do things that ‘you’ don’t
> > like. Parents can chose to trust only those DNS providers that give strong parental controls. Whatever group you are in
> > many things would be less controversial. Oh, it’s not easy but at least we wouldn’t be in the current position where it is
> > almost certain that a sudden change will occur to a keystone of the Internet.
> > Worst case example is that given the billions of queries per second we are talking about here and the localisation of
> > content delivery it impacts, many terrabytes per second of traffic could / would rapidly migrate to less-optimal CDN’s. The
> > distribution of this might well break networks, sadly there is no research that can reliably work out the full impact. Small
> > trials really don’t help because we already handle small percentages of non-local DNS use. It’s the unknown of what
> > happens if 80% of the users in a single software update change to a non-local DNS provider (especially if it’s one that
> > doesn’t forward granular enough EDNS client-subnet data because ‘privacy’).
> > I admit that last paragraph may be FUD, but in this case the risk to the stability of the Internet is potentially at stake so
> > largest possible ‘we’ owe everyone a little time exposing the potential issues in detail with any mitigations if they exist.
> > Preparing those who will be impacted for change and then somehow containing the initial  change so if it really does cause
> > hard to contain issues we have a small enough problem its solvable in reasonable timeframes. Anyone who has done
> > operations will tell you that big changes that happen fast are the nightmare you fight hardest to avoid.
> > One more thing I’ll repeat others warning.. beware unintended consequences this must not end in a fight between
> > networks, or governments and DoH providers. If this goes wrong and corporates and other players decide this is a step
> > too far because of the impacts we all know the outcome could be very messy and I for one would rather work to get a
> > less painful and most likely less privacy impactful result.
> > NB: Don’t bite I do like the protocol and I agree that there are some that need it to exist.
> I agree with the thrust of your argument, think that those that seek to distinguish between the protocol and its impact in
> real-world implementation scenarios are mistaken.  The current design is incomplete and lacking in functionality and
> needs more engineering effort in order to address the shortcomings identified here and elsewhere.  Without further work,
> DoH will simply serve to undermine privacy and security, as well as leaving application developers and resolvers that use it
> in a position where they may be non-compliant with legislation in numerous countries  - and so open to legal redress.
> I hope that the IETF recognises that these are legitimate challenges that need to be dealt with so that DoH can deliver
> it's intended benefits.
> Andrew
> _______________________________________________
> Doh mailing list