[Opendnssec-develop] Review requirements
jakob at kirei.se
Tue May 12 21:11:07 UTC 2009
On 12 maj 2009, at 14.12, Antoin Verschuren wrote:
> 1. In 3.2.3 it says: "2. The signer MAY inspect input DNSSEC RRs
> associated with a zone and, if valid, output them instead of
> generating new ones.
> Note: this behaviour SHOULD be a configurable option."
> Can somebody explain why this should be a configurable option ? Or
> in other words, in what situations would you want to be able to mess
> with this ?
if you feed the opendnssec system an already signed zone, you may want
to strip all dnssec information at ingress.
> 2. I see in 2.4.3: "It MUST be possible to manually roll the KSK for
> a zone."
> I don't know how far this goes, but does that mean that there should
> be a simple command or button to do an emergency key rollover ?
> I think in case of a key compromise, I would like to have a simple
> button like that, so all other integrity checks are done
> automatically. Not only that I can manually generate a key, but all
> other keys and timers should be recalculated so that operation goes
> back to normal. An emergency key rollover without thinking what else
> needs to be done.
> 3. 2.4.3: "6. The production of a new KSK for a zone MAY be notified
> to the operator if such notifications are enabled."
> I would like to have a configurable notification option as well
> where I am warned in advance that a KSK rollover will be necessary
> in a specific timeframe.
seems like resonable thing that one would like to ask the KASP enforcer.
> So f.e a notification that I need to generate new keys in the coming
> month. In cases of some higher security, f.e. when manual
> intervention for KSK generation is needed (offline signing).
> Do we still find that applicable ? Is there still an opinion that
> ZSK rollovers are handled by the HSM/signer, but KSK rollovers can/
> should be done offline ?
currently, all key handling is done online. we've had discussion
regarding operations that involves carbon life forms as well, but
nothing is currently implemented as far as I know.
> 4. Don't know if this is a nice to have or a requirement: I would
> like to have some state reporting to see how my signing is
> A sort of oversight of all the zones with the versions of KSK and
> ZSK's used or ready to be used to monitor the signing process.
yes that would be nice. please send code :-) (sorry, I had to say that)
> 5. Parent interaction
> How configurable will the KSK notifications be ? I'm thinking of
> parsing notifications directly to my parent. You'll have questions
> like do I need the DNSKEy, should I calculate the DS, can I follow
> the update process at the parent, in other words, what information
> and format do I need for KSK notification ?
as far as I know, we have not discussed parent-child interaction yet.
> 6. There is a requirement for multiple HSM's to facilitate migration
> to new HSM's. I think another use case is that there are more zones/
> keys than fit in a single HSM, so you'll need extra HSM's to expand
> capacity. That use case should be provided too. I think it says that
> correctly in the requirements, but I want to make sure.
we have a capacity value for each HSM so that should be possible.
> 7. Integrity checking
> We are used to do integrity checking before a zone is published.
> However, we can do a lot of integrity checking because we generate a
> complete new build of a zone. So we can compare the old zone with
> the new one and see if there is not a major change. I have 2
> questions: Will integrity checking be done only on the DNSSEC data,
> or also on other parameters (What happens f.e. if the outputted zone
> is DNSSEC correct but has 90% less data). Or in other words do I
> still need integrity checking of the zone before and after I submit
> it to the signer.
IMHO, the KASP auditor should only audit what the KASP states - so
garbage in, garbage out.
> And the second question is how configurable will this be ? I can
> imagine there are zone specific checks you want performed (this
> record should be in there). Or is this out of scope ?
I think this is out of scope.
> 8. Performance
> I think this does indeed need more specification, and I think the
> current requirement is quite low.
> I don't know how this will impact the one large zone versus lot's of
> small zones, or how that performance changes when increments are
> signed later, or do we think about that in a next stage ?
parts of the performance is depending on what HSM is used, but also
how scheduling is done. I think we need to revisit this after the
first version is released.
> Shouldn't we have similar performance figures for integrity
> checking ? (The more you check, the longer it takes).
Kirei AB - www.kirei.se
More information about the Opendnssec-develop