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

[Petr Spacek]

On 9.8.2013 16:22, Petr Spacek wrote:
> 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.

Simo, did you had a chance to summarize your idea with per-server keys?

Thank you for your time!

-- 
Petr^2 Spacek