From roy at nominet.org.uk  Fri Nov 14 17:17:51 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Fri, 14 Nov 2008 18:17:51 +0100
Subject: [Opendnssec-develop] new opendnssec mailinglist
Message-ID: <OFF4FDB6CE.7959A769-ON80257501.005D88B0-C1257501.005F047D@nominet.org.uk>

Hi everybody,

I've created a new list, especially for development, which contains the 
following subscribers:

 jelte at nlnetlabs.nl
 jad at jadickinson.co.uk
 jakob at kirei.se
 Patrik.Wallstrom at iis.se
 staffan.hagnell at iis.se
 Stephen.Morris at nominet.org.uk
 matje at nlnetlabs.nl
 roy at nominet.org.uk
 Rickard.Bondesson at iis.se
 olaf at nlnetlabs.nl 

Please let me know if I've forgotten anyone.

If you'll be at the upcoming IETF in Minneapolis, lets pick a slot here: 

http://www.doodle.com/participation.html?pollId=gq85m2u8qa8zsy3f

Regards,

Roy Arends


From roy at nominet.org.uk  Fri Nov 14 22:15:36 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Fri, 14 Nov 2008 23:15:36 +0100
Subject: [Opendnssec-develop] Re: Our little get-together. Re: Progressing
	OpenDNSSEC.
In-Reply-To: <9D9920CC-9809-4F1E-A486-90890C0A3ECB@nlnetlabs.nl>
References: <OFD8238BB5.87BAE70D-ON802574D4.00462848-C12574E2.0035FE71@nominet.org.uk>
	<15C70C9B-4E55-42B8-8F4D-078937EBF174@kirei.se>
	<48F5D91B.5090505@NLnetLabs.nl>
	<OF06EBCED2.4D073549-ON802574E3.00443E05-C12574E3.004C9725@nominet.org.uk>
	<9D9920CC-9809-4F1E-A486-90890C0A3ECB@nlnetlabs.nl>
Message-ID: <OFD99A254D.2341CDFF-ON80257501.0078F6CD-C1257501.007A4756@nominet.org.uk>

Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 11/10/2008 11:30:07 AM:

> Folk,
> 
> Here are a few notes from our little get-together in Dubai. I've added 
> Matthijs to the CC. Is there a mailinglist for this project.

Hi Olaf, now there is indeed a mailinglist for this project.

> --- Begin Notes ---
> 
> * There are two functions that opendnssec needs to fulfill:
>    1 - A piece of software: DNSSEC in a box
>    2 - A set of procedures and documentation initially within a wiki.
> 
>    We currently concentrate on getting piece 1 done with the 
> understanding that 1 is not complete without having it documented.
> 
> * The first phase of the project intends to be finalized by the 2nd 
> quarter of 2009.
> 
>    3 major arch components are needed for that.
>    * The KASP, with its policy language and policy engine (John 
> Dickinson is the lead for that)
>    * A PKCS#11 software engine (Richard Bondesson has that token)
>    * A signer, including zone input-output, with the ability to 
> interface using the PKCS#11 API (Jelte/NLnetLabs).
> 
> With respect to the signer the expected functionality is that it will 
> be able to take a zonefile as input and generate a signed zonefile and/ 
> or take zone-fragments (with specific requirements on ordering) and 
> sign those for insertion later.
> 
> At the end of phase 1 the expectation is that this is all packaged and 
> ready for use by IIS and Nominet and potentially other  clients.
> 
> Roy takes the token to document this and make a project plan.

Indeed.

> A few personal notes and thoughts added to this. We did refer to these 
> during the discussion but I am not sure what the level of mutual 
> commitment on these ideas was.
> 
> - As far as the input-output requirements we will need to make sure 
> that the expectations are clear. Those are to be documented in Roy's 
> requirements document (correct?)

That is correct.

> - During the meeting I referred to the 'vapor ware' that we call 
> Masterdont. The core of this idea is that we have a kernel that is 
> aware of all possible interactions with, properties off, and relations 
> of the environments with zone.
> 
> In that context I think it is important to make the zone I/O 
> intelligence and the KASP language extendible so that KASP is to 
> become a subset of a zone-policy language that not only describes the 
> signing and key properties of zones but can also describe TTL, 
> Nameserver, and content properties for zones.

KASP was specifically designed with DNSSEC in mind, and deals with the 
various timings, state and properties of keys. I think what you are 
referring to is the ability to contain KASP in NSCP. I think that generic 
configuration items should go into NSCP, and that various state properties 
of keys should remain in KASP.
 
> I have asked Matthijs to set up requirements for this (based on KASP 
> and NSCP) and come up with an architecuture of what I refer to as the 
> "Masterdont kernel". Although work on phase 1 of the project is to 
> large extend orthogonal to this idea there are a few hooks, specifically

> - Colleagues from SURFNET are interested in working along and even 
> providing resources in the form of a programmer. I am not sure if 
> there is need for adding  resources to phase 1 of the project (and if 
> we do if there is efficiency gain). But I think they should be privy 
> to the requirements document.

I think that we have covered most (all) bases with the current team. I 
have no problem adding development resources if there is a yet 
unidentified part of this project. However, I'm not convinced we more 
resources. However, since SURFNET host a large amount of zones, I can see 
value in inviting them to test the software.
 
> - At NLnet Labs we are cranking up the investments on this. Synced 
> expectations would be good?

Indeed.

> Concluding: What is the next step: A document by Roy?

Yes. 

> If we are meeting in MSP, then we need to plan a timeslot. My agenda 
> is filling fast.

I send out a quick doodle for allocating a timeslot next week.

Roy


From olaf at NLnetLabs.nl  Sat Nov 15 15:51:51 2008
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Sat, 15 Nov 2008 09:51:51 -0600
Subject: [Opendnssec-develop] Re: Our little get-together. Re: Progressing
	OpenDNSSEC.
In-Reply-To: <OFD99A254D.2341CDFF-ON80257501.0078F6CD-C1257501.007A4756@nominet.org.uk>
References: <OFD8238BB5.87BAE70D-ON802574D4.00462848-C12574E2.0035FE71@nominet.org.uk>
	<15C70C9B-4E55-42B8-8F4D-078937EBF174@kirei.se>
	<48F5D91B.5090505@NLnetLabs.nl>
	<OF06EBCED2.4D073549-ON802574E3.00443E05-C12574E3.004C9725@nominet.org.uk>
	<9D9920CC-9809-4F1E-A486-90890C0A3ECB@nlnetlabs.nl>
	<OFD99A254D.2341CDFF-ON80257501.0078F6CD-C1257501.007A4756@nominet.org.uk>
Message-ID: <447574FA-DE98-4C64-9E9F-57FB53C6E0C7@nlnetlabs.nl>

>>
>>
>> Here are a few notes from our little get-together in Dubai. I've  
>> added
>> Matthijs to the CC. Is there a mailinglist for this project.
>
> Hi Olaf, now there is indeed a mailinglist for this project.
>

Cool...

>
>
>> - During the meeting I referred to the 'vapor ware' that we call
>> Masterdont. The core of this idea is that we have a kernel that is
>> aware of all possible interactions with, properties off, and  
>> relations
>> of the environments with zone.
>>
>> In that context I think it is important to make the zone I/O
>> intelligence and the KASP language extendible so that KASP is to
>> become a subset of a zone-policy language that not only describes the
>> signing and key properties of zones but can also describe TTL,
>> Nameserver, and content properties for zones.
>
> KASP was specifically designed with DNSSEC in mind, and deals with the
> various timings, state and properties of keys. I think what you are
> referring to is the ability to contain KASP in NSCP. I think that  
> generic
> configuration items should go into NSCP, and that various state  
> properties
> of keys should remain in KASP.

That is not exactly what I refer to.

A zone can have many properties, such as the policy it is signed with,  
which keys are used to implement that policy, which nameservers it is  
served on, which clients are allowed to query it, its SOA timing  
prarameters, etc, etc. Some of these properties are expressed in the  
language that KASP will use for its configuration, others will be used  
in NSCP.

If you are starting on a framework to maintain a subset of properties  
for zones, which I think KASP is, then you better make sure you can  
add the other pieces too. Make it extendable: while not solving all of  
ones problems at once make sure you can in the future build upon the  
foundations you are setting.

>
>
>> I have asked Matthijs to set up requirements for this (based on KASP
>> and NSCP) and come up with an architecuture of what I refer to as the
>> "Masterdont kernel". Although work on phase 1 of the project is to
>> large extend orthogonal to this idea there are a few hooks,  
>> specifically
>
>> - Colleagues from SURFNET are interested in working along and even
>> providing resources in the form of a programmer. I am not sure if
>> there is need for adding  resources to phase 1 of the project (and if
>> we do if there is efficiency gain). But I think they should be privy
>> to the requirements document.
>
> I think that we have covered most (all) bases with the current team. I
> have no problem adding development resources if there is a yet
> unidentified part of this project. However, I'm not convinced we more
> resources. However, since SURFNET host a large amount of zones, I  
> can see
> value in inviting them to test the software.

I think that might be rather late. Why not use them as a sounding  
board for assessing if your current set of requirements and your  
vision would work for them?


--Olaf




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 235 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081115/2623c4da/attachment.bin>

From roy at nominet.org.uk  Sat Nov 15 23:22:49 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Sun, 16 Nov 2008 00:22:49 +0100
Subject: [Opendnssec-develop] Re: Our little get-together. Re: Progressing
	OpenDNSSEC.
In-Reply-To: <447574FA-DE98-4C64-9E9F-57FB53C6E0C7@nlnetlabs.nl>
References: <OFD8238BB5.87BAE70D-ON802574D4.00462848-C12574E2.0035FE71@nominet.org.uk>
	<15C70C9B-4E55-42B8-8F4D-078937EBF174@kirei.se>
	<48F5D91B.5090505@NLnetLabs.nl>
	<OF06EBCED2.4D073549-ON802574E3.00443E05-C12574E3.004C9725@nominet.org.uk>
	<9D9920CC-9809-4F1E-A486-90890C0A3ECB@nlnetlabs.nl>
	<OFD99A254D.2341CDFF-ON80257501.0078F6CD-C1257501.007A4756@nominet.org.uk>
	<447574FA-DE98-4C64-9E9F-57FB53C6E0C7@nlnetlabs.nl>
Message-ID: <OFD3CE3E9E.48832E2C-ON80257502.00800613-C1257502.00806E45@nominet.org.uk>

Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 11/15/2008 04:51:51 PM:

> >> - During the meeting I referred to the 'vapor ware' that we call
> >> Masterdont. The core of this idea is that we have a kernel that is
> >> aware of all possible interactions with, properties off, and 
> >> relations
> >> of the environments with zone.
> >>
> >> In that context I think it is important to make the zone I/O
> >> intelligence and the KASP language extendible so that KASP is to
> >> become a subset of a zone-policy language that not only describes the
> >> signing and key properties of zones but can also describe TTL,
> >> Nameserver, and content properties for zones.
> >
> > KASP was specifically designed with DNSSEC in mind, and deals with the
> > various timings, state and properties of keys. I think what you are
> > referring to is the ability to contain KASP in NSCP. I think that 
> > generic
> > configuration items should go into NSCP, and that various state 
> > properties
> > of keys should remain in KASP.
> 
> That is not exactly what I refer to.
> 
> A zone can have many properties, such as the policy it is signed with, 
> which keys are used to implement that policy, which nameservers it is 
> served on, which clients are allowed to query it, its SOA timing 
> prarameters, etc, etc. Some of these properties are expressed in the 
> language that KASP will use for its configuration, others will be used 
> in NSCP.

Yes.

> If you are starting on a framework to maintain a subset of properties 
> for zones, which I think KASP is, then you better make sure you can 
> add the other pieces too. Make it extendable: while not solving all of 
> ones problems at once make sure you can in the future build upon the 
> foundations you are setting.

Okay. Lets go over this face to face next week. I think we're in 
agreement, though we might not be convinced ;-)

> >> I have asked Matthijs to set up requirements for this (based on KASP
> >> and NSCP) and come up with an architecuture of what I refer to as the
> >> "Masterdont kernel". Although work on phase 1 of the project is to
> >> large extend orthogonal to this idea there are a few hooks, 
> >> specifically
> >
> >> - Colleagues from SURFNET are interested in working along and even
> >> providing resources in the form of a programmer. I am not sure if
> >> there is need for adding  resources to phase 1 of the project (and if
> >> we do if there is efficiency gain). But I think they should be privy
> >> to the requirements document.
> >
> > I think that we have covered most (all) bases with the current team. I
> > have no problem adding development resources if there is a yet
> > unidentified part of this project. However, I'm not convinced we more
> > resources. However, since SURFNET host a large amount of zones, I 
> > can see
> > value in inviting them to test the software.
> 
> I think that might be rather late. Why not use them as a sounding 
> board for assessing if your current set of requirements and your 
> vision would work for them?

That is a good idea. Could you elaborate on who is your point of contact 
within SURFNET?

Thanks,

Roy



From olaf at NLnetLabs.nl  Sun Nov 16 04:44:34 2008
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Sat, 15 Nov 2008 22:44:34 -0600
Subject: [Opendnssec-develop] Re: Our little get-together. Re: Progressing
	OpenDNSSEC.
In-Reply-To: <OFD3CE3E9E.48832E2C-ON80257502.00800613-C1257502.00806E45@nominet.org.uk>
References: <OFD8238BB5.87BAE70D-ON802574D4.00462848-C12574E2.0035FE71@nominet.org.uk>
	<15C70C9B-4E55-42B8-8F4D-078937EBF174@kirei.se>
	<48F5D91B.5090505@NLnetLabs.nl>
	<OF06EBCED2.4D073549-ON802574E3.00443E05-C12574E3.004C9725@nominet.org.uk>
	<9D9920CC-9809-4F1E-A486-90890C0A3ECB@nlnetlabs.nl>
	<OFD99A254D.2341CDFF-ON80257501.0078F6CD-C1257501.007A4756@nominet.org.uk>
	<447574FA-DE98-4C64-9E9F-57FB53C6E0C7@nlnetlabs.nl>
	<OFD3CE3E9E.48832E2C-ON80257502.00800613-C1257502.00806E45@nominet.org.uk>
Message-ID: <0C41CC23-D15A-478A-BD1C-4E011A1158A6@nlnetlabs.nl>


On Nov 15, 2008, at 5:22 PM, Roy Arends wrote:

>> I think that might be rather late. Why not use them as a sounding
>> board for assessing if your current set of requirements and your
>> vision would work for them?
>
> That is a good idea. Could you elaborate on who is your point of  
> contact
> within SURFNET?


Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> en Rogier Spoor <Rogier.Spoor at surfnet.nl 
 >


--Olaf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 235 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081115/00d3d815/attachment.bin>

From jakob at kirei.se  Mon Nov 17 10:09:00 2008
From: jakob at kirei.se (Jakob Schlyter)
Date: Mon, 17 Nov 2008 11:09:00 +0100
Subject: [Opendnssec-develop] new opendnssec mailinglist
In-Reply-To: <OFF4FDB6CE.7959A769-ON80257501.005D88B0-C1257501.005F047D@nominet.org.uk>
References: <OFF4FDB6CE.7959A769-ON80257501.005D88B0-C1257501.005F047D@nominet.org.uk>
Message-ID: <3B3FB806-9EA8-470B-9635-375876801B95@kirei.se>

On 14 nov 2008, at 18.17, Roy Arends wrote:

> Hi everybody,
>
> I've created a new list, especially for development, which contains  
> the
> following subscribers:
>
> jelte at nlnetlabs.nl
> jad at jadickinson.co.uk
> jakob at kirei.se
> Patrik.Wallstrom at iis.se
> staffan.hagnell at iis.se
> Stephen.Morris at nominet.org.uk
> matje at nlnetlabs.nl
> roy at nominet.org.uk
> Rickard.Bondesson at iis.se
> olaf at nlnetlabs.nl

there is also a separat list for subversion commit messages, please  
let me know if you want to be on that list as well. people already on  
that list knows they already are I guess.

	jakob



From jakob at kirei.se  Mon Nov 17 15:19:14 2008
From: jakob at kirei.se (Jakob Schlyter)
Date: Mon, 17 Nov 2008 16:19:14 +0100
Subject: [Opendnssec-develop] Re: Enforcer
In-Reply-To: <3D85A497-8BF7-49D5-BEC4-F6EC8AF269C8@nlnetlabs.nl>
References: <49DED752-01FF-4B4A-A2A3-4745809E762D@jadickinson.co.uk>
	<3D85A497-8BF7-49D5-BEC4-F6EC8AF269C8@nlnetlabs.nl>
Message-ID: <48FA794D-63F0-4423-85B9-02CF73B2BD98@kirei.se>

On 15 nov 2008, at 01.16, Olaf Kolkman wrote:

> I noticed a 1 to many relation between zones and keys. I can imagine  
> that one KSK and one ZSK private key is in use for many zones e.g.  
> in the context of a webhosting farm.

doesn't sharing keys between zones make key rollover "interesting"?


	jakob



From jad at jadickinson.co.uk  Mon Nov 17 15:27:55 2008
From: jad at jadickinson.co.uk (John Dickinson)
Date: Mon, 17 Nov 2008 15:27:55 +0000
Subject: [Opendnssec-develop] Re: Enforcer
In-Reply-To: <48FA794D-63F0-4423-85B9-02CF73B2BD98@kirei.se>
References: <49DED752-01FF-4B4A-A2A3-4745809E762D@jadickinson.co.uk>
	<3D85A497-8BF7-49D5-BEC4-F6EC8AF269C8@nlnetlabs.nl>
	<48FA794D-63F0-4423-85B9-02CF73B2BD98@kirei.se>
Message-ID: <06DE582A-D3CC-49C4-939C-FE0FF973B5AE@jadickinson.co.uk>


On 17 Nov 2008, at 15:19, Jakob Schlyter wrote:

> On 15 nov 2008, at 01.16, Olaf Kolkman wrote:
>
>> I noticed a 1 to many relation between zones and keys. I can  
>> imagine that one KSK and one ZSK private key is in use for many  
>> zones e.g. in the context of a webhosting farm.
>
> doesn't sharing keys between zones make key rollover "interesting"?

Also, Wouldn't you only share keys when it was too much effort to  
manage a key for each zone. OpenDNSSEC will be so easy to use that  
100,000 keys will be no effort at all :)

John


From jad at jadickinson.co.uk  Wed Nov 19 13:13:53 2008
From: jad at jadickinson.co.uk (John Dickinson)
Date: Wed, 19 Nov 2008 13:13:53 +0000
Subject: [Opendnssec-develop] Re: Enforcer
In-Reply-To: <48FA794D-63F0-4423-85B9-02CF73B2BD98@kirei.se>
References: <49DED752-01FF-4B4A-A2A3-4745809E762D@jadickinson.co.uk>
	<3D85A497-8BF7-49D5-BEC4-F6EC8AF269C8@nlnetlabs.nl>
	<48FA794D-63F0-4423-85B9-02CF73B2BD98@kirei.se>
Message-ID: <0A246AC9-F339-4D55-A055-45DC55EE9946@jadickinson.co.uk>


Thanks for the comments. I like Jakob's idea of ZoneGroups and unless  
someone has a better suggestion then I plan to add that to the schema.

I have been getting to grips with Stephen's KSM code to see how it  
might be used in OpenDNSSEC. I really like it.

Here are a few diagrams that summarize how I think KSM fits together.  
Stephen - please shout if it is wrong?

http://www.opendnssec.com/browser/docs/KSM.pdf?format=raw
http://www.opendnssec.com/browser/docs/KSMCreateKey.pdf?format=raw
http://www.opendnssec.com/browser/docs/KSMDeleteKey.pdf?format=raw

This is how I imagine integrating it into the first version of the  
enforcer:

http://www.opendnssec.com/browser/docs/Enforcer.pdf?format=raw
http://www.opendnssec.com/browser/docs/osdKeys.pdf?format=raw

Any thoughts?

Thanks
John


From jad at jadickinson.co.uk  Wed Nov 19 14:22:34 2008
From: jad at jadickinson.co.uk (John Dickinson)
Date: Wed, 19 Nov 2008 14:22:34 +0000
Subject: Fwd: [Opendnssec-develop] Re: Enforcer
References: <0A246AC9-F339-4D55-A055-45DC55EE9946@jadickinson.co.uk>
Message-ID: <32C3EC80-8C5E-4346-A4B7-9FACD6F28E9F@jadickinson.co.uk>



Begin forwarded message:

> From: John Dickinson <jad at jadickinson.co.uk>
> Date: 19 November 2008 13:13:53 GMT
> To: opendnssec-develop at lists.opendnssec.org
> Subject: Re: [Opendnssec-develop] Re: Enforcer
>
>
> Thanks for the comments. I like Jakob's idea of ZoneGroups and  
> unless someone has a better suggestion then I plan to add that to  
> the schema.

Not sure where I dreamt that - I meant Jakob's idea of policies to  
contain the parameters.

John


From patrik.wallstrom at iis.se  Mon Nov 24 14:01:09 2008
From: patrik.wallstrom at iis.se (Patrik Wallstrom)
Date: Mon, 24 Nov 2008 15:01:09 +0100
Subject: [Opendnssec-develop] Re: Enforcer
In-Reply-To: <48FA794D-63F0-4423-85B9-02CF73B2BD98@kirei.se>
References: <49DED752-01FF-4B4A-A2A3-4745809E762D@jadickinson.co.uk>
	<3D85A497-8BF7-49D5-BEC4-F6EC8AF269C8@nlnetlabs.nl>
	<48FA794D-63F0-4423-85B9-02CF73B2BD98@kirei.se>
Message-ID: <2DBDC7D2-8DEE-40A8-9761-3AF8735F4BAB@iis.se>


On Nov 17, 2008, at 4:19 PM, Jakob Schlyter wrote:

>> I noticed a 1 to many relation between zones and keys. I can  
>> imagine that one KSK and one ZSK private key is in use for many  
>> zones e.g. in the context of a webhosting farm.
>
> doesn't sharing keys between zones make key rollover "interesting"?

.cz allows having the same key for many zones...
Yes, interesting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081124/ef93bb99/attachment.bin>

From jad at jadickinson.co.uk  Thu Nov 27 10:25:24 2008
From: jad at jadickinson.co.uk (John Dickinson)
Date: Thu, 27 Nov 2008 10:25:24 +0000
Subject: [Opendnssec-develop] Creating keys
Message-ID: <950B8719-09E2-460D-BEC5-5BF2CE81925B@jadickinson.co.uk>

Lacking anyone physically present who cares about DNS, DNSSEC or keys  
to bounce thoughts off I am going to use this mailing list :)

I am working on the key creation logic of the enforcer.

A policy is used to specify key and signing parameters for a zone or  
set of zones.

Lets look at an example, say the policy specifies that the algorithm  
to be used for new KSKs is 5 and that the algorithm to be used for  
ZSKs is 11. (ignore for now any technicalities of exactly how you  
switch to a new algorithm.). Keys for both KSKs and ZSKs are to be  
stored in security module 1.

The enforcer will start for the FIRST TIME and examine the policy - it  
will see that it needs keys of types 5 and 11. It knows (because we  
told it) that the capacity of security module 1 is 1000 keys.

Key generation is expensive so I was planning to pre-create as many  
keys as possible. So first of all I thought the Enforcer could create  
500 keys of each algorithm. Great - that is easy. But consider the  
following events in the future...

1. Additional policy using same key algorithms
at some time later we create a second policy which specifies that it  
needs KSKs with alg 5 and ZSKs with alg 5. Fine there are 500 (minus  
any we have used) of alg 5 keys we just start using them for policy 2.

2. Additional policy using new key algorithms
at some time later we create a third policy which specifies that it  
needs KSKs with alg 6 and ZSKs with alg 12. Oh no! the security module  
is full. What do we do?

3. Change an existing policy to use new algorithm.
at some time later we modify the first policy to say that new keys  
must use alg 94. Oh no! the security module is full. What do we do?


Solution:
This is the logic I intend use to get round this.
Policy will also specify a minimum number of unused keys that must  
exist.
policy->zsk->alg = 5
policy->zsk->keymincount = 100
policy->ksk->alg = 11
policy->ksk->keymincount = 20

as before there will be a known capacity of the security module. Lets  
say 300.

The enforcer will start for the FIRST TIME and examine the policy - it  
will see that it needs keys of types 5 and 11. It will create 100 alg  
5 and 20 alg 11 keys

1. Additional policy using same key algorithms
at some time later we create a second policy which specifies that it  
needs 100 ZSKs with alg 5 and 20 KSKs with alg 11. Fine there is still  
180 spaces for keys in the security module - create another 100 alg 5  
and 20 alg 11 keys

2. Additional policy using new key algorithms
at some time later we create a third policy which specifies that it  
needs 200 ZSKs with alg 6 and 50 KSKs with alg 12. OK there is room  
for the 50 alg 12 keys but not for 200 alg 6. So the Enforcer will  
scan for dead keys and delete them. If there is now room for 200 more  
keys then great - if not then WARN.

3. Change an existing policy to use new algorithm.
There was room... at some time later we modify the first policy to say  
that new keys ksk and zsk must use alg 94 min still 100 and 20. the  
Enforcer will scan for dead keys and delete them. If there is now room  
for 120 more keys then great - if not then WARN.

Each time the policy is read a check will be made of the number of un- 
used keys available. If for a particular algorithm there is less than  
the sum over all policies of keymincount then new keys will be created.

Assuming keys are being used regularly this will cause new keys to be  
created regularly. We might want a threshold saying don?t create new  
keys unless we are x many below the minimum.

BTW if you set keymincount = a small number <= no of keys in use then  
you are effectively saying don't pre-create keys.

Note: the above says nothing about keys getting used. Even if new keys  
can not be created - If there are un-used keys available then  
scheduled key rollovers will continue. If at any time there are no new  
keys available then the Enforcer will scan for dead keys and delete  
them. If there is now room for more keys then great - if not then key  
rollover will stop - (re-)signing will always continue...

I am not really asking any questions but if what I wrote seems stupid  
then please shout.

John




From olaf at NLnetLabs.nl  Thu Nov 27 11:59:30 2008
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Thu, 27 Nov 2008 12:59:30 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <950B8719-09E2-460D-BEC5-5BF2CE81925B@jadickinson.co.uk>
References: <950B8719-09E2-460D-BEC5-5BF2CE81925B@jadickinson.co.uk>
Message-ID: <429E698B-C206-4FDB-92F2-CAEAEB8B7FC8@NLnetLabs.nl>


On Nov 27, 2008, at 11:25 AM, John Dickinson wrote:

> Lacking anyone physically present who cares about DNS, DNSSEC or  
> keys to bounce thoughts off I am going to use this mailing list :)
>
> I am working on the key creation logic of the enforcer.
>
> A policy is used to specify key and signing parameters for a zone or  
> set of zones.
>
> Lets look at an example, say the policy specifies that the algorithm  
> to be used for new KSKs is 5 and that the algorithm to be used for  
> ZSKs is 11. (ignore for now any technicalities of exactly how you  
> switch to a new algorithm.). Keys for both KSKs and ZSKs are to be  
> stored in security module 1.
>
> The enforcer will start for the FIRST TIME and examine the policy -  
> it will see that it needs keys of types 5 and 11. It knows (because  
> we told it) that the capacity of security module 1 is 1000 keys.
>
> Key generation is expensive so I was planning to pre-create as many  
> keys as possible. So first of all I thought the Enforcer could  
> create 500 keys of each algorithm. Great - that is easy. But  
> consider the following events in the future...
>

The whole argument is build on the presumption that Key generation is  
so expensive you need to pre-create that many. I do not understand  
that point. In the context of resigning a zone the key-generation is  
only a fraction of the expensed isn't it?

My, maybe naive, thinking is that you only generate keys when you  
actually are about to use them?

--Olaf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 235 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081127/5238cbe1/attachment.bin>

From jad at jadickinson.co.uk  Thu Nov 27 15:54:56 2008
From: jad at jadickinson.co.uk (John Dickinson)
Date: Thu, 27 Nov 2008 15:54:56 +0000
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <429E698B-C206-4FDB-92F2-CAEAEB8B7FC8@NLnetLabs.nl>
References: <950B8719-09E2-460D-BEC5-5BF2CE81925B@jadickinson.co.uk>
	<429E698B-C206-4FDB-92F2-CAEAEB8B7FC8@NLnetLabs.nl>
Message-ID: <EADC09C6-F7ED-4DA5-B7DD-5327F141D55E@jadickinson.co.uk>


On 27 Nov 2008, at 11:59, Olaf Kolkman wrote:

>
> On Nov 27, 2008, at 11:25 AM, John Dickinson wrote:
>
>> Lacking anyone physically present who cares about DNS, DNSSEC or  
>> keys to bounce thoughts off I am going to use this mailing list :)
>>
>> I am working on the key creation logic of the enforcer.
>>
>> A policy is used to specify key and signing parameters for a zone  
>> or set of zones.
>>
>> Lets look at an example, say the policy specifies that the  
>> algorithm to be used for new KSKs is 5 and that the algorithm to be  
>> used for ZSKs is 11. (ignore for now any technicalities of exactly  
>> how you switch to a new algorithm.). Keys for both KSKs and ZSKs  
>> are to be stored in security module 1.
>>
>> The enforcer will start for the FIRST TIME and examine the policy -  
>> it will see that it needs keys of types 5 and 11. It knows (because  
>> we told it) that the capacity of security module 1 is 1000 keys.
>>
>> Key generation is expensive so I was planning to pre-create as many  
>> keys as possible. So first of all I thought the Enforcer could  
>> create 500 keys of each algorithm. Great - that is easy. But  
>> consider the following events in the future...
>>
>
> The whole argument is build on the presumption that Key generation  
> is so expensive you need to pre-create that many. I do not  
> understand that point. In the context of resigning a zone the key- 
> generation is only a fraction of the expensed isn't it?
>
> My, maybe naive, thinking is that you only generate keys when you  
> actually are about to use them?
>

True, these are the figures for RSA keys generation on a SCA6000

key size | time/sec
-------------------
256      |  0.7
512      |  0.8
1024     |  1.1
2048     |  1.9

Signing speed is 14,000 sig/sec per card (tested at 40,000 sig/sec by  
Roy with 3 SCA cards). So whilst a second or two is not long it is  
very expensive compared with signing.

So I guess if you have a large zone like co.uk then a couple of  
seconds in the 6 odd minutes that it would take to sign from scratch  
is nothing. However, if you have 1000's of small zones or you are  
dynamically updating every minute then it could make a big difference.

Roy - I know you have thought about this - any comments?
John




From olaf at NLnetLabs.nl  Thu Nov 27 16:01:26 2008
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Thu, 27 Nov 2008 17:01:26 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <EADC09C6-F7ED-4DA5-B7DD-5327F141D55E@jadickinson.co.uk>
References: <950B8719-09E2-460D-BEC5-5BF2CE81925B@jadickinson.co.uk>
	<429E698B-C206-4FDB-92F2-CAEAEB8B7FC8@NLnetLabs.nl>
	<EADC09C6-F7ED-4DA5-B7DD-5327F141D55E@jadickinson.co.uk>
Message-ID: <69748EBA-0D42-4283-A48D-561A53DE2121@NLnetLabs.nl>


On Nov 27, 2008, at 4:54 PM, John Dickinson wrote:

>
> So I guess if you have a large zone like co.uk then a couple of  
> seconds in the 6 odd minutes that it would take to sign from scratch  
> is nothing. However, if you have 1000's of small zones or you are  
> dynamically updating every minute then it could make a big difference.

But even then... the key-rollover would take place only once per month  
or so. So this 2 second pain per zone only happens once or twice per  
month.



--Olaf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 235 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081127/754b3bbd/attachment.bin>

From roy at nominet.org.uk  Fri Nov 28 16:26:49 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Fri, 28 Nov 2008 16:26:49 +0000
Subject: [Opendnssec-develop] project plan and SURFnet
Message-ID: <OFD7B3696C.4A0E4A01-ON8025750F.003EC220-C125750F.005A58C6@nominet.org.uk>

Dear OpenDNSSEC folk,

I have yet to finish the project plan (I'm not slacking, just swamped), 
but will dump here what I already have (see attached pdf) written. It 
contains the high level overview of components (which we already assigned 
to different folk).

Yesterday, I went to NLNetLabs office to talk with Olaf, Jelte and folks 
from SURFnet (the dutch academic network) about OpenDNSSEC. Rogier Spoor 
and Roland van Rijswijk both work for SURFnet, and Rick van Rein works for 
OpenFortress.

SURFnet are in need of a solution, and the solution they had in mind is 
exactly what OpenDNSSEC is. They are interested in joining the effort, as 
their constituency have requested DNSSEC to be deployed on the zones that 
SURFnet hosts for the academic networks. They are the other extreme of a 
single, very large zone: very large amount of small zones.

We do not really need more developers joining the project, however, Roland 
van Rijswijk has significant PKCS11 skills, as he helped develop the 
PKCS11 standards. So I'd like him to have a look at both sides of the 
PKCS11 API (Rickards softHSM, and Jelte's ldns interface to pkcs11). Rick 
van Rein has also significant security skills. 

I've added them to our mailing list.

Thanks,

Roy Arends
Sr Researcher
Nominet UK

-------------- next part --------------
A non-text attachment was scrubbed...
Name: opendnssec.pdf
Type: application/pdf
Size: 70054 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081128/b74d4193/attachment.pdf>

From Stephen.Morris at nominet.org.uk  Fri Nov 28 16:47:32 2008
From: Stephen.Morris at nominet.org.uk (Stephen.Morris at nominet.org.uk)
Date: Fri, 28 Nov 2008 16:47:32 +0000
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <69748EBA-0D42-4283-A48D-561A53DE2121@NLnetLabs.nl>
Message-ID: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>

Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 27/11/2008 16:01:26:

> 
> On Nov 27, 2008, at 4:54 PM, John Dickinson wrote:
> 
> >
> > So I guess if you have a large zone like co.uk then a couple of 
> > seconds in the 6 odd minutes that it would take to sign from scratch 
> > is nothing. However, if you have 1000's of small zones or you are 
> > dynamically updating every minute then it could make a big difference.
> 
> But even then... the key-rollover would take place only once per month 
> or so. So this 2 second pain per zone only happens once or twice per 
> month.

In this approach, are there any problems in ensuring that the keys are 
replicated to a backup HSM before they are used?  Do you need any type of 
"master" password to export private keys from the HSM?

Stephen


From roland.vanrijswijk at surfnet.nl  Fri Nov 28 17:08:34 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Fri, 28 Nov 2008 18:08:34 +0100
Subject: [Opendnssec-develop] project plan and SURFnet
In-Reply-To: <OFD7B3696C.4A0E4A01-ON8025750F.003EC220-C125750F.005A58C6@nominet.org.uk>
References: <OFD7B3696C.4A0E4A01-ON8025750F.003EC220-C125750F.005A58C6@nominet.org.uk>
Message-ID: <49302592.5060603@surfnet.nl>

Hi Roy,

Thanks for introducing SURFnet on the list. I would like to make one
minor correction: I have not co-authored the PKCS #11 specs, but have
spent some 4 years developing a commercial PKCS #11 module for use with
cryptographic smart cards (and thus know a lot about the ins and outs of
the spec). Just to make sure no-one overestimates my fame ;-)

Cheers,

Roland van Rijswijk

Roy Arends wrote:
> Dear OpenDNSSEC folk,
> 
> I have yet to finish the project plan (I'm not slacking, just swamped), 
> but will dump here what I already have (see attached pdf) written. It 
> contains the high level overview of components (which we already assigned 
> to different folk).
> 
> Yesterday, I went to NLNetLabs office to talk with Olaf, Jelte and folks 
> from SURFnet (the dutch academic network) about OpenDNSSEC. Rogier Spoor 
> and Roland van Rijswijk both work for SURFnet, and Rick van Rein works for 
> OpenFortress.
> 
> SURFnet are in need of a solution, and the solution they had in mind is 
> exactly what OpenDNSSEC is. They are interested in joining the effort, as 
> their constituency have requested DNSSEC to be deployed on the zones that 
> SURFnet hosts for the academic networks. They are the other extreme of a 
> single, very large zone: very large amount of small zones.
> 
> We do not really need more developers joining the project, however, Roland 
> van Rijswijk has significant PKCS11 skills, as he helped develop the 
> PKCS11 standards. So I'd like him to have a look at both sides of the 
> PKCS11 API (Rickards softHSM, and Jelte's ldns interface to pkcs11). Rick 
> van Rein has also significant security skills. 
> 
> I've added them to our mailing list.
> 
> Thanks,
> 
> Roy Arends
> Sr Researcher
> Nominet UK
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop


-- 

-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From roy at nominet.org.uk  Fri Nov 28 17:09:34 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Fri, 28 Nov 2008 18:09:34 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <950B8719-09E2-460D-BEC5-5BF2CE81925B@jadickinson.co.uk>
References: <950B8719-09E2-460D-BEC5-5BF2CE81925B@jadickinson.co.uk>
Message-ID: <OF192526EE.202CF7AA-ON8025750E.00408580-C125750F.005E4259@nominet.org.uk>

John Dickinson wrote on 11/27/2008 11:25:24 AM:

> Lacking anyone physically present who cares about DNS, DNSSEC or keys 
> to bounce thoughts off I am going to use this mailing list :)
> 
> I am working on the key creation logic of the enforcer.
> 
> A policy is used to specify key and signing parameters for a zone or 
> set of zones.
> 
> Lets look at an example, say the policy specifies that the algorithm 
> to be used for new KSKs is 5 and that the algorithm to be used for 
> ZSKs is 11. (ignore for now any technicalities of exactly how you 
> switch to a new algorithm.). Keys for both KSKs and ZSKs are to be 
> stored in security module 1.
> 
> The enforcer will start for the FIRST TIME and examine the policy - it 
> will see that it needs keys of types 5 and 11. It knows (because we 
> told it) that the capacity of security module 1 is 1000 keys.
> 
> Key generation is expensive so I was planning to pre-create as many 
> keys as possible.

Though I understand that key generation is expensive, in practice there is 
really no need to switch keys every minute. So, why not pre-create as many 
keys as needed, instead of as much as possible? I don't think there is a 
requirement that zones are dumped en-masse in the opendnssec daemon, and 
expected to work _on the spot_. I have no problem with a little initiation 
time. Keep in mind that when these zones are dumped en-mass, the 
key-generation time is not the bottleneck. Getting every zone completely 
signed asap is the bottleneck imho.

Hope this helps.

> So first of all I thought the Enforcer could create 
> 500 keys of each algorithm. Great - that is easy. But consider the 
> following events in the future...
> 
> 1. Additional policy using same key algorithms
> at some time later we create a second policy which specifies that it 
> needs KSKs with alg 5 and ZSKs with alg 5. Fine there are 500 (minus 
> any we have used) of alg 5 keys we just start using them for policy 2.
> 
> 2. Additional policy using new key algorithms
> at some time later we create a third policy which specifies that it 
> needs KSKs with alg 6 and ZSKs with alg 12. Oh no! the security module 
> is full. What do we do?
> 
> 3. Change an existing policy to use new algorithm.
> at some time later we modify the first policy to say that new keys 
> must use alg 94. Oh no! the security module is full. What do we do?
> 
> 
> Solution:
> This is the logic I intend use to get round this.
> Policy will also specify a minimum number of unused keys that must 
> exist.
> policy->zsk->alg = 5
> policy->zsk->keymincount = 100
> policy->ksk->alg = 11
> policy->ksk->keymincount = 20
> 
> as before there will be a known capacity of the security module. Lets 
> say 300.
> 
> The enforcer will start for the FIRST TIME and examine the policy - it 
> will see that it needs keys of types 5 and 11. It will create 100 alg 
> 5 and 20 alg 11 keys
> 
> 1. Additional policy using same key algorithms
> at some time later we create a second policy which specifies that it 
> needs 100 ZSKs with alg 5 and 20 KSKs with alg 11. Fine there is still 
> 180 spaces for keys in the security module - create another 100 alg 5 
> and 20 alg 11 keys
> 
> 2. Additional policy using new key algorithms
> at some time later we create a third policy which specifies that it 
> needs 200 ZSKs with alg 6 and 50 KSKs with alg 12. OK there is room 
> for the 50 alg 12 keys but not for 200 alg 6. So the Enforcer will 
> scan for dead keys and delete them. If there is now room for 200 more 
> keys then great - if not then WARN.
> 
> 3. Change an existing policy to use new algorithm.
> There was room... at some time later we modify the first policy to say 
> that new keys ksk and zsk must use alg 94 min still 100 and 20. the 
> Enforcer will scan for dead keys and delete them. If there is now room 
> for 120 more keys then great - if not then WARN.
> 
> Each time the policy is read a check will be made of the number of un- 
> used keys available. If for a particular algorithm there is less than 
> the sum over all policies of keymincount then new keys will be created.
> 
> Assuming keys are being used regularly this will cause new keys to be 
> created regularly. We might want a threshold saying don?t create new 
> keys unless we are x many below the minimum.
> 
> BTW if you set keymincount = a small number <= no of keys in use then 
> you are effectively saying don't pre-create keys.
> 
> Note: the above says nothing about keys getting used. Even if new keys 
> can not be created - If there are un-used keys available then 
> scheduled key rollovers will continue. If at any time there are no new 
> keys available then the Enforcer will scan for dead keys and delete 
> them. If there is now room for more keys then great - if not then key 
> rollover will stop - (re-)signing will always continue...
> 
> I am not really asking any questions but if what I wrote seems stupid 
> then please shout.


Roy


From roy at nominet.org.uk  Fri Nov 28 17:10:50 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Fri, 28 Nov 2008 18:10:50 +0100
Subject: [Opendnssec-develop] project plan and SURFnet
In-Reply-To: <49302592.5060603@surfnet.nl>
References: <OFD7B3696C.4A0E4A01-ON8025750F.003EC220-C125750F.005A58C6@nominet.org.uk>
	<49302592.5060603@surfnet.nl>
Message-ID: <OF8EA13242.7FB39920-ON8025750F.005E4BC1-C125750F.005E600C@nominet.org.uk>

Roland van Rijswijk <roland.vanrijswijk at surfnet.nl> wrote on 11/28/2008 
06:08:34 PM:

> Hi Roy,
> 
> Thanks for introducing SURFnet on the list. I would like to make one
> minor correction: I have not co-authored the PKCS #11 specs, but have
> spent some 4 years developing a commercial PKCS #11 module for use with
> cryptographic smart cards (and thus know a lot about the ins and outs of
> the spec). Just to make sure no-one overestimates my fame ;-)
> 
> Cheers,

Thanks for the update,

Roy


From roy at nominet.org.uk  Fri Nov 28 17:31:37 2008
From: roy at nominet.org.uk (Roy Arends)
Date: Fri, 28 Nov 2008 18:31:37 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
References: <69748EBA-0D42-4283-A48D-561A53DE2121@NLnetLabs.nl>
	<OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
Message-ID: <OFE4B69301.19C333AF-ON8025750F.005EA6D5-C125750F.00604774@nominet.org.uk>

Stephen Morris wrote on 11/28/2008 05:47:32 PM:

> Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 27/11/2008 16:01:26:
> 
> > 
> > On Nov 27, 2008, at 4:54 PM, John Dickinson wrote:
> > 
> > >
> > > So I guess if you have a large zone like co.uk then a couple of 
> > > seconds in the 6 odd minutes that it would take to sign from scratch 

> > > is nothing. However, if you have 1000's of small zones or you are 
> > > dynamically updating every minute then it could make a big 
difference.
> > 
> > But even then... the key-rollover would take place only once per month 

> > or so. So this 2 second pain per zone only happens once or twice per 
> > month.
> 
> In this approach, are there any problems in ensuring that the keys are 
> replicated to a backup HSM before they are used?  Do you need any type 
of 
> "master" password to export private keys from the HSM?

I guess in a situation where the procedures require that keys need to be 
backed up, it is up to the specific HSM implementation if such a scenario 
is possible. Different HSMs use different methods. For instance, to be 
fully FIPS 140-2 level 3 compliant, the HSM needs to be in complete "do 
not export" state, which guarantees that keys stored on an HSM can't be 
exported. Another requirement is that "do not export" is irreversible. 

What I think is fairly common is that a keystore (containing the actual 
private DNSKEY's) is an encrypted filesystem (the individual files are 
encrypted, not the directory structure) on a regular disk, while the 
Keystore Decryption Key (or Master Key, or SuperKey or RootToken, all 
depending on which vendor you talk to) resides physically in the HSM. This 
Decryption key can actually be synchronised between the various HSMs (of 
the same brand, as there is currently no standard defined way). There are 
different methods to do this. Once the decrytion key is equal on all HSMs, 
keystores can be read by all involved HSMs, while the same encrypted 
keystores (filesystems) can be backed-up, replicated, etc.

However, since the methods on key-retrieval, backup, recovery is so 
incredibly vendor specific, I think that is out of scope. We should just 
allow the system to be able to pre-generate keys, in order to allow 
redundant keystores. 

Hope this helps,

Roy Arends
Sr. Researcher
Nominet UK


From jad at jadickinson.co.uk  Fri Nov 28 18:03:27 2008
From: jad at jadickinson.co.uk (John Dickinson)
Date: Fri, 28 Nov 2008 18:03:27 +0000
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <OFE4B69301.19C333AF-ON8025750F.005EA6D5-C125750F.00604774@nominet.org.uk>
References: <69748EBA-0D42-4283-A48D-561A53DE2121@NLnetLabs.nl>
	<OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
	<OFE4B69301.19C333AF-ON8025750F.005EA6D5-C125750F.00604774@nominet.org.uk>
Message-ID: <E7DE3DD8-E518-41DF-83C0-3D4F68EA2027@jadickinson.co.uk>


On 28 Nov 2008, at 17:31, Roy Arends wrote:

> Stephen Morris wrote on 11/28/2008 05:47:32 PM:
>
>> Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 27/11/2008 16:01:26:
>>
>>>
>>> On Nov 27, 2008, at 4:54 PM, John Dickinson wrote:
>>>
>>>>
>>>> So I guess if you have a large zone like co.uk then a couple of
>>>> seconds in the 6 odd minutes that it would take to sign from  
>>>> scratch
>
>>>> is nothing. However, if you have 1000's of small zones or you are
>>>> dynamically updating every minute then it could make a big
> difference.
>>>
>>> But even then... the key-rollover would take place only once per  
>>> month
>
>>> or so. So this 2 second pain per zone only happens once or twice per
>>> month.
>>
>> In this approach, are there any problems in ensuring that the keys  
>> are
>> replicated to a backup HSM before they are used?  Do you need any  
>> type
> of
>> "master" password to export private keys from the HSM?
>
> I guess in a situation where the procedures require that keys need  
> to be
> backed up, it is up to the specific HSM implementation if such a  
> scenario
> is possible. Different HSMs use different methods. For instance, to be
> fully FIPS 140-2 level 3 compliant, the HSM needs to be in complete  
> "do
> not export" state, which guarantees that keys stored on an HSM can't  
> be
> exported. Another requirement is that "do not export" is irreversible.

This means that to allow for backup you might want to have the key  
generation on a separate machine - I did once imagine a system where  
an offline server generated keys in a "master" HSM. The HSM backup  
system was then used to copy those keys to HSMs to be attached to the  
signing server. This would allow the HSMs attached to the signer to be  
locked (backups not possible). (But then again, can you have one HSM  
that is the duplicate of another where one is in FIPS 140-2 level 3  
and one not??)

>
> What I think is fairly common is that a keystore (containing the  
> actual
> private DNSKEY's) is an encrypted filesystem (the individual files are
> encrypted, not the directory structure) on a regular disk, while the
> Keystore Decryption Key (or Master Key, or SuperKey or RootToken, all
> depending on which vendor you talk to) resides physically in the  
> HSM. This

We have had this conversation elsewhere: But WHY? Just use an HSM or  
soft token for all the keys :)

>
> Decryption key can actually be synchronised between the various HSMs  
> (of
> the same brand, as there is currently no standard defined way).  
> There are
> different methods to do this. Once the decrytion key is equal on all  
> HSMs,
> keystores can be read by all involved HSMs, while the same encrypted
> keystores (filesystems) can be backed-up, replicated, etc.
>
>
> However, since the methods on key-retrieval, backup, recovery is so
> incredibly vendor specific, I think that is out of scope. We should  
> just

I agree, key backup is outside the scope of OpenDNSSEC and should be  
done according to the mechanism designed by the HSM manufacturer.  
Ability to do this would be a consideration when selecting an HSM or  
soft token.

However, I do agree with Stephen, an operator might want a chance to  
know that they had backups before deciding to use a key. Given that  
backup is likely to be a manual step maybe pre-creation is needed, at  
least for some people. Maybe we need a backup interval between  
generation and publication.

>
> allow the system to be able to pre-generate keys, in order to allow
> redundant keystores.

I am a bit confused - is that pre-generate the same as the "So, why  
not pre-create as many keys as needed, instead of as much as  
possible?" in the previous email? BTW - how many is "as many keys as  
needed"? Enough for the immediate key rollover that the enforcer is  
trying to do or enough for all the key rollovers planned in the next x  
minutes?

Or should we allow the operator to select pre-generate or only  
generate the minimum needed?
John


From roland.vanrijswijk at surfnet.nl  Fri Nov 28 20:52:36 2008
From: roland.vanrijswijk at surfnet.nl (Roland van Rijswijk)
Date: Fri, 28 Nov 2008 21:52:36 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <E7DE3DD8-E518-41DF-83C0-3D4F68EA2027@jadickinson.co.uk>
References: <69748EBA-0D42-4283-A48D-561A53DE2121@NLnetLabs.nl>	<OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>	<OFE4B69301.19C333AF-ON8025750F.005EA6D5-C125750F.00604774@nominet.org.uk>
	<E7DE3DD8-E518-41DF-83C0-3D4F68EA2027@jadickinson.co.uk>
Message-ID: <49305A14.4080704@surfnet.nl>

Hi all,

Just thought I'd contribute my 2 cents to the discussion.

John Dickinson wrote:
> 
> On 28 Nov 2008, at 17:31, Roy Arends wrote:
> 
>> Stephen Morris wrote on 11/28/2008 05:47:32 PM:
>>
>>> Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 27/11/2008 16:01:26:
>>>
>>>>
>>>> On Nov 27, 2008, at 4:54 PM, John Dickinson wrote:
>>>>
>>>>>
>>>>> So I guess if you have a large zone like co.uk then a couple of
>>>>> seconds in the 6 odd minutes that it would take to sign from scratch
>>
>>>>> is nothing. However, if you have 1000's of small zones or you are
>>>>> dynamically updating every minute then it could make a big
>> difference.
>>>>
>>>> But even then... the key-rollover would take place only once per month
>>
>>>> or so. So this 2 second pain per zone only happens once or twice per
>>>> month.
>>>
>>> In this approach, are there any problems in ensuring that the keys are
>>> replicated to a backup HSM before they are used?  Do you need any type
>> of
>>> "master" password to export private keys from the HSM?
>>
>> I guess in a situation where the procedures require that keys need to be
>> backed up, it is up to the specific HSM implementation if such a scenario
>> is possible. Different HSMs use different methods. For instance, to be
>> fully FIPS 140-2 level 3 compliant, the HSM needs to be in complete "do
>> not export" state, which guarantees that keys stored on an HSM can't be
>> exported. Another requirement is that "do not export" is irreversible.
> 
> This means that to allow for backup you might want to have the key 
> generation on a separate machine - I did once imagine a system where an 
> offline server generated keys in a "master" HSM. The HSM backup system 
> was then used to copy those keys to HSMs to be attached to the signing 
> server. This would allow the HSMs attached to the signer to be locked 
> (backups not possible). (But then again, can you have one HSM that is 
> the duplicate of another where one is in FIPS 140-2 level 3 and one not??)
> 
>>
>> What I think is fairly common is that a keystore (containing the actual
>> private DNSKEY's) is an encrypted filesystem (the individual files are
>> encrypted, not the directory structure) on a regular disk, while the
>> Keystore Decryption Key (or Master Key, or SuperKey or RootToken, all
>> depending on which vendor you talk to) resides physically in the HSM. 
>> This
> 
> We have had this conversation elsewhere: But WHY? Just use an HSM or 
> soft token for all the keys :)
> 
>>
>> Decryption key can actually be synchronised between the various HSMs (of
>> the same brand, as there is currently no standard defined way). There are
>> different methods to do this. Once the decrytion key is equal on all 
>> HSMs,
>> keystores can be read by all involved HSMs, while the same encrypted
>> keystores (filesystems) can be backed-up, replicated, etc.
>>
>>
>> However, since the methods on key-retrieval, backup, recovery is so
>> incredibly vendor specific, I think that is out of scope. We should just
> 
> I agree, key backup is outside the scope of OpenDNSSEC and should be 
> done according to the mechanism designed by the HSM manufacturer. 
> Ability to do this would be a consideration when selecting an HSM or 
> soft token.

I agree as well, I know of quite a few HSM manufacturers that use the 
model described above (master key in the HSM, actual key material stored 
on disk with ways to restore the master key). A good example is nCipher.

I'm pretty sure each manufacturer provides their own methods for backing 
up and restoring key material and also for duplicating security worlds 
across multiple distributed HSMs.

In my opinion, functionality like key backup should be addressed in 
something like a manual (it's something operators should at least think 
about) but should not be solved by OpenDNSSEC. HSM manufacturers have 
much more experience in this which should be leveraged. Unfortunately 
they also have widely varying implementations which makes it hard to 
specify a single statement on how to go about backing up your keys :-(.

> However, I do agree with Stephen, an operator might want a chance to 
> know that they had backups before deciding to use a key. Given that 
> backup is likely to be a manual step maybe pre-creation is needed, at 
> least for some people. Maybe we need a backup interval between 
> generation and publication.

It's a good point that operators may want to have some assurance about 
having a backup. The trouble is that it is going to be hard to ascertain 
this by querying the HSM. There is no 'this key is backed up' flag in 
PKCS #11. For these reasons I'm doubtful whether there should be a 
technical facility in OpenDNSSEC to enforce this. What I could imagine 
is that an operator knows the creation date of a key (which should thus 
be stored somewhere) and knows the last time the HSM was backed up and 
can thus manually verify that a backup is available.

> 
>>
>> allow the system to be able to pre-generate keys, in order to allow
>> redundant keystores.
> 
> I am a bit confused - is that pre-generate the same as the "So, why not 
> pre-create as many keys as needed, instead of as much as possible?" in 
> the previous email? BTW - how many is "as many keys as needed"? Enough 
> for the immediate key rollover that the enforcer is trying to do or 
> enough for all the key rollovers planned in the next x minutes?

Although key generation is computationally expensive, this should not be 
overestimated. Especially for ZSKs where the key size is likely to be 
limited to something like 1024 bits, key generation is not that hard to 
do, especially for some special purpose hardware like a HSM. This only 
becomes an issue for KSKs which are rolled over far less often. IMHO it 
should be possible to work out the number of keys that should be kept in 
store according to some formula based on the number of zones (thus ZSKs 
and KSKs), the validity period of each key and a worst case scenario 
where all keys expire at the same time (which is unlikely) and then 
provide enough keys to roll over each key at least n-times where n is 
configurable.

Then there could be a background daemon that chugs away at a lower 
priority generating key material as needed. On that point: this may 
require some form of load balancing interface to sit between the 
processes using the HSM and the HSM itself that decides which has a 
higher priority (key generation or signing) since I can imagine that 
there may be a few HSMs that can only do one thing at a time (especially 
if you include a really cheap HSM: a smart card in a reader).

> Or should we allow the operator to select pre-generate or only generate 
> the minimum needed?

Why not make this configurable? I think it should be possible to come up 
with a sensible default scenario with some formula as I proposed above 
but leave it up to more experienced administrator to decide on their own 
policy.

Another thing I'm pondering is the policy for KSKs. Have you already 
discussed having one KSK for all zones administered by an OpenDNSSEC box 
versus having a KSK for each zone? (If you have, forgive me for bringing 
it up). There are of course risks in having a single KSK (bigger impact 
if the key is compromised), but benefits as well (less key material 
floating around, easier to communicate to your parent). And then there 
are legal issues to consider (who is signing on behalf of whom, 
especially in the case where an ISP manages many zones for a lot of 
different entities); there is going to be a point where people start 
wondering who 'owns' the key material that is used to sign a zone and 
who is legally responsible for the statement of authenticity that is 
being given for the signed data.

Finally, there is one other thing I'd like to bring up (and again, since 
I don't know the whole history of the discussions you've had before, 
please ignore it if it's already been discussed and decided on):

It may make sense to store KSKs in an expensive device like a HSM but to 
store ZSKs in a soft token (because of limitations in the HSMs storage 
space, etc. etc.). I would like to point out that it would still make a 
lot of sense to generate the key material in the HSM because of the 
better quality key generator in the HSM (care taken to provide entropy, 
filtering of weak keys, etc.). These could then be exported in a 
standard format (have a look at PKCS #8) in wrapped form (e.g. wrapped 
using a symmetric algorithm) and be imported into the soft token where 
they are then unwrapped and stored for use.

Hope I've helped a bit...

Cheers,

Roland.

-- 
-- Roland M. van Rijswijk
-- SURFnet Middleware Services
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From olaf at NLnetLabs.nl  Sun Nov 30 14:46:48 2008
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Sun, 30 Nov 2008 15:46:48 +0100
Subject: [Opendnssec-develop] Creating keys
In-Reply-To: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
References: <OF6F7E149A.00D067C2-ON8025750F.005A576F-8025750F.005C3E1E@nominet.org.uk>
Message-ID: <DA8F052F-4DCF-4D74-855B-C568F59FE11B@nlnetlabs.nl>






On Nov 28, 2008, at 5:47 PM, Stephen.Morris at nominet.org.uk wrote:

> Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 27/11/2008 16:01:26:
>
>>
>> On Nov 27, 2008, at 4:54 PM, John Dickinson wrote:
>>
>>>
>>> So I guess if you have a large zone like co.uk then a couple of
>>> seconds in the 6 odd minutes that it would take to sign from scratch
>>> is nothing. However, if you have 1000's of small zones or you are
>>> dynamically updating every minute then it could make a big  
>>> difference.
>>
>> But even then... the key-rollover would take place only once per  
>> month
>> or so. So this 2 second pain per zone only happens once or twice per
>> month.
>
> In this approach, are there any problems in ensuring that the keys are
> replicated to a backup HSM before they are used?  Do you need any  
> type of
> "master" password to export private keys from the HSM?
>


And again, here I can see a many zones using one private key. With  
that possibility a number of these questions do not pop up. One  
private key (with many public key instances) that is used for many  
zones. One single generation, one single backup an al this magic.

Not that one priv-key to many zones excludes many-to-many.

-Olaf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 235 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20081130/0097dbc5/attachment.bin>