Ok, Stephen, John and myself have talked this over a bit now and this is how we
feel about the issue of standby keys and whether to keep them or not.
Johan
1. DNSSEC key management is a history of manual failure about to be replaced by
software success.
Some of us have played with DNSSEC for a Long Time(tm). We've been jumping
through hoops, run ugly scripts and in general dealt with an amount of
operational complexity that is simply not suited for any reasonable amount of
manual operations. All the while we've been chanting the mantra "there will be
software in the future that deals with this".
Given that history we're really concerned when we see statements like
"Our idea: The support of standby keys in OpenDNSSEC can be deprecated,
because it
can be handled outside the system."
because to us, that sounds very much like going back to square one. I.e. if
there is a use for standby keys, then we'd very much prefer to have opendnssec
deal with that, rather than opt out for simplicity just to push the problem
elsewhere.
2. Is there a use for standby keys?
Yes, there is. Being able to plan for trouble and be prepared to roll keys
"immediately" has a use. As far as I can tell that is mostly agreed upon.
However, at present, it appears that there is less than good understanding of
how this actually works. Both Jakob and Rickard have explained to me that users
seem to believe that just "adding a standby key" more or less by magic makes
the zone more secure, which is of course not true. So, clearly, there exists
what we'd refer to as a pedagogical issue with standby keys and we do
understand that the people working with opendnssec may feel that not to be
their primary focus. On the other hand, we argue that there are *many*
pedagogical issues with DNSSEC and the need for lots of work in that area,
which is quite separate from the need for software development. However, if the
software doesn't even support something, then any form of educational effort
will be completely wasted and pointless.
3. Doesn't the standby key typically get compromised at the same time as the
other keys in the HSM?
No, not necessarily. That is a question both of the design of the actual HSM
and the policy of whether to use a single HSM or several separate HSMs, both of
which are choices that should not be made by opendnssec, but by the users of
opendnssec.
4. Wouldn't removal of support for standby keys lead significant simplification
of the code?
Personally, I really don't know, because I have not worked on the opendnssec
code. But we are convinced that when talking about the complexity of the code
to support standby keys very little is about standby keys as such and almost
all the complexity regards support for multiple HSMs, some of which may be
offline while still containing keys. We believe that opendnssec will have to
support offline key storage regardless of the standby keys issue (just think
"smartcards") and hence we do not believe that in the long run there will be a
significant simplification gained from removing support for standby keys.
Given support for keys stored in offline HSMs, supporting standby keys becomes
if not trivial at least not a daunting task.
I'll post part #2 in a minute, which contains some thoughts on how to support
standby keys in opendnssec assuming that HSMs containing keys may be offline.
Regards,
Johan
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
