knot-dns-users Listopad 2018

knot-dns-users@lists.nic.cz

15 participants
19 discussions

Re: [knot-dns-users] Key sizes with ECDSA

by Full Name

OK, thanks. Just making sure I was not missing something obvious. -----Original Message----- From: "libor.peltan" [libor.peltan(a)nic.cz] Date: 11/29/2018 04:33 AM To: knot-dns-users(a)lists.nic.cz Subject: Re: [knot-dns-users] Key sizes with ECDSA Hi Full Name, indeed, this is not possible. The ECC and EDD algorithm families always stick to one key size for any algorithm. You can't have your KSK and ZSK with different algorithms. On the other hand, this is no big deal. Those algorithms are considered safe enough even with small keys, so you can choose just e.g. ECDSA256 and profit from having small signatures. You can also think of using single-type signing scheme. BR, Libor Dne 28.11.18 v 22:58 Full Name napsal(a): > A policy section in knot.conf would contain (among other things) an algorithm specification and (optionally) the KSK and ZSK keys sizes. This works fine for RSA. Now imagine that I want to establish a policy with ECC keys for both KSKs and ZSKs. However, I might want for the KSKs to be 384-bit keys, and for the ZSKs to be 256-bit keys. Can a policy be created in Knot to do so? It would seem that, given that the algorithm specification for NIST elliptic curves includes both the curve and digest data, the key size specifications do not apply here - i.e. both KSKs and ZSKs will necessarily use the same curve, and therefore the same key size. Is this correct? -- https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

6 let, 12 měsíců

Key sizes with ECDSA

by Full Name

A policy section in knot.conf would contain (among other things) an algorithm specification and (optionally) the KSK and ZSK keys sizes. This works fine for RSA. Now imagine that I want to establish a policy with ECC keys for both KSKs and ZSKs. However, I might want for the KSKs to be 384-bit keys, and for the ZSKs to be 256-bit keys. Can a policy be created in Knot to do so? It would seem that, given that the algorithm specification for NIST elliptic curves includes both the curve and digest data, the key size specifications do not apply here - i.e. both KSKs and ZSKs will necessarily use the same curve, and therefore the same key size. Is this correct?

6 let, 12 měsíců

Re: [knot-dns-users] Problem to import key material of softhsm into knot

by mark.karpilovskij＠nic.cz

Hi Christian, I am glad to hear that. Let us know if you have any other issues. Best regards, Mark On 2018-11-27 14:04, Christian Petrasch wrote: > Hello Mark, > > I was able to sign with Knot and SoftHSM. I switched to an actual > version of gnutls and recompiled Knot. > > Thank you very much for your good support > > best regards > -- > Christian Petrasch > Product Owner > Zone Creation & Signing > IT-Services > > DENIC eG > Kaiserstraße 75-77 > 60329 Frankfurt am Main > GERMANY > > E-Mail: petrasch(a)denic.de > http://www.denic.de > > PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E > 8841 549B E0AE > > Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) > Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. > Jörg Schweiger > Vorsitzender des Aufsichtsrats: Thomas Keller > Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht > Frankfurt am Main > > Von: "Mark Karpilovskij" <mark.karpilovskij(a)nic.cz> > An: "Christian Petrasch" <petrasch(a)denic.de> > Datum: 26.11.2018 16:22 > Betreff: Re: [knot-dns-users] Problem to import key material of > softhsm into knot > > ------------------------- > > Hi Christian, > > also, did you build Knot manually or did you use a package? What is > your current GnuTLS version? It should be at least 3.4.6 for the HSM > to work, at least according to our documentation. > > BR, > > Mark > > On 26. 11. 18 16:09, Mark Karpilovskij wrote: > > Hi Christian, > > I have verified that it is indeed necessary for Knot to use full > length key IDs with PKCS #11, so make sure you do that. Other than > that, I am quite puzzled by the "FAILED TO INITIALIZE KASP (NOT > IMPLEMENTED)" error that you are getting and so far I have been unable > to reproduce it. I will spend some more time on it. Which version of > CentOS are you using? Meanwhile, see if both setting correct policy > configuration and using full length key IDs will help you. > > Best regards, > > Mark > > On 26. 11. 18 12:31, Christian Petrasch wrote: > Hi Mark, > > thanks a lot for you help.. > > I added the keystore to my config.. but I_m getting another error > now.. > > # See knot.conf(5) manual page for documentation. > > server: > listen: [ 127.0.0.1@53, ::1@53 ] > > keystore: > > # KSK > - id: a1a1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > # ZSK > - id: a1b1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > policy: > - id: manual > manual: on > keystore: a1b1 > nsec3: on > nsec3-iterations: 16 > nsec3-opt-out: on > nsec3-salt-length: 8 > > zone: > - domain: example.com > dnssec-signing: on > dnssec-policy: manual > zonefile-load: difference > file: example.com.zone > storage: /etc/knot/ > > log: > - target: syslog > any: debug > > ### > > [root@centos-test2 ~]# keymgr -c /etc/knot/knot.conf example.com. > import-pkcs11 a1b1 algorithm=RSASHA256 size=2048 ksk=no > created=20181126090000 publish=20181126090000 retire=+10mo remove=+1y > Failed to initialize KASP (not implemented) > > I tried with the -d parameter as well.. but i got: > > keymgr -d /var/lib/knot/keys/ example.com. import-pkcs11 a1b1 > algorithm=RSASHA256 size=2048 ksk=no created=20181126090000 > publish=20181126090000 retire=+10mo remove=+1y > Error (not exists) > > I read from former knot versions about the "keymgr init" command, but > it is not implemented anymore.. > > Do you have another idea whats going wrong.. ? > > Thanks a lot for your great help :) > > best regards > > -- > Christian Petrasch > Product Owner > Zone Creation & Signing > IT-Services > > DENIC eG > Kaiserstraße 75-77 > 60329 Frankfurt am Main > GERMANY > > E-Mail: petrasch(a)denic.de > http://www.denic.de > > PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E > 8841 549B E0AE > > Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) > Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. > Jörg Schweiger > Vorsitzender des Aufsichtsrats: Thomas Keller > Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht > Frankfurt am Main > > Von: "Mark Karpilovskij" <mark.karpilovskij(a)nic.cz> > An: "Christian Petrasch" <petrasch(a)denic.de> > Kopie: knot-dns-users(a)lists.nic.cz > Datum: 26.11.2018 11:56 > Betreff: Re: [knot-dns-users] Problem to import key material of > softhsm into knot > > ------------------------- > > Hi Christian, > > I have checked out your Knot configuration, and I suspect that the > issue might be a missing keystore option in the policy section of your > configuration. Try specifying the ID of the PKCS11 keystore in the > policy section as follows: > > keystore: > - id: a1a1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > - id: a1b1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > policy: > - id: manual > manual: on > KEYSTORE: A1A1 > nsec3: on > nsec3-iterations: 16 > nsec3-opt-out: on > nsec3-salt-length: 8 > > Let us know if this helps. > > Best regards, > > Mark > > On 26. 11. 18 9:49, Christian Petrasch wrote: > Hi @ all, > > we are testing with softhsm 2.5 and KNOT 2.7.4... > > I try to import the keys inside softhsm into keymgr to sign with this > a example zone. > > The keymaterial is shown via pkcs11-tool: > > [root@centos-test2 ~]# pkcs11-tool --login --list-objects --module > /usr/local/lib/softhsm/libsofthsm2.so > > Using slot 0 with a present token (0x285d1c08) > Logging in to "testKSK_1". > Please enter User PIN: > Private Key Object; RSA > label: testKSK_1 > ID: a1a1 > Usage: decrypt, sign, unwrap > Public Key Object; RSA 1024 bits > label: testZSK_1 > ID: a1b1 > Usage: encrypt, verify, wrap > Private Key Object; RSA > label: testZSK_1 > ID: a1b1 > Usage: decrypt, sign, unwrap > Public Key Object; RSA 2048 bits > label: testKSK_1 > ID: a1a1 > Usage: encrypt, verify, wrap > > ###### > > The KNOT config is : > > [root@centos-test2 ~]# cat /etc/knot/knot.conf > # See knot.conf(5) manual page for documentation. > > server: > listen: [ 127.0.0.1@53, ::1@53 ] > > keystore: > - id: a1a1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > - id: a1b1 > backend: pkcs11 > config: "pkcs11:token=testKSK_1;pin-value=5678 > /usr/local/lib/softhsm/libsofthsm2.so" > > policy: > - id: manual > manual: on > nsec3: on > nsec3-iterations: 16 > nsec3-opt-out: on > nsec3-salt-length: 8 > > zone: > - domain: example.com > dnssec-signing: on > dnssec-policy: manual > zonefile-load: difference > file: example.com.zone > storage: /etc/knot/ > > log: > - target: syslog > any: debug > > ################### > > And if I try to import the key into keymgr i run the command: > > [root@centos-test2 ~]# keymgr -c /etc/knot/knot.conf example.com. > import-pkcs11 a1a1 algorithm=RSASHA256 size=2048 ksk=yes > created=20181126090000 publish=20181126090000 retire=+10mo remove=+1y > Error (not exists) > > ### > > I don't know how I can fix this.. maybe anybody can help me ? The > documentation of KNOT is very good.. but at this point it is a little > bit insufficient. Does anybody has examples for this ? > > Thanks a lot in advance for the help.. > > best regards > > -- > Christian Petrasch > Product Owner > Zone Creation & Signing > IT-Services > > DENIC eG > Kaiserstraße 75-77 > 60329 Frankfurt am Main > GERMANY > > E-Mail: petrasch(a)denic.de > http://www.denic.de > > PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E > 8841 549B E0AE > > Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) > Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. > Jörg Schweiger > Vorsitzender des Aufsichtsrats: Thomas Keller > Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht > Frankfurt am Main

6 let, 12 měsíců

Problem to import key material of softhsm into knot

by Christian Petrasch

Hi @ all, we are testing with softhsm 2.5 and KNOT 2.7.4... I try to import the keys inside softhsm into keymgr to sign with this a example zone. The keymaterial is shown via pkcs11-tool: [root@centos-test2 ~]# pkcs11-tool --login --list-objects --module /usr/local/lib/softhsm/libsofthsm2.so Using slot 0 with a present token (0x285d1c08) Logging in to "testKSK_1". Please enter User PIN: Private Key Object; RSA label: testKSK_1 ID: a1a1 Usage: decrypt, sign, unwrap Public Key Object; RSA 1024 bits label: testZSK_1 ID: a1b1 Usage: encrypt, verify, wrap Private Key Object; RSA label: testZSK_1 ID: a1b1 Usage: decrypt, sign, unwrap Public Key Object; RSA 2048 bits label: testKSK_1 ID: a1a1 Usage: encrypt, verify, wrap ###### The KNOT config is : [root@centos-test2 ~]# cat /etc/knot/knot.conf # See knot.conf(5) manual page for documentation. server: listen: [ 127.0.0.1@53, ::1@53 ] keystore: - id: a1a1 backend: pkcs11 config: "pkcs11:token=testKSK_1;pin-value=5678 /usr/local/lib/softhsm/libsofthsm2.so" - id: a1b1 backend: pkcs11 config: "pkcs11:token=testKSK_1;pin-value=5678 /usr/local/lib/softhsm/libsofthsm2.so" policy: - id: manual manual: on nsec3: on nsec3-iterations: 16 nsec3-opt-out: on nsec3-salt-length: 8 zone: - domain: example.com dnssec-signing: on dnssec-policy: manual zonefile-load: difference file: example.com.zone storage: /etc/knot/ log: - target: syslog any: debug ################### And if I try to import the key into keymgr i run the command: [root@centos-test2 ~]# keymgr -c /etc/knot/knot.conf example.com. import-pkcs11 a1a1 algorithm=RSASHA256 size=2048 ksk=yes created=20181126090000 publish=20181126090000 retire=+10mo remove=+1y Error (not exists) ### I don't know how I can fix this.. maybe anybody can help me ? The documentation of KNOT is very good.. but at this point it is a little bit insufficient. Does anybody has examples for this ? Thanks a lot in advance for the help.. best regards -- Christian Petrasch Product Owner Zone Creation & Signing IT-Services DENIC eG Kaiserstraße 75-77 60329 Frankfurt am Main GERMANY E-Mail: petrasch(a)denic.de http://www.denic.de PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E 8841 549B E0AE Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. Jörg Schweiger Vorsitzender des Aufsichtsrats: Thomas Keller Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am Main

6 let, 12 měsíců

mod-onlinesign in master-slave environment

by Oto Stefan

Hello, first of all I would like to express many thanks to the CZ.NIC DNS team for an amazing piece of software which the KnotDNS in my view surely is. Well, to my question. I run two instances of knot 2.6.9 in the master-slave configuration which serve a couple of zones. The zones are DNSSEC signed at master with an automated key management. This works excellent even with the KSK rotation (I am under .cz TLD). However, I also have a subdomain (i.e., 3rd order domain) with synthesized records. The only way to allow DNSSEC for it I was able to find is: - using mod-onlinesign on both the master and slave, - generating a key externally (with bind-utils) and importing it into KASP on both servers, - configuring manual key policy, - adding the appropriate DS record into the parent zone. This seems to work fine, all the validation tests pass. The question is: Is there a better way to achieve the goal (especially with new features like automated key rotation in online signing of the 2.7 version in mind) or what is the recommended practice in a similar situation? Thanks in advance for any suggestion or advice, Have a nice day, Oto

6 let, 12 měsíců

Define SALT String for NSEC3

by Christian Petrasch

Hi, is there any knot-dns configuration parameter to define the SALT string for NSEC3 ? I have : nsec3: BOOL nsec3-iterations: INT nsec3-opt-out: BOOL nsec3-salt-length: INT but nothing to configure the string.. Does anybody has an idea ? Any help would be really appreciated.. thanks a lot best regards -- Christian Petrasch Product Owner Zone Creation & Signing IT-Services DENIC eG Kaiserstraße 75-77 60329 Frankfurt am Main GERMANY E-Mail: petrasch(a)denic.de http://www.denic.de PGP-KeyID: 549BE0AE, Fingerprint: 0E0B 6CBE 5D8C B82B 0B49 DE61 870E 8841 549B E0AE Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. Jörg Schweiger Vorsitzender des Aufsichtsrats: Thomas Keller Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am Main

6 let, 12 měsíců

Knot DNS 2.7.4 release

by Daniel Salzman

Hello Knot DNS users, CZ.NIC has released Knot DNS 2.7.4! This version mainly fixes DNSSEC-related issues. Changelog: https://gitlab.labs.nic.cz/knot/knot-dns/tags/v2.7.4 Source code: https://secure.nic.cz/files/knot-dns/knot-2.7.4.tar.xz https://secure.nic.cz/files/knot-dns/knot-2.7.4.tar.xz.asc Documentation: https://www.knot-dns.cz/docs/2.7/html Support: https://www.knot-dns.cz/support Regards, Daniel

7 let

Re: [knot-dns-users] Dealing with limited capacity key storage

by Full Name

Feedback much appreciated. Thanks. -----Original Message----- From: "" [daniel.salzman(a)nic.cz] Date: 11/08/2018 03:43 AM To: "Full Name" <nuncestbibendum(a)excite.com> CC: knot-dns-users(a)lists.nic.cz Subject: Re: [knot-dns-users] Dealing with limited capacity key storage On 2018-11-08 01:04, Full Name wrote: > By default, Knot will use the local file system as its key storage. I > believe that, when using the SoftHSM backend, the same is true. For > most practical purposes, the implication is that the key storage has > an unlimited capacity for keys. Now when using an actual HSM, that is > not true - most HSMs will, in general, have a relatively modest keys > storage capacity, especially when compared to that of a local > filesystem. > Yes, that is correct. > Does Knot have with capabilities to deal with such situations? If > I need to have 150 keys in my key storage, but my key storage can't > hold more than 100, how does Knot deal with this? Conceptually, one > only has to wrap the keys in the HSM appropriately and dump then to > disk - where they will remain inaccessible to anybody but the HSM. > After this, one can generate (or unwrap) more keys, and use them as > necessary. Is this something that Knot can already do? The only solution with Knot DNS is using shared keys https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#ksk-shared. Also Single-Type Signing Scheme could help to reduce the number of keys https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#single-type-signing. Daniel

7 let

python-libknot: How to do "zone-set" command to add resource records

by Frank Matthieß

Hi, i work on a python library based on python/libknot/control.py. I'm at the point to add/remove resource record to a configured zone. I have tried a lot, but got no positive result: "invalid parameter (data: COMMAND = b'zone-set', ERROR = b'invalid parameter', ZONE = b'domain.tld.', OWNER = b'www.domain.tld.', TYPE = b'A', DATA = b'127.0.0.1')" The full test script debug output: DEBUG: _openSocket DEBUG: _zone-begin DEBUG: _cmd: {'cmd': 'zone-begin'} DEBUG: _cmd: {'cmd': 'zone-set', 'zone': 'domain.tld.', 'owner': 'www.domain.tld.', 'rtype': 'A', 'data': '127.0.0.1'} DEBUG: _zone-abort DEBUG: _cmd: {'cmd': 'zone-abort'} invalid parameter (data: COMMAND = b'zone-set', ERROR = b'invalid parameter', ZONE = b'domain.tld.', OWNER = b'www.domain.tld.', TYPE = b'A', DATA = b'127.0.0.1') DEBUG: _zone-begin DEBUG: _cmd: {'cmd': 'zone-begin'} DEBUG: _cmd: {'cmd': 'zone-get', 'zone': 'domain.tld.', 'owner': 'ns1.domain.tld.'} DEBUG: _zone-commit DEBUG: _cmd: {'cmd': 'zone-commit'} resp: { "domain.tld.": { "ns1.domain.tld.": { "A": { "ttl": "86400", "data": [ "192.168.120.211" ] } } } } DEBUG: _closeSocket The "_cmd" call uses libknot.control.send_block[1] internally, the following "{…}" held the function parameters. [1] https://gitlab.labs.nic.cz/knot/knot-dns/blob/master/python/libknot/control… It needs some time to discover "owner" as the query filter for "zone-get", which wasn't that obvious. Now I'm wondering how set the parameter, for adding a resource record to a zone. - frank -- Frank Matthieß Stapenhorster Straße 42b, DE 33615 Bielefeld Mail: frank.matthiess(a)virtion.de GnuPG: 9F81 BD57 C898 6059 86AA 0E9B 6B23 DE93 01BB 63D1

7 let

Dealing with limited capacity key storage

by Full Name

By default, Knot will use the local file system as its key storage. I believe that, when using the SoftHSM backend, the same is true. For most practical purposes, the implication is that the key storage has an unlimited capacity for keys. Now when using an actual HSM, that is not true - most HSMs will, in general, have a relatively modest keys storage capacity, especially when compared to that of a local filesystem. Does Knot have with capabilities to deal with such situations? If I need to have 150 keys in my key storage, but my key storage can't hold more than 100, how does Knot deal with this? Conceptually, one only has to wrap the keys in the HSM appropriately and dump then to disk - where they will remain inaccessible to anybody but the HSM. After this, one can generate (or unwrap) more keys, and use them as necessary. Is this something that Knot can already do?

7 let

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users Listopad 2018