Re: [dnsext] Historical root keys: The Large Router Vendor Speaks

Nicholas Weaver <nweaver@icsi.berkeley.edu> Fri, 28 January 2011 17:09 UTC

Return-Path: <nweaver@icsi.berkeley.edu>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2196F3A6914 for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 09:09:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.379
X-Spam-Level:
X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcKFYGv1JvMo for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 09:09:24 -0800 (PST)
Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 66FBC3A68D2 for <dnsext@ietf.org>; Fri, 28 Jan 2011 09:09:24 -0800 (PST)
Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 10B8A369FE9; Fri, 28 Jan 2011 09:12:31 -0800 (PST)
References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com>
In-Reply-To: <4D42ED13.5030000@cisco.com>
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
Message-Id: <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
Date: Fri, 28 Jan 2011 09:12:30 -0800
To: John Bashinski <jbash@cisco.com>
X-Mailer: Apple Mail (2.1082)
Cc: dnsext List <dnsext@ietf.org>, george.barwood@plueyonder.co.uk
Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2011 17:09:26 -0000

It really seems to me that the only thing that works to bootstrap a device which may have missed arbitrary key rollovers is the following:


If the root KSK is due to 'once every 5 years/because we feel like it/we want to see what happens' rollover event (98% chance):

As long as all the historical data is available someplace that the device knows about (eg. http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02 .  Or pick whatever...), there is no excuse for not using this style of mechanism.

Its not only secure, but MORE secure than any other automatic alternative because it doesn't add to the 'you need to trust' keyset.  

Anything else MUST either add additional keys to the trusted root, and/or becomes the trusted root instead.  In the former you're weakening the system (you now trust both the . KSK AND some 'random' PKI certificate, as a compromise of EITHER is sufficient to break your security), in the latter you're just replacing one key roll problem with a second (how do you roll the PKI certificate?).


And although the root SHOULD provide such a trust history, any vendor COULD provide its own trust history as a backup/until IANA decides formally it will provide such a mechanism.  It doesn't increase the trust in the vendor.


Thus the only question on a normal rollover is what to do if the update fails because the historic information is unavailable.


My thought would be a 'limited leap of faith': Just ask the root for its KSK, accept the result temporarily, but keep retrying to get the full chain once a minute for the first 10 minutes, once every 10 minutes for the first day, and once a day thereafter.

Yet this temporary result should ONLY be used for validating A records and the like, NOT be used for validating security records (eg, like the DANE working group is proposing).  

Fortunately, since using DNSSEC to validate security-relevenat records requires new API calls, this should be a reasonable to implement restriction.


Thus a denial-of-service from a MitM will be able to muck with A records fine, but can't muck with security records. 

Since such a MitM could just as easily muck with the final traffic in most cases, this is not a substantial increase in security risk, while gaining the ability to automatically role the root for a device that has been offline since who-knows-when, including being able to roll the device when the history service fails.



Instead, if the root KSK is rolled due to a key compromise:

Well, things are ugly.  But things have BEEN ugly for the whole period of time when the compromise was unknown (and someone who compromises the root key is going to have an incentive to keep it VERY quiet).  

And if this requires human intervention to fix, so be it, its going to be such a big mess that human-in-the-loop will be needed for so many other things that, hey, thats life.


Someone invents a practical quantum computer:

Well, DNSSEC is FUBARed then.  Back to the drawing board.