Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

Paul Wouters <paul@nohats.ca> Mon, 09 January 2017 15:14 UTC

Return-Path: <paul@nohats.ca>
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 E3382128AB0 for <dnsop@ietfa.amsl.com>; Mon, 9 Jan 2017 07:14:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.199
X-Spam-Level:
X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199] 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 Pnqc-ELAe1aH for <dnsop@ietfa.amsl.com>; Mon, 9 Jan 2017 07:14:36 -0800 (PST)
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 BEDCE129408 for <dnsop@ietf.org>; Mon, 9 Jan 2017 07:14:35 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3txzGJ4qD8z1rr; Mon, 9 Jan 2017 16:14:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1483974872; bh=fh2FsSV8HMe33vvelA61Fd8IfTcf+zKnBOkG+v0dlxE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=f+waof7/KyOs2gXRv2arrIFW/mbv9+P2VjTN4wOs7hoSsmAMoIwrARHgPdAJzR2YO 3UtfHU61FpE3zkpQsJlPY+Om4ughL/Foek1xQm3DSs8On6IOG0N/zIEAKvKR8wTq7E PzZpFbk1G/FA9hVubPT840AezNpOJBQ6NokQaqnM=
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 895oBbWXYSWq; Mon, 9 Jan 2017 16:14:31 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 9 Jan 2017 16:14:30 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id B4CE6CA34C7; Mon, 9 Jan 2017 10:14:27 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca B4CE6CA34C7
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9E5A540D7281; Mon, 9 Jan 2017 10:14:27 -0500 (EST)
Date: Mon, 9 Jan 2017 10:14:27 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: Ted Lemon <mellon@fugue.com>
In-Reply-To: <F1E2DDCD-6114-43A3-B9FB-831C3AC13F15@fugue.com>
Message-ID: <alpine.LRH.2.20.1701090959570.28120@bofh.nohats.ca>
References: <20161229160603.GA10627@odin.ULTHAR.us> <20161229163826.34758.qmail@ary.lan> <20170107225456.GB10627@odin.ULTHAR.us> <7B87D311-5132-4D1D-9684-B09FE2CCA3B3@senki.org> <alpine.LRH.2.20.1701082342250.18316@bofh.nohats.ca> <F1E2DDCD-6114-43A3-B9FB-831C3AC13F15@fugue.com>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2lEPOawpXTtG8XxdBdX8qzmCeeQ>
Cc: dnsop <dnsop@ietf.org>, Barry Raveendran Greene <bgreene@senki.org>
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 09 Jan 2017 15:14:38 -0000

On Mon, 9 Jan 2017, Ted Lemon wrote:

> On Jan 8, 2017, at 11:49 PM, Paul Wouters <paul@nohats.ca> wrote:
>       It is actually the other way around. If an end-node performs DNSSEC
>       validation, it can only see RPZ modified answers as an attack. It is
>       in the interest of RPZ to give such clients the confidence that the RPZ
>       produced answer is not an attack but a handbreak action in the user's
>       interest.
> 
> 
> I think you missed what Barry was saying: you are correct that an end-node that performs DNSSEC validation will see RPZ on a domain that is signed as an attack.   The point Barry is making is that this only
> matters if they sign their zones, and they won't, because doing so produces a clear audit trail leading back to them.

Apple is getting ready to drop port 80 support. unsigned/unencrypted
transports are dying. I hope we are moving to a word where DNS without
DNSSEC will also be seen as bad. So yes, I am assuming in the future,
attackers will have to sign DNS and that domains without DNSSEC are seen
as "rogue domains that don't have clear audit trails".

> I think this is actually not true: why is a DS record any more of an audit train than an NS record?

Because it proves ownership of the domain. My nohats.ca DS record cannot
be modified by the UK ISPs forced to filter my domain. But they can
spoof NS records. See the recent discovery that Heathrow Airport runs a
MITM TLS server on torproject.org. Do we want them to run RPZ where they
can disappear torproject.org alltogether? No. Do we want them to run RPZ
to prevent travelers from getting malware installed? Yes.

>   Nevertheless, let's be clear on what RPZ does and does not do.   I think the main reason attackers won't
> sign is that it's too much trouble, and provides no real benefit in the presence of an effective RPZ block.

It's fine for "attackers" not to sign domains. That is not the point.

> Your point here, that in order for RPZ to function in the presence of widespread DNSSEC signing, there has to be some mechanism for authenticating RPZ answers _as_ RPZ answers, doesn't seem clearly true.   It
> may be perfectly functional for RPZ answers to look like an attack.   But it's certainly worth considering, and has been talked about earlier in this thread.   The question is, does it make sense to add code
> to the validating resolver to detect and validate an RPZ block, so the user can be informed that a block occurred, and who did it?   Would people actually code this up?   Would it be better or worse?

To me that is quite obvious "yes". If we allow the DNS protocol to
randomly rewrite DNS, then why _do_ we have DNSSEC?

> To me it seems like a bad idea: it's a larger attack surface, more complexity, a single point of attack: if I can compromise the RPZ keys, I can make an attack look like protection to the end user.  

Excellent! It means if the RPZ/DNS provider screws up, they are
accountable. And they will properly maintain such systems that
are golden opportunity for hackers to compromise. Also, the
danger you are describing "I can make an attack look like protection to
the end user" is exactly what the current RPZ spec already allows!
I guess you really meant to say "a compromised RPZ system can unblock
a malicious and previously blocked side". Well yes. You are describing
a weakness, not a strength, of the RPZ solution.

> Ultimately, if we were to specify a solution for this, I think we doul actually be doing something harmful to human rights.   Isn't blocking the domain enough?

Just blocking the domain is "too much". And in my view that _is_ the
human rights issue.

If we change this discussion and replace DNS and DNSSEC with BGP and
RPKI, would you still think it is fine to allow random parties to
change BGP announcements in a world of secure BGP so that users can
be prevented to go to certain IP ranges?

Paul