[Freeipa-devel] DNSSEC support design considerations: key material handling

[Simo Sorce]

On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote:
> On 23.7.2013 10:55, Petr Spacek wrote:
> > On 19.7.2013 19:55, Simo Sorce wrote:
> >> I will reply to the rest of the message later if necessary, still
> >> digesting some of your answers, but I wanted to address the following
> >> first.
> >>
> >> On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote:
> >>>
> >>> The most important question at the moment is "What can we postpone?
> >>> How
> >>> fragile it can be for shipping it as part of Fedora 20?" Could we
> >>> declare
> >>> DNSSEC support as "technology preview"/"don't use it for anything
> >>> serious"?
> >>
> >> Until we figur out proper management in LDAP we will be a bit stuck, esp
> >> if we want to consider usin the 'somthing' that stores keys instead of
> >> toring them stright in LDAP.
> >>
> >> So maybe we can start with allowing just one server to do DNSSEC and
> >> source keys from files for now ?
> >
> > The problem is that DNSSEC deployment *on single domain* is 'all or nothing':
> > All DNS servers have to support DNSSEC otherwise the validation on client side
> > can fail randomly.
> >
> > Note that *parent* zone indicates that the particular child zone is secured
> > with DNSSEC by sending DS (delegation signer) record to the client. Validation
> > will fail if client receives DS record from the parent but no signatures are
> > present in data from 'child' zone itself.
> >
> > This prevents downgrade (DNSSEC => plain DNS) attacks.
> >
> > As a result, we have only two options: One DNS server with DNSSEC enabled or
> > arbitrary number DNS servers without DNSSEC, which is very unfortunate.
> >
> >> as soon as we have that workign we should also have clearer plans about
> >> how we manage keys in LDAP (or elsewhere).
> 
> Dmitri, Martin and me discussed this proposal in person and the new plan is:
> - Elect one super-master which will handle key generation (as we do with 
> special CA certificates)

I guess we can start this way, but how do you determine which one is
master ?
I do not really like to have all this 'super roles', it's brittle and
admins will be confused which means one day their whole infrastructure
will be down because the keys are expired and all the clients will
refuse to communicate with anything.

I think it is ok as a first implementation, but I think this *must not*
be the final state. We can and must do better than this.

> - Store generated DNSSEC keys in LDAP
> - Encrypt stored keys with 'DNSSEC master key' shared by all servers

ok.

> - Derive 'DNSSEC master key' from 'Kerberos master key' during server 
> install/upgrade and store it somewhere on the filesystem (as the Kerberos 
> master key, on each IPA server)

The Kerberos master key is not stored on disk, furthermore it could
change, so if you derive it at install time and install a replica after
it was changed everything will break. I think we need to store the key
in LDAP, encrypted, and dump it to disk when a new one is generated.

Aside, DNSSEC uses pub/private key crypto so this would be a special
'master key' used exclusively to encrypt keys in LDAP ?

> - Consider certmonger or oddjob as key generation triggers

I do not understand this comment.

> I think that we should add one new thing - a 'salt' - used for Kerberos master 
> key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC 
> master key as necessary without a change in the Kerberos master key.

Salts are not necessary, HKDF from a cryptographically random key does
not require it.

> Does it make sense? Does anybody have any ideas/recommendations which 
> libraries we should use for key derivation and key material en/decryption?

openssl/nss I already have all the basic code we need for that.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York