Re: [DNSOP] IETF meeting prep and what

[Brian Dickson <[e-mail]>]

On Fri, Jun 18, 2021 at 12:06 PM Joe Abley <[e-mail]> wrote:

> On 18 Jun 2021, at 14:45, Paul Wouters <[e-mail]> wrote:
>
> > On Jun 18, 2021, at 13:41, Peter van Dijk <[e-mail]>
> 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
   IETF LC)
   - 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.).

Brian