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

Joe Abley <> Tue, 14 January 2014 18:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 264FE1ADF8F for <>; Tue, 14 Jan 2014 10:55:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KZPk3zX21z08 for <>; Tue, 14 Jan 2014 10:55:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::231]) by (Postfix) with ESMTP id 6BCC91ADF90 for <>; Tue, 14 Jan 2014 10:55:12 -0800 (PST)
Received: by with SMTP id ar20so903700iec.22 for <>; Tue, 14 Jan 2014 10:55:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=C/vHArdgrXFYB8BXVB1DsVx7Rsr0GnGslKXFxpoiQZs=; b=LAI8+N0fuTM3UxzdNGF6/wCi/JMJclwH+3nTm0vbyKGDcI2AjTSqPjsSGQvWZtpYXj Y3nJPIkPPOsAk2hj2mIP8Rdy9/RrPD9kU0m4uqcL4v7qXdBtFENhKs/orqExZoekRrdD 6qZiWYb53GMo8hawuYspvYcI5p5mVrPboC6y0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=C/vHArdgrXFYB8BXVB1DsVx7Rsr0GnGslKXFxpoiQZs=; b=cmJiUZVYD/ycO7gdqXZDhT7sWje0xXnwsyNaJe5mP6U+xpZbE9oLnSsDgcxa3TWExD TcCR8W0VHNT5OF4wI0q/keM8BzSOi0w17rZZivdCOVevinOZcm7se6txKWOi+xUhCV2z VMRuNAjezLwMwOhMz2kKdhI8P7NoYpZ/dqndGnv0aC3mxznrYa7OB+7VwEqm+lZcHDBx kOpIdx1vx2Dmba4lM0WHgIQCHAUeVVtX0EkzJHpRu92PkpT25oV/j2V+ecybZWHmJd2F C9tPgMQOX1Vm2p/j0vk+AqcElUPzm6LUtZ5uW4OGI4rTG9i2NATwQhI4caAO5lVekCaW HQNw==
X-Gm-Message-State: ALoCoQkJABXX3hGWQ2ztuGkn5z7RuyrjfcEg3x3fo+3cdyuREpvfEMcVbyOnbFMXm9tGkRCnt0UP
X-Received: by with SMTP id kq4mr4692821igb.40.1389725700917; Tue, 14 Jan 2014 10:55:00 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id a1sm2513149igo.0.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Jan 2014 10:54:59 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_13912D51-09B8-4D13-BC42-F46FF4CEC0AB"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Joe Abley <>
In-Reply-To: <>
Date: Tue, 14 Jan 2014 13:54:56 -0500
Message-Id: <>
References: <>
To: Andrew Sullivan <>
X-Mailer: Apple Mail (2.1827)
Cc: dnsop <>
Subject: Re: [DNSOP] More keys in the DNSKEY RRset at ., and draft-ietf-dnsop-respsize-nn
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Jan 2014 18:55:14 -0000

On 2014-01-14, at 12:22, Andrew Sullivan <> wrote:

> For my sins, I have been following some of the recent discussions
> about "Internet governance".  One of the discussions over on the
> "1net" list ( is
> about the control by one particular government of the DNS root zone,
> and how uncomfortable that makes some other governments.  The
> consequence has been renewed discussion on a somewhat older proposal
> for splitting up the management of the root zone keys.  The proposal
> can be found at

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, except that there's only a single RKO and it's called IANA. The general framework (as deployed today) whereby KSRs are sent from the RZM to the RKO and ceremonies are held at the RKO to process them seems eminently extensible, at least in theory.

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. It also adds points where political concerns might lead to a refusal to sign. Since a KSR is not linked to a specific set of proposed changes to the root zone, a refusal to sign would presumably be on general/philosophical grounds rather than in reaction to any particular proposed change to the root zone.

Timing for KSK rollover would have to be carefully managed, since it seems like having multiple RKOs roll their KSKs in overlapping windows would be a recipe for grand hilarity.

> The proposal has the appealing property that nobody can "hijack" the
> root,

Well, in fact any RKO can hijack the root (by which I mean put its publication in jeopardy for people validating against that RKO's trust anchor). They can just refuse to process a KSR; during the time window corresponding to that KSR, validators depending solely on that RKO's trust anchor would see the namespace go dark.

[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.]

In terms of custody of each KSK, multiple RKOs means multiple opportunities to compromise private key assets. That's a change to the risk profile. Also, one RKO performing key ceremonies is tedious enough, imagine if there were five times as many :-)

I realise this wasn't the point you were raising, but I thought it was an interesting tangent. To the point you were actually raising:

> I am not sure I am so sanguine, but this put in my mind the
> draft-ietf-dnsop-respsize draft, which I now realise was never
> published as an RFC.
> I'd like this thread to discuss the "so what, use TCP!" remark.  I'd
> also like to ask either the chairs or the WG whether
> draft-ietf-dnsop-respsize-14 needs revision and, if so, what revision
> to be publishable, because I think it's needed advice.

I also think that draft should be published. I think we have a little more operational experience with (and studies that speak to) large responses now than we did when Vixie last lifted the pen on that document, so I imagine it would benefit from some review.

I would be happy to review and/or contribute.