search

PowerDNS / pdns

PowerDNS Authoritative, PowerDNS Recursor, dnsdist
https://www.powerdns.com/
GNU General Public License v2.0
3.69k stars 906 forks source link

pdnsutil only makes CSK instead of KSK/ZSK #5330

Closed Ghorix closed 6 years ago

Ghorix commented 7 years ago

Short description

Currently i'm busy with testing DNSSEC using powerdns. I want to use a split key configuration (ZSK + KSK). Before using it in production i was testing diffrent types of rollovers. And i noticed that "Algorithm rollover" had nearly no documentation besides from the RFC. So i went out and tried to do an algorithm rollover. However i found strange results during the process. At one point PDNS would only make CSK instead of ksk or zsk for the "example.com" zone. Even after deleting all keys and trying to add new keys it gave me "CSK". The weirdest thing is that after making keys for another zone "test.com". The behavior of example.com returned to normal and i could make ZSK/KSK again.

tldr: Situation where only CSK are given instead of ZSK/KSK, but with weird work-around it works again as it's supposed to.

old algorithm rsasha1 new algorithm ecdsa256

Environment

One Hiddenmaster Two NSD based slaves

Steps to reproduce

New zone with DNSSEC

  1. make zone example.com
  2. pdnsutil add-key-zone example.com ksk active 2048 rsasha1
  3. pdnsutil add-key-zone example.com zsk active 1024 rsasha1

Algorithm rollover RFC6781 section 4.14 (Should work same als Double Key-signing rollover)

  1. pdnsutil add-key-zone example.com ksk inactive ecdsa256
  2. pdnsutil show-zone example.com

Clean up zone because want to use split-key conf (these steps have been done 3 times with same results)

  1. Delete all te keys using pdnsutil remove-key-zone ZONE KEY-ID
  2. pdnsutil rectify-zone example.com
  3. pdnsutil add-key-zone example.com ksk active ecdsa256 pdnsutil add-key-zone example.com zsk active ecdsa256

Clean up old zone and try signing an new zone

  1. Perform steps 6,7 again for example.com
  2. pdnsutil create-zone test123.com
  3. pdnsutil add-key-zone test123.com ksk active ecdsa256

Try again to make keys on example.com (Look step 9. this is now a non-DNSSEC zone) 12 pdnsutil add-key-zone example.com ksk active ecdsa256 pdnsutil add-key-zone example.com zsk active ecdsa256

Expected behaviour

Step 1,2,3 Works as expected Step 4,5 New KSK added with new algorithm and rrset added with new algorithm Step 6,7 are run without issue, zone has no "keys" and rectify runs without error. Step 8 New ksk/zsk key with new algorithm added to zone Step 9 example.com is "clean" zone without keys or other DNSSEC records. Step 10,11 new zone, with CSK with new algorithm, (Because of "earlier BUG) Step 12 example.com signed with a CSK instead of ksk/zsk

Actual behaviour

Step 1,2,3 Work as expected new keys are added Step 4,5 New CSK added with new algorithm and rrset added with new algorithm. Step 6,7 are run without issue, zone has no "keys" and rectify-zone runs without error. Step 8 New CSK key's (2) with new algorithm added to zone Step 9 example.com seems a "clean" zone without keys or other DNSSEC records. Step 10,11 new zone, with KSK with new algorithm Step 12 example.com now signed with correct KSK/ZSK

Behavior tldr:

Make Zone Ok Do DNSSEC with algorithm 1 Ok Change keys to keys with new algorithm No no no Clean Zone en Redo DNSSEC to get new algorithm No no no Make new zone and do DNSSEC Ok Do DNSSEC again on old zone with new algorithm Ok.

pieterlexis commented 7 years ago

Hi!

Thanks for the extensive bug report!

I have a hunch what the issue can be, can you look at the key-ids (as they are in the database) after each step? I think we might mess up the cryptokeyid somewhere

Thanks!

Ghorix commented 7 years ago

For testing i will create 2 new zones.

  1. test1.nl
  2. test2.nl

Step 1,2,3 Keys are added as expected with old algorithm ID according show-zone command are 44 and 43 MariaDB -> 44 and 43 ok ok

Step 4,5 Trying to add a new algorithm KSK. Getting a CSK. Having ID 45 MariaDB -> 36 ok ok pdnsutils show-zone gives (CSK) (This could be a feature because only "added a KSK at this point" and different algorithms for ZSK and KSK are not allowed.)

Step 6,7 deleted without error doens't seem anything wrong

Step 8 Adding ksk and zsk getting ksk and zsk (ID 46 & 47) Getting an KSK and ZSK this time. (Can/t seem too replicate the bug tried multiple times) MariaDB -> ID 46 & 47

So At this point i was thinking i was going crazy. Like maybe adding 2 times ksk getting double CSK? However i look at my history and see i didn't make that mistake.

However there was a part that caught my attention. I remember i was busy cleaning up the keys right before the odd things happend. However after i used the delete command once they key would still be there. I thought It was just in my mind. but:

121 pdnsutil remove-zone-key example.com 10 122 pdnsutil add-zone-key example.com ksk active 2048 rsasha256 (key 11) 123 pdnsutil show-zone example.com 124 pdnsutil remove-zone-key example.com 11 125 pdnsutil add-zone-key example.com ksk inactive 2048 rsasha256 (Key 12) 126 pdnsutil remove-zone-key example.com 11 127 pdnsutil show-zone example.com 128 pdnsutil remove-zone-key example.com 12 129 pdnsutil remove-zone-key example.com 8 130 pdnsutil add-zone-key example.com zsk inactive 2048 rsasha256 (Key 13) 131 pdnsutil remove-zone-key example.com 8 132 pdnsutil show-zone example.com 133 pdnsutil remove-zone-key example.com 13 134 pdnsutil add-zone-key example.com zsk inactive 2048 rsasha256 135 pdnsutil show-zone example.com 136 pdnsutil remove-zone-key example.com 14 137 pdnsutil show-zone example.com

During this part the weird stuff started. So there is a good chance there is/was some bug with the cryptokeys_ID.

I will try to recreate all tomorrow. I have to ínstall pdns on an different machine.

thank you for the quick response!

Ghorix commented 7 years ago

And i have done it again! I have been able to recreate. (It seems the difference is going from the newer to the older algorithm)

Step 1. Is make a zone sign it with EDCSA (algorithm 13) (split-key) Step 2. Delete the keys Step 3. Sign zone with rsasha1 (Splitkey) key id 50 and 51

I looked up in mariadb: Step 2. gone in mariadb Step 3. Key id 50 and 51.

The key id from the DB and the pdnsutil

i won/t touch the zone and leave it at this state. So i can give u more information if needed.

mind04 commented 7 years ago

Without mentioning the flags value of the CSK is impossible to tell what is going on. Please show us zone-info output or say "CSK where flags = 257 / 256"

Habbie commented 7 years ago

Ping!

Ghorix commented 7 years ago

I'm sorry i haven responded before. There was another project that needed my attention. I will look into this again. and hope to give an update soon.

Ghorix commented 7 years ago

Note, This is a new zone with the CSK "label".

The CSK label only applies with a algorithm rollover.

output with pdnsutil show-zone:

ID = 193 (ZSK), flags = 256, tag = 6848, algo = 13, bits = 256 Active ( ECDSAP256SHA256 ) ID = 195 (CSK), flags = 256, tag = 35051, algo = 10, bits = 2048 Inactive ( RSASHA512 ) CSK DNSKEY = example.com. IN DNSKEY 256 3 10 AwEAAcjuWow5zqHmfaVl9FZIAGnFZkVKR6FOSI+lK9HfhvV5Fe1vKcHGfTtmsNBs/5I4FuPJd3m714BeP7jSIZFOiBhrTZ/R8cdPGgKKAEOFdRam0pIP5oCXSIcG5jlgxluz2B3hwcsYGytFd96tNjp76T5yE/kvtymSAtI8V0e0MyjWsp3XimQQPk70IzeamTux1LmbNHdED/zoEbbasF0L+7EWdK6ItdA8+0BZcuU5y1dva0SLBlWxbS94k/gozsI5Cb1cE6j5Gyb2/eVGVPB3IVMsGZH1jgV0MT/rYxXC10wcMVqRSRa/romYabJ2dfcVIL/GV6cjMVYo/1GiGZgegtk= ; ( RSASHA512 ) DS = example.com. IN DS 35051 10 1 f87c39d539ca443c95d71515ac5c58f69f0a64ed ; ( SHA1 digest ) DS = example.com. IN DS 35051 10 2 7e930f85adbcfd3e7c09f00a2663fc7534f7e6ab3913bb2e2ce84f7a2aa957ff ; ( SHA256 digest ) DS = example.com. IN DS 35051 10 4 b00c87b539b5edab96b3659f0261687695a34db8bb6412f7ff07a23ae9ee9f9a93c3a425e5138c60b0a39069d3f77c5f ; ( SHA-384 digest )

ID = 196 (CSK), flags = 257, tag = 60093, algo = 10, bits = 2048 Inactive ( RSASHA512 ) CSK DNSKEY = example.com. IN DNSKEY 257 3 10 AwEAAaafowDN1CsVTtm87PTjLO2liv3CgXJxJo1kawUj8OIgCHjMTdn8/3hu+cTAEeD1rF82l/CE/m2Ll6K+IOxoRY4uCCI2UEIhcpK0FEZhob0cuRnVkDD+dOpa6/zvmdA3Axl9Z6Ckzz7zK+m9iO0nhnFokkNUd35xRXaVkzVQ6SgoDInguwFaGv0DzTLuqsl4LM+ZtJi7LvFyZf5Y8gUYbLMt3w049HGryxpCPIR8jyK4KSbnzXeowO56OxGE2HX2Sd1kumBqUvHO4uqFy3ZT3dya1ANKGM4HC0hI1Q3ledkqyYs27Bc2NbqmatPZiUYXMS5CjZ6fG8cfJHC6JHpEXbk= ; ( RSASHA512 ) DS = example.com. IN DS 60093 10 1 2a6b512b950996c158eddb84852e910b2cb19187 ; ( SHA1 digest ) DS = example.com. IN DS 60093 10 2 87798df36d012cf8bf8887537b7fc51ba5f84c0faa7c59b9705f730979335a65 ; ( SHA256 digest ) DS = example.com. IN DS 60093 10 4 bf83e8f9ce380517c5c7e49ebc062c8a31a599ed0cbb8d86a24430bf7234be85c1e0b45686d69adf45cd95c6c28a8347 ; ( SHA-384 digest )

ID = 194 (KSK), flags = 257, tag = 7446, algo = 13, bits = 256 Active ( ECDSAP256SHA256 ) KSK DNSKEY = example.com. IN DNSKEY 257 3 13 /PEOHIz4IVVtfPgaeJ7dgkhWxOEBLQF+aN2Q+Vvpd/XIJd6aQT9M1wfN09UXJahTvVKe4PvJ0/Q1jeeiQ2hp3Q== ; ( ECDSAP256SHA256 ) DS = example.com. IN DS 7446 13 1 d9b5766a4049b221a9c31e97dd9adc8255aadc93 ; ( SHA1 digest ) DS = example.com. IN DS 7446 13 2 4156f8542abdd538c595fa91ec8635f832a740b9b2b11fdd3d407a3668e9193a ; ( SHA256 digest ) DS = example.com. IN DS 7446 13 4 c7063f903dfe6c81aea575ed7f1d841aaf032467fad585fc8f3c181103e9b076181d394347bc55c65c500ff8c8b301c2 ; ( SHA-384 digest )

mind04 commented 7 years ago

Both RSASHA512 keys are inactive and powerdns is treating both keys as CSK. This is wrong because it is impossible to determine the type of the key when there are keys with different flags and no active keys for an algorithm.

This is resulting in a lot of noise in the pdnsutil output.

leeyc0 commented 7 years ago

I think I found the possible bug: if the KSK/ZSK have different key algorithm pdns will treat them as CSK instead of KSK/ZSK.

Example:

# KSK/ZSK different key algo, shows both keys are CSK
pdnsutil disable-dnssec example.com
pdnsutil add-zone-key example.com ksk active 4096 rsasha512
pdnsutil add-zone-key example.com zsk active 2048 rsasha256

# KSK/ZSK same key algo, shows KSK/ZSK
pdnsutil disable-dnssec example.com
pdnsutil add-zone-key example.com ksk active 4096 rsasha512
pdnsutil add-zone-key example.com zsk active 2048 rsasha512

# this command also shows KSK/ZSK
pdnsutil disable-dnssec example.com
pdnsutil add-zone-key example.com ksk active 4096 rsasha256
pdnsutil add-zone-key example.com zsk active 2048 rsasha256

# try again using ECDSA, this command shows both keys are CSK
pdnsutil disable-dnssec example.com
pdnsutil add-zone-key example.com ksk active ecdsa384
pdnsutil add-zone-key example.com zsk active ecdsa256

# this command shows KSK/ZSK
pdnsutil disable-dnssec example.com
pdnsutil add-zone-key example.com ksk active ecdsa256
pdnsutil add-zone-key example.com zsk active ecdsa256
Habbie commented 7 years ago

I think I found the possible bug: if the KSK/ZSK have different key algorithm pdns will treat them as CSK instead of KSK/ZSK.

That is correct behaviour, as far as I know.

mind04 commented 7 years ago

KSK/ZSK and CSK are evaluated per algorithm

james-stevens commented 6 years ago

I think I found the possible bug: if the KSK/ZSK have different key algorithm pdns will treat them as CSK instead of KSK/ZSK. That is correct behaviour, as far as I know.

I agree, here's a good analysis - https://security.stackexchange.com/questions/80493/dnssec-does-the-algorithm-of-the-zsk-need-to-match-the-algorithm-of-the-ksk

I think the confusion here is becuase ecdsa256 & ecdsa384 are two different algorithms that /only/ support 256 & 384 bits respectively - unlike (say) rsasha256 & rsasha512, which are two different algorithms that each support a range of different key lengths.

ecdsa256 & ecdsa384 are not one algorithm with two different key lengths.

Habbie commented 6 years ago

This does not appear to be a bug report, so I'm closing this. Please see https://www.powerdns.com/opensource.html to get help if needed.