Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt

Mark Andrews <marka@isc.org> Mon, 05 March 2018 23:28 UTC

Return-Path: <marka@isc.org>
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 CBB7A126DEE for <dnsop@ietfa.amsl.com>; Mon, 5 Mar 2018 15:28:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 4BVUrDUOrLBm for <dnsop@ietfa.amsl.com>; Mon, 5 Mar 2018 15:28:05 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 513D4120227 for <dnsop@ietf.org>; Mon, 5 Mar 2018 15:28:05 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 68C883AB007; Mon, 5 Mar 2018 23:28:02 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 523CD160088; Mon, 5 Mar 2018 23:28:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 35CBE160087; Mon, 5 Mar 2018 23:28:02 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3TsYSLgMRTO9; Mon, 5 Mar 2018 23:28:01 +0000 (UTC)
Received: from [172.30.42.66] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id D72A5160083; Mon, 5 Mar 2018 23:28:00 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <2C0BDA4D-E1E4-48A1-AB54-EFF31F55EB7E@verisign.com>
Date: Tue, 6 Mar 2018 10:27:58 +1100
Cc: Geoff Huston <gih@apnic.net>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F8942F63-B813-4D8F-9841-C63513C8355E@isc.org>
References: <151984683961.5212.6854317117587193083@ietfa.amsl.com> <39567D9A-312D-42A8-A108-C8F7EE249668@verisign.com> <99AB422F-C607-412B-BC5C-A1DE17CD2393@apnic.net> <2C0BDA4D-E1E4-48A1-AB54-EFF31F55EB7E@verisign.com>
To: "Wessels, Duane" <dwessels@verisign.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/r9WY7Rl1OXvKby8OFv1IA_aRzuY>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 05 Mar 2018 23:28:08 -0000

> On 6 Mar 2018, at 9:31 am, Wessels, Duane <dwessels@verisign.com> wrote:
> 
> 
>> On Mar 3, 2018, at 2:32 PM, Geoff Huston <gih@apnic.net> wrote:
>> 
>> I guess that the knowledge that resolver X trusts a key with a hash value of Y does not leave me much the wiser in terms of exploitable knowledge about the (in)security of that resolver.
> 
> If there is a key or algorithm compromise for key Y then that seems like useful information to an attacker.
> 
> 
>> 
>> 
>> Aren’t we getting into issues of DNS privacy here rather than the sentinel per se? Its not as if the sentinel process calls for any change in the DNS query response mechanism. There is no forking off information to third parties in any form in this draft - the user agent asks a particular query form to its DNS resolvers and the user agent will get a response. As far as I can tell, in the same way that the DNS itself admits third parties to look over the shoulder of DNS transactions in every other DNS query and response, this is no different as far as I can tell.  And in the same way as various DNS privacy mechanisms make it harder for third parties to eavesdrop on user activity, this is no different, and the user agent can take the same measures to attempt to increase the eavesdropping degree of difficulty on sentinel queries as much as any other DNS query that the user agent may make.
>> 
>> It seems I must be missing something here that has triggered your concerns Duane - could you explain them in a little more details?
> 
> 
> No, I wasn't thinking of eavesdropping.  I'm thinking whatever Geoff can do, a motivated nation state can just as easily do.  For example...
> 
> The country of Freedonia decides it doesn't trust the ICANN-controlled Internet and goes off and builds its own root server system and signs its version of the root zone with its own set of DNSSEC keys.  Persons and organizations operating in Freedonia are required to install this trust anchor and remove the IANA trust anchor.  kskroll sentinel provides a way for Freedonia to monitor compliance with this policy.  They can use known techniques (ads, embedded javascript, unique URL hostnames) to learn which keys are in the trust anchor set for resolvers/devices within (and even outside) its realm.

And recursive servers will just be modified to lie to hide non compliance.  Also how do you prevent there being minor differences in the zone content which are identifiable?

> DW
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org