Hi Eric, On 30. 10. 2013, at 15:34, Eric Kom <erickom(a)metropolitancollege.co.za> wrote: On our www.knot-dns.cz web or on in the announcement email? O. -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------

AFAIK Jan V. is already working on PKCS#11 support (via openssl). O. -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, CZE mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------

On Oct 31, 2013, at 17:10 , Jan Včelák wrote: Good! That's ok. I understand that depending on dnssec-keygen is an interim solution, I'm just concerned that once you create your own tools you should avoid staying with the (to my mind) broken interfaces provided by the interim solution. Do you parse the timing metadata or do you only use the keying material? I'd argue that while timing metadata is certainly important the way to look at it is as a "policy", i.e. for zone foo.com I want to use the key-and-signing-policy FOO and then the timing information should be associated with the policy, not with the individual keys. I.e. I advise against using timing information stored in K* files. "Key-and-signing-policy" is what OpenDNSSEC calls "KASP" and that seems to be the right abstraction here. You want to be able to define multiple policies and for each zone declare which policy should be used to sign it. So I realise that it sounds like I'm singing the OpenDNSSEC song here, but frankly I'm not. I'd love to see an alternative to OpenDNSSEC, but at the same time I must say that OpenDNSSEC really has found the right abstractions and the right design in many respects. I.e. I'm more interested in alternative implementation than inventing yet another way of describing the problem space. You're welcome. Johan

[thanks for including me in this discussion] I will probably write a keymanager in Go at some point in time, my interaction with HSM is already taken care of because I wrote a PKCS#11 wrapper for Go - just for this purpose :-) [ Quoting <jan.vcelak(a)nic.cz> in "Re: [knot-dns-users] Knot DNS 1.3.3..." ] All the previous emails sound right to me. A "lightweight" key-manager thingy, unlike BIND and unlike OpenDNSSEC. As for the user interface, that would be rather simple: a key should be used to sign, or should be carried in the zone at some point in time. The KSK flag deals with what should be signed. So you talk to the key-manager, and it responds with: key1, sign, KSK key2, carry, KSK key3, sign , ZSK and then your smart incremental signer knows what to do, no? Grtz Miek -- Miek Gieben PGP 3880D0F6

Hi, Dne 31.10.2013 14:42, Johan Ihrén napsal(a): I have different opinion on this. I'm fine with private keys on disk. I don't want to run SoftHSM using SQLite database full of strange binary blobs, use three different tools to create, manage and export private keys and work with long alphanumeric nonsense IDs. I'm happy with KSK for example.com in file named KSK_example.com.private, the same way I work with SSL certificates or SSH keys. In case of emergency it is much more simple to just recover the right key file from backup instead of going through some lengthy process like [1]. [1]: https://wiki.opendnssec.org/display/USERDOCREF/Recovery+of+a+single+dnskey+… So, PKCS11 support would be nice to have, but please don't make it the only option to deploy DNSSEC using Knot. Same way with the KASP policy. The best database for me is the filesystem itself. -- Ondřej Caletka

Hi, On Oct 31, 2013, at 20:18 , Ondřej Surý wrote: I agree. As long as the user interface is sufficiently abstract, and has suitable safe guards ("no, you don't want to delete the active KSK") I'm happy. The existence of files in a filesystem behind the scenes is not the issue, as long as that isn't the suggested interface. There's always a behind-the-scenes interface where you can mess stuff up if you set your mind to it. That said, I'll comment a bit on the consequences of keeping the keys in separate files in the file system below. I used to think this too. But I've come to change my mind. So, just going with this line of thought: * Your zone is example.com and the name of the KSK files are KSK_example.com.private (and .key). Sofar, simple and predictable, just two files to be aware of. * In most cases you want to add a ZSK. That's four files for one zone. * Only having one single zone is actually quite rare. Without going into the professional hosting environments that have tens of thousands of zones, but just looking at myself and fellow geeks (not all of them DNS geeks, mind you), I find that ususally there are around ten zones or so. There's the v4 reverse zone, the v6 reverse and if you have stuff in more than one place then there's multiple v4 and v6 reverses. And for the sake of argument perhaps there are five forward zones, i.e. nine zones in total. (5 forward + 4 reverses) * 4 = 36 files. * Time for rollovers. Here you have two alternatives. Either the files are *renamed* as the state of the key inside changes (generated-->published-->ready-->active-->retired) or they are not. If the names are changed then that's a risk by itself, because you get the potential for locking issues where the contents of the file you think you're doing something to is not the same as it was some time ago. If, on the other hand you never rename files then you need to keep the metadata (state, etc) somewhere else than in the filename, i.e. inside the file or a database somewhere. Furthermore, with static filenames, what should be the name of the *new* KSK that is generated? It cannot be KSK_example.com.{key,private} obviously. So it has to be KSK_example.[id of some sort].{key,private}. And now we've reinvented the K* files. And, BTW, when dealing with multiple keys during rollovers there will be at least 3, possibly 5 keys per zone. Both KSK and ZSK. So that's at least: 3 states * 2 keys * 2 files * 9 zones = 108 files that because of the need for a unique id for each key will all have unpredictable names that are difficult to script. * And the final nit: time. Because DNSSEC rollovers take a lot of time (months typically) you will not be able to just figure out which key is in which file once and take care of what needs to be done, you'll get half way and then you need to continue with the next phase in two weeks time. At this point you will have forgotten which key was which so you need to start over looking inside all the files again, etc. Unless, of course, you cheat and have a little file on the side with metadata about which key is which, etc. Regardless of method it is messy. And this is why I argue that exposing the key files to the users are, umm, not the way to go in 2013. It's just like the english story telling idiom: "...it seemed like a good idea at the time". It's just that "the time" was around 1996, and at that time we had not figured out the KSK/ZSK split, we had not figured out all the different states during rollovers and we had not figured out all the complexity and pain we'd get from algorithm rollovers (that I didn't even include above). So here we are, seventeen years later, and it no longer seems like a good idea ;-) Regards, Johan

On Nov 1, 2013, at 10:25 , Miek Gieben wrote: I don't have a strong position on that. From my POV we want most things to be automatic, because if manual then some users will screw up (if no one else, I will). But whether you delete old retired keys via a "delete" operation in the API or if the key-manager is sufficiently clueful on its own to understand when to delete keys I don't really care. One concern with making the key-manager smarter is that I think you want to avoid ending up with the key-manager running as a server process that you connect to. Much better to keep it as "invoked on demand", but then you must avoid making it responsible for anything that should happen on a clock. Deleting old keys may be deferred until whenever it is called next, so that is probably ok, though. Yeah, the first time I saw that I hurt my head as I fell over backwards... Johan

Hi Miek, On Nov 1, 2013, at 11:28 , Miek Gieben wrote: Or not even that. Look at it this way: assume that in the next week there are keys that should change state. What happens if you don't invoke the key-manager? Has the keys changed state or not? Eventually you do invoke it, and if at that point all the state changes and other stuff happen in the right order then you're fine. My point is that the keys inside the key-manager act a bit like Heisenberg's Cat. You only know their state if you invoke the key-manager. So not invoking it will never cause anything bad to happen because you'll never need the effect of the changed state until you eventually invoke it. So you'll only have to invoke the key-manager whenever you want it to sign something, however often that is depending on your KASP. Regards, Johan

[ Quoting <johani(a)johani.org> in "Re: [knot-dns-users] Knot DNS 1.3.3..." ] I'm exploring what it should look like, by writing the manual page. See https://github.com/miekg/keys, the README is not perfectly formatted, but should be readable. Central idea is the 'stamp' command, that the current config is now in use. -- Miek Gieben PGP 3880D0F6

It might have been worse - keys in the key-manager acting as a Hindenburg's cat ;) O. -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, CZE mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- On 3. 11. 2013, at 17:46, Johan Ihrén <johani(a)johani.org> wrote: