IETF Logo Mail Archive

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

Paul Wouters <paul@nohats.ca> Wed, 13 March 2019 01:04 UTC

Return-Path: <paul@nohats.ca>
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 1545C1311E3; Tue, 12 Mar 2019 18:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 P05NnP2P0Q4O; Tue, 12 Mar 2019 18:04:34 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0270D1311B5; Tue, 12 Mar 2019 18:04:34 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44JtsW11VnzKJY; Wed, 13 Mar 2019 02:04:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552439071; bh=x2k8Mmmo03gTfzOs9pF0Al5B9U1AJ6EuLhTA5OrWGic=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Fco5j8ToJEEsyGrt8jt2TdH0deV9muFxjiP8fh318DUZlg8IEQYtsSWME9HKHFrkw yG53G4j3PBxLVfKXAd72qdcKxBfeFb0C5h75MNhZB/w7e0ur7KsuY5bMG3GNYn2ilB kaelbefFWL4tGyapop1UVCrg62WI9hOs5n0kT2GU=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id xobr81eYOZIC; Wed, 13 Mar 2019 02:04:29 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 13 Mar 2019 02:04:28 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id B567C2FCD9; Tue, 12 Mar 2019 21:04:27 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B567C2FCD9
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AB5D540D35BD; Tue, 12 Mar 2019 21:04:27 -0400 (EDT)
Date: Tue, 12 Mar 2019 21:04:27 -0400
From: Paul Wouters <paul@nohats.ca>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
cc: dnsop <dnsop@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "doh@ietf.org" <doh@ietf.org>
In-Reply-To: <2d8f178f-9ba0-2b49-5553-b41a2da72310@cs.tcd.ie>
Message-ID: <alpine.LRH.2.21.1903122101280.7197@bofh.nohats.ca>
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <2356055.DoC3vY7yXE@linux-9daj> <92a3c1c1-0e0b-50c4-252f-94755addf971@cs.tcd.ie> <7128698.bmqQpDD1M4@linux-9daj> <2d8f178f-9ba0-2b49-5553-b41a2da72310@cs.tcd.ie>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/FWQF2T1OL-NC46u2lFe4Lllp5Bo>
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: Wed, 13 Mar 2019 01:04:42 -0000

On Wed, 13 Mar 2019, Stephen Farrell wrote:

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

no. RPZ allows filtering answers which would turn into BOGUS for
DNSSEC validating clients. I am waiting for RPZ to be an RFC to
start a bis document that moves the Answer to the Authoritative
section, so you can indeed detect the network's desire for protecting
you, and use DNSSEC to confirm you are not censored without consent.

Paul
ps. I owe the ISE a rpz document review, so it is partially my fault
this is stuck now. I hope to get enough airplane time in the next two
weeks to fix that :)

v2.23.0 | Report a Bug | By Email