Re: [DNSOP] draft-ietf-dnsop-dnssec-trust-history - discussion

Joe Abley <jabley@hopcount.ca> Tue, 14 September 2010 20:01 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8723A6A99 for <dnsop@core3.amsl.com>; Tue, 14 Sep 2010 13:01:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 UArgr-7gOiv6 for <dnsop@core3.amsl.com>; Tue, 14 Sep 2010 13:01:26 -0700 (PDT)
Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 1A2B33A6A94 for <dnsop@ietf.org>; Tue, 14 Sep 2010 13:01:26 -0700 (PDT)
Received: from [199.212.90.26] (helo=dh26.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from <jabley@hopcount.ca>) id 1OvbhC-0000hJ-TK; Tue, 14 Sep 2010 20:01:39 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <alpine.LSU.2.00.1009141854170.4600@hermes-1.csi.cam.ac.uk>
Date: Tue, 14 Sep 2010 16:01:37 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D3EA166-C431-427F-85EA-67D64612396F@hopcount.ca>
References: <569C36E4-4F05-41B2-B0B8-A4B8228F13C9@googlemail.com> <4C8E36ED.70201@nlnetlabs.nl> <2BFBD0CC-95E7-4F08-B3AD-6B439F3AAD7B@hopcount.ca> <alpine.LSU.2.00.1009141854170.4600@hermes-1.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
X-Mailer: Apple Mail (2.1081)
X-SA-Exim-Connect-IP: 199.212.90.26
X-SA-Exim-Mail-From: jabley@hopcount.ca
X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] draft-ietf-dnsop-dnssec-trust-history - discussion
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 14 Sep 2010 20:01:27 -0000

On 2010-09-14, at 13:55, Tony Finch wrote:

> On Tue, 14 Sep 2010, Joe Abley wrote:
>> 
>> Doesn't trust-history impose a requirement high standards of operational
>> security for key materials which have long since fallen out of
>> production, and hence extend the possible window for a key compromise
>> long after the key has stopped being used? From an operational
>> perspective this worries me.
> 
> I haven't checked the draft, but it should be possible to throw away a
> private key after it has signed its successor and been decommissioned.

Right. I'm concerned about the scenario where

 - KSK goes out of production
 - KSK is supposed to be destroyed following some suitable emergency roll-back window
 - KSK is not actually destroyed due to operational error
 - KSK is compromised by someone (hard disk found in dumpster)
 - KSK is used to create an apparently-legitimate branch of the trust-history chain, legitimising a bogus key

In normal operation this would not be a concern because the retired KSK is of no practical use. By inventing a practical use for the retired KSK, the requirements for secure handling are extended until the end of time.

I agree that in an ideal world the KSK would be securely destroyed. I don't often feel like I live in that world, however, hence my worry.


Joe