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

Geoff Huston <gih@apnic.net> Sat, 03 March 2018 22:32 UTC

Return-Path: <gih@apnic.net>
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 F2AE412025C for <dnsop@ietfa.amsl.com>; Sat, 3 Mar 2018 14:32:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.onmicrosoft.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 TFfpXeko8xTe for <dnsop@ietfa.amsl.com>; Sat, 3 Mar 2018 14:32:17 -0800 (PST)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0043.outbound.protection.outlook.com [104.47.124.43]) (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 A24A11200E5 for <dnsop@ietf.org>; Sat, 3 Mar 2018 14:32:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rrCANmxwi3SUVQKhflzmkK7Fh2aWrsNqMne5rvZSnbE=; b=Rjg3UfagPRmYtWGw81F4RXtIadSAtdQyEYIpoxc/SwqczGMG1OfQBCUWkLobizVnCW8YJQx2fzUOZXH2PNhFymvq44m2FuJMSGgroTqMiYJljRyKNHiTBS6Ixvnz8l0mJzXcc5T/XxG5AuVt5gVUj2YP6yxfuvGbtbGerLL4kZw=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net;
Received: from 2001-44b8-1121-1a00-c093-7d6e-831a-1cb2.static.ipv6.internode.on.net (2001:44b8:1121:1a00:c093:7d6e:831a:1cb2) by SIXPR04MB0698.apcprd04.prod.outlook.com (2a01:111:e400:51ee::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Sat, 3 Mar 2018 22:32:11 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <39567D9A-312D-42A8-A108-C8F7EE249668@verisign.com>
Date: Sun, 4 Mar 2018 09:32:00 +1100
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <99AB422F-C607-412B-BC5C-A1DE17CD2393@apnic.net>
References: <151984683961.5212.6854317117587193083@ietfa.amsl.com> <39567D9A-312D-42A8-A108-C8F7EE249668@verisign.com>
To: "Wessels, Duane" <dwessels@verisign.com>
X-Mailer: Apple Mail (2.3445.5.20)
X-Originating-IP: [2001:44b8:1121:1a00:c093:7d6e:831a:1cb2]
X-ClientProxiedBy: HK2PR0401CA0020.apcprd04.prod.outlook.com (2603:1096:202:2::30) To SIXPR04MB0698.apcprd04.prod.outlook.com (2a01:111:e400:51ee::21)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 5c3abba7-775b-4356-773d-08d581569c69
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:SIXPR04MB0698;
X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0698; 3:n7CEASCpeHo/tzHJeU3rBP5powZF/OUSR7uJiTaQ6kjWsaa02IDezMpOZMWMhpF9cajLUjR//3GSwuGjXG33+APxJxHI8JNPUJnqVVjDVeVSt1pKKhtJ+vlGTajp4miITJAENKklpUGTKh0hpaVhIskplzjBVcl0VfKGs8Wm2w9Vuq9jehugeV3dUVicbs56/8cxzIiwHrfKFuLx1f4RGhwl9It6fE5gVwWjXgedRJWuqs5fGZa2+APeKTvP3Crv; 25:YDLGvblb+pV2rB4YadBLMIpN+sNAeMBruy8Z4Cgrl8nvVAWd+rsYFNTfcVq7EvgPEsNxLEgAMbvFAwjazLBZQbrzTuFFYeJXwY2znUxVW23GfreCqpIG6HdPCJuZsw86UyKXAprXVUfZ8V1UIXp6e/IhudqE/QfwCLV0UQ37/vbH3jKigsA06osJKQXTKSqAf/3EsUXrN0qvtwuUI4/dcOiL1K+lnmdQyzfcbGbkyvtITBONoL6aLwswyc2EcPtrv25gp6cOPSbxtc3K0DBsEQIhPBU8MJSpTOy5M1c03qTHdkFf5TB+mHLSEDKBr/cbR9kV3GaKhOgQSQH+9lz20A==; 31:Z+MxkN6W215l5jS7si9il56gyNWRLsFkpbngnMytvGf35eCKfIGpUj7VL4hLI+fiBnkMxiIw7PkCWuKNAqnAjZHBFoOswRFtowKZBOQnc4Xp8E9vJff3yTfK2+ZYG0e0oAj2wLki5jN2Yr2wXtVEveAZdUyQVlUR+edboAy2qUgO4QWBCt7+wVowL0nTUN0BDCI4KhLZGT1MUkSCVHtNoYH1pwxhC6/yHsaO8OJUeyA=
X-MS-TrafficTypeDiagnostic: SIXPR04MB0698:
X-Microsoft-Antispam-PRVS: <SIXPR04MB06989C1B80024F4375C43864B8C40@SIXPR04MB0698.apcprd04.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(192374486261705);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(3231220)(944501244)(52105095)(10201501046)(93006095)(93001095)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:SIXPR04MB0698; BCL:0; PCL:0; RULEID:; SRVR:SIXPR04MB0698;
X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0698; 4:CZABMoItso2U2NGUcwAZe0PUxwNN1ssG2OWSDssJ6uX/hOk6kxzwFFJNNWmPSIC++btuha2/q3pYlfjzRMUgCF39aUC9By1K+ocK1o9Vc6oStnVCVU/acOcbrVX/iDaJBG5CldYdL7Xh8A4DRGAi/pnjetFg9UHLa/0bTdV3ECmFu+XEYk2TUtceOHV5V5NGJ76oBiqCO+6eIis8CeX5fgn656IRCOPmKIdeNdUEsop/fRNjrzqcNIcOSGz0IxfWjW5yJsULJblcXFm1/sF5165DwSWWBZ1/v3AES0KFtdpMeLxnl2rIcfzvHgDTcmVy
X-Forefront-PRVS: 0600F93FE1
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(39830400003)(366004)(39380400002)(346002)(376002)(396003)(51914003)(199004)(189003)(8676002)(316002)(16526019)(81156014)(81166006)(305945005)(86362001)(8936002)(6512007)(6246003)(6486002)(53936002)(50226002)(8746002)(229853002)(186003)(6916009)(2950100002)(6666003)(59450400001)(68736007)(6506007)(386003)(83716003)(36756003)(5660300001)(7736002)(53546011)(76176011)(97736004)(105586002)(57306001)(478600001)(33656002)(2906002)(6116002)(52116002)(52396003)(2486003)(82746002)(52146003)(25786009)(23676004)(46003)(50466002)(106356001)(4326008)(47776003)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:SIXPR04MB0698; H:2001-44b8-1121-1a00-c093-7d6e-831a-1cb2.static.ipv6.internode.on.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTSVhQUjA0TUIwNjk4OzIzOmt1N09nNmdBbCtmSE1Oai9GU1lXcW1SaDI1?= =?utf-8?B?RUJLbWdRdWt6Q1hsaHBML0dBZjEzTlhNWG55cStEVGtvWXh5dkEvUGg2b3Rq?= =?utf-8?B?TGtSOUJCUFNrNVdLdzRIRmo0M1FZY1VsQXQwcTVZRldvYmdjU0kxUGZmZStH?= =?utf-8?B?NUxvN3ZXY05mVTRaM0tGMTF5TXRyZjhpKzF6ckFBUnUvaWk4VGllTllWK200?= =?utf-8?B?ZDBiMGkvVkhKM0s1WVo2dUJYYVpDTUtlajdmcXlucVoxUDhvSGZRbkJ1REpp?= =?utf-8?B?TUhqZ3dEWEpzUnpaeGZQSnF4OFZsTjV0V3NQM1prV2xtckNtb09XZGtrOGV3?= =?utf-8?B?R3pwMDBwZFloQlVTOWdLVGI5SGlUTVdhOWg4eDJwNjFFeTk2S2twOEZJWS9n?= =?utf-8?B?M0hLTnc3TzdhM1gvSkNFakVKNXlJb29LUldWdXgwVTN2V0QzZlErYzgrWTVS?= =?utf-8?B?Y04vUHVubEZVVHU3MTdxcWwxakJMcGY3UkF4bmR2bWkzL2srN0RUU1FiUEp5?= =?utf-8?B?dUJYbUl3a2VqeUZEM0oxSCs4S2xabmp2d3hVdldEdXYvZzBpOC9oYXVydm9j?= =?utf-8?B?Y1lsTXFYNnQ2Y2FheTRFekNzTDVFdGoybXdUcVc1WWFHVXpZay8vbTBrVHdI?= =?utf-8?B?YVg5UG1GQUtBc1dSci9ybzlzRi9VZFMyM3pXODJRRVNDTm5zS0ZsOW5BNVZv?= =?utf-8?B?U3hNNUV3cWFLSVZIc1RCbmJNRFpDaHk0VmRwQUsweWFpUDlNeldEa1N4Vno4?= =?utf-8?B?YnZ3QUQ2YmZPUGVLanEwdEdUZTJpbmJRWWZ4d3FkZEdDanhPcXFmOWI4cHVP?= =?utf-8?B?ZjYyWEkzUW1FRmluUUl3NEZlN3g0M2l3SDlHcHVROUIrMUdQQ2w2MWc3eDJR?= =?utf-8?B?QmFVNHM2R1lUcFpidHFXQ3cxODdvam9nWkhSTjEwd0dhV2pDSmJGZ0J1NmMx?= =?utf-8?B?aDdndnlnU2ZNSHF0eGZyUWZkbElOUVVVcjVRV21jRjVXamp5ckR5WUpNUXVU?= =?utf-8?B?a2dBcFFLMG9EbDc2bHRHRnJkVWtXWURjc0hOUEZwUlVOTUxNblE1cVNkR2to?= =?utf-8?B?ZnVkbUdyU1pHaEI5UkNWRklKMGVrMWhGOHZYTHNPV1dKNlJUKzhJSkFYcVpz?= =?utf-8?B?UFFGQUR0Vkk3ZjFqZDlMaUpMZ2E0b3AzbDB0azBTZThyMlp5OVkzenRJUjM2?= =?utf-8?B?YTRuYVZNOU5zRDdzeFpzK2pUdGZFRkdQUFF5eWJLbUFWU055QlBjQmwyWGJS?= =?utf-8?B?d1d1WVRlWUZvenR1ZGZjUlNZZ0lVaVduU285cmFkTVVQazhwMUd1WXUzeHNW?= =?utf-8?B?eUl0N1hLU2FXa1pMYWxITTRqZzVta05temRFaTkwYlJCVjMycVVkTEtZdTRm?= =?utf-8?B?ZkVFVzU5eXFVampKTDY1MldRT0hTK0lCN3lKRytwakxvTEZBTlZrdi9Pcm40?= =?utf-8?B?WWE3L1lMSHlLMFhKR1pJZmFVMnVSSDZxU2N1ci9kaW41TGlUK0tFTUNXdGZw?= =?utf-8?B?Sjk3clBTcEtjS2V5ZU12SVMvTTBlWXJBVkliaGJkL2F6blA1c2RuR0gvV011?= =?utf-8?B?SHY0R0lKSmh0ZU9tNFp1OFdsc0lXTmpQSnR6RU9veHVJazJoV0hGYVZXNUE2?= =?utf-8?B?WEhlUnhZZXVkRnRTb09xT256NWJhV0dCcHR1K01yakJrQzFJdTF5UkQxUXE1?= =?utf-8?B?L0treXR3azZBZlVrVEdRL1FRTFpBSFRpQnF3UGYxZTdaY0k4TEk5T25iaFFk?= =?utf-8?Q?gXGRnAFUBT8k6WsU+S+W9ZJomyNia0u/WgjUM=3D?=
X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0698; 6:HXn82y6g+HxK1C1/j18QgCzUCVM8Oj6z+cdBy57abIU0Q3VGPGvPhBCZLL+HcrizLbD9NXwMhUN5fvNf+bWvz1GLr5+gDGENnlhMc76xABARb3w/NQ/irfZNNLDd7MYd+YApBLjEPL7VxRLDn46C7+Tk+y+A0reGTQejDmND1BH26CTENcWF1xWwXsMxot5mzRrTi27BYG17mKhRg1xfTlOK1vtFzxVUkVC2DY2fjNGFFq9ys2qZfJuKgL1TtKjEu+f0IQYxlIGRRaXcntajJ4w2ULps4okeCmJmNBFOPXEv+FJ8iZdrTVYa2SIb3nUSXvKwHlhSwemW4G0uNOnmN9Gl4KcfxG7mtHxA7rX0u/g=; 5:fuD5wYz5MzohbBqsMMrjTOWdH0iz89oIbSjuMQ+bbqMSime4iXxXHCDLoRJQzkeCZiTp9H/TO53R4IhrSgWDP1VRWTU+3lBc8eDPki/qXwXYmjqFLrZr3ApPoBNZUsel/PxtA9gKpsmTrKFgZKK0Up256o8Ew5mA5q8e1COIMsk=; 24:aQWyj79AR7oWxQfhQlntxKR/JRSoLORNjbNPf2tvtbzGxtudI58atsd8wcu32V3kGRxkl4tLXNeVsdLraqjtjvdfE82J+t2FHuSj2En2iuY=; 7:gzJjJ8wnMMuR3AMnM7l3bmPExjZ6k2SayaHKsX39/MaCOek/WwdNDghZBG65v/bBtKsIut/8s5+6Ev/PYZQMsATfOVjZEtzBdb1rkHY2m5ZzxuP7JN0Aji6BVJJLUpXLlfdD0GPxtP07OEs9eWDOHWviXwl4e+vydNORpCRZZ3bUTzA6PCIAGFdJKdxHPv3gKQC3RGAP+cXXvGCIz1Dq6nq0q/0uIgaxJ6CP9m3+ZoIgiRF7BhOn6b/i/8CpPWtq
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: apnic.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2018 22:32:11.0212 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c3abba7-775b-4356-773d-08d581569c69
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SIXPR04MB0698
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/44fQzHSfcq8XIL_KNWKI8hz9T3M>
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: Sat, 03 Mar 2018 22:32:19 -0000

Hi Duane,

> On 1 Mar 2018, at 9:45 am, Wessels, Duane <dwessels@verisign.com> wrote:
> 
> Thanks for the update.
> 
> IMO this document really needs a Privacy Considerations section and maybe also some additions to the Security Considerations.  Whereas the signals in 8145 are between the validator and the zone owner, this technique enables third parties (with either good or bad intentions) to learn something about the security configuration of recursive name servers.  Possibly all of them.

If one could direct queries directly at individual recursive resolvers then it may possible to determine some information about the behaviour of recursive resolvers, but with the use of forwarders it is sometimes challenging to determine if the observed behaviour is that of the recursive resolver or the target of the forwarder. However, to perform that task, its much more than a simple scripted get of a URL. At the user level it requires the use of code that allows DNS queries to be sent to recursive resolvers.

The sentinel changes the behaviour of a DNSSEC-validating resolver by making an otherwise validated response into a SERVFAIL signal depending on the exact query and the state of the trusted key stash in the validating resolver. However the intrinsic value of that information (that a resolver trusts a key whose hash matches a particular number) seems to me to be somewhat abstract. Section 5 of RFC4035 specifies that a trusted key must appear at the apex DNSKEY RRSET, so even if a) I know of a key pair where the public key part matches the hash value, and b) I can construct a DNS situation where this key is used to sign a RR, the key must still sit within a chain of trust. 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.



> 
> Similarly, I think the document could be more transparent and consistent about who is able to make the determinations.  For example it currently says:
> 
>   "allow an end user to determine the trusted key state"
> 
>   "allow a user to determine the state of their DNS resolution system"
> 
>   "allow us to infer a trust key state"
> 
>   "allow the client to determine the category"
> 
> I'd like to see at least in the abstract "...allows end users and third parties to determine…"


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?

thanks,

    Geoff