[Opendnssec-develop] Review requirements

Tue May 12 12:12:28 UTC 2009

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

I've taken some time to review the openDNSSEC requirements.
I came across 2 requirements on the website, one for the complete project (http://www.opendnssec.se/wiki/ProjectPlan/Requirements) and one only for the signer (http://www.opendnssec.se/wiki/Signer/AuditorRequirements)

I've taken the liberty to review http://www.opendnssec.se/wiki/ProjectPlan/Requirements, and I have some questions to discuss:

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 ? 

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

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.

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 ?

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.

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

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 ?
Shouldn't we have similar performance figures for integrity checking ? (The more you check, the longer it takes).

Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E antoin.verschuren at sidn.nl
W http://www.sidn.nl/

> -----Original Message-----
> From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-
> develop-bounces at lists.opendnssec.org] On Behalf Of
> Stephen.Morris at nominet.org.uk
> Sent: Thursday, April 23, 2009 1:39 PM
> To: Opendnssec-develop at lists.opendnssec.org
> Subject: [Opendnssec-develop] KASP Auditor Requirements
> 
> I've placed the first draft of (what I consider to be) the requirements
> for the KASP Auditor on the wiki:
> 
>       http://www.opendnssec.se/wiki/Signer/AuditorRequirements
> 
> Regards
> 
> Stephen
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
-----BEGIN PGP SIGNATURE-----
Version: 9.6.3 (Build 3017)

wsBVAwUBSglnrDqHrM883AgnAQiwoQf9FgS4hQUgwL48aV8NaVoz0Z90Xz/DkqsD
7gkA4nLl2Bu48zaGYZLLUIKHK11a/CfLMwTsuwsXjI5TpG7J8hDKZ9If7X2V0qQA
msEq3+AACVHnn2rFgjdpshQFSU1WEdm9HTdgOMQ5lxot8OuxOEslPPVbGRWnGdz6
qlbwB1C9a0zyptUHax/rGgicREjjmzyihfNDDkbeId2IzFAPKMMf82/KueZK7UTr
XRudHIoSiZP4L5GuuVniOakRpKEDDOHPfX6B5vaYdM+pmRrPPJWpa5e8HFTsp7e8
8wLzcbzu2A/e+OY4pedwqQu9ENuY+SSDZB1vW4GKLCxoYX6Odd/dyg==
=E3kN
-----END PGP SIGNATURE-----