Re: [DNSOP] IETF meeting prep and what

Brian Dickson <> Sat, 26 June 2021 01:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EC643A155E for <>; Fri, 25 Jun 2021 18:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EnS_mndra4_r for <>; Fri, 25 Jun 2021 18:04:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75A2F3A155D for <>; Fri, 25 Jun 2021 18:04:56 -0700 (PDT)
Received: by with SMTP id c11so14960137ljd.6 for <>; Fri, 25 Jun 2021 18:04:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dd6NJa5NE/0W19rRzv2JOsj4Ni0Jj7w+fIW/m88A7qI=; b=ETScLNRhyfQcz+N6RBUUE480DxWtyvcGenSBScQ3qSHB336ABusxj4Hx2Vtw3gj1+h 0u18PDK4/hNfurA1Y6gkTY0tqd6ldpilZbY8ZGfnPb2itKXLNxzP8pYskhlLKkL0eak+ UWh5nBUOT/pLGOIcXSXQm+KFTr9I0U7adypAz+Ts9FT4bMb9oBpp2CNLHPEqM0mbM6RM s0mEB8C/Iq3EBKIFfPbBDVP66CMQtECzf+Lp9HYBUecZ5oTYw/OkLghE7IZO45ANyhg3 3wlwUQHmMvo8TvEVTVQZX6CtS8jWb8g68uOSob35rtuyKJFymQoFCzgiZPJQVS0rwDca fkWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dd6NJa5NE/0W19rRzv2JOsj4Ni0Jj7w+fIW/m88A7qI=; b=L4oKhx2qsIhfTrAcuTbOCeT06VDxyfqZD7OuzN9qdyB56Gp002/gDeFenGhk1pX1Yi 71O0SwkslFXJzqzZCU3EMn1aBPcaYoKDkGsFbXf49A+pNRDX7BjoLY6WKcSTbsJ2REOM gck98/vY90RZvgOCBlOWJRY8IAzPXb8T2nu9u+l7TIerR3A9siiUDc5TEICJb7+yFOid iU8J273yed6HQ3DsX5wEaMsn7XmxxmAmpiUbvxGQNBTrJYZUQqA1vMWtotSZNgeu7Mkw LTMfAqSybup4BMz9QCG2wysX49gLMhkThLJ3WfOckkIvX7Vum66Udx8lslFEaW0q12OZ 2UQQ==
X-Gm-Message-State: AOAM532egEeunIWWEmg/oypWzZmPerkGuJFNapprbghbBBTZMcsx1BlN /ovIZNgJdu87ZnxfT2YnY9SXDCmZRkcISadrjbM=
X-Google-Smtp-Source: ABdhPJx+yDrn+b1uFCRBYKYgdTNEY7Q/bdcapYuhmzst+WkzNLp4FQNQds9AeiyiRnWGVOOpYQvy9Yc9uVwZlbj0qgo=
X-Received: by 2002:a05:651c:1b3:: with SMTP id c19mr10427841ljn.253.1624669494114; Fri, 25 Jun 2021 18:04:54 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Fri, 25 Jun 2021 18:04:42 -0700
Message-ID: <>
To: Joe Abley <>
Cc: Paul Wouters <>, dnsop <>, Peter van Dijk <>
Content-Type: multipart/alternative; boundary="00000000000012fc4d05c5a0d80d"
Archived-At: <>
Subject: Re: [DNSOP] IETF meeting prep and what
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 26 Jun 2021 01:05:02 -0000

On Fri, Jun 18, 2021 at 12:06 PM Joe Abley <> wrote:

> On 18 Jun 2021, at 14:45, Paul Wouters <> wrote:
> > On Jun 18, 2021, at 13:41, Peter van Dijk <>
> wrote:
> >
> >> I propose replacing rfc5011-security-considerations with a short
> document deprecating 5011 in its entirety.
> >
> > Eh? 5011 is baked into various software. Why would replace 5011 ?
> >
> > Did I miss something?
> There were some conversations adjacent to the last great root zone KSK
> roll excitement about how a more measurable and reliable mechanism might be
> useful. My memory is that there might be value in specifying a new
> mechanism that could be used as an alternative to or in conjunction with
> 5011, though, not that 5011 was fundamentally unsound and deserved to be
> deprecated.
> I agree that, in the end, 5011 seems to have done a reasonable job -- it
> was just hard to predict with any degree of comfort or certainty.

I didn't realize the -security-considerations document had the history in
the wg during wglc (I missed that entirely, sorry).
And hadn't really closely read either the draft (even in its latest
iteration), or looked at 5011 itself with a critical eye.

I am in favor of all of the following:

   - Advancing the -security-considerations draft as Informational (e.g. as
   - Keeping 5011 or a successor
   - Working on an informal 5011 thing to document:
      - What it can and cannot do
      - Requirements on how to strengthen it against the replay attack
      causing failed rollover
      - Requirements for how to strengthen it against a compromised key
      (discovered empirically for example)
      - Requirements for how to protect against change-of-control via
      single compromised key
   - Working on a formal 5011-bis informed by both the present
   -security-considerations work, and the informal thing (previous bullet)

I am willing to work on the last two items as a co-author, but probably
don't have the cycles to be the holder-of-the-pen.
I have specific ideas, so this isn't just wishful thinking, I don't think.
However, whether the -bis is able to get consensus is not a foregone
conclusion, I don't think.

Having a stronger and more resilient 5011 is something I think that may be
important, particularly for use in environments which are not the Root
Trust Anchor (e.g. private trust anchors in various environments, including
the 2-letter undelegated use case, the internal-only subdomain use case,
and possibly some of the HomeNet use cases presumably.).