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

[Rob Crittenden]

Simo Sorce wrote:
> 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.

AFAIU keys don't expire, rather there is a rollover process. The problem 
would be if the server that controlled the rollover went away the keys 
would never roll, leaving you potentially exposed.

> 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.

He is trying to automate the key rollover. I don't think certmonger will 
work as it is designed for X.509 certs. Are you proposing an additional 
attribute to schedule the rollover? I thought that it was a good idea to 
have some flexibility here to prevent timed DoS attacks for rollover time.

>> 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.

I prefer the procedure just outlined in 
https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html 
which just calls dnssec-keygen rather than trying to roll your own. I 
don't know what derivation really buys you.

rob