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

[Petr Spacek]

On 12.8.2013 14:30, Loris Santamaria wrote:
> El vie, 09-08-2013 a las 16:22 +0200, Petr Spacek escribió:
>> 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.
>
> You could implement a "protocol" where each master has a day or the week
> or the month where it checks if there are any pending keys or CA
> certificates to renew and tries to do the job. Next day it is another
> master's turn to do the same job and so on.
>
> Every master is identified by an unique nsDS5ReplicaId, which could be
> used as a vector to generate an ordered list of masters. If you have
> masters with nsDS5ReplicaId 5,34,35,45 you can say that the one with
> nsDS5ReplicaId 5 is master number one, the next is master number two and
> so on.
>
> On first day of the month it is master number one's turn to check of any
> pending key and CA certificate renewal issues and to do the renewal. On
> second day of the month it is master number two's turn to do the same.
> So if a master was down the job will be done next day by the next
> master.
>
> The cicle will repeat every "number of master" days, in the example
> every four days.

It is interesting idea... but I think that it is could be fragile and create 
some serious problems.

Please see and reply to e-mail in this thread:
https://www.redhat.com/archives/freeipa-devel/2013-September/msg00015.html

Thank you for your time & contribution!

-- 
Petr^2 Spacek