[Opendnssec-develop] Review requirements

[Jakob Schlyter]

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 ?

yes.

> 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.

yes.

> 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  
> progressing.
> 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).

yes, probably.


	jakob

--
Jakob Schlyter
Kirei AB - www.kirei.se