[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
.gov DNSSEC operational message
- Subject: .gov DNSSEC operational message
- From: oberman at es.net (Kevin Oberman)
- Date: Tue, 28 Dec 2010 20:07:22 -0800
- In-reply-to: Your message of "Tue, 28 Dec 2010 22:34:20 EST." <[email protected]>
> Date: Tue, 28 Dec 2010 22:34:20 -0500 (EST)
> From: Jay Ashworth <jra at baylink.com>
>
> ---- Original Message -----
> > From: "Kevin Oberman" <oberman at 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.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751