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

Ted Lemon <mellon@fugue.com> Mon, 09 January 2017 15:49 UTC

Return-Path: <mellon@fugue.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 8DFE9129D96 for <dnsop@ietfa.amsl.com>; Mon, 9 Jan 2017 07:49:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 OKpxPzRtyu9t for <dnsop@ietfa.amsl.com>; Mon, 9 Jan 2017 07:48:59 -0800 (PST)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 DD241129D91 for <dnsop@ietf.org>; Mon, 9 Jan 2017 07:48:58 -0800 (PST)
Received: by mail-qt0-x232.google.com with SMTP id x49so73163061qtc.2 for <dnsop@ietf.org>; Mon, 09 Jan 2017 07:48:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sRIZdwG2khASqHrFVoVAucL6dkJTG7WAxClc4YNwPOo=; b=j+TCYpwCzIQCga0cdllrJMkG+UfCldSiT134shiUJ/+KU9FW/sIbZvJshaVoqj+T22 bJT0dVGx/Q7rtAd9et/UYXXHWwPsS60S20WrZZCR0qejbUSQJrBClt/wgUN4xz7dfqAt XIXxbUSrSiCzOuHzhH2XXCKPD2IolxxP4pOVLrbIKJP/gTQDh97Un8EgGMbw09JYndSa RuBEwOEEanXdYxl/yZm0CIop7mDmQv30qqfeo2TMLkmc6FaBBuILeHozhQnCX58FvzHj Uw/7jHMhSVK64es9DPAU6oXB3kNbi9BykvbwI+h9NVNTKwKDUsC99mocyp/SM3noB8oG slcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sRIZdwG2khASqHrFVoVAucL6dkJTG7WAxClc4YNwPOo=; b=pDcLwZy7CUB4s2VjEO+XOUwjW/RNDRgw/RQwBYOON8AMRwUmJVoUsqyTJIzn0y26bd o285bTllEyi0Dz9DKLK31eJryntu5S4jI5rpglZYupTvAFDrXU0+Nj7qJKVtpAPFAn0W Rh0hbhRPa6VMaEH7xVAsRTJpHw1JU4JjftAy6otL4cmPtSvhFKhN7WuWjgbYFq4oyDuh Ubm22j145VHr4EVUWsL3Jbexj3jf4KkslI2DsCj4miqvHTbAvZCFZXSB0cSjMFfWk1WG rhZvboQbPvA3wpYSZ4taRj+c2FMVbWYk2F4+r9H/BMjp5LilNGkZayoMZIYRurGfw+U8 1RAg==
X-Gm-Message-State: AIkVDXL3/bmyP4ZPq7PFncynCpDCYtCrhGJ+BQ7UMlwPT3z7RAOd4g3HjCNFbHTPX6xmGw==
X-Received: by 10.200.55.37 with SMTP id o34mr22584411qtb.48.1483976937887; Mon, 09 Jan 2017 07:48:57 -0800 (PST)
Received: from [10.0.20.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id w138sm1281995qka.27.2017.01.09.07.48.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 07:48:56 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <alpine.LRH.2.20.1701090959570.28120@bofh.nohats.ca>
Date: Mon, 9 Jan 2017 10:48:55 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4634DCAB-0BA3-4B21-B3F9-C66F81CE50A9@fugue.com>
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> <alpine.LRH.2.20.1701090959570.28120@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/U7NZjdw068fqDaZ6lLWulo1Vzv4>
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:49:00 -0000

On Jan 9, 2017, at 10:14 AM, Paul Wouters <paul@nohats.ca> wrote:
> 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".

It remains the case that most service providers at present appear to believe that PKI is enough, and they don't think DNSSEC is worth the trouble.   Like you, I look forward to the day when this is no longer true, although I don't look forward to the attack that changes peoples' minds about this.

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

We are talking at cross purposes.   We agree that the DS record proves ownership of the zone.   But it doesn't provide any more of an audit trail in terms of zone setup than does an NS record.   In terms of accurately identifying who set up the zone, it is completely useless.

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

Again, not the point I was making.   Of course we want the resolver to do validation.   The question is, do we want the resolver to have code in it to validate who did the RPZ block.   I think this would be a really bad idea, and would be seriously damaging to human rights.

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

You are thinking like a IETF geek.   The average end user will know nothing of this.   To them, it will simply be the case that their computer says "this is a malware site."   They will not see the audit trail.   It doesn't matter if the ACLU can detect the attack: they could have detected the attack without the signature, and most likely had a clear idea of who did it.

What matters is that we have no provided a way for malicious site operators to lie to end users, who will not be able to detect the lie.  To be clear, the lie is "I am authorized to block zones on your behalf."

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

We disagree here.   I have seen way too many people screwed over by malware to think that preserving a perfect uncensored view of the DNS is more important than blocking malware.   As long as we can tell that we have been given a filtered response, I think we have the best possible compromise, and if sites are not willing to put in the effort to sign their zones, that is their problem.

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

If that IP range is being operated by a malware site or for example is going to redirect all of my traffic through a country that is sniffing my packets for intelligence purposes, then yes, it should be possible for the infrastructure to prevent the broken route from being installed, regardless of whether or not it has been signed.   This is the distinction between authentication and authorization that we all know so well: just because something is _authentic_ does not mean that it is authorized.

Taking that very clear distinction and turning it political is not helping anyone.