[dnssec-deployment] proposed method of generating and using a root domain key
paul at vix.com
Thu Jul 28 02:39:24 EDT 2005
# > my question was, and remains, "then why did the WG send this protocol to
# > IESG without root-key management, if it's mandatory?"
# and my reply is, ask the IETF WG... i have no idea how the IETF
# politics works these days.
i won't ask them. i'm going to follow the recommendations they made, and fill
in the parts they failed to make. the onus is on you (or maybe sam) to ask
the ietf to declare dnssec undeployable-without-key-management if indeed you
want it to be seen as undeployable-without-key-management. the rest of us
are, or at least i am, going to try to deploy, rather than waiting an
undefined period of time for an unnamed problem to be fixed by unknown
# manual configuration in the endsystems ... a showstopper
# for production systems.
it's been working for the list of root name servers, so it's not a showstopper
for production systems. a bad idea, perhaps. but not a showstopper.
# > the key management that doesn't work today is automatically updating or
# > replacing all the trust anchors in a validator population when a KSK is
# > revoked. but since the WG explicitly declared revocation out-of-scope
# > years ago, it's really hard to understand why you (or sam) would declare
# > that the docset handed to IESG described an undeployable protocol since
# > it lacked support for revocation.
# can't speak for sam. the WG was wrong. and i'm not sure that a
# general solution for all TA's is needed. We do need something
# for the root TA tho.
well then feel free to not deploy it. i'm interpretting events differently,
and am going to deploy it, and any potholes left by the WG, i'll pave over.
# > ... the three KSK's made by the interrim keymaster will have infinite
# > validity periods and the resulting trust anchors can be used to create
# > ZSK's for the lifetime of the internet.
# ah... the old VSGN recommendation of sig periods of 38 years. all we
# really need to do is get just past the epoch, right? no key roll
# needed in our lifetime. can we just lose the fiction of "interim"
# keymaster then?
perhaps i lack the ability to tell fact from fiction. for example, the fact
is, we're not going to see wide deployment of NSEC. verisign's going to wait
for NSEC3 for .COM, and thus there will be a complete swapout of validator
code when NSEC3 is deployed. feel free to just not deploy NSEC on that basis,
but don't expect me to follow your, um, lead.
# basing things on hope/faith is not the soundest technical way forward.
# my intent is to define/provide a stable, secure technical basis for
# the long-term stability of DNSSEC. I don' tthink you have proposed
ok, that's a fair point. however, after 11 years, i have deployment-itch,
and the thing i lack hope/faith in is that the ietf should be given more
years to add key management, anti-zonewalking, and everything else we either
never expected to need or explicitly removed from the must-have list. i
know how to get dnssec-bis out of the lab and into the world, and am going
to work toward that goal. anyone who wants to wait for dnssec-ter should
do that; i'll be helping with that in parallel to my dnssec-bis deployment
More information about the Dnssec-deployment