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

Warren Kumari <warren@kumari.net> Wed, 13 February 2019 22:30 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9324F130DBE for <dnsop@ietfa.amsl.com>; Wed, 13 Feb 2019 14:30:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLrjuUe2Z2QA for <dnsop@ietfa.amsl.com>; Wed, 13 Feb 2019 14:30:09 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 E7717128CF2 for <dnsop@ietf.org>; Wed, 13 Feb 2019 14:30:08 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id o17so4367939wrw.3 for <dnsop@ietf.org>; Wed, 13 Feb 2019 14:30:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; 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; d=1e100.net; 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: <2019021215560470371417@cnnic.cn> <alpine.LRH.2.21.1902120846480.18026@bofh.nohats.ca> <201902131403257357123@cnnic.cn> <0CFDF54E-E57F-4500-8285-96A5EB035E9A@virtualized.org> <CAH1iCir9gYVTtQ-hLUusveMdZGZiL9VC5tDnM4AYsYz-AJTkeg@mail.gmail.com>
In-Reply-To: <CAH1iCir9gYVTtQ-hLUusveMdZGZiL9VC5tDnM4AYsYz-AJTkeg@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 13 Feb 2019 17:29:30 -0500
Message-ID: <CAHw9_i+4J8HQPGA5pX5ca3Lk6y+qKFY_XXdVgfSKaBOX2T7ZFA@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000075245b0581ce158e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9cSyhmUjqz002VwTg1N4EIQtmAc>
Subject: Re: [DNSOP] DoH vs DoT vs network operators, and requirements/goals?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=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 -- https://www.ietf.org/mailman/listinfo/doh - 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."

W

On Wed, Feb 13, 2019 at 4:56 PM Brian Dickson <brian.peter.dickson@gmail.com>;
wrote:

> 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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
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
pants.
   ---maf