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

Ted Lemon <mellon@fugue.com> Mon, 09 January 2017 14:19 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 60253129CDC for <dnsop@ietfa.amsl.com>; Mon, 9 Jan 2017 06:19:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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: 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 vBtjPXMSfffv for <dnsop@ietfa.amsl.com>; Mon, 9 Jan 2017 06:19:42 -0800 (PST)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 09825129504 for <dnsop@ietf.org>; Mon, 9 Jan 2017 06:19:42 -0800 (PST)
Received: by mail-qt0-x22f.google.com with SMTP id x49so70604594qtc.2 for <dnsop@ietf.org>; Mon, 09 Jan 2017 06:19:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kDuMtucPTWzz8Yh51mMTzwfvd/wTeuIUPaKQca4yCuM=; b=uNcTz/qWhJV0KpVVNfiqBxEe0SoNw+ycht5KaeT20b9rh7xeKFobeUIHMC0bAcbnzT bQiuS8HpMxhHZcp5jblgr183nB0h6qOdPOfZs0Ai8+XI2HC0R8ix4oQ79L4Jaapmz9mq ym1/DJHH42DVbi8AG4l6eqXX8RWI2ExTttzWIKeF1pN9vHdG/bdKEg1Exo9cOQTj5vz/ N41yG2+fa4WwNW2jL0sFM2s/hkuCyTHdn/ld3lMHea29LLIo2U56pHTD/8kmRfOOU9cn eQYbGSUq0yEF6fllMYDki+5pdi3H+0S3n4hYZXyFCPVvme8Eq5Dd6Zbts8NwC1ENZocJ 553A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kDuMtucPTWzz8Yh51mMTzwfvd/wTeuIUPaKQca4yCuM=; b=KapwvyT4aKO50d16g0o4qzNnjVAxLH03GszjyJeEq3JJLO6HxpLnvLSSiHOO4zHRkh 77dO/BE42Z2JVGGMvfNn9AgBbFGmRE5Ea18H/I0zI4md+0TkPfB+lNeRKSSUDcE7oFX0 JefeNfGfsGUcVIpprjvyBjcIxPGOwD5cZ8Ak8DSBv2fbiV8miZBwVtwq3pMVceYLfmmT sNYfv36gCXLF9SMVKq1eZiTq+AVR+CLlm5r7dk1fs93uLmBSMclfMBOSfcFRd6avd7TE FwS/56CiosmR1JOChnr6RGrs19aV8euAIgeNJ3qww/xfo4HevEksaq6K1TOXT+jeky4i yr0Q==
X-Gm-Message-State: AIkVDXL0Vt6h3VTRm+h1lS10xpEW66wVho36fG5Sywj5B7sET+TGm4YbV/eaWxbxNFnzZw==
X-Received: by 10.200.37.241 with SMTP id f46mr82040020qtf.164.1483971581132; Mon, 09 Jan 2017 06:19:41 -0800 (PST)
Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id i125sm434316qkf.24.2017.01.09.06.19.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 06:19:39 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <F1E2DDCD-6114-43A3-B9FB-831C3AC13F15@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_35AC6C55-3172-4B4A-8765-440030C0AB1F"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Mon, 09 Jan 2017 09:19:37 -0500
In-Reply-To: <alpine.LRH.2.20.1701082342250.18316@bofh.nohats.ca>
To: Paul Wouters <paul@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>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GqRdOKkINRjcbApkT4PjIn757tA>
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 14:19:43 -0000

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.

I think this is actually not true: why is a DS record any more of an audit train than an NS record?   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.

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