.gov DNSSEC operational message

Mailman List Mirror (Read Only)
1

Date: Tue, 28 Dec 2010 22:34:20 -0500 (EST)
From: Jay Ashworth <jra@baylink.com>

> From: "Kevin Oberman" <oberman@es.net>

> There is no reason that you could not do OOB transfers of keys, but it
> would be so cumbersome with the need to maintain keys for every TLD
> (and, for that matter, every zone under them) and deal with key rolls
> at random intervals and confirm that the new keys you were getting were,
> in fact legitimate would be more than overwhelming. It just does not
> scale.

I apologize; I was not clear.

I was not suggesting OOB *production transfer of keying information*.

I was rather suggesting that an additional publication of the keys, in
an authenticatable manner, which could be used by anyone who believed
that Something Hincky might be going on to confirm or deny, might be
useful.

Ahh. I did miss your point and I suspect others (other than Bill) might
have, as well.

Yes, having a verifiable source of keys OOB might have a small bit of
value, but, assuming we get general adoption of RFC 5011, I think it's
pretty limited value. Of course, this begs the question, how do we do a
better job of verifying the keys received out of band than the root zone
does of verifying the keys? Sort of a chicken and egg problem.

2

presumes RFC 5011 is viable. fall outside the 30day window and
  your screwed. :slight_smile: that said, what folks came up w/ for the root
  key roll might be a useful template, e.g. the use of TCR's and
  use an M/N assurance check - in those rare cases where your just
  foobarr'ed and you can't take your servers into the SCIF to rekey.

  and/or an alternative to the strict timing constraints in RFC 5011
  with a protocol that gives more leyway for a node being offline
  over a keyroll interval.

  There -should- be a functional equivalent of OTAR for DNSSEC keys
  that is not constrained to a tight window... IMHO of course.

--bill