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

Ted Lemon <> Wed, 21 December 2016 17:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82F78129873 for <>; Wed, 21 Dec 2016 09:47:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jVhHYlUcLVcV for <>; Wed, 21 Dec 2016 09:47:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8A701293DB for <>; Wed, 21 Dec 2016 09:47:50 -0800 (PST)
Received: by with SMTP id u25so78515648qki.2 for <>; Wed, 21 Dec 2016 09:47:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ddncIc/nGh/p4VY1/spZSR4PI+XHuiEQe55sVe6NThk=; b=qaSjlt+H4MqCyXMkF3YO4BCAym34r3DUQAQ+bQ7pY5JFinEicR/8nJan+NxWVDddbd pydDcpjM5aWCGWeU1apPWn1ASvztkMa5cOwj8hqiKVOX7+gnvj2vgIadHS6/0cmd5w/q ZSBZSmQt3Bcp0uln2zfQajEOv1JUKo2BST2VGha9ruYgWIbkQixHBz9ax8lHwti4ZSdg UmzA4QduuSUxWcoDgVwi85/uEJAum3Vm4gReXwspSrRz06YTRmY3oz+j7ujUXEjNeJPj tW3i1JHY3MBMw4j1R4V4pr63x2tBBIUsu1cP1i5D9lDGlG/3jT+WgfUclr8xG2AXv2qN fsPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ddncIc/nGh/p4VY1/spZSR4PI+XHuiEQe55sVe6NThk=; b=lHKLhzppJdgIxfcpJm5syhCDmamxz+czt1Qb9HCHIzhchsgJ6E7VWhZt/3ej2a8bZo HCn0Z2HnwA3Yux3swQfyVbqJuvvRQVMHppdlskcYk75Uhgw9z8CZjc8Mmxae+wcnS/w+ ZcsXauNwUDhRqpesJdmmzSUqqQcvhassBGkvo2urHfUXTPk3sbcAjdHk2IvPep3B+B+M dt6CArX145rpmsKXeMbZ8uWxJetNQjx2cZKd10ouobCukFwX/w4b8j1PQ6ay3VMaB/je wKKj8uOUa0NS6W/E78LQ14COOZ2vGI+jwHNPX+GbjU0HtOUW3GG/0TFb3oyE4ItiyuhP G3Dg==
X-Gm-Message-State: AIkVDXLEE1idN14HrMLhNc4AJpMRHL+QTsDVBdcm08ty9WD2LWXobXG2SwgIxTfWoZVJ/A==
X-Received: by with SMTP id 128mr5868818qke.281.1482342469958; Wed, 21 Dec 2016 09:47:49 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id y22sm15996048qtb.26.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Dec 2016 09:47:48 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7610C1E7-AED2-4378-8373-6957E97DF0C3"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 21 Dec 2016 12:47:47 -0500
In-Reply-To: <>
To: Matthew Pounsett <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: dnsop <>, Paul Wouters <>
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Dec 2016 17:47:52 -0000

On Dec 21, 2016, at 12:39 PM, Matthew Pounsett <> wrote:
> 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.  

To be clear, there is no real alternative to RPZ in terms of providing protection.   We could provide annotation in RPZ, and that might be useful in some cases.   But ultimately if a domain is malicious, you _have_ to block it by not providing an answer.   If you do not, only those devices that implement the new protocol will be protected, which is to say we will be failing broken, not failing safe.

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

Yes, correct.   I proposed a draft in tls to do this after the redirect has happened, which I think is useful, but does not solve the problem of signaling when DNSSEC is available: <>

If we wanted to account for DNSSEC and provide signaling, I think the signaling would have to take the form of a signed EDNS0 option that signaled similar information.

In the draft I’m referencing, it was my intention to provide a set of values that could be returned to indicate what has happened.   I think it’s a bad idea to provide anything more than that, because for example if you return a text string, that becomes an attack surface.   You can use it to trick the user into bypassing their security settings.