Re: [DNSOP] DoH vs DoT vs network operators, and requirements/goals?

Warren Kumari <> Wed, 13 February 2019 22:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9324F130DBE for <>; Wed, 13 Feb 2019 14:30:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 VLrjuUe2Z2QA for <>; Wed, 13 Feb 2019 14:30:09 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7717128CF2 for <>; Wed, 13 Feb 2019 14:30:08 -0800 (PST)
Received: by with SMTP id o17so4367939wrw.3 for <>; Wed, 13 Feb 2019 14:30:08 -0800 (PST)
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; bh=JUBl+IBpEKgaI1fXllZ80Zfi3gDmSnldImapcWc0fe0=; b=YWsdwLw3Rx99IjldSF7NHdjkxFe6KK9WOsQFzXdVV3hJWgYi+SBggVyHXNbCagYZvs Yz0P4fkBnOxWKQc5g7gvJsBKf+S3HXi+1c1spioFbOiOTnyS1S9gsTCMH5a9zBEEDS0k uZpDT5LHM9pt7vX8lbc+eIiLqlDzMtmUmSt92wd/3fqFWG2bzDf/sRZm2v7Vn10boY0k Rr4P6IHXKHPA1qzQ0SiNAHG28FusQf2JUh28KVvAJmP5hlOIdCTJaxOftLbAA2AOKt4I MwgThxZv1vb3M0mN8w3oBEOkLjvCiRh243j7f2YY1RwrR6xtKWs+DVLRoVynxvMU0c/K cfbQ==
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; bh=JUBl+IBpEKgaI1fXllZ80Zfi3gDmSnldImapcWc0fe0=; b=ZOsZXdVbdkFaN0IbTRhAUyGtwpDfbjK73UQpRexsIDxBkErR2Olq3hICDINZT6tUS6 H/bcGuqyYW3uxFoCI+i9ibF7/1BjMRjCIZesQWQI00OMQ1gQqaHrroa+xDsYpHBoSmBy tlqR6ZxmzyzWRKfCp52tMSYE+VosCSNxJ1/VNIxTrcEpY1WIt8MxI0PVbjoQeGK77K3O VfzyUW3ExP5BmwZkkZUnIKxKqOR4cbhznKluHLXKZWXxM7HZiIJgqDwNo2+S65xS8JQc T77xx7+cP1BzKonGl+/r0qijOWIo2zZZ+HfPA57K6op5ZBV7B3nNCh6R23mTLMGBxfwX a5Gw==
X-Gm-Message-State: AHQUAub2D20rQC7+YmZfD6xNjFLUl9Yg8Q3NxxQ1StkAjH7eYUtB83BV phUvcyjPd5XmXu4yWw5xm9DDv6c5LA3cQpcV+49KpQ==
X-Google-Smtp-Source: AHgI3IbhkDZXuKyDscxiw4xQAnT67hOV9CtnarrY/QMGoT0MSfyP92nHjtT3a/JlluTXDxSKxrFX6DfLK1kwQtXVWn8=
X-Received: by 2002:a5d:4e82:: with SMTP id e2mr238137wru.291.1550097006789; Wed, 13 Feb 2019 14:30:06 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Wed, 13 Feb 2019 17:29:30 -0500
Message-ID: <>
To: Brian Dickson <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="00000000000075245b0581ce158e"
Archived-At: <>
Subject: Re: [DNSOP] DoH vs DoT vs network operators, and requirements/goals?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Feb 2019 22:30:11 -0000

This discussion (and the other DoH ones) would probably be better handled
on the DoH mailing list -- - so
that the DoH people are involved.

The DoH WG charter specifically says: "The working group will coordinate
with the DNSOP and INTAREA working groups
for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics,
respectvely. In particular, DNSOP will be consulted for guidance on the
operational impacts that result from traditional host behaviors (i.e.,
stub-resolver to recursive-resolver interaction) being replaced with the
specified mechanism."


On Wed, Feb 13, 2019 at 4:56 PM Brian Dickson <>

> I've been thinking a bit about some of the issues raised in the recent DoH
> discussion.
> What I am wondering about, is what the goals of different parties might be.
> I am also wondering whether some available standards (or additions to some
> of those standards) might be helpful.
> Finding particular middle ground technical solutions to balance the
> different goals (hard requirements vs philosophical issues vs real-world
> things), is what I think is a productive direction to have discussions.
> Some of the issues may need to be examined a bit closer. E.g. distrust is
> pretty vague. There are multiple underlying issues, e.g. privacy ("I don't
> trust you to know stuff"), or data integrity ("I don't trust you to not
> mangle data"), or surveillance ("I trust him more than I trust you, because
> he doesn't keep logs longer than X hours").
> I think the ability to separate out DNS from non-DNS traffic when the
> transport is TLS on some commonly-used TCP port, is another issue.
> Similarly, being able to identify end-points by name or by cert, and
> possibly having the ability to act on that identification (permit/deny) is
> another thing.
> Are there other requirements/drivers on these issues, that are implied or
> that might need to be considered?
> Is there any need/desire to separate the transport from the actual DNS
> resolution? Or would that add too much complexity with no obvious benefit?
> Would anyone offer transport while allowing use of a third/fourth party DNS
> resolver??
> The technical things that might be worth looking at, that I can think of,
> are:
>    - New certificate use types (specific to only DNS, DoH, DoT,
>    server/client etc?)
>    - SNI
>    - DNS server names (standardized or validated, or white-listed)
>    - SRV stuff or similar
>    - AH without any content encryption (Null cipher), allows channel
>    integrity while letting network operator monitor view query/response
>    traffic, e.g. for pseudo-RPZ functionality
>    - Is there a DANE use case anywhere in here?
> Sorry for the noise, if anyone isn't interested in this stuff.
> Brian
> _______________________________________________
> DNSOP mailing list

I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of