Re: [dnsext] historal root keys for upgrade path?

Brian Dickson <brian.peter.dickson@gmail.com> Tue, 01 February 2011 04:58 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 B27F53A6B60 for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 20:58:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 sfuxUn9WNNxq for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 20:58:54 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 6E8673A6B5D for <dnsext@ietf.org>; Mon, 31 Jan 2011 20:58:54 -0800 (PST)
Received: by fxm9 with SMTP id 9so6994747fxm.31 for <dnsext@ietf.org>; Mon, 31 Jan 2011 21:02:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BbGVCJb5qXw56u5DEJIMWFOhb1FdJq+p/9Fkt63+6EI=; b=wxxMjchjr+SXRBlcUwBuNxnjX+GQLQa5zunEAGHDsEtOMs6PeO1L4PZtfv5FDRvSvY DKT7P7Hbs5ZuxmZLG9QSNHDcccdql5t9fPwta2FBJAjRb9xTm36Mjx02CB/rzFIFMyYB 8R4bU3PmdL46WVWJoAlM1toTmFECBMBOSGD70=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vFKU15D7NBqcYKzeZl6mtII/gGyT9fGzCM1JBC3wOdI2GamamGKTZwDxCObsBZweuc z46we2KMe2rt3S9JHmq2io9x1XYUJqS565BJMt8QnAIY89iQ5B2DmbLN+9u8v2kif/Vg scEwVDND8C8InnzhfCR+ECpKHGnx1UYw5cb2I=
MIME-Version: 1.0
Received: by 10.223.83.11 with SMTP id d11mr6908257fal.37.1296536529731; Mon, 31 Jan 2011 21:02:09 -0800 (PST)
Received: by 10.223.108.71 with HTTP; Mon, 31 Jan 2011 21:02:09 -0800 (PST)
In-Reply-To: <AANLkTiksER2SYPLiwy6uta3UBvbrEj0mDVOJnKSV-fbV@mail.gmail.com>
References: <alpine.LFD.1.10.1101251250040.30991@newtla.xelerance.com> <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <4D45DE93.9090508@vpnc.org> <AANLkTinbjRebooyqWMpZ2oTudruoDSGqgaXXr35WPYVH@mail.gmail.com> <AANLkTikiqe2K4S-dNsyQZ-xp71J4bM11SsahwpxfDKCX@mail.gmail.com> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> <AANLkTinOtx88vK3mz-w=uw1CnsKwm=c-nTDOsj=5JAPY@mail.gmail.com> <AANLkTiksER2SYPLiwy6uta3UBvbrEj0mDVOJnKSV-fbV@mail.gmail.com>
Date: Tue, 1 Feb 2011 01:02:09 -0400
Message-ID: <AANLkTinq+F3AfXROavDW5YGeZ2zVeqW4Oc0jSkWmN8Ss@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: dnsext@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [dnsext] historal root keys for upgrade path?
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: Tue, 01 Feb 2011 04:58:55 -0000

On Mon, Jan 31, 2011 at 3:23 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>
> On Mon, Jan 31, 2011 at 1:22 PM, Brian Dickson
> <brian.peter.dickson@gmail.com> wrote:
>> The simplest bootstrap method would be to have a series of BSK
>> (bootstrap keys), created on a periodic basis (every N years), and
>> used as follows:
>
> If a compromise has occurred then the first thing to ask would be why.
> There are only three places where a compromise can logically occur - in the
> cryptographic algorithm, in the cryptographic hardware manufacturer or in
> ICANN,
> If its the algorithm then the whole series of BSKs is compromised.

I think it is helpful to use as explicit a form of language as
necessary, to clearly communicate ideas.

So, when I ask you to clarify this into particulars, it is with the
intent of understanding what you meant.

"If a compromise has occurred" - a compromise of what, exactly, are
you talking about?

It could be that there has been a theoretical weakness in the
algorithm, which makes it slightly more feasible to break, but that
the root zone key's private parts have not been exposed.

In which case, this is "theoretically weak".

On the other hand, it could be that the root zone key has had its
private parts found, in which case the term "compromised" has the very
real, concrete meaning in that someone has directly compromised its
security.

In both cases, the impact on another key, which is neither dependent,
nor whose security depends on, the root zone key, is non-existent,
other than that it implies that the other key is equally
"theoretically weak".

In other words, the BSKs might be "weak", but not "compromised", per
se - and using that term doesn't facilitate clear and rational
discussion, of something pretty darned important for a large class of
operational problems (bootstrapping).

As to the cost of compromising multiple keys:

If two keys share only the algorithm and key size, the expected effort
for both is equal.

If the required effort to discover the private keys for either key is,
on average, what would require six months of the combined effort of
10,000,000 zombie machines, then:
- it would take a botnet of 10,000,000 machines six months (on
average) to break the root zone key
- it would also take the same botnet six months (on average) to break
any single one of the BSKs
- combined, it would take a year of the whole botnet's combined
resources to compromise one BSK and the root zone key, which would
then create a theoretical ability to forge answers to queries for both
zones, for a small number of devices during a one-time, small window
when they bootstrap
- the BSKs are independent, so for N BSKs, it would take N+1 times the
total resource requirements, to have all the BSKs compromised

I'd suggest that the very large resource requirements, the very small
window of opportunity, and the requirement that both forgery attempts
succeed, for a one-time attack on one single device, puts the
likelihood of success sufficiently close to zero to discourage anyone
or any organization from making the attempt.

Brian