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

"Wessels, Duane" <dwessels@verisign.com> Mon, 05 March 2018 22:31 UTC

Return-Path: <dwessels@verisign.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 EEA93127010 for <dnsop@ietfa.amsl.com>; Mon, 5 Mar 2018 14:31:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 WEwP4_xj68O3 for <dnsop@ietfa.amsl.com>; Mon, 5 Mar 2018 14:31:10 -0800 (PST)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 8FA7F12DB70 for <dnsop@ietf.org>; Mon, 5 Mar 2018 14:31:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2998; q=dns/txt; s=VRSN; t=1520289065; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=9MeyCZnfAFISsKXLIyteoprYDN+fddHQ0BsUWGpQ0Jk=; b=a3KOrwzlACLK9+wy5r0qmJMhRQtj/AEjPTG8cgZYZ6RkIWJG24b9GKGg +a/1zZH4tcrbfSShEov+8YIPxHET+djJDeTpUmKYSbCEqT94PXYHBWVGh vGaaMyj10e3WWTlmik3opMup5++tV631JMkQJ5Thse1XaTjvXHrr6hRp5 +W2/Nit1x2TT6zoOI8OAzZkdluk7bXL30BeTQl3K8dwbwuwEH92hd/0GP fkemJcn+Rz/ci/WdL3NcqE7Wf9ho3yQkagnL8gMxzJZjaCdNzWZM4Fqh6 RVYQVmGmC+83ULd7z8HFbK8QKtScgE3uOKMdhvR8g5d4jEmygZcwQqolt Q==;
X-IronPort-AV: E=Sophos;i="5.47,428,1515456000"; d="scan'208";a="3816430"
IronPort-PHdr: =?us-ascii?q?9a23=3AAv8LLhHfOE/EB8RC8kA4Cp1GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ7zpsWwAkXT6L1XgUPTWs2DsrQY07GQ6/iocFdDyK7JiGoFfp1IWk1Nou?= =?us-ascii?q?QttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBAj0OxZr?= =?us-ascii?q?KeTpAI7SiNm82/yv95HJbAhEmDSwbaluIBmqsA7cqtQYjYx+J6gr1xDHuGFIe+?= =?us-ascii?q?NYxWNpIVKcgRPx7dqu8ZBg7ipdpesv+9ZPXqvmcas4S6dYDCk9PGAu+MLrrxjD?= =?us-ascii?q?QhCR6XYaT24bjwBHAwnB7BH9Q5fxri73vfdz1SWGIcH7S60/VDK/5KlpVRDokj?= =?us-ascii?q?8KOT4n/m/Klsx+gqFVoByjqBx+34Hab46aOeFifqzGeNMWWXZNUtpTWiFHH4iy?= =?us-ascii?q?b5EPD+0EPetAoYXyp0UBrQClBQayAOPv0SdEjWL4060nyeshFx/J0AI9FN8JrX?= =?us-ascii?q?vVosv6NLwJUe+ryKnI1i7Ob+1I1jfn6YjIaREhof6KXb5qbcXRzkwvGhrDg16N?= =?us-ascii?q?qoLlJyuY2vkRv2SB8uZtV+yih3Q6pwxxrDWj3Nkgh4bGi44N11zI6T91zJs3KN?= =?us-ascii?q?GkUkJ3fNGpHZhKuy2HNIZ7RN4pTXtytyYg0LIGvIa2fC0NyJs62RHSc+eHc42U?= =?us-ascii?q?4hL7U+aRPCt4iGpleL2hgxay9lCtxfbmVsmyzVpKqiVEktzWuXAM0xzT7dWHSu?= =?us-ascii?q?dh8ku8wzqPyR7c6vtFIUAvlKrbJJghzqQsmZoUtETPBi72mEPog6+Kbkgo5/Sk?= =?us-ascii?q?5/76brjkqJKQLZJ4hwHwP6g0hMCyDus1PhALX2eB+OS80LPj/Vf+QLVPlvA5j6?= =?us-ascii?q?fYv47BJcQAuKG5BxRV35096xmhFTem0c8YnXgILFJDYh6Ik4/pO1TWLPDiEfi/?= =?us-ascii?q?m0iskCtsx/3eI7LhBI7NLn/bkLr6fLZy9VJcyAQpwdBY/ZJUBakLIOjvVU/pqN?= =?us-ascii?q?zYEhg5PhS7w+bmCNVwzZkRWXqJAq+YLKzeq1mI6fwzI7rEWIhAlzv6JfZtx+P1?= =?us-ascii?q?kXg/0QsSfKmB1IMRaXv+GPl6dRa3e33p150+HHwRsw4lCKTGlVSEXHQbM3qtUr?= =?us-ascii?q?kn6zUgIJyrF4bYR4+rxreG2XHoTdVtemlaBwXUQj/TfIKeVqJUZQ=3D=3D?=
X-IPAS-Result: =?us-ascii?q?A2GNAABrxJ1a//SZrQpdGQEBAQEBAQEBAQEBAQcBAQEBAYM?= =?us-ascii?q?fgi8Kg0qKJI96EYEFlDSCFQqFMAIagno0GAECAQEBAQEBAgECgQ+COCKCSgEBA?= =?us-ascii?q?QECASMRRQULAgEIDQEKAgImAgICMBUQAgQOBYUTqQeCJ4FAgzKDcoIrgQ+EHoQ?= =?us-ascii?q?GgWUpgwSFC4MhMIIyBJpiAwYCn3WRKAIECwIZAYEuHoILcBVkAYIYgjAdgXt3i?= =?us-ascii?q?1eBGAEBAQ?=
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id w25MV3fI031384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Mar 2018 17:31:04 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Mon, 5 Mar 2018 17:31:03 -0500
From: "Wessels, Duane" <dwessels@verisign.com>
To: Geoff Huston <gih@apnic.net>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt
Thread-Index: AQHTtNGkY5DafpSeRUu0OzFQArQmMQ==
Date: Mon, 5 Mar 2018 22:31:02 +0000
Message-ID: <2C0BDA4D-E1E4-48A1-AB54-EFF31F55EB7E@verisign.com>
References: <151984683961.5212.6854317117587193083@ietfa.amsl.com> <39567D9A-312D-42A8-A108-C8F7EE249668@verisign.com> <99AB422F-C607-412B-BC5C-A1DE17CD2393@apnic.net>
In-Reply-To: <99AB422F-C607-412B-BC5C-A1DE17CD2393@apnic.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <CC5BA60535111A40A456269B34A8E957@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZkeTN-r8FgSUdhcGF-NlGl1xr2M>
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 22:31:12 -0000

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

DW