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

Fri Aug 9 14:22:03 UTC 2013

On 9.8.2013 15:12, Rob Crittenden wrote:
> 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 ?
How do we select the 'super-master' for CA certificates? I would re-use the 
same logic (for now).

>> 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.
In DNSSEC it could be a problem. Each signature contains validity interval and 
validation will fail when it expires. It practically means that DNS will stop 
working if the keys are not rotated in time. (More keys can co-exists, so the 
roll-over process can be started e.g. a month before the current key really 
expires.)

>> 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.
I definitely agree. IMHO the basic problem is the same or very similar for 
DNSSEC key generation & CA certificates, so we should solve both problems at 
once - one day.

I mean - we need to coordinate key & cert maintenance between multiple masters 
somehow - and this will be the common problem for CA & DNSSEC.

>>> - 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
Interesting. The master key is stored in the krbMKey attribute in 
cn=REALM,cn=kerberos,dc=your,dc=domain , I didn't know that.

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

>> Aside, DNSSEC uses pub/private key crypto so this would be a special
>> 'master key' used exclusively to encrypt keys in LDAP ?
That was the original intention - generate a new 'DNSSEC master key'/'DNSSEC 
wrapping key' and let named+certmonger/oddjob to play with it.

>>> - Consider certmonger or oddjob as key generation triggers
>>
>> I do not understand this comment.
I mean: How hard would it be to extend certmonger/oddjob to take care of 
DNSSEC key maintenance?

> 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.
It definitely requires some changes in certmonger, I'm just exploring various 
possibilities.

>>> 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.
It is correct as long as you don't need to change the 'derived' key without a 
change in the 'source' key. Did I miss something? We don't need to dive into 
details because (as Simo pointed out) the K/M can change.

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

I think that there is slight misunderstanding. We need to decide how the keys 
generated by dnssec-keygen will be wrapped with 'the DNSSEC master key'. I 
totally agree with using dnssec-keygen for the 'key generation' part! :-)

Simo proposed to use separate keys for each IPA DNS server. It could work in 
theory, but I can see some problems:

How the keys are split:
- The (trusted) parent zone 'com.' contains hashes of public parts of KSKs 
(key signing keys) used by child zone 'example.com.'
- The child zone 'example.com.' contains the whole public parts of KSKs and ZSKs
- KSKs signs ZSKs (zone signing key, the keys used for signing of real data)

Layers are:
   top ] hash of the KSKs in parent zone 'com.'
middle] KSKs in the zone 'example.com.'
bottom] ZSKs - 'zone subkeys' used for real data signing

How the client validates DNSSEC signatures (client operates with public keys):
1) Read hashes of KSKs from (trusted) parent domain 'com.'
2) Get KSKs from the child domain 'example.com.'
3) Compare hashes received from parent domain with hashes computed from KSKs.
4) Trust ZSKs published in the zone 'example.com.' if they are signed by valid 
KSK (valid = hash from parent and the zone itself match).
5) Get data requested by user along with signatures.
6) Validate that the data are signed by one of valid ZSKs.

The point is that *parent* zone has to contain all KSKs used by all IPA 
servers. As a result, different keys on each IPA server will create very 
interesting game with KSKs (on each KSK re-generation, i.e. approximately once 
a year).

The another problem is that each key & signature contains key-id, which has to 
be unique for each key. The client use this key-id to chose the right public 
key for signature validation.

Key-id is 16 bits long unsigned integer, so there is not much space for 
distributed number assignment.

Fortunately, you can re-use key-id if the key was removed from the zone and 
records with this key-id disappeared from all caches. A secure interval for 
key-id reuse can be determined from key TTL.

And the third problem:  Many keys in parent zone will result in much bigger 
responses to clients from the parent. It could cause some problems if we 
exceed some 'local limit'. Some crazy firewalls could drop large UDP DNS 
packets and TCP is not very nice solution alternative.

-- 
Petr^2 Spacek