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

Matthew Pounsett <matt@conundrum.com> Wed, 21 December 2016 17:39 UTC

Return-Path: <matt@conundrum.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 39EB8129889 for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 09:39:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-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 3u6IE9dUTB37 for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 09:39:57 -0800 (PST)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 EB2B4129503 for <dnsop@ietf.org>; Wed, 21 Dec 2016 09:39:56 -0800 (PST)
Received: by mail-ua0-x229.google.com with SMTP id 34so22992069uac.1 for <dnsop@ietf.org>; Wed, 21 Dec 2016 09:39:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7gWoc+/0ZXeYukGD/Rbtu5V4bm1eYr++AFmcXOR6m6U=; b=N2/zO1IuxhErUxKuLzutpc3ZvfLTVyNFhzrB4RhmRXihNT/e49lfCNz19flrS6YZEh dYIJJZgR1AVrp3tN7pKXzM4+Cdu3iJTtNPo5ozvkwPC+7rLsp3UWIepz7AmG41kNa8AS V+IuJKTJ0OVdPtby1c+FPGOYQW4MBsu7nTZ0C/qMEgsvxoI8ijVwfanMusIH+fozBukp u4DWrd6BsRPKevX8NqCrPfMu8rEoi2Cx8PuwghrjU5YH0bEkYyXS8eMsEJW/2zGkohKG M1pmGv3WMfO3ZW9UMMiFSXXUe/SndOU71dKVZvUyspM/47K1E3B3EFj8opZUqo1GxhOQ UqjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7gWoc+/0ZXeYukGD/Rbtu5V4bm1eYr++AFmcXOR6m6U=; b=TqRcAScYBDtJmRyI1yIvXHIU+NjNn8a/RElql5jV0zjONSu/zk9wMl8sj+y039etWK p3rTXcVX6Gn6nG6FyPhVPFepLlB1UA5TErkEhxjxEiw+Nfoa+TnTdlX77LAt30n49lrz 2nu/j8kyH3AGee29o61i5uuUCIacgtDtzQEyUhZtPd+SxqmKPlIj1vhA3jWSSLHjs00V a7rzmh/R/o0pO+tkS0rHaIpwOoiBM9Zj5IArlEPwOXOB3M6gb5Qn6aQcAk46Q07Wjult G+tu7MCaBlVbbhSFdIvuTusUlOlK5GIuYXNszzsbQ5iSG8fck4EtUzIplYgRRuZR7/XG Y3qw==
X-Gm-Message-State: AIkVDXK55M67RS1nblBS2oFijvbgkpxphZPS1Xjgg/Z6WynUTGZ6CPeRTXfKb2rBgyPIvKcrSEbZQt0OFbQ3DA==
X-Received: by 10.176.71.89 with SMTP id i25mr3845730uac.31.1482341996064; Wed, 21 Dec 2016 09:39:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.133.135 with HTTP; Wed, 21 Dec 2016 09:39:55 -0800 (PST)
In-Reply-To: <6C982A3A-721C-4094-A04F-059698581321@fugue.com>
References: <C18E2D4E-EE89-4AF6-B4A0-FAD1A7A01B5E@vpnc.org> <5248A099-7E1F-437A-A1B7-C300F917D273@fl1ger.de> <CACfw2hj4VfuqsM-jRpxNc+bWNsUcSid+Y=r9U5jsA-0ZLbLRUg@mail.gmail.com> <20161221.163826.74705202.sthaug@nethelp.no> <alpine.LRH.2.20.1612211047200.13966@bofh.nohats.ca> <CAAiTEH_-LGUkpmPjDRsKpnPhXev1sNdF_2yaVXKmeWMJ7vm_eg@mail.gmail.com> <6C982A3A-721C-4094-A04F-059698581321@fugue.com>
From: Matthew Pounsett <matt@conundrum.com>
Date: Wed, 21 Dec 2016 12:39:55 -0500
Message-ID: <CAAiTEH_LOUhCSRuDNggTK9f1iWw6dCQB2bJQ7FVyYn3MH49KUQ@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Content-Type: multipart/alternative; boundary="f403045f81bc1c8ba505442ea46c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/B1qp4kIgsFniBobROP2R5cQMMkA>
Cc: dnsop <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>
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: Wed, 21 Dec 2016 17:39:58 -0000

On 21 December 2016 at 12:29, Ted Lemon <mellon@fugue.com> wrote:

> Practically speaking, none of these changes are _required_.   The worse
> case scenario is that if someone looks up a malicious domain, you get back
> a bogus answer that doesn’t validate.   The resolver reports "no answer"
> because an answer that doesn’t validate is no answer.   The user sees that
> the page fails to load.   There is little they can do to bypass this, and
> they aren’t likely to have a sense of how to do it, so our job is pretty
> much done.
>

None of those things are required by RPZ, but I believe they are required
by the hypothetical better alternative that a few people have suggested we
should work on instead.


>
> It would be _nice_ if the browser, for example, could get some kind of
> positive, signed assertion that some authority has claimed that the domain
> in question is malicious (or whatever).   This would be good mostly for the
> purpose of transparency, so it’s not clear that it makes any difference if
> it’s communicated to the user: people who care about transparency will be
> able to look it up, and, in particular, people who are interested in
> watching for censorship will have no problem at all noticing that it is
> happening.
>

If you want the browser to receive and understand a signal then that signal
needs to be invented, the DNS servers need to be modified to send it, and
the browsers (and all other applications you want to benefit) need to be
modified to receive and understand it.  This is the point I was making.

RPZ is not the ideal, but it works, and goes beyond being deployable–it is
deployed.