Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

Brian Dickson <brian.peter.dickson@gmail.com> Tue, 12 March 2019 23:12 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2A11278CF; Tue, 12 Mar 2019 16:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 PprSAzy_ANYR; Tue, 12 Mar 2019 16:12:50 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 A2F021200D7; Tue, 12 Mar 2019 16:12:49 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id d2so4598442qti.11; Tue, 12 Mar 2019 16:12:49 -0700 (PDT)
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 :cc; bh=HlUYRI5YfVapiEBfupAP40hlQS+ndhH6MwgK/NyL3p0=; b=VBplFPLaVvBXHY6RTeps+eZAcpgGZzBoEB6QJPjRCZUeN36iYa3XcPiU/5d6CKKnhY Jxzgk7REHz/V+8NMoIcgc5kN0a6bEU+AjUpIvFBD1QfiLRvCoPX4d6iqXLiLsb+CvVGm L0rXZQy2EulFSWVreu2WDu6A5cQ1apah1d5IlfLRxCyNoTGL5uDrjS6kpQxxLLiAg0FG mUgGC3yswSaNslwXQkmrJUJkng9freVAkQSJfMSIZMB3Xm9w8ztzdbyRtbn5UkYdMfl+ pII3gxM9dRHlWa5QuBteqb/2MQEaE08noRoQdoL29AQQ9wzLzxM1dqlzxDvFAfSD+odW xmsg==
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=HlUYRI5YfVapiEBfupAP40hlQS+ndhH6MwgK/NyL3p0=; b=T3k+Eo/AYrPytey+qNaJ27AHaZur577sfjVzavNSxoLp8yrFqAEoTv+VNtK4cE12WS Rsz3KbOdNjOzhOwx/lzjxD9m0wWVUgXqQtVkE3gRTQDk+ZvoSFB9vdTStvOfb37Zt3MP 8lip5sYdGSxE8z4mtUNoFtGdNUQifEiU0V5LJah26pF2z+p2bfT6nrnZebGP/Twjk/ih Vn9Up87wXLYjj4VdUK6rHYYQ87nl7GAAlIerVwKbq5rOckYKZzq2tGFH63MuC74dQNpG 0calO4V5jlOfKIAox9skVooLe6Q54Cmr19oKNFilEEd+dRf4994ogC5ofXg9M4au8qNP yJLw==
X-Gm-Message-State: APjAAAVZgkkmR1MeJQgdtLSNwkAULmCPwKyQUeTYQ08wCmFuTE95VIec IF+OfHGSGlu9VBy16ahMe8mAQ+OsfSMSqcHip9y0QA==
X-Google-Smtp-Source: APXvYqzPRjCFLPHR7xWfCPw7WRdvt/DlxywsQGXy6xUc74rt8dAik2C6wlmYFWP7wF+aBlQpGEfClO5+vUTQaLQUuGQ=
X-Received: by 2002:ac8:3896:: with SMTP id f22mr31490715qtc.324.1552432368642; Tue, 12 Mar 2019 16:12:48 -0700 (PDT)
MIME-Version: 1.0
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <2356055.DoC3vY7yXE@linux-9daj> <92a3c1c1-0e0b-50c4-252f-94755addf971@cs.tcd.ie> <7128698.bmqQpDD1M4@linux-9daj>
In-Reply-To: <7128698.bmqQpDD1M4@linux-9daj>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 12 Mar 2019 16:12:37 -0700
Message-ID: <CAH1iCir7QgDsQ3wZ4nOfRpAOLt4Cgzwm3ONpdoseMxmfS8K=nQ@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "doh@ietf.org" <doh@ietf.org>, Christian Huitema <huitema@huitema.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="000000000000def3660583edd324"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/R8Iw_5dKCI5vnFOYtKzKfTtSEs8>
Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2019 23:12:52 -0000

On Tue, Mar 12, 2019 at 3:51 PM Paul Vixie <paul@redbarn.org> wrote:

> On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote:
> > On 12/03/2019 21:11, Paul Vixie wrote:
> > > ...
> >
> > There are reasons to want confidentiality for DNS queries
> > and answers, and access patterns, for which the IETF has
> > achieved consensus. (See RFC7626) (*)
>
> i have no qualms about confidentiality, for traffic allowed by a network
> operator. it's the inability to interefere (as called for in RFC 8484) and
> not
> the inability to observe (as called for in RFC 7626) that's at issue here.
>
> > DoT is one way to tackle those problems. DoH is another.
>
> DoT does not intend to place itself beyond interference by on-path
> entities,
> and as such, my choice as a network operator is either to allow it through
> even though i can't see the contents, or disallow it. and that's all fine.
>
>
I think there is a way to use technical design(s) to split hairs, i.e. I
think the side meeting
has the possibility of bearing fruit which is palatable enough for all
parties.

The crux of the problem is how to determine if the network operator is
truly hostile (GFC),
or merely restrictive (Paul's network, Paul's rules.)

Suppose the client signaled a desire to use a particular DoH operator.
The network could respond with, "No", or "Yes", or "Yes, but I want to
inspect your DNS traffic",
or "No, but I'll place you logically outside my network, and enable the
isolated bubble you are in to do what you want."
The client could treat "No" as hostile, and do something appropriate for
being behind the GFC.
The client could treat the "Yes, but" as a reason to then ask for the
"bubble" treatment.
If the client is offered and accepts, or requests and is permitted, the
"bubble" treatment, there is no need to go hostile.
In "bubble", the client would not be able to interact with any local
resources, in effect being in a non-split-mode VPN to the outside world.

There is really nothing that would stop a non-compliant client (or malware)
from choosing the "hostile" mode.
However, if "bubble" is available, I don't see why that would not be
acceptable for any client that isn't malicious.

Does "bubble" (and the signaling required) seem like a promising compromise?
(Presuming the operator can still refuse "bubble" requests, of course,
perhaps with a polite message denying the request with an explanation.)

(Also, I would expect the MDM thing can be reduced to whether client(s) are
allowed to go hostile or do "bubble" mode.)

Brian

Brian


> DoH intends "to prevent on-path interference with DNS operations", and
> that's
> well beyond the remit of RFC 7626, and is therefore not spoken to one way
> or
> another by IETF consensus. i do not believe that a non-interference
> objective
> would reach broader IETF consensus. perhaps we can test that one day.
>
> vixie
>
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>