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

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 13 February 2019 21:56 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 BCDD012D861 for <dnsop@ietfa.amsl.com>; Wed, 13 Feb 2019 13:56:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTJ_tvAk6mn7 for <dnsop@ietfa.amsl.com>; Wed, 13 Feb 2019 13:56:42 -0800 (PST)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 98F1A130EC7 for <dnsop@ietf.org>; Wed, 13 Feb 2019 13:56:42 -0800 (PST)
Received: by mail-qt1-x832.google.com with SMTP id p25so4263044qtb.3 for <dnsop@ietf.org>; Wed, 13 Feb 2019 13:56:42 -0800 (PST)
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=cpRnYH8TFh/5p8x1FGyZpOWZKOuAMegRNxzwqKudQkQ=; b=rRQT49BRO6Qb2KFmNy6rHBT45edW8WXdcCuYh4lvYRQyFGjbqLtDpT2mEB2de6l07Y mQhf7qPtSQEUAJteTEyF5LGBijd7Kb2pM2Bf52vDaIw76ZItPwXzzG7qkxRx2J9jUMQ5 Pqmg5DYC7m9rMWVOPo8loyF9L/ZrE4HH4yJfL6mtHuR9qPcYXp64aM7p0JvSUAb4624T mffjr2iGSaB6h8I7YpmhCii9+FPEyxphi9xl7zK1DVnZyWyzYruBKH4RnbYU31uolWPH N9hPuWOPnje9xanIfJme4gGEzoTqfCLaRI5LU8FiMQfieegKrFgxEbPzQq9gGQajcOCH pDFg==
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=cpRnYH8TFh/5p8x1FGyZpOWZKOuAMegRNxzwqKudQkQ=; b=pDtQIg5paDvZ1aFGW/gzjqiEqz5N8jsSrFM4a0vXDE9rqIReLTRJ/oWnpQb4rpVTBK tktVziVhhDcJVJndF+7QRNzxlkK4H3y3cJtNjYYYs3FcJCtbbroWTBfwSeTgBBpZ7Ypy 87EZtgvgucFiw3/oeWCMCPFVk4DLvBn8m46uWgZX0yog+j3wnzh9Gb4BWbqCtE5NPm/8 ckGvrVbbBfW7pywwXgJ3mrlsUVzzb1y8DoFjhKjuNFpc8JgiCLUFVv7m3+iljMb+eccW PFtrNfsPsxP0xnP9Ypb/Mc89mxlHMC7UyH/tVyTAorDbXru0VEE4Ds7qGAEqZokaRWv0 Khsg==
X-Gm-Message-State: AHQUAuZSMbOT30bz0xS0OrtVLR41lsCACdigtN50qpBWUqcxHD1BxHP4 JpPATlezUaIZ9g5vYR1tWPDqFfK/73Fc+dUFSqJ5DA==
X-Google-Smtp-Source: AHgI3Ia+aAiur9DRG70FN5U181rDHtHE/WozcoeulRUi3G+KUaKt60InThAmrSUtuooI8B8zEJhnekc8a+NZbMyQ2VQ=
X-Received: by 2002:ac8:26ea:: with SMTP id 39mr278144qtp.351.1550095001127; Wed, 13 Feb 2019 13:56:41 -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>
In-Reply-To: <0CFDF54E-E57F-4500-8285-96A5EB035E9A@virtualized.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 13 Feb 2019 13:56:29 -0800
Message-ID: <CAH1iCir9gYVTtQ-hLUusveMdZGZiL9VC5tDnM4AYsYz-AJTkeg@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e90ee70581cd9d5f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ARxEpePAk8Zcoz3O-AivhwBbwZw>
Subject: [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 21:56:45 -0000

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