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

Vernon Schryver <vjs@rhyolite.com> Mon, 09 January 2017 15:51 UTC

Return-Path: <vjs@rhyolite.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 3BB70129541 for <dnsop@ietfa.amsl.com>; Mon, 9 Jan 2017 07:51:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.202
X-Spam-Level:
X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 wcPHfsj9SvyQ for <dnsop@ietfa.amsl.com>; Mon, 9 Jan 2017 07:51:57 -0800 (PST)
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) (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 30E29129DA0 for <dnsop@ietf.org>; Mon, 9 Jan 2017 07:51:48 -0800 (PST)
Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v09FpVdW091632 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org> env-from <vjs@rhyolite.com>; Mon, 9 Jan 2017 15:51:31 GMT
Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v09FpVif091631 for dnsop@ietf.org; Mon, 9 Jan 2017 15:51:31 GMT
Date: Mon, 9 Jan 2017 15:51:31 GMT
From: Vernon Schryver <vjs@rhyolite.com>
Message-Id: <201701091551.v09FpVif091631@calcite.rhyolite.com>
To: dnsop@ietf.org
In-Reply-To: <F1E2DDCD-6114-43A3-B9FB-831C3AC13F15@fugue.com>
X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZjKNXCZFHl1x8yuYOAqnVurdAII>
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:51:58 -0000

> From: Ted Lemon <mellon@fugue.com>

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

Yes, but there is a reason more important than RPZ for miscreants to
sign their attacks.  It is the same reason that plenty of spam is sent
with valid STARTTLS, DKIM, and/or SPF signatures and why spammers were
the first significant SPF publishers.  A large fraction of their targets
support the silly notion that authenticated strangers differ from other
strangers and that a certificate of authentication from a third party
is a bankable guarantee of virtue.

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

That's the rub.  RPZ has multiple independent interoperating
implementations, is widely deployed, and is in common use because the
customers of DNS recursive server implementators initially welcomed
it and now demand it.  Those customers are operators of DNS resolvers,
especially large operators who pay real money (as opposed to hot air)
for DNS server code, hire people to operate it, pay the secondary
bandwidth, training, bug and other costs, and pay for RPZ blacklists.

Where is the equivalent demand among resolver operators for doubling
the size of DNSSEC responses to contain both the original and the RPZ
rewritten rrsets including RRSIGs, and to pay the implied costs in
bugs, CPU cycles, bandwidth, training, security, etc?  People pay money
for code implementing what the draft describes, but as Ted Lemon asks,
who would pay for the suggested code in resolvers?  If it were free,
who would pay the costs of turning it on?
(You'd also need to convince RPZ blacklist providers to include RRSIGs
in their feeds, because you'd need signatures on rewritten responses.)

Such considerations are why so many users are behind resolvers that
validate DNSSEC but practically no domains are signed.  DNSSEC is a
good thing for operators of DNS clients, both resolvers and stubs, but
it is far more cost than benefit to operators of authority servers.
That's why we have the enduring, very discouraging picture at
http://scoreboard.verisignlabs.com/percent-trace.png
http://scoreboard.verisignlabs.com/

Such issues might also be why some of the most emphatic critics of RPZ in
this mailing list nevertheless send their critiques from unsigned domains.

Note that the vast majority of clients of RPZ rewriting resolvers are
stubs that don't do validation but trust header bits saying that a
resolver operated by a third party did the validation.  I think that's
wrong, evil, nasty, unethical, a Major Human Rights Issue, and blah
de blah de blah, but it's also something no one seems willing and able
to change.


Vernon Schryver    vjs@rhyolite.com