Re: [DNSOP] More keys in the DNSKEY RRset at ., and draft-ietf-dnsop-respsize-nn

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 14 January 2014 20:09 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1680B1AE210 for <dnsop@ietfa.amsl.com>; Tue, 14 Jan 2014 12:09:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level:
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
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 jkhCtf2d5xp6 for <dnsop@ietfa.amsl.com>; Tue, 14 Jan 2014 12:09:05 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C5A841AE13E for <dnsop@ietf.org>; Tue, 14 Jan 2014 12:09:05 -0800 (PST)
Received: from mx1.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id CE46B8A031 for <dnsop@ietf.org>; Tue, 14 Jan 2014 20:08:53 +0000 (UTC)
Date: Tue, 14 Jan 2014 15:08:49 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20140114200849.GA17907@mx1.yitter.info>
References: <20140114172240.GO17198@mx1.yitter.info> <C6EFA413-1FFC-4188-B98A-13C747981FBC@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <C6EFA413-1FFC-4188-B98A-13C747981FBC@hopcount.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [DNSOP] More keys in the DNSKEY RRset at ., and draft-ietf-dnsop-respsize-nn
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <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 Jan 2014 20:09:07 -0000

On Tue, Jan 14, 2014 at 01:54:56PM -0500, Joe Abley wrote:

> It's interesting to see that what was actually built in 2009/2010 is
> largely compatible (at the high-level diagram level) with what was
> proposed

I thought that was interesting too.

> However, each RKO you add increases the operational risk that an SKR
> from that RKO might not be obtained within the required window,
> which puts zone publication in jeopardy.

Good point.  I think the idea is that this is a feature, because it's
supposed to be the Mutually-Assured Destruction threat that will
prevent the USG from unilaterally removing some country from the root
zone (that seems to be the threat people are worried about.  Why is
left as an exercise for the reader.  Note that I do not promise there
is a solution to this exercise).

> [If validators took the approach of installing trust anchors from
> each and every RKO to mitigate this possibility, then they are
> effectively saying "I'm happy so long as at least one RKO is happy
> even if all the others are deeply miserable", which doesn't sound
> like it achieves the document's objectives.]

It _might_, if the idea were instead that validators used n of m.  Ben
Laurie had a not-completely-dissimilar idea for root TA distribution
entered in the "rollover" competition back in 2006 or so.  See
http://tools.ietf.org/html/draft-laurie-dnssec-key-distribution-02.

Thanks for the observations, which I think are quite helpful.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com