9:25 a.m.
On 12/16/21 11:10 PM, Alexander Bokovoy wrote:
On to, 16 joulu 2021, Harry G. Coin via FreeIPA-users wrote:
> Alexander and others who care about dnssec:
>
> Given the ongoing problems with opendnssec/libp11 and the many
> freeipa routines and resources dedicated to working around it, has
> bind9's native dnssec implementation improved to the point we can
> greatly reduce the freeipa package count by just using bind's dnssec
> provisions? What's the roadmap on that?
We did a research some time ago and a result was that native DNSSEC
implementation in BIND required some tooling that would have been an
equivalent of what is being done with SoftHSM/OpenDNSSEC:
The BIND / DNSSec guide is rather naive when it comes to storing
private keys:
https://bind9.readthedocs.io/en/latest/dnssec-guide.html#key-storage
Quoting the guide: "Ideally, private keys should be stored offline, in
secure devices such as a smart card. Operationally, however, this
creates certain challenges, since the private key is needed to create
RRSIG resource records, and it is a hassle to bring the private key out
of storage every time the zone file changes or signatures expire. A
common approach to strike the balance between security and practicality
is to have two sets of keys (...) For example, a KSK private key stored
on a USB flash drive that is kept in a fireproof safe, only brought
online once a year to sign a new pair of ZSKs, combined with a ZSK
private key stored on the network file system and available for routine
use, may be a good balance between operational flexibility and
security."
Effectively, this is a repeatance of what OpenDNSSEC provides if you'd
look into making HSM-backed keys.
> My dnssec database was corrupted by a recent freeipa upgrade that
> reverted to upstream code I patched locally some time ago. The
> upstream doesn't really comprehend/value/test multi-concurrent thread
> machine speed key/context/pin updates as deployed by opendnssec /
> softhsm2. Even after I fixed the database by rolling keys and
> identifying corrupt files, etc, etc , the 'new and improved' upstream
> code corrupted it again within minutes. So I've disabled dnssec
> entirely as money to fund those minutes has run out.
Probably a good way going forward would be to have an isolated example
with OpenDNSSEC/SoftHSMv2 alone that shows this set of problems and work
with that to identify the issue. Right now, it seems, there is no a
single place with end to end description of the problem.
Thinking about it for a few days, given ICANN's call for full dnssec
deployment, and the fact that dns-over-tls only provides improved
results between end-user and server (nothing regarding confidence about
server data integrity): I think it's fair to ask the freeipa community
whether now is the time to re-assess the reasons why, after so many
years, freeipa's caution 'dnssec support is experimental' remains
(https://www.freeipa.org/page/Howto/DNSSEC).
Alexander correctly suggests that creating an isolated example that
highlights an issue be done. Notice that becomes much easier to ask for
than produce when the problem is a race condition among threads that
manifests itself in a library that's, what, 4 or 5 packages deep from
the launching daemons, each package maintained by different groups with
different dev priorities abilities regarding multithreading. Remember
'softhsm' is an add-on to a 'smart card' technology most use not at
machine speeds but as humans insert and remove physical security
devices. And significantly -- almost always just one at a time per host.
Multi-processing, multi-threading and re-entrancy (such as during bulk
reconsideration of multiple zsk's, ksks and sqlite db contents while
other threads are assessing master-slave sync issues) are not top of
softhsm/libp11 dev minds and quite understandably. Just a quick look
at libp11's eng_back.c will show even a casual reader externally
accessible routines could find essential variables in an inconsistent
state from a multi-threading perspective ( e.g. ctx->pin ctx->pin_length).
Moreover, since freeipa last reassessed the matter in the big picture,
bind's dnssec shortcomings have been improved. From a maintainability
perspective, there's obviously something to be said for the same results
being delivered by fewer dependencies and fewer points of failure in sub
packages. After all, in the present case, to cite just one example, we
have freeipa's dnssec routines (call it 'top level') running code quite
literally to 'fix' cert/key file permissions so that softhsm,
opendnssec, libp11, openssl-pkcs11, and, bind, can interoperate with
dyndb-ldap and, last, freeipa. While that's obviously necessary to
deliver function, I don't think anybody would call it 'their first
design choice'.
I respectfully ask freeipa folks to re-assess whether bind's
implementation has improved to the point the, ah, 'unfortunate'
documentation Alexander points at might be less important than the
tenuous reliability we experience now owing to reliance on so many
levels of differently maintained packages.
Whether this particular issues persuades the freeipa community or does
not: At least to me, most significantly, it has been many years that
freeipa has written 'dnssec is experimental'. After so long, it's fair
to ask what is lacking that dnssec can't be considered 'production
ready' and take steps to cause that to occur.
Best to all
Harry Coin