Discussion:
DNSSEC will eventually generate Identical Key ID's
Mark Elkins
2018-09-09 17:51:52 UTC
Permalink
Just for the record, although I do look from a curiosity point of view
for Identical Key ID's once every few month - I've never seen them -
until now.

Now I have them - generated by BIND within a few days of each other...


-rw-r--r-- 1 root root   431 Aug 18 00:03 Kipv6.org.za.+008+46578.key
-rw------- 1 root root  1012 Aug 18 00:03 Kipv6.org.za.+008+46578.private

# cat Kipv6.org.za.+008+46578.key
; This is a zone-signing key, keyid 46578, for ipv6.org.za.
; Created: 20180817220323 (Sat Aug 18 00:03:23 2018)
; Publish: 20180817220323 (Sat Aug 18 00:03:23 2018)
; Activate: 20180817220323 (Sat Aug 18 00:03:23 2018)
ipv6.org.za. IN DNSKEY 256 3 8
AwEAAbdOBycxs6uv0fgkpxh1DyFNyVdWlHfVWy4zKAeEM0MEYeR/idNO
/Z7aWFLlHsEADEpUGuz5dpHRP5OgPDzFesa1AdK0YsbzkDVsRD10Epjt
1CakfLbYqnrn4i/+Ds7VGDQJa83+JOewhKl5lSbGMCtvycFoXg7pyi+A bsCQvITN


-rw-r--r-- 1 root root   431 Aug 23 00:03 Kftth.net.za.+008+46578.key
-rw------- 1 root root  1008 Aug 23 00:03 Kftth.net.za.+008+46578.private

# cat Kftth.net.za.+008+46578.key
; This is a zone-signing key, keyid 46578, for ftth.net.za.
; Created: 20180822220329 (Thu Aug 23 00:03:29 2018)
; Publish: 20180822220329 (Thu Aug 23 00:03:29 2018)
; Activate: 20180822220329 (Thu Aug 23 00:03:29 2018)
ftth.net.za. IN DNSKEY 256 3 8
AwEAAeB+Q8/GXSoyp3eMHusIgxlr51HUMhMpsRUzhp5A4TlnGPPXHw3C
ktwELF4FzPpnHWrHuOL+PewPU15KL6rQ+y4jN1s9tRMK7+jyTuttSnsF
R9gmmhtCvyZ+GtmAhcBVaoe/4VfZMOCHjthwLxoqMy1l19qx9Yy5jVtd WWa+q6Ot

I've been running DNSSEC for 7 years and have around 400 DNSSEC keys for
133 signed Domains.
I'm a smallish Registrar for ZA domains.

Never assume a KeyID is unique.  :-)
--
Mark James ELKINS - Posix Systems - (South) Africa
***@posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind
Anand Buddhdev
2018-09-09 18:30:10 UTC
Permalink
Post by Mark Elkins
Never assume a KeyID is unique.  :-)
One of the DNSSEC RFCs specifically says that the KeyID is not meant to
be unique. I can't remember which one, and it's too late on a Sunday
evening to be reading RFCs :)

Even then, I've had the misfortune of dealing with a vendor whose
developers didn't read the RFCs properly, and designed their key store
using the key IDs as indexes. So one fine day, we had a zone signed with
one key, but the DS record came from another key. Boom. Yuck. What a
mess it was to sort out!

Regards,
Anand
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/lis
Warren Kumari
2018-09-10 13:47:20 UTC
Permalink
Post by Anand Buddhdev
Never assume a KeyID is unique. :-)
One of the DNSSEC RFCs specifically says that the KeyID is not meant to
be unique. I can't remember which one, and it's too late on a Sunday
evening to be reading RFCs :)
You are thinking of RFC4034, Section 8. Security Considerations:

The key tag is used to help select DNSKEY resource records
efficiently, but it does not uniquely identify a single DNSKEY
resource record. It is possible for two distinct DNSKEY RRs to have
the same owner name, the same algorithm type, and the same key tag.
An implementation that uses only the key tag to select a DNSKEY RR
might select the wrong public key in some circumstances. Please see
Appendix B for further details.
Post by Anand Buddhdev
Even then, I've had the misfortune of dealing with a vendor whose
developers didn't read the RFCs properly, and designed their key store
using the key IDs as indexes. So one fine day, we had a zone signed with
one key, but the DS record came from another key. Boom. Yuck. What a
mess it was to sort out!
Oooh, that sounds like fun to debug....
W
Post by Anand Buddhdev
Regards,
Anand
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
---maf
Ray Bellis
2018-09-10 08:45:08 UTC
Permalink
Post by Mark Elkins
Just for the record, although I do look from a curiosity point of view
for Identical Key ID's once every few month - I've never seen them -
until now.
Now I have them - generated by BIND within a few days of each other...
I've been running DNSSEC for 7 years and have around 400 DNSSEC keys for
133 signed Domains.
I'm a smallish Registrar for ZA domains.
Never assume a KeyID is unique.  :-)
It's inevitable that they won't be.

With only a 16 bit key tag space (and in 2016 Roy Arends discovered that
the effective space is only 15 bits) then due to the birthday collision
paradox you only need of the order of sqrt(32k) different keys to get a
50% chance of a collision.

Ray

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/li
Warren Kumari
2018-09-12 20:46:36 UTC
Permalink
Post by Ray Bellis
Post by Mark Elkins
Just for the record, although I do look from a curiosity point of view
for Identical Key ID's once every few month - I've never seen them -
until now.
Now I have them - generated by BIND within a few days of each other...
I've been running DNSSEC for 7 years and have around 400 DNSSEC keys for
133 signed Domains.
I'm a smallish Registrar for ZA domains.
Never assume a KeyID is unique. :-)
It's inevitable that they won't be.
With only a 16 bit key tag space (and in 2016 Roy Arends discovered that
the effective space is only 15 bits) then due to the birthday collision
paradox you only need of the order of sqrt(32k) different keys to get a
50% chance of a collision.
This reminds me of some interesting (well, interesting to me :-)) related
research Ben Laurie and I did around that time -- while looking at the
distribution of generated keys I noticed that OpenSSL / GnuTLS generate a
different distribution than e.g mbedTLS.
OpenSSL / GnuTLS optimize the generation of primes by setting the least
significant bits (fair, they have to be odd to be primes :-)) but also
clear the most significant bits of both P and Q (to ensure that the product
of P & Q do not overflow) -- this results in a key with less bits of
"security" than most would expect...

W
Post by Ray Bellis
Ray
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
---maf
Tony Finch
2018-09-13 09:47:07 UTC
Permalink
Post by Warren Kumari
This reminds me of some interesting (well, interesting to me :-)) related
research Ben Laurie and I did around that time -- while looking at the
distribution of generated keys I noticed that OpenSSL / GnuTLS generate a
different distribution than e.g mbedTLS.
Funky. There are all sorts of fun things you can do with less secure RSA
keys, e.g. Mark Wooding's hack for embedding text of your choice in the
base64 of the public key
https://git.uis.cam.ac.uk/x/uis/u/fanf2/talks/2014-03-nws42.git/blob/HEAD:/rsa-cheat

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
Shannon, Rockall: West or southwest 5 or 6, increasing 7 at times. Rough or
very rough, becoming moderate or rough. Rain or showers. Moderate or good.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Tony Finch
2018-09-10 11:32:54 UTC
Permalink
Never assume a KeyID is unique.  :-)
Good tools ensure that key IDs are unique per zone. For example, if you
keep generating keys for a zone with `dnssec-keygen` it will eventually
get into an infinite loop perpetually generating colliding keys!

Apart from the footgun that Anand described, the reason for keeping key
IDs unique per zone is so that a validator can quickly skip keys that
can't possibly match an RRSIG or DS record.

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
Tyne, Dogger, Fisher: Southwest 5 to 7. Slight or moderate in Tyne, otherwise
moderate or rough. Showers then rain. Good, occasionally poor.
Loading...