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

Paul Vixie <paul@redbarn.org> Wed, 13 March 2019 06:45 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454C2130EA7; Tue, 12 Mar 2019 23:45:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 LNomWqfyaIvd; Tue, 12 Mar 2019 23:45:43 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1291130E92; Tue, 12 Mar 2019 23:45:43 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 963E4892C6; Wed, 13 Mar 2019 06:45:43 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "doh@ietf.org" <doh@ietf.org>, Christian Huitema <huitema@huitema.net>
Date: Wed, 13 Mar 2019 06:45:42 +0000
Message-ID: <3721473.Tv99E4QfP4@linux-9daj>
Organization: Vixie Freehold
In-Reply-To: <2d8f178f-9ba0-2b49-5553-b41a2da72310@cs.tcd.ie>
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7128698.bmqQpDD1M4@linux-9daj> <2d8f178f-9ba0-2b49-5553-b41a2da72310@cs.tcd.ie>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/YdIelbDLd6CCtQbVGPA22X9P9u4>
Subject: Re: [dns-privacy] [DNSOP] [Doh] New: draft-bertola-bcp-doh-clients
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2019 06:45:45 -0000

On Wednesday, 13 March 2019 00:36:32 UTC Stephen Farrell wrote:
> Hiya,
> 
> On 12/03/2019 22:51, Paul Vixie wrote:
...
> > i have no qualms about confidentiality, for traffic allowed by a network
> > operator.
> 
> To me, the above reads as self-contradictory. If the traffic is
> confidential the operator doesn't know if its "allowed" except
> possibly in some extremely coarse-grained sense. Perhaps when
> you said "traffic allowed" maybe you meant "protocol allowed"?

yes.

> But even that is confusing, given the likes of websockets, alpn,
> and other webby ways in which stuff gets layered on 443 all
> the time.

relevant security mechanisms allow for short term losses, leading to long term 
policy shifts. that is, i didn't isolate my chromecast-ultra until it 
misbehaved too egregiously. at work we're on more of a hair trigger.

> > it's the inability to inter[e]fere (as called for in RFC 8484) and not
> > the inability to observe (as called for in RFC 7626) that's at issue here.
> 
> Hmm. Not sure what to make of that. DNSSEC presumably makes it
> possible to detect interference, and yet RPZ (IIRC) calls for
> not changing DNSSEC-signed answers. I don't get why an inability
> to change is ok for the RPZ/DNSSEC context but not for DoH.

i think that's off-topic. my point is, as an operator, i can decide whether to 
allow DoT to off-net providers, based on whether it's OK with me that i cannot 
see what it's doing OR interfere with its results. (and i choose _not to_.) 
whereas, as an operator, that choice was deliberately taken out of my hands 
with respect to DoH... by design.

i think if the DoH people had wanted operators to have a choice, they might 
have said, DoT will handle anti-surveillance and anti-interference if it 
works, and the runtime will handle the selection. and, they wouldn't have said 
that one of their goals was to prevent on-path interference in DNS operations.

their def'n of "interfere" is probably unrelated, having a totally different 
scope, to the RPZ concept of interference.

> Another possibility is that we're discovering that when this
> confidentiality stuff gets used for real, we find that we'd
> really prefer to not have to change what we've been doing before.
> I don't mean that as an accusation but it has been easy to
> ignore e.g. the lack of deployment of DNSSEC or more recently,
> DoT.

i don't take it as an accusation, but this is about security economics, not 
new vs. old ways of doing the same thing, or preferences. the DoH people 
intended to dramatically raise the costs of on-path DNS interference. as an 
on-path interference fan, i don't like the choices they've left me with. one 
of those is "let any user or app inside my network do its DNS outside of my 
surveillance and outside of my (RPZ) policy controls." i won't be choosing 
that. my motives are grounded in security economics, teenagers, and malware.

vixie