Keyfoot prints and BIND versions

[Edward Lewis <lewis@tislabs.com>]

I'm sure a few on the list already know about this...but buried in here is
a question for all.

Up through BIND 9.1.1 there is a bug in the calculation of some key
footprints, specifically DSA keys.  This bug has been fixed in version
9.1.2.  The problem is that BIND 9.1.1 and earlier cannot interoperate with
BIND 9.1.2 and later when processing DSA (actually non-RSA) pulic keys.

We have a few signed zones, delegated from two different signed parents -
CAIRN and our labs.  All of our signed zones are served from the same set
of machines.  The impact of this and the bug fix is that if we upgraded to
9.1.2 (from 9.1.1), we would no longer be able to use DSA keys with our
parents.  If we got just our  labs parent to switch, then we'd have a
problem with CAIRN.  The other case, upgrading with CAIRN only leaves us
with a problem with our labs parent.  Having a "flag day" isn't desirable,
but this scenario hints at one.

One way to fend off a flag day is to migrate to using RSA keys, upgrade
servers individually, and, once all servers are 9.1.2 and newer,
reintroduce DSA and other non-RSA keys.  I'm just throwing this out on the
list as a suggestion.

Folks who are collaborating probably should discuss a deadline for getting
away from 9.1.1 and earlier so non-RSA keys are usable again.  Beside the
parent-child dependencies, resolver-server dependencies will remain a
sticking point.

***Would it be wise to issue a BCP letting folks that after a certain date,
using DNSSEC in pre-9.1.2 BIND is a very bad idea?***  Perhaps a date of
Aug 5 (start of IETF 51).

Some background - the footprint of a key is a 16 bit "short hand"
identifier for a key in a key set.  RSA keys were first defined, with this
16 bit number being the last-2 and last-1 octect of the key's bits (the
last octet is too predictable).  Later, as there were concerns about
patents, etc., DSA keys were defined and in so doing, the footprint
definition used for RSA was deemed unacceptable.  So a new footprint method
was specified for all non-RSA keys.

(Note: RSA/MD5 keys.  I don't know if this will impact the RSA/SHA-1
signature calculation.)

The software bug at the root of all this is: the new footprint is the
result of a function (hash) over the entire RDATA - at least that is what
the spec and 9.1.2+ says.   Up to 9.1.1, only the key bits in the RDATA was
fed to the caculating function.

The impact of this is that if a 9.1.2 resolver gets a signature from a
9.1.2 zone:
        signature from a 9.1.2 served zone, signed by "03894"
        keys arrive, 9.1.2 would calculate the footprints as "12944,03894"
        9.1.2. resolver identifies the second key as the signer, and verifies

If a 9.1.1 resolver is involved:
        signature from a 9.1.2 served zone, signed by "03894"
        keys arrive, 9.1.1 would calculate the footprints as "22842,43924"
        9.1.1. resolver determines the key is non-existent

(Note, the "keys arrive" refers to the same block of keys, but the two
resolvers differ in the footprint calculation.)


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.